Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-multi-media-rtp-session-10

[Colin Perkins <[e-mail]>]

Hi,

> On 11 Nov 2015, at 21:43, Ben Campbell <[e-mail]> wrote:
> 
> On 11 Nov 2015, at 8:49, Colin Perkins wrote:
> 
>> Hi,
>> 
>> Thanks for the review; replies inline. Let me know if you want me to submit an updated draft now, or after last call.
> 
> Please go ahead and submit a new version when you are ready. We can do the last call on the updated version.

Will do.

> More inline:
> 
> 
> [...]
> 
>>> Substantive Comments:
>>> =====================
>>> 
>>> - Section 4, "Equal treatment of media."
>>> 
>>> This section is made effectively normative by the "MUST" in the preamble. But the guidance under "Equal treatment" is a bit on the fuzzy side for normative requirements. And since the detailed guidance is delegated to the two references at the end of this section, they should be normative references. This is a bit problematic since they are informational drafts. Now, that's not a show stopper; if the references should be normative we can make them so--it just requires a bit more process.
>>> 
>>> So, please consider whether the section should be tightened up and the references made normative, or if it can be restated as non-normative guidance. This impacts how we do the IETF last call announcement, so I will hold the last call until we resolve it.
>> 
>> My suggestion would be that the “MUST” in the preamble changes to “needs to”, since this section is less normative requirements, and more a statement of the facts about how a single RTP works.
> 
> I think that would help. But even then, do you think the reader can fully understand the “Equal Treatment" section without reading multiplex-guidelines or dart-dscp-rtp?

I’ve rephrased it slightly, but yes I think so. Those drafts are relevant for cases where non-equal treatment is needed, but in the usual cases where all media are treated the same, they’re not relevant. 

>>> - 6.2, third paragraph:
>>> 
>>> 5956 obsoletes 4756. Is there a need to keep the reference to 4656? (e.g. backwards compatibility?)
>> 
>> I assume the reference is for backwards compatibility, but don’t have a strong opinion.
> 
> If it is about backwards compatibility, then it would be good to have a sentence or two stating that.

Rephrased for clarity.

>> 
>>> Editorial and Nits:
>>> ===================
>>> 
>>> - section 2: IDNits points out that the draft uses “NOT RECOMMENDED”, but does not mention it here.
>> 
>> This is a bug in the RFC 2119 boilerplate, which this draft copies verbatim. I can add “NOT RECOMMENDED”, but don’t then complain that the boilerplate doesn’t match RFC 2119 ;-)
> 
> I think we can let this one slide :-)

I added “NOT RECOMMENDED” to the boilerplate, since that seems clearest.


-- 
Colin Perkins
https://csperkins.org/