Subject: [Modern] TN, E.164, or Something Else?

From: Eric Burger <[email-masked]>
Date: Mon, 18 May 2015 18:23:27 -0400

Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, “telephone numbers,” or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a’priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A “telephone number” spawns the debate as to whether it is, in fact, a ‘telephone’ number. Given Henning’s presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that “telephone number” is just a code word for E.164 number are most likely correct. This spills into the whole “It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966).” I.e., it looks, smells, and tastes like a rose.

Could we agree to disagree and say that MODERN is about managing globally unique identifiers that have a syntax of up to 15 decimal digits that have some hierarchical authorities mixed in to lock down who can and cannot request and assign numbers? Those authorities can be an opaque thingbat, because that is where we get into the policy bits, and everyone on the list swears MODERN will not touch policy.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 20 May 2015 09:31:09 -0500

Eric,

I'm not comfortable with saying that MODERN  is ONLY about managing 
globally unique identifiers as this rules out private numbering plans 
put in place by enterprises.

Yes, MODERN is about globally unique identifiers that have the format of 
a telephone number, but it is also about private identifiers that also 
have the format of a telephone number.

Regards,

Steve

On 5/18/15 5:23 PM, Eric Burger wrote:
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern

---

From: Eric Burger <[email-masked]>
Date: Wed, 20 May 2015 10:47:05 -0400

Does this mean that private identifiers do not need to be globally unique?

Not that we are talking about phone numbers ;-), but are you thinking PBXen with four-digit dial plans? If so, is the idea that the local authority would only know about the four digits, in which case the identifiers really are not global? E.g., my ‘1234’ at Georgetown is different than your ‘1234’ at Oracle? Or, is the idea that the dial plan is just a direct mapping to the globally unique E.164 number? E.g, ‘1234’ is really the number ‘+12145551234” for Oracle and ‘+12025551234’ for Georgetown?

Such a model really does give credence to say the identifiers are *not* E.164 numbers, because these identifiers cannot be used for things like STIR or global routing.

> On May 20, 2015, at 10:31 AM, Steve Donovan <[email-masked]> wrote:
> 
> Eric,
> 
> I'm not comfortable with saying that MODERN  is ONLY about managing globally unique identifiers as this rules out private numbering plans put in place by enterprises. 
> 
> Yes, MODERN is about globally unique identifiers that have the format of a telephone number, but it is also about private identifiers that also have the format of a telephone number.
> 
> Regards,
> 
> Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 20 May 2015 12:02:15 -0500

I'm referring to private number ranges that potentially have zero 
correlation to E.164 numbers.

I don't think we need to change the existing charter to cover this 
case.  I just don't want to change it in a way that would preclude 
private numbers.

In the end both types of TNs need to be supported.

Steve

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 24 May 2015 05:27:37 +0000

Adding in private numbers introduces all sorts of complications.

In many cases there is a mapping between E.164 numbers and private numbers, i.e. the allocation by the public administration of an E.164 number automatically generates a valid private number, and vice versa. In other cases there could be no such mapping. When you apply the above to international private networks, with DDI ranges in multiple countries belonging to the same private network, it gets even more complicated.

There are other complications resulting from the joint ownership of some companies, resulting in an owned companies network forming part of the private numbering plan of both parent companies.

Unless there is a proven use case from deployers of private networks, I strongly propose that we should avoid these cases altogether.

I'd note by the way that I have not been pushing for global uniqueness, only against the assumption that the numbering plans are not locally unique to the particular administration. I believe we should assume local uniqueness, but that does not presuppose global uniqueness.

regards

Keith

________________________________
From: Modern [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: [email-masked]
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

Regards,

Steve

Something I have been mulling about is the focus (and amount of list traffic) discussing whether the scope of MODERN is E.164 numbers, "telephone numbers," or something else.

We seem to get very emotional about E.164 numbers. Perhaps rightly so. An E.164 number carries a lot of a'priori regulatory baggage. By definition, the ITU-T assigns country codes. National numbering authorities allocate numbers to service providers. Service providers manage them for users.

A "telephone number" spawns the debate as to whether it is, in fact, a 'telephone' number. Given Henning's presentation, the value of the telephone number is global routing and global understanding for 5/7ths of the world using romanized arabic script. Given that, the people who worry that "telephone number" is just a code word for E.164 number are most likely correct. This spills into the whole "It is not an E.164 number, it is the ABNF for an E.164 number (see RFC3966)." I.e., it looks, smells, and tastes like a rose.

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 25 May 2015 11:52:00 -0400

Now I am confused.

I was thinking we are building something more complex than just a registry of strings of digits to services and maybe routing. IANA (and a host of others) can do that today.

I thought the thing that needed solving, which Henning described at the BOF, was a how to provision and interface with a registry that maps strings of digits to services and maybe routing, where there was a clear need for some sort of (outside of scope) policy that needs to be enforced.

Am I wrong in thinking the entire point of MODERN is the mechanisms for policy enforcement?

By policy enforcement, I mean that, depending on jurisdiction, policies may be that only the national numbering authority can delegate the authority to allocate numbers to registered service providers. Or, a policy may be that only the national numbering authority can allocate numbers to users. Or, a policy may be that only the user can assign which services or service providers are allowed to service the number. What the policies are is out of scope for the work group. However, that there are policies I was under the impression is the whole point of the work group.

I am very leery of a policy that says that some part of the name space lives with the ITU-T and national numbering authorities, but another part of the name space is a free-for-all. What is to stop me from declaring “+1 214-555-1000” to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? TN?) name space, then say so. Then Keith’s question becomes relevant: what is the use case? Cullen, is this in the Cisco world? Steven, is this in the Oracle world?

Thanks,
Eric

> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/modern <https://www.ietf.org/mailman/listinfo/modern>
>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 25 May 2015 21:21:31 -0500

Private number spaces cannot be part of the publicly managed numbers.  
They can and generally are mapped to public numbers but that is very 
different from me declaring that "+1 214 555 0000" is a private number.  
Private numbers only work in the context of devices used in the "domain" 
that is administering the private number space.

I thought I had already said that private numbers are not a part of 
E.164.  They are, however, still TNs by the definition currently in the 
charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used 
to initiate communication with another user of a service. "

Steve

On 5/25/15 10:52 AM, Eric Burger wrote:
> Now I am confused.
>
> I was thinking we are building something more complex than just a 
> registry of strings of digits to services and maybe routing. IANA (and 
> a host of others) can do that today.
>
> I thought the thing that needed solving, which Henning described at 
> the BOF, was a how to provision and interface with a registry that 
> maps strings of digits to services and maybe routing, *where there was 
> a clear need for some sort of (outside of scope) policy that needs to 
> be enforced.*
> *
> *
> By policy enforcement, I mean that, depending on jurisdiction, 
> policies may be that only the national numbering authority can 
> delegate the authority to allocate numbers to registered service 
> providers. Or, a policy may be that only the national numbering 
> authority can allocate numbers to users. Or, a policy may be that only 
> the user can assign which services or service providers are allowed to 
> service the number. What the policies are is out of scope for the work 
> group. However, that there are policies I was under the impression is 
> the whole point of the work group.
>
> I am very leery of a policy that says that some part of the name space 
> lives with the ITU-T and national numbering authorities, but another 
> part of the name space is a free-for-all. What is to stop me from 
> declaring “+1 214-555-1000” to be just a private number?
>
> If the proposal is that private numbers are not in the numbering 
> (E.164? TN?) name space, then say so. Then Keith’s question becomes 
> relevant: what is the use case? Cullen, is this in the Cisco world? 
> Steven, is this in the Oracle world?
>
> Thanks,
> Eric
>
>
>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> In many cases there is a mapping between E.164 numbers and private 
>> numbers, i.e. the allocation by the public administration of an E.164 
>> number automatically generates a valid private number, and vice 
>> versa. In other cases there could be no such mapping. When you apply 
>> the above to international private networks, with DDI ranges in 
>> multiple countries belonging to the same private network, it gets 
>> even more complicated.
>> There are other complications resulting from the joint ownership of 
>> some companies, resulting in an owned companies network forming part 
>> of the private numbering plan of both parent companies.
>> Unless there is a proven use case from deployers of private networks, 
>> I strongly propose that we should avoid these cases altogether.
>> I'd note by the way that I have not been pushing for global 
>> uniqueness, only against the assumption that the numbering plans are 
>> not locally unique to the particular administration. I believe we 
>> should assume local uniqueness, but that does not presuppose global 
>> uniqueness.
>> regards
>> Keith
>>
>>     ------------------------------------------------------------------------
>>     *From:* Modern [mailto:[email-masked]] *On Behalf Of
>>     *Steve Donovan
>>     *Sent:* 20 May 2015 15:31
>>     *To:* [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [Modern] TN, E.164, or Something Else?
>>
>>     Eric,
>>
>>     I'm not comfortable with saying that MODERN  is ONLY about
>>     managing globally unique identifiers as this rules out private
>>     numbering plans put in place by enterprises.
>>
>>     Yes, MODERN is about globally unique identifiers that have the
>>     format of a telephone number, but it is also about private
>>     identifiers that also have the format of a telephone number.
>>
>>     Regards,
>>
>>     Steve
>>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 26 May 2015 10:26:54 -0400

I’d like to reiterate my higher level struggle with this, to add a bit to Eric’s more policy oriented questions.

To me, provisioning interfaces are dime a dozen.

To the new world providers that are looking at this new telecom environment where there are private numbers and we have a nice easy to use provisioning interface (assuming policy allows) the preference would be something that would be a few weeks work to integrate a number provisioning interface.  Much in the same style you would integrate Facebook or twitter interfaces for auth, etc.

To a traditional telecom service provider, they would likely look at this world as pain and headache, but that’s the world we live in currently, hopefully that is slowly changing for the better.

Correlating the concepts of “easy to use provisioning for new web oriented service providers” and building a new set of IETF protocols for provisioning does not compute in my head.

Ask any typical web oriented application provider, would they want to use DNS style protocols in their web applications to provision numbers for their customer??  Absolutely not, most would request an HTTP based interface.

So, i feel like there is a convoluted discussion going on that placates both new and old worlds with the opposite arguments.

If the policy side allows, the representatives of whatever private numbering space folks want to conform to should just build a simple straight forward RESTful interface to allow for number provisioning and call it a day.  I see no reason why this isn’t a completely valid easily adoptable path for all parties for private numbering.  

This would support adaptation between a number of worlds quite easily as well:
You could easily support multiple public and private numbering spaces within a single customer facing service and a new world begins, happy days.
This could be a business or product opportuntity that easily adapts new and old worlds with interface adaptors from and to old world provisioning systems.
Eventually, old world provisioning systems could be scrapped and overhauled into the new world.

To me, trying to do anything beyond the keep-it-simple approach is almost a guarantee for a repeat of history for these efforts.  Primarily because it’s the most painful for everyone option, new world has to use protocols they aren’t used to, old world needs to adapt protocols anyway.

-Chris

Comcast

> On May 25, 2015, at 10:21 PM, Steve Donovan <[email-masked]> wrote:
> 
> Private number spaces cannot be part of the publicly managed numbers.  They can and generally are mapped to public numbers but that is very different from me declaring that "+1 214 555 0000" is a private number.  Private numbers only work in the context of devices used in the "domain" that is administering the private number space.
> 
> I thought I had already said that private numbers are not a part of E.164.  They are, however, still TNs by the definition currently in the charter: "TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. "
> 
> Steve
> 
>>> On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> From: Modern [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Steve Donovan
>>> Sent: 20 May 2015 15:31
>>> To: [email-masked] <mailto:[email-masked]>

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 26 May 2015 15:19:30 +0000

Why do you think that the WG wouldn't "keep it simple"?

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 26, 2015 10:26 AM
To: Steve Donovan <[email-masked]<mailto:[email-masked]>>
Cc: Modern List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] TN, E.164, or Something Else?

-Chris

Comcast

On May 25, 2015, at 10:21 PM, Steve Donovan <[email-masked]<mailto:[email-masked]>> wrote:

Steve

Thanks,
Eric

On May 24, 2015, at 1:27 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:

regards

Keith

________________________________
From: Modern [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: 20 May 2015 15:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Modern] TN, E.164, or Something Else?

Eric,

Regards,

Steve

_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>

_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/modern<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>

_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 26 May 2015 14:36:19 -0400

Has the conversation to date provided any indication of this?  

Is the IETF in the business of defining RESTful or web service interfaces?

“Simple" is in the eye of the beholder of course.

> On May 26, 2015, at 11:19 AM, McGarry, Tom <[email-masked]> wrote:
> 
> From: Chris Wendt <[email-masked] <mailto:[email-masked]>>
> To: Steve Donovan <[email-masked] <mailto:[email-masked]>>
> Cc: Modern List <[email-masked] <mailto:[email-masked]>>
>> On May 25, 2015, at 10:21 PM, Steve Donovan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>>> [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>>> https://www.ietf.org/mailman/listinfo/modern <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>> 
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 26 May 2015 18:56:25 +0000

We're not developing a solution on the list yet (although it seems some keep trying to bring us there).  So I don't see any discussion on the list that would indicate that a WG would not try to avoid complexity and keep solutions simple.

And I certainly would expect to discuss web-based solutions.

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 26, 2015 2:36 PM
To: Tom Mcgarry <[email-masked]<mailto:[email-masked]>>
Cc: Modern List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] TN, E.164, or Something Else?

On May 26, 2015, at 11:19 AM, McGarry, Tom <[email-masked]<mailto:[email-masked]>> wrote:

-Chris

Comcast

Steve

Thanks,
Eric

regards

Keith

Eric,

Regards,

Steve

_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/modern<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ir3tvJvLhqRnmhzLCQm7ZyiKV7f6t5KZN9o1lW-vyGE&s=eMMgYy5MI-4cDg46y14wRpDceRl8odIyuri3Kq6tsdY&e=>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 May 2015 14:06:16 -0500

Is the concern that we don't need/want to define "new" protocols? 
There's no reason a working group could not choose a RESTful or web 
services interface.

The charter text leaves room for choosing existing protocols rather than 
defining new ones. Perhaps it should go further and express a preference 
for using (or building on) existing protocols?

On 26 May 2015, at 13:36, Chris Wendt wrote:

>> I’d like to reiterate my higher level struggle with this, to add a 
>> bit to Eric’s more policy oriented questions.
>>
>> To the new world providers that are looking at this new telecom 
>> environment where there are private numbers and we have a nice easy 
>> to use provisioning interface (assuming policy allows) the preference 
>> would be something that would be a few weeks work to integrate a 
>> number provisioning interface.  Much in the same style you would 
>> integrate Facebook or twitter interfaces for auth, etc.
>>
>> To a traditional telecom service provider, they would likely look at 
>> this world as pain and headache, but that’s the world we live in 
>> currently, hopefully that is slowly changing for the better.
>>
>> Correlating the concepts of “easy to use provisioning for new web 
>> oriented service providers” and building a new set of IETF 
>> protocols for provisioning does not compute in my head.
>>
>> Ask any typical web oriented application provider, would they want to 
>> use DNS style protocols in their web applications to provision 
>> numbers for their customer??  Absolutely not, most would request an 
>> HTTP based interface.
>>
>> So, i feel like there is a convoluted discussion going on that 
>> placates both new and old worlds with the opposite arguments.
>>
>> If the policy side allows, the representatives of whatever private 
>> numbering space folks want to conform to should just build a simple 
>> straight forward RESTful interface to allow for number provisioning 
>> and call it a day.  I see no reason why this isn’t a completely 
>> valid easily adoptable path for all parties for private numbering.
>>
>> You could easily support multiple public and private numbering spaces 
>> within a single customer facing service and a new world begins, happy 
>> days.
>> This could be a business or product opportuntity that easily adapts 
>> new and old worlds with interface adaptors from and to old world 
>> provisioning systems.
>> To me, trying to do anything beyond the keep-it-simple approach is 
>> almost a guarantee for a repeat of history for these efforts.  
>> Primarily because it’s the most painful for everyone option, new 
>> world has to use protocols they aren’t used to, old world needs to 
>> adapt protocols anyway.
>>
>> -Chris
>>
>> Comcast
>>
>>
>>> On May 25, 2015, at 10:21 PM, Steve Donovan 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> Private number spaces cannot be part of the publicly managed 
>>> numbers.  They can and generally are mapped to public numbers but 
>>> that is very different from me declaring that "+1 214 555 0000" is a 
>>> private number.  Private numbers only work in the context of devices 
>>> used in the "domain" that is administering the private number space.
>>>
>>> E.164.  They are, however, still TNs by the definition currently in 
>>> the charter: "TNs, as defined in RFC3966, and blocks of TNs, that 
>>> are used to initiate communication with another user of a service. "
>>>
>>> Steve
>>>
>>>> registry of strings of digits to services and maybe routing. IANA 
>>>> (and a host of others) can do that today.
>>>>
>>>> maps strings of digits to services and maybe routing, where there 
>>>> was a clear need for some sort of (outside of scope) policy that 
>>>> needs to be enforced.
>>>>
>>>> authority can allocate numbers to users. Or, a policy may be that 
>>>> only the user can assign which services or service providers are 
>>>> allowed to service the number. What the policies are is out of 
>>>> scope for the work group. However, that there are policies I was 
>>>> under the impression is the whole point of the work group.
>>>>
>>>> I am very leery of a policy that says that some part of the name 
>>>> space lives with the ITU-T and national numbering authorities, but 
>>>> another part of the name space is a free-for-all. What is to stop 
>>>> me from declaring “+1 214-555-1000” to be just a private 
>>>> number?
>>>>
>>>> (E.164? TN?) name space, then say so. Then Keith’s question 
>>>> becomes relevant: what is the use case? Cullen, is this in the 
>>>> Cisco world? Steven, is this in the Oracle world?
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>> numbers, i.e. the allocation by the public administration of an 
>>>>> E.164 number automatically generates a valid private number, and 
>>>>> vice versa. In other cases there could be no such mapping. When 
>>>>> you apply the above to international private networks, with DDI 
>>>>> ranges in multiple countries belonging to the same private 
>>>>> network, it gets even more complicated.
>>>>>
>>>>> There are other complications resulting from the joint ownership 
>>>>> of some companies, resulting in an owned companies network forming 
>>>>> part of the private numbering plan of both parent companies.
>>>>>
>>>>> Unless there is a proven use case from deployers of private 
>>>>> networks, I strongly propose that we should avoid these cases 
>>>>> altogether.
>>>>>
>>>>> uniqueness, only against the assumption that the numbering plans 
>>>>> are not locally unique to the particular administration. I believe 
>>>>> we should assume local uniqueness, but that does not presuppose 
>>>>> global uniqueness.
>>>>>
>>>>> regards
>>>>>
>>>>> Keith
>>>>>
>>>>>
>>>>>
>>>>>> From: Modern [mailto:[email-masked] 
>>>>>> <mailto:[email-masked]>] On Behalf Of Steve Donovan
>>>>>> Sent: 20 May 2015 15:31
>>>>>>> Something I have been mulling about is the focus (and amount of 
>>>>>>> list traffic) discussing whether the scope of MODERN is E.164 
>>>>>>> numbers, “telephone numbers,” or something else.
>>>>>>>
>>>>>>> We seem to get very emotional about E.164 numbers. Perhaps 
>>>>>>> rightly so. An E.164 number carries a lot of a’priori 
>>>>>>> regulatory baggage. By definition, the ITU-T assigns country 
>>>>>>> codes. National numbering authorities allocate numbers to 
>>>>>>> service providers. Service providers manage them for users.
>>>>>>>
>>>>>>> A “telephone number” spawns the debate as to whether it is, 
>>>>>>> in fact, a ‘telephone’ number. Given Henning’s 
>>>>>>> presentation, the value of the telephone number is global 
>>>>>>> routing and global understanding for 5/7ths of the world using 
>>>>>>> romanized arabic script. Given that, the people who worry that 
>>>>>>> “telephone number” is just a code word for E.164 number are 
>>>>>>> most likely correct. This spills into the whole “It is not an 
>>>>>>> E.164 number, it is the ABNF for an E.164 number (see 
>>>>>>> RFC3966).” I.e., it looks, smells, and tastes like a rose.
>>>>>>>
>>>>>>> Could we agree to disagree and say that MODERN is about managing 
>>>>>>> globally unique identifiers that have a syntax of up to 15 
>>>>>>> decimal digits that have some hierarchical authorities mixed in 
>>>>>>> to lock down who can and cannot request and assign numbers? 
>>>>>>> Those authorities can be an opaque thingbat, because that is 
>>>>>>> where we get into the policy bits, and everyone on the list 
>>>>>>> swears MODERN will not touch policy.
>>>>>>>
>>>>>>>
>>>>>>> <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern 
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>>>
>>>>
>>>>
>>>> <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/modern 
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>> <https://www.ietf.org/mailman/listinfo/modern>
>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 26 May 2015 20:16:06 +0000

I've envisioned that this group will be primary focused on developing
information models, with the encoding and transport of the data itself
taking place via pre-defined and popular protocols. We don't need to
invent a new JSON, we need the expertise to figure out what the basic
semantics of queries and responses should be for the architectures under
consideration. In that sense, even TeRQ is not a "new" protocol, it's just
an information model with rules for how to bind it to various lightweight
or heavyweight encodings as necessary.

Jon Peterson
Neustar, Inc.

On 5/26/15, 12:06 PM, "Ben Campbell" <[email-masked]> wrote:

>> ³Simple" is in the eye of the beholder of course.
>>
>>
>>> I¹d like to reiterate my higher level struggle with this, to add a
>>> bit to Eric¹s more policy oriented questions.
>>>
>>> this world as pain and headache, but that¹s the world we live in
>>> Correlating the concepts of ³easy to use provisioning for new web
>>> oriented service providers² and building a new set of IETF
>>> and call it a day.  I see no reason why this isn¹t a completely
>>> Primarily because it¹s the most painful for everyone option, new
>>> world has to use protocols they aren¹t used to, old world needs to
>>> adapt protocols anyway.
>>>
>>> -Chris
>>>
>>> Comcast
>>>
>>>
>>>>> me from declaring ³+1 214-555-1000² to be just a private
>>>>> number?
>>>>>
>>>>> (E.164? TN?) name space, then say so. Then Keith¹s question
>>>>>>>> numbers, ³telephone numbers,² or something else.
>>>>>>>>
>>>>>>>> rightly so. An E.164 number carries a lot of a¹priori
>>>>>>>> A ³telephone number² spawns the debate as to whether it is,
>>>>>>>> in fact, a Œtelephone¹ number. Given Henning¹s
>>>>>>>> ³telephone number² is just a code word for E.164 number are
>>>>>>>> most likely correct. This spills into the whole ³It is not an
>>>>>>>> RFC3966).² I.e., it looks, smells, and tastes like a rose.
>>>>>>>>
>>>>>>>><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
>>>>>>>>mailman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32i
>>>>>>>>B7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZY
>>>>>>>>Z0aGnSyxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>>>>><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
>>>>>>ilman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Hu
>>>>>>fveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnS
>>>>>>yxTsyFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>
>>>>>
>>>>>
>>>>>
>>>>><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>>>>lman_listinfo_modern&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Hufv
>>>>>eeIDcLextZ1ooNcfp01IYIaVqsORjI&m=ook7ezMBcf-_t2kjt1ww-SKyyBZYZ0aGnSyxT
>>>>>syFB4k&s=MIpfiYX3CP2w40cLYVXvmf_XkI-uR95UmLuDU14yJ1U&e=>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 May 2015 15:19:24 -0500

