Re: [Modern] A revised revised MODERN charter

[Steve Donovan <[e-mail]>]

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

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
>