draft-ietf-dnsop-terminology-bis-04.txt   draft-ietf-dnsop-terminology-bis-05.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
Intended status: Best Current Practice Dyn Intended status: Best Current Practice Dyn
Expires: July 31, 2017 K. Fujiwara Expires: September 14, 2017 K. Fujiwara
JPRS JPRS
January 27, 2017 March 13, 2017
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-04 draft-ietf-dnsop-terminology-bis-05
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 8 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 9 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 10
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 11 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 12
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 20 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 21
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 21 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 22
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 25 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Definitions Updated by this Document . . . . . . . . 33 Appendix A. Definitions Updated by this Document . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (See whose messages in both directions have the same format. (See
Section 2 for a fuller definition.) The protocol and message format Section 2 for a fuller definition.) The protocol and message format
are defined in [RFC1034] and [RFC1035]. These RFCs defined some are defined in [RFC1034] and [RFC1035]. These RFCs defined some
terms, but later documents defined others. Some of the terms from terms, but later documents defined others. Some of the terms from
[RFC1034] and [RFC1035] now have somewhat different meanings than [RFC1034] and [RFC1035] now have somewhat different meanings than
they did in 1987. they did in 1987.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
* Format of names * Format of names
* Administration of names * Administration of names
* Types of data that can be associated with names * Types of data that can be associated with names
* Types of metadata for names * Types of metadata for names
* Protocol for getting data from a name * Protocol for getting data from a name
* Context for resolving a name
Note that this list is a small subset of facets that people have Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming agree on a good set of facets that can be used to compare naming
systems. For example, other facets might include "protocol to systems. For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data update data in a name", "privacy of names", and "privacy of data
associated with names", but those do not not have a clear associated with names", but those do not not have a clear
definitions as the ones listed above. The list here is chosen definitions as the ones listed above. The list here is chosen
because it helps describe the DNS and naming systems similar to because it helps describe the DNS and naming systems similar to
the DNS. the DNS.
skipping to change at page 5, line 5 skipping to change at page 5, line 7
Global DNS: Using the short set of facets listed in "Naming system", Global DNS: Using the short set of facets listed in "Naming system",
the global DNS can be defined as follows. Most of the rules here the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
inclusive. In a fully-qualified domain name, the first label is 0 inclusive. In a fully-qualified domain name, the first label is 0
octets long; it is the only label whose length may be 0 octets, octets long; it is the only label whose length may be 0 octets,
and it is called the "root" or "root label". A domain name in the and it is called the "root" or "root label". A domain name in the
global DNS has a maximum total length of 255 octets; the root global DNS has a maximum total length of 255 octets in the wire
represents one octet for this calculation. format; the root represents one octet for this calculation.
Format of names -- Names in the global DNS are domain names. Format of names -- Names in the global DNS are domain names.
There are three formats: wire format, presentation format, and There are three formats: wire format, presentation format, and
common display. common display.
The basic wire format for names in the global DNS is a list of The basic wire format for names in the global DNS is a list of
labels with the root label last. Each label is preceded by a labels with the root label last. Each label is preceded by a
length octet. [RFC1035] also defines a compression scheme that length octet. [RFC1035] also defines a compression scheme that
modifies this format. modifies this format.
skipping to change at page 6, line 19 skipping to change at page 6, line 22
DNS appears as a set of resource records (see the definition of DNS appears as a set of resource records (see the definition of
"RRset" in Section 4). Some names do not themselves have data "RRset" in Section 4). Some names do not themselves have data
associated with them in the DNS, but "appear" in the DNS anyway associated with them in the DNS, but "appear" in the DNS anyway
because they form part of a longer name that does have data because they form part of a longer name that does have data
associated with it (see the defintion of "empty non-terminals" in associated with it (see the defintion of "empty non-terminals" in
Section 6). Section 6).
Protocol for getting data from a name -- The protocol described in Protocol for getting data from a name -- The protocol described in
[RFC1035]. [RFC1035].
Context for resolving a name -- The global DNS root zone
distributed by PTI.
Private DNS: Names that use the protocol described in [RFC1035] but Private DNS: Names that use the protocol described in [RFC1035] but
that do not rely on the global DNS root zone, or names that are that do not rely on the global DNS root zone, or names that are
otherwise not generally available on the Internet but are using otherwise not generally available on the Internet but are using
the protocol described in [RFC1035]. A system can use both the the protocol described in [RFC1035]. A system can use both the
global DNS and one or more private DNS systems; for example, see global DNS and one or more private DNS systems; for example, see
"Split DNS" in Section 7. "Split DNS" in Section 7.
Note that domain names that do not appear in the DNS, and that are Note that domain names that do not appear in the DNS, and that are
intended never to be looked up using the DNS protocol, are not intended never to be looked up using the DNS protocol, are not
part of the global DNS or a private DNS even though they are part of the global DNS or a private DNS even though they are
domain names. domain names.
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
local context. [RFC6303] defines subdomains of IN-ADDR.ARPA tha
are locally served zones. Resolution of names through locally
served zones may result in ambiguous results. For example, the
same name may resolve to different results in different locally
served DNS zone contexts. The context through which a locally
served zone may be explicit, for example, as defined in [RFC6303],
or implicit, as defined by local DNS administration and not known
to 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 final, zero-length label of the root: such a name would be the final, zero-length label of the root: such a name would be
written "www.example.net." (note the terminating dot). But written "www.example.net." (note the terminating dot). But
because every name eventually shares the common root, names are because every name eventually shares the common root, names are
often written relative to the root (such as "www.example.net") and often written relative to the root (such as "www.example.net") and
are still called "fully qualified". This term first appeared in are still called "fully qualified". This term first appeared in
[RFC0819]. In this document, names are often written relative to [RFC0819]. In this document, names are often written relative to
skipping to change at page 8, line 51 skipping to change at page 9, line 20
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is its first 12 octets. Many of the The header of a DNS message is its first 12 octets. Many of the
fields and flags in the header diagram in Sections 4.1.1 through fields and flags in the header diagram in Sections 4.1.1 through
4.1.3 of [RFC1035] are referred to by their names in that diagram. 4.1.3 of [RFC1035] are referred to by their names in that diagram.
For example, the response codes are called "RCODEs", the data for a For example, the response codes are called "RCODEs", the data for a
record is called the "RDATA", and the authoritative answer bit is record is called the "RDATA", and the authoritative answer bit is
often called "the AA flag" or "the AA bit". often called "the AA flag" or "the AA bit".
QNAME The most commonly-used definitions are that the QNAME is a
field in the Question section of a query. "A standard query
specifies a target domain name (QNAME), query type (QTYPE), and
query class (QCLASS) and asks for RRs which match." (Quoted from
[RFC1034], Section 3.7.1.)
[RFC2308], however, has an alternate definition that puts the
QNAME in the answer (or series of answers) instead of the query.
It defines QNAME as: "...the name in the query section of an
answer, or where this resolves to a CNAME, or CNAME chain, the
data field of the last CNAME. The last CNAME in this sense is
that which contains a value which does not resolve to another
CNAME."
Some of response codes that are defined in [RFC1035] have acquired Some of response codes that are defined in [RFC1035] have acquired
their own shorthand names. Some common response code names that their own shorthand names. Some common response code names that
appear without reference to the numeric value are "FORMERR", appear without reference to the numeric value are "FORMERR",
"SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
as "Name Error"). All of the RCODEs are listed at as "Name Error"). All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps. uses mixed-case capitalization, while most documents use all-caps.
NODATA: "A pseudo RCODE which indicates that the name is valid for NODATA: "A pseudo RCODE which indicates that the name is valid for
the given class, but there are no records of the given type. A the given class, but there are no records of the given type. A
skipping to change at page 12, line 43 skipping to change at page 13, line 26
Full resolver: This term is used in [RFC1035], but it is not defined Full resolver: This term is used in [RFC1035], but it is not defined
there. RFC 1123 defines a "full-service resolver" that may or may there. RFC 1123 defines a "full-service resolver" that may or may
not be what was intended by "full resolver" in [RFC1035]. This not be what was intended by "full resolver" in [RFC1035]. This
term is not properly defined in any RFC. term is not properly defined in any RFC.
Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
term to mean a resolver that acts in recursive mode with a cache term to mean a resolver that acts in recursive mode with a cache
(and meets other requirements). (and meets other requirements).
Recursive resolver: A resolver that acts in recursive mode. In
general, a recursive resolver is expected to cache the answers it
receives (which would make it a full-service resolver), but some
recursive resolvers might not cache.
Priming: The mechanism used by a resolver to determine where to send Priming: The mechanism used by a resolver to determine where to send
queries before there is anything in the resolver's cache. Priming queries before there is anything in the resolver's cache. Priming
is most often done from a configuration setting that contains a is most often done from a configuration setting that contains a
list of authoritative servers for the root zone. list of authoritative servers for the root zone.
Root hints: "Operators who manage a DNS recursive resolver typically Root hints: "Operators who manage a DNS recursive resolver typically
need to configure a 'root hints file'. This file contains the need to configure a 'root hints file'. This file contains the
names and IP addresses of the authoritative name servers for the names and IP addresses of the authoritative name servers for the
root zone, so the software can bootstrap the DNS resolution root zone, so the software can bootstrap the DNS resolution
process. For many pieces of software, this list comes built into process. For many pieces of software, this list comes built into
skipping to change at page 18, line 33 skipping to change at page 19, line 23
inadvertently also include any NS records that appear in the zone, inadvertently also include any NS records that appear in the zone,
even those that might not truly be authoritative because there are even those that might not truly be authoritative because there are
identical NS RRs below the zone cut. This reveals the ambiguity identical NS RRs below the zone cut. This reveals the ambiguity
in the notion of authoritative data, because the parent-side NS in the notion of authoritative data, because the parent-side NS
records authoritatively indicate the delegation, even though they records authoritatively indicate the delegation, even though they
are not themselves authoritative data. are not themselves authoritative data.
Root zone: The zone whose apex is the zero-length label. Also Root zone: The zone whose apex is the zero-length label. Also
sometimes called "the DNS root". sometimes called "the DNS root".
Empty non-terminals: "Domain names that own no resource records but Empty non-terminals (ENT): "Domain names that own no resource
have subdomains that do." (Quoted from [RFC4592], Section 2.2.2.) records but have subdomains that do." (Quoted from [RFC4592],
A typical example is in SRV records: in the name Section 2.2.2.) A typical example is in SRV records: in the name
"_sip._tcp.example.com", it is likely that "_tcp.example.com" has "_sip._tcp.example.com", it is likely that "_tcp.example.com" has
no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
RRset. RRset.
Delegation-centric zone: A zone that consists mostly of delegations Delegation-centric zone: A zone that consists mostly of delegations
to child zones. This term is used in contrast to a zone that to child zones. This term is used in contrast to a zone that
might have some delegations to child zones, but also has many data might have some delegations to child zones, but also has many data
resource records for the zone itself and/or for child zones. The resource records for the zone itself and/or for child zones. The
term is used in [RFC4956] and [RFC5155], but is not defined there. term is used in [RFC4956] and [RFC5155], but is not defined there.
skipping to change at page 23, line 40 skipping to change at page 24, line 34
following: following:
* Checking the validity of DNSSEC signatures * Checking the validity of DNSSEC signatures
* Checking the validity of DNS responses, such as those including * Checking the validity of DNS responses, such as those including
authenticated denial of existence authenticated denial of existence
* Building an authentication chain from a trust anchor to a DNS * Building an authentication chain from a trust anchor to a DNS
response or individual DNS RRsets in a response response or individual DNS RRsets in a response
The first two definitions above consider the only validity of The first two definitions above consider only the validity of
individual DNSSEC components such as the RRSIG validity or NSEC individual DNSSEC components such as the RRSIG validity or NSEC
proof validity. The third definition considers the components of proof validity. The third definition considers the components of
the entire DNSSEC authentication chain, and thus requires the entire DNSSEC authentication chain, and thus requires
"configured knowledge of at least one authenticated DNSKEY or DS "configured knowledge of at least one authenticated DNSKEY or DS
RR" (as described in [RFC4035], Section 5). RR" (as described in [RFC4035], Section 5).
[RFC4033], Section 2, says that a "Validating Security-Aware Stub [RFC4033], Section 2, says that a "Validating Security-Aware Stub
Resolver... performs signature validation" and uses a trust anchor Resolver... performs signature validation" and uses a trust anchor
"as a starting point for building the authentication chain to a "as a starting point for building the authentication chain to a
signed DNS response", and thus uses the first and third signed DNS response", and thus uses the first and third
definitions above. The process of validating an RRSIG RR is definitions above. The process of validating an RRSIG RR is
described in [RFC4035], Section 5.3. described in [RFC4035], Section 5.3.
[RFC5155] refers to validating responses throughout the document, [RFC5155] refers to validating responses throughout the document,
in the context of hashed authenticated denial of existence; this in the context of hashed authenticated denial of existence; this
uses the second definition above. uses the second definition above.
The terms "authentication" and "verification" are used The term "authentication" is used interchangeably with
interchangeably with "validation" in the sense of the third "validation", in the sense of the third definition above.
definition above. [RFC4033], Section 2, describes the chain [RFC4033], Section 2, describes the chain linking trust anchor to
linking trust anchor to DNS data as the "authentication chain". A DNS data as the "authentication chain". A response is considered
response is considered to be authentic if "all RRsets in the to be authentic if "all RRsets in the Answer and Authority
Answer and Authority sections of the response [are considered] to sections of the response [are considered] to be authentic"
be authentic" ([RFC4035]). DNS data or responses deemed to be ([RFC4035]). DNS data or responses deemed to be authentic or
authentic or validated have a security status of "secure" validated have a security status of "secure" ([RFC4035],
([RFC4035], Section 4.3; [RFC4033], Section 5). "Authenticating Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys
both DNS keys and data is a matter of local policy, which may and data is a matter of local policy, which may extend or even
extend or even override the [DNSSEC] protocol extensions" override the [DNSSEC] protocol extensions" ([RFC4033],
([RFC4033], Section 3.1). Section 3.1).
The term "verification", when used, is usually synonym for
"validation".
Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
RRset in a zone."(Quoted from [RFC6781], Section 3.1) RRset in a zone."(Quoted from [RFC6781], Section 3.1)
Zone signing key (ZSK): "DNSSEC keys that can be used to sign all Zone signing key (ZSK): "DNSSEC keys that can be used to sign all
the RRsets in a zone that require signatures, other than the apex the RRsets in a zone that require signatures, other than the apex
DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the
roles KSK and ZSK are not mutually exclusive: a single key can be roles KSK and ZSK are not mutually exclusive: a single key can be
both KSK and ZSK at the same time. Also note that a ZSK is both KSK and ZSK at the same time. Also note that a ZSK is
sometimes used to sign the apex DNSKEY RRset. sometimes used to sign the apex DNSKEY RRset.
skipping to change at page 32, line 29 skipping to change at page 33, line 29
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055, Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011, DOI 10.17487/RFC6055, February 2011,
<http://www.rfc-editor.org/info/rfc6055>. <http://www.rfc-editor.org/info/rfc6055>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <http://www.rfc-editor.org/info/rfc6265>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
 End of changes. 16 change blocks. 
36 lines changed or deleted 78 lines changed or added

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