VoIP and ENUM

The IETF ENUM WG was the first session on Monday morning, and it went quite well (business-as-usual) until it flew apart in the last 10 minutes.

The agenda is available here and the presentations given may be downloaded via this page.

Co-chair Patrik Faltstrom is back again and announced that he will start work on I-D RFC3761bis. There have been some issues especially with non-terminals NAPTRs and the DDDS. Patrik will also set up a ticketing system for tracking issues with RFC3761.

Next on the agenda the ENUM Implementors Draft was discussed and is considered to be final. The Guide and Template for IANA Registration of Enumservices is moving forward.

Next some new Enumservices where discussed, such as CNAM, IAX, FOAF, IM and calendar services. There are still many issues. Basically with every new Enumservice proposed always somebody raises the privacy issue and then somebody else is approaching the microphone challenging the use of E.164 numbers: "Why do we need phone numbers and not SIP URIs?"

Answer:
1. This is ENUM WG, NUM standing for number and E somehow relates to E.164
2. because no provider is giving SIP URIs to his customers.

IMHO it should be much easier to register Enumservices. If somebody or a group of implementers (say the foaf community) want to have their own Enumservice, why shouldn't they have it. I suggest a fast lane with only expert review similar to the planned easy registration of DNS RR as proposed in RFC2929bis. If this is possible for DNS RR, it must e possible also for Enumservices.

The proposal by Alexander Mayhofer to merge ENUM Registration (Validation) and Domainkeys as lightweight Distributed Identity Infrastructure raised many issues and controversy.

Having set all this aside, the ENUM WG finally moved on to Infrastrucure ENUM issues. The Infrastructure ENUM Requirements are finally done and will be up-issued for WGLC with two minor corrections after the blackout period.

So only Michael Haberler's and mine draft on Combined User and Carrier ENUM in the e164.arpa tree was left. I gave a short presentation and then the meeting flew apart.

It was basically our mistake that we mixed up again too many issues in one draft. I should have known better with my experience from the msg I-D (now finally RFC 4355) that the IETF is capable only to deal with one issue at a time. And you should not have options in an I-D and we had too many:

Option 1 to have a new tree beside e164.arpa via IESG, RIPE and ITU-T, Option 2 to have a split below the country code in e164.arpa or even in another tree, and finally the pursuing Option 1 and Option 2 in parallel, using Option 2 as interim solution until Option 1 is sorted out.

Option 2 had in addition a sub-option to use a "Branch Location Record" (BLR) giving the position, label and apex of the split in e164.arpa, which could optionally either be implemented as DNS TXT RR or as a new DNS RR.

So a confusing discussion started in the last 10 minutes of the meeting, jumping between policy issues with the ITU-T and why TXT records are bad.

We requested finally a hum if we should move forward with the I-D as WG item and here finally Richard Shockey (opposing the BLR and interim solution) wanted to over-hum the room.

This ended the meeting, Patrik Faltstrom ording the opponents that they MUST come to a common agreement regarding the way forward during this week at the IETF.

So I held off this post on the ENUM WG until this agreement was reached. The common agreement was reached Wednesday evening and I will post it soon in detail.

The agreement reached is basically that Option 1 and 2 are pursued in parallel, having each Option in a separate I-D. The BLR will also be in a separe I-D, featuring a BLR RR as equested by the DNS proponents, using the expert review fast lane as mentioned above.

The agreement sets out also a time frame that all I-Ds should be ready for WGLC before or at IETF67.