qemu-devel
[Top][All Lists]
Advanced

[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




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]