Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

[Wouter Verhelst <w@uter.be>]

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