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.