Re: [PATCH] doc: Improvements to block-status
Hi Eric,
On a general note, reviewing these kinds of changes is easier if you
send separate patches for normative changes and for reflowing the text;
otherwise I have to read every paragraph you touched twice, hunting for
the changes you made. This is a waste of everyone's time ;-)
On Wed, Mar 14, 2018 at 05:52:44PM -0500, Eric Blake wrote:
[...]
> +The query string with no `[leaf-name]` is only valid within
> +`NBD_OPT_LIST_META_CONTEXT`. If a `[leaf-name]' requested by the
> +client is not recognized, the server MUST ignore it rather than
> +reporting an error.
I think we discussed this point when we originally spec'd the
BLOCK_STATUS extension, and decided at the time that we wanted to leave
this up to the extension to decide. However, I do agree that it's
probably a bad idea to have only a namespace for SET.
Can you perhaps reword it so that this becomes a requirement for the
base: namespace, and only a SHOULD (but not a MUST) for other
namespaces?
> #### `base:allocation` metadata context
>
> The `base:allocation` metadata context is the basic "allocated at all"
> @@ -1261,11 +1268,6 @@ of the newstyle negotiation.
> Return a list of `NBD_REP_META_CONTEXT` replies, one per context,
> followed by an `NBD_REP_ACK`.
>
> - If the query string is syntactically invalid, the server SHOULD send
> - `NBD_REP_ERR_INVALID`. If the query string is syntactically valid
> - but finds no metadata contexts, the server MUST send a single
> - reply of type `NBD_REP_ACK`.
> -
[...]
> + If the query string is syntactically invalid (such as lacking the
> + colon that would delimit the namespace, or using a leaf name that
> + is invalid for a known namespace), the server MAY fail the request
This turns a SHOULD into a MAY. Any specific reason for that?
[...]
Other than that, LGTM.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: