Re: 6MAN WG Last Call: <draft-ietf-6man-text-addr-representation-01.txt>

[Seiichi Kawamura <[e-mail]>]

-----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 <[e-mail]> 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
> [e-mail]
> 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-----