Re: [dispatch] E2M: Proposed Charter (draft version only)

"Cartwright, Kenneth" <kcartwright@tnsi.com> Tue, 29 December 2009 22:25 UTC

Return-Path: <kcartwright@tnsi.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531243A68EC for <dispatch@core3.amsl.com>; Tue, 29 Dec 2009 14:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.564
X-Spam-Level:
X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_50=0.001, HTML_MESSAGE=0.001, OBFUSCATING_COMMENT=0.973]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iezs0OfBwDD2 for <dispatch@core3.amsl.com>; Tue, 29 Dec 2009 14:24:49 -0800 (PST)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 672A03A68B7 for <dispatch@ietf.org>; Tue, 29 Dec 2009 14:24:48 -0800 (PST)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.38971684; Tue, 29 Dec 2009 17:29:48 -0500
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 29 Dec 2009 17:24:20 -0500
From: "Cartwright, Kenneth" <kcartwright@tnsi.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Date: Tue, 29 Dec 2009 17:24:17 -0500
Thread-Topic: Re: [dispatch] E2M: Proposed Charter (draft version only)
Thread-Index: AcqI1aj2UP220S/qSs+59UsL8OTiGw==
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA091AB63873TNSMAILNAwin2_"
MIME-Version: 1.0
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2009 22:25:00 -0000

Bernie,
Thanks for offering up the food for thought captured in the proposal.  I think that the first time I heard E2M proposed was at the ENUM meeting at Dublin.  At first blush, I liked the concept, due to the clutter that seemed to me to be gathering in E2U (er E2Everything).  However, after considering it further, my reservations about this proposed charter are as follows:
It is being built around a pre-assumed solution, DDDS with "E2M" as the DDDS application name, without first fully understanding and characterizing the problem that needs to be solved.  And without first understanding and characterizing the problem that needs to be solved, we are not likely to select the correct solution.  More specifically, DNS has shortcomings when attempting to use it simply as a generic distributed database, as DDDS attempts to do.  These shortcomings include: (1) only strings formed like domain names can be used as lookup keys (a severe limitation that is completely un-necessary), (2) no good way to identify the source of the lookup, (3) no XML like structure to the responses to allow for richer response data, (4) only supports key lookups, no ability to support queries.
Are those shortcomings going to get in the way of E2M's usefulness as new service types and subtypes are introduced, and new uses cases arise?  I think that is very possible.  To add further weight to this point, look at the core Domain Name System (.com, .org, .net, .biz, .info, etc, etc).  The groups of companies and organizations that defined, implemented and run that system (*the* prototypical DNS system) did not even use DNS to serve up metadata about their domain names.  They chose protocols like WhoIs, EPP, and IRIS.  They did not choose to use their DNS systems to store or query/resolve for metadata about domain names.  That is very telling.
What I do like about DDDS, however, is the design and administrative processes that allow for the introduction, review, and approval of new "data element sets" (i.e. service types and their contained elements).  However, this can also be accomplished using design constructs of XML (see IRIS and EPP as examples) and similar administrative policies.  Another alluring, but misleading, aspect of creating another ENUM like DDDS service is that we all have bind servers and we all understand ENUM well and we've all implemented it.  But that also can lead to us falling into the everything-looks-like-a-nail-to-me-if-my-favorite-tool-is-my-hammer trap.
In short, you are right on the money that we very much do need to get the VoIP/ENUM/PSTN data/metadata service problem scoped, defined, and solved.  However, I do not think another DDDS/DNS based solution is the *best* solution.  Please look at RFCs 4698 and 3981 as food for thought.
Ken


=================================================

 *   From: Bernie Hoeneisen <bernie at ietf.hoeneisen.ch<mailto:bernie@DOMAIN.HIDDEN>>
 *   To: IETF DISPATCH list <dispatch at ietf.org<mailto:dispatch@DOMAIN.HIDDEN>>
 *   Date: Tue, 15 Dec 2009 20:28:57 +0100 (CET)

size=2 width="100%" align=center>

Hi,


As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an E2M charter (draft) for discussion on this mailing list.



Have fun!



cheers,

 Bernie



---



E.164 to Metadata (E2M) (proposed charter / draft state)

-----------------------



Last Modified: 2009-12-15



Additional information is available at tools.ietf.org/wg/e2m

[not yet in use]





Chair(s):



    * TBA



Real-time Applications and Infrastructure Area Director(s):



    * Robert Sparks <rjsparks at nostrum.com>

    * Cullen Jennings <fluffy at cisco.com>



Real-time Applications and Infrastructure Area Advisor:



    * Cullen Jennings <fluffy at cisco.com>





Mailing Lists:



General Discussion: e2m at ietf.org [not yet in use]

To Subscribe: e2m-request at ietf.org [not yet in use]

In Body: subscribe

Archive: http://www.ietf.org/mail-archive/web/e2m/index.html

         [not yet in use]





Description of Working Group:



Abstract



   E.164 to Metadata (E2M) will use of the Domain Name System (DNS)

   for resolving E.164 numbers into metadata to provide information

   about E.164 numbers in cases where E.164 Number to URI Mapping

   (ENUM) can not be used.





Background



   ENUM provides an identifier mapping mechanism to map E.164 numbers

   to Uniform Resource Identifiers (URIs) using the DNS.



   Thus, ENUM can be used to look up the services associated with an

   E.164 number.  However, it is controversial whether or not the result

   of an ENUM lookup should always be intended to establish a

   communications session using the URI found in the corresponding

   Naming Authority Pointer (NAPTR) DNS Resource Record (RR).





Problem Statement



   Several proposals for Enumservice registrations do not fulfill the

   above mentioned interpretation, which suggests that an ENUM lookup

   should always be intended to result in a communications session.

   These proposals are therefore virtually locked in the process.

   Such proposals include (but are not limited to) Enumservices for

   'cnam' to provide information about the calling party name,

   'unused' to provide a hint that a number is not in use, and

   'send-n' to describe the structure of an ENUM tree.



   Another issue is that the result of an ENUM (E2U) lookup always

   needs to be an URI, which unnecessarily complicates simple mappings.



   The authors of such Enumservice proposals tried to circumvent the

   issues by introducing the 'data' URI scheme or inventing completely

   new URI schemes, with limited success however.  The main objection

   remained that an ENUM lookup should always result in a URI intended

   to establish a communications session.



Proposal



   The E2M Working Group is chartered to develop a new Dynamic

   Delegation Discovery System (DDDS) application E2M, which can be

   used with DNS NAPTR RRs for resolving E.164 numbers into metadata.

   The resulting metadata can be used (for example) to provide hints

   about properties of certain ENUM domains or to provide information

   that can be used as attributes of an E.164 number.



   E2M will provide the means for services related to E.164 numbers

   that do not fit into the concept of ENUM (E2U), and thus a

   way forward for such existing ENUM WG documents in the queue.



   Along with the E2M DDDS application a new IANA registry will be

   specified for registration of E2M services. The registration policy

   shall be Expert Review and Specification Required (see RFC 5226),

   similarly as specified for Enumservice registrations.



   The E2M specifications shall reuse a much as possible from the ENUM

   DDDS and its IANA registry specification.



   The E2M Working Group may take on further proposals for E2M service

   registrations (e.g. send-n) until the IANA registration for E2M

   services is approved by the IESG.





Goals and Milestones:



   Aug 2010  Submit Internet Draft(s) for the E2M DDDS application and

             its IANA registry specification



   Dec 2010  Submit 'cnam' and 'unused' as E2M service registrations

             (Informational)



   XXX 2011  Close the E2M Working Group (or recharter)





Internet-Drafts:



   http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01

   http://tools.ietf.org/html/draft-ietf-enum-unused-04

   http://tools.ietf.org/html/draft-ietf-enum-cnam-08

   (http://tools.ietf.org/html/draft-bellis-enum-send-n-02)





Request For Comments:



   None



size=2 width="100%" align=center>

 *   Follow-Ups:
    *   Re: [dispatch] E2M: Proposed Charter (draft version only)<http://www.ietf.org/mail-archive/web/dispatch/current/msg01074.html>
       *   From: Richard Shockey

 *   Prev by Date: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt<http://www.ietf.org/mail-archive/web/dispatch/current/msg01071.html>
 *   Next by Date: Re: [dispatch] [Enum] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt<http://www.ietf.org/mail-archive/web/dispatch/current/msg01073.html>
 *   Previous by thread: [dispatch] E2M: Find a proper home for draft-hoeneisen-e164-to-metadata-01.txt<http://www.ietf.org/mail-archive/web/dispatch/current/msg01067.html>
 *   Next by thread: Re: [dispatch] E2M: Proposed Charter (draft version only)<http://www.ietf.org/mail-archive/web/dispatch/current/msg01074.html>
 *   Index(es):
    *   Date<http://www.ietf.org/mail-archive/web/dispatch/current/maillist.html#01072>
    *   Thread<http://www.ietf.org/mail-archive/web/dispatch/current/threads.html#01072>

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.


________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.