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