rfc9515.original.xml		rfc9515.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		std" consensus="true" docName="draft-ietf-grow-bmp-registries-change-04" number=
	<!-- used by XSLT processors -->		"9515" ipr="trust200902" updates="7854" obsoletes="" xml:lang="en" tocInclude="t
	<!-- For a complete list and description of processing instructions (PIs),		rue" tocDepth="4" symRefs="true" sortRefs="true" version="3">
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that
	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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-grow-bmp-registries-change-04" ipr="trust200902" updates="7854" obsoletes=""
	submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true
	" sortRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.18.0 -->		<!-- xml2rfc v2v3 conversion 3.18.0 -->
	<!-- 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 ***** -->		<!-- ***** FRONT MATTER ***** -->
	<front>		<front>
	<title abbrev="BMP TLV Registration Procedures">		<title abbrev="BMP TLV Registration Procedures">
	Revision to Registration Procedures for Multiple BMP Registries</title>		Revision to Registration Procedures for Multiple BMP Registries</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-registries-chan		<seriesInfo name="RFC" value="9515"/>
	ge-04"/>
	<!-- add 'role="editor"' below for the editors if appropriate -->
	<!-- Another author who claims to be an editor -->
	<author fullname="John Scudder" initials="J." surname="Scudder">		<author fullname="John Scudder" initials="J." 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>USA</country>		<country>United States of America</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>
	<date/>		<date year="2023" month="December" />
	<!-- Meta-data Declarations -->		<!-- Meta-data Declarations -->
			<area>ops</area>
	<area>General</area>		<workgroup>grow</workgroup>
	<workgroup>Network Working Group</workgroup>
	<keyword>IDR</keyword>		<keyword>IDR</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document updates RFC 7854, BGP Monitoring Protocol (BMP) by making		This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by
	a change to the registration procedures for several registries.		changing the registration procedures for several registries.
	Specifically, any BMP registry with a range of 32768-65530 designated		Specifically, any BMP registry with a range of 32768-65530 designated
	"Specification Required" has that range re-designated as "First Come		"Specification Required" has that range redesignated as "First Come
	First Served".		First Served".
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	<xref target="RFC7854" format="default"/> creates a number of IANA regist ries that		<xref target="RFC7854" format="default"/> creates a number of IANA regist ries that
	include a range of 32768-65530 designated "Specification Required".		include a range of 32768-65530 designated "Specification Required".
	skipping to change at line 108 ¶		skipping to change at line 73 ¶
	of unregistered code points (so-called "code point squatting").		of unregistered code points (so-called "code point squatting").
	</t>		</t>
	<t>		<t>
	Accordingly, this document revises the registration procedures, as given		Accordingly, this document revises the registration procedures, as given
	in <xref target="IANA" format="default"/>.		in <xref target="IANA" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="IANA" numbered="true" toc="default">		<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	IANA is requested to revise the following registries within the BMP		IANA has revised the following registries within the BMP
	group:		group:
	</t>		</t>
	<ul spacing="compact">		<ul spacing="compact">
	<li>BMP Statistics Types</li>		<li>BMP Statistics Types</li>
	<li>BMP Initiation Message TLVs</li>		<li>BMP Initiation and Peer Up Information TLVs</li>
	<li>BMP Termination Message TLVs</li>		<li>BMP Termination Message TLVs</li>
	<li>BMP Termination Message Reason Codes</li>		<li>BMP Termination Message Reason Codes</li>
	<li>BMP Route Mirroring TLVs</li>		<li>BMP Route Mirroring TLVs</li>
	<li>BMP Route Mirroring Information Codes</li>		<li>BMP Route Mirroring Information Codes</li>
	</ul>		</ul>
	<t>		<t>
	For each of these registries, the ranges 32768-65530 whose registration		For each of these registries, the ranges 32768-65530 whose registration
	procedures were "Specification Required" are revised to have the		procedures were "Specification Required" are revised to have the
	registration procedures "First Come First Served".		registration procedures "First Come First Served".
	</t>		</t>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This revision to registration procedures does not change the		This revision to registration procedures does not change the
	underlying security issues inherent in the existing <xref target="RFC7854		underlying security issues inherent in <xref target="RFC7854" format="def
	" format="default"/>.		ault"/>.
	</t>
	</section>
	<section anchor="Acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>
	<t>
	Thanks to Jeff Haas for review and encouragement, and to Tom Petch
	for review.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<!-- *****BACK MATTER ***** -->		<!-- *****BACK MATTER ***** -->
	<back>		<back>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<!--?rfc include=		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"
	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->		/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
			/>
	<reference anchor="RFC7854" target="https://www.rfc-editor.org/info/rfc
	7854" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml">
	<front>
	<title>BGP Monitoring Protocol (BMP)</title>
	<author fullname="J. Scudder" initials="J." role="editor" surname="Scu
	dder"/>
	<author fullname="R. Fernando" initials="R." surname="Fernando"/>
	<author fullname="S. Stuart" initials="S." surname="Stuart"/>
	<date month="June" year="2016"/>
	<abstract>
	<t>This document defines the BGP Monitoring Protocol (BMP), which ca
	n be used to monitor BGP sessions. BMP is intended to provide a convenient inter
	face for obtaining route views. Prior to the introduction of BMP, screen scrapin
	g was the most commonly used approach to obtaining such views. The design goals
	are to keep BMP simple, useful, easily implemented, and minimally service affect
	ing. BMP is not suitable for use as a routing protocol.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7854"/>
	<seriesInfo name="DOI" value="10.17487/RFC7854"/>
	</reference>
	<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc812
	6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs</
	title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use const
	ants to identify various protocol parameters. To ensure that the values in these
	fields do not have conflicting uses and to promote interoperability, their allo
	cations are often coordinated by a central record keeper. For IETF protocols, th
	at role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance descr
	ibing the conditions under which new values should be assigned, as well as when
	and how modifications to existing values can be made, is needed. This document d
	efines a framework for the documentation of these guidelines by specification au
	thors, in order to assure that the provided guidance for the IANA Considerations
	is clear and addresses the various issues that are likely in the operation of a
	registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 5226
	.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	</references>		</references>
			<section anchor="Acknowledgements" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>
			Thanks to Jeff Haas for review and encouragement, and to Tom Petch
			for review.
			</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 18 change blocks.
	116 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48.