draft-ietf-urn-ddds-toc-00.txt   draft-ietf-urn-ddds-toc-01.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Verisign Internet-Draft VeriSign
Expires: April 28, 2002 October 28, 2001 Expires: July 12, 2002 January 11, 2002
Dynamic Delegation Discovery System (DDDS) Part One: The Dynamic Delegation Discovery System (DDDS) Part One: The
Comprehensive DDDS Standard Comprehensive DDDS Standard
draft-ietf-urn-ddds-toc-00.txt draft-ietf-urn-ddds-toc-01.txt
Status of this Memo Status of this Memo
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 RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on April 28, 2002. This Internet-Draft will expire on July 12, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document specifies the exact documents that make up the complete This document specifies the exact documents that make up the complete
Dynamic Delegation Discovery System (DDDS) standard. The DDDS is an Dynamic Delegation Discovery System (DDDS) standard. The DDDS is an
abstract algorithm for applying dynamically retrieved string abstract algorithm for applying dynamically retrieved string
transformation rules to an application-unique string. transformation rules to an application-unique string.
This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC
2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. 2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5].
skipping to change at page 4, line 24 skipping to change at page 4, line 24
o The requirements on applications using the algorithm o The requirements on applications using the algorithm
o The requirements on databases that store DDDS rules o The requirements on databases that store DDDS rules
RFC XXXX is the actual DDDS algorithm Specification. But the RFC XXXX is the actual DDDS algorithm Specification. But the
specification by itself is useless without some additional document specification by itself is useless without some additional document
that defines how and why the algorithm is used. These documents are that defines how and why the algorithm is used. These documents are
called Applications and do not actually make up part of the DDDS core called Applications and do not actually make up part of the DDDS core
specification. Applications require databases in which to store specification. Applications require databases in which to store
their Rules. These databases are called DDDS Databases and are their Rules. These databases are called DDDS Databases and are
usually specified in seperate documents. But again, these Database usually specified in separate documents. But again, these Database
specifications are not included in the DDDS core specification specifications are not included in the DDDS core specification
itself. itself.
4. DDDS Applications 4. DDDS Applications
No implementation can begin without an Application specification, as No implementation can begin without an Application specification, as
this is what provides the concrete instantiation details for the this is what provides the concrete instantiation details for the
DDDS. Without them the DDDS is nothing more than a general DDDS. Without them the DDDS is nothing more than a general
algorithm. Application documents define the following: algorithm. Application documents define the following:
skipping to change at page 6, line 29 skipping to change at page 6, line 29
o collision avoidance measures o collision avoidance measures
A Database cannot be used on its own; there must be at least one A Database cannot be used on its own; there must be at least one
Application that uses it. Multiple Databases and Applications are Application that uses it. Multiple Databases and Applications are
defined, and some Databases will support multiple Applications. defined, and some Databases will support multiple Applications.
However, not every Application uses each Database, and vice versa. However, not every Application uses each Database, and vice versa.
Thus, compliance is defined by the combination of a Database and Thus, compliance is defined by the combination of a Database and
Application specification. Application specification.
One sample Database specification are documented in: One sample Database specification is documented in:
o "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS o "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database" (RFC XXXX) [1] (This document is the official Database" (RFC XXXX) [1] (This document is the official
specification for the NAPTR DNS Resource Record) specification for the NAPTR DNS Resource Record)
6. Security Considerations
Any known security issues that arise from the use of algorithms and
databases must be specified in the respective specifications. They
must be completely and fully described. It is not required that the
database and algorithms be secure or that it be free from risks, but
that the known risks be identified. Publication of a new database
type or algorithm do require a security review, and the security
considerations section should be subject to continuing evaluation.
Additional security considerations should be addressed by publishing
revised versions of the database and algorithm specifications.
7. IANA Considerations
While this document itself does not create any new requirements for
the IANA, the documents in this series create many varied
requirements. The IANA Considerations sections in those documents
should be reviewed by the IANA to determine the complete set of new
registries and requirements. Any new algorithms, databases or
applications should take great care in what they require the IANA to
do in the future.
References References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work
in progress), May 2000. in progress), May 2000.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000. database-07.txt (work in progress), May 2000.
skipping to change at page 7, line 37 skipping to change at page 9, line 37
(NAPTR) DNS Resource Record", RFC 2915, August 2000. (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource [8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997. Identifiers using the Domain Name System", RFC 2168, June 1997.
Author's Address Author's Address
Michael Mealling Michael Mealling
Verisign VeriSign
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
Phone: +1 770 921-2251 Phone: +1 770 921-2251
EMail: michaelm@netsol.com EMail: michaelm@netsol.com
URI: http://www.verisign.com URI: http://www.verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 9 change blocks. 
9 lines changed or deleted 31 lines changed or added

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