Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 13 December 2017 18:06 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8012714F for <bfcpbis@ietfa.amsl.com>; Wed, 13 Dec 2017 10:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 y9DAr5pazX_9 for <bfcpbis@ietfa.amsl.com>; Wed, 13 Dec 2017 10:06:32 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC321200FC for <bfcpbis@ietf.org>; Wed, 13 Dec 2017 10:06:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36748; q=dns/txt; s=iport; t=1513188392; x=1514397992; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yjuvrWbil5x4EIGD1J/g6gu1cOUG7Y24JdAzet4PZ/M=; b=Xus7/bMPefRlcxfh4opxxzua55NcSVSurZpmWc97V0/kOBeaz8ECYgPp YljffH5Vd5az/piHR9r/SJZ/ZH9fx3qW1pWtNdmSZYE+9Mzgzuv6mc3j6 U8/y+/XLaIf0hr2IVptonJVczBp7IptMHR9ME2yVjpObz+Ohp6P0Y8Wkz g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DpAADTazFa/4sNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJKRS9mdCcHg3uKIY8FgVcmgw2Fa44ZFIIBChgBCoRJTwIahHk/GAEBAQEBAQEBAWsohSMBAQEBAwEBGwZFBgsMBAIBCBEDAQEBIQcDAgICHwYLFAkIAgQBDQWJREwDFRCoWIInJocSDYMYAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYNggguDPykLgWmBDoJqRAEBgVUCHRkWAoJdMYIyBYpKjwiJED0Ch3mIL4R9ghZjhS+LQI0QPYhsAhEZAYE6AQ8QOSWBKW8VOioBgX4JgkkcgWd4AYkkgRUBAQE
X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208,217";a="330147032"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 18:06:31 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBDI6Vb4005179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 18:06:31 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 12:06:30 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Wed, 13 Dec 2017 12:06:30 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Alan Ford <alan.ford@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com>
CC: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>, Roman Shpount <rshpount@turbobridge.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Thread-Topic: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review
Thread-Index: AdMCPCFSYamXLa2wSSi7CPCvHfiETwKoe+aAGBVp11AAYTHdAAAhNucAAQh1MYAAM0lpgA==
Date: Wed, 13 Dec 2017 18:06:30 +0000
Message-ID: <D7BAD156-3774-49FB-97CC-7D8EE5E49E58@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B4CC93DD7@ESESSMB109.ericsson.se> <BFFCDC28-BB45-4439-80C7-261F46F98B76@cisco.com> <7594FB04B1934943A5C02806D1A2204B6C03BCEF@ESESSMB109.ericsson.se> <42C58DF0-BDAB-45BB-91B1-1F55FC2E278C@cisco.com> <D64EC104.27124%christer.holmberg@ericsson.com> <D581A92A-AB14-4004-8EE4-1D77489E7166@gmail.com>
In-Reply-To: <D581A92A-AB14-4004-8EE4-1D77489E7166@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.28.0.171108
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: multipart/alternative; boundary="_000_D7BAD156377449FB97CC7D8EE5E49E58ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/Hl65Y5yEpHsRX8Dr6PzuLKcN2MI>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 18:06:36 -0000
Hi Alan, Please see inline. From: Alan Ford <alan.ford@gmail.com> Date: Tuesday, December 12, 2017 at 1:38 AM To: Christer Holmberg <christer.holmberg@ericsson.com> Cc: Charles Eckel <eckelcu@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Tom Kristensen <tomkrist@cisco.com>, Roman Shpount <rshpount@turbobridge.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review Hi all, I agree with Christer re Section 4 here, the text has become slightly confused. Now the presence of this attribute in O/A has been raised to a MUST, the following paragraph serves no purpose any more and should be removed: If the 'floorctrl' attribute is not used in an offer/answer exchange, by default the offerer and the answerer will act as a floor control client and as a floor control server, respectively. That would resolve the confusion highlighted here. [cue] I am okay with that change. I think the suggested wording I provided in my response to Christer is more explicit, but I am okay either way. Christer, do you have a preference? Regarding my own WGLC comments, I’m not going to kick up any more of a fuss about this, but in Section 6, although the text re “mstrm” has been improved to clarify being optional, I remain confused as to what the scenario actually is for a floorid without associated media stream(s). Does it affect all streams in that case? Or would it be used for floors that do not have any associated media streams (whatever that means)? I think it would be useful to define what the lack of mstrm means (unless it’s application-specific, in which case we can ignore it). [cue] I agree but can only say that is the way it was defined in RFC 4583 and we do not change that. I do not know why it was defined this way. My guess is it has something to do with a conference in which a floor control server wants to advertise the same floor-id to all participants and not all of the participants have a floor controlled stream yet (e.g. I joined the conference and have an audio and video stream but no presentation sharing stream yet.). However, in section 11.5, https://tools.ietf.org/html/rfc4583#section-11.5, RFC 4583 implies there is always at least one media stream associated with a floorid. Other than that, I am happy with the document as it now stands. Regards, Alan [cue] Great, thanks. Charles On 7 Dec 2017, at 08:16, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, Q1: SDP 'floorctrl' attribute: ------------------------------------- It is very unclear whether the attribute is mandatory in offers/answers or not. Section 11.1 says that it MUST be included in offers. However, section 4 seems to indicate that it may not be included in an offer. Section 11.2 says that it MUST be included in an answer, while section 4 indicates that it is only included if present in the offer. [cue] Sections 11.1 says it MUST be included in offers IF the offerer acts as a floor control server. [cue] Similarly, section 11.2 says it MUST be included in the answer IF the answerer acts as a floor control server. Section 4 does not talk about the role. The text says: "If an SDP media description in an offer contains a 'floorctrl' attribute, the answerer accepting that media MUST include a 'floorctrl' attribute in the corresponding media description of the answer.² [cue] This is consistent with section 4, which states a floor control server acting as an offerer or as an answerer MUST include this attribute in its session descriptions. Based on the text in section 11.2, if the answerer does NOT include the attribute in the answer, it would mean that the answerer acts as floor control client. Right? BUT, the text in section 4 says: "If the 'floorctrl' attribute is not used in an offer/answer exchange, by default the offerer and the answerer will act as a floor control client and as a floor control server, respectively.² So, to me that means that if the answerer does NOT include the attribute in the answer, the answerer acts as server. [cue] So I think this is technically correct, though as you point out, perhaps not the best wording. That said, it was reworded in this draft to try to make it more clear. Do you have a different wording that you think would be better? In my opinion, section 4 should only define the attribute, and what it is used for. The offer/answer considerations should ONLY be in section 11. Regards, Christer -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 19 July 2017 12:23 To: bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> Cc: Tom Kristensen (tomkrist) <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>; Roman Shpount <rshpount@turbobridge.com<mailto:rshpount@turbobridge.com>>; Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>; Gonzalo Camarillo <gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>; Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; alan@pexip.com<mailto:alan@pexip.com> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis (As WG co-chair) Thanks to those who provided reviews. We have decided to extend WGLC an additional week, through July 25, to provide folks tied up with other IETF matters time to complete their reviews. Cheers, Charles -----Original Message----- From: bfcpbis <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org>> on behalf of Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> Date: Monday, July 17, 2017 at 10:10 AM To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>> Cc: Tom Kristensen <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>, Roman Shpount <rshpount@turbobridge.com<mailto:rshpount@turbobridge.com>>, Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com<mailto:Gonzalo.Camarillo@ericsson.com>>, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis (As WG co-chair) This is a reminder that WGLC ends tomorrow. I realize the time to review overlaps with IETF prep and meeting times. If you require more time to review the draft, please let me know. Otherwise, please share your review comments by the end of tomorrow. Thanks, Charles -----Original Message----- From: bfcpbis <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org>> on behalf of Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> Date: Wednesday, July 5, 2017 at 5:59 PM To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>> Subject: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis (As WG co-chair) This is to announce an additional working group last call for draft-ietf-bfcpbis-rfc4583bis, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams". http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ This is intended as a Standards Track RFC, obsoleting RFC 4583. Please respond to the list by July 18th (i.e. 2 weeks) with any comments. We had a working group last call previous, but a significant amount of time and some substantial changes and additions have occurred to justify another review of the draft in its entirely. It is helpful to attempt to categorize your comment (e.g. technical issue vs. editorial), and also to provide any replacement text you feel is necessary. If you review the document and have no comments, please tell the chairs that you have reviewed it. This is always useful information in assessing the degree of WG review and consensus behind the document. Note, we have not scheduled a working group session for IETF 99 in Prague. This WGLC will close during IETF 99. If helpful, we can arrange a side meeting to discuss any significant issues, or with any luck, gather at a bar to celebrate the draft being ready to advance to the next step toward RFC. Cheers, Charles _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Christer Holmberg
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Charles Eckel (eckelcu)
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Christer Holmberg
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Charles Eckel (eckelcu)
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Christer Holmberg
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Charles Eckel (eckelcu)
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Christer Holmberg
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Charles Eckel (eckelcu)
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Alan Ford
- Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583… Charles Eckel (eckelcu)