Re: [core] AD review of draft-ietf-core-new-block-09

mohamed.boucadair@orange.com Wed, 14 April 2021 14:43 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957BD3A1093; Wed, 14 Apr 2021 07:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebvZRjytFeZT; Wed, 14 Apr 2021 07:43:15 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944C43A109A; Wed, 14 Apr 2021 07:43:15 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4FL4w0210HzBrNg; Wed, 14 Apr 2021 16:43:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1618411392; bh=EDVC0UcLpL1xzV3y/D8SjqHxrm6Bpk8/P4ojoI+tYTA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HUUMDi7Mfbbf1xZhRjZMzD1AWdFnf7gqBwcUDjWIzlY2QHycj7FTr7n7/MZ1lPcgQ GWHWPr4Hh+/LHBcUQgq4kX3OyfdCy4XlMk4Dav7ShSQx4dxBdSQOOBbo6qYJ5CYgjd cyz0ijr12pIhrGQV1BRsrYCFSa120OPUkzFpDzUMhTqB6EiBwaGadryPMbVTnr5vxK jQtZ1dCDLd3EettlrA8Rq45RplK1LXDqeGlRLMFjiwI2rwBH66YSwH9VElejNYNEdU wmnbdb6ql/fTvIxqH4IIyjpnH20Q/x3Xh0NOTtOUMoKhNcopBwi1M2gdK2qRi2azbH yKO815uhwnzcg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4FL4w011spzBrLb; Wed, 14 Apr 2021 16:43:12 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Francesca Palombini <francesca.palombini@ericsson.com>
CC: "core@ietf.org" <core@ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>
Thread-Topic: AD review of draft-ietf-core-new-block-09
Thread-Index: AQHXKMAB96eXAzct4U2xMq7Yy2g+ZqqnH+rQgA0LswD///dvIA==
Date: Wed, 14 Apr 2021 14:43:10 +0000
Message-ID: <8765_1618411392_6076FF80_8765_49_1_787AE7BB302AE849A7480A190F8B933035369C14@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <836C3253-EBED-4758-9B07-6AEF91784DAD@ericsson.com> <6260_1617721331_606C77F3_6260_205_9_787AE7BB302AE849A7480A190F8B933035364693@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <922BEA47-DD6A-41E5-96FF-2436ABDDBE65@ericsson.com>
In-Reply-To: <922BEA47-DD6A-41E5-96FF-2436ABDDBE65@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7R24m_owJT08cW_0bRZV5kdB_Ng>
Subject: Re: [core] AD review of draft-ietf-core-new-block-09
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 14:43:21 -0000

Hi Fransasca, 

Thank you for the follow-up. 

The full changes can be tracked at: https://tinyurl.com/new-block-latest. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Francesca Palombini [mailto:francesca.palombini@ericsson.com]
> Envoyé : mercredi 14 avril 2021 14:58
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : core@ietf.org; draft-ietf-core-new-block@ietf.org
> Objet : Re: AD review of draft-ietf-core-new-block-09
> 
> Hi Jon, Med!
> 
> Thank you for answering my questions and addressing my comments.
> 
> I will start IETF Last Call while we finish talking over the couple
> of issues left (which are minor, see inline). Feel free to post an
> update to the document, either right now or as soon as we are done
> with my review.
> 
> Thanks,
> Francesca
> 
[..]
> >>
> >> General:
> >>
> >> 1.
> >> [FP]: Throughout the text, it seems that "payload" is used as a
> >> synonym to "CoAP request/response" or "block". This is incorrect
> and
> >> should be fixed. (See for example "received payload")
> >>
> >
> >[Med] The definition we are using is called out in the text:
> >
>   >"The terms "payload" and "body" are defined in [RFC7959].  The
> term
>    >"payload" is thus used for the content of a single CoAP message
>    >(i.e., a single block being transferred)"
> >
> 
> FP: Yes, they are defined, but I still have a problem with how they
> are used, in particular as a synonym to "CoAP request". One example
> in the comment below.
> 

[Med] Changed to avoid this confusion. "payload of block" and similar are not anymore used. 

> >>
> >> Section 1:
> >>
> >> 3.
> >>    o  They can operate in environments where packet loss is highly
> >>       asymmetrical.
> >>
> >> [FP]: Please clarify: Block1 and Block2 can also be used in
> >> environments where packet loss is asymmetrical. What do these new
> >> options add in that case?
> >
> >[Med] Please refer to the introduction where this is introduced. See
> for example:
> >
>    >There is a requirement for these blocks of data to be transmitted
> at
>    >higher rates under network conditions where there may be
> asymmetrical
>    >transient packet loss (i.e., responses may get dropped).  An
> example
>    >is when a network is subject to a Distributed Denial of Service
>    >(DDoS) attack and there is a need for DDoS mitigation agents
> relying
>    >upon CoAP to communicate with each other (e.g.,
>    >[RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]
>    >recommends the use of Confirmable (CON) responses to handle
> potential
>    >packet loss.  However, such a recommendation does not work with a
>    >flooded pipe DDoS situation.
> >
> 
> FP: This is more of an editorial clarification: I was looking for a
> more explicit statement about Q-Block1 and Q-Block2 having higher
> transmission rates; how the bullet point is stated "they can operate"
> does not explain why they are a good fit for cases where packet loss
> is asymmetrical (and to be nit-picking, Block1 and Block2 strictly
> speaking can also be used, but probably with worse results, which is
> what should be highlighted here).

[Med] This is what is supposed to be covered by the second bullet:

"They enable faster transmissions of sets of blocks of data with less packet interchanges."

> >> 8.
> >>    The Content-Format Option applies to the body, not to the
> payload
> >>    (i.e., it must be the same for all payloads of the same body).
> >>
> >> [FP]: I think this is missing that the previous sentence is true
> >> "when present together with the Q-Block1 or Q-Block2 Option".
> >
> >[Med] Sure, this is only if it is present. FWIW, we are using the
> same wording as in RFC7959:
> >
>    >"The Content-Format Option applies to the body, not to the
>    >payload; in particular, the boundaries between the blocks may be
> in
>    >places that are not separating whole units in terms of the
> structure,
>    >encoding, or content-coding used by the Content-Format."
> >
> >We can add a "when present" if you think this is more accurate.
> >
> 
> FP: It can't hurt to be explicit, IMO.
> 

[Med] Fixed. Thanks.

> >>
> >> -----
> >>
> >> 9.
> >>    include the Q-Block2 Option in a GET or similar request, the Q-
> >> Block2
> >>    Option in a PUT or similar request, or the Q-Block1 Option in a
> >> PUT
> >>    or similar request so that the server knows that the client
> >> supports
> >>
> >> [FP]: I am confused by the meaning of "similar request": what is
> >> considered a similar request to a GET request?
> >
> >[Med] We meant similar requests that are used to retrieve the
> representation of a resource. We have FETCH in mind but we also
> wanted a text that is future proof if such similar requests are
> defined in the future.
> 
> FP: I see - then I would suggest adding "such as FETCH, for example",
> which gives the reader the intuition of what a "similar request" is
> without over specifying.
> 

[Med] Good suggestion. Done. 

> >
> >How is a PUT request
> >> different from a GET request? Additionally, how does the client
> >> decides if it needs to include a Q-Block1 or Q-Block2 Option in a
> PUT
> >> (or similar) request to indicate support for these two options?
> >>
> >
> >[Med] This can be driven by a local configuration knob, triggered by
> an application (DOTS, for example), etc. How this is done, is out of
> the scope of the spec.
> 
> FP: Makes sense. Could you add this sentence to the document for
> clarification?

[Med] Happily. 

> >>
> >> -----
> >>
> >> 12.
> >>    Each individual payload of the body is treated as a new request
> >>    (Section 5).
> >>
> >> [FP]: Again, I suspect the meaning of this sentence will be
> clarified
> >> in section 5, but I think it is incorrect to say that each payload
> is
> >> treated as a new request - each payload is treated as a payload.
> >
> >[Med] As indicated above, the wording assumes the following:
> >
> >" "payload" is thus used for the content of a single CoAP message"
>                              >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> 
> FP: right, payload is used for the content, i.e. the resource
> representation (and when the block options are used, a block of the
> resource representation), not the whole CoAP request, which includes
> the payload but also CoAP code, options etc. This is again a simple
> terminology issue.
> 

[Med] Thank you for clarifying. Tweaked the text accordingly. Hope this is better.

> >> -----
> >>
> >> 14.
> >>       M bit set) have been successfully received.  The token used
> >> SHOULD
> >>       be from the last received payload.
> >>
> >> [FP]: "SHOULD" must be motivated: why is this not a MUST? What are
> >> the conditions where it is acceptable that the token is different
> >> from the one in the request with the last received payload? (note:
> >> several occurrences)
> >>
> >
> >[Med] We do already have this text to explain the rationale for
> SHOULD:
> >
>    >"Note that the use of any received token with the same
>    >Request-Tag would work, but providing the one used in the last
>    >received payload will aid any troubleshooting.  The client will
> use
>    >the token to determine what was the previously sent request to
> obtain
>    >the Request-Tag value to be used."
> >
> >The same applies for the other occurrences you pointer to.
> >
> 
> FP: I think that in this case, since it is not strictly necessary for
> interoperability that the token used is the one from the last
> received request, BCP 14 SHOULD is maybe not the correct term. This
> could be instead rephrased with something on the sort of: "The token
> used MUST be one received from a request using the same Request-Tag.
> However, it is desirable to provide the one used in the last received
> request, since that will aid any troubleshooting."

