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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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.