Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Martin, 

Thank you for the review. The changes can be tracked at: https://tinyurl.com/new-block-latest. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Martin Duke via Datatracker [mailto:[e-mail]]
> Envoyé : vendredi 30 avril 2021 01:24
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Martin Duke's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-core-new-block-11: Discuss
> 
> 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 DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> 
> 
> 
> ---------------------------------------------------------------------
> -
> DISCUSS:
> ---------------------------------------------------------------------
> -
> 
> I am concerned about the convergence of three different provisions in
> this spec:
> 
> - In (4.1), it says "To reliably get a rejection message, it is
> therefore
>    REQUIRED that clients use a Confirmable message for determining
>    support for Q-Block1 and Q-Block2 Options."
> 
> IIUC this mandates that at least one request will use CON.
> 
> - (7.1): all the blocks of a single body over an
>    unreliable transport MUST either all be Confirmable or all be Non-
>    confirmable.
> 
> - (7.2) However, the other CON congestion
>    control parameters will need to be tuned to cover this change.
> This
>    tuning is out of scope of this document as it is expected that all
>    requests and responses using Q-Block1 and Q-Block2 will be Non-
>    confirmable (Section 3.2).
> 
> I can't reconcile (4.1) with the last sentence in (7.2).

[Med] Why? 4.1 can be done with default CoAP setting. The purpose of this CON request is to determine support of the functionality. We made this change:

OLD:
   Congestion control for CON requests and responses is specified in
   Section 4.7 of [RFC7252].  In order to benefit from faster
   transmission rates, NSTART will need to be increased from 1.
   However, the other CON congestion control parameters will need to be
   tuned to cover this change.  This tuning is not specified in this
   document given that the applicability scope of the current
   specification assumes that all requests and responses using Q-Block1
   and Q-Block2 will be Non-confirmable (Section 3.2).

NEW:  
   Congestion control for CON requests and responses is specified in
   Section 4.7 of [RFC7252].  In order to benefit from faster
   transmission rates, NSTART will need to be increased from 1.
   However, the other CON congestion control parameters will need to be
   tuned to cover this change.  This tuning is not specified in this
   document given that the applicability scope of the current
   specification assumes that all requests and responses using Q-Block1
   and Q-Block2 will be Non-confirmable (Section 3.2) apart from the
                                                      ^^^^^^^^^^^^^^  
   initial Q-Block functionality negotiation.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 Moreover, if
> my reading of (4.1) is correct, it's not sufficient to declare
> congestion control guidance out of scope when it's a mandated part of
> the protocol.
> 
> 
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> Thank you for the examples. They were useful in providing an overview
> of the protocol.
> 
> Thanks also to Colin Perkins for an especially thoughtful TSVART
> review. Please address his comments, although his concerns about
> (7.1) are IMO mostly subsumed by my DISCUSS.
> 
> - It would be useful to introduce the "token", "request tag", and
> "Etag"
> concepts before using them. Reading front-to-back, I spent most of
> Section 4 confused.

[Med] As called out in Section 2, the assumption is that the reader is familiar with CoAP concepts. That’s said, we can add some key concepts. We made this change: 

OLD:
   Readers should be familiar with the terms and concepts defined in
   [RFC7252], [RFC7959], and [RFC8132].  

NEW:
   Readers should be familiar with the terms and concepts defined in
   [RFC7252], [RFC7959], and [RFC8132].  Particularly, the document uses
   the following key concepts:

   Token:  is used to match responses to requests independently from the
      underlying messages (Section 5.3.1 of [RFC7252]).

   ETag:  is used as a resource-local identifier for differentiating
      between representations of the same resource that vary over time
      (Section 5.10.6 of [RFC7252]).

   Request-Tag refers an option that allows a CoAP server to match
   message fragments belonging to the same request
   [I-D.ietf-core-echo-request-tag].

> 
> - (4.4) It would be useful to state that clients MUST (SHOULD?) NOT
> request retransmission of blocks from ETags that are not "fresh" --
> IIUC, they probably don't exist anymore, and anyway the server has no
> way of knowing which non-fresh ETag to serve beacuse it says "The
> ETag Option should not be used in the request for missing blocks"
> 
> BTW, s/should/SHOULD

[Med] We used to have the normative language but we changed it as per a valid comment we received from the WG. The reasoning is that this is more a factural statement than a normative one. The client cannot use it to retrieve a missing block as the server may reply with 2.03 (Valid) (which has no data) instead of 2.05 (Content) if a valid ETag was included.    

> 
> - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the
> same value as computed for EXCHANGE_LIFETIME", why are they different
> variables?

[Med] Because they refer to distinct aspects that may be tweaked separately: the timeout induced by PROBING_RATE and the one to observe for expired partial bodies. 

 Or is that they SHOULD have the same value but might not?
> A normative word would be helpful here.

[Med] Not sure a change is needed here given the definition of the two parameters.

_________________________________________________________________________________________________________________________

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.