rfc9003xml2.original.xml   rfc9003.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<?rfc strict="yes"?>
<rfc category="std"
docName="draft-ietf-idr-rfc8203bis-08"
updates="4486"
obsoletes="8203"
ipr="trust200902">
<front>
<title abbrev="BGP Shutdown Communication">
Extended BGP Administrative Shutdown Communication
</title>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization abbrev="NTT">NTT Communications</organization>
<address>
<postal>
<street>Theodorus Majofskistraat 100</street>
<code>1065 SZ</code>
<city>Amsterdam</city>
<country>The Netherlands</country>
</postal>
<email>job@ntt.net</email>
</address>
</author>
<author fullname="Jakob Heitz" initials="J." surname="Heitz">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>jheitz@cisco.com</email>
</address>
</author>
<author fullname="John Scudder" initials="J." surname="Scudder">
<organization abbrev="Juniper">Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<email>jgs@juniper.net</email>
</address>
</author>
<author fullname="Alexander Azimov" initials="A." surname="Azimov">
<organization abbrev="Yandex">Yandex</organization>
<address>
<email>a.e.azimov@gmail.com</email>
</address>
</author>
<date />
<area>Routing</area>
<workgroup>IDR</workgroup>
<keyword>BGP</keyword>
<keyword>cease</keyword>
<keyword>shutdown</keyword>
<abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-rfc8203b
<t> is-08"
This document enhances the BGP Cease NOTIFICATION message "Admin number="9003" updates="4486" obsoletes="8203" ipr="trust200902" submissionType="
istrative Shutdown" and "Administrative Reset" subcodes for operators to transmi IETF"
t a short freeform message to describe why a BGP session was shutdown or reset. category="std" consensus="true" xml:lang="en" sortRefs="true" symRefs="true"
This document updates RFC 4486 and obsoletes RFC 8203 by definin tocInclude="true" tocDepth="3" version="3">
g an Extended BGP Administrative Shutdown Communication of up to 255 octets to i
mprove communication using multibyte character sets.
</t>
</abstract>
<note title="Requirements Language"> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<front>
<title abbrev="BGP Shutdown Communication">
Extended BGP Administrative Shutdown Communication
</title>
<seriesInfo name="RFC" value="9003"/>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization abbrev="NTT">NTT Ltd.</organization>
<address>
<postal>
<street>Theodorus Majofskistraat 100</street>
<code>1065 SZ</code>
<city>Amsterdam</city>
<country>Netherlands</country>
</postal>
<email>job@ntt.net</email>
</address>
</author>
<author fullname="Jakob Heitz" initials="J." surname="Heitz">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>jheitz@cisco.com</email>
</address>
</author>
<author fullname="John Scudder" initials="J." surname="Scudder">
<organization abbrev="Juniper">Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<email>jgs@juniper.net</email>
</address>
</author>
<author fullname="Alexander Azimov" initials="A." surname="Azimov">
<organization abbrev="Yandex">Yandex</organization>
<address>
<postal>
<street>Ulitsa Lva Tolstogo 16</street>
<city>Moscow</city>
<code>119021</code>
<country>Russian Federation</country>
</postal>
<email>a.e.azimov@gmail.com</email>
</address>
</author>
<date month="January" year="2021"/>
<area>Routing</area>
<workgroup>IDR</workgroup>
<keyword>BGP</keyword>
<keyword>cease</keyword>
<keyword>shutdown</keyword>
<abstract>
<t>This document enhances the BGP Cease NOTIFICATION message "Administrati
ve
Shutdown" and "Administrative Reset" subcodes for operators to transmit a
short free-form message to describe why a BGP session was shut down or res
et.
This document updates RFC 4486 and obsoletes RFC 8203 by defining an Exten
ded
BGP Administrative Shutdown Communication of up to 255 octets to improve
communication using multibyte character sets.</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>It can be troublesome for an operator to correlate a <xref target="RFC4
271"
format="default">BGP-4</xref> session teardown in the network with a notic
e that
was transmitted via offline methods, such as email or telephone calls. Thi
s document
updates <xref target="RFC4486" format="default"/> by specifying a mechanis
m to
transmit a short free-form <xref target="RFC3629" format="default">UTF-8</
xref>
message as part of a <xref target="RFC4271" format="default">Cease NOTIFIC
ATION
message</xref> to inform the peer why the BGP session is being shut down o
r reset.
This document obsoletes <xref target="RFC8203" format="default"/>; the spe
cific
differences and rationale are discussed in detail in <xref target="changes
_to_8203"
format="default"/>.</t>
<section anchor="req-lang" numbered="true" toc="default">
<name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and "OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
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> </t>
</note> </section>
</section>
</front> <section anchor="message" numbered="true" toc="default">
<name>Shutdown Communication</name>
<middle> <t>If a BGP speaker decides to terminate its session with a BGP neighbor,
<section anchor="intro" title="Introduction"> and it
<t> sends a NOTIFICATION message with the Error Code "Cease" and Error Subcode
It can be troublesome for an operator to correlate a <xref targe "Administrative Shutdown" or "Administrative Reset" <xref target="RFC4486"
t="RFC4271">BGP-4</xref> session teardown in the network with a notice that was format="default"/>, it <bcp14>MAY</bcp14> include a UTF-8-encoded string.
transmitted via offline methods such as email or telephone calls. The contents
This document updates <xref target="RFC4486" /> by specifying a of the string are at the operator's discretion.</t>
mechanism to transmit a short freeform <xref target="RFC3629">UTF-8</xref> messa <t>The Cease NOTIFICATION message with a Shutdown Communication is encoded
ge as part of a <xref target="RFC4271">Cease NOTIFICATION message</xref> to info as below:</t>
rm the peer why the BGP session is being shutdown or reset. <figure anchor="encoding">
This document obsoletes <xref target="RFC8203"/>; the <artwork name="Cease NOTIFICATION Message with a Shutdown Communication" type=""
specific differences and rationale are discussed in align="left" alt=""><![CDATA[
detail in <xref target="changes_to_8203"/>.
</t>
</section>
<section anchor="message" title="Shutdown Communication">
<t>
If a BGP speaker decides to terminate its session with a BGP nei
ghbor, and it sends a NOTIFICATION message with the Error Code "Cease" and Error
Subcode "Administrative Shutdown" or "Administrative Reset" <xref target="RFC44
86" />, it MAY include a UTF-8 encoded string.
The contents of the string are at the operator's discretion.
</t>
<t>
The Cease NOTIFICATION message with a Shutdown Communication is encoded as
below:
<figure anchor="encoding" align="center"><artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6 | Subcode | Length | ... \ | Error Code 6 | Subcode | Length | ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
\ \ \ \
/ ... Shutdown Communication ... / / ... Shutdown Communication ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</t> </figure>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt>Subcode:</dt>
<t hangText="Subcode:"> <dd>The Error Subcode value <bcp14>MUST</bcp14> be one of the following
the Error Subcode value MUST be one of the following values: 2 ("Administrative Shutdown") or 4 ("Administrative Reset").
values: 2 ("Administrative Shutdown") or 4 </dd>
("Administrative Reset"). <dt>Length:</dt>
</t> <dd>This 8-bit field represents the length of the Shutdown
<t></t> Communication field in octets. When the length value is zero,
<t hangText="Length:"> no Shutdown Communication field follows.</dd>
this 8-bit field represents the length of the Shutdown <dt>Shutdown Communication:</dt>
Communication field in octets. When the length value is <dd>To support international characters, the Shutdown
zero, Communication field <bcp14>MUST</bcp14> be encoded using UTF-8. A
no Shutdown Communication field follows. receiving BGP speaker <bcp14>MUST NOT</bcp14> interpret invalid UTF-
</t> 8
<t></t> sequences. Note that when the Shutdown Communication
<t hangText="Shutdown Communication:"> contains multibyte characters, the number of characters
to support international characters, the Shutdown will be less than the length value.
Communication field MUST be encoded using UTF-8. A This field is not
receiving BGP speaker MUST NOT interpret invalid UTF-8 NUL terminated. UTF-8 "Shortest Form" encoding is <bcp14>REQUIRED</b
sequences. Note that when the Shutdown Communication cp14>
contains multibyte characters, the number of characters to guard against the technical issues outlined in <xref target="UTR36
will be less than the length value. This field is not "
NUL terminated. UTF-8 "Shortest Form" encoding is REQUIR format="default"/>.</dd>
ED to guard against the technical issues outlined in <xref target="UTR36" />. </dl>
</t> <t>
</list>
</t>
<t>
Mechanisms concerning the reporting of information contained in Mechanisms concerning the reporting of information contained in
the Shutdown Communication are implementation specific but the Shutdown Communication are implementation specific but
SHOULD include methods such as <xref target="RFC5424">Syslog</xr <bcp14>SHOULD</bcp14> include methods such as <xref target="RFC5
ef>. 424" format="default">syslog</xref>.
</t> </t>
</section> </section>
<section anchor="ops" numbered="true" toc="default">
<section anchor="ops" title="Operational Considerations"> <name>Operational Considerations</name>
<t> <t>
Operators are encouraged to use the Shutdown Communication to Operators are encouraged to use the Shutdown Communication to
inform their peers of the reason for the shutdown of the BGP inform their peers of the reason for the shutdown of the BGP
session and include out-of-band reference materials. An session and include out-of-band reference materials. An
example of a useful Shutdown Communication would be: example of a useful Shutdown Communication would be:
</t> </t>
<t>"[TICKET-1-1438367390] software upgrade; back in 2 hours"</t> <t>"[TICKET-1-1438367390] software upgrade; back in 2 hours"</t>
<t> <t>"[TICKET-1-1438367390]" is a ticket reference with significance to both
"[TICKET-1-1438367390]" is a ticket reference with significance the sender and receiver, followed by a brief human-readable message regard
to both the sender and receiver, followed by a brief human-readable message rega ing
rding the reason for the BGP session shutdown followed by an indication about th the reason for the BGP session shutdown followed by an indication about th
e length of the maintenance. e length
The receiver can now use the string 'TICKET-1-1438367390' to sea of the maintenance. The receiver can now use the string 'TICKET-1-14383673
rch in their email archive to find more details. 90' to
</t> search in their email archive to find more details.</t>
<t> <t>
If a Shutdown Communication longer than 128 octets is sent to a BGP If a Shutdown Communication longer than 128 octets is sent to a BGP
speaker that implements [RFC8203], then that speaker will treat it as speaker that implements [RFC8203], then that speaker will treat it as
an error, the consequence of which should be a log message. an error, the consequence of which should be a log message.
</t> </t>
<t> <t>
If a Shutdown Communication of any length is sent to a BGP If a Shutdown Communication of any length is sent to a BGP
speaker that implements neither [RFC8203] nor this specification, speaker that implements neither [RFC8203] nor this specification,
then that speaker will treat it as then that speaker will treat it as
an error, the consequence of which should be a log message. an error, the consequence of which should be a log message.
</t> </t>
<t> <t>
In any case, a receiver of a NOTIFICATION message is unable to In any case, a receiver of a NOTIFICATION message is unable to
acknowledge the receipt and correct understanding of any acknowledge the receipt and correct understanding of any
Shutdown Communication. Shutdown Communication.
</t> </t>
<t> <t>
Operators should not rely on Shutdown Communications as their Operators should not rely on Shutdown Communications as their
sole form of communication with their peer for important events. sole form of communication with their peers for important events.
</t> </t>
<t> <t>
If it is known that the peer BGP speaker supports this specification, If it is known that the peer BGP speaker supports this specification,
then a Shutdown Communication that is not longer than 255 octets MAY be sent. then a Shutdown Communication that is not longer than 255 octets <bcp14>MAY</
Otherwise, a Shutdown Communication MAY be sent, but it SHOULD NOT be bcp14> be sent.
Otherwise, a Shutdown Communication <bcp14>MAY</bcp14> be sent, but it <bcp14
>SHOULD NOT</bcp14> be
longer than 128 octets. longer than 128 octets.
</t> </t>
</section> </section>
<section anchor="error" numbered="true" toc="default">
<section anchor="error" title="Error Handling"> <name>Error Handling</name>
<t> <t>
If a Shutdown Communication with an invalid UTF-8 If a Shutdown Communication with an invalid UTF-8
sequence is received, a message indicating this event sequence is received, a message indicating this event
SHOULD be logged for the attention of the operator. A <bcp14>SHOULD</bcp14> be logged for the attention of t
n he operator. An
erroneous or malformed Shutdown Communication itself M erroneous or malformed Shutdown Communication itself <
AY bcp14>MAY</bcp14>
be logged in a hexdump format. be logged in a hexdump format.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>IANA has referenced this document at subcodes "Administrative Shutdown"
IANA is requested to reference this document at subcode "Adminis and "Administrative Reset" in the "BGP Cease NOTIFICATION message subcodes
trative Shutdown", and at subcode "Administrative Reset" in the "BGP Cease NOTIF "
ICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Para registry under the "Border Gateway Protocol (BGP) Parameters" group in add
meters" group in addition to <xref target="RFC4486" />. ition to
</t> <xref target="RFC4486" format="default"/>.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This document uses UTF-8 encoding for the Shutdown Communication . This document uses UTF-8 encoding for the Shutdown Communication .
There are a number of security issues with Unicode. There are a number of security issues with Unicode.
Implementers and operators are advised to review <xref target="U Implementers and operators are advised to review <xref target="U
TR36">Unicode Technical Report #36</xref> to learn about these issues. TR36" format="default">Unicode Technical Report #36</xref> to learn about these
UTF-8 "Shortest Form" encoding is REQUIRED to guard against the issues.
technical issues outlined in <xref target="UTR36" />. UTF-8 "Shortest Form" encoding is <bcp14>REQUIRED</bcp14> to gua
</t> rd against the technical issues outlined in <xref target="UTR36" format="default
<t> "/>.
</t>
<t>
As BGP Shutdown Communications are likely to appear in syslog ou tput, there is a risk that carefully constructed Shutdown Communication might be formatted by receiving systems in a way to make them appear as additional syslo g messages. As BGP Shutdown Communications are likely to appear in syslog ou tput, there is a risk that carefully constructed Shutdown Communication might be formatted by receiving systems in a way to make them appear as additional syslo g messages.
The 255 octet length limit on the BGP Shutdown The 255-octet length limit on the BGP Shutdown
Communication may help limit the ability to mount such Communication may help limit the ability to mount such
an attack. an attack.
</t> </t>
<t> <t>
Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Comm unication message could be forged. Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Comm unication message could be forged.
Unless a transport that provides confidentiality is used, a Shut down Communication message could be snooped by an attacker. Unless a transport that provides confidentiality is used, a Shut down Communication message could be snooped by an attacker.
These issues are common to any BGP message but may be of greater These issues are common to any BGP message, but they may be of g
interest in the context of this proposal since the information carried in the m reater interest in the context of this proposal since the information carried in
essage is generally expected to be used for human-to-human communication. the message is generally expected to be used for human-to-human communication.
Refer to the related considerations in <xref target="RFC4271" /> Refer to the related considerations in <xref target="RFC4271" fo
and <xref target="RFC4272" />. rmat="default"/> and <xref target="RFC4272" format="default"/>.
</t> </t>
<t> <t>Users of this mechanism should consider applying data minimization prac
Users of this mechanism should consider applying data minimizati tices
on practices as outlined in <xref target="RFC6973">Section 6.1 of</xref> because as outlined in <xref target="RFC6973" sectionFormat="of" section="6.1"></x
a received Shutdown Communication may be used at the receiver's discretion. ref>
</t> because a received Shutdown Communication may be used at the receiver's di
</section> scretion.</t>
</section>
</middle> </middle>
<back>
<back> <references>
<name>References</name>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>Normative References</name>
<?rfc include="reference.RFC.8174"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.3629"?> FC.2119.xml"/>
<?rfc include="reference.RFC.4271"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.4486"?> FC.8174.xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<references title="Informative References"> FC.3629.xml"/>
<?rfc include="reference.RFC.4272"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.5424"?> FC.4271.xml"/>
<?rfc include="reference.RFC.6973"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8203"?> FC.4486.xml"/>
<reference anchor="UTR36" target="http://unicode.org/reports/tr36/"> </references>
<front> <references>
<title>Unicode Security Considerations</title> <name>Informative References</name>
<author initials="M." surname="Davis" fullname="Mark Davis"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization/></author> FC.4272.xml"/>
<author initials="M." surname="Suignard" fullname="Michel Su <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ignard"><organization/></author> FC.5424.xml"/>
<date year="2010" month="August" day="4"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.6973.xml"/>
<seriesInfo name="Unicode Technical Report" value="#36"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.8203.xml"/>
</references>
<section anchor="acknowledgements" title="Acknowledgements">
<t>
The authors would like to gratefully acknowledge Tom Scholl, Dav
id Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley
, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Be
rger, Alvaro Retana, and Adam Roach.
</t>
<t>
The authors would like to thank Enke Chen and Vincent Gillet for
their work on <xref target="RFC4486"/> and granting the related BCP 78 rights t
o the IETF Trust.
</t>
<t>
The authors would like to acknowledge Misha Grishin (MSK-IX) for
raising awareness that <xref target="RFC8203"/>'s length specification was insu
fficient in context of multibyte character sets.
</t>
</section>
<section anchor="changes_to_8203" title="Changes to RFC 8203"> <reference anchor="UTR36" target="http://unicode.org/reports/tr36/">
<t> <front>
The maximum permitted length was changed from 128 to 255. <title>Unicode Security Considerations</title>
</t> <author initials="M." surname="Davis" fullname="Mark Davis" role="ed
<t> itor">
Feedback from operators based in regions which pr <organization/>
edominantly use multibyte character sets, showed that messages similar in meanin </author>
g to what can be send in other languages in using single-byte encoding, failed t <author initials="M." surname="Suignard" fullname="Michel Suignard"
o fit within the Length constraints as specified by <xref target="RFC8203"/>. role="editor">
For example, the phrase: 'Planned work to add swi <organization/>
tch to stack. Completion time - 30 minutes' has length 65 bytes. </author>
Its translation in Russian has length 139 bytes. <date year="2010" month="August"/>
</t> </front>
<t> <seriesInfo name="Unicode Technical Report" value="#36"/>
If a Shutdown Communication message longer than 128 octet </reference>
s is sent to a BGP speaker that implements <xref target="RFC8203"/>, then that s </references>
peaker will bring it to the attention of an operator, but will otherwise process </references>
the NOTIFICATION message as normal. <section anchor="changes_to_8203" numbered="true" toc="default">
</t> <name>Changes to RFC 8203</name>
<t>The maximum permitted length was changed from 128 to 255.</t>
<t>Feedback from operators based in regions that predominantly use multiby
te character
sets showed that messages similar in meaning to what can be sent in other
languages
using single-byte encoding failed to fit within the length constraints as
specified by
<xref target="RFC8203" format="default"/>. For example, the phrase "Planne
d work to add
switch to stack. Completion time - 30 minutes" has a length of 65 bytes.
Its translation in
Russian has a length of 139 bytes.</t>
<t>If a Shutdown Communication message longer than 128 octets is sent to a
BGP speaker
that implements <xref target="RFC8203" format="default"/>, then that speak
er will bring
it to the attention of an operator but will otherwise process the NOTIFICA
TION message
as normal.</t>
</section> </section>
</back> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to gratefully acknowledge <contact fullname="Tom
Scholl"/>,
<contact fullname="David Freedman"/>, <contact fullname="Jared Mauch"/>, <
contact
fullname="Jeff Haas"/>, <contact fullname="Peter Hessler"/>, <contact full
name="Bruno
Decraene"/>, <contact fullname="John Heasley"/>, <contact fullname="Peter
van Dijk"/>,
<contact fullname="Arjen Zonneveld"/>, <contact fullname="James Bensley"/>
, <contact
fullname="Susan Hares"/>, <contact fullname="Saku Ytti"/>, <contact fullna
me="Lou Berger"/>,
<contact fullname="Alvaro Retana"/>, and <contact fullname="Adam Roach"/>.
</t>
<t>The authors would like to thank <contact fullname="Enke Chen"/> and <co
ntact fullname="Vincent
Gillet"/> for their work on <xref target="RFC4486" format="default"/> and
granting the related BCP
78 rights to the IETF Trust.</t>
<t>The authors would like to acknowledge <contact fullname="Misha Grishin"
/> (MSK-IX) for raising
awareness that the length specification of <xref target="RFC8203" format="
default"/> was insufficient
in context of multibyte character sets.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 22 change blocks. 
298 lines changed or deleted 328 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/