Ballot for draft-ietf-avtext-rid
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> performed the opsdir review and changes were incorporated into 07
I don't see a response to the SecDir review, but maybe missed it? https://www.ietf.org/mail-archive/web/secdir/current/msg06724.html
There is one use of normative language but no rfc2119 boilerplate: "RtpStreamId and RepairedStreamId MUST contain only alphanumeric characters." I would actually recommend to add more normative language (and the boilerplate), e.g.: " To be clear: the value carried in a RepairedRtpStreamId MUST match the RtpStreamId value from another RTP stream in the same session. For example, if a source RTP stream is identified by RtpStreamId "A", then any redundancy RTP stream that repairs that source RTP stream will contain a RepairedRtpStreamId of "A" (if this mechanism is being used to perform such correlation). These redundant RTP streams MAY also contain their own unique RtpStreamId."
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?
Thanks for the "don't use PII" text!