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 <[email protected]> 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 <[email protected]> on behalf of "Alberto Rodriguez-Natal > (natal)" <[email protected]> > Date: Friday, April 22, 2022 at 3:21 PM > To: Roman Danyliw <[email protected]>, The IESG <[email protected]> > Cc: Luigi Iannone <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > 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 <[email protected]> > Date: Thursday, April 21, 2022 at 5:41 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: 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
