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>
<section anchor="introduction" title="Introduction"> <xref target="RFC7854" format="default"/> defines a number of different B
<t> GP Monitoring Protocol (BMP) message
<xref target="RFC7854"/> defines a number of different BMP 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 BMP has been extended
Protocol has been extended, this oversight has become problematic. In , this overlap has become problematic.
this document, we create a distinct namespace for the Peer Up message to In this
eliminate this overlap, and create the corresponding missing registry. document, we create distinct namespaces for the Peer Up and Initiation
messages to eliminate the overlap.
</t> </t>
<!--We also supply a definition of "string" for
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>
<section anchor="init_info_tlv" <section anchor="init_info_tlv" numbered="true" toc="default">
title="Revision to Information TLV, Renamed as Initiation Information T <name>Revision to the Information TLV</name>
LV"> <t>
<t> The Information TLV defined in <xref target="RFC7854" sectionFormat="of"
The Information TLV defined in section 4.4 of <xref target="RFC7854"/> section="4.4"/>
is renamed "Initiation Information TLV". It is used only by the is renamed "Initiation Information TLV". It is used only by the
Initiation message, not by the Peer Up message. Initiation message, not by the Peer Up message.</t>
</t>
<t>
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> <t>
Type = 1: sysDescr. The Information field contains an ASCII The definition of Type = 0 is revised as shown below.
string whose value MUST be set to be equal to the value of the Type = 1 and Type = 2 are unchanged; they are provided
sysDescr MIB-II <xref target="RFC1213"/> object. for for completeness.
</t> </t>
<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 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 Type = 2: sysName. The Information field contains an ASCII
string whose value MUST be set to be equal to the value of the string whose value <bcp14>MUST</bcp14> be set to be equal to the
sysName MIB-II <xref target="RFC1213"/> object. value of the
</t> sysName MIB-II <xref target="RFC1213" format="default"/> object.
</list> </t>
</t> </li>
</section> </ul>
<section title="Revision to Peer Up Notification"> </section>
<t> <section numbered="true" toc="default">
The final paragraph of section 4.10 of <xref target="RFC7854"/> <name>Revision to the Peer Up Notification</name>
references the Information TLV (which is revised <xref <t>The final paragraph of <xref target="RFC7854" sectionFormat="of"
target="init_info_tlv">above</xref>). That paragraph is replaced by section="4.10"/> references the Information TLV (which is revised
the following: <xref target="init_info_tlv" format="default">above</xref>). That
<list style="symbols"> paragraph is replaced by the following:
<t> </t>
<ul spacing="normal">
<li>
<t>
Information: Information about the peer, using the Peer Up Information: Information about the peer, using the Peer Up
Information TLV format defined <xref Information TLV format defined in <xref target="peer_up_info_tlv"
target="peer_up_info_tlv">below</xref>. The String type may be format="default"/> of RFC 9736. The String type may be
repeated. Inclusion of the Information field is OPTIONAL. Its repeated. Inclusion of the Information field is
presence or absence can be inferred by inspection of the Message <bcp14>OPTIONAL</bcp14>. Its presence or absence can be
Length in the common header. inferred by inspection of the Message Length in the common
</t> header.
</list> </t>
</t> </li>
</section> </ul>
<section anchor="peer_up_info_tlv" </section>
title="Definition of Peer Up Information TLV"> <section anchor="peer_up_info_tlv" numbered="true" toc="default">
<t> <name>Definition of Peer Up Information TLV</name>
<t>
The Peer Up Information TLV is used by the Peer Up message. The Peer Up Information TLV is used by the Peer Up message.
</t> </t>
<figure align="center">
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 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 Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) | | Information (variable) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <ul spacing="normal">
<t> <li>
<list style="symbols"> <t> Information Type (2 bytes): types are as defined in the "BMP Pee
<t> r Up Message TLVs" registry:</t>
Information Type (2 bytes): defined types are: <ul spacing="normal">
<list style="symbols"> <li>
<t> <t>Type = 0: String. The Information field contains a <xref
Type = 0: String. The Information field contains a <xref target="string" format="default">string</xref>. The value is
target="string">string</xref>. The value is administratively administratively assigned. If multiple strings are included,
assigned. If multiple strings are included, their ordering MUST be their ordering <bcp14>MUST</bcp14> be preserved when they are
preserved when they are reported. reported.</t>
</t> </li>
<t> <li>
Type = 3: VRF/Table Name. The Information field contains a UTF-8 <t>Type = 3: VRF/Table Name. The Information field contains a
string whose value MUST be equal to the value of the VRF or table UTF-8 string whose value <bcp14>MUST</bcp14> be equal to the
name (e.g., RD instance name) being conveyed. The string size MUST value of the VRF or table name (e.g., RD instance name) being
be within the range of 1 to 255 bytes. conveyed. The string size <bcp14>MUST</bcp14> be within the
</t> range of 1 to 255 bytes.</t>
<t> </li>
Type = 4: Admin Label. The Information field contains a free-form <li>
UTF-8 string whose byte length is given by the Information Length <t> Type = 4: Admin Label. The Information field contains a
field. The value is administratively assigned. There is no free-form UTF-8 string whose byte length is given by the
requirement to terminate the string with null or any other Information Length field. The value is administratively
character. assigned. There is no requirement to terminate the string
</t> a with null or any other character.</t>
</list> </li>
</t> </ul>
<t> </li>
Information Length (2 bytes): The length of the following <li>
Information field, in bytes. <t>Information Length (2 bytes): The length of the following
</t> Information field, in bytes.</t>
<t> </li>
Information (variable): Information about the monitored <li>
router, according to the type. <t>Information (variable): Information about the monitored
</t> router, according to the type.</t>
</list> </li>
</t> </ul>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations">
<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>
<c>Standards Action</c>
<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>
<c>String</c>
<c>this document</c>
<c>1</c>
<c>Reserved</c>
<c>this document</c>
<c>2</c>
<c>Reserved</c>
<c>this document</c>
<c>3</c>
<c>VRF/Table Name</c>
<c>this document</c>
<c>4</c>
<c>Admin Label</c>
<c>this document</c>
<c>65535</c>
<c>Reserved</c>
<c>this document</c>
</texttable>
<t>
IANA is also requested to rename the existing "BMP Initiation
and Peer Up Information TLVs" registry to "BMP Initiation
Information TLVs" and seed it with the following values:
</t>
<texttable>
<ttcol align='center'>Type</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>0</c>
<c>String</c>
<c>this document</c>
<c>1</c>
<c>sysDescr</c>
<c>this document</c>
<c>2</c>
<c>sysName</c>
<c>this document</c>
<c>3</c>
<c>Reserved</c>
<c>this document</c>
<c>4</c>
<c>Reserved</c>
<c>this document</c>
<c>65535</c>
<c>Reserved</c>
<c>this document</c>
</texttable>
</section>
<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>
</rfc> </rfc>
 End of changes. 50 change blocks. 
343 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.48.