Subject: [e2md] Alternative to source URI

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 10:14:36 +1300

Correct me if this is wrong but the basic premise of the source-URI proposal is for each recipient to get a different answer, depending on they are.  One way (1) of achieving this is to give a different response depending on who asks, but it is not the only way.

The alternative (2) is simple indirection combined with private data.

So (1) goes
- determine who has asked
- find appropriate data
- send it to them

and (2) goes
- send private data beforehand to different parties
- when anyone asks for data give the same public data
- each recipient then use the public data as a key into their private data.  Each recipient with different private data will get a different answer.

(2) does not require any change to DNS, eliminates all issues of privacy, deals with caching and wildcards and just works.

A more concrete example:

- under 7.7.6.9.1.3.9.4.4.6.whatever is published
	NAPTR "e2md" "meta-endpoint:endpoint-1"

- my best buddy carrier has private data that says
	"endpoint-1" is serviced by "sip:6449316977@somewhere-special"

- all other carriers I am forced by regulators to connect to have data that says
	"endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner"

any thoughts?
Jay

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 17:29:00 -0400

Unfortunately it's not who asked the DNS query. (otherwise we could just use IP-Address based views)
It's who originated the application request, which triggered the DNS query (possibly by a third party).

For example, in a private carrier model where proxies generate the ENUM-DNS query when they get SIP requests, it's the SIP URI of the originator of the SIP request.

The primary use-case of it is in the SIP or H.323 routing use-case with ENUM, where the source of the call affects how the call gets routed. (for a bunch of reasons)

So (2) wouldn't work because the same DNS client needs to use different result data for the same query key, based on where the SIP request came from.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jay Daley
> Sent: Monday, March 29, 2010 5:15 PM
> To: E.164 To MetaData BOF discussion list
> Subject: [e2md] Alternative to source URI
> 
> Correct me if this is wrong but the basic premise of the source-URI
> proposal is for each recipient to get a different answer, depending on
> they are.  One way (1) of achieving this is to give a different response
> depending on who asks, but it is not the only way.
> 
> - each recipient then use the public data as a key into their private data.
> Each recipient with different private data will get a different answer.
> 
> (2) does not require any change to DNS, eliminates all issues of privacy,
> deals with caching and wildcards and just works.
> 
> A more concrete example:
> 
> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 16:34:12 -0500

On Mar 29, 2010, at 4:14 PM, Jay Daley wrote:
> ...
> - each recipient then use the public data as a key into their  
> private data.  Each recipient with different private data will get a  
> different answer.
>
> (2) does not require any change to DNS, eliminates all issues of  
> privacy, deals with caching and wildcards and just works.
>
> A more concrete example:
>

I think it's very interesting.

A fairly large number of people in Anaheim told me that they thought  
that the DNS's "immune system" would be open to putting in a pointer  
to a general metadata-lookup service along these lines.

The model they seemed to have in mind is that "The DNS" would have a  
per-phone-number (or per-phone-number-aggregation) record that would  
point to the metadata service for that phone number or aggregation- 
range.

This eliminates many of the concerns:

1) We don't end up putting an additional record into the DNS for each  
piece of metadata

2) We don't have to define a selective-query or search mechanism on  
top of DNS

3) We don't have very-large RR-sets in responses due to having many  
different metadata types

4) We don't need to extend DNS to support source-specific responses

5) Authentication and authorization concerns are pushed out of the  
DNS's core and onto "the other protocol/service"

The one repeatedly-heard concern that I know of that this proposal  
doesn't directly address is the "framework vs. individual use case"  
issue. However, I believe that the main reason this issue comes up is  
that adding arbitrary metadata into the DNS is considered a problem  
due to to the questions above, which Jay's #2 proposal neatly  
bypasses. So, I don't think we'd have nearly the problem with saying  
that the external metadata service returns metadata within an  
extensible schema that we have with building an extensible metadata  
schema directly in the DNS.

Further, the "metadata" service that the URI points to could well have  
all the fast-lookup properties that we know and love from DNS. One  
might think of the URI as being something of a "metadata delgation".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 16:36:42 -0500

On Mar 29, 2010, at 4:29 PM, Hadriel Kaplan wrote:

> For example, in a private carrier model where proxies generate the  
> ENUM-DNS query when they get SIP requests, it's the SIP URI of the  
> originator of the SIP request.
>
> The primary use-case of it is in the SIP or H.323 routing use-case  
> with ENUM, where the source of the call affects how the call gets  
> routed. (for a bunch of reasons)
>
> So (2) wouldn't work because the same DNS client needs to use  
> different result data for the same query key, based on where the SIP  
> request came from.

2 would apparently work if the "other protocol" used to dereference  
the E2MD URI conveyed the source information.

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 17:37:52 -0400

This approach is less amenable to my needs and seems un-necessarily slow and complex for the use cases we have.  However, there is of course nothing that says that a given E2U/E2M service cannot re-direct to another URL if that is appropriate for that service.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Monday, March 29, 2010 5:34 PM
To: Jay Daley
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

--
Dean

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: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 10:41:13 +1300

Sorry Hadriel I don't get what you are saying.

> For example, in a private carrier model where proxies generate the ENUM-DNS query when they get SIP requests, it's the SIP URI of the originator of the SIP request.

It is the originators who have the "private" data, not the proxies.

> The primary use-case of it is in the SIP or H.323 routing use-case with ENUM, where the source of the call affects how the call gets routed. (for a bunch of reasons)

Which is specifically what I intended it for. 

> So (2) wouldn't work because the same DNS client needs to use different result data for the same query key, based on where the SIP request came from.

I don't see what the DNS client has to do with it - it just passes on the data to higher up the stack where the keying into the private data takes place.

If you could help me understand then I would appreciate it.

thanks
Jay

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 10:52:57 +1300

On 30/03/2010, at 10:37 AM, Cartwright, Kenneth wrote:

> This approach is less amenable to my needs and seems un-necessarily slow and complex for the use cases we have. 

Can you explain why?

I think it is actually faster as per this explanation:

For (1) there are two additional lookups to plain DNS

- lookup to check the validity of the source URI
- lookup to retrieve information specific to the source URI

for (2) there is only one additional lookup and that is done by the recipient of the data not you

- lookup to find private data keyed to public data

It also seems far less complex

- the information given out in DNS is always the same
- there is no issue with spoofing of the source/validation of the source

cheers
Jay

> However, there is of course nothing that says that a given E2U/E2M service cannot re-direct to another URL if that is appropriate for that service.
> 
> Ken
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 21:05:23 -0400

Sorry I thought you meant based on which endpoint made the DNS query.
Maybe I'm confused as to the proposal in general. :)

Basically, as far as I know, those of using it are using it in private settings.  You get a SIP call from an endpoint/pbx/peer, and you do a routing lookup by querying a private DNS server using ENUM, which returns the NAPTRs for routing it on.  But due to different tariffs and peering policies, where you route it on to depends on where it came from.  In some contexts this is just a trunk difference - if it came from peer X with target number Y then send it to Z.  In other cases it's a number prefix difference - if it comes from prefix X with target number Y then send it to Z.

So let's assume destination Y is 12345.  I am a proxy.  I get a SIP request for destination 12345, from source 77777.  I query 5.4.3.2.1.foo.
What do I get back?  How do I use what I get back to determine how to route it, given this specific case is for source 67890, which is a different route than if I got a SIP request for the same destination but from source 88888?

-hadriel

________________________________________
From: Jay Daley [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 5:41 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

thanks
Jay

-hadriel

-----Original Message-----

So (1) goes

and (2) goes

A more concrete example:

- all other carriers I am forced by regulators to connect to have data
that says
	"endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner"

any thoughts?
Jay

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 21:25:11 -0400

I think I'm understanding your concern more now.  You're thinking of it in the public DNS context (ie, The DNS).
In the private ENUM model it's the same server or database that has to answer the routing question, so moving the problem around doesn't help.

In the public model you're right the public server has no idea how to route the request from and through any given carrier.

For that model I think some of us are thinking this would be where the SPID/SPN comes in.  The public servers would just return a SPID/SPN which the originating/transit carriers would use for their internal lookups.
There would be no source-based distinction for the public entries - the same SPID/SPN would represent the terminating/final administrative domain regardless of source.

In that sense it *is* a form of indirection, I suppose.
But internally within the originating/transit domains they'd need source-uri, because that SPID/SPN key still gets different results based on the source. (and in the US the SPID/SPN wouldn't be enough for an internal lookup key, unless each LATA gets its own SPID/SPN)

Although I could argue source-uri could still be useful in a public context, so that for example a public ENUM of NZ numbers could say "if the call comes from +64, use this SPID, if it comes from the anything else use this SPID, except if it comes from +61 then don't call us". :)

-hadriel

> Sent: Monday, March 29, 2010 5:53 PM
> To: Cartwright, Kenneth
> > However, there is of course nothing that says that a given E2U/E2M
> service cannot re-direct to another URL if that is appropriate for that
> service.
> >
> > Ken
> >
> Dean Willis
> > are not the intended recipient, please contact the sender by reply e-
> mail and destroy all copies of the original message.
> >
> 
> 
> --
> Jay Daley
> Chief Executive

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 21:26:38 -0400

> Hadriel Kaplan
> Sent: Monday, March 29, 2010 9:05 PM
> 
> So let's assume destination Y is 12345.  I am a proxy.  I get a SIP
> request for destination 12345, from source 77777.  I query 5.4.3.2.1.foo.
> What do I get back?  How do I use what I get back to determine how to
> route it, given this specific case is for source 67890, which is a
> different route than if I got a SIP request for the same destination but
> from source 88888?

Ugh, I meant "... given this specific case is for source 77777..."

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 15:16:38 +1300

> In the public model you're right the public server has no idea how to route the request from and through any given carrier.

Yes indeed.  There is an extraordinary spectrum of views that any solution needs to address.  At one end we have carriers who believe that even making the existence of a number public is a privacy violation and at the other end there are those who believe all the data should be public.  I'm interested in one flexible solution that can be used in both ways.  

The benefit of E2U + E2MD being delivered in one set of NAPTRs is that the spectrum of views is effectively encoded in those records (in a public tree).  Those brave souls who allow public connection specify an E2U, those that want control specify an E2MD.  The originator just does one lookup to see what options they have.

> There would be no source-based distinction for the public entries - the same SPID/SPN would represent the terminating/final administrative domain regardless of source.

It needs to be an abstract identifier to deal with issues some carriers have expressed to me of not advertising their network topology.

> But internally within the originating/transit domains they'd need source-uri, because that SPID/SPN key still gets different results based on the source. (and in the US the SPID/SPN wouldn't be eno…

I presume this is the same point as in your previous message so I'll answer it there.

> Although I could argue source-uri could still be useful in a public context, so that for example a public ENUM of NZ numbers could say "if the call comes from +64, use this SPID, if it comes from t…

Or just give them blank private data!

best
Jay

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 15:23:36 +1300

> What do I get back?  How do I use what I get back to determine how to route it, given this specific case is for source 67890, which is a different route than if I got a SIP request for the same des…

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

The latter will have to exist anyway since it allows the private data to encode transit arrangements (e.g.  I'll accept your calls destined for city B that originate in city A at my interconnect in city A because we've agreed you will do the same.)

cheers
Jay

---

From: [email-masked]
Date: Tue, 30 Mar 2010 09:56:54 +0100

> point to the metadata service for that phone number or aggregation- 

I believe that that's conflating too many of the existing and potential 
use cases.

It still makes absolute sense (IMHO) to have "unused/void" and "send-n" 
exist as real (meta-)data in the ENUM tree, as their entire intent is to 
be returned instead of "normal" NAPTR results to optimise dialling and 
calling.

> DNS's core and onto "the other protocol/service"

If you (re-)read the message I sent to you and Dispatch on 8th March 
you'll see that this is very similar to Jay's proposal.  This is 
unsurprising as we jointly worked on a similar proposed specification for 
the UK's number portability database before Jay headed to the Antipodes. 
This proposed solution is equivalent to the SPEERMINT "LUF", with the 
second stage lookup equivalent to the "LRF".  However unlike SPEERMINT 
this version has the desirable (IMHO) property that it's source invariant, 
as you mention in 4) above.

Ray

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2010 04:03:19 -0500

On Mar 30, 2010, at 3:56 AM, [email-masked] wrote:

> I believe that that's conflating too many of the existing and  
> potential use cases.
>

I think it covers the cases "about the number", but probably not the   
"send-n" case, which is more "about the tree". I'm on the fence as to  
which approach to take with "unused".

> It still makes absolute sense (IMHO) to have "unused/void" and "send- 
> n" exist as real (meta-)data in the ENUM tree, as their entire  
> intent is to be returned instead of "normal" NAPTR results to  
> optimise dialling and calling.

I agree, at least for send-n.

> unsurprising as we jointly worked on a similar proposed  
> specification for the UK's number portability database before Jay  
> headed to the Antipodes.  This proposed solution is equivalent to  
> the SPEERMINT "LUF", with the second stage lookup equivalent to the  
> "LRF".  However unlike SPEERMINT this version has the desirable  
> (IMHO) property that it's source invariant, as you mention in 4)  
> above.
>

You're talking about the I-D on destgroups?

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 22:23:35 +1300

On 30/03/2010, at 9:56 PM, [email-masked] wrote:

> I believe that that's conflating too many of the existing and potential use cases. 
> 
> It still makes absolute sense (IMHO) to have "unused/void" and "send-n" exist as real (meta-)data in the ENUM tree, as their entire intent is to be returned instead of "normal" NAPTR results to optimise dialling and calling.

