Re: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP

["Stastny Richard" <[e-mail]>]

I have some concerns with this memorandum, which needs
to be discussed in Prague

The first one:
 
>3. The IETF will continue to develop standards and profiles that facilitate
>the exchange of real time SIP sessions including applications that assist in
>the provisioning of telephone number to URI data to various network
>elements.

So IETF is dealing in future with SIP only ?
 
Richard 
 

________________________________

Von: Richard Shockey [mailto:[e-mail]]
Gesendet: Fr 16.02.2007 22:13
An: [e-mail]
Betreff: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP





FYI this was just sent to the IAB/IESG.


MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM
WORKING GROUP


Dear Colleagues, 

We, the ENUM Working Group chairs want to alert the IESG as well as the IAB
to some unusual and significant considerations involving several documents
the ENUM WG has recently approved and submitted to the IESG for approval as
Informational or Proposed Standards.

The documents listed below [Appendix A] deal with issues involving what has
been referred to as Infrastructure ENUM.  We believe it is necessary to
alert the larger IETF Management community to their significance before IESG
action is taken on them and we believe the documents also point to actions
that should be taken by the IAB as well.

This memorandum outlines the issues involved with these documents, a general
back ground of their historical context and some specific recommendations
that the IESG/IAB should undertake in its relationship with ITU-T and ITU
Study Group 2. 

To understand why these documents are particularly significant, it is worth
pointing out a little history about the development and deployment of RFC
2916 and its successor RFC 3761.

When RFC 2916/3761 was approved there was a highly significant IANA
instruction included in the RFC.

{Quote from RFC 3761}

"4. IANA Considerations

This memo requests that the IANA delegate the E164.ARPA domain   following
instructions to be provided by the IAB.  Names within this   zone are to be
delegated to parties according to the ITU   recommendation E.164.  The names
allocated should be hierarchic in accordance with ITU Recommendation E.164,
and the codes should   assigned in accordance with that Recommendation.

Delegations in the zone e164.arpa (not delegations in delegated   domains of
e164.arpa) should be done after Expert Review, and the   IESG will appoint a
designated expert."

This clause triggered a long and complicated process of negotiations with
the ITU-T Study Group 2 that resulted in a series of agreements between the
IETF and the ITU regarding how delegations within e164.arpa were to be
accomplished. These negotiations were documented in the following:

The History and Context of Telephone Number Mapping (ENUM) Operational
Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)

ftp://ftp.rfc-editor.org/in-notes/rfc3245.txt

Liaison to IETF/ISOC on ENUM

ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt

The negotiation process was extremely difficult and resulted is several
compromises that continue to complicate the global deployment of RFC 3761,
such as the processes by which zone administrators are selected.

The ITU has never fully reconciled itself with the e164.arpa zone
administration system though, in practice, there have been few disputes.

Of particular concern is that the IAB/ITU agreements on the administration
of e164.arpa are still considered "Interim Procedures" and consequently
subject to cancellation at any time. This, in our opinion, continues to have
a negative effect on ENUM global deployments and zone delegations.

        [ITU ENUM procedures]
http://www.itu.int/ITU-T/inr/enum/procedures.html


ENUM was envisioned as a global public service where the customer or the
telephone number holder would have to "opt-in" before their information
would be listed within the public DNS zone that other users would access.
This mode of operation was supported by many government regulators as a
natural extension of policy on Number Portability. The deployment of RFC
3761 under these principals is generally referred to as "Public ENUM".

[Historical over view of Number Portability]
Number Portability in the Global Switched Telephone Network (GSTN): An
Overview

http://www.ietf.org/rfc/rfc3482.txt

In the intervening years since RFC 3761 was approved in 2004 there has been
a considerable shift in the development and deployment of SIP based VoIP in
general and the emerging concept of Next Generation Networks [NGN].  Many
national communications carriers and new incumbent carriers are redesigning
their voice networks to use TCP/IP and SIP. Some global carriers have
announced plans to "shut off" the PSTN completely. This has created a new
set of requirements for number translation resolution and signaling in
emerging NGN networks to support "All Call Query" on call or session
origination.

This created the requirements for what is commonly referred to as
"Infrastructure ENUM". The central premise behind Infrastructure ENUM is
that it is the carrier of record that issues the phone number vs the
consumer or number holder that would be authoritative for writing the zone
files with NAPTR records that designate "points of network interconnection"
between real time communications service providers.

Many global carriers have come to look on the technology of RFC 3761 as
central to internally resolving phone numbers to URI's in order to
facilitate internal network routing between network soft switches as well as
facilitate network to network service interconnection. An added benefit has
been to replace protocol functions now exclusively associated with SS7/C7
signaling. ENUM related work is currently under active discussion in such
fora as 3GPP, CableLabs, ETSI, ITU and ATIS. The IETF ENUM WG continues to
make significant contributions to that effort.

