Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-11-11
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-10-14
08 (System) Notify list changed from draft-ietf-avtext-rtp-grouping-taxonomy.ad@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy.shepherd@ietf.org, keith.drage@alcatel-lucent.com, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, avtext-chairs@ietf.org to (None)
2015-09-28
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-09-18
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-07-31
08 (System) RFC Editor state changed to EDIT
2015-07-31
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-07-31
08 (System) Announcement was received by RFC Editor
2015-07-31
08 (System) IANA Action state changed to No IC from In Progress
2015-07-31
08 (System) IANA Action state changed to In Progress
2015-07-31
08 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2015-07-31
08 Cindy Morgan IESG has approved the document
2015-07-31
08 Cindy Morgan Closed "Approve" ballot
2015-07-31
08 Cindy Morgan Ballot writeup was changed
2015-07-31
08 Cindy Morgan Ballot writeup was changed
2015-07-31
08 Ben Campbell Ballot approval text was generated
2015-07-29
08 Robert Sparks Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks.
2015-07-20
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-07-20
08 Bo Burman IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-07-20
08 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-08.txt
2015-07-13
07 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Menachem Dodge.
2015-07-09
07 Amy Vezza IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2015-07-09
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-07-09
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-07-09
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-07-09
07 Spencer Dawkins
[Ballot comment]
Wow, I wish we'd had this document when RTCWeb and CLUE were starting in parallel! Thank you all for producing it.

Jitter is …
[Ballot comment]
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.
2015-07-09
07 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2015-07-09
07 Alvaro Retana
[Ballot comment]
While I won't stand in the way of publishing this document, I think that it may be better suited to live on in …
[Ballot comment]
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.
2015-07-09
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-07-08
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-07-08
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-07-08
07 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to Yes from No Objection
2015-07-08
07 Alissa Cooper
[Ballot comment]
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 …
[Ballot comment]
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/
2015-07-08
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-07-08
07 Ben Campbell Changed consensus to Yes from Unknown
2015-07-08
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-07-08
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-07-08
07 Benoît Claise
[Ballot comment]
Thanks for this document. I particularly like the figures 1, 2 and 7, as entry points in the document.

For completeness, you might …
[Ballot comment]
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"
2015-07-08
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-07-08
07 Ben Campbell
Publication request for A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (draft-ietf-avtext-rtp-grouping-taxonomy-06)

A first draft of the document …
Publication request for A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (draft-ietf-avtext-rtp-grouping-taxonomy-06)

A first draft of the document was produced by a team of people led by Jonathan Lennox as draft-lennox-raiarea-rtp-grouping-taxonomy-00 in February 2013. There were three further iterations as an author draft until the document was adopted as a working group document by the AVTEXT working group in November 2013, with Bo Burman taking over the lead editorship. The document has been through six iterations as a working group document, with working group last call occurring in November 2014. While the authors of the draft have been limited, a significant team of experts has been working on the draft including Jonathan Lennox, Kevin Gross, Bo Burman, Magnus Westerlund, Suhas Nandakumar, Gonzalo Salgueiro, Harald Alvestrand.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The intended status is Informational.

The document contains terminology which can be used in other documents, but contains no normative requirements in its own right.

The title page does indicate the intended status.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.
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.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

None.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document itself contains terminology only, and no requirements, so is not directly implementable in its own right. The document has been developed in parallel with a number of specifications in the AVTCORE, PAYLOAD, MMUSIC, RTCWEB, and CLUE working groups, and has been reviewed by editors of documents in those groups.
Apart from the regular GenArt review, no further external reviews are identified as needed.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Keith Drage is the document shepherd.

Ben Campbell is the responsible area director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been read through, manually scanned for NITs, reviewed for clarity, and all references checked. Where appropriate automated reviews have also occurred.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd has no concerns about the depth or breadth of the reviews that have been performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Apart from the regular GenArt review, no further external reviews are identified as needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each author has independently confirmed that they have reviewed for IPR and see no need for filing declarations

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed on this document, nor on its predecessor document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents WG consensus and has been read and reviewed by a significant number of experts.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Apart from the regular GenArt review, no further external reviews are identified as needed.

(13) Have all references within this document been identified as either normative or informative?

All the references in the document are informative, and that is what would be expected, given the nature of the document.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references in the document. Some of the informative references are yet to be completed, but publication should proceed without waiting for any of these references. (Obviously if RFC numbers become available before publication they should be used).

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The document is informational in nature and all the references are informative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document does not change the status of any other RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The document makes no IANA registrations and requires none.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document creates no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document has no contents written in a formal language.


