Re: [ipwave] [Int-dir] 118

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

At Thu, 18 Apr 2019 22:32:27 +0200,
Alexandre Petrescu <[e-mail]> wrote:

> > I personally suggest this specification stick to
> > the current status quo, i.e., 64-bit IID length, so that new
> > developers can develop interoperable implementations without
> > ambiguity.  At the very least, this approach doesn't impose any new
> > procedural bar and will help publish it sooner.
>
> This is your recommendatio, but not the recommendation from AD.  The
> recommendation from AD, if I understand it correctly, is to stay silent
> about this, and get the IID length through 6man.

This is a verbatim copy of Shresh's word:

>> I would like to look at this from a different angle. It is clear from
the current standards that you need to be using fe80::/64 to form the LL
address as the IPv6 address architecture requires the IID to be 64 bits
long (for non b000 prefixes) and SLAAC requires the prefix and the IID
lengths to add up to 128. If you want this changed, I don’t think this is
the document where you should do it. The *burden of proof is on you* to
show why the status quo does not work in this case and IMHO it has not been
meet.

>> I would request that you keep the link-local prefix length discussion
out of this draft, and in 6man where it belongs. Here is the thread that
you started in January this year in 6man

>> https://mailarchive.ietf.org/arch/msg/ipv6/SD0OSOxFe9UGExX84u_CQSdfOsM

>> and the associated draft

>> https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-prefix-len/

>> If you wish to pursue this topic further, please do so with *that*
draft. An IP-over-foo document is not a place to do such a major
architectural change.

It actually seems to be essentially the same as my own personal
suggestion: I would interpret it as: "you should use fe80::/64
according to the current standard; if you want to change it, bring it
to 6man", no?

But yes, it's still just my personal suggestion, and I'm not even an
assigned int-dir reviewer, let alone an AD.  I don't have any power
(or intent) to dictate which approach this draft must take in the end.
It's ultimately up to you and the WG.  I believe I was clear about
that in my previous message.

I still made this suggestion, since if the length of IID is kept
ambiguous I'd certainly raise the same point if and when it reaches an
IETF last call, as a co-author of RFC4862.  But if you'd rather defer
the discussion until that point, please feel free to ignore it in this
thread; I'm already feeling quite guilty about "stealing" a thread
started by a draft review by another int-dir member.

>> Separately, if you believe your cause is strong enough to change the
>> current standard, you can try it at 6man so a non-0 value in the
>> intermediate 54-bit field can be validly used.  IPv6-over-COB can be
>> subsequently updated to reflect that.

> YEs, let us try that.

> I would like to ask you: would you support such a proposal in 6man?

Right now, I'm not convinced.  But I'm open to discussion.  That's why
I asked you to write a draft with the proposal and with detailed
explanation of why it needs to change.  Once I understand it I may or
may not support it.  So,

> OR are you redirecting me there in the hope 6man will discard my
> proposal and I come back to your initial suggestion?
> (the ping pong effect)

of course not.  But I expect your proposal will be quite controversial
and take a long time.  I also admit I *expect* its odds are low and it's
quite possible that you end up falling back to the status quo;
changing a long standing standard is always hard.  But that doesn't
mean I *hope* it will fail (also, my expectation can prove incorrect).

--
JINMEI, Tatuya