Subject: [Enum] ETSI TISPAN WG4 on Carrier ENUM draft

From: "Stastny Richard" <[email-masked]>
Date: Sat, 18 Jun 2005 09:08:59 -0400

Dear all,
 
ETSI TISPAN WG4 discussed  I-D draft-pfautz-lind-enum-carrier-user-00 circulated via the IETF ENUM mailing list (and also the related document from the US ENUM Forum GEN129R0_Lind_Infrastructure_ENUM_Requirements) during the meeting held this week (14-17 June 2005) in Stockholm. A document was produced (WG4TD13r1) as a "Response on ENUM recent infrastructure developments from ETSI TISPAN WG4" and endorsed by WG4 stating the current position of WG4 on this issue.
 
I include here the full text of WG4TD13r1 for your information:
 
"With the move towards all IP networks applications, interworking must be addressed in order to facilitate global interoperability. NGN networks should interwork with each other through secure interfaces that provide a high level of trust, particularly with regard to any routeing information obtained from an ENUM database. Consideration must be given to how an NGN will interwork with other NGNs, and with other VoIP providers which are not part of the NGN cloud.
 
Until now ENUM according to RFC3761 in e164.arpa (User ENUM) has not been seen as useful to an NGN/Telco/VoIP provider as it is reliant on user action in terms of registration, insertion of data and management of that data. Additionally, there is also controversy regarding the inclusion of data within the NAPTR records which is publicly exposed in User ENUM.

Both ETSI TISPAN and 3GPP have discovered that ENUM promises to be a useful technology for interworking and facilitating interoperability. Given that NGNs will require interworking with other IP networks, ENUM is a favoured tool, but not in the form of User ENUM. 

Within TISPAN and 3GPP, Infrastructure ENUM ("carrier ENUM") which meets this need has, until now, been proposed to be hosted in a separate tree from User ENUM.

The following points summarise the current views held within ETSI TISPAN.

1) ETSI TISPAN is still convinced that a separate tree ENUM for Infrastructure ENUM that is available to NGN networks would allow for ultimate flexibility, especially when different NGN operators want to introduce interconnection of their networks on an IP peering basis.
It can be argued that using e164.arpa for Infrastructure ENUM would not require a new policy framework as the existing arrangements between the IAB and the ITU apply to the administration of that name space. However because of the way these rules apply, carrier routeing information would fall under the national regulatory framework in a different manner to the way this has worked in the past.
Carriers should be aware that action by governmental authorities is required, according to present IAB/ITU-T rules, if the "<cc>.e164.arpa" domain is used, irrespective of whether the domain would be used for User or Infrastructure ENUM.  In most cases a governmental authority is the domain name holder of "<cc>.e164.arpa" and therefore responsible for the rules.  Consequently, carriers would not be able to operate unless governmental authorities take this positive action.

2) ETSI TISPAN is also aware that some other groups such as the GSM-A have already decided to use a separate domain of their own for infrastructure ENUM purposes; e.g. "e164enum.net". The envisaged solution should also include these ENUM domains within a global ENUM infrastructure or at least to allow and facilitate interworking between these different domains.

3) If the cohabitation of User ENUM and Infrastructure ENUM in the same domain as proposed in I-D draft-pfautz-lind-enum-carrier-user-00 is to be progressed, the impact on existing implementations of User ENUM should be kept to a minimum. This implies that modifications to existing RFCs e.g. 3761, 3401-4 should be avoided. 

4) For any proposed solution it is a requirement that any impact caused by that implementation at a global level is considered. 
Therefore it has to be applicable for use with all national numbering plans; particular challenges may be to ensure that a global implementation is compatible with the use of variable length numbering (e.g. as used in Germany and Austria) and DDI blocks.

5) Infrastructure ENUM as proposed in I-D draft-pfautz-lind-enum-carrier-user-00 must be subject to appropriate measures for control and management of the data contained in the NAPTRs. This information must be current and reliable for routing purposes. 
Infrastructure ENUM does not remove the need for authentication that the party inserting, modifying or removing data in NAPTR records has a right to the corresponding number. Authentication is still required and an appropriate authentication procedure needs to be in place between the ENUM Tier 1 Registry and the carrier serving the number.
 
Apart from control and management of data, the issues of security and trust, mentioned in the first paragraph, are also important.  Ensuring trust in the data accessible by means of Infrastructure ENUM may involve having rules dealing with:
* the accuracy of data;
* who has access to data;
* the allowable purposes for which data may be used.
With the proposed approach set out in I-D draft-pfautz-lind-enum-carrier-user-00, these rules would normally be made by or subject to governmental authorities."
 
best regards
Richard Stastny

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