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
