I believe to be crystal clear, we should use the text “reserved and unassigned” everywhere. I do not want to change names of bits or else they may clash with other fields.
Dino > On Oct 24, 2018, at 6:25 AM, [email protected] wrote: > > Joel, > > "is a Reserved bit for future use" contradicts with its definition in RFC8126 > which says "Reserved: Not assigned and not available for assignment". > > The text should be tweaked IMO to avoid that. For example, > > OLD: > 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. > NEW: > > U: The U-bit is unassigned and available for future use. It MUST be set > to 0 > on transmit and MUST be ignored on receipt. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:[email protected]] >> Envoyé : mercredi 24 octobre 2018 15:15 >> À : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci >> Cc : [email protected] >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >> >> Med, just to be clear. Ar eyou saying that we should change the word >> Reserved to Unasigned? THe text would read weirdly, but I can live with >> it. We need to keep the rest of the text, as it is critical for future >> interoperability. >> >> Yours, >> Joel >> >> On 10/24/18 5:24 AM, [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
