Vendor-Specific LISP Canonical Address Format (LCAF)
draft-ietf-lisp-vendor-lcaf-12

(Revised ballot)

Thanks to the authors and IANA for updating the formal name of "https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-lcaf-type" to be "LISP Canonical Address Format (LCAF) Types."

** Éric’s ballot already called out that Figure 1 doesn’t match the text in Section 3 (i.e., Figure 1 says “Type = TBD” but the Section 3 text says “Type = 255”).  It should read TBD in both places.  Suggesting 255, if that is the desired value, only makes sense in Section 6 (as it currently reads).

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.

## 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.

## 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.

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 ?

Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/w8r32njasR5PwAa8-Y4Fv0dHw1s).