Re: [ipwave] 118

[Alexandre Petrescu <[e-mail]>]

Le 18/04/2019 à 23:34, 神明達哉 a écrit :
> At Thu, 18 Apr 2019 22:32:27 +0200,
> Alexandre Petrescu <[e-mail] 
> <mailto:[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?

No.  HE first says what he thinks as a participant (he thinks 64 is the 
rule).  Then he becomes AD and says that if I want that changed it is 
not in OCB document, but in 6man WG.

> 
> 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.

The IID len is ambiguous now in IP-over-OCB draft.
The IID len should be fixed quickly in 6man.  They cant delay this 
IP-over-OCB document with infinite discussions.

>  >> 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).

This is a structural problem.

If you direct us to 6MAN and know and assume the variable len IID gets 
stuck there then you should not direct as there.

Alex

> --
> JINMEI, Tatuya