[martini] gin #67 (new): Apps Area Review

["martini issue tracker" <[e-mail]>]

#67: Apps Area Review

 I have been selected as the Applications Area Review Team reviewer for
 this draft (for background on apps-review, please see
 http://www.apps.ietf.org/content/applications-area-review-team).
 Please resolve these comments along with any other Last Call comments you
 may receive.
 Please wait for direction from your document shepherd or AD before posting
 a new version of the draft.

 Document: draft-ietf-martini-gin-10.txt
 Title: Registration for Multiple Phone Numbers in the Session Initiation
 Protocol (SIP)
 Reviewer:Ted Hardie Review
 Date: November 30, 2010

 Summary: This draft is ready for publication as a proposed standard, with
 a few editorial issues which the author or working group may wish to
 consider.

 Major Issues: None identified.

 Minor Issues:

 In the "Constraints" section, the document notes:

   The following paragraph is perhaps the most important in
    understanding the reasons for the design decisions made in this
    document.

    Within the problem space that has been established for this work,
    several constraints shape our solution.  These are defined in the
    MARTINI requirements document [18].  In terms of impact to the
    solution at hand, the following two constraints have the most
    profound effect: (1) The SIP-PBX cannot be assumed to be assigned a
    static IP address; and (2) No DNS entry can be relied upon to
    consistently resolve to the IP address of the SIP-PBX.

 I suggest augmenting the pointer to the requirements document here with a
 pointer to Appendix A, which helpfully lists how the document meets the
 requirements (note however that the Appendix apparently elides
 requirements 18, 19, and 20 without comment).  Given the existence of
 appendix A, I am not personally certain I see the need for the first of
 the two paragraphs.

 In section 5.1, the document says:

   The "bnc" URI parameter indicates that special interpretation of the
    Contact URI is necessary: instead of representing a single, concrete
    Contact URI to be inserted into the location service, it represents
    multiple URIs (one for each associated AOR), semantically resulting
    in multiple AOR-to-Contact rows in the location service.

 Saying that the URI parameter represents multiple URIs will bend the brain
 of URI folks a bit, and the later text in 5.2 avoids this same issue:

    After the SIP-PBX is authenticated, the registrar
    updates its location service with a unique AOR-to-Contact mapping for
    each of the AORs associated with the SIP-PBX.  Semantically, each of
    these mappings will be treated as a unique row in the location
    service.  The actual implementation may, of course, perform internal
    optimizations to reduce the amount of memory used to store such
    information.

 I suggest using similar language for the 5.1 text, for example:

   The "bnc" URI parameter indicates that special interpretation of the
    Contact URI is necessary: instead of indicating the insertion of a
 single
    Contact URI into the location service, it indicates that
    multiple URIs (one for each associated AOR) should be inserted.

 Section 7.4 contains two elements which it may be appropriate to consider
 for inclusion in the Security Considerations.  The first of these is that
 proxies will not be able to apply policy decisions on as granular a basis
 as
 before:

    Proxies will be unable to make policy decisions on a
    contact-by-contact basis regarding whether to include themselves in
    the path.  Second, and similarly, all AORs on the SIP-PBX that are
    registered with a common REGISTER request will be forced to share a
    common Service-Route.

 Would this extend to proxies including themselves for the purposes of
 CALEA?  If so, this might be a privacy issue.  Similarly,  this text:

    This token or cookie may convey information
    to proxies about the identity, capabilities, and/or policies
    associated with the user.  Since this information will be shared
    among several AORs and several Contacts when multiple AOR
    registration is employed, care should be taken to ensure that doing
    so is acceptable for all AORs and all Contacts registered in a single
    REGISTER request.

 might properly be considered in the privacy portion of a Security
 Considerations section.  Back pointers to one or both sections may be
 appropriate if the author or WG concur.

 In the IANA registrations, IANA lists RFC 5727 as a governing document
 along with the ones listed by this draft; including it and a reference may
 be appropriate.

-- 
-----------------------------------+----------------------------------------
 Reporter:  ted.ietf@…             |       Owner:  adam@…          
     Type:  defect                 |      Status:  new             
 Priority:  minor                  |   Milestone:  milestone1      
Component:  gin                    |     Version:  1.0             
 Severity:  Submitted WG Document  |    Keywords:                  
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/67>
martini <http://tools.ietf.org/martini/>