The spec indirectly implies that NBD_OPT_LIST should be sent with a payload size of 0 (nothing in "Option types" mentions it, but NBD_REP_ERR_INVALID under "Option reply types" uses "an NBD_OPT_LIST with nonzero data length" as an example). Meanwhile, we have no mention of payload size for NBD_OPT_ABORT (presumably, for maximum compatibility, the client SHOULD use a payload of 0, but the server MUST ignore payload size altogether); nor for NBD_OPT_STARTTLS (presumably, the client MUST use a payload of 0, and the server MUST reject with an error an attempt to send starttls with payload - for matching existing practice). Similarly, for the structured-reply extension, NBD_OPT_STRUCTURED_REPLY documents "The option request has no additional data" - but does not phrase it in terms of a requirement on either client or server. Should we use consistent wording on all options that are sent without payload (with the possible exception of NBD_OPT_ABORT, since the desired behavior of quitting trumps diagnosing any invalid payload)? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature