Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt

[Mary Barnes <[e-mail]>]

CLUE WG,

Below, I've summarized changes based on Dan's comments.  I've tried to
incorporate from the various threads of discussion and in some cases I've
proposed slightly different text.  I plan to submit an update with these
changes early next week, so please comment ASAP if you see any issues.

Thanks,
Mary.


On Thu, Nov 21, 2013 at 9:08 AM, Romascanu, Dan (Dan) <[e-mail]>wrote:

> 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-ietf-clue-telepresence-requirements-06.txt
> Reviewer: Dan Romascanu
> Review Date: 11/21/13
> IETF LC End Date: 11/27/13
> IESG Telechat date: (if known)
>
> Summary: It's a good and well written document, almost ready, but a number
> of issues should be clarified before approval.
>
> Major issues:
>
> 1. The definitions of Left and Right in Section 3 use an entry article in
> Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of
> Wikipedia articles (subject to change, subject to attacks) as references,
> and I also believe that the current definitions (@11/21/13, US morning
> hours) are ambiguous. Actually the Wikipedia article does not include
> definitions for Left and Right, and speaks about 'house left' (equal to
> 'stage right') and 'house right' (equal to 'stage left'). If another
> specification in CLUE will use the terms defined here it is not clear which
> one is meant.
>
[MB] These definitions will be deleted, as they're not needed in the
context of the requirements and the use of the terms in the other CLUE WG
documents is within a context specific enough that the terms don't need to
be redefined from their normal English language usage. [/MB]

>
> 2. In REQMT-1d it is not clear what 'the extent of individual video
> captures' means
>
> 3. In REQMT-2d it is not clear what 'the extent of individual audio
> captures' means
>
[MB] The proposal for these two issues is to change "extent" to "area of
coverage". [/MB]


>
> 4. REQMT-10: The solution MUST make it possible for endpoints without
>               support for telepresence extensions to participate in a
>               telepresence session with those that do.
>
> More clarity is needed to explain what level of participation in a session
> (and what limitations) are expected from endpoints that do not support the
> telepresence extensions. I assume there are limitations, otherwise
> extensions would not be needed.
>
[MB] As mentioned on the mailing list we don't believe it's necessary to
define all the limits in the requirements.  Basically, we're trying to say
that an existing SIP endpoint that supports a single audio and video stream
should be able to establish a basic audio & video session with a CLUE
endpoint.  This is no different than existing video systems, for example,
that still allow a participant to join in audio only mode.  It's also
probably best to word the requirement from the perspective of the endpoint
that supports telepresence extensions (since that's who these requirements
apply to). Note, that the WG plans to address (and already has some text in
solution documents) various scenarios involving "non-CLUE enabled"
endpoints.  We also have an issue in the tracker.

I think rewording this requirement something like the following should be
sufficient:

REQMT-10:   The solution MUST ensure that endpoints that support
telepresence
extensions can establish a session with a SIP endpoint that does not
support the telepresence extensions.  For example, in the case of a SIP
endpoint that supports a single audio and a single video stream, an
endpoint that supports the telepresence extensions would setup a session
with a single audio and single video stream using existing SIP and SDP
protocol mechanisms.

[/MB]

>
> 5. REQMT-15 (last bullet): I could not really figure out what is meant here
>
> *  There can be variation in placement, number and size of
>                  presentations
>
[MB] I think this whole requirement can be slightly reworded something like
the following, with that last bullet being made more specific and
normative.  I think this wording is better as each of these bullets could
now be read as a separate requirement:

REQMT-15:  The solution MUST provide mechanisms to support the following:

              *  Presentations with different media sources

              *  Presentations for which the media streams are visible
to all endpoints

              *  Multiple, simultaneous presentation media streams,
including presentation media streams that are spatially related to
each other.

   Use case is presentation.


[/MB]


> 6. REQMT-16:  The solution MUST include extensibility mechanisms.
>
> What 'extensibility' is meant here? Extending the telepresence sessions,
> or extending the specifications for new functionality in the future?
>
[MB] Suggestion is to reword this as:

REQMT-16:  The specification of any new protocols for the solution MUST
provide extensibility mechanisms.

[/MB]

>
>
> Minor issues:
>
> 1. If this is the first and basic document to be read by somebody who
> starts to browse through the CLUE specifications, it would be good to
> define or expand some place in the introduction what CLUE is.
>
[MB] The proposal is to expand the use of CLUE in the abstract as follows:

OLD:
   This memo discusses the requirements for specifications that enable

   telepresence interoperability, by describing the relationship between
   multiple RTP streams.

NEW

   This memo discusses the requirements for specifications, that enable

   telepresence interoperability by describing behaviors and protocols
for Controlling   Multiple Streams for Telepresence (CLUE).


[/MB]

>
> 2. In the Introduction Section I see:
>
> >  These
>    requirements are for the specification, they are not requirements on
>    the telepresence systems implementing the solution/protocol that will
>    be specified.
>
> But then all requirements in section 5 start by 'The solution ...' which
> is ambiguous. It would be good to mention (again) in section 5 that by what
> is meant by the 'solution' is the definition of the protocol, not the
> implementation.
>
[MB] Agreed.  We'll add the following sentence right before the last
sentence in paragraph 1 in section 5.

"Note, the term "solution" is used in these requirements to mean the
protocol specifications, including extensions to existing protocols as well
as any new protocols,  developed to support the use cases."

[/MB]

>
> 3. I will defer to the Security Review to comment whether REQMT-18 is
> enough from a security point of view - especially as the information about
> media captures may include explicitly or implicitly details about equipment
> on each site, etc. To me it seems a little bit too vague.
>
> Regards,
>
> Dan
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>