[Modern] AD Evaluation: draft-ietf-modern-problem-framework-03

[Adam Roach <[e-mail]>]

I'm doing my AD evaluation of draft-ietf-modern-problem-framework-03. 
Thanks to everyone who has helped out with this work. Content-wise, this 
document looks very good to me. I have some editorial comments, but none 
of them are so severe to prevent sending it to IETF last call, which I 
will request shortly.

Below, please find my editorial comments. Please treat these as IETF 
last call comments, and handle them at the same time as you deal with 
any comments that arise during that process.

Thanks!


>
>             Modern Problem Statement, Use Cases, and Framework
>                 draft-ietf-modern-problem-framework-03.txt


The title needs to make sense in a vacuum. I suggest "Problem Statement, 
Use Cases and Framework for Managing, Ordering, Distributing, Exposing, 
& Registering Telephone Numbers (MODERN)".


> 2.  Definitions
>
> ...
>     
>     Credential Authority:  An entity that distributes credentials, such
>        as certificates that attest the authority of assignees (defined


"...attest to the authority..."


>        below) and delegates.  This document assumes that one of more


"...one or more..."


>                  +---------+
>                  |Numbering|
>                  |Authority|Registry
>                  +----+----+
>                       |
>                       V 10,000 TNs
>                  +---------+
>                  |   CSP   |Registrar
>                  +----+----+
>                       |
>                       V  100 TNs
>                  +---------+
>                  |   PBX   |Assignee
>                  +---------+
>                       |
>                       V    1 TN
>                  +---------+
>                  |  User   |Delegate
>                  +---------+
>
>                     Figure 1: Chain of Number Assignment


These boxes, from top to bottom, are labeled with: Actor, Actor, Type of 
Hardware, Actor. I suggest that these should be consistent (e.g., change 
the third box from "PBX" to "Enterprise").


> 2.2.  Data Types
>
> ...
>   
>     Semi-restricted:  Only a subset of actors can access semi-restricted
>        data.  For example CSPs may be able to access other CSP's service
>        data in some closed environment.


"...closed environments."


> 4.  Use Cases
>
>     The high-level use cases in this section will provide an overview of
>     the expected operation of the three interfaces in the MODERN problem
>     space:


This is the first time we see "MODERN" in the document text. Please 
either qualify it (e.g., "...MODERN Working Group problem space:") or 
expand the acronym.


> 4.1.1.  Acquiring TNs from Registrar
>
> ...
>     Registrar, similarly to how such functions are conducted today when
>     Users purchase domain names.  For the purpose of status information
>     kept by the Registry, TNs assigned to a User are always considered
>     assigned, not inventory.In this use case, after receiving a number


Space between period and "In this use case..."


>
> 4.1.2.  Acquiring TNs from CSPs
> ...
>     Virtually the same flow would work for a reseller: it would form a
>     business relationship with the CSP, at which point the CSP would
>     collect and store administrative data about the reseller and give the
>     reseller any material needed for the reseller to acquire credentials
>     for the numbers.  A user might then in turn acquire numbers from the
>     reseller: in this case, the delegate re-delegating the TNs would be
>     performing functions done by the CSP, e.g., providing any
>     credentials, collecting administrative data, or creative service
>     data.


"...creating service data."


> 4.2.2.1.  CSP to other CSPs
>
> ...
>     If the CSP is assigning a TN from its own inventory it may not need
>     to perform service data updates as change occurs because the existing


Replace "as change occurs" with either "as such a change occurs" or "as 
changes occur."


> 4.2.3.1.  Changing the CSP for an Existing Service
>
>     Consider the case where a User who subscribes to a communications
>     service, and received their TN from that CSP, wishes to retain the
>     same TN but move their service to a different CSP.
>
>     In the simplest scenario, where there's an authoritative combined


"...where there is an..."


> 4.3.  Retrieval
>
>     Retrieval of administrative or service data will be subject to access
>     restrictions based on the category of the specific data: public,
>     semi-restricted or restricted.  Both administrative and service data
>     can have data elements that fall into each of these categories.  It
>     is expected that the majority of administrative will fall into the


