Re: 6MAN WG Last Call: <draft-ietf-6man-text-addr-representation-01.txt>
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6MAN WG Last Call: <draft-ietf-6man-text-addr-representation-01.txt>



I support it.

Half-substantive and half-editorial comments follow.

draft:
When the length of the
   consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
   the former is shortened.

The "former" when reading it left-to-right western latin style? Maybe better "The most significant if represented in network byte order"? Or similar.

Is there any intention to suggest this choice of placement of :: to the IEEE Unix ("Austin Group") who standardizes what inet_pton and ntop do:
http://www.opengroup.org/onlinepubs/9699919799/

?

Or at least add a reference in the draft about the inet_ntop and pton standardization documents, which are IEEE (outside of IETF).

Finally, is there some implementation prototyping in support of recommendation of section 4? I think there may be already.

Alex

Bob Hinden a écrit :
All,

This message starts a 2-week 6MAN Working Group Last Call on advancing:


    Title           : A Recommendation for IPv6 Address Text Representation
    Author(s)       : S. Kawamura, M. Kawashima
    Filename        : draft-ietf-6man-text-addr-representation-01.txt
    Pages           : 14
    Date            : 2009-10-18


as a Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the document editor.

Who is the document editor?

Alex


 This last
call will end on November 5, 2009.

Regards,
Bob Hinden & Brian Haberman
6MAN Chairs
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.