Re: [bfcpbis] draft-ietf-bfcpbis-rfc4582bis-15

"Charles Eckel (eckelcu)" <> Tue, 20 October 2015 14:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D83801A1BC2 for <>; Tue, 20 Oct 2015 07:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z7DpcPv6dNkP for <>; Tue, 20 Oct 2015 07:21:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EC8E1A1BA2 for <>; Tue, 20 Oct 2015 07:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9863; q=dns/txt; s=iport; t=1445350889; x=1446560489; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Gbul56zO0kClYV/gT6Mgbvfi7MqhsHoPE/USULt2URU=; b=fx0sgDonhZqmMHMsUVZTPuN3t9TKI1eFIUpPBCsA9bE4UUajvCNDGuVS 8c4fNdag/fVAb9Rqk/pHDYBvwAcz+Cogi44dpmzgi5Wk9pxWZ13NxqvqP LMb4MriAL9GxagVYxhOCcIxGZJHzKumBUEDNwjPUMpOG8+N5NWutjXIUU U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208,217";a="200018995"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2015 14:21:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9KELSK8017773 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 14:21:28 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 09:21:10 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 09:21:10 -0500
From: "Charles Eckel (eckelcu)" <>
To: "Paul E. Jones" <>, "" <>
Thread-Topic: [bfcpbis] draft-ietf-bfcpbis-rfc4582bis-15
Thread-Index: AQHRCxwXLDZqUXL3JkyZavUukbCjqp50TXUA
Date: Tue, 20 Oct 2015 14:21:09 +0000
Message-ID: <>
References: <emba60df91-e131-42b6-bc8b-80ae0eb547d9@helsinki>
In-Reply-To: <emba60df91-e131-42b6-bc8b-80ae0eb547d9@helsinki>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D24B99355C010eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4582bis-15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Oct 2015 14:21:34 -0000

Thank you, Paul, or the thorough update of the document and summary of changes.

For all of you who have been helping with this draft and/or following along, these changes were primarily motivated by comments from IESG review. Those with comments are of course reviewing, but I ask that others on this list review as well to make sure you are happy with the end result before we request publication. Please complete your review within the next week, by Oct 28. If necessary, we can use the BFCPBIS session slot at IETF 94 to cover any issues that arise.


From: bfcpbis <<>> on behalf of Paul Jones <<>>
Reply-To: Paul Jones <<>>
Date: Tuesday, October 20, 2015 at 2:45 AM
To: "<>" <<>>
Subject: [bfcpbis] draft-ietf-bfcpbis-rfc4582bis-15


A new revision of draft-ietf-bfcpbis-rfc4582bis (-15) was published just a few days ago.  This is a summary of what was changed

  *   Several editorial changes to clarify the text, making "should" a "SHOULD", "REQUIRD" to "required", "SHALL" to "MUST", etc. based on feedback sent to the list, DISCUSS comments, etc.
  *   Corrected a few places where the wrong message was referenced (copy/paste errors)
  *   Put parentheses around the message size calculation in 6.2.3 for clarity
  *   Enhanced the examples in Appendix A to explicitly show the "R" value to add clarity
  *   Removed "This User ID will be used by the floor control server to authenticate and authorize the request." in several places in the text, since the User ID neither authenticates nor authorizes.
  *   Clarified text in 5.1 regarding unsupported messages
  *   Removed superfluous text "At this point" in several places
  *   Added a note about predictable conference identifiers to warn against such use
  *   Added language to encourage discarding message if fragment lengths are not right
  *   Adjusted the T1 and T2 timers to implement RFC 2988 (TCP retransmission timer calculation)
  *   Removed text suggesting to use ICMP messages to control behavior, as those are subject to off-path attacks
  *   Clarified text in B.1.1.6 to present it in a historical context
  *   Explain that "Hello" is more than just for liveness checks (for unreliable transports, at least)
  *   Correct error in 6.2.3 that said fragment offset length was in bytes (should be "4-octet units")
  *   Explain that if timer T1 expires, that means the connection is broken.
  *   Changed text in 9.1 to make it clear that the protocol is not restricted to self-signed certificates
  *   Removed redundant language in 13.7
  *   Defined "transaction failure window"
  *   Made it clearer that the fragment offset / fragment length word is never present when using a reliable transport
     *   Note, that said: what really guides presence is the "F" bit, but the point is these fields should not be there if the transport is reliable
  *   Made clarifying changes to the IANA section (since most is already registered)
  *   Changed the ABNF syntax to remove unnecessary parentheses

Hopefully, that's everything.  Many small changes, but I think that addresses all of the outstanding comments.  I did notice a missing period at the end of section 5.1.  If we're only down to that, I believe the text is ready to go. :)