-----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>
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
--------------------------------------------------------------------
