Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 11 September 2018 20:59 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 9A17F130F76; Tue, 11 Sep 2018 13:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, URIBL_BLOCKED=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 4wd75Ifnr0DJ; Tue, 11 Sep 2018 13:59:31 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8FC130FEA; Tue, 11 Sep 2018 13:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4056; q=dns/txt; s=iport; t=1536699571; x=1537909171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oneFOCPNKCnj2+HCB/CEB/vkKT9g1Xb8eFHHQnipC28=; b=Bf0vAjelassWIB9uqVj4peAMVtpGsz/2D3SyE5a15s5lk+oN9eKN92vo nN9uhurXAEGU6kVhb5RXgkidLUm7DLCGHtGAjvqnKr66l7h4pO5OZUlgO mc7nb1QaBoXkhSnsh4F/u4Zom33wjbBzLEAtuBeI86N2PnAefWQsB7aRX 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AUBwApLJhb/4oNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYNOZX8oCoNolDmCDYM9hSCNcYFmCx6ECEYCF4MZITgUAQIBAQIBAQJtHAyFOAEBAQEBAiMRRQwEAgEIEQMBAgMCJgICAh8RFQgIAQEEAQ0FgyEBgWkDFQ+lR4EuhysNgkoFgQuJXBeCAIESJx+CTIJWISQCAYEkJhaDATGCJgKbZisJAok2gzqDFBeOdYwlh0wCERSBJTQhgVVwFWUBgkGLFYU+bwGNOoEeAQE
X-IronPort-AV: E=Sophos;i="5.53,362,1531785600"; d="scan'208";a="448950413"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 20:59:21 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w8BKxLAL011866 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2018 20:59:21 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 15:59:20 -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; Tue, 11 Sep 2018 15:59:20 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Adam Roach <adam@nostrum.com>, "draft-ietf-bfcpbis-rfc4583bis.all@ietf.org" <draft-ietf-bfcpbis-rfc4583bis.all@ietf.org>
CC: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
Thread-Index: AdRKBSanEUT3mXgfR9+heKDHJ6DIEf//+MoA
Date: Tue, 11 Sep 2018 20:59:20 +0000
Message-ID: <39D21140-F791-481B-A01B-6A5CCFAD71B9@cisco.com>
References: <1a54a9fe1d0d48a29b7bb70c80f27d81@ericsson.com>
In-Reply-To: <1a54a9fe1d0d48a29b7bb70c80f27d81@ericsson.com>
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.178.20]
Content-Type: text/plain; charset="utf-8"
Content-ID: <687984787AABDC4E889C96D31D45B323@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/x4cU3YCCwc4SPfzr_4ZLqLx4of0>
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: Tue, 11 Sep 2018 20:59:41 -0000

RFC 4583 is underspecified in this regard, and currently rfc4583bis is as well.

This was a point of much debate years ago within the IMTC. No one with the IMTC used "c-s" for its intended purpose, though some implementations were known to use "c-s" incorrectly to mean "c-only, s-only". We agreed to not use "c-s" and to interpret "c-s" as meaning "c-only, s-only" if it was ever received. This worked well it is documented in this liaison statement:
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2012-05-31-imtc-the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf

Cheers,
Charles


-----Original Message-----
From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, September 11, 2018 at 12:47 PM
To: Adam Roach <adam@nostrum.com>, "draft-ietf-bfcpbis-rfc4583bis.all@ietf.org" <draft-ietf-bfcpbis-rfc4583bis.all@ietf.org>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: RE: AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
Resent-From: <alias-bounces@ietf.org>
Resent-To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, <tom.kristensen@tandberg.net>, Christer Holmberg <christer.holmberg@ericsson.com>, Charles Eckel <eckelcu@cisco.com>, Keith Drage <drageke@ntlworld.com>, <ben@nostrum.com>, Adam Roach <adam@nostrum.com>, <aamelnikov@fastmail.fm>, Mary Barnes <mary.ietf.barnes@gmail.com>
Resent-Date: Tuesday, September 11, 2018 at 12:47 PM

    Hi,
    
    ...
    
    >§7.1 (BLOCKING):
    >
    >  When the existing TCP connection is closed and re-established  following the rules in [16], the floor control 
    >  client MUST send an offer towards the floor control server in order to re-establish the  connection.
    >
    > The behavior here is ambiguous in the case that "a=floorctrl:c-s" is negotiated.
    > This needs to be clarified. Perhaps something like:
    >
    >    If the peers are acting as both floor control client and floor control
    >    server (i.e., if "a=floorctrl:c-s" has been negotiated), then the peer that
    >    most recently sent a successfully answered offer MUST send an offer.
    
    I think this was discussed at some point. If I remember correctly, in the case of 'c-s' in the answer the actual roles will be determined on BFCP level.
    
    When I look at 4582bis, I does describe client and server procedures, but I do NOT find any procedures regarding determining the roles. In fact, 4582bis says:
    
       "BFCP roles are negotiated in the offer/answer exchange as specified
       in [10], resulting in one endpoint being responsible for opening the
       TCP connection used for the BFCP communication."
    
    ...which raises the question whether 'c-s' should be allowed in the answer to begin with?
    
    Removing it would of course not be backward compatible with 4583, but if it is unclear how it would work it may not matter?
    
    Regards,
    
    Christer