Hi Paolo, Thank you for your reply. We have updated the document as described below. In particular, thank you for your explanation regarding 3a and 3d.
Regarding item 6, please verify that this is correct, as it’s different from what I see in Section 4.4 of RFC 7854. >> 6) <!-- [rfced] Please confirm that the bit ruler appears as expected. >> Typically the numbers appear over the hyphens. Compare the alignment with >> the figure in Section 4.4 of RFC 7854 >> <https://www.rfc-editor.org/rfc/rfc7854.html#section-4.4>. >> Original (this doc): >> 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> --> > > I confirm it looks good, it was pretty much copy-pasted :-) From Section 4.4 of RFC 7854: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Type | Information Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also including a snapshot in case the figure above doesn’t display correctly: Please review the current files and let us know if any additional updates are needed. https://www.rfc-editor.org/authors/rfc9736.xml https://www.rfc-editor.org/authors/rfc9736.txt https://www.rfc-editor.org/authors/rfc9736.pdf https://www.rfc-editor.org/authors/rfc9736.html AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9736-auth48diff.html https://www.rfc-editor.org/authors/rfc9736-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9736-diff.html https://www.rfc-editor.org/authors/rfc9736-rfcdiff.html (side by side) Thank you, RFC Editor/sg > On Feb 5, 2025, at 12:00 PM, Paolo Lucente <pa...@ntt.net> wrote: > > > Hi, > > Please see inline: > > On 4/2/25 00:04, rfc-edi...@rfc-editor.org wrote: >> Authors, >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the XML file. >> 1) <!-- [rfced] For clarity, may we replace "oversight" with "overlap"? >> Original: >> As the BGP Monitoring Protocol has >> been extended, this oversight has become problematic. >> Perhaps: >> As the BGP Monitoring Protocol has >> been extended, this overlap has become problematic. >> --> > > That works! > > >> 2) <!-- [rfced] We find the "corresponding missing registry" somewhat >> confusing because it seems to refer to the registry being renamed as >> "missing". Please consider whether the suggested text would be more clear. >> Original: >> In this >> document, we create a distinct namespace for the Peer Up message to >> eliminate this overlap, and create the corresponding missing >> registry. >> Perhaps: >> In this >> document, we create distinct namespaces for the Peer Up and Initiation >> messages to eliminate the overlap. >> --> > > That works! Thanks! > > >> 3) <!-- [rfced] Section 3: Please review the questions below. >> a) It is unclear to us whether Section 3.1 refers to the updates to the >> "BMP Initiation Information TLVs" registry [1] or if it indicates that >> "Initiation" should to be updated to "Initiation Information" in the "BMP >> Message Types" registry [2], or both. >> Please review the IANA registries and let us know if updates are needed. >> [1] >> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#initiation-information-tlvs >> [2] >> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#message-types >> b) If updating the entry in "BMP Message Types" is intended, we suggest >> describing the action in the IANA Considerations section as well. Please >> provide text. > > None of the two, we are just updating RFC7854: > > in section 4.4 of RFC7854 the optional TLV that can follow an Initiation > message is called "Information TLV". We are just changing that definition to > "Initiation Information TLV" to limit the scope to the Initialization message > only. Nothing to do for IANA here as in section 10.5 of RFC7854 the registry > is correctly already named "BMP Initiation Message TLVs". (see more in my > comment to your point "d") > > >> c) The section title feels overloaded. May we change it as follows? >> Original: >> 3.1. Revision to Information TLV, Renamed as Initiation Information TLV >> Perhaps: >> 3.1. Revision to the Information TLV > > Agree! > > >> d) Somewhat related, Section 3.3 says: >> Original: >> The Peer Up Information TLV is used by the Peer Up message. >> Is the Peer Up Information TLV an IANA-registered value? We don't see >> "Peer Up Information" in the BMP registry. >> --> > > Similarly to before, we are just updating RFC7854. In section 4.10 of RFC7854 > we find "Information: Information about the peer, using the Information TLV > (Section 4.4) format. [ .. ]"; so we are overloading the term Information TLV > for two different message types, Initialization and Peer Up; in this document > we say they are called differently and each will ultimately point to a > different IANA registry: > > * Initialization Information TLV field to the existing "BMP Initiation > Information TLVs" IANA registry; > > * Peer Up Information TLV field to the newly created (as part of this > document) "BMP Peer Up Information TLVs" IANA registry; > > Hope this makes things more clear. > > >> 4) <!-- [rfced] The text mentions Type 0 being revised, but the text that >> follows also includes definitions for Types 1 and 2. May we update the >> text as follows for clarity? >> Original: >> The definition of Type = 0 is revised to be: >> Perhaps: >> The definition of Type = 0 is revised as shown below. >> Type = 1 and Type = 2 are unchanged; they are provided >> for here for completeness. >> --> > > Agree! > > >> 5) <!-- [rfced] Because this text is supposed to replace text in RFC 9736, >> we have updated "defined below (Section 3.3)" to read "defined in Section >> 3.3 of RFC 9736." Rationale: if this text were incorporated into RFC 7854, >> "below (Section 3.3)" would be incorrect. >> Original: >> * Information: Information about the peer, using the Peer Up >> Information TLV format defined below (Section 3.3). >> --> > > Agree! > > >> 6) <!-- [rfced] Please confirm that the bit ruler appears as expected. >> Typically the numbers appear over the hyphens. Compare the alignment with >> the figure in Section 4.4 of RFC 7854 >> <https://www.rfc-editor.org/rfc/rfc7854.html#section-4.4>. >> Original (this doc): >> 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> --> > > I confirm it looks good, it was pretty much copy-pasted :-) > > >> 7) <!-- [rfced] Some author comments are present in the XML. Please confirm >> that no updates related to these comments are outstanding. Note that the >> comments will be deleted prior to publication. >> --> > > I confirm there are no updates and they can be deleted. > > >> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature >> typically result in more precise language, which is helpful for readers. >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > It seems all fine to me, thanks for bringing this up. > > Paolo > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
