Re: [core] I-D Action: draft-ietf-core-new-block-06.txt

[Christian Amsüss <[e-mail]>]

Hello new-block authors,

here a few notes that I didn't see fitting any of the previous
threads (or so I hope):

* "can fall back to using Block1 and Block2 Options, respectively": Even
  though the rest says (as agreed on) that it's both-or-none, the
  "respectively" seems to imply otherwise -- maybe just drop the word.

* CSM option: "There is little, if any, benefit of using these options
  with [reliable transports]" ... and reliable transports are the only
  thing CSMs are defined for. So why define a CSM if it's not expected
  to be useful?

* Ad Class E/U: It may be worth stating that it *is* allowed to mix
  Block and Q-Block when one is inner and the other is outer -- for the
  simple reason that there'd be no way to enforce anything else, for
  proxies along the path can perform outer-blockwise transfers in
  ignorance of the content.

  (Then, at a receiver, an outer Block option could arrive, and when
  that's done, it should still process the inner Q-Block without erring
  just because the two worlds met).

* 3.3 Use of the QB1 option:

  The rules for the final message are different between 2.04 Changed
  ("token SHOULD be from the last received payload") and 2.05 Content
  (~"MUST be the one in the final block"). Any reason for that? The
  former sounds more sensible. (I originally favored the latter, but
  then when a 4.08 comes back on the last-block request, the same token
  would need to be used for the final successful response too, and
  that'd be awkward -- and I'd prefer to avoid it if we can pick the one
  rule set ("SHOULD from the last received") that allows having only one
  response per token unless there are actually multiple blocks
  transported on it).

* 3.5 Block + Observation: Has this been implemented and tested? The
  combination of Block1(!)+Block2+Observer is already tricky with
  regular blocks, and made harder by the semi-noresponse blocks here.

  Unless you have a use case for it, I'd ask to see this implmeneted
  before it is published, or else to leave this as "interactions are up
  to further specification" (with a corresponding note in the
  ups-and-downs list) in the interest of getting this on speedily (given
  this document's purpose is to get the DOTS use case running).

* The 2.31 Continue rules: Why not send it with CON? A 2.31 Continue is
  just as compact as an ACK, and can convey to the client that all
  packages up to that point have been received, so it doesn't need to
  retransmit the earlier ones even though the corresponding ACK may have
  gotten lost.

* The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But that
  agreement is SHOULD only, and even that's already stretching what I'd
  expect of a configurable CoAP parameter.

  It's also rather complicated. How is this better than a simple "M=1
  means this block plus as many as you can comfortably send, where M=0
  is for this one only"?

* "is meant to prevent amplification attacks": Could you elaborate? A
  client permitted the use of QB2 has already some leverag on the server
  to start attacks, and would in any case (overlaps or not) only be
  permitted MAX_PAYLOADS on a single request by the server, no matter
  how it requests more than that.

* "then the body response SHOULD be restarted with a different ETag
  Option value": That behavior sounds like a recipe for endless running
  requests when CON is involed (which, granted, are under flow control,
  but still don't do anything useful). Given there is also a
  recommendation to keep the being-transmitted version alive, why not
  just stop the transmission?  Or send just one final block of the new
  value -- and then it's up to the client to decide whether that's a
  representation it already knows (and just got a freshness statement
  for) or needs to get it as a whole again?

* 3.6 Size1/2: These options MUST be used per 3rd paragraph, so the "If"
  in the 4th is odd.

* (General wording: It's "A comprise X and Y" or "A is comprised of X
  and Y"; https://en.wiktionary.org/wiki/comprise#Usage_notes "in the
  passive voice")

* 4 the new 4.08 format: Since this is a CBOR sequence, the
  implementation note on telling the array length in advance does not
  apply. As for the CDDL, I don't know whether the array format is OK to
  use for the sequence, or whether the CBOR 

* 5. Use of Tokens: The MUST on the unique tokens misrepresents
  echo-request-tag. There are rules there about when a token can or can
  not be reused, and they depend on factors immaterial to the present
  specification.

  In particular, when used with CoAP-over-TLS or with OSCORE, using
  non-unique tokens is quite alright.

  I recmomend not making a normative statement where none is required;
  eg.

  "Each new request generally uses a new Token (and sometimes must, see
  Section 4 of ERT).  Additional responses to a request all use the
  token of the request they respond to".

* "Implementation Note: To minimize": I'd prefer to go with "it is
  suggested" rather than "recommended", but as long as it's not in
  normative language, I don't care too much.

* "Servers continue to treat": While not factually incorrect considering
  the above recommendation, the reference to the 32 bits in the
  paragraph about the server is confusing. Last prenthized expression
  could read "(i.e., is sent on the token of the request that caused
  its retransmission)".

* (I skipped through the congestion contol section for the time being;
  it's probably best read by someone with some experience in congestion
  control which I lack).

* "When the next client completes building the body, any existing
  partial body transmission to the CoAP server is terminated": Just a
  note, you're already using Request-Tag, so you could leave it up to
  the proxy to try to run them simultaneously (it obviously can, as it
  already got to the point of having both request bodies loaded in
  full). The server can then still cancel one or postpone the other.

* Figure 6: The first line says "for RT=11", that's probably a remnant
  from when the Request-Tag was copied into the payload. (Same for later
  '[for RT=...]' items

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom