Subject: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Aug 2016 14:03:56 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-avtext-rid-08: 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-rid/

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

In this text from the Introduction,

   RTP sessions frequently consist of multiple streams,
   
would it be possible to add a word or two explaining why this happens? If
it's true that this happens because multiple media types, or codecs, or
... are in use in the same RTP session, that's the level of detail I'm
thinking about. 

In this text:

   At the same time, when redundancy RTP streams are in use, 
   
could you provide a reference for redundancy RTP streams? I'm guessing
this is using RFC 7198, but that's just a guess.

I was impressed that you included this,

   These
   redundant RTP streams may also contain their own unique RtpStreamId.
   
but (of course) started wondering why you'd do that - can the RtpStreamId
for a redundancy RTP stream appear as a RepairedRtpStreamId for a third
RTP stream? Or is there some other reason to assign an RtpStreamId?