You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<title>Xml2rfc Vocabulary Version 3 Schema xml2rfc release 3.12.0</title>
7
+
<title>Xml2rfc Vocabulary Version 3 Schema xml2rfc release 3.12.1</title>
8
8
<metacontent="xml2rfc(1)" name="author">
9
9
<metacontent="
10
10
11
11
This document provides information about the XML schema implemented in this release of xml2rfc, and the individual elements of that schema. The document is generated from the RNG schema file that is part of the xml2rfc distribution, so schema information in this document should always be in sync with the schema in actual use. The textual descriptions depend on manual updates in order to reflect the implementation.
The latest version of this documentation is available in HTML form at <span><ahref="https://xml2rfc.ietf.org/xml2rfc-doc">https://xml2rfc.ietf.org/xml2rfc-doc</a></span>.<ahref="#section-1-5" class="pilcrow">¶</a></p>
369
369
<pid="section-1-6">
370
-
This documentation applies to xml2rfc version 3.12.0.<ahref="#section-1-6" class="pilcrow">¶</a></p>
370
+
This documentation applies to xml2rfc version 3.12.1.<ahref="#section-1-6" class="pilcrow">¶</a></p>
<title>Xml2rfc Vocabulary Version 3 Schema xml2rfc release 3.12.0</title>
7
+
<title>Xml2rfc Vocabulary Version 3 Schema xml2rfc release 3.12.1</title>
8
8
<metacontent="xml2rfc(1)" name="author">
9
9
<metacontent="
10
10
11
11
This document provides information about the XML schema implemented in this release of xml2rfc, and the individual elements of that schema. The document is generated from the RNG schema file that is part of the xml2rfc distribution, so schema information in this document should always be in sync with the schema in actual use. The textual descriptions depend on manual updates in order to reflect the implementation.
The latest version of this documentation is available in HTML form at <span><ahref="https://xml2rfc.ietf.org/xml2rfc-doc">https://xml2rfc.ietf.org/xml2rfc-doc</a></span>.<ahref="#section-1-5" class="pilcrow">¶</a></p>
369
369
<pid="section-1-6">
370
-
This documentation applies to xml2rfc version 3.12.0.<ahref="#section-1-6" class="pilcrow">¶</a></p>
370
+
This documentation applies to xml2rfc version 3.12.1.<ahref="#section-1-6" class="pilcrow">¶</a></p>
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. Contents Status of this Memo.......................................... 1</t></abstract>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
533
+
<authorfullname="Thomas Narten">
534
+
</author>
535
+
<authorfullname="Harald Alvestrand">
536
+
</author>
537
+
<datemonth="March"day="26"year="2008"/>
538
+
<abstract>
539
+
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
540
+
541
+
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
542
+
543
+
This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
0 commit comments