Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 10 Jan 2010 23:06:53 +0100 (CET)

Hi Kenneth

Thanks for your thoughts on the E2M proposal.

On Tue, 29 Dec 2009, Cartwright, Kenneth wrote:

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

Yep, I put the Dublin ideas to paper.

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

This looks like a classical tradeoff between 'KISS' and a 'pink squirrel'.
I favour KISS, at least in the E2M context.

E2M does not intend to use DNS as a generic distributed Database. Use 
cases that fall into these "shortcomings" are out of scope for E2M. For 
such use cases other protocols are to be considered, e.g. LDAP, SOAP/REST, 
EPP, IRIS, etc.

E2M rather intend to address these cases where the E.164 number is the 
lookup key, but ENUM (E2U) is not appropriate

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

To address the use cases we have on the table, E2M is a straight forward 
solution. Other use cases need to be solved by other means/protocal.

cheers,
  Bernie

---

From: [email-masked]
Date: Mon, 11 Jan 2010 11:36:34 +0000

> solution. Other use cases need to be solved by other means/protocal.

Agree 100%, +1, etc :)

I need E2M or similar for some of my own work to progress.

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 11 Jan 2010 10:48:41 -0500

Ok, understood.  But, like I said, even the main stream DNS community does not use DDDS/DNS to lookup/resolve metadata about domain names.  They came up with other protocols that were better suited to that purpose.  I think the VoIP community should as well.  DDDS and ENUM were of course originally created to define the manner in which the destination domain name and then the IP address for a given domainName/service pair are to be looked up.

So while I understand and like your KISS point, it concerns me that we are adopting a solution that plugs part of an immediate need, while possibly not fitting well into or helping to solve the bigger, longer term picture.  And it's at least worth considering that the "KISS" moniker can, under some circumstances, be synonymous with the "short term hack" moniker, :-) (just teasing).  But of course neither of these monikers is very edifying.  So, more to the point,

1) Telephone calls and the services that surround them (e.g. calling name, e911, etc, etc) need to work for both TN and URI lookup key use cases.  If I understand your E2M/DDDS proposal, it will only be usable if a TN (turned into a domain name) is the lookup key.  Do I understand your proposal correctly here?  It seems that allowing a lookup key to be an arbitrarily formed string (rather than a domain name) is a relatively minor change, so maybe E2M can be designed to support that.
2) The response structure of a meta-data protocol should be allowed to be fairly rich and nested (e.g. XML like).  Otherwise folks will find yucky hacks in order to accomplish that within a protocol that does not support it.  Perhaps E2M can be designed to support this.
3) It would be very good to be able to identify and use the source of a lookup when formulating the response.  So at a *minimum*, it would good to make sure that the solution proposed allows for a source identification scheme to be overlaid.  This seems like a feasible feature that perhaps E2M could support.

