Subject: AD review of draft-ietf-6man-text-addr-representation

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Dec 2009 12:24:03 +0200

I have reviewed this draft.

Overall, this is a long overdue change and I want to move forward with 
this document. There were a couple of issues I wanted to talk to the 
working group before sending the draft to last call, however.

First just an observation. I felt that the motivation part of the draft 
was unnecessarily long and at times not fully waterproof. I think the 
draft would have been stronger by making a short statement about the 
types of problems caused by flexible format rules. I have included some 
specific detailed issues below. I'd like you to correct those, but I'm 
not asking for a bigger rewrite. The important part of this draft is the 
recommendation.

Second, I am not entirely comfortable with Section 5 and 6 
recommendations, as they do not actually specify a format that can be 
deterministically followed by all parties. I have included some 
suggestions below on how this could be fixed. My understanding is that 
there was some discussion in the working group along these lines 
earlier. I don't want to oppose the working group's opinion if you 
really think that the current text is the best we can do. However, I 
wanted to have a discussion before we proceed.

Third, I would suggest that the draft should be extended to explicitly 
cover prefix formats as well.

Detailed comments:

> An SNMP GET of an interface address and text representation in a 
> humanly written text file is highly unlikely to match on first try.

The result of an SNMP GET operation, converted to text and compared to a 
textual address written by a human is highly unlikely to match on first 
try.l

(SNMP returns binary)

> Some protocols require certain data fields to be verified.  One
> example of this is X.509 certificates.  If an IPv6 address was
> embedded in one of the fields in a certificate, and the verification
> was done by just a simple textual comparison, the certificate may be
> mistakenly shown as being invalid due to a difference in text
> representation methods.
>   

But the IP address fields in certificates are in binary, not text. In 
order for this to happen the implementation would have to convert binary 
to text and compare it to some other data that is either already in text 
or was converted to text with a different algorithm. Suggested rewrite:

Some protocols require certain data fields to be verified.  One example 
of this is X.509 certificates. If an IPv6 address field in a certificate 
was incorrectly verified by converting it to text and making a simple 
textual comparison to some other address, the certificate may be 
mistakenly shown as being invalid due to a difference in text 
representation methods.

> For example, a system may take an input of
> 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
> RIR databases).

Remove the sentence in parentheses (its not quite clear where "which" 
refers to).

>  A distinguished engineer will know that
>  the right address is set, but an operator, or a customer that is
>  communicating with the operator to solve a problem, is usually not as
>  distinguished as we would like.
>   

Maybe better as "Someone familiar with IPv6 address representation knows 
that the right address is set, but not everyone may understand this."

> NOC

network operations center

> Usually, a change in a platform (e.g.
>    Unix to Windows, Cisco to Juniper) will result in a major change of
>    code, but flexibility in address representation will increase the
>    work load.

Maybe better as: ... major change of code anyway, but ...

>    With all the possible text representation ways, each application must
>    include a module, object, link, etc. to a function that will parse
>    IPv6 addresses in a manner that no matter how it is represented, they
>    will mean the same address.  This is not too much a problem if the
>    output is to be just 'read' or 'managed' by a network engineer.
>    However, many system engineers who integrate complex computer systems
>    to corporate customers will have difficulties finding that their
>    favorite tool will not have this function, or will encounter
>    difficulties such as having to rewrite their macro's or scripts for
>    their customers.
...
>   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.  It is advised that
>    humans also follow these recommendations when spelling an address.

I'll note that as long as we must accept any legitimate 4291 format, all 
implementations still need that function that the first text excerpt 
talks about.

> Place holder zeros are often cause of misreading.
>   

This text in Section 4 is redundant, well described earlier. Just delete 
this.

> together, there seems to be many different ways to do so.  Examples

s/seems to be/are/

>    However, there may be situations where full hexadecimal
>    representation is chosen to meet certain needs.  Addressing those
>    needs is out of the scope of this document.  The text representation
>    method noted in Section 4 <http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-03#section-4> should be applied for the leading
>    hexadecimal part (i.e. ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:
>    192.0.2.1).
>   
Is the last sentence connected to the rest of this paragraph? I think 
not. If so, move that sentence out of this paragraph, and place a new 
paragraph before it.

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.

And

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

Is there reason why we can't simply recommend the specified algorithm to 
be followed for prefixes as well?

Jari

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 25 Dec 2009 21:05:11 +0900

Hi Jari

Thanks so much for the thorough review.

> not asking for a bigger rewrite. The important part of this draft is the

I will make the changes. What you pointed out if pretty clear,
and I agree.

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

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

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

Best Regards,
Seiichi

Jari Arkko wrote:
>>    method noted in Section 4
>> <http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-03#section-4>
>> should be applied for the leading
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Dec 2009 11:34:03 +0200

Seiichi,

> I will make the changes. What you pointed out if pretty clear,

Thanks.

> was mentioned here it would provide a pointer to something that

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?

> for the given context and cross-platform portability does not become an issue."

I'm fine with this.

> text, that's not a problem for me.

Yes, please move it to the main text.

Jari