Subject: Re: [Modern] Services

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Oct 2014 19:55:25 +0000

We have some precedence for service definitions in the caller preferences work, for standards-based services. It's relatively easy, I think, if the services are clearly separated ("voice only" + "text only"). Given modern multimedia services, I'm not sure how common this is going to be, given that every service will likely support audio, video and text.

For proprietary services, this is probably pretty much a name registration problem ("Skype", "Facebook").

________________________________________
From: PFAUTZ, PENN L [[email-masked]]
Sent: Thursday, October 16, 2014 3:42 PM
To: Brian Rosen; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [Modern] Zombie numbering issues

Re number 2 below I understand the desire but remind you that then we have to get into service definition - maybe there is a way to fudge that?

---

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Oct 2014 16:43:10 -0400

Like it or not, we have OTT services using the same TN as the service provider’s services, even if there is overlap.  That is, I suspect, exactly what Penn was getting at.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Oct 2014 00:13:47 +0000

If they are both SIP services (say), I'm not sure how you'd distinguish them (and make the call work without some voice IVR like "The number you have reached has multiple services. Would you like to talk to 201 555 1234 via AT&T, Vonage or Facebook?"

As far as I can tell today, a single number today only has one provider. Or are you talking about the case where I can use my SMS number as an Apple iChat identifier, which then bypasses SMS?

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Thursday, October 16, 2014 4:43 PM
To: Henning Schulzrinne
Cc: PFAUTZ, PENN L; [email-masked]
Subject: Re: [Modern] Services

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 17 Oct 2014 08:50:52 -0400

Yes, among many other services that use your phone number as an identifier.   I think the iMessage service is very interesting, because it really does use the TN as the identifier.  It has an association between a TN and an AppleId, which it then uses to extend who and how it contacts other users, but that service is the “text” supplier for the device, and it may make use of other services tied to the TN, such as the SMS service.  

I think, long term, that a service like voice (or video) really will be separate from a service like text, and users will be free to choose whatever service provider they wish.  I think the user interfaces for such services may well be separate from the service providers.  Of course bundles of services and user interfaces will continue to exist, but I think the notion that there is one service provider per TN has long past, and I would like to make sure that the TN is portable for all such services that use it.

Brian

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Fri, 17 Oct 2014 13:48:38 +0000

"... but I think the notion that there is one service provider per TN has long past, and I would like to make sure that the TN is portable for all such services that use it."

HEAR HEAR!!!

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: October 17, 2014 7:51 AM
To: Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

Yes, among many other services that use your phone number as an identifier.   I think the iMessage service is very interesting, because it really does use the TN as the identifier.  It has an association between a TN and an AppleId, which it then uses to extend who and how it contacts other users, but that service is the "text" supplier for the device, and it may make use of other services tied to the TN, such as the SMS service.

Brian

On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne <[email-masked]> wrote:

> Like it or not, we have OTT services using the same TN as the service provider's services, even if there is overlap.  That is, I suspect, exactly what Penn was getting at.
>
> Brian

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

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Fri, 17 Oct 2014 19:21:54 +0000

IVR wouild be one way.  The app could also assume that termination in a like app/provider if available, or one or more preferences settings.  E.g., use least-cost app/provider.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: October 16, 2014 7:14 PM
To: Brian Rosen
Cc: [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

Brian

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 17 Oct 2014 19:26:43 +0000

I'm not so sure I agree that a TN should not have a fundamental association with a single provider, but that's a policy issue. In the DNS an FQDN is delegated to a single party. I believe a registry architecture could - and the FCC wants it to - be able to accommodate a variety of potential policies.  IFF there were agreement on service definitions, then a registry could have per-service delegation records. So I don't see that this is something that could be or has to be decided now.

-----Original Message-----
From: Gorman, Pierce A [NTK] [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 9:49 AM
To: Brian Rosen; Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: RE: [Modern] Services

HEAR HEAR!!!

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: October 17, 2014 7:51 AM
To: Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

Brian

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Fri, 17 Oct 2014 19:46:46 +0000

An FQDN is also not (very) portable.  I like the idea that started with portability many years ago that a TN can become the virtual property of the user, rather than the provider.  Its why non-geographic portability appeals to me too.  Not sure if inter-country portability will happen in my lifetime (glad there's some roaming), but the idea that an integer can be a universal language abstraction of how to contact me multiple different ways is powerful.

Note: Feel scared and need to disclaim that the opinions expressed herein are my own, and should not be considered express or implied opinions of Sprint.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Gorman, Pierce A [NTK] [mailto:[email-masked]]
Sent: Friday, October 17, 2014 9:49 AM
To: Brian Rosen; Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: RE: [Modern] Services

HEAR HEAR!!!

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: October 17, 2014 7:51 AM
To: Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

Brian

---

From: Richard Shockey <[email-masked]>
Date: Fri, 17 Oct 2014 18:07:38 -0400

‹

Pierce ..understood.  BTW some of you may recall I¹ve written extensively
on this in my filings with the FCC. Given the glide path on ICC/USF reform
and PSTN transition full geographic number portability would be easy and
purely a policy decision not a technical one.

http://shockey.us/files/4813/9155/2471/FCC-Numbering.pdf

Service portability is certainly doable. Though some providers might have
issues.

On 10/17/14, 3:46 PM, "Gorman, Pierce A [NTK]" <[email-masked]>
wrote:

>An FQDN is also not (very) portable.  I like the idea that started with
>portability many years ago that a TN can become the virtual property of
>the user, rather than the provider.  Its why non-geographic portability
>appeals to me too.  Not sure if inter-country portability will happen in
>my lifetime (glad there's some roaming), but the idea that an integer can
>be a universal language abstraction of how to contact me multiple
>different ways is powerful.
>
>Note: Feel scared and need to disclaim that the opinions expressed herein
>are my own, and should not be considered express or implied opinions of
>Sprint.
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>
>I'm not so sure I agree that a TN should not have a fundamental
>association with a single provider, but that's a policy issue. In the DNS
>an FQDN is delegated to a single party. I believe a registry architecture
>could - and the FCC wants it to - be able to accommodate a variety of
>potential policies.  IFF there were agreement on service definitions,
>then a registry could have per-service delegation records. So I don't see
>that this is something that could be or has to be decided now.
>
>"... but I think the notion that there is one service provider per TN has
>long past, and I would like to make sure that the TN is portable for all
>such services that use it."
>
>HEAR HEAR!!!
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>Yes, among many other services that use your phone number as an
>identifier.   I think the iMessage service is very interesting, because
>it really does use the TN as the identifier.  It has an association
>between a TN and an AppleId, which it then uses to extend who and how it
>contacts other users, but that service is the "text" supplier for the
>device, and it may make use of other services tied to the TN, such as the
>SMS service.
>
>I think, long term, that a service like voice (or video) really will be
>separate from a service like text, and users will be free to choose
>whatever service provider they wish.  I think the user interfaces for
>such services may well be separate from the service providers.  Of course
>bundles of services and user interfaces will continue to exist, but I
>think the notion that there is one service provider per TN has long past,
>and I would like to make sure that the TN is portable for all such
>services that use it.
>
>Brian
>
>> If they are both SIP services (say), I'm not sure how you'd distinguish
>>them (and make the call work without some voice IVR like "The number you
>>have reached has multiple services. Would you like to talk to 201 555
>>1234 via AT&T, Vonage or Facebook?"
>>
>> As far as I can tell today, a single number today only has one
>>provider. Or are you talking about the case where I can use my SMS
>>number as an Apple iChat identifier, which then bypasses SMS?
>>
>> Like it or not, we have OTT services using the same TN as the service
>>provider's services, even if there is overlap.  That is, I suspect,
>>exactly what Penn was getting at.
>>
>> Brian
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 18 Oct 2014 00:50:31 +0000

By international portability, do you mean the ability of a non-US resident to obtain a US phone number as, as you put it, virtual property or of a non-US (Canadian) service provider to become available through a +1 number? The latter seems relatively straightforward if the virtual owner can add his own SIP URL, say, to the number record. (I'll ignore whether other carriers would connect to that number, or should have to.)

Germany, as far as I know, requires proof of residency before assigning VoIP numbers through a provider.

As far as I can tell, beyond the add-your-own SIP URL ability mentioned above, this wouldn't seem to affect the protocol or architecture design, just the policies, which could presumably change. (They could conceivably differ for 800 numbers, for example.)

________________________________________
From: Gorman, Pierce A [NTK] [[email-masked]]
Sent: Friday, October 17, 2014 3:46 PM
To: PFAUTZ, PENN L; Brian Rosen; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [Modern] Services

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Gorman, Pierce A [NTK] [mailto:[email-masked]]
Sent: Friday, October 17, 2014 9:49 AM
To: Brian Rosen; Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: RE: [Modern] Services

HEAR HEAR!!!

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: October 17, 2014 7:51 AM
To: Henning Schulzrinne
Cc: [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 18 Oct 2014 00:56:48 +0000

You can always add a layer of indirection via DNS NAPTR. The only indirect decision is whether the number record may contain a single URL, a domain record that can then add service types as in ENUM, or a list of these, with service identifiers. 

If we're trying to compile requirements, we probably do have to decide that level of detail.

In DNS, a domain belongs to one party, but it's easy to point the MX record to one destination, and the other records to another. With SRV, you get protocol-specific redirection.

My mental model is that assignment of a number is roughly equivalent to assignment of a DNS name in that sense (leaving aside who can be assigned the record; even if that's only a carrier, a separate policy decision could mandate the ability to carry additional provider pointers, for example). Does that model work?

Sent: Friday, October 17, 2014 3:26 PM

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 18 Oct 2014 00:58:59 +0000

This sounds similar to the NAPTR/SRV ordering, where the destination (domain owner) rank-orders the choices.

________________________________________
From: Gorman, Pierce A [NTK] [[email-masked]]
Sent: Friday, October 17, 2014 3:21 PM
To: Henning Schulzrinne; Brian Rosen
Cc: [email-masked]; PFAUTZ, PENN L
Subject: RE: [Modern] Services

Best regards,

---

From: Richard Shockey <[email-masked]>
Date: Sat, 18 Oct 2014 20:30:53 -0400

In general I¹d agree that a phone number is essentially a domain in the
classic theory of the abstraction of naming and addressing.  That domain
should be consumer enterprise centric and carriers will ultimately IMHO
manage that service but I can also see the classic resistance of service
providers to the larger issue of number administration by consumers etc.

We¹ve seen number administration become a classic barrier to entry for
competitors. I can site cases if anyone is interested.

But the larger thrust here is something more interesting.  What is the
real alternative to DNS for different classes of names outside the ICANN
model.   Istnt that what we are talking about?  We accept and create a
model of resolution of one class of names E.164 totally outside the ICANN
model of administration.

NGN ENUM not using DNS preserving the traditional rights of nation states
to administer their portions of the numbering plan?

I¹m just thinking. 

On 10/17/14, 8:56 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>You can always add a layer of indirection via DNS NAPTR. The only
>indirect decision is whether the number record may contain a single URL,
>a domain record that can then add service types as in ENUM, or a list of
>these, with service identifiers.
>
>In DNS, a domain belongs to one party, but it's easy to point the MX
>record to one destination, and the other records to another. With SRV,
>you get protocol-specific redirection.
>
>My mental model is that assignment of a number is roughly equivalent to
>assignment of a DNS name in that sense (leaving aside who can be assigned
>the record; even if that's only a carrier, a separate policy decision
>could mandate the ability to carry additional provider pointers, for
>example). Does that model work?
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Sun, 19 Oct 2014 23:04:10 +0000

Yes. I think that model can encompass the important set of possible policies

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Oct 2014 00:38:35 +0000

This isn't *that* new, although obviously at a new scale. For example, there are many domain-specific URN schemes (e.g., DOIs for science publications) that are assigned outside ICANN control, but interact with DNS.

We already have very basic mapping from numbers to domain names or IP addresses in the existing databases (and most certainly in the VRS numbering database), so this is not fundamentally new even for phone numbers.

Besides the who-won't-like-it question, we already have a number space not managed by carriers, namely 800#. They illustrate to some extent that this can work technically, but preventing hoarding may require more scalable mechanisms than relying on kicking misbehaving entities out of the club.

Thus, as a strawman, I could picture that the number record returned by a query returns (optionally) a domain name, resolved via DNS SRV or NAPTR as the next step. This allows various combinations of managed-by-carrier and managed-by-end user, depending on who gets to manage the DNS entry and who gets to manage the number record. This then becomes a policy knob, beyond the MODERN discussion.

________________________________________
From: Richard Shockey [[email-masked]]
Sent: Saturday, October 18, 2014 8:30 PM
To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rosen
Cc: [email-masked]
Subject: Re: [Modern] Services

I¹m just thinking.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 09:51:24 -0400

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

> On Oct 19, 2014, at 8:38 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Oct 2014 13:57:51 +0000

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

Brian

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Mon, 20 Oct 2014 14:10:41 +0000

As mentioned before, classical DNS ENUM does not work well for numerous voice call routing requirements.  There may be other applications which would also find the source-information limitations of classical ENUM TN to URI resolution process cumbersome or inadequate.

The "EDNS Option Code for SIP and PSTN Source Reference Info"  (http://tools.ietf.org/html/draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03) provides one way to address the source-information shortcoming of classical ENUM TN, but as Richard Shockey put it back in August, "Its duct tape and bailing wire but it works."  I certainly agree with the "duct tape and bailing wire" aspects.

My experience has been that SRV load distribution and failure-recovery implementations based on weight and priority are not always straight forward.  Is a SIP 503 a server failure that requires a different choice based on priority, or does it require a 6xx?  TTL is also not always respected.  Assuming UDP is used for large-scale query/response processing, what happens if/when large quantities of NAPTR RR responses are larger than what fits in the (extended?) UDP payload limit and requires TCP re-tries?

DNS NAPTR, OPT, SRV, A/AAAA is just barely adequate for most featureless local and long-distance voice call routing requirements but inadequate otherwise.  E.g., toll-free.

I am not saying we should abandon DNS ENUM, but I am saying we should be open to considering something other than DNS for more complex service/application session routing requirements.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: October 19, 2014 7:39 PM
To: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rosen
Cc: [email-masked]
Subject: RE: [Modern] Services

In general I¹d agree that a phone number is essentially a domain in the classic theory of the abstraction of naming and addressing.  That domain should be consumer enterprise centric and carriers will ultimately IMHO manage that service but I can also see the classic resistance of service providers to the larger issue of number administration by consumers etc.

We¹ve seen number administration become a classic barrier to entry for competitors. I can site cases if anyone is interested.

But the larger thrust here is something more interesting.  What is the real alternative to DNS for different classes of names outside the ICANN
model.   Istnt that what we are talking about?  We accept and create a
model of resolution of one class of names E.164 totally outside the ICANN model of administration.

NGN ENUM not using DNS preserving the traditional rights of nation states to administer their portions of the numbering plan?

I¹m just thinking.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 10:11:35 -0400

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 10:18:32 -0400

Agree.  I think we’re thinking REST/json

Brian

> On Oct 20, 2014, at 10:16 AM, PFAUTZ, PENN L <[email-masked]> wrote:
> 
> I don't want to rehash the history of ENUM and I recognize there are some tasks it doesn't do well. I will, however, be skeptical of any one-off protocol for managing E.164 public user identities. I would expect that, like ENUM, whatever we come up with will be built on some more general protocol. I would also like to see some technical commonality with the management of other types of PUIDs.
> 
> From: Brian Rosen [mailto:[email-masked]] 
> 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.  
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 20 Oct 2014 14:16:42 +0000

-----Original Message-----
From: Brian Rosen [mailto:[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

Brian

---

From: "Douglas Ranalli" <[email-masked]>
Date: Mon, 20 Oct 2014 11:36:25 -0400

Henning and Brian,

Great discussion over the past week.  There might be some value in breaking
the discussion down into separate distinct concepts.  Here's a strawman to
consider:

- Concept-1:  Number Allocation:  Today, numbers are assigned as code-ranges
to licensed carriers.  The group has already explored several possible
enhancements.  Seems like the direction is to move towards more granular
allocation of numbers (perhaps TN specific) to a broader set of industry
players (not just licensed carriers).  Lots of interesting policy decisions
here that eventually need to be reflected in an underlying implementation.

- Concept-2:  Multiple SPs Per TN:  The concept of multiple-services
associated with a TN seems like an important advancement from our current
telephony architecture.  The group has explored this from several angles.
Key policy issue is to guarantee a user's right to select more than one SP
to provide services associated with the single TN.  Key technology issue is
to define how multiple services are discovered.  Brian, your note below
proposes a query for "TN and service".  I like the idea of being able to ask
for a single "service" but I think a mechanism is necessary to discover all
of the services associated with a TN as well.  

- Concept-3: Service Provider ID:  We've seen from experience that the
minimum requirement for reaching a given service associated with a given TN
is identifying some type of unique "service-provider ID" associated with the
service.  I draw this out as a separate concept because it involves
agreement on a global naming convention that works for licensed
carriers/operators, OTT providers, enterprises, etc.  We're still missing a
globally unique service-provider-ID mechanism that can be managed by the
industry.  I see value in separating the concept of service-provider
discovery from route-discovery.   

- Concept-4: Routing:  The final step is to establish a connection/session
with the destination service-provider.  I agree with Brian that the
mechanism for defining the route is separate from the mechanism for defining
the service-provider-ID.  The user selects a service-provider for a given
service.  The originating and terminating service-providers both have a role
to play in defining if/when/how to route to a given service.  Current
experience with SIP interconnect suggests that every originating SP can
define its own local routing policy for reaching a given destination
service. The solution involves bilateral interconnect discussions that are
slow but it works.  Alternatively we can explore a dynamic route-discovery
mechanism that provides for destination-specific entry-point discovery that
might vary by origin.  I like the idea of dynamic discovery because it
aligns with the general trend towards mobility in all forms of
communication. 

Doug

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning
Schulzrinne
Sent: Monday, October 20, 2014 9:58 AM
To: Brian Rosen
Cc: Gorman, Pierce A [NTK]; [email-masked]; PFAUTZ, PENN L; Richard Shockey
Subject: Re: [Modern] Services

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

resolving to

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

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.

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 12:06:40 -0400

I like the way you are thinking.

I do want to pick out your number 3.

It may very well be that what we want is a SPID.  I would like to figure out if SPID is actually what we want before we start going down the path of creating a new identifier.

You want a SPID when an entity doing a query has some sort of database that can translate SPID to something else.  A good example might be you have peering relationships with some SPs, but for others, you use a transit provider.  You have a database by SPID of which provider you send a call to.   I like that example because you would not put that information in some common database - it’s local to you.

But, do we need an SPID that is different from a domain name?  Domain Names are unique, so that’s one thing we need.  They are easy to create, and we already have a management process.  I think the downside is that not all domains are SPIDs, and we might need to know the difference.  Another one is because they are cheap, they may proliferate in ways detrimental to maintaining things like routing databases.

But, as a straw man, what is wrong with domain name as SPID?

Brian

> On Oct 20, 2014, at 11:36 AM, Douglas Ranalli <[email-masked]> wrote:
> 
> Henning and Brian,
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 20 Oct 2014 16:24:34 +0000

Brian:
The i3 Forum did a bit of work on SPID (see http://i3forum.org/i3forum-global-spid-specifications-release-1-may-2011/)
There were some parties that wanted a numeric identifier, but as with ENUM, the biggest issues were not technical but business in terms of getting agreement on who would administer SPID. I took a run at a number of alternatives, IANA, ITU, RIR, without really getting anywhere. There was some suggestion the GSMA might step up.
We do want something global.

Penn

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 12:07 PM
To: Douglas Ranalli
Cc: Henning Schulzrinne; Gorman, Pierce A [NTK]; [email-masked]; PFAUTZ, PENN L; Richard Shockey
Subject: Re: [Modern] Services

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 12:27:17 -0400

Yeah, I know.

That’s why I want to question first principles.

Do we need a SPID?  Why won’t a domain name do?  What properties do we need in an ID beyond global uniqueness?

Brian

> On Oct 20, 2014, at 12:24 PM, PFAUTZ, PENN L <[email-masked]> wrote:
> 
> Brian:

---

From: Richard Shockey <[email-masked]>
Date: Mon, 20 Oct 2014 12:26:52 -0400

‹

On 10/20/14, 12:06 PM, "Brian Rosen" <[email-masked]> wrote:

>It may very well be that what we want is a SPID.  I would like to figure
>out if SPID is actually what we want before we start going down the path
>of creating a new identifier.
>
>You want a SPID when an entity doing a query has some sort of database
>that can translate SPID to something else.  A good example might be you
>have peering relationships with some SPs, but for others, you use a
>transit provider.  You have a database by SPID of which provider you send
>a call to.   I like that example because you would not put that
>information in some common database - it¹s local to you.
>
>But, do we need an SPID that is different from a domain name?  Domain
>Names are unique, so that¹s one thing we need.  They are easy to create,
>and we already have a management process.  I think the downside is that
>not all domains are SPIDs, and we might need to know the difference.
>Another one is because they are cheap, they may proliferate in ways
>detrimental to maintaining things like routing databases.
>

Security .. Topology hiding.. This is not the DNS as you point out. There
are lots of other reasons for this. But I¹m pretty sure a name space could
be created at minimal industry cost.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 20 Oct 2014 12:32:01 -0400

Penn based on my personal conversations on this matter the RIR¹s would do
it. It sits front and center to their ongoing mission.  Its just that it
would take work to formulate the proposals some informational RFC¹s and go
through the various open multi stake holder consensus Šetc that they all
have. Travel budgets etc. Its a matter of commitment.

On 10/20/14, 12:24 PM, "PFAUTZ, PENN L" <[email-masked]> wrote:

>Brian:
>The i3 Forum did a bit of work on SPID (see
>http://i3forum.org/i3forum-global-spid-specifications-release-1-may-2011/)
>There were some parties that wanted a numeric identifier, but as with
>ENUM, the biggest issues were not technical but business in terms of
>getting agreement on who would administer SPID. I took a run at a number
>of alternatives, IANA, ITU, RIR, without really getting anywhere. There
>was some suggestion the GSMA might step up.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 12:35:44 -0400

> are lots of other reasons for this. But Iąm pretty sure a name space could

Possibly you are mistaking what I’m suggesting.

I’m suggesting that rather than creating a new identifier, let’s say it was numeric, administered by someone, that we use a string that just happens to be the same as a domain owned by the SP, administered by the existing DNS registrars.

I’m not suggesting that there is anything in the DNS entry for that domain that we’re using for identification.  I’m just suggesting that the string “att.net” is a very fine SPID.  AT&T already owns it.  We have an acceptable administrator for it.  It’s globally unique.  “broadband.com” is perfectly fine.  “brianrosen.net” is also okay.  It’s a globally unique string, owned by the “Service Provider”, capable of being used whenever a lookup in a database that needs some column for “service provider id”.

What else do we need?

Brian

---

From: Richard Shockey <[email-masked]>
Date: Mon, 20 Oct 2014 12:23:22 -0400

In Line ..

>here that eventually need to be reflected in an underlying implementation.

	RS>  +1  Though I think given realities single digit allocations over
time is the preferred end goal also flatten the namespace by requiring 10
digit dialing that would ultimately give us national number portability or
essentially one number for life ( if you stay in North America).  I can
hear the whining from 202 Area Code holders but NYC did a overlay and the
Republic still stands.(see the Seinfeld episode)

>discovery from route-discovery.

	RS> Doug I¹m glad you brought this up.  It has come up in several
contexts and I personally ran a couple of memos around the industry to
look into this.  Our international i3forum friends have had this problem
for some time.  One idea was to create a G-SPID. To hold costs in line it
could be administered similar to AS numbers by the RIR¹s.  I talked to
ARIN and RIPE about this and they were willing if the communities would go
through the process and put together the proposals.  There was a very very
strong desire within the industry NOT to go to Geneva about this, for
obvious reasons. We know US carriers use the NECA OCN codes now but that
that is not going to hold once we see further progress on International
SIP Interconection.

>aligns with the general trend towards mobility in all forms of

	RS> An arguments can be made that the terminating service provider wants
more say in this than we have now.  Its the entire Determinate Response
issue that we used Kaplan source URI to overcome in ENUM generally but
needs to be completely reimagined in this new environment. How the service
is routed is based on who is asking the question and from where.

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 20 Oct 2014 16:42:30 +0000

So to be clear,
You're proposing that an SP designate one or more of their domain names as SPIDs and these SPIDs would then be used in the E.164 Registry(ies)?

Since I was not one of those folks that want to do prefixing (one of the i3 drivers for numeric) I think I could live with this. It does meet the criteria of being available to all potential SPs, unlike, say, NECA stuff.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 12:36 PM
To: Richard Shockey
Cc: Douglas Ranalli; Henning Schulzrinne; Gorman, Pierce A [NTK]; [email-masked]; PFAUTZ, PENN L
Subject: Re: [Modern] Services

What else do we need?

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 12:45:17 -0400

Yep, that’s my proposal.

It requires a bit of care at the provider.  They often have a zillion domain names, and they have to choose which one(s) to use, and use them consistently.  But it’s really no more complex than managing any other form of SPID.  

Brian

> On Oct 20, 2014, at 12:42 PM, PFAUTZ, PENN L <[email-masked]> wrote:
> 
> So to be clear,

---

From: "Douglas Ranalli" <[email-masked]>
Date: Mon, 20 Oct 2014 14:22:03 -0400

I agree that a globally unique domain name seems like a perfectly valid implementation of a service-provider-ID (SPID) in the context of identifying a destination service-provider for a communications service associated with a TN. 

Doug

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 12:45 PM
To: PFAUTZ, PENN L
Cc: Richard Shockey; Douglas Ranalli; Henning Schulzrinne; Gorman, Pierce A [NTK]; [email-masked]
Subject: Re: [Modern] Services

Yep, that’s my proposal.

Brian

>> Security .. Topology hiding.. This is not the DNS as you point out. 
>> There are lots of other reasons for this. But Iąm pretty sure a name 
>> space could be created at minimal industry cost.
>> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Oct 2014 13:42:14 -0500

Actually, I find Penn's final sentence here -- "I would also like to see 
some technical commonality with the management of other types of PUIDs" 
-- to be of particular interest. I think it would be reasonable to keep 
the mechanism open to inputs other than numbers, and to consider 
delegation models other than numeric prefixes.

/a

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 21 Oct 2014 01:34:57 +0000

If history shows us anything, it's that we need to be versatile in the
identifiers we accommodate. While ideally, we could standardize on some
single thing, different contexts seem to consistently require different
elements.

This is why I think it's still premature to worry too much about whether
the key is in the DNS, or ENUM, or DIAMETER, or whatever. The exercise I
think we need is to tabulate what kinds of data authorities want to
provision associated with identifiers, and what kinds of questions network
elements of various types want to ask about those identifiers. I suspect
SPIDs, DNS names, and many other elements will ultimately be at play. We
will need a framework to enable that, and the nature of the framework will
come into focus as we better understand those practical needs of protocols
and services. 

Jon Peterson
Neustar, Inc.

On 10/20/14, 9:45 AM, "Brian Rosen" <[email-masked]> wrote:

>Yep, that's my proposal.
>
>It requires a bit of care at the provider.  They often have a zillion
>domain names, and they have to choose which one(s) to use, and use them
>consistently.  But it's really no more complex than managing any other
>form of SPID.  
>
>Brian
>
>> You're proposing that an SP designate one or more of their domain names
>>as SPIDs and these SPIDs would then be used in the E.164 Registry(ies)?
>> 
>> Since I was not one of those folks that want to do prefixing (one of
>>the i3 drivers for numeric) I think I could live with this. It does meet
>>the criteria of being available to all potential SPs, unlike, say, NECA
>>stuff.
>> 
>>>There
>> Possibly you are mistaking what I'm suggesting.
>> 
>> I'm suggesting that rather than creating a new identifier, let's say it
>>was numeric, administered by someone, that we use a string that just
>>happens to be the same as a domain owned by the SP, administered by the
>>existing DNS registrars.
>> 
>> I'm not suggesting that there is anything in the DNS entry for that
>>domain that we're using for identification.  I'm just suggesting that
>>the string "att.net" is a very fine SPID.  AT&T already owns it.  We
>>have an acceptable administrator for it.  It's globally unique.
>>"broadband.com" is perfectly fine.  "brianrosen.net" is also okay.  It's
>>a globally unique string, owned by the "Service Provider", capable of
>>being used whenever a lookup in a database that needs some column for
>>"service provider id".
>> 
>> What else do we need?
>> 
>> Brian
>> 
>> 
>> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Oct 2014 03:34:54 +0000

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?

Sent: Monday, October 20, 2014 10:11 AM

Okay, perhaps we are.

Brian

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Tue, 21 Oct 2014 10:41:57 +0000

Yes, but in step 2 replace "authentication" with "source_information".  Credentials are one form of source data.  There could/will be others such as "location".

Pierce

Sent from my iPad

> On Oct 20, 2014, at 10:35 PM, "Henning Schulzrinne" <[email-masked]> wrote:
>

---

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

This is generally consistent with what I had in mind.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 11:35 PM
To: Brian Rosen
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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 21 Oct 2014 09:13:30 -0400

It used to be that we did not want a public database of which service provider(s) served a specific telephone number.  Is that now not an issue?

Brian

> On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 21 Oct 2014 13:16:04 +0000

I caught that too. How public would public be? I can imagine arguments for some level of access control even if the database were on the Internet. And I would want some protection from DDOS.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2014 9:14 AM
To: Henning Schulzrinne
Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; [email-masked]
Subject: Re: [Modern] Services

Brian

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Tue, 21 Oct 2014 14:13:32 +0000

I am very leary of a public database.  SPAM over Internet Telephony (SPIT) is just as much a concern as it ever was.

If the database is to be used by "carriers" of telecommunications services (e.g., voice, 2-way video, presence capabilities, geo-location, emergency services call/text/etc), I would want the same restrictions to access as are enjoyed by LERG and NPAC.  I understand OTT providers may require access as well (I assume they will) but I would definitely not want it to be as open as DNS.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, October 21, 2014 9:14 AM
To: Henning Schulzrinne
Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; [email-masked]
Subject: Re: [Modern] Services

Brian

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 21 Oct 2014 17:42:03 +0000

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.
>
>(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".]
>
>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
>
>
>> 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
>>
>> 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
>>
>> 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
>
>
>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=

---

From: Richard Shockey <[email-masked]>
Date: Tue, 21 Oct 2014 14:02:01 -0400

+1  Also the regulators want some level of control here for perfectly
senseable reasons. I¹ve certainly argued that access to the national
numbering plan and its databases should imply a set of obligations. By
definition it is a public resource.

On 10/21/14, 10:13 AM, "Gorman, Pierce A [NTK]" <[email-masked]>
wrote:

>I am very leary of a public database.  SPAM over Internet Telephony
>(SPIT) is just as much a concern as it ever was.
>
>If the database is to be used by "carriers" of telecommunications
>services (e.g., voice, 2-way video, presence capabilities, geo-location,
>emergency services call/text/etc), I would want the same restrictions to
>access as are enjoyed by LERG and NPAC.  I understand OTT providers may
>require access as well (I assume they will) but I would definitely not
>want it to be as open as DNS.
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>
>I caught that too. How public would public be? I can imagine arguments
>for some level of access control even if the database were on the
>Internet. And I would want some protection from DDOS.
>
>It used to be that we did not want a public database of which service
>provider(s) served a specific telephone number.  Is that now not an issue?
>
>Brian
>
>> 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.
>>
>>have some kind of public numbering database, it can't tailor its
>>response to the querier, by definition.
>>
>> 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.
>>points, but I would think that would be the result of the first "modern"
>>> ENUM was a mistake, and one of the mistakes was using DNS.  It's not
>>>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
>>
>
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Oct 2014 13:07:00 -0500

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

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Tue, 21 Oct 2014 19:15:22 +0000

LERG and NPAC may fall into your categories of naïve, secret, requiring a special handshake, and right amount of money to access, but I would argue with naïve.  :-)

Your concern is still valid and I agree.  Slamming has been a problem in the past even with controlled access.  Perhaps database content of services/SP associated with TN(s) associated with a typical consumer subscriber can be controlled by the subscriber themselves?  They do so through the proxy of their telephone service carrier(s) today, but MODERN technology (pun intended) might support a more direct role.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: October 21, 2014 1:07 PM
To: McGarry, Tom; [email-masked]
Subject: Re: [Modern] Services

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:
> 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.
>
>
>
>> 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
>>
>> simultaneously be talking about information that is being returned by
>> a public number directory (before you know who is "in charge" of the
>> 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
>> relationship to modern.att.net, it would presumably get a generic
>> answer for carriers without special arrangement or some version of
>> "go away".]
>>
>> 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
>>
>>
>>> 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
>>>
>>> I assume we don't want to put IP addresses directly into the
>>> response, so DNS enters the picture at some point.
>>>
>>> concepts, but I think DNS is not the appropriate way to get anything
>>> to do with E.164s.
>>> the appropriate query mechanism, and it has a golden root problem.
>>> I remember well the DNS guys questioning whether DNS was the right
>>> service provider id/URL because I do think the user controls that
>>> part of the record while the SP controls the route.
>>>
>>> Brian
>>
>> Z1ooNcfp01IYIaVqsORjI&m=p-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s
>> =0X93 agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=

---

From: Brian Rosen <[email-masked]>
Date: Tue, 21 Oct 2014 15:43:00 -0400

Clearly, we need a low barrier to entry.  It’s not clear there should be no barrier.

“Peering” might be the way in.  If you have an agreement to peer with someone, you can get at the database.  Seed with the current notion of carrier and it might scale from there.

Brian

Brian
> On Oct 21, 2014, at 2:07 PM, Adam Roach <[email-masked]> wrote:
>

---

From: Ken Pogran <[email-masked]>
Date: Tue, 21 Oct 2014 15:52:22 -0400

The notion of not having a single public database, but instead having
databases maintained by multiple service providers, is akin to what we
have today with the PSTN's LIDB/CNAM databases. So this is a model that is
familiar to service providers. Provisioning of these databases (by SPs,
imbuing the data provisioned with some level of trust), is also well
understood. (There is, of course, the question of whether the database
maintained by each service provider contains all TNs, or if the space is
somehow partitioned, as with today's LIDB/CNAM).

Today's PSTN databases live on the SS7 network,  which for the most part
is a closed network that also affords some degree of "security by
obscurity."  The databases we're talking about here won't have that, umm,
"advantage" and so will need more explicit security mechanisms.

We will need to explore a variety of use cases. Perhaps we will have the
equivalent of "listed" and "unlisted" numbers, where information about
certain services is publicly available for listed numbers, while the same
information is unavailable for unlisted numbers. Since there will be many
services associated with a telephone number, we will need to define WHAT
entities are entitled to query WHOSE databases about WHICH service entries
for a given TN (e.g., Henning's "who's asking?"). Use cases will help us
explore this.

Ken Pogran
  EGH
  www.egh.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Oct 2014 05:00:15 +0000

Let's assume for a moment that organizations can directly get numbers, e.g., a university or corporation. Why shouldn't they be able to advertise their direct reachability and other characteristics, via (say) SIP, just as they advertise their BGP or DNS reachability today?

Whether to do that is obviously a policy decision, but I suspect it's wise to plan for the ability of a large number of entities to acquire numbers, whether that number is 100 million households, 6 million businesses (with employees) or 6,000 (guestimate) of carriers and kind-of-like-carriers entities.

I suspect we mostly agree that there may not be a single master copy that everybody accesses, but rather physically (and logically) distributed, but synchronized, versions.

Going back to the compatibility and learning from other public identifier systems, what aspects of the DNS environment (not the protocol) are important to clone and which have shown themselves to be problematic?

________________________________________
From: Modern [[email-masked]] on behalf of Gorman, Pierce A [NTK] [[email-masked]]
Sent: Tuesday, October 21, 2014 3:15 PM
To: Adam Roach; McGarry, Tom; [email-masked]
Subject: Re: [Modern] Services

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: October 21, 2014 1:07 PM
To: McGarry, Tom; [email-masked]
Subject: Re: [Modern] Services

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Oct 2014 05:09:42 +0000

If preventing SPIT relies on keeping a secret database of a rather limited identifier space, I suspect we've lost the battle already...

I'm not sure how read access would facilitate spam (or how restricting access would significantly interfere with automated sequential dialing).

Maybe part of this is that we have not quite defined what elements would be contained and accessible by whom - for example, "ownership" data might be more tightly held (as is effectively the case in DNS today, with all the identity protection schemes that registrars and other offer). 

So far, we seem to have discussed, at least implicitly:

* holder contact data (similar to the whois-style data for technical, admin and billing contacts), possibly via indirection (SPID, OCN)
* user data (who is being reached)
* service indications, including pointers to protocol-based reachability information (very roughly equivalent to NS records)

Is there other data?

________________________________________
From: Gorman, Pierce A [NTK] [[email-masked]]
Sent: Tuesday, October 21, 2014 10:13 AM
To: PFAUTZ, PENN L; Brian Rosen; Henning Schulzrinne
Cc: Richard Shockey; [email-masked]
Subject: RE: [Modern] Services

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, October 21, 2014 9:14 AM
To: Henning Schulzrinne
Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; [email-masked]
Subject: Re: [Modern] Services

Brian

---

From: "McGarry, Tom" <[email-masked]>
Date: Fri, 24 Oct 2014 17:44:32 +0000

Good about DNS:
- Lightweight and fast
- Widely deployed
- Well understood technology
- Well understood registration/administration model
- Caching

Problematic about DNS:
- Vulnerable to attacks
- Vulnerable to mining
- Very little ability to expand functionality in the query and response
- Can't reliably identify the originator of a query

On 10/22/14 1:00 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

><html>
>Let's assume for a moment that organizations can directly get numbers,
>e.g., a university or corporation. Why shouldn't they be able to
>advertise their direct reachability and other characteristics, via (say)
>SIP, just as they advertise their BGP or DNS reachability today?
>
>Whether to do that is obviously a policy decision, but I suspect it's
>wise to plan for the ability of a large number of entities to acquire
>numbers, whether that number is 100 million households, 6 million
>businesses (with employees) or 6,000 (guestimate) of carriers and
>kind-of-like-carriers entities.
>
>I suspect we mostly agree that there may not be a single master copy that
>everybody accesses, but rather physically (and logically) distributed,
>but synchronized, versions.
>
>Going back to the compatibility and learning from other public identifier
>systems, what aspects of the DNS environment (not the protocol) are
>important to clone and which have shown themselves to be problematic?
>
>LERG and NPAC may fall into your categories of naïve, secret, requiring a
>special handshake, and right amount of money to access, but I would argue
>with naïve.  :-)
>
>Your concern is still valid and I agree.  Slamming has been a problem in
>the past even with controlled access.  Perhaps database content of
>services/SP associated with TN(s) associated with a typical consumer
>subscriber can be controlled by the subscriber themselves?  They do so
>through the proxy of their telephone service carrier(s) today, but MODERN
>technology (pun intended) might support a more direct role.
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AAIFAw&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s=p
>>2IjM8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=
>
>listinfo_modern&d=AAIFAw&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=FUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s=p2Ij
>M8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=
>
>listinfo_modern&d=AAIFAw&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=FUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s=p2Ij
>M8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Oct 2014 22:02:43 +0000

I think the discussions have three facets:

(1) DNS as an information retrieval protocol (which most of the bullets below seem to summarize succinctly);

(2) domain names as a model for managing globally-unique identifiers, including associating extensible lists of information (DNS records, in that case) with each name;

(3) the protocols that are currently used to manage parts of (2), e.g., for registrar-registry interactions and information retrieval about domain holders.

I think it would be helpful to clearly separate the three as we address requirements and choices.

Henning

________________________________________
From: Modern [[email-masked]] on behalf of McGarry, Tom [[email-masked]]
Sent: Friday, October 24, 2014 1:44 PM
To: [email-masked]
Subject: Re: [Modern] Services

Good about DNS:
- Lightweight and fast
- Widely deployed

Problematic about DNS:
- Vulnerable to attacks
- Vulnerable to mining

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Mon, 27 Oct 2014 23:18:53 +0000

This is a great discussion & continues to follow the common IETF principles of proposing a solution & then finding what patches it needs to meet some implicit requirement(s).

However, in this case, given the huge legacy coming in from both the IP & PSTN worlds, I suspect that perhaps we should consider modifying the process somewhat, & first generate some kind of statement of requirements / problem statement.  A large amount of the required information has already been aired, as we see below, so potentially this could be done without the expenditure of much effort.

Maybe what we need to start the process is an informational RFC that list out all the identifiers in common use in this field, & how they are used, translated for routing, etc.?  Based on that it should be easy to rationally derive a set of requirements & (hopefully) figure which identifier(s) & supporting mechanisms can be minimally modified to produce a reasonable solution.

David Holmes
Sprint

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Monday, October 27, 2014 3:03 PM
To: McGarry, Tom; [email-masked]
Subject: Re: [Modern] Services

Henning

Good about DNS:
- Lightweight and fast
- Widely deployed

Problematic about DNS:
- Vulnerable to attacks
- Vulnerable to mining

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 Oct 2014 23:28:53 -0400

There is still the first order problem of clearly and succinctly defining
what is the problem statement. Everything else falls out from that.

The value proposition would run something like this.

How do we construct a set of tools that National Number Administrations
can use to design systems for which E.164 identifiers can be properly and
securely managed and authorized entities can create and use metadata
associated with those E.164 identifiers to enable ubiquitous global
communications. 

David ..I can testify that other National Number Administrations are
struggling with this.

What is the history of the IETF with E.164 identifiers?  Where has there
been success and failure so far and why is new work needed.

Certainly the history of ENUM is instructive. We all know what the
successes and failures of that effort were and Tom McGarry correctly laid
out the pros and cons of using DNS models. As you know Ive been there done
that. I¹ll volunteer to write that section. :-)

We have looked at provisioning issues in DRINKS but that had its own
issues associated with it and I, for one do not believe the existing DNS
EPP tool kit RFC 4114 is an appropriate starting place for provisioning
based on what we know of modern carrier systems. I¹m not sure even the
Domain Name Registration industry would go down the EPP route if they knew
what they know now. It wouldn¹t hurt to ask Scott Hollenbeck since he is
the institutional memory of all of this. You correctly point out we
somewhat trapped in legacy models and telephony provisioning systems are
staggeringly expensive.

I¹ve argued that EPP is actually a IETF failure since it is not really a
general purpose provisioning data exchange system it is highly bound to
the domain name registry industry and as such carries a lot of baggage
associated with it. Even HTTP/SOAP/XML has now been eclipsed for all sorts
of reasons but it did work and was clearly more generic than other methods
that proceeded it.

We certainly know what people use in North America use SOA/LSMS interfaces
for the NPAC and BIRDDS for the LERG etc and there is a lot of open
documentation on all of those what the required fields are etc.

We¹d need to see every darn field currently in use and then see if it
could have some mapping to some new system and certainly we have more
modern Query Response mechanisms.  Brian Rosen pointed out REST/JSON
certainly comes to mind and I would certainly agree. There is the
globalization problem. E.164 is a big name space but I reject the notion
that the solution has to be globally applicable from day one.  That is way
too much of a stretch. Visions of global roots come into mind and my head
wants to explode. 

My basic suspicion is if we all sat down in a room for a day or two (with
beer) a white board we could roughly outline the basics including one or
more models of how registries would operate and I commend to your
attention the work of IETF PAWS and the FCC White Spaces initiative on how
a new federated registry model might actually work.

Needless to say there is some level of Layer 9 here (politics) due to the
nature of control of the namespace itself.  This is <cough> telephony not
the Internet.

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 10/27/14, 7:18 PM, "Holmes, David W [CTO]" <[email-masked]>
wrote:

>This is a great discussion & continues to follow the common IETF
>principles of proposing a solution & then finding what patches it needs
>to meet some implicit requirement(s).
>
>However, in this case, given the huge legacy coming in from both the IP &
>PSTN worlds, I suspect that perhaps we should consider modifying the
>process somewhat, & first generate some kind of statement of requirements
>/ problem statement.  A large amount of the required information has
>already been aired, as we see below, so potentially this could be done
>without the expenditure of much effort.
>
>Maybe what we need to start the process is an informational RFC that list
>out all the identifiers in common use in this field, & how they are used,
>translated for routing, etc.?  Based on that it should be easy to
>rationally derive a set of requirements & (hopefully) figure which
>identifier(s) & supporting mechanisms can be minimally modified to
>produce a reasonable solution.
>
>David Holmes
>Sprint
>
>(2) domain names as a model for managing globally-unique identifiers,
>including associating extensible lists of information (DNS records, in
>that case) with each name;
>
>(3) the protocols that are currently used to manage parts of (2), e.g.,
>for registrar-registry interactions and information retrieval about
>domain holders.
>