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

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

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]> 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]> *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]>
> 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]>, Carles Gomez <
> [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
>
>
>
> [image: Image removed by sender.]
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
> Libre de virus.www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
>