Subject: [e2md] New proposed charter for E2MD

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 14:24:13 -0600

Bernie and I just iterated on the charter proposal based on current  
feedback and a call yesterday with the ADs, and below is the meat of  
our current proposal.

Note that Richard had suggested adding the open issue about metadata  
sensitivity explicitly into the charter with a declaration that this  
problem is "out of scope". We suspect that won't fly, and would like  
to instead use some of our Anaheim meeting time to discuss this issue  
and possible resolutions.

-------

Description of Working Group:

Abstract

E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI  
Mapping) in either public or private instantiations to provide  
additional information about E.164 (telephone) numbers. In some use  
cases, information (metadata) about E.164 numbers cannot be expressed  
as a URI (Uniform Resource Identifier) as required by the ENUM DDDS  
(Dynamic Delegation Discovery System) described in RFC 3761bis.  
Therefore, E2MD will define a different mechanism for expressing  
metadata. The initial expectation is that this mechanism will be a new  
DDDS for metadata, based on RFC 3761bis, that returns standardized  
metadata instead of URIs.

Background

ENUM provides an identifier mapping mechanism to map E.164 numbers to  
Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically  
used to look up the services associated with an E.164 number, each of  
which is represented by a URI.

However, there is more information about a telephone number that may  
be useful when establishing a communications session using that phone  
number. For example, this information might be used to decide or what  
sort of communications session to establish using that phone number,  
or whether to accept a communications session offered by someone using  
that phone number. We refer to this information as "metadata". Several  
example use cases for metadata have been documented as Internet  
drafts, and will be considered during the work of E2MD for inclusion  
in the group's work product.

Typically, this metadata information is such that it cannot be  
described using a URI consistent those returned by a lookup using RFC  
3761bis, making a direct use of RFC 3761bis innapropriate. However,  
the basic lookup mechanism of RFC 3761bis appears to provide a good  
foundation for a metadata service, so E2MD will work from this basis.

Previous Enumservice proposals tried to resolve these issues by using  
the 'data' URI scheme or inventing completely new URI schemes, however  
it is believed that such proposals do not satisfy the general use case  
for metadata, and a new approach is required.

Problem Statement

Typically, the phone-number asssociated metadata is such that it  
cannot be described using a URI consistent those returned by a lookup  
using RFC 3761bis, making a direct use of RFC 3761bis inapropriate.  
However, the basic lookup mechanism of RFC 3761bis appears to provide  
a good foundation for a metadata service, so E2MD will work from this  
basis. The initially favored approach is to define an additional ENUM  
service (E2M) that maps phone-numbers to metadata that will operate in  
parallel to the current ENUM service (E2U), which maps phpne numbers  
to URIs.

Current proposals for metadata to be addressed by E2MD 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, 'send-n' to describe the structure of an ENUM  
tree, "spid" to describe a service provider identifier, "itad" to  
describe an internet telephony administrative domain, etc.

Scope of Working Group:

The E2MD Working Group is chartered to develop a new Dynamic  
Delegation Discovery System (DDDS) application that can be used with  
DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will  
provide the means for data related to E.164 numbers that do not fit  
into the classic concept of ENUM (E2U).

The E2MD specifications shall reuse as much as possible from the ENUM  
DDDS and its IANA registry specification. Along with the E2MD DDDS  
application a new IANA registry will be specified for registration of  
E2MD services. The registration policy shall be Expert Review and  
Specification Required (see RFC 5226), similar to those specified for  
Enumservice (E2U) registrations.

Limitations of the DNS are to be considered while defining the  
protocol; in particular packet size restrictions of deployed DNS  
transport.

The E2MD Working Group may take on further proposals for E2MD service  
registrations (e.g. send-n) until the IANA registration for E2MD  
services is approved by the IESG.

E2MD shall not be specified as a general purpose lookup nor as bulk  
transfer protocol, but rather focus on clear use cases related to E. 
164 numbers.

Goals and Milestones:

Aug 2010  Submit Internet Draft(s) for the E2MD DDDS application and  
its IANA registry specification to IESG

Dec 2010  Submit 'cnam' and 'unused' as E2MD service registrations   
(Informational) to IESG

XXX 2011  Close the E2MD Working Group (or recharter)

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Mar 2010 16:02:07 -0500

Why won't it fly, since CNAM itself is one of the core types of metadata
under discussion? The issue is easily analogous to location data in SIP.  We
do tools not policy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Thursday, March 11, 2010 3:24 PM
To: E.164 To MetaData BOF discussion list
Cc: Robert Sparks; Gonzalo Camarillo
Subject: [e2md] New proposed charter for E2MD

-------

Abstract

Background

Problem Statement

Scope of Working Group:

Goals and Milestones:

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 15:12:57 -0600

> under discussion? The issue is easily analogous to location data in  

The argument goes like this:

The DNS wonks and privacy/security wonks are going to get upset if we  
hit them with a charter explicitly for developing a protocol whose  
intended use is only private/restricted networks. That's just not what  
they think the IETF does.

But if we have a dual-use (Internet/intranet) protocol that conveys a  
multiplicity of information elements, and some of those information  
elements have sensitivities that require applicability statements  
restricting them to intranets, then we have a lot of precedents that  
might get us somewhere with forming a WG.

The fact that we don't have a consensus on how to handle the sensitive  
elements yet is what necessitates talking it through in the BOF.  
Talking about controversial subjects in a BOF is always fraught with  
hazard, so we're trying to stage it in smoothly. The ideas is "We have  
all of these use cases, and only SOME of them have sensitivities. The  
other use-cases are no-brainers, we can just do them. How are we going  
to deal with the sensitive use cases?"

Of course, if we can get an on-list consensus sorted out between now  
and then,  it'll make the BOF run a lot smoother.

--
Dean