[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@inode.at> Thu, 08 March 2007 16:08 UTC
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLAg-0001ok-9S; Thu, 08 Mar 2007 11:08:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLAe-0001oJ-11; Thu, 08 Mar 2007 11:08:48 -0500
Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPLAc-0004Ia-Ld; Thu, 08 Mar 2007 11:08:48 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.59]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <mah@inode.at>) id 1HPL9N-00017z-Mb; Thu, 08 Mar 2007 17:07:30 +0100
Mime-Version: 1.0 (Apple Message framework v752.3)
References: <OFE93A3BB8.3519BA2E-ON80257297.006E7524-80257297.006E94E0@nominet.org.uk>
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at>
Content-Transfer-Encoding: quoted-printable
From: Michael Haberler <mah@inode.at>
Date: Thu, 08 Mar 2007 17:07:26 +0100
To: iab@ietf.org, iesg@ietf.org, enum@ietf.org
X-Mailer: Apple Mail (2.752.3)
X-SA-Exim-Connect-IP: 83.136.33.3
X-SA-Exim-Mail-From: mah@inode.at
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at
X-Spam-Level:
X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb
X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000)
X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
Cc: Lendl Otmar <lendl@nic.at>, Paul Erkkila <pee@erkkila.org>, Conroy Lawrence <lconroy@insensate.co.uk>, Bernie Hoeneisen <bhoeneis@switch.ch>, Wilhelm Wimmreuter <wilhelm@wimmreuter.de>, Mayrhofer Alexander <alexander.mayrhofer@nic.at>, Stastny Richard <richard.stastny@oefeg.at>, Bartosiewicz Andrzej <andrzej.bartosiewicz@nask.pl>, Daley Jay <jay@nominet.org.uk>, Reid Jim <jim@rfc1035.com>, Niall O'Reilly <Niall.oReilly@ucd.ie>
Subject: [Enum] statement by ENUM WG members in response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP"
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org
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@ietf.org https://www1.ietf.org/mailman/listinfo/enum
- [Enum] statement by ENUM WG members in response t… Michael Haberler
- Re: [Enum] statement by ENUM WG members in respon… Tony Rutkowski
- [Enum] RE: statement by ENUM WG members in respon… Stastny Richard
- [Enum] Re: statement by ENUM WG members in respon… Brian E Carpenter