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://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
