-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jinmei-san
Thanks for your comments. I think they all give help in clarifying. I will make the change. JINMEI Tatuya wrote: > At Thu, 22 Oct 2009 11:00:47 -0700, > Bob Hinden <bob.hin...@gmail.com> wrote: > >> This message starts a 2-week 6MAN Working Group Last Call on advancing: > >> Title : A Recommendation for IPv6 Address Text Representation >> Author(s) : S. Kawamura, M. Kawashima > >> as a Proposed Standard. Substantive comments and statements of >> support for advancing this document should be directed to the mailing >> list. Editorial suggestions can be sent to the document editor. This >> last call will end on November 5, 2009. > > A bit belated, but hopefully later is better than never... > > I've read the latest version and I basically support this document to > be published. > > I have a few comments, which I don't think are marginal (but I'm not > sure if these are substantial enough to require an additional > revision, either). I also have some minor nits. > > Non-marginal comments: > > 1. this document specifies *humans SHOULD* follow the recommended > representation. In section 4 it states: > > [...] The > recommendation in this document SHOULD be followed by humans and > systems when generating an address to represent as text, [...] > > It sounds a little awkward to me to request a human follow something > in this type of context, using a formal RFC2119 term (i.e., > SHOULD). What exactly does that mean, and is it verifiable? > To be specific, it's clear to me if we say a program that converts a > wire-format IPv6 address into a textual representation SHOULD follow > the recommendation, and it SHOULD produce 2001:db8::1234 when it's > given 2001:0db8:0000:0000:0000:0000:0000:1234. And if an > implementation doesn't follow the recommendation, we can it's buggy > (per the meaning of SHOULD) and the implementation should be fixed. > But, when a *human* writes down, e.g., 2001:0db8::1234, which maybe > on purpose or just mistyped or simply because that human misses the > recommended representation, what does that mean? Would we say this > person is buggy and should be fixed? > > IMO, it's safer and clearer to use RFC2119 terms only for programs, > devices, etc. For humans, we can simply use a milder suggestion > without using capital letters, e.g, > "when a human writes down an IPv6 address, it is advisable that the > address be spelled in the recommended representation." > (and, we might also suggest that human use a convenient script to > produce the "canonical" format of address, rather than directly > writing down the address) > > 2. this draft repeatedly mentions "fees" that takes place as an effect > of the additional operation cost. In my personal opinion, these > statements sound awkward in a technical document such as RFC. Of > course, we should generally provide a justification if we want to > introduce a restriction or something new to be implemented, but IMO > it's sufficient if we can show there would be non negligible > overhead (or operational cost) otherwise. Whether it leads to an > additional fee is largely a matter of economics, and is not always > easily proved, so I think it's rather safer to not bother to mention > that when we don't have to. And, I think this document would be > convincing even without mentioning fees. > > 3. Even though this document is generally understandable, I've seen > some confusing text (I'm too lazy to point out each of them, > sorry). Maybe it's a job of the RFC editor, but if possible, I > suggest polishing the text by someone whose primary language is > English (assuming it's not the case for the document authors) > before passing it to the IESG. > > And minor nits follow: > > - Section 3.2.5 > s/maistakenly/mistakenly/ > > - Section 4.2.3 > > "By nature > IPv6 addresses are usually assigned or allocated to end-users as > longer than 32 bits (typically 48 bits or longer)." > > Although I can understand what this means, "addresses as longer > than 32 bits" sounds awkward to me (because an IPv6 address is > always "128 bits" in length). I'd suggest rephrasing this, e.g., > as follows: > > "By nature > IPv6 addresses are usually assigned or allocated to end-users > from a prefix of 32 bits or longer (typically 48 bits or longer)." > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > -------------------------------------------------------------------- > 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) iEYEARECAAYFAkr4ziIACgkQcrhTYfxyMkJYEQCeNU9tG9VPcuksJVK6bWJvBqfo 46EAnjUCrAe1CtnKnhOTf++PAsF6armC =0Rw5 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
