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

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 2 Dec 2013 12:11:27 -0800

Comments inline.
Mark Duckworth

From: clue [mailto:[email-masked]] On Behalf Of Stephen Botzko
Sent: Wednesday, November 27, 2013 5:28 PM
To: Mary Barnes
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> 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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 2 Dec 2013 20:34:04 +0000

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.

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.

Mike

From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: Monday, December 02, 2013 3:11 PM
To: Stephen Botzko; Mary Barnes
Cc: [email-masked];
[email-masked]
Subject: Re: [clue] Gen-ART review of
draft-ietf-clue-telepresence-requirements-06.txt

Comments inline.

Mark Duckworth

From: clue [mailto:[email-masked]] On Behalf Of Stephen Botzko
Sent: Wednesday, November 27, 2013 5:28 PM
To: Mary Barnes
Cc: [email-masked];
[email-masked]
Subject: Re: [clue] Gen-ART review of
draft-ietf-clue-telepresence-requirements-06.txt

Comments are in-line

Stephen Botzko

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <[email-masked]>
wrote:

On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[email-masked]>
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.

More inline.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you
may receive.

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] 

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.

 [/MB]

        Thanks,
        Paul

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" ?

[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]

            - Presentation media streams can be spatially related to each
other

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] 

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]

  These

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] 

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Dec 2013 11:37:20 +0000

Minor clarification of my comment on a minor issue. What needs definition here is the term CLUE itself. The document talks about 'CLUE will not dictate', 'architecture for CLUE', 'CLUE enables', etc., but what is CLUE? (someone may wonder)

Regards,

Dan

Minor issues:

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 5 Dec 2013 09:53:03 -0500

>>>The document talks about ‘CLUE will not dictate’, ‘architecture for
CLUE’, ‘CLUE enables’, etc., but what is CLUE? (someone may wonder)
I imagine other WGs have run into this with their requirements.  How is it
normally handled?

Stephen

On Tue, Dec 3, 2013 at 6:37 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

>  Minor clarification of my comment on a minor issue. What needs
> definition here is the term CLUE itself. The document talks about ‘CLUE
> will not dictate’, ‘architecture for CLUE’, ‘CLUE enables’, etc., but what
> is CLUE? (someone may wonder)
>
>
>
> Regards,
>
>
>
> Dan
>
>
>
>
>
>
>
>
>
>
> 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]
>
>
>
>
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 5 Dec 2013 10:15:40 -0600

We can expand CLUE on first usage and then qualify that the use of the term
CLUE in this document is referring to the solutions developed to enable
support for CLUE.

It may be most appropriate actually to introduce the term CLUE in the
abstract. Perhaps something like:
OLD
    This memo discusses the requirements for specifications that enable

   telepresence interoperability, by describing the relationship between
   multiple RTP streams.  In addition, the problem statement and related
   definitions are also covered herein.

NEW

   This memo discusses the requirements for specifications, that enable

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

   In addition, the problem statement and related

   definitions are also covered herein.

Mary

---

From: Mary Barnes <[email-masked]>
Date: Thu, 5 Dec 2013 13:09:06 -0600

HI Michael,

Comments inline below [MB].

Thanks,
Mary.

On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer <[email-masked]

> 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]

> involved in creating a “presentation”.
>
[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:[email-masked]] *On Behalf Of *Duckworth, Mark
> *Sent:* Monday, December 02, 2013 3:11 PM
> *To:* Stephen Botzko; Mary Barnes
>
> *Cc:* [email-masked];
> [email-masked]
> *Subject:* Re: [clue] Gen-ART review of
> *From:* clue [mailto:[email-masked]] *On Behalf Of *Stephen Botzko
> *Sent:* Wednesday, November 27, 2013 5:28 PM
> *To:* Mary Barnes
> *Cc:* [email-masked];
> [email-masked]
> *Subject:* Re: [clue] Gen-ART review of
> 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
> *[Duckworth, Mark] I agree too.*
>
>
>
> 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
> 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.
>
>
>
> 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.
>
> *[Duckworth, Mark] I agree with Steve about the intent.  I agree “area of
> coverage” is a better term than “extent” for this purpose.*
>
>
>
>
>
> 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” ?*
>
>
> 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*
>
>
>
> 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:
>
> *[Duckworth, Mark] I agree.*
>
>
>
> 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.
>
> 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?
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 5 Dec 2013 19:36:12 +0000

Mary,

What is the process here?  

The earlier comments imply that further changes may be needed and possible.

Now, you say no changes are possible?  

What was the point of posting on the email list?

Or, is it only comments from the anointed?

The anointed are free to use my comments how they like by the way.  :)

I would also argue since the text is redundant, 

it is editorial change to remove to make the document clearer.

Mike

From: Mary Barnes [mailto:[email-masked]] 
Sent: Thursday, December 05, 2013 2:09 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [clue] Gen-ART review of
draft-ietf-clue-telepresence-requirements-06.txt

HI Michael,

Thanks,

Mary.

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

[/MB]

[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

Comments inline.

Mark Duckworth

Comments are in-line

Stephen Botzko

Authors,

More inline.

Major issues:

[SB]

[/SB]

 

 [/MB]

        Thanks,
        Paul

[/SB]

Minor issues:

  These

Regards,

Dan

---

From: Mary Barnes <[email-masked]>
Date: Thu, 5 Dec 2013 13:57:18 -0600

Responses below [MB].

Mary.

On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer <[email-masked]

> The earlier comments imply that further changes may be needed and possible.
[MB] The process is standard IETF document progression process:
http://www.ietf.org/about/process-docs.html

The WG completes WGLC (which was completed for this doc on Sunday, Sept.
29th).  Then the document shepherd completes the write-up, reflecting that
the WG believes the document is ready to progress - that was done on
October 24th, 2013.  The AD then reviews the write-up and decides whether
the doc is ready for IETF Last Call.  The IETF Last Call for this document
started on October 30th and  lasted 4 weeks due to overlap with the IETF
meeting. Note, you can find all this information in the data tracker:
http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/
They've added a lot of nice new features that you might find handy,
including a link to Search the mailing list for any threads related to this
document as well as the History of it's progression through the IETF
process.

This email thread and any suggested changes are based upon the Gen-ART
review by Dan Romascanu during IETF Last Call.  We brought the discussion
to the WG mailing list since the changes are slightly more than editorial
and we cannot make the changes without ensuring the WG is okay with them.

Your comments arrived after IETF Last Call completed.  Certainly, if
someone finds something in a WG document that is terribly broken, they
should be brought to the attention of the WG, but I don't think this
comment fits in that category. [/MB]

[MB] What I'm saying is that this change does not seem necessary.  It
doesn't add clarity and the requirement as it is doesn't takeaway from the
document.  I haven't dug back through email threads to see why this
requirement was added in the individual -03 - you might want to do that and
you might find visiting the email archives related to the development of
this document in the WG quite informative.   Everyone in the WG had
*plenty* of time to review this WG document over the past 2.5 years (the
-03 version where this requirement first appeared was published in June of
2011.  After a document leaves the WG, one should always be conservative
with regards to changes. [/MB]

> What was the point of posting on the email list?
[MB] See Above. [/MB]

> Or, is it only comments from the anointed?
[MB] See above - the comments being considered are those that were sent
during IETF Last Call. Your comments came after the completion of IETF Last
Call. Typically comments that late in the cycle are not always incorporated
unless there is a very compelling reason.  I personally don't see that
there is here. [/MB]

> The anointed are free to use my comments how they like by the way.  :)
[MB] And, that would the WG - if the WG decides that this change should be
made after IETF Last Call - as noted,  typically WGs want to be
conservative about changes at this stage unless there is a really
compelling reason. [/MB]

> I would also argue since the text is redundant,
[MB] I don't at all see it as entirely redundant.  It might be implying the
same requirement, but it is also clearly spelling out requirements explicit
to presentation, which are also related to requirements for other media.
[/MB]

> it is editorial change to remove to make the document clearer.
[MB] I actually believe it makes the document clearer by being very
explicit as to the requirements associated with the presentation use case.
[/MB]

>
>
> Mike
>
>
>
>
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* Thursday, December 05, 2013 2:09 PM
> *To:* Michael Hammer
> *Cc:* [email-masked]; [email-masked];
> On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer <
> [email-masked]> wrote:
>
> 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]
>
>
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 5 Dec 2013 20:19:45 +0000

No problem.

It was posted to the list.

I provided my two cents.

You can crank through the process as you see fit.

Mike

Sent: Thursday, December 05, 2013 2:57 PM

Responses below [MB].

Mary.

On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer
<[email-masked]> wrote:

Mary,

The WG completes WGLC (which was completed for this doc on Sunday, Sept.
29th).  Then the document shepherd completes the write-up, reflecting that
the WG believes the document is ready to progress - that was done on October
24th, 2013.  The AD then reviews the write-up and decides whether the doc is
ready for IETF Last Call.  The IETF Last Call for this document started on
October 30th and  lasted 4 weeks due to overlap with the IETF meeting. Note,
you can find all this information in the data tracker: 

This email thread and any suggested changes are based upon the Gen-ART
review by Dan Romascanu during IETF Last Call.  We brought the discussion to
the WG mailing list since the changes are slightly more than editorial and
we cannot make the changes without ensuring the WG is okay with them.

Your comments arrived after IETF Last Call completed.  Certainly, if someone
finds something in a WG document that is terribly broken, they should be
brought to the attention of the WG, but I don't think this comment fits in
that category. [/MB]

[MB] What I'm saying is that this change does not seem necessary.  It
doesn't add clarity and the requirement as it is doesn't takeaway from the
document.  I haven't dug back through email threads to see why this
requirement was added in the individual -03 - you might want to do that and
you might find visiting the email archives related to the development of
this document in the WG quite informative.   Everyone in the WG had *plenty*
of time to review this WG document over the past 2.5 years (the -03 version
where this requirement first appeared was published in June of 2011.  After
a document leaves the WG, one should always be conservative with regards to
changes. [/MB] 

[MB] See Above. [/MB] 

[MB] See above - the comments being considered are those that were sent
during IETF Last Call. Your comments came after the completion of IETF Last
Call. Typically comments that late in the cycle are not always incorporated
unless there is a very compelling reason.  I personally don't see that there
is here. [/MB] 

[MB] And, that would the WG - if the WG decides that this change should be
made after IETF Last Call - as noted,  typically WGs want to be conservative
about changes at this stage unless there is a really compelling reason.
[/MB] 

[MB] I actually believe it makes the document clearer by being very explicit
as to the requirements associated with the presentation use case. [/MB] 

Mike

HI Michael,

Thanks,

Mary.

[/MB]

Mike

Comments inline.

Mark Duckworth

Comments are in-line

Stephen Botzko

Authors,

More inline.

Major issues:

[SB]

[/SB]

 

 [/MB]

        Thanks,
        Paul

[/SB]

Minor issues:

  These

Regards,

Dan

---

From: Mary Barnes <[email-masked]>
Date: Fri, 6 Dec 2013 15:46:55 -0600

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.

> specification in CLUE will use the terms defined here it is not clear which
[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]

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

> 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]

> *  There can be variation in placement, number and size of
[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]

> 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]

> 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:

   multiple RTP streams.

NEW

[/MB]

> is meant by the 'solution' is the definition of the protocol, not the
[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]

> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 8 Dec 2013 12:16:50 +0000

FWIW - with the proposed changes below I am a happy Gen-ART reviewer and consider all my comments addressed.

Thanks and Regards,

Dan

From: clue [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Friday, December 06, 2013 11:47 PM
To: CLUE
Cc: [email-masked]
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt

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) <[email-masked]<mailto:[email-masked]>> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

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]

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]

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]

*  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:

              *  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.

[/MB]

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

[/MB]

Minor issues:

OLD:

   multiple RTP streams.

NEW

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

[/MB]

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]

Regards,

Dan

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue