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

[[e-mail]]

Hi Eric, 

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 3 mai 2021 14:17
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Éric Vyncke's No Objection on draft-ietf-core-new-block-11:
> (with COMMENT)
> 
> É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 ?

[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.   

> 
> -- Section 3 --
> 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.