WDIFF

draft-ietf-enum-combined-05.txt --> draft-ietf-enum-combined-06.txt

ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft R. Stastny O. Lendl
Intended status: Informational Oefeg enum.at
Expires: December 15, 2007 June 13, January 27, 2008 R. Stastny
Oefeg
July 26, 2007

Combined User and Infrastructure ENUM in the e164.arpa tree
draft-ietf-enum-combined-05
draft-ietf-enum-combined-06

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
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.

This Internet-Draft will expire on December 15, 2007. January 27, 2008.

Abstract

This memo defines an interim solution for Infrastructure ENUM to
allow a combined User and Infrastructure ENUM implementation in
e164.arpa as a national choice until the long-term solution is
approved. This interim solution will be deprecated after approval of
the long-term solution.

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 1]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 3

4. Leveraging the e164.arpa infrastructure The Algorithm . . . . . . . . . . . . . 4

5. Locating the Infrastructure ENUM Branch . . . . . . . . . . . 4

5. Determing the Position of the IEBL Record Branch . . . . . . . . . . . . . 5

6. Transition to the long-term Solution . . . . 5

7. Recommended resolver behaviour . . . . . . . . . 6

7. Examples . . . . . . . . 6

8. Security considerations . . . . . . . . . . . . . . . . . . . 7

9. IANA

8. Security considerations . . . . . . . . . . . . . . . . . . . . . 8

10. Interoperability

9. IANA considerations . . . . . . . . . . . . . . . 8

11. Acknowledgements . . . . . . 9

10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9

12.

11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1.
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2.
11.2. Informative References . . . . . . . . . . . . . . . . . 9

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 2]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

1. Introduction

ENUM (E.164 Number Mapping, RFC 3761 [2]) [1]) is a system that transforms
E.164 numbers [3] [2] into domain names and then uses DNS (Domain Name
Service) [6] [3] services like delegation through Name Server (NS)
records and NAPTR (Naming Authority Pointer) records [4] to look up
which services are available for a specific domain name.

ENUM as defined in RFC 3761 (User-ENUM) is not well suited for the
purpose of interconnection by carriers and voice service providers,
as can be seen by the use of various private tree arrangements based
on ENUM mechanisms.

Infrastructure ENUM is defined as the use of the technology in RFC
3761 [2] [1] by the carrier-of-record [8] (Voice service provider) for a
specific E.164 number [3] [2] to map a telephone number into one or more
Uniform Resource Identifiers (URIs) [5].

These URIs will be used to derive specific points of interconnection
into the service provider's network that could enable the originating
party to establish communication with the associated terminating
party. These URIs are separate from any URIs that the end-user who
registers his E.164 number in ENUM may wish to associate with that
E.164 number.

The requirements, terms and definitions for Infrastructure ENUM are
defined in [8].

Using the same E.164 number to domain mapping techniques for other
applications under a different, internationally agreed apex (instead
of e164.arpa) is straightforward on the technical side. Establishing
the international agreements necessary to delegate the country-code
level subdomains under the new apex is non-trivial and time-
consuming. This process
of defining the Dynamic Delegation Discovery System (DDDS) [4]
application for Infrastructure ENUM is work in progress [9]. This is
called the long term solution.

2. Terminology

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 BCP 14, RFC 2119 [1]. [6].

3. Interim Solution

As stated above, the

The agreements to establish the long-term solution

Haberler & Stastny Expires December 15, 2007 [Page 3]

Internet-Draft Combined User and Infrastructure ENUM June 2007 may take some
time. It was therefore decided to develop an Interim Solution that
can be used by individual countries to implement an interoperable

Haberler, et al. Expires January 27, 2008 [Page 3]

Internet-Draft Combined User and Infrastructure ENUM July 2007

Infrastructure ENUM tree immediately. The Interim Solution will be
deprecated upon approval (loosely timed) of the long-term solution.
It is therefore also required that the Interim Solution includes a
smooth migration path to the long-term solution.

