On 04/06/2016 04:37 PM, Alex Bligh wrote:
> These are changes which possibly have semantic effect
>
> * Clarify that SHOULD / MUST / MAY etc. when in capitals have an
> RFC 2119 meaning using the wording within that RFC.
>
> * Fix some lowercase use of these words which actually were
> meant to be uppercase.
>
> * Fix some lowercase 'should' which clearly meant 'MUST'; where
> it's not obvious, I've made them 'SHOULD' or left them as is.
>
> * Fix wording on transmission flags to be clearer.
>
> Signed-off-by: Alex Bligh <alex@...872...>
> ---
> doc/proto.md | 102 +++++++++++++++++++++++++++++++++++------------------------
> 1 file changed, 60 insertions(+), 42 deletions(-)
> @@ -752,20 +770,19 @@ Therefore these commands share common documentation.
> server has multiple alternate names for a single export, or a
> default export was specified.
>
> - 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature