Eric,
>> - The server MUST NOT fail an NDB_OPT_GO sent with the same parameters
>> - as a previous NBD_OPT_INFO which returned successfully (i.e. with
>> + The server MUST NOT fail an `NDB_OPT_GO` sent with the same parameters
>> + as a previous `NBD_OPT_INFO` which returned successfully (i.e. with
>> `NBD_REP_SERVER`) unless in the intervening time the client has
>> negotiated other options. The server MUST return the same transmission
>> - flags with NDB_OPT_GO as a previous NDB_OPT_INFO unless in the
>> + flags with `NDB_OPT_GO` as a previous `NDB_OPT_INFO` unless in the
>> intervening time the client has negotiated other options.
>
> I failed to notice this earlier, but a server MAY send different
> transmission flags if NBD_OPT_INFO(name1) is immediately followed by
> NBD_OPT_GO(name2), with no intervening client options (because some of
> the transmission flags, like read-only, are determined by the choice of
> export name). The first sentence gets this right ("with the same
> parameters"), the second does not (missing that phrase).
>
>> The values of the transmission flags MAY differ from what was sent
>> earlier in response to an earlier `NBD_OPT_INFO` (if any), and/or
>> the server MAY fail the request, based on other options that were
>> negotiated in the meantime.
>
> And if we reword the second sentence, the third sentence may also need a
> tweak.
>
> However, it may be worth fixing that as a followup patch, and letting
> this one through.
>
> Everything else is looking good from my perspective.
>
I don't think I changed the meaning here (merely added backticks)
so I think this should be addressed separately.
I agree with the change though.
--
Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail