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