Re: [Modern] All-IP telecommunications network or TN identifiers

[Eric Burger <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 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)"
> <[e-mail]> 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.
>> 
>> 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:[e-mail]] On Behalf Of
>>> Peterson, Jon
>>> Sent: 30 April 2015 17:25
>>> To: Steve Donovan; [e-mail]
>>> 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.
>>> 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" <[e-mail]> wrote:
>>> 
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> Modern mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/modern
>>> 
>>> _______________________________________________
>>> Modern mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/modern
>>> 
> 
> _______________________________________________
> Modern mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/modern