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

[[e-mail]]

Hi Christian,

We would appreciate if you can check the latest version of the spec and let us know whether your issues were adequately addressed. A diff can be found at: https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block-03&url2=draft-ietf-core-new-block-06 

To ease tracking issues, please see below an update to the initial replies. 

Replies to the second part of your review can be seen at: 

https://mailarchive.ietf.org/arch/msg/core/zTjLyXkjtjEUka44mvD8E4HSke8/ 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : core [mailto:[e-mail]] De la part de supjps-
> [e-mail]
> Envoyé : jeudi 24 décembre 2020 10:40
> À : [e-mail]; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> 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.

[Med] The following two items were added: 

o  To reduce the transmission times for CON transmission of large	
   bodies, NSTART needs to be increased from 1, but this affects	
   congestion control where other parameters need to be tuned	
   (Section 4.7 of [RFC7252]).  Such tuning is out of scope of this	
   document.	
		 		
o  There is no multicast support.

> >
> > * "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.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.