One way of looking at this is that we need a more capable/flexible DDDS that supports the requirements above (or a more flexible DDDS application, more flexible than ENUM that is, depending on what portions of ENUM's structure you believe are dictated by DDDS).  In any case, E2M has the opportunity to lay the foundation for that.  I think that ENUM has proven to be problematic in some ways, and basically adding in another ENUM name space and calling it E2M may not be the best tact.

But on a separate point, why is this proposal looking for a WG home.  It seems pretty clear to me like Speermint, or Drinks should be the home for it.  And I say this regardless of what the solution is determined to be.

Thanks Bernie for furthering this discussion.
Ken

-----Original Message-----
From: Bernie Hoeneisen [mailto:[email-masked]]
Sent: Sunday, January 10, 2010 5:07 PM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

Hi Kenneth

cheers,
  Bernie

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.

---

From: [email-masked]
Date: Mon, 11 Jan 2010 16:20:42 +0000

Ken,

On reading your mail I am continually reminded of the mantra that 
perfection is the enemy of the good.  By trying to be all things to all 
people, we end up making something that's too complicated for anyone to 
use - just look what we did in DRINKS :(.

Sure, there are use cases for such things as non-E164 to URI (for 
e-mail-style AoRs, for example), and all that other stuff.  However those 
are hard problems which will take years of IETF effort to solve.

There's a specific need for particular forms of (meta-)data which would 
fit perfectly well inside E2U, were it not that the _semantics_ of that 
data are unacceptable to the ENUM purists.

The E2M proposal is a very minor adaption of the _proven_ RFC 3761 
technology, but without the semantic limitations.

Taking those drafts that are struggling to find a home in ENUM and 
updating them for E2M would be completely trivial, and IMHO should be done 
without delay.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 11 Jan 2010 12:09:17 -0500

Hi Ray,

I hear ya on the time frame.  Your need for something *now* for a specific sub-set of use cases can certainly trump a broader desire to cover the additional use cases that the three items in my previous response would cover.  But I think it's crystal clear that my last response is nowhere near targeting "perfection".  And suggesting that just muddies the discussion I think.  And again, monikers like "KISS" and "perfection should not be the enemy of the good" are not edifying, which is proved by the fact that you and I both apparently agree that "keeping things only as complex as necessary and no more so" is very good and that trying to achieve perfection in software is a waste of time.  In fact these are two fundamental principles I follow when architecting software.  However, these monikers do not mean that one should not attempt to solve the problem.  So we've basically debating *what* sub-set of problems need to be solved in what time frame.

So getting back to the point, perhaps an approach would be a phased one, where the first phase is to solve what folks determine to be the immediate needs, and the second phase is to build on that to meet a broader set of use cases.  Because I think you are right that E2M as proposed does definitely meet the need of some important use cases.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 11, 2010 11:21 AM
To: Cartwright, Kenneth
Cc: Bernie Hoeneisen; [email-masked]; [email-masked]
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

Ken,

On reading your mail I am continually reminded of the mantra that perfection is the enemy of the good.  By trying to be all things to all people, we end up making something that's too complicated for anyone to use - just look what we did in DRINKS :(.

Sure, there are use cases for such things as non-E164 to URI (for e-mail-style AoRs, for example), and all that other stuff.  However those are hard problems which will take years of IETF effort to solve.

There's a specific need for particular forms of (meta-)data which would fit perfectly well inside E2U, were it not that the _semantics_ of that data are unacceptable to the ENUM purists.

The E2M proposal is a very minor adaption of the _proven_ RFC 3761 technology, but without the semantic limitations.

Taking those drafts that are struggling to find a home in ENUM and updating them for E2M would be completely trivial, and IMHO should be done without delay.

Ray

________________________________

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 11 Jan 2010 18:25:31 +0100 (CET)

Hi Ken

On Mon, 11 Jan 2010, Cartwright, Kenneth wrote:

> So getting back to the point, perhaps an approach would be a phased one, 
> where the first phase is to solve what folks determine to be the 
> immediate needs, and the second phase is to build on that to meet a 
> broader set of use cases.

I have some difficulties getting what concrete Use Cases you have in mind. 
It would be much easier to address them, if we knew what those are.

cheers,
  Bernie

---

From: [email-masked]
Date: Mon, 11 Jan 2010 17:46:02 +0000

> I hear ya on the time frame.  Your need for something *now* for a 
> specific sub-set of use cases can certainly trump a broader desire 
> to cover the additional use cases that the three items in my 
> previous response would cover.

Looking at those three items:

> 1) Telephone calls and the services that surround them (e.g. calling
>    name, e911, etc, etc) need to work for both TN and URI lookup key
>    use cases.  If I understand your E2M/DDDS proposal, it will only
>    be usable if a TN (turned into a domain name) is the lookup key.
>    Do I understand your proposal correctly here?  It seems that allowing
>    a lookup key to be an arbitrarily formed string (rather than a
>    domain name) is a relatively minor change, so maybe E2M can be
>    designed to support that.

I've been involved with an NICC study on use of non-E.164 identifiers in 
next-generation-networks, which should be published shortly - it's real 
hard, particularly where portability is a requirement.

If this is a goal then there should be _separate_ and very wide ranging 
work at IETF about peering and routing for non-E.164-based calling.  I 
believe Otmar has called for this before.

In any event, the three known use cases for E2M are rather E.164 specific. 
 Send-N and Void are certainly 100% E.164 specific.  I'm not so sure about 
CNAM.

> 2) The response structure of a meta-data protocol should be allowed
>    to be fairly rich and nested (e.g. XML like).  Otherwise folks will
>    find yucky hacks in order to accomplish that within a protocol that
>    does not support it.  Perhaps E2M can be designed to support this.

