Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 12 September 2018 20:04 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 CD4B0130EA9 for <bfcpbis@ietfa.amsl.com>; Wed, 12 Sep 2018 13:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 3_H7CPgkzMB7 for <bfcpbis@ietfa.amsl.com>; Wed, 12 Sep 2018 13:04:22 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C95130D7A for <bfcpbis@ietf.org>; Wed, 12 Sep 2018 13:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6548; q=dns/txt; s=iport; t=1536782662; x=1537992262; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DVuGxaZAUaRv22qbTzeJxeFgX4uiAaLK9AZUmDpcPKQ=; b=F931kits9EqrjeJ5EYKZXPG/iOjv/RWOOqSwnPQtJk2LXXG2cuTS6xGM OZlxAI477XAKfn7Kv/gQaUoealXXlL7iq5Rjvjp3JGOPtzn3oXvmr29h7 Dbax0N09ABIG5voG48Z+j1HLqEhfDiBIv5smWew7wxMePwb+a+oZOXkgV 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C8AADhcJlb/4cNJK1cDgsBAQEBAQEBAQEBAQEHAQEBAQGBToIIZX8oCoNoiBWOKYM9kwCBegsYC4QDRgIXgzYhNBgBAgEBAgEBAm0cDIU4AQEBAQIBAQEhEToEEwQCAQgOAwMBAgECAiYCAgIlCxUICAEBBAESgyEBgXkID6VMgS6EcoUYBYELiVwXggCBEicfgkyDGwEBgUsWgwExgiYCkxyINU8JApAIF4FBhEODAIV3iE+LKgIRFIElHTiBVXAVOyoBgkGLFYUEOm+NXoEeAQE
X-IronPort-AV: E=Sophos;i="5.53,366,1531785600"; d="scan'208";a="170278303"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 20:04:19 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w8CK4JQZ032333 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Sep 2018 20:04:19 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Sep 2018 15:04:18 -0500
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.1395.000; Wed, 12 Sep 2018 15:04:18 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
Thread-Index: AdRKBSanEUT3mXgfR9+heKDHJ6DIEf//+MoA///JhiCAAPmrgIAA6QUA///WvYA=
Date: Wed, 12 Sep 2018 20:04:18 +0000
Message-ID: <081DF52F-3AB7-460C-9C28-67F2766ABEAB@cisco.com>
References: <1a54a9fe1d0d48a29b7bb70c80f27d81@ericsson.com> <39D21140-F791-481B-A01B-6A5CCFAD71B9@cisco.com> <eb2fdf2422e747eca18ad46b8be072a0@ericsson.com> <e7e15eb9-4816-0ed1-2d95-861a5b14cb0e@nostrum.com> <191e16d5-8cf6-f66f-41e5-ad62d580fd75@alum.mit.edu>
In-Reply-To: <191e16d5-8cf6-f66f-41e5-ad62d580fd75@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.e.1.180613
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.176.160]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DBD8A8C826E9B440A5D27A9EDB84C662@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/7pghB8MGGaUwyKDBluOWo2-MjTs>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Sep 2018 20:04:24 -0000
Hi Paul, Please see inline. -----Original Message----- From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu> Date: Wednesday, September 12, 2018 at 8:32 AM To: "bfcpbis@ietf.org" <bfcpbis@ietf.org> Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue On 9/11/18 9:37 PM, Adam Roach wrote: > On 9/11/18 5:17 PM, Christer Holmberg wrote: >> Hi, >> >> Based on my reading, an endpoint being both client and server is unclear even in 4582/4582bis. My understanding is that one endpoint acts as client and one endpoints acts as server. Of course, the roles can be re-negotiated, but at any given time an endpoint only has ONE role. >> >> Or, have I missed something? > > > I think so. From §3: > > Furthermore, there are situations where both endpoints act as both > floor control client and floor control server within the same > session. For example, in a two-party session that involves an audio > stream and a shared whiteboard, one endpoint acts as the floor > control server for the audio stream and the other endpoint acts as > the floor control server for the shared whiteboard. > > > I note that this text exists in RFC 4583 as well, so this has > conceptually been part of the protocol at least since its first > publication. The way I read this, to implement the above-described > scenario, both sides would negotiate a c-s role. Client A would send > FloorRequest messages to Client B to ask for the audio floor, and Client > B would send FloorRequest messages to Client A to ask for the whiteboard > floor. This would all take place over the same BFCP stream. > > Now, what I'm hearing you and Charles say is that this "both client and > server" behavior was under-specified in RFC 4582, and so the RFC 4583 > behavior was consequently mis-implemented, with implementations failing > to distinguish between "c-only, s-only" and "c-s" (which, based on my > description above, would mean radically different things from each > other); and that the confusion here was so profound that an external > consortium has issued its own guidance that effectively deprecates the > original meaning of "c-s" altogether. > > All of which tells me that the behavior described by the paragraph I > quote above is not used in the field, apparently not useful, and too > confusing to understand; on top of which, IMTC has salted the ground > even if we wanted to clarify meanings and procedures surrounding "c-s". > > My suggestion, then, is: > > 1. Remove the above quoted paragraph, replacing it with text that > clarifies that one peer must be a server for all streams or a client > for all steams. > 2. Explicitly deprecate the use of "c-s," with a note that some > implementations are known to treat it as identical to "c-only, > s-only" (and make the text otherwise consistent on this point; e.g., > in §10 and its subsections) > 3. Update the examples to match. ISTM that to go this way the document should be returned to the WG. It seems like too big a change to do otherwise. I agree. This discussion is occurring on the WG list, and any changes/updated versions of the draft(s) will be vetted here as well. Are you suggesting something more formal, like another WGLC? Cheers, Charles > Another alternative would be to add clarification about how to implement > the scenario I quote above (I think you'd get a lot of mileage by simply > adding the word "simultaneously" to the end of the description of "c-s" > in §5.1, which was clearly the original intention), clarify §7.1 to > indicate who re-establishes connections for "c-s" relationships, pull > RFC4582bis out of the RFC Editor queue and fix it so it specifies how to > act as both a client and a server over a single BFCP stream, and ignore > the fact that the IMTC guidance will lead to incompatibilities anyway. > This approach seems like a lot more work to clarify a feature that no > one apparently uses or wants, so I would not recommend it. > > /a > > > > _______________________________________________ > 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] AD Review of draft-ietf-bfcpbis-rfc… Christer Holmberg
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Charles Eckel (eckelcu)
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Christer Holmberg
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Adam Roach
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Alan Ford
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Charles Eckel (eckelcu)
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Paul Kyzivat
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Christer Holmberg
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Charles Eckel (eckelcu)
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Charles Eckel (eckelcu)
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Paul Kyzivat
- Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc… Christer Holmberg