Subject: [Modern] A revised revised MODERN charter

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 10:20:36 -0500

The following is the latest proposed version of the MODERN working group 
charter with updates discussed on the list discussion so far.

Regards,

Steve

----------

CHARTER TEXT:

The MODERN working group will define a set of Internet-based mechanisms 
for the purposes of managing and resolving telephone numbers (TNs) in an 
IP environment.  Existing mechanisms for these purposes face 
obsolescence as the voice communications infrastructure evolves to IP 
technology and new applications for TNs become possible.  The 
traditional model of a TN having an association to a single service 
provider and a single application is breaking down.  Its use as a 
network locator is going away, but its use as an identifier for an 
individual or an organization will remain for some time. Devices, 
applications, and network tools increasingly need to manage TNs, 
including requesting and acquiring TN delegations from authorities.  A 
sample of problems with existing mechanisms include:

- lack of flexibility (for example, it can be difficult to add fields 
without a very elaborate and lengthy process typically spanning years)
- lack of distribution (for example, it is hard or impossible to have 
more than one administrator for each database)
- complexity (leading, for example, to a fair amount of rural call 
completion problems which aren't helped by small providers struggling to 
keep numbers straight)
- difficulty of adopting more modern allocation (e.g., "blocks" of 1) 
and porting mechanisms

The working group will define a framework for the roles and functions 
involved in managing and resolving TNs in an IP environment.  It will 
also define protocol mechanisms for acquiring and resolving TNs.  The 
protocol mechanism for acquiring TNs will provide an enrollment process 
for the individuals and 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 enrollment 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, possibly including 
caller name data (CNAM).  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, and DRINKS.

The work of this group will focus on E.164 telephone numbers due to the 
changing telecom environment and interest expressed by 
telecommunications industry regulators to support more flexible 
regulatory models than exist today.  There is an expectation that 
aspects of the architecture and protocols defined by the working group 
will be reusable for other user-focused identifiers.  Any such 
extensions or reuse of MODERN mechanisms are out of scope for the MODERN 
working group.  Solutions and mechanisms created by the working group 
will be flexible enough to accommodate different policies, e.g., by 
different regulatory agencies.

The work group will deliver the following:

-       An architecture overview, including high level requirements and 
security/privacy considerations

-       A description of the enrollment processes for existing and new 
TNs including any modifications to metadata related to those TNs

-       A description of protocol mechanisms for accessing contact 
information associated with enrollments

-       A description of mechanisms for resolving information related to TNs

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Apr 2015 16:24:36 +0000

While I understand the desire to scope identifiers in the charter per the
recent thread, I think putting it this starkly is too restrictive:

> Any such
> working group. 

I mean, I thought we were going to define an extensible query-response
protocol in this working group for managing data about telephone numbers.
Something that would look at least vaguely like what is in
draft-peterson-terq. From this reading, I could easily argue that TeRQ is
outside the scope of MODERN precisely because it is extensible to other
identifiers.

>From the recent thread, I had thought people were arguing for some gating.
Like "first, this working group is going to define a mechanism for
telephone numbers. The group may later recharter to work on other things."
I would be okay with some text along those lines, though frankly, I would
prefer the second sentence read more like, "this group is also chartered
to further investigate the use of other identifiers for the purpose of an
eventual recharter," since I think the expertise to scope the work on
identifiers resides on this mailing list and we should explicitly use it
for that purpose.

Also, in that same paragraph I'd prefer not to qualify "telephone numbers"
with "E.164". This seems to come up again and again, but, there are a lot
of telephone numbers we care about that do to fall under the E.164 plan.
The earlier charter text doesn't say E.164, and I don't see why this part
needs to either. Let's just keep it to "telephone numbers."

Jon Peterson
Neustar, Inc.

On 4/30/15, 8:20 AM, "Steve Donovan" <[email-masked]> wrote:

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

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 12:10:13 -0500

Jon,

