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
