Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10

Lorenzo Miniero <lorenzo@meetecho.com> Fri, 10 June 2016 10:29 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 84F0212D0CA for <straw@ietfa.amsl.com>; Fri, 10 Jun 2016 03:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 cH0-66NBgA2e for <straw@ietfa.amsl.com>; Fri, 10 Jun 2016 03:29:34 -0700 (PDT)
Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBCD12D155 for <straw@ietf.org>; Fri, 10 Jun 2016 03:29:33 -0700 (PDT)
Received: from lminiero ([95.238.194.65]) by smtpcmd09.ad.aruba.it with bizsmtp id 4yVW1t00u1R7qa701yVXmr; Fri, 10 Jun 2016 12:29:31 +0200
Date: Fri, 10 Jun 2016 12:29:30 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Ben Campbell <ben@nostrum.com>
Message-ID: <20160610122930.7d11aa08@lminiero>
In-Reply-To: <D1190F77-528C-442B-AD7B-8CB8226F1592@nostrum.com>
References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> <D1190F77-528C-442B-AD7B-8CB8226F1592@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: <https://mailarchive.ietf.org/arch/msg/straw/AeXaRmH978Qn4cMXYTa386Rg2gA>
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: Fri, 10 Jun 2016 10:29:36 -0000

On Thu, 09 Jun 2016 15:51:41 -0500
"Ben Campbell" <ben@nostrum.com> wrote:

> Hi,
> 
> Comments to your email inline. I removed sections that don't seem to 
> need further discussion. I will send any comments about the new draft 
> revision separately.
> 


Hello Ben,

thanks for the additional comments! I just pushed a new version of the
document that addresses the final points of the discussion.

I'll also send a new mail to the list shortly to foster discussion on
the "standards track vs BCP" scope for the document, as you suggested.

Thanks,
Lorenzo


> Thanks!
> 
> Ben.
> 
> On 31 May 2016, at 6:12, Lorenzo Miniero wrote:
> 
> > On Fri, 27 May 2016 17:17:35 -0500
> > "Ben Campbell" <ben@nostrum.com> wrote:  
> 
> [...]
> 
> >
> >
> > 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.
> >  
> 
> Let's leave this as PS for now, but realize that may change at some 
> point as we go forward. As far as getting the WG's opinion goes, it 
> might be worth it to send a separate email to the list about this one 
> question. Otherwise people may miss it buried in the rest of the
> review comments.
> 
> 
> >  
> >>
> >> * 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"?  
> 
> I think that logic is reasonable.
> 
> [...]
> 
> >
> >  
> >>
> >> * 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?  
> 
> In retrospect, I wrote that comment without thinking about it in
> context of b2bua-dtls-srtp. Since you already reference that draft, I
> withdraw that comment. No change is really needed.
> 
> >  
> >>
> >>      * 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.
> >  
> 
> Aren't those attributes that the b2bua must, by definition, know
> about and have a "specific reason" not to forward.
> 
> > 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.  
> 
> Right. One of the big issues with b2buas is that they tend to make
> SIP networks brittle to new features. I think we need to discourage
> that as much as possible. I realize we can't write guidance on how to
> handle a "foo" attribute that works in all cases of "foo", but we can
> at least err on the side of letting things through.
> 
> 
> 
> >
> > I'll think about a way to make this clearer in the next for next
> > version.  
> 
> Okay.
>