Hi, Thanks for addressing my comments, and for explaining the reason for Experimental :) Regards, Christer -----Original Message----- From: Luigi Iannone <ggx@xxxxxxxxx> Sent: tiistai 12. huhtikuuta 2022 10.14 To: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Cc: gen-art@xxxxxxxx; draft-ietf-lisp-vendor-lcaf.all@xxxxxxxx; last-call@xxxxxxxx; lisp@xxxxxxxx Subject: Re: Genart last call review of draft-ietf-lisp-vendor-lcaf-09 Hi Christer, Thanks for the review. As a shepherd I have a couple of comments inline. > On 11 Apr 2022, at 22:35, Christer Holmberg via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Christer Holmberg > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lisp-vendor-lcaf-09 > Reviewer: Christer Holmberg > Review Date: 2022-04-11 > IETF LC End Date: 2022-04-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > The document is well written, and easy to read and understand. > However, I do have a couple of issues. > > Major issues: > > Q1: > > I do wonder why the document is published as Experimental, however, > due to the following reasons: It is experimental because is an update to RFC 8060, which is experimental. So unless we move that one to standard track I would say that is the right type of RFC. > > a) > > The document defines usage of the Type value 255. > > b) > > Section 3 says: > > "If a LISP device receives a LISP message containing a Vendor Specific > LCAF with an OUI that it does not understand, it MUST drop the > message and it SHOULD create a log message." > > This sounds like an update to LISP. > Excellent point. Actually this document updates RFC 8060, and this should be stated in the document. > c) > > Section 3 defines new header fields. > > Minor issues: > > N/A > > Nits/editorial comments: > > Q2: > > Section 1 says: > > “The Vendor Specific LCAF allows organizations to create > LCAF addresses to be used only internally on particular LISP > deployments.” > > Is “allows” the best wording? Where organizations previously > disallowed to do this? > > Would it be more correct to say “defines how organizations can create…”? Yes, this wording is more correct. Ciao L. > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
