draft-iab-itu-enum-notes-00.txt   rfc3245.txt 
INTERNET-DRAFT John C. Klensin
16 January 2002 Editor, for the IAB
The History and Context of ENUM Operational Decisions:
Informational Documents Contributed to ITU-T SG2
draft-iab-itu-enum-notes-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 except that the
right to produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Network Working Group J. Klensin, Ed.
and may be updated, replaced, or obsoleted by other documents at any Request for Comments: 3245 IAB
time. It is inappropriate to use Internet-Drafts as reference The History and Context of Telephone Number Mapping (ENUM)
material or to cite them other than as "work in progress." Operational Decisions: Informational Documents Contributed
to ITU-T Study Group 2 (SG2)
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
0. Abstract Abstract
RFC 2916 assigned responsibility for a number of administrative and RFC 2916 assigned responsibility for a number of administrative and
operational details of ENUM to the IAB. It also anticipated that ITU operational details of Telephone Number Mapping (ENUM) to the IAB.
would take responsibility for determining the legitimacy and It also anticipated that ITU would take responsibility for
appropriateness of applicants for delegation of "country code"-level determining the legitimacy and appropriateness of applicants for
subdomains of the top-level ENUM domain. Recently, three memos have delegation of "country code"-level subdomains of the top-level ENUM
been prepared for the ITU-T Study Group 2 to explain the background domain. Recently, three memos have been prepared for the ITU-T Study
of, and reasoning for, the relevant decisions. The IAB has also Group 2 (SG2) to explain the background of, and reasoning for, the
supplied a set of procedural instructions to The RIPE NCC for relevant decisions. The IAB has also supplied a set of procedural
implementation of their part of the model. The content of the three instructions to the RIPE NCC for implementation of their part of the
memos is provided in this document for the information of the IETF model. The content of the three memos is provided in this document
community. for the information of the IETF community.
Table of Contents Table of Contents
1. Introduction: ENUM Background Information 1. Introduction: ENUM Background Information ..................... 2
2. Why one and only one domain is used in ENUM 2. Why one and only one domain is used in ENUM ................... 2
3. Why .ARPA was selected as the top level domain for ENUM 3. Why .ARPA was selected as the top level domain for ENUM ....... 4
4. The selection of an operator for E164.ARPA 4. The selection of an operator for E164.ARPA .................... 7
5. Procedures to be followed by RIPE NCC 5. Procedures to be followed by RIPE NCC ......................... 8
6. References 6. References .................................................... 8
6.1. Normative references 6.1. Normative references ........................................ 8
6.2. Informative and explanatory references 6.2. Informative and explanatory references ...................... 8
7. Security Considerations 7. Security Considerations ....................................... 9
8. IANA Considerations 8. IANA Considerations ........................................... 9
9. Authors' Addresses 9. Authors' Addresses ............................................ 9
10. Full Copyright Statement ..................................... 10
1. Introduction: ENUM Background Information 1. Introduction: ENUM Background Information
In January 2002, in response to questions from ITU-T Study Group 2 In January 2002, in response to questions from the ITU-T Study Group
(referred to just as "SG2", below), specifically its group working on 2 (referred to just as "SG2", below), specifically its group working
"Questions 1 and 2", and members of the IETF and telecommunications on "Questions 1 and 2", and members of the IETF and
communities, Scott Bradner, as Area Director responsible for the ENUM telecommunications communities, Scott Bradner, as Area Director
work and ISOC Vice President for Standards, initiated an effort to responsible for the ENUM work and ISOC Vice President for Standards,
produce explanations of the decisions made by the IETF about ENUM initiated an effort to produce explanations of the decisions made by
administration. The effort to produce and refine those documents the IETF about ENUM administration. The effort to produce and refine
eventually involved him, Patrik Faltstrom (author of RFC 2916), and those documents eventually involved him, Patrik Faltstrom (author of
several members of the IAB. RFC 2916), and several members of the IAB.
The documents have now been contributed to ITU-T, and are being The documents have now been contributed to ITU-T, and are being
published as internal SG2 documents. This document provides the IETF published as internal SG2 documents. This document provides the IETF
community a copy of the information provided to SG2. Section 2 below community a copy of the information provided to SG2. Section 2 below
contains the same content as COM 2-11-E, section 3 contains the same contains the same content as COM 2-11-E, section 3 contains the same
content as COM 2-12-E, and section 4 contains the same content as SG2 content as COM 2-12-E, and section 4 contains the same content as SG2
document COM 2-10-E. The documents being published within SG2 show document COM 2-10-E. The documents being published within SG2 show
their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF", which their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF", which
is a formality deriving from the fact that ISOC holds an ITU sector is a formality deriving from the fact that ISOC holds an ITU sector
membership on behalf of the IETF. membership on behalf of the IETF.
skipping to change at line 112 skipping to change at page 3, line 11
"delegation" and their variations are used here in their specific, "delegation" and their variations are used here in their specific,
technical, DNS sense and may not have the same meanings they normally technical, DNS sense and may not have the same meanings they normally
would in an ITU context. would in an ITU context.
Given that one starts with the well-known root zone, every party Given that one starts with the well-known root zone, every party
querying the DNS system will end up at the same set of servers for querying the DNS system will end up at the same set of servers for
the same domain, regardless of who is sending the query, when the the same domain, regardless of who is sending the query, when the
query is sent and where in the network the query is initiated. In query is sent and where in the network the query is initiated. In
May 2000 the IAB published a document on the need for a single root May 2000 the IAB published a document on the need for a single root
in the DNS. This document explores the issues in greater detail. in the DNS. This document explores the issues in greater detail.
See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt?number=2826 ). See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt).
2.3. Storing E.164 numbers in the DNS 2.3. Storing E.164 numbers in the DNS
An E.164 number is also globally unique, and because of that it has An E.164 number is also globally unique, and because of that it has
the most of the same properties as a domain name. This was the reason most of the same properties as a domain name. This was the reason
why storing E.164 numbers in the DNS system is technically a simple why storing E.164 numbers in the DNS system is technically a simple
mapping. ENUM is just that, a way to store E.164 numbers in the DNS. mapping. ENUM is just that, a way to store E.164 numbers in the DNS.
Multiple ENUM trees in the DNS hierarchy would have the telephony Multiple ENUM trees in the DNS hierarchy would have the telephony
equivalent of permitting every carrier to assign a different meaning equivalent of permitting every carrier to assign a different meaning
to an E.164 country code, with each one potentially mapping a given to an E.164 country code, with each one potentially mapping a given
number to a different circuit or rejecting it entirely. For the number to a different circuit or rejecting it entirely. For the
Internet, if there were multiple trees, there would be no way to Internet, if there were multiple trees, there would be no way to
determine which domains might contain ENUM records. Thus, each determine which domains might contain ENUM records. Thus, each
application that uses ENUM facilities would have to be manually application that uses ENUM facilities would have to be manually
configured with a list of domains to be searched. This would incur configured with a list of domains to be searched. This would incur
skipping to change at line 167 skipping to change at page 4, line 18
This memo is one of a series provided by the IETF to SG2 to provide This memo is one of a series provided by the IETF to SG2 to provide
background information about the IETF's ENUM Working Group background information about the IETF's ENUM Working Group
deliberations and decisions. This particular memo addresses the deliberations and decisions. This particular memo addresses the
IETF's decision that the ENUM DNS tree would use the .ARPA top level IETF's decision that the ENUM DNS tree would use the .ARPA top level
domain. domain.
3.2. IAB Statement on Infrastructure Domain and Subdomains 3.2. IAB Statement on Infrastructure Domain and Subdomains
(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt , May (Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt , May
2000) 2000.)
Over the last several months, the IAB has been reviewing, and Over the last several months, the IAB has been reviewing, and
discussing with ICANN and other parties, the handling of various discussing with ICANN and other parties, the handling of various
Internet Protocol-related infrastructure components that the Internet Protocol-related infrastructure components that the
community has concluded should be placed into the DNS. community has concluded should be placed into the DNS.
Historically, the most visible infrastructure domain has been the Historically, the most visible infrastructure domain has been the
IPv4 address reverse-mapping domain. This domain was placed in IPv4 address reverse-mapping domain. This domain was placed in "in-
"in-addr.arpa" as part of the initial ARPANET transition strategy addr.arpa" as part of the initial ARPANET transition strategy from
from host table naming (see RFC 881- host table naming (see RFC 881-http://www.ietf.org/rfc/ rfc0881.txt).
http://www.ietf.org/rfc/rfc0881.txt?number=881 ). Other than the Other than the IPv4 reverse-mapping subdomain, it became the only
IPv4 reverse-mapping subdomain, it became the only active subdomain active subdomain of that domain as the <host-table-name>.ARPA names
of that domain as the <host-table-name>.ARPA names that were also that were also part of the transition were gradually removed. Other
part of the transition were gradually removed. Other infrastructure infrastructure domains were, in the past, placed under the "INT" TLD
domains were in the past placed under the "INT" TLD and various and various organizational names.
organizational names.
It is in the interest of general Internet stability, adequate It is in the interest of general Internet stability, to pay adequate
attention to the placement of secondary DNS servers, and attention to the placement of secondary DNS servers, and
administrative cleanliness, to start rationalizing this situation by administrative cleanliness, to start rationalizing this situation by
locating new infrastructure subdomains in a single domain and locating new infrastructure subdomains in a single domain and
migrating existing ones to it as appropriate. It appears that our migrating existing ones to it as appropriate. It appears that our
original infrastructure domain "ARPA", redesignated from an original infrastructure domain "ARPA", redesignated from an
abbreviation for "ARPANET" to an acronym for "Address and Routing abbreviation for "ARPANET" to an acronym for "Address and Routing
Parameters Area" is best suited for this purpose. Parameters Area" is best suited for this purpose.
3.3. Infrastructure subdomains 3.3. Infrastructure subdomains
Operationally, it is easier to ensure good stability for DNS in Operationally, it is easier to ensure good stability for DNS in
general if we have as few DNS zones as possible that are used for general if we have as few DNS zones as possible that are used for
parameters for infrastructure purposes. Today new infrastructure parameters for infrastructure purposes. Today, new infrastructure
domains are put in ARPA and old assignments which were made in other domains are put in ARPA and old assignments which were made in other
domains are being migrated to ARPA. Currently ARPA is used for domains are being migrated to ARPA. Currently, ARPA is used for in-
in-addr.arpa (for reverse mapping of IPv4 addresses), ip6.arpa, (for addr.arpa (for reverse mapping of IPv4 addresses), ip6.arpa, (for
reverse mapping of IPv6 addresses), and e164.arpa, (the subject of reverse mapping of IPv6 addresses), and e164.arpa, (the subject of
this memo). In the future, URI schemes, URN namespaces and other new this memo). In the future, URI schemes, URN namespaces and other new
address families will be stored in ARPA. address families will be stored in ARPA.
Theoretically, each set of infrastructure parameters could be stored Theoretically, each set of infrastructure parameters could be stored
in a separate domain as a TLD. (For example, .URI, .UNI, .IPV6, in a separate domain as a TLD. (For example, .URI, .UNI, .IPV6, new
.ENUM) But in that case every infrastructure parameter would need a TLD, which only can be created via the ICANN process (which might
new TLD, which only can be created via the ICANN process (which might
take a year or more) and would unnecessarily and undesirably flatten take a year or more) and would unnecessarily and undesirably flatten
the DNS tree. It is much easier to have one TLD with easily created the DNS tree. It is much easier to have one TLD with easily created
new subdomains (2nd level domains), one for each parameter. Thus it new subdomains (2nd level domains), one for each parameter. Thus it
was logical to store E.164 numbers in ARPA. was logical to store E.164 numbers in ARPA.
3.4. The ARPA domain (derived from RFC 3172, September 2001) 3.4. The ARPA domain (derived from RFC 3172, September 2001)
The "arpa" domain was originally established as part of the initial The "arpa" domain was originally established as part of the initial
deployment of the DNS, to provide a transition mechanism from the deployment of the DNS, to provide a transition mechanism from the
Host Tables that were previously standard in the ARPANET. It was Host Tables that were previously standard in the ARPANET. It was
also used to provide a permanent home for IPv4 address to name also used to provide a permanent home for IPv4 address to name
mappings ("reverse mappings") which were previously also handled mappings ("reverse mappings") which were previously also handled
using the Host Table mechanism. The Internet Architecture Board using the Host Table mechanism. The Internet Architecture Board
(IAB), in cooperation with the Internet Corporation for Assigned (IAB), in cooperation with the Internet Corporation for Assigned
Names and Numbers (ICANN), is currently responsible for managing the Names and Numbers (ICANN), is currently responsible for managing the
Top Level Domain (TLD) name "arpa". This arrangement is documented Top Level Domain (TLD) name "arpa". This arrangement is documented
in Appendix A. [of RFC 3172] This domain name provides the root of in Appendix A of RFC 3172. This domain name provides the root of the
the name hierarchy of the reverse mapping of IP addresses to domain name hierarchy of the reverse mapping of IP addresses to domain
names. More generally, this domain name undertakes a role as a names. More generally, this domain name undertakes a role as a
limited use domain for Internet infrastructure applications, by limited use domain for Internet infrastructure applications, by
providing a name root for the mapping of particular protocol values providing a name root for the mapping of particular protocol values
to names of service entities. This domain name provides a name root to names of service entities. This domain name provides a name root
for the mapping of protocol values into lookup keys to retrieve for the mapping of protocol values into lookup keys to retrieve
operationally critical protocol infrastructure data records or operationally critical protocol infrastructure data records or
objects for the Internet. objects for the Internet.
The IAB may add other infrastructure uses to the "arpa" domain in the The IAB may add other infrastructure uses to the "arpa" domain in the
future. Any such additions or changes will be in accordance with the future. Any such additions or changes will be in accordance with the
skipping to change at line 278 skipping to change at page 6, line 33
to locate the servers of each of the parent names of a more deeply to locate the servers of each of the parent names of a more deeply
nested infrastructure name. The maximal lookup set for ARPA is a nested infrastructure name. The maximal lookup set for ARPA is a
lookup of the name servers for the "arpa" domain from a root server, lookup of the name servers for the "arpa" domain from a root server,
and the query agent is then provided with a list of authoritative and the query agent is then provided with a list of authoritative
"arpa" name servers. "arpa" name servers.
The efficient and correct operation of the "arpa" domain is The efficient and correct operation of the "arpa" domain is
considered to be sufficiently critical that the operational considered to be sufficiently critical that the operational
requirements for the root servers apply to the operational requirements for the root servers apply to the operational
requirements of the "arpa" servers. All operational requirements requirements of the "arpa" servers. All operational requirements
noted in RFC 2870 as they apply to the operational requirements of noted in RFC 2870, as they apply to the operational requirements of
the root servers shall apply to the operation of the "arpa" servers. the root servers, shall apply to the operation of the "arpa" servers.
Any revision to RFC 2870 in relation to the operation of the root Any revision to RFC 2870 in relation to the operation of the root
servers shall also apply to the operation of the "arpa" servers. servers shall also apply to the operation of the "arpa" servers.
Many of the servers that are authoritative for the root zone (or the Many of the servers that are authoritative for the root zone (or the
"." zone) also currently serve as authoritative for the "arpa" zone. "." zone) also currently serve as authoritative for the "arpa" zone.
As noted in RFC 2870, this arrangement is likely to change in the As noted in RFC 2870, this arrangement is likely to change in the
future. future.
3.7. Summary: ENUM use of .ARPA 3.7. Summary: ENUM use of .ARPA
The ARPA domain is the preferred TLD for infrastructure and parameter The ARPA domain is the preferred TLD for infrastructure and parameter
use. The ENUM structure should be placed in a single domain subtree use. The ENUM structure should be placed in a single domain subtree
(see separate contribution, COM 2-11), and is expected to evolve into (see separate contribution, COM 2-11), and is expected to evolve into
important Internet infrastructure, and hence should be placed there. important Internet infrastructure, and hence should be placed there.
This decision is facilitated by the MOU between ICANN and IETF and This decision is facilitated by the MOU between ICANN and IETF and
the instructions from the US Government to ICANN, which provide for the instructions from the US Government to ICANN, which provide for
IAB supervision of that domain. Despite some confusion with the name IAB supervision of that domain. Despite some confusion with the name
of a US Department of Defence agency, DARPA, these uses are of a US Department of Defense agency, DARPA, these uses are
consistent with all of the historical uses of the ARPA domain, which consistent with all of the historical uses of the ARPA domain, which
have been for infrastructure purposes (initially when the have been for infrastructure purposes (initially when the
hierarchical DNS was created to replace the old flat namespace of hierarchical DNS was created to replace the old flat namespace of
ARPANET): the domain was never used for any internal or specific ARPANET): the domain was never used for any internal or specific
DARPA purpose. Recognizing the potential difficulties with multiple DARPA purpose. Recognizing the potential difficulties with multiple
infrastructure domains, the Internet Architecture Board concluded in infrastructure domains, the Internet Architecture Board concluded in
May 2000 that all new infrastructure information was to be stored in May 2000 that all new infrastructure information was to be stored in
the ARPA domain and existing infrastructure subtrees migrated there the ARPA domain and existing infrastructure subtrees migrated there
as feasible. http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt as feasible. http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt
provides additional context for these decisions. provides additional context for these decisions.
skipping to change at line 322 skipping to change at page 7, line 28
4.1. Introduction 4.1. Introduction
This contribution is one of a series provided by the IETF to SG2 to This contribution is one of a series provided by the IETF to SG2 to
provide background information about the IETF's ENUM Working Group provide background information about the IETF's ENUM Working Group
deliberations and decisions. This particular contribution addresses deliberations and decisions. This particular contribution addresses
the IETF's selection of an operator for the E164.ARPA domain. the IETF's selection of an operator for the E164.ARPA domain.
4.2. Name server operator requirements 4.2. Name server operator requirements
RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt?number=2780 ) describes RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the
the requirements for operating DNS root servers. Important DNS-based requirements for operating DNS root servers. Important DNS-based
infrastructure services require that their servers be operated with infrastructure services require that their servers be operated with
the same level of attention to reliability and security that the root the same level of attention to reliability and security that the root
servers require. In addition, for an infrastructure service such as servers require. In addition, for an infrastructure service such as
E164.ARPA some additional requirements were felt by the IAB to be E164.ARPA some additional requirements were felt by the IAB to be
important. Organizations that operate core services such as important. Organizations that operate core services such as IN-
IN-ADDR.ARPA and E164.ARPA must have a history of reliable operation ADDR.ARPA and E164.ARPA must have a history of reliable operation of
of DNS servers and be highly respected and known for both their DNS servers and be highly respected and known for both their relevant
relevant technical skills and their fairness and impartiality. In technical skills and their fairness and impartiality. In addition,
addition, the IAB felt that the organization that operates such the IAB felt that the organization that operates such infrastructure
infrastructure domains must be a non-profit and public-service domains must be a non-profit and public-service-oriented one to
-oriented one to remove any incentive for exploitative behavior based remove any incentive for exploitative behavior based on profit
on profit motives that depend on, e.g., the number of records in the motives that depend on, e.g., the number of records in the database
database even if some reasonable registration fee is charged to even if some reasonable registration fee is charged to recover costs.
recover costs. The IAB also felt that they wanted an organization The IAB also felt that they wanted an organization with good (and
with good (and extensive) experience working with governments when extensive) experience working with governments when necessary and one
necessary and one with experience working with the IAB and the IETF with experience working with the IAB and the IETF more generally.
more generally.
4.3. Evaluating possible operators 4.3. Evaluating possible operators
The IAB researched various options for operators and came to the The IAB researched various options for operators and came to the
conclusion that the regional IP address registries (RIRs) met all of conclusion that the regional IP address registries (RIRs) met all of
the criteria. They all had extensive experience providing and the criteria. They all had extensive experience providing and
supporting infrastructure services reliably and securely and all supporting infrastructure services reliably and securely and all
three of them had a long history of working with the IETF. three of them had a long history of working with the IETF.
4.4. Selecting a particular operator 4.4. Selecting a particular operator
Given that all of the RIRs would have met the criteria, the selection Given that all of the RIRs would have met the criteria, the selection
of a particular RIR required looking at other factors. The IAB of a particular RIR required looking at other factors. The IAB
concluded that RIPE NCC would be the best operator for E164.ARPA, concluded that RIPE NCC would be the best operator for E164.ARPA,
based largely on their somewhat greater experience in running DNS based largely on their somewhat greater experience in running DNS
servers and on their location in a neutral legal jurisdiction. servers and on their location in a neutral legal jurisdiction.
4.5. Country administration of cc subdomains 4.5. Country administration of cc subdomains
Of course, once a subdomain associated with a country code is Of course, once a subdomain associated with a country code is
assigned for registration and operations to an assigned for registration and operations to an appropriately-
appropriately-designated entity for the associated country or designated entity for the associated country or numbering plan,
numbering plan, administration of that subdomain is entirely a administration of that subdomain is entirely a National Matter, with
National Matter, with no involvement anticipated from the IAB/IETF, no involvement anticipated from the IAB/IETF, the E164.ARPA registry,
the E164.ARPA registry, or from the ITU. or from the ITU.
5. Procedures to be followed by RIPE NCC 5. Procedures to be followed by RIPE NCC
The IAB and the RIPE NCC have agreed on procedures for the latter to The IAB and the RIPE NCC have agreed on procedures for the latter to
follow in making ENUM registrations at the country code level. Those follow in making ENUM registrations at the country code level. Those
instructions are expected to evolve as experience is accumulated. instructions are expected to evolve as experience is accumulated.
Current versions will be posted on the IAB and/or RIPE NCC web sites. Current versions will be posted on the IAB and/or RIPE NCC web sites.
6. References 6. References
6.1. Normative references 6.1. Normative references
None. This document is intended to be self-contained and purely None. This document is intended to be self-contained and purely
informational. informational.
6.2. Informative and explanatory references. 6.2. Informative and explanatory references.
RFC 2860. Carpenter, B., F. Baker, M. Roberts. "Memorandum of [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Internet Assigned Understanding Concerning the Technical Work of the
Numbers Authority". June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
RFC 2870. Bush, R., D. Karrenberg, M. Kosters, R. Plzak. "Root Name [RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
Server Operational Requirements". June 2000. Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.
RFC 2916. Faltstrom, P. "E.164 number and DNS", September 2000. [RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
RFC 3172. IAB, G. Huston, editor, "Management Guidelines & [RFC 3172] Huston, G., Ed., "Management Guidelines & Operational
Operational Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ('arpa')". September 2001. Domain ('arpa')", BCP 52, RFC 3172, September 2001.
7. Security Considerations 7. Security Considerations
This document provides information only and raises no new security This document provides information only and raises no new security
issues. The security issues associated with the underlying protocols issues. The security issues associated with the underlying protocols
are described in RFC 2916. are described in RFC 2916.
8. IANA Considerations 8. IANA Considerations
There are no IANA considerations regarding this document. Sections 3 There are no IANA considerations regarding this document. Sections 3
and 4 contain a record of actions already performed by IANA and and 4 contain a record of actions already performed by IANA and
partial explanations for them. partial explanations for them.
9. Authors' Addresses 9. Authors' Addresses
Internet Architecture Board Internet Architecture Board EMail: iab@iab.org
EMail: iab@iab.org
Membership at time this document was completed: Membership at time this document was completed:
Harald Alvestrand Harald Alvestrand
Ran Atkinson Ran Atkinson
Rob Austein Rob Austein
Fred Baker Fred Baker
Steve Bellovin Steve Bellovin
Brian Carpenter Brian Carpenter
Jon Crowcroft Jon Crowcroft
Leslie Daigle Leslie Daigle
Steve Deering Steve Deering
Sally Floyd Sally Floyd
Geoff Huston Geoff Huston
John Klensin John Klensin
Henning Schulzrinne Henning Schulzrinne
Scott Bradner Scott Bradner
sob@harvard.edu EMail: sob@harvard.edu
Patrik Faltstrom Patrik Faltstrom
paf@cisco.com EMail: paf@cisco.com
This draft was created in January 2002 10. Full Copyright Statement
It expires in June 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 31 change blocks. 
112 lines changed or deleted 97 lines changed or added

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