Last Call Review of draft-ietf-payload-rtp-ancillary-10
review-ietf-payload-rtp-ancillary-10-genart-lc-holmberg-2017-08-25-00

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

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