< draft-leiba-iana-policy-update-00.txt   draft-leiba-iana-policy-update-01.txt >
Network Working Group B. Leiba Network Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Updates: 5226 (if approved) September 27, 2011 Updates: 5226 (if approved) October 26, 2011
Intended status: BCP Intended status: BCP
Expires: March 30, 2012 Expires: April 28, 2012
Update of and Clarification to IANA Policy Definitions in BCP 26 Update of and Clarification to IANA Policy Definitions in BCP 26
draft-leiba-iana-policy-update-00 draft-leiba-iana-policy-update-01
Abstract Abstract
Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration
policies that might be used in documents with IANA actions, and policies that might be used in documents with IANA actions, and
defines some well-known policy terms. This document clarifies the defines some well-known policy terms. This document clarifies the
usage of these terms, and discourages the use of overly restrictive usage of these terms, and discourages the use of overly restrictive
registration policies. registration policies.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2012. This Internet-Draft will expire on April 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
skipping to change at page 5, line 26 skipping to change at page 5, line 26
to any registration policy more stringent than Specification to any registration policy more stringent than Specification
Required, asking for justification and ensuring that more relaxed Required, asking for justification and ensuring that more relaxed
policies have been considered, and the strict policy is the right policies have been considered, and the strict policy is the right
one. This is a situation that will -- and should -- involve a one. This is a situation that will -- and should -- involve a
substantive discussion between the IESG and the working group, substantive discussion between the IESG and the working group,
chairs, document editors, and/or document shepherd. The important chairs, document editors, and/or document shepherd. The important
point, again, is not to relax the registration policy just to get the point, again, is not to relax the registration policy just to get the
document through quickly, but to carefully choose the right policy document through quickly, but to carefully choose the right policy
for each registry. for each registry.
Accordingly, document developers need to anticipate this and include Accordingly, document developers need to anticipate this and document
a justification for the chosen policy in the document along with the their considerations for choosing the specified policy. Ideally,
documentation of the choice. At the least, a justification should be they should include that in the document. At the least, it should be
included in the shepherd writeup for the document, and in any case included in the shepherd writeup for the document, and in any case
the document shepherd should ensure that the selected policies have the document shepherd should ensure that the selected policies have
been justified before sending the document to the IESG. been justified before sending the document to the IESG.
When specifications are revised, registration policies should be When specifications are revised, registration policies should be
reviewed in light of experience since the policies were set. It is reviewed in light of experience since the policies were set. It is
also possible to produce a small document at any time, which also possible to produce a small document at any time, which
"updates" the original specification and changes registration "updates" the original specification and changes registration
policies. In either case, a policy can be relaxed or made more policies. In either case, a policy can be relaxed or made more
strict, as appropriate to the actual situation. strict, as appropriate to the actual situation.
Once again, it cannot be stressed enough that this must not be a
mechanical process, but one to which the document developers apply
thought, consideration, assessment, and judgment in choosing the
right policy for each registry.
The recommendations in this section apply whether the terms defined The recommendations in this section apply whether the terms defined
in BCP 26 are used, or whether the document contains its own policy in BCP 26 are used, or whether the document contains its own policy
definitions. The point, again, is not to limit registration definitions. The point, again, is not to limit registration
policies, but to ensure that the policies selected are appropriate, policies, but to ensure that the policies selected are appropriate,
and that proper consideration has been given to the level of and that proper consideration has been given to the level of
strictness required by them. strictness required by them.
4. Security Considerations 4. Security Considerations
See the Security Considerations section in BCP 26 [RFC5226], and note See the Security Considerations section in BCP 26 [RFC5226], and note
skipping to change at page 6, line 17 skipping to change at page 6, line 23
to be registered, while overly permissive policies can result in to be registered, while overly permissive policies can result in
inappropriate registrations. Striking the right balance is an inappropriate registrations. Striking the right balance is an
important part of document development. important part of document development.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Acknowledgements 6. Acknowledgements
Cyrus Daboo, Alexey Melnikov, Pete Resnick, and Peter St. Andre were Cyrus Daboo, Alexey Melnikov, Thomas Narten, Pete Resnick, and Peter
involved in early discussion of these issues. St. Andre were involved in early discussion of these issues.
7. Normative References 7. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Author's Address Author's Address
Barry Leiba Barry Leiba
 End of changes. 8 change blocks. 
10 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/