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

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 19 Apr 2016 20:55:47 -0700

Suresh Krishnan 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:
----------------------------------------------------------------------

Is there a specific reason that the 4.08 response code is overloaded for
use for two different kinds of issues?

a) Mismatching Content-Format options in different blocks
b)  not all previous blocks are available at the server at the time of
processing the final block of an atomic operation

Section 7.1:

Have you thought about how this text can be made actionable, especially
in the case of atomic PUT or POST requests without maintaining state? If
so, it would be good to elaborate here.

"Wherever possible, servers should therefore minimize the opportunities
to create state for untrusted sources, e.g. by using stateless
approaches."

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 23:44:49 +0200

Hi Suresh,

In the logic of this draft, these cases aren't so different:
If you start a new sequence of blocks with a different Content-Format in
the middle, the server is not going to have matching blocks available
for the previous block numbers.  So you get the same error code that you
get with starting a transfer in the middle from scratch.

> in the case of atomic PUT or POST requests without maintaining state? 

Mostly by "don't do that".
The problem is the same we have with reassembly buffers at the IP level.
You just make sure that you don't commit too many resources to them.

> If

i.e., best don't offer atomic transactions outside of authorized
connections.  (Or at least exercise tight control over the state
created, and discard early/often.)

Grüße, Carsten