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

["Spencer Dawkins" <[e-mail]>]

So ... does the working group have any comments about the questions Ted 
Hardie asked in his review?

Opinions soon would be awesome. Gonzalo isn't very far from putting this 
draft on an IESG telechat agenda!

Spencer


> #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/>
>
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>