From nobody Thu Jun 9 13:51:41 2016 Return-Path: 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 848C512D5DB; Thu, 9 Jun 2016 13:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 jxM_zOTDVTjt; Thu, 9 Jun 2016 13:51:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B0012D106; Thu, 9 Jun 2016 13:51:38 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u59KpVZc090869 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2016 15:51:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Lorenzo Miniero" Date: Thu, 09 Jun 2016 15:51:41 -0500 Message-ID: In-Reply-To: <20160531131223.176ff3ef@lminiero> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 20:51:39 -0000 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. Thanks! Ben. On 31 May 2016, at 6:12, Lorenzo Miniero wrote: > On Fri, 27 May 2016 17:17:35 -0500 > "Ben Campbell" 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. From nobody Thu Jun 9 14:04:12 2016 Return-Path: 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 5A59B12D9FE; Thu, 9 Jun 2016 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 N9Frvjb_PdPN; Thu, 9 Jun 2016 14:04:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E3212D9FA; Thu, 9 Jun 2016 14:04:06 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u59L427E092211 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2016 16:04:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Lorenzo Miniero" Date: Thu, 09 Jun 2016 16:04:11 -0500 Message-ID: In-Reply-To: References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5685C143-336F-4A9E-89A5-86137AB47C17_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:04:11 -0000 --=_MailMate_5685C143-336F-4A9E-89A5-86137AB47C17_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit I did a quick scan of the new revision, and I think it's addressed most of my editorial concerns. I encourage the chairs to re-request publication as soon as the authors address the one or two outstanding items mentioned below. Thanks! Ben. On 9 Jun 2016, at 15:51, Ben Campbell 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. > > Thanks! > > Ben. > > On 31 May 2016, at 6:12, Lorenzo Miniero wrote: > >> On Fri, 27 May 2016 17:17:35 -0500 >> "Ben Campbell" 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. --=_MailMate_5685C143-336F-4A9E-89A5-86137AB47C17_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I did a quick scan of the new revision, and I think it's = addressed most of my editorial concerns. I encourage the chairs to re-req= uest publication as soon as the authors address the one or two outstandin= g items mentioned below.

Thanks!

Ben.

On 9 Jun 2016, at 15:51, Ben Campbell wrote:

Hi,

Comments to your email inline. I removed sections that do= n't seem to need further discussion. I will send any comments about the n= ew draft revision separately.

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 wro= te:

[...]

Hello again, Ben,

