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
