Subject: Re: [MMUSIC] Recent Bundle Changes - final chance

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jun 2018 11:36:55 +0200

Hi,

Christer pinged me about this unanswered item from Adam's IESG review:

Den 2018-04-17 kl. 11:31, skrev Christer Holmberg:
>
>> --------------------------------------------------------------------------
>> -
>>
>> §10.2:
>>
>>>   Applications can implement RTP stacks in many different ways.  The
>>>   algorithm below details one way that RTP streams can be associated
>>>   with "m=" sections, but is not meant to be prescriptive about exactly
>>>   how an RTP stack needs to be implemented.
>> ...
>>>   To prepare to associate RTP streams with the correct "m=" section,
>>>   the following steps MUST be followed for each BUNDLE group:
>> This "MUST" seems to be at odds with the text about not being
>> prescriptive.
>> Please clarify whether the steps following this statement are prescriptive
>> (normative) or not.
> I will ask Magnus/Colin to address this.
>

On a high level it is important that the endpoints mapping between RTP 
streams and m= sections are consistent. So from that perspective the 
behaviour is strictly defined. From that point a MUST make sense. But, 
at the same time the specific realization to achieve this result doesn't 
really matter. So in that sense the MUST is a bit to strict. However, 
there is one sentence prior to the MUST that do apply:

    Applications MAY use any
    algorithm that achieves equivalent results to those described in the
    algorithm below.

To me what is there is good enough, although one may find alternative 
formulation that makes this clearer.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Jun 2018 13:12:46 -0500

> On Jun 14, 2018, at 4:36 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> On a high level it is important that the endpoints mapping between RTP streams and m= sections are consistent. So from that perspective the behaviour is strictly defined. From that point a MUST make sense. But, at the same time the specific realization to achieve this result doesn't really matter. So in that sense the MUST is a bit to strict. However, there is one sentence prior to the MUST that do apply:
> 
>   Applications MAY use any
> To me what is there is good enough, although one may find alternative formulation that makes this clearer.

I agree with Adam that this creates ambiguity as written. It’s only normative in the sense that any algorithm must achieve the same results, but the steps themselves are not normative. I can forsee arguments happening at a SIPit over whether the MUST overrides the previous paragraph. How about something along the following lines:

   "Applications can implement RTP stacks in many different ways.  The
   example algorithm below details one way that RTP streams can be associated
   with "m=" sections, but is not meant to be prescriptive about exactly
   how an RTP stack needs to be implemented.  Applications MAY use any
   algorithm that achieves equivalent results to those described in the
   example algorithm.

   To prepare to associate RTP streams with the correct "m=" section,
   the example algorithm follows the following stems for each BUNDLE group:”

If people agree, I can put this in an RFC Editor note.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 17 Jun 2018 08:47:26 +0000

Hi,

One minor comment, after a second read:

Instead of "Applications MAY use any..." I would suggest "Applications can use any...". 

Because, it's just a clarification to the previous statement.

But, if people prefer "MAY" I will not argue against :)

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 14 June 2018 20:13
To: Magnus Westerlund <[email-masked]>; Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>; Adam Roach <[email-masked]>
Subject: Re: [MMUSIC] Recent Bundle Changes - final chance

>>>> with "m=" sections, but is not meant to be prescriptive about 
>>>> exactly  how an RTP stack needs to be implemented.
>>> ...

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Jun 2018 12:42:32 -0500

I read the MAY as explicitly giving permission to use other algorithms that achieve the same results. The previous sentence offers the rational for the MAY.  My preference would be to keep it.

Or more to the point, I don’t think my proposed change is particularly material; it removes a normative keyword, but that keyword was spurious. But I can see people arguing that removing the MAY could be a material change.

Thanks!

Ben.

> On Jun 17, 2018, at 3:47 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jun 2018 17:48:15 +0000

Hi,

>I read the MAY as explicitly giving permission to use other algorithms that achieve the same >results. The previous sentence offers the rational for the MAY.  My preference would be to >keep it.

Keep it we will :)

>Or more to the point, I don’t think my proposed change is particularly material; it removes a >normative keyword, but that keyword was spurious. But I can see people arguing that >removing the MAY could be a material change.

If anyone has an issue, please indicate it.

Regards,

Christer

> To: Magnus Westerlund <[email-masked]>; Christer 
> Holmberg <[email-masked]>
>>>> -------------------------------------------------------------------
>>>> -
>>>> ------
>>>> -
>>>> 
>>>> §10.2:
>>>> 
>> ---------------------------------------------------------------------
>> - Network Architecture & Protocols, Ericsson Research