Re: [core] Ben Campbell's No Objection on draft-ietf-core-block-19: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Ben,

your COMMENTs should be addressed in draft-ietf-core-block-20

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I moved the following from a DISCUSS to a COMMENT, pending the next
> revision:
> 
> -- START:
> 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.
> 
> -- END

The two SHOULDs are now plain text describing the outcome, not the
behavior of each peer.  (See the changes on what is now page 11.)

> 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.)

Here, the risk of creating new problems needs to be weighted against the
convenience for new readers.  As I told Mirja, I refrained from major
surgery.

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

(It is quite mnemonic after a while, and it is less confusing than other
alternatives we have discussed.)

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

Reinforced by new text in the intro to section 2 (page 5).

> - 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).

I'm still not sure how to address this.

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

(See my previous comments.)

> 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.

(See my previous comments.)

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

(Entirely removed the term instead, page 11.)

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

(As discussed)

Grüße, Carsten