It is also required that existing ENUM clients querying User ENUM as
defined in RFC 3761 [2] [1] continue to work without any modification.

Because of various reasons, sharing a single domain name between the
user itself and the respective carrier for a number is not possible.
Hence, a different domain name must be used to store infrastructure
ENUM information.

In order to avoid the delays associated with the long term solution,
the existing delegations and agreements around e164.arpa need to be
leveraged.

The method most easily fulfilling this the requirements is to branch off
the e164.arpa tree into a subdomain at or somewhere below the country code delegation
level below e164.arpa, and deploy an Infrastructure ENUM subtree
underneath without touching User ENUM semantics at all.

4. Leveraging the e164.arpa infrastructure

A convention is needed how, given a fully qualified E.164 number [3],

This allows countries using a resolver can determine the location of the Infrastructure ENUM
domain for this number. In order dedicated country code to avoid the delays associated with introduce the long term solution,
Interim Solution as a national matter by the existing delegations concerned National
Regulation Authority (NRA). The governing body of a shared country
code and agreements
around e164.arpa need to be leveraged for the discovery algorithm. owner of a global network code can also chose to
implement this solution within their area of responsibility.

Under this approach, ITU-T and IETF (IAB) involvement is only
lightweight, e.g. to recommend the proper algorithm defined here to
enable international interoperability.

This allows to introduce the Interim Solution as a national matter by
the concerned National Regulation Authority (NRA) or

4. The Algorithm

RFC 3761 defines ENUM as a regional
opt-in within in a given Numbering Plan Area (NPA) such as Dynamic Delegation Discovery System (DDDS)
application according to RFC 3401 [4]. As such, ENUM defines the North
American NPA.

Beyond
following components of the setup phase, an NRA need not be involved operationally -
it is sufficient to establish a convention linking DDDS algorithm:

1. Application Unique String
2. First Well Known Rule
3. Expected Output
4. Valid Databases

The "Valid Databases" part contains the national
definition transformation of a carrier E.164
telephone number into a domain name. Section 2.4 of record to the credentials for write access
to the Infrastructure ENUM tree.

5. Locating the Infrastructure ENUM Branch

[7] specifies an extension to RFC 3761 uses
the ENUM DDDS application which adds an
extra mapping following four step using a DNS resource record (Infrastructure ENUM

Haberler & Stastny algorithm for this:

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 4]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

Branch Location - IEBL) to

1. Remove all characters with the E.164 to domain-name translation
algorithm.

The decision where to place exception of the Infrastructure ENUM tree is a
national or group-of-countries decision. The IEBL affecting digits.
2. Put dots (".") between each digit.
3. Reverse the
translation order of any E.164 number thus needs the digits.
4. Append the string ".e164.arpa" to reside under the
e164.arpa tree end.

The Interim Solution for the country code Infrastructure ENUM uses a modified version
of that number.

The IEBL contains the following parameters: this algorithm:

1. a SEPARATOR,
2. a POSITION,
3. an APEX.

Together, these three parameters describe Determine the tree shape proper POSITION parameter for a
country's Infrastructure ENUM tree this E.164 number
according to the Interim Solution.
These parameters provide enough flexibility to describe setups
ranging algorithm in Section 5.

2. Build an ordered list of single-digit strings from branches under e164.arpa at NPA level, branches at
country-code level, independent trees per country, and also all digits
appearing in the long-
term solution.

o Existence telephone number. All non-digit characters are
ignored.

3. Insert a string consisting of "i" after POSITION strings into
this list. If the IEBL Record: The national or group-of-country's
decision to implement the Interim Solution is documented in the
e164.arpa tree by inserting list of strings was shorter than POSITION
elements, then report an IEBL resource record at error.

4. Reverse the country
code level.

o SEPARATOR: This branching label will be inserted into order of the ENUM
domain list.

5. Append the string "e164.arpa" to branch off from the User-ENUM tree into end of the
Infrastructure ENUM sub-tree. This MAY be an empty (zero-length)
string which means no label will be inserted.

