Last Call Review of draft-ietf-payload-rtp-ancillary-10

Request Review of draft-ietf-payload-rtp-ancillary
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-07-25
Requested 2017-07-03
Authors Thomas Edwards
Draft last updated 2017-08-25
Completed reviews Genart Last Call review of -06 by Christer Holmberg (diff)
Secdir Last Call review of -06 by Shawn Emery (diff)
Opsdir Last Call review of -06 by Nevil Brownlee (diff)
Genart Last Call review of -10 by Christer Holmberg (diff)
Assignment Reviewer Christer Holmberg 
State Completed
Review review-ietf-payload-rtp-ancillary-10-genart-lc-holmberg-2017-08-25
Reviewed rev. 10 (document currently at 14)
Review result Ready with Nits
Review completed: 2017-08-25


I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>

Document:                       draft-ietf-payload-rtp-ancillary-10.txt

Reviewer:                         Christer Holmberg

Review Date:                   25 August 2017

IETF LC End Date:           25 July 2017

IETF Telechat Date:        N/A

Summary: The document is well written. However, I have a few issues that I would like the authors to address.

Major Issues: None

Minor Issues:

Q1: In section 5, I think you should say that, in subsequent offers/answers, the used DID/SDID values must be included in the SDP, even if the values haven’t changed.

Q2: In section 4, I think it would be good to indicate whether there are any default values for the parameters, or whether omitting them means that they are not specified.

Q3: In section 5, I don’t think you need to say that the answerer MAY reject the offer. That is basic offer/answer. Instead, the text could say that the answerer, if it accepts the offer, MUST respond with all or subset, and that the answerer MUST NOT include things that weren’t in the offer…

Q4: Related to Q3, it would be good to indicate if there are specific criteria for rejecting the offer. For example if the answerer is not able to provide a subset of the offered values. Or, is it allowed for the answerer to not return anything?

Q5: Do we really need Section 5.2? My suggestion would be to remove the declarative considerations – unless it is known that someone is actually going to use it.

Q6: Section 4.1 talks about associating ANC RTP streams with other streams. What if ANC RTP streams are multiplexed with other RTP streams (using the SDP BUNDLE mechanism)? I assume that does not automatically mean they are associated? It would be good to have a “Multiplexing Considerations” section and describe that.

Editorial Issues:

Q1: In the Introduction, please add a reference to RFC 3550 on the first occurrence of “RTP”.

Q2: In some places, the text says “RFC 3550 [RFC3550]”, "RTP RFC 3550 [RFC3550]”etc. I suggest to simply say "[RFC3550]”.