Subject: [dtn] Other comments / questions on bpbis-03 draft

From: Keith Scott <[email-masked]>
Date: Tue, 29 Mar 2016 15:14:06 -0400

Why are there separate definitions for 'Taking custody' and 'Accepting
custody'?  Is it possible to do the first without the second?

----

The term 'Refusing custody' is defined but is never used later in the
text.  I don't *think* this is the same thing as a custody failed signal
from 5.4.2.

I think generating such signals might be a bad idea, since a node might
choose to not take custody of (though still forward) a bundle (thus
declining an opportunity to take custody). In that case it would seem wrong
to notify current custodians of the fact?

----

The first paragraph on page 13 is repeated from the second full paragraph
on page 12.

----

Should 5.4(step 4) 'Bundle Forwarding' really refer to 5.10.2 'Custody
Release' or should it refer to 5.10.1 'Custody acceptance'?  If that's
right, might it be better for 5.4(4) to reference 5.10 (to include the
notion that the node can decide whether to take custody or not) or to move
that text into 5.10.1?

----

  --keith

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 29 Mar 2016 22:56:38 +0000

Sorry, hit Reply instead of Reply All:

From: Burleigh, Scott C (312B)
Sent: Tuesday, March 29, 2016 1:42 PM
To: 'Keith Scott' <[email-masked]>
Subject: RE: [dtn] Other comments / questions on bpbis-03 draft

Keith, some notes in-line below.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Keith Scott
Sent: Tuesday, March 29, 2016 12:14 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] Other comments / questions on bpbis-03 draft

Why are there separate definitions for 'Taking custody' and 'Accepting custody'?  Is it possible to do the first without the second?

Ø    Yes, during fragmentation a node may release custody of the original bundle (enabling it to be discarded from memory) and take custody of the resulting fragments.  This shouldn’t entail transmission of any custody signals, which does happen when custody is accepted.  The same sort of thing happens on reassembly as well: custody of all the fragments has already been accepted, so now you release custody of all the fragments and take custody of the reconstituted original bundle without sending any custody signals.

----

The term 'Refusing custody' is defined but is never used later in the text.  I don't *think* this is the same thing as a custody failed signal from 5.4.2.

Ø  No, it is the same thing.  The custody signal with Succeeded flag set to 0 (“Failed”) is the bundle that is sent in order to “notify all current custodians of that bundle that an opportunity to take custody of the bundle has been declined”.

I think generating such signals might be a bad idea, since a node might choose to not take custody of (though still forward) a bundle (thus declining an opportunity to take custody). In that case it would seem wrong to notify current custodians of the fact?

Ø  Right, there is “declining to take custody” and there is “notifying all current custodians of the bundle that an opportunity to take custody of it has been declined” (which is refusal).  You can do the former without doing the latter.  There are specific rules for the latter, but the former is just a local node decision.

----

The first paragraph on page 13 is repeated from the second full paragraph on page 12.

Ø  Good catch!  Missed this during the restructuring of section 3.  The paragraph needs to be removed from page 12.
----

Should 5.4(step 4) 'Bundle Forwarding' really refer to 5.10.2 'Custody Release' or should it refer to 5.10.1 'Custody acceptance'?  If that's right, might it be better for 5.4(4) to reference 5.10 (to include the notion that the node can decide whether to take custody or not) or to move that text into 5.10.1?

Ø  An even better catch.  Step 4 of 5.4 should reference 5.10, not 5.10.2.

----

  --keith

---

From: Keith Scott <[email-masked]>
Date: Wed, 30 Mar 2016 07:45:05 -0400

and of course I followed suit...   :)

---------- Forwarded message ----------
From: Keith Scott <[email-masked]>
Date: Wed, Mar 30, 2016 at 7:44 AM
Subject: Re: [dtn] FW: Other comments / questions on bpbis-03 draft
To: "Burleigh, Scott C (312B)" <[email-masked]>

Cool, thx.

I still think the definition of refusing custody is a bit odd, but if the
definition includes the act of informing the current custodians (as it
does, I just didn't read it that way the first time) then OK.

  --keith

On Tue, Mar 29, 2016 at 6:56 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> *From:* Burleigh, Scott C (312B)
> *Sent:* Tuesday, March 29, 2016 1:42 PM
> *To:* 'Keith Scott' <[email-masked]>
> *Subject:* RE: [dtn] Other comments / questions on bpbis-03 draft
>
>
>
> *From:* dtn [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Keith Scott
> *Sent:* Tuesday, March 29, 2016 12:14 PM
> *To:* [email-masked]
> *Subject:* [dtn] Other comments / questions on bpbis-03 draft
>
>
>
> Ø    Yes, during fragmentation a node may release custody of the original
> bundle (enabling it to be discarded from memory) and take custody of the
> resulting fragments.  This shouldn’t entail transmission of any custody
> signals, which does happen when custody is accepted.  The same sort of
> thing happens on reassembly as well: custody of all the fragments has
> already been accepted, so now you release custody of all the fragments and
> take custody of the reconstituted original bundle without sending any
> custody signals.
>
>
>
> ----
>
>
>
> Ø  No, it is the same thing.  The custody signal with Succeeded flag set
> to 0 (“Failed”) is the bundle that is sent in order to “notify all current
> custodians of that bundle that an opportunity to take custody of the bundle
> has been declined”.
>
>
>
> Ø  Right, there is “declining to take custody” and there is “notifying
> all current custodians of the bundle that an opportunity to take custody of
> it has been declined” (which is refusal).  You can do the former without
> doing the latter.  There are specific rules for the latter, but the former
> is just a local node decision.
>
>
>
> ----
>
>
>
> Ø  Good catch!  Missed this during the restructuring of section 3.  The
> paragraph needs to be removed from page 12.
>
> ----
>
>
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>