o POSITION: A number indicating after which digit this label
(SEPARATOR) should be inserted. A value list.

6. Create a single domain-name by joining the list together with
dots (".") between each string.

5. Determing the Position of 0 means the Branch

In order to allow for the right deployment of all digits.

o APEX: A domain name indicating what domain replaces "e164.arpa"
for this application. "e164.arpa" MAY also Interim Solution
independently of IAB/ITU/RIPE negotiations the branching label "i"
cannot be replaced inserted in the Tier-0 zone (i.e. the e164.arpa zone
itself) managed by itself.

o The IEBL record is extremely well suited for caching: The layout
of RIPE NCC. This condition acts as a country's Infrastructure ENUM setup is very static
information, allowing large TTLs lower bound on
the IEBL records. Overall,
the number choice of possible IEBL records in the DNS is bounded by POSITION parameter.

For international E.164-numbers for geographic areas ([2] 6.2.1) and
for international E.164-numbers for global services ([2] 6.2.2) the
most sensible choice for POSITION is number of countries, which digits in combination means very high cache
hit rates.

6. Position the country
code of the IEBL Record

The EBL record for Infrastructure ENUM (IEBL), as defined in [7]), is

Haberler & Stastny Expires December 15, 2007 [Page 5]

Internet-Draft Combined User and Infrastructure ENUM June 2007

stored number in question. This places the DNS at branch directly
under the country code level within the e164.arpa ENUM tree.

If a country or group-of-countries decides to implement the interim
solution

For international E.164-number for Infrastructure ENUM, then it SHALL put an IEBL record at networks ([2] 6.2.3) the level of individual country codes as assigned by ITU-T.

The same algorithm applies
appropriate choice for non-geographic country codes (global
services, e.g. +800, +878, +808 or networks, e.g. +882): If I-ENUM POSITION is
introduced for these numbers, the IEBL record SHALL be stored at
X.Y.Z.e164.arpa, even if combined length of the Tier-1 delegation CC
(Country Code) and IC (Identification Code) fields.

For international E.164-number for groups of countries ([2] 6.2.4)
the value for POSITION is not at 4. Please note that level
in country code 1 of the ENUM tree.

The only remaining a-priori knowledge an
North American Numbering Plan (NANP) does not fall under the ITU

Haberler, et al. Expires January 27, 2008 [Page 5]

Internet-Draft Combined User and Infrastructure ENUM resolver
needs to have is the current list July 2007

classification of "groups of countries", but is a "shared country codes, or an equivalent
method to determine where the country code in the number ends.
code" for a geographic area.

The authoritative source for up-to-date country code and network
Identity Code allocations is published by ITU-T as complement to the
recommendation E.164 [3]. [2]. The current version of this complement is
available from ITU website under "ITU-T / Service Publications".

As of 2007, the country code length POSITION value for a specific E.164 number can be
determined with the following simple algorithm:

o 3 digits is If the default length of a country code.
o country codes number starts with 1 or 7 then POSITION is 1 and 7 are a single digit.
o If the number is in one of the following 2-digit country codes are two digits: codes:
20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84,
86, 90-95, 98. or 98, then POSITION is 2.
o If the number starts with 388 or 881, then POSITION is 4
o If the number starts with 878 or 882, then POSITION is 5
o In all other cases, POSITION is 3.

Figure 1

Given the fact that the ITU-T recently allocated only 3-digit country
codes, there are no more spare 1- and 2-digit country codes and
existing 1- and 2-digit country codes are extremely unlikely to be
recovered, the above table consisting list of the existing 1- and 2-digit country codes
can be considered very stable. The only problem may be a country
split as happened recently e.g. to Yugoslavia.

Examples can be found

Regarding network codes, the ITU has up to now only allocated one and
two digit ICs while the standard allows up to 4 digits. A change in [7]

7. Recommended resolver behaviour