I just posted a new version of the document (an announcem= ent 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 chan= ge at some point as we go forward. As far as getting the WG's opinion goe= s, it might be worth it to send a separate email to the list about this o= ne question. Otherwise people may miss it buried in the rest of the revie= w 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, a= s 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 di= scouraged"? 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 m= edia is
encrypted" to be enough, in case?

In retrospect, I wrote that comment without thinking abou= t it in context of b2bua-dtls-srtp. Since you already reference that draf= t, I withdraw that comment. No change is really needed.

 * Third paragraph:
     * "It SHOULD NOT, though, blindly forward all SDP

attributes,"
- Isn=E2=80=99t
the idea that it should forward any attributes that it
doesn=E2=80=99t
have a specific reason not to forward? (i.e. default to
forwarding?)

The issue here is the reason not to forward itself. In or= der 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 definitio= n, know about and have a "specific reason" not to forward.

Of course, as you point out there could be reasons to act= ually 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 ten= d to make SIP networks brittle to new features. I think we need to discou= rage that as much as possible. I realize we can't write guidance on how t= o handle a "foo" attribute that works in all cases of "foo", but we can a= t least err on the side of letting things through.

I'll think about a way to make this clearer in the next f= or next
version.

Okay.

--=_MailMate_5685C143-336F-4A9E-89A5-86137AB47C17_=-- From nobody Thu Jun 9 14:07:43 2016 Return-Path: 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 44BAC12D9FE; Thu, 9 Jun 2016 14:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 83wZVKQT6QSY; Thu, 9 Jun 2016 14:07:39 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2944312D7AD; Thu, 9 Jun 2016 14:07:37 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-3f-5759da979654 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.76.27088.79AD9575; Thu, 9 Jun 2016 23:07:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 23:07:35 +0200 From: Christer Holmberg To: Ben Campbell , Lorenzo Miniero Thread-Topic: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 Thread-Index: AQHRuGWWsQ+3wCTBkUiMBFu7v3tzqp/SyEqAgA7G1oCAAAN+gIAAIntt Date: Thu, 9 Jun 2016 21:07:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38046839@ESESSMB209.ericsson.se> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38046839ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7hO6MW5HhBnPec1nM7zzNbrHy9Fs2 i+1bFjBZ3Gp+zOrA4rFkyU8mj46H99k9Zu18whLAHMVlk5Kak1mWWqRvl8CVsWLiGcaCxVkV H7efZG5g7IvoYuTkkBAwkdjzbBE7hC0mceHeerYuRi4OIYEjjBL9X68yQziLGSUWP1rD1MXI wcEmYCHR/U8bpEFEwEvi5puVbCA2s0CdxKvDn5lAbGEBW4k1fS1sEDV2Ek/vf4Ky3SS+tH4A s1kEVCR+XesAs3kFfCW+HG1ghdh1mlFi/sb9rCAJTgF7iZV//oFdxwh03fdTa5gglolLNH1Z yQpxtYDEkj3nmSFsUYmXj/+xQtTkSzz+s5EdYoGgxMmZT1gmMIrMQtI+C0nZLCRlEHEDiS/v b0PZ2hLLFr5mhrD1Jbrfn2ZCFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzDuDm75 bbCD8eVzx0OMAhyMSjy8CVMjwoVYE8uKK3MPMUpwMCuJ8D68GBkuxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgbH6n13A5H3P2OWOFYrHP7m5dEOm4wJG lxWHXgTavNFRaShydtvAsX2dQbeAR+WLNKanXe8/z/y/eWZj+MHXapqvA50rj7w3NGd5f5ih 3CQ/S8/2/6JZ28LEM+4FFlsscJ9mYxHVZ8HjJyTleWfOsuhDZq0/wouZ3jsksLH1ZcxclP4g 737SKiWW4oxEQy3mouJEACSIdb+3AgAA Archived-At: Cc: "draft-ietf-straw-b2bua-rtcp.all@ietf.org" , "straw@ietf.org" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:07:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38046839ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable (As co-chair) ACK! Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD10/=FD06/=FD2016 00:04 To: Lorenzo Miniero Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org; straw@ietf.org; Christer Holmber= g Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 I did a quick scan of the new revision, and I think it's addressed most of = my editorial concerns. I encourage the chairs to re-request publication as = soon as the authors address the one or two outstanding items mentioned belo= w. Thanks! Ben. On 9 Jun 2016, at 15:51, Ben Campbell wrote: Hi, Comments to your email inline. I removed sections that don't seem to need f= urther discussion. I will send any comments about the new draft revision se= parately. 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 b2b= ua vendors to implement the rules in this draft? Do they expect existing b2= bua 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 a= s 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 fa= ct that existing b2buas do not follow specs is a reason to create more spec= s. 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 re= ally 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 c= omment. No change is really needed. * Third paragraph: * "It SHOULD NOT, though, blindly forward all SDP attributes," - Isn=92t the idea that it should forward any attributes that it doesn=92t 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 netw= orks 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" attri= bute 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. --_000_7594FB04B1934943A5C02806D1A2204B38046839ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
(As co-chair)=

ACK!

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD10= /=FD06/=FD2016 00:04
To: Lorenzo Miniero
Cc: draft-ietf-straw-b2b= ua-rtcp.all@ietf.org; straw@ietf.org; Christer Holmberg
Subject: Re: [= straw] Review of draft-ietf-straw-b2bua-rtcp-10

I did a quick scan of the new revision, and I think it's ad= dressed most of my editorial concerns. I encourage the chairs to re-request= publication as soon as the authors address the one or two outstanding item= s mentioned below.

Thanks!

Ben.

On 9 Jun 2016, at 15:51, Ben Campbell 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 d= raft revision separately.

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 announcemen= t 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 b2bu= a 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, i= t might be worth it to send a separate email to the list about this one que= stion. 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<= br> 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 i= f 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=92t
the idea that it should forward any attributes that it
doesn=92t
have a specific reason not to forward? (i.e. default to
forwarding?)

The issue here is the reason not to forward itself. In orde= r 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 actua= lly 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 hand= le a "foo" attribute that works in all cases of "foo", but we can at least err on the side of letti= ng things through.

I'll think about a way to make this clearer in the next for= next
version.

Okay.

--_000_7594FB04B1934943A5C02806D1A2204B38046839ESESSMB209erics_-- From nobody Fri Jun 10 03:27:26 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4297612D155; Fri, 10 Jun 2016 03:27:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610102722.15471.1079.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 03:27:22 -0700 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-12.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:27:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-12.txt Pages : 17 Date : 2016-06-10 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 03:29:38 2016 Return-Path: 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 ; 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 ; 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 ; 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 To: "Ben Campbell" Message-ID: <20160610122930.7d11aa08@lminiero> In-Reply-To: References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> 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: Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:29:36 -0000 On Thu, 09 Jun 2016 15:51:41 -0500 "Ben Campbell" wrote: > Hi, >=20 > Comments to your email inline. I removed sections that don't seem to=20 > need further discussion. I will send any comments about the new draft=20 > revision separately. >=20 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! >=20 > Ben. >=20 > On 31 May 2016, at 6:12, Lorenzo Miniero wrote: >=20 > > On Fri, 27 May 2016 17:17:35 -0500 > > "Ben Campbell" wrote: =20 >=20 > [...] >=20 > > > > > > Hello again, Ben, > > > > I just posted a new version of the document (an announcement should=20 > > get > > to the ML soon) that tries to address most, if not all, of your=20 > > 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. > > > > =20 > >> > >> * 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? > >> =20 > > > > > > 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. > > =20 >=20 > Let's leave this as PS for now, but realize that may change at some=20 > point as we go forward. As far as getting the WG's opinion goes, it=20 > might be worth it to send a separate email to the list about this one=20 > question. Otherwise people may miss it buried in the rest of the > review comments. >=20 >=20 > > =20 > >> > >> * 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. > >> =20 > > > > > > 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"? =20 >=20 > I think that logic is reasonable. >=20 > [...] >=20 > > > > =20 > >> > >> * 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 > >> =20 > > > > > > 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? =20 >=20 > 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. >=20 > > =20 > >> > >> * Third paragraph: > >> * "It SHOULD NOT, though, blindly forward all SDP > >> attributes," > >> - Isn=E2=80=99t > >> the idea that it should forward any attributes that it > >> doesn=E2=80=99t > >> have a specific reason not to forward? (i.e. default to > >> forwarding?) > >> =20 > > > > > > 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=20 > > text, > > or other attributes supporting features a B2BUA may not support=20 > > itself. > > =20 >=20 > Aren't those attributes that the b2bua must, by definition, know > about and have a "specific reason" not to forward. >=20 > > 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. =20 >=20 > 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. >=20 >=20 >=20 > > > > I'll think about a way to make this clearer in the next for next > > version. =20 >=20 > Okay. >=20 From nobody Fri Jun 10 03:46:40 2016 Return-Path: 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 A741812D1E4 for ; Fri, 10 Jun 2016 03:46:38 -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 y1dWJBRJpdTj for ; Fri, 10 Jun 2016 03:46:36 -0700 (PDT) Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3919912D0A3 for ; Fri, 10 Jun 2016 03:46:36 -0700 (PDT) Received: from lminiero ([95.238.194.65]) by smtpcmd09.ad.aruba.it with bizsmtp id 4ymb1t0071R7qa701ymbFS; Fri, 10 Jun 2016 12:46:35 +0200 Date: Fri, 10 Jun 2016 12:46:34 +0200 From: Lorenzo Miniero To: straw@ietf.org Message-ID: <20160610124634.028fd73e@lminiero> 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=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [straw] RTCP document: Proposed Standard or Best Current Practice? 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:46:38 -0000 Hi all, I just published a new version of the RTCP document, that hopefully now addresses all the very useful comments Ben provided in his latest detailed review: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-12 One last notable point remains to be clarified, that is related to the intended scope of the document. The draft is currently "Standards Track", something Ben is not sure about, considering this might mean expecting B2BUA developers to implement this. Besides, the document is more trying to discipline the behaviour of components that, for one reason or another, are not always adhering to specifications that should already prevent the broken behaviours the draft tries to address. In order to make sure the WG would be aware of this discussion and not have it buried under the other discussions we had around the document itself, Ben suggested to open a new post to discuss specifically about this and get the WG's feeling on the matter. As I said a few posts ago, I'd rather keep the document "Proposed Standard" than changing it to a "Best Current Practice", mainly because we want it to have an actual impact and stress the importance of doing things right in that context. Besides, the DTLS-SRTP document was published as "Standards Track" too, and I believe the aim of the two documents was similar. Anyway, I obviously wouldn't fight changing it to "Best Current Practice", as we are talking about guidelines on the behaviour to follow. What is your opinion on this? Any reason to change the scope of the document, or any reason not to? Thanks! Lorenzo From nobody Fri Jun 10 03:50:51 2016 Return-Path: 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 BA5B412D1E4 for ; Fri, 10 Jun 2016 03:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LQnSsHWM4Wys for ; Fri, 10 Jun 2016 03:50:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDEA12D1C2 for ; Fri, 10 Jun 2016 03:50:45 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b8-575a9b82d359 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.51.27088.28B9A575; Fri, 10 Jun 2016 12:50:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 12:50:42 +0200 From: Christer Holmberg To: Lorenzo Miniero , "straw@ietf.org" Thread-Topic: [straw] RTCP document: Proposed Standard or Best Current Practice? Thread-Index: AQHRwwVgA8PWBuH6+Uy0vUXIY9jwzp/il4IA Date: Fri, 10 Jun 2016 10:50:41 +0000 Message-ID: References: <20160610124634.028fd73e@lminiero> In-Reply-To: <20160610124634.028fd73e@lminiero> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5DDEF16A581D944EB6B1B40EFE8DCE65@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7rm7T7Khwg+fXNSy2b1nAZHGr+TGr A5PHkiU/mTw6Ht5nD2CK4rJJSc3JLEst0rdL4MrY3uVVsFmg4k/zLdYGxt28XYycHBICJhJn Ts1kg7DFJC7cWw9mCwkcYZSYvTS8i5ELyF7CKPHx5n+WLkYODjYBC4nuf9ogNSICvhJf3h5l AbGFBQIl3hzoZoSIB0ksWfOPGcI2kti+cRdYDYuAqsT+aR1MIGN4BawkGp/pQKzSk7jbchOs lVNAX+Jfw2QwmxHonO+n1jCB2MwC4hK3nsxngjhTQGLJnvPMELaoxMvH/1hBbFGgOV/uzWOE iCtKtD9tYITo1ZO4MXUKG4RtLbH3zGRWCFtbYtnC12BzeAUEJU7OfMIygVF8FpJ1s5C0z0LS PgtJ+ywk7QsYWVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbawS2/DXYwvnzueIhRgINR iYf3wbPIcCHWxLLiytxDjBIczEoivH3To8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwX EkhPLEnNTk0tSC2CyTJxcEo1MO7w2asxP+9xZ5t93P+XAjlMPb2/up984Dz2L9+w++jG1sXm M2dLnpw5M0837eaizuybzOw3cl64uG2XE3iwISomJyjsldm+rM0uljs/i1f1v0yqN32xTzCY veHX3EzO1JMzNrYf/6sZF8HyvKDoZr/i0n8m0yYtar5x9sKpV8qa3Q5OHafudSixFGckGmox FxUnAgCTjG08sAIAAA== Archived-At: Subject: Re: [straw] RTCP document: Proposed Standard or Best Current Practice? 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:50:48 -0000 (As co-chair) Hi, Just to point out that, apart from the taxonomy document, all STRAW deliverables so far haven been =B3Standards Track=B2. Regards, Christer On 10/06/16 13:46, "straw on behalf of Lorenzo Miniero" wrote: >Hi all, > >I just published a new version of the RTCP document, that hopefully >now addresses all the very useful comments Ben provided in his >latest detailed review: > >https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-12 > >One last notable point remains to be clarified, that is related to the >intended scope of the document. The draft is currently "Standards >Track", something Ben is not sure about, considering this might mean >expecting B2BUA developers to implement this. Besides, the document is >more trying to discipline the behaviour of components that, for one >reason or another, are not always adhering to specifications that >should already prevent the broken behaviours the draft tries to >address. In order to make sure the WG would be aware of this discussion >and not have it buried under the other discussions we had around the >document itself, Ben suggested to open a new post to discuss >specifically about this and get the WG's feeling on the matter. > >As I said a few posts ago, I'd rather keep the document "Proposed >Standard" than changing it to a "Best Current Practice", mainly because >we want it to have an actual impact and stress the importance of doing >things right in that context. Besides, the DTLS-SRTP document was >published as "Standards Track" too, and I believe the aim of the two >documents was similar. Anyway, I obviously wouldn't fight changing it to >"Best Current Practice", as we are talking about guidelines on the >behaviour to follow. > >What is your opinion on this? Any reason to change the scope of the >document, or any reason not to? > >Thanks! >Lorenzo > >_______________________________________________ >straw mailing list >straw@ietf.org >https://www.ietf.org/mailman/listinfo/straw From nobody Wed Jun 15 23:13:16 2016 Return-Path: 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 7636F12D0BD for ; Wed, 15 Jun 2016 23:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 00MERKHSajKG for ; Wed, 15 Jun 2016 23:13:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF52412B057 for ; Wed, 15 Jun 2016 23:13:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-b1-576243731ec0 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DD.BC.18043.37342675; Thu, 16 Jun 2016 08:13:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Thu, 16 Jun 2016 08:13:07 +0200 From: Christer Holmberg To: Christer Holmberg , Lorenzo Miniero , "straw@ietf.org" Thread-Topic: [straw] RTCP document: Proposed Standard or Best Current Practice? Thread-Index: AQHRx5Ymx4xElBk6gEu7jber2MikMw== Date: Thu, 16 Jun 2016 06:13:06 +0000 Message-ID: References: <20160610124634.028fd73e@lminiero> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7n26Jc1K4wZO7nBbbtyxgsrjV/JjV gcljyZKfTB4dD++zBzBFcdmkpOZklqUW6dslcGU0H9vJVPBHumLPNL8GxgXSXYycHBICJhLL u5+zQdhiEhfurQeyuTiEBI4wSqyZ1wXlLGGUmH3hN2MXIwcHm4CFRPc/bZAGEYFmRonlexhB bGGBQIk3B7oZIeJBEkvW/GOGsPUkLjZfYgKxWQRUJaZs2g+2jFfASmL+8UVg9UIC8RIPD08B q+cUsJY4+Ho3O4jNCHTQ91NrwHqZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgtiiQLu+3JsH dqaEgJLEtK1pEK1aEl9+7GODsK0lDt84xAphK0pM6X7IDnGOoMTJmU9YJjCKz0KybRaS9llI 2mchaZ+FpH0BI+sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBYO7jlt9UOxoPPHQ8xCnAw KvHwPjifGC7EmlhWXJl7iFGCg1lJhPeBfVK4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rh QgLpiSWp2ampBalFMFkmDk6pBsb5NvIxuzMOnzxe9cfs4slPrOwn1Aq3LTpjsuL3Er71L6pD s2WMFk5Yx6giyXZVaMGEiDuyOVHzfj0VkWKQmHGr5V6V+/cpDOf/cB+s2nQkIFOtWPiPPJfZ 24vrEnWWM/39q7SWL/2IvrWG+NxPZ1k83PfER3DMWsm1va/ulfzs/o38vpmaOoxKLMUZiYZa zEXFiQAUoKPJsQIAAA== Archived-At: Subject: Re: [straw] RTCP document: Proposed Standard or Best Current Practice? 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 06:13:13 -0000 KEFzIGNvLWNoYWlyKQ0KDQpIaSwNCg0KRG9lcyBhbnlvbmUgb2JqZWN0IHRvIG1vdmluZyBmb3J3 YXJkIGFzIKGwU3RhbmRhcmRzIFRyYWNrobEsIGNvbnNpZGVyaW5nDQp0aGF0IGlzIHdoYXQgd2Wh r2xsIHVzZWQgZm9yIHRoZSBvdGhlciBTVFJBVyBkZWxpdmVyYWJsZXMgdG9vPw0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDEwLzA2LzE2IDEzOjUwLCAic3RyYXcgb24gYmVoYWxmIG9m IENocmlzdGVyIEhvbG1iZXJnIg0KPHN0cmF3LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj4oQXMgY28tY2hhaXIp DQo+DQo+SGksDQo+DQo+SnVzdCB0byBwb2ludCBvdXQgdGhhdCwgYXBhcnQgZnJvbSB0aGUgdGF4 b25vbXkgZG9jdW1lbnQsIGFsbCBTVFJBVw0KPmRlbGl2ZXJhYmxlcyBzbyBmYXIgaGF2ZW4gYmVl biCp+FN0YW5kYXJkcyBUcmFja6n3Lg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4N Cj5PbiAxMC8wNi8xNiAxMzo0NiwgInN0cmF3IG9uIGJlaGFsZiBvZiBMb3JlbnpvIE1pbmllcm8i DQo+PHN0cmF3LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxvcmVuem9AbWVldGVjaG8u Y29tPiB3cm90ZToNCj4NCj4+SGkgYWxsLA0KPj4NCj4+SSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyB2 ZXJzaW9uIG9mIHRoZSBSVENQIGRvY3VtZW50LCB0aGF0IGhvcGVmdWxseQ0KPj5ub3cgYWRkcmVz c2VzIGFsbCB0aGUgdmVyeSB1c2VmdWwgY29tbWVudHMgQmVuIHByb3ZpZGVkIGluIGhpcw0KPj5s YXRlc3QgZGV0YWlsZWQgcmV2aWV3Og0KPj4NCj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc3RyYXctYjJidWEtcnRjcC0xMg0KPj4NCj4+T25lIGxhc3Qgbm90YWJsZSBw b2ludCByZW1haW5zIHRvIGJlIGNsYXJpZmllZCwgdGhhdCBpcyByZWxhdGVkIHRvIHRoZQ0KPj5p bnRlbmRlZCBzY29wZSBvZiB0aGUgZG9jdW1lbnQuIFRoZSBkcmFmdCBpcyBjdXJyZW50bHkgIlN0 YW5kYXJkcw0KPj5UcmFjayIsIHNvbWV0aGluZyBCZW4gaXMgbm90IHN1cmUgYWJvdXQsIGNvbnNp ZGVyaW5nIHRoaXMgbWlnaHQgbWVhbg0KPj5leHBlY3RpbmcgQjJCVUEgZGV2ZWxvcGVycyB0byBp bXBsZW1lbnQgdGhpcy4gQmVzaWRlcywgdGhlIGRvY3VtZW50IGlzDQo+Pm1vcmUgdHJ5aW5nIHRv IGRpc2NpcGxpbmUgdGhlIGJlaGF2aW91ciBvZiBjb21wb25lbnRzIHRoYXQsIGZvciBvbmUNCj4+ cmVhc29uIG9yIGFub3RoZXIsIGFyZSBub3QgYWx3YXlzIGFkaGVyaW5nIHRvIHNwZWNpZmljYXRp b25zIHRoYXQNCj4+c2hvdWxkIGFscmVhZHkgcHJldmVudCB0aGUgYnJva2VuIGJlaGF2aW91cnMg dGhlIGRyYWZ0IHRyaWVzIHRvDQo+PmFkZHJlc3MuIEluIG9yZGVyIHRvIG1ha2Ugc3VyZSB0aGUg V0cgd291bGQgYmUgYXdhcmUgb2YgdGhpcyBkaXNjdXNzaW9uDQo+PmFuZCBub3QgaGF2ZSBpdCBi dXJpZWQgdW5kZXIgdGhlIG90aGVyIGRpc2N1c3Npb25zIHdlIGhhZCBhcm91bmQgdGhlDQo+PmRv Y3VtZW50IGl0c2VsZiwgQmVuIHN1Z2dlc3RlZCB0byBvcGVuIGEgbmV3IHBvc3QgdG8gZGlzY3Vz cw0KPj5zcGVjaWZpY2FsbHkgYWJvdXQgdGhpcyBhbmQgZ2V0IHRoZSBXRydzIGZlZWxpbmcgb24g dGhlIG1hdHRlci4NCj4+DQo+PkFzIEkgc2FpZCBhIGZldyBwb3N0cyBhZ28sIEknZCByYXRoZXIg a2VlcCB0aGUgZG9jdW1lbnQgIlByb3Bvc2VkDQo+PlN0YW5kYXJkIiB0aGFuIGNoYW5naW5nIGl0 IHRvIGEgIkJlc3QgQ3VycmVudCBQcmFjdGljZSIsIG1haW5seSBiZWNhdXNlDQo+PndlIHdhbnQg aXQgdG8gaGF2ZSBhbiBhY3R1YWwgaW1wYWN0IGFuZCBzdHJlc3MgdGhlIGltcG9ydGFuY2Ugb2Yg ZG9pbmcNCj4+dGhpbmdzIHJpZ2h0IGluIHRoYXQgY29udGV4dC4gQmVzaWRlcywgdGhlIERUTFMt U1JUUCBkb2N1bWVudCB3YXMNCj4+cHVibGlzaGVkIGFzICJTdGFuZGFyZHMgVHJhY2siIHRvbywg YW5kIEkgYmVsaWV2ZSB0aGUgYWltIG9mIHRoZSB0d28NCj4+ZG9jdW1lbnRzIHdhcyBzaW1pbGFy LiBBbnl3YXksIEkgb2J2aW91c2x5IHdvdWxkbid0IGZpZ2h0IGNoYW5naW5nIGl0IHRvDQo+PiJC ZXN0IEN1cnJlbnQgUHJhY3RpY2UiLCBhcyB3ZSBhcmUgdGFsa2luZyBhYm91dCBndWlkZWxpbmVz IG9uIHRoZQ0KPj5iZWhhdmlvdXIgdG8gZm9sbG93Lg0KPj4NCj4+V2hhdCBpcyB5b3VyIG9waW5p b24gb24gdGhpcz8gQW55IHJlYXNvbiB0byBjaGFuZ2UgdGhlIHNjb3BlIG9mIHRoZQ0KPj5kb2N1 bWVudCwgb3IgYW55IHJlYXNvbiBub3QgdG8/DQo+Pg0KPj5UaGFua3MhDQo+PkxvcmVuem8NCj4+ DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnN0 cmF3IG1haWxpbmcgbGlzdA0KPj5zdHJhd0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0cmF3DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5zdHJhdyBtYWlsaW5nIGxpc3QNCj5zdHJhd0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RyYXcNCg0K