Infrastructure ENUM Requirements
draft-ietf-enum-infrastructure-enum-reqs-04

[Ballot discuss]
I did not see a response to the SecDir Review by Stephen Farrell:

  My only concern is that I would have thought that infrastructure
  ENUM carries with it a new set of threats, due to the fact that one
  carrier-of-record could attempt to disrupt another's service. I would
  guess that this might change the security considerations a bit from
  those stated in rfc 3761, and that that difference should be recognised
  here. A simple statement to that effect would be enough IMO, say
  something like "The security considerations for ENUM detailed
  in [2] still apply. Since infrastructure ENUM involves carriers
  where RFC 3761 mainly considered individuals, protocols meeting
  these requirements SHOULD re-consider the RFC 3761 security model
  given this difference in the actors concerned. ..." However, perhaps
  3761 already considered this issue? In that case, there'd be no need
  for a new sentence.

[Ballot discuss]
Comments from Pekka Savola:

It is not obvious whether the IETF Last Call comments made on the ENUM infrastructure requirements draft have been addressed.  The document has not been updated since IETF last call.

My review:
http://arcknowledge.com/ietf.enum/2006-11/msg00095.html

Lots of followups ensued (look for 'last call', and there were also other comments under 'comments'):
http://arcknowledge.com/ietf.enum/2006-11/index.html

PROTO Write-up

1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication?
The chairs have reviewed the document.
2. Has the document had adequate review from both key WG members and key non-WG members?
The document has been adequately reviewed within the ENUM WG.
3. Do you have any concerns about the depth or breadth of the reviews that have been performed?
.No.
4. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?
The IESG should be aware that this document introduces significant long term political questions that may be of concern to the greater IETF community. This document postulates a requirement that a new entirely separate root structure for ENUM data be created for the use exclusive use service providers of record for a particular telephone number as opposed to the consumer or telephone number holder of record as is current general practice within e164.arpa.  Creation of this new infrastructure will unquestionably require a reopening of discussions with ITU-T and ITU SG2 regarding this new domain. 
5. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up.
The concerns expressed are not technical but political in nature as noted in 4.

6. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
There is strong consensus within the Working Group that the DNS entries within an infrastructure ENUM system should be visible in the public DNS. The IETF does not make a distinction between public and non public DNS.

Within the Telecom Industry that consensus is not as clear. Having the location of critical service provider network elements resolvable in the global DNS has some unique security and privacy implications associated with it that is the basis of ongoing discussion in the industry.

There is rough consensus in the WG that this should be implemented as a new root in the DNS (as noted in point 4) and not by other DNS solutions (like use of non-terminal NAPTR records) or the use of other DNS techniques (Branch Location Records) that would require significant modification to DNS resolver behavior.

Therefore we ( the chairs) cannot conclude that there is complete consensus in the WG on what exactly are the requirements for Infrastructure ENUM and what are the appropriate security and privacy considerations etc. This lack of consensus very similar to the type of confusion on requirements and objectives now seen in the SPEERMINT WG on carrier to carrier peering and/or interconnection. 

In any case, the technologies described in this document are becoming extremely critical to the design VoIP networks.  There is active work on these issue with in other standards bodies such 3GPP and CableLabs, and it important for  the IETF to continue this work.

7. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director.
No.
8. Have the chairs verified that the document adheres to all of the ID Checklist items ?
NIT and ID Checklist review preformed by WG Secretary as noted above.
9. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.)
Yes . The document currently has only a normative references section.  There are no normative references to IDs currently under IESG review.
10. What is the intended status of the document? (e.g., Proposed Standard, Informational?)
Informational
11. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections:
o Technical Summary
o Working Group Summary
o Protocol Quality
Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents.
Technical Summary
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. Because end user ENUM as defined in RFC 3761 requires end user opt-in and control of the location of the NAPTRs, it is not suitable for interconnection needs bu service providers. The requirements in the document are needed for the WG to develop a technical solution.
.
Working Group Summary
The working group reviewed this document in 2005-6 and was document NIT review preformed by Alexander Mayrhofer
Protocol Quality
There is significant interest in a number of countries and among other standards bodies (3GPP and CableLabs) in pursuing a concept defined as infrastructure ENUM. A significant number of private (non DNS visable)  infrastructure ENUM implementations are already in place and proving to be working, but currently a global solution as contemplated in these requirements is lacking.