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.
- [dispatch] E2M: Proposed Charter (draft version o… Bernie Hoeneisen
- Re: [dispatch] E2M: Proposed Charter (draft versi… Richard Shockey
- Re: [dispatch] E2M: Proposed Charter (draft versi… Paul Kyzivat
- Re: [dispatch] E2M: Proposed Charter (draft versi… Cartwright, Kenneth
- Re: [dispatch] E2M: Proposed Charter (draft versi… Bernie Hoeneisen
- Re: [dispatch] E2M: Proposed Charter (draft versi… Ray.Bellis
- Re: [dispatch] E2M: Proposed Charter (draft versi… Cartwright, Kenneth
- Re: [dispatch] E2M: Proposed Charter (draft versi… Ray.Bellis
- Re: [dispatch] E2M: Proposed Charter (draft versi… Cartwright, Kenneth
- Re: [dispatch] E2M: Proposed Charter (draft versi… Bernie Hoeneisen
- Re: [dispatch] E2M: Proposed Charter (draft versi… Ray.Bellis
- Re: [dispatch] E2M: Proposed Charter (draft versi… Richard Shockey
- Re: [dispatch] E2M: Proposed Charter (draft versi… Ray.Bellis
- Re: [dispatch] E2M: Proposed Charter (draft versi… Cartwright, Kenneth