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

[Lawrence Conroy <[e-mail]>]

Hi Richard, folks,
 If I read it properly, I like this draft charter; the revisions help a lot.

I do have a few comments on the revised text
*    Please can we say this is based on RFC3761bis et al, NOT on 3761.
  This matters as the registration process is streamlined in the updated docs,
  AND 3761bis has P-, which might be a helpful item for PII/Data Protection use.

*    Please can we avoid ' typos? Its making my eye's bleed.
  c/URI's/URIs/    c/URI'./URI./

*    Please can someone produce a clean copy of the new proposed charter
  -- It's getting hard to see the text.

Finally, as an aside, writing a new DDDS Application spec is actually quite a short task;
writing a DDDS database spec is also a fairly short task. Taking an existing one as a model
this can be done readily in a slow week. I know -- I tried it and cross checked against 340x.
[In theory we could not only blend some bits of E2U, but even dump NAPTR for some other RR
-- to do the latter is unwise, if only as it would also require a new RR type spec, but ...]

The real issue is the process for such a set of changes can be long, from publication, review,
agreement, through approval, publication, selection of experts to priming IANA, before we're
open for business. I assume the timescales are for publication as WGLC'd drafts?

all the best,
  Lawrence

On 6 Mar 2010, at 20:32, Richard Shockey wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> e2md mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e2md