< draft-leiba-cotton-iana-5226bis-14.txt   draft-leiba-cotton-iana-5226bis-15.txt >
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
BCP: 26 B. Leiba BCP: 26 B. Leiba
Obsoletes: 5226 (if approved) Huawei Technologies Obsoletes: 5226 (if approved) Huawei Technologies
Intended status: Best Current Practice T. Narten Intended status: Best Current Practice T. Narten
Expires: November 29, 2016 IBM Corporation Expires: December 01, 2016 IBM Corporation
May 30, 2016 June 01, 2016
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-14 draft-leiba-cotton-iana-5226bis-15
Abstract Abstract
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
record keeper. For IETF protocols, that role is filled by the record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA). Internet Assigned Numbers Authority (IANA).
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 November 29, 2016. This Internet-Draft will expire on December 01, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 49 skipping to change at page 2, line 49
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20
4.11. Using the Well-Known Registration Policies . . . . . . . . 21 4.11. Using the Well-Known Registration Policies . . . . . . . . 21
4.12. Using Multiple Policies in Combination . . . . . . . . . . 22 4.12. Using Multiple Policies in Combination . . . . . . . . . . 22
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 23 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 23
5.1. The Motivation for Designated Experts . . . . . . . . . . 23 5.1. The Motivation for Designated Experts . . . . . . . . . . 23
5.2. The Role of the Designated Expert . . . . . . . . . . . . 23 5.2. The Role of the Designated Expert . . . . . . . . . . . . 23
5.2.1. Managing Designated Experts in the IETF . . . . . . . 24 5.2.1. Managing Designated Experts in the IETF . . . . . . . 24
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 25 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 25
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26
6. Well-Known Registration Status Terminology . . . . . . . . . . 27 6. Well-Known Registration Status Terminology . . . . . . . . . . 27
7. Documentation References in IANA Registries . . . . . . . . . 27 7. Documentation References in IANA Registries . . . . . . . . . 28
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 28 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 28
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 30
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 29 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 30
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 30 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 30
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 30 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 30
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 30 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 31
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31
9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 32 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 32
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33
14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Acknowledgments for This Document (2016) . . . . . . . . 35 15.1. Acknowledgments for This Document (2016) . . . . . . . . 35
15.2. Acknowledgments from the second edition (2008) . . . . . 35 15.2. Acknowledgments from the second edition (2008) . . . . . 35
15.3. Acknowledgments from the first edition (1998) . . . . . . 35 15.3. Acknowledgments from the first edition (1998) . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
record keeper. For IETF protocols, that role is filled by the record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA) [RFC2860]. Internet Assigned Numbers Authority (IANA) [RFC2860].
The Protocol field in the IP header [RFC0791] and MIME media types The Protocol field in the IP header [RFC0791] and MIME media types
[RFC4288] are two examples of such coordinations. [RFC6838] are two examples of such coordinations.
In this document, we call the range of possible values for such a In this document, we call the range of possible values for such a
field a "namespace". The binding or association of a specific value field a "namespace". The binding or association of a specific value
with a particular purpose within a namespace is called an assignment with a particular purpose within a namespace is called an assignment
(or, variously: an assigned number, assigned value, code point, (or, variously: an assigned number, assigned value, code point,
protocol constant, or protocol parameter). The act of assignment is protocol constant, or protocol parameter). The act of assignment is
called a registration, and it takes place in the context of a called a registration, and it takes place in the context of a
registry. The terms "assignment" and "registration" are used registry. The terms "assignment" and "registration" are used
interchangably throughout this document. interchangably throughout this document.
skipping to change at page 14, line 25 skipping to change at page 14, line 25
While it is sometimes necessary to restrict what gets registered While it is sometimes necessary to restrict what gets registered
(e.g., for limited resources such as bits in a byte, or for items for (e.g., for limited resources such as bits in a byte, or for items for
which unsupported values can be damaging to protocol operation), in which unsupported values can be damaging to protocol operation), in
many cases having what's in use represented in the registry is more many cases having what's in use represented in the registry is more
important. Overly strict review criteria and excessive cost (in time important. Overly strict review criteria and excessive cost (in time
and effort) discourage people from even attempting to make a and effort) discourage people from even attempting to make a
registration. If a registry fails to reflect the protocol elements registration. If a registry fails to reflect the protocol elements
actually in use, it can adversely affect deployment of protocols on actually in use, it can adversely affect deployment of protocols on
the Internet, and the registry itself is devalued. the Internet, and the registry itself is devalued.
Therefore, working groups and other document developers should use Therefore, it is important to think specifically about the
care in selecting appropriate registration policies when their registration policy, and not just pick one arbitrarily or nor copy
documents create registries. They should select the least strict text from another document. Working groups and other document
policy that suits a registry's needs, and look for specific developers should use care in selecting appropriate registration
justification for policies that require significant community policies when their documents create registries. They should select
involvement (those stricter than Expert Review or Specification the least strict policy that suits a registry's needs, and look for
Required, in terms of the well-known policies). specific justification for policies that require significant
community involvement (those stricter than Expert Review or
Specification Required, in terms of the well-known policies). The
needs here will vary from registry to registry, and, indeed, over
time, and this BCP will not be the last word on the subject.
The following policies are defined for common usage. These cover a The following policies are defined for common usage. These cover a
range of typical policies that have been used to describe the range of typical policies that have been used to describe the
procedures for assigning new values in a namespace. It is not procedures for assigning new values in a namespace. It is not
strictly required that documents use these terms; the actual strictly required that documents use these terms; the actual
requirement is that the instructions to IANA be clear and requirement is that the instructions to IANA be clear and
unambiguous. However, use of these terms is strongly recommended unambiguous. However, use of these terms is strongly recommended
because their meanings are widely understood, and newly minted because their meanings are widely understood. Newly minted policies,
policies should not be used without good reason and explanation. The including ones that combine the elements of procedures associated
terms are fully explained in the following subsections. with these terms in novel ways, may be used if none of these policies
are suitable; it will help the review process if an explanation is
included as to why that is the case. The terms are fully explained
in the following subsections.
1. Private Use 1. Private Use
2. Experimental Use 2. Experimental Use
3. Hierarchical Allocation 3. Hierarchical Allocation
4. First Come First Served 4. First Come First Served
5. Expert Review 5. Expert Review
6. Specification Required 6. Specification Required
7. RFC Required 7. RFC Required
8. IETF Review 8. IETF Review
9. Standards Action 9. Standards Action
skipping to change at page 18, line 14 skipping to change at page 18, line 14
The required documentation and review criteria, giving clear guidance The required documentation and review criteria, giving clear guidance
to the designated expert, should be provided when defining the to the designated expert, should be provided when defining the
registry. It is particularly important to lay out what should be registry. It is particularly important to lay out what should be
considered when performing an evaluation and reasons for rejecting a considered when performing an evaluation and reasons for rejecting a
request. It is also a good idea to include, when possible, a sense request. It is also a good idea to include, when possible, a sense
of whether many registrations are expected over time, or if the of whether many registrations are expected over time, or if the
registry is expected to be updated infrequently or in exceptional registry is expected to be updated infrequently or in exceptional
circumstances only. circumstances only.
Thorough understanding of Section 5 is important when deciding on an
Expert Review policy and designing the guidance to the designated
expert.
Good examples of guidance to designated experts: Good examples of guidance to designated experts:
Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and
7.2 7.2
North-Bound Distribution of Link-State and TE Information using North-Bound Distribution of Link-State and TE Information using
BGP [RFC7752], Section 5.1 BGP [RFC7752], Section 5.1
When creating a new registry with Expert Review as the registration When creating a new registry with Expert Review as the registration
policy, in addition to the contact person field or reference, the policy, in addition to the contact person field or reference, the
registry should contain a field for change controller. Having a registry should contain a field for change controller. Having a
skipping to change at page 19, line 13 skipping to change at page 19, line 15
documentation. documentation.
For RFC publication, formal review by the designated expert is still For RFC publication, formal review by the designated expert is still
requested, but the normal RFC review process is expected to provide requested, but the normal RFC review process is expected to provide
the necessary review for interoperability. The designated expert's the necessary review for interoperability. The designated expert's
review is still important, but it's equally important to note that review is still important, but it's equally important to note that
when there is IETF consensus, the expert can sometimes be "in the when there is IETF consensus, the expert can sometimes be "in the
rough" (see also the last paragraph of Section 5.4). rough" (see also the last paragraph of Section 5.4).
As with Expert Review (Section 4.5), clear guidance to the designated As with Expert Review (Section 4.5), clear guidance to the designated
expert, should be provided when defining the registry. expert, should be provided when defining the registry, and thorough
understanding of Section 5 is important.
When specifying this policy, just use the term "Specification When specifying this policy, just use the term "Specification
Required". Some specifications have chosen to refer to it as "Expert Required". Some specifications have chosen to refer to it as "Expert
Review with Specification Required", and that only causes confusion. Review with Specification Required", and that only causes confusion.
Examples: Examples:
Diffserv-aware TE Bandwidth Constraints Model Identifiers Diffserv-aware TE Bandwidth Constraints Model Identifiers
[RFC4124] [RFC4124]
TLS ClientCertificateType Identifiers 64-223 [RFC5246] TLS ClientCertificateType Identifiers 64-223 [RFC5246]
skipping to change at page 24, line 13 skipping to change at page 24, line 11
Ideally, the designated expert follows specific review criteria as Ideally, the designated expert follows specific review criteria as
documented with the protocol that creates or uses the namespace. See documented with the protocol that creates or uses the namespace. See
the IANA Considerations sections of [RFC3748] and [RFC3575] for the IANA Considerations sections of [RFC3748] and [RFC3575] for
specific examples. specific examples.
Designated experts are expected to be able to defend their decisions Designated experts are expected to be able to defend their decisions
to the IETF community, and the evaluation process is not intended to to the IETF community, and the evaluation process is not intended to
be secretive or bestow unquestioned power on the expert. Experts are be secretive or bestow unquestioned power on the expert. Experts are
expected to apply applicable documented review or vetting procedures, expected to apply applicable documented review or vetting procedures,
or in the absence of documented criteria, follow generally accepted or in the absence of documented criteria, follow generally accepted
norms such as those in Section 5.3. norms such as those in Section 5.3. Designated experts are generally
not expected to be "gatekeepers", setting out to make registrations
difficult to obtain, unless the guidance in the defining document
specifies that they should act as such. Absent stronger guidance,
the experts should be evaluating registration requests for
completeness, interoperability, and conflicts with existing protocols
and options.
It has proven useful to have multiple designated experts for some It has proven useful to have multiple designated experts for some
registries. Sometimes those experts work together in evaluating a registries. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups, request, while in other cases additional experts serve as backups,
acting only when the primary expert is unavailable. In registries acting only when the primary expert is unavailable. In registries
with a pool of experts, the pool often has a single chair responsible with a pool of experts, the pool often has a single chair responsible
for defining how requests are to be assigned to and reviewed by for defining how requests are to be assigned to and reviewed by
experts. In other cases, IANA might assign requests to individual experts. In other cases, IANA might assign requests to individual
members in sequential or approximate random order. members in sequential or approximate random order. The document
defining the registry can, if it's appropriate for the situation,
specify how the group should work -- for example, it might be
appropriate to specify rough consensus on a mailing list, within a
related working group, or among a pool of designated experts.
In cases of disagreement among multiple experts, it is the In cases of disagreement among multiple experts, it is the
responsibility of those experts to make a single clear recommendation responsibility of those experts to make a single clear recommendation
to IANA. It is not appropriate for IANA to resolve disputes among to IANA. It is not appropriate for IANA to resolve disputes among
experts. In extreme situations, such as deadlock, the designating experts. In extreme situations, such as deadlock, the designating
body may need to step in to resolve the problem. body may need to step in to resolve the problem.
If a designated expert is conflicted for a particular review (is, for If a designated expert is conflicted for a particular review (is, for
example, an author or significant proponent of a specification example, an author or significant proponent of a specification
related to the registration under review), that expert should recuse related to the registration under review), that expert should recuse
skipping to change at page 35, line 47 skipping to change at page 36, line 4
and suggestions for making this document as thorough as possible. and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by Tony This document has benefited from thorough review and comments by Tony
Hansen, John Klensin, and Mark Nottingham. Hansen, John Klensin, and Mark Nottingham.
Special thanks to Mark Nottingham for reorganizing some of the text Special thanks to Mark Nottingham for reorganizing some of the text
for better organization and readability, and to Tony Hansen for for better organization and readability, and to Tony Hansen for
acting as document shepherd. acting as document shepherd.
15.2. Acknowledgments from the second edition (2008) 15.2. Acknowledgments from the second edition (2008)
The original acknowledgments section in RFC 5226 was: The original acknowledgments section in RFC 5226 was:
This document has benefited from specific feedback from Jari Arkko, This document has benefited from specific feedback from Jari Arkko,
Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer
Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerlund, and Bert Wijnen. Westerlund, and Bert Wijnen.
15.3. Acknowledgments from the first edition (1998) 15.3. Acknowledgments from the first edition (1998)
The original acknowledgments section in RFC 2434 was: The original acknowledgments section in RFC 2434 was:
Jon Postel and Joyce Reynolds provided a detailed explanation on what Jon Postel and Joyce Reynolds provided a detailed explanation on what
IANA needs in order to manage assignments efficiently, and patiently IANA needs in order to manage assignments efficiently, and patiently
provided comments on multiple versions of this document. Brian provided comments on multiple versions of this document. Brian
Carpenter provided helpful comments on earlier versions of the Carpenter provided helpful comments on earlier versions of the
document. One paragraph in the Security Considerations section was document. One paragraph in the Security Considerations section was
borrowed from [RFC4288]. borrowed from RFC 4288.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
16.2. Informative References 16.2. Informative References
skipping to change at page 37, line 43 skipping to change at page 37, line 54
Authentication and Key Agreement (AKA) Version-2", RFC Authentication and Key Agreement (AKA) Version-2", RFC
4169, November 2005. 4169, November 2005.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006. Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006. 4395, February 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
skipping to change at page 38, line 43 skipping to change at page 38, line 53
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011. Considerations", BCP 42, RFC 6195, March 2011.
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
September 2012. September 2012.
[RFC6838] Freed, N., Klensin, J. and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-
editor.org/info/rfc6838>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc- 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-
editor.org/info/rfc6994>. editor.org/info/rfc6994>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014. Points", BCP 100, RFC 7120, January 2014.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", RFC Internationalized Strings in Application Protocols", RFC
 End of changes. 20 change blocks. 
30 lines changed or deleted 54 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/