Subject: [avtext] 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
>

---

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

Thank you for the review and your comments! Please find my answers inline below.

Cheers,
Bo B

> From: Robert Sparks [mailto:[email-masked]]
> Sent: den 14 maj 2015 21:22
> To: General Area Review Team; [email-masked]; [email-masked]; [email-masked]
> Subject: 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:
[BoB] As Keith also pointed out, this was discussed in the WG and the conclusion there was that there seems to be no point in delaying publication. I don't think the WG recently discussed not publishing it at all, but given that several drafts already reference it, today 14 (2 of which normatively), the information in the document appears both desirable and useful in the IETF context.

> 
> 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).
[BoB] (This was also sent in a separate mail). 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 separate 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 (who also commented about that), my co-authors and the WG, and come up with a text proposal.

Additional comments:
I have a slight naming problem for that transformation, for several reasons:
1) I need separate names for forward and reverse transforms,
2) it involves both encryption and authentication, and
3) I want to keep the name short, but yet sufficiently descriptive.

One option would be to call it "RTP-based Security", specifically having a reference to RTP similar to "RTP-based Redundancy". I however then get problems with what to call the reverse transformation; I don't think anything with "de-security" or "unsecure" works. "Protect" and "unprotect" could possibly work, but runs the risk of being mistaken for what we otherwise call "redundancy", like FEC. I cannot come to think of anything better than "RTP-based Encryption" and "RTP-based Decryption", and think that "RTP-based Encryption and Authentication" and "RTP-based Decryption and Authentication" are far too long.

Co-authors: your suggestions are welcome!

> 
> 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
[BoB] What about just removing "grouping" from the title?

Proposal for abstract:
OLD:
   The terminology about, and associations among, Real-Time Transport
   Protocol (RTP) sources can be complex and somewhat opaque.  This
   document describes a number of existing and proposed relationships
   among RTP sources, and attempts to define common terminology for
   discussing protocol entities and their relationships.
NEW:
   The terminology about, and associations among, Real-Time Transport
   Protocol (RTP) sources can be complex and somewhat opaque.  This
   document describes a number of existing and proposed properties and
   relationships among RTP sources, and defines common terminology for
   discussing protocol entities and their relationships.

Proposal for Introduction:
OLD:
   The existing taxonomy of sources in RTP is often regarded as
   confusing and inconsistent.  Consequently, a deep understanding of
   how the different terms relate to each other becomes a real
   challenge.  Frequently cited examples of this confusion are (1) how
   different protocols that make use of RTP use the same terms to
   signify different things and (2) how the complexities addressed at
   one layer are often glossed over or ignored at another.

   This document attempts to provide some clarity by reviewing the
   semantics of various aspects of sources in RTP.  As an organizing
   mechanism, it approaches this by describing various ways that RTP
   sources can be grouped and associated together.
NEW:
   The existing taxonomy of sources in Real-Time Transport Protocol
   (RTP) [RFC3550] has previously often been regarded as confusing and
   inconsistent.  Consequently, a deep understanding of how the
   different terms relate to each other becomes a real challenge.
   Frequently cited examples of this confusion are (1) how different
   protocols that make use of RTP use the same terms to signify
   different things and (2) how the complexities addressed at one layer
   are often glossed over or ignored at another.

   This document provides some clarity by reviewing the semantics of
   various aspects of sources in RTP.  As an organizing mechanism, it
   approaches this by describing various ways that RTP sources are
   transformed on their way between sender and receiver, and how they
   can be grouped and associated together.

> The document call out the possibility of loops, but no discussion shows the use of one. What motivated calling out the
> possibility?
[BoB] If I remember correctly, it was the result of an early design discussion for the media chain concept that concluded we should not rule out loops, if we found them to be necessary. As it turned out, it seems we have no obvious use for it. I suggest simply removing that latter part of the sentence where it is mentioned.

> 
> 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?
[BoB] The list is not intended to be complete, and you are right that the bullet information content is inconsistent. I also agree that general observations are better placed as body text, as are probably any "list" with only a single bullet.

One of the reasons to have a bullet list in the first place was that for some sections, there were multiple sentences with pieces of useful information (like classification) and observations around the thing, but those sentences provided a weak logic flow in prose text, which could hamper the reader's understanding. An easy "fix" was to clearly separate them into a bullet list, but the "characteristics" heading for that list probably turned out to be an ill fit for the actual contents. Do you think it preferable to convert all of the bullet lists into more verbose prose, and would benefit the text as a whole?

> 
> "The actually used codec is also an important factor in many communication systems."
[BoB] It tries to highlight that the codec type (not media type, like "video", but format, like "H.265") is as important as other properties like bitrate, resolution, bandwidth etc. I guess you could just as well include "codec" as one item among the listed properties, and remove the last sentence. Do you think that would be sufficiently clear?

> 
> 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?
[BoB] I think that "at least some", as opposed to "always a complete", is intended to cover the case where an Encoded Stream is split onto multiple Source RTP Streams. I don't think we have a concrete example of that in the rest of the text, but all exemplified or depicted Media Packetizer transforms all have a single output. Do you think we should explicitly disallow that an Encoded Stream is split onto several Source RTP Streams by the Media Packetizer?

For the extreme edge case where no output at all is produced from the media encoder, there is no encoded stream. Should a media packetizer without any input whatsoever anyway produce an RTP stream? I believe that decision must be left up to the individual RTP format specification for the used codec, detail implementation considerations like RTP keep-alive, and it is hard to mandate any behavior. An "active" media packetizer without input will produce RTCP sender reports for a couple of RTCP intervals, but will then revert to sending only receiver reports. Those receiver reports are firstly control information, not media, and are secondly not directly related to the (silent) forward direction RTP stream.

I don't understand your question if an RTP stream would not qualify as a source stream? Do you rather mean to ask if an RTCP stream is not a source stream? In that case, I would like to say yes, it is strictly not part of the source stream itself but control information related to the source stream. Do you think this level of RTP/RTCP detailed considerations is important to include in the text?

> 
> In 2.2.1 it's not clear what "ensure Endpoint Identification" means. Did you mean something like 'establish' instead of
> 'ensure'?
[BoB] Yes, 'establish' or 'provide' are probably better words.

> 
> 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?
[BoB] Good catch. I think this was pointing to text that is for some reason no longer there in 3.12. One major reason to use separate Media Transports is to make use of different Quality of Service provided by the Media Transport. I'll add some brief text on that here in 3.6 instead and point to 3.12 for considerations that should be made when separating RTP streams.

> 2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP synchronized clock/
[BoB] OK.

> 2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous.
[BoB] OK. Will replace with "a Media Source". This single bullet will also be reworked into prose text, in line with what is stated above.

> 2.1.6 Characteristics bullet: This isn't a characteristic of a Media encoder.
[BoB] OK. Will remove, as the same information is already present in prose text.

>         transport, and transport receiver transformations", or something
[BoB] Yes, motivated by section 2.1.13 describing "Media Transport" as an aggregate transformation term and also providing the detailing of it. Would it be sufficient to include a reference to 2.1.13?

> 3.5 Consider clarifying "mono encoder"
[BoB] What about "single-channel (mono) encoder"?

> 3.6 last sentence: s/This to/This is to/ or s/This to enable/This enables/
[BoB] OK.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 21 May 2015 17:30:54 +0000

<snip>

> Co-authors: your suggestions are welcome!

I think "RTP-based Encryption/Decryption” is the logical choice and the one I would have come up with independently.

Cheers,

Gonzalo

<snip>

---

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

> [BoB] What about just removing "grouping" from the title?
So, this, and the changes proposed below make the title, introduction, 
and abstract consistent, but strengthens the notion that this document 
is about sources.
I don't think it's only (or even mainly) about sources anymore.
Would it be wrong to change the title to "A Taxonomy of Semantics and 
Mechanisms for the Real-Time Transport Protocol (RTP)"?
If that's right, then the changes to the abstract and introduction are 
going to take more work.
> [BoB] If I remember correctly, it was the result of an early design discussion for the media chain concept that concluded we should not rule out loops, if we found them to be necessary. As it turne…
wfm
> One of the reasons to have a bullet list in the first place was that for some sections, there were multiple sentences with pieces of useful information (like classification) and observations around…
The right balance is probably in the middle. Many of the lists would 
benefit from being pulled back into the prose. Those that really are 
lists of characteristics should probably remain as lists.
> [BoB] It tries to highlight that the codec type (not media type, like "video", but format, like "H.265") is as important as other properties like bitrate, resolution, bandwidth etc. I guess you cou…
I think that would help.
> [BoB] I think that "at least some", as opposed to "always a complete", is intended to cover the case where an Encoded Stream is split onto multiple Source RTP Streams.
I think we missed each other a little here - your response suggests 
bigger changes than I would have expected.

I think we should back up a little, and focus on clarifying what "at 
least some content" meant.
 From your response, I take it that you were trying to shine the light 
on the cases where the stream carries only some of the overall 
interesting data.
My (mis-)read was that it was requiring that there be some bits.