In my mind a well defined and discrete charter is better than an open 
ended one.  I don't think the group will benefit from spending a lot of 
time arguing about what constitutes a telephone number.  It would be 
better to have a list of telephone number identifiers that we consider 
in scope.  I'm open to having that list contain more than one item, I 
just don't think it shouldn't be open ended.

The existing wording doesn't say that any defined mechanisms can't be 
extensible.  It says that the current iteration of the MODERN working 
group will not be responsible for defining those extensions.  If we need 
to add something to the charter saying that any 
architectures/frameworks/protocols/data models created by the working 
group should be extensible then we should, by all means, add that wording.

More inline.

Steve

> outside the scope of MODERN precisely because it is extensible to other
SRD> See my comment above.
> identifiers resides on this mailing list and we should explicitly use it
SRD> I'm ok with adding a work item along the lines that you articulate 
above.  It should come after the primary work items are finished.
> needs to either. Let's just keep it to "telephone numbers."
SRD> I assume you mean "do not fall under...".  Let's list the ones that 
we care about in the charter.  If we miss any that are architecturally 
significant then we can recharter and pull them in.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 30 Apr 2015 12:39:41 -0500

On 30 Apr 2015, at 12:10, Steve Donovan wrote:

> ended one.  I don't think the group will benefit from spending a lot 
> of time arguing about what constitutes a telephone number.  It would 
> be better to have a list of telephone number identifiers that we 
> consider in scope.  I'm open to having that list contain more than one 
> item, I just don't think it shouldn't be open ended.
>
> group will not be responsible for defining those extensions.  If we 
> need to add something to the charter saying that any 

I also read it that _extensions_ were out of scope, not necessarily 
_extensibility_.

Should we explicitly ask for extensibility?

> SRD> I'm ok with adding a work item along the lines that you 
> articulate above.  It should come after the primary work items are 
> finished.
>>
>>
> SRD> I assume you mean "do not fall under...".  Let's list the ones 
> that we care about in the charter.  If we miss any that are 
> architecturally significant then we can recharter and pull them in.
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>>> -       A description of mechanisms for resolving information 
>>> related to
>>> TNs
>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Apr 2015 18:28:56 +0000

I'd argue against putting extension statements in charters unless there is at least a perception of a clear need to do additional work.

At the end of the day, any working group can be rechartered, whether such a statement exists or not. Conversely, the AD has a big orange button to kill a working group, whether the charter has completed or not.

Regarding using the term "telephone number" rather than "E.164 number", then I am afraid that:

-	I find no standard definition of the term that is useful
-	use within normal English / American covers a very wide range of different perceptions, so in the US, I believe some people would quite happily refer to sequences incorporating alphabetic characters as telephone numbers. They would not in the UK.

I prefer to use terms that are defined, especially in this case. I would suggest the way forward is to identify what you want to cover explicitly in addition to E.164 numbers. Then the list can cast judgement. You may find that annex A of Recommendation E.164 gives you some appropriate terminology.

Regards

Keith 

> -----Original Message-----
> From: Modern [mailto:[email-masked]] On Behalf Of 
> Peterson, Jon
> Sent: 30 April 2015 17:25
> To: Steve Donovan; [email-masked]
> Subject: Re: [Modern] A revised revised MODERN charter
> 
> 
> While I understand the desire to scope identifiers in the 
> charter per the recent thread, I think putting it this 
> starkly is too restrictive:
> 
> > Any such
> > extensions or reuse of MODERN mechanisms are out of scope for the 
> > MODERN working group.
> 
> I mean, I thought we were going to define an extensible 
> query-response protocol in this working group for managing 
> data about telephone numbers.
> draft-peterson-terq. From this reading, I could easily argue 
> that TeRQ is outside the scope of MODERN precisely because it 
> is extensible to other identifiers.
> 
> Like "first, this working group is going to define a 
> mechanism for telephone numbers. The group may later 
> recharter to work on other things."
> I would be okay with some text along those lines, though 
> frankly, I would prefer the second sentence read more like, 
> "this group is also chartered to further investigate the use 
> of other identifiers for the purpose of an eventual 
> recharter," since I think the expertise to scope the work on 
> identifiers resides on this mailing list and we should 
> explicitly use it for that purpose.
> 
> 
> with "E.164". This seems to come up again and again, but, 
> there are a lot of telephone numbers we care about that do to 
> fall under the E.164 plan.
> The earlier charter text doesn't say E.164, and I don't see 
> why this part needs to either. Let's just keep it to 
> "telephone numbers."
> 
> Jon Peterson
> Neustar, Inc.
> 
> >The following is the latest proposed version of the MODERN working 
> >group charter with updates discussed on the list discussion so far.
> >
> >Regards,
> >
> >Steve
> >
> >----------
> >
> >CHARTER TEXT:
> >
> >for the purposes of managing and resolving telephone numbers 
> (TNs) in 
> >an IP environment.  Existing mechanisms for these purposes face 
> >completion problems which aren't helped by small providers 
> struggling 
> >to keep numbers straight)
> >for the individuals and 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 enrollment 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, possibly 
> >including caller name data (CNAM).  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, and DRINKS.
> >
> >extensions or reuse of MODERN mechanisms are out of scope for the 
> >MODERN working group.  Solutions and mechanisms created by 
> the working 
> >group will be flexible enough to accommodate different 
> policies, e.g., 
> >by different regulatory agencies.
> >
> >-       A description of mechanisms for resolving 
> information related to
> >TNs
> >

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Apr 2015 19:20:13 +0000

The list of identifiers I personally thought were interesting, and a
description of the nature of telephone numbers, are both in
draft-peterson-terq. Basically, when used for an ENUM-like query, TeRQ
proposed operating on either telephone numbers or SPIDs, and being able to
return a variety of identifiers including Internet identifiers like URIs
or PSTN identifiers like trunk groups. It did include the notion of
querying for a telephone number range - I think if we lose that property,
we will lose a bunch of use cases that we want to keep. SPIDs, well, I'd
be okay relegating them to a later extension or iteration.

But ranges are one reason why I'm reluctant to say "E.164" in the charter.
My understanding is that a lot of things don't fall under E.164, including
service codes, short codes, US freephone numbers, and various other
dialable numbers I think we care about. I would be comfortable defining
"telephone number" by its ABNF rather than by its policy or practice, and
going from there - in fact, I think doing so is essential to the whole
MODERN concept of reimagining number administration. That's roughly what
TeRQ does. In the early TeRQ discussions, there was some debate about
whether we need a new ABNF for telephone numbers, and if so, fine - but
that should be in the MODERN charter.

Jon Peterson
Neustar, Inc.

On 4/30/15, 11:28 AM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

>I'd argue against putting extension statements in charters unless there
>is at least a perception of a clear need to do additional work.
>
>At the end of the day, any working group can be rechartered, whether such
>a statement exists or not. Conversely, the AD has a big orange button to
>kill a working group, whether the charter has completed or not.
>
>-	use within normal English / American covers a very wide range of
>different perceptions, so in the US, I believe some people would quite
>happily refer to sequences incorporating alphabetic characters as
>telephone numbers. They would not in the UK.
>
>I prefer to use terms that are defined, especially in this case. I would
>suggest the way forward is to identify what you want to cover explicitly
>in addition to E.164 numbers. Then the list can cast judgement. You may
>find that annex A of Recommendation E.164 gives you some appropriate
>terminology.
>
>Regards
>
>Keith 
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 16:37:44 -0400

Are we boiling the ocean?

> On Apr 30, 2015, at 11:20 AM, Steve Donovan <[email-masked]> wrote:
> 
> The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment.

Does this mean we are replacing not only the NPAC, LERG, NANPA, et al., but ENUM, DNS, et al. too?

Let us put aside whether it is worth working on replacing something that works in order for the incumbents to spend a lot of money to get the features and functionality they get today. I.e., they have strong negative incentives to not use any results we develop in the IETF. Putting it bluntly, I did not see a lot of people saying the problems discussed by https://tools.ietf.org/html/draft-peterson-modern-problems-00 were problems that needed to be solved, or solved any time soon.

So, let’s put aside the Charter discussion for a few minutes, and see if we can come up with some problems that *do* need to be solved, and if we can rally behind a charter to solve them. If it happens that the solution to these problems can address the issues raised by Jon’s draft, then I think in the long term *everyone* can be happy.

OVERARCHING PROBLEM: E.164 numbers are being used for more than terminating phone calls by service providers.
[Why is this the overarching problem? Because if the problem is simply that the PSTN is transitioning to an all-IP telecommunications network, then until the industry really needs it, the industry will use the NPAC, LERG, etc. as is. The code to run the databases is already written, the code to interface with the databases is already written, and the policies, governance, procedures and regulations are already known and debugged.]

So, who would benefit from access to E.164 allocations that cannot get them right now?

I see two use cases; I would love it if people could pour in more.

USE CASE #1: Enterprise DID assignment
Cullen gave the compelling example of a multi-campus enterprise. Why do they need to buy their DIDs from a registered carrier, and then pay carriers for the privilege of moving them to other carriers for termination to their own campus?

USE CASE #2: DID-based applications
Another use case would be for enhanced services, such as a single number service. Today an enhanced services company needs to be a service bureau and buy their DIDs from a registered carrier, who will provide them with termination services. I.e., technically the service bureau is buying termination service and getting DIDs as a part of that termination service. Again, if the service bureau wants to change termination service providers, they have to pay for the privilege.

Let me examine Use Case #2. I would offer this is a compelling opportunity. Why? Because there are extant IP-based protocols for entities to get numbers from carriers today. Moreover, that are a bunch of incompatible IP-based protocols for entities to get numbers from carriers. I.e., we have existence proof of a solution, we have existence proof of market need, and we have an opportunity to create standards to expand markets and solve problems (like Cullen’s). For example (and thanks to Cullen for finding the URL’s so I do not need to go hunting), see:

> AT&T is doing this - see https://developer.att.com/apis/enhanced-webrtc/docs
> 
> Tropo is doing this - see phone number pricing at https://www.tropo.com/pricing/
> 
> Twillio is doing this - their pricing at https://www.twilio.com/voice/pricing#volume-pricing - and it is used by Uber, AIrBNB, PayPal, Opentable, Home Depot and so on
Twillio is also the back end for BT and others.

Note that where there are APIs, they are all different. That is an opportunity, I would think.

Now there is a subtlety going on here. All of these services are bundled with termination services. In the AT&T case mentioned above, it has a nice integration with their wireless offering and enterprise offering. For virtual numbers (DIDs), calls get handled by AT&T for termination to their customer, the app developer. For Tropo and Twillio, they ofter termination services at their platform, presumably through contracts with various global carriers, who have access to the pool of regional E.164 numbers.

Are we interested in making it easy for carriers to rent their inventory of DIDs? Are we interested in making it easy for application developers to have access to an inventory of DIDs? I know I am. Are you?

Note that solving this problem does not require the clean-sheet reinvention of the all-IP telecommunications network. I.e., not only how numbers are managed (which we have near zero consensus there is a need) but also how they are resolved (also near zero consensus there is a need).

Building on Use Case #1, if we can do retail rental of DIDs, any reason not to do bulk assignment of DIDs? This begins to come on to Cullen’s use case he brought up at the BOF. Namely, I am an enterprise and I somehow get a bucket full of DIDs. I want to assign them as I wish to my various campuses. That means that in addition to needing to be able to grab an allocation of DIDs (Use Case #2), I will need to tell my service provider how to terminate calls to a particular DID. That is a somewhat more challenging problem. However, I would offer it would have a big payout. The big payout is my expectation is a protocol that lets an enterprise grab a DID *and* lets an enterprise specify how to route that DID would look almost the same as a protocol that enables a carrier to manage E.164 allocation and use.

So, you might ask, “Has Eric lost his mind? Eric has been saying no one wants to build a protocol to enable a carrier to manage E.164 numbers, and yet in the paragraph above he says we can enable carriers to manage E.164 numbers!” Well, here is the answer: approaching the problem from the national numbering authority perspective is doomed. It is rather clear that no one wants to tackle it, and even if we did, as Pierce rather eloquently stated, we are walking right into other folks’ SDO patch. I would offer his ARIN analogy is 100% spot on.

Let us not look at this problem as “How do we do work to remove the last reason for carriers to exist?” That is, if carriers do not vouch for subscriber identity and manager their numbers, what is left for them to do? Instead, let us look at a parallel and really valid problem: how can we automate and standardize the interaction between _some_entity_with_numbers_ (carriers in the base case) and _some_entity_that_uses_numbers_ (app service bureaux and enterprises). If it happens the solution to that could be used for the cases mentioned in Jon’s draft, that is gravy.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Apr 2015 20:40:30 +0000

Well here is where it would help if people actually read E.164, and why I referred to annex A, especially when you say the terminology defined there does not suit your purpose.

To the best of my knowledge US freephone numbers are international E.164 numbers. They can be used across national boundaries; all that happens is that the resultant call is not free of charge.

If they are not used across national boundaries, I suspect they fall into the class identified in E.164 annex A.8.3.2 as international special purpose numbers used nationally.

What you mean by service codes are, I suspect, identified in E.164 annex A.8.3.1 as Local Special Purpose Numbers.

"telephone number range" is just a means of specifying multiple numbers in one go. It does not remove the necessity of saying what those numbers are.

As regards the latter part of your mail, IETF has zero responsibility for redefining the numbering plan for the telephony world, or its administration. If you want to do that, I suggest you get your tickets to ITU-T SG2. 

Keith

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: 30 April 2015 20:20
> To: DRAGE, Keith (Keith); Steve Donovan; [email-masked]
> The list of identifiers I personally thought were 
> interesting, and a description of the nature of telephone 
> numbers, are both in draft-peterson-terq. Basically, when 
> used for an ENUM-like query, TeRQ proposed operating on 
> either telephone numbers or SPIDs, and being able to return a 
> variety of identifiers including Internet identifiers like 
> URIs or PSTN identifiers like trunk groups. It did include 
> the notion of querying for a telephone number range - I think 
> if we lose that property, we will lose a bunch of use cases 
> that we want to keep. SPIDs, well, I'd be okay relegating 
> them to a later extension or iteration.
> 
> My understanding is that a lot of things don't fall under 
> E.164, including service codes, short codes, US freephone 
> numbers, and various other dialable numbers I think we care 
> about. I would be comfortable defining "telephone number" by 
> its ABNF rather than by its policy or practice, and going 
> from there - in fact, I think doing so is essential to the 
> whole MODERN concept of reimagining number administration. 
> That's roughly what TeRQ does. In the early TeRQ discussions, 
> there was some debate about whether we need a new ABNF for 
> telephone numbers, and if so, fine - but that should be in 
> the MODERN charter.
> 
> Jon Peterson
> Neustar, Inc.
> 
> >At the end of the day, any working group can be rechartered, whether 
> >such a statement exists or not. Conversely, the AD has a big orange 
> >button to kill a working group, whether the charter has 
> completed or not.
> >
> >Regarding using the term "telephone number" rather than 
> "E.164 number", 
> >then I am afraid that:
> >
> >I prefer to use terms that are defined, especially in this case. I 
> >would suggest the way forward is to identify what you want to cover 
> >explicitly in addition to E.164 numbers. Then the list can cast 
> >judgement. You may find that annex A of Recommendation E.164 
> gives you 
> >some appropriate terminology.
> >
> >Regards
> >
> >Keith
> >
> Peterson, 
> >> Jon
> charter per 
> >> the recent thread, I think putting it this starkly is too 
> >> restrictive:
> >> 
> >> > Any such
> >> draft-peterson-terq. From this reading, I could easily argue that 
> >> TeRQ is outside the scope of MODERN precisely because it is 
> >> extensible to other identifiers.
> >> 
> frankly, I 
> >> would prefer the second sentence read more like, "this 
> group is also 
> >> chartered to further investigate the use of other 
> identifiers for the 
> >> purpose of an eventual recharter," since I think the expertise to 
> >> scope the work on identifiers resides on this mailing list and we 
> >> should explicitly use it for that purpose.
> >> 
> >> 
> there are a 
> >> lot of telephone numbers we care about that do to fall under the 
> >> E.164 plan.
> >> The earlier charter text doesn't say E.164, and I don't 
> see why this 
> >> part needs to either. Let's just keep it to "telephone numbers."
> >> 
> >> Jon Peterson
> >> Neustar, Inc.
> >>

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 17:01:55 -0400

