draft-ietf-dnsext-edns0dot5-01.txt   draft-ietf-dnsext-edns0dot5-02.txt 
Network Working Group R. Austein Network Working Group R. Austein
draft-ietf-dnsext-edns0dot5-01.txt InterNetShare.com, Inc. draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc.
H. Alvestrand H. Alvestrand
EDB MaXware AS Cisco Systems
July 2000 November 2000
A Proposed Enhancement to the EDNS0 Version Mechanism A Proposed Enhancement to the EDNS0 Version Mechanism
Status of this document Status of this document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
format used by the Domain Name System protocols. The framework format used by the Domain Name System protocols. The framework
includes a simple version numbering scheme to allow the parties in a includes a simple version numbering scheme to allow the parties in a
DNS protocol exchange to determine which extension features the other DNS protocol exchange to determine which extension features the other
party understands. While having the advantage of simplicity, the party understands. While having the advantage of simplicity, the
version numbering scheme as specified has drawbacks: version numbering scheme as specified has drawbacks:
- It provides no way to deprecate a protocol feature; - It provides no way to deprecate a protocol feature;
- It provides no way to deploy experimental protocol features. - It provides no way to deploy experimental protocol features.
This note proposes to replace the monolithic version numbering This note proposes to augument the monolithic version numbering
mechanism with a mechanism for listing an explicit set of protocol mechanism with a mechanism for listing an explicit set of protocol
features that a particular implementation supports. We retain features that a particular implementation supports. We retain
version numbering as a way of abbreviating the feature sets that we version numbering as a way of abbreviating the feature sets that we
expect to see in common use. expect to see in common use.
Model Model
Our revised extension model for EDNS0 is designed with three goals in Our revised extension model for the DNS is designed with three goals
mind: in mind:
- We want the protocol to be as simple as possible for the common - We want the protocol to be as simple as possible for the common
case of a client or server that implements "mainstream standard case of a client or server that implements "mainstream standard
DNS"; DNS";
- We want to provide a safe way to experiment with new protocol - We want to provide a safe way to experiment with new protocol
features, both inside and outside the deployed DNS; features, both inside and outside the deployed DNS;
- We want to provide a safe way to deprecate protocol features. - We want to provide a safe way to deprecate protocol features.
skipping to change at page 3, line 23 skipping to change at page 3, line 23
- To remove the need for supporting FEATUREs that turned out to be a - To remove the need for supporting FEATUREs that turned out to be a
Really Bad Idea; Really Bad Idea;
- To allow replacing a badly specified FEATURE with a better - To allow replacing a badly specified FEATURE with a better
specified FEATURE performing the same function that has a new specified FEATURE performing the same function that has a new
FEATURE number. FEATURE number.
Mechanism Mechanism
We propose to transport explicit feature sets as lists of integers We transport explicit feature sets as lists of integers carried in
carried in the variable RDATA portion of the EDNS0 OPT pseudo-RR. the variable RDATA portion of the EDNS0 OPT pseudo-RR.
The OPTION-CODE for FEATURES is [TBD]. The OPTION-CODE for FEATURES is [TBD].
The OPTION-DATA for FEATURES is an ordered list of "feature numbers"; The OPTION-DATA for FEATURES is an ordered list of "feature numbers";
a feature number is represented as a big-endian 16-bit unsigned a feature number is represented as a big-endian 16-bit unsigned
integer, and the list is sorted into numerically increasing order. integer, and the list is sorted into numerically increasing order.
Each feature number names a particular protocol feature that is Each feature number names a particular protocol feature that is
supported by the implementation that generated this OPT pseudo-RR. supported by the implementation that generated this OPT pseudo-RR.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
Rob Austein Rob Austein
InterNetShare.com, Inc. InterNetShare.com, Inc.
505 West Olive Ave., Suite 321 505 West Olive Ave., Suite 321
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
sra@hactrn.net sra@hactrn.net
Harald Tveit Alvestrand Harald Tveit Alvestrand
EDB MaXware AS Cisco Systems
Pirsenteret Weidemanns vei 27
N-7486 Trondheim N-7043 Trondheim
NORWAY NORWAY
+47 73 54 57 97 +47 73 50 33 52
Harald@Alvestrand.no Harald@Alvestrand.no
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/