ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft R. Stastny
Expires: September 7, 2006 Oefeg
March 6, 2006
Combined User and Carrier ENUM in the e164.arpa tree
draft-haberler-carrier-enum-02
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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
ENUM as defined in RFC3761 [1] is not well suited for the purpose of
interconnection by carriers, as can be seen by the use of various
private tree arrangements based on ENUM mechanisms. A combined end-
user and carrier ENUM tree solution would leverage the ENUM
infrastructure in e164.arpa, increase resolution rates, and decrease
the cost per registered telephone number. This document describes a
minimally invasive scheme to provide both end-user and carrier data
Haberler & Stastny Expires September 7, 2006 [Page 1]
Internet-Draft Combined User and Carrier ENUM March 2006
in ENUM.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Carrier of Record . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Introducing a branch into the e164.arpa tree . . . . . . . . . 5
5. Resolver behaviour options and the Carrier ENUM branch
location . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Recommended resolver behaviour . . . . . . . . . . . . . . . . 8
7. Zone file examples . . . . . . . . . . . . . . . . . . . . . . 9
8. The Branch Location Record . . . . . . . . . . . . . . . . . . 13
9. Security considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Interoperability considerations . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Haberler & Stastny Expires September 7, 2006 [Page 2]
Internet-Draft Combined User and Carrier ENUM March 2006
1. Introduction
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms
E.164 numbers [2] into domain names and then uses DNS (Domain Name
Service) [3] services like delegation through NS records and NAPTR
records to look up what services are available for a specific domain
name.
ENUM as defined currently is based on the end-user opt-in principle.
While this has great potential to foster new services and end-user
choice in the long-term, the current requirements for IP-based
interconnection of carriers and VoIP Service Providers require the
provisioning of all allocated or served (hosted) numbers of a
participating carrier of record. This is especially necessary if
Carrier ENUM is used for number portability applications and accessed
eventually from the PSTN via mediation devices. An interconnection
scenario through Carrier ENUM typically also implies underlying
closed usage scenarios where URIs are used in authenticated context,
an assumption which cannot reasonably be imposed on User ENUM
entries, but are dealt with within the scope of SPEERMINT [5], for
instance through SIP federations and DNS-based policy announcement
[4].
While in principle solutions like compulsory opt-in through terms and
conditions for end users are conceivable, there are substantial
downsides to such an approach. ENUM for end-user provisioning
remains an ill-suited solution for the PoI (point-of-interconnect)
information discovery problem.
Both from an OPEX (Operational Expenditure) perspective as well as
overall resolution rates achievable through the given approach, a
combined ENUM tree both for end-users and carrier of record ENUM
stands to be superior over a forest of disparate private trees now as
well as long-term. Since the common infrastructure easily supports
both usage scenarios, a combined approach will support the end-user
ENUM vision by driving down the average cost per number. Lastly, a
later convergence between ENUM for end-users and carriers of record
will be significantly easier and cheaper, thus benefiting users as
well as carriers. For the rest of the document the terms User ENUM
and Carrier ENUM will be used to distinguish between the two
approaches. Note: The ENUM WG decided at IETF#64 to prefer the term
Infrastructure ENUM. For consistency, this document uses the term
Carrier ENUM as synonym.
2. The Carrier of Record
In User ENUM, the entity or person having the right-to-use of an
Haberler & Stastny Expires September 7, 2006 [Page 3]
Internet-Draft Combined User and Carrier ENUM March 2006
E.164 number has the sole discretion about the content of the
associated domain and thus the zone content.
Within a Carrier ENUM namespace, we use the term "carrier of record"
for the entity having that discretion. This right typically lies
with a service provider authorized to issue E.164 numbers for the
provisioning of PSTN service for this E.164 number under the
authority of a National Regulatory Authority (NRA), but generally
exhibits one or more of the following properties:
o it has been assigned one or more national number ranges by an NRA.
o it has been assigned a number range directly by the ITU, for
instance a code under "International Networks" (+882) or
"Universal Personal Telecommunications (UPT)" (+878).
o it can be the recipient of a number porting operation.
o it provides a PSTN point-of-interconnect for the number.
Carrier ENUM is understood to mean a form of ENUM where such entities
have exclusive discretion about zone content.
3. Requirements
A solution for combined User and Carrier ENUM within the e164.arpa
tree should meet the following requirements:
o A single DNS lookup should suffice to resolve any given number in
the public DNS in any given context, and under both scenarios.
o It should leave User ENUM resolution semantics and tree shape
intact, i.e. requiring no changes to existing User ENUM resolvers
or tree layout.
o Additional functionality should only be imposed on carrier ENUM
resolvers.
o It should work with both fixed and variable-length numbering plans
without resorting to wildcard records in the non-user controlled
part of the DNS, both to avoid associated semantic problems as
well as keeping the route to DNSSEC deployment open.
o It should not require the introduction of new constructs within
existing standards, such as new types or changed semantics of
NAPTR records.
o It should be possible to introduce the scheme in a timely manner,
supporting current carrier needs. Consequently, it is desirable
to deploy the scheme without re-opening already settled questions
of roles, responsibilities and international coordination, and in
particular the country code delegation process.
o It should meet all reasonable privacy concerns about visibility of
information an end user has no control over, for example discovery
of unlisted numbers, or inadvertent disclosure of user identity.
Haberler & Stastny Expires September 7, 2006 [Page 4]
Internet-Draft Combined User and Carrier ENUM March 2006
o It should keep the option open for other types of closed-user-
group type applications, which might not naturally fit into the -
predominantly voice oriented - Carrier ENUM scenario.
Note in particular that we assume all entries to properly resolve in
the public DNS, both user and carrier. Usage restrictions on Carrier
ENUM records are to be handled at the URI level, and not by
restriction on the visibility of entries in the public DNS. This is
within the scope of SPEERMINT.
4. Introducing a branch into the e164.arpa tree
The method most easily fulfilling the above mentioned requirements is
to branch off the e164.arpa tree into a subdomain at a given point
below e164.arpa, and deploy a Carrier ENUM subtree underneath without
touching User ENUM semantics at all. For readability, we will use
the label 'carrier' for this subdomain from now on, while in practice
any label will suffice, e.g. a single character label like 'c' or
'i'.
For interoperability it is desirable to have that branch sit either
in a commonly agreed or in an easily discoverable place. Several
options for this branch location exist, the two most easily
implemented - both political and technical - are selected:
1. above the country code delegation level, directly below e164.arpa
e.g. '4.9.7.1.carrier.e164.arpa',
2. somewhere below the country code delegation level, e.g.
'4.9.7.carrier.1.e164.arpa' or 'carrier.4.9.7.1.e164.arpa'.
Option 1 is obviously the most straightforward, because it requires
no changes to the resolver semantics. This approach amounts to just
a different apex definition for the resolver. Regarding the IETF
ENUM WG, one additional line to RFC 3761 adding an additional apex
for Carrier ENUM e.g. "c.e164.arpa" is sufficient, leaving the rest
of the algorithm and the RFC 3761 unchanged.
A potential drawback is that heavy involvement of the IAB, RIPE,
ITU-T, as well as the applicable NRAs (National Regulatory
Authorities) is needed during the setup phase and therefore may take
some time to implement. Also, reopening the discussion of the
interim procedures already agreed is a tedious process, as is the
adaptation of the current delegation mechanism.
On the other hand, it could be that only the IAB and RIPE is
involved. The IAB just needs to duplicate the instructions to RIPE
for "c.e164.arpa" or whatever is defined in RFC3761bis. RIPE may
accept any separate request for either "e164.arpa" or "c.e164.arpa"
Haberler & Stastny Expires September 7, 2006 [Page 5]
Internet-Draft Combined User and Carrier ENUM March 2006
and forward it as instructed to the ITU-TSB. The ITU-TSB is
according to the interim procedures instructed to check if 1. the
request is for a valid CC and 2. the concerned member state agrees to
the request. Since the interim procedures do not define the apex at
all, both a request for "e164.arpa" and "c.e164.arpa" is valid, if it
concerns a valid CC and is agreed by the member state.
Option 2 allows to solve the above mentioned issues to be resolved as
a national matter by the concerned NRA or as a regional opt-in within
in a given Numbering Plan Area such as the North American NPA.
However, a convention is needed how, given a fully qualified E.164
[2] number, a resolver can determine the location of the carrier ENUM
subdomain for this country. However, ITU-T and IETF (IAB)
involvement is only lightweight, e.g. to recommend the proper
algorithm defined here to enable international interoperability.
Beyond the setup phase, an NRA need not be involved operationally -
it is sufficient to establish a convention linking the national
definition of a carrier of record to the credentials for write access
to the Carrier ENUM tree.
We believe the choice among the above options should not be
predetermined for maximum flexibility and left to national or
regional environments to decide. This suggests a method for Carrier
ENUM resolution which can deal at runtime with whatever the decision
for a country code, or a group of countries, happens to be.
It should also be mentioned that Option 1 and 2 could be pursued in
parallel, because Option 2 can be implemented immediately by any
country willing to do so. This could be done either for trials or
even for production, because Option 2 contains Option 1 as default
and a migration back to Option 1 is possible at any time, if Option 1
is finally agreed upon.
The remainder of this paper addresses therefore only the Option 2.
5. Resolver behaviour options and the Carrier ENUM branch location
A Carrier ENUM resolver thus needs to determine the place applicable
in a given number to search for the 'carrier' subdomain for
international interoperability, regardless what the national or
group-of-countries setup decision was.
We propose a mechanism to discover this boundary dynamically for any
given shape as follows:
Haberler & Stastny Expires September 7, 2006 [Page 6]
Internet-Draft Combined User and Carrier ENUM March 2006
o the national or group-of-countries decision about subdomain
location is documented in the e164.arpa tree proper by inserting a
special DNS record into the country code zone. This branch
location record (Section 8) (BLR) carries three values for maximum
flexibility: 1. an integer value which points to the level in the
tree where the carrier subtree branches off. 2. an alphanumeric
value containing the name of the label of the branch 3. an
alphanumeric value containing the apex of the tree where the tree
is contained. Implementation options for the BLR are discussed
below.
o a resolver looking for a Carrier ENUM domain needs to retrieve
this BLR once during first resolution within a country code,
caching the result in a local table for later re-use.
o while constructing the FQDN, the label given in the BLR is
inserted at the position indicated by the BLR's integer value and
finally the apex is appended
For the abovementioned tree shape options (Section 4), the
corresponding branch location record values in the 1.e164.arpa zone
would be as follows:
+---------------------------+-----------------+---------+-----------+
| shape | branch location | label | apex |
+---------------------------+-----------------+---------+-----------+
| 4.9.7.1.carrier.e164.arpa | 0 | carrier | e164.arpa |
| 4.9.7.carrier.1.e164.arpa | 1 | carrier | e164.arpa |
| carrier.4.9.7.1.e164.arpa | 4 | carrier | e164.arpa |
+---------------------------+-----------------+---------+-----------+
Figure 1
The only remaining a-priori knowledge a Carrier ENUM resolver should
have is the current list of country codes, or an equivalent method to
determine where the country code in the number ends.
To prime the country code extraction algorithm, the current scheme to
determine country code length as follows could be employed:
o 3 digits is the default length of a country code.
o country codes 1 and 7 are a single digit.
o the following country codes are two digits: 20, 27, 30-34, 36, 39,
40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, 98.
Figure 2
Given the fact that the ITU recently allocated only 3-digit country
codes, there are no more spare 1- and 2-digit country codes and
Haberler & Stastny Expires September 7, 2006 [Page 7]
Internet-Draft Combined User and Carrier ENUM March 2006
existing 1- and 2-digit country codes are extremely unlikely to be
recovered, the above table consisting 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.
If a branch location record is not found that way (for instance, in
the unlikely case the ITU allocates a country code not according to
these rules), it is still possible to determine the branch location
record by "iterating down" the tree. Such a fallback strategy would
rely on the assumption that there is never a branch location record
inserted above the country code zone, for which there would be no use
in the first place.
It seems unlikely that inspection of more than the first five digits
will be required to locate the branch location record under any
realistic numbering administrative partitioning.
6. Recommended resolver behaviour
A User ENUM resolver as per RFC 3761 need not be aware of any Carrier
ENUM conventions at all. A combined User and Carrier ENUM resolver
shall behave as follows:
The input to the resolver routine shall be:
1. the called number in fully qualified E.164 (international)
format,
2. a 'subtree' parameter indicating whether the search should
proceed in the User ENUM tree, or in the subtree indicated by the
parameter (example: 'carrier' to indicate Carrier ENUM
resolution, or a null value for defaulting to User ENUM
resolution),
3. optionally a table or algorithm to easily detect country codes
(Section 5),
4. any other parameters used to drive the search, for instance an
enumservice type. These parameters are outside the scope of this
draft.
The resolver shall proceed as follows:
o if the subtree parameter indicates a User ENUM search, proceed as
per RFC3761.
o If the subtree parameter indicates a Carrier ENUM query:
* determine country code length.
* consult cache table if a branch location for this country code
was already retrieved since resolver boot time.
* if not:
Haberler & Stastny Expires September 7, 2006 [Page 8]
Internet-Draft Combined User and Carrier ENUM March 2006
retrieve the branch location record from the country code
zone, and store the country code and branch location data in
the cache table.
optional fallback for irregular country code not covered by
the CC extraction algorithm: (Figure 2) if the last step
fails, iterate over the number up to five digits and try to
retrieve the branch location record each time, again storing
the country code and branch location data in the cache table
if successful.
if both attempts fail, return NXDOMAIN.
* valid branch location found: insert the carrier label from the
table accordingly at the location given and append the given
apex while creating the inverted dotted domain name.
* search the DNS for any NAPTR records for the resulting domain.
It is assumed that already discovered branch location values are
stored in a cache table of country code and branch location data.
7. Zone file examples
Example 1 - carrier subtree branches of right under the country code
+43 level, zone files for country code zone and carrier subtree zone.
The BLR happens to be at the same level as the carrier subtree.
Since they use the same name, the BLR needs to be below the zone cut
in the 3.4.e164.arpa zone. Note there is no change in the e164.arpa
zone in this case, the carrier subtree can be introduced nationally
without further external interaction.
Haberler & Stastny Expires September 7, 2006 [Page 9]
Internet-Draft Combined User and Carrier ENUM March 2006
; +43 country code zone
$ORIGIN 3.4.e164.arpa.
@ IN NS ns1.enum.at.
@ IN NS ns2.enum.at.
; Branch location record in e164.arpa at CC level
@ IN BLR 2 "carrier" "e164.arpa"
Note: or with TXT RR according to RFC1464:
@ IN TXT "blr-level=2"
@ IN TXT "blr-label=carrier"
@ IN TXT "blr-apex=e164.arpa"
; carrier subtree starts here
carrier IN NS ns1-ce.enum.at.
carrier IN NS ns2-ce.enum.at.
; Carrier ENUM NAPTR example for +43(1)23
$ORIGIN carrier.3.4.e164.arpa
3.2.1 IN NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@telco.at!" .
Figure 3
Example 2 - country code +7 opted for carrier subtree under
7.carrier.e164.arpa, which is documented by the BLR in the
7.e164.arpa zone. This implies consent with ITU and RIPE.
Haberler & Stastny Expires September 7, 2006 [Page 10]
Internet-Draft Combined User and Carrier ENUM March 2006
$ORIGIN 7.e164.arpa.
@ IN NS ns1.enum.ru.
@ IN NS ns2.enum.ru.
; Branch location record at CC level
@ IN BLR 0 "carrier" "e164.arpa"
carrier IN NS ns1-ce.enum.ru.
carrier IN NS ns2-ce.enum.ru.
; Carrier ENUM NAPTR example for +7(90)123
$ORIGIN carrier.e164.arpa.
3.2.1.0.9.7 IN NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@foo.ru!" .
Figure 4
Example 3 - country code +1 opted for carrier subtree under +1 (NPA),
i.e. 4 digits into the number. This would imply one zone per NPA.
We show an example for the 794 NPA. This scenario, again, can be
introduced without ITU and RIPE involvement.
Haberler & Stastny Expires September 7, 2006 [Page 11]
Internet-Draft Combined User and Carrier ENUM March 2006
$ORIGIN 1.e164.arpa.
@ IN NS ns1.cc1enum.ca.
@ IN NS ns2.cc1enum.ca.
;
; Branch location record at CC level
@ IN BLR 4 "carrier" "e164.arpa"
; delegation for 794 NPA - User ENUM
4.9.7 IN NS ns1-ue.cc1enum.org.
4.9.7 IN NS ns2-ue.cc1enum.org.
; delegation for 794 NPA - Carrier ENUM
carrier.4.9.7 IN NS ns1-ce.cc1enum.org.
carrier.4.9.7 IN NS ns2-ce.cc1enum.org.
; Carrier subtree for +1 794 NPA
$ORIGIN carrier.4.9.7.1.e164.arpa
; Carrier ENUM NAPTR example for +1(794) 123
3.2.1 IN NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@foo.com!" .
Figure 5
Example 4 - country code +49 opted for a carrier tree in a completely
different domain e.g. in e164.info, which is documented by the BLR in
the 9.4.e164.arpa zone. Note there is no change in the e164.arpa
zone in this case, the carrier tree can be introduced nationally
without further external interaction.
Haberler & Stastny Expires September 7, 2006 [Page 12]
Internet-Draft Combined User and Carrier ENUM March 2006
$ORIGIN 9.4.e164.arpa.
@ IN NS ns1-ue.enum.de.
@ IN NS ns2-ue.enum.de.
; Branch location record at CC level
@ IN BLR 0 "" "e164.info"
; Carrier ENUM NAPTR example for +49 123
$ORIGIN e164.info.
@ IN NS ns1-ce.enum.de.
@ IN NS ns2-ce.enum.de.
3.2.1.9.4 IN NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@foo.de!" .
Figure 6
8. The Branch Location Record
The BLR is located at the country code level and conveys the name and
location of a specific subtree. It returns three values: 1. an
integer value which points to the level in the tree where the carrier
subtree branches off. 2. an alphanumeric value containing the name of
the label of the branch 3. an alphanumeric value containing the apex
of the tree where the tree is contained.
We envisage several implementation options, such as:
o for trial purposes, 3 TXT records carrying the values in the
string arguments.
o a new DNS Resource Record, e.g. BLR as used in the examples above
o a NAPTR record with a new service definition for that purpose.
While technically equivalent, we believe the NAPTR option to be the
most flexible. We solicit suggestions for the final choice. If on
the other hand Option 2 is only a temporary solution, TXT records may
suffice.
9. Security considerations
Haberler & Stastny Expires September 7, 2006 [Page 13]
Internet-Draft Combined User and Carrier ENUM March 2006
Privacy issues have been raised regarding unwarranted disclosure of
user information by publishing Carrier 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 Carrier 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
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. Carrier
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 in the user-part of
the SIP URI either anonymized UserIDs or the E.164 number itself,
such as sip:441632960084@example.com .
The definition of a new RR type or a new enumservice does not
introduce security problems into the DNS. Usage of the Branch
Location record conveys only static setup information under a country
code subtree of e164.arpa. The intended use of DNSSEC within ENUM
will prove authenticity of the conveyed value.
10. IANA considerations
The following parameters need to be registered with IANA:
1. If Option 1 as outlined in this proposal is accepted: the name of
the Carrier ENUM subdomain as defined in RFC3761bis, for example
'carrier' (or 'c' for brevity). In the future other labels could
be registered for different purposes.
2. According to RFC 3761, the IETF requested IANA to delegate the
E164.ARPA domain following instructions provided by the IAB.
Names within this zone are to be delegated to parties according
to the ITU-T Recommendation E.164. If Option 2 outlined in this
proposal is accepted, there will be no changes requested of IANA
with respect to the E164.ARPA domain. However, if the Option 1
Haberler & Stastny Expires September 7, 2006 [Page 14]
Internet-Draft Combined User and Carrier ENUM March 2006
outlined in this document is accepted, this would require IETF to
request IANA to create a new sub-domain CARRIER.E164.ARPA.
3. for the branch location record, eventually an RR type or NAPTR
service defintion (note: to be defined in a separate RFC?)
11. Interoperability considerations
A resolver needs to indicate which information is requested - User or
Carrier ENUM, or both. A user-ENUM-only resolver need not be aware
of the carrier subtree and no changes with respect to RFC3761
semantics are required. A resolver desiring to retrieve Carrier ENUM
or both types of records needs to be aware of the conventions laid
out in this draft.
If the parallel approach of option 1 and option 2 as outlined in
section 4 is accepted, each country using Option 2 may decide on its
own when to migrate to Option 1. The BLR records for this country
would then be changed to the values "blr-level=0", "blr-label=c" and
"blr-apex=e164.arpa". If finally all countries have migrated, the
BLR records may be removed.
12. Acknowledgements
We gratefully acknowledge suggestions and improvements by Jason
Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence
Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar
Lendl of enum.at.
13. References
13.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
13.2. Informative References
[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[4] Lendl, O., "Publishing SIP Peering Policy",
Haberler & Stastny Expires September 7, 2006 [Page 15]
Internet-Draft Combined User and Carrier ENUM March 2006
draft-lendl-sip-peering-policy-00 (work in progress),
December 2005.
[5] Meyer, D., "SPEERMINT Requirements and Terminology",
draft-meyer-speermint-reqs-and-terminology-00 (work in
progress), February 2006.
Haberler & Stastny Expires September 7, 2006 [Page 16]
Internet-Draft Combined User and Carrier ENUM March 2006
Authors' Addresses
Michael Haberler
Internet Foundation Austria
Waehringerstrasse 3/19
Wien A-1090
Austria
Phone: +43 664 4213465
Email: mah@eunet.at
URI: http://www.nic.at/ipa/
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 Expires September 7, 2006 [Page 17]
Internet-Draft Combined User and Carrier ENUM March 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Haberler & Stastny Expires September 7, 2006 [Page 18]