< draft-daigle-unaptr   rfc4848.txt 
Network Working Group L. Daigle Network Working Group L. Daigle
Internet-Draft Cisco Systems Request for Comments: 4848 Cisco Systems
Expires: August 14, 2007 February 10, 2007 Category: Standards Track April 2007
Domain-based Application Service Location Using URIs and the Dynamic
Delegation Discovery Service (DDDS)
draft-daigle-unaptr-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Domain-Based Application Service Location Using URIs and
http://www.ietf.org/ietf/1id-abstracts.txt. the Dynamic Delegation Discovery Service (DDDS)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The purpose of this document is to define a new, straightforward The purpose of this document is to define a new, straightforward
Dynamic Delegation Discovery Service (DDDS) application to allow Dynamic Delegation Discovery Service (DDDS) application to allow
mapping of domain names to URIs for particular application services mapping of domain names to URIs for particular application services
and protocols. Although defined as a new DDDS application, dubbed and protocols. Although defined as a new DDDS application, dubbed
U-NAPTR, this is effectively an extension of the Straightforward U-NAPTR, this is effectively an extension of the Straightforward
NAPTR (S-NAPTR) DDDS application. NAPTR (S-NAPTR) DDDS Application.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Straightforward URI-enabled NAPTR (U-NAPTR) . . . . . . . . . 3 2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3
2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . 3 2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Permitted Regular Expressions . . . . . . . . . . . . . . 4 2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4
3. Sample U-NAPTR DNS records . . . . . . . . . . . . . . . . . . 4 3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4
4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5 4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5
4.1. Application Unique String . . . . . . . . . . . . . . . . 5 4.1. Application Unique String . . . . . . . . . . . . . . . . . 5
4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5 4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5 4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5 4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5
4.5.1. Application Services . . . . . . . . . . . . . . . . . 6 4.5.1. Application Services . . . . . . . . . . . . . . . . . 6
4.5.2. Application Protocols . . . . . . . . . . . . . . . . 6 4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6
4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . 7 4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
The purpose of this document is to define a new, straightforward The purpose of this document is to define a new, straightforward
Dynamic Delegation Discovery Service (DDDS, [7]) application to allow Dynamic Delegation Discovery Service (DDDS) [7] application to allow
mapping of domain names to URIs for particular application services mapping of domain names to URIs for particular application services
and protocols. This allows the "lookup" of particular services and protocols. This allows the "lookup" of particular services
available for given domains, for example. available for given domains, for example.
Although this is defining a new and separate DDDS application, dubbed Although this is defining a new and separate DDDS Application, dubbed
U-NAPTR, it is built from the same principles as the Straightforward U-NAPTR, it is built from the same principles as the Straightforward
NAPTR (S-NAPTR) application, specified in [2]. This specification is NAPTR (S-NAPTR) application, specified in [2]. This specification is
not an update of S-NAPTR, but the reader is encouraged to review that not an update of S-NAPTR, but the reader is encouraged to review that
document for extensive coverage of motivation and implementation document for extensive coverage of motivation and implementation
considerations. considerations.
S-NAPTR provides for application service location that does not rely S-NAPTR provides for application service location that does not rely
on rigid domain naming conventions. It is deemed "straightforward" on rigid domain naming conventions. It is deemed "straightforward"
in part because it rules out the use of regular expressions in NAPTR in part because it rules out the use of regular expressions in NAPTR
records (for the S-NAPTR DDDS Application). However, that also rules records (for the S-NAPTR DDDS Application). However, that also rules
out the possibility of providing a URI as the target of DDDS out the possibility of providing a URI as the target of DDDS
resolution. A number of applications, specified (e.g., [9]) and resolution. A number of applications, specified (e.g., [9]) and
proposed, find the restriction too limiting, making S-NAPTR a near proposed, find the restriction too limiting, making S-NAPTR a near
miss to suit their needs. miss to suit their needs.
This U-NAPTR is effectively a modest extension to S-NAPTR, to This U-NAPTR is effectively a modest extension to S-NAPTR, to
accommodate the use of URIs as targets, without allowing the full accommodate the use of URIs as targets, without allowing the full
range of possible regular expressions in NAPTR records. range of possible regular expressions in NAPTR records.
2. Straightforward URI-enabled NAPTR (U-NAPTR) 2. Straightforward URI-Enabled NAPTR (U-NAPTR)
This document assumes the reader is familiar with the S-NAPTR This document assumes the reader is familiar with the S-NAPTR
specification ([2]). The intention of U-NAPTR is to provide specification [2]. The intention of U-NAPTR is to provide everything
everything that S-NAPTR does, except that it allows the use of the that S-NAPTR does, except that it allows the use of the "U" flag in
"U" flag in the NAPTR record, and a specific form of REGEXP. the NAPTR record, and a specific form of REGEXP.
2.1. Permitted Flags 2.1. Permitted Flags
U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus
the "U" Flag. For the U-NAPTR DDDS Application, the presence of the the "U" Flag. For the U-NAPTR DDDS Application, the presence of the
"U" Flag in the NAPTR record indicates the REGEXP field must be "U" Flag in the NAPTR record indicates the REGEXP field must be
populated (and, consequently, the REPLACEMENT field is empty). The populated (and, consequently, the REPLACEMENT field is empty). The
regular expression in the REGEXP field must be of the limited form regular expression in the REGEXP field must be of the limited form
described below, and the result of the regular expression evaluation described below, and the result of the regular expression evaluation
will be a URI that is the result of the DDDS resolution. will be a URI that is the result of the DDDS resolution.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
The specific allowed syntax for U-NAPTR regular expressions is: The specific allowed syntax for U-NAPTR regular expressions is:
u-naptr-regexp = "!.*!"<URI>"!" u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [8], the URI syntax where <URI> is as defined in STD 66 [8], the URI syntax
specification. specification.
With this limited form of regular expression, applications using With this limited form of regular expression, applications using
U-NAPTR need not implement full regular expression parsers. U-NAPTR need not implement full regular expression parsers.
3. Sample U-NAPTR DNS records 3. Sample U-NAPTR DNS Records
In the sample NAPTR RRs for example.com shown below, "WP" is the In the sample NAPTR RRs for example.com shown below, "WP" is the
imagined application service tag for "white pages", and "EM" is the imagined application service tag for "white pages", and "EM" is the
application service tag for an imagined "Extensible Messaging" application service tag for an imagined "Extensible Messaging"
application service. application service.
example.com. example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp "" ; regexp
skipping to change at page 5, line 7 skipping to change at page 5, line 7
"!.*!prota://someisp.example.com!" ; regexp "!.*!prota://someisp.example.com!" ; regexp
"" ; replacement "" ; replacement
) )
IN NAPTR 200 30 "a" "EM:protB" ; service IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp "" ; regexp
myprotB.example.com.; replacement myprotB.example.com.; replacement
) )
4. Formal Definition of U-NAPTR Application of DDDS 4. Formal Definition of U-NAPTR Application of DDDS
This section formally defines the DDDS application, as described in This section formally defines the DDDS Application, as described in
[7]. [7].
4.1. Application Unique String 4.1. Application Unique String
The Application Unique String is a fully quallified domain name The Application Unique String is a fully qualified domain name (FQDN)
(FQDN) for which an authoritative server for a particular service is for which an authoritative server for a particular service is sought.
sought.
4.2. First Well Known Rule 4.2. First Well Known Rule
The "First Well Known Rule" is identity -- that is, the output of the The "First Well Known Rule" is identity -- that is, the output of the
rule is the Application Unique String, the FQDN for which the rule is the Application Unique String, the FQDN for which the
authoritative server for a particular service is sought. authoritative server for a particular service is sought.
4.3. Expected Output 4.3. Expected Output
The expected output of this Application is the information necessary The expected output of this Application is the information necessary
to connect to authoritative server(s) (host, port, protocol, or URI) to connect to authoritative server(s) (host, port, protocol, or URI)
for an application service within a given domain. for an application service within a given domain.
4.4. Flags 4.4. Flags
This DDDS Application uses only 3 of the Flags defined for the URI/ This DDDS Application uses only 3 of the Flags defined for the URI/
URN Resolution Application ([5]): "S", "A", and "U". No other Flags URN Resolution Application [5]: "S", "A", and "U". No other Flags
are valid. If a client obtains a NAPTR RR for a U-NAPTR-using are valid. If a client obtains a NAPTR RR for a U-NAPTR-using
application that contains any other flag, that NAPTR RR should be application that contains any other flag, that NAPTR RR should be
ignored and processing continues with the next record (if any). ignored and processing continues with the next record (if any).
These flags are for terminal lookups. This means that the Rule is These flags are for terminal lookups. This means that the Rule is
the last one and that the flag determines what the next stage should the last one and that the flag determines what the next stage should
be. The "S" flag means that the output of this Rule is a FQDN for be. The "S" flag means that the output of this Rule is a FQDN for
which one or more SRV [3] records exist. "A" means that the output which one or more SRV [3] records exist. "A" means that the output
of the Rule is a domain name and should be used to lookup address of the Rule is a domain name and should be used to lookup address
records for that domain. "U" means that the output of the Rule is a records for that domain. "U" means that the output of the Rule is a
URI which should be resolved in order to obtain access to the URI that should be resolved in order to obtain access to the
described service. described service.
Consistent with the DDDS algorithm, if the Flag string is empty the Consistent with the DDDS algorithm, if the Flag string is empty the
next lookup is for another NAPTR record (for the replacement target). next lookup is for another NAPTR record (for the replacement target).
4.5. Service Parameters 4.5. Service Parameters
Service Parameters for this Application take the form of a string of Service Parameters for this Application take the form of a string of
characters that follow this ABNF ([1]): characters that follow this ABNF [1]:
service-parms = [ [app-service] *(":" app-protocol)] service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32 ; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character. ; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive. ; The service-parms are considered case-insensitive.
Thus, the Service Parameters may consist of an empty string, just an Thus, the Service Parameters may consist of an empty string, just an
app-service, or an app-service with one or more app-protocol app-service, or an app-service with one or more app-protocol
specifications separated by the ":" symbol. specifications separated by the ":" symbol.
Note that this is similar to, but not the same as the syntax used in Note that this is similar to, but not the same as the syntax used in
the URI DDDS application ([5]). The DDDS DNS database requires each the URI DDDS application [5]. The DDDS DNS database requires each
DDDS application to define the syntax of allowable service strings. DDDS application to define the syntax of allowable service strings.
The syntax here is expanded to allow the characters that are valid in The syntax here is expanded to allow the characters that are valid in
any URI scheme name (see [8]). Since "+" (the separator used in the any URI scheme name (see [8]). Since "+" (the separator used in the
RFC3404 service parameter string) is an allowed character for URI RFC3404 service parameter string) is an allowed character for URI
scheme names, ":" is chosen as the separator here. scheme names, ":" is chosen as the separator here.
4.5.1. Application Services 4.5.1. Application Services
The "app-service" must be an IANA-registered service; see Section 5 The "app-service" must be an IANA-registered service; see Section 5
for instructions on registering new application service tags. for instructions on registering new application service tags.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
following syntax (i.e., a regular expression to replace the domain following syntax (i.e., a regular expression to replace the domain
name with a URI): name with a URI):
u-naptr-regexp = "!.*!"<URI>"!" u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [8], the URI syntax where <URI> is as defined in STD 66 [8], the URI syntax
specification. specification.
4.7. Valid Databases 4.7. Valid Databases
At present only one DDDS Database is specified for this Application. At present, only one DDDS Database is specified for this Application.
[4] specifies a DDDS Database that uses the NAPTR DNS resource record [4] specifies a DDDS Database that uses the NAPTR DNS resource record
to contain the rewrite rules. The Keys for this database are encoded to contain the rewrite rules. The Keys for this database are encoded
as domain-names. as domain names.
The First Well Known Rule produces a domain name, and this is the Key The First Well Known Rule produces a domain name, and this is the Key
that is used for the first lookup -- the NAPTR records for that that is used for the first lookup -- the NAPTR records for that
domain are requested. domain are requested.
DNS servers MAY interpret Flag values and use that information to DNS servers MAY interpret Flag values and use that information to
include appropriate NAPTR, SRV or A records in the Additional include appropriate NAPTR, SRV, or A records in the Additional
Information portion of the DNS packet. Clients are encouraged to Information portion of the DNS packet. Clients are encouraged to
check for additional information but are not required to do so. See check for additional information but are not required to do so. See
the Additional Information Processing section of [4] for more the Additional Information Processing section of [4] for more
information on NAPTR records and the Additional Information section information on NAPTR records and the Additional Information section
of a DNS response packet. of a DNS response packet.
5. IANA Considerations 5. IANA Considerations
This document does not itself place any requirements on IANA, but This document does not itself place any requirements on IANA, but
provides the basis upon which U-NAPTR-using services can make use of provides the basis upon which U-NAPTR-using services can make use of
the existing IANA registries for application service tags and the existing IANA registries for application service tags and
application protocol tags (defined in RFC3958, [2]). application protocol tags (defined in RFC 3958 [2]).
As is the case for S-NAPTR, all application service and protocol tags As is the case for S-NAPTR, all application service and protocol tags
that start with "x-" are considered experimental, and no provision is that start with "x-" are considered experimental, and no provision is
made to prevent duplicate use of the same string. Use them at your made to prevent duplicate use of the same string. Use them at your
own risk. own risk.
All other application service and protocol tags are registered based All other application service and protocol tags are registered based
on the "specification required" option defined in [6], with the on the "specification required" option defined in [6], with the
further stipulation that the "specification" is an RFC (of any further stipulation that the "specification" is an RFC (of any
category). category).
skipping to change at page 8, line 14 skipping to change at page 8, line 17
o Any relevant related publications o Any relevant related publications
The defining RFC may also include further application-specific The defining RFC may also include further application-specific
restrictions, such as limitations on the types of URIs that may be restrictions, such as limitations on the types of URIs that may be
returned for the application service. returned for the application service.
6. Security Considerations 6. Security Considerations
U-NAPTR has the same considerations for security as S-NAPTR; see U-NAPTR has the same considerations for security as S-NAPTR; see
Section 8 of [2]). U-NAPTR has the additional consideration that Section 8 of [2]. U-NAPTR has the additional consideration that
resolving URIs (from the result of the DDDS resolution) has its own resolving URIs (from the result of the DDDS resolution) has its own
set of security implications, covered in the URI specification (in set of security implications, covered in the URI specification (in
particular, Section 7 of [8]). In essence, using DNSSEC, client particular, Section 7 of [8]). In essence, using DNSSEC, client
software can be confident that the URI obtained using U-NAPTR is software can be confident that the URI obtained using U-NAPTR is
indeed the one specified by the administrator of the domain from indeed the one specified by the administrator of the domain from
which it was retrieved; but the validity of the service reached by which it was retrieved; but the validity of the service reached by
resolving that URI is a matter of URI resolution security practices. resolving that URI is a matter of URI resolution security practices.
7. Acknowledgements 7. Acknowledgements
Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes,
Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier
drafts and catching errors! versions and catching errors!
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[2] Daigle, L. and A. Newton, "Domain-Based Application Service [2] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002. October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404, Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002. October 2002.
skipping to change at page 9, line 25 skipping to change at page 9, line 28
Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
January 2005. January 2005.
[9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", [9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords",
RFC 4095, May 2005. RFC 4095, May 2005.
Author's Address Author's Address
Leslie L. Daigle Leslie L. Daigle
Cisco Systems Cisco Systems
13600 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA 20171 Herndon, VA 20171
US US
Email: [email protected]; [email protected] EMail: [email protected]; [email protected]
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 10, line 45 skipping to change at page 10, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
[email protected] [email protected]
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 29 change blocks. 
78 lines changed or deleted 57 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/