[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv6] Improve documentation for TLS
From: |
Alex Bligh |
Subject: |
Re: [Qemu-devel] [PATCHv6] Improve documentation for TLS |
Date: |
Sun, 10 Apr 2016 10:02:47 +0100 |
Eric,
Thanks. In v7 I've taken all of these, save where indicated
(or as described) below.
>> +If the server receives `NBD_OPT_STARTTLS` it MUST reply with
>
> Worth mentioning 'prior to initiating TLS', since...
> ...the behavior after initiating TLS is required to be different?
As you point out later (and as I found independently) this
difference was not explicitly set out. It now is.
> Worth mentioning that clients should be prepared to encounter buggy
> servers (qemu 2.5) that disconnect rather than properly send an error
> message? Maybe not, since the buggy versions will eventually be ancient
> history, and since you already stated above that either party can
> disconnect at any time for any reason during handshake phase.
I think not worth mentioning. There may be (and probably are)
buggy clients of all sorts. In this case Qemu's behaviour isn't
technically a bug anyway as it can drop the session at any
time. It's merely being someone ungracious.
> You deleted the requirement about MUST reply with NBD_REP_ERR_INVALID
> when the client sends NBD_CMD_STARTTLS when already in TLS, but I don't
> see it above. Arguably, since we required above that the client MUST
> NOT send NBD_CMD_STARTTLS twice, it's already undefined behavior, but
> requiring that the server MUST reject with NBD_REP_ERR_INVALID would
> make it harder for implementations to get it wrong when dealing with
> buggy clients.
Reinstated explicitly in the TLS section, and mentioned in the
NBD_OPT_ section too. Thanks for catching that one.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail