Re: [Modern] A revised revised MODERN charter

["Peterson, Jon" <[e-mail]>]

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