ENUM related issues have also spawned the SPEERMINT WG in the IETF RAI Area.
SPEERMINT is specifically chartered to assist in developing tools and best
current practices to assist in carrier to carrier peering and
interconnection when ENUM is used to resolve the telephone number to a URI.

Global service providers looked at the administrative procedures surrounding
the various zones of e164.arpa and correctly concluded that RFC 3761 could
not be relied upon to provide a truly authoritative database of E.164 named
end points since the data relied upon the explicit "opt-in" by the user as
opposed to the carrier of record for a particular telephone number.

Should significant numbers of consumers "opt-out" of a Public ENUM system,
it would be impossible for service providers to route sessions in an
accurate manner and would therefore require the use of SS7/C7 signaling
mechanisms indefinitely.

The ENUM Working group has been discussing for several years now what is
necessary to actually implement an Infrastructure ENUM system. The logical
place to start was to adapt the e164.arpa domain for that purpose but for
countless technical reasons that has proved to be a challenge.

There is consensus within the ENUM community and ENUM WG that the
requirements for User and Infrastructure ENUM are orthogonal to each other
and the one approach would be to designate an entirely separate domain
[ie164.arpa] for Infrastructure ENUM purposes only. This approach is
outlined in:

http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt.

This approach represented a WG consensus after the ENUM WG meeting at IETF
65 in Dallas in early 2006 as outlined in the following ENUM message.

http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html

Another school of thought believes that the use of the global DNS for
discovery of carrier to carrier points of interconnection is a misuse of the
DNS and that various "Private ENUM" approaches are the ultimate solution.

Many carriers are deeply concerned that exposure of points of
interconnection in the global DNS could expose their networks to various
forms of attacks that would compromise the quality and reliability of real
time voice communications.

Private ENUM is generally regarded as one or more technologies that permit
service providers to exchange phone number to URI data to find points of
interconnection in private secure manner. Any mutually agreed to domain
could be used and access control to the data would be strictly enforced.

Private ENUM could take several forms including maintaining a full and
complete cache of an authoritative telephone number database within the
service providers network boundaries or permitting queries via SIP Redirect
or RFC 3761 to a centralized registry or database so long at the data was
not visible or accessible by the general public.

All of the various approaches however stress that there is a strict division
between the concept of a "Public ENUM" where the end user is in control of
the zone files and Infrastructure ENUM or Private ENUM, where the service
provider of record is in control. There is also near universal agreement
that both concepts need to exist in parallel with each other.

The larger issue these documents [Appendix A] raise is what is the
appropriate role the IETF can and should play in defining relationships
between real time application service providers?

The IESG and IAB should be aware that by approving the documents listed
below may mean that the IETF is endorsing the idea that a new domain or sub
domain under .arpa will be required for Infrastructure ENUM. This domain
would be under the control of carriers only and the zone delegations would
likely be handled in a similar manner to that of e164.arpa.

There is some question about the viability of Infrastructure ENUM concept in
general, not only for security reasons previously stated, but in light of
many Private ENUM initiatives sponsored by 3GPP, CableLabs and commercial
firms. 

We do not advocate any particular approach for service providers to take
Infrastructure or Private. Ultimately that is not the concern of the IETF.
Such issues will be properly resolved in the market place.

The issues IAB and IESG should consider as to what are the appropriate roles
of the IETF and the ITU in developing standards appropriate to governing
relationships between service providers.

IETF can and must define protocols that a carrier can use to create real
time communication and facilitate interconnection over IP networks but it
does not seem appropriate for the IETF to define a specific Carrier
Infrastructure ENUM domain, carrier business rules or carrier to carrier
business structures.

We believe this crosses the boundary of what is and is not appropriate work
for the IETF to undertake. This seems a perfectly reasonable conclusion in
light of the IETF recognizing the role that ICANN plays in defining the
business rules the domain name business while the IETF defines the actual
DNS protocols and DNS provisioning tools.

We, the ENUM WG chairs believe we have preformed our task in managing the
documents listed below to WG consensus, though we both believe there are
significant architectural issues with the combined use of e164.arpa for both
User and Infrastructure purposes and in particular the use of the so called
Branch Location Record within e164.arpa.

[http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-
02.txt ] 

We strongly recommend expert DNS review of this document and the associated
draft-ietf-enum-combined-03.txt.  The chairs do not recommend either of
these documents should Standards Track RFC's but adopted as Experimental
only.

Over the years the ENUM WG has looked at several other technical solutions
that were ultimately rejected, such as a branch "below" the full E.164
number in the DNS tree using either non-terminal NAPTR Resource Records or
new suggested resource record types, such as the one discussed in
draft-ietf-enum-uri-00.txt.

