[core] Re: Fwd: New Version Notification for draft-gomez-core-coap-bp-01.txt

[Carles Gomez Montenegro <[e-mail]>]

Hi Marco,

First of all, apologies for the delay in this response.

Many thanks for your thoughtful comments!

Please find below my inline responses:

On Mon, 24 Jun 2024 at 23:22, Marco Tiloca <[e-mail]> wrote:

> Hi Carles,
>
> Thanks for this update! Please see below a few quick comments.
>
> Best,
> /Marco
>
>
> Section 4.1
>
> * "Upon receipt of a bundle that carries a CoAP CON message with the
> "request reporting of bundle delivery" flag set, the receiver MAY opt to
> only send the corresponding bundle delivery status report and omit sending
> a bundle encapsulating a CoAP ACK message, if and only if it is not
> possible to transmit a piggybacked response (e.g., because the response is
> not ready at the moment, or because the CON message does not elicit a
> response)."
>
>   Is the beginning of the sentence referring literally to any "CoAP CON
> message", or only to CoAP requests like the second part of the sentence
> seems to suggest? (The same goes for the last sentence in the same
> paragraph)
>
>
The beginning of the sentence is intended to refer literally to any "CoAP
CON message".

Perhaps the second part of the sentence could be modified as:

OLD:
the receiver MAY opt to only send the corresponding bundle delivery status
report and omit sending a bundle encapsulating a CoAP ACK message, if and
only if it is not possible to transmit a piggybacked response (e.g.,
because the response is not ready at the moment, or because the CON message
does not elicit a response).

NEW:
the receiver MAY opt to only send the corresponding bundle delivery status
report and omit sending a bundle encapsulating a CoAP ACK message, if and
only if the CoAP ACK message does not carry a payload.



>   On the second part of the sentence, what if the server has ready to send
> a CON separate response (see Section 5.2.2 of RFC 7252)? Before the CON
> separate response, can't the server consider to send the bundle delivery
> status instead of sending an empty ACK also in this case?
>
>
To the second question, the answer is yes. I hope that the NEW text above
can offer a clearer wording.


>
> Section 7
>
> * "When CoAP is used over BP, determining whether a notification was sent
> by the server later than another notification SHOULD be performed based on
> the creation timestamps of the corresponding bundles encapsulating the two
> notifications."
>
>   At the same time, Section 5 says:
>
>   > CoAP messages destined to the same endpoint MAY be aggregated and
> carried as the payload of a single encapsulating bundle.
>   >
>   > TO-DO: aggregation, to be discussed.
>
>   If multiple notifications are aggregated and placed in the same bundle,
> will they have to be internally ordered, i.e., based on the value of their
> Observe option or of their Partial IV if protected with (Group) OSCORE?
>
>   Is there a further internal mechanism provided by the BP bundle that one
> can additionally/alternatively rely on?
>
>
A bundle has exactly one payload block. Therefore, I understand that any
ordering will have to be performed at the upper layer.
Let's see how we perform the aggregation (Carsten gave some hints recently)
and whether it might naturally provide the ordering.


>
> Section 10
>
> * "OSCORE is a CoAP option that"
>
>   Well, OSCORE is a security protocol. A CoAP message protected with
> OSCORE also includes the OSCORE option.
>
>
Definitely!
(Will be updated in -02.)


> * "OSCORE is used to secure CoAP group communication
> [draft-ietf-core-groupcomm-bis]."
>
>   That is the Group OSCORE protocol, see draft-ietf-core-oscore-groupcomm.
>
>
Agreed.


> * "only the CoAP message payload and some of the CoAP message header
> fields are protected"
>
>   More precisely:
>
>   "only the CoAP message payload, one CoAP message header field, and some
> of the CoAP options are protected"
>
>

>   (The CoAP message header field in question being 'Code')
>
>
Many thanks!


> * "OSCORE uses by default an anti-replay window, with a window size of 32"
>
>   More precisely:
>
>   "OSCORE uses by default an anti-replay sliding window, with a window
> size of 32"
>
>
Agreed.


> Nit
>
> * Section 11.1
> --- s/[rfc6761]/[RFC6761]
>
>
> Agreed.

Once again, many thanks for all your comments!

Cheers,

Carles


>
> On 2024-06-24 09:45, Carles Gomez Montenegro wrote:
>
> Dear CoRE and DTN WGs,
>
> Please find below the main pointers to our updated version (-01) of the
> CoAP over BP Internet Draft.
>
> We have aimed to address all the feedback that has been provided by both
> WGs in IETF 119 (Brisbane) and also via the mailing lists.
> We are very grateful to everyone who provided feedback. (*)
>
> As usual, comments are very much welcome!
>
> Cheers,
>
> Carles and Anna
>
> (*) The following paragraph will be duly added in the Acknowledgments
> section of the next revision:
> The authors would like to thank (in alphabetical order) Christian Amsüss,
> Edward J. Birrane, Marc Blanchet, Carsten Bormann, Scott Burleigh, Joshua
> Deaton, Jaime Jiménez, Achim Kraus, Brian Sipos, Rick Taylor, Marco Tiloca,
> Rodney Van Meter, and Magnus Westerlund for useful design considerations,
> reviews and comments.
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, 24 Jun 2024 at 09:22
> Subject: New Version Notification for draft-gomez-core-coap-bp-01.txt
> To: Anna Calveras <[e-mail]>, Carles Gomez <
> [e-mail]>
>
>
> A new version of Internet-Draft draft-gomez-core-coap-bp-01.txt has been
> successfully submitted by Carles Gomez and posted to the
> IETF repository.
>
> Name:     draft-gomez-core-coap-bp
> Revision: 01
> Title:    Constrained Application Protocol (CoAP) over Bundle Protocol (BP)
> Date:     2024-06-24
> Group:    Individual Submission
> Pages:    23
> URL:      https://www.ietf.org/archive/id/draft-gomez-core-coap-bp-01.txt
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-gomez-core-coap-bp-01.txt&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519139622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PaeUCkI3Hsxhc2QX6NT4GKZUHNXNodAEekPm3RPdZFk%3D&reserved=0>
> Status:   https://datatracker.ietf.org/doc/draft-gomez-core-coap-bp/
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gomez-core-coap-bp%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519156423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6lzcX2MQ%2F9MgSax%2FixHZkHB6hlglEy%2F%2FSINIhAdfVhg%3D&reserved=0>
> HTMLized: https://datatracker.ietf.org/doc/html/draft-gomez-core-coap-bp
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-gomez-core-coap-bp&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519172245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EC78U9s%2Bah9ExCzCAFQEIvsiMYdxgdZh53rzysdj7Zo%3D&reserved=0>
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-gomez-core-coap-bp-01
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-gomez-core-coap-bp-01&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519187351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tCHfZp9hnLT9BP%2Bat1c794jqO6McX35sKcYQlV8SPrc%3D&reserved=0>
>
> Abstract:
>
>    The Bundle Protocol (BP) was designed to enable end-to-end
>    communication in challenged networks.  The Constrained Application
>    Protocol (CoAP), which was designed for constrained-node networks,
>    may be a suitable application-layer protocol for the scenarios where
>    BP is used.  This document specifies how CoAP is carried over BP.
>
>
>
> The IETF Secretariat
>
>
>
>
> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519201318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c3MJbAyTqV963AYaeu%2FKxNToAx5H6HyxP4UDl%2FOxoaQ%3D&reserved=0> Libre
> de virus.www.avg.com
> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avg.com%2Femail-signature%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail&data=05%7C02%7Cmarco.tiloca%40ri.se%7C02b24c1004b243f5461a08dc9421a9ec%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638548119519213493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=9lWxORhBKK5jhfK2kuMijxh%2BuAIRqqR77Bw3UlBHAjQ%3D&reserved=0>
>
> _______________________________________________
> core mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: [phone]
>
> RISE Research Institutes of Sweden AB
> Box 1263
> 164 29 Kista (Sweden)
>
> Division: Digital Systems
> Department: Computer Science
> Unit: Cybersecurity
> https://www.ri.se
>
>