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

[Mary Barnes <[e-mail]>]

HI Michael,

Comments inline below [MB].

Thanks,
Mary.


On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer <[e-mail]
> wrote:

> Requirement 15 is written in language that is more vague than the other
> requirements.
>
> I would argue that what it says is already covered by the other
> requirements and could be removed with no harm.
>
[MB] You have a reasonable point, but I would suggest that leaving this
requirement also causes no harm. It's been in the document since the -00 WG
version.  It was added as REQMT-16 in the individual -03.
Please keep in mind that this document has completed IETF Last Call (we had
consensus on this document in the WG a while back), so there would have to
an extremely compelling reason and WG consensus to remove.
[/MB]

>
>
> For example Reqts 2 and 4 seem to say that there will be multiple devices
> involved in creating a “presentation”.
>
> And 5-9 seem to cover various interop issues with different numbers and
> types of devices.
>
> Also, presentation is not defined.
>
[MB] Given that we have an entire use case dedication to "presentation" I
don't think the term needs to be defined in this document. However, it
would probably be good to add the reference to the Presentation use case
for REQMT-15 as we have done for some others.   [/MB]

>
>
> Mike
>
>
>
>
>
> *From:* clue [mailto:[e-mail]] *On Behalf Of *Duckworth, Mark
> *Sent:* Monday, December 02, 2013 3:11 PM
> *To:* Stephen Botzko; Mary Barnes
>
> *Cc:* [e-mail];
> [e-mail]
> *Subject:* Re: [clue] Gen-ART review of
> draft-ietf-clue-telepresence-requirements-06.txt
>
>
>
> Comments inline.
>
> Mark Duckworth
>
>
>
> *From:* clue [mailto:[e-mail]] *On Behalf Of *Stephen Botzko
> *Sent:* Wednesday, November 27, 2013 5:28 PM
> *To:* Mary Barnes
> *Cc:* [e-mail];
> [e-mail]
> *Subject:* Re: [clue] Gen-ART review of
> draft-ietf-clue-telepresence-requirements-06.txt
>
>
>
> Dan - thanks so much for reviewing this.
>
> Comments are in-line
>
>
>
> Stephen Botzko
>
>
>
> On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <[e-mail]>
> wrote:
>
> On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[e-mail]>
> wrote:
>
> Authors,
>
> What do you think of these comments?
> If you aren't in agreement with all of them, then we should have a dialog
> with Dan about them.
>
> If in agreement, then lets discuss what changes are appropriate.
>
> More inline.
>
>
>
> On 11/21/13 7:08 AM, Romascanu, Dan (Dan) 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.
>
>
>
> This seems like a reasonable point to me. Is there a more stable reference
> we can use? If not, can we just define these terms in the document?
>
> [MB] I'm almost of a mind to just remove those definitions.  The consensus
> was that the terms should be qualified when they are used and the framework
> does an excellent job of defining more precise terms that properly qualify
> "left" and "right" and differentiate from stage right, etc. as appropriate.
>  We use "left" and "right" in one place in this requirements document and I
> think the use is general enough that we don't need a definition (in this
> document).   The wikipedia reference has been in the document since day 1
> as a WG document (it was added in -03 of the individual document).   The
> discussions around "left"/"right" on the list were in the context of the
> definitions document and again, consensus was that the terms should be
> qualified (as they are in the framework), thus I don't think the current
> definitions serve any value. [/MB]
>
> [SB] I agree with Mary that these definitions can simply be removed.
> [/SB]
>
> *[Duckworth, Mark] I agree too.*
>
>
>
> 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
>
>
>
> We have had our own concerns about this. I think we want to say
> *something* but its unclear to me exactly what. Perhaps we could focus on
> what we want to use this for, and explicitly leave details of what it is
> for the FW.
>
> [MB] Can you point to the threads of discussion where you feel this
> concern with this phrasing has been raised?   There were certainly concerns
> raised about those requirements (i.e., 3D), but I'm not reading this as
> Dan's concern.   My understanding is that the word "extent" is used in the
> context of video imagery from the perspective of the camera - i.e., the
> "angular extent" or something like that.  I think we should replace the
> word "extent" with something more specific.  Anyone have a suggestion?
>
> [SB]
>
> The intent of REQMT-1d was to say that CLUE needs to identify the area
> that each camera captured in the room - so it would be clear how views from
> different camera related to each other, and also if there were any gaps,
> etc.  Identifying the scale of the view is related, but is captured
> concisely in requirement 6.  Proper rendering in a multi-camera
> telepresence system requires this knowledge - today it is generally
> hard-wired into the room design.  But that doesn't result in an
> interoperable experience, and it needs to be signaled if you want to get
> appropriate rendering between rooms with disparate designs.
>
>
>
> For audio [REQMT-2d], there is an analogous need to identify the area of
> coverage of a microphone.  The need to correlate the audio and the video is
> related, but is captured separately in REQMT-3.
>
>
>
> The discussions on the list related to audio and video area of coverage
> were about whether the model in the framework was adequate.  Personally I
> believe it is.  But what really matters here is whether we are clearly
> stating the *requirement*, not the adequacy of the proposed
> specifications.
>
> One alternative term is "area of coverage", which is commonly used in
> surveillance applications to describe a similar concept.  If people think
> that might be confused with radio coverage (e.g. an LTE coverage map) we
> could draft a definition and add it to section 3.
>
> [/SB]
>
> *[Duckworth, Mark] I agree with Steve about the intent.  I agree “area of
> coverage” is a better term than “extent” for this purpose.*
>
>
>
>
>
> And, note these requirements were added based on discussion at IETF-82:
>
> http://www.ietf.org/proceedings/82/slides/clue-1.pdf
>
>
>
>  [/MB]
>
>         Thanks,
>         Paul
>
>
>
> 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.
>
> [SB] The intent was to simply state that the solution must not prevent
> direct interoperability with SIP devices (either phone or
> videoconferencing) - without the need for a middlebox to convert signaling
> (as would be required with rtcweb for instance).   The limitation is simply
> that telepresence extensions can't be used.  I do not see a need to
> describe the limitations of existing SIP systems in this requirements
> document.
>
> Suggested text that makes the requirement more clear would be helpful.
> This is a bit tricky to word, since SIP itself has no requirement that says
> SIP endpoints must interoperate with each other w/o middleboxes to assist.
> And in fact they often don't.  We could alternatively drop the requirement.
>
> [/SB]
>
> *[Duckworth, Mark] I agree with Steve about the intent.  How about
> something like “The solution must make it possible for devices that support
> CLUE to interoperate directly with SIP devices that do not support CLUE” ?*
>
>
> 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
>
> [SB]At this point I am not certain either.  We might have meant that
> different use cases had different placements, number, and size of
> presentations. Or that existing telepresence systems handle presentations
> in different ways.
>
> It is not worded as a clear requirement, and it says "can", not "should"
> or "must".  My recommendation is to delete that bullet.
> [/SB]
>
> *[Duckworth, Mark] I think we meant this:*
>
>             * - There can be multiple simultaneous presentation media
> streams*
>
>             *- Presentation media streams can be spatially related to
> each other*
>
>
>
> 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?
>
> [SB] What is meant is extending the specifications for new functionality
> in the future.  I suggest that we re-word to "New protocols developed for
> the solution MUST include extensibility mechanisms"
> [/SB]
>
> *[Duckworth, Mark] Steve’s suggestion is more clear.*
>
>
>
> 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.
>
> [SB] I am not sure if the CLUE WG has a recommended order for reading the
> various documents.  Personally I would recommend that people start with the
> use cases.  In any event, I think the document purpose is properly captured
> in the abstract - it is not intended to be an introduction to telepresence
> generally or as an orientation to CLUE specifications.
> [/SB]
>
> *[Duckworth, Mark] I agree.*
>
>
>
> 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.
>
> [SB] I agree.  We should also use "specifications", since current plans
> call for more than one standards-track RFC
> [/SB]
>
> *[Duckworth, Mark] I agree*
>
>
> 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.
>
> [SB] I don't see it as vague - it pretty clearly says that only the
> mechanism needs to be secure.  I think you are saying that the security
> section might be incomplete.
>
> Current protocol designs do not include explicit details about equipment,
> and I see nothing in the requirements that suggest otherwise.  Some
> requirements do require transport of information that can be used infer
> room dimensions (at least of the visible portion of the room) and the
> audio/video coverage within it.  Can you identify threats that might use
> that information?
>
> Of course each specification includes its own Security Considerations.
> Obviously we will address any security review comments in this one.
> [/SB].
>
>
> Regards,
>
> Dan
>
>
>