> -----Original Message----- > From: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp] > Sent: Tuesday, January 05, 2010 1:33 AM > To: Dan Wing > Cc: 'Jari Arkko'; > draft-ietf-6man-text-addr-representat...@tools.ietf.org; > 'IETF IPv6 Mailing List' > Subject: Re: AD review of draft-ietf-6man-text-addr-representation > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jari, Dan > > Happy new year. > > I'm going with Jari's text, > and I'm adding a little to the next paragraph > (which talks about exceptions) > > <t>There will be situations where certain prefixes > that do not meet this > condition will prefer a mixed notation to meet certain needs. > On the other hand, there may > be situations where conditions are met, but full hexadecimal > representation is chosen. > Addressing these needs is out of the scope of this document. > Tools that provide options to > specify prefixes that is (or is not) to be represented as > mixed notation may be useful in > these cases.</t>
Perfect. Thanks! -d > Regards, > Seiichi > > > Dan Wing wrote: > > > > > >> -----Original Message----- > >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > >> Behalf Of Jari Arkko > >> Sent: Monday, December 28, 2009 1:34 AM > >> To: Seiichi Kawamura > >> Cc: draft-ietf-6man-text-addr-representat...@tools.ietf.org; > >> IETF IPv6 Mailing List > >> Subject: Re: AD review of draft-ietf-6man-text-addr-representation > >> > >> Seiichi, > >> > >>> I will make the changes. What you pointed out if pretty clear, > >>> and I agree. > >>> > >> > >> Thanks. > >> > >>>> Sections 5 and 6 are not as strict with respect to > >> recommending a single > >>>> choice as would perhaps be desirable. Is there a reason > >> why the second > >>>> alternative in Section 5 can't be removed and the RFC 3986 > >> format be > >>>> chosen as mandatory in Section 6? For Section 5 I > thought that was > >>>> actually what we had discussed on the list. In other > words, change: > >>>> OLD: > >>>> For these addresses, mixed notation is recommended if > either of the > >>>> below conditions are met. > >>>> > >>>> (1) The address can be distinguished as having IPv4 > >> addresses embedded > >>>> in the lower 32 bits solely from the address field. (e.g. > >> Well Known > >>>> Prefixes) > >>>> > >>>> (2) An external mechanism such as prefix learning or > >> pre-configuration > >>>> helps in recognizing the address as having IPv4 addresses > >> embedded in > >>>> the lower 32 bits. > >>>> NEW: > >>>> For these addresses, mixed notation is recommended if > the following > >>>> condition is met: The address can be distinguished as having IPv4 > >>>> addresses embedded in the lower 32 bits solely from the > >> address field > >>>> through the use of a well known prefix [RFC 4291]. Note that this > >>>> prevents the use of the mixed notation on some addresses > >> that employ a > >>>> dynamically chosen prefix. However, it was felt that the > >> benefits of > >>>> deterministic text representation outweigh the benefits of human > >>>> readability in this case. > >>>> > >>> The original text was close to what you mentioned. > >>> The second point was brought up with a request from the BEHAVE WG. > >>> Removing this would not stop anyone from requiring the mixed style > >>> for representation in a given protocol, but the other > hand, if this > >>> was mentioned here it would provide a pointer to something that > >>> should be considered. > >>> > >> I understand their motivations, given that BEHAVE may > >> introduce new well > >> known prefixes for translation purposes. > >> > >> However, the motivation does not help remove the problem > >> associated with > >> dynamically changing formats. An "external mechanism" may be > >> available > >> on my host's IP layer but is unlikely to exist in my management > >> application or the excel sheet that I use to register my > addresses. > >> Every time you introduce flexibility to the address format > you risk > >> making two different parties arrive at a different representation. > >> > >> We have the following alternatives: > >> > >> 1) Mandate that the text representation is <SOMETHING> and > >> never changes > >> after this. It doesn't change even if new WKPs are assigned. This > >> alternative has the highest likelihood of enabling > >> comparisons, and the > >> smallest likelihood of producing readable IP addresses for mixed > >> IPv6/IPv4 addressing. > >> > >> 2) Mandate that the text representation is <SOMETHING> but > take into > >> account new WKPs. Here we can have a situation where an > updated node > >> produces a different string than an older node, if the older > >> node does > >> not recognize a new WKP. There's still a reasonable > likelihood that > >> eventually the situation will be corrected, and for most > of the time, > >> readable IPv6/IPv4 addressing can be achieved. > >> > >> 3) Mandate that the text representation is <SOMETHING> but > >> require that > >> external mechanisms help recognize even dynamically assigned > >> IPv4/IPv6 > >> prefixes. This has the highest likelihood of producing readable > >> addresses, but relies on the existence and proper use of > the external > >> mechanisms. > > > > For (3), I would like to encourage tools to support something like > > "--prefix=", for example: > > > > tcpdump --64prefix=ABCD::/96 > > > > which helps reduce the worry that a tool might not know of a WKP > > (due to release cycles of the new code), and also means a network- > > specific prefix could also be provided to the tool. > > > > -d > > > >> 4) As above, but specify a mandatory external mechanism. > >> > >> Basically, the choice comes down to how important we > believe readable > >> addresses are in the BEHAVE translation cases vs. likelihood of > >> achieving proper comparisons. My take is that alternative #2 is a > >> practical approach with a very high likelihood of working > correctly. > >> > >> What do other people in the WG think? > >> > >>>> The [] style as expressed in [RFC3986] is recommended. > >> Other styles are > >>>> acceptable when cross-platform portability does not become > >> an issue. > >>>> NEW: > >>>> The [] style as expressed in [RFC3986] should be employed, > >> and is the > >>>> default format unless otherwise specified. Other styles > >> are acceptable > >>>> when there is exactly one style for the given context. For > >> instance, a > >>>> given protocol specification might indicate that the '#' > >> format is used. > >>>> > >>> A discussion early in the draft showed that various > implementations > >>> of a given protocol already had different styles and if > >> they did not mix, > >>> we could live with them. I think the following would work, a mix > >>> of the OLD and NEW. > >>> > >>> "The [] style as expressed in [RFC3986] should be employed, > >> and is the default format > >>> unless otherwise specified. Other styles are acceptable > >> when there is exactly one style > >>> for the given context and cross-platform portability does > >> not become an issue." > >>> > >> I'm fine with this. > >> > >>>> Is there reason why we can't simply recommend the > >> specified algorithm to > >>>> be followed for prefixes as well? > >>>> > >>> Its written in Appendix B. but if you wanted it placed > >> inside the main > >>> text, that's not a problem for me. > >>> > >> Yes, please move it to the main text. > >> > >> Jari > >> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAktDB0wACgkQcrhTYfxyMkJp4QCfQcDJeAXrkmMZZUpk4nOLqDd2 > ocMAnjToOyPD9lC0cKr1zhCTeM4DPa6K > =0LPT > -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
