Re: [ipwave] [Int-dir] 118

[Russ Housley <[e-mail]>]

Alex:

You have received very clear feedback on this point, and it has been consistent throughout the long history on this document.  I do not understand why you are continuing to pushback.  I declare WG consensus for staying with the  /64 boundary.

Russ


> On Apr 19, 2019, at 12:10 AM, Suresh Krishnan <[e-mail]> wrote:
> 
> Hi Alex,
> 
> 
>> On Apr 18, 2019, at 5:44 PM, Alexandre Petrescu <[e-mail]> wrote:
>> 
>> 
>> 
>> 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.
> 
> The view I expressed earlier is the same Jinmei-san is expressing above. Not sure where you see a disconnect when you respond with a “No”. The right forum for discussion is 6man. As I said before, keep this non-64 discussion off the OCB document.
> 
>> 
>>> 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.
> 
> Use 64 in this document and it will be compliant to current standards. If you want it changed, make your case in 6man to get it changed.
> 
>> 
>>>>> 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.
> 
> 6man is the venue for this discussion. If nobody else shares your view (which is what I see) your document will get stuck. That *does not* mean you can use your position as the editor of the OCB document to insert your view of the IID length here.
> 
> Thanks
> Suresh