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, <[email protected]> > <[email protected]> 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:[email protected]] > Envoyé : jeudi 25 octobre 2018 05:05 > À : BOUCADAIR Mohamed TGI/OLN > Cc : Luigi Iannone; [email protected] > 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, <[email protected]> > > <[email protected]> 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:[email protected]] > >> Envoyé : mercredi 24 octobre 2018 10:01 > >> À : Dino Farinacci > >> Cc : BOUCADAIR Mohamed TGI/OLN; [email protected] > >> 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 <[email protected]> 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, [email protected] 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 > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