On 26 May 2015, at 15:16, Peterson, Jon wrote:

> taking place via pre-defined and popular protocols.

Should the charter say that?

> We don't need to

Thanks!

Ben.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 26 May 2015 20:34:33 +0000

It is the mere fact that they are mapped to public network numbers that causes the issues.

If you are trying to understand the usage of the private number, then you will also need to understand the mapping when that exists.

And that will depend also on whether you are the administrator of the private numbering space or the public numbering space, or in the case of Centrex and business trunking, potentially both.

Keith

Sent: 26 May 2015 03:22

Steve

I am very leery of a policy that says that some part of the name space lives with the ITU-T and national numbering authorities, but another part of the name space is a free-for-all. What is to stop me from declaring "+1 214-555-1000" to be just a private number?

If the proposal is that private numbers are not in the numbering (E.164? TN?) name space, then say so. Then Keith's question becomes relevant: what is the use case? Cullen, is this in the Cisco world? Steven, is this in the Oracle world?

Thanks,
Eric

regards

Keith

Eric,

Regards,

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 26 May 2015 21:03:51 +0000

If it makes people more comfortable for that to be in the charter, I'm all
for it. I think it's a reasonable constraint on the design. I'm not sure
the charter needs to declare a preemptive consensus for JSON versus some
other format, say, but the general sentiment that we're not in the
business of building new transports, but instead focusing on semantics,
would be fine with me.

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Tue, 26 May 2015 21:45:53 -0400