Here is a big question for the community that Keith has been touching on: what *is* a telephone number? As Keith points out, the only thing that makes sense for us to talk about is an E.164 number. Otherwise, we are talking about strings of digits that are up to 15 digits long. We can do that right now - heck, not much different than an ASN.

So, if we are talking about E.164 numbers, can we hand them out willy-nilly? The answer from Henning’s presentation: No, an E.164 number is literally that, something the ITU-T allocates at the international (country code) level [ITU Operational Bulletin No. 835]. Moreover, the answer for delegated numbers is also No: Henning’s expectation is different nation states will handle number allocation as they see fit.

What I am offering here, and the first point of question for the work group, is whether it makes sense for the IETF to be heading directly into policy space? I.e., carriers or users getting numbers directly from a numbering authority (to use Jon’s terms)?

My vote is a strong No. We do not have a need to reinvent number allocation. From a business perspective, carriers already get numbers from numbering authorities. The code is written, debugged, and works. In fact, it mostly works over IP, if you want to get into the particulars and feel that because something runs over IP it is ‘better.' Until it is time for the carriers to replace their provisioning systems, there is little need for a ‘new’ method to get what they get today.

> On Apr 30, 2015, at 3:20 PM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: Peter Koch <[email-masked]>
Date: Thu, 30 Apr 2015 23:41:52 +0200

On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote:

> My vote is a strong No. We do not have a need to reinvent number allocation. From a business perspective, carriers already get numbers from numbering authorities. The code is written, debugged, and works. In fact, it mostly works over IP, if you want to get into the particulars and feel that because something runs over IP it is ???better.' Until it is time for the carriers to replace their provisioning systems, there is little need for a ???new??? method to get what they get today.

my understanding is - and please take this as an attempt to rephrase the question
rather than an explanation, that - in IP address parlance - "allocation"
would be superseded by "assignment", getting rid of number blocks and the
necessity for porting, as well as, at the risk of crossing the policy
boundary, support for a thick registry (of TN holders) rather than a thin
registry (of block custodians).  I'm likely wrong, but I'd like to know where.

-Peter

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 17:53:22 -0400

> On Apr 30, 2015, at 5:41 PM, Peter Koch <[email-masked]> wrote:
> 

I do not know that you are wrong, but where is the requirement?

Is the requirement to eliminate service providers managing TNs?
Is the requirement to eliminate the two-tier model we have today, where national numbering authorities allocate TNs to service providers who allocate them to users? And related, where ‘users’ are sometimes enterprises or service bureaux who then allocate their numbers to users?
Is the requirement to eliminate the distributed model we have today in most of the world where the national numbering authority allocates TNs in blocks to service providers and replace it with a centralized model where all TNs live in a single data base?
Is the requirement to eliminate the quasi-distributed model we have today in countries such as the U.S., Canada, Argentina, India, etc. where the national numbering authority allocates TNs in blocks to services providers with a centralized data base for ported numbers?
Is there another requirement?

And, if we are going to dictate the numbering allocation model to the world, will the world accept it?