On 04/14/2016 09:31 AM, Alex Bligh wrote: > > On 14 Apr 2016, at 14:59, Eric Blake <ebl...@redhat.com> 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list Nbd-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nbd-general
