In message <[email protected]>, Jari Arkko writes: > 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
ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in BIND 9. > - 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 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
