Changing it to what? Be specific commenters. Dino
> On Oct 29, 2018, at 2:02 AM, Luigi Iannone <[email protected]> wrote: > > > >> 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