"...of administrative data will..."


>     semi-restricted category: access to this information may require some
>     form of authorization, though service data crucial to reachability
>     will need to be accessible.  In some environments, it's possible that


"...it is possible..."


>     none of the service data necessary to initiate communications will be
>     useful to an entity on the public Internet, say, or that all that
>     service data will have dependencies on .


The ending of this sentence is unsatisfying. I think there's a missing word.


>
>     The retrieval protocol mechanism for semi-restricted and restricted
>     data needs a way for the receiver of the request to identify the
>     originator of the request and what is being requested.  The receiver
>     of the request will process that request based on this information.
>
> 4.3.1.  Retrieval of Public Data
>
>     Eithert administrative or service data may be made publicly available


"Either"


>     by the authority that generates and provisions it.  Under most
>     circumstances, a CSP wants its communications service to be publicly
>     reachable through TNs, so the retrieval interface supports public
>     interfaces that permit clients to query for service data about a TN.
>     Some service data may however require that the client be authorized


"...may, however, require..."


>     to receive it, per the use case in Section 4.3.3 below.
>
>     Public data can simply be posted on websites or made available
>     through a publicly available API.  Public data hosted by a CSP may
>     have a reference address at the Registry.
>
> 4.3.2.  Retrieval of Semi-restricted Administrative Data
>
>     Consider a case in which a CSP is having service problems completing
>     calls to a specific TN, so it wants to contact the CSP serving that
>     TN.  The Registry authorizes the originating CSP to access this
>     information.  It initiates a query to the Registry, the Registry

"The CSP initiates a query to the Registry, and the Registry..."


>     verifies the requestor and the requested data and Registry responds

"...data; the Registry responds..."


>     with the serving CSP and contact data.  However, CSPs might not want
>     to make those administrative contact points public data: they are
>     willing to share them with other CSPs for troubleshooting purposes,
>     but not to make them available to general communication.
>
>     Alternatively that information could be part of a distributed data


"Alternatively, such information..."


>     store and not stored at a monolithic Registry.  In that case, the CSP
>     has the data in a local distributed data store and it initiates the
>     query to the local data store.  The local data store responds with
>     the CSP and contact data.  No verification is necessary because it
>     was done when the CSP was authorized to receive the data store.
>
> 4.3.3.  Retrieval of Semi-restricted Service Data
>
>     Consider a case where a User on a CSP's network calls a TN.  The CSP
>     initiates a query for service data associated with the TN to complete
>     the call, and will receive special service data because the CSP
>     operates in a closed environment where different CSPs receive
>     different responses, and only participating CSPs can initiate
>     communications.  This service data would be flagged as semi-
>     restricted.  The query and response have real-time performance
>     requirements in that environment.
>
>     Semi-restricted service data also works in a distributed data store
>     model, where each CSP distributes its updated service data to all
>     other CSPs.  The originating CSP has the service data in its local
>     data store and queries it.  The local data store responds with the
>     service data.  The service data in the response can be a reference
>     address to a data store maintained by the serving CSP, or it can be
>     the service address itself.  In the case where the response gives a
>     reference address, a subsequent query would go to the serving CSP,
>     who would in turn authorize the requestor for the requested data and

"...which would in turn..."


>     respond appropriate.  In the case where the original response


"...respond appropriately."


> 7.  Security Considerations
>
> ...
>     A management interface for telephone numbers has similar
>     requirements.  Without proper authentication and authorization
>     mechanisms in place, an attack could use the management interface to

"...an attacker could use..."


>     disrupt service data or administrative data, which could deny service
>     to users, enable new impersonation attacks, prevent billing systems
>     from operating properly, and cause similar system failures.
>
>     Finally, a retrieval interfaces has its own needs for mutual


"Finally, a retrieval interface has its own..." or "Finally, retrieval 
interfaces have their own..."


>     authentication, integrity protection, and for confidentiality.  Any


"...authentication, integrity protection, and confidentiality" or 
"authentication, for integrity protection, and for confidentiality"


Thanks!

/a