Session Initiation Protocol (SIP) Session Mobility
Note: This ballot was opened for revision 05 and is now closed.
(Sam Hartman) (was Discuss) Yes
I was disappointed that section 9 didn't discuss future directions for DTLS SRTP keying. Given the complexity of this spec, I think that DTLS SRTP may well be in use by the time this is deployed. Section 9 talks about the use of S/MIME to secure the crypto attribute. I'm not sure that actually works well with the rest of the spec. In particular, it seems that thee MN needs to stitch together a bunch of SDP and that would be incompatible with the SDP being encrypted. I'd hold a discuss on this if I thought there was any danger of someone trying to use S/MIME for this application. I think a discussion of how extensions to SDP (new attributes) interacts with the spec is important. What does the MN need to do when using 3pcc when it sees a SDP attribute it does not understand? Will this use of 3PCC make it harder to deploy new SDP attributes?
(Jon Peterson) Yes
(Jari Arkko) (was Discuss) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
As Sam noted, the liberal use of "must" and "should" is confusing. The word "must" seems to describe critical functional requirements. The word "should" seems to identify important functional requirements in some cases, but in other cases it mens preferred options where multiple mechanisms are expected to be available. For example, section 6.1 opens with "Before executing a session transfer, the device must check the capabilities of the CN and the new device." I interpert this as a critical functional requirement - if the device blindly transfers a session codec differences may cause a failure - that is not enforced by the protocols themselves. That is, SIP and SLP will not enforce this requirement (although they can be used to implement this requirement.) The last sentence in the first paragraph of 6.1 uses "should" to identify preferred mechanisms: Since the OPTIONS method is standard, it should be used to query the CN, while SLP should be used to get the media capabilities of local devices, since it is already being used for them. I interpereted this sentence to say "OPTIONS" is mandatory to implement for SIP, and the CN supports SIP (or it wouldn't be SIP session mobility!), so this mechanism is the appropriate one for interrogating the CN. SLP is already in use for local device discovery and supports device capability discovery, so it is the preferred solution for these devices. However, section 6.2 seems to identify a functional requirement: "Other differences in device capabilities, such as display resolution and bandwidth limitations, should also be reconciled during transfer." I generally recommend limiting the use of must and should in non-2119 contexts. This isn't a hard rule, but it usually increases teh document clarity.