Re: [MMUSIC] Recent Bundle Changes - final chance

[Christer Holmberg <[e-mail]>]

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:[e-mail]] 
Sent: 14 June 2018 20:13
To: Magnus Westerlund <[e-mail]>; Christer Holmberg <[e-mail]>
Cc: Flemming Andreasen <[e-mail]>; mmusic <[e-mail]>; Adam Roach <[e-mail]>
Subject: Re: [MMUSIC] Recent Bundle Changes - final chance



> On Jun 14, 2018, at 4:36 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> 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.

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.







> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>