Hi Ben,
I apologize for the delay in responding. I had initially missed this review - it either got cached directly with gen-art reviews or the tools alias burped. I'm not on the main IETF list with this email address.
Anyways, thank you very much for your thorough review. Our responses are below [MB].
We have an update underway that addresses your's and other's LC comments. We can forward that to you to preview if you would like.
Regards,
Mary.
-----Original Message-----
From: Ben Campbell [mailto:ben@xxxxxxxxxxx]
Sent: Tuesday, July 16, 2013 6:52 PM
To: draft-yusef-dispatch-ccmp-indication.all@xxxxxxxxxxxxxx
Cc: <gen-art@xxxxxxxx> Team; IETF-Discussion list
Subject: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-yusef-dispatch-ccmp-indication-04
Reviewer: Ben Campbell
Review Date: 2013-07-16
IETF LC End Date: 2013-07-16
Summary: This draft is almost ready for publication as a proposed standard, but I think there are some clarifications needed first.
Major issues:
-- None
Minor issues:
-- Abstract:
Is the abstract current? It says you will discuss pros and cons of a few options, and recommend two. I guess you did recommend two, but the others have been relegated to the appendix. There are no pros and cons listed for the two recommended choices, which seems rather odd.
It also mentions that these are mechanisms to be used by SIP clients. That's not repeated in the introduction. Is this entire draft intended exclusively for SIP clients?
-- 2.
It would be helpful to give more guidance on when one would use one method over the other. 2.1 mentions that it might be an "easier way for a UA that is not interested in the URI".
-- 2.1:
I assume this section is intended to be SIP specific. It would help to say that somewhere, and include a 3261 citation for Call-Info. There are hints that the entire draft is SIP specific in the abstract, but that doesn't get repeated elsewhere. (In fact, the only non-abstract citation to 3261 is in the IANA considerations.)
-- Appendices:
There's more detail and discussion around the discarded methods than the recommended ones in sections 2.X. It would be helpful to have those sections have at least this much explanation.
Further, you say "... beyond those applicable to the mechanisms described within". The mechanisms in sections 2.X are "described within". I assume those aren't the ones you mean here.
-----Original Message-----
From: Ben Campbell [mailto:ben@xxxxxxxxxxx]
Sent: Tuesday, July 16, 2013 6:52 PM
To: draft-yusef-dispatch-ccmp-indication.all@xxxxxxxxxxxxxx
Cc: <gen-art@xxxxxxxx> Team; IETF-Discussion list
Subject: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-yusef-dispatch-ccmp-indication-04
Reviewer: Ben Campbell
Review Date: 2013-07-16
IETF LC End Date: 2013-07-16
Summary: This draft is almost ready for publication as a proposed standard, but I think there are some clarifications needed first.
Major issues:
-- None
Minor issues:
-- Abstract:
Is the abstract current? It says you will discuss pros and cons of a few options, and recommend two. I guess you did recommend two, but the others have been relegated to the appendix. There are no pros and cons listed for the two recommended choices, which seems rather odd.
[MB] You are correct, it's slightly out of date. We should just update this to reflect that this document defines two mechanisms. And, we'll add additional text to the selected solutions explaining the motivation for choosing those. So, we suggest the following change (also removing the references as this document actually doesn't update any normative behavior in either 3261 or 4575):
OLD:
This document describes a few options to address the above limitation with the pros and cons for each approach, and recommends two to be used depending on the need of the UA. The first approach uses the Call-Info header and as a result this document updates RFC 3261 [RFC3261]. The second approach defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package, and as a result this document updates RFC 4575 [RFC4575].
NEW:
This document describes two mechanisms, depending upon the need of the UA, to address the above limitation. The first mechanism uses the Call-Info header, and the second mechanism defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package.
[/MB]
It also mentions that these are mechanisms to be used by SIP clients. That's not repeated in the introduction. Is this entire draft intended exclusively for SIP clients?
[MB] We can fix that. The intent is for SIP clients to use this, in particular since the Call-Info header is SIP specific. The service-uri that is being used could also be in the XCON-Data. But, there would be no reason for an XCON client to care about that URI since they are using XCON methods to create conferences, the URI they have for communicating with the conference server MUST be an XCON URI. We propose adding text to the Intro something like the following:
OLD:
The CCMP protocol defines a way for a client to determine if a conference control server supports CCMP, but it does not define a way for a client to determine if a conference focus supports CCMP. This document defines two mechanisms to address the above limitation. Other mechanisms that we considered are listed in Appendix A.
NEW:
The CCMP defines a way for an XCON-aware client to discover whether a conference control server supports CCMP. However, it does not define a way for a SIP client involved in a conference to determine if the conference focus [RFC4353] supports CCMP. Knowing that a focus supports CCMP would allow a SIP client (that is also XCON-aware) that joins a conference using SIP based conferencing [RFC4579] to also register for the XCON conference event package [RFC6502] and take advantage of CCMP operations on the conference.
This document describes two options to address the above limitation, depending on the need of the UA. The first option uses the Call-Info [RFC3261] header, and the second option defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package [RFC4575]. Other options considered are described in Appendix A.
[/MB]
-- 2.
It would be helpful to give more guidance on when one would use one method over the other. 2.1 mentions that it might be an "easier way for a UA that is not interested in the URI".
[MB] Would the following address this concern?
OLD:
This section defines the mechanisms that can be use to discover that a focus supports CCMP.
NEW:
This section defines two mechanisms that can be used by a SIP UA to
discover whether the conference which a client has joined, per the
SIP signaling procedures defined in [RFC4579], supports CCMP.
Specifically, the mechanisms allow the client to know that the URI
representing the conference focus, as defined in [RFC4579], is
an XCON-URI as defined in [RFC 6501].
I'm not sure what it means for a UA to be interested or not interested in a URI--maybe you mean "A UA that does not otherwise need to parse the URI"?
[MB] Correct. We can re-word that paragraph something like the following.
OLD:
While the XCON-URI by itself should be enough to indicate that the focus supports CCMP, the purpose with a value of 'ccmp' provides a easier way for a UA that is not interested in the URI to discover that the focus supports CCMP without parsing the URI.
NEW:
While the XCON-URI by itself should be enough to indicate that the
conference focus supports CCMP, the purpose parameter with a
value of 'ccmp' provides an easier way for a UA,
that does not use the conference event package, to discover that
the conference focus supports CCMP, without parsing the URI.
[/MB]
-- 2.1:
I assume this section is intended to be SIP specific. It would help to say that somewhere, and include a 3261 citation for Call-Info. There are hints that the entire draft is SIP specific in the abstract, but that doesn't get repeated elsewhere. (In fact, the only non-abstract citation to 3261 is in the IANA considerations.)
[MB] Agreed. [/MB]
Also, the section seems underspecified. It says the ccmp value can go in any INVITE, INVITE response, or OPTIONS response. It would help to describe how UAs would actually use it. Simply naming the actors would help; as it is, they are obscured by the passive voice in "... can be used...", and the reader is left to infer the intent based on his knowledge of SIP.
[MB] Sure. The gist of it is that with this information, a UA can then make use of additional functionality as specified in the CCMP specification. We should be explicit - it's kindof hinted in the introduction, but never stated outright. We can add text something like the following to the end of section 2.1.
Also, the section seems underspecified. It says the ccmp value can go in any INVITE, INVITE response, or OPTIONS response. It would help to describe how UAs would actually use it. Simply naming the actors would help; as it is, they are obscured by the passive voice in "... can be used...", and the reader is left to infer the intent based on his knowledge of SIP.
[MB] Sure. The gist of it is that with this information, a UA can then make use of additional functionality as specified in the CCMP specification. We should be explicit - it's kindof hinted in the introduction, but never stated outright. We can add text something like the following to the end of section 2.1.
NEW:
This approach would be suitable for a UA, like an application server
that acts as a B2BUA, that is interested in discovering that a
conference focus supports CCMP but does not use the XCON
conference event package [RFC 6502].
In this case the application could use the OPTIONS request
and discover the CCMP support from the response.
This approach would also be suitable for a conference focus that
initiates an INVITE request to a SIP UA to add a participant to a
conference, as it would allow the conference focus to indicate that
it supports CCMP with the INVITE request sent to the UA.
The pros of this approach is the ability to discover that a
conference focus supports CCMP without subscribing to the XCON event
package [RFC 6502]. The cons is the need, in some cases,
for an extra request,
i.e. OPTIONS request, to discover that a conference focus supports
CCMP.
[/MB]
--2.2:
I assume this section is _not_ necessarily SIP specific. If that's the intent, it would be helpful to say so.
I assume this section is _not_ necessarily SIP specific. If that's the intent, it would be helpful to say so.
[MB] The expectation would be that a SIP client (that is also XCON-aware) would be most interested in this information, as noted above, they would then know that the focus supports CCMP and then the client can use CCMP methods if they have applications that use such (e.g., UIs that provide rosters, allow them to see all the sorts of conferences supported by that server, etc.). We can add text something like the following (also addressing the motivations and pros/cons for this option:
NEW:
The pros of this approach is the use of an existing mechanism for
extending the <purpose> field of the <service-uris> element in the
conferencing event package [RFC4353]. The con
is the requirement that the client subscribe for the conference event
package.
This approach would be suitable for a SIP UA that would typically
subscribe to the conference event package. Knowing that a conference
supports CCMP allows a SIP UA that is XCON-aware to make use of the
CCMP operations and allows them to subscribe to the XCON event
package [6502] to get additional information related to the conference.
[/MB]
-- Appendices:
There's more detail and discussion around the discarded methods than the recommended ones in sections 2.X. It would be helpful to have those sections have at least this much explanation.
[MB] Hopefully, the text proposed above addresses this concern.[/MB]
-- section 3:
You say this draft introduces no additional security considerations. Statements like that turn out false more often than not. For example, is there no security consideration created by having a SIP UA identify itself as a conference focus in an INVITE? (Even if the answer is no, it's helpful to have text along the line of "we thought about this and decided it was not a consideration due <reasons>"
-- section 3:
You say this draft introduces no additional security considerations. Statements like that turn out false more often than not. For example, is there no security consideration created by having a SIP UA identify itself as a conference focus in an INVITE? (Even if the answer is no, it's helpful to have text along the line of "we thought about this and decided it was not a consideration due <reasons>"
[MB] This mechanism doesn't introduce anything new since the existing SIP signaling for conferencing already provides the same functionality. We can change the text to something like the following:
OLD:
These proposals introduce no additional security considerations beyond those which are applicable to each of the mechanisms described herein.
NEW:
The solution options described in this document introduce no additional security considerations, as they define no new headers or data elements and are reusing existing headers and data elements and thus no new security threats are introduced.
[/MB]
Further, you say "... beyond those applicable to the mechanisms described within". The mechanisms in sections 2.X are "described within". I assume those aren't the ones you mean here.
[MB] I think you are referring to the text that says "herein" (i.e., last sentence). What that text is intended to say is that the mechanisms identified in this draft are existing mechanisms, thus the mechanisms themselves introduce no new security requirements. For example, Service-URIs - this is defined in the XCON data model and thus would be protected in the same way as the data. And, then Call-Info is an existing SIP header and is protected by the existing SIP security mechanisms. We can certainly write some explicit text for this if you think that's warranted. [/MB]
Nits/editorial comments:
-- Abstract:
The abstract should not contain citations. It will be published in multiple places without the rest of the document, orphaning the citations.
Nits/editorial comments:
-- Abstract:
The abstract should not contain citations. It will be published in multiple places without the rest of the document, orphaning the citations.
[MB] We'll fix that. [/MB]