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 <sgin...@staff.rfc-editor.org>
*Envoyé :* mercredi 12 février 2025 00:52
*À :* Paolo Lucente <pa...@ntt.net>
*Cc :* RFC Editor <rfc-edi...@rfc-editor.org>; John Scudder
<j...@juniper.net>; grow-...@ietf.org; grow-cha...@ietf.org;
j...@fastly.com; Warren Kumari <war...@kumari.net>;
auth48archive@rfc-editor.org
*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
<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
____________________________________________________________________________________________________________
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.
