Re: [core] WG Last Call on draft-ietf-core-new-block

[[e-mail]]

Hi Christian,

Thanks for this and the time spent thinking about it.  Some items have
already become separate threads.

Otherwise responses inline - part 1.  Some of the changes can be seen at
https://tinyurl.com/new-block-latest 

Regards

Jon

> -----Original Message-----
> From: Christian Amsüss [mailto: [e-mail]]
> Sent: 23 December 2020 05:01
> To: [e-mail]
> Cc: [e-mail]; [e-mail] WG ([e-mail])
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hello new-block authors, hello CoRE,
> 
> I've finally managed to have another look at the document (and it's still
the
> 22nd *somewhere*...).
> 
> My over-all summary is that while this document has matured quite a bit
> (and turned out better than I had expected for the special-purpose blocks
it
> is), I think that the topic of response suppression and congestion control
> sections still have to be sharpened, and the examples could pick a more
> realistic balance between going all-NON and all-CON (or explain why that's
> something that wouldn't be done even though the text reads like that's
> what's expected to be used but maybe it's just me).
> 
> 
> Except for the first item (which is coming back to the notes for the
WGLC),
> all should be more or less sequential in the document (with forward/back
> references as needed).
> 
> * On the downref to No-Response: I don't see the downref as too big an
>   issue. It's a bit odd that that document didn't go through the CoRE
>   WG, but my impression is that it's widely used (on a "when the library
>   I maintain broke it people filed issues" level), and both OSCORE and
>   groupcomm-bis (which is to replace RFC7390) reference it. It's an
>   informative reference because they don't mechanically depend on it,
>   but it shows how well No-Response has been taken up.
> 
>   (Frankly, I'd support a retroactive adoption. I don't suppose we can
>   do that with "adults"?).
> 
>   From how I understand Q-Block to be intended to work, No-Response does
>   not cover all of the behavior (as it's timeout based); still, that
>   document lays good groundwork for what's done here in a rather precise
>   way (see comment on "For Confirmable transmission, the server MUST
>   continue" later on) where this document needs the examples to be fully
>   understood.
> 
>   Based on the later text on MAX_TRANSMIT_SPAN, why not at least
>   acknowledge the equivalence? Maybe like this:
> 
>   > The behavior of endpoints following this draft can equivalently b
>   > described in terms of the No-Response option {{?RFC7967}}:
>   >
>   > For a message with a Q-Block1 option with M=1 that is followed by
>   > another message on the same Request-Tag within MAX_TRANSMIT_SPAN
> [
>   > or MAX_BLOCK_JITTER, see later ], the default value for No-Response
>   > is 8 (suppressing the 4.xx code that would be returned due to the
>   > incomplete request); an explicitly set No-Response option would
>   > override that."
> 
>   although I'd still advocate just using No-Response for the whole
>   definition even if No-Response is not typically expressed.
> 
>   (I'm not really sure what the correct response would be for an
>   individual non-terminal request if it were to be answered due to an
>   explicit No-Response:0 -- might be 2.31 Continue that's just not
>   used in this specification because it's always suppressed? I'll come
>   back to that -- but then it'd rather be No-Response: 10).
> 
> * intro: WebSockets (capitalization)

[Jon] OK
> 
> * The list of pros and cons (with the cons being almost trivial) does
>   not explain to the reader why these are not a replacement; I suggest
>   to add:
> 
>   * The Q-Block options do not support stateless operation / random
>     access.

[Jon] Actually Q-Block2 does now support this following the redefinition of
the M bit usage in a previous iteration (with M=0 you can ask for any
individual block).

[Jon] For stateless, Request-Tag is included so this should be fine.
https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#section-4
.2
> 
>   * Proxying of Q-Block is limited to caching full representations.
> 
>   (The latter might be mitigated by additional text around caching, but
>   I doubt it's worth the effort given it's not part of the use case).
[Jon] I am not entirely convinced that Block1/2 have got the caching by
block properly sorted out - e.g. what happens when different clients make
requests with different SZX and Block2 is part of the cache key.  The
limiting to caching full representations is there so that a new can of worms
is not opened up.

[Jon] I will see if I can think of any further cons.
> 
> * "compromises of": I don't understand that sentence.

[Jon] OK  s/compromises of/comprises of/
> 
> * "the asymmetrical packet loss is not a benefit here": It never is;
>   what is meant here?

[Jon] OK.  How about (which is obvious, but a reminder to the implementer)
OLD
However, the asymmetrical packet loss is not a benefit here.
NEW
However, the use of Confirmable messages will not work if there asymmetrical
packet loss. 
> 
> * "Updated CoAP Response Code": "This document updates" sounds like a
>   formal update to RFC7959, which it neither is nor needs to be.
>   Phrasing it along the lines of "adds a media type that can be used
>   with 4.08" would ease that.

[Jon]
OLD
1.2.  Updated CoAP Response Code (4.08)

   This document updates the 4.08 (Request Entity Incomplete) by
   defining an additional message format for reporting on payloads using
   the Q-Block1 Option that are not received by the server.
NEW
1.2.  CoAP Response Code (4.08) Usage

This document adds a media type for the 4.08 (Request Entity
 Incomplete) response defining an additional message format for
 reporting on payloads using the Q-Block1 Option that are not received 
 by the server.
> 
> * "Only C and U columns are marked": "The Q-Block1 option is critical, and
>   unsafe for proxies to forward" would be easier to read -- which
>   checkboxes are marked is visible alrady from the table. (Or just leave
>   it for the later paragraphs that say that in more detail).

[Jon] OK. Gone with Critical etc.
> 
> * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the
>   Q-Block1 option" first paragraph).

[Jon] OK
> 
> * "Is opaque in nature, but it is RECOMMENDED" on being a counter and
>   starting off random: Like other similar suggestions (ETag), this is
>   implementation guidance level and not required for interoperability.
>   Maybe phrase this the same way as the recommendations on tokens?

[Jon]
OLD
The Request-Tag is opaque
   in nature, but it is RECOMMENDED that the client treats it as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
   The server still treats it as an opaque entity.  The Request-Tag
   value MUST be different for distinct bodies or sets of blocks of data
   and SHOULD be incremented whenever a new body of data is being
   transmitted between peers.  The initial Request-Tag value SHOULD be
   randomly generated by the client.
NEW
The Request-Tag is opaque, the server still treats it as opaque but the
client SHOULD ensure that it is unique for every different body of
transmitted data.

Implementation Note: It is suggested that the client treats the Request-Tag
as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
The initial Request-Tag value should be randomly generated and then
subsequently incremented  by the client whenever a new body of data is being
   transmitted between peers.

OLD
   The ETag is opaque in nature, but it is RECOMMENDED that the server
   treats it as an unsigned integer of 8 bytes in length.  An
   implementation may want to consider limiting this to 4 bytes to
   reduce packet overhead size.  The client still treats it as an opaque
   entity.  The ETag value MUST be different for distinct bodies or sets
   of blocks of data and SHOULD be incremented whenever a new body of
   data is being transmitted between peers.  The initial ETag value
   SHOULD be randomly generated by the server.
NEW
   The ETag is opaque, the client still treats it as opaque but the server
SHOULD ensure that it is unique for every different body of transmitted
data.

Implementation Note: It is suggested that the server treats the ETag as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
The initial ETag value should be randomly generated and then subsequently
incremented  by the server whenever a new body of data is being
   transmitted between peers. 

> 
> * "For Confirmable transmission, the server MUST continue": This reads
>   like new-block could change anything about that, when all it does is
>   do things on the response level. [1] has a good note on that
>   separation topic.
> 
>   [1]: https://tools.ietf.org/html/rfc7967#section-2

[Jon] The intent here was that CON continues to work for each
request/response in that the request needs to be acknowledged, but a
response (piggybacked or separate) is not required.
OLD
For Confirmable transmission, the server MUST continue to acknowledge
   each packet.
NEW
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until retransmission or successful receipt of the body.

[Jon] To be continued in part 2.