VoIP and ENUM

After 3 weeks of vacation and one week IETF in Paris I am trying to start blogging again. The IETF#63 last week in Paris had basically four highlights for me: ECRIT, the voipeer BoF, Monet's Garden in Giverny and ENUM.

The week was really very tensing, because the suspension was building up during the whole week, to be finally resolved in the last meeting and here at the end, when Carrier ENUM was scheduled. I was originally not very happy to see ENUM scheduled on Friday, but looking backwards it was a very good idea to have it after the VOIP peering and Interconnection BoF.

The VoIP Peering and Interconnect BoF was very interesting, especially the presentations given showed a wide spectrum of opinions and that a lot of basic work needs to done, e.g. clear definitions, defining a scope and scenarios and a requirements document. I will report on the voipeer BoF in detail in a later entry. One of the clear outcomes was that there is a definite need for Carrier ENUM, stated in many presentations, and this paved the way for the discussion in the ENUM WG on this topic.

So the first important decision regarding Carrier ENUM was the overwhelming hum on the question if Carrier ENUM is within the scope of the IETF ENUM WG - there where NO objections. This answered also the question I posted twice on the mailing list to the responsible AD Allison Mankin (who was BTW NOT present at the meeting). Remark: this was somehow prejudged already by adoption of the I-D on Enumservice npd:tel as WG item. This Enumservice is basically aimed for carrier use.

This decision will be reflected in an update of the WG charter and the requirements for Carrier ENUM will be continued to be incorporated in the requirements I-D, requested by Patrik and collected in a hurry by Steve Lind (to be made available officially after the blackout). This I-D was also adopted as WG item. The outcome of the requirements will help to decide if Carrier ENUM can either be incorporated as update to RFC 3761 or in a new RFC. This incorporation in an RFC has been requested by many vendors, because most of their customers demand it.

It was clearly stated by the WG chairs that the data in Carrier ENUM will be available in the public DNS (with no access restrictions), but this does not imply (as usual) that one may access the servers where the URIs may point to without restrictions. Since Carrier ENUM only makes sense if the carriers may enter ALL the numbers they host into Carrier ENUM (carrier opt-in and not user opt-in), this automatically implies for the requirements that the carriers must protect the privacy of their customers, e.g. by entering only URIs pointing to their network such as sip:+xxxxxxx@provider.net and eventually rolling out the whole block of numbers to give no information of numbers in-service.

Since David Meyer from voippeer was also available at the meeting, the opportunity was taken to define a clear split of responsibilites and scope between ENUM WG and a potential voipeer WG: these access restriction and eventual peering agreements are definitely within the scope of voipeer, the ENUM WG is responsible for the DNS related issues e.g. the implementation of Carrier ENUM in the DNS and required ENUMservices.

Having set these basic principles aside, the discussion moved on to the "details": where to place Carrier ENUM in the DNS?

Two proposals where brought forward as I-Ds:

- the usage of non-terminal NAPTRs to split User and Carrier e.g. in Tier 1 or below by Steve Lind and Penn Pfautz

- and the proposal from Michael Haberler and myself to split of the carrier tree somewhere below e164.arpa.

The usage of non-terminal NAPTRs and the problems caused by this e.g. for countries with numbering plans using variable number lenght has been already discussed at lenght on the ENUM mailing list. The usage of non-terminal NAPTRs will also require a fix in the DDDS application and also in RFC3761, as already pointed ot by Lawrence in his I-D modest proposal. This will be done in any case.

Penn Pfautz requested a (non-binding) hum on the opinion of the partizipants regarding the general directions of the future discussions and the chairs posed the following questions to the audience:

Do you prefer for implementation of Carrier ENUM:

A. with non-terminals
B. a split-off (to be decided where) in e164.arpa
C. a completely new tree for Carrier ENUM

Result was surprisingly clear, no hums for A. and C., an overwhelming hum for B.

Regarding option B. basically two sub-options exist:

- splitting the tree immediately below e164.arpa, by using e.g. c.e164.arpa as apex.
This is of course the most straightforward solution, and would require in principle only some additional lines in an updated RFC3761, but wouldl require heavy involvement of the IAB, RIPE and especially the ITU-T, basically a re-run of the (still not finalized) discussion regarding the Interim Procedures.

- leaving the point of split-off to the national entity responsible for "cc" .e164.arpa and indicate the split level used within this country code within the DNS itself, e.g. c."cc".e164.arpa. The split-off point could be after 0-n digits. This proposal is not as straight-forward as the first, but the complication would only concern carreir clients, would leave the ITU-T interim procedures untouched and could be implemented in countries willing to do so immediately. It could also cause some more pressure on national regulators by carriers to opt-in into e164.arpa or to go commercial.

The next steps will be:

- move the requirements I-D forward as fast as possible via mailing-list discussion
- a solution should be finalized latest at the next IETF in Vancouver (November)
- this is especially necessary if the solution requires input to the ITU-T
- the next ITU-T SG2 Plenary is in December 2005

Note for TISPAN: this decisions have important implications to the current work of TISPAN WG4 (and eventually also for the plans of GSMA using Carrier ENUM within GRX)

TISPAN WG4 will discuss these issues at the next ad-hoc meeting end of August in London to provide a proposal for a common position of TISPAN for the next TISPAN Plenary in September 2005.

The rest of the ENUM WG for completeness:

ENUM Implementation Issues and Experiences will go to WGLC.

IANA Registration for Enumservice Voice (the vovi minus video), only containing voice:tel will be a WG item (finally).

IANA Registration for ENUMservice Mobile Webpage caused already some discussion on the mailing list and also within the meeting. James Seng raised an issue and comments this on his blog:

... I think I surprised quite a few people when I stood up and objected to Shin's mobileweb registration (basically, a ENUMservice for mobile web). Now, Shin is a close friend but I think it is a bad idea to start putting session negiotation information into ENUM. Its a slippery slope to go near there - DNS should remains as DNS - you throw something at it and it give you back something. The capability negiotation should be done within the session setup, and especially HTTP already provides User-Agent negiotation that serves the need

I can understand why mobileweb would make sense - It is very helpful for a registry/registrar who can start to market a new product ("register your mobile web address now!") but lets not taint the protocol.

Some people also raised concerns in filling up the DNS and especially the responses with too many NAPTRs.

Jon Peterson stood up in his position as AD and stated that this problem is recurring (we had it already with voice:sip) and should basically not discussed again and again with specific applications, but discussed in general and solved.

The rest of the meeting concerned IRIS EREG, and the I-Ds on validation (an alpine co-operation ;-) are also moving slowly forward:

ENUM Validation Architecture
ENUM Validation Token Format Definition
ENUM Validation Information Mapping for the Extensible Provisioning Protocol

the documents have also been approved as WG items.