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

It doesn’t *have to be* what 8126 is. It needs to be what we believe the the unassigned bits are labeled.

Dino

> On Oct 24, 2018, at 10:02 PM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> 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
> > 
> 