Subject: [Modern] FW: Modern Digest, Vol 3, Issue 19

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 21 Oct 2014 19:41:23 +0000

Re Adam's issue below, I don't think some level of access control rules out access by OTT.
Recall that the FCC already trialed giving numbering resources directly to  OTT SPs.
I'd distinguish between high barriers and reasonable obligations.

Penn

Hrm. I've heard OTT providers tossed around in this discussion as a 
potential consumer of this data. It sounds like the last few messages 
have been angling towards solutions that would provide high barriers to 
entry to becoming such a provider.

I'm thinking we should put some thought into how to deploy a system that 
doesn't exclude small new players, while honoring the valid operational 
concerns of incumbents. I'm very suspect of the naive approach of "well, 
let's just make it a secret database that requires a special handshake 
and/or the right amount of money to access."

Subject: Re: [Modern] Services
From: Adam Roach <[email-masked]>
To: "McGarry, Tom" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 21 Oct 2014 18:07:00 +0000

Hrm. I've heard OTT providers tossed around in this discussion as a
potential consumer of this data. It sounds like the last few messages
have been angling towards solutions that would provide high barriers to
entry to becoming such a provider.

I'm thinking we should put some thought into how to deploy a system that
doesn't exclude small new players, while honoring the valid operational
concerns of incumbents. I'm very suspect of the naive approach of "well,
let's just make it a secret database that requires a special handshake
and/or the right amount of money to access."

/a

On 10/21/14 12:42, McGarry, Tom wrote:
> So there seems to be some pushback on a "public DB" and I tend to agree.
> This is why I've advocated that the administrator distributes these DBs to
> others, e.g., ISPs.  Make them part of service providers' infrastructure
> with all the attendant security.  The challenges here are around updating
> it and securing the data from the entity that is now hosting it.  Securing
> primarily means making sure it can't be modified.  But it could even mean
> protecting it from being mined.
>
>
>
> On 10/20/14 11:34 PM, "Henning Schulzrinne" <[email-masked]>
> wrote:
>
>> <html>
>> I suspect we're trying to get at how many levels of indirection we allow
>> before we arrive at RFC 3263 and where, in one or more places, choices of
>> service are expressed.
>>
>> Whether you designate a SPID or a domain name, there then has to be a
>> second step to get something resolvable. Needless to say, you could use
>> both, since a SPID would presumably translate mechanically into a domain
>> name like 1234.neca.org
>>
>> Also, I'm confused by the model that people have in mind - we seem to
>> simultaneously be talking about information that is being returned by a
>> public number directory (before you know who is "in charge" of the
>> number) and highly-customized information that differs based on who's
>> asking.
>>
>> We need both, and they may well use the same wire protocol, but, if we
>> have some kind of public numbering database, it can't tailor its response
>> to the querier, by definition.
>>
>> To make this a bit more concrete:
>>
>> (1) Query a public numbering database with the MODERN protocol, with
>> input "number, service". Get a SPID or domain name, say modern.att.net.
>>
>> (2) Query domain name modern.att.net with MODERN, but with
>> authentication. Return customized SIP URL(s). [If the querier has no
>> relationship to modern.att.net, it would presumably get a generic answer
>> for carriers without special arrangement or some version of "go away".]
>>
>> (3) Use RFC 3263 process for those URLs.
>>
>> Is that what people have in mind?
>>
>> ________________________________________
>> From: Brian Rosen [[email-masked]]
>> Sent: Monday, October 20, 2014 10:11 AM
>> To: Henning Schulzrinne
>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK];
>> [email-masked]
>> Subject: Re: [Modern] Services
>>
>> Okay, perhaps we are.
>>
>> I think ³media² is not a good service, but we¹ll see.  I think it¹s more
>> like voice/video/text/event.  They can always all have the same response.
>> I think that using SRV is not a good enough routing protocol, although
>> allowing it would be fine with me.  SRV, like lots of things, does not
>> properly consider the source, nor the location, both requirements.
>>
>> It might be okay to have a two step route where the first step resolves
>> to a rendezvous for negotiation of the signaling and media interchange
>> points, but I would think that would be the result of the first ³modern²
>> query = it returns a URI where you negotiate interchange.  The second
>> step would have some notion of location and source identity and returns
>> route.
>>
>> Brian
>>
>>
>>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne
>>> <[email-masked]> wrote:
>>>
>>> I suspect we're talking past each other. I'm not advocating a "golden
>>> root" or anything that looks like ENUM number-based mapping. As a
>>> strawman, consider a JSON response within the MODERN context to a query
>>> for a phone number, returning for you
>>>
>>> "media": "myphone.brianrosen.net"
>>>
>>> with myphone.brianrosen.net
>>>
>>> resolving to
>>>
>>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
>>>
>>>
>>> I assume we don't want to put IP addresses directly into the response,
>>> so DNS enters the picture at some point.
>>>
>>> The alternative is to use the SRV or NAPTR service field (here,
>>> _sip._tcp) directly in the MODERN response. I can see advantages to both.
>>>
>>> Henning
>>>
>>> ________________________________________
>>> From: Brian Rosen [[email-masked]]
>>> Sent: Monday, October 20, 2014 9:51 AM
>>> To: Henning Schulzrinne
>>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK];
>>> [email-masked]
>>> Subject: Re: [Modern] Services
>>>
>>> I really would like to get away from DNS entirely.  We can reuse
>>> concepts, but I think DNS is not the appropriate way to get anything to
>>> do with E.164s.
>>> ENUM was a mistake, and one of the mistakes was using DNS.  It¹s not
>>> the appropriate query mechanism, and it has a golden root problem.  I
>>> remember well the DNS guys questioning whether DNS was the right
>>> protocol when we started ENUM.  We were so sure it was.  It was a
>>> mistake then, and it is now.
>>>
>>> Let¹s learn from that and stay away from DNS.
>>>
>>> We need a query with TN and service that returns either some form of
>>> service provider id/service URL and/or some form of route.  I personally
>>> think that it would be best to keep route separate from service provider
>>> id/URL because I do think the user controls that part of the record
>>> while the SP controls the route.
>>>
>>> Brian
>>
>> _______________________________________________
>> Modern mailing list
>> [email-masked]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>> listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>> Z1ooNcfp01IYIaVqsORjI&m=p-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s=0X93
>> agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern