Re: draft-bourbaki-6man-classless-ipv6-00

[神明達哉 <[e-mail]>]

At Wed, 7 Jun 2017 10:13:51 -0500,
David Farmer <[e-mail]> wrote:

> >     IPv6 unicast routing is based on prefixes of any valid length up to
> >     128 [BCP198].  Interface Identifiers must be 64 bit long except
> >     when the addresses are manually configured, or by exceptions defined
> >     in standards track documents.  For example, [RFC6164] standardises
> >     127 bit prefixes on inter-router point-to-point links.  The rationale
> >     for using 64 bit Interface Identifiers can be found in [RFC7421]
> >
> > then there will be no dispute or further time wasting (we'll still
> > need to decide what to do with the magic leading bits of 000 in terms
> > of the interface identifier length, but if we can agree at this level
> > this will be a relatively minor point to address).
>
> I think "should be 64" is the correct language, primarily because "must be
> 64" has been misinterpreted several times to justify hard coding 64 in IPv6
> implementations, but also it seems like a false imperative.  Now that an
> explicit manual configuration exception is included, I could live with
> "must be 64", only if the language is further clarified as an operational
> directive and not an implementation directive to hard code 64 along with
> the list of exceptions.
>
> So I'd prefer; "Interface Identifiers should be 64 bits long except..."
> However, I could live with; "Operationally, Interface Identifiers must be
> 64 bits long except..."

Personally I don't care about should vs must here.  I just thought
this "must" was critical for the so-called "small but vocal" group,
and, if others can accept it with "except..." then it might be a way
forward.  In that sense, I don't see the point of tweaking it further
by such as adding "operationally".  As you said, with the "except"
it's already pretty clear that we cannot simply hardcode the magic
number.  If we are still worried about the blind hardcoding we can
just say implementations must not unconditionally hardcode a particular
value for all cases.

Anyway, my humble suggestion to the wg at this point is to hold off
until the next version of the draft is submitted.  Several people have
already pointed out the current version is so confusing, and, as a
result everyone seems to interpret it in their favorite way (or
overreact to it due to the confusion).  Most of the discussions since
the submission of 00 seem to be largely irrelevant and just time
wasting.  It looks like the authors also acknowledge the need for a
substantial revise, so it's more productive to wait for it and have a
more focused discussion on it.

--
JINMEI, Tatuya