From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aorDh-0000Qc-83 for qemu-devel@nongnu.org; Sat, 09 Apr 2016 07:38:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aorDd-00076h-Ve for qemu-devel@nongnu.org; Sat, 09 Apr 2016 07:38:29 -0400 Received: from barbershop.grep.be ([89.106.240.122]:36355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aorDd-00076b-Q2 for qemu-devel@nongnu.org; Sat, 09 Apr 2016 07:38:25 -0400 Date: Sat, 9 Apr 2016 13:38:11 +0200 From: Wouter Verhelst Message-ID: <20160409113811.GT19023@grep.be> References: <1460053967-65141-1-git-send-email-alex@alex.org.uk> <20160409101117.GI19023@grep.be> <9AD6CFB3-011D-42FF-8652-5BCBF085BE57@alex.org.uk> <20160409103828.GO19023@grep.be> <7E2CCD80-B06D-4F69-87C2-49F703545E00@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E2CCD80-B06D-4F69-87C2-49F703545E00@alex.org.uk> Subject: Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "Daniel P. Berrange" , "qemu-devel@nongnu.org" On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote: > An alternative route would be to delete OPTIONALTLS, and make some of > the MUST requirements in SELECTIVETLS say "MUST xyz unless there are > no TLS-only exports". However, this makes it rather harder to read, > so I described that case as a separate mode. I understand now. However, although I disagree with Daniel on the idea of having a server which can (in the same process) support both TLS-enabled and non-TLS-enabled exports, I do agree with him that what you call OPTIONALTLS is a bad idea, and that it should be discouraged. Mentioning that option explicitly is counter to that goal, and I would therefore prefer that you not add it. Also, while we try to negotiate the protocol in such a way that things remain compatible between implementations who implement a disjoint set of features from the protocol, I think the long-term goal should be that STARTTLS and INFO are supported by all implementations (or at least, that INFO is). In that context, explicitly explaining (in much detail) what happens when a client doesn't support INFO but does support STARTTLS seems contraproductive. So I'd just drop optional. > >> I'd be all for that. Or certainly "SHOULD NOT support LS versions older > >> than 1.2 by default" > > > > Or that. The point is that doing TLS < 1.2 is stupid, especially for a > > new protocol, so I think we should make it explicit that clients should > > not try that save in exceptional circumstances. > > +1. Do you want to ping me when you have had a chance to review v5 and > I will collate all of these in to a v6? I have, but did not have any further comments. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12