Subject: [e2md] First cut of requirements write up

From: Jay Daley <[email-masked]>
Date: Wed, 7 Apr 2010 08:53:35 +1200

Following this morning's (ahem!) call I've written up my notes on requirements below.  Due to a small child demanding I turn the TV on I missed the fascinating bit that ended with a similarity being identified between French and German carriers handling cross-border calls.  If anyone can fill that in then I would be grateful.

Let me know what you think.

Jay

1.  Generic requirements

1.1 Access to data

1.1.1.  Public and private use cases
Each proposal has a public use case.  That is to say there is a valid requirement for that data to be published in  public database unencumbered by access control.  Most proposals have a private use case.  That is to say there are valid requirements for that data to be subject to access control.  For example:

- CNAM has an obvious private use case when the data personally identifies a private individual.  It also has a public use case, when the CNAM refers to a company and local regulation exists that requires companies to accurately identify themselves as the originator of telephone calls.

1.1.2 Mechanisms for controlling access
The alternate mechanisms for controlling access to data include:

a. indirection - some data is made public but only acts as a key, possibly along with other known data, into a private database.
b. source differentiation - a public or private database that validates the source that makes the requests and returns specific data for that source
c. private database - a wholly private database that access is only granted to by contractual agreement and on which all the data is the same (so no source differentiation).

1.1.3  Relationships between parties
The relationships between the various parties that produce and consume data, leading to access control requirements, are summarised as:

a.  A producer may choose to provide different information to different consumers.
b.  A producer may choose to provide no usable information at all to some consumers.
c.  A producers cannot expect a consumer to keep data secret from itself.  So if a consumer asks the same question of the producer and receives two different answers, for whatever reason such as source differentiation, then the consumer is trusted to use that data as the producer intends, it is not a requirement for a mechanism to prevent the consumer misusing that data.
d.  A producer may not wish for one consumer to know that it has published different data to another consumer.  So it may not want it obvious to a consumer that there is other data that it does not have access to.

1.2 Relevance

There are two known relevancy domains for the data:
	- for originating a call
	- for receiving a call

It is a requirement that the client that makes the lookup can separate out the data for the relevancy domain that it is interested in.  

1.2.1  Mechanisms for separating out relevancy domains
This may be achieved by:

	- a single query only returning information from one relevancy domain
	- the client filtering the returned values to extract those it requires

1.3  Performance requirements

The database needs the following performance characteristics:

a.  A real-time response (in the order of milliseconds).
b.  Scalable to hundreds of millions of keys.
c.  Scalable to millions of querying clients.
d.  Scalable to accommodate millions of changes per day.

It does _not_ need the following performance characteristics:

a. Deliver data greater that a few kilobytes in size.
b. Guaranteed consistency.

2.  DNS Protocol considerations

2.1 Access to data

The various 'pure' DNS mechanisms for controlling access are:

a.  Private trees.
b.  Only publishing an indirect key in DNS.

The various DNS+ mechanisms for controlling access are:

a.  Source-URI
b.  Replicating DNS on a different port and confining it to this data [Is this really what that proposal is about?]

2.2  Relevancy

The various mechanisms for separating out relevancy domains are:

a.  Private trees
b.  Different branches of the same tree.   So e164m.arpa for data needed to 'make' a call and e164r.arpa for data needed to 'receive' a call.
c.  Source-URI

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 7 Apr 2010 22:52:06 +0200 (CEST)

Hi all

To structure the E2MD work better I asked Henrik to provide us with a WiKi 
space for E2MD, and he immediately answered my request.

I then created a WiKi page for E2MD requirements and included Jay's 
First-Cut (incl. Dean's addition) to this page. Please find it on:

   http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList

Please from now on edit directly this WiKi page to add or modify 
requirements.

You need a login to edit the page: Your existing IETF login normally 
works. If you do not have an IETF login yet, just create one.

If we are done, this WiKi page will be the source for an I-D to be 
submitted.

cheers,
  Bernie

PS: I intend to use the WiKi also to collect the "list of objections" as 
agreed on the conf call. More about this later.

On Wed, 7 Apr 2010, Jay Daley wrote:

> Following this morning's (ahem!) call I've written up my notes on 
> requirements below.  Due to a small child demanding I turn the TV on I 
> missed the fascinating bit that ended with a similarity being identified 
> between French and German carriers handling cross-border calls.  If 
> anyone can fill that in then I would be grateful.
>

[...]

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 8 Apr 2010 15:28:35 -0400

Here are a few emails that I've sent over the past couple weeks, that contains what might be called requirements of the overall approach we take, and for the concept of source dependent responses.  However, I did not write them with the intention that they would become part of a "requirements document".  So they may need to be tightened up, etc, if that is the eventual intention.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Hoeneisen
Sent: Wednesday, April 07, 2010 4:52 PM
To: Jay Daley
Cc: E.164 To MetaData BOF discussion list
Subject: [e2md] New WiKi page for requirements (was: First cut of requirements write up)

Hi all

cheers,
  Bernie

> Let me know what you think.

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

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.

Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling
From: "Cartwright, Kenneth" <[email-masked]>
To: Richard Shockey <[email-masked]>, 'Hadriel Kaplan' <[email-masked]>, 'Jay Daley' <[email-masked]>, 'Dean Willis' <[email-masked]>
Cc: 'E.164 To MetaData BOF discussion list' <[email-masked]>
Date: Mon, 29 Mar 2010 16:37:01 -0400
List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" <e2md.ietf.org>

Now that maybe we’re back on track, here’s a rough re-statement of what one might like to see from this E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS, plus some orthogonal extensions:

1)  Have a standard query data structure for E2U and E2M from a *framework* perspective (DDDS and ENUM gives us this).

2)  Have a standard query response structure for E2U and E2M from a *framework* perspective (DDDS and ENUM gives us this).

3)  Have a standard query data structure for each E2U and E2M service within that framework (DDDS and ENUM gives us this).

4)  Have a standard query response structure for each E2U and E2M service within that framework (DDDS and ENUM gives us this).

5)  Have a standard way to identify the source of a query, both at the organization level, and down to the "device/node" level within an organization (Hadriel’s proposal gives us this).

6)  Have the *option* to return both E2U and E2M service responses in a single query response (I think the E2M proposal did not forbid this).

7)  Continue to allow "Bind" to function as, at least, a proxy pass-through client for queries.  Iow, the base query request/response structure needs to be backward compatible with "Bind" (DDDS and ENUM gives us this).

8)  Continue to allow both UDP and TCP as the layer 3 protocol (DDDS and ENUM gives us this).

9)  Have a standard way for the querier to specify, per query, which E2U and/or E2M services it is interested in having in its query response (although this is less vital, this is already done to a lesser extent today, but via non-standard means) (however, Hadriel’s proposal might also give us this).

10)  There is of course more detail that can be added, but it just gets too much for emails….

As you can tell, I very much like the framework approach that DDDS embodies, even though it has some shortcomings.  This is because a significant number of systems in existence today return data across multiple E2U and the proposed E2M services.  So using the same query/response framework greatly facilitates that type of situation.  So I'd like to see us stick with the framework approach offered by DDDS.  This question came up at the BOF (Should we use a framework or develop a separate dedicated, RR Type for each type of meta-data).

And as mentioned in previous emails, I've not really been a fan of the fact that we turn TNs into domain names to look them up.  In fact I think it’s pretty humorous.  However, that is a more principled/theoretical issue, not a practical one.  If we were to move away from treating TNs as domain names at this point, that would be too drastic a change, just to be able to lookup CNAM, unused, etc.

Ken

  _____

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, March 29, 2010 4:14 PM
To: 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

As for Dean ..No we should not shoot the messenger ..especially one that has so many guns.  I wish there was some focus here on what the problem is. How do we help SIP network operators work better. There is a clear and demonstrable problem that needs to be addressed in SIP PSTN interworking.  The discussion is getting wrapped up in orthogonal arguments about what is and is not appropriate use of DNS technology.

I almost got the sense in the BOF that folks thought ENUM itself was a mistake.  I know John Klensin almost wishes he had never heard the word :)  We have a mechanism for translating E.164 keys into FOO and it works quite well.  We need a mechanism that translates E.164 numbers into other types of FOO otherwise SIP does not work as well as it should.

An alternate port IMHO solves a load of problems and I don’t see any problem with that.  What I have a problem with is bashing up the proposed solutions here without understanding what problem we are trying to fix.

This alternate use of DNS technology is well understood and widely deployed. Gee we have split DNS right?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, March 29, 2010 3:40 PM
To: Jay Daley; Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

  _____

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
Sent: Monday, March 29, 2010 4:02 AM
To: Dean Willis

On 29/03/2010, at 7:19 PM, Dean Willis wrote:

1.  ENUM did not originate with carriers trying to pollute the Internet and the IETF did not bend over backwards to put phone numbers onto the Internet.  Quite the opposite.  There was a lot of opposition to ENUM from ITU types as they saw it as a cunning IETF plot to take over telephony.

There are many public ENUM trees (at the country code level), it is hard to see what is really more in the DNS than that.  The success of ENUM in a private context is surprising given the original hostility to ENUM from some carriers, but is not an indication that this is a private protocol.

Most carriers I’ve talked to were not hostile to ENUM using DNS the protocol – they were hostile to the data being put in The DNS.  They actually like the properties of the protocol, a lot.

Carriers are not working against the best interests of the Internet, they are just trying to bring their experience, their values and their way of working to the Internet.  You might disagree with those but nobody holds the keys to the Internet, that is the whole point.

I think you misunderstand Dean – he’s being the messenger, not the source.  That’s part of his role as the BOF Chair.

3.  I don't mean to be rude but I don't think you understand DNS at all.  For a start we are not taking about making changes to the DNS at all because NAPTR already exists.   All we are talking about it a standard data representation within NAPTR.

Actually he’s relaying the comments he got from other IETF folks, again as his role as BOF Chair and trying to help us move forward.  And for some of the mechanisms we need for ENUM, some IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to the database.  We’ve heard it consistently for the past 2 years: “this stuff doesn’t belong in The DNS”.  I and you and others feel there’s nothing wrong with putting the data we want into The DNS, but if we have to get every piece of data we want past a consensus call as well as the IESG, then we should to listen to them.

-hadriel

  _____

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.

Subject: Re: [e2md] Alternative to source URI
From: "Cartwright, Kenneth" <[email-masked]>
To: Jay Daley <[email-masked]>, Hadriel Kaplan <[email-masked]>
Cc: E.164 To MetaData BOF discussion list <[email-masked]>
Date: Wed, 31 Mar 2010 11:54:02 -0400
List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" <e2md.ietf.org>

Source based responses can be selected at three levels of granularity (depending on the policy driven need of the given use case):

1) Source Organization (done today through non-standard means such as a different root domain to the same DNS server)
2) Source Node/IP (done today through non-standardized means such as source IP address of the DNS query)
3) Source Person/Identity (done today via non-standardized means such as the callers SIP URI)

Does what you propose directly support all three, directly support a subset of the three, get in the way of any of the three, ignore any of the three, etc?  Granted I've not had the time to follow all of these emails, but it's not clear to me that it supports 2 and 3.  Sorry if I missed something in a previous email.  If so please just point me at that email and I will read/reread it.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
Sent: Wednesday, March 31, 2010 12:02 AM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote:

>> Assuming the proxy is "allowed" to know this then they either have two
>> sets of private data, one for the source carrier that services 67890 and
>> one for the source carrier that services 88888.  Or if the originating
>> carrier is the same then just one set of private data that identifies the
>> source within it:
>>
>>      meta-endpoint -> source -> actual-endpoint
>
> It is the same source carrier for both calls originating from 77777 and 88888, hence the rub - even if the destination carrier says "meta-endpoint", the source carrier needs to do a lookup (somewhere) that takes the source number into account.  In other words *someone* has to do a source-based lookup, and that someone could/would use source-uri.

