[martini] Fw: Apps Area Review team review: draft-ietf-martini-gin-10.txt

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

Just to keep the working group in the loop ...

Spencer

----- Original Message ----- 
From: "Ted Hardie" <[e-mail]>
To: "Apps Discuss" <[e-mail]>; <[e-mail]>; "Bernard Aboba" 
<[e-mail]>; "Spencer Dawkins" <[e-mail]>; 
"IESG" <[e-mail]>
Sent: Tuesday, November 30, 2010 4:11 PM
Subject: Apps Area Review team review: draft-ietf-martini-gin-10.txt


>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.