David, The problem is that we cannot make this a required format. Like it or not, there is a range of ways to represent an IPv6 address in text form, and has been for many years. 2001:DEAD:BEEF:: and 2001:deAd:BEeF:: are the same address.
The draft is very precise on this point: The recommendation in this document SHOULD be followed by systems when generating an address to represent as text, but all implementations MUST accept any legitimate [RFC4291] format. This is the only approach which is consistent with history. Making that SHOULD into a MUST would be simply unrealistic. But I really don't understand your objection to this as a standards track document. It's a complete, if simple, normative specification. (It could also have been a BCP, imho, but the WG preferred standards track.) I don't see any particular need to provide pseudocode; it wouldn't change the normative content. It certainly wouldn't do any harm. Regards Brian Carpenter On 2010-02-03 03:36, black_da...@emc.com wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-6man-text-addr-representation-04 > Reviewer: David L. Black > Review Date: February 2, 2010 > IESG Telechat date: February 4, 2010 > > Summary: > This draft is on the right track, but has open issues, described > in the review. > > Comments: > The draft provides recommendations for a canonical format for IPv6 > addresses. > > The open issue is that the draft only provides recommendations, and > does not tightly specify a canonical format. A tight specification > of a canonical format would include at least one (and preferably > both) of: > - An algorithm to test whether an IPv6 text address > is in the canonical format > - An algorithm to convert an IPv6 text address into canonical > form. > Code or pseudo-code should be used, and note that the latter item > subsumes the former (a canonicalization algorithm makes no changes to > input that's already in the canonical format). In the absence of > these elements, I'm not convinced that the draft defines an > interoperable standard that solves the problem. > > This document is a good start - I think it's a fine requirements > document that would be appropriate to publish as an Informational RFC, > but I believe that more work is needed to produce a standards-track RFC > that specifies an interoperable representation. If this document > is published in its current form, it should be edited slightly to > make it clear that it is only a requirements document. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_da...@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
