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