From nobody Tue Nov 22 10:56:39 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 EDA27129407; Tue, 22 Nov 2016 10:56:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147984099592.30363.3881989144560055018.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 10:56:35 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-straw-b2bua-rtcp-15=3A_=28with_COMMENT=29?= 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: Tue, 22 Nov 2016 18:56:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- High level comment: This document mainly talks about cases where the SSRC or the RTP seq# is changed. Are they no other fields that could be changed as well? Would there need to be additional guidance (in 3.2) then, or are SSRC and seq# more special then other fields? And why would a relay change those fields? Wouldn't it be appropriate to give the guidance somewhere that those fields SHOULD NOT be changed!?! Smaller comments: section 3.1: "Apart from the mentioned attributes, B2BUAs SHOULD forward all other SDP attributes they don't have a reason not to forward, in order to avoid breaking additional functionality endpoints may be relying on." Shouldn't that be a MUST (with all the exceptions given already)...? "...a B2BUA MAY rewrite CNAME items if any potential collision is detected..." And why is that a MAY? Shouldn't this be a SHOULD at least? From nobody Fri Nov 25 07:07:45 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 0C0CC12A2F1; Fri, 25 Nov 2016 07:07:44 -0800 (PST) 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 A2GecvKvDm_h; Fri, 25 Nov 2016 07:07:39 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B267C12A420; Fri, 25 Nov 2016 06:49:33 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-60-58384f7b6b90 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 0E.57.32482.B7F48385; Fri, 25 Nov 2016 15:49:32 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Fri, 25 Nov 2016 15:49:03 +0100 To: "tsv-art@ietf.org" , , "tsv-ads@tools.ietf.org" From: Magnus Westerlund Message-ID: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> Date: Fri, 25 Nov 2016 15:49:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM2K7tG6Nv0WEwbafrBa3mh+zWkyb95HR YtaeRSwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bfRb/YCtYoVExcNJm5gXGDZBcj J4eEgIlE/7ZlzF2MXBxCAusYJXZO+ckK4SxnlDg/fT0rSJWIQIHE56d9bCA2m4CFxM0fjUA2 B4ewgKXEj8UCIGFeAXuJC91/mEBsFgFViVXdlxhBbFGBGIlP6/6yQ9QISpyc+YQFpJUZqP7B 1jKQMLOAvETz1tnMILaQgLZEQ1MH6wRG3llIOmYhdMxC0rGAkXkVo2hxanFSbrqRsV5qUWZy cXF+nl5easkmRmBQHdzyW3UH4+U3jocYBTgYlXh4N1iYRwixJpYVV+YeYpTgYFYS4Y31sYgQ 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgdH25YOQtDNC S9lMblzcFC/0TOiHrKzWPMZHdu13A3umdC78WRllOWE5n1N+9sT5HEc+Kv5wOyD7L0c+JzF3 V5LbnEmLq19tyOsTTX1ovLayfC+3hLBegobJlIfVv4J+qKyZ5azw/n/GWdawZfJFX2UPad17 kDe/j8Hx26024/mfzgm7z0nOP6nEUpyRaKjFXFScCABxCzrwJgIAAA== Archived-At: Subject: [straw] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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, 25 Nov 2016 15:07:44 -0000 Hi, I have done this review as part of the TSVART's task to review documents with potential transport impact. Below you will find a number of comments on issues that I found. I think there are several significant issues below: 2, 3, 4, and 6. The rest would be good to address. I am sorry that this review is late in the process. 1. Section 3.1: I am surprised that there are no discussion for a Media Relay regarding a=rtcp-mux and its impact on where RTP/RTCP packets will flow and if a=rtcp attribute is at all relevant. I think there would be clearer if one in the context of a=rtcp also discusses a=rtcp-mux and how that impacts the actual transport layer flows that will result. 2. Section 3.1: While [RFC7022] can prevent this from happening, there may be implementations that don't make use of it. As such, a B2BUA MAY rewrite CNAME items if any potential collision is detected, even in the Media Relay case. If a B2BUA does indeed decide to rewrite CNAME items, though, then it MUST generate new CNAMEs following [RFC7022]. While the Media Relay is generally safe in regards to the use of RTP header extensions, this text above actually requires translation of the RTP header extension identified as "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]. Then also that needs to be translated. 3. Section 3.2: Also this section will need a discussion of RTP header extensions. So one set of header extensions that may be translated are any SDES items. So CNAME, MID, RID should be considered. Especially MID and RID as they are directly related to SDP they are likely to need translation. However, also the set of transport related information, like the ones that has been proposed for use with RMCAT but have not yet been approved. As they can have packet specific information, if one starts removing packets, then one may need to consider these also. 4. Section 3.2: SR Entry: I like to note that if an Media Relay act in the role of a SFU, then it needs to track in the outgoing SR, the relevant number of packets sent, total amount of bytes sent to that particular receiver, rather than what was received. Note, that as this is SR specific, it does not apply to RR. I note that SFU also requires sequence number rewriting, which affects other RTCP packet type that reference sequence numbers, like NACK. 5. Section 3.2: REMB: [I-D.alvestrand-rmcat-remb] A media-aware B2BUA MUST properly rewrite the additional SSRC identifier(s) in REMB packets, if it changed the related RTP SSRC of the media sender. I assume that you have had some thought about the need to include this individual proposal. I do note that it is not clear if this ever will be published, especially considering the RMCAT WG's work on a different feedback format. 6. Section 3.2: In fact, while a Media Relay B2BUA may choose to use it on the side that supports it and not on the side that doesn't, there are other aspects to take into account before doing so. The above sentence indicates that it is okay to use reduced sized RTCP on one leg but not the other. I would strongly discourage that due to the issues that are raised. If one is going to "forward" a reduced size RTCP packet, that needs to be upgraded to a compliant RTCP compound packet. Which makes it bigger, and then RTCP bandwidth becomes an issue. I think the above sentence should be clearer that there are real issues here. And I think the conclusion should be to use it only if both legs support it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Nov 29 03:31:56 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 74D72129735 for ; Tue, 29 Nov 2016 03:31:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 BcJQl46h58mU for ; Tue, 29 Nov 2016 03:31:51 -0800 (PST) Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D61296E9 for ; Tue, 29 Nov 2016 03:31:18 -0800 (PST) Received: from lminiero.lan ([93.44.46.109]) by smtpcmd09.ad.aruba.it with bizsmtp id DnXG1u0112MLHNd01nXHVx; Tue, 29 Nov 2016 12:31:18 +0100 Date: Tue, 29 Nov 2016 12:31:16 +0100 From: Lorenzo Miniero To: Magnus Westerlund Message-ID: <20161129123116.033312d7@lminiero.lan> In-Reply-To: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480419078; bh=U9l0bICbbcV3Mn/hKCp0p15S0fjZ7bKQNF+R+1m8TTM=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=hZLGfYyAdmM1lJKAV28idljF7OZw+FIkW3Y0FecXbfMqyDVu604B3TPMDxMDXP2Yf 9JlyTcH0awVu14qtNJw66FuTeHmPO7t+DJM1ZnEZ8TEBTnNmAgclGJnyJ/xihZc8yx HygsMq5Qdh1hz+I78KYbBMYp86h+tn1j/aPOoHM8sf0PTDXEqzm4Wvv2Jkam96S30e ZgigZ+Ex8+9Fmzo9AJYA7qIGD70MREd8kDw57CxXgz62wponCkfUFsA7VVsNbo6uYg ma1MZ5x+EN8aJH+F+X4YldHmF+3cWCIvYZRDFpNg3Zfqv53Ih9zGnmLKrN6AZcU+P1 cKpzs6gxnjXkQ== Archived-At: Cc: "tsv-art@ietf.org" , straw@ietf.org, "tsv-ads@tools.ietf.org" Subject: Re: [straw] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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: Tue, 29 Nov 2016 11:31:54 -0000 On Fri, 25 Nov 2016 15:49:01 +0100 Magnus Westerlund wrote: > Hi, >=20 > I have done this review as part of the TSVART's task to review > documents with potential transport impact. >=20 > Below you will find a number of comments on issues that I found. I > think there are several significant issues below: 2, 3, 4, and 6. The > rest would be good to address. I am sorry that this review is late in > the process. >=20 Hi Magnus, thanks for reviewing this again! >=20 > 1. Section 3.1: I am surprised that there are no discussion for a > Media Relay regarding a=3Drtcp-mux and its impact on where RTP/RTCP > packets will flow and if a=3Drtcp attribute is at all relevant. I think > there would be clearer if one in the context of a=3Drtcp also discusses > a=3Drtcp-mux and how that impacts the actual transport layer flows that > will result. >=20 You're right, we talk about 'rtcp-mux' in 3.2 but not 3.1, I'll fix this. Considering we're talking of a possibly/probably media-unaware component, would you be ok with a text suggesting a 3.1 Media Relay SHOULD reject 'rtcp-mux'? If the MR is able to demux RTP/RTCP then it's looking at packets rather than just forwarding them, making it more of a Media-aware Relay than a plain Media Relay. > 2. Section 3.1: > While [RFC7022] can prevent this from > happening, there may be implementations that don't make use of it. > As such, a B2BUA MAY rewrite CNAME items if any potential > collision is detected, even in the Media Relay case. If a B2BUA does > indeed decide to rewrite CNAME items, though, then it MUST generate > new CNAMEs following [RFC7022]. >=20 > While the Media Relay is generally safe in regards to the use of RTP=20 > header extensions, this text above actually requires translation of > the RTP header extension identified as=20 > "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]. Then also that > needs to be translated. >=20 Mh, this would also mean making a plain MR (or assuming it is) too aware of the media it is handling, especially if it comes up to editing RTP extensions. Anyway, since we're talking about CNAME rewriting, it makes sense to refer to RFC7941 too where that's mentioned, so I'll update the sections where that happens. > 3. Section 3.2: >=20 > Also this section will need a discussion of RTP header extensions. So=20 > one set of header extensions that may be translated are any SDES > items. So CNAME, MID, RID should be considered. Especially MID and > RID as they are directly related to SDP they are likely to need > translation. >=20 > However, also the set of transport related information, like the ones=20 > that has been proposed for use with RMCAT but have not yet been=20 > approved. As they can have packet specific information, if one starts=20 > removing packets, then one may need to consider these also. >=20 Isn't this widening the scope too much? The purpose of the draft is to address RTCP-related problematics, and opening the door to RTP (even just header extensions) could mean adding way more text and cases to this than originally planned. > 4. Section 3.2: SR Entry: >=20 > I like to note that if an Media Relay act in the role of a SFU, then > it needs to track in the outgoing SR, the relevant number of packets > sent, total amount of bytes sent to that particular receiver, rather > than what was received. Note, that as this is SR specific, it does > not apply to RR. >=20 Ok, I'll clarify this in the SR text. > I note that SFU also requires sequence number rewriting, which > affects other RTCP packet type that reference sequence numbers, like > NACK. >=20 That's already in the document, at least for NACKs themselves. > 5. Section 3.2: >=20 > REMB: [I-D.alvestrand-rmcat-remb] > A media-aware B2BUA MUST properly rewrite the additional > SSRC identifier(s) in REMB packets, if it changed the related RTP > SSRC of the media sender. >=20 > I assume that you have had some thought about the need to include > this individual proposal. I do note that it is not clear if this ever > will be published, especially considering the RMCAT WG's work on a > different feedback format. >=20 We had this in the beginning since most of our experimentation in this field was based on WebRTC implementations, and REMB played a great deal in that respect. Failing to adapt things would lead to recipients possibly flooded with data they couldn't handle, due to missing or broken feedback. I do know the REMB draft has been obsoleted for a while, but it's still used in both Chrome and Firefox, and so I thought it made sense to keep the related text there, as it is indeed still useful in the "real world". If you believe we should rather remove it, or replace references to REMB with something else, no problem from me. > 6. Section 3.2: >=20 > In fact, while a Media Relay B2BUA may choose to > use it on the side that supports it and not on the side that > doesn't, there are other aspects to take into account before doing so. >=20 > The above sentence indicates that it is okay to use reduced sized > RTCP on one leg but not the other. I would strongly discourage that > due to the issues that are raised. If one is going to "forward" a > reduced size RTCP packet, that needs to be upgraded to a compliant > RTCP compound packet. Which makes it bigger, and then RTCP bandwidth > becomes an issue. I think the above sentence should be clearer that > there are real issues here. And I think the conclusion should be to > use it only if both legs support it. >=20 I actually added that text after feedback from your previous review :-) https://www.ietf.org/mail-archive/web/straw/current/msg00336.html The text following the snippet you pasted tries indeed to convey exactly the point you make, that is that if you decide to go that road there are issues to be aware of. I'll try to make it clearer in the text that the issues are actually more severe than one might think, and so advice against negotiating it on one leg and not on the other. Thanks! Lorenzo > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Nov 29 05:14:44 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 48D2312996C; Tue, 29 Nov 2016 05:14:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148042528325.17209.407392282457070103.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 05:14:43 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT) 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: Tue, 29 Nov 2016 13:14:43 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- intro: Including the LI example in section 1 seems wrong given RFC2804. And I don't see why you need it if there are other justifications that are not controversial in the IETF. Why not just delete that? (The problem with including that justification in a standards track document is that doing so goes entirely against RFC2804.) But this should be an easy fix, via a revised ID or RFC editor note. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The security considerations section is pretty good, thanks! From nobody Tue Nov 29 05:35:55 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 890D6129B7F for ; Tue, 29 Nov 2016 05:35:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 7-3RNIo5do8q for ; Tue, 29 Nov 2016 05:35:48 -0800 (PST) Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id B72EC129B81 for ; Tue, 29 Nov 2016 05:35:47 -0800 (PST) Received: from lminiero.lan ([93.44.46.109]) by smtpcmd09.ad.aruba.it with bizsmtp id Dpal1u00Y2MLHNd01pal5j; Tue, 29 Nov 2016 14:34:45 +0100 Date: Tue, 29 Nov 2016 14:34:44 +0100 From: Lorenzo Miniero To: "Stephen Farrell" Message-ID: <20161129143444.244c3a14@lminiero.lan> In-Reply-To: <148042528325.17209.407392282457070103.idtracker@ietfa.amsl.com> References: <148042528325.17209.407392282457070103.idtracker@ietfa.amsl.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=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480426485; bh=PZ5qTaBFkfNFXyirpPiokBKjEqrvaotCIqChGm3tWk8=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=XqGwfmvdROSwPva8pSGoUnAKrAHdVnqCqyrnXB6QocIrKAyGd8R0q/oTEjL/WjW3Y ejVApOIeRiYt21z4TUfLzX1I+7kXSgWLwxv9tzx5DN9CfZ6mgxlNKhrKZ0NFcT4EZ2 01/NucenXy++GVcDJ02VoMe6oN2ARV/CAOzhAt2vEp0flvoCuOY2ECCgMTMzSH6h8n 6UnHfjPQ/UIoiAMDPylAKg4B1TvWG4AkQN9/1O4J9nXrJtCoc2lkNei/50Hbcq7XCK N+hRdcz6cq6msVqFOCo2TAlXc6SS+yr2BMKUf2Uu2y7KAVC6VODa1rBEDhR40UgQfl MGSPWcu2GHTMA== Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT) 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: Tue, 29 Nov 2016 13:35:54 -0000 On Tue, 29 Nov 2016 05:14:43 -0800 "Stephen Farrell" wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-straw-b2bua-rtcp-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > Hi Stephen, thanks for reviewing the document! > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > intro: Including the LI example in section 1 seems > wrong given RFC2804. And I don't see why you need it if > there are other justifications that are not controversial > in the IETF. Why not just delete that? (The problem with > including that justification in a standards track document > is that doing so goes entirely against RFC2804.) > > But this should be an easy fix, via a revised ID or RFC > editor note. > Do you mean the part where we mention "[..] like billing, lawful interception, session recording and so on [..]"? Do you think editing the text to just leave "[..] like session recording and so on [..]" would fix this, or is there other text that is breaking RFC2804? If you believe this is best left to the RFC editors to amend, I'll add the note as suggested. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - The security considerations section is pretty good, > thanks! > Thanks! Lorenzo > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Nov 29 05:36:31 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 449261295CE; Tue, 29 Nov 2016 05:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 BDQpxuej7Qp7; Tue, 29 Nov 2016 05:36:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97585129575; Tue, 29 Nov 2016 05:36:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 977F7BE32; Tue, 29 Nov 2016 13:36:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZJDwg1QvMGS; Tue, 29 Nov 2016 13:36:19 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E2FDBE38; Tue, 29 Nov 2016 13:36:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480426579; bh=K0Qhg8g4seNAJFW5BgbVlCom8F4gyC2JnIfDqHZfxZE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hXv0nKx58LD8PpSMMuZsw6dDZ3wgZrtuc5miq9Dt5r1M+gxmCXJ9Oem4tWR6qoYf1 mdM19ngrJkP1GMD4YI4s0yWJRoNPXaVJRCOyMky7mBzhNMN5LAicfYu+q2m0DYwyW6 JM5wsuwsLzM3TYF40HkyskFbQwhl5YS6rx1M+XwM= To: Lorenzo Miniero References: <148042528325.17209.407392282457070103.idtracker@ietfa.amsl.com> <20161129143444.244c3a14@lminiero.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 29 Nov 2016 13:36:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161129143444.244c3a14@lminiero.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040103070803020802020508" Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT) 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: Tue, 29 Nov 2016 13:36:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040103070803020802020508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/11/16 13:34, Lorenzo Miniero wrote: > On Tue, 29 Nov 2016 05:14:43 -0800 > "Stephen Farrell" wrote: >=20 >> Stephen Farrell has entered the following ballot position for >> draft-ietf-straw-b2bua-rtcp-15: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >=20 >=20 > Hi Stephen, >=20 > thanks for reviewing the document! >=20 >=20 >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> intro: Including the LI example in section 1 seems >> wrong given RFC2804. And I don't see why you need it if >> there are other justifications that are not controversial >> in the IETF. Why not just delete that? (The problem with >> including that justification in a standards track document >> is that doing so goes entirely against RFC2804.) >> >> But this should be an easy fix, via a revised ID or RFC >> editor note. >> >=20 >=20 > Do you mean the part where we mention "[..] like billing, lawful > interception, session recording and so on [..]"? Do you think editing > the text to just leave "[..] like session recording and so on [..]" > would fix this, or is there other text that is breaking RFC2804? If you= > believe this is best left to the RFC editors to amend, I'll add the not= e > as suggested. Right, that's all that's needed I think. S >=20 >=20 >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - The security considerations section is pretty good, >> thanks! >> >=20 >=20 > Thanks! >=20 > Lorenzo >=20 >=20 >> >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw >=20 --------------ms040103070803020802020508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjkx MzM2MThaMC8GCSqGSIb3DQEJBDEiBCC1Wx0qL3peYQRBKY0fCM4vuPzFO0XmGnPwQywaoxEG vzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBwjx7cuVCg79ze4MPYL/tEzArjQ6kKRwcRlTcs2L0PaGIs1INItMgM hcWLnRAg99jByXoz9XIVE73tqcbxShcu0yVodhGAhwIHbfDuKbv6DdT40ceLuS7WZvik0e8o CGiDqqGLvSKkc4ZuGMbSZ3LcdJh8YD6J4jUhxYzwhUY8q/gFBUSXQIVjNQPxfZ0DTcLgw7/m dJcTufvCSeOGUYVyYL2sbeHgUN5hl4qQo4zJYZpxLcCvXbJ6Facz4uikXcruj/LR575eKu8g 7VfBGlrVNZb9StBC9+d9wyCjuVpYt8yUxq1LKrFZD3pmXJP3+SFAnMVLDrmK5H63Lywwfk93 AAAAAAAA --------------ms040103070803020802020508-- From nobody Tue Nov 29 11:25:46 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 A2F53129C3F; Tue, 29 Nov 2016 11:25:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148044754162.11662.5213146159999935353.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 11:25:41 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Alvaro Retana's No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Tue, 29 Nov 2016 19:25:42 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [1] As I understand it, a Media-Aware Relay is an instance of a RTP/RTCP translator. I'm wondering whether the behavior in 3.2 can/should be more broadly applied to other types of translators, and not just to a media-aware B2BUA. ?? [Disclaimer: I am out of my depth here...] [2] The guidelines in 3.2 have a normative "MUST" attached to them: "...a media-aware B2BUA MUST handle incoming RTCP messages to forward following this guideline". However, some of the references are not Normative. I assume that (as with the guidelines related to RFC3550) the text in 3.2 represents a behavior beyond what is described in the references, which implies to me that those references should be Normative. The solution seems simple: move rfc3611, rfc5104, etc. to be Normative references...but I-D.alvestrand-rmcat-remb is also referenced, which not only expired 3 years ago, but it is marked as Experimental. Can the expected behavior from I-D.alvestrand-rmcat-remb be somehow defined in this document so that the reference is not needed? From nobody Tue Nov 29 11:58:13 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 10D3C129C47; Tue, 29 Nov 2016 11:58:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 11:58:12 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT) 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: Tue, 29 Nov 2016 19:58:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 3.1 = I think there is a lack of clarity in the recommendations here, because "such attributes" aren't listed out anywhere and then later it's not clear what the "mentioned attributes" are referring to. I've proposed some edits below to try to clarify what I think the recommendations are saying -- does this capture the intent? OLD However, certain SDP attributes may lead to call failures when forwarded by a media relay. Such attributes SHOULD NOT be forwarded. One notable example is the 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly state the port they're willing to use for RTCP. Considering the B2BUA would relay RTCP messages, the port as seen by the other UAC involved in the communication would differ from the one negotiated originally, and it MUST be rewritten accordingly. Apart from the mentioned attributes, B2BUAs SHOULD forward all other SDP attributes they don't have a reason not to forward, in order to avoid breaking additional functionality endpoints may be relying on. NEW However, certain SDP attributes may lead to call failures when forwarded by a media relay. One notable example is the 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly state the port it is willing to use for RTCP. Assuming that the B2BUA would relay RTCP messages, the port as seen by the other UAC involved in the communication would differ from the one negotiated originally. The 'rtcp' attribute MUST be rewritten accordingly, rather than being forwarded. Any other attributes known to the B2BUA to cause call failures when forwarded SHOULD NOT be forwarded. B2BUAs SHOULD forward all other SDP attributes in order to avoid breaking additional functionality endpoints may be relying on. = Section 3.2 = (1) "It is worthwile to point out that such a B2BUA may not necessarily forward all the packets it receives, though. Selective Forwarding Units (SFU) [RFC7667], for instance, may aggregate or drop incoming RTCP messages, while at the same time originating new ones on their own. For the messages that are forwarded and/or aggregated, though, it's important to make sure the information is coherent." I don't see much beyond this text that discusses the implications of dropping and aggregating RTCP messages. Is this written down in another document? If not, I'm wondering about what happens with RTCP information aside from identifiers, SSRCs, and sequence numbers in these cases. E.g., if a B2BUA drops one RTCP message containing an RFC 7002 block but forwards the next one containing such a block, won't the interval and the discard count reported to the receiver be wrong? I assume there are a lot of cases involving XR blocks where this could be a problem, but this document doesn't address those cases. (2) "SR: [RFC3550] If the B2BUA has changed the SSRC of the sender RTP stream a Sender Report refers to, it MUST update the SSRC in the SR packet header as well. If the B2BUA has changed the SSRCs of other RTP streams too, and any of these streams are addressed in any of the SR report blocks, it MUST update the related values in the SR report blocks as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change needs to be properly addressed in the 'extended highest sequence number received' field in the Report Blocks." Why is the recommendation about the extended highest sequence number received not also a MUST? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3.2 = s/properly address/reflected/ From nobody Tue Nov 29 14:25:10 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 7EF05129CA6; Tue, 29 Nov 2016 14:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 14:24:59 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Tue, 29 Nov 2016 22:24:59 -0000 Alia Atlas has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa that the set of attributes that fall into each category is just not clear or fully specified. I'm not sure about better wording - but at least indicating how to categorize the different attributes (if listing them all isn't reasonable) would help. Describing the category as "those that cause issues"' is not helpful. From nobody Tue Nov 29 14:46:20 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 50B5E129CB5; Tue, 29 Nov 2016 14:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 ArmJsq71mm8F; Tue, 29 Nov 2016 14:46:17 -0800 (PST) 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 F30C5129441; Tue, 29 Nov 2016 14:46:16 -0800 (PST) Received: from [10.0.1.21] (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 uATMkBSO078898 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2016 16:46:12 -0600 (CST) (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.21] From: "Ben Campbell" To: "Alia Atlas" Date: Tue, 29 Nov 2016 16:46:11 -0600 Message-ID: <8A8BF586-01EE-4639-A072-BC8D8451D84B@nostrum.com> In-Reply-To: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> References: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Tue, 29 Nov 2016 22:46:18 -0000 On 29 Nov 2016, at 16:24, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-straw-b2bua-rtcp-15: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alissa that the set of attributes that fall into each > category is just not clear or fully specified. > I'm not sure about better wording - but at least indicating how to > categorize the different attributes (if listing them > all isn't reasonable) would help. Describing the category as "those > that > cause issues"' is not helpful. Hi Alia, Did you find Alissa's suggested wording helpful? The problem is, these can't reasonably be enumerated. It's basically the set of any attributes that have implied assumptions that the attribute describes the immediate peer. Thanks! Ben. From nobody Tue Nov 29 14:56:33 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 EE6DD129441; Tue, 29 Nov 2016 14:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YKOx0CToiyRj; Tue, 29 Nov 2016 14:56:25 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 26D39124281; Tue, 29 Nov 2016 14:56:25 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id n6so171501157qtd.1; Tue, 29 Nov 2016 14:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AOxJ/aoLupe8gPXgoPxM+mW4bgtkdd43fNtBbFSuJug=; b=JtYFVW1oGeeN/lKtMuNlwheW7t9WQ7gu9vSFtpb/qliM44Jo61bIrO+bJLM7oGxIVZ 5k7soW3C6XKADQ7GyA6rYeXo8UcikAps+jXleZNohSGUbcMFHAhZdGm6Nts3A0TX4Fyx iPPPhxaFy5eaUzrOjsWP966/IcF91WFYDWkqKCrvqryzsIxd7BzSjKwlW4iWrmqmrzER hH7OIpqAycniHNbzoQnwiwHxr6dq+6hCHREO4nU2eUbaP+2Aoy2D2i+VBxD52s9BquKQ MGsvSta3NOuwA2q62+Gch8OzfGtnkFNW5r3PmsOCiFkASoEWqymN4x6yGYgVRnmEsDS1 mJ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AOxJ/aoLupe8gPXgoPxM+mW4bgtkdd43fNtBbFSuJug=; b=mHGFQfvtJlq3ZpDKyBF7TwJ2amQHWWlpBwSQOJzGIzSMNTyRwkc8fXIJjpyj3SIOSn e1v1XsGl12JcpCFGV9b6pGkalOrqaPspbf2uY0zjFjllRRbExMquhbrn71NzEv46MRzt QIEOpNBDzR0PYalN1XjWGWtCkla+VU0Vdm7r9XrqdXU47k7xLu38W6Q9UjzZHfWHp0oR iT3x7NTvu7lKqYu3+0FVtQ7IsHzx337BOteJUdQr4HfbSKfRVWHRUIjLxTp/YC/L2NLq XYJ2b+PJuTZ67zPW31FE8wH+KEqLoCVSUkYK5p5AqfFn7yq7Us/vSeovdfNQfvleruQ7 O6eg== X-Gm-Message-State: AKaTC03tIRRhYaTw4VXFAoleeNUkDWx02OgfFxUgVhBNiGkvPdlsFwZ7H73x8WM8QYnEg1+wvFciZl9HtCbWlg== X-Received: by 10.237.33.156 with SMTP id l28mr29725879qtc.111.1480460184290; Tue, 29 Nov 2016 14:56:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.14 with HTTP; Tue, 29 Nov 2016 14:56:23 -0800 (PST) In-Reply-To: <8A8BF586-01EE-4639-A072-BC8D8451D84B@nostrum.com> References: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> <8A8BF586-01EE-4639-A072-BC8D8451D84B@nostrum.com> From: Alia Atlas Date: Tue, 29 Nov 2016 17:56:23 -0500 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a11397c5463a8040542787f32 Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, Christer Holmberg , The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Tue, 29 Nov 2016 22:56:27 -0000 --001a11397c5463a8040542787f32 Content-Type: text/plain; charset=UTF-8 Hi Ben, On Tue, Nov 29, 2016 at 5:46 PM, Ben Campbell wrote: > On 29 Nov 2016, at 16:24, Alia Atlas wrote: > > Alia Atlas has entered the following ballot position for >> draft-ietf-straw-b2bua-rtcp-15: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with Alissa that the set of attributes that fall into each >> category is just not clear or fully specified. >> I'm not sure about better wording - but at least indicating how to >> categorize the different attributes (if listing them >> all isn't reasonable) would help. Describing the category as "those that >> cause issues"' is not helpful. >> > > Hi Alia, > > Did you find Alissa's suggested wording helpful? > Not sufficiently.... > The problem is, these can't reasonably be enumerated. It's basically the > set of any attributes that have implied assumptions that the attribute > describes the immediate peer. > Right, I gathered that the set of attributes was too large - but your response starts to indicate the categories that could be used. I.e. instead of "Any other attributes known to the B2BUA to cause call failures when forwarded SHOULD NOT be forwarded." perhaps something like (wildly out of my core expertise of course) "Some attributes have an implied assumption that the attribute describes the immediate peer. A clear example of this is the 'rtcp' attribute, which describes the expected peer port. Other attributes might include the immediate peer's IP address, preferred transport, etc. In general, the guideline is to require rewriting of attributes that are implicitly describing the immediate peer. If in doubt during implementation, testing to determine whether a call failure occurs should be done." Regards, Alia > Thanks! > > Ben. > --001a11397c5463a8040542787f32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,