>   I don't think we have a concrete example of that in the rest of the text, but all exemplified or depicted Media Packetizer transforms all have a single output. Do you think we should explicitly disallow that an Encoded Stream is split onto several Source RTP Streams by the Media Packetizer?
No.
> I don't understand your question if an RTP stream would not qualify as a source stream?
More evidence that we missed each other. My point is simple. I think the 
text as written will cause confusion with silence-suppressed streams. 
Clarifying "at least some content" will fix that, I hope.
> Do you rather mean to ask if an RTCP stream is not a source stream? In that case, I would like to say yes, it is strictly not part of the source stream itself but control information related to the source stream. Do you think this level of RTP/RTCP detailed considerations is important to include in the text?
No - I wasn't trying to go that direction at all.
> [BoB] Yes, motivated by section 2.1.13 describing "Media Transport" as an aggregate transformation term and also providing the detailing of it. Would it be sufficient to include a reference to 2.1.…
How about something like  "the Media Transport's aggregate 
transformation (see section 2.1.13)"
> [BoB] What about "single-channel (mono) encoder"?
Yes - that will help.

---

From: Bo Burman <[email-masked]>
Date: Fri, 22 May 2015 16:04:52 +0000

More responses inline, cutting away parts that I consider already concluded.

Cheers,
Bo B

> Sent: den 21 maj 2015 21:28
> To: Bo Burman; [email-masked]; [email-masked]
> Cc: Magnus Westerlund

<snip>

> >> Minor issues:
> >>
> >> The title says this document is about grouping. While conversations
> >> around grouping motivated the document, the text goes well beyond describing 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.
> So, this, and the changes proposed below make the title, introduction, and abstract consistent, but strengthens the
> notion that this document is about sources.
[BoB] While the document is not strictly confined to describing just "RTP sources", I do consider the current document contents to be mainly about the "RTP sources" and how they are used, standalone or in relation to other "RTP sources". With the vague term "RTP sources", I mean the media things that can be transported from one end of a network to another by RTP. The document contents also include a discussion about the context in which such "RTP sources" exist and a hierarchy of named entities that can generate or consume them.

With that clarification (I hope) in mind, could you elaborate a bit on why you think the document is not only about RTP sources? Maybe there is a better name for the scope I describe above, but I have no better suggestion.

> Would it be wrong to change the title to "A Taxonomy of Semantics and Mechanisms for the Real-Time Transport
> Protocol (RTP)"?
[BoB] While that is certainly possible, I think it instead hints a scope that is way too wide for the current contents, suggesting that the provided taxonomy is "RTP-complete". We would arguably need to include better taxonomy for many other aspects of RTP as well that we did not look into, like time stamping, RTCP reporting, contributing sources, RTP header extensions, etc.

> If that's right, then the changes to the abstract and introduction are going to take more work.
[BoB] If so, that wouldn't be a problem, but as said above I don't (yet) agree with you.

<snip>

> >> 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?
> > [BoB] I think that "at least some", as opposed to "always a complete", is intended to cover the case where an Encoded
> Stream is split onto multiple Source RTP Streams.
> I think we missed each other a little here - your response suggests bigger changes than I would have expected.
> 
> I think we should back up a little, and focus on clarifying what "at least some content" meant.
>  From your response, I take it that you were trying to shine the light on the cases where the stream carries only some of
> the overall interesting data.
[BoB] Yes

> >   I don't think we have a concrete example of that in the rest of the text, but all exemplified or depicted Media
> Packetizer transforms all have a single output. Do you think we should explicitly disallow that an Encoded Stream is split
> onto several Source RTP Streams by the Media Packetizer?
> No.
[BoB] Good

> >
> > For the extreme edge case where no output at all is produced from the media encoder, there is no encoded stream.
> Should a media packetizer without any input whatsoever anyway produce an RTP stream? I believe that decision must be
> left up to the individual RTP format specification for the used codec, detail implementation considerations like RTP keep-
> alive, and it is hard to mandate any behavior. An "active" media packetizer without input will produce RTCP sender
> reports for a couple of RTCP intervals, but will then revert to sending only receiver reports. Those receiver reports are
> firstly control information, not media, and are secondly not directly related to the (silent) forward direction RTP stream.
> >
> More evidence that we missed each other. My point is simple. I think the text as written will cause confusion with
> silence-suppressed streams.
[BoB] Agree. I however have a problem to find a good wording. Silence suppressed streams definitely qualify as Source Streams, no argument there. What about "...that sends at least some content at some point during its lifetime..." or something similar? That way, a source that is silent for its entire lifetime and never sends _any_ data will not be classified as a source (disregarding RTCP), but that should not pose a problem, I guess?

> > Do you rather mean to ask if an RTCP stream is not a source stream? In that case, I would like to say yes, it is strictly not
> part of the source stream itself but control information related to the source stream. Do you think this level of RTP/RTCP
> detailed considerations is important to include in the text?
[BoB] OK

<snip>