Subject: [dns-dir] Help with errata

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Apr 2012 13:22:02 -0400

Hi all,
      There are quite a few erratum filed against DNS documents sitting 
in "Reported" state.  The IESG routinely gets a list of these and the 
ADs are asked to "deal with them".  I would like to recruit a few people 
willing to review the DNS-related erratum and let me know how they 
should be handled.  There are currently 26 filed against DNS documents.

      The guidelines for how errata gets handled is described in an IESG 
statement (http://www.ietf.org/iesg/statement/errata-processing.html). 
All I ask is a report back with the errata number and what state it 
should be put in.  I will deal with the task of actually doing the state 
changes.

      To make it easier, the list of erratum for DNS documents is 
provided below.

http://www.rfc-editor.org/errata_search.php?eid=3196
http://www.rfc-editor.org/errata_search.php?eid=3197
http://www.rfc-editor.org/errata_search.php?eid=2805
http://www.rfc-editor.org/errata_search.php?eid=461
http://www.rfc-editor.org/errata_search.php?eid=1474
http://www.rfc-editor.org/errata_search.php?eid=1679
http://www.rfc-editor.org/errata_search.php?eid=2984
http://www.rfc-editor.org/errata_search.php?eid=2811
http://www.rfc-editor.org/errata_search.php?eid=2810
http://www.rfc-editor.org/errata_search.php?eid=1680
http://www.rfc-editor.org/errata_search.php?eid=272
http://www.rfc-editor.org/errata_search.php?eid=1063
http://www.rfc-editor.org/errata_search.php?eid=3043
http://www.rfc-editor.org/errata_search.php?eid=1062
http://www.rfc-editor.org/errata_search.php?eid=2681
http://www.rfc-editor.org/errata_search.php?eid=3045
http://www.rfc-editor.org/errata_search.php?eid=2824
http://www.rfc-editor.org/errata_search.php?eid=3044
http://www.rfc-editor.org/errata_search.php?eid=119
http://www.rfc-editor.org/errata_search.php?eid=2647
http://www.rfc-editor.org/errata_search.php?eid=2460
http://www.rfc-editor.org/errata_search.php?eid=2752
http://www.rfc-editor.org/errata_search.php?eid=46
http://www.rfc-editor.org/errata_search.php?eid=2332
http://www.rfc-editor.org/errata_search.php?eid=15
http://www.rfc-editor.org/errata_search.php?eid=1018

Thanks!
Brian

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 29 Apr 2012 09:27:25 +0200

On 27 apr 2012, at 19:22, Brian Haberman wrote:

>     To make it easier, the list of erratum for DNS documents is provided below.

> http://www.rfc-editor.org/errata_search.php?eid=3196

Approved

> http://www.rfc-editor.org/errata_search.php?eid=3197

Approved

> http://www.rfc-editor.org/errata_search.php?eid=2805

Mumble, I think the text is correct, but IF there is a clarification to be made, the new text should be:

   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
   RDLENGTH and RDATA fields are equal. Note that the time-to-live
   (TTL) field is explicitly excluded from the comparison. Further
   that comparison for various data can not be made byte by byte.
   For example domain names are compared regardless of whether
   compression or different casing in US ASCII is in use or not.

> http://www.rfc-editor.org/errata_search.php?eid=461

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1474

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1679

Approved, and I agree with the comments on alternatives (that this is made historic etc)

> http://www.rfc-editor.org/errata_search.php?eid=2984

Approved, although that implies the RFC is really broken (for weights==0) and must be updated.

> http://www.rfc-editor.org/errata_search.php?eid=2811

Approved

> http://www.rfc-editor.org/errata_search.php?eid=2810

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1680

Approved, but see also 1679 above.

> http://www.rfc-editor.org/errata_search.php?eid=272

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1063

Approved, i.e. I agree having that list in an RFC was a bad choice.

> http://www.rfc-editor.org/errata_search.php?eid=3043

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1062

Approved (see 1063 above)

> http://www.rfc-editor.org/errata_search.php?eid=2681

Approved, but I think the example, ac += (ac >> 16) & 0xFFFF;, should also be included in a "new" text.

> http://www.rfc-editor.org/errata_search.php?eid=3045

Approved

> http://www.rfc-editor.org/errata_search.php?eid=2824

Not approved.

All wildcard labels start with * in the leftmost label. No other kind of wildcard label exists.

From RFC 1034:

> 4.3.3. Wildcards
> 
> In the previous algorithm, special treatment was given to RRs with owner
> names starting with the label "*".

I.e. what is suggested is not wrong, but not needed as there is no other wildcard labels than the leftmost.

> http://www.rfc-editor.org/errata_search.php?eid=3044

Approved

> http://www.rfc-editor.org/errata_search.php?eid=119

Not approved.

I.e. the paragraph is standard, and although words are mentioned that are later not used, I do not see this as an error.

> http://www.rfc-editor.org/errata_search.php?eid=2647

Approved

> http://www.rfc-editor.org/errata_search.php?eid=2460

Approved

Not approved, as RFC 4035 already says in section 5.2:

> o  The Algorithm and Key Tag in the DS RR match the Algorithm field
>    and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
>    RRset

As SHA-1 and SHA-256 are different algorithm fields, 4035 already says that SHA-1 based DS should be ignored when using SHA-256.

> http://www.rfc-editor.org/errata_search.php?eid=46

Approved

> http://www.rfc-editor.org/errata_search.php?eid=2332

Approved

> http://www.rfc-editor.org/errata_search.php?eid=15

Approved

> http://www.rfc-editor.org/errata_search.php?eid=1018

Approved

   Patrik

---

From: Brian Haberman <[email-masked]>
Date: Sun, 29 Apr 2012 07:38:58 -0400

Patrik,
      Many thanks for such a quick response.  If I don't hear any 
disagreements in the next few days, I will file these as suggested.

Regards,
Brian

On 4/29/12 3:27 AM, Patrik Fältström wrote:
> Approved, but I think the example, ac += (ac>>  16)&  0xFFFF;, should also be included in a "new" text.
>

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 29 Apr 2012 17:36:54 +0200

I think the ones I have just said "Approved" on are crystal clear. So people wanting to look at more special cases, concentrate on the others.

   Patrik

On 29 apr 2012, at 13:38, Brian Haberman wrote:

> Patrik,
>     Many thanks for such a quick response.  If I don't hear any disagreements in the next few days, I will file these as suggested.
> 
> Regards,
> Brian
>

---

From: Peter Koch <[email-masked]>
Date: Sun, 29 Apr 2012 17:57:40 +0200

Brian, all,

i have followed Patrik's example, but without looking at
his assessments, so this is offered as "second opinion".

> statement (http://www.ietf.org/iesg/statement/errata-processing.html). 

{reordered chronologically}

> http://www.rfc-editor.org/errata_search.php?eid=15
RFC 4701, trivial typo
Suggest: Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=46
RFC 4592, mix of style, typos and one error
Only the last in a list of five (element (5)) is
  erroneous, others I'd disagree with
Suggest: Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=119
RFC4343
There are lots of RFCs with superfluous elements in the
 RFC 2119 word list
Suggest: Reject

> http://www.rfc-editor.org/errata_search.php?eid=272
RFC 3445
The RFC has been obsoleted, teh KEY RRtype is deprecated
in DNSSEC, but RFC 3445 is still at PS; there is no
document update to occur.
Suggest: defer to DNSEXT WG, seek for Historic for RFC 3445

> http://www.rfc-editor.org/errata_search.php?eid=461
RFC 2308
server/resolver confusion correctly spotted, but should
not be misleading within the given context
Suggest: Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=1018
RFC 4956
five issues compiled, with different severity; not completely
  sure how to handle this process wise
(1) significant typo, suggest: Accept
(2) minor typo, suggest: Hold for Document Update
(3) probably minor omission, suggest: Hold for Document Update
(4) suggest: Hold for Document Update
(5) references to RFC 3655 have come up couple of times
   suggest: defer to DNSEXT WG

> http://www.rfc-editor.org/errata_search.php?eid=1062
RFC 4034
Abstain from suggestion

> http://www.rfc-editor.org/errata_search.php?eid=1063
RFC 3597
Abstain from suggestion

> http://www.rfc-editor.org/errata_search.php?eid=1474
RFC 2317, simple typo
Suggest: Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=1679
RFC 2673
The erratum is probably 'overtaken by events', since RFC 2673
has been reclassified as "Experimental", so the question of
it 'updating' 1034/1035 might be less relevant.  Other than that,
as John already identifies in his rationale, it is unclear whether
an erratum can get effect beyond the RFC itself, i.e. the RFC index
in this case.
Suggest: general issue needs further insight

> http://www.rfc-editor.org/errata_search.php?eid=1680
RFC 3364
I agree with most of what John writes, but the problem is that
the actual action of reclassification (to the extent that this
constitutes an "update" in the first place), was an IESG action
(as it should be)
<http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg19416.html>
but that action itself was not recorded in an RFC.  This is another process
glitch. In similar cases, we've issued Informational RFCs giving rationale to
and recording the IESG action while obsoleting the RFC in question.
This method was not applicable here.
Suggest: general issue needs further insight

> http://www.rfc-editor.org/errata_search.php?eid=2332
RFC 4635
(Author/Editor) asks for an "UpdatesRFC 2845" entry.
Reasoning given sounds sensible to me, but we are touching the
same issue as in erratum 1679 as to whether an erratum can
change the RFC Index.
Suggest: general issue needs further insight

> http://www.rfc-editor.org/errata_search.php?eid=2460
RFC 4398
Minor table misalignment, should not confuse the reader
Suggest: Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=2647
RFC 4343
Superfluous "and", which could be misinterpreted as a missing
item in an enumeration
Suggest: Accept

> http://www.rfc-editor.org/errata_search.php?eid=2681
RFC 4034
This should either be covered in <draft-ietf-dnsext-dnssec-bis-updates-17>
or rejected.
Suggest: Defer to DNSEXT WG

> http://www.rfc-editor.org/errata_search.php?eid=2752
RFC 4509
Requests an "Updates RFC 4035"
see above for the same pattern. In this case, -bis Updates
<draft-ietf-dnsext-dnssec-bis-updates-17> would offer a fix.
Suggest: general issue needs further insight

> http://www.rfc-editor.org/errata_search.php?eid=2805
RFC 2136
In my reading, "NAME" always refers to the full owner name, not the
potentially compressed on-the-wire representation, which would make this
an implementation hint at best. The addition is acceptable, but not
necessary IMHO.
Suggest: Reject or Hold for Document Update

> http://www.rfc-editor.org/errata_search.php?eid=2810
RFC 3226
misrepresented reference, proposed fix is OK, although rather obvious.
Suggest: Accept
That said, RFC 3226 is in need of an update since it bases its
size recommendations on th A6 RR type and RFC 2535 DNSSEC.

> http://www.rfc-editor.org/errata_search.php?eid=2811
RFC 3110
I disagree with the perceived significance of the confusion. In fact,
the proposed addition I think is even more confusing than the original text.
Suggest: Reject

> http://www.rfc-editor.org/errata_search.php?eid=2824
RFC 4034
Note: Ed, the reporter, is the editor of RFC 4952 on DNS wildcards
In the context of RFC 4034, section 3.1.3, I disagree that the
proposed text would solve much.  There is a slight misnomer in
calling "*" the "wildcard label", since that special property comes
into effect only in the leftmost position.  www.*.example.com. would
well count the "*".
Suggest: Reject

> http://www.rfc-editor.org/errata_search.php?eid=2984
RFC 2782
There is an issue here, although i am not sure the reporter is right.
It might be that the random number should be greater than 0 and so the
"inclusive" only refers to the "sum". It was for sure not intended to
have two weights (1 and 1) subject to selection based on random numbers
0, 1, and 2.
Suggest: Defer to the DNSEXT WG

> http://www.rfc-editor.org/errata_search.php?eid=3045

These theree request an "Updates: 3007" to be removed from RFCs 4033, 4034, and 4035
Again, unless the issue as such is resolved, the Erratum cannot be handled
Suggest: general issue needs further insight

> http://www.rfc-editor.org/errata_search.php?eid=3197
RFC 1995
The second erratum is not really rlevant IMHO, the first should probably
be covered.  However, Alfred is a co-editor of <draft-ietf-dnsext-rfc1995bis-ixfr-01>,
so I do not really understand what motivated these errata
Suggest: Hold for Document Update

It's interesting to see several errata block on a common pattern.

-Peter

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 30 Apr 2012 15:18:32 -0400

On 27/04/2012 13:22, Brian Haberman wrote:
> Hi all,
> There are quite a few erratum filed against DNS documents sitting in
> "Reported" state. The IESG routinely gets a list of these and the ADs
> are asked to "deal with them". I would like to recruit a few people

Brian I see that Patrik and Peter have responded before me,
I did my evaluation w/o looking at their responses.
Attached is a table of our responses as to when we agree or not
any mistakes in the table are mine.

    Olafur

> http://www.rfc-editor.org/errata_search.php?eid=3196
Agree

> http://www.rfc-editor.org/errata_search.php?eid=3197

I disagree with as RRset is defined in RFC2181 thus it is not an 
appropriate term to use in here.

> http://www.rfc-editor.org/errata_search.php?eid=2805

agree

> http://www.rfc-editor.org/errata_search.php?eid=461
Agree

> http://www.rfc-editor.org/errata_search.php?eid=1474
agree

> http://www.rfc-editor.org/errata_search.php?eid=1679
agree

> http://www.rfc-editor.org/errata_search.php?eid=2984

Not actionable Errata

> http://www.rfc-editor.org/errata_search.php?eid=2811
agree,

> http://www.rfc-editor.org/errata_search.php?eid=2810
agree,

> http://www.rfc-editor.org/errata_search.php?eid=1680
agree

> http://www.rfc-editor.org/errata_search.php?eid=272
agree

> http://www.rfc-editor.org/errata_search.php?eid=1063
agree

> http://www.rfc-editor.org/errata_search.php?eid=3043
agree

> http://www.rfc-editor.org/errata_search.php?eid=1062
same as 1063 approve

> http://www.rfc-editor.org/errata_search.php?eid=2681
agree

> http://www.rfc-editor.org/errata_search.php?eid=3045
same as 3043 approve

> http://www.rfc-editor.org/errata_search.php?eid=2824

already rejected

> http://www.rfc-editor.org/errata_search.php?eid=3044
same as 3043 approve

> http://www.rfc-editor.org/errata_search.php?eid=119
Rejected agree

> http://www.rfc-editor.org/errata_search.php?eid=2647
approved agree

> http://www.rfc-editor.org/errata_search.php?eid=2460
approve,

> http://www.rfc-editor.org/errata_search.php?eid=2752
approve

> http://www.rfc-editor.org/errata_search.php?eid=46
approve

> http://www.rfc-editor.org/errata_search.php?eid=2332
approve

> http://www.rfc-editor.org/errata_search.php?eid=15
fail to see difference between text in RFC and text offered.
reject

> http://www.rfc-editor.org/errata_search.php?eid=1018
approve

	Olafur