Subject: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 15 Dec 2015 14:56:55 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-clue-framework-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have some minor comments. These should be easy to resolve, and I don't
think any are show-stoppers.

=== Subtantive ===

- Section 3, MCU definition.
Does this need a normative reference to 4353? I'm not sure the definition
can be understood as written without reading it.

- 4, paragraph (5):
The 2119 "OPTIONAL" is vague about what it applies to. Use of companion
protocols? Consider stating this descriptively.

-4, last paragraph:
I don't think the 2119 "REQUIRED" is needed or appropriate here. It
doesn't seem to add anything, and might be interpreted to not  allow 
local policy decisions, etc.

-5, paragraph 5:
The paragraph describes what Media Capture means, but never really
defines what "Encoding" means. (And the definition of "Encoding" in the
terminology section is somewhat circular.)

- 5, 3rd paragraph after Fig 2:
Isn't setting up media transmission a primary effect?

-6, third bullet:
It seems kind of odd to use a  MUST for this,  given that the criteria of
professionally installed is somewhat vague. I think a non-normative
recommendation would make more sense.

- 7.1.1.7, "Note"
Where are these keywords expected to be defined? This seems like an
unfinished section--is it an open to do item?

- 7.1.1.8
Why is this limited (with a MUST) to these defined values? This list
assumes traditional usages. It seems like a more open list would allow
for  innovative usage. For example, a game court, an outdoor space, etc.

- 7.1.1.9:
This section seems to need a normative reference to 5646.

- 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content
that can be carried here?

-7.1.1.11: Is the list of person types exhaustive?

-7.1.1.12: How is priority interpreted? Larger number is higher priority?
Is it strictly a matter of ordering, or does 2N represent twice the
priority of N?

-8, paragraph after Table 5: "Simultaneous Transmission Sets MUST allow
all
   the media Captures in any particular Capture Scene View..."

This seems to reverse the causality. Since the simultaneous transmission
set is based on physical limits, shouldn't it say that any particular CSV
MUST respect the limitations in the simultaneous transmission sets? (Same
for Global View).

- 15, 2nd paragraph:
I think this requires 5239 to be a normative reference.

-15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used unless
the media, which is based on RTP, is secured by other means..."
Is "secured by other means" intended to be the sole exception? If so,
then this might should say MUST ... unless". As defined in 2119, a SHOULD
would allow an implementation to skip the protection for other reasons,
if the implementer was aware of the implications, etc...
Also, should the references to 7201 and 7202 be normative?
 
=== Editorial ===

- Figure 2:
By SDP Media Session you mean an RTP session as described by the basic
SDP right? That is not an SDP session per se.

-5, third paragraph from end:
Please avoid 2119 keywords inside parenthetical phrases. Also, it's
redundant to say implementations of a protocol MUST follow the protocol
:-)

---

From: Christian Groves <[email-masked]>
Date: Fri, 18 Dec 2015 13:57:58 +1100

Hello Ben,

Answers to a few of your comments below:

On 16/12/2015 9:56 AM, Ben Campbell wrote:
> ..snip..
[CNG] The xcard/vcard specification allows these fields to carry base64 
data. Thus a large amount of data could be included. The only other 
field is the KEYS field that carries security key information. We didn't 
think the keys field would be likely to carry the same amount of data as 
the LOGO, PHOTO or sound fields.
> -7.1.1.11: Is the list of person types exhaustive?
[CNG] For defined types yes. Additional types could be registered. It 
also allows user specified non-registered types.
> Is it strictly a matter of ordering, or does 2N represent twice the
[CNG] Just a matter of ordering.

Regards, Christian

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 18 Dec 2015 00:06:33 -0600

Thanks! Comments inline.

Ben.

On 17 Dec 2015, at 20:57, Christian Groves wrote:

> [CNG] The xcard/vcard specification allows these fields to carry 
> base64 data. Thus a large amount of data could be included. The only 
> other field is the KEYS field that carries security key information. 
> We didn't think the keys field would be likely to carry the same 
> amount of data as the LOGO, PHOTO or sound fields.

That seems like a reasonable assumption.

> also allows user specified non-registered types.

Okay.

> [CNG] Just a matter of ordering.

Okay. It would at least be worth mentioning that a higher number means a 
higher priority.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 18 Dec 2015 13:40:44 -0800

About the priority value, the data model document specifies a lower number is higher priority.

I will also respond to some more of the comments on the framework next week.  

Mark

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Friday, December 18, 2015 1:07 AM
> To: Christian Groves
> Cc: The IESG; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with
> COMMENT)
> 
> Thanks! Comments inline.
> 
> Ben.
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 22 Dec 2015 10:16:09 -0800

Hello Ben,
Thanks for the feedback.
I have a few more responses to your comments below.
Mark

> Sent: Tuesday, December 15, 2015 5:57 PM

[Duckworth, Mark] I don't know. Is there any objection to making RFC4353 a normative reference?

> protocols? Consider stating this descriptively.
[Duckworth, Mark] I think it was meant to say the Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Would it be more clear to replace "although it should be stressed that their use in an implementation is OPTIONAL" with "the Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages"?  Or is it supposed to mean something else?

> local policy decisions, etc.
[Duckworth, Mark] How about replacing that clause with "whereas an Endpoint or MCU that accepts it is indicating support for CLUE as specified in this document and its companion documents"?

> terminology section is somewhat circular.)
[Duckworth, Mark] Encodings are further described in section 9.

> Isn't setting up media transmission a primary effect?
[Duckworth, Mark] I think so. How about we remove the word "side"?

> recommendation would make more sense.
[Duckworth, Mark] It does seem odd. I think the working group previously discussed this and decided on using MUST.

> unfinished section--is it an open to do item?
[Duckworth, Mark] The data model document describes the values, and how to extend them.

> for  innovative usage. For example, a game court, an outdoor space, etc.
[Duckworth, Mark] Again, the data model describes how to extend this stuff. Would it be better to say "Possible values are:" ?

[Duckworth, Mark] Okay, is there any objection to changing this from informative to normative?

> Is it strictly a matter of ordering, or does 2N represent twice the
[Duckworth, Mark] See Christian Grove's response.

> MUST respect the limitations in the simultaneous transmission sets? (Same
[Duckworth, Mark] The point isn't about causality, it is just saying the two have to be mutually consistent.

> I think this requires 5239 to be a normative reference.
[Duckworth, Mark] Okay, is there any objection to changing this from informative to normative?

> Also, should the references to 7201 and 7202 be normative?
[Duckworth, Mark] I don't know. Does anybody else have a suggestion about this?

> SDP right? That is not an SDP session per se.
[Duckworth, Mark] I think the diagram should say "BASIC MEDIA SESSION", and "UPDATED MEDIA SESSION". This would be consistent with the text immediately after the figure that says "An initial offer/answer exchange establishes a basic media session..." Any objections?

> redundant to say implementations of a protocol MUST follow the protocol
[Duckworth, Mark] How about change the phrase to " (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds (through a Configure) to the Provider's information)" ?

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 Dec 2015 10:18:58 +1100

Hello Mark,

Some comments below on your replies.

Regards,
Christian

> [Duckworth, Mark] I don't know. Is there any objection to making RFC4353 a normative reference?
[CNG] I'm not sure its appropriate. The definition says "RFC4353-like" 
(doesn't sound particularly normative) and says then indicates that the 
MCU is without a RFC4353. Again its not normatively saying to use it. 
Just because the reference is information doesn't mean a person 
shouldn't read it if they're unfamiliar with it.
> [Duckworth, Mark] It does seem odd. I think the working group previously discussed this and decided on using MUST.
[CNG] The MUST relates to systems that know their physical dimensions 
providing them in an Advertisement rather than relating to 
professionally installed systems. We could strike the "(for example 
professionally installed Telepresence room systems)" if that's causing a 
problem.

> [Duckworth, Mark] Okay, is there any objection to changing this from informative to normative?
[CNG] That's OK for me.
> [Duckworth, Mark] Okay, is there any objection to changing this from informative to normative?
[CNG] OK
> [Duckworth, Mark] I don't know. Does anybody else have a suggestion about this?
[CNG] I think the wording around this was discussed for awhile and 
what's in the framework was the compromise we came up with, i.e. "Its a 
really good idea to secure the media using SRTP-DTLS, but we can't force 
you if you have a reason not to".
> [Duckworth, Mark] I think the diagram should say "BASIC MEDIA SESSION", and "UPDATED MEDIA SESSION". This would be consistent with the text immediately after the figure that says "An initial offer/…
[CNG] OK
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Dec 2015 16:52:43 -0600

Thanks for the response. A few more comments:

Thanks!

Ben.
---------

[...]
> RFC4353 a normative reference?

Please make sure Alissa is onboard with any change here, since 4353 is 
informational. That's not a show stopper, but there are some process 
bits that would need to occur.

An alternative would be to put some more words in the definition, so 
that the term MCU can be fully understood without the dependency.

> [Duckworth, Mark] I think it was meant to say the Media Provider and 
> Media Consumer may use information in CLUE messages to reduce the 
> complexity of SIP offer/answer messages. Would it be more clear to 
> replace "although it should be stressed that their use in an 
> implementation is OPTIONAL" with "the Media Provider and Media 
> Consumer may use information in CLUE messages to reduce the complexity 
> of SIP offer/answer messages"?  Or is it supposed to mean something 
> else?

I think that helps--this doesn't seem like something that needs to use a 
2119 keyword. It might also help to to tie the "such information" that 
is made available via CLUE mechanisms to the desirable mechanism to 
narrow the options. If nothing else, the use of "such information" to 
refer to "a mechanism" was a bit confusing to me.

> [Duckworth, Mark] How about replacing that clause with "whereas an 
> Endpoint or MCU that accepts it is indicating support for CLUE as 
> specified in this document and its companion documents"?

That helps, thanks.

> [Duckworth, Mark] Encodings are further described in section 9.

Even if section 9 defined the term "encoding" (which as far as I can 
tell, it does not.), it would be helpful to have brief definition or 
forward reference in or before section 5.

> [Duckworth, Mark] I think so. How about we remove the word "side"?

That helps, thanks.

> [Duckworth, Mark] It does seem odd. I think the working group 
> previously discussed this and decided on using MUST.

The issue here is that MUST is contingent on a vague condition.  
(Systems that know their dimensions). I think the real condition should 
be something along the line of "Systems intended to convey spatial 
information ...". But that sort of simplifies to "Systems that want to 
provide real-world measurements MUST do so".
> [Duckworth, Mark] The data model document describes the values, and 

A citation of the data model would be helpful in this paragraph.

> [Duckworth, Mark] Again, the data model describes how to extend this 
> stuff.

The problem is, the wording _here_  effectively forbids extension.

> Would it be better to say "Possible values are:" ?

Maybe--or even "Currently defined values [citation] are as follows:"

> the two have to be mutually consistent.

Is it really _mutual_ consistency, or would it make more sense to say 
that any related CSVs MUST be consistent with the simultaneous 
transmission set, if present?

> [Duckworth, Mark] I think the diagram should say "BASIC MEDIA 
> SESSION", and "UPDATED MEDIA SESSION". This would be consistent with 
> the text immediately after the figure that says "An initial 
> offer/answer exchange establishes a basic media session..." Any 
> objections?

I am fine with that, or "... RTP session"

> [Duckworth, Mark] How about change the phrase to " (although the 
> Consumer follows the CLUE protocol and, therefore, gracefully receives 
> and responds (through a Configure) to the Provider's information)" ?

That works, although I might suggest:

" (although the Consumer follows the CLUE protocol and, therefore, 
gracefully receives and responds to the Provider's information using a 
Configure)"

Also does it make sense to say "a Configure" vs "a Configure operation", 
or something to that effect?

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Dec 2015 16:53:03 -0600

Hi, A couple more comments below:

Thanks!

Ben.

On 22 Dec 2015, at 17:18, Christian Groves wrote:

> (doesn't sound particularly normative) and says then indicates that 
> the MCU is without a RFC4353. Again its not normatively saying to use 
> it. Just because the reference is information doesn't mean a person 

It goes on to say "without the [RFC4353] requirement".

The criteria for a normative reference is one that is required to fully 
implement or understand the draft. I agree this one is borderline. If 
you think someone can understand the MCU definition without it well 
enough for the purposes of the document, then I won't push on it.

[...]

> professionally installed Telepresence room systems)" if that's causing 
> a problem.

Please see my related comment to Mark.

[...]

> what's in the framework was the compromise we came up with, i.e. "Its 
> a really good idea to secure the media using SRTP-DTLS, but we can't 
> force you if you have a reason not to".

"If you have a good reason not to" is substantially different than "if 
you are secured by other means".