<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    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" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-grow-bmp-registries-change-04" number="9515" 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 -->

  <!-- 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>
    <title abbrev="BMP TLV Registration Procedures">
    Revision to Registration Procedures for Multiple BMP Registries</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-registries-change-04"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor --> name="RFC" value="9515"/>

    <author fullname="John Scudder" initials="J." surname="Scudder">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1194 N. Mathilda Ave</street>
          <!-- Reorder these if your country does things differently -->

          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jgs@juniper.net</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date/>
    <date year="2023" month="December" />
    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Network Working Group</workgroup>
    <area>ops</area>
    <workgroup>grow</workgroup>
    <keyword>IDR</keyword>
    <abstract>
      <t>
	This document updates RFC 7854, BGP "BGP Monitoring Protocol (BMP) (BMP)", by making
	a change to
	changing the registration procedures for several registries.
	Specifically, any BMP registry with a range of 32768-65530 designated
	"Specification Required" has that range re-designated redesignated as "First Come
	First Served".
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	<xref target="RFC7854" format="default"/> creates a number of IANA registries that
	include a range of 32768-65530 designated "Specification Required".
	Each such registry also has a large range designated "Standards
	Action". Subsequent experience has shown two things. First, there is
	less difference between these two policies in practice than there is in
	theory (consider that <xref target="RFC8126" format="default"/> explains that for
	Specification Required, "Publication of an RFC is an ideal means of
	achieving this requirement"). Second, it's desirable to have a very low
	bar to registration, to avoid the risk of conflicts introduced by use
	of unregistered code points (so-called "code point squatting").
</t>
      <t>
	Accordingly, this document revises the registration procedures, as given
	in <xref target="IANA" format="default"/>.
</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	IANA is requested to revise has revised the following registries within the BMP
	group:
</t>
      <ul spacing="compact">
        <li>BMP Statistics Types</li>
        <li>BMP Initiation Message and Peer Up Information TLVs</li>
        <li>BMP Termination Message TLVs</li>
        <li>BMP Termination Message Reason Codes</li>
        <li>BMP Route Mirroring TLVs</li>
        <li>BMP Route Mirroring Information Codes</li>
      </ul>
      <t>
	For each of these registries, the ranges 32768-65530 whose registration
	procedures were "Specification Required" are revised to have the
	registration procedures "First Come First Served".
</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	This revision to registration procedures does not change the
	underlying security issues inherent in the existing <xref target="RFC7854" format="default"/>.
</t>
    </section>

  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

    </references>
    <section anchor="Acknowledgements" numbered="true" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
	Thanks to Jeff Haas for review and encouragement, and to Tom Petch
	for review.
</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>Normative References</name>
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

	  <reference anchor="RFC7854" target="https://www.rfc-editor.org/info/rfc7854" 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="Scudder"/>
          <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 can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. 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/rfc8126" 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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
            <t>To make assignments in a given registry prudently, guidance describing 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 defines a framework for the documentation of these guidelines by specification authors, 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>
  </back>
</rfc>