A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
RFC 5850

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

(Cullen Jennings) (was Discuss, Yes) Yes

Comment (2009-06-18)
No email
send info
- Abstract states "This framework also describes other goals that embody
the spirit of SIP applications as used on the Internet" - it would have
been useful if this sentence at least had identified a few of these goals.

- Section 2.3: "peers can take advantage of end-to-end message integrity
or encryption" - I would say this applies only when certain conditions are
met and hence perhaps something like "peers may take advantage..." or
similar would be better.

- Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early
"Acronyms" section would be useful.

- Section 3: The sentence "One means of accomplishing this is through the
ability to define and obtain URIs for these actions as described in
section ." seems to be missing the final section reference.


From Gen Art...

Nits/editorial comments: 
- in Abstract page 2: SIP -> Session Initiation Protocol (SIP)

- ToC page 3: Far fork -> Far-fork (or Near-fork -> Near fork but
 fixing the far branch seems better)

- Toc page 4: Acknowledgements -> Acknowledgments
 (IETF/RFC Editor spelling)

- 2.3 page 10: the UA abbrev should be introduced (and IMHO far before)

- 2.4.2.1 page 12: large- scale -> large-scale

- 2.6.7.2 page 17: the IVR abbrev must be introduced

- 3.3.2 page 26: from controller) -> from controller):

- 3.3.2 page 26: i.e. -> i.e.,
 (same for other i.e. and e.g.)

- 3.3.5 page 28: a central mixer) -> a central mixer).

- 3.3.8 page 29 (title): Far fork -> Far-fork

- 3.2.8 page 30: forked-media -> forked media ?

- 4 page 30: The class ... include -> includes ?

- 6.31 page 39: (ex: -> (e.g.,

- 7 page 39 (title): Acknowledgements -> Acknowledgments

(Dan Romascanu) Yes

(Jari Arkko) No Objection

Comment (2009-06-18 for -)
No email
send info
The flexibility offered by this model is incredible. But I am wondering
what it means for interoperability in practice. Are systems employing
this model in use, and what do we know of their interoperability across
vendors and across potentially different ways to handle calls?

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-06-18 for -)
No email
send info
Two very minor editorial nits:

First sentence of section 2.7.1: expansion of acronyms "SIPS"?

Renumber/reorganize sections 2.6.2-2.6.7 to indicate that these sections  all describe "Media Inermediaries", while sections 2.7 through 2.9 discuss other topics?

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-06-18 for -)
No email
send info
It seems to me that SIP is getting closer and closer to needing to make routing decisions as multi-segment SIP calls are established, and as SIP servers discover each other and the capabilities of other servers.

Although not specific, I would like to urge the SIP experts to consult with the Routing Area in order to see whether there is helpful cross-fertilisation that can take place.

(Russ Housley) No Objection

Comment (2009-06-15 for -)
No email
send info
  The Gen-ART Review by Francis Dupont raised a few editorial comments
  that ought to be considered:

   - in Abstract page 2: SIP -> Session Initiation Protocol (SIP)
   - ToC page 3: Far fork -> Far-fork (or Near-fork -> Near fork but
     fixing the far branch seems better)
   - ToC page 4: Acknowledgements -> Acknowledgments
     (IETF/RFC Editor spelling)
   - 2.3 page 10: the UA abbrev should be introduced (and IMHO far before)
   - 2.4.2.1 page 12: large- scale -> large-scale
   - 2.6.7.2 page 17: the IVR abbrev must be introduced
   - 3.3.2 page 26: from controller) -> from controller):
   - 3.3.2 page 26: i.e. -> i.e.,  (same for other i.e. and e.g.)
   - 3.3.5 page 28: a central mixer) -> a central mixer).
   - 3.3.8 page 29 (title): Far fork -> Far-fork
   - 3.2.8 page 30: forked-media -> forked media ?
   - 4 page 30: The class ... include -> includes ?
   - 6.31 page 39: (ex: -> (e.g.,
   - 7 page 39 (title): Acknowledgements -> Acknowledgments

Alexey Melnikov No Objection

Comment (2009-06-13 for -)
No email
send info
6.16.  Do Not Disturb

   In Do Not Disturb, Alice selects the Do Not Disturb option.  Calls to
   her either ring briefly or not at all and are forwarded elsewhere.
   Some variations allow specially authorized callers to override this
   feature and ring Alice anyway.  Do Not Disturb is best implemented in
   SIP using presence [RFC3264].

Should this be referencing [RFC3856]?

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-06-17)
No email
send info
Comments
--------

Although brief, the Security Considerations section reads well (a more
comprehensive trust/threat model analysis for the proposed framework would
have been nice though). It could be useful to add a sentence or two on
anonymity aspects in the context of the proposed framework. The body of
the text mentions this aspect in passing once (2.6.4) but there is no
mentioning in the Security Considerations section.

In the sixth paragraph, an explicit method for replay attack prevention is
recommended (lower-case "should"). I am not sure about the reason for this
and could potentially see other ways to mitigate such attacks. Hence, one
suggestion could be to replace the current "In the case of features
initiated by a former participant, these should be protected against
replay attacks by using a unique name or identifier per invocation" with:
"In the case of features initiated by a former participant, these should
be protected against replay attacks, e.g. by using a unique name or
identifier per invocation."

For clarity, I also suggest changing this section's last sentence to:
"These credentials may for example need to be passed transitively or
fetched in an event body."

A question: The third paragraph in the Security Considerations section
refers to Section 3.2 - might this be Section 2.3?

General/editorial:

- Abstract states "This framework also describes other goals that embody
the spirit of SIP applications as used on the Internet" - it would have
been useful if this sentence at least had identified a few of these goals.

- Section 2.3: "peers can take advantage of end-to-end message integrity
or encryption" - I would say this applies only when certain conditions are
met and hence perhaps something like "peers may take advantage..." or
similar would be better.

- Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early
"Acronyms" section would be useful.

- Section 3: The sentence "One means of accomplishing this is through the
ability to define and obtain URIs for these actions as described in
section ." seems to be missing the final section reference.

-- Magnus

(Robert Sparks) Recuse