Yes, trivially, by mirroring E2U+vcard, and allowing indirection to "rich" 
data sources.

> 3) It would be very good to be able to identify and use the source of a
>    lookup when formulating the response.  So at a *minimum*, it would
>    good to make sure that the solution proposed allows for a source
>    identification scheme to be overlaid.  This seems like a feasible 
feature
>    that perhaps E2M could support.

Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None of the 
three established use cases need it.

If you're thinking of DRINKS, didn't the design team ultimately conclude 
that the LUF (which happens to map nicely to ENUM) doesn't need this 
feature?

> ... snipped ... 
> However, these monikers do not mean that one should not attempt to 
> solve the problem.  So we?ve basically debating *what* sub-set of 
> problems need to be solved in what time frame.
>
> So getting back to the point, perhaps an approach would be a phased 
> one, where the first phase is to solve what folks determine to be 
> the immediate needs, and the second phase is to build on that to 
> meet a broader set of use cases.  Because I think you are right that
> E2M as proposed does definitely meet the need of some important use 
cases.

I think that we need to determine whether those other potential problems 
are in the same class as those that E2M is designed to solve.

I don't believe that they are even remotely in the same class, and would 
not like to see E2M being held up because of unrelated (and frankly, far 
larger) issues.

kind regards,

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 11 Jan 2010 14:01:24 -0500

In line..

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, January 11, 2010 12:46 PM
To: Cartwright, Kenneth
Cc: [email-masked]; Bernie Hoeneisen; [email-masked]
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

If this is a goal then there should be _separate_ and very wide ranging work
at IETF about peering and routing for non-E.164-based calling.  I believe
Otmar has called for this before. 

Don't hold your breath on that one. 

It actually is and in fact it is the major market driver for using the E2M
ENUM LUF. 

>    does not support it.  Perhaps E2M can be designed to support this. 

E2M+foo defines what you may ultimately look at. 

Right ..

feature 

Not necessarily .. for the peering function the LUF might return a different
URI based on the source. 

I don't believe that they are even remotely in the same class, and would not
like to see E2M being held up because of unrelated (and frankly, far larger)
issues. 

IMHO put the E2M structure in place and let people see what they want to use
if for. Any one of these preliminary use cases justifies the Development of
E2M. 

kind regards, 

Ray

---

From: [email-masked]
Date: Mon, 11 Jan 2010 20:12:02 +0000

> | If this is a goal then there should be _separate_ and very wide 
> | ranging work at IETF about peering and routing for non-E.164-based 
> | calling.  I believe Otmar has called for this before. 
> 
> Don’t hold your breath on that one. 

That's kind of my point.  Portability of non-E.164 is a massive topic and 
I, for one, don't want to see E2M caught up in it.
 
> | In any event, the three known use cases for E2M are rather E.164 
> | specific.  Send-N and Void are certainly 100% E.164 specific.  I'm 
> | not so sure about CNAM. 
> It actually is and in fact it is the major market driver for using 
> the E2M ENUM LUF. 

I thought that was probably the case - thanks for clarifying.
 
> E2M+foo defines what you may ultimately look at. 

Indeed.

> | Yes, trivially, by mirroring E2U+vcard, and allowing indirection to 
> | "rich" data sources. 
> 
> Right ..

Is that actual agreement, or do you mean "right" in the sense that you 
could, but probably shouldn't? ;-)

> | If you're thinking of DRINKS, didn't the design team ultimately 
> | conclude that the LUF (which happens to map nicely to ENUM) doesn't 
> | need this feature? 
> Not necessarily .. for the peering function the LUF might return a 
> different URI based on the source. 

OK, useful to know, but still no case (IMHO) for encumbering E2M with it 
when E2U doesn't.

> IMHO put the E2M structure in place and let people see what they 
> want to use if for. Any one of these preliminary use cases justifies
> the Development of E2M. 

+1, but don't complicate it with unspecified future use cases.  They'll 
likely need something completely different.

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 11 Jan 2010 18:28:05 -0500

a)       On Non-TN lookup keys, what you refer to as the "use of non-E.164 identifiers in next-generation-networks ... where portability is a requirement" is not on my radar screen.  So I'm not sure what you are referring to there.  What I was getting as was, for example, how would you envision looking up a calling name or a vcard using an email address, as apposed to a telephone number?  Having to have a separate protocol and a separate registry just because the lookup key takes a different form is not good.  Imo, E2M would necessitate the review of all the ENUM services that have been approved, and those currently under evaluation, such that all those services that are more appropriately under the e2m rather than e2u are moved over to e2m.  Aren't there many current and future ENUM services that are useful even for non-telephone-number lookup keys?  For example, wouldn't you want the ability to lookup a vcard or a calling name for an email like URI, just like you might want to look one up for a telephone number?
b)       On source identification, there is not yet a standardized approach to it for ENUM, but it is certainly commonly "hacked in" and done in practice using a couple different means.  As you alluded to, Drinks discussed a couple approaches that are used in practice.  And with respect to your question about the LUF, I do not think that source identification can be *disallowed* for a LUF service.  However, it is certainly true that some LUF services may not need/want to use it.
c)       On more rich response structures and query criteria, I guess there are they types of partial solutions and workarounds like those used in vcard that can be made to work for some cases.

On the whole, however, it sounds like you have your path set, and I see you have a need for urgency to get the solution in place to meet the uses case identified asap (which I can certainly sympathize with).  So as long as the distinction between E2U and E2M name spaces are clear then I guess the need that I see for a more full featured address-to-metadata-lookup-protocol is more appropriately somewhere other than the immediate E2M name space.

Ken

Subject: RE: [dispatch] E2M: Proposed Charter (draft version only)

>    designed to support that.

I've been involved with an NICC study on use of non-E.164 identifiers in next-generation-networks, which should be published shortly - it's real hard, particularly where portability is a requirement.

If this is a goal then there should be _separate_ and very wide ranging work at IETF about peering and routing for non-E.164-based calling.  I believe Otmar has called for this before.

In any event, the three known use cases for E2M are rather E.164 specific.  Send-N and Void are certainly 100% E.164 specific.  I'm not so sure about CNAM.

>    does not support it.  Perhaps E2M can be designed to support this.

Yes, trivially, by mirroring E2U+vcard, and allowing indirection to "rich" data sources.

>    identification scheme to be overlaid.  This seems like a feasible feature

Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None of the three established use cases need it.

If you're thinking of DRINKS, didn't the design team ultimately conclude that the LUF (which happens to map nicely to ENUM) doesn't need this feature?

> solve the problem.  So we've basically debating *what* sub-set of
> E2M as proposed does definitely meet the need of some important use cases.

I think that we need to determine whether those other potential problems are in the same class as those that E2M is designed to solve.

I don't believe that they are even remotely in the same class, and would not like to see E2M being held up because of unrelated (and frankly, far larger) issues.

kind regards,

Ray