Re: [Modern] A revised revised MODERN charter

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

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
>