Re: [core] Review of draft-ietf-core-echo-request-tag-07

[Christian M. Amsüss <[e-mail]>]

Hello Francesca,

thanks for your review. I'm only answering the points that are not
addressed in parallel by Göran and John. Comments that resulted in a
simple probably uncontroversial text change were moved to the end of the
mail; they are reflected in a [pending pull request].

> # High level suggestions #

(Out of scope here, but to get it documented: The topic intros will move
to the topics as you suggested. Appendix A will stay and maybe grow a few
words on its applicability to not give the impression that this is the
generally recommended algorithm for all scenarios).

> * Section 3.2
> 
> I am not sure it is said anywhere what the server should do if it
> supports the Request-Tag option and it receives it in a non-blockwise
> message... I guess just discard, but it would be good to explicitely
> state.
> 
> Also, could this option be used for something else? For example, I am
> thinking of Observe operations, re-registration... Does not need to be
> defined here, but if we MANDATE that it can only be used with
> blockwise, we are practically stopping any other use that might come
> up...

I did consider making this a "MUST NOT process" for anything else, but
I think that would rule out those other applications that you think of.

Currently we state that they MUST NOT be present when neither Block1 nor
Block2 is present (though, AFAIR, without good reason other that we
don't see a use case). Should that be left in, or would you like to see
that relaxed?

> * Section 3.4.3
> 
> I believe this section is missing something on the lines of: 
> 
> "Proxies that are aware of this specification can modify their
> implementation to simply forward block operations."
> 
> Would you agree?

It already says "If it [does X], it does not need to keep track of any
further block state." say that?

(I might add " and can simply forward the messages", but would that
really add something?)


KR
c

[pending pull request]: https://github.com/core-wg/echo-request-tag/pull/51


---

"simply fixed" comments:

> "   (Concurrent block-wise request operations are impossible with the
>    options of [RFC7959] because the second operation's block overwrites
>    any state of the first exchange.).
> "
> 
> I believe this is true, but could you point to the section that states
> that? I didn't manage to find it while checking.

Reference made more precise, "from a single endpopoint" added.

> " They can
>    still be treated as independent messages by the server (e.g. when it
>    sends 2.01/2.04 responses for every block), or initiate a new
>    operation (overwriting kept context) when the later message carries
>    Block1 number 0.
> "
>
> I have a hard time parsing/understanding this paragraph, particularly from "or initiate..."

Split up into separate sentences for better clarity.

> * Section 3.3
> 
> "
>    Clients MUST NOT recycle a request tag unless the first operation has
>    concluded. 
> "
> 
> in the case where a client supports but does not use Request-Tag, this
> implies "concurrent block operations without Request-Tag are not
> allowed". If that is the case, I would like that to be stated
> explicitely.
> 
> (also minor, I'd like to add "that support Request-Tag" after "Clients")

That requirement was already kind of conditional on the client using
Request-Tag for a particular purpose -- for otherwise the "unless
concluded" clause makes no sense, for that's defined by the purpose.

Rephrased to pull in the purpose before the MUST and make that explicit.

The "that support Request-Tag" comment should be obsolete by hat, for
only who supports it can use it for something.

(We did, in the chat earlier, consider asking the WG whether that'd all
mean that we're updating RFC7959, but as we're now back to "If you want
to achieve X, do Y" wording, I don't see necessity for such an update).

> * Section 3.3
> 
> The last sentence gives some requirements about where the Request-Tag
> option can/musty be used per message. I felt the document was missing
> on usage requirements (e.g. if it is set, it MUST be set for all
> requests for a specific operation)

Added to the initial (now split up) paragraph of that section.

> * Section 3.4.2
> 
> "
>    When initializing a new block-wise operation, a client has to look at
>    other active operations:
> 
>    o  If any of them is matchable to the new one, and the client neither
>       wants to cancel the old one nor postpone the new one, it can pick
>       a Request-Tag value that is not in use by the other matchable
>       operations for the new operation.
> 
>    o  Otherwise, it can start the new operation without setting the
>       Request-Tag option on it.
> "
> 
> Does not cover the fact that Request-Tag can be omitted if that is a
> different from the other matchable operations. ("pick a new value"
> excludes it)

Explicitly included as an option now.

(Would have been even easier if there were a once-and-for-all definition
of a "request-tag value" that can be absent or have the option's data,
but that had long-winded wording in the last version that was in, and
still might be mistaken by readers that don't have the precise
definition at hand).