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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
