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

[Luigi Iannone <[e-mail]>]

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) <[e-mail]> 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)" <[e-mail]>
> Date: Monday, 18 April 2022 at 23:44
> To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Luigi Iannone <[e-mail]>
> 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 <[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
> 
>