I might be being thick here but I don't get why you think the only solution is source-uri.  What effect is achieved by source-uri that is not achieved by the scheme I'm suggesting?  As far as I can tell they achieve exactly the same thing.

cheers
Jay

> -hadriel

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

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.

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

Subject: Re: [e2md] Alternative to source URI
From: "Cartwright, Kenneth" <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, list <[email-masked]>
Date: Thu, 1 Apr 2010 10:01:06 -0400
List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" <e2md.ietf.org>

I think the disconnect in our common understandings is this statement you you've made:

"That is achieved by deciding to whom to give what private data."

I think the statement presumes that we are *pushing* a private data set *down/out* to the organization that wants/isAllowedTo to see that private dataset.  The solution cannot be predicated on that operational model.  With respect to the location of the "private" data as you call it, there are two models:

1) Shared/Central Resolution Server Model:  The private data sets are not pushed down to the organization that has visibility to that private data, but instead sits in a common location where access and visibility into the data is controlled.  Under many circumstances it is not permissible from a business model, and/or privacy, and/or scalability perspective to push the "private" data down to each individual organization that wants to query it.
2) Private/Local Resolution Server Model:  The private views into the larger data set are created, updated, and pushed down to local resolution servers owned/operated/hosted by the organization that has visibility into that view.

The solution needs to support both of these models.

Ken

-----Original Message-----
From: Jay Daley [mailto:[email-masked]]
Sent: Wednesday, March 31, 2010 4:33 PM
To: Cartwright, Kenneth
Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

On 1/04/2010, at 4:54 AM, Cartwright, Kenneth wrote:

> Source based responses can be selected at three levels of granularity (depending on the policy driven need of the given use case):

thanks, this is very helpful.

> 1) Source Organization (done today through non-standard means such as a different root domain to the same DNS server)

That is achieved by deciding to whom to give what private data.

> 2) Source Node/IP (done today through non-standardized means such as source IP address of the DNS query)

This is presumably an indirect mechanism for a different form of source based filtering - in other words it is not the IP that actually matters but who is using that IP?

If is actually the IP then that is achieved by the contents of the private data.

> 3) Source Person/Identity (done today via non-standardized means such as the callers SIP URI)

That is achieved by the contents of the private data.

> Does what you propose directly support all three, directly support a subset of the three, get in the way of any of the three, ignore any of the three, etc?  Granted I've not had the time to follow all of these emails, but it's not clear to me that it supports 2 and 3.  Sorry if I missed something in a previous email.  If so please just point me at that email and I will read/reread it.

I think it does support all three but I need to understand the purpose of 2 a bit better to be sure, assuming you think I have explained 1 and 3 well enough.  Can you provide more detail?

thanks
Jay

>
> Ken
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
> Sent: Wednesday, March 31, 2010 12:02 AM
> To: Hadriel Kaplan
> Cc: E.164 To MetaData BOF discussion list
> Subject: Re: [e2md] Alternative to source URI
>
>
> On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote:
>
>>> Assuming the proxy is "allowed" to know this then they either have two
>>> sets of private data, one for the source carrier that services 67890 and
>>> one for the source carrier that services 88888.  Or if the originating
>>> carrier is the same then just one set of private data that identifies the
>>> source within it:
>>>
>>>     meta-endpoint -> source -> actual-endpoint
>>
>> It is the same source carrier for both calls originating from 77777 and 88888, hence the rub - even if the destination carrier says "meta-endpoint", the source carrier needs to do a lookup (somewhere) that takes the source number into account.  In other words *someone* has to do a source-based lookup, and that someone could/would use source-uri.
>
> I might be being thick here but I don't get why you think the only solution is source-uri.  What effect is achieved by source-uri that is not achieved by the scheme I'm suggesting?  As far as I can tell they achieve exactly the same thing.
>
> cheers
> Jay
>
>
>>
>> -hadriel
>
>
> --
> Jay Daley
> Chief Executive
> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md
>
> 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.
>

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.

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