Subject: [MMUSIC] Comments on draft-ietf-mmusic-rid-01

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Feb 2016 17:41:53 +0000

Hi,

I very much agree with Christer’s recent comments. 

In addition, I didn’t find a precise specification in the draft for what RID parameters constrain what “a=fmtp:" parameters, for what RTP payload formats. I think this draft needs a complete list of which parameters are constrained by each RID parameter, to ensure unambiguous behaviour with existing codecs. 

Also, to ensure consistency going forward, the draft should probably give some guidance to the PAYLOAD working group, mandating “a=fmtp:” parameter names for common features when defining future payload formats, so they match the RID parameter names if they’re intended to be restricted by RID parameters, and to use different names otherwise.

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Feb 2016 10:14:15 -0600

On 2/2/16 11:41, Colin Perkins wrote:
> I didn’t find a precise specification in the draft for what RID parameters constrain what “a=fmtp:" parameters, for what RTP payload formats. I think this draft needs a complete list of which parameters are constrained by each RID parameter, to ensure unambiguous behaviour with existing codecs.

I fear such an approach may be intractable. On a quick analysis, I find 
almost 100 RFCs that define "a=fmtp" parameters, and most of those 
define more than one. If you want to volunteer to slog through that 
entire corpus and figure out which correspond to the constraints we're 
defining, I'll happily accept the output of that work. But I suspect 
you'll reach the same conclusion as I did: it's not a reasonable task.

That said, the principle here is pretty easy to grasp: when the "a=fmtp" 
parameters constrain your encoding in some way, and the "a=rid" 
parameters also constrain your encoding in some way, you need to meet 
both constraints simultaneously. If you think there's some text we can 
add to Section 9 to clarify this principle, I'm happy to expound on it. 
But I'm pretty certain that the future-proof approach here is to lay out 
a principle of interaction, rather than (for example) spending the 
energy to figure out how the "pgroup" parameter for SMPTE 292M might 
interact with any of the constraints we're defining, and then doing that 
same kind of analysis hundreds of times over.

> Also, to ensure consistency going forward, the draft should probably give some guidance to the PAYLOAD working group, mandating “a=fmtp:” parameter names for common features when defining future pa…

Trying to harmonize PAYLOAD's handling of <format specific parameters> 
seems to be somewhat outside the scope of what this document is doing. I 
mean, I get that the lack of coordination of constraining parameters on 
video codecs is a pretty sad state of affairs, but it's not really fair 
to shackle this draft to the task of solving that mess before it can 
move forward.

To be clear, I'd be happy to see some kind of guidance regarding <format 
specific parameters> put forth in an independent document so that there 
is at least a modicum of uniformity for future formats. I just think 
it's not in the scope of the RID work.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Feb 2016 12:39:32 -0600

On 2/3/16 10:14, Adam Roach wrote:
> If you think there's some text we can add to Section 9... 
Sorry, I meant Section 8.

/a

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Feb 2016 00:17:27 +0000

> On 3 Feb 2016, at 16:14, Adam Roach <[email-masked]> wrote:
> I fear such an approach may be intractable. On a quick analysis, I find almost 100 RFCs that define "a=fmtp" parameters, and most of those define more than one. If you want to volunteer to slog through that entire corpus and figure out which correspond to the constraints we're defining, I'll happily accept the output of that work. But I suspect you'll reach the same conclusion as I did: it’s not a reasonable task.

I’m not volunteering, but I think the problem is smaller than it seems, since this only applies to video codecs that have flexibility in encoding. Many of those 100 RFCs are for audio, text, or FEC formats, and many of the remaining are for video codecs are have insufficient flexibility to be impacted by the constraints, or are effectively obsolete. 

At the least, it ought to do the analysis and mapping of a=fmtp parameters to rid constraints for the small number of modern codecs that people are likely to use - the WebRTC recommendations, for example.

> That said, the principle here is pretty easy to grasp: when the "a=fmtp" parameters constrain your encoding in some way, and the "a=rid" parameters also constrain your encoding in some way, you need to meet both constraints simultaneously. If you think there's some text we can add to Section 9 to clarify this principle, I'm happy to expound on it. But I’m pretty certain that the future-proof approach here is to lay out a principle of interaction, rather than (for example) spending the energy to figure out how the "pgroup" parameter for SMPTE 292M might interact with any of the constraints we're defining, and then doing that same kind of analysis hundreds of times over.

Sure, I understand, if it can be done without ambiguity. 

> Trying to harmonize PAYLOAD's handling of <format specific parameters> seems to be somewhat outside the scope of what this document is doing. I mean, I get that the lack of coordination of constraining parameters on video codecs is a pretty sad state of affairs, but it's not really fair to shackle this draft to the task of solving that mess before it can move forward.
> 
> To be clear, I'd be happy to see some kind of guidance regarding <format specific parameters> put forth in an independent document so that there is at least a modicum of uniformity for future formats. I just think it's not in the scope of the RID work.

I thought this wasn’t do bad: “registrations of future RTP payload format specifications that define media types that have parameters matching the RID constraints specified in this memo SHOULD name those parameters in a manner that matches the names of those RID constraints, and SHOULD explicitly state what media type parameters are constrained by what RID constraints”?

