Re: [Modern] A revised revised MODERN charter

["Ben Campbell" <[e-mail]>]

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

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

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

Should we explicitly ask for extensibility?

>
> More inline.
>
> Steve
>
> On 4/30/15 11:24 AM, Peterson, Jon wrote:
>> 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.
> SRD> See my comment above.
>>
>> >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.
> 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.
>>
>>
>> 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."
> 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.
>>
>> 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