-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jari
Thanks so much for the thorough review. > 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. I will make the changes. What you pointed out if pretty clear, and I agree. > 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. > 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." > 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. Best Regards, Seiichi Jari Arkko wrote: > 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 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAks0qncACgkQcrhTYfxyMkIpXgCfZat8AFLs/nBGnfCUBKsnoSLT 3lQAnRuR0s87uJl5ZyiQy9kZau/U2uCq =vKSf -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