[Med] Fair point. Updated accordingly. 

> 
> >> -----
> >>
> >> 15.
> >>       A response using this Response Code SHOULD NOT be generated
> for
> >>       every received Q-Block1 Option request.  It SHOULD only be
> >>       generated when all the payload requests are Non-confirmable
> and
> >> a
> >>       set of MAX_PAYLOADS (Section 6.2) payloads have been
> received
> >> by
> >>       the server.
> >>
> >>       It SHOULD NOT be generated for CON.
> >>
> >> [FP]: Same remark as previous comment - please motivate why this
> is
> >> SHOULD and is not MUST. When using SHOULD, guidance should be
> given
> >> to implementers about in which case it is ok to deviate from the
> >> recommendations.
> >
> >[Med] The text does not use "MUST NOT" for the first part of the
> text you quoted because there might be situations where MAX_PAYLOADS
> is set to 1. This is discussed in in 6.2:
> >
>    >are no other network issues over that period, then the value of
>    >MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1)
> >
> 
> FP: Ok, thanks for clarifying, can we move/add the reference to 6.2
> here?
> 

[Med] Done. Thanks. 

> >The second SHOULD is not a MUST because sending a "continue" signal
> is an optimization and that the peer endpoint will send the next set
> of blocks after a timer is reached. This is discussed in 6.2:
> >
>    >For the server receiving NON Q-Block1 requests, it SHOULD send
> back a
>    >2.31 (Continue) Response Code on receipt of all of the
> MAX_PAYLOADS
>    >payloads to prevent the client unnecessarily delaying.  Otherwise
> the
>    >server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
>    >based on the repeat request count for a payload), before sending
> the
>    >4.08 (Request Entity Incomplete) Response Code for the missing
>    >payload(s).
> >
> 
> FP: Thanks for clarifying. I would clarify that this reference is
> where motivation is given, but I'll leave that up to you.
> 

[Med] Sure. Fixed. 

> >> -----
> >>
> >> 18.
> >>    The requested missing block numbers MUST have an increasing
> block
> >>    number in each additional Q-Block2 Option with no duplicates.
> The
> >>
> >> [FP]: What is the reason for mandating that the blocks requested
> must
> >> be in order (increasing block number)?
> >>
> >
> >[Med] This is a way to force the client to check for duplicates and
> remove them. This also helps with troubleshooting.
> 
> FP: I see. Could this clarification be added here?
> 

[Med] Done.

> >>
> >> 26.
> >>    The missing blocks MUST be reported in ascending order without
> any
> >>    duplicates.  The client SHOULD silently drop 4.08 (Request
> Entity
> >>
> >> [FP]: Same question: why does order matter?
> >>
> >
> >[Med] Same answer as above: ease troubleshooting and have a way to
> force the server to detect/remove duplicates.
> >
> 
> FP: This could point to the previous section where this will be
> (hopefully) clarified.

[Med] ACK

> >>
> >> Section 9:
> >>
> >> 29.
> >>             +--------->| [[Payloads 3 - 9 not detailed]]
> >>
> >> [FP]: Minor: I think it would make more sense to change "3 - 9" to
> "2
> >> - 8" (and same for examples below)
> >>
> >
> >[Med] I prefer the current one where we count payloads from 1, not
> from 0. Of course, payload 1 corresponds to the one with block num=0.
> >
> 
> FP: Ok, as you prefer.

[Med] Added new text to explain that payload N corresponds to block N-1 :-)

> 
> >>
> >> -----
> >>
> >> 31.
> >>           |<---------+ [[Payloads 3 - 8 not detailed]]
> >>
> >> [FP]: This is inconsistent and should be either 3 - 9 or 2 - 8 as
> >> noted above.
> >>
> >
> >[Med] Why?
> >
> >Payload 9 is indicated in the example:
> >
>             >+--------->| [[Payloads 3 - 8 not detailed]]
>             >+--------->| NON PUT /path M:0x19 T:0xe9 RT=11
> QB1:8/1/1024
> >
> 
> FP: Sorry, hard to understand which one I was referring to without
> the context :) I meant this one:
> 
>           |     X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23
> QB2:1/1/1024
>           |<---------+ [[Payloads 3 - 8 not detailed]]
>           |     X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23
> QB2:9/1/1024
> 
> I think this should be 3 - 9 if you keep the current notation

[Med] I confirm. 


_________________________________________________________________________________________________________________________

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.