Thank you, Paolo, for your reply and the upcoming revised I-D. I now understand the issue about “String” ;-)
Regards -éric From: Paolo Lucente <[email protected]> Date: Wednesday, 2 October 2024 at 20:03 To: Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's No Objection on draft-ietf-grow-bmp-peer-up-04: (with COMMENT) Hi Eric, Thanks for your comments! We have addressed pretty much all of them in a -05 revision of the document which i will submit shortly. Maybe a disambiguation i should make here is about string part. There is a TLV type called String -- we carry this over from RFC 7854 and this is why you see it mentioned in this document; the String TLV is, well, .. a string; but multiple String TLVs may appear in a BMP message; i have hence modified the text there "If multiple String TLVs are included", hope that does it. Paolo On 24/9/24 11:27, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-grow-bmp-peer-up-04: 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-grow-bmp-peer-up/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work done in this document. Some editorial suggestions/comments > below (they can be ignored): > > Should BMP be expanded in the abstract (or even in the title) ? > > Unsure whether the leading text of section 3 is useful as the 3.* subsections > are rather short and clear. > > Section 2, suggest to use "UTF-8 string" as the name; is it useful to define > this type, which is used only once ? > > Section 3.1, isn't there some contradictions between `The Information field > contains *a* string (Section 2)` and `If *multiple* strings are included` ? It > is at least unclear to me. > > Section 3.3, defining the semantic and syntax of "information" in the > description of "Information Type" seems weird and unusual. > > Section 5, it is a matter of taste of course, but isn't `This rearrangement of > deck chairs` a little too informal ? > > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