These mechanisms were rejected due to the requirement that a carrier of
record would have to rely on DNS hosting by some external party for any
intermediary zone between the Country Code zone [cc.e164.arpa] and the
location of the NAPTR record that referred to the service they run.

At IETF 67 in San Diego, the ENUM WG chairs held discussions with Lesile
Daigle, Olaf Kolkman, John Klensin, and Scott Bradner (in his capacity as
IETF - ITU liaison) and many others voicing our concerns about these
documents. We also kept our RAI Area Directors Jon Peterson and Cullen
Jennings appraised of these discussions.

In these discussions, a general set of ideas emerged which we, the ENUM WG
chairs completely support.

The consensus is that the IETF should not attempt to define a specific
domain for Infrastructure ENUM purposes. If such a domain should be defined
at all it should be a result of discussions by ITU Study Group 2 which is
authoritative for the E.164 plan.






In addition there was a consensus that a mutual understanding of what are
the appropriate roles and responsibilities between IETF and ITU-T needs to
be developed as it may relate to these emerging carrier to carrier business
models.

A potential set of guidelines might include:

1. The IETF continue to be responsible for the DNS, including definition of
Resource Records, and the base ENUM specification as defined for "Public
ENUM" (or just "ENUM") in RFC 3761 and its successors where the E.164 number
holder is in control over the information in global DNS, and that
information is made available through the DNS, to anyone on the Internet.

2. The IAB continues to be responsible to decisions related to the namespace
in the DNS according to the existing exchange of letters between IAB, ITU-T,
ITU-T TSB and the registry for ENUM (as appointed by the IAB, currently RIPE
NCC).

3. The IETF will continue to develop standards and profiles that facilitate
the exchange of real time SIP sessions including applications that assist in
the provisioning of telephone number to URI data to various network
elements.

4. The ITU-T should take responsibility for "Infrastructure ENUM" where
goals are resolve the issues described in
draft-ietf-enum-infrastructure-04.txt. ITU-T should be responsible for
business relationships that involve bi-lateral or multilateral agreements
between service providers.

5. The IAB should strongly suggest that the ITU-T SG2 Interim Agreements on
the delegation of the zones for e164.apra be made permanent.

In conclusion, should the management of the IETF decide that this consensus
is appropriate then we recommend an appropriate Liaison Letter should be
sent to ITU SG2 outlining these views as soon as practically possible.

Though these documents raise some unique issues for our community, the
working group chairs are immensely proud of the overall accomplishments of
the ENUM WG in general. We both have confidence that the RFC's currently
delivered by the ENUM WG now and in the future will be deployed by service
provider networks world wide.

Sincerely,

Richard Shockey
Patrik Faltstrom


Appendix A: INFRASTRUCTURE ENUM DOCUMENTS UNDER DISCUSSION

Title           : Infrastructure ENUM Requirements
        Author(s)       : S. Lind, P. Pfautz
        Filename        : draft-ietf-enum-infrastructure-enum-reqs-03.txt
        Pages           : 7
        Date            : 2006-8-8
       
This document provides requirements for "infrastructure" or "carrier"
ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to
facilitate interconnection of networks for E.164 number addressed services,
in particular but not restricted to VoIP (Voice over IP.)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs
-03.txt



Title           : The ENUM Branch Location Record
        Author(s)       : O. Lendl
        Filename        : draft-ietf-enum-branch-location-record-02.txt
        Pages           : 9
        Date            : 2006-12-12
       
This documents defines the ENUM Branch Location record (EBL) which is
   used to indicate where the ENUM tree for special ENUM application is
   located.  The primary application for the EBL record is to provide a
   temporary solution for the Infrastructure ENUM tree location.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-0
2.txt

Title           : Combined User and Infrastructure ENUM in the e164.arpa
tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-ietf-enum-combined-04.txt
        Pages           : 12
        Date            : 2007-1-24
       
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-04.txt


Title           : The E.164 to Uniform Resource Identifiers
                          (URI) Dynamic Delegation Discovery System
                          (DDDS) Application for Infrastructure ENUM
        Author(s)       : J. Livingood, et al.
        Filename        : draft-ietf-enum-infrastructure-05.txt
        Pages           : 6
        Date            : 2007-1-24
       
This document defines a use case as well as a proposal for a parallel
   namespace to "e164.arpa" as defined in RFC3761, to be used for
   Infrastructure ENUM purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-05.txt




Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org
Skype:"rshockey101"
PSTN Office +1 571.434.5651
PSTN Mobile: [phone]
<mailto:richard(at)shockey.us>
<mailto:richard.shockey(at)neustar.biz>






_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum




_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum