RFC 7803 BEST CURRENT PRACTICE NETCONF · IANA · POLICY

Changing the Registration Policy for the NETCONF Capability URNs Registry

A Best Current Practice changes how NETCONF capability URNs are reviewed.

On rfc-editor.org ↗
PUBLISHED
February 2016
AUTHORS
B. Leiba
STREAM
IETF
BUILDS ON
RFC 6241 — NETCONF
DOI
10.17487/RFC7803

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 7803                           Huawei Technologies
BCP: 203                                                   February 2016
Updates: 6241
Category: Best Current Practice
ISSN: 2070-1721


                  Changing the Registration Policy for
                  the NETCONF Capability URNs Registry

Abstract

   The registration policy for the "Network Configuration Protocol
   (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned
   out to be unnecessarily strict.  This document changes that
   registration policy to "IETF Review", allowing registrations from
   certain well-reviewed Experimental RFCs, in addition to Standards
   Track RFCs.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7803.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   2
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   2
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

1.  Introduction

   The "Network Configuration Protocol (NETCONF) Capability URNs"
   registry [RFC6241] was set up with a registration policy of
   "Standards Action" [RFC5226], allowing registrations only from
   Standards Track RFCs.  This provided thorough review of the
   specifications that are requesting NETCONF Capability URNs.  It has
   turned out to be desirable to allocate capability URNs for certain
   Experimental RFCs also, provided those specifications are also
   carefully reviewed.  The existing registration policy is, therefore,
   unnecessarily strict, requiring exception handling by the IESG.  This
   document changes that registration policy to "IETF Review", which
   also allows registrations from certain well-reviewed Experimental
   RFCs, or, for example, corrections to registry errors from
   Informational RFCs, with IETF review and consensus.

2.  IANA Considerations

   IANA has changed the registration policy for the "Network
   Configuration Protocol (NETCONF) Capability URNs" registry to "IETF
   Review" and has added this document to the registry's reference
   field.

   Registrations made from RFCs that are not on the Standards Track need
   to be carefully reviewed through IETF Last Call and in consultation
   with relevant working groups, such as NETCONF.  The Operations and
   Management Area Directors should confirm that the document has
   received the appropriate level of review during IESG Evaluation.

3.  Security Considerations

   This document is purely procedural, and there are no related security
   considerations.

4.  Normative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

Author's Address

   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   Email: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/

ISO Plain Language

On this page
PROBLEMThe NETCONF Capability URNs registry allowed registrations only from Standards Track RFCs, which the RFC says was unnecessarily strict.
MECHANISMRFC 7803 changes the registry policy to IETF Review. Non-Standards-Track RFCs need IETF Last Call, consultation with relevant working groups, and confirmation of appropriate review during IESG evaluation.
POLICY CHANGEThe change broadens which reviewed RFCs may register capability URNs and updates RFC 6241.

§1Why the Registration Rule Changed

RFC 6241 set the NETCONF Capability URNs registry to Standards Action, allowing registrations only from Standards Track RFCs. RFC 7803 says this policy proved unnecessarily strict because certain Experimental RFCs and registry corrections in Informational RFCs may also need entries.

The old rule limited registry entries to Standards Track RFCs. The IETF decided that this excluded some work that had received careful review.

§2The IETF Review Process

RFC 7803 changes the registration policy to IETF Review and adds the document as a registry reference. A registration from an RFC outside the Standards Track needs careful review through IETF Last Call and consultation with relevant working groups. The Operations and Management Area Directors should confirm the review during IESG evaluation.

More kinds of RFCs can seek a registry entry, but they must go through IETF review. The relevant area directors check that the review was appropriate.

§3Scope and Security

This document changes a registry procedure and updates RFC 6241. IANA changed the NETCONF Capability URNs registry policy to IETF Review. RFC 7803 describes itself as procedural and says it has no related security considerations.

The change concerns how registrations are reviewed. It does not add a protocol feature, and the RFC says it has no related security considerations.