Subject: [core] Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 03 May 2021 05:16:50 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-core-new-block-11: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated especially on the intended status/lack of public implementations).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

!!! I was about to ballot a DISCUSS on this point... In the absence of a
section about existing implementations for such a new transport, I really
wonder whether standard track should be used rather then experimental. Did the
authors/WG run some simulations ?

Happy to have read Colin Perkins' review for the Transport ART, which has
provided me with some confidence in this brand new transport protocol. I am
also trusting the TSV Area Directors on this point.

-- Section 1 --
I had in mind that constrained network are well protected either at layer-2 or
by having an air-gap or firewall at their edges, so, a DoS seems quite
improbable in those deployments. Should this 'use case' really be part of the
introduction? Or is it simply linked to the DOTS use case ? In either case, the
DoS should be more detailed.

-- Section 3 --
Any reason why 'CON' is not expanded/explained on first use ?

---

From: <[email-masked]>
Date: Mon, 3 May 2021 12:36:03 +0000

Hi Eric, 

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 3 mai 2021 14:17
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Objet : Éric Vyncke's No Objection on draft-ietf-core-new-block-11:
> (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please find below some non-blocking COMMENT points (but replies would
> be appreciated especially on the intended status/lack of public
> implementations).
> 
> !!! I was about to ballot a DISCUSS on this point... In the absence
> of a section about existing implementations for such a new transport,
> I really wonder whether standard track should be used rather then
> experimental. Did the authors/WG run some simulations ?

[Med] There is an implementation and a PR was pushed so that this functionality is supported in the libcoap. Please refer to the following from the write-up:

======
A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611 

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.
====

> 
> Happy to have read Colin Perkins' review for the Transport ART, which
> has provided me with some confidence in this brand new transport
> protocol. I am also trusting the TSV Area Directors on this point.
> 
> -- Section 1 --
> I had in mind that constrained network are well protected either at
> layer-2 or by having an air-gap or firewall at their edges, so, a DoS
> seems quite improbable in those deployments.

[Med] One side note: there were reports of "weak" implementations and deployments. You may refer for example to https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-flaws-warns-trend-micro/ or https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-ddos-attacks/. Of course, there are guards out there but deployments may not support them. 

 Should this 'use case'
> really be part of the introduction? Or is it simply linked to the
> DOTS use case ? In either case, the DoS should be more detailed.

[Med] This is mainly driven by the DOTS use case. Not sure which more details you would like see added.   

> Any reason why 'CON' is not expanded/explained on first use ?

[Med] Actually, it is. Please refer to Section 1:

   As a reminder, [RFC7959]
   recommends the use of Confirmable (CON) responses to handle potential
   packet loss. 

_________________________________________________________________________________________________________________________

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 3 May 2021 15:47:08 +0000

Hello Med,

See in-line for EV

As you know, all my comments are non-blocking, so, I have appreciated your reply.

BTW, have you seen the recent IoT directorate review by Emmanuel Baccelli
https://datatracker.ietf.org/doc/review-ietf-core-new-block-11-iotdir-telechat-baccelli-2021-05-03/

Kind regards

-éric

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, 3 May 2021 at 14:36
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

    Hi Eric, 

    Please see inline.

    Cheers,
    Med

    ======

EV> indeed, thank you. Now, whether this code has been tested in several setups / test cases (bandwidth, packet loss, reboots) would be interesting.

EV> for sure __

     Should this 'use case'

EV> simply adding a reference to the DOTS RFC/user case to avoid confusing readers (like myself)

       As a reminder, [RFC7959]

EV> indeed, this was not my day...
    _________________________________________________________________________________________________________________________

---

From: <[email-masked]>
Date: Tue, 4 May 2021 06:54:32 +0000

Hi Eric, 

Please see inline.

Cheers,
Med

> De : Eric Vyncke (evyncke) [mailto:[email-masked]]
> Envoyé : lundi 3 mai 2021 17:47
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; The
> IESG <[email-masked]>
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Objet : Re: Éric Vyncke's No Objection on draft-ietf-core-new-block-
> 11: (with COMMENT)
> 
> Hello Med,
> 
> See in-line for EV
> 
> BTW, have you seen the recent IoT directorate review by Emmanuel
> Baccelli https://datatracker.ietf.org/doc/review-ietf-core-new-block-
> 11-iotdir-telechat-baccelli-2021-05-03/
> 

[Med] ACK. Thanks.

> Cc: "[email-masked]" <draft-ietf-core-new-
> [email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
[..]
>     [Med] There is an implementation and a PR was pushed so that this
> functionality is supported in the libcoap. Please refer to the
> following from the write-up:
> 
>     ======
>     A Pull-Request of an author's implementation to "libcoap" is
> available at https://github.com/obgm/libcoap/pull/611
> 
>     Feedback from the implementation activity has contributed to the
> design and refinement of specific aspects, notably:
> 
> EV> indeed, thank you. Now, whether this code has been tested in
> several setups / test cases (bandwidth, packet loss, reboots) would
> be interesting.
> 

[Med] It was tested in the context of DOTS telemetry. The list above shows how the testing was helpful to refine/assess the design.

[..]
> EV> simply adding a reference to the DOTS RFC/user case to avoid
> EV> confusing readers (like myself)

[Med] Will see what we can do as we do already cite it many times, and even one more as per the iotdir review. Thank you.

---

From: <[email-masked]>
Date: Tue, 4 May 2021 09:05:13 +0100

Hi Eric,

> [Med] It was tested in the context of DOTS telemetry. The list above shows
> how the testing was helpful to refine/assess the design.
> 

Libcoap provides the testing capability of one or more specific packets dropped, or randomly dropped. Testing was done with one or more packets missing from the start, around the MAX_PAYLOADS pause point, at the end as well as in the middle of a MAX_PAYLOAD sequence for both CON and NON.  Lessons learnt about the recoveries etc. updated the draft.

Logic tested with complete packet loss in one direction (for NON, CON fails here) confirming data still gets through.

Multiple concurrent sessions were run in parallel - including with enforced packet loss.

Applications running on the peers were restarted frequently (other peer remaining up) to checkout out recovery etc.

The block size (SZX) was deliberately set to a small size, thus considerably increasing the number of blocks needed to transfer large payloads to exercise that logic.  This brought about the addition of the 'Continue' logic.

Regards

Jon

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 4 May 2021 08:07:46 +0000

Jon and Med,

Thank you, I feel way more comfortable with that amount of testing ;-)

Regards

-éric

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, 4 May 2021 at 10:05
To: Eric Vyncke <[email-masked]>, 'The IESG' <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

    Hi Eric,

    Regards

    Jon