draft-ietf-dnsext-2929bis-02.txt   draft-ietf-dnsext-2929bis-03.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929 Motorola Laboratories Obsoletes RFC 2929 Motorola Laboratories
Updates RFCs 1183 and 3597 Updates RFCs 1183 and 3597
Domain Name System (DNS) IANA Considerations Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ------------------- ------ ---- ------ ----- -------------------
<draft-ietf-dnsext-2929bis-02.txt> <draft-ietf-dnsext-2929bis-03.txt>
Status of This Document Status of This Document
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.
Distribution of this draft is unlimited. It is intended to become Distribution of this draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
Internet Assigned Number Authority (IANA) parameter assignment Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System considerations are specified for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, RR header (DNS) Classes, RR Types, operation codes, error codes, RR header
bits, and AFSDB subtypes. bits, and AFSDB subtypes.
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. DNS Query/Response Headers..............................3 2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4 2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4 2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5 2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6 3. DNS Resource Records....................................6
3.1 RR TYPE IANA Considerations............................7 3.1 RR TYPE IANA Considerations............................7
3.1.1 DNS TYPE Allocation Policy...........................8 3.1.1 DNS TYPE Allocation Policy...........................8
3.1.2 Expert Review DNS TYPE Expert Review Template........8 3.1.2 Expert Review DNS TYPE Expert Review Template........8
3.1.3 Special Note on the OPT RR...........................9 3.1.3 DNS RRTYPE Expert Guidelines.........................9
3.1.4 The AFSDB RR Subtype Field...........................9 3.1.4 Special Note on the OPT RR..........................10
3.1.5 The AFSDB RR Subtype Field..........................10
3.2 RR CLASS IANA Considerations..........................10 3.2 RR CLASS IANA Considerations..........................10
3.3 RR NAME Considerations................................11 3.3 RR NAME Considerations................................12
4. Security Considerations................................12 4. Security Considerations................................12
Additional IPR Provisions.................................13 Additional IPR Provisions.................................14
Appendix: Changes from RFC 2929...........................14 Appendix: Changes from RFC 2929...........................15
Copyright and Disclaimer..................................15 Copyright.................................................16
Normative References......................................15 Normative References......................................16
Informative References....................................16 Informative References....................................17
Author's Address..........................................18 Author's Address..........................................19
Expiration and File Name..................................18 Expiration and File Name..................................19
Disclaimer................................................19
1. Introduction 1. Introduction
The Domain Name System (DNS) provides replicated distributed secure The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records" hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. DNS data is structured into CLASSes and (RRs) under domain names. DNS data is structured into CLASSes and
zones which can be independently maintained. See [RFC 1034, 1035, zones which can be independently maintained. See [RFC 1034, 1035,
2136, 2181, 4033] familiarity with which is assumed. 2136, 2181, 4033] familiarity with which is assumed.
This document provides, either directly or by reference, the general This document provides, either directly or by reference, the general
skipping to change at page 4, line 7 skipping to change at page 4, line 7
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so The ID field identifies the query and is echoed in the response so
they can be matched. they can be matched.
The QR bit indicates whether the header is for a query or a response. The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However, only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value some DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF implementation. Such meanings may only be assigned by an IETF
Standards Action. Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), The unsigned integer fields query count (QDCOUNT), answer count
authority count (NSCOUNT), and additional information count (ARCOUNT) (ANCOUNT), authority count (NSCOUNT), and additional information
express the number of records in each section for all opcodes except count (ARCOUNT) express the number of records in each section for all
Update [RFC 2136]. These fields have the same structure and data opcodes except Update [RFC 2136]. These fields have the same
type for Update but are instead the counts for the zone (ZOCOUNT), structure and data type for Update but are instead the counts for the
prerequisite (PRCOUNT), update (UPCOUNT), and additional information zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and
(ARCOUNT) sections. additional information (ARCOUNT) sections.
2.1 One Spare Bit? 2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS a zone is acceptable. It is believed that current DNS
implementations ignore this bit. implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action. Assigning a meaning to the Z bit requires an IETF Standards Action.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
6 YXDomain Name Exists when it should not [RFC 2136] 6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136] 7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136] 8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136] 9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136] 10 NotZone Name not contained in zone [RFC 2136]
11 - 15 Available for assignment 11 - 15 Available for assignment
16 BADVERS Bad OPT Version [RFC 2671] 16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845] 16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845] 17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845] 18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RPC 2930] 19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RPF 2930] 20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RPF 2930] 21 BADALG Algorithm not supported [RFC 2930]
22 BADTRUC Bad Truncation [TSIG-SHA]
22 - 3,840 23 - 3,840
0x0016 - 0x0F00 Available for assignment 0x0017 - 0x0F00 Available for assignment
3,841 - 4,095 3,841 - 4,095
0x0F01 - 0x0FFF Private Use 0x0F01 - 0x0FFF Private Use
4,096 - 65,534 4,096 - 65,534
0x1000 - 0xFFFE Available for assignment 0x1000 - 0xFFFE Available for assignment
65,535 65,535
0xFFFF Reserved, can only be allocated by an IETF 0xFFFF Reserved, can only be allocated by an IETF
Standards Action. Standards Action.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
Allocation Policy as specified in section 3.1.1.. Allocation Policy as specified in section 3.1.1..
65,280 - 65,534 65,280 - 65,534
0xFF00 - 0xFFFE - Private Use. 0xFF00 - 0xFFFE - Private Use.
65,535 65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action. 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
3.1.1 DNS TYPE Allocation Policy 3.1.1 DNS TYPE Allocation Policy
Parameter values specified above as assigned based on DNS TYPE Parameter values specified in Section 3.1 above as assigned based on
Allocation Policy are allocated by Expert Review if they meet the two DNS TYPE Allocation Policy are allocated by Expert Review if they
requirements listed below. If they do not meet these requirements, meet the two requirements listed below. Some guidelines for the
they are allocated by IETF Standards Action as modified by [RFC Expert are given in Section 3.1.3. RR TYPEs that do not meet these
4020]. requirements, are allocated by IETF Standards Action as modified by
[RFC 4020].
A complete template as specified in Section 3.1.2 has been posted for 1. A complete template as specified in Section 3.1.2 has been posted
three weeks to the namedroppers@ops.ietf.org mailing list before for three weeks to the namedroppers@ops.ietf.org mailing list
the Expert Review. before the Expert Review decision.
Note that partially completed or draft templates may be posted Note that partially completed or draft templates may be posted
for comment. for comment.
2. The RR for which a TYPE code is being requested must be either (a) 2. The RR for which a TYPE code is being requested is either (a) a
a data TYPE which can be handled as an Unknown RR as described in data TYPE which can be handled as an Unknown RR as described in
[RFC 3597] or (b) a Meta TYPE who processing is optional, i.e., [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e.,
which it is safe to simply discard. which it is safe to simply discard.
Note that such RRs may include additional section processing Note that such RRs may include additional section processing
provided such processing is optional. provided such processing is optional.
3.1.2 Expert Review DNS TYPE Expert Review Template 3.1.2 Expert Review DNS TYPE Expert Review Template
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
Date: Date:
Name, email, and telephone number of originator: Name, email, and telephone number of originator:
Pointer to internet-draft or other public document giving a Pointer to internet-draft or other public document giving a
detailed description of the protocol use of the new RR Type: detailed description of the protocol use of the new RR Type:
What need is the new RR TYPE intended to satisfy? What need is the new RR TYPE intended to satisfy?
What existing RR TYPE(s) come closest to filling that need and What existing RR TYPE or TYPEs come closest to filling that
why are they unsatisfactory? need and why are they unsatisfactory?
Does the proposed RR TYPE require special handling within the Does the proposed RR TYPE require special handling within the
DNS different from an Unknown RR TYPE? DNS different from an Unknown RR TYPE or ignorable meta-TYPE?
Comments: Comments:
3.1.3 Special Note on the OPT RR 3.1.3 DNS RRTYPE Expert Guidelines
The designed DNS RRTYPE Expert is required to monitor discussion of
the proposed RRTYPE which may occur on the namedroppers mailing list
and to consult with other experts as necessary. The Expert should
reject any RRTYPE allocation request which meets the following
criterion:
1. Did not have a complete template as specified above posted to the
namedroppers mailing list for at least three weeks.
2. Was documented in a manner that was not sufficiently clear to
evaluate or ensure interoperability.
3. The RRTYPE value is needed for a DNS extension, but the extension
is not consistent with the documented (or generally understood)
architecture of the DNS protocol, and would be harmful to the DNS
if widely deployed.
4. The intended use of the proposed RRTYPE would cause problems with
existing DNS deployments.
5. The requested RRTYPE would conflict with one under development
within the IETF and the existence of more than one such type would
harm interoperability.
6. An existing RRTYPE or RRTYPEs appear to adequately meet the
purpose of the RR for which an RRTYPE value or values are
requested.
7. An excessive number of RRTYPE values is being requested when the
purpose could be met with a smaller number.
8. The request appears to be for an RRTYPE value that would not
genuinely be used in the DNS or whose use would be insignificant
or whose near term use would be better met by a value from the
range reserved for Private Use.
3.1.4 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits. extends the RCODE field from 4 to 12 bits.
3.1.4 The AFSDB RR Subtype Field 3.1.5 The AFSDB RR Subtype Field
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
RDATA field structure as the MX RR but the 16 bit unsigned integer RDATA field structure as the MX RR but the 16 bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as field at the beginning of the RDATA is interpreted as a subtype as
follows: follows:
Decimal Decimal
Hexadecimal Hexadecimal
0 0
skipping to change at page 10, line 7 skipping to change at page 10, line 43
0x0003 - 0xFEFF - Allocation by IETF Consensus. 0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534 65,280 - 65,534
0xFF00 - 0xFFFE - Private Use. 0xFF00 - 0xFFFE - Private Use.
65,535 65,535
0xFFFF - Reserved, allocation requires IETF Standards Action. 0xFFFF - Reserved, allocation requires IETF Standards Action.
3.2 RR CLASS IANA Considerations 3.2 RR CLASS IANA Considerations
There are two subcategories of DNS CLASSes: normal data containing There are currentlty two subcategories of DNS CLASSes: normal data
classes and QCLASSes that are only meaningful in queries or updates. containing classes and QCLASSes that are only meaningful in queries
or updates.
DNS CLASSes have been little used but constitute another dimension of DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one data relationship between the name space or root servers for one data
CLASS and those for another data CLASS. The same name can have CLASS and those for another data CLASS. The same name can have
completely different meanings in different CLASSes. The label types completely different meanings in different CLASSes. The label types
are the same and the null label is usable only as root in every are the same and the null label is usable only as root in every
CLASS. As global networking and DNS have evolved, the IN, or CLASS. As global networking and DNS have evolved, the IN, or
Internet, CLASS has dominated DNS use. Internet, CLASS has dominated DNS use.
skipping to change at page 11, line 48 skipping to change at page 12, line 39
types are sometimes referred to as Text and Binary. Text labels can, types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero value octets but many in fact, include any octet value including zero value octets but many
current uses involve only [US-ASCII]. For retrieval, Text labels are current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching defined to treat ASCII upper and lower case letter codes as matching
[RFC 4343]. Binary labels are bit sequences [RFC 2673]. The Binary [RFC 4343]. Binary labels are bit sequences [RFC 2673]. The Binary
label type is Experimental [RFC 3363]. label type is Experimental [RFC 3363].
IANA considerations for label types are given in [RFC 2671]. IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet 1981] CLASSes are for essentially local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at CLASS is thus the only DNS CLASS in global use on the Internet at
this time. this time.
A somewhat out-of-date description of name allocation in the IN Class A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC 1591]. Some information on reserved top level is given in [RFC 1591]. Some information on reserved top level
domain names is in BCP 32 [RFC 2606]. domain names is in BCP 32 [RFC 2606].
4. Security Considerations 4. Security Considerations
This document addresses IANA considerations in the allocation of This document addresses IANA considerations in the allocation of
skipping to change at page 14, line 13 skipping to change at page 15, line 13
ipr@ietf.org. ipr@ietf.org.
Appendix: Changes from RFC 2929 Appendix: Changes from RFC 2929
RFC Editor: This Appendix should be deleted for publication. RFC Editor: This Appendix should be deleted for publication.
Changes from RFC 2929 to this draft: Changes from RFC 2929 to this draft:
1. Changed most "IETF Consensus" and "Specification Required" 1. Changed most "IETF Consensus" and "Specification Required"
allocation policies for RR TYPEs to be "DNS TYPE Allocation Policy" allocation policies for RR TYPEs to be "DNS TYPE Allocation Policy"
and add the specification of that policy. Change some remaining "IETF and add the specification of that policy which is based on Expert
Standards Action" allocation requirements to say "as modified by [RFC Review with additional provisions and restrictions. Change some
4020]". remaining "IETF Standards Action" allocation requirements to say "as
modified by [RFC 4020]".
2. Updated numerous RFC references. 2. Updated numerous RFC references.
3. Mentioned that the Binary label type is now Experimental and 3. Mentioned that the Binary label type is now Experimental and
IQuery is Obsolete. IQuery is Obsolete.
4. Changed allocation status of RR TYPE 0xFFFF and RCODE 0xFFFF to be 4. Changed allocation status of RR TYPE 0xFFFF and RCODE 0xFFFF to be
IETF Standards Action required. IETF Standards Action required.
5. Add an IANA allocation policy for the AFSDB RR Subtype field. 5. Add an IANA allocation policy for the AFSDB RR Subtype field.
6. Addition of reference to case insensitive RFC [RFC 4343], Unknown 6. Addition of reference to case insensitive RFC [RFC 4343], Unknown
RRs RFC [RFC 3597], and SIG(0) RFC [RFC 2931]. RRs RFC [RFC 3597], SIG(0) RFC [RFC 2931], and TSIG SHA RFC [RSIG
SHA].
7. Split Specification Required CLASSes into data CLASSes and query 7. Add the BADTRUC code to the table of RCODEs.
8. Split Specification Required CLASSes into data CLASSes and query
or meta CLASSes. or meta CLASSes.
Copyright and Disclaimer Copyright
Copyright (C) The Internet Society (2006). This document is subject to Copyright (C) The Internet Society 2006. This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights. as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Normative References Normative References
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
skipping to change at page 16, line 33 skipping to change at page 17, line 26
2005. 2005.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034, Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005. March 2005.
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005. 4035, March 2005.
[TSIG-SHA] - D. Eastlake 3rd, "HMAC SHA TSIG Algorithm Identifiers",
draft-ietf-dnsext-tsgi-sha-06.txt. RFC EDITOR NOTE: This draft is in
the RFC Editor Queue, please replace references with the RFC number
when it is assigned.
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange", [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968. X3.4, American National Standards Institute: New York, 1968.
Informative References Informative References
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987, Technical Plan - Name Service, April 1987,
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June Institute of Technology Artificial Intelligence Laboratory, June
skipping to change at page 18, line 17 skipping to change at page 19, line 17
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w) Telephone: +1-508-786-7554 (w)
email: Donald.Eastlake@motorola.com email: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires September 2006. This draft expires December 2006.
Its file name is draft-ietf-dnsext-2929bis-02.txt. Its file name is draft-ietf-dnsext-2929bis-03.txt.
Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
 End of changes. 29 change blocks. 
61 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/