Skip to main content

Telechat Review of draft-ietf-core-new-block-11
review-ietf-core-new-block-11-iotdir-telechat-baccelli-2021-05-03-00

Request Review of draft-ietf-core-new-block
Requested revision No specific revision (document currently at 14)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2021-05-04
Requested 2021-04-28
Requested by Éric Vyncke
Authors Mohamed Boucadair , Jon Shallow
I-D last updated 2021-05-03
Completed reviews Genart Last Call review of -10 by Pete Resnick (diff)
Tsvart Last Call review of -11 by Colin Perkins (diff)
Iotdir Telechat review of -11 by Emmanuel Baccelli (diff)
Comments
Possibly my last request for a IoT directorate review :-O
But, let's have a review on this one but from someone not working in the CORE WG

Thank you

-éric
Assignment Reviewer Emmanuel Baccelli
State Completed
Request Telechat review on draft-ietf-core-new-block by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/PSHaQMAewOUeuslo0yZf8DOO0aM
Reviewed revision 11 (document currently at 14)
Result Ready w/nits
Completed 2021-05-03
review-ietf-core-new-block-11-iotdir-telechat-baccelli-2021-05-03-00
iotdir telechat review of draft-ietf-core-new-block-11
Emmanuel Baccelli, 3 May 2021

====
Summary
====

Many thanks for this document. In general, the spec is well written as far as I
could see. I have a few nits and suggestions (see below).

My main question is about the use of Confirmable messages. Maybe I missed
something, but it seems to me the use of CON messages is not recommended in the
spec, but is nevertheless evoked in the spec. Is there room for 
simplification, or is it considered too "radical" to only specify the use of
Q-Block with non-confirmable messages?

Details below.

Best regards,

Emmanuel

====
Comments
====

# Section 1

## Second to last sentence:
"such a recommendation does not work with a flooded pipe DDoS situation."
=> an explicit ref would feel natural at this point of the text (RFC8782 again?
Or another ref?).

## Last sentence:
Ends a little dry. How about completing it with something similar to:
OLD: "This document introduces the CoAP Q-Block1 and Q-Block2 Options (Section
3)" NEW: "This document introduces the CoAP Q-Block1 and Q-Block2 Options which
allow block-wise transfer to work with series of Non-confirmable messages,
instead of lock-stepping using CON messages".

# Section 3
It would read more naturally to my eyes if you'd swap around the section's
content in the beginning (part before 3.1 begins) like this:
 - move up the overview of the Q-Block options, i.e essentially the part
 "Q-Block1 and Q-Block2 Options are designed to work in particular with NON
 requests and responses..." and onwards; - gather afterwards the bullet points
 summing up the advantages / limitations /drawbacks of Q-Block options compared
 to the Block options.

# Section 4.1
the first time you mention POST, PUT? FETCH, iPATCH etc., I suggest you
explicitly cite RFC8132 again.

# Section 4.3, for Response code 4.13
"If a server receives payloads with different Request-Tags for the same
resource, it should continue to process all the bodies as it has no way of
determining which is the latest version, or which body, if any, the client is
terminating the transmission for." => since this is a *should* and not a MUST,
would it make sense to add reassuring an implementer note on how to comply
while minimzing buffer memory requirements? Are there use cases where the
server is *very* constrained in RAM for instance (say: Class 1 devices in RFC
7228)?

# Section 7.1
Do I understand correctly that this configuration (all confirmable messages for
a given body) is *not* recommended? The statement "it is expected that all
requests and responses using Q-Block1 and Q-Block2 will be Non-confirmable" is
confusing at first sight, it begs the question: why specify the configuration
using CON, then? But maybe I missed something.

# Section 11
If the Request-tag happens to be an outer option (or if there is a proxy) does
the above comment on section 4.3 (response code 4.13) translate in a potential
resource exhaustion vulnerability for the server?