[core] Ben Campbell's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-core-block-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-block/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be easy to clean up, and it's entirely possible I am
misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be
inconsistent in SHOULD vs MUST for block size.  I _think_ I'm reading the
following:

1. If the client requests a specific block size, the server MUST use that
size or a smaller one. 

2. Any subsequent requests from the client MUST indicate the same size
that the server used

3. But paragraph 3 then says all further requests SHOULD indicate the
same size. But if they already MUST indicate the same size as in the
initial response, then this   SHOULD seems non-constraining at best, and
at worst in conflict with 1. (ignoring the last-block size issue for the
moment.)

4. Then paragraph 3 goes on to say the server SHOULD use the block size
indicated in the request or smaller. This seems to conflict with the MUST
in 1.

5.  Then it again asserts that the client MUST indicate the same size in
subsequent requests, conflicting with the SHOULD in 3., but agreeing with
the MUST in 1.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

- General: The draft dives into detail without giving much context until
the examples. The reader is left to infer the forest from the trees. It
would be very helpful (to me, at least) to add a high-level overview of
operation early in the document, including definitions for "descriptive"
vs " control" usages. (I know it's late in the process to ask for a whole
new section, so I won't push the point.)

- The distinction between the option names Block1 and Block2 seems almost
actively non-mnemonic. Is that intentional? (I won't push this point,
either.)

- 3.4: Does the eTag apply to the "payload" or the whole "body"?

- 2.5, 2nd paragraph, last sentence:
Should I read this to mean that the reduction in block size is
retroactive? That could use some elaboration. (I thought I read comments
in the examples suggesting such a reduction would _not_ be retroactive).

- 7: Does "object security" apply to the "payload", or the "body"?
Can you describe or add a reference for the "usual considerations"?

Editorial:

- Abstract: That’s a really long abstract, and serves more as an
introduction than an abstract. Please consider combining the first and
last paragraph and leaving the rest to the introduction.

- 2.4, paragraph 5: a definition for "reassembler" would be helpful.

- Figures 5 and 6:
There's no discussion of either figure. Is that intentional?