Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261
RFC 5954

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) Yes

(Lars Eggert) Yes

Alexey Melnikov (was Discuss) Yes

Comment (2010-05-10)
No email
send info
Note to myself and Peter: The problem of matching of different textual forms of IPv6 addresses might affect other URI schemes.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2010-05-20)
No email
send info
I found the use of RFC 2119 "MUST" in Sections 3.1 and 3.2 a bit odd. I think you could have used "are replaced" instead of "MUST be replaced" since your document *is* the implementation of the documentation.

But it not important enough to worry about.

(David Harrington) No Objection

Comment (2010-05-18)
No email
send info
Should RFC3261 be corrected by Errata, as well?

(Russ Housley) No Objection

Comment (2010-05-19)
No email
send info
  The Gen-ART Review by Suresh Krishnan on 17-May-2010 raises a point
  that deserves a response:

    The draft also fixes the ABNF for IPv4 addresses i.e. the
    <IPv4address> rule but is silent about why it is doing so.
    I think I understand why it is being fixed but I would like
    the authors to clarify.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-05-18)
No email
send info
This I-D says:

   Accordingly, this document updates RFC3261 as follows:  the
   <IPv6address> and <IPv4address> production rules MUST be deleted from
   RFC3261 and MUST be replaced with the production rules of the same
   name in RFC3986 (and reproduced above.)  These changes, when made to
   RFC3261, will make <hexpart>, <hexseq>, and <hex4> production rules
   obsolete.  Thus this document also mandates that the <hexpart>,
   <hexseq>, and <hex4> production rules MUST be deleted from the ABNF
   of RFC3261.

What does it mean that certain production rules MUST be deleted from RFC3261? Isn't that RFC immutable once published? I think it would be clearer to say that those production rules MUST be deleted from any specification that obsoletes RFC3261, and that this specification updates RFC3261 accordingly.

(Sean Turner) No Objection

Comment (2010-05-19)
No email
send info
This is nitpicky, but I think you should point to [1] in the first sentence of the security consideration:

This document does not introduce any security considerations in addition to those described in [1].