Subject: [avtext] SDP review of draft-ietf-avtext-rtp-stream-pause-07

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jun 2015 13:15:55 -0400

I am the assigned SDP directorate reviewer for this draft.
For background on the SDP directorate, please see the FAQ at
http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

Summary:

The SDP aspects of this draft are well written and clear. In my opinion 
it *can* be published in this form.

However, I do have concern about one aspect - that the manner of 
configuring the supported options of this feature is obscure and 
confusing. (This is of course a matter of taste.)

Details:

I have concerns about the way the configuration of options is specified 
using a numeric value. I can see how that might be reasonable if the 
numbers represented a pure hierarchy. But that seems not to be the case. 
The rules for valid answers are quite complex. (It isn't something that 
can be easily remembered.) This is because each number represents a 
particular combination of semi-independent properties, each of which has 
separate rules for answers vs. offers.

It seems to me that it would be better to configure these distinct 
properties independently. Perhaps just declare each of 
{PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And for 
convenience, perhaps some extra keywords for common combinations. (E.g. 
"all".) Then the rules for valid answers for a given offer would be easy 
to state and understand.

	Thanks,
	Paul Kyzivat, for the SDP Directorate

---

From: Bo Burman <[email-masked]>
Date: Tue, 16 Jun 2015 07:28:26 +0000

It is as you say a matter of taste how the configuration is expressed. I can agree that the chosen "config" approach is less suitable for a human SDP reader, but is probably better suited for an automated SDP parser and offer/answer logic.

The reasons the authors chose the number-based "config" parameter is because we found SDP Offer/Answer rules for the four individual messages in the two different directions (send support and receive support) to be hard to express in prose, and it was difficult to clearly describe the restrictions that must be put to the offerer and answerer to provide a working and meaningful functionality.

There was thus a definite need to simplify. The numbered "config" especially made the description significantly shorter, more structured and clear in what messages and directions must be supported in an answer, given a certain support of messages and directions in the offer.

We could of course go back and try to describe the per-message-per-direction approach again, but unless there's consensus that the "config" approach is hard to understand, hard to use or even broken, I'm personally hesitant to do that given that we already tried and failed.

Cheers,
Bo

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: den 10 juni 2015 19:16
> To: [email-masked]; [email-masked]
> Cc: SDP Directorate
> Subject: SDP review of draft-ietf-avtext-rtp-stream-pause-07
> 
> For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html
> 
> Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> Summary:
> 
> The SDP aspects of this draft are well written and clear. In my opinion it *can* be published in this form.
> 
> However, I do have concern about one aspect - that the manner of configuring the supported options of this feature is
> obscure and confusing. (This is of course a matter of taste.)
> 
> Details:
> 
> I have concerns about the way the configuration of options is specified using a numeric value. I can see how that might
> be reasonable if the numbers represented a pure hierarchy. But that seems not to be the case.
> The rules for valid answers are quite complex. (It isn't something that can be easily remembered.) This is because each
> number represents a particular combination of semi-independent properties, each of which has separate rules for
> answers vs. offers.
> 
> It seems to me that it would be better to configure these distinct properties independently. Perhaps just declare each of
> {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And for convenience, perhaps some extra keywords
> for common combinations. (E.g.
> "all".) Then the rules for valid answers for a given offer would be easy to state and understand.
> 
> 	Thanks,

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2015 11:26:03 -0400

> We could of course go back and try to describe the per-message-per-direction approach again, but unless there's consensus that the "config" approach is hard to understand, hard to use or even broke…

At the end of the day it is the wg, the ADs, and the IESG that should 
decide this. I expressed an opinion, but it is only that.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Jun 2015 10:32:46 -0500

On 16 Jun 2015, at 10:26, Paul Kyzivat wrote:

>> It is as you say a matter of taste how the configuration is 
>> expressed. I can agree that the chosen "config" approach is less 
>> suitable for a human SDP reader, but is probably better suited for an 
>> automated SDP parser and offer/answer logic.
>>
>> The reasons the authors chose the number-based "config" parameter is 
>> because we found SDP Offer/Answer rules for the four individual 
>> messages in the two different directions (send support and receive 
>> support) to be hard to express in prose, and it was difficult to 
>> clearly describe the restrictions that must be put to the offerer and 
>> answerer to provide a working and meaningful functionality.
>>
>> There was thus a definite need to simplify. The numbered "config" 
>> especially made the description significantly shorter, more 
>> structured and clear in what messages and directions must be 
>> supported in an answer, given a certain support of messages and 
>> directions in the offer.
>>
>> We could of course go back and try to describe the 
>> per-message-per-direction approach again, but unless there's 
>> consensus that the "config" approach is hard to understand, hard to 
>> use or even broken, I'm personally hesitant to do that given that we 
>> already tried and failed.
>

As I mentioned in my AD review, I am also concerned about the complexity 
of this--but I'm not sure expressing the config per-message helps. Both 
approaches seem to encourage non-interoperable implementations.

I'm sure this has already been discussed, but I'd like to see opinions 
on how much configurability is really required. For example, do the use 
cases mentioned as supporting the config parameter really need all these 
options?

>>> The SDP aspects of this draft are well written and clear. In my 
>>> opinion it *can* be published in this form.
>>>
>>> configuring the supported options of this feature is
>>> I have concerns about the way the configuration of options is 
>>> specified using a numeric value. I can see how that might
>>> The rules for valid answers are quite complex. (It isn't something 
>>> that can be easily remembered.) This is because each
>>> number represents a particular combination of semi-independent 
>>> properties, each of which has separate rules for
>>> answers vs. offers.
>>>
>>> {PAUSE,RESUME,PAUSED,REFUSED} that can be sent and received. (And 
>>> for convenience, perhaps some extra keywords

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Jun 2015 10:21:45 +1000

Hello,

I agree with Bo's response. Originally this was specified by a per 
message response but the text around it was very complex. Its not just a 
case of saying that an endpoint supports a message. There are certain 
message combinations that don't make sense. So you would end up having 
to list all the combinations that don't make sense. The draft then has 
to enforce the valid scenarios via procedural text because writing the 
ABNF would be a pain.

The approach taken by the draft in figure 6 is simple and concise. The 
endpoint simply sends the config number of the valid set of messages it 
supports. A receiving endpoint doesn't have to parse the SDP to see if 
the set of advertised messages is actually valid.

The number of configurations is due to states local pause, local resume, 
remote pause and remote resume and optionality in what the local and 
remote endpoints support. E.g. an endpoint may only support local pause 
by sending a PAUSED indication (config 8), an endpoint may support local 
and remote pausing and supports all messages (config 1) or something in 
between, like it may only request remote pause (by sending pause/resume 
and receiving PAUSED/REFUSED indications) but not support local pause 
(config 4).

With respect to interop, Fig.8 of the draft makes it clear what 
configurations may be permitted in an SDP answer. Part of this is to 
ensure commonality between local and remote endpoints. I wouldn't like 
to try to draft a table like this for the "per message" approach.

Regards, Christian

On 17/06/2015 1:32 AM, Ben Campbell wrote:
>>> suitable for a human SDP reader, but is probably better suited for 
>>> an automated SDP parser and offer/answer logic.
>>>
>>> clearly describe the restrictions that must be put to the offerer 
>>> and answerer to provide a working and meaningful functionality.
>>>
> As I mentioned in my AD review, I am also concerned about the 
> complexity of this--but I'm not sure expressing the config per-message 
> helps. Both approaches seem to encourage non-interoperable 
> implementations.
>
> on how much configurability is really required. For example, do the 
> use cases mentioned as supporting the config parameter really need all 
> these options?
>
>>
>>     Thanks,
>>     Paul
>>
>>
>>> Cheers,
>>> Bo
>>>
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
>