I don’t think there should be anything controversial with the changes I made. Can we move onto more pressing issues?
Dino > On Oct 25, 2018, at 8:09 AM, Joel M. Halpern <[email protected]> wrote: > > Actually, given the existence of RFC 8126, varying from that recommendation > for the distinction between Reserved and Unassigned (by which, what we mean > is Unassigned) should only be done with very good reason. > > Yours, > Joel > > On 10/25/18 11:04 AM, Dino Farinacci wrote: >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
