Session Initiation Protocol (SIP) Session Mobility
RFC 5631

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

(Sam Hartman) (was Discuss) Yes

Comment (2007-09-19)
No email
send info
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

Comment (2007-09-19)
No email
send info
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

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.

(David Ward) (was Discuss) No Objection

(Magnus Westerlund) (was Discuss) No Objection