An User ENUM resolver as per RFC 3761
the ITU policy in this respect will need not to be aware of any reflected in the above
algorithm.

6. Transition to the long-term Solution

The proposed long-term solution for Infrastructure ENUM conventions at all. A combined User [9] is the
the establishment of a new zone apex for that tree. This apex will
play the same role as "e164.arpa" does for User-ENUM.

It is unrealistic to assume that all countries and
Infrastructure all ENUM resolver shall behave as follows:

Haberler & Stastny clients
will manage to migrate from the Interim Solution to the long-term
solution at single point in time. It is thus necessary to plan for
an incremental transition.

In order to achieve this, clients using the interim solution need to
be redirected to the long-term I-ENUM tree for all country codes

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 6]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

The input

which have already switched to the resolver routine shall be:
1. long-term solution. This SHOULD
be done by placing DNAME [7]. records at the E.164 number branch (the "i") label
pointing to the appropriate domain name in fully qualified (international) format,
2. a mode parameter indicating whether resolution should follow User
ENUM the long-term I-ENUM tree.
All descendants at that branch label location where the DNAME record
is inserted MUST be removed as required by Section 3 of RFC 2672.

Therefore ALL entities involved in making or Infrastructure ENUM rules,
3. optionally answering DNS queries
for I-ENUM MUST fully support the DNAME record type and its
semantics. In particular, entities involved in I-ENUM lookups MUST
correctly handle responses containing synthesized CNAMEs that may be
generated as a table or algorithm to calculate country code lengths
(Section 6),
4. consequence of DNAME processing by any other parameters used to drive the search, for instance element
in resolution, typically an
enumservice type. iterative mode resolving name server.
These parameters are outside the scope entities MUST also apply adequate measures to detect loops and
prevent non-terminating resolutions because of improperly configured
DNAME records or combinations of this
draft. DNAME and CNAME records.

The resolver shall proceed as follows:
o If the mode parameter indicates a User ENUM search, proceed as per
RFC 3761.
o If domain name for the mode parameter indicates an Infrastructure ENUM query:
* Determine country code length, branch location and thus its DNAME record SHOULD
be removed once the location of transition to the
IEBL record.
* Check for a cached IEBL lookup result.
* If no cached result long-term solution is present:

Retrieve the IEBL record from the country code zone, completed
and store
the result all entities involved in a cache. For positive result, normal DNS caching
semantics apply. For negative results, it is RECOMMENDED that I-ENUM have migrated to the new zone
apex for I-ENUM.

7. Examples

These are two examples of how E.164 numbers translate to to
Infrastructure ENUM client sets the caching timeout domains according to 24 hours.
* If no IEBL the Interim Solution.

+1 21255501234 4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa
+44 2079460123 3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa

Here is present at the calculated position in list of the DNS,
return an error.
* If an IEBL was found, construct a domain name according intermediate steps for the second example to
visualize how the algorithm given as defined in [7].
* Search Section 4 operates on "+44
2079460123":

1. "+44 2079460123" is within a 2-digit country code, thus POSITION
is 2.

2. The list of strings is
("4","4","2","0","7","9","4","6","0","1","2","3").

3. POSITION is 2, thus "i" is inserted between the DNS for any ENUM NAPTR records for second and the resulting
domain name.

It is assumed that
third string, yielding:
("4","4","i","2","0","7","9","4","6","0","1","2","3")

4. Reversing the location list gives:
("3","2","1","0","6","4","9","7","0","2","i","4","4")

Haberler, et al. Expires January 27, 2008 [Page 7]

Internet-Draft Combined User and Infrastructure ENUM July 2007

5. Appending "e164.arpa" yields:
("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")

6. Concatenation with dots: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"

After the introduction of the long term Infrastructure ENUM tree solution
using for
each country will be rather static. Extensive caching example "ienum.example.net" as the new apex for I-ENUM, the
administrators of discovered
IEBL records (and +44 can implement a smooth transition by putting
the following DNAME record in their absence) is thus recommended. zone:

i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net.

