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
