Thanks Éric for your review, good catch on section 3 ;-) Ciao
L. Sent from my iPad > On 19 Apr 2022, at 07:33, Eric Vyncke (evyncke) <[email protected]> wrote: > > > Hello Alberto > > Thank you for the prompt reply. All your suggestions look fine for me. Just > unsure about what do your co-authors think about the unknown OUI (which seems > good to me though). > > Regards > > -éric > > PS: thanks for writing my first name with a É ;-) > > From: "Alberto Rodriguez-Natal (natal)" <[email protected]> > Date: Monday, 18 April 2022 at 23:44 > To: Eric Vyncke <[email protected]>, The IESG <[email protected]> > Cc: "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, Luigi Iannone > <[email protected]> > Subject: Re: Éric Vyncke's No Objection on draft-ietf-lisp-vendor-lcaf-10: > (with COMMENT) > > Hi Éric, > > Thanks a lot for your review! Please see inline for some comments (starting > with [AR]). > > Thanks! > Alberto > > From: Éric Vyncke via Datatracker <[email protected]> > Date: Monday, April 18, 2022 at 8:10 AM > To: The IESG <[email protected]> > Cc: [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, Luigi Iannone > <[email protected]>, [email protected] <[email protected]> > Subject: Éric Vyncke's No Objection on draft-ietf-lisp-vendor-lcaf-10: (with > COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-lisp-vendor-lcaf-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-vendor-lcaf/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. The document is short and easy > to read. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), including one that should have > been a blocking DISCUSS but the fix is so easy that I am balloting NO > OBJECTION. > > Special thanks to Luigi Iannone for the shepherd's write-up including the WG > consensus and the experimental status. > > I hope that this helps to improve the document, > > Regards, > > -éric > > ## Abstract & section 1 > > The word "internal" is rather ambiguous. > > [AR] What do you think about using instead “implementation-specific” in the > Abstract? For Section 1 we can probably just remove “internally”. > > > ## Section 1 > > I lack the context of course, but isn't "particular LISP deployments" more for > network operators and less for vendors (like in the doc title) ? I.e, using > "Organisation-specific LCAF" seems more appropriate. > > [AR] “Vendor” is used in the document to refer in general to someone > implementing LISP. Maybe we can use “particular LISP implementations” here > instead? > > > ## Section 3 > > Figure 1 states "Type = TBD" but the text specifies "The "Type" field MUST be > set to the value 255". Using a text similar to section 6 would be an easy fix. > BTW, I was about to raise a blocking DISCUSS on this one. > > [AR] Good catch, we updated the document as a result of Alvaro’s review and > we missed updating this paragraph. How about we phrase this as follows: “The > "Type" field MUST be set to the value assigned by IANA to indicate that this > is a Vendor Specific LCAF (255 is recommended, see Section 6)”. > > > Would this LCAF be used by organisations with any IEEE OUI ? I.e., should > there > be a non-recommended option to use a specific OUI in such a case ? > > [AR] If I understand the IEEE guidelines correctly [1], it seems that an > all-ones value is used to represent unknown/null OUI, maybe we can use that > one? Agree that this should be a non-recommended option. > > [1] > https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
