[Enum] statement by ENUM WG members in response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP"

[Michael Haberler <mah at inode.at>]

In response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING
INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP" we make the following
statement.


1. Consensus
We are disappointed that the chairs of the ENUM working group have  
chosen
to ignore the consensus of the working group and are attempting to  
reverse
decisions that were made only after considerable debate.

To summarise the actual consensus, we refer to the "Dallas Treaty" as
signed by Richard Shockey, Alexander Mayrhofer, Jason Livingood, Penn
Pfautz, Lawrence Conroy, Michael Haberler, and Richard Stastny on 22  
March
2006.  The text of the agreement is here:

http://voipandenum.blogspot.com/2006/03/dallas-treaty-on- 
infrastructure-enum.html

This agreement was for the long-term solution of a public infrastructure
ENUM apex, as well as an interim solution that can be used by individual
countries to implement an interoperable public infrastructure ENUM  
tree as
soon as possible, independently of negotiations with the ITU.  This
interim solution has been shown to work and is supported by running  
code.
There is no reason to downgrade the proposed drafts to "Experimental"
status and to do so would devalue the consensus intention.

This agreement, which gives a clear picture of working group  
consensus and
direction, contained a commitment that "All parties to this agreement  
will
support this in good faith, in its entirety".  We feel this memo
substantially deviates from this and does so by citing reasons that have
already been discussed and resolved.

We are, to say the least, surprised to discover from this memorandum  
that
at IETF67 there were private discussions resulting in an "alternate  
set of
ideas" which the WG chairs say they support, but which have so far not
been communicated to the ENUM WG.  We find it extraordinary that these
alternate ideas are described in the memorandum as "consensus".


2. Public infrastructure ENUM is an imposition
The portrayal of public infrastructure ENUM as a means to force a
particular interconnection model upon carriers is not accurate, in fact
the reverse is true.  With public infrastructure ENUM a carrier will  
have
the choice of where to publish their data.  They can choose to use the
public tree or they can use a private system, or both.  In the same way
that public user ENUM is 'opt-in' for end users, public infrastructure
ENUM is 'opt-in' for carriers.  There is nothing in the provision of
public infrastructure ENUM that would prevent the development, use and
growth of private systems.

Beyond being opt-in at the carrier level, public infrastructure ENUM  
does
not imply a particular model such as "need to interconnect with  
everybody
else in the same tree" or "zero settlement between all  
participants".  In
fact, it does not imply "interconnecting" at all except for those
explicitly wishing to do so on the terms they require. Such
interconnection might be keyed on numbers, SIP domains, federations, or
mechanisms yet to be conceived - a question directed at the Speermint  
WG.

The movement from PSTN to NGN networks has seen a large increase in such
private systems.  The combination of new technologies and liberalising
regulatory environments has meant that carriers are increasingly  
required
to use the services that such systems provide.  Without public
infrastructure ENUM, carriers can only use a private system that may not
provide them with the access and services they require.  This would  
appear
to benefit only those whose business is to supply services or  
equipment to
power such private systems.  The attempt to prevent public  
infrastructure
ENUM would appear to do exactly what the authors claim they wish to  
avoid,
which is to impose a specific interconnection model on carriers.

In a landscape without public infrastructure ENUM and only private
systems, there remains the problem of inter-networking between the  
private
systems.  As an N-squared problem this cannot be resolved at the same
level as the private systems and a solution would require the  
creation of
a central, global directory.  This is of course the problem that public
infrastructure ENUM aims to solve.


3. Innovation of protocols
The memorandum questions the need for public infrastructure ENUM in  
light
of the many private ENUM initiatives.  We regard this argument as a
variant on the claims that the existence of multiple private DNS roots
removes the need for the public DNS tree.

As with all new standards that are produced by the IETF, the  
introduction
of public infrastructure ENUM will provide a platform for innovation  
that
may lead to a change in the current landscape for service providers.   
This
might raise business concerns for some WG members, but until this
memorandum it has not affected their participation in the consensus.  At
no time has the IETF ever felt this was a reason to prevent the
development of new standards and it should not start now.  We cannot  
allow
the protection of position by the stifling of innovation.

