Subject: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06

From: Robert Sparks <[email-masked]>
Date: Thu, 14 May 2015 14:21:55 -0500

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-avtext-rtp-grouping-taxonomy-06
Reviewer: Robert Sparks
Review Date: 14 May 2015
IETF LC End Date: 18 May 2015
IESG Telechat date: Not currently scheduled

Summary: This draft is on the right track, but has open issues.

This draft has clearly helped progress conversations across several 
working groups,
particularly around grouping streams. It's good that it was put 
together. I worry
a little about the timing of publishing it as an RFC now (is that driven 
by other
documents wanting to reference this normatively?) rather than keeping 
most of it
as a living document somewhere. That said, I don't think publishing it 
as an RFC
is going to hurt anything, but since future readers aren't going to be 
focusing
so hard on the current conversations, I want to check on a couple of things:

Major issues:

I'm surprised that there is no mention of how SRTP fits into the 
vocabulary this
document builds. Would it be a mistake for someone to think of SRTP as what
this document calls a transformation? Are there any consequences of 
using SRTP
on one or more of the streams being associated that impact how you would 
talk about
the association? (There are certainly consequences about which elements 
can see
into the various streams).

Minor issues:

The title says this document is about grouping. While conversations around
grouping motivated the document, the text goes well beyond describing 
grouping.
The abstract and introduction don't contain the word 'grouping'; 
instead, they cast
the document as being about describing sources, but the document goes 
well beyond
a taxonomy of sources. It suggest reworking these sections to reflect 
what the
document ended up being.

Nits/editorial comments:

In more-or-less document order:

The document call out the possibility of loops, but no discussion shows 
the use
of one. What motivated calling out the possibility?

The use of "Characteristics" is inconsistent across the sections. Sometimes
the bullets list things that could be used to classify a thing, and 
sometimes
they appear to be a set of observations about the thing. It's hard to tell
whether the lists are intended to be complete or exclusive, depending on the
section. Perhaps these should be worked mostly back into the prose, leaving
points here that are specific to clarifying the taxonomy?

"The actually used codec is also an important factor in many 
communication systems."
is unclear. What's this trying to say?

In 2.1.10, 2nd paragraph, is "at least some content" accurate? What 
about the
edge cases where encoding results in an empty stream (an audio stream 
that is
silent, where the codec does silence suppression resulting in no bits 
out for
example). You're still going to be emitting RTCP. Is this section saying
that the RTP stream doesn't qualify as a Source stream?

In 2.2.1 it's not clear what "ensure Endpoint Identification" means. Did you
mean something like 'establish' instead of 'ensure'?

At the end of the first paragraph of 3.6, you point forward to 3.12 for a
discussion of other considerations effecting which usage is desirable.
3.12 doesn't talk about that. It only talks about how you separate the
streams. What is "other considerations" supposed to be pointing to?

Very tiny nits and suggestions:
2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP synchronized clock/
2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous.
2.1.6 Characteristics bullet: This isn't a characteristic of a Media 
encoder.
       The sentence is almost a cyclic definition. I suggest removing the
       characteristics section from this (or saying something different).
2.1.19 "the Media Transport's transformation" is ambiguous. Which one?
        Did you mean "the combination of of the transport sender, network
        transport, and transport receiver transformations", or something
        like it?
3.5 Consider clarifying "mono encoder"
3.6 last sentence: s/This to/This is to/ or s/This to enable/This enables/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 May 2015 19:45:14 +0000

In regard to the summary comment, I would like to confirm that the issue of when to publish was extensively discussed in the working group and between the working group chairs and the authors. It was agreed that nothing would be achieved by waiting and therefore there was consensus to move forward.

The remainder I will leave to the document editor.

Keith 
AVTEXT working group co-chair

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of 
> Robert Sparks
> Sent: 14 May 2015 20:22
> To: General Area Review Team; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [avtext] Genart LC review: 
> draft-ietf-avtext-rtp-grouping-taxonomy-06
> 
> 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.
> 
> This draft has clearly helped progress conversations across 
> several working groups, particularly around grouping streams. 
> It's good that it was put together. I worry a little about 
> the timing of publishing it as an RFC now (is that driven by 
> other documents wanting to reference this normatively?) 
> rather than keeping most of it as a living document 
> somewhere. That said, I don't think publishing it as an RFC 
> is going to hurt anything, but since future readers aren't 
> going to be focusing so hard on the current conversations, I 
> want to check on a couple of things:
> 
> Major issues:
> 
> I'm surprised that there is no mention of how SRTP fits into 
> the vocabulary this document builds. Would it be a mistake 
> for someone to think of SRTP as what this document calls a 
> transformation? Are there any consequences of using SRTP on 
> one or more of the streams being associated that impact how 
> you would talk about the association? (There are certainly 
> consequences about which elements can see into the various streams).
> 
> Minor issues:
> 
> The title says this document is about grouping. While 
> conversations around grouping motivated the document, the 
> text goes well beyond describing grouping.
> The abstract and introduction don't contain the word 
> 'grouping'; instead, they cast the document as being about 
> describing sources, but the document goes well beyond a 
> taxonomy of sources. It suggest reworking these sections to 
> reflect what the document ended up being.
> 
> Nits/editorial comments:
> 
> The document call out the possibility of loops, but no 
> discussion shows the use of one. What motivated calling out 
> the possibility?
> 
> The use of "Characteristics" is inconsistent across the 
> sections. Sometimes the bullets list things that could be 
> used to classify a thing, and sometimes they appear to be a 
> set of observations about the thing. It's hard to tell 
> whether the lists are intended to be complete or exclusive, 
> depending on the section. Perhaps these should be worked 
> mostly back into the prose, leaving points here that are 
> specific to clarifying the taxonomy?
> 
> In 2.1.10, 2nd paragraph, is "at least some content" 
> accurate? What about the edge cases where encoding results in 
> an empty stream (an audio stream that is silent, where the 
> codec does silence suppression resulting in no bits out for 
> example). You're still going to be emitting RTCP. Is this 
> section saying that the RTP stream doesn't qualify as a Source stream?
> 
> In 2.2.1 it's not clear what "ensure Endpoint Identification" 
> means. Did you mean something like 'establish' instead of 'ensure'?
> 
> At the end of the first paragraph of 3.6, you point forward 
> to 3.12 for a discussion of other considerations effecting 
> which usage is desirable.
> 3.12 doesn't talk about that. It only talks about how you 
> separate the streams. What is "other considerations" supposed 
> to be pointing to?
> 
> 2.1.6 Characteristics bullet: This isn't a characteristic of 
> a Media encoder.
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 14 May 2015 20:42:02 +0000

As an author of the only draft in the RFC Editor queue that's waiting on
this taxonomy draft, (that would be draft-ietf-dart-dscp-rtp) I certainly
did not put any pressure on anyone to rush publication of this taxonomy
draft.

The normative reference that's causing the dart draft to wait for this
taxonomy draft exists because it's important a single set of terminology
be used with consensus on what the terms mean.  IMHO, getting RFC content
right is much more important than getting RFCs published quickly.

Thanks,
--David

> From: Gen-art [mailto:[email-masked]] On Behalf Of DRAGE, Keith
> (Keith)
> Sent: Thursday, May 14, 2015 3:45 PM
> To: Robert Sparks; General Area Review Team; [email-masked]; [email-masked];
> Subject: Re: [Gen-art] [avtext] Genart LC review: draft-ietf-avtext-rtp-
> grouping-taxonomy-06
> 
> In regard to the summary comment, I would like to confirm that the issue of
> when to publish was extensively discussed in the working group and between the
> working group chairs and the authors. It was agreed that nothing would be
> achieved by waiting and therefore there was consensus to move forward.
> 
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2015 11:38:02 +0200

> into the various streams).

Yes, encryption is clearly a transformation. And there are cases where 
the order of the encryption and other transformations, like FEC, do 
matter. Thus, I agree that it is an significant oversight to not include 
security.

So SRTP is an Securing / Protection (as it is not only Encryption) 
transformation that operates on Source RTP Streams or Redundancy RTP 
Streams to create Secured Source RTP Streams or Secured Redundancy RTP 
Stream.

If one looks on something like ISMAcrypt that operates on a special form 
of packetized encoded streams, i.e. payload created, but not RTP 
headers, we get into further distinctions that we so far haven't needed 
to have.

I don't know how well we must ensure that something like ISMAcrypt is 
clearly defined, because then we do need to split the RTP packetization 
transformation into two parts.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 20 May 2015 15:25:33 -0500

Magnus and Robert: Is there an action implied here? I see that Magnus 
agreed that there was an oversight in regards to security, but it's not 
clear to me what action (if any) is planned.

Thanks!

Ben.

On 18 May 2015, at 4:38, Magnus Westerlund wrote:

> matter. Thus, I agree that it is an significant oversight to not 
> include security.
>
> If one looks on something like ISMAcrypt that operates on a special 
> form of packetized encoded streams, i.e. payload created, but not RTP 
> headers, we get into further distinctions that we so far haven't 
> needed to have.
>
> clearly defined, because then we do need to split the RTP 
> packetization transformation into two parts.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 20 May 2015 15:39:12 -0500

On 5/20/15 3:25 PM, Ben Campbell wrote:
> agreed that there was an oversight in regards to security, but it's 
> not clear to me what action (if any) is planned.
I think Magnus was sketching out proposed new text for the document.
>> Yes, encryption is clearly a transformation. And there are cases 
>> where the order of the encryption and other transformations, like 
>> FEC, do matter. Thus, I agree that it is an significant oversight to 
>> not include security.
>>
>> Streams to create Secured Source RTP Streams or Secured Redundancy 
>> RTP Stream.
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 May 2015 11:33:04 +0200

> I think Magnus was sketching out proposed new text for the document.

Well,

I didn't promised text. But, I am working with Bo, so he can produce a 
proposal for addressing this.

cheers

Magnus Westerlund

---

From: Bo Burman <[email-masked]>
Date: Thu, 21 May 2015 17:02:35 +0000

I agree that there should be text explicitly discussing SRTP, and having it as a separate transformation is likely the best option.

One reason to keep it as a separate transformation is to be able to describe the relation to the RTP-based Redundancy transformation. That would not be possible if SRTP were to be described as an configuration option to the Media Packetizer, for example. New 2.1.x sub-sections for that transformation and the resulting stream will be needed, as well as an update to the media chain figures. I will work with Magnus, my co-authors and the WG, and come up with a text proposal.

I will respond to the other comments in the separate thread, reducing the sendlist somewhat.

Cheers,
Bo B

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: den 18 maj 2015 11:38
> To: Robert Sparks; General Area Review Team; [email-masked]; [email-masked]; draft-ietf-avtext-rtp-grouping-
> [email-masked]
> Subject: Re: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06
> 
> > vocabulary this document builds. Would it be a mistake for someone to
> > think of SRTP as what this document calls a transformation? Are there
> > any consequences of using SRTP on one or more of the streams being
> > associated that impact how you would talk about the association?
> > (There are certainly consequences about which elements can see into
> > the various streams).
> >
> 
> Yes, encryption is clearly a transformation. And there are cases where the order of the encryption and other
> transformations, like FEC, do matter. Thus, I agree that it is an significant oversight to not include security.
> 
> So SRTP is an Securing / Protection (as it is not only Encryption) transformation that operates on Source RTP Streams or
> Redundancy RTP Streams to create Secured Source RTP Streams or Secured Redundancy RTP Stream.
> 
> If one looks on something like ISMAcrypt that operates on a special form of packetized encoded streams, i.e. payload
> created, but not RTP headers, we get into further distinctions that we so far haven't needed to have.
> 
> I don't know how well we must ensure that something like ISMAcrypt is clearly defined, because then we do need to
> split the RTP packetization transformation into two parts.
> 
> Cheers
> 
> Magnus Westerlund
>