Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261
draft-ietf-sip-ipv6-abnf-fix-05

[Ballot comment]
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.

[Ballot comment]
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].

[Ballot comment]
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
    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.

[Ballot comment]
This I-D says:

  Accordingly, this document updates RFC3261 as follows:  the
    and  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 , , and  production rules
  obsolete.  Thus this document also mandates that the ,
  , and  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.

[Ballot discuss]
This is a fine document and I will be voting Yes once the following issue is discussed.

I would like to discuss more generic implications of the following change in Section 3.2:

  OLD:

  o  For two URIs to be equal, the user, password, host, and port
      components must match.

  NEW:

  o  For two URIs to be equal, the user, password, host, and port
      components must match.  If the host component contains a textual
      representation of IP addresses, then the representation of those
      IP addresses may vary.  If so, the host components are considered
      to match if the different textual representations yield the same
      binary IP address.

So effectively you are replacing binary comparison for the host part with some additional rules to deal with multiple semantically equivalent representations. So this begs the question: what about non-IP hostnames, e.g. US-ASCII hostnames differing in case?