This way, clients using the interim I-ENUM solution end up querying
the same tree as clients implementing the long-term solution.

8. Security considerations

Privacy issues have been raised regarding unwarranted disclosure of
user information by publishing Infrastructure ENUM information in the
public DNS, for instance the use for harvesting of numbers in
service, or unlisted numbers.

Given that number range allocation is public information, we believe
the easiest way to cope with such concerns is to fully unroll
allocated number ranges in the Infrastructure ENUM subtree, wherever
such privacy concerns exist. Whether a number is served or not would
be exposed by the carrier of record when an attempt is made to
contact the corresponding URI. We assume this to be an authenticated

Haberler & Stastny Expires December 15, 2007 [Page 7]

Internet-Draft Combined User and Infrastructure ENUM June 2007 the corresponding URI. We assume this to be an authenticated
operation, which would not leak information to unauthorized parties.

Entering all numbers in an allocated number range, whether serviced
or not, or listed or unlisted, will prevent mining attempts for such
number attributes.

The result would be that the information in the public DNS would
mirror number range allocation information, but not more.
Infrastructure ENUM will not tell you more than you can get by just
dialing numbers.

The URI pointing to the destination network of the Carrier of Record
should also not disclose any privacy information about the identity
of end-user. It is therefore recommended to use either anonymized
UserIDs or the E.164 number itself in the user-part of the URI, such
as in sip:+441632960084@example.com .

The usage of the Branch Location record conveys only static setup
information under a country code subtree of e164.arpa. The intended
use of DNS Security Extensions (DNSSEC) within ENUM will prove
authenticity of the conveyed value.

9. IANA considerations

None.

10. Interoperability considerations

An application using the combined resolver needs to indicate which
information is requested - User or Infrastructure ENUM, or both. A
user-ENUM-only resolver need not be aware of the Infrastructure ENUM
subtree and no changes with respect to RFC 3761 semantics are
required. A resolver desiring to retrieve Infrastructure ENUM or
both types of records needs to be aware of the conventions laid out
in this draft.

When the long-term solution is adopted, each country using the
interim solution may decide on its own when to migrate to the long-
term solution. The IEBL records for this country would then be
changed to the values "position=0", "separator="" and
"apex=example.com" (whatever is defined). When finally all countries
have migrated, the IEBL records may be removed.

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 8]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

11. Acknowledgements

9. IANA considerations

None.

10. Acknowledgments

We gratefully acknowledge suggestions and improvements by Jason
Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence
Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer and Otmar
Lendl of
enum.at.

12.

11. References

12.1.

11.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.

[3]

[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, February 2005.

[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.

[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.

[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.

[6] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 1034, November 1987. 2119, March 1997.

[7] Lendl, O., "The ENUM Branch Location Record",
draft-ietf-enum-branch-location-record-03 (work in progress),
June 2007.

12.2. Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.

11.2. Informative References

[8] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-04 (work in progress),
May 2007.

[9] Livingood, J., "The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application for
Infrastructure ENUM", draft-ietf-enum-infrastructure-05 (work in
progress), January 2007.

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 9]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

Infrastructure ENUM", draft-ietf-enum-infrastructure-05 (work in
progress), January 2007.

Authors' Addresses

Michael Haberler
Internet Foundation Austria
Waehringerstrasse 3/19
Wien A-1090
Austria

Phone: +43 664 4213465
Email: mah@inode.at
URI: http://www.nic.at/ipa/

Otmar Lendl
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria

Phone: +43 1 5056416 33
Email: otmar.lendl@enum.at
URI: http://www.enum.at/

Richard Stastny
Oefeg
Postbox 147
Vienna A-1030
Austria

Phone: +43 664 420 4100
Email: richard.stastny@oefeg.at
URI: http://www.oefeg.at

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 10]

Internet-Draft Combined User and Infrastructure ENUM June July 2007

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Haberler & Stastny

Haberler, et al. Expires December 15, 2007 January 27, 2008 [Page 11]

----