Hi Dino, If I were the editor of the document, I would follow 8126.
Thank you. Cheers, Med > -----Message d'origine----- > De : Dino Farinacci [mailto:[email protected]] > Envoyé : jeudi 25 octobre 2018 17:04 > À : BOUCADAIR Mohamed TGI/OLN > Cc : Luigi Iannone; [email protected] > Objet : 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, <[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