If this is the intent, specifically your statement about transports vs semantics, and everybody is in general agreement with this, then the scope is a lot less open-ended than i was interpreting.

It would certainly make me more comfortable to add this language to the charter.

Thanks.

-Chris

> On May 26, 2015, at 5:03 PM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 May 2015 20:50:06 -0500

On 26 May 2015, at 20:45, Chris Wendt wrote:

> If this is the intent, specifically your statement about transports vs 
> semantics, and everybody is in general agreement with this, then the 
> scope is a lot less open-ended than i was interpreting.

I am in general agreement with this. While I would hesitate to 
completely forbid the working group from designing new protocols in the 
unlikely case that it decided no reasonable choice met the requirements, 
I very much agree to stating a strong preference for not doing so.

>>>> consideration. In that sense, even TeRQ is not a "new" protocol, 
>>>> it's
>>>> just

---

From: Steve Donovan <[email-masked]>
Date: Wed, 27 May 2015 09:35:07 -0500

I think we're pretty close.

Here's the paragraph in question:

The working group will define an information management framework for 
the roles
and functions involved in associating information with one or more TNs 
in an IP
environment.  The working group will also define protocol mechanisms to 
support
the interactions between the functions defined by the framework. This 
includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs.  The protocol mechanism for acquiring TNs will provide an
enrollment process for the entities that use and manage TNs. TNs may 
either be
managed in a hierarchical tree, or in a distributed peer-to-peer 
architecture.
Privacy of the managed data and security of the resource will be primary
considerations.  The protocol mechanism for resolving TNs will allow 
entities
such as service providers, devices, and applications to access data 
related to
TNs.  Maintaining reliability, real time application performance, 
security and
privacy are primary considerations.  The working group will take into
consideration existing IETF work including ENUM, SPEERMINT, DRINKS and SCIM.

How about if we change the second sentence from "...The working group 
will define protocol mechanisms..." to "...The working group will 
___identify___ protocol mechanisms.

The next sentence already talks about recommending or defining. Maybe if 
we change "...This includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs..." to "...This includes
either recommending or defining protocol mechanisms for acquiring, 
associating
and resolving TNs, ___with a preference for use of existing transports___".

This should hopefully address the concern.

Steve

On 5/26/15 8:50 PM, Ben Campbell wrote:
>> If this is the intent, specifically your statement about transports 
>> vs semantics, and everybody is in general agreement with this, then 
>> the scope is a lot less open-ended than i was interpreting.
>
> completely forbid the working group from designing new protocols in 
> the unlikely case that it decided no reasonable choice met the 
> requirements, I very much agree to stating a strong preference for not 
> doing so.
>
>>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 27 May 2015 09:41:42 -0500

Keith,

I don't see this as a reason for precluding looking at private number 
spaces in the MODERN charter.

The mapping, should there be one, will be handled in context of the 
private space administrator, whether directly or delegated.  It 
shouldn't have any impact on the public numbering space.

It might be as simple as having an optional information element that 
includes the mapping for operations within the private number space.  
But this can be addressed by the working group.

Steve

On 5/26/15 3:34 PM, DRAGE, Keith (Keith) wrote:
> If you are trying to understand the usage of the private number, then 
> you will also need to understand the mapping when that exists.
> And that will depend also on whether you are the administrator of the 
> private numbering space or the public numbering space, or in the case 
> of Centrex and business trunking, potentially both.
> Keith
>
>     *Sent:* 26 May 2015 03:22
>     *To:* [email-masked]
>     that is very different from me declaring that "+1 214 555 0000" is
>     a private number.  Private numbers only work in the context of
>     devices used in the "domain" that is administering the private
>     number space.
>
>     I thought I had already said that private numbers are not a part
>     of E.164.  They are, however, still TNs by the definition
>     currently in the charter: "TNs, as defined in RFC3966, and blocks
>     of TNs, that are used to initiate communication with another user
>     of a service. "
>
>     Steve
>
>>     I thought the thing that needed solving, which Henning described
>>     at the BOF, was a how to provision and interface with a registry
>>     that maps strings of digits to services and maybe routing, *where
>>     there was a clear need for some sort of (outside of scope) policy
>>     that needs to be enforced.*
>>     *
>>     *
>>     space lives with the ITU-T and national numbering authorities,
>>     but another part of the name space is a free-for-all. What is to
>>     stop me from declaring “+1 214-555-1000” to be just a private number?
>>
>>>     In many cases there is a mapping between E.164 numbers and
>>>     private numbers, i.e. the allocation by the public
>>>     administration of an E.164 number automatically generates a
>>>     valid private number, and vice versa. In other cases there could
>>>     be no such mapping. When you apply the above to international
>>>     private networks, with DDI ranges in multiple countries
>>>     belonging to the same private network, it gets even more
>>>     complicated.
>>>     of some companies, resulting in an owned companies
>>>     network forming part of the private numbering plan of both
>>>     parent companies.
>>>     are not locally unique to the particular administration. I
>>>     believe we should assume local uniqueness, but that does not
>>>     presuppose global uniqueness.
>>>     regards
>>>     Keith
>>>
>>>         *From:* Modern [mailto:[email-masked]] *On Behalf
>>>         Of *Steve Donovan
>>>         managing globally unique identifiers as this rules out
>>>         private numbering plans put in place by enterprises.
>>>
>>>         Yes, MODERN is about globally unique identifiers that have
>>>         the format of a telephone number, but it is also about
>>>         private identifiers that also have the format of a telephone
>>>         number.
>>>
>>>         Regards,
>>>
>>>         Steve
>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 May 2015 09:46:41 -0500

On 27 May 2015, at 9:35, Steve Donovan wrote:

> environment.  The working group will also define protocol mechanisms 
> to support
> The next sentence already talks about recommending or defining. Maybe 
> if we change "...This includes

s/"existing transports"/"existing protocol mechanisms" and I think it's 
good. (The TSV guys are protective of the word "transport" :-) )

---

From: Mark R Lindsey <[email-masked]>
Date: Wed, 27 May 2015 11:37:38 -0400

Steve -- 

An upside to handling private number space is this: Private number spaces follow the general Internet pattern of defining domains to give context.
-- Email addresses have a domain.
-- All DNS zones have a domain, which might just be the root domain, "."
-- The tel URI already has a phone-context idea 

Where we don't have an explicit domain, a new, invisible level of indirection is added:
-- Private IP address space doesn't indicate its context

So far, we're all thinking about E.164 as the root domain for TNs. Let's plan to make domain specific, and E.164 should be one of them.

If we don't make the domain explicit, private number spaces will be created by replicating the numbering plan. For example, folks replicate the routing table every time a new private Internet routing domain / VRF instance is created.  And for telephony, without an explicit indicator of context, each system that needs its private space will run another instance of the TN-management system using the MODERN-defined mechanisms.  For example, ALU's phone system might end up having one server for managing internal telephone extensions, and a separate server involved in E.164 TNs.