IANA considerations: "this draft updates RFC 4855 to give additional guidance on choice of parameter names, and on their relation to RID constraints [RFC XXXX]”

Whether that goes in this draft, or in a short draft for PAYLOAD, isn’t so important. 

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Feb 2016 14:46:27 -0600

> At the least, it ought to do the analysis and mapping of a=fmtp parameters to rid constraints for the small number of modern codecs that people are likely to use - the WebRTC recommendations, for e…

It seems that anything less than full coverage would be difficult to do 
in a normative way, unless we restrict RIDs for use with the subset of 
codecs we decided to analyze.

That said, it seems reasonable and tractable to have a non-normative 
description of how the fmtp parameters of two codecs you indicate 
interact with the constraints defined in this document. I'll make a run 
at this and put the results out as a -04.

> IANA considerations: "this draft updates RFC 4855 to give additional guidance on choice of parameter names, and on their relation to RID constraints [RFC XXXX]”

I'm happy to add your proposed text, but I'm going to very quick to 
suggest pulling it out if it looks like it's going to slow down this 
document. It's really not the core purpose of this spec to fix PAYLOAD's 
format parameter naming morass.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Feb 2016 17:23:04 -0600

Colin:

I've dropped a new version (-04) that incorporates this feedback. Please 
review the changes 
(https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-04) and confirm 
that they address your feedback.

/a

On 2/8/16 14:46, Adam Roach wrote:
>>>> I didn’t find a precise specification in the draft for what RID 
>>>> parameters constrain what “a=fmtp:" parameters, for what RTP 
>>>> payload formats. I think this draft needs a complete list of which 
>>>> parameters are constrained by each RID parameter, to ensure 
>>>> unambiguous behaviour with existing codecs.
>>> I fear such an approach may be intractable. On a quick analysis, I 
>>> find almost 100 RFCs that define "a=fmtp" parameters, and most of 
>>> those define more than one. If you want to volunteer to slog through 
>>> that entire corpus and figure out which correspond to the 
>>> constraints we're defining, I'll happily accept the output of that 
>>> work. But I suspect you'll reach the same conclusion as I did: it’s 
>>> not a reasonable task.
>> I’m not volunteering, but I think the problem is smaller than it 
>> seems, since this only applies to video codecs that have flexibility 
>> in encoding. Many of those 100 RFCs are for audio, text, or FEC 
>> formats, and many of the remaining are for video codecs are have 
>> insufficient flexibility to be impacted by the constraints, or are 
>> effectively obsolete.
>>
>> At the least, it ought to do the analysis and mapping of a=fmtp 
>> parameters to rid constraints for the small number of modern codecs 
>> that people are likely to use - the WebRTC recommendations, for example.
>
> It seems that anything less than full coverage would be difficult to 
> do in a normative way, unless we restrict RIDs for use with the subset 
> of codecs we decided to analyze.
>
> interact with the constraints defined in this document. I'll make a 
> run at this and put the results out as a -04.
>
>>>
>>> Trying to harmonize PAYLOAD's handling of <format specific 
>>> parameters> seems to be somewhat outside the scope of what this 
>>> document is doing. I mean, I get that the lack of coordination of 
>>> constraining parameters on video codecs is a pretty sad state of 
>>> affairs, but it's not really fair to shackle this draft to the task 
>>> of solving that mess before it can move forward.
>>>
>>> To be clear, I'd be happy to see some kind of guidance regarding 
>>> <format specific parameters> put forth in an independent document so 
>>> that there is at least a modicum of uniformity for future formats. I 
>>> just think it's not in the scope of the RID work.
>> I thought this wasn’t do bad: “registrations of future RTP payload 
>> format specifications that define media types that have parameters 
>> matching the RID constraints specified in this memo SHOULD name those 
>> parameters in a manner that matches the names of those RID 
>> constraints, and SHOULD explicitly state what media type parameters 
>> are constrained by what RID constraints”?
>>
>> IANA considerations: "this draft updates RFC 4855 to give additional 
>> guidance on choice of parameter names, and on their relation to RID 
>> constraints [RFC XXXX]”
>
> document. It's really not the core purpose of this spec to fix 
> PAYLOAD's format parameter naming morass.
>
> /a

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Feb 2016 13:40:51 +0000

Thanks - I do think that helps.
Colin

> On 8 Feb 2016, at 23:23, Adam Roach <[email-masked]> wrote:
> 
> Colin:
> 
> I've dropped a new version (-04) that incorporates this feedback. Please review the changes (https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-04) and confirm that they address your feedback.
> 
> /a
> 
>> It seems that anything less than full coverage would be difficult to do in a normative way, unless we restrict RIDs for use with the subset of codecs we decided to analyze.
>> 
>> That said, it seems reasonable and tractable to have a non-normative description of how the fmtp parameters of two codecs you indicate interact with the constraints defined in this document. I'll make a run at this and put the results out as a -04.
>> 
>>>> 
>> I'm happy to add your proposed text, but I'm going to very quick to suggest pulling it out if it looks like it's going to slow down this document. It's really not the core purpose of this spec to fix PAYLOAD's format parameter naming morass.
>> 
>> /a
> 

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