Subject: Re: [Modern] Revised MODERN Charter

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Apr 2015 16:53:36 -0400

It would be very nice to keep CNAM CNIT issues away from MODERN at this
time.

The first order of business in CNIT is to define what is the thing or
things one queries for. There may be more than one possible data object.
How that data is retrieved could be a subject for MODERN but may not be.

MODERN is better focused on a generic set of protocols for the retrieval
and or provisioning of E.164 data or meta data and the security mechanisms
surrounding it.

On 4/22/15, 9:35 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>Quick comments:
>
>"security of the resource" - unclear what "resource" refers to and what
>security threats we worry about. Disruption by third parties? Rogue
>number manager? We don't have to go into great detail, but I think we
>agree that we generally assume that the managers are vetted and trusted
>and that any misbehavior would be dealt with outside a protocol context.
>(In the US, this is known as the FCC Enforcement Bureau - I guess you
>could call it the protocol police in this role.)
>
>More substantially, we might want to specify more precisely what privacy
>risk we're worried about. After all, all TN managers will have access to
>the enrollment data. It also isn't obvious whether enrollment data
>includes whois-like information or (say) simply the OCN. I suspect that
>this will depend on national regulators and industry customs. Is the
>"enrollment data" the same as the CNAM data? Right now, pretty much
>anyone can query CNAM for any number (see OpenCNAM and other API
>services).
>
>There is a bit of duplication between the "Additionally" paragraph and
>the next one, as both seem to include resolution and mention varying
>design requirements lists. Might be crisper to wrap the list of
>desirables into one.
>
>This also implies that the lookup to CNAM and the unspecified resolution
>are different, but it seems likely that there's a single query -> data
>operation, possibly with qualifiers and differentiated data availability.
>
>"or after the MODERN" - I wouldn't preclude re-chartering after the
>completion of the initial tasks.
>
>________________________________
>From: Modern [[email-masked]] on behalf of McGarry, Tom
>[[email-masked]]
>Sent: Monday, April 20, 2015 10:45 AM
>To: Modern List
>Subject: [Modern] Revised MODERN Charter
>
>The following changes were made from the version we went over in the BoF:
>
>  *   The fourth paragraph defines the identifiers to be worked on as
>"E.164 telephone numbers and telephony related identifiers"
>  *   The fourth paragraph describes the motivation as "the changing
>telecommunications environment and interest expressed by
>telecommunications industry regulators"
>  *   The fourth paragraph acknowledges that while the work of a proposed
>working group could be reusable for other identifiers, the work will
>focus on E.164 telephone numbers and other telephony related identifiers
>  *   The word "document" has been deleted from the list of deliverables
>to allow flexibility for combining deliverables
>
>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.
>
>The working group will define a framework for the roles and functions
>involved in managing and resolving TNs in an IP environment. This
>includes a protocol mechanism for acquiring TNs, which 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.
>
>Additionally, the working group will deliver a protocol mechanism for
>resolving TNs which 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 and other
>telephony related identifiers 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.
>Extensions to the MODERN defined architecture and protocols can occur
>outside of the MODERN working group, either in parallel with the MODERN
>working group or after the MODERN working group is complete.  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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/modern