Downsides to managing private number spaces:

-- We'll need to spend time thinking about the mapping. Is it a matter of defining the canonical name and its variants? Is this private address merely a speed-dial feature? Does the mapping between the extension "2207" and the E.164 EN "+12293160013" mean that the linking between the two needs specific authority delegated?

-- It'll make any resulting standards longer, more complicated, and therefore more likely to be buggy and ignored.

I hope to convince everyone to avoid optional parameters, because most telecom developers won't implement any optional parameter until forced. This leads to a mixture of implementations with and without support for any given optional parameter, putting us all in worse shape than if you had never define the optional parameter. E.g., look at the tel URI, and how often the phone-context is actually used in real networks. Though it might be a fine idea, phone-context is effectively a wart on RFC 3966 for practical application because interop engineers have to ensure both sides don't use it.

Mark

> On May 27, 2015, at 10:41 , Steve Donovan <[email-masked]> wrote:
> 
> Keith,
> 
> I don't see this as a reason for precluding looking at private number spaces in the MODERN charter. 
> 
> The mapping, should there be one, will be handled in context of the private space administrator, whether directly or delegated.  It shouldn't have any impact on the public numbering space.
> 
> It might be as simple as having an optional information element that includes the mapping for operations within the private number space.  But this can be addressed by the working group.
> 
> Steve
> 

              --- mailto:[email-masked] 
                  tel:+1-229-316-0013 
                  http://ecg.co/lindsey

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 May 2015 22:05:54 -0400

I am all for the charter saying the work group will produce [a set of] protocol(s) for provisioning / allocating ‘numbers’ that may or may not be private.

I seriously question the wisdom of chartering an IETF work group to build a data model.

The IETF is really good at developing protocols.

The IETF is spotty at best at developing stand-alone data models.

The idea of a data model that could be transported over REST, XMPP, SMTP, or foobar sounds intellectually stimulating but practically worse than useless. It encourages bloat to make sure the data could be exchanged over transaction ensured, sequenced, unreliable, or frobotz-capable transport protocols.

If we are not ready to produce protocols, we are not ready for a work group.

Reiterating sentence 1: let’s do what the IETF is good at and charter a protocol-developing work group.

Once we get there, I am sure we will include the “motherhood and apple pie” [1] statement that we will build upon existing IETF protocols, if they are available and make sense.

- Eric

[1] http://idioms.thefreedictionary.com/motherhood+and+apple+pie

> On May 27, 2015, at 10:46 AM, Ben Campbell <[email-masked]> wrote:
> 
>> The working group will define an information management framework for the roles
>> and functions involved in associating information with one or more TNs in an IP
>> environment.  The working group will also define protocol mechanisms to support
>> the interactions between the functions defined by the framework. This includes
>> either recommending or defining protocol mechanisms for acquiring, associating
>> enrollment process for the entities that use and manage TNs. TNs may either be
>> managed in a hierarchical tree, or in a distributed peer-to-peer architecture.
>> considerations.  The protocol mechanism for resolving TNs will allow entities
>> such as service providers, devices, and applications to access data related to
>> TNs.  Maintaining reliability, real time application performance, security and
>> How about if we change the second sentence from "...The working group will define protocol mechanisms..." to "...The working group will ___identify___ protocol mechanisms.
>> 
>> The next sentence already talks about recommending or defining. Maybe if we change "...This includes
>> either recommending or defining protocol mechanisms for acquiring, associating
>> either recommending or defining protocol mechanisms for acquiring, associating
> s/"existing transports"/"existing protocol mechanisms" and I think it's good. (The TSV guys are protective of the word "transport" :-) )
>