2015-07-07
07 Terry Manderson
[Ballot comment]
A comprehensive document, and only a small comment that should be easy to clarify if I have misinterpreted.

---
4.14.  SSRC
---

It …
[Ballot 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.
2015-07-07
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-07-07
07 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2015-07-06
07 Ben Campbell IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-07-02
07 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2015-07-02
07 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2015-07-01
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-07-01
07 Ben Campbell Placed on agenda for telechat - 2015-07-09
2015-07-01
07 Ben Campbell Notification list changed to draft-ietf-avtext-rtp-grouping-taxonomy.ad@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy.shepherd@ietf.org, keith.drage@alcatel-lucent.com, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, avtext-chairs@ietf.org from "Keith Drage" <keith.drage@alcatel-lucent.com>
2015-07-01
06 Ben Campbell
[Ballot comment]
A few editorial comments:

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

in _the_ Real-Time Transport Protocol...

"... has previously often been"

has previously …
[Ballot comment]
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.
2015-07-01
06 Ben Campbell Ballot comment text updated for Ben Campbell
2015-07-01
06 Ben Campbell Ballot has been issued
2015-07-01
06 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2015-07-01
06 Ben Campbell Created "Approve" ballot
2015-07-01
06 Ben Campbell Ballot approval text was generated
2015-06-23
06 Bo Burman IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-06-23
07 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-07.txt
2015-05-18
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-05-15
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman.
2015-05-13
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2015-05-13
06 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtext-rtp-grouping-taxonomy-06, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtext-rtp-grouping-taxonomy-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2015-05-08
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2015-05-08
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2015-05-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2015-05-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2015-05-07
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2015-05-07
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2015-05-04
06 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-05-04
06 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Taxonomy of Grouping Semantics …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources) to Informational RFC


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'A Taxonomy of Grouping Semantics and Mechanisms for Real-Time
  Transport Protocol (RTP) Sources'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-05-04
06 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-05-04
06 Amy Vezza Last call announcement was changed
2015-05-03
06 Ben Campbell Last call was requested
2015-05-03
06 Ben Campbell IESG state changed to Last Call Requested from AD Evaluation
2015-05-03
06 Ben Campbell Last call announcement was generated
2015-05-03
06 Ben Campbell Last call announcement was generated
2015-05-03
06 Ben Campbell Ballot writeup was changed
2015-05-03
06 Ben Campbell Ballot writeup was generated
2015-05-03
06 Ben Campbell Ballot approval text was generated
2015-05-03
06 Ben Campbell
Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Nothing here is sufficient to delay the IETF last call, but I'd like to at least see a …
Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Nothing here is sufficient to delay the IETF last call, but I'd like to at least see a response to the subtsantive comments.

Thanks!

Ben.

----------------

Substantive Comments:

-- I do not object to this being informational per se, but I wonder if people expect it to be normatively references by future standards track documents. Remember that a reference should be normative if it is needed to understand the dependent document. Terminology references often fall squarely into that category. If the answer is yes, has there been any considerations that this draft may need to be standards track?

-- Along the same lines, all the references informational. Could a reader be expected to understand this draft without reading _any_ of the references? I recognize this may not be important for an informational draft that is not a technical specification. But it may be more important if standards track docs normatively reference this doc.


Nits and Editorial Comments:

-- Abstract: "... attempts to define..."

Is there a concern that it may not have succeeded?  :-)

-- Section 1, 1st sentence:

Do you think RTP terminology will continue to be confusing and inconsistent after this draft is published? Also, please expand RTP in the first use in the body. (In addition to the abstract.)

-- 2.1.2:

Do you consider the meaning of the term "Media" to be clear enough that it doesn't need a definition here?

I find it hard to parse the following sentence:

"This data is due to its periodical sampling, or at least being timed asynchronous events, some form of a stream of media data. "

-- 2.1.2, 2nd bullet list entry:

s/support/supports

-- 2.1.4, first sentence

I find the sentence hard to parse:

-- 2.1.5

Was the "raw stream" not also time-progressing?

-- 2.1.9, first bullet list entry:

I can't parse the sentence. Is there a missing word towards the end?

-- 2.1.18 "... alarm subsequent transformations ... "

Do you mean "alert"?

-- 2.2.3, first bullet list entry:

is the SIP URI example assumed to be an Address of Record? If so, it might be worth mentioning that, since a SIP URI could also point to a device, and a participant might have more than one.

