Subject: Re: [avtext] Terry Manderson's No Objection on draft-ietf-avtext-rtp-grouping-taxonomy-07: (with COMMENT)

From: Bo Burman <[email-masked]>
Date: Wed, 8 Jul 2015 08:20:59 +0000

Terry, I'm not sure I get what you are asking for. Do you want more text from RFC3550 to be cited in 4.14? This document does not intend to re-define or override the definition of any existing terms, it only uses the common taxonomy to describe and hopefully improve the understanding of how terms relate to other terms. There is a single sentence at the beginning of section 4 that is supposed to say that, but maybe that needs amending? I have no problem making further changes if there is a need to do so. After all, the document is there to bring clarity.

> -----Original Message-----
> From: Terry Manderson [mailto:[email-masked]]
> Sent: den 8 juli 2015 04:13
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Terry Manderson's No Objection on draft-ietf-avtext-rtp-grouping-taxonomy-07: (with COMMENT)
> 
> Terry Manderson has entered the following ballot position for
> draft-ietf-avtext-rtp-grouping-taxonomy-07: No Objection
> 
> 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-avtext-rtp-grouping-taxonomy/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> A comprehensive document, and only a small comment that should be easy to clarify if I have misinterpreted.
> 
> ---
> 4.14.  SSRC
> ---
> 
> It might be my stylistic approach, but I prefer the more complete definition from RFC3550 (Section 3:) that starts with:
> 
> "Synchronization source (SSRC): ..."
> 
> I understand that the document is long, but do consider that if a reader finds this tome the words provided in 4.14 don't
> seem to fix the opacity problem the draft is addressing.
>

---

From: "Terry Manderson" <[email-masked]>
Date: Tue, 07 Jul 2015 19:13:17 -0700

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

A comprehensive document, and only a small comment that should be easy to
clarify if I have misinterpreted.

---
4.14.  SSRC
---

It might be my stylistic approach, but I prefer the more complete
definition from RFC3550 (Section 3:) that starts with:

I understand that the document is long, but do consider that if a reader
finds this tome the words provided in 4.14 don't seem to fix the opacity
problem the draft is addressing.

---

From: Terry Manderson <[email-masked]>
Date: Thu, 9 Jul 2015 00:11:20 +0000

Hi Bo,

Thanks for responding.

It struck me that there was a lot of effort put into all of the other
terms for clarity - and then I read "SSRC" and thought "that can't be it".
My comment is that while you are not trying to redefine SSRC, I feel like
you haven't given it due attention my making it too brief.

Was it the intention to make this term itself so brief in comparison? if
so - and you are 100% sure that it is crystal clear, then I can move on.

Cheers
Terry

On 8/07/2015 6:20 pm, "Bo Burman" <[email-masked]> wrote:

>Terry, I'm not sure I get what you are asking for. Do you want more text
>from RFC3550 to be cited in 4.14? This document does not intend to
>re-define or override the definition of any existing terms, it only uses
>the common taxonomy to describe and hopefully improve the understanding
>of how terms relate to other terms. There is a single sentence at the
>beginning of section 4 that is supposed to say that, but maybe that needs
>amending? I have no problem making further changes if there is a need to
>do so. After all, the document is there to bring clarity.
>
>> Cc: [email-masked];
>>[email-masked];
>> [email-masked];
>>[email-masked]; [email-masked];
>> [email-masked]
>> Subject: Terry Manderson's No Objection on
>>draft-ietf-avtext-rtp-grouping-taxonomy-07: (with COMMENT)
>> 
>>email addresses included in the To and CC lines.
>> Please refer to 
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>> I understand that the document is long, but do consider that if a
>>reader finds this tome the words provided in 4.14 don't

---

From: Bo Burman <[email-masked]>
Date: Thu, 9 Jul 2015 11:14:57 +0000

Hi Terry,

Understood. The main reason the text on SSRC is so brief is that it builds on and re-uses the other taxonomy concepts,
which in turn already covers everything else in the RFC 3550 definition of it. There should be no need to repeat that
information from other sections.

There are however two things around the RFC 3550 SSRC definition that could possibly motivate another sentence or two:
 * The RFC 3550 definition contains the following text:
   "A synchronization source may change its data format, e.g., audio encoding, over time"
   That could suggest that SSRC is not a suitable identifier for an Encoded Stream,
   but changing RTP Payload Type (PT) must be seen as simply changing Media Encoder.
   That would arguably also replace the Encoded Stream (and the identifier for it), but
   since only one PT can be effective at any given point in time (section 5.2 of RFC 3550),
   there's no ambiguity in having just SSRC as identifier, leaving RTP PT to describe the "format".
 * Taxonomy section 4.14 does not say that an SSRC value also identifies an RTP Stream
   (in addition to the Encoded Stream), but that was thought to be self-evident.

Just let me know if someone wants this to be added to the document.

Cheers,
Bo

> Sent: den 9 juli 2015 02:11
> To: Bo Burman; IESG
> Cc: [email-masked]; [email-masked]; [email-masked]; avtext-
> [email-masked]; [email-masked]; draft-ietf-avtext-rtp-grouping-
> [email-masked]
> Subject: Re: Terry Manderson's No Objection on draft-ietf-avtext-rtp-grouping-taxonomy-07: (with COMMENT)
> 
> Hi Bo,
> 
> Thanks for responding.
>

---

From: Terry Manderson <[email-masked]>
Date: Thu, 9 Jul 2015 13:54:02 +0000

Hi Bo,

Thanks again for thinking through this.

On 9/07/2015 9:14 pm, "Bo Burman" <[email-masked]> wrote:

>Hi Terry,
>
>Understood. The main reason the text on SSRC is so brief is that it
>builds on and re-uses the other taxonomy concepts,
>which in turn already covers everything else in the RFC 3550 definition
>of it. There should be no need to repeat that

To be honest it did cause me to re-read 3550 if that is any indication...

>
>There are however two things around the RFC 3550 SSRC definition that
>could possibly motivate another sentence or two:

I think that is meaningful, given the idea that this document positions
itself as a clarifying taxonomy.

>   (in addition to the Encoded Stream), but that was thought to be

I agree, it is self evident.

Cheers
Terry