On 04/14/2016 09:31 AM, Alex Bligh wrote: > > On 14 Apr 2016, at 14:59, Eric Blake <eblake@...696...> wrote: > >> On 04/14/2016 04:29 AM, Alex Bligh wrote: >>> Eric, >>> >>>> +Both options have identical formats for requests and replies. The only >>>> +difference is that after a successful reply to `NBD_OPT_GO` (i.e. zero >>>> +or more `NBD_REP_INFO` then an `NBD_REP_EXPORT`), transmission mode is >>>> +entered immediately. Therefore these commands share common >>>> +documentation. >>> >>> So just to check, for an *unsuccessful* option, can I send a sequence >>> of NBD_REP_INFO followed by (e.g.) NBD_REP_ERR_TLSREQD? >> >> Seems like a reasonable request, although I hadn't thought of it. It >> risks leaking information, but there's nothing wrong with a SELECTIVETLS >> server that doesn't mind leaking information. > > And indeed a FORCETLS server can reply with NBD_REP_ERR_TLSREQD. > Technically, a FORCETLS server MUST reply with NBD_REP_ERR_TLS_REQD, without any intervening NBD_REP_INFO. Only a SELECTIVETLS server MAY send intervening NBD_REP_INFO before ultimately failing (as in, "I'm willing to tell you details about the export, but I will conclude by telling you that you must upgrade to TLS before relying on those details"). >>> If I'm right above 'the final `NBD_REP_EXPORT` or error'. >> >> In fact, with your approach coupled with Wouter's desire to end on >> NBD_REP_ACK rather than NBD_REP_EXPORT, it becomes 'zero or more >> NBD_REP_INFO followed by NBD_REP_ERR_*, or at least one NBD_REP_INFO >> followed by NBD_REP_ACK' > > Yes. > >> Okay. And thinking about it more, a server may indeed want to advertise >> all names by which an export is known, so NBD_INFO_NAME could even be >> given more than once (but then the wording needs to no longer call out >> that it is a 'canonical' name). > > Mmmm ... maybe. I'm not actually quite sure what the purpose of > sending the canonical name is, but if there is a purpose may be > we should set a 'canonical' flag on that one. That argues that either we add a canonical field to NBD_INFO_NAME, or we have two separate types: NBD_INFO_CANONICAL_NAME (at most once), and NBD_INFO_ALTERNATE_NAME (as many as wanted). I don't have any strong preferences about the need or desire to expose more than one name; anyone else want to chime in on whether I'm over-engineering things for current needs? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature