draft-ietf-dnsext-unknown-rrs-06.txt   rfc3597.txt 
INTERNET-DRAFT Andreas Gustafsson Network Working Group A. Gustafsson
draft-ietf-dnsext-unknown-rrs-06.txt Nominum Inc. Request for Comments: 3597 Nominum Inc.
June 2003 Category: Standards Track September 2003
Updates: RFC 1034, RFC 2163, RFC 2535
Handling of Unknown DNS Resource Record Types Handling of Unknown DNS Resource Record (RR) Types
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
Extending the Domain Name System with new Resource Record (RR) types Extending the Domain Name System (DNS) with new Resource Record (RR)
currently requires changes to name server software. This document types currently requires changes to name server software. This
specifies the changes necessary to allow future DNS implementations document specifies the changes necessary to allow future DNS
to handle new RR types transparently. implementations to handle new RR types transparently.
1. Introduction 1. Introduction
The DNS is designed to be extensible to support new services through The DNS is designed to be extensible to support new services through
the introduction of new resource record (RR) types. In practice, the introduction of new resource record (RR) types. In practice,
deploying a new RR type currently requires changes to the name server deploying a new RR type currently requires changes to the name server
software not only at the authoritative DNS server that is providing software not only at the authoritative DNS server that is providing
the new information and the client making use of it, but also at all the new information and the client making use of it, but also at all
slave servers for the zone containing it, and in some cases also at slave servers for the zone containing it, and in some cases also at
caching name servers and forwarders used by the client. caching name servers and forwarders used by the client.
Because the deployment of new server software is slow and expensive, Because the deployment of new server software is slow and expensive,
the potential of the DNS in supporting new services has never been the potential of the DNS in supporting new services has never been
fully realized. This memo proposes changes to name servers and to fully realized. This memo proposes changes to name servers and to
procedures for defining new RR types aimed at simplifying the future procedures for defining new RR types aimed at simplifying the future
deployment of new RR types. deployment of new RR types.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2. Definition 2. Definition
An "RR of unknown type" is an RR whose RDATA format is not known to An "RR of unknown type" is an RR whose RDATA format is not known to
the DNS implementation at hand, such that it cannot be converted to a the DNS implementation at hand, and whose type is not an assigned
type-specific text format, compressed, or otherwise handled in a QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
type-specific way, and whose type is not an assigned QTYPE or Meta- within the range reserved in that section for assignment only to
TYPE in RFC2929 section 3.1 nor within the range reserved in that QTYPEs and Meta-TYPEs. Such an RR cannot be converted to a type-
section for assignment only to QTYPEs and Meta-TYPEs. specific text format, compressed, or otherwise handled in a type-
specific way.
In the case of a type whose RDATA format is class specific, an RR is In the case of a type whose RDATA format is class specific, an RR is
considered to be of unknown type when the RDATA format for that considered to be of unknown type when the RDATA format for that
combination of type and class is not known. combination of type and class is not known.
3. Transparency 3. Transparency
To enable new RR types to be deployed without server changes, name To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently. servers and resolvers MUST handle RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs as That is, they must treat the RDATA section of such RRs as
unstructured binary data, storing and transmitting it without change unstructured binary data, storing and transmitting it without change
[RFC1123]. [RFC1123].
To ensure the correct operation of equality comparison (section 6) To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known and of the DNSSEC canonical form (section 7) when an RR type is known
to some but not all of the servers involved, servers MUST also to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of due to compression or decompression where allowed by section 4 of
this memo. In particular, the character case of domain names that this memo. In particular, the character case of domain names that
are not subject to compression MUST be preserved. are not subject to compression MUST be preserved.
4. Domain Name Compression 4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message, pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed which now contains unrelated data. This would cause the compressed
name to be corrupted. name to be corrupted.
To avoid such corruption, servers MUST NOT compress domain names To avoid such corruption, servers MUST NOT compress domain names
embedded in the RDATA of types that are class-specific or not well- embedded in the RDATA of types that are class-specific or not well-
known. This requirement was stated in RFC1123 without defining the known. This requirement was stated in [RFC1123] without defining the
term "well-known"; it is hereby specified that only the RR types term "well-known"; it is hereby specified that only the RR types
defined in RFC1035 are to be considered "well-known". defined in [RFC1035] are to be considered "well-known".
The specifications of a few existing RR types have explicitly allowed The specifications of a few existing RR types have explicitly allowed
compression contrary to this specification: RFC2163 specified that compression contrary to this specification: [RFC2163] specified that
compression applies to the PX RR, and RFC2535 allowed compression in compression applies to the PX RR, and [RFC2535] allowed compression
SIG RRs and NXT RRs records. Since this specification disallows in SIG RRs and NXT RRs records. Since this specification disallows
compression in these cases, it is an update to RFC2163 (section 4) compression in these cases, it is an update to [RFC2163] (section 4)
and RFC2535 (sections 4.1.7 and 5.2). and [RFC2535] (sections 4.1.7 and 5.2).
Receiving servers MUST decompress domain names in RRs of well-known Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, NAPTR, and SRV (although the current specification of the SRV RR NXT, NAPTR, and SRV (although the current specification of the SRV RR
in RFC2782 prohibits compression, RFC2052 mandated it, and some in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
servers following that earlier specification are still in use). servers following that earlier specification are still in use).
Future specifications for new RR types that contain domain names Future specifications for new RR types that contain domain names
within their RDATA MUST NOT allow the use of name compression for within their RDATA MUST NOT allow the use of name compression for
those names, and SHOULD explicitly state that the embedded domain those names, and SHOULD explicitly state that the embedded domain
names MUST NOT be compressed. names MUST NOT be compressed.
As noted in RFC1123, the owner name of an RR is always eligible for As noted in [RFC1123], the owner name of an RR is always eligible for
compression. compression.
5. Text Representation 5. Text Representation
In the "type" field of a master file line, an unknown RR type is In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field, type number, with no intervening whitespace. In the "class" field,
an unknown class is similarly represented as the word "CLASS" an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number. immediately followed by the decimal class number.
This convention allows types and classes to be distinguished from This convention allows types and classes to be distinguished from
each other and from TTL values, allowing the "[<TTL>] [<class>] each other and from TTL values, allowing the "[<TTL>] [<class>]
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
RFC1035 to both be unambiguously parsed. [RFC1035] to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows: sequence of white space separated words as follows:
The special token \# (a backslash immediately The special token \# (a backslash immediately followed by a hash
followed by a hash sign), which identifies the sign), which identifies the RDATA as having the generic encoding
RDATA as having the generic encoding defined defined herein rather than a traditional type-specific encoding.
herein rather than a traditional type-specific
encoding.
An unsigned decimal integer specifying the An unsigned decimal integer specifying the RDATA length in octets.
RDATA length in octets.
Zero or more words of hexadecimal data encoding Zero or more words of hexadecimal data encoding the actual RDATA
the actual RDATA field, each containing an even field, each containing an even number of hexadecimal digits.
number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length. the \# token and the single zero representing the length.
An implementation MAY also choose to represent some RRs of known type An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file RDATA, which carries the benefit of making the resulting master file
portable to servers where these types are unknown. Using the generic portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies useful in the case of an RR type where the text format varies
skipping to change at page 4, line 36 skipping to change at page 4, line 26
Even though an RR of known type represented in the \# format is Even though an RR of known type represented in the \# format is
effectively treated as an unknown type for the purpose of parsing the effectively treated as an unknown type for the purpose of parsing the
RDATA text representation, all further processing by the server MUST RDATA text representation, all further processing by the server MUST
treat it as a known type and take into account any applicable type- treat it as a known type and take into account any applicable type-
specific rules regarding compression, canonicalization, etc. specific rules regarding compression, canonicalization, etc.
The following are examples of RRs represented in this manner, The following are examples of RRs represented in this manner,
illustrating various combinations of generic and type-specific illustrating various combinations of generic and type-specific
encodings for the different fields of the master file format: encodings for the different fields of the master file format:
a.example. CLASS32 TYPE731 \# 6 abcd ( a.example. CLASS32 TYPE731 \# 6 abcd (
ef 01 23 45 ) ef 01 23 45 )
b.example. HS TYPE62347 \# 0 b.example. HS TYPE62347 \# 0
e.example. IN A \# 4 0A000001 e.example. IN A \# 4 0A000001
e.example. CLASS1 TYPE1 10.0.0.2 e.example. CLASS1 TYPE1 10.0.0.2
6. Equality Comparison 6. Equality Comparison
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are to be compared for equality. Two RRs of the same unknown type are
considered equal when their RDATA is bitwise equal. To ensure that considered equal when their RDATA is bitwise equal. To ensure that
the outcome of the comparison is identical whether the RR is known to the outcome of the comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify the server or not, specifications for new RR types MUST NOT specify
type-specific comparison rules. type-specific comparison rules.
This implies that embedded domain names, being included in the This implies that embedded domain names, being included in the
overall bitwise comparison, are compared in a case-sensitive manner. overall bitwise comparison, are compared in a case-sensitive manner.
As a result, when a new RR type contains one or more embedded domain As a result, when a new RR type contains one or more embedded domain
names, it is possible to have multiple RRs owned by the same name names, it is possible to have multiple RRs owned by the same name
that differ only in the character case of the embedded domain that differ only in the character case of the embedded domain
name(s). This is similar to the existing possibility of multiple TXT name(s). This is similar to the existing possibility of multiple TXT
records differing only in character case, and not expected to cause records differing only in character case, and not expected to cause
any problems in practice. any problems in practice.
7. DNSSEC Canonical Form and Ordering 7. DNSSEC Canonical Form and Ordering
DNSSEC defines a canonical form and ordering for RRs [RFC2535, DNSSEC defines a canonical form and ordering for RRs [RFC2535]
section 8.1]. In that canonical form, domain names embedded in the (section 8.1). In that canonical form, domain names embedded in the
RDATA are converted to lower case. RDATA are converted to lower case.
The downcasing is necessary to ensure the correctness of DNSSEC The downcasing is necessary to ensure the correctness of DNSSEC
signatures when case distinctions in domain names are lost due to signatures when case distinctions in domain names are lost due to
compression, but since it requires knowledge of the presence and compression, but since it requires knowledge of the presence and
position of embedded domain names, it cannot be applied to unknown position of embedded domain names, it cannot be applied to unknown
types. types.
To ensure continued consistency of the canonical form of RR types To ensure continued consistency of the canonical form of RR types
where compression is allowed, and for continued interoperability with where compression is allowed, and for continued interoperability with
existing implementations that already implement the RFC2535 canonical existing implementations that already implement the [RFC2535]
form and apply it to their known RR types, the canonical form remains canonical form and apply it to their known RR types, the canonical
unchanged for all RR types whose whose initial publication as an RFC form remains unchanged for all RR types whose whose initial
was prior to the initial publication of this specification as an RFC publication as an RFC was prior to the initial publication of this
(RFC TBD). specification as an RFC (RFC 3597).
As a courtesy to implementors, it is hereby noted that the complete As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons, downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6. DNAME, and A6.
This document specifies that for all other RR types (whether treated This document specifies that for all other RR types (whether treated
as unknown types or treated as known types according to an RR type as unknown types or treated as known types according to an RR type
definition RFC more recent than than RFC TBD), the canonical form is definition RFC more recent than RFC 3597), the canonical form is such
such that no downcasing of embedded domain names takes place, and that no downcasing of embedded domain names takes place, and
otherwise identical to the canonical form specified in RFC2535 otherwise identical to the canonical form specified in [RFC2535]
section 8.1. section 8.1.
Note that the owner name is always set to lower case according to the Note that the owner name is always set to lower case according to the
DNS rules for character comparisons, regardless of the RR type. DNS rules for character comparisons, regardless of the RR type.
The DNSSEC canonical RR ordering is as specified in RFC2535 section The DNSSEC canonical RR ordering is as specified in [RFC2535] section
8.3, where the octet sequence is the canonical form as revised by 8.3, where the octet sequence is the canonical form as revised by
this specification. this specification.
8. Additional Section Processing 8. Additional Section Processing
Unknown RR types cause no additional section processing. Future RR Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section type specifications MAY specify type-specific additional section
processing rules, but any such processing MUST be optional as it can processing rules, but any such processing MUST be optional as it can
only be performed by servers for which the RR type in case is known. only be performed by servers for which the RR type in case is known.
9. IANA Considerations 9. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
10. Security Considerations 10. Security Considerations
This specification is not believed to cause any new security This specification is not believed to cause any new security
problems, nor to solve any existing ones. problems, nor to solve any existing ones.
Normative References 11. Normative References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC1034] Mockapetris, P., "Domain Names - Concepts and
November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] - Domain Names - Implementation and Specifications, P. [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Mockapetris, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[RFC1123] - Requirements for Internet Hosts -- Application and [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
Support, R. Braden, Editor, October 1989. Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
S. Bradner, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] - Domain Name System Security Extensions. D. Eastlake, [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
March 1999. RFC 2535, March 1999.
[RFC2613] - Using the Internet DNS to Distribute MIXER Conformant [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute
Global Address Mapping (MCGAM), C. Allocchio, January 1998. MIXER Conformant Global Address Mapping (MCGAM)", RFC
2163, January 1998.
[RFC2929] - Domain Name System (DNS) IANA Considerations, D. [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning,
Eastlake, E. Brunner-Williams, B. Manning, September 2000. "Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
Non-normative References 12. Informative References
[RFC1876] - A Means for Expressing Location Information in the Domain [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January Means for Expressing Location Information in the Domain
1996. Name System", RFC 1876, January 1996.
[RFC2052] - A DNS RR for specifying the location of services (DNS [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782. the location of services (DNS SRV)", RFC 2052, October
1996.
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE), [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997. "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2782] - A DNS RR for specifying the location of services (DNS [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
SRV), A. Gulbrandsen, P. Vixie, L. Esibov, February 2000. specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Author's Address 13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14. Author's Address
Andreas Gustafsson Andreas Gustafsson
Nominum Inc. Nominum, Inc.
2385 Bay Rd 2385 Bay Rd
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 381 6004 Phone: +1 650 381 6004
EMail: gson@nominum.com
Email: gson@nominum.com 15. Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2001 - 2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Acknowledgement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any Funding for the RFC Editor function is currently provided by the
copyrights, patents or patent applications, or other proprietary Internet Society.
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
 End of changes. 54 change blocks. 
127 lines changed or deleted 126 lines changed or added

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