It is our view that public infrastructure ENUM is unquestionably a
protocol matter and this has to be an IETF concern. Every
telephony-standards body (ITU-T, ETSI, etc) defers to the IETF on  
matters
of Internet protocols and it would be inappropriate for the IETF to
abdicate its responsibilities here, or leave a vacuum for other
organisations to fill.


4. Publication of interconnection points
Whilst we recognise the legitimate concerns of some carriers who are
concerned by publication of their points of interconnection in the DNS,
this is not something they are forced to do.  Public infrastructure ENUM
does not suggest, nor require exposure of a network's points of
interconnection.  The WG has clearly documented the consensus on this
issue at the Dallas IETF as "DNS entries in I-ENUM must resolve in the
DNS.  There is no requirement that the result of the resolution process
will be a public IP address."

Again innovation is possible and the way in which interconnection  
data is
described or access to interconnection points are granted may develop
quickly to the point that the fears of these carriers are allayed and  
they
are ready to 'opt-in'.  Certainly the pressure of their requirements  
will
be a further driver of innovation.  There are already applications of
public infrastructure ENUM that do not even resolve to "points of
interconnection", such as draft-enum-teluri-e212-00.txt.  We maintain  
that
the IETF has no business in effect restricting use of such ad-hoc  
mappings
to "private DNS only" by following such arguments.

There are proposals in the Speermint WG that use the concept of
federations of carriers to optionally divert the URI-to-ingress-point
mapping to private interconnection arrangements, for instance in RFC1918
space (see draft-lendl-speermint-federations-03 and
draft-lendl-domain-policy-ddds-02).  This method has not only been
outlined in ID's, but implemented in running code and shown to work.

As a final point we note that there are many carriers who do not  
share the
view in the memorandum and who see public infrastructure ENUM as putting
control back into their hands, freeing them from the need to work with
closed, proprietary systems.


5. Architectural issues with e164.arpa
The two I-D's, draft-ietf-enum-branch-location-record-02 and
draft-ietf-enum-combined-03, emerged after two years of intense
discussions in various fora as the best possible interim solution given
the constraints.  These drafts enable deployment of a fully-backwards
compatible solution which can be seamlessly transitioned to the long  
term
solution of a separate public infrastructure ENUM apex, based on a
national decision.  There may be other potential solutions that the
working group could consider, but the memorandum would appear to  
preclude
all such work.

Experts from both the dnsext and dnsop WG were consulted to provide  
input,
and the EBL draft incorporated their suggestions. Expert review is  
already
progressing according to draft-ietf-dnsext-rfc2929bis. There may be some
minor adjustments resulting from that review.  Therefore, due process  
has
been followed, and no credible argument has been provided for a  
downgrade
to "Experimental" status.


6. The role of the IAB, IESG and ITU-T in defining an apex for public
infrastructure ENUM
We do not suggest the IETF define a specific domain.  We do, however,
suggest that IETF propose a domain, for instance i164.arpa, but leave  
the
final decision to the ITU-T.  We also suggest the IETF propose the
adoption of a similar, or even identical process like the "Interim
Procedures" to delegate under this domain.

We would argue such a proposal could be very lightweight, and impose no
foreseeable long-term liaison or discussion requirements upon the IETF.


7.  Next steps
We believe that the ID's draft-ietf-enum-branch-location-record-02 and
draft-ietf-enum-combined-03 remain "Standards track" and that the IESG
should take no action in support of the memorandum.

Further, we would ask that the IESG make the proposals to the ITU-T as
described above.


Michael Haberler
Alexander Mayrhofer
Otmar Lendl
Jay Daley
Jim Reid
Lawrence Conroy
Richard Stastny
Wilhelm Wimmreuter
Bernie Höneisen
Andrzej Bartosiewicz
Niall O'Reilly
Paul Erkkila





_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum