Le 18/04/2019 à 23:34, 神明達哉 a écrit :
At Thu, 18 Apr 2019 22:32:27 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>> 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
