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

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 14:52:40 -0600

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 <[email-masked]>
     * Cullen Jennings <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:

     * Cullen Jennings <[email-masked]>

Mailing Lists:

    General Discussion: [email-masked]
    Listinfo: https://www.ietf.org/mailman/listinfo/e2md
    To Subscribe: [email-masked]
    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>

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>

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 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>

    E2MD 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 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>

    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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 5 Mar 2010 23:00:40 +0100 (CET)

Hi Dean

Thanks for your review and feedback. My comments inline.

> <dw> either "make" before "use" or delete "of" in the preceding</dw>

Will be fixed.

> <dw> IS thsi true? I thought we were adding metadata mapping alongside the U
> RI mapping for the e.164 number </dw>

As per current proposal

there can be E2M and E2U records alongside in the same zone. E2M records 
resolve to a URI or to ASCII text (E2U records resolve always to a URI as 
per ENUM).

>    E.164 number.  However, it is controversial whether or not the result
> <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 eithe
> r; it's inane. <dw>

As you say ENUM lookups can resolve to either nothing or to a URI.
If it resolves to a URI, the URI can be intended to establish 
communications. The controversy starts, if the resulting URI is not 
intended for communications. This is where e2md starts...

> <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 m
> etadata suffice? IS "metadata" an unbounded representation space, or is it s
> coped to specific items (perhaps extensible through more RFCs and an IANA re
> gistry?</dw>

The E2MD and ENUM systems are to a large extent analog. We do not need to 
reinvent the wheel here and even existing code can be reused.

Thus, the preferred approach is to copy - paste - modify the existing ENUM 
specs.

> <dw>Not sure I like this; I can see a registry for new resource-records or s
> ubfields thereof (services? Gimme a vocabulary break!) but I'm guessing we n
> eed more than Expert Review to protect the security/privacy sensitivity aspe
> cts.</dw>

Expert review guidelines certainly must cover security/privacy 
considerations, as it is the case with Enumservices.

Whether or not Expert Review is sufficient for e2md-services is an 
interesting question. I believe it is sufficient as it is the case with 
Enumservices.

cheers,
  Bernie

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 6 Mar 2010 19:36:24 +0000

Hi Dean, folks,
 I may agree with Dean on inanity, or I may not; for now, I'm unsure.
Thus, a question for clarification:

I contend that...
An ENUM lookup returns a set of rules (one or more NAPTRs), and any of
those rules may be usable by one client and not-usable by another. A
client might not support the contact form (URI scheme), or interpret
the URI value differently from another client (e.g. private ENUM
architectures with local DNS views meaning the client interprets a
contact's target domain differently, ...).

I further contend that...
A publisher/server don't process each query differently (unless we are
not in Kansas anymore, and it's some voodoo DNS server -- in which case
speak to DNSEXT, not this proposed group). All the clients get all the
rules, and once sorted it's up to each one of them to decide which of
the returned rules to discard as unusable.

So ...
The cruft I may have in a NAPTR's constructed URI might make the URI
contact non-usable **FOR SOME QUERYING CLIENTS** WHO DON"T HAVE OTHER
DATA TO COMPLETE EFFECTVE RESOLUTION OF THE CONTACT TARGET.
Other clients do have that data and so can work with the returned data.

Q:  Is this inane?

[it looks pretty close to NICC's approach, or GSMA's or ...]

all the best,
  Lawrence

On 5 Mar 2010, at 20:52, Dean Willis wrote:
> <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>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 6 Mar 2010 15:32:53 -0500

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

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

 

Chair(s):
 
    * TBA

 

Mailing Lists:

 
 
Abstract

 
<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

 
<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

<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)

<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.

   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

Goals and Milestones:

 

Internet-Drafts:

Request For Comments:
 
   None

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 6 Mar 2010 21:11:34 +0000

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:
> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 6 Mar 2010 23:35:41 +0100 (CET)

Hi Rich

On Sat, 6 Mar 2010, Richard Shockey wrote:

> <RS REVISED TEXT> E.164 to MetaData (E2MD) will build on RFC 3761 in 
> either public or private instant iations to provide information about 
> E.164 numbers in those cases where metadata about E.164 numbers cannot 
> be expressed as URI’s.

Are you proposing that an E2M(D) lookup should never result in an URI?

If so, how should we treat the following cases:

- 'unused', to provide more information about the reason at some http-URI

- pointers to more complicated data-structures, e.g. XML;
   i.e. the XML data itself is not in the NAPTR RR (too long),
   but instead a pointer to some server providing the XML data.
   (the indirection case)

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 7 Mar 2010 11:45:50 -0500

OK I understand ..then you say

RS REVISED TEXT 2> E.164 to MetaData (E2MD) will build on RFC 3761bis in
either public or private instantiations to provide information about E.164
numbers. In some cases, metadata about E.164 numbers might not be expressed
as URI?s as required by the E2U DDDS application described in RFC 3761.

-----Original Message-----
From: Bernie Hoeneisen [mailto:[email-masked]] 
Sent: Saturday, March 06, 2010 5:36 PM
To: Richard Shockey
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Draft charter, comments inline <dw>

Hi Rich

On Sat, 6 Mar 2010, Richard Shockey wrote:

> be expressed as URI?s.

cheers,
  Bernie

---

From: Jay Daley <[email-masked]>
Date: Mon, 8 Mar 2010 10:35:54 +1300

I support the draft charter with Richard's edited edits.

I would add my support to two views already expressed:

1.  Creating a new DDDS is not difficult and both far more appropriate and deliverable than a new RR.  In fact a new RR would be quite wrong for this.  We have NAPTR and have to stick with until someone, anyone please, comes up with a complete replacement.

2.  The privacy issues are out of scope for this group to try to solve and are identical to those that come with ENUM, where they have been adequately addressed in the CNAM draft.  Personally I would not even identify them as it all comes down to personal prejudice and personal choice within the context of the bleeding obvious.  I doubt SMTP would ever have been developed if the privacy hand grenade had been lobbed in at regular intervals.

best
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 08 Mar 2010 10:48:29 +0100

A few comments from my side:

On 07.03.2010 22:35, Jay Daley wrote:
> 
> 1.  Creating a new DDDS is not difficult and both far more appropriate
> and deliverable than a new RR.  

Yes. See e.g.
http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt where I key
off the domain and not ENUM-like on the E.164.

> In fact a new RR would be quite wrong
> for this.  We have NAPTR and have to stick with until someone, anyone
> please, comes up with a complete replacement.

Well, you can either go with an ENUM clone, or you might want to restrict
what features of the NAPTR you actually want to use, e.g.

* non-terminals
* RE parsing

I don't have the reference handy, but under the name S-NAPTR something a
bit more lightweight has already been proposed. This is still the same
NAPTR RR on the wire, just the interpretation changed a bit.

> 2.  The privacy issues are out of scope for this group to try to solve
> and are identical to those that come with ENUM, where they have been
> adequately addressed in the CNAM draft.

Yes and no. In terms of PII, yes.

But if you talk about SPIDs and call routing, I have the nagging feeling
that a lot of folks here and in other IETF lists miss the fact that once
you consider multi-homed corporate PBXs and want to do fully featured call
routing from/to them, then the global E.164->SPID mapping data must
de-facto be public.

There just is no way around that.

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //