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

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

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

 

Looking forward to seeing experiments with this layering!

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]> On Behalf Of Carles Gomez Montenegro
Sent: Friday, March 1, 2024 4:52 AM
To: [e-mail]; [e-mail]
Cc: Anna Calveras Auge <[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] 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