On 04/11/2016 01:33 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 | 100 +++++++++++++++++++++++++++++++++++------------------------ > 1 file changed, 59 insertions(+), 41 deletions(-) > > Changes since v5: > > * Rebased on top of "Improve documentation for TLS" > > * Eric's nit re NBD_OPT_INFO fixed in passing > @@ -1031,20 +1049,19 @@ Therefore these commands share common documentation. > - 64 bits, size of the export in bytes (unsigned) > - 16 bits, transmission flags. > > - The server MUST NOT fail an NBD_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 > + The server MUST NOT fail an `NBD_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 NBD_OPT_GO as a previous NBD_OPT_INFO unless in the > - intervening time the client has negotiated other options. > - The values of the transmission flags MAY differ from what was sent > + flags with `NBD_OPT_GO` as a previous `NBD_OPT_INFO` with the same > + parameters unless in the intervening time the client has negotiated other > + options. 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. This is what you were referring to above, although I still like my wording better (less repetitive). But I'm fine waiting for yours to land (it is a conflict magnet, and the sooner we get it in, the less we have to keep rebasing it) before reposting my wording improvements. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature