Skip to main content

A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
draft-ietf-avtext-rtp-grouping-taxonomy-08

Yes

(Barry Leiba)

No Objection

(Alia Atlas)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Stephen Farrell)

Note: This ballot was opened for revision 06 and is now closed.

Alissa Cooper Former IESG member
(was No Objection) Yes
Yes (2015-07-08 for -07) Unknown
Thanks for all your work on this. Caught some nits below.

= Sec 2.1.3 =

s/The time progressing stream/A Raw Stream is the time progressing stream/

= Sec 2.1.5 =

s/A stream of digital samples/A Source Stream is a stream of digital samples/

= Sec 2.1.6 =

s/Such Media Encoder produce/Such Media Encoders produce/

= Sec 2.1.9 =

s/and put their content/and putting their content/

= Sec 2.1.10 =

s/A stream of RTP packets/An RTP Stream is a stream of RTP packets/

= Sec 2.1.12 =

s/A RTP Stream (Section 2.1.10) that contains/A Redundancy RTP Stream is an RTP Stream (Section 2.1.10) that contains/

= Sec 2.1.19 =

s/The RTP Stream that is emitted/The Transported RTP Stream is the RTP Stream that is emitted/

= Sec 2.1.20 =

s/The receiver Endpoint's (Section 2.2.1) transformation/The Media Transport Receiver is the receiver Endpoint's (Section 2.2.1) transformation/

= Sec 2.1.23 =

s/The RTP Stream (Section 2.1.10) resulting/The Received RTP Stream is the RTP Stream (Section 2.1.10) resulting/

= Sec 2.1.24 =

s/The Redundancy RTP Stream (Section 2.1.12) resulting/The Received Redundancy RTP Stream is the Redundancy RTP Stream (Section 2.1.12) resulting/

= Sec 2.1.26 =

s/A Received RTP Stream (Section 2.1.23) for which/A Repaired RTP Stream is a Received RTP Stream (Section 2.1.23) for which/

= Sec 2.1.28 =

s/The received version of/The Received Encoded Stream is the received version of/

= Sec 2.1.30 =

s/The received version of a Source Stream/The Received Source Stream is the received version of a Source Stream/

= Sec 3.1.32 =

s/The received version of a Raw Stream/The Received Raw Stream is the received version of a Raw Stream/

= Sec 2.2.1 =

s/A single addressable entity/An Endpoint is a single addressable entity/
Barry Leiba Former IESG member
Yes
Yes (for -07) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2015-07-01 for -06) Unknown
A few editorial comments:

-- section 1: "in Real-Time Transport Protocol"

in _the_ Real-Time Transport Protocol...

"... has previously often been"

has previously been 

-- 4.1 and children:

It's confusing figuring out which section references are to CLUE vs to other sections in this document.
Spencer Dawkins Former IESG member
Yes
Yes (2015-07-09 for -07) Unknown
Wow, I wish we'd had this document when RTCWeb and CLUE were starting in parallel! Thank you all for producing it.

Jitter is called out separately from delay in 2.1.16, but not in 2.1.18, 2.1.23, or 2.1.24. Was that intentional?

2.1.16 also calls out inter packet spacings separately. I'm not sure if that's also relevant in 2.1.18, 2.1.23, or 2.1.24, but wanted to ask.
Alia Atlas Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2015-07-09 for -07) Unknown
While I won't stand in the way of publishing this document, I think that it may be better suited to live on in a Wiki where it can be updated in a more fluent fashion.  I didn't get a particularly warm fuzzy feeling from phrases like these: "This document provides *some* clarity..." or "For each concept *an attempt is made*...".  That text can be made firmer, but the point remains: it is probable that the concepts could be refined and the taxonomy may evolve.
Benoît Claise Former IESG member
No Objection
No Objection (2015-07-08 for -07) Unknown
Thanks for this document. I particularly like the figures 1, 2 and 7, as entry points in the document.

For completeness, you might consider:
- adding a few words about the boundary between analog and digital (in the Physical Stimulus, I guess)
- inserting in figure 7 that a RTP session "is a group communications channel which can potentially carry a number of RTP Streams"
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (2015-07-07 for -07) Unknown
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.