I’ll add the suggested text. Queued up for draft-ietf-lisp-rfc6833bis-16.
Thanks, Dino > On Sep 25, 2018, at 1:10 PM, BRUNGARD, DEBORAH A <[email protected]> wrote: > > As Alvaro suggested, we could have incorporated all of RFC8113 here, and > obsolete it. But it also is ok as a standalone. The group wanted to continue > with it as a standalone. I think though we need to be clear on the > relationships. I think Dino is right, RFC8113 is only (and should be only) > informative here. There are some inter-relationships which we should clarify > in this document and 8113bis. Also need to clarify a bit more what is to be > done in the IANA section - I'm sure IANA will do ok - but it will make it > clearer for others. > > (Thanks Alvaro!!!) > > Section 5.1 > ========= > OLD > For completeness, this document references the LISP Shared Extension Message > assigned by [RFC8113]. > NEW > For completeness, the summary below includes the LISP Shared Extension > Message assigned by [RFC8113]. > OLD > Values in the "Not Assigned" range can be assigned according to procedures in > [RFC8126]. Documents that request for a new LISP packet type may indicate a > preferred value. > NEW > Values in the "Not Assigned" range can be assigned according to procedures in > [RFC8113]. > (Deborah: 8113 set up the guidelines for the unassigned, the reader should > refer to it. This will answer Alvaro's question on the procedures. Hint for > Alvaro: unassigned is done via standards action.) > OLD > Protocol designers experimenting with new message formats SHOULD use the LISP > Shared Extension Message Type and request a [RFC8113] sub-type assignment. > NEW > Protocol designers experimenting with new message formats are recommended to > use the LISP Shared Extension Message Type [RFC8113]. > (Deborah: I think this sentence could be deleted, but if want to keep, I > think it should not be "normative") > > LISP Packet Type Codes > =================== > * For authors of RFC8113bis: need to add to 8113bis "updates 6833bis" > Suggest: > OLD > It is being requested that the IANA be authoritative for LISP Packet Type > definitions and that it refers to this document as well as [RFC8113] as > references. > New > It is being requested that the IANA be authoritative for LISP Packet Type > definitions and it is requested to replace the [RFC6830] registry message > references with the RFC number assigned to this document. > > OLD > message type 5, was added to this document NEW message type 5, > NEW > message type 5, was added by this document NEW message type 5, > > LISP ACT and Flag Fields > ==================== > OLD > Four values have already been allocated by [RFC6830]. > NEW > Four values have already been allocated by [RFC6830], IANA is requested to > replace the [RFC6830] reference for this registry with the RFC number > assigned to this document and the [RFC6830] Action values references with the > RFC number assigned to this document. > > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Dino Farinacci > Sent: Tuesday, September 25, 2018 12:03 PM > To: [email protected] > Cc: [email protected]; [email protected]; The IESG <[email protected]>; > [email protected]; Alvaro Retana <[email protected]> > Subject: Re: [lisp] Alvaro Retana's No Objection on > draft-ietf-lisp-rfc6833bis-13: (with COMMENT) > > That is not the part I had a problem with. Consider it added. > > Dino > >> On Sep 25, 2018, at 2:22 AM, <[email protected]> >> <[email protected]> wrote: >> >> Hi Dino, >> >> I think that Alvaro has a valid point about rfc8113bis to be cited as >> normative. >> >> This is easy to fix, IMO. Thanks. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : lisp [mailto:[email protected]] De la part de Dino Farinacci >>> Envoyé : lundi 24 septembre 2018 19:39 À : Alvaro Retana Cc : >>> [email protected]; The IESG; [email protected]; >>> [email protected] >>> Objet : Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp- >>> rfc6833bis-13: (with COMMENT) >>> >>> Alvaro, I don’t know what you want to be satisified with the text. >>> And rather than go 20 questions, with weeks of turn-around time, can >>> you offer text please? >>> >>> Dino >>> >>>> On Sep 24, 2018, at 8:33 AM, Alvaro Retana <[email protected]> wrote: >>>> >>>> On September 11, 2018 at 12:23:04 PM, Dino Farinacci >>>> ([email protected]) >>> wrote: >>>> >>>> Hi! >>>> >>>> I’m back to this document…after the Defer... >>>> >>>> ... >>>>>> (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting >>> rfc6830, I >>>>>> think that, because of how the contents of that RFC were >>>>>> distributed, >>> this >>>>>> document should also be tagged as Obsoleting rfc6830. >>>>> >>>>> Done. >>>> The text is there, but the tag in the header is missing ("Obsoletes: >>>> 6833 >>> (if approved)”). >>>> >>>> >>>> >>>>>> (4) The LISP Packet Types registry was set up in rfc8113. This >>>>>> document >>> asks >>>>>> that IANA "refers to this document as well as [RFC8113] as references" >>> (§11.2), >>>>>> and it seems to try to change the registration (or the text is >>> incomplete) in >>>>>> (§5.1): "Values in the "Not Assigned" range can be assigned >>>>>> according to procedures in [RFC8126]." Which procedure? s/Not >>>>>> Assigned/Unassigned (§6 >>> in >>>>>> rfc8126) >>>>> >>>>> The early values are already registered with IANA. This document is >>>>> asking >>> to register the new ones which include type 15. And the values >>> *within* type >>> 15 are documented in RFC8113. >>>> The only place where I see type 15 referenced is in §5.1. If that >>>> section >>> is "asking to register the new ones which include type 15”, then >>> these are instructions to IANA. >>>> >>>> Regardless, a pointer from §11.2 to §5.1 won’t hurt the document. >>>> >>>> >>>> >>>>>> (5) Because of the point above, this draft should (at least) >>>>>> Update >>> rfc8113 >>>>>> (see also below). >>>>> >>>>> Don’t follow. >>>> This document asks that the LISP Packet Type registry point also to >>>> this >>> registry. That is a change to the registry, which was defined in >>> rfc8113 (which is the only current reference). Updating the registry >>> this way should be signaled with an update to rfc8113 in this document. >>>> >>>> >>>> >>>>>> (6) This document says that "Protocol designers experimenting with >>>>>> new >>> message >>>>>> formats SHOULD use the LISP Shared Extension Message Type". I >>>>>> think this statement makes rfc8113 a Normative reference -- which >>>>>> results in a >>> DownRef. >>>>>> Suggestion: given that this document already updates the registry >>>>>> set up >>> in >>>>>> rfc8113, and recommends the use of the Shared Extension Message, >>>>>> it may >>> be a >>>>>> good idea to simply adopt the contents of that document here >>>>>> (grand >>> total of 6 >>>>>> pages) and declare it Obsolete. >>>>> >>>>> I’m yielding to the lisp-chairs and Deborah for this one. >>>> I see that there’s a WG adoption call for rfc8113bis. That’s fine >>>> with me >>> — but I still think that the reference should be normative. >>>> >>>> Thanks! >>>> >>>> Alvaro. >>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai >>> lman_listinfo_lisp&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7 >>> jYlxXD8w&m=oId2sNzdWAJ97tLbuZUKthdnDylZ3Imi2N7zYcMdkbc&s=5h76BQw8IAJV >>> MN23ujgggCFwRXldKTwkRTWpxrH-_Mk&e= > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
