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]”.