On Tue, Nov 29, 2016 at 5:46 PM, Ben Campbell <= ben@nostrum.com>= ; wrote:
On 29 Nov 2016, at 16:24, Ali= a Atlas wrote:

Alia Atlas has entered the following ballot position for
draft-ietf-straw-b2bua-rtcp-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/d= raft-ietf-straw-b2bua-rtcp/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I agree with Alissa that the set of attributes that fall into each
category is just not clear or fully specified.
I'm not sure about better wording - but at least indicating how to
categorize the different attributes (if listing them
all isn't reasonable) would help.=C2=A0 Describing the category as &quo= t;those that
cause issues"' is not helpful.

Hi Alia,

Did you find Alissa's suggested wording helpful?
<= br>
Not sufficiently....=C2=A0
=C2=A0
The problem is, these can't reasonably be enumerated. It's basicall= y the set of any attributes that have implied assumptions that the attribut= e describes the immediate peer.

Right, = I gathered that the set of attributes was too large - but your response sta= rts to indicate the categories that could be used.

I.e. instead of "Any other= attributes known to the B2BUA to cause call failures when forwarded SHOULD= NOT be forwarded." perhaps something like (wildly out of my core expe= rtise of course)
"So= me attributes have an implied assumption that the attribute describes the i= mmediate peer. A clear example of this is the 'rtcp' attribute, wh= ich describes the expected peer port. Other attributes might include the i= mmediate peer's IP address, preferred transport, etc. In general, the = guideline is to require rewriting of attributes that are implicitly describ= ing the immediate peer. If in doubt during implementation, testing to dete= rmine whether a call failure occurs should be done."
=
Regards,
Alia

=C2=A0

=C2=A0
Thanks!

Ben.

--001a11397c5463a8040542787f32-- From nobody Tue Nov 29 15:00:20 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 8E2C7129CD9; Tue, 29 Nov 2016 15:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 yCIJSds9NhaL; Tue, 29 Nov 2016 15:00:10 -0800 (PST) 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 A7FE0129CA8; Tue, 29 Nov 2016 14:59:59 -0800 (PST) Received: from [10.0.1.21] (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 uATMxrkN080077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2016 16:59:54 -0600 (CST) (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.21] From: "Ben Campbell" To: "Alia Atlas" Date: Tue, 29 Nov 2016 16:59:53 -0600 Message-ID: <63D461D3-3575-4590-ACCB-155AAC9F96D5@nostrum.com> In-Reply-To: References: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> <8A8BF586-01EE-4639-A072-BC8D8451D84B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, Christer Holmberg , The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Tue, 29 Nov 2016 23:00:12 -0000 On 29 Nov 2016, at 16:56, Alia Atlas wrote: > Hi Ben, > > On Tue, Nov 29, 2016 at 5:46 PM, Ben Campbell wrote: > >> On 29 Nov 2016, at 16:24, Alia Atlas wrote: >> >> Alia Atlas has entered the following ballot position for >>> draft-ietf-straw-b2bua-rtcp-15: No Objection >>> >>> When responding, please keep the subject line intact and reply to >>> all >>> email addresses included in the To and CC lines. (Feel free to cut >>> this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I agree with Alissa that the set of attributes that fall into each >>> category is just not clear or fully specified. >>> I'm not sure about better wording - but at least indicating how to >>> categorize the different attributes (if listing them >>> all isn't reasonable) would help. Describing the category as "those >>> that >>> cause issues"' is not helpful. >>> >> >> Hi Alia, >> >> Did you find Alissa's suggested wording helpful? >> > > Not sufficiently.... > > >> The problem is, these can't reasonably be enumerated. It's basically >> the >> set of any attributes that have implied assumptions that the >> attribute >> describes the immediate peer. >> > > Right, I gathered that the set of attributes was too large - but your > response starts to indicate the categories that could be used. > > I.e. instead of "Any other attributes known to the B2BUA to cause call > failures when forwarded SHOULD NOT be forwarded." perhaps something > like > (wildly out of my core expertise of course) > > "Some attributes have an implied assumption that the attribute > describes > the immediate peer. A clear example of this is the 'rtcp' attribute, > which > describes the expected peer port. Other attributes might include the > immediate peer's IP address, preferred transport, etc. In general, the > guideline is to require rewriting of attributes that are implicitly > describing the immediate peer. If in doubt during implementation, > testing > to determine whether a call failure occurs should be done." That seems like a reasonable clarification, assuming the authors agree that the new first sentence adequately describes all the problematic attributes (that is, there are no attributes I have forgotten about that do not have that specific implication, but still break things.) Thanks! Ben. From nobody Wed Nov 30 22:30:17 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 17F9C1295A9; Wed, 30 Nov 2016 22:30:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148057381107.9623.13436464476587634522.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 22:30:11 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Spencer Dawkins' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Thu, 01 Dec 2016 06:30:11 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for responding to Magnus's thorough TSV-ART review (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html). I'm inclined to agree with the resolutions you've proposed (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), but I do have one question - given that you want to include REMB, because it's deployed in Chrome and Firefox, and given that https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't moved in three years and RMCAT is doing something else, what's your plan for publishing this draft as an RFC that's not stuck in MISSREF forever? From nobody Wed Nov 30 22:30:19 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 BEEB9129C09; Wed, 30 Nov 2016 22:30:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148057381177.9603.6990677534643010984.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 22:30:11 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Spencer Dawkins' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT) 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: Thu, 01 Dec 2016 06:30:12 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for responding to Magnus's thorough TSV-ART review (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html). I'm inclined to agree with the resolutions you've proposed (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), but I do have one question - given that you want to include REMB, because it's deployed in Chrome and Firefox, and given that https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't moved in three years and RMCAT is doing something else, what's your plan for publishing this draft as an RFC that's not stuck in MISSREF forever?