> On 25 Oct 2018, at 18:01, Dino Farinacci <[email protected]> wrote: > > Do you think what I added will be objected to?
May be. IMO The point is: If you do not doing it now and someone complains you will slow down publication by weeks. If you do it now you will spend 5 minutes and everybody will be happy. Your call. Ciao L. > > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
