Re: [lisp] [Ext] Re: Roman Danyliw's No Objection on draft-ietf-lisp-vendor-lcaf-10: (with COMMENT)

Since there is more than one type the name should be pluralized. Therefore the website should reflect RFC 8060. 

Dino

> On Apr 22, 2022, at 4:05 PM, Amanda Baber <amanda.baber@iana.org> wrote:
> 
> 
> Hi,
>  
> The registry was created for https://datatracker.ietf.org/doc/html/draft-ietf-lisp-lcaf-22, at which point the registry was called “LISP LCAF Type.” It looks like we need to update the name of the registry to match the published RFC.
>  
> Thanks,
> Amanda
>  
> From: iesg <iesg-bounces@ietf.org> on behalf of "Alberto Rodriguez-Natal (natal)" <natal=40cisco.com@dmarc.ietf.org>
> Date: Friday, April 22, 2022 at 3:21 PM
> To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
> Cc: Luigi Iannone <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "draft-ietf-lisp-vendor-lcaf@ietf.org" <draft-ietf-lisp-vendor-lcaf@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
> Subject: [Ext] Re: Roman Danyliw's No Objection on draft-ietf-lisp-vendor-lcaf-10: (with COMMENT)
>  
> Hi Roman,
>  
> Thanks for your review! Regarding the registry name, we took it from the IANA section of RFC 8060 [1] that lists it as "LISP Canonical Address Format (LCAF) Types". You’re indeed right that the IANA website shows it as “LISP LCAF Type.” I guess here we should follow the IANA website name, right?
>  
> Thanks!
> Alberto
>  
> [1] https://www.rfc-editor.org/rfc/rfc8060.html#section-7 [rfc-editor.org]
>  
>  
> From: Roman Danyliw via Datatracker <noreply@ietf.org>
> Date: Thursday, April 21, 2022 at 5:41 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-lisp-vendor-lcaf@ietf.org <draft-ietf-lisp-vendor-lcaf@ietf.org>, lisp-chairs@ietf.org <lisp-chairs@ietf.org>, lisp@ietf.org <lisp@ietf.org>, Luigi Iannone <ggx@gigix.net>, ggx@gigix.net <ggx@gigix.net>
> Subject: Roman Danyliw's No Objection on draft-ietf-lisp-vendor-lcaf-10: (with COMMENT)
> 
> Roman Danyliw 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/ [ietf.org] 
> 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/ [datatracker.ietf.org]
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** É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).
> 
> ** Section 6.
> 
> Following the guidelines of [RFC8126], IANA is asked to assign a
>    value (255 is suggested) for the Vendor Specific LCAF from the "LISP
>    Canonical Address Format (LCAF) Types" registry (defined in
>    [RFC8060]) as follows:
> 
> The text here calls the registry the “LISP Canonical Address Format (LCAF)
> Types”.  That doesn’t appear to be the official name. Examining
> https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-lcaf-type
> it appears to be “LISP LCAF Type.”
> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp