Changing the Registration Policy for the NETCONF Capability URNs Registry
Relaxes the registration policy for NETCONF capability identifiers.
Leiba, B., "Changing the Registration Policy for the NETCONF Capability URNs Registry", BCP 203, RFC 7803, DOI 10.17487/RFC7803, February 2016, <https://www.rfc-editor.org/info/rfc7803>.
@misc{rfc7803,
series = {Request for Comments},
number = 7803,
howpublished = {RFC 7803},
publisher = {RFC Editor},
doi = {10.17487/RFC7803},
url = {https://www.rfc-editor.org/info/rfc7803},
author = {B. Leiba},
title = {{Changing the Registration Policy for the NETCONF Capability URNs Registry}},
pagetotal = 3,
year = 2016,
month = feb,
} RFC text
Contents
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/
AI ELI5
On this page
§1Relaxing Registry Access
RFC 6241 defined NETCONF (Network Configuration Protocol) and set up an IANA registry for NETCONF Capability URNs. The registry originally used the 'Standards Action' policy, which means only Standards Track RFCs could register entries. This policy was intended to ensure thorough review. However, it became clear that useful Experimental RFCs and other well-reviewed work needed capability URN allocations, and the strict policy required IESG exceptions to allow them.
A registry for network configuration standards was closed except to official standards. It turned out to be too strict.
§2The New IETF Review Policy
RFC 7803 changes the policy to 'IETF Review'. This allows registrations from Standards Track RFCs as before, but also from well-reviewed Experimental RFCs, Informational RFCs (for example, to correct registry errors), and other RFCs, provided they go through IETF Last Call and consultation with relevant working groups. The Operations and Management Area Directors confirm that the document received appropriate review during IESG evaluation.
Now the registry accepts names from official standards, but also from experimental work that has been carefully reviewed and approved by the IETF community.
§3Implementation and Impact
This policy change has had real impact on the NETCONF ecosystem. By allowing Experimental RFCs to register capabilities when carefully reviewed, the working group can now document and register extensions sooner. The Operations and Management Area Directors verify that non-Standards-Track RFCs receive appropriate review. This balance maintains quality while reducing procedural barriers.
The new rule makes it easier for new ideas to get official names, as long as they are carefully checked.