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

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jun 2015 22:24:43 +0000

Two historical RAI examples that come close are LoST and HELD (not exactly REST, but close). RDAP (out of WEIRDS) is a more recent, somewhat related, standards-track effort.

________________________________
From: Modern [[email-masked]] on behalf of Chris Wendt [[email-masked]]
Sent: Tuesday, May 26, 2015 2:36 PM
To: McGarry, Tom
Cc: [email-masked]
Subject: Re: [Modern] TN, E.164, or Something Else?

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]<mailto:[email-masked]>> wrote:

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?

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

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.

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]<mailto:[email-masked]>> wrote:

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

On 5/18/15 5:23 PM, Eric Burger wrote:

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.

_______________________________________________
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=>

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

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