Subject: Re: [dtn] new BPbis spec reference mistakes

From: Lucas Kahlert <[email-masked]>
Date: Wed, 23 Aug 2017 18:57:20 +0200

Hello,

I think the reference mistakes are still there in version 
draft-ietf-dtn-bpbis-08.

Regards,
Lucas

On 14.07.2017 13:23, Lucas Kahlert wrote:
> Hi,
> 
> I think I have found some mistakes in the cross-references of the new 
> BPbis:
> 
>   - Section 5.14 Bundle Deletion does not exist, I think it should be 
> "Section 5.10"
>   - 5.4.1 Forwarding Contraindicated: "Proceed from Step 5", I think 
> Step 4 is meant
> 
> Regards,
> Lucas
> 
> On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
>> Hi.  I just posted an updated BPbis specification that I think 
>> addresses nearly all of the comments on which we reached consensus, 
>> either over email or at IETF 98.  The one exception I can think of is 
>> the request to add references to formal definitions for CRC-16-ANSI 
>> and CRC-32, which I omitted because on a quick search I wasn’t able to 
>> find any; if anyone knows where those definitions live, please speak up.
>>
>> I think we may have two quite different approaches on the table for 
>> defining custody transfer outside of the BP specification.  I will be 
>> posting one of them in a few minutes and hope to post the other 
>> sometime tomorrow.
>>
>> Scott
>>
>>
>>
>> _______________________________________________
>> dtn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 18:03:35 +0000

Thanks Lucas - your follow-up is appreciated.

Question to chairs and ADs - can these points be addressed during AUTH48?

Fred

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
> Sent: Wednesday, August 23, 2017 9:57 AM
> To: [email-masked]
> Subject: Re: [dtn] new BPbis spec reference mistakes
> 
> Hello,
> 
> >> and CRC-32, which I omitted because on a quick search I wasn't able to

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Aug 2017 23:13:17 -0500

Hi, Fred,

> Question to chairs and ADs - can these points be addressed during AUTH48?

(not speaking for the chairs or the shepherd, but you asked me, too)

Sure, but this draft hasn't been PUBREQed yet - it's still in the working
group. If someone wanted to fix them after WGLC, that would be great.

Spencer, as responsible AD

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Aug 2017 18:14:41 +0000

Thanks Spencer!

Fred

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, August 24, 2017 9:13 PM
To: Templin, Fred L <[email-masked]>
Cc: Lucas Kahlert <[email-masked]>; [email-masked]
Subject: Re: [dtn] new BPbis spec reference mistakes

Hi, Fred,

On Thu, Aug 24, 2017 at 1:03 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Lucas - your follow-up is appreciated.

Sure, but this draft hasn't been PUBREQed yet - it's still in the working group. If someone wanted to fix them after WGLC, that would be great.

Fred

> From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lucas Kahlert
> To: [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Lucas Kahlert <[email-masked]>
Date: Mon, 28 Aug 2017 13:38:32 +0200

Hello,

I come across the following problem as part of a formalization of the 
Bundle Protocol:

As I understand: "5.2 Bundle Transmission" is the entry point / 
interface of the "Bundle Protocol Agent" to the upper layers.

5.2 Bundle Transmission states in step 2 to proceed with "5.4 Bundle 
Forwarding" (already RFC 5050 states to proceed with "Bundle 
Forwarding") but I think the procedure should proceed with "5.3 Bundle 
Dispatching".

The motivation is the following use case:
An "Application Agent" should be able to send bundles to itself 
(loopback capability). This should be implementation-independent.
It is required for loopback bundles that a they get dispatched because 
local delivery is only possible during the "5.3 Bundle Dispatching" 
procedure. If "Bundle Transmission" proceeds directly with "Bundle 
Forwarding" there is no possibility for local delivery.

Regards,
Lucas

On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
> Hi.  I just posted an updated BPbis specification that I think addresses 
> nearly all of the comments on which we reached consensus, either over 
> email or at IETF 98.  The one exception I can think of is the request to 
> add references to formal definitions for CRC-16-ANSI and CRC-32, which I 
> omitted because on a quick search I wasn’t able to find any; if anyone 
> knows where those definitions live, please speak up.
> 
> posting one of them in a few minutes and hope to post the other sometime 
> tomorrow.
> 
> Scott
> 
> 
>

---

From: Lucas Kahlert <[email-masked]>
Date: Mon, 28 Aug 2017 13:48:27 +0200

Hello again,

should the "Bundle Deletion" procedure be performed if a bundle gets 
abandoned ("5.7. Local Bundle Delivery" in step 2). Maybe the 
specification should contain a hint on this.

What would be the correct reason code for an according "Bundle Deletion 
Status Report"?

Regards,
Lucas

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 28 Aug 2017 20:29:30 +0000

Lucas, you are right, the "section 5.14" error was fixed in one place but I missed it in four other places.  I'll fix it now.

Are you sure the "Step 5" problem is still an error in the version-8 spec?  I only saw that in one place (in the last sentence of 5.4.1) and it is corrected there now, right?

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
Sent: Wednesday, August 23, 2017 9:57 AM
To: [email-masked]
Subject: Re: [dtn] new BPbis spec reference mistakes

Hello,

I think the reference mistakes are still there in version draft-ietf-dtn-bpbis-08.

Regards,
Lucas

On 14.07.2017 13:23, Lucas Kahlert wrote:
>> and CRC-32, which I omitted because on a quick search I wasn't able 
>> to find any; if anyone knows where those definitions live, please speak up.
>>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 28 Aug 2017 20:43:15 +0000

Hi, Lucas.  I think the current text is actually correct here: it is precisely by proceeding directly to 5.4 instead of 5.3 that we support true loopback capability.  The outbound bundle is passed to the forwarding function, which selects a next-hop destination (the local node) and passes the bundle to the convergence-layer adapter for convergence-layer transmission to the next-hop destination; the bundle is then received at the convergence layer at the next-hop destination (the local node) and passed up to the local node's bundle protocol agent; the local node's BPA thereupon invokes 5.3, dispatching and thus delivering the bundle.  If we move directly from 5.2. to 5.3 we bypass all of the BP processing, simulating loopback without actually performing it.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
Sent: Monday, August 28, 2017 4:39 AM
To: [email-masked]
Subject: Re: [dtn] Bundle Transmission -> Bundle Dispatching

Hello,

I come across the following problem as part of a formalization of the Bundle Protocol:

As I understand: "5.2 Bundle Transmission" is the entry point / interface of the "Bundle Protocol Agent" to the upper layers.

5.2 Bundle Transmission states in step 2 to proceed with "5.4 Bundle Forwarding" (already RFC 5050 states to proceed with "Bundle
Forwarding") but I think the procedure should proceed with "5.3 Bundle Dispatching".

The motivation is the following use case:
An "Application Agent" should be able to send bundles to itself (loopback capability). This should be implementation-independent.
It is required for loopback bundles that a they get dispatched because local delivery is only possible during the "5.3 Bundle Dispatching" 
procedure. If "Bundle Transmission" proceeds directly with "Bundle Forwarding" there is no possibility for local delivery.

Regards,
Lucas

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 28 Aug 2017 21:23:21 +0000

Hi, Lucas.  Here again I think we are okay.  The only way into the local bundle delivery procedure that I can find is from 5.3, bundle dispatching.  If the bundle is abandoned during the bundle delivery procedure, all that happens is that the bundle is not delivered, causing step 3 of 5.7 to have no effect.  At that point, the bundle dispatching procedure (5.3) simply proceeds with its next step, which is to move on to 5.4 where the Dispatch Pending retention constraint is removed and the Forward Pending retention constraint is added.

If the bundle is destined for a multi-node endpoint, then you would NOT want abandonment of the bundle to result in its deletion because that would prevent the bundle from being forwarded to other members of the endpoint.  So the lack of deletion in 5.7 is a good thing.

If not, then removal of the Forward Pending retention constraint in step 5 of 5.4 will cause the bundle to be silently discarded (5.11; not deleted) in the normal way.  In that case the lack of deletion in 5.7 is irrelevant.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
Sent: Monday, August 28, 2017 4:48 AM
To: [email-masked]
Subject: Re: [dtn] Bundle Abadonment

Hello again,

should the "Bundle Deletion" procedure be performed if a bundle gets abandoned ("5.7. Local Bundle Delivery" in step 2). Maybe the specification should contain a hint on this.

What would be the correct reason code for an according "Bundle Deletion Status Report"?

Regards,
Lucas