Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Sounds reasonable to me

-- Flemming (as individual)

On 5/4/17 7:08 AM, Christer Holmberg wrote:
> Hi,
>
> I intend to move forward with option 2), and submit a new version of 
> draft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but 
> simply indicate that RFC 8035 updates the same section and moves the 
> location of the paragraph updated by draft-mux-exclusive.
>
> Regards,
>
> Christer
>
> From: mmusic <[email protected] 
> <mailto:[email protected]>> on behalf of Christer Holmberg 
> <[email protected] <mailto:[email protected]>>
> Date: Tuesday 2 May 2017 at 14:09
> To: Tolga Asveren <[email protected] 
> <mailto:[email protected]>>, "[email protected] 
> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
> Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and 
> RFC 8035
>
> Hi,
>
> >I got your point but that made me think about a more fundamental issue: Does 
> draft-mux-exclusive indeed update RFC5761?
>
> >IMHO it is not. It defines a new indicator with its own semantics. This is a new capability, not 
> something changing a capability already defined. And
>
> >it seems “backward compatibility concerns” are already addressed in a 
> reasonable way by mux-exclusive and RFC8035 updates on RFC5761.
>
> >
>
> >So, I would:
>
> >i- Remove “Updates: RFC5761” statement from the prologue
>
> >ii- Remove Section 5.
>
> >
>
> >If you still want to keep rtcp-mux-exclusive as an “update on RFC5761”, then 2) sounds 
> reasonable to me as well.
>
> It was previously agreed to add the <new></new> text to 
> draft-mux-exclusive, so I donÂ’t want to change that at this point. At 
> the end of the day, itÂ’s just a clarification specifying that if there 
> is SOME mechanism to indicate that separate ports cannot be used, the 
> stream must be disabled. Unfortunately, the RFC8035 update does not 
> add such specification.
>
> Option 2) would be adding something like this to draft-mux-exclusive:
>
> "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the 
> paragraph updated in this document is not updated by RFC8035, the 
> location of the paragraph within section 5.1.1 is moved."
>
> Regards,
>
> Christer
>
>
>
> *From:* Christer Holmberg [mailto:[email protected]]
> *Sent:* Tuesday, May 2, 2017 4:25 AM
> *To:* Asveren, Tolga <[email protected] 
> <mailto:[email protected]>>; [email protected] <mailto:[email protected]>
> *Subject:* Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035
>
> Hi,
>
> >i- “rtcp-mux-exclusive” is a new capability/indication, not an update on 
> RFC5761/8035 per se.
>
> >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional.
>
> >iii- rtcp-mux-exclusive is defined as bidirectional.
>
> >
>
> >Adding all these together, I fail to see the rationale behind the 
> <new></new> text. Therefore, I think “4) Do Nothing” is the way to go 
> here.
>
> Note that the <new></new> text is already in draft-mux-exclusive, and 
> option 4) would not remove it.
>
> The issue is that, based on the update in RFC8035, the text is no 
> longer within the “4th paragraph”, as RFC8035 adds new paragraphs, and 
> my question is whether we should somehow point that out within 
> draft-mux-exclusive.
>
> >OTOH, I still think that draft-mux-exclusive explicitly should indicate 
> that “rtcp-mux-exclusive itself is bidirectional” and that RFC8035 
> updated RFC5761 to clarify that “rtcp-mux is birectional”.
>
> I think we should look at that suggestion (which, btw, I think seems 
> reasonable) as a separate thing. THIS issue is more administrative.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email protected]] *On Behalf Of *Christer 
> Holmberg
> *Sent:* Friday, April 28, 2017 5:57 AM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and 
> RFC 8035
>
> Hi,
> draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 
> also updates section 5.1.1 of RFC 8035.
> draft-mux-exclusive keeps the existing text, and adds some new 
> (<new></new>).
> *Update to 4th paragraph of section 5.1.1*
> OLD TEXT (RFC 5761):
>    If the answer does not contain an "a=rtcp-mux" attribute, the offerer
>    MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
>    it should send and receive RTCP on a port allocated according to the
>    usual port-selection rules (either the port pair, or a signalled port
>    if the "a=rtcp:" attribute [10] is also included).  This will occur
>    when talking to a peer that does not understand the "a=rtcp-mux"
>    attribute.
> NEW TEXT (RFC 8035):
>    If the answer does not contain an "a=rtcp-mux" attribute, the offerer
>    MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
>    it should send and receive RTCP on a port allocated according to the
>    usual port-selection rules (either the port pair, or a signalled port
>    if the "a=rtcp:" attribute [10] is also included).  This will occur
>    when talking to a peer that does not understand the "a=rtcp-mux"
>    attribute.
> As we can see, the original text is identical in 5761 and 8035. So, 
> there is no clash. So far so good.
> draft-mux-exclusive keeps the existing text, and adds some new 
> (<new></new>).
> NEW TEXT (draft-mux-exclusive):
>    If the answer does not contain an "a=rtcp-mux" attribute, the offerer
>    MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
>    it should send and receive RTCP on a port allocated according to the
>    usual port-selection rules (either the port pair, or a signaled port
>    if the "a=rtcp:" attribute [10] is also included).  This will occur
>    when talking to a peer that does not understand the "a=rtcp-mux"
>    attribute. <new> However, if the offerer indicated in the offer 
> that it is
>    not able to send and receive RTCP on a separate port, the offerer
>    MUST disable the media streams associated with the attribute. The
>    mechanism for indicating that the offerer is not able to send and
>    receive RTCP on a separate port is outside the scope of this
>    specification.</new>
> Now, the issue is that, following the update in RFC 8035, the text is 
> no longer within the 4th paragraph of section 5.1.1. So, should we:
> 1)within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 
> are updated; or
> 2) within draft-mux-exclusive, add a note indicating which paragraph 
> is affected following the update in RFC 8035
> 3)within draft-mux-exclusive, ONLY update RFC 8035; or
> 4)o nothing
> My first reaction would be to go for option 2), as there IMO is no 
> reason to formally update the text in RFC 8035.
> Regards,
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic