Re: [Modern] A revised revised MODERN charter

["DRAGE, Keith (Keith)" <[e-mail]>]

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

> -----Original Message-----
> From: Peterson, Jon [mailto:[e-mail]] 
> Sent: 30 April 2015 20:20
> To: DRAGE, Keith (Keith); Steve Donovan; [e-mail]
> Subject: Re: [Modern] A revised revised MODERN charter
> 
> 
> 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
> >> 
> 
>