Do you think what I added will be objected to? Dino
> On Oct 25, 2018, at 8:57 AM, Joel M. Halpern <[email protected]> wrote: > > Is it a big deal? No. > Is it likely someone will ask for it during IESG review? Moderate. > Would I just do it in your shoes? Yes. > Do you have to do it? No. > > Yours, > Joel > > On 10/25/18 11:48 AM, Dino Farinacci wrote: >> 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
