Benoit Claise's No Objection on draft-ietf-6man-ug-06: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-6man-ug-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-ug/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection to the publication, but let's speak about this one.

When you wrote about the "u/l" bit:

      In an IID, this bit is in position 6, i.e., position 70 in the
      complete IPv6 address.

You actually mean the 7th position because you start counting at 0. I
guess that you have RFC 4291 appendix. A in mind:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+


Without knowing that you start counting at 0, this is a mistake.
Proposal (but feel free to develop your own text):

      In an IID, this bit is in the seventh from the left, i.e., position
70 in the
      complete IPv6 address, when starting counting at zero like in the
figures in RFC 4291 appendix A.

Same remark for the "i/g" bit:

      In an IID, this bit is in position 7, i.e., position 71 in the
      complete IPv6 address.

NEW ADDITION TO THIS "NO OBJECTION", FOLLOWING AN EMAIL DISCUSSION WITH
BRIAN:
>>> RFC 4291, section 2.5.1
>>> <http://tools.ietf.org/search/rfc4291#section-2.5.1>. Interface
>>> Identifiers
>>>      Interface identifiers in IPv6 unicast addresses are used to
identify
>>>      interfaces on a link.  They are required to be unique within a
subnet
>>>      prefix.  It is recommended that the same interface identifier
not be
>>>      assigned to different nodes on a link.
>>> "it's _required _to be unique", so you're right.
>>> On the other hand, I see "It is _recommended _that the same
interface
>>> identifier not be assigned to different nodes on a link "
>>> It seems to me that those 2 sentences contradict each other. I'm
>>> slightly confused....
> That 'recommended' does seem screwy,
Is this something you should be updating (in the sense OLD/NEW) in the
draft?
It would make sense to me...