This draft was on the IESG review yesterday, and did not get approved
due to a number of Discusses from the other ADs.
There's a number of small details that we can talk about separately, but
I wanted to talk to the working group about the high level issues.
Generally speaking the reviewers were surprised about the lack of
preciseness in the definition of the canonical form. This had to do with
the IPv4-embedded addresses, the specification style and lack of MUST
keywords, and so on. I think everyone believed the draft as currently
written will already improve things, but many reviewers felt that it
could have been much stricter. The reviewers were also wondering about
the role of the draft, will it affect everything or just other
specifications that decide to adopt the new format.
I explained the situation with the IPv4-embedded addresses -- this is a
design tradeoff where we can either nail down everything now and not
have a nice textual representation in some cases, or we can leave some
flexibility. We've already had this discussion in the working group, and
I believe we keep the current approach in the draft. However, we need to
add the rationale to the draft so that future readers are not asking the
same questions as our reviewers did now.
Then we talked about the strictness. I explained that this is largely a
specification style issue, and in the real world there will always be
old code that doesn't produce the canonical form, and that we hope that
this RFC will convince all new code to do the right thing. However, we
came up with the following proposal to make the specification stricter:
- Use RFC 2119 language and MUST. Implementations conforming to this
specification MUST ...
- Provide a reference to the currently defined WKPs
- In the section that talks about ports, please make sure that for URIs
everyone MUST follow RFC 3986, and for the rest, the default can be
again RFC 3986. The current language leaves everything open, even for URIs.
- There's a part about reducing longest sequence of 0s -- it would be
great if we could point to some publicly available code that already
does this, as an informational reference to implementors
- We will keep the specification on the Standards Track, i.e., publish
it as a Proposed Standard
- This specification Updates RFC 4291
Would these changes be acceptable to the working group?
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
