Wednesday, November 02, 2005

ENUM at IETF#64 in Vancouver 

Talking about busy weeks, the next week in Vancouver at the IETF#64 will be also very busy.

The ENUM WG is scheduled on Tuesday, November 8th, in the afternoon sessions III and IV from 1740 to 1950.

The first and most important item on the agenda is the recharter discussion to include "Carrier or Infrastructure" ENUM. The current proposal is contained in the agenda.

The discussion will concentrate mainly on the issues related to Carrier ENUM:

... There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services.

Working Group Revised Goals and Scope:

2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing.

4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data.

And the new:

Goals and Milestones:

March 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard

April 06 Requirements for Carrier Interconnection using ENUM as an Informational

June 06 Carrier Interconnection using ENUM as a Proposed Standard

July 06 ENUM Privacy and Security Considerations as an Informational

August 06 Advancement of RFC 3761 to Draft Standard

Next on the agenda are the ready to go items:

ENUM Implementation Issues and Experiences

This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol.

ENUM Requirement for EDNS0 Support

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support ENUM query resolution (as defined in RFC3761). This requirement is needed as DNS responses to ENUM-related questions return larger sets of Resource Records than typical DNS messages. Without EDNS0 support in all the involved entities, a fallback to TCP transport for ENUM queries and responses would typically occur. That has a severe impact on DNS Server load, and on latency of ENUM queries. This document updates RFC3761 only in adding this requirement.

New Work Items:

IANA Registration for Enumservice vCard

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call.

IANA Registration for IAX Enumservice

This document registers the IAX2 Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761.

An ENUM Library API

This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number.

Ongoing items:

Carrier/Infrastrucure ENUM Requirements

This document provides requirements for "infrastructure" or "carrier" ENUM, 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 VoI

Combined User and Carrier ENUM in the tree

ENUM as defined now in RFC3761 [1] is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM.

IANA Registration for an Enumservice Containing PSTN Signaling Information

This document registers the Enumservice “pstn” and subtype “tel” using the URI scheme ‘tel:’,
as well as the subtype “sip” using the URI scheme ‘sip’ as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists.

ENUM Validation Architecture

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure.

ENUM Validation Token Format Definition

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion.

ENUM Validation Information Mapping for the Extensible Provisioning Protocol

This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names.

For completeness:

IANA Registration for Enumservice Voice

is in last call

IANA Registration for Enumservice VOID

is in IESG Evaluation

IANA Registration for Enumservices email, fax, mms, ems and sms

still slumbering quietly in the Editor queue, awaiting a normative reference to be resolved.

Also for completeness, two related I-D are currently in treated in IPTEL WG, not meeting at IETF#64:

The ENUM Dip Indicator parameter for the "tel" URI
draft-ietf-iptel-tel-enumdi-01.txt (a version 02 will show up after the shadow period)


New Parameters for the "tel" URI to Support Number Portability

Since these two I-D and also

Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) draft-ietf-iptel-trunk-group-04.txt

require additional parameters to the tel URI defined in RFC3966. it was proposed to create an IANA registry for these parameters. This registry will be defined in:

The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry draft-jennings-iptel-tel-reg-00.txt

also available after the shadow period.

Comments: Post a Comment

This page is powered by Blogger. Isn't yours?