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

From: "Ben Campbell" <[email-masked]>
Date: Thu, 21 Apr 2016 07:09:04 -0700

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

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/

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

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?

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Apr 2016 16:48:41 +0200

Ben, I agree with your statements about the need for an overview and the
use of the Block1 and Block2 mnemonics. The Block1/Block2 functionality
is heavily overloaded and really only best understood when looking at
the examples. Conceptually, this is a fairly simple mechanism but the
way it is written makes it sound somewhat complex.

Ciao
Hannes

On 04/21/2016 04:09 PM, Ben Campbell wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Apr 2016 21:03:10 +0200

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

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

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

> actively non-mnemonic. Is that intentional? (I won't push this point,

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

> in the examples suggesting such a reduction would _not_ be retroactive).

I'm still not sure how to address this.

> Can you describe or add a reference for the "usual considerations"?

(See my previous comments.)

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

> There's no discussion of either figure. Is that intentional?

(As discussed)

Grüße, Carsten