[bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-14

"Paul E. Jones" <paulej@packetizer.com> Tue, 22 September 2015 20:49 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 322911B2DE5; Tue, 22 Sep 2015 13:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.212
X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MeQwKDupm-u9; Tue, 22 Sep 2015 13:49:40 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com []) (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 480F41B2DE4; Tue, 22 Sep 2015 13:49:40 -0700 (PDT)
Received: from [] (cpe-098-122-181-215.nc.res.rr.com [] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id t8MKnY4K024909 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2015 16:49:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1442954976; bh=aSflXsu4qY8jwoSI9kgnt0cOwm6+b5WaVUjJMB48qgE=; h=From:To:Subject:Cc:Date:Reply-To; b=tjXB1MVNhHMY+XHXmDPUIlhaM2VEphEL9Zo8FV4PqOaKhLl5x19Whfax+y9Qh6xgx RtN4qyqUwLag31rYveDdQT7o9KXUMgBrCvRgypboWetVXj2R0ZdjxDL43Fh/2ztMSs FRNorPuLwXoQttKuEHIP3ahXW3IftgmTAFIIS7Dc=
From: "Paul E. Jones" <paulej@packetizer.com>
To: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, IESG <iesg@ietf.org>, "Tom Kristensen" <tomkrist@cisco.com>, gen-art@ietf.org
Date: Tue, 22 Sep 2015 20:49:36 +0000
Message-Id: <em2240cd8c-30a7-454b-9e88-40b7f39ab393@sydney>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB37DD9864-0D96-4966-9A61-1FF24B3E135A"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com []); Tue, 22 Sep 2015 16:49:36 -0400 (EDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/BLA7BDnxqPJNtnqWFj86tgrAzEk>
Cc: Alissa Cooper <alissa@cooperw.in>
Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-14
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
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, 22 Sep 2015 20:49:43 -0000


Alissa asked me to review the current text, provide input, and help 
address some of the current DISCUSS points.

Here are some suggested improvements:

In Section 4.1, it says "Subsequent FloorStatus messages consist of 
server-initiated transactions, and therefore their Transaction ID is 0." 
  This is true since the transport in these examples is reliable.  While 
perhaps minor, I think it might be worth explicitly stating that be 
appending "given the example uses a reliable transport", otherwise the 
reader may miss that there is a difference in behavior when 
communicating over unreliable transports.In 5.3.7, it says "the 
following is the format of the FloorRequest message".  That should be 
"FloorQuery message"In 6.2.3, the equation:
  (message size - COMMON-HEADER size / MTU size - COMMON-HEADER size)
for better readability should say:
  ((message size - COMMON-HEADER size) / (MTU size - COMMON-HEADER 
size))In 10.2.2, it reads "A message from the floor control server is 
considered a response to the FloorRelease message if the message from 
the floor control server has the same Conference ID, Transaction ID, and 
User ID as the FloorRequest message."  I believe "FloorRequest" should 
be "FloorRelease".A similar copy/paste error as above was noted in 
12.1.2.I think it would be beneficial in Appendix A to explicitly show 
what the "R" value is.  It is possible for a floor participant and a 
floor control server to each initiate a transaction at the same time 
with Transaction ID == 124, for example.  The "R" bit is what helps to 
differentiate transactions and their responses, and I think that would 
be helpful here.
Section 10.1.1 says the "User ID will be used by the floor control 
server to authenticate and authorize the request."  TLS/DTLS is used for 
authentication/authorization presently.  Further, the draft more than 
once that other mechanisms might be developed in the future.  Merely 
looking at this field in a message, though, is not sufficient to 
authenticate or authorize a request.  This existed in the original RFC, 
but I propose we strike the sentence.