Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-vendor-lcaf-10: (with COMMENT)

["Alberto Rodriguez-Natal (natal)" <[e-mail]>]

Hi Éric,

Thanks a lot for your review! Please see inline for some comments (starting with [AR]).

Thanks!
Alberto

From: Éric Vyncke via Datatracker <[e-mail]>
Date: Monday, April 18, 2022 at 8:10 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Luigi Iannone <[e-mail]>, [e-mail] <[e-mail]>
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