Re: [e2md] Draft charter, comments inline <dw>

["Richard Shockey" <[e-mail]>]

 We are going to have to re work this a bit. comments in line.

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Dean
Willis
Sent: Friday, March 05, 2010 3:53 PM
To: Bernhard Hoeneisen
Cc: Robert Sparks; [e-mail]
Subject: [e2md] Draft charter, comments inline <dw>

 

E.164 to MetaData (E2MD) (proposed charter)
------------------------
 
Last Modified: 2010-03-05
 
Additional information is available at tools.ietf.org/wg/e2md
[not yet in use]
 
 
Chair(s):
 
    * TBA
 
Real-time Applications and Infrastructure Area Director(s):
 
    * Robert Sparks <[e-mail]>
    * Cullen Jennings <[e-mail]>
 
Real-time Applications and Infrastructure Area Advisor:
 
    * Cullen Jennings <[e-mail]>
 
 
Mailing Lists:
 
   General Discussion: [e-mail]
   Listinfo: https://www.ietf.org/mailman/listinfo/e2md
   To Subscribe: [e-mail]
   In Body: subscribe
   Archive: http://www.ietf.org/mail-archive/web/e2md/index.html
 
 
 
Description of Working Group:
 
Abstract
 
   E.164 to MetaData (E2MD) will use of the Domain Name System (DNS)
<dw> either "make" before "use" or delete "of" in the preceding</dw>
 
   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.
 
<dw> IS thsi true? I thought we were adding metadata mapping alongside the
URI mapping for the e.164 number </dw>
 
 
<RS REVISED TEXT> E.164 to MetaData (E2MD) will build on RFC 3761 in either
public or private instantiations to provide information about E.164 numbers
in those cases where metadata about E.164 numbers cannot be expressed as
URI's. 
 
 
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).
 
<dw> No, it's not. The result of an ENUM lookup is either nothing or a URI.
Are you saying that encoding other cruft into the URI that makes the URI
non-usable for contact purpose is controversial? That's not controversial
either; it's inane. <dw>
 
<RS> Yea I think we can delete the second paragraph. It provides no useful
charter function.
 
 
<REWRITE RS>
Problem Statement
 
   Several proposals for Enumservice registrations cannot currently be
expressed as URI'.
 
   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 or various forms of
Service Provider Identification data (SPID) 
 
   The authors of such Enumservice proposals tried to resolve these
   issues by introducing the 'data' URI scheme or inventing completely
   new URI schemes. 
 
 
Proposal
 
   The E2MD Working Group is chartered to develop a new Dynamic
   Delegation Discovery System (DDDS) application E2MD, 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.
 
 
<dw>Zooks! This sounds like a big job, developing a Whole New System. Would
just adding some resource records to the DNS that encode specific items of
metadata suffice? IS "metadata" an unbounded representation space, or is it
scoped to specific items (perhaps extensible through more RFCs and an IANA
registry?</dw>
 
 
<RS>  
 
   E2MD will provide the means for data related to E.164 numbers
   that do not fit into the classic concept of ENUM (E2U)
 
   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),
   similarly as specified for Enumservice registrations.
 
<dw>Not sure I like this; I can see a registry for new resource-records or
subfields thereof (services? Gimme a vocabulary break!) but I'm guessing we
need more than Expert Review to protect the security/privacy sensitivity
aspects.</dw>
 
<RS> As I mentioned in a earlier note we will certainly have to address
issues of security and privacy here but we have sufficient models and
deployments that address these concerns. This is old ground in ENUM terms
and in fact is already being done in non standard environments. We can add
flags to the registry to indicate concern but remember a great deal of this
will be used in private closed environments. We have sample text that could
be incorporated into the charter as noted from the CNAM draft.
 
 
< RS IDEA>
 

Distribution of E2MD Data

    

          The distribution of E2MD data could be highly restricted or
contain Publically Identifying Information (PII). The NAPTR records
developed by the WG could, in some cases, be inappropriate to be part of the
e164.arpa DNS tree or any portion of the general DNS.  Distribution of this
NAPTR data would be either within a service providers internal network, or
on a private basis between one or more parties using a variety of well known
security mechanisms to prohibit general public access.

    

          If such PII data was distributed in an open DNS system, a national
regulatory body may have jurisdiction.

Such a body may choose to restrict distribution of the data in such a way
that it may not pass over that          country's national borders.  How
Personally Identifying Information is collected, distributed and
subsequently regulated is out of the scope of the WG.

 
 
   The E2MD specifications shall reuse as much as possible from the ENUM
   DDDS and its IANA registry specification.
 
   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.
 
 
Out-Of-Scope
 
   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)
 
 
Internet-Drafts:
 
   http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02
   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