Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

Hi Dino,

Thank you.

I’m afraid that « reserved and unassigned » is still not appropriate (see 8126). Please change it with “unassigned and available for future use”.

Cheers,
Med

De : Dino Farinacci [mailto:farinacci@gmail.com]
Envoyé : jeudi 25 octobre 2018 05:05
À : BOUCADAIR Mohamed TGI/OLN
Cc : Luigi Iannone; lisp@ietf.org
Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

How about these changes? So we can not over complicate this.

Dino

> On Oct 24, 2018, at 2:24 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
>
> Hi Luigi,
>
> Fully agree that changing the text and updating the figures would be appropriate.
>
> Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis-24, e.g.,
>
>   R: The R-bit is a Reserved bit for future use.  It MUST be set to 0
>      on transmit and MUST be ignored on receipt.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Luigi Iannone [mailto:ggx@gigix.net]
>> Envoyé : mercredi 24 octobre 2018 10:01
>> À : Dino Farinacci
>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org
>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned
>>
>> Hi All,
>>
>> disclaimer: this is my personal point of view.
>>
>> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it up.
>>
>> While I understand Dino’s reply, because I my self as well always thought
>> “reserved = can be used in the future”, I think that Med is right.
>>
>> To be compliant with RFC 8126, and because we may need those “reserved” bits
>> in the future, we better mark them as “unassigned”.
>> This means changing the text and clearly spell out that this is conform to
>> RFC 8126 definitions.
>>
>> At the end, it is as simple as adding the following sentence in section 2
>> “Requirements Notation”:
>>
>>       The  “Unassigned” and “Reserved” terminology for bits and fields of
>>       messages and headers defined in this documents is the Well-Known
>>       Registration Status Terminology defined in Section 6 of [RFC8126].
>>
>>
>> Then we just replace “reserved” with “unassigned” throughout the document.
>>
>> Ciao
>>
>> L.
>>
>>
>>
>>> On 23 Oct 2018, at 18:27, Dino Farinacci <farinacci@gmail.com> wrote:
>>>
>>> I am not sure if we should make this distinction. What does the WG think?
>> Because fields marked “reserved” are obviously unassigned and don’t know if
>> they will be assigned in the future.
>>>
>>> So I am not sure how helpful in making the distinction.
>>>
>>> Dino
>>>
>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote:
>>>>
>>>> Hi Dino, all,
>>>>
>>>> Apologies for raising this late easy to fix comment:
>>>>
>>>> RFC8126 says the following:
>>>>
>>>>     Unassigned:  Not currently assigned, and available for assignment
>>>>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>           via documented procedures.  While it's generally clear that
>>>>           any values that are not registered are unassigned and
>>>>           available for assignment, it is sometimes useful to
>>>>           explicitly specify that situation.  Note that this is
>>>>           distinctly different from "Reserved".
>>>>
>>>>     Reserved:  Not assigned and not available for assignment.
>>>>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>           Reserved values are held for special uses, such as to extend
>>>>           the namespace when it becomes exhausted.  "Reserved" is also
>>>>           sometimes used to designate values that had been assigned
>>>>           but are no longer in use, keeping them set aside as long as
>>>>           other unassigned values are available.  Note that this is
>>>>           distinctly different from "Unassigned".
>>>>
>>>> This is well handled in Section 5.1, but not in other sections which are
>> using Reserved instead of Unassigned as per RFC8126.
>>>>
>>>> It would be appropriate to update the text accordingly. Thank you.
>>>>
>>>> Cheers,
>>>> Med
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>