rfc9736v1.txt		rfc9736.txt
	skipping to change at line 60 ¶		skipping to change at line 60 ¶
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Requirements Language		1.1. Requirements Language
	2. String Definition		2. String Definition
	3. Changes to Existing RFCs		3. Changes to Existing RFCs
	3.1. Revision to the Information TLV, Renamed as Initiation		3.1. Revision to the Information TLV
	Information TLV
	3.2. Revision to the Peer Up Notification		3.2. Revision to the Peer Up Notification
	3.3. Definition of Peer Up Information TLV		3.3. Definition of Peer Up Information TLV
	4. IANA Considerations		4. IANA Considerations
	5. Security Considerations		5. Security Considerations
	6. Normative References		6. Normative References
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	[RFC7854] defines a number of different BMP message types. With the		[RFC7854] defines a number of different BGP Monitoring Protocol (BMP)
	exception of the Route Monitoring message type, these messages are		message types. With the exception of the Route Monitoring message
	TLV-structured. Most message types have distinct namespaces and IANA		type, these messages are TLV-structured. Most message types have
	registries. However, the namespace of the Peer Up message overlaps		distinct namespaces and IANA registries. However, the namespace of
	that of the Initiation message. As the BGP Monitoring Protocol has		the Peer Up message overlaps that of the Initiation message. As BMP
	been extended, this oversight has become problematic. In this		has been extended, this overlap has become problematic. In this
	document, we create a distinct namespace for the Peer Up message to		document, we create distinct namespaces for the Peer Up and
	eliminate this overlap, and create the corresponding missing		Initiation messages to eliminate the overlap.
	registry.
	Compliant implementations of [RFC7854], [RFC8671], and [RFC9069] also		Compliant implementations of [RFC7854], [RFC8671], and [RFC9069] also
	comply with this specification.		comply with this specification.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at line 104 ¶		skipping to change at line 102 ¶
	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		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)		to terminate the string with a null (or any other particular)
	character -- the Length field gives its termination.		character -- the Length field gives its termination.
	3. Changes to Existing RFCs		3. Changes to Existing RFCs
	[RFC7854] is updated as detailed in the following subsections.		[RFC7854] is updated as detailed in the following subsections.
	3.1. Revision to the Information TLV, Renamed as Initiation Information		3.1. Revision to the Information TLV
	TLV
	The Information TLV defined in Section 4.4 of [RFC7854] is renamed		The Information TLV defined in Section 4.4 of [RFC7854] is renamed
	"Initiation Information TLV". It is used only by the Initiation		"Initiation Information TLV". It is used only by the Initiation
	message, not by the Peer Up message.		message, not by the Peer Up message.
	The definition of Type = 0 is revised to be:		The definition of Type = 0 is revised as shown below. Type = 1 and
			Type = 2 are unchanged; they are provided for for completeness.
	* Type = 0: String. The Information field contains a string		* Type = 0: String. The Information field contains a string
	(Section 2). The value is administratively assigned. If multiple		(Section 2). The value is administratively assigned. If multiple
	string TLVs are included, their ordering MUST be preserved when		string TLVs are included, their ordering MUST be preserved when
	they are reported.		they are reported.
	* Type = 1: sysDescr. The Information field contains an ASCII		* Type = 1: sysDescr. The Information field contains an ASCII
	string whose value MUST be set to be equal to the value of the		string whose value MUST be set to be equal to the value of the
	sysDescr MIB-II [RFC1213] object.		sysDescr MIB-II [RFC1213] object.
	skipping to change at line 142 ¶		skipping to change at line 140 ¶
	* Information: Information about the peer, using the Peer Up		* Information: Information about the peer, using the Peer Up
	Information TLV format defined in Section 3.3 of RFC 9736. The		Information TLV format defined in Section 3.3 of RFC 9736. The
	String type may be repeated. Inclusion of the Information field		String type may be repeated. Inclusion of the Information field
	is OPTIONAL. Its presence or absence can be inferred by		is OPTIONAL. Its presence or absence can be inferred by
	inspection of the Message Length in the common header.		inspection of the Message Length in the common header.
	3.3. Definition of Peer Up Information TLV		3.3. Definition of Peer Up Information TLV
	The Peer Up Information TLV is used by the Peer Up message.		The Peer Up Information TLV is used by the Peer Up message.
	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) |
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	* Information Type (2 bytes): defined types are:		* Information Type (2 bytes): types are as defined in the "BMP Peer
			Up Message TLVs" registry:
	- Type = 0: String. The Information field contains a string		- Type = 0: String. The Information field contains a string
	(Section 2). The value is administratively assigned. If		(Section 2). The value is administratively assigned. If
	multiple strings are included, their ordering MUST be preserved		multiple strings are included, their ordering MUST be preserved
	when they are reported.		when they are reported.
	- Type = 3: VRF/Table Name. The Information field contains a		- Type = 3: VRF/Table Name. The Information field contains a
	UTF-8 string whose value MUST be equal to the value of the VRF		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		or table name (e.g., RD instance name) being conveyed. The
	string size MUST be within the range of 1 to 255 bytes.		string size MUST be within the range of 1 to 255 bytes.
End of changes. 6 change blocks.
	16 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48.