Diameter Session Initiation Protocol (SIP) Application
RFC 4740

Note: This ballot was opened for revision 12 and is now closed.

(Allison Mankin) Yes

Comment (2006-02-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Very disappointed the OAM area does not coordinate to bring the related
radius document at the same time.  That needs management
to get closure - there is excessive perfectionism going on.  The radius
document as well as the diameter document are very strong requirements
in the external community.

(Dan Romascanu) Yes

(Bert Wijnen) (was Discuss, Yes) Yes

(Brian Carpenter) No Objection

Comment (2006-02-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
s/achronyms/acronyms/

(Margaret Cullen) No Objection

(Lisa Dusseault) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

Comment (2006-02-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The Introduction could use some additional text explaining that the functions described in this document go well beyond authentication and authorization methods, but furthermore deals with user profiles, message routing, and the like.

The use of the term "SIP server" in this document is as a bit ambiguous. There are numerous "server" roles that an entity might play in SIP: UASs, proxies, redirect servers, registrars, etc. It would be nice when the term server is used (especially in the first few sections) if it were explicit whether or not the text was meant to apply to some or all of those roles.

The scope of this document includes functions that overlap with RFC3263 - I would especially note the example given in 6.7 and the whole function of LIR/LIA. The relationship between DIAMETER-based message routing and traditional message routing as described in RFC3263 is a little unclear to me. In particular, I'm unsure how a DIAMETER server maps onto the "location service" abstraction defined in RFC3261. The manner in which a SIP server might be "assigned" to a user seems confusing to me when I read text like (from 8.6): 

   This is typically the situation when the user is either
   registered, or unregistered but a SIP server is still assigned to the
   user.

Unregistered but a SIP server is assigned to a user? Are these servers responsible for the domain specified in the host portion of the AoR, as a location service per RFC3261 would be? If not, what is the nature of this assignment? Or conversely, if I used the procedures in RFC3763, is it possible or likely that I would reach some server other than the one that has been "assigned" to the user?

Also, some further text on the intended use of SIP-Server-Capabilities (which in 9.3.1 and 9.3.2 appears to be left in syntax and semantics entirely up to local policy) would probably shed some light on its relationship with traditional SIP message routing. Use of capabilities to identify the next proxy server to which a request might be forwarded sounds like a substantial departure from traditional routing.

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Alex Zinin) No Objection