VoIP and ENUM

Important things first: At the meeting the issue was raised that the mixed usage of the terms "Carrier ENUM" and "Infrastructure ENUM" is confusing and the meeting should decide on the term used in future documents. This was done by hum and there was a slight preference for "Infrastructure ENUM". So Jon Peterson put his A-D hat on and decided:

Infrastucture ENUM

In detail:
Note: all presentations gvien at the meeting can be retrieved from here.

The charter proposed in the agenda was approved.

ENUM Implementation Issues and Experiences draft-ietf-enum-experiences-03.txt and ENUM Requirements for EDNS0 Support draft-conroy-enum-edns0-01.txt

Regarding EDNS0: after some prior discussions on the list, consulting with dns-experts and also a discussion at DNSOPS it was decided to modify the draft to a very short and precise document, let it check by dnsops and submit it as BCP. The experiences draft will undergo one update to reflect this and will go immediately to WGLC afterwards. Further experiences to come up will be dealt with in another document.

IANA Registration for Enumservice vCard draft-mayrhofer-enum-vcard-00.txt and IANA Registration for IAX Enumservice draft-guy-enumiax-00.txt where both presented and accepted as WG items. The IAX ENUMservice will be treated similar to ENUMservice H323. The URI definition is contained in the IAX protocol specification to be contained in an Informational RFC. The I-D will show up after the shadow period.

An ENUM Library API draft-sajitha-enum-api-00.txt was considered out-of-scope and not dealt with.

Infrastructure ENUM issues, ongoing work:

Infrastructure ENUM Requirements draft-lind-infrastructure-enum-reqs-01.txt

Combined User and Carrier ENUM in the e164.arpa tree draft-haberler-carrier-enum-01.txt

and

IANA Registration for an Enumservice Containing PSTN Signaling Information draft-ietf-enum-pstn-01.txt

where presented. It was decided to finalize the requiremnets with high priority. The other two I-Ds will move on in the meantime. Regarding the draft-haberler-carrier-enum-01 it was proposed to move the definitions and terminology over to the the requirements I-D and concentrate on technical issues. We had some side discussions here at IETF how to put the information where to branch off the infrastructure part within the e164.arpa tree in the DNS and by which means (e.g. with a new RR record). The results will be incorporated in the next issue of the I-D.

The basic idea is to have within the country code zone (e.g. in 3.4.e164.arpa or in 1.e164.arpa) in predefined context containing a RR with the following information:

• number of digits where the branch occurs
• the name of top label of the branch tree
• the apex of the tree where the information is contained (this allows eventually also to point to other trees
  

If this is done with a new DNS RR (called Branch Location Record), the information could e.g. look like:

$ORIGIN 1.e164.arpa
infra IN BLR "4" "carrier" "e164.arpa"

The NAPTRs for number +1-234-567-8900 will then be found in domain
0.0.9.8.7.6.5.carrier.4.3.2.1.e164.arpa

The data contained in the BLR is a national decision by the NRA.

BTW, the definition of User ENUM in this terms would be
user IN BLR "0" "" "e164.arpa"

An ENUM client capable of querying Infrastucture ENUM needs only to know the Country Codes (as already described in the draft) and then must retrieve at bootstrap time (or when he first queries a number from a specific country code) this information once (for the Time-To-Live of the BLR, which can be set very long).

Validation issues, ongoing work

ENUM Validation Architecture draft-ietf-enum-validation-arch-00.txt

ENUM Validation Token Format Definition draft-ietf-enum-validation-token-00.txt

ENUM Validation Information Mapping for the Extensible Provisioning Protocol draft-ietf-enum-validation-epp-01.txt

The three drafts where presented. There are still some minor isssues, but the work seems to be finished soon.