Subject: [clue] Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 18 Jan 2017 12:48:01 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-clue-rtp-mapping-12: Discuss

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-rtp-mapping/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I plan to ballot "yes" for this, but there's an issue in section 9 that I
think needs to be fixed first:

In the second paragraph, the draft says "CLUE endpoints MUST support RTP/
SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft goes
further by saying that media MUST be secured, and that DTLS-SRTP SHOULD
be used unless the media is secured by some other mechanism. I think that
readers will expect the mapping spec to be authoritative about that sort
of thing. It's likely to be misleading to have it mention the requirement
to support RTP/SAVPF and DTLS-SRTP without also mentioning the MUST be
secured, SHOULD be used requirements. This can easily be fixed by
mentioning the additional requirements and citing the framework.

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

Substantive:

-3: The opening paragraph mentions "Point-to-Point, as well as
Media-Mixing
   mixers, Media- Switching mixers, and Selective Forwarding Middleboxs."
The section goes on to discuss the first two, but doesn't mention the
last two.

-5, paragraph 4: "When the media provider
   switches the MC it sends within an MCC, it MUST send the captureID
   value for the MC just switched into the MCC."

Does MUST send mean MUST send both in the RTP header and as an RTCP SDES
item, as in the previous sentence?

-5, paragraph 5:
It would be helpful to add a sentence or two clarifying the difference
between an MCC that carries multiple MCs at the same time, and one that
switch between MCs, but only carry one at a time.

Editorial:

- 1, 2nd paragraph: Please expand SSRC on first use.

-3, 2nd paragraph: Please expand SDES on first use.
-- "specified in CLUE use case [RFC7205]"
should that say "specified in the CLUE use case document [RFC7205]"?
-- "described using MCC."
missing article ("using an MCC."

-3, third paragraph: "If needed by CLUE
   endpoint,"
Missing article.

-4, 2nd paragraph: s/"slide video"/"side video"

-6, first paragraph: s/"made by"/"made up of"  ; or "comprises"

-9, 2nd paragraph: Please don't use 2119 to describe requirements from
other documents, unless in a direct quote (in quotation marks.)

---

From: Roni Even <[email-masked]>
Date: Thu, 19 Jan 2017 06:51:28 +0000

Hi Ben,
See inline
Roni

> I plan to ballot "yes" for this, but there's an issue in section 9 that I think
> needs to be fixed first:
> 
> readers will expect the mapping spec to be authoritative about that sort of
> thing. It's likely to be misleading to have it mention the requirement to
> support RTP/SAVPF and DTLS-SRTP without also mentioning the MUST be
[Roni Even] You are right, I will use the text from the framework which is the correct text
> -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing
> The section goes on to discuss the first two, but doesn't mention the last
> two.
[Roni Even] There was some text in previous revision but the feedback from the WG was to remove it since it was just repeating text from the topology draft (RFC7667)
> Does MUST send mean MUST send both in the RTP header and as an RTCP
> SDES item, as in the previous sentence?
[Roni Even] Yes, for clarification I can add to the previous sentence "as specified in [RFC7941]"
> switch between MCs, but only carry one at a time.
[Roni Even] I think that it is clear, it is not carrying multiple MCs it "sends a composed stream of multiple MCs". This document does not define what is an MCC so if you do not know what is an MCC you need to read the framework document which is a normative reference. 
> - 1, 2nd paragraph: Please expand SSRC on first use.
[Roni Even] OK
> missing article ("using an MCC."
[Roni Even] OK
> -3, third paragraph: "If needed by CLUE
[Roni Even] OK
> -4, 2nd paragraph: s/"slide video"/"side video"
[Roni Even] It is slide see RFC4796 - but the change is to "slides"
> -6, first paragraph: s/"made by"/"made up of"  ; or "comprises"
[Roni Even] OK
> other documents, unless in a direct quote (in quotation marks.)
[Roni Even] I am not sure what to do, I assume it is about "CLUE endpoints MUST support RTP/
   SAVPF and DTLS-SRTP keying [RFC5764].". We want to say that they MUST support SAVPF and DTLS-SRTP keying . but I think that this text will change based on Magnus request to provide specific security profile

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 Jan 2017 09:06:09 -0600

Hi Roni, thanks for the response. See comments below. I removed sections 
that I think  are resolved.

> which is the correct text

Thanks. I will clear the discuss now, since this is a simple enough fix.

>> last
> [Roni Even] There was some text in previous revision but the feedback 
> from the WG was to remove it since it was just repeating text from the 
> topology draft (RFC7667)

Okay. Something to the effect that "Media-switching mixers and Selective 
Forwarding Middleboxes behave as described in [RFC7677]" towards the end 
of the section would help balance things--but it's not critical one way 
or the other.

[...]

> [Roni Even] I think that it is clear, it is not carrying multiple MCs 
> it "sends a composed stream of multiple MCs". This document does not 
> define what is an MCC so if you do not know what is an MCC you need to 
> read the framework document which is a normative reference.

Your call on this one. I am not sure that people will realize that 
"composed stream of multiple MCs" means one at a time.

[...]

>    SAVPF and DTLS-SRTP keying [RFC5764].". We want to say that they 
> MUST support SAVPF and DTLS-SRTP keying . but I think that this text 
> will change based on Magnus request to provide specific security 
> profile

You can always say that "[RFCXXXX] requires endpoints to..."

---

From: Roni Even <[email-masked]>
Date: Sun, 22 Jan 2017 05:14:23 +0000

Hi Ben,
See inline
Roni

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: יום ה 19 ינואר 2017 17:06
> To: Roni Even
> Cc: The IESG; [email-masked]; Paul Kyzivat; clue-
> [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with
> DISCUSS and COMMENT)
> 
> >> I plan to ballot "yes" for this, but there's an issue in section 9
> >> that I think needs to be fixed first:
> >>
> >> In the second paragraph, the draft says "CLUE endpoints MUST support
> >> RTP/ SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft
> >> goes further by saying that media MUST be secured, and that DTLS-SRTP
> >> SHOULD be used unless the media is secured by some other mechanism. I
> >> think that readers will expect the mapping spec to be authoritative
> >> about that sort of thing. It's likely to be misleading to have it
> >> mention the requirement to support RTP/SAVPF and DTLS-SRTP without
> >> also mentioning the MUST be secured, SHOULD be used requirements.
> >> This can easily be fixed by mentioning the additional requirements
> >> and citing the framework.
> of the section would help balance things--but it's not critical one way or the
> other.
[Roni Even] OK
> 
> [...]
> 
> >>
> >> -5, paragraph 5:
> >> It would be helpful to add a sentence or two clarifying the
> >> difference between an MCC that carries multiple MCs at the same time,
> >> and one that switch between MCs, but only carry one at a time.
> Your call on this one. I am not sure that people will realize that "composed
> stream of multiple MCs" means one at a time.
[Roni Even] I thought that using singular language "stream" and not "streams" means a single stream but since English is a foreign language to me I can change to "one compose stream"
> 
> [...]
> 
> >>
> >> -9, 2nd paragraph: Please don't use 2119 to describe requirements
> >> from other documents, unless in a direct quote (in quotation marks.)
[Roni Even] Thanks, will use your suggestion