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

[[e-mail]]

Hi Eric, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Eric Vyncke (evyncke) [mailto:[e-mail]]
> Envoyé : lundi 3 mai 2021 17:47
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; The
> IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Éric Vyncke's No Objection on draft-ietf-core-new-block-
> 11: (with COMMENT)
> 
> 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/
> 

[Med] ACK. Thanks.

> Kind regards
> 
> -éric
> 
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Monday, 3 May 2021 at 14:36
> To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
> Cc: "[e-mail]" <draft-ietf-core-new-
> [e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: RE: Éric Vyncke's No Objection on draft-ietf-core-new-block-
> 11: (with COMMENT)
> 
>     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
>     >
[..]
>     > == 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.
>     ====
> 
> 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.

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

_________________________________________________________________________________________________________________________

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.