rfc9736xml2.original.xml   rfc9736.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc [
<!-- used by XSLT processors --> <!ENTITY nbsp "&#160;">
<!-- For a complete list and description of processing instructions (PIs), <!ENTITY zwsp "&#8203;">
please see http://xml.resource.org/authoring/README.html. --> <!ENTITY nbhy "&#8209;">
<!-- Below are generally applicable Processing Instructions (PIs) that <!ENTITY wj "&#8288;">
most I-Ds might want to use. ]>
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-grow-bmp-peer-up-05"
ipr="trust200902" updates="7854, 8671, 9069" consensus="true">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-grow-bmp-peer-up-05" number="9736" ipr="trust200902" updates="7854, 8671, 906 9" consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude= "true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="BMP Peer Up Namespace">The BGP Monitoring Protocol (BMP) Peer
Up Message Namespace</title>
<seriesInfo name="RFC" value="9736"/>
<title abbrev="BMP Peer Up Namespace"> <author fullname="John Scudder" initials="J." surname="Scudder">
BMP Peer Up Message Namespace</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="John Scudder" initials="J.S."
surname="Scudder">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1194 N. Mathilda Ave</street> <street>1194 N. Mathilda Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jgs@juniper.net</email> <email>jgs@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Paolo Lucente" initials="P." surname="Lucente">
<author fullname="Paolo Lucente" initials="P" surname="Lucente">
<organization>NTT</organization> <organization>NTT</organization>
<address> <address>
<postal> <postal>
<street>Veemweg 23</street> <street>Veemweg 23</street>
<city>Barneveld</city> <city>Barneveld</city>
<code>3771</code> <code>3771 MT</code>
<region>MT</region> <country>Netherlands</country>
<country>NL</country>
</postal> </postal>
<email>paolo@ntt.net</email> <email>paolo@ntt.net</email>
</address> </address>
</author> </author>
<date year="2025" month="February"/>
<date year="2024" /> <area>OPS</area>
<workgroup>grow</workgroup>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>GROW</workgroup>
<keyword>IDR</keyword> <keyword>IDR</keyword>
<keyword>GROW</keyword> <keyword>GROW</keyword>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>BMP</keyword> <keyword>BMP</keyword>
<abstract> <abstract>
<t> <t>
RFC 7854, BGP Monitoring Protocol, uses different message types for RFC 7854, the BGP Monitoring Protocol (BMP), uses different message types
different purposes. Most of these are Type, Length, Value (TLV) for
structured. One message type, the Peer Up message, lacks a set of different purposes. Most of these are structured as Type, Length, Value (
TLV).
One message type, the Peer Up message, lacks a set of
TLVs defined for its use, instead sharing a namespace with the Initiation TLVs defined for its use, instead sharing a namespace with the Initiation
message. Subsequent experience has shown that this namespace sharing was message. Experience has shown that this namespace sharing was
a mistake, as it hampers the extension of the protocol. a mistake, as it hampers the extension of the protocol.</t>
</t>
<t> <t>
This document updates RFC 7854 by creating an independent namespace for This document updates RFC 7854 by creating an independent namespace for
the Peer Up message. It also updates RFC 8671 and RFC 9069 by moving the the Peer Up message. It also updates RFC 8671 and RFC 9069 by moving
defined codepoints in the newly introduced registry. Compliant implementa defined codepoints into the newly introduced registry. Compliant implemen
tions tations
of RFC 7854, RFC 8671 and RFC 9069 also comply with this specification. of RFC 7854, RFC 8671, and RFC 9069 also comply with this specification.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
<!-- [rfced] For clarity, may we replace "oversight" with "overlap"?
<section anchor="introduction" title="Introduction"> Original:
<t> As the BGP Monitoring Protocol has
<xref target="RFC7854"/> defines a number of different BMP message been extended, this oversight has become problematic.
Perhaps:
As the BGP Monitoring Protocol has
been extended, this overlap has become problematic.
-->
<!-- [rfced] We find the "corresponding missing registry" somewhat confusing bec
ause it seems to refer to the registry being renamed as "missing". Please consi
der 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 messag
es to
eliminate the overlap.
-->
<xref target="RFC7854" format="default"/> defines a number of different B
MP message
types. With the exception of the Route Monitoring message type, these types. With the exception of the Route Monitoring message type, these
messages are TLV-structured. Most message types have distinct messages are TLV-structured. Most message types have distinct
namespaces and IANA registries. However, the namespace of the Peer Up namespaces and IANA registries. However, the namespace of the Peer Up
message overlaps that of the Initiation message. As the BGP Monitoring message overlaps that of the Initiation message. As the BGP Monitoring
Protocol has been extended, this oversight has become problematic. In Protocol has been extended, this oversight has become problematic. In
this document, we create a distinct namespace for the Peer Up message to this document, we create a distinct namespace for the Peer Up message to
eliminate this overlap, and create the corresponding missing registry. eliminate this overlap, and create the corresponding missing registry.
</t> </t>
<!--We also supply a definition of "string" for <!--We also supply a definition of "string" for
convenience, since TLVs from multiple different registries include a stri ng. --> convenience, since TLVs from multiple different registries include a stri ng. -->
<t> <t>
Compliant implementations of <xref target="RFC7854"/>, <xref target="RFC8 Compliant implementations of <xref target="RFC7854" format="default"/>, <
671"/> xref target="RFC8671" format="default"/>,
and <xref target="RFC9069"/> also comply with this specification. and <xref target="RFC9069" format="default"/> also comply with this speci
fication.
</t> </t>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name>Requirements Language</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <t>
"MAY", and "OPTIONAL" in this document are to be interpreted as The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
target="RFC8174"/> when, and only when, they appear in all ",
capitals, as shown here.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</section> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<section anchor="string" title="String Definition"> </section>
<t> </section>
<section anchor="string" numbered="true" toc="default">
<name>String Definition</name>
<t>
A string TLV is a free-form sequence of UTF-8 characters whose length A string TLV is a free-form sequence of UTF-8 characters whose length
in bytes is given by the TLV's Length field. There is no requirement to in bytes is given by the TLV's Length field. There is no requirement to
terminate the string with a null (or any other particular) character -- terminate the string with a null (or any other particular) character --
the Length field gives its termination. the Length field gives its termination.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Changes to existing RFCs"> <name>Changes to Existing RFCs</name>
<t> <t>
<xref target="RFC7854"/> is updated as detailed in the following sub-sections <xref target="RFC7854" format="default"/> is updated as detailed in the follo
. wing subsections.
</t> </t>
<!-- [rfced] Section 3: Please review the questions below.
<section anchor="init_info_tlv" a) It is unclear to us whether Section 3.1 refers to the updates to the "BMP Ini
title="Revision to Information TLV, Renamed as Initiation Information T tiation Information TLVs" registry [1] or if it indicates that "Initiation" shou
LV"> ld to be updated to "Initiation Information" in the "BMP Message Types" registry
<t> [2], or both.
The Information TLV defined in section 4.4 of <xref target="RFC7854"/> Please review the IANA registries and let us know if updates are needed.
is renamed "Initiation Information TLV". It is used only by the [1] https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#initiat
Initiation message, not by the Peer Up message. ion-information-tlvs
</t> [2] https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#message
<t> -types
The definition of Type = 0 is revised to be:
<list style="symbols">
<t>
Type = 0: String. The Information field contains a <xref
target="string">string</xref>. The value is administratively
assigned. If multiple string TLVs are included, their ordering
MUST be preserved when they are reported.
</t>
<t> b) If updating the entry in "BMP Message Types" is intended, we suggest describi
Type = 1: sysDescr. The Information field contains an ASCII ng the action in the IANA Considerations section as well. Please provide text.
string whose value MUST be set to be equal to the value of the
sysDescr MIB-II <xref target="RFC1213"/> object.
</t>
<t> c) The section title feels overloaded. May we change it as follows?
Type = 2: sysName. The Information field contains an ASCII
string whose value MUST be set to be equal to the value of the
sysName MIB-II <xref target="RFC1213"/> object.
</t>
</list>
</t>
</section>
<section title="Revision to Peer Up Notification"> Original:
<t> 3.1. Revision to Information TLV, Renamed as Initiation Information TLV
The final paragraph of section 4.10 of <xref target="RFC7854"/>
references the Information TLV (which is revised <xref
target="init_info_tlv">above</xref>). That paragraph is replaced by
the following:
<list style="symbols">
<t>
Information: Information about the peer, using the Peer Up
Information TLV format defined <xref
target="peer_up_info_tlv">below</xref>. The String type may be
repeated. Inclusion of the Information field is OPTIONAL. Its
presence or absence can be inferred by inspection of the Message
Length in the common header.
</t>
</list>
</t>
</section>
<section anchor="peer_up_info_tlv" Perhaps:
title="Definition of Peer Up Information TLV"> 3.1. Revision to Information TLV
<t>
The Peer Up Information TLV is used by the Peer Up message.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Information Type (2 bytes): defined types are:
<list style="symbols">
<t>
Type = 0: String. The Information field contains a <xref
target="string">string</xref>. The value is administratively
assigned. If multiple strings are included, their ordering MUST be
preserved when they are reported.
</t>
<t>
Type = 3: VRF/Table Name. The Information field contains a UTF-8
string whose value MUST be equal to the value of the VRF or table
name (e.g., RD instance name) being conveyed. The string size MUST
be within the range of 1 to 255 bytes.
</t>
<t>
Type = 4: Admin Label. The Information field contains a free-form
UTF-8 string whose byte length is given by the Information Length
field. The value is administratively assigned. There is no
requirement to terminate the string with null or any other
character.
</t>
</list>
</t>
<t>
Information Length (2 bytes): The length of the following
Information field, in bytes.
</t>
<t>
Information (variable): Information about the monitored
router, according to the type.
</t>
</list>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations"> d) Somewhat related, Section 3.3 says:
<t>
IANA is requested to create a registry within the BMP
group, named "BMP Peer Up Message TLVs", reference this
document.
</t>
<t>
Registration procedures for this registry are:
</t>
<texttable>
<ttcol align='center'>Range</ttcol>
<ttcol align='center'>Registration Procedures</ttcol>
<c>0, 3-32767</c> Original:
<c>Standards Action</c> The Peer Up Information TLV is used by the Peer Up message.
<c>32768-65530</c>
<c>First Come, First Served</c>
<c>65531-65534</c>
<c>Experimental</c>
<c>1-2, 65535</c>
<c>Reserved</c>
</texttable>
<t>
Initial values for this registry are:
</t>
<texttable>
<ttcol align='center'>Type</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>0</c> Is the Peer Up Information TLV an IANA-registered value? We don't see "Peer Up
<c>String</c> Information" in the BMP registry.
<c>this document</c> -->
<section anchor="init_info_tlv" numbered="true" toc="default">
<name>Revision to Information TLV, Renamed as Initiation Information TLV
</name>
<t>
The Information TLV defined in <xref target="RFC7854" sectionFormat="of"
section="4.4"/>
is renamed "Initiation Information TLV". It is used only by the
Initiation message, not by the Peer Up message.</t>
<!-- [rfced] The text mentions Type 0 being revised, but the text that follows a
lso includes definitions for Types 1 and 2. May we update the text as follows f
or clarity?
<c>1</c> Original:
<c>Reserved</c> The definition of Type = 0 is revised to be:
<c>this document</c>
<c>2</c> Perhaps:
<c>Reserved</c> The definition of Type = 0 is revised as shown below.
<c>this document</c> Type = 1 and Type = 2 are unchanged; they are provided
for here for completeness.
-->
<c>3</c> <t>
<c>VRF/Table Name</c> The definition of Type = 0 is revised to be:
<c>this document</c> </t>
<c>4</c> <ul spacing="normal">
<c>Admin Label</c> <li>
<c>this document</c> <t>
Type = 0: String. The Information field contains a <xref
target="string" format="default">string</xref>. The value is
administratively assigned. If multiple string TLVs are
included, their ordering <bcp14>MUST</bcp14> be preserved when
they are reported.
</t>
</li>
<li>
<t>
Type = 1: sysDescr. The Information field contains an ASCII
string whose value <bcp14>MUST</bcp14> be set to be equal to
the value of the sysDescr MIB-II <xref target="RFC1213"
format="default"/> object.
</t>
</li>
<li>
<t>
Type = 2: sysName. The Information field contains an ASCII
string whose value <bcp14>MUST</bcp14> be set to be equal to the
value of the
sysName MIB-II <xref target="RFC1213" format="default"/> object.
</t>
</li>
</ul>
<c>65535</c> </section>
<c>Reserved</c> <section numbered="true" toc="default">
<c>this document</c> <name>Revision to Peer Up Notification</name>
</texttable> <t>The final paragraph of <xref target="RFC7854" sectionFormat="of"
<t> section="4.10"/> references the Information TLV (which is revised
IANA is also requested to rename the existing "BMP Initiation <xref target="init_info_tlv" format="default">above</xref>). That
and Peer Up Information TLVs" registry to "BMP Initiation paragraph is replaced by the following:
Information TLVs" and seed it with the following values: </t>
</t> <!-- [rfced] Because this text is supposed to replace text in RFC 9736, we have
<texttable> updated "defined below (Section 3.3)" to read "defined in Section 3.3 of RFC 973
<ttcol align='center'>Type</ttcol> 6." Rationale: if this text were incorporated into RFC 7854, "below (Section 3.
<ttcol align='center'>Description</ttcol> 3)" would be incorrect.
<ttcol align='center'>Reference</ttcol>
<c>0</c> Original:
<c>String</c> * Information: Information about the peer, using the Peer Up
<c>this document</c> Information TLV format defined below (Section 3.3).
-->
<c>1</c> <ul spacing="normal">
<c>sysDescr</c> <li>
<c>this document</c> <t>
Information: Information about the peer, using the Peer Up
Information TLV format defined in <xref target="peer_up_info_tlv"
format="default"/> of RFC 9736. The String type may be
repeated. Inclusion of the Information field is
<bcp14>OPTIONAL</bcp14>. Its presence or absence can be
inferred by inspection of the Message Length in the common
header.
</t>
</li>
</ul>
<c>2</c> </section>
<c>sysName</c> <section anchor="peer_up_info_tlv" numbered="true" toc="default">
<c>this document</c> <name>Definition of Peer Up Information TLV</name>
<t>
The Peer Up Information TLV is used by the Peer Up message.
</t>
<c>3</c> <!-- [rfced] Please confirm that the bit ruler appears as expected. Typically t
<c>Reserved</c> he numbers appear over the hyphens. Compare the alignemnt with the figure in Se
<c>this document</c> ction 4.4 of RFC 7854 <https://www.rfc-editor.org/rfc/rfc7854.html#section-4.4>.
<c>4</c> Original (this doc):
<c>Reserved</c> 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
<c>this document</c> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->
<c>65535</c> <artwork align="center" name="" type="" alt=""><![CDATA[
<c>Reserved</c> 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
<c>this document</c> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</texttable> | Information Type | Information Length |
</section> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<ul spacing="normal">
<li>
<t> Information Type (2 bytes): defined types are:</t>
<ul spacing="normal">
<li>
<t>Type = 0: String. The Information field contains a <xref
target="string" format="default">string</xref>. The value is
administratively assigned. If multiple strings are included,
their ordering <bcp14>MUST</bcp14> be preserved when they are
reported.</t>
</li>
<li>
<t>Type = 3: VRF/Table Name. The Information field contains a
UTF-8 string whose value <bcp14>MUST</bcp14> be equal to the
value of the VRF or table name (e.g., RD instance name) being
conveyed. The string size <bcp14>MUST</bcp14> be within the
range of 1 to 255 bytes.</t>
</li>
<li>
<t> Type = 4: Admin Label. The Information field contains a
free-form UTF-8 string whose byte length is given by the
Information Length field. The value is administratively
assigned. There is no requirement to terminate the string
a with null or any other character.</t>
</li>
</ul>
</li>
<li>
<t>Information Length (2 bytes): The length of the following
Information field, in bytes.</t>
</li>
<li>
<t>Information (variable): Information about the monitored
router, according to the type.</t>
</li>
</ul>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>IANA Considerations</name>
<t> <t>
This document does not alter the security considerations of <xref IANA has created the "BMP Peer Up Message TLVs" within the "BGP Monitorin
target="RFC7854"/> which continue to apply. g Protocol (BMP) Parameters" registry group and listed this document as the refe
</t> rence. </t>
</section> <t>
Registration procedures for this registry are:</t>
<table align="center">
<thead>
<tr>
<th align="left">Range</th>
<th align="left">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0, 3-32767</td>
<td align="left">Standards Action</td>
</tr>
<tr>
<td align="left">32768-65530</td>
<td align="left">First Come First Served</td>
</tr>
<tr>
<td align="left">65531-65534</td>
<td align="left">Experimental</td>
</tr>
<tr>
<td align="left">1-2, 65535</td>
<td align="left">Reserved</td>
</tr>
</tbody>
</table>
<section anchor="Implementation" title="Implementation status - RFC EDITOR: REMO <t>
VE BEFORE PUBLICATION"> The initial values for this registry are:
<t>
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft. The description of implementations in this section
is intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF. Furthermore,
no effort has been spent to verify the information presented here that
was supplied by IETF contributors. This is not intended as, and must
not be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
</t> </t>
<t> <table align="center">
As of today these vendors have produced an implementation of the <thead>
BMP Peer Up Namespace: <tr>
<th align="center">Type</th>
<th align="center">Description</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">String</td>
<td align="center">RFC 9736</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">Reserved</td>
<td align="center">RFC 9736</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">Reserved</td>
<td align="center">RFC 9736</td>
</tr>
<tr>
<td align="center">3</td>
<td align="center">VRF/Table Name</td>
<td align="center">RFC 9736</td>
</tr>
<tr>
<td align="center">4</td>
<td align="center">Admin Label</td>
<td align="center">RFC 9736</td>
</tr>
<tr>
<td align="center">65535</td>
<td align="center">Reserved</td>
<td align="center">RFC 9736</td>
</tr>
</tbody>
</table>
<list style="symbols"> <t>
<t>FRRouting</t> IANA has also renamed the "BMP Initiation
<t>pmacct</t> and Peer Up Information TLVs" registry to "BMP Initiation Information TL
</list> Vs"
and populated it with the following values:
</t> </t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"> <table align="center">
<t> <thead>
The authors would like to thank Maxence Younsi for his review. <tr>
<th align="left">Type</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">String</td>
<td align="left">RFC 9736</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">sysDescr</td>
<td align="left">RFC 9736</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">sysName</td>
<td align="left">RFC 9736</td>
</tr>
<tr>
<td align="left">3</td>
<td align="left">Reserved</td>
<td align="left">RFC 9736</td>
</tr>
<tr>
<td align="left">4</td>
<td align="left">Reserved</td>
<td align="left">RFC 9736</td>
</tr>
<tr>
<td align="left">65535</td>
<td align="left">Reserved</td>
<td align="left">RFC 9736</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This document does not alter the security considerations of <xref target=
"RFC7854" format="default"/> that continue to apply.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <references>
<!--?rfc include= <name>Normative References</name>
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<?rfc include="reference.RFC.2119.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.121
<?rfc include="reference.RFC.1213.xml"?> 3.xml"/>
<?rfc include="reference.RFC.7854.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.785
<?rfc include="reference.RFC.8671.xml"?> 4.xml"/>
<?rfc include="reference.RFC.9069.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.867
<?rfc include="reference.RFC.8174.xml"?> 1.xml"/>
<!-- <?rfc include="reference.RFC.8126.xml"?> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.906
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Maxence Younsi"/> fo
r his review.</t>
</section>
</back> </back>
<!-- [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.
-->
<!-- [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.
-->
</rfc> </rfc>
 End of changes. 59 change blocks. 
334 lines changed or deleted 420 lines changed or added

This html diff was produced by rfcdiff 1.48.