Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10
Lorenzo Miniero <lorenzo@meetecho.com> Tue, 31 May 2016 11:12 UTC
Return-Path: <lorenzo@meetecho.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90C12D558 for <straw@ietfa.amsl.com>; Tue, 31 May 2016 04:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipsjQAVwUjAU for <straw@ietfa.amsl.com>; Tue, 31 May 2016 04:12:33 -0700 (PDT)
Received: from smtpweb120.aruba.it (smtpweb120.aruba.it [62.149.158.120]) by ietfa.amsl.com (Postfix) with ESMTP id CE03712D591 for <straw@ietf.org>; Tue, 31 May 2016 04:12:26 -0700 (PDT)
Received: from lminiero ([93.44.66.215]) by smtpcmd03.ad.aruba.it with bizsmtp id 0zCP1t01F4efdGD01zCQ8Y; Tue, 31 May 2016 13:12:25 +0200
Date: Tue, 31 May 2016 13:12:23 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Ben Campbell <ben@nostrum.com>
Message-ID: <20160531131223.176ff3ef@lminiero>
In-Reply-To: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com>
References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/straw/v7NfHrSgkXH6SVa4zk4mNvbUYq4>
Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/straw/>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 11:12:36 -0000
On Fri, 27 May 2016 17:17:35 -0500 "Ben Campbell" <ben@nostrum.com> wrote: > [Oops, I sent that from the wrong address. Please send any discussion > to ben@nostrum.com] > > Hi, > > Here is my review of draft-ietf-straw-b2bua-rtcp-10. I mentioned in > my AD evaluation of a previous version that the draft needed editing > for clarity and readability. In my opinion, this version is improved, > but still a bit rough in places. I have a few substantive comments > and quite a few editorial comments. > > This is not a formal AD evaluation. That will occur after the chairs > submit a new publication request. But I think we need to work through > this before it will be ready for IETF last call. > Hello again, Ben, I just posted a new version of the document (an announcement should get to the ML soon) that tries to address most, if not all, of your points. You can find some additional comments inline on the parts I haven't addressed yet (or I only partly addressed), for one reason or another. To make this more readable, I snipped the parts that I already integrated. > > * The intended status is proposed standard. Do people really expect > b2bua vendors to implement the rules in this draft? Do they expect > existing b2bua implementations to be updated? > I already answered to this in my previous mail, but just to reinstate, I'll leave the decision to WG and chairs/ADs as to what the intended status should be. I personally would keep it a proposed standard, but again wouldn't object to a BCP, if needed. > > * Section 3, last paragraph - This paragraph seems to argue that the > fact that > existing b2buas do not follow specs is a reason to create more > specs. That seems > questionable. > Fair point. I haven't changed that part in the doc yet, as I wanted to be sure I'd get it right, first. Do you think it would be ok to say something along the lines of "due to the mixed nature of B2BUAs, they sometimes can't or won't implement all specifications, so they should at least do this"? > * Section 3.1: > > * Second Paragraph > * "but having them synced during setup would > help nonetheless" - Help how? Please elaborate, or > consider dropping the text in the parentheses. > This came up in a STRAW meeting some time ago. The main scenario for that is WebRTC usage, where browsers typically advertize the SSRCs they're going to use in advance. The RTCWEB RTP usage drafts, specifically, mandates support for signalled SSRC identifiers (see Section 4.8), although it also clarifies that endpoints should be prepared to handle SSRCs that were not advertized. The text in the parenthesis wanted to refer to that kind of usage, but I realize the wording was pretty awful, so I dropped it as you suggested. > > * Section 4 > * Last paragraph, 2nd to last sentence - If you think people will > really pay attention, > then this might be a good place for a MUST or SHOULD > Do you mean where we say "behaviour is unspecified and discouraged"? Or more in general about the fact that a B2BUA can only follow the guidelines when it has access to editing fields without breaking hashes? Not sure which MUST or SHOULD we might add there, considering that, if the media the B2BUA is encrypted, it can't possibly edit RTP related information without disrupting the communication, which in turn means no RTCP editing will be needed/possible either. Do you think a "B2BUAs MUST NOT modify RTP/RTCP data if media is encrypted" to be enough, in case? > > * Section 1, First Paragraph: > > * I'm not sure what "... can lead to unexpected situations the > IETF is trying to address" means. It was an awkward attempt at referring to the scope of the STRAW WG itself. I removed the text after "situations". > > * Third paragraph: > * "It SHOULD NOT, though, blindly forward all SDP > attributes," > - Isn’t > the idea that it should forward any attributes that it > doesn’t > have a specific reason not to forward? (i.e. default to > forwarding?) > The issue here is the reason not to forward itself. In order to figure out whether an attribute can be forwarded or not, the B2BUA must have some knowledge of it and of its impact. What I wanted to highlight in that sentence is that there are attributes that, if left where they are by a B2BUA unaware of their purpose, can actually cause issues. Just think, for instance, of 'rtcp' attribute that is explained in the text, or other attributes supporting features a B2BUA may not support itself. Of course, as you point out there could be reasons to actually keep attributes you don't know about in there, e.g., because they advertize support for an end-to-end feature the B2BUA doesn't need to worry about. Besides, the attributes that can cause issues are probably not that many anyway. I'll think about a way to make this clearer in the next for next version. Thanks! Lorenzo
- [straw] Review of draft-ietf-straw-b2bua-rtcp-10 Ben Campbell
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Lorenzo Miniero
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Lorenzo Miniero
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Ben Campbell
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Ben Campbell
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Christer Holmberg
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Lorenzo Miniero
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Ben Campbell
- Re: [straw] Review of draft-ietf-straw-b2bua-rtcp… Lorenzo Miniero