Resending to include an updated email address for Job. > On Feb 11, 2025, at 3:52 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > wrote: > > 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: > > <Screen Shot 2025-02-11 at 3.47.53 PM.png> > > > 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
