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(_at_)nostrum(_dot_)com]
Sent: Tuesday, July 16, 2013 6:52 PM
To:
draft-yusef-dispatch-ccmp-indication(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: <gen-art(_at_)ietf(_dot_)org> 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.
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.
[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>"
[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.
[MB] We'll fix that. [/MB]