Mailing List Archive

On Monday 25 February 2008 18:46, Frank Ellermann wrote:
> Hi, apart from one tricky issue our 4408-errata page is IMO
> in good shape. At the moment the RFC-editor folks still
> list it as "reported" instead of "verified". There was a
> backlog of about 300 pending errata for some years, that's
> now cleaned up.
>
> The proposed procedure is that if each IETF area director
> tackles two unverified errata per month they hope to be
> up to date within a year (starting 2008-02). I'd like to
> propose the 4408-errata as a kind of low hanging fruit, is
> that okay for you ?
>
> Actually I wanted to do it earlier (before 2008-02-03), but
> I didn't know that there are "only" 300 unverified errata,
> and that the I* accepted "confirmation by area director" as
> strategy for errata affecting IETF RFCs.
>
What's the tricky issue?

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote:

> What's the tricky issue?

The discrepancy reported by Julian some weeks (or now already
months) ago. I'm not sure that I recall it correctly, that's
why I consider it as "tricky"... ;-)

It was arguably related to the last pending erratum:
http://www.openspf.org/RFC_4408/Errata#permerror-invalid-domains

Possibly I confuse it - Julian, please corect me - if not it's
this statement in the "PermError" (2.5.7) section...

| Be aware that if the domain owner uses macros (Section 8),
| it is possible that this result is due to the checked
| identities having an unexpected format.

...in combination with the following statement in section 4.4
(record lookup):

| If all DNS lookups that are made return a server failure
| (RCODE 2), or other error (RCODE other than 0 or 3), or time
| out, then check_host() exits immediately with the result
| "TempError".

We do not want "TempError" for HELO do..ts.example or similar
crap in a <target-name> after macro expansion. Odd, looking
at it again it appears to be simple, section 2.5.7 trumps 4.4,
end of story.

I'm too lazy to dig in the list archive today. Is that all a
hallucination on my side, RFC 4408 always wanted PermError for
adjacent dots ? In that case I could mark the wannabe-erratum
as bogey stating that 4.4 is limited to the cases not already
covered by 2.5.7.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Frank Ellermann wrote:
> I'm too lazy to dig in the list archive today. Is that all a
> hallucination on my side, RFC 4408 always wanted PermError for
> adjacent dots ? In that case I could mark the wannabe-erratum
> as bogey stating that 4.4 is limited to the cases not already
> covered by 2.5.7.

That would make sense if the explanation about DNS timeout were coded
in section 2.5.6. Besides 4.4, section 5 also repeats that same
concept. As a matter of taste, I think the specifications would be
more readable if the discussion on DNS RCODEs were concentrated in a
single section. (This has probably been discussed already as well.)

I hope marking errata is a prelude to preparing a new version of the
specifications...

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com