Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"

["Elwell, John" <[e-mail]>]

I have reviewed this document and it is ready to go, apart from the following minor issues and nits that should be corrected.

1. "A registrar that receives a Contact URI with both a "bnc" parameter
   and a user portion MUST either discard the user portion and process
   the request as if the parameter were not present or ..."
It doesn't make sense. If the parameter were not present, one would expect a user portion to be present. I think this should say :
"A registrar that receives a Contact URI with both a "bnc" parameter
   and a user portion MUST either discard the user portion and process
   the request as if the user portion were not present or ..."
                         ^^^^^^^^^^^^

2. "Currently, the descriptions are somewhat informal, and omit some
   details for the sake of brevity.  If the MARTINI working group
   expresses interest in furthering the mechanism described by this
   document, they will be fleshed out with more detail and formality."
This seems to be historic and should be deleted.

3. "   When a UA registers with the SIP-PBX using GRUU procedures for a
   Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it
   received from the SSP.  This "sg" parameter contains a disambiguation
   token that the SIP-PBX can use to route the request to the proper
   user agent."
This isn't terribly clear. Rewording as follows might help:
"When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP.  This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA."

4. "The SSP registrar then maps I_i to the "bnc" AOR template and
      instance ID using the database, a persistent hash-map or similar
      technology."
This is the first use of the expression "AOR template and instance ID". We could do with some clarification, but I don't have a proposal. We have something that could be described as a template, but I would have considered that to be a contact template rather than an AOR template.

5. "(1) The SIP-PBX registers with the SSP for a range of AORs.
       It includes the URI it expects to receive in the Request-URI
       in its "Contact" header field, and includes information that
       routes to the SIP-PBX in the "Path" header field."
I think "the URI" should be changed to "the domain". Only the domain part of the REGISTER request's Contact header field will appear in the Request-URI of the inbound request.


Nits:
N1. "in the same way that
   is would " 
Change "is" to "it".

N2. "then the resulting registration
   information documents SHOULD contain an 'aor' attribute in its
   <registration/> element"
Change "documents" to "document", or alternatively add "each" after "SHOULD".

N3. "for all the potentially
   effected users"
Change "effected" to "affected".

N4. "The ability to learn the identity and registration state of every use
   on the PBX "
Change "use" to "user".

N5. "These are being defined in
   the MARTINI requirements document [8]."
Delete "being".

N6.  "   Further, the term "SSP" is meant as an acronym for a "SIP Service
   Provider," while "
Move the comma outside the quotes.

N7. Perhaps it is a matter of taste (ignore if you wish), but there are several places where we talk about REGISTER message or just REGISTER when we perhaps mean REGISTER request.

N8. Again a mater of taste, but in several places the word "multitude" is used, which suggests the number is always very large. Perhaps "multiplicity" might be better.

N9. "   that User Agents services by the SIP-PBX can acquire and use GRUUs
   for their own use."
Change "services" to "serviced".

N10. "sent the following Contact header field
   in its register"
Change "register" to "REGISTER request".

N11. "When the
      SSP registrar creates the first temporary GRUU for a particular
      SIP-PBX and instance ID..."
This is the first time "instance ID" has been mentioned - should we have a reference to RFC 5627 at this point?

N12. "temp-gruu-cookie = base64enc(I_i || SA)"
We should add "where || denotes concatenation." (the same as in 7.1.2.2)

N13: "This allows the SSP to
   designate a domain on the incoming Request URI that does not
   necessarily resolve to the SIP-PBX from when the SSP applies RFC 3263
   procedures to it."
I think the word "from" should be deleted.

N14: "This document registers a new SIP option tag to indicate support for
   the mechanism it defines, plus two new SIP URI parameters."
We should also mention the new header field parameter defined in 9.3.

N15: "more than on AOR"
Chance "on" to "one".


John


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: 07 July 2010 06:57
> To: [e-mail]
> Subject: [martini] Announcement of MARTINI WG last Call on 
> "Registration for Multiple Phone Numbers in the SIP"
> 
> This is an announcement of MARTINI WG last call on 
> "Registration for Multiple Phone Numbers in the SIP" prior to 
> requesting that the IESG publish the document as a Proposed Standard. 
> 
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt
> 
> MARTINI WG last call will conclude on Thursday, July 22, 2010. 
> 
> Please respond to this WG last call, whether you have 
> comments or not. 
> 
> If you have no comments, please reply to this message and 
> indicate in the body of your message whether you
> 
> think the document is ready for consideration by the IESG or not. 
> 
> If you have comments, please provide them to the WG in one of 
> the following ways: 
> 
> 1. If you have an account on the IETF Tools server, or can 
> open one, please login and enter your issue(s) in the 
> 
> MARTINI Issue tracking database (TRAC), which is available here:
> 
> http://trac.tools.ietf.org/wg/martini/trac/newticket
> 
> Note that if you submit an issue in TRAC, it will 
> automatically also be posted to the MARTINI WG mailing list. 
> 
> 2. If you don't have an account on the IETF Tools server, 
> please post your
> 
> Issue to the MARTINI WG mailing list (martini at ietf.org) in 
> the following format: 
> 
> To:  martini at ietf.org
> 
> Subject: Requirements-Issue: <title of your issue>
> 
> Priority: blocker, critical, major, minor or trivial
> 
> <Explanation of your issue, including a proposal for specific 
> text changes to resolve the issue>
> 
>