Hi Paolo, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9736>. Note that we will wait to hear from John as well before continuing with the publication process.
Thank you, RFC Editor/sg > On Feb 24, 2025, at 4:27 PM, Paolo Lucente <pa...@ntt.net> wrote: > > > Hi Sandy, > > Thanks! I have re-read the document and i confirm it all looks good to me! > > Paolo > > > On 20/2/25 00:21, Sandy Ginoza wrote: >> Hi Paolo, >> We have replaced the figure with the one from Section 4.4 of RFC 7854. >> Please review and let us know if corrections are needed or if you approve >> the RFC for publication. >> 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 >> Diffs highlighting the most recent updates only: >> https://www.rfc-editor.org/authors/rfc9736-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9736-lastrfcdiff.html (side by side) >> 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 19, 2025, at 11:01 AM, Paolo Lucente <pa...@ntt.net> wrote: >>> >>> >>> Hi Sandy, >>> >>> Thanks for bringing this up. If you could copy the figure from Section 4.4 >>> of RFC 7854 into this draft, that would be awesome as there is also much >>> more clear the counting of the bits. >>> >>> Paolo >>> >>> >>> On 12/2/25 00:52, Sandy Ginoza 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 >>>>>> <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.xml> >>>> https://www.rfc-editor.org/authors/rfc9736.txt >>>> <https://www.rfc-editor.org/authors/rfc9736.txt> >>>> https://www.rfc-editor.org/authors/rfc9736.pdf >>>> <https://www.rfc-editor.org/authors/rfc9736.pdf> >>>> https://www.rfc-editor.org/authors/rfc9736.html >>>> <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-auth48diff.html> >>>> https://www.rfc-editor.org/authors/rfc9736-auth48rfcdiff.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-diff.html> >>>> https://www.rfc-editor.org/authors/rfc9736-rfcdiff.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 >>>>> <mailto:pa...@ntt.net>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Please see inline: >>>>> >>>>> On 4/2/25 00:04, rfc-edi...@rfc-editor.org >>>>> <mailto: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 >>>>>> >>>>>> <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 >>>>>> >>>>>> <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 >>>>>> <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 >>>>>> <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
