Hi Med,
We have updated the document as described below.
For this one, please review the update closely, as I am not sure I understood
the desired update.
> (3) S3.2 No explicit mention of the IANA registry in the description of the
> info type.
>
> CURRENT: Information Type (2 bytes): defined types are:
It currently reads as follows:
* Information Type (2 bytes): types are as defined in the "BMP Peer
Up Message TLVs" registry:
Please review the current files:
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 of the most recently 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)
Please review and let us know if any further updates are needed or if you
approve the RFC for publication.
Thank you,
RFC Editor/sg
> On Feb 11, 2025, at 10:08 PM, [email protected] wrote:
>
> Hi all,
>
>
>
> Some few comments about the edited version, fwiw:
>
>
>
> (1) S.1 Expand at first use
>
>
>
> CURRENT
>
> [RFC7854] defines a number of different BMP message types. With the
>
> ^^^^
>
> exception of the Route Monitoring message type, these messages are
>
> TLV-structured. Most message types have distinct namespaces and IANA
>
> registries. However, the namespace of the Peer Up message overlaps
>
> that of the Initiation message. As the BGP Monitoring Protocol has
>
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>
> NEW:
>
> [RFC7854] defines a number of different BGP Monitoring Protocol (BMP)
> message types. With the
> exception of the Route Monitoring message type, these messages are
> TLV-structured. Most message types have distinct namespaces and IANA
> registries. However, the namespace of the Peer Up message overlaps
> that of the Initiation message. As BMP has
>
>
> (2) S3.1 nit
>
>
>
> CURRENT: provided for here for completeness
>
> NEW: provided for completeness
>
>
>
> (3) S3.2 No explicit mention of the IANA registry in the description of the
> info type.
>
>
>
> CURRENT: Information Type (2 bytes): defined types are:
>
>
> Cheers,
>
> Med
>
>
>
> De : Sandy Ginoza <[email protected]>
> Envoyé : mercredi 12 février 2025 00:52
> À : Paolo Lucente <[email protected]>
> Cc : RFC Editor <[email protected]>; John Scudder <[email protected]>;
> [email protected]; [email protected]; [email protected]; Warren Kumari
> <[email protected]>; [email protected]
> Objet : Re: AUTH48: RFC-to-be 9736 <draft-ietf-grow-bmp-peer-up-05> for your
> review
>
>
>
>
> 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:
>
>
>
> <image001.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 <[email protected]> wrote:
>
>
> Hi,
>
> Please see inline:
>
> On 4/2/25 00:04, [email protected] 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
>
>
>
>
>
> ___________________________________________________________________________________________________________
> _
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
