660 lines
24 KiB
Plaintext
660 lines
24 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
DNEXT Working Group S. Rose
|
|
Internet Draft NIST
|
|
Expires: June 2001 January 2001
|
|
Category: Informational
|
|
|
|
|
|
|
|
|
|
DNS Security Document Roadmap
|
|
------------------------------
|
|
<draft-ietf-dnsext-dnssec-roadmap-01.txt>
|
|
|
|
|
|
Status of this Document
|
|
|
|
This document is an Internet-Draft and is in full
|
|
conformance with all provisions of Section 10 of RFC2026.
|
|
Distribution of this document is unlimited. Comments
|
|
regarding this document should be sent to the author.
|
|
|
|
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
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
|
|
The list of Internet-Draft Shadow Directories can be
|
|
accessed at http://www.ietf.org/shadow.html.
|
|
|
|
|
|
Abstract
|
|
|
|
DNS Security (DNSSEC)technology is composed of extensions
|
|
to the Domain Name System (DNS) protocol that provide
|
|
data integrity and authentication to security aware
|
|
resolvers and applications through the use of
|
|
cryptographic digital signatures. Several documents
|
|
exist to describe these extensions and the implementation
|
|
specific details regarding specific digital signing
|
|
schemes. The interrelationship between these different
|
|
documents is discussed here. A brief overview of what to
|
|
|
|
|
|
|
|
Rose [Page 1]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
find in which document and author guidelines for what to
|
|
include in new DNS Security documents, or revisions to
|
|
existing documents, is described.
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
|
|
|
|
|
|
1. Introduction ............................................... 3
|
|
2. Interrelationship of DNS Security Documents ................ 3
|
|
3. Relationship of DNS Security Documents to other DNS Docu-
|
|
ments .......................................................... 6
|
|
4. Recommended Content for new DNS Security Documents ......... 6
|
|
4.1 Security Related Resource Records ......................... 6
|
|
4.2 Digital Signature Algorithm Implementation ................ 7
|
|
4.3 Refinement of Security Procedures ......................... 7
|
|
4.4 The Use of DNS Security Extensions with Other Protocols
|
|
................................................................ 8
|
|
5. Security Considerations .................................... 8
|
|
6. Acknowledgements ........................................... 8
|
|
7. References ................................................. 9
|
|
8. Author's Address ........................................... 10
|
|
Expiration and File Name ....................................... 10
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rose [Page 2]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
1. Introduction
|
|
|
|
This document is intended to provide guidelines for the development
|
|
of supplemental documents describing security extensions to the
|
|
Domain Name System (DNS).
|
|
|
|
The main goal of the DNS Security (DNSSEC) protocol extensions is to
|
|
add data authentication and integrity services to the DNS protocol.
|
|
These protocol extensions should be differentiated from DNS opera-
|
|
tional security issues, which are beyond the scope of this effort.
|
|
DNS Security documents fall into one or possibly more of the follow-
|
|
ing sub-categories: new DNS security resource records, implementation
|
|
details of specific digital signing algorithms for use in DNS Secu-
|
|
rity and Secure DNS transactions. Since the goal of DNS Security
|
|
extensions is to become part of the DNS protocol standard, additional
|
|
documents that seek to refine a portion of the security extensions
|
|
will be introduced as the specifications progress along the IETF
|
|
standards track.
|
|
|
|
There is a set of basic guidelines for each sub-category of documents
|
|
that explains what should be included, what should be considered a
|
|
protocol extension, and what should be considered an operational
|
|
issue. Currently, there are at least two documents that fall under
|
|
operational security considerations that deal specifically with the
|
|
DNS security extensions: The first is RFC 2541 which deals with the
|
|
operational side of implementing the security extensions. The other
|
|
is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These documents
|
|
should be considered part of the operational side of DNS, but will be
|
|
addressed as a supplemental part of the DNS Security roadmap. That
|
|
is not to say that these two documents are not important to securing
|
|
a DNS zone, but it does not directly address the proposed DNS secu-
|
|
rity extensions. Authors of documents that seek to address the
|
|
operational concerns of DNS security should be aware of the structure
|
|
of DNS Security documentation if they wish to include their documents
|
|
in the DNSEXT Working Group in addition to the DNS Operations WG.
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in [RFC 2119]. It is
|
|
also assumed the reader has some knowledge of the Domain Name System
|
|
[RFC1035] and the Domain Name System Security Extensions [RFC2535].
|
|
|
|
|
|
2. Interrelationship of DNS Security Documents
|
|
|
|
The DNSSEC set of documents can be partitioned into five main groups
|
|
as depicted in Figure 1. All of these documents in turn are under
|
|
the larger umbrella group of DNS base protocol documents. It is
|
|
|
|
|
|
|
|
Rose [Page 3]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
possible that some documents fall into more than one of these
|
|
categories, such as RFC 2535, and should follow the guidelines for
|
|
the all of the document groups it falls into. However, it is wise to
|
|
limit the number of "uberdocuments" that try to be everything to
|
|
everyone. The documents listed in each category are current as to
|
|
the time of writing.
|
|
|
|
|
|
+--------------------------------+
|
|
| |
|
|
| Base DNS Protocol Docs. |
|
|
| [RFC1035, RFC2181, etc.] |
|
|
| |
|
|
+--------------------------------+
|
|
|
|
|
|
|
|
|
|
|
+------------+ +-----------+ +-------------+
|
|
| New | | DNSSEC | | New |
|
|
| Security | <------->| protocol |<-------->| Security |
|
|
| RRs | | | | Uses |
|
|
| [RFC2538, | | [RFC2535, | | |
|
|
| RFC2931, | | RFC3007, | +-------------+
|
|
| NO] | | RFC3008, |
|
|
+------------+ | CLARIFY, |
|
|
| SIZE ] |
|
|
| OKBIT, |
|
|
| ADBIT, |
|
|
| OPTIN ] |
|
|
+-----------+
|
|
|
|
|
|
|
|
+----------------------+***********************
|
|
| | *
|
|
| | *
|
|
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
|
|
| DS | | | | Implementation |
|
|
| Algorithm | | Transactions | * Notes *
|
|
| Impl. | | | | |
|
|
| [RFC2536, | | [RFC2845, | * [CAIRN, *
|
|
| RFC2537 | | RFC2930] | | ROLLOVER ] |
|
|
| RFC2539 | | | * *
|
|
| GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+
|
|
| RSA-SHA] | +---------------+
|
|
+------------+
|
|
Figure 1 DNSSEC Document Roadmap
|
|
|
|
|
|
|
|
|
|
|
|
Rose [Page 4]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
The "DNSSEC protocol" document set refers to the document that makes
|
|
up the groundwork for adding security to the DNS protocol [RFC2535]
|
|
and updates to this document. RFC 2535 laid out the goals and expec-
|
|
tations of DNS Security and the new security related Resource Records
|
|
KEY, SIG, and NXT. Expanding from this document, related document
|
|
groups include the implementation documents of various digital signa-
|
|
ture algorithms with DNSSEC, and documents further refining the tran-
|
|
saction of messages. It is expected that RFC 2535 will be obseleted
|
|
by one or more documents that refine the set of security extensions
|
|
and DNS security transactions. Documents that seek to modify or
|
|
clarify the base protocol documents should state so clearly in the
|
|
introduction of the document (as well as proscribe to the IETF guide-
|
|
lines of RFC/Internet Draft author guidelines). Also, the portions
|
|
of the specification to be modified SHOULD be synopsized in the new
|
|
document for the benefit of the reader. The "DNSSEC protocol" set
|
|
includes the documents [RFC2535], [RFC3007], [RFC3008], [CLARIFY],
|
|
[SIZE], [OKBIT], [ADBIT] and their derivative documents.
|
|
|
|
The "New Security RRs" set refers to the group of documents that seek
|
|
to add additional Resource Record to the set of base DNS Record
|
|
types. These new records can be related to securing the DNS protocol
|
|
[RFC2535], [RFC2931], [NO] or using DNS security for other purposes
|
|
such as storing certificates [RFC2538].
|
|
|
|
The "DS Algorithm Impl" document set refers to the group of documents
|
|
that describe how a specific digital signature algorithm is imple-
|
|
mented to fit the DNSSEC Resource Record format. Each one of these
|
|
documents deals with one specific digital signature algorithm. Exam-
|
|
ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA]
|
|
and [GSS-TSIG].
|
|
|
|
The "Transactions" document set refers to the group of documents that
|
|
deal with the message transaction sequence of security related DNS
|
|
operations. The contents and sequence for operations such as dynamic
|
|
update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
|
|
described in this document category. Additional message transaction
|
|
schemes to support DNSSEC operation would also fall under this group,
|
|
including secret key establishment [RFC2930], and verification.
|
|
|
|
The final document set, "New Security Uses", refers to documents that
|
|
seek to use proposed DNS Security extensions for other security
|
|
related purposes. Documents that fall in this category include the
|
|
use of DNS in the distribution of certificates and individual user
|
|
public keys (PGP, email, etc.).
|
|
|
|
Lastly, there is a set of documents that should be classified as
|
|
"Implementation Notes". Because the DNS security extensions are
|
|
still in the developmental stage, there is an audience for documents
|
|
|
|
|
|
|
|
Rose [Page 5]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
that detail the transition and implementation of the security exten-
|
|
sions. These have more to do with the practical side of DNS opera-
|
|
tions, but can also point to places in the protocol specifications
|
|
that need improvement. Documents in this set may be offspring of
|
|
both the DNSEXT and/or DNSOP working groups. Currently, there are
|
|
two Internet Drafts that falls under this category: The report on
|
|
the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
|
|
[ROLLOVER]. These documents were submitted through the DNSOP working
|
|
group, however the main concern of these documents is the implementa-
|
|
tion and limitations of the DNS security extensions, hence their
|
|
interest to the DNS security community. The CAIRN draft deals with
|
|
the implementation of a secure DNS, and the draft on key rollover
|
|
deals with updating DNS keys in a secure fashion. Authors of docu-
|
|
ments that deal with the implementation and operational side of the
|
|
DNSSEC specifications would be advised/encouraged to submit their
|
|
documents to the DNSEXT working group as well.
|
|
|
|
|
|
3. Relationship of DNS Security Documents to other DNS Documents
|
|
|
|
The DNS security related extensions should be considered a subset of
|
|
the DNS protocol. The DNS Security working group of the IETF
|
|
(DNSSEC) has been absorbed into the larger DNS Extensions working
|
|
group (DNSEXT). Therefore, all DNS security related documents should
|
|
be seen as a subset of the main DNS architecture documents. It is a
|
|
good idea for authors of future DNS security documents to be familiar
|
|
with the contents of these base protocol documents.
|
|
|
|
|
|
4. Recommended Content for new DNS Security Documents
|
|
|
|
Documents that seek to make additions or revisions to the DNS proto-
|
|
col to add security should follow common guidelines as to minimum
|
|
required content and structure. It is the purpose of this document
|
|
roadmap to establish criteria for content that any new DNS security
|
|
protocol specifications document SHOULD contain. This criteria
|
|
SHOULD be interpreted as a minimum set of information required/needed
|
|
in a document, any additional information regarding the specific
|
|
extension should also be included in the document. These criteria
|
|
are not officially part of the IETF guidelines regarding RFC/Internet
|
|
Drafts, but should be considered as guidance to promote uniformity to
|
|
working group documents.
|
|
|
|
Since the addition of security to the DNS protocol is now considered
|
|
A general extension to the DNS protocol, any guideline for the con-
|
|
tents of a DNS Security document could be taken as a suggestion for
|
|
the contents of any DNS extension document.
|
|
|
|
|
|
|
|
|
|
Rose [Page 6]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
4.1 Security Related Resource Records
|
|
|
|
Documents describing a new type of DNS Security Resource Record (RR)
|
|
should contain information describing the structure and use of the
|
|
new RR type. It is a good idea to only discuss one new type in a
|
|
document, unless the set of new resource records are closely related
|
|
or a protocol extensions requires the use of more than one new record
|
|
type. Specifically: each document detailing a new Security related
|
|
RR type should include the following information:
|
|
|
|
* The format of the new RR type, both "on the wire" (bit format) and
|
|
ASCII representation (for text zone files), if appropriate.
|
|
|
|
* When and in what section of a DNS query/response this new RR type
|
|
is to be included.
|
|
|
|
* At which level of the DNS hierarchy this new RR type is to be
|
|
considered authoritative (i.e. in a zone, in a zone's superzone) and
|
|
who is authoritative to sign the new RR.
|
|
|
|
|
|
4.2 Digital Signature Algorithm Implementations
|
|
|
|
Documents describing the implementation details of a specific digital
|
|
signature algorithm such as [RFC 2536, RFC 2537] for use with DNS
|
|
Security should include the following information:
|
|
|
|
* The format/encoding of the algorithm's public key for use in a
|
|
KEY Resource Record.
|
|
|
|
* The acceptable key size for use with the algorithm.
|
|
|
|
* The current known status of the algorithm (as one of REQUIRED,
|
|
RECOMMENDED, or OPTIONAL).
|
|
|
|
In addition, authors are encouraged to include any necessary descrip-
|
|
tion of the algorithm itself, as well as any know/suspected
|
|
weaknesses as an appendix to the document. This is for reference
|
|
only, as the goals of the DNSEXT working group is to propose exten-
|
|
sions to the DNS protocol, not cryptographic research.
|
|
|
|
|
|
4.3 Refinement of Security Procedures
|
|
|
|
This set of documents includes DNS protocol operations that relate to
|
|
DNS Security specifically such as DNS secret key establishment [TKEY]
|
|
and security extensions to pre-existing or proposed DNS operations
|
|
such as dynamic update [RFC2137]. Documents that describe a new set
|
|
|
|
|
|
|
|
Rose [Page 7]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
of DNS message transactions, or seek to refine a current series of
|
|
transaction that make up a DNS operation SHOULD include the following
|
|
information:
|
|
|
|
* The order in which the DNS messages are sent by the operation ini-
|
|
tiator and target.
|
|
|
|
* The format of these DNS messages.
|
|
|
|
* Any required authentication mechanisms for each stage of the
|
|
operation and the required authority for that mechanism (i.e. zone,
|
|
host, or some other trusted authority such as a DNS administrator or
|
|
certificate authority).
|
|
|
|
|
|
4.4 The Use of DNS Security Extensions with Other Protocols
|
|
|
|
Because of the flexibility and ubiquity of the DNS, there may exist
|
|
other Internet protocols and applications that could make use of, or
|
|
extend, the DNS security protocols. Examples of this type of docu-
|
|
ment include the use of DNS to support the Public Key Infrastructure
|
|
(PKI). It is beyond the scope of this roadmap to describe the con-
|
|
tents of this class of documents. However, if uses or extensions
|
|
require the addition or modification of a DNS Resource Record type or
|
|
DNS query/response transactions, then the guidelines laid out in the
|
|
previous sections of this document SHOULD be adhered too.
|
|
|
|
|
|
5. Security Considerations
|
|
|
|
This document provides a roadmap and guidelines for writing DNS Secu-
|
|
rity related documents. The reader should follow all the security
|
|
procedures and guidelines described in the DNS Security Extensions
|
|
document [RFC2535].
|
|
|
|
|
|
6. Acknowledgements
|
|
|
|
In addition to the RFCs mentioned in this document, there are also
|
|
numerous Internet drafts that fall in one or more of the categories
|
|
of DNS Security documents mentioned above. Depending on where (and
|
|
if) these documents are on the IETF standards track, the reader may
|
|
not be able to access these documents through the RFC repositories.
|
|
For that reason, the version of the Internet drafts that were refer-
|
|
enced in this document are given below:
|
|
|
|
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
|
|
dnsind-sigalgopt-00.txt>
|
|
|
|
|
|
|
|
Rose [Page 8]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
|
|
Status" <draft-ietf-dnsext-zone-status-03.txt>
|
|
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
|
|
Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
|
|
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
|
|
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt>
|
|
* UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic
|
|
Update". <draft-ietf-simple-secure-update-02.txt>
|
|
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver
|
|
message size requirements". <draft-ietf-dnsext-message-size-01.txt>
|
|
* GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS
|
|
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-01.txt>
|
|
* NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS
|
|
with Minimum Disclosure". <draft-jas-dnsext-no-01.txt>
|
|
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
|
|
<draft-ietf-dnsext-dnssec-okbit-01.txt>
|
|
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
|
|
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-02.txt>
|
|
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
|
|
Security Key Rollover" <draft-ietf-dnsopt-rollover-00.txt>.
|
|
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
|
|
ietf-dnsext-ad-is-secure-00.txt>
|
|
* OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" <draft-
|
|
kosters-dnsext-dnssec-opt-in-00.txt>
|
|
|
|
7. References
|
|
|
|
[RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC
|
|
2535, March 1999.
|
|
|
|
[RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys-
|
|
tem (DNS)", RFC 2537, March 1999.
|
|
|
|
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
|
|
(DNS)", RFC 2536, March 1999.
|
|
|
|
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
|
|
RFC 2137, April 1997.
|
|
|
|
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
|
|
Name System (DNS)", RFC 2539, March 1999.
|
|
|
|
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
|
|
Domain Name System (DNS)", RFC 2538, March 1999.
|
|
|
|
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
|
|
September 2000.
|
|
|
|
|
|
|
|
|
|
Rose [Page 9]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures
|
|
(SIG(0))" RFC 2931, September 2000.
|
|
|
|
[RFC1591] J. Postal, "Domain Name System Structure and Delegation",
|
|
RFC 1591, March 1994.
|
|
|
|
[RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specification",
|
|
RFC 2181, July 1997.
|
|
|
|
[RFC2541] D. Eastlake, "DNS Security Operational Considerations", RFC
|
|
541, March 1999.
|
|
|
|
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, and B. Wellington.
|
|
"Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845,
|
|
May 2000.
|
|
|
|
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
|
|
ment Levels", RFC-2119, March 1997.
|
|
|
|
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
|
|
Update". RFC 3007, November 2000.
|
|
|
|
[RFC3008] B. Wellington, "Domain Name System Security (DNSSEC) Sign-
|
|
ing Authority". RFC 3008, November 2000.
|
|
|
|
|
|
|
|
|
|
8. Authors' Addresses
|
|
|
|
Scott Rose
|
|
National Institute for Standards and Technology
|
|
Gaithersburg, MD
|
|
Email: scott.rose@nist.gov
|
|
|
|
|
|
|
|
Expiration and File Name:
|
|
|
|
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-01.txt> expires June 2001
|
|
|
|
|
|
|
|
Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
|
|
|
|
|
|
Rose [Page 10]
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET-DRAFT DNS Security Document Roadmap January 2001
|
|
|
|
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of develop-
|
|
ing Internet standards in which case the procedures for copyrights
|
|
defined in the Internet Standards process must be followed, or as
|
|
required to translate it into languages other than English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns.
|
|
|
|
This document and the information contained herein is provided on an
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
TASK FORCE DISCLAIMS 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 MER-
|
|
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rose [Page 11]
|
|
|
|
|