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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 18 Apr 2016 20:24:38 -0700

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?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 09:44:23 +0200

(Section 2.4, I presume.)

> 1. If the client requests a specific block size, the server MUST use that

Yes, that is the negotiation logic.

> 2. Any subsequent requests from the client MUST indicate the same size

(If the Block2 option was given in the first request.)

> at worst in conflict with 1. (ignoring the last-block size issue for the

This is for the general case, including the one where the Block2 option
came in as a surprise for a request without a Block2 option.  The client
might want to adjust that block size down again in its second request
(the first one with a Block2 request option).  But the SHOULD is
unfortunate, because the sentence is really describing the likely
outcome and not a mandate on the client behavior.

> indicated in the request or smaller. This seems to conflict with the MUST

That is indeed an unfortunate construction (with the "or").

> subsequent requests, conflicting with the SHOULD in 3., but agreeing with

Thank you for noticing this jumble; to be cleaned up in the next draft.

Others have already been complaining about too much text...

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

Go ahead and invent better ones... We tried.  (Block1 is for the bodies
in the requests, which are the first messages in an exchange, Block2 for
bodies in the responses, which are the second messages in an exchange.)

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

To the body.  We say this explicitly for the Content-Format, but not for
ETag; we probably should.  I have added text to the penultimate
paragraph of Section 2 in the editor's draft.

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

The transfer that already happened used a certain block size, and that
history of course doesn't change.  The last sentence points out that if
the next transfer uses a different (smaller) block size, the block
number needs to be scaled up so we hit the right continuation point.

> - 7: Does "object security" apply to the "payload", or the "body"?

Yes.  That is the discussion we are having in defining object security
extensions.  Both may be useful (actually, it may be even better to
define a third level between "payload" and "body" which defines the
slices to be secured independently).

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

For Buffer Overflows?  Good question.  Is there a canonical reference
for that?  (If the reader doesn't already know about buffer overflows,
maybe they shouldn't be implementing protocols?)

> last paragraph and leaving the rest to the introduction.

Actually, I consider this to be a quite useful abstract -- many RFC
abstracts are too short to be really useful as an abstract (as in "why
should I be reading this document" and "if I don't read it, do I still
know what it is about").  It hasn't been through the "leave out every
third word" filter yet, but, hey, it fits on the first page :-)

There is a larger discussion about RFC style lurking here; maybe this
isn't the place.

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

Maybe it's easier to simply s/client's reassembler/client/.
Done in editor's draft.

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

Is discussion beyond the introductory paragraph on page 18 needed?
(Students typically found these figures self-explanatory.)

Grüße, Carsten

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 21 Apr 2016 08:58:01 -0500

> Thank you for noticing this jumble; to be cleaned up in the next 

Thanks, I will release the DISCUSS now, but will watch for the update.

> Others have already been complaining about too much text...

Others have complained about duplication; that's not what I'm asking 
for. (In fact, I agree with them). In any case, this was a non-blocking 
comment.

> bodies in the responses, which are the second messages in an 

Again, a non-blocking comment. But how about Block-Req and Block-Resp? 
(or Req-block and Resp-block)? Those are obvious enough that I suspect 
people have already discarded them for some reason...

> paragraph of Section 2 in the editor's draft.

Thanks

> number needs to be scaled up so we hit the right continuation point.

I think I understand. A bit of elaboration might help.

> maybe they shouldn't be implementing protocols?)

I'm not aware of one --I was hoping you knew of some citable guidance 
:-) It's not a big deal if there's not one.

> There is a larger discussion about RFC style lurking here; maybe this

Probably not. I won't push the matter.

> Maybe it's easier to simply s/client's reassembler/client/.

works for me.

> (Students typically found these figures self-explanatory.)

It's fine as it is if that is on purpose.

Thanks!

Ben.