-- 3.7, last paragraph, 2nd sentence:

Sentence is convoluted and hard to read. Please consider splitting it into multiple simpler sentences.

-- 3.8, first paragraph, 2nd sentence:

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

-- 3.10, last paragaph, last sentence:

Convoluted sentence.

-- 3.11, last paragraph : "This requires to either use..."

Missing noun?  ("This requires XXX to use either", or "This requires the use of either...")

3.13, first paragraph, last sentence:

I can’t parse the sentence—is there a word missing? (i.e. “… and smaller number of flow based…”)?


2015-04-29
06 Ben Campbell IESG state changed to AD Evaluation from Publication Requested
2015-04-19
06 Benoît Claise Shepherding AD changed to Ben Campbell
2015-03-25
06 Cindy Morgan Shepherding AD changed to Benoit Claise
2015-03-23
06 Keith Drage
Publication request for A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (draft-ietf-avtext-rtp-grouping-taxonomy-06)

A first draft of the document …
Publication request for A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (draft-ietf-avtext-rtp-grouping-taxonomy-06)

A first draft of the document was produced by a team of people led by Jonathan Lennox as draft-lennox-raiarea-rtp-grouping-taxonomy-00 in February 2013. There were three further iterations as an author draft until the document was adopted as a working group document by the AVTEXT working group in November 2013, with Bo Burman taking over the lead editorship. The document has been through six iterations as a working group document, with working group last call occurring in November 2014. While the authors of the draft have been limited, a significant team of experts has been working on the draft including Jonathan Lennox, Kevin Gross, Bo Burman, Magnus Westerlund, Suhas Nandakumar, Gonzalo Salgueiro, Harald Alvestrand.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The intended status is Informational.

The document contains terminology which can be used in other documents, but contains no normative requirements in its own right.

The title page does indicate the intended status.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.
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.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

None.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document itself contains terminology only, and no requirements, so is not directly implementable in its own right. The document has been developed in parallel with a number of specifications in the AVTCORE, PAYLOAD, MMUSIC, RTCWEB, and CLUE working groups, and has been reviewed by editors of documents in those groups.
Apart from the regular GenArt review, no further external reviews are identified as needed.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Keith Drage is the document shepherd.

Richard Barnes is the responsible area director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been read through, manually scanned for NITs, reviewed for clarity, and all references checked. Where appropriate automated reviews have also occurred.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd has no concerns about the depth or breadth of the reviews that have been performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Apart from the regular GenArt review, no further external reviews are identified as needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each author has independently confirmed that they have reviewed for IPR and see no need for filing declarations

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed on this document, nor on its predecessor document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents WG consensus and has been read and reviewed by a significant number of experts.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Apart from the regular GenArt review, no further external reviews are identified as needed.

(13) Have all references within this document been identified as either normative or informative?

All the references in the document are informative, and that is what would be expected, given the nature of the document.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references in the document. Some of the informative references are yet to be completed, but publication should proceed without waiting for any of these references. (Obviously if RFC numbers become available before publication they should be used).

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The document is informational in nature and all the references are informative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document does not change the status of any other RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The document makes no IANA registrations and requires none.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document creates no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document has no contents written in a formal language.


2015-03-23
06 Keith Drage Responsible AD changed to Richard Barnes
2015-03-23
06 Keith Drage IETF WG state changed to Submitted to IESG for Publication from WG Document
2015-03-23
06 Keith Drage IESG state changed to Publication Requested
2015-03-23
06 Keith Drage IESG process started in state Publication Requested
2015-03-23
06 Keith Drage Changed document writeup
2015-03-23
06 Keith Drage Intended Status changed to Informational from None
2015-03-23
06 Keith Drage Notification list changed to "Keith Drage" <keith.drage@alcatel-lucent.com>
2015-03-23
06 Keith Drage Document shepherd changed to Keith Drage
2015-03-05
06 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-06.txt
2015-01-22
05 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-05.txt
2015-01-16
04 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-04.txt
2014-11-14
03 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
2014-06-27
02 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-02.txt
2014-02-14
01 Bo Burman New version available: draft-ietf-avtext-rtp-grouping-taxonomy-01.txt
2013-11-06
00 Jonathan Lennox Set of documents this document replaces changed to draft-lennox-raiarea-rtp-grouping-taxonomy from None
2013-11-05
00 Gonzalo Salgueiro New version available: draft-ietf-avtext-rtp-grouping-taxonomy-00.txt