A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
draft-ietf-sipping-cc-framework-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the Yes position for Cullen Jennings |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2010-02-11
|
12 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-01-25
|
12 | (System) | IANA Action state changed to No IC from In Progress |
2010-01-25
|
12 | (System) | IANA Action state changed to In Progress |
2010-01-25
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-01-25
|
12 | Amy Vezza | IESG has approved the document |
2010-01-25
|
12 | Amy Vezza | Closed "Approve" ballot |
2010-01-25
|
12 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2010-01-22
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Yes from Discuss by Cullen Jennings |
2009-12-20
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-12-20
|
12 | (System) | New version available: draft-ietf-sipping-cc-framework-12.txt |
2009-11-11
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-11-11
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-06-19
|
12 | (System) | Removed from agenda for telechat - 2009-06-18 |
2009-06-18
|
12 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2009-06-18
|
12 | Ralph Droms | [Ballot comment] 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 … [Ballot comment] 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? |
2009-06-18
|
12 | Cullen Jennings | [Ballot comment] - Abstract states "This framework also describes other goals that embody the spirit of SIP applications as used on the Internet" - it … [Ballot comment] - 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 |
2009-06-18
|
12 | Cullen Jennings | [Ballot discuss] Magnus is out for a bit so I am going to hold his review .... Although brief, the Security Considerations section reads well … [Ballot discuss] Magnus is out for a bit so I am going to hold his review .... 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? |
2009-06-18
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Yes by Cullen Jennings |
2009-06-18
|
12 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-06-18
|
12 | Adrian Farrel | [Ballot comment] It seems to me that SIP is getting closer and closer to needing to make routing decisions as multi-segment SIP calls are established, … [Ballot comment] 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. |
2009-06-18
|
12 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-06-18
|
12 | Jari Arkko | [Ballot comment] The flexibility offered by this model is incredible. But I am wondering what it means for interoperability in practice. Are systems employing this … [Ballot comment] 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? |
2009-06-18
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2009-06-17
|
12 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-06-17
|
12 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-06-17
|
12 | Tim Polk | [Ballot comment] Comments -------- Although brief, the Security Considerations section reads well (a more comprehensive trust/threat model analysis for the proposed framework would have been … [Ballot comment] 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 |
2009-06-17
|
12 | Tim Polk | [Ballot discuss] This is a good document, it reads well, and provides a nice overview of the requirements for multi-party control of SIP. However, the … [Ballot discuss] This is a good document, it reads well, and provides a nice overview of the requirements for multi-party control of SIP. However, the Security Considerations need to be enhanced to cover some of the complexities of multi-party control, especially those introduced by the peer-to-peer approach. Implementing authentication, authorization, and policy in a peer-to-peer model for establishing conversation spaces seems to introduce new problems: (1) If authentication is being performed by "mutually untrusted participants" (bullet eight in the Introduction), then ensuring that consistent levels of authentication were performed becomes very difficult. (2) It will be difficult to convey which forms of authentication credentials are acceptable, since different participants may have different capabilities. That is, Alice may be able to validate certificate credentials while Bob can only handle shared keys (or whatever the other possibilities are in SIP). (3) Communicating how a participant was authenticated and by whom, in addition to the list of participants, may be important. I also believe that the same types of issues will apply with authorization and policy. I don't believe the issues are new (I seem to recall this discussion with respect to the conferencing framework), but they are more complicated in the peer-to-peer model. Perhaps we can refer to security considerations in other documents and note that the issues are exacerbated by the pee-to-peer model. Magnus Nystrom posted a secdir review on June 14. I believe many of his comments have merit and would like to discuss one on the call. I have appended the remainder as comments, and request that the authors include Magnus in any discussion of his comments. From the secidr review: Background ---------- This document describes a framework for call control and multi-party usage of SIP (while the abstract also talks about requirements, I did not see any strong requirements - at least there are no normative statements in the RFC 2119 sense in the document). There are some firm protocol requirements in this document, but I wonder if they are prominent enough without the use of 2119 language. I also recall that use of 2119 language in this type of document is controversial... does anyone else think that a mechanism of some sort to highlight the requirements is needed? |
2009-06-17
|
12 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-06-16
|
12 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom. |
2009-06-16
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-06-15
|
12 | Robert Sparks | [Ballot Position Update] New position, Recuse, has been recorded by Robert Sparks |
2009-06-15
|
12 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-06-15
|
12 | Russ Housley | [Ballot comment] The Gen-ART Review by Francis Dupont raised a few editorial comments that ought to be considered: - in Abstract page 2: … [Ballot comment] 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 |
2009-06-15
|
12 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-06-15
|
12 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu |
2009-06-13
|
12 | Alexey Melnikov | [Ballot comment] 6.16. Do Not Disturb In Do Not Disturb, Alice selects the Do Not Disturb option. Calls to her either ring briefly … [Ballot comment] 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]? |
2009-06-13
|
12 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-06-10
|
12 | Cullen Jennings | [Ballot comment] From Gen Art... Nits/editorial comments: - in Abstract page 2: SIP -> Session Initiation Protocol (SIP) - ToC page 3: Far fork -> … [Ballot comment] 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 |
2009-06-10
|
12 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings |
2009-06-10
|
12 | Cullen Jennings | Placed on agenda for telechat - 2009-06-18 by Cullen Jennings |
2009-06-10
|
12 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
2009-06-10
|
12 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
2009-06-10
|
12 | Cullen Jennings | Created "Approve" ballot |
2009-06-09
|
12 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-06-05
|
12 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-05-28
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2009-05-28
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2009-05-26
|
12 | Amy Vezza | Last call sent |
2009-05-26
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-05-26
|
12 | Amy Vezza | State Changes to Last Call Requested from AD Evaluation by Amy Vezza |
2009-05-26
|
12 | Amy Vezza | Last Call was requested by Amy Vezza |
2009-05-26
|
12 | (System) | Ballot writeup text was added |
2009-05-26
|
12 | (System) | Last call text was added |
2009-05-26
|
12 | (System) | Ballot approval text was added |
2009-05-24
|
12 | Cullen Jennings | Note field has been cleared by Cullen Jennings |
2009-05-24
|
12 | Cullen Jennings | [Note]: 'Sent ticket to LC' added by Cullen Jennings |
2009-05-22
|
12 | Cullen Jennings | [Note]: 'Make sure to do LC via ticket with ref to dispatch due to sipping being closed.' added by Cullen Jennings |
2009-05-22
|
12 | Cullen Jennings | [Note]: 'Make sure to do LC via ticket with ref to dispatch due to sip being closed.' added by Cullen Jennings |
2009-04-01
|
12 | Cullen Jennings | Responsible AD has been changed to Cullen Jennings from Jon Peterson |
2009-03-05
|
11 | (System) | New version available: draft-ietf-sipping-cc-framework-11.txt |
2009-01-14
|
12 | Jon Peterson | State Changes to AD Evaluation from Publication Requested by Jon Peterson |
2008-05-06
|
12 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Gonzalo Camarillo is the document shepherd. He has reviewed this document and believes it is ready to be published. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There have been extensive discussions on this document on the SIPPING list. The current revision of the draft addresses all the reviews received. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? After long discussions, all the WG was behind this effort. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes, the draft passes ID nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document only has Informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document contains a no-op IANA Considerations Section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No formal language is used in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines a framework and requirements for call control and multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Consensus was reached among all interested parties before requesting the publication of this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Some of the features in this document are widely implemented. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document shepherd is Gonzalo Camarillo. The responsible AD is Jon Peterson. |
2008-05-06
|
12 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-04-16
|
10 | (System) | New version available: draft-ietf-sipping-cc-framework-10.txt |
2007-12-05
|
09 | (System) | New version available: draft-ietf-sipping-cc-framework-09.txt |
2007-12-03
|
08 | (System) | New version available: draft-ietf-sipping-cc-framework-08.txt |
2007-03-07
|
07 | (System) | New version available: draft-ietf-sipping-cc-framework-07.txt |
2006-03-08
|
06 | (System) | New version available: draft-ietf-sipping-cc-framework-06.txt |
2005-10-26
|
05 | (System) | New version available: draft-ietf-sipping-cc-framework-05.txt |
2005-02-22
|
04 | (System) | New version available: draft-ietf-sipping-cc-framework-04.txt |
2003-10-27
|
03 | (System) | New version available: draft-ietf-sipping-cc-framework-03.txt |
2003-03-07
|
02 | (System) | New version available: draft-ietf-sipping-cc-framework-02.txt |
2002-07-05
|
01 | (System) | New version available: draft-ietf-sipping-cc-framework-01.txt |
2002-03-01
|
00 | (System) | New version available: draft-ietf-sipping-cc-framework-00.txt |