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

["Sipos, Brian J." <[e-mail]>]

Carles,

Great to see your feedback.

 

One other aspect to consider with the application-level responses is that of security parity between request and response bundles and/or ADUs. It’s likely that the security (and forwarding) policies related to status reports will be completely disconnected from application traffic being statused, in the sense that the status reports have a different destination/audience by design.

 

On that same topic it would be good to have some application requirements (outside of security considerations section) about the security relationships between CoAP-over-BP requests and responses. Or asked another way: must a bundle containing a CoAP response have at least the same layer/type/level of security as the request?

Part of the complexity of this question is that there can be security at BP layer and at CoAP layer (or both) and that can include (or not include) authentication, integrity, and confidentiality aspects.

 

The example in [1] is somewhat of a special case because it is designed to be sent in plaintext, with security as part of the application layer design. For CoAP/BP though, for example, if a request includes BPSec confidentiality of the payload I would hope/expect that the response must also include confidentiality.

 

From: Carles Gomez Montenegro <[e-mail]> 
Sent: Tuesday, March 19, 2024 3:50 PM
To: Sipos, Brian J. <[e-mail]>
Cc: [e-mail]; [e-mail]; Anna Calveras Auge <[e-mail]>
Subject: Re: [EXT] [dtn] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hi Brian,

 

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

 

Many thanks for your encouraging, detailed and helpful feedback!

 

Please find below our inline comments/responses:

 

On Fri, 1 Mar 2024 at 16:42, Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > wrote:

Authors,

This looks like a good starting point for this kind of layering and leveraging of existing application-side tools over a new transport.

I have a few feedback comments about clarifying behavior:

1.	It is important for applications to define appropriate Bundle Lifetime durations for each ADU being sent. This allows the network to delete bundles when appropriate (and also avoid deleting when inappropriate) and avoids application-level retries acting in conflict with BP-level retention logic. The bundle Lifetimes could be set to correspond with the EXCHANGE_LIFETIME to make that explicit and controlled, with response messages’ Lifetimes adjusted appropriately.

 

Agreed! 

 

We plan to address your comment in the next draft update. One detail is that we probably need to set the bundle lifetime to EXCHANGE_LIFETIME for bundles carrying CoAP CON messages, and NON_LIFETIME for bundles carrying CoAP NON messages.

 

1.	 
2.	The document doesn’t have any explicit logic about response data and bundle source/dest EIDs. BP itself doesn’t have any intrinsic logic of what a “response” means, so it’s up to an application to define the Source EID and Destination EID of a response relative to the bundle-being-responded-to (see [1] for an example). This doesn’t need to be complex logic, but does need to be defined by the BP application.

 

Thanks a lot. The example is indeed very helpful! Again, to be addressed in the next draft update.

 

1.	 
2.	Related to your aside at the end of Section 4.1 about the use of BP Status reports to elide application acknowledgement: this assumption is probably incorrect, as status reporting contains lots of other information not pertinent to the CoAP ACK logic. Also, because there is currently not a well-defined scope for BPA—application interfaces a BPA receiving a status report does not necessarily give any visibility to the BP application. Current BPA implementations tend to treat status reports as accounting events similar to ICMP messages, where the application is not involved or informed.

 

Admittedly, this "optimization attempt" aimed to (according to some numbers we have) save a few (although not many) bytes to be transmitted, hoping that it would compensate the additional complexity of this special handling. I am wondering if future implementations might offer a BPA - application interface, but if this proposal is not really worth it, even if it is offered as a "MAY", we can of course abandon it. 

 

1.	 
2.	In the URI definition of section 8.1 it is important to indicate that the embedded EID (which itself is a URI) must be percent-encoded when embedding. And the percent-encoded-EID really just conforms to the “reg-name” rule of [2] and doesn’t involve the “port” rule at all.

 

Yes, we plan to address your comment it in the next draft revision.

 

1.	 

 

Looking forward to seeing experiments with this layering!

 

Great, thanks!

 

Such experiments are indeed in our roadmap (in the mid-long term), and we are of course also interested in similar initiatives from other participants.

 

Cheers,

 

Carles (on behalf of the authors)

 

Brian S.

 

[1] https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html#section-3.4

[2] https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2

 

From: dtn <[e-mail] <mailto:[e-mail]> > On Behalf Of Carles Gomez Montenegro
Sent: Friday, March 1, 2024 4:52 AM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Cc: Anna Calveras Auge <[e-mail] <mailto:[e-mail]> >
Subject: [EXT] [dtn] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Dear CoRE and DTN WGs,

 

Please find below the main pointers to the initial version of a draft that aims to specify how CoAP can be carried over BP.

 

We look forward to receiving your feedback!

 

Best regards,

 

Carles and Anna

 

 

---------- Forwarded message ---------
From: <[e-mail] <mailto:[e-mail]> >
Date: Fri, 1 Mar 2024 at 10:39
Subject: New Version Notification for draft-gomez-core-coap-bp-00.txt
To: Anna Calveras <[e-mail] <mailto:[e-mail]> >, Carles Gomez <[e-mail] <mailto:[e-mail]> >



A new version of Internet-Draft draft-gomez-core-coap-bp-00.txt has been
successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:     draft-gomez-core-coap-bp
Revision: 00
Title:    Constrained Application Protocol (CoAP) over Bundle Protocol (BP)
Date:     2024-03-01
Group:    Individual Submission
Pages:    19
URL:      https://www.ietf.org/archive/id/draft-gomez-core-coap-bp-00.txt
Status:   https://datatracker.ietf.org/doc/draft-gomez-core-coap-bp/
HTMLized: https://datatracker.ietf.org/doc/html/draft-gomez-core-coap-bp


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

 


 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 

Libre de virus. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> www.avg.com