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
draft-ietf-enum-experiences-03.txt
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
draft-conroy-enum-edns0-01.txt
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
draft-mayrhofer-enum-vcard-00.txt
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
draft-guy-enumiax-00.txt
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
draft-sajitha-enum-api-00.txt
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
draft-lind-infrastructure-enum-reqs-01.txt
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 e164.arpa tree
draft-haberler-carrier-enum-01.txt
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 e164.arpa, 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
draft-ietf-enum-pstn-01.txt
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
draft-ietf-enum-validation-arch-00.txt
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
draft-ietf-enum-validation-token-00.txt
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
draft-ietf-enum-validation-epp-01.txt
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
draft-ietf-enum-voice-01.txt
is in last call
IANA Registration for Enumservice VOID
draft-ietf-enum-void-02.txt
is in IESG Evaluation
IANA Registration for Enumservices email, fax, mms, ems and sms
draft-ietf-enum-msg-05.txt
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)
and
New Parameters for the "tel" URI to Support Number Portability
draft-ietf-iptel-tel-np-07.txt
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.
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
draft-ietf-enum-experiences-03.txt
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
draft-conroy-enum-edns0-01.txt
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
draft-mayrhofer-enum-vcard-00.txt
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
draft-guy-enumiax-00.txt
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
draft-sajitha-enum-api-00.txt
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
draft-lind-infrastructure-enum-reqs-01.txt
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 e164.arpa tree
draft-haberler-carrier-enum-01.txt
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 e164.arpa, 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
draft-ietf-enum-pstn-01.txt
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
draft-ietf-enum-validation-arch-00.txt
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
draft-ietf-enum-validation-token-00.txt
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
draft-ietf-enum-validation-epp-01.txt
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
draft-ietf-enum-voice-01.txt
is in last call
IANA Registration for Enumservice VOID
draft-ietf-enum-void-02.txt
is in IESG Evaluation
IANA Registration for Enumservices email, fax, mms, ems and sms
draft-ietf-enum-msg-05.txt
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)
and
New Parameters for the "tel" URI to Support Number Portability
draft-ietf-iptel-tel-np-07.txt
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
