draft-ietf-dnsop-terminology-bis-12.txt   draft-ietf-dnsop-terminology-bis-13.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft ICANN Internet-Draft ICANN
Obsoletes: 7719 (if approved) A. Sullivan Obsoletes: 7719 (if approved) A. Sullivan
Updates: 2308 (if approved) Updates: 2308 (if approved)
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: February 14, 2019 JPRS Expires: February 21, 2019 JPRS
August 13, 2018 August 20, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-12 draft-ietf-dnsop-terminology-bis-13
Abstract Abstract
The domain name system (DNS) is defined in literally dozens of The domain name system (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes of DNS protocols, and by operators of DNS systems, has sometimes
changed in the decades since the DNS was first defined. This changed in the decades since the DNS was first defined. This
document gives current definitions for many of the terms used in the document gives current definitions for many of the terms used in the
DNS in a single document. DNS in a single document.
This document will be the successor to RFC 7719, and thus will This document obsoletes RFC 7719 and updates RFC 2308.
obsolete RFC 7719. It will also update RFC 2308.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 February 14, 2019. This Internet-Draft will expire on February 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13
6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15
7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 27
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Definitions Updated by this Document . . . . . . . . 41 Appendix A. Definitions Updated by this Document . . . . . . . . 41
Appendix B. Definitions First Defined in this Document . . . . . 41 Appendix B. Definitions First Defined in this Document . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
skipping to change at page 3, line 26 skipping to change at page 3, line 26
quite differently by different DNS experts. Further, some terms that quite differently by different DNS experts. Further, some terms that
are defined in early DNS RFCs now have definitions that are generally are defined in early DNS RFCs now have definitions that are generally
agreed to, but that are different from the original definitions. agreed to, but that are different from the original definitions.
Therefore, this document is a substantial revision to [RFC7719]. Therefore, this document is a substantial revision to [RFC7719].
The terms are organized loosely by topic. Some definitions are for The terms are organized loosely by topic. Some definitions are for
new terms for things that are commonly talked about in the DNS new terms for things that are commonly talked about in the DNS
community but that never had terms defined for them. community but that never had terms defined for them.
Other organizations sometimes define DNS-related terms their own way. Other organizations sometimes define DNS-related terms their own way.
For example, the W3C defines "domain" at For example, the WHATWG defines "domain" at
<https://url.spec.whatwg.org/>. The Root Server System Advisory <https://url.spec.whatwg.org/>. The Root Server System Advisory
Committee (RSSAC) has a good lexicon [RSSAC026]. Committee (RSSAC) has a good lexicon [RSSAC026].
Note that there is no single consistent definition of "the DNS". It Note that there is no single consistent definition of "the DNS". It
can be considered to be some combination of the following: a commonly can be considered to be some combination of the following: a commonly
used naming scheme for objects on the Internet; a distributed used naming scheme for objects on the Internet; a distributed
database representing the names and certain properties of these database representing the names and certain properties of these
objects; an architecture providing distributed maintenance, objects; an architecture providing distributed maintenance,
resilience, and loose coherency for this database; and a simple resilience, and loose coherency for this database; and a simple
query-response protocol (as mentioned below) implementing this query-response protocol (as mentioned below) implementing this
architecture. Section 2 defines "global DNS" and "private DNS" as a architecture. Section 2 defines "global DNS" and "private DNS" as a
way to deal with these differing definitions. way to deal with these differing definitions.
Capitalization in DNS terms is often inconsistent among RFCs and Capitalization in DNS terms is often inconsistent among RFCs and
various DNS practitioners. The capitalization used in this document various DNS practitioners. The capitalization used in this document
is a best guess at current practices, and is not meant to indicate is a best guess at current practices, and is not meant to indicate
that other capitalization styles are wrong or archaic. In some that other capitalization styles are wrong or archaic. In some
cases, multiple styles of capitalization are used for the same term cases, multiple styles of capitalization are used for the same term
due to quoting from different RFCs. due to quoting from different RFCs.
Readers should note that the terms in this document are grouped by
topic. Someone who is not already familiar with the DNS can probably
not learn about the DNS from scratch by reading this document from
front to back. Instead, skipping around may be the only way to get
enough context to understand some of the definitions. This document
has an index that might be useful for readers who are attempting to
learn the DNS by reading this document.
2. Names 2. Names
Naming system: A naming system associates names with data. Naming Naming system: A naming system associates names with data. Naming
systems have many significant facets that help differentiate them. systems have many significant facets that help differentiate them.
Some commonly-identified facets include: Some commonly-identified facets include:
* Composition of names * Composition of names
* Format of names * Format of names
skipping to change at page 7, line 19 skipping to change at page 7, line 29
above quote says "a portion of the DNS namespace", it would be above quote says "a portion of the DNS namespace", it would be
clearer to say "a portion of the domain name space" The names in clearer to say "a portion of the domain name space" The names in
mDNS are not intended to be looked up in the DNS. mDNS are not intended to be looked up in the DNS.
Locally served DNS zone: A locally served DNS zone is a special case Locally served DNS zone: A locally served DNS zone is a special case
of private DNS. Names are resolved using the DNS protocol in a of private DNS. Names are resolved using the DNS protocol in a
local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that
are locally served zones. Resolution of names through locally are locally served zones. Resolution of names through locally
served zones may result in ambiguous results. For example, the served zones may result in ambiguous results. For example, the
same name may resolve to different results in different locally same name may resolve to different results in different locally
served DNS zone contexts. The context through which a locally served DNS zone contexts. The context for a locally served DNS
served zone may be explicit, for example, as defined in [RFC6303], zone may be explicit, for example, as defined in [RFC6303], or
or implicit, as defined by local DNS administration and not known implicit, as defined by local DNS administration and not known to
to the resolution client. the resolution client.
Fully qualified domain name (FQDN): This is often just a clear way Fully qualified domain name (FQDN): This is often just a clear way
of saying the same thing as "domain name of a node", as outlined of saying the same thing as "domain name of a node", as outlined
above. However, the term is ambiguous. Strictly speaking, a above. However, the term is ambiguous. Strictly speaking, a
fully qualified domain name would include every label, including fully qualified domain name would include every label, including
the zero-length label of the root: such a name would be written the zero-length label of the root: such a name would be written
"www.example.net." (note the terminating dot). But because every "www.example.net." (note the terminating dot). But because every
name eventually shares the common root, names are often written name eventually shares the common root, names are often written
relative to the root (such as "www.example.net") and are still relative to the root (such as "www.example.net") and are still
called "fully qualified". This term first appeared in [RFC0819]. called "fully qualified". This term first appeared in [RFC0819].
skipping to change at page 11, line 38 skipping to change at page 11, line 49
* QNAME (effective): A name actually resolved, which is either * QNAME (effective): A name actually resolved, which is either
the name originally queried, or a name received in a CNAME the name originally queried, or a name received in a CNAME
chain response. chain response.
* QNAME (final): The name actually resolved, which is either the * QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain name actually queried or else the last name in a CNAME chain
response. response.
Note that, because the definition in [RFC2308] is actually for a Note that, because the definition in [RFC2308] is actually for a
different concept than what was in [RFC1034], it would have be different concept than what was in [RFC1034], it would have been
better if [RFC2308] had used a different name for that concept. better if [RFC2308] had used a different name for that concept.
In general use today, QNAME almost always means what is defined In general use today, QNAME almost always means what is defined
above as "QNAME (original)". above as "QNAME (original)".
Referrals: A type of response in which a server, signaling that it Referrals: A type of response in which a server, signaling that it
is not (completely) authoritative for an answer, provides the is not (completely) authoritative for an answer, provides the
querying resolver with an alternative place to send its query. querying resolver with an alternative place to send its query.
Referrals can be partial. Referrals can be partial.
A referral arises when a server is not performing recursive A referral arises when a server is not performing recursive
skipping to change at page 13, line 29 skipping to change at page 13, line 40
Presentation format: The text format used in master files. This Presentation format: The text format used in master files. This
format is shown but not formally defined in [RFC1034] and format is shown but not formally defined in [RFC1034] and
[RFC1035]. The term "presentation format" first appears in [RFC1035]. The term "presentation format" first appears in
[RFC4034]. [RFC4034].
EDNS: The extension mechanisms for DNS, defined in [RFC6891]. EDNS: The extension mechanisms for DNS, defined in [RFC6891].
Sometimes called "EDNS0" or "EDNS(0)" to indicate the version Sometimes called "EDNS0" or "EDNS(0)" to indicate the version
number. EDNS allows DNS clients and servers to specify message number. EDNS allows DNS clients and servers to specify message
sizes larger than the original 512 octet limit, to expand the sizes larger than the original 512 octet limit, to expand the
response code space, and potentially to carry additional options response code space, and to carry additional options that affect
that affect the handling of a DNS query. the handling of a DNS query.
OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to
contain control information pertaining to the question-and-answer contain control information pertaining to the question-and-answer
sequence of a specific transaction. (Definition from [RFC6891], sequence of a specific transaction. (Definition from [RFC6891],
Section 6.1.1) It is used by EDNS. Section 6.1.1) It is used by EDNS.
Owner: The domain name where a RR is found ([RFC1034], Section 3.6). Owner: The domain name where a RR is found ([RFC1034], Section 3.6).
Often appears in the term "owner name". Often appears in the term "owner name".
SOA field names: DNS documents, including the definitions here, SOA field names: DNS documents, including the definitions here,
skipping to change at page 27, line 5 skipping to change at page 27, line 14
9. Registration Model 9. Registration Model
Registry: The administrative operation of a zone that allows Registry: The administrative operation of a zone that allows
registration of names within that zone. People often use this registration of names within that zone. People often use this
term to refer only to those organizations that perform term to refer only to those organizations that perform
registration in large delegation-centric zones (such as TLDs); but registration in large delegation-centric zones (such as TLDs); but
formally, whoever decides what data goes into a zone is the formally, whoever decides what data goes into a zone is the
registry for that zone. This definition of "registry" is from a registry for that zone. This definition of "registry" is from a
DNS point of view; for some zones, the policies that determine DNS point of view; for some zones, the policies that determine
what can go in the zone are decided by superior zones and not the what can go in the zone are decided by zones that are
registry operator. superordinate and not the registry operator.
Registrant: An individual or organization on whose behalf a name in Registrant: An individual or organization on whose behalf a name in
a zone is registered by the registry. In many zones, the registry a zone is registered by the registry. In many zones, the registry
and the registrant may be the same entity, but in TLDs they often and the registrant may be the same entity, but in TLDs they often
are not. are not.
Registrar: A service provider that acts as a go-between for Registrar: A service provider that acts as a go-between for
registrants and registries. Not all registrations require a registrants and registries. Not all registrations require a
registrar, though it is common to have registrars involved in registrar, though it is common to have registrars involved in
registrations in TLDs. registrations in TLDs.
skipping to change at page 41, line 41 skipping to change at page 41, line 41
Lexicon", 2017, Lexicon", 2017,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/
rssac-026-14mar17-en.pdf>. rssac-026-14mar17-en.pdf>.
Appendix A. Definitions Updated by this Document Appendix A. Definitions Updated by this Document
The following definitions from RFCs are updated by this document: The following definitions from RFCs are updated by this document:
o Forwarder in [RFC2308] o Forwarder in [RFC2308]
o QNAME in [RFC2308]
o Secure Entry Point (SEP) in [RFC3757]; note, however, that this o Secure Entry Point (SEP) in [RFC3757]; note, however, that this
RFC is already obsolete RFC is already obsolete
Appendix B. Definitions First Defined in this Document Appendix B. Definitions First Defined in this Document
The following definitions are first defined in this document: The following definitions are first defined in this document:
o "Alias" in Section 2 o "Alias" in Section 2
o "Apex" in Section 7 o "Apex" in Section 7
skipping to change at page 44, line 8 skipping to change at page 44, line 8
o "Validation" in Section 10 o "Validation" in Section 10
o "View" in Section 6 o "View" in Section 6
o "Zone transfer" in Section 6 o "Zone transfer" in Section 6
Index Index
A A
Address records 14 Address records 15
Alias 8 Alias 9
Anycast 21 Anycast 21
Apex 22 Apex 22
Asterisk label 26 Asterisk label 26
Authoritative data 22 Authoritative data 22
Authoritative server 17 Authoritative server 18
Authoritative-only server 18 Authoritative-only server 18
arpa: Address and Routing Parameter Area Domain 25 arpa: Address and Routing Parameter Area Domain 25
C C
CNAME 9 CNAME 9
Canonical name 8 Canonical name 9
Child 21 Child 21
Class independent 14 Class independent 14
Closest encloser 26 Closest encloser 26
Closest provable encloser 26 Closest provable encloser 26
Combined signing key (CSK) 31 Combined signing key (CSK) 31
D D
DNS operator 27 DNS operator 27
DNSSEC Policy (DP) 32 DNSSEC Policy (DP) 32
DNSSEC Practice Statement (DPS) 32 DNSSEC Practice Statement (DPS) 32
DNSSEC-aware and DNSSEC-unaware 28 DNSSEC-aware and DNSSEC-unaware 28
Delegation 22 Delegation 22
Delegation-centric zone 24 Delegation-centric zone 25
Domain name 4 Domain name 4
E E
EDNS 13 EDNS 13
EPP 27 EPP 27
Empty non-terminals (ENT) 24 Empty non-terminals (ENT) 24
F F
FORMERR 9 FORMERR 9
Fast flux DNS 25 Fast flux DNS 25
Forward lookup 25 Forward lookup 25
Forwarder 19 Forwarder 19
Forwarding 19 Forwarding 19
Full resolver 17 Full resolver 17
Full-service resolver 17 Full-service resolver 17
Fully qualified domain name (FQDN) 7 Fully qualified domain name (FQDN) 7
G G
Global DNS 4 Global DNS 5
Glue records 23 Glue records 23
H H
Hardware security module (HSM) 32 Hardware security module (HSM) 33
Hidden master 19 Hidden master 19
Host name 7 Host name 8
I I
IDN 8 IDN 8
In-bailiwick 23 In-bailiwick 23
Insecure delegation 30 Insecure delegation 30
Instance 21 Instance 21
Iterative mode 15 Iterative mode 16
Iterative resolution 17 Iterative resolution 17
K K
Key signing key (KSK) 31 Key signing key (KSK) 31
L L
Label 4 Label 5
Lame delegation 23 Lame delegation 23
Locally served DNS zone 7 Locally served DNS zone 7
M M
Master file 13 Master file 13
Master server 18 Master server 18
Multicast DNS 6 Multicast DNS 7
N N
NODATA 9 NODATA 10
NOERROR 9 NOERROR 9
NOTIMP 9 NOTIMP 9
NS 17 NS 18
NSEC 29 NSEC 29
NSEC3 29 NSEC3 29
NXDOMAIN 9 NXDOMAIN 9
Naming system 3 Naming system 4
Negative caching 17 Negative caching 17
Negative response 10 Negative response 10
Next closer name 26 Next closer name 26
Non-recursive query 16 Non-recursive query 17
O O
OPT 13 OPT 13
Occluded name 25 Occluded name 25
Open resolver 20 Open resolver 20
Opt-out 30 Opt-out 30
Origin 21 Origin 21
Out-of-bailiwick 23 Out-of-bailiwick 23
Owner 13 Owner 13
P P
Parent 21 Parent 21
Passive DNS 20 Passive DNS 21
Policy-implementing resolver 20 Policy-implementing resolver 20
Presentation format 13 Presentation format 13
Primary master 19 Primary master 19
Primary server 18 Primary server 18
Priming 17 Priming 17
Privacy-enabling DNS server 21 Privacy-enabling DNS server 21
Private DNS 6 Private DNS 6
Public suffix 27 Public suffix 27
Q Q
QNAME 10 QNAME 10
R R
RDAP 27 RDAP 27
REFUSED 9 REFUSED 9
RR 12 RR 13
RRset 12 RRset 13
Recursive mode 16 Recursive mode 16
Recursive query 16 Recursive query 16
Recursive resolver 16 Recursive resolver 16
Referrals 11 Referrals 12
Registrant 27 Registrant 27
Registrar 27 Registrar 27
Registry 26 Registry 27
Resolver 15 Resolver 15
Reverse DNS, reverse lookup 25 Reverse DNS, reverse lookup 25
Root hints 17 Root hints 17
Root zone 24 Root zone 24
S S
SERVFAIL 9 SERVFAIL 9
SOA 13 SOA 13
SOA field names 13 SOA field names 13
Secondary server 18 Secondary server 18
Secure Entry Point (SEP) 32 Secure Entry Point (SEP) 32
Service name 25 Service name 25
Signed zone 28 Signed zone 29
Signing software 33 Signing software 33
Slave server 18 Slave server 18
Source of Synthesis 26 Source of Synthesis 26
Split DNS 20 Split DNS 20
Split-horizon DNS 20 Split-horizon DNS 20
Stealth server 19 Stealth server 19
Stub resolver 15 Stub resolver 15
Subdomain 8 Subdomain 8
Subordinate 28 Subordinate 28
Superordinate 28 Superordinate 28
T T
TLD 8 TLD 8
TTL 13 TTL 14
Trust anchor 32 Trust anchor 32
U U
Unsigned zone 29 Unsigned zone 29
V V
Validating resolver 31 Validating resolver 31
Validation 30 Validation 30
View 20 View 20
W W
WHOIS 27 WHOIS 27
Wildcard 25 Wildcard 26
Wildcard domain name 26 Wildcard domain name 26
Z Z
Zone 21 Zone 21
Zone cut 22 Zone cut 22
Zone enumeration 30 Zone enumeration 30
Zone signing key (ZSK) 31 Zone signing key (ZSK) 31
Zone transfer 18 Zone transfer 18
Acknowledgements Acknowledgements
skipping to change at page 47, line 48 skipping to change at page 47, line 48
acknowledgements may be added as this draft is worked on. acknowledgements may be added as this draft is worked on.
The authors gratefully acknowledge all of the authors of DNS-related The authors gratefully acknowledge all of the authors of DNS-related
RFCs that proceed this one. Comments from Tony Finch, Stephane RFCs that proceed this one. Comments from Tony Finch, Stephane
Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
John Klensin, David Black, and many others in the DNSOP Working Group John Klensin, David Black, and many others in the DNSOP Working Group
helped shape RFC 7719. helped shape RFC 7719.
Additional people contributed to this document, including: Bob Most of the major changes between RFC 7719 and this document came
Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin from active discussion on the DNSOP WG. Specific people who
Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL contributed material to this document include: Bob Harold, Dick
APPEAR HERE AS FOLKS CONTRIBUTE]]. Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin Hoffmann,
Paul Vixie, Peter Koch, Duane Wessels, Allison Mankin, Giovane Moura,
Roni Even, Dan Romascanu, and Vladmir Cunat.
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
Andrew Sullivan Andrew Sullivan
 End of changes. 36 change blocks. 
47 lines changed or deleted 58 lines changed or added

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