| < draft-narten-iana-considerations-rfc2434bis-08.txt | draft-narten-iana-considerations-rfc2434bis-09.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT Thomas Narten | INTERNET-DRAFT Thomas Narten | |||
| IBM | IBM | |||
| <draft-narten-iana-considerations-rfc2434bis-08.txt> Harald Alvestrand | <draft-narten-iana-considerations-rfc2434bis-09.txt> Harald Alvestrand | |||
| Obsoletes (if approved): 2434 Google | Obsoletes (if approved): 2434 Google | |||
| Expires: April 4, 2007 October 4, 2007 | Expires: September 21, 2007 March 26, 2008 | |||
| Intended Status: BCP | Intended Status: BCP | |||
| Guidelines for Writing an IANA Considerations Section in RFCs | Guidelines for Writing an IANA Considerations Section in RFCs | |||
| <draft-narten-iana-considerations-rfc2434bis-08.txt> | <draft-narten-iana-considerations-rfc2434bis-09.txt> | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| This Internet-Draft expires in six months. | This Internet-Draft expires in six months. | |||
| Abstract | Abstract | |||
| Many protocols make use of identifiers consisting of constants and | Many protocols make use of identifiers consisting of constants and | |||
| other well-known values. Even after a protocol has been defined 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 | 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 | new option type in DHCP, or a new encryption or authentication | |||
| transform for IPsec). To ensure that such quantities have consistent | transform for IPsec). To ensure that such quantities have consistent | |||
| values and interpretations in different implementations, their | values and interpretations across all implementations, their | |||
| assignment must be administered by a central authority. For IETF | assignment must be administered by a central authority. For IETF | |||
| protocols, that role is provided by the Internet Assigned Numbers | protocols, that role is provided by the Internet Assigned Numbers | |||
| Authority (IANA). | Authority (IANA). | |||
| In order for IANA to manage a given name space prudently, it needs | In order for IANA to manage a given name space prudently, it needs | |||
| guidelines describing the conditions under which new values can be | guidelines describing the conditions under which new values can be | |||
| assigned, or when modifications to existing values can be made. If | 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, | 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 | the IANA must be given clear and concise instructions describing that | |||
| role. This document discusses issues that should be considered in | role. This document discusses issues that should be considered in | |||
| skipping to change at page 3, line 16 ¶ | skipping to change at page 3, line 16 ¶ | |||
| Status of this Memo.......................................... 1 | Status of this Memo.......................................... 1 | |||
| 1. Introduction............................................. 4 | 1. Introduction............................................. 4 | |||
| 2. Why Management of a Name Space May be Necessary.......... 5 | 2. Why Management of a Name Space May be Necessary.......... 5 | |||
| 3. Designated Experts....................................... 5 | 3. Designated Experts....................................... 5 | |||
| 3.1. The Motivation For Designated Experts............... 5 | 3.1. The Motivation For Designated Experts............... 5 | |||
| 3.2. The Role of the Designated Expert................... 7 | 3.2. The Role of the Designated Expert................... 7 | |||
| 3.3. Designated Expert Reviews........................... 7 | 3.3. Designated Expert Reviews........................... 8 | |||
| 4. Creating A Registry...................................... 9 | 4. Creating A Registry...................................... 9 | |||
| 4.1. Well-Known IANA Policy Definitions.................. 9 | 4.1. Well-Known IANA Policy Definitions.................. 10 | |||
| 4.2. What To Put In Documents That Create A Registry..... 13 | 4.2. What To Put In Documents That Create A Registry..... 13 | |||
| 4.3. Updating IANA Guidelines For Existing Registries.... 15 | 4.3. Updating IANA Guidelines For Existing Registries.... 16 | |||
| 5. Registering New Values In An Existing Registry........... 15 | 5. Registering New Values In An Existing Registry........... 16 | |||
| 5.1. What to Put In Documents When Registering Values.... 15 | 5.1. What to Put In Documents When Registering Values.... 16 | |||
| 5.2. Updating Registrations.............................. 17 | 5.2. Updating Registrations.............................. 18 | |||
| 5.3. Overriding Registration Procedures.................. 18 | 5.3. Overriding Registration Procedures.................. 18 | |||
| 6. Miscellaneous Issues..................................... 18 | 6. Miscellaneous Issues..................................... 19 | |||
| 6.1. When There Are No IANA Actions...................... 18 | 6.1. When There Are No IANA Actions...................... 19 | |||
| 6.2. Namespaces Lacking Documented Guidance.............. 19 | 6.2. Namespaces Lacking Documented Guidance.............. 20 | |||
| 6.3. After-The-Fact Registrations........................ 19 | 6.3. After-The-Fact Registrations........................ 20 | |||
| 6.4. Reclaiming Assigned Values.......................... 20 | 6.4. Reclaiming Assigned Values.......................... 20 | |||
| 7. Appeals.................................................. 20 | 7. Appeals.................................................. 21 | |||
| 8. Mailing Lists............................................ 20 | 8. Mailing Lists............................................ 21 | |||
| 9. Security Considerations.................................. 21 | 9. Security Considerations.................................. 21 | |||
| 10. Changes Relative to RFC 2434............................ 21 | 10. Changes Relative to RFC 2434............................ 22 | |||
| 11. IANA Considerations..................................... 22 | 11. IANA Considerations..................................... 23 | |||
| 12. Acknowledgments......................................... 22 | 12. Acknowledgments......................................... 23 | |||
| 13. Normative References.................................... 23 | 13. Normative References.................................... 23 | |||
| 14. Informative References.................................. 23 | 14. Informative References.................................. 23 | |||
| 15. Authors' Addresses...................................... 26 | 15. Authors' Addresses...................................... 26 | |||
| 1. Introduction | 1. Introduction | |||
| Many protocols make use of fields that contain constants and other | Many protocols make use of fields that contain constants and other | |||
| skipping to change at page 7, line 39 ¶ | skipping to change at page 7, line 39 ¶ | |||
| norms, e.g., those in section 3.3. | norms, e.g., those in section 3.3. | |||
| Section 5.2 discusses disputes and appeals in more detail. | Section 5.2 discusses disputes and appeals in more detail. | |||
| Designated experts are appointed by the IESG (normally upon | Designated experts are appointed by the IESG (normally upon | |||
| recommendation by the relevant Area Director). They are typically | recommendation by the relevant Area Director). They are typically | |||
| named at the time a document creating or updating a name space is | named at the time a document creating or updating a name space is | |||
| approved by the IESG, but as experts originally appointed may later | approved by the IESG, but as experts originally appointed may later | |||
| become unavailable, the IESG will appoint replacements if necessary. | become unavailable, the IESG will appoint replacements if necessary. | |||
| For some registries, it has proven useful to have multiple designated | ||||
| experts. Sometimes those experts work together in evaluating a | ||||
| request, while in other cases additional experts serve as backups. In | ||||
| cases of disagreement among those experts, it is the responsibility | ||||
| of those experts to make a single clear recommendation to IANA. It is | ||||
| not appropriate for IANA to resolve disputes among experts. In | ||||
| extreme situations (e.g., deadlock) the IESG may need to step in to | ||||
| resolve the problem. | ||||
| In registries where a pool of experts evaluates requests, the pool | ||||
| should have a single chair responsible for defining how requests are | ||||
| to be assigned to and reviewed by experts. In some cases, the expert | ||||
| pool may consist of a primary and backups, with the backups involved | ||||
| only when the primary expert is unavailable. In other cases, IANA | ||||
| might assign requests to a individual members in sequential or | ||||
| approximate random order. In the event that IANA finds itself havnig | ||||
| received conflicting advice from its experts, it is the | ||||
| responsibility of the pool's chair to resolve the issue and provide | ||||
| IANA with clear | ||||
| Since the designated experts are appointed by the IESG, they may be | Since the designated experts are appointed by the IESG, they may be | |||
| removed by the IESG. | removed by the IESG. | |||
| 3.3. Designated Expert Reviews | 3.3. Designated Expert Reviews | |||
| In the eight years since RFC 2434 was published and has been put to | In the eight years since RFC 2434 was published and has been put to | |||
| use, experience has led to the following observations: | use, experience has led to the following observations: | |||
| - a designated expert must respond in a timely fashion, normally | - a designated expert must respond in a timely fashion, normally | |||
| within a week for simple requests to a few weeks for more complex | within a week for simple requests to a few weeks for more complex | |||
| skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 23 ¶ | |||
| Expert Review (or Designated Expert) - approval by a Designated | Expert Review (or Designated Expert) - approval by a Designated | |||
| Expert is required. The required documentation and review | Expert is required. The required documentation and review | |||
| criteria for use by the Designated Expert should be | criteria for use by the Designated Expert should be | |||
| provided when defining the registry. For example, see | provided when defining the registry. For example, see | |||
| Sections 6 and 7.2 in [RFC3748]. | Sections 6 and 7.2 in [RFC3748]. | |||
| Examples: EAP Method Types [RFC3748], HTTP Digest AKA | Examples: EAP Method Types [RFC3748], HTTP Digest AKA | |||
| algorithm versions [RFC4169], URI schemes [RFC4395], | algorithm versions [RFC4169], URI schemes [RFC4395], | |||
| GEOPRIV Location Types [RFC4589]. | GEOPRIV Location Types [RFC4589]. | |||
| Specification required - Values and their meaning must be | Specification Required - Values and their meaning must be | |||
| documented in an RFC or other permanent and readily | documented in a permanent and readily available public | |||
| available public specification, in sufficient detail so | specification, in sufficient detail so that | |||
| that interoperability between independent implementations | interoperability between independent implementations is | |||
| is possible. When used, Specification Required also implies | possible. When used, Specification Required also implies | |||
| usage of a Designated Expert, who will review the public | usage of a Designated Expert, who will review the public | |||
| specification and evaluate whether it is sufficiently clear | specification and evaluate whether it is sufficiently clear | |||
| to allow interoperable implementations. The intention | to allow interoperable implementations. The intention | |||
| behind "permanent and readily available" is that a document | behind "permanent and readily available" is that a document | |||
| can be reasonably be expected to easily be found long after | can reasonably be expected to be findable and retrievable | |||
| IANA assignment of the requested value. Publication of an | long after IANA assignment of the requested value. | |||
| RFC is the ideal means of achieving this requirement. For | Publication of an RFC is an ideal means of achieving this | |||
| RFC publication, the normal RFC review process is expected | requirement, but Specification Required is intended to also | |||
| to provide the necessary review for interoperability, | cover the case of a document published outside of the RFC | |||
| though the Designated Expert may be a particularly well- | path. For RFC publication, the normal RFC review process is | |||
| qualified person to perform such a review. | expected to provide the necessary review for | |||
| interoperability, though the Designated Expert may be a | ||||
| particularly well-qualified person to perform such a | ||||
| review. | ||||
| Examples: Diffserv-aware TE Bandwidth Constraints Model | Examples: Diffserv-aware TE Bandwidth Constraints Model | |||
| Identifiers [RFC4124], TLS ClientCertificateType | Identifiers [RFC4124], TLS ClientCertificateType | |||
| identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. | identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. | |||
| RFC Required - RFC publication (either as IETF Submission or as an | RFC Required - RFC publication (either as IETF Submission or as an | |||
| RFC Editor submission [RFC3932]) suffices. Unless otherwise | RFC Editor submission [RFC3932]) suffices. Unless otherwise | |||
| specified, any type of RFC is sufficient (e.g., | specified, any type of RFC is sufficient (e.g., | |||
| Informational, Experimental, Standards Track, etc.) | Informational, Experimental, Standards Track, etc.) | |||
| IETF Review - (Formerly called "IETF Consensus" in [IANA- | IETF Review - (Formerly called "IETF Consensus" in [IANA- | |||
| CONSIDERATIONS]) New values are assigned only through RFCs | CONSIDERATIONS]) New values are assigned only through RFCs | |||
| that have been shepherded through the IESG as AD-Sponsored | that have been shepherded through the IESG as AD-Sponsored | |||
| IETF (or WG) Documents [RFC3932,RFC3978]. The intention is | or IETF WGs Documents [RFC3932,RFC3978]. The intention is | |||
| that the document and proposed assignment will be reviewed | that the document and proposed assignment will be reviewed | |||
| by the IESG and appropriate IETF WGs (or experts, if | by the IESG and appropriate IETF WGs (or experts, if | |||
| suitable working groups no longer exist) to ensure that the | suitable working groups no longer exist) to ensure that the | |||
| proposed assignment will not negatively impact | proposed assignment will not negatively impact | |||
| interoperability or otherwise extend IETF protocols in an | interoperability or otherwise extend IETF protocols in an | |||
| inappropriate or damaging manner. | inappropriate or damaging manner. | |||
| To ensure adequate community review, such documents are | To ensure adequate community review, such documents are | |||
| shepherded through the IESG as AD-sponsored documents with | shepherded through the IESG as AD-sponsored (or WG) | |||
| an IETF Last Call. | documents with an IETF Last Call. | |||
| Examples: IPSECKEY Algorithm Types [RFC4025], Accounting- | Examples: IPSECKEY Algorithm Types [RFC4025], Accounting- | |||
| Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake | Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake | |||
| Hello Extensions [RFC4366]. | Hello Extensions [RFC4366]. | |||
| Standards Action - Values are assigned only for Standards Track | Standards Action - Values are assigned only for Standards Track | |||
| RFCs approved by the IESG. | RFCs approved by the IESG. | |||
| Examples: BGP message types [RFC4271], Mobile Node | Examples: BGP message types [RFC4271], Mobile Node | |||
| Identifier option types [RFC4283], DCCP Packet Types | Identifier option types [RFC4283], DCCP Packet Types | |||
| skipping to change at page 12, line 33 ¶ | skipping to change at page 13, line 6 ¶ | |||
| processes implied by other policies that could have been | processes implied by other policies that could have been | |||
| employed for a particular assignment. IESG Approval would | employed for a particular assignment. IESG Approval would | |||
| be appropriate, however, in cases where expediency is | be appropriate, however, in cases where expediency is | |||
| desired and there is strong consensus for making the | desired and there is strong consensus for making the | |||
| assignment (e.g., WG consensus). | assignment (e.g., WG consensus). | |||
| The following guidelines are suggested for any evaluation | The following guidelines are suggested for any evaluation | |||
| under IESG Approval: | under IESG Approval: | |||
| - The IESG can (and should) reject a request if another | - The IESG can (and should) reject a request if another | |||
| path is available that is more appropriate and there is | path for registration is available that is more | |||
| no compelling reason to bypass normal community review. | appropriate and there is no compelling reason to use | |||
| that path. | ||||
| - before approving a request, the community should be | - before approving a request, the community should be | |||
| consulted, via a "call for comments" that provides as | consulted, via a "call for comments" that provides as | |||
| much information as is reasonably possible about the | much information as is reasonably possible about the | |||
| request. | request. | |||
| Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP | Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP | |||
| Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and | Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and | |||
| Option values [RFC3775]. | Option values [RFC3775]. | |||
| It should be noted that it often makes sense to partition a name | It should be noted that it often makes sense to partition a name | |||
| space into multiple categories, with assignments within each category | space into multiple categories, with assignments within each category | |||
| handled differently. For example, many protocols now partition name | handled differently. For example, many protocols now partition name | |||
| spaces into two (or even more) parts, where one range is reserved for | spaces into two (or even more) parts, where one range is reserved for | |||
| Private or Experimental Use, while other ranges are reserved for | Private or Experimental Use, while other ranges are reserved for | |||
| globally unique assignments assigned following some review process. | globally unique assignments assigned following some review process. | |||
| Dividing a name space into ranges makes it possible to have different | Dividing a name space into ranges makes it possible to have different | |||
| policies in place for different ranges. | policies in place for different ranges. | |||
| Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3) | ||||
| [RFC4446]. | ||||
| 4.2. What To Put In Documents That Create A Registry | 4.2. What To Put In Documents That Create A Registry | |||
| The previous sections presented some issues that should be considered | The previous sections presented some issues that should be considered | |||
| in formulating a policy for assigning values in name spaces. It is | in formulating a policy for assigning values in name spaces. It is | |||
| the Working Group and/or document author's job to formulate an | the Working Group and/or document author's job to formulate an | |||
| appropriate policy and specify it in the appropriate document. In | appropriate policy and specify it in the appropriate document. In | |||
| almost all cases, having an explicit "IANA Considerations" section is | almost all cases, having an explicit "IANA Considerations" section is | |||
| appropriate. The following and later sections define what is needed | appropriate. The following and later sections define what is needed | |||
| for the different types of IANA actions. | for the different types of IANA actions. | |||
| skipping to change at page 14, line 40 ¶ | skipping to change at page 15, line 19 ¶ | |||
| the desired level of review. It is also acceptable to cite one of the | the desired level of review. It is also acceptable to cite one of the | |||
| above policies and include additional guidelines for what kind of | above policies and include additional guidelines for what kind of | |||
| considerations should be taken into account by the review process. | considerations should be taken into account by the review process. | |||
| For example, RADIUS [RFC3575] specifies the use of a Designated | For example, RADIUS [RFC3575] specifies the use of a Designated | |||
| Expert, but includes specific additional criteria the Designated | Expert, but includes specific additional criteria the Designated | |||
| Expert should follow. | Expert should follow. | |||
| For example, a document could say something like: | For example, a document could say something like: | |||
| This document defines a new DHCP option, entitled "FooBar" (see | This document defines a new DHCP option, entitled "FooBar" (see | |||
| Section y), assigned a value of TBD1 from the DCHP Option space | Section y), assigned a value of TBD1 from the DHCP Option space | |||
| [to be removed upon publication: | [to be removed upon publication: | |||
| http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP- | http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP- | |||
| OPTIONS,DHCP-IANA]: | OPTIONS,DHCP-IANA]: | |||
| Data | Data | |||
| Tag Name Length Meaning | Tag Name Length Meaning | |||
| ---- ---- ------ ------- | ---- ---- ------ ------- | |||
| TBD1 FooBar N FooBar server | TBD1 FooBar N FooBar server | |||
| The FooBar option also defines an 8-bit FooType field, for which | The FooBar option also defines an 8-bit FooType field, for which | |||
| IANA is to create and maintain a new sub-registry entitled | IANA is to create and maintain a new sub-registry entitled | |||
| "FooType values" under the FooBar option. Initial values for the | "FooType values" under the FooBar option. Initial values for the | |||
| DHCP FooBar FooType registry are given below; future assignments | DHCP FooBar FooType registry are given below; future assignments | |||
| are to be made through Expert Review [IANA-CONSIDERATIONS]. | are to be made through Expert Review [IANA-CONSIDERATIONS]. | |||
| Assignments consist of a DHCP FooBar FooType name and its | Assignments consist of a DHCP FooBar FooType name and its | |||
| associated value. | associated value. | |||
| Value DHCP FooBar FooType Name Definition | Value DHCP FooBar FooType Name Definition | |||
| ---- ------------------------ ---------- | ---- ------------------------ ---------- | |||
| 0 Reserved | 0 Reserved | |||
| 1 Frobnitz See Section y.1 | 1 Frobnitz See Section y.1 | |||
| 2 NitzFrob See Section y.2 | 2 NitzFrob See Section y.2 | |||
| 3-254 Unassigned | 3-254 Unassigned | |||
| 255 Reserved | 255 Reserved | |||
| For examples of documents that provide detailed guidance to IANA on | For examples of documents that provide detailed guidance to IANA on | |||
| the issue of assigning numbers, consult [RFC2929, RFC3575, RFC3968, | the issue of assigning numbers, consult [RFC2929, RFC3575, RFC3968, | |||
| RFC4520]. | RFC4520]. | |||
| 4.3. Updating IANA Guidelines For Existing Registries | 4.3. Updating IANA Guidelines For Existing Registries | |||
| Updating the registration process for an already existing (i.e., | Updating the registration process for an already existing (i.e., | |||
| previously created) name space (whether created explicitly or | previously created) name space (whether created explicitly or | |||
| implicitly) follows a process similar to that used when creating a | implicitly) follows a process similar to that used when creating a | |||
| skipping to change at page 16, line 9 ¶ | skipping to change at page 16, line 37 ¶ | |||
| value is to be registered. If the registration goes into a sub- | value is to be registered. If the registration goes into a sub- | |||
| registry, the author should clearly describe where the assignment | registry, the author should clearly describe where the assignment | |||
| or registration should go. It is helpful to use the exact name | or registration should go. It is helpful to use the exact name | |||
| space name as listed on the IANA web page (and defining RFC), and | space name as listed on the IANA web page (and defining RFC), and | |||
| cite the RFC where the name space is defined. | cite the RFC where the name space is defined. | |||
| Note 1: There is no need to mention what the assignment policy for | Note 1: There is no need to mention what the assignment policy for | |||
| new assignments is, as that should be clear from the references. | new assignments is, as that should be clear from the references. | |||
| Note 2: When referring to an existing registry, providing a URL to | Note 2: When referring to an existing registry, providing a URL to | |||
| precisely identify the registry is helpful. All such URLs, | precisely identify the registry is helpful. Such URLs, however, | |||
| however, will be removed from the RFC prior to final publication. | should usually be removed from the RFC prior to final publication, | |||
| For example, documents could contain: [TO BE REMOVED: This | since IANA URLs are not guaranteed to be stable in the future. In | |||
| cases where it is important to include a URL in the document, IANA | ||||
| should should concur on its inclusion. | ||||
| As an example, documents could contain: [TO BE REMOVED: This | ||||
| registration should take place at the following location: | registration should take place at the following location: | |||
| http://www.iana.org/assignments/foobar-registry] | http://www.iana.org/assignments/foobar-registry] | |||
| - Each value requested should be given a unique reference. When the | - Each value requested should be given a unique reference. When the | |||
| value is numeric, use the notation: TBD1, TBD2, etc. Throughout | value is numeric, use the notation: TBD1, TBD2, etc. Throughout | |||
| the document where an actual IANA-assigned value should be filled | the document where an actual IANA-assigned value should be filled | |||
| in, use the "TBDx" notation. This helps ensure that the final RFC | in, use the "TBDx" notation. This helps ensure that the final RFC | |||
| has the correct assigned values inserted in in all of the relevant | has the correct assigned values inserted in in all of the relevant | |||
| places where the value is expected to appear in the final | places where the value is expected to appear in the final | |||
| document. For values that are text strings, a specific name can be | document. For values that are text strings, a specific name can be | |||
| skipping to change at page 16, line 52 ¶ | skipping to change at page 17, line 37 ¶ | |||
| - The IANA Considerations section should summarize all of the IANA | - The IANA Considerations section should summarize all of the IANA | |||
| actions, with pointers to the relevant sections elsewhere in the | actions, with pointers to the relevant sections elsewhere in the | |||
| document as appropriate. When multiple values are requested, it is | document as appropriate. When multiple values are requested, it is | |||
| generally helpful to include a summary table. It is also helpful | generally helpful to include a summary table. It is also helpful | |||
| for this table to be in the same format as it should appear on the | for this table to be in the same format as it should appear on the | |||
| IANA web site. For example: | IANA web site. For example: | |||
| Value Description Reference | Value Description Reference | |||
| -------- ------------------- --------- | -------- ------------------- --------- | |||
| tbd1 Foobar [RFCXXXX] | TBD1 Foobar [RFCXXXX] | |||
| Note: in cases where authors feel that including the full table is | Note: in cases where authors feel that including the full table is | |||
| too verbose or repetitive, authors should still include the table, | too verbose or repetitive, authors should still include the table, | |||
| but may include a note asking the table be removed prior to | but may include a note asking the table be removed prior to | |||
| publication of the final RFC. | publication of the final RFC. | |||
| As an example, the following text could be used to request assignment | As an example, the following text could be used to request assignment | |||
| of a DHCPv6 option number: | of a DHCPv6 option number: | |||
| IANA has assigned an option code value of TBD1 to the DNS | IANA has assigned an option code value of TBD1 to the DNS | |||
| skipping to change at page 21, line 39 ¶ | skipping to change at page 22, line 26 ¶ | |||
| security considerations must be provided when assigning new values, | security considerations must be provided when assigning new values, | |||
| and the process for reviewing such claims. | and the process for reviewing such claims. | |||
| 10. Changes Relative to RFC 2434 | 10. Changes Relative to RFC 2434 | |||
| Changes include: | Changes include: | |||
| - Major reordering of text to expand descriptions and to better | - Major reordering of text to expand descriptions and to better | |||
| group topics such as "updating registries" vs. "creating new | group topics such as "updating registries" vs. "creating new | |||
| registries", in order to make it easier for authors to find the | registries", in order to make it easier for authors to find the | |||
| text most applicable to thier needs. | text most applicable to their needs. | |||
| - Numerous editorial changes to improve readability. | - Numerous editorial changes to improve readability. | |||
| - Changed the term "IETF Consensus" to "IETF Review" and added more | - Changed the term "IETF Consensus" to "IETF Review" and added more | |||
| clarifications. History has shown that people see the words "IETF | clarifications. History has shown that people see the words "IETF | |||
| Consensus" (without consulting the actual definition) are quick to | Consensus" (without consulting the actual definition) are quick to | |||
| make incorrect assumptions about what the term means in the | make incorrect assumptions about what the term means in the | |||
| context of IANA Considerations. | context of IANA Considerations. | |||
| - Added "RFC Required" to list of defined policies. | - Added "RFC Required" to list of defined policies. | |||
| skipping to change at page 22, line 38 ¶ | skipping to change at page 23, line 24 ¶ | |||
| This document is all about IANA Considerations, but has no IANA | This document is all about IANA Considerations, but has no IANA | |||
| actions. | actions. | |||
| 12. Acknowledgments | 12. Acknowledgments | |||
| 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, Barbara | Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Barbara | |||
| Denny, Spencer Dawkins, Miguel Garcia, Paul Hoffman, Russ Housley, | Denny, Spencer Dawkins, Miguel Garcia, Paul Hoffman, Russ Housley, | |||
| John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus | John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus | |||
| Westerland and Bert Wijnen. | Westerlund and Bert Wijnen. | |||
| 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 [MIME-REG]. | borrowed from [MIME-REG]. | |||
| skipping to change at page 25, line 37 ¶ | skipping to change at page 26, line 25 ¶ | |||
| [RFC4346] "The Transport Layer Security (TLS) Protocol Version 1.1," | [RFC4346] "The Transport Layer Security (TLS) Protocol Version 1.1," | |||
| T. Dierks, E. Rescorla. April 2006. | T. Dierks, E. Rescorla. April 2006. | |||
| [RFC4395] "Guidelines and Registration Procedures for New URI | [RFC4395] "Guidelines and Registration Procedures for New URI | |||
| Schemes," T. Hansen, T. Hardie, L. Masinter. | Schemes," T. Hansen, T. Hardie, L. Masinter. | |||
| February 2006. | February 2006. | |||
| [RFC4422] "Simple Authentication and Security Layer (SASL)". A. | [RFC4422] "Simple Authentication and Security Layer (SASL)". A. | |||
| Melnikov, Ed., K. Zeilenga, Ed.. June 2006. | Melnikov, Ed., K. Zeilenga, Ed.. June 2006. | |||
| [RFC4446] "IANA Allocations for Pseudowire Edge to Edge Emulation | ||||
| (PWE3)," L. Martini. April 2006. | ||||
| [RFC4520] "Internet Assigned Numbers Authority (IANA) Considerations | [RFC4520] "Internet Assigned Numbers Authority (IANA) Considerations | |||
| for the Lightweight Directory Access Protocol | for the Lightweight Directory Access Protocol | |||
| (LDAP)," K. Zeilenga. June 2006. | (LDAP)," K. Zeilenga. June 2006. | |||
| [RFC4589] "Location Types Registry," H. Schulzrinne, H. Tschofenig. | [RFC4589] "Location Types Registry," H. Schulzrinne, H. Tschofenig. | |||
| July 2006. | July 2006. | |||
| [RFC4727] "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, | [RFC4727] "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, | |||
| and TCP Headers". B. Fenner. November 2006. | and TCP Headers". B. Fenner. November 2006. | |||
| skipping to change at page 26, line 45 ¶ | skipping to change at page 27, line 33 ¶ | |||
| Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
| assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
| attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
| such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
| http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at | |||
| ipr@ietf.org. | ietf-ipr@ietf.org. | |||
| Copyright Statement | Copyright Statement | |||
| Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
| This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
| contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
| retain all their rights. | retain all their rights. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
| End of changes. 31 change blocks. | ||||
| 48 lines changed or deleted | 82 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/ | ||||