Subject: [Enum] FINAL AGENDA ENUM WG IETF 64 Vancouver

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Oct 2005 12:10:24 -0400

IETF 64 Vancouver Telephone Number Mapping (ENUM) WG Agenda FINAL

Chair(s):
Patrik Faltstrom <[email-masked]>
Richard Shockey <[email-masked]>

WG Secretary:
Alex Mayrhofer <[email-masked]>

Transport Area Director(s):
Allison Mankin <[email-masked]>
Jon Peterson <[email-masked]>

Transport Area Advisor:
Allison Mankin  <[email-masked]>

TUESDAY, November 8, 2005

AGENDA BASHING (5 min)

RECHARTER DISCUSSION (CURRENT PROPOSAL)  (15 MIN )

The ENUM working group has defined a DNS-based architecture and protocol
[RFC 3761] by which an E.164 number, as defined in ITU Recommendation
E.164, can be expressed as a Fully Qualified Domain Name in a specific
Internet Infrastructure domain defined for this purpose (e164.arpa).

Background:

E.164 numbers are globally unique, language independent identifiers for
resources on Public Telecommunication Networks that can support many
different services and protocols. 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:

1. The working group will update RFC 3761 and advance to Draft Standard.

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.

3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

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.

5. The Working Group will continue to maintain appropriate contact and
liaison with other standards bodies and groups, specifically ITU-T SG2,
to provide technical or educational information and address, as needed,
issues related to the use of the E.164 numbering plan for services on IP
networks.  In addition the Working Group will continue to encourage the
exchange of technical information within the emerging global ENUM
community as well as documentation on practical experiences with
implementations, alternate technology uses and the administration and
provisioning of RFC 3761.

6. As described in RFC 3761, the IETF documents and registers the
Enumservices.  While extant, it is the ENUM working group that performs
the technical review and development of the Enumservices for the Internet
community.  The working group determines whether to advance them and
how to progress them technically.  Coordination with other WGs will
be taken into account on these.

Other than Enumservices, all proposed deliverables of the working group
will be discussed with and approved by the Area Directors, who may
require wider review due to the broad impact of the subject.

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

2. Ready to Go Items.

ENUM Implementers Draft: (Final Version) 5 MIN

	Title		: ENUM Implementation Issues and Experiences
	Author(s)	: L. Conroy, K. Fujiwara
	Filename	: draft-ietf-enum-experiences-03.txt
	Pages		: 33
	Date		: 2005-10-18
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-03.txt

DNS issues 10-M

B. Title		: ENUM Requirement for EDNS0 Support
	Author(s)	: L. Conroy, J. Reid
	Filename	: draft-conroy-enum-edns0-01.txt
	Pages		: 16
	Date		: 2005-10-25
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-01.txt

3. New Work Items.

A. Title		: IANA Registration for Enumservice vCard  10-Min
	Author(s)	: A. Mayrhofer, D. Lindner
	Filename	: draft-mayrhofer-enum-vcard-00.txt
	Pages		: 7
	Date		: 2005-10-5
	
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt

B.

Title        : IANA Registration for IAX Enumservice ( 10-Min )
     Author(s)    : E. Guy
     Filename    : draft-guy-enumiax-00.txt
     Pages        : 11
     Date        : 2005-10-20

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-guy-enumiax-00.txt

Title		: An ENUM Library API    ( 5 Min WG Chairs will lead discussion )
	Author(s)	: T. Sajitha
	Filename	: draft-sajitha-enum-api-00.txt
	Pages		: 7
	Date		: 2005-10-21
	
This draft defines a library API for ENUM. The API takes telephone
number as input and returns the URI associated with that telephone
number.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt

4 Old Items:

A. Carrier ENUM Requirements?   ( 15 - M )

Title	: Carrier/Infrastrucure ENUM Requirements
	Author(s)	: S. Lind, et al.
	Filename	: draft-lind-infrastructure-enum-reqs-01.txt
	Pages		: 7
	Date		: 2005-10-21
	
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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt

Title		: Combined User and Carrier ENUM in the e164.arpa tree  ( 15 - M )
	Author(s)	: M. Haberler, R. Stastny
	Filename	: draft-haberler-carrier-enum-01.txt
	Pages		: 15
	Date		: 2005-10-21
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt

B. IANA Registration for an Enumservice
Containing PSTN Signaling Information
draft-ietf-enum-pstn-01    ( 10 Min )

C. Validation Drafts   ( 10 Min )

Title		        : ENUM Validation Architecture
	Author(s)	: A. Mayrhofer, B. Hoeneisen
	Filename	: draft-ietf-enum-validation-arch-00.txt
	Pages		: 16
	Date		: 2005-10-6
	
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-00.txt

Title		: ENUM Validation Token Format Definition
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-validation-token-00.txt
	Pages		: 16
	Date		: 2005-10-10
	
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-00.txt

Title		: ENUM Validation Information Mapping for the Extensible 
Provisioning Protocol
	Author(s)	: B. Hoeneisen
	Filename	: draft-ietf-enum-validation-epp-01.txt
	Pages		: 25
	Date		: 2005-10-27
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-01.txt

????????????

Title		: Extension MIB for ENUM management
	Author(s)	: Y. Shin
	Filename	: draft-shin-enum-emib-00.txt
	Pages		: 8
	Date		: 2005-10-26
	
    It is service that ENUM replaces existent IP by telephone number and
    a user does various kinds devices so that is available by one
    peculiar number. As this ENUM's DNS becomes bulky, we need monitoring
    for ENUM. There is MIB to monitoring method that is used present.
    We propose standard for efficient ENUM DNS administration applying
    extension MIB that is this MIB's extension to ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shin-enum-emib-00.txt

5 General Discussion.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 28 Oct 2005 09:38:38 -0700

"Other than Enumservices, all proposed deliverables of the working group
will be discussed with and approved by the Area Directors, who may
require wider review due to the broad impact of the subject. "

We need to address this proposed amendment, transparently.

We already have the IESG issued last call that call for outside comments on 
the WGs opinion on last call standing. Why does ENUM WG need such a special 
rule, and what issues motivated this amendment?

Less formally, this issue addresses the ADs job. If our ADs needs such 
"special agent powers" to be assigned in the WG charter, are they suited to 
being an IETF AD? The scope of the requested powers is conventional AD work, 
after all, working with IESG to further the standards track status of 
documents, and IAB to perform oversight. Why would a AD want a AD-specific 
veto, when an AD can and should influence IESG to use existing procedural 
powers to require changes?

If something remarkable in the ENUM WG rechartering case requires the 
special powers, we need a _transparent_ process for administering the new 
powers of the ENUM ADs. One assumes that such powers are required on the 
basis of the new questions that FORCED rechartering.

It is a fascinating, proposed amendment.

>From: Richard Shockey <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: [Enum] FINAL AGENDA ENUM WG IETF 64 Vancouver
>Date: Fri, 28 Oct 2005 12:10:24 -0400
>