I have been told repeatedly by carriers that there are privacy issues over publishing "unused/void" in a public tree because it tells other carriers what numbers they have in service.  Has this been tackled in NICC?  

Anyone else care to comment?

cheers
Jay

> If you (re-)read the message I sent to you and Dispatch on 8th March you'll see that this is very similar to Jay's proposal.  This is unsurprising as we jointly worked on a similar proposed specification for the UK's number portability database before Jay headed to the Antipodes.  This proposed solution is equivalent to the SPEERMINT "LUF", with the second stage lookup equivalent to the "LRF".  However unlike SPEERMINT this version has the desirable (IMHO) property that it's source invariant, as you mention in 4) above. 
> 
> Ray 
>

---

From: [email-masked]
Date: Tue, 30 Mar 2010 10:32:50 +0100

> You're talking about the I-D on destgroups?

Yes.

Ray

---

From: [email-masked]
Date: Tue, 30 Mar 2010 10:36:00 +0100

> I have been told repeatedly by carriers that there are privacy 
> issues over publishing "unused/void" in a public tree because it 
> tells other carriers what numbers they have in service.  Has this 
> been tackled in NICC? 

No, it hasn't.  At NICC we withdrew "unused" from the requirements.

Ray

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 12:15:18 -0400

> Sent: Monday, March 29, 2010 10:24 PM
> To: Hadriel Kaplan
> 
> 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:
> 

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.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 12:58:39 -0400

This doesn't solve the problem at all - it just moves it around.
What protocol do you think we would use to access the "metadata" referenced?
Answer: DNS.

-hadriel

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 30 Mar 2010 13:30:26 -0400

I see the merits of it as a way to allay the concern about putting this data into "The DNS". But from my perspective, I do not plan to put this data in "The DNS" anyway.  But if there are folks that do plan to put this data in "The DNS" then this may very well be helpful.  But for my use cases, it is entirely un-necessary.  So, I think, my use cases are basically interested in what the solution is *after* the location of the private data has been determined.  And if that portion of the solution adheres to the 10 rough requirements I stated in my email yesterday then *I think* I'm ok with what is proposed below.

So from my perspective, you're suggesting that the solution be broken in two, (1) a mechanism to achieve indirection to the meta-data location, and (2) a mechanism to query and resolve the meta-data (the latter here being the problem that I think we are really working to solve).  And the use of part (2) here can exist without the use of part (1) in the case of data that is not in "The DNS".

One potential issue here though, is the case where a server needs to serve up both E2U service information and E2M service information.  I assume that that private source could server up both E2U and E2M.

It does see a little contrived however, which concerns me a bit because there could be corner case issues that we've not thought of yet.  And Hadriel accurately suggests that, to a certain extent, this just moves the solution space.  But maybe that is enough to allay the concerns.

Ken

-----Original Message-----
From: Jay Daley [mailto:[email-masked]]
Sent: Monday, March 29, 2010 5:53 PM
To: Cartwright, Kenneth
Cc: Dean Willis; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

Can you explain why?

cheers
Jay

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 30 Mar 2010 22:21:30 +0200

On 29.03.2010 23:34, Dean Willis wrote:
> that the DNS's "immune system" would be open to putting in a pointer to
> a general metadata-lookup service along these lines.

As others have noted, speermint's LUF / LRF distinction also leads in this
direction.

> point to the metadata service for that phone number or aggregation-range.
> 
> 2) We don't have to define a selective-query or search mechanism on top
> of DNS
> 
> 5) Authentication and authorization concerns are pushed out of the DNS's
> core and onto "the other protocol/service"

I see a slightly different split between the "direct data retrieval" and
the "getting a key for a second look-up" use-cases:

For me, if the use-case needs 2) (a more expressive query language) or 4)
(different answers depending on who's asking), then a pure ENUM-like
solution won't cut it and ENUM/E2MD needs to refer to another lookup mechanism.

This way, the DNS continues to serve as simple directory and no assumptions
on its operational parameters need to be re-evaluated.

Your 5) isn't that much of a deal-breaker for me, private trees usually can
handle this good enough.

---------

So I'd view CNAM as a use-case where you put the actual data in your
(probably private) DNS. After all, the name is the same regardless of who
queries. (only access rules might apply, e.g. for emergency services)

Regarding the overhead of a second query, e.g. for determining SIP routing
information (outbound proxy, source dependent): I think that a good
selection of the ENUM/E2MD (= the LUF) return values (e.g. destination
groups) will enable very efficient caching of the answers retrieved from
the second stage query (the LRF).

For example: if simple E2MD queries yield the categorization of both
calling and called number, then the routing decision is the same for all
other calls where caller and callee are mapped to the same
destination-group pair.

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2010 22:07:11 -0500

"Hadriel Kaplan" <[email-masked]> wrote:

>Answer: DNS

I believe you were describing a protocol you called ENS when were in Anaheim.  ENUM points via a NAPTR to an ENS entry point, and ENS can then do all the things we wanted do do in DNS but couldn't get past the immune system.

-- 
Dean Willis

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2010 23:25:29 -0500

On Mar 30, 2010, at 12:30 PM, Cartwright, Kenneth wrote:

> I see the merits of it as a way to allay the concern about putting  
> this data into "The DNS". But from my perspective, I do not plan to  
> put this data in "The DNS" anyway.  But if there are folks that do  
> plan to put this data in "The DNS" then this may very well be helpful.

The argument that we're not getting goes like this: Once the IETF has  
blessed the specifications for putting X in the DNS protocol (which  
they would need to do to let us use the DNS protocol for our private  
installations), then some yokel will come along and say "Gee whiz,  
Mom! The IETF says I should put my diary in The DNS!" and proceeds to  
do so.

Since this proposal can in no way be used to put a diary or other  
cruft into The DNS, it should be no more offensive to the DNS  
directorate than ENUM currently is (which is non-zero, but something  
they can't really complain about). Now it might well let somebody put  
a pointer to his diary into the DNS, but how is that any worse than  
having a pointer to wikipedia in there?

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Wed, 31 Mar 2010 17:01:54 +1300

> 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 (somewhe…

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

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 31 Mar 2010 09:12:35 -0400

You do not seem to be directly responding to what I said.  I said "I see the merits of it as a way to allay...".   So Yes.  I get that.  I don't agree with it, because the realities I have lived and observed around how the systems and code that underlies "The DNS" is architected, maintained, managed, and operated do not at all bear that out.  But perhaps you did not like the fact that my underlying opinions bleed through in my email below.  Sorry about that, it just resulted in some email spam here.  But believe me, I get that.  That's why I agreed with the rough outline of Hadrliel's proposal and in the email you responded to below to basically create a spec that formally moves the problem space I said "I see the merits of it".

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, March 31, 2010 12:25 AM
To: Cartwright, Kenneth
Cc: Jay Daley; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Alternative to source URI

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 31 Mar 2010 11:54:02 -0400

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

cheers
Jay

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Mar 2010 12:59:17 -0400

> I might be being thick here but I don't get why you think the only
> solution is source-uri.  

Oh it may well be *me* being thick.  :)

But I'm not saying the source-uri mechanism in particular is the _only_ solution - I mean you could skin the cat many ways.  I just think skinning the cat requires looking up some database at some point with a key that has source information - not the source of the query to the DB, but the source of the call.

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

Then I clearly don't understand your proposal. :(

Afaict, what you're proposing is that given a query to destination 5.4.3.2.1.foo, you'd return a "key" which I would locally interpret, but that same key value someone else would interpret differently.  That's all fine, but it doesn't solve my problem:
My problem is that when I do a query for 5.4.3.2.1.foo, sometimes it needs to resolve to answer1, and sometimes to answer2 - for the *same* client that asks the question/query.  What decides whether it's answer1 or answer2 is the source number/info of the SIP request.

In the public DNS context I assume that in general the servers won't know whether its answer1/answer2 or even that there are multiple answers.  All I need from them is a SPID or a Dest-Group or whatever - some form of aggregator "key" as you put it, which then gets used in my local/private next-stage, but I still need the source info to be used in that next-stage.

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Thu, 1 Apr 2010 09:33:27 +1300

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

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

---

From: Jay Daley <[email-masked]>
Date: Thu, 1 Apr 2010 09:41:07 +1300

> My problem is that when I do a query for 5.4.3.2.1.foo, sometimes it needs to resolve to answer1, and sometimes to answer2 - for the *same* client that asks the question/query.  What decides whethe…

The local interpretation is effectively looking up a tuple of

	"source number/info of the SIP request", "key", "answers"

so the private data actually encodes within it everything needed to produce either answer1 or answer2.

Does that explain it?

> In the public DNS context I assume that in general the servers won't know whether its answer1/answer2 or even that there are multiple answers.  All I need from them is a SPID or a Dest-Group or wha…

So are you saying this lookup into private data will be done by a third party who does not know the source info?  

If so then does the mechanism look like this?:
	Originator O wishes to connect to Destination D through Proxy P
	O gives P some Source Info S that P cannot read or interpret
	P passes S to D
	D can interpret S and so responds to P with data based on that

Jay