Subject: Re: [dtn] Representation of Bundle Protocol

From: Elwyn Davies <[email-masked]>
Date: Thu, 21 Jul 2016 11:55:38 +0200

Hi.
This document http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdfhas a detailed description of the DTN2 API and the rest of the non-security aspects of the stack.
The API is definitely not a 'socket interface' in the sense of the BSD TCP/IP socket interface.
There was a proposal to make a socket style interface as part of the N4C project.  My personal opinion was that this was not a good fit having looked into it (I'll have to recover my internal arguments from tertiary storage if you want details, but it is mostly to do with the more asynchronous nature of the DTN API, particularly that the stack will hold bundles related to a EID pattern even when there is no active application - the passive registration concept - you would have to decide whether this was a required concept).  My preferred approach for a more standardized interface would have been to provide a DBus style interface in the Linux domain.  I got  part way to implementing this but ran out of time - and there was not sufficient interest in an alternative interface:  The existing interface worked sufficiently well for the needs of the experiments in hand.
You will find a lot more info about DTN2 in the document.
Regards,Elwyn
Sent from Samsung tablet.-------- Original message --------From: "Birrane, Edward J." <[email-masked]> Date: 20/07/2016  12:23  (GMT+01:00) To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked] Cc: [email-masked], [email-masked] Subject: Re: [dtn] Representation of Bundle Protocol 

Agreed. 

Doesn't the DTN 2 implement this architecture concept by providing a socket interface to its BPA? That could give us a good starting point for an APISR (API Sorry Rick).

Sent with Good Work (www.good.com)

From: [email-masked] <[email-masked]>
Date: Wednesday, Jul 20, 2016, 6:20 AM
To: Birrane, Edward J. <[email-masked]>, [email-masked] <[email-masked]>, [email-masked]
 <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>,
 [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: [dtn] Representation of Bundle Protocol

+1.
 
Ed, you’re right. Not only does the role (or functional overview) of the BPA need to be clarified, but the exact subset of functionality which encompasses
 a bundle producer/consumer must also be determined. In a sense, a producer/consumer is an API (sorry Rick). It may just be me, but I can’t see any large difference in the interactions (at least for sending/receiving) of an application running on a local BPA
 or that which is connected via this transformer/converter, which is in turn connected to the BPA. As a result, it could/should be possible to specify the interactions for both in one pass. As a simple example, some expansion of the following:
·        
A BPA SHOULD provide routing functionality across a DTN of BPAs.
·        
The BPA MUST provide send/receive functionality to local applications, including transformation layers for bundle producers and consumers.
·        
The BPA must perform security operations prior to transmission to a transformation layer.
·        
A transformation layer MUST provide connection status information to its proximate BPA.
·        
A transformation layer MUST NOT change the content of the bundles coming through it; only the encapsulation and format may be changed.
·        
A transformation layer MUST NOT provide routing functionality other than whatever is required to talk to its local network of bundle consumers.
Etc, etc, etc.
 
Thanks,
jeremy

From: Birrane, Edward J. [mailto:[email-masked]]

Sent: Wednesday, July 20, 2016 11:57 AM

To: Burleigh, Scott C (312B); Rick Taylor; [email-masked]; Mayer, Jeremy; [email-masked]; [email-masked]

Cc: [email-masked]; [email-masked]

Subject: RE: [dtn] Representation of Bundle Protocol

I concur. 

The only caveat would be to make clear the definition of a BPA as a function of roles and responsibilities not just "the thing that talks CBOR". 

Put another way, it would be confusing if a series of "bundle producers/consumers" wanted to network amongst themselves without an intermediary BPA, to include security and routing/forwarding etc... 

-Ed

Sent with Good Work (www.good.com)

From: Burleigh, Scott C (312B) <[email-masked]>

Date: Tuesday, Jul 19, 2016, 10:02 PM

To: Rick Taylor <[email-masked]>,
[email-masked] <[email-masked]>,
[email-masked] <[email-masked]>,
[email-masked] <[email-masked]>, Birrane, Edward J. <[email-masked]>,
[email-masked] <[email-masked]>

Cc: [email-masked] <[email-masked]>,
[email-masked] <[email-masked]>

Subject: RE: [dtn] Representation of Bundle Protocol

If I understand properly, I think this is a fine direction to go in.  That is:

1.  Define a single encoding (I think CBOR is the best candidate) in the bpbis specification.

2.  Define alternate bundle encodings in supplementary documents that define additional, very simple protocols.  This would be in the expectation that a simple bundle "producer" or "consumer" (or "producer/consumer") would not be a BP node, formally speaking. 
 It would instead exchange data items conforming to such a protocol with some entity that encompasses both a full-fledged BP node and also some sort of transformer that converts such items to and from bundles before reception by -- and after transmission from
 -- convergence-layer adapters.  (In implementation, maybe this transformer function is a library that is built into the CLA, but I don't think we need to nail that down anywhere.)

If this is where we are headed, I'm happy to revise the bpbis I-D along these lines over the next few weeks.

Scott

________________________________________

From: dtn [[email-masked]] on behalf of Rick Taylor [[email-masked]]

Sent: Tuesday, July 19, 2016 5:20 AM

To: [email-masked]; 
[email-masked]; [email-masked];
[email-masked]; 
[email-masked]

Cc: [email-masked]; 
[email-masked]

Subject: Re: [dtn] Representation of Bundle Protocol

All,

I may be wrong, but I believe the original proponents of differing

bundle encodings were looking at the use-case at the edge of the DTN:

the bundle producers and consumers, rather than the intermediate

forwarding nodes.

Is the solution here to explore multiple encodings for a bundle

submission protocol (the minimal subset of BPbis to insert a bundle

into the network) allowing hand-held devices using HTTP/JOSN, but to

require that the core routing nodes of the network implement the CBOR

encoding of BPbis?  This is the 'edge routers do transcoding to CBOR'

suggestion by someone earlier.

I get the feeling that rough consensus is that multiple encodings are a

bad idea in the DTN network 'core', and I agree, but I am unsure

whether people feel having alternate encodings at the edge is a good

idea.

Opinions please...

Rick

On Tue, 2016-07-19 at 11:47 +0000, [email-masked] wrote:

> All,

> First off,  I am still a fan of this bundle producer/consumer idea,

> where not everyone requires a full BP stack in order to play nicely

> with fully-featured BPAs.

> If this doesn’t fly with the WG, why not go a slightly different way:

> CBOR is THE on-the-wire AND canonical format for BpBis, and if anyone

> wants to do something different (and it doesn’t matter if that is

> JSON or haikus), they must base their encoding off of the wire

> format. The BpBis “considerations and requirements for alternate

> encodings” section would suddenly become extremely short: “Alternate

> encodings are considered to be a functional tunnel for CBOR data. As

> a result, it is the responsibility of the implementer to guarantee

> that the alternate encoding consumes and produces valid CBOR with no

> data loss between”.

> Thanks,

> Jeremy

> From: dtn [mailto:[email-masked]] On Behalf Of Birrane, Edward

> J.

> Sent: Tuesday, July 19, 2016 1:33 PM

> To: Sheehe, Charles J. (GRC-LCA0); Marc Blanchet; Spencer Dawkins at

> IETF

> Cc: [email-masked]; Sebastian Schildt

> Subject: Re: [dtn] Representation of Bundle Protocol

> Chuck,

>   Actually the WG voted to remove CMS from BPSEC at the last meeting.

> Which isn't to say we can't have a CMS block, just that it isn't a

> mandatory part of BPSec and would be captured in a separate document.

>   In fact, the approach we are taking for BPSEC might work for BPBis.

> In BPSEC we specify BIB and BCB and a canonical form for blocks. If

> someone wants to author a new security block type spec (CMS) we are

> adding a section to BPSec for what considerations must be taken by

> such an author at that time (processing rules, keys, etc...) And to

> be BPSEC compliant you must still support BIB and BCB.

>   Could we say that BPBis uses CBOR encoding and it is the default

> encoding and assumed available on every BPA. BPBis could add a

> section of "considerations and requirements for alternate encodings"

> talking about canonical forms and translations etc...

>   If someone wants to write a non-CBOR encoding, they must produce

> both their own encoding document and address the considerations and

> requirements of an alternate encoding.

>  -Ed

> Sent with Good Work (www.good.com)

> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]>

> Date: Tuesday, Jul 19, 2016, 7:19 AM

> To: Marc Blanchet <[email-masked]>, Spencer Dawkins at

> IETF <[email-masked]>

> Cc: [email-masked] <[email-masked]>, Sebastian Schildt <[email-masked]

> -bs.de>

> Subject: Re: [dtn] Representation of Bundle Protocol

> Hi

> Is there truly no way to reconcile these? The IOT has many resource

> constrained devices.

> A base format that will allow rappers/extensions at points.

> In the BPsec we allowed CMS as an option which blots the code.

> So how many bits are we really talking about adding to the

> fundamental format?

> Thanks

> Chuck

> Charles J. Sheehe III

> Electronics Engineer

> Glenn Research Center

> 21000 Brookpark Rd

> Cleveland, OH 44135

> [email-masked]

> Office: 216-433-5179

> "Science is the belief in the ignorance of the experts" – Richard

> Feynman

> What you do makes a difference and you have to decide what kind of

> difference you want to make.

> -----Original Message-----

> From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet

> Sent: Tuesday, July 19, 2016 5:54 AM

> To: Spencer Dawkins at IETF <[email-masked]>

> Cc: [email-masked]; Sebastian Schildt <[email-masked]>

> Subject: Re: [dtn] Representation of Bundle Protocol

> On 19 Jul 2016, at 11:44, Spencer Dawkins at IETF wrote:

>         I'm trying to ask the responsible AD question ...

>         On Tue, Jul 19, 2016 at 11:14 AM, Sebastian Schildt <schildt@

> ibr.cs.tu-bs.de <mailto:[email-masked]> 

>                 wrote:

>                 Hello,

>                 As have understood the discussion, everybody would be

> fine, to have a

>                 single representation of the BP, however agreement

> coud not be achieved,

>                 what kind of encoding that should be. Roughly

> (overly) generalizing, there

>                 had been two camps: One side wants the most effcient

> coding possible as to

>                 not add any unacceptable overhead when working on

> contrained devices or

>                 space use cases. You do not want to sent any super-

> verboe JSON or XML here

>                 (not even compressed). The other camp argued, that

> would be cumbersome and

>                 preclude adaptation of the protocol in modern -

> possibly web-based-

>                 techology stacks. Stuffing a custom binary format

> over websockets to a

>                 browser is certainly possible - but not fun.

>                 As these requirements are impossible to reconcile (at

> least that has been

>                 consensus, and I agree), but both use cases are

> valid, it was decided to do

>                 the split. I would not strongly oppose adding one

> canonical format into the

>                 BP spec while still allowing other encodings, but

> there is a slight danger

>                 that it makes oher encodings secondary citizens/an

> ugly hack. If the every

>                 encoding needs to use the same "interface", and there

> is nor "primary"

>                 encoding, we need to be sure that interface is well

> designed, which will

>                 help all encodings.

>                 Also, if we move forward CBOR encoding and BPBis at

> the the same time,

>                 isn't the outcome the same as rolling CBOR into

> BPBis?

>         So, am I understanding that with multiple encodings, there

> would not be one

>         encoding that is mandatory to implement for all endpoints? Or

> did I miss

>         the conversation about that?

> I think we haven’t reached that discussion point yet. It was clearly

> one of my next question (as co-chair): if we have more than one,

> which one is mandatory?.

> Marc.

>         Spencer

> ________________________________

>         dtn mailing list

>         [email-masked] <mailto:[email-masked]> 

>         https://www.ietf.org/mailman/listinfo/dtn

> _______________________________________________

> dtn mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/dtn

> _______________________________________________

> 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: Gilbert Clark <[email-masked]>
Date: Thu, 21 Jul 2016 10:22:50 -0400

Re-sending with fewer recipients ...

On Jul 21, 2016 10:17 AM, "Gilbert Clark" <[email-masked]> wrote:

> Hi:
>
> At one point, I did actually build a BSD socket interface that worked with
> both DTN2 and ION.  Upon reflection, I think I agree with Elwyn's note that
> it's not really the best fit for DTN.
>
> It's absolutely possible to make it *work*, and the familiar interface is
> absolutely great, but ... I remember running into issues  (e.g.
> asynchronous operation did indeed present a challenge) that made the
> familiar interface behave in ways that didn't align well with other socket
> types such as TCP or UDP in many cases.
>
> -Gilbert
>
> On Jul 21, 2016 5:56 AM, "Elwyn Davies" <[email-masked]> wrote:
>
> Hi.
>
> This document
> http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf
> has a detailed description of the DTN2 API and the rest of the
> non-security aspects of the stack.
>
> There was a proposal to make a socket style interface as part of the N4C
> project.  My personal opinion was that this was not a good fit having
> looked into it (I'll have to recover my internal arguments from tertiary
> storage if you want details, but it is mostly to do with the more
> asynchronous nature of the DTN API, particularly that the stack will hold
> bundles related to a EID pattern even when there is no active application -
> the passive registration concept - you would have to decide whether this
> was a required concept).  My preferred approach for a more standardized
> interface would have been to provide a DBus style interface in the Linux
> domain.  I got  part way to implementing this but ran out of time - and
> there was not sufficient interest in an alternative interface:  The
> existing interface worked sufficiently well for the needs of the
> experiments in hand.
>
> Regards,
> Elwyn
> Sent from Samsung tablet.
> -------- Original message --------
> From: "Birrane, Edward J." <[email-masked]>
> Date: 20/07/2016 12:23 (GMT+01:00)
> To: [email-masked], [email-masked],
> [email-masked], [email-masked],
> [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> Doesn't the DTN 2 implement this architecture concept by providing a
> socket interface to its BPA? That could give us a good starting point for
> an APISR (API Sorry Rick).
>
>
>
>
> *From: [email-masked] <[email-masked]>
> *Date: *Wednesday, Jul 20, 2016, 6:20 AM
> *To: *Birrane, Edward J. <[email-masked]>,
> [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>,
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *RE: [dtn] Representation of Bundle Protocol
>
> +1.
>
>
>
> Ed, you’re right. Not only does the role (or functional overview) of the
> BPA need to be clarified, but the exact subset of functionality which
> encompasses a bundle producer/consumer must also be determined. In a sense,
> a producer/consumer is an API (sorry Rick). It may just be me, but I can’t
> see any large difference in the interactions (at least for
> sending/receiving) of an application running on a local BPA or that which
> is connected via this transformer/converter, which is in turn connected to
> the BPA. As a result, it could/should be possible to specify the
> interactions for both in one pass. As a simple example, some expansion of
> the following:
>
> ·         A BPA SHOULD provide routing functionality across a DTN of BPAs.
>
> ·         The BPA MUST provide send/receive functionality to local
> applications, including transformation layers for bundle producers and
> consumers.
>
> ·         The BPA must perform security operations prior to transmission
> to a transformation layer.
>
> ·         A transformation layer MUST provide connection status
> information to its proximate BPA.
>
> ·         A transformation layer MUST NOT change the content of the
> bundles coming through it; only the encapsulation and format may be changed.
>
> ·         A transformation layer MUST NOT provide routing functionality
> other than whatever is required to talk to its local network of bundle
> consumers.
>
> Etc, etc, etc.
>
>
>
> Thanks,
>
> jeremy
>
>
>
> *From:* Birrane, Edward J. [mailto:[email-masked]]
> *Sent:* Wednesday, July 20, 2016 11:57 AM
> *To:* Burleigh, Scott C (312B); Rick Taylor; [email-masked];
> Mayer, Jeremy; [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: [dtn] Representation of Bundle Protocol
>
>
>
> I concur.
>
>
>
> The only caveat would be to make clear the definition of a BPA as a
> function of roles and responsibilities not just "the thing that talks
> CBOR".
>
>
>
> Put another way, it would be confusing if a series of "bundle
> producers/consumers" wanted to network amongst themselves without an
> intermediary BPA, to include security and routing/forwarding etc...
>
>
>
> -Ed
>
>
> *From: *Burleigh, Scott C (312B) <[email-masked]>
>
> *Date: *Tuesday, Jul 19, 2016, 10:02 PM
>
> *To: *Rick Taylor <[email-masked]>,
> [email-masked] <[email-masked]>, [email-masked]
> <[email-masked]>, [email-masked] <
> [email-masked]>, Birrane, Edward J. <[email-masked]>,
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>
>
> *Subject: *RE: [dtn] Representation of Bundle Protocol
>
>
>
> 2.  Define alternate bundle encodings in supplementary documents that
> define additional, very simple protocols.  This would be in the expectation
> that a simple bundle "producer" or "consumer" (or "producer/consumer")
> would not be a BP node, formally speaking.  It would instead exchange data
> items conforming to such a protocol with some entity that encompasses both
> a full-fledged BP node and also some sort of transformer that converts such
> items to and from bundles before reception by -- and after transmission
> from -- convergence-layer adapters.  (In implementation, maybe this
> transformer function is a library that is built into the CLA, but I don't
> think we need to nail that down anywhere.)
>
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> > From: dtn [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Birrane, Edward
> > J.
> <[email-masked]%0b>> -bs.de>
> > From: dtn [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Marc Blanchet
> > ibr.cs.tu-bs.de <mailto:[email-masked]
> <[email-masked]>>
> >
> >                 wrote:
> >
> >                 Hello,
> >
> >         [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: <[email-masked]>
Date: Thu, 21 Jul 2016 16:59:35 +0000

Hey,
I don’t think we should wrap ourselves up in the details of between the bundle producer/consumer interface to an application. That isn’t to say that I believe BSD-sockets are the best fit for many applications, but they certainly may be used. To the consumer, it’s safe to assume that some stream of notbundles will be received. I don’t think that it’s really our place to specify how those get presented up the stack, since (thanks to the webdev folks), that’s a very dynamic environment. We could use select() calls, HTTP slow polling, websockets, zeroMq-over-TCP, etc, since all of those allow for asynchronous presentation.

I would focus on the details required by the BPA in order to successfully forward notbundles from the producers/consumers. That alone would be a good basis for the APISRTWWCIN (API, Sorry Rick That’s What We’re Calling It Now).

Thanks,
Jeremy

From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Thursday, July 21, 2016 4:23 PM
To: Elwyn Davies
Cc: [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

On Jul 21, 2016 10:17 AM, "Gilbert Clark" <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

At one point, I did actually build a BSD socket interface that worked with both DTN2 and ION.  Upon reflection, I think I agree with Elwyn's note that it's not really the best fit for DTN.

It's absolutely possible to make it *work*, and the familiar interface is absolutely great, but ... I remember running into issues  (e.g. asynchronous operation did indeed present a challenge) that made the familiar interface behave in ways that didn't align well with other socket types such as TCP or UDP in many cases.

-Gilbert

On Jul 21, 2016 5:56 AM, "Elwyn Davies" <[email-masked]<mailto:[email-masked]>> wrote:
Hi.

This document
http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf
has a detailed description of the DTN2 API and the rest of the non-security aspects of the stack.

Regards,
Elwyn

-------- Original message --------
From: "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>>
Date: 20/07/2016 12:23 (GMT+01:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Representation of Bundle Protocol

Agreed.

Sent with Good Work (www.good.com<http://www.good.com>)
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, Jul 20, 2016, 6:20 AM
To: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dtn] Representation of Bundle Protocol

+1.

Ed, you’re right. Not only does the role (or functional overview) of the BPA need to be clarified, but the exact subset of functionality which encompasses a bundle producer/consumer must also be determined. In a sense, a producer/consumer is an API (sorry Rick). It may just be me, but I can’t see any large difference in the interactions (at least for sending/receiving) of an application running on a local BPA or that which is connected via this transformer/converter, which is in turn connected to the BPA. As a result, it could/should be possible to specify the interactions for both in one pass. As a simple example, some expansion of the following:

•         A BPA SHOULD provide routing functionality across a DTN of BPAs.

•         The BPA MUST provide send/receive functionality to local applications, including transformation layers for bundle producers and consumers.

•         The BPA must perform security operations prior to transmission to a transformation layer.

•         A transformation layer MUST provide connection status information to its proximate BPA.

•         A transformation layer MUST NOT change the content of the bundles coming through it; only the encapsulation and format may be changed.

•         A transformation layer MUST NOT provide routing functionality other than whatever is required to talk to its local network of bundle consumers.
Etc, etc, etc.

Thanks,
jeremy

From: Birrane, Edward J. [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 20, 2016 11:57 AM
To: Burleigh, Scott C (312B); Rick Taylor; [email-masked]<mailto:[email-masked]>; Mayer, Jeremy; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] Representation of Bundle Protocol

I concur.

-Ed

Sent with Good Work (www.good.com<http://www.good.com>)
From: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, Jul 19, 2016, 10:02 PM
To: Rick Taylor <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dtn] Representation of Bundle Protocol

2.  Define alternate bundle encodings in supplementary documents that define additional, very simple protocols.  This would be in the expectation that a simple bundle "producer" or "consumer" (or "producer/consumer") would not be a BP node, formally speaking.  It would instead exchange data items conforming to such a protocol with some entity that encompasses both a full-fledged BP node and also some sort of transformer that converts such items to and from bundles before reception by -- and after transmission from -- convergence-layer adapters.  (In implementation, maybe this transformer function is a library that is built into the CLA, but I don't think we need to nail that down anywhere.)

Scott
________________________________________
From: dtn [[email-masked]<mailto:[email-masked]>] on behalf of Rick Taylor [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 19, 2016 5:20 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Representation of Bundle Protocol

All,

Opinions please...

Rick

On Tue, 2016-07-19 at 11:47 +0000, [email-masked]<mailto:[email-masked]> wrote:
> Cc: [email-masked]<mailto:[email-masked]>; Sebastian Schildt
> Sent with Good Work (www.good.com<http://www.good.com>)
>
> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<mailto:[email-masked]>>
> To: Marc Blanchet <[email-masked]<mailto:[email-masked]>>, Spencer Dawkins at
> IETF <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Sebastian Schildt <[email-masked]
<mailto:[email-masked]%0b>> -bs.de<http://bs.de>>
> [email-masked]<mailto:[email-masked]>
> Office: 216-433-5179<tel:216-433-5179>
>
> To: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Sebastian Schildt <[email-masked]<mailto:[email-masked]>>
> ibr.cs.tu-bs.de<http://ibr.cs.tu-bs.de> <mailto:[email-masked]>
>
>                 wrote:
>
>                 Hello,
>
>         [email-masked]<mailto:[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

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

---

From: Gilbert Clark <[email-masked]>
Date: Thu, 21 Jul 2016 19:13:31 -0400

>
>
> I would focus on the details required by the BPA in order to successfully
> forward notbundles from the producers/consumers. That alone would be a good
> basis for the APISRTWWCIN (API, Sorry Rick That’s What We’re Calling It
> Now).
>

This actually confuses me.  Maybe I'm just not understanding things
properly, but I think the following items are being considered as two
*different* things:

* Guidelines that discuss how to generate bundles that haven't been
produced by a BPA, and
* Guidelines that discuss how to generate bundles that have been produced
by a BPA

I guess my question here is: why should these two cases be discrete in the
first place?  Why should it be a BPA's responsibility to care about the
origin of a bundle?  This almost seems like it's going down the path of
defining two discrete bundle protocols: one for notbundles and one for
bundles.  If this is the case, my thought would be to use the notbundle as
the core BP spec, and build the bundle protocol as an extension to the
notbundle protocol ... or something along those lines.

I really think that, if a bundle conforms to the spec, then great!  It's
delivered, or routed, or etc. If not, then the side that's receiving /
processing the bundle can either try to fix it and hope for the best, or
get rid of it and tell the origin they really should try to do better next
time.  Either way, the result is that neither side cares whether or not the
other end is running a full BPA, they only care if the capabilities they're
using are actually present.  Thus, capability negotiation might be a good
thing to support (that would be along the lines of the above) ... but I
don't think the ability to negotiate capabilities is quite the same thing
as trying to legislate multiple levels (for lack of a better word) of BPA
support.

>From a pragmatic perspective, I also think the IETF specification for an
encoding really only matters at the borders between different DTNs ...
there's no way to know what's being spoken beyond that point, and I also
don't really see a reason one would want to care.  For all the devices are
concerned, one could strip off the bundle headers and replace 'em with CoAP
(or, for that matter, [insert awesome proprietary vendor protocol X here])
while messages are moving through the network ... and as long as these
messages either get locally delivered or rebuilt into conformant bundles
before they actually leave the network, no one would ever be the wiser.

In other words, I guess I'm not understanding the reasons one might wish to
treat transformation as a special case in the bundle protocol, nor am I
really understanding the reason to treat certain producers or consumers
differently than others insofar as protocol conformance is concerned ... so
could we back up and review that for a moment?

-Gilbert

>
> Thanks,
>
> Jeremy
>
>
>
> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Gilbert Clark
> *Sent:* Thursday, July 21, 2016 4:23 PM
> *To:* Elwyn Davies
> *Cc:* [email-masked]
>
> *Subject:* Re: [dtn] Representation of Bundle Protocol
>
>
>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 22 Jul 2016 17:09:43 +0000

Gilbert,
  I think mailman is configured to not send duplicate e-mails.

Elwyn,

  Thanks for the post. This is good information and, as you mention, not necessarily from an implementation point of view, but from a data-exchanged and responsibilities point of view.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Thursday, July 21, 2016 10:23 AM
To: Elwyn Davies
Cc: [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Hi:

-Gilbert

This document

Regards,
Elwyn

-------- Original message --------
From: "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>>
Date: 20/07/2016 12:23 (GMT+01:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Representation of Bundle Protocol

Agreed.

+1.

Thanks,
jeremy

I concur.

-Ed

Scott

All,

Opinions please...

Rick

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 22 Jul 2016 13:28:50 -0400

Hi Ed:

Is that an indication that my text was not received, or simply not useful?
I'm not quite sure I understand the intent of that message, so would
appreciate clarification there :)

Cheers,
Gilbert

On Fri, Jul 22, 2016 at 1:09 PM, Birrane, Edward J. <
[email-masked]> wrote:

>   Thanks for the post. This is good information and, as you mention, not
> necessarily from an implementation point of view, but from a data-exchanged
> and responsibilities point of view.
>
>
>
> -Ed
>
>
>
> ---
> *Sent:* Thursday, July 21, 2016 10:23 AM
> *To:* Elwyn Davies
> *Cc:* [email-masked]

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 22 Jul 2016 18:09:18 +0000

Gilbert,

  Sorry if I was unclear, I just meant if there was a concern about people receiving the same e-mail twice (once by having their e-mail explicitly stated, and once by membership in the DTN list) that that would not happen, as the Mailman mailing list software is configured to not send duplicates in that case.

-Ed

---

From: Gilbert Clark [mailto:[email-masked]]
Sent: Friday, July 22, 2016 1:29 PM
To: Birrane, Edward J.
Cc: Elwyn Davies; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Hi Ed:
Is that an indication that my text was not received, or simply not useful?  I'm not quite sure I understand the intent of that message, so would appreciate clarification there :)

Cheers,
Gilbert

On Fri, Jul 22, 2016 at 1:09 PM, Birrane, Edward J. <[email-masked]<mailto:[email-masked]>> wrote:
Gilbert,
  I think mailman is configured to not send duplicate e-mails.

Elwyn,

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:443-778-7423> / (F) 443-228-3839<tel:443-228-3839>

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gilbert Clark
Sent: Thursday, July 21, 2016 10:23 AM
To: Elwyn Davies
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Representation of Bundle Protocol

Hi:

-Gilbert

This document

Regards,
Elwyn

-------- Original message --------
From: "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>>
Date: 20/07/2016 12:23 (GMT+01:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Representation of Bundle Protocol

Agreed.

+1.

Thanks,
jeremy

I concur.

-Ed

Scott

All,

Opinions please...

Rick

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 22 Jul 2016 14:10:35 -0400

Right, I meant that there was actually some text inline that was relevant
to the conversation (or so I thought) ... but in the end, it's likely not
going to influence the outcome one way or the other, so we can just move on
:)

-Gilbert

On Fri, Jul 22, 2016 at 2:09 PM, Birrane, Edward J. <
[email-masked]> wrote:

> Gilbert,
>
>
>
>   Sorry if I was unclear, I just meant if there was a concern about people
> receiving the same e-mail twice (once by having their e-mail explicitly
> stated, and once by membership in the DTN list) that that would not happen,
> as the Mailman mailing list software is configured to not send duplicates
> in that case.
>
>
>
> -Ed
>
>
>
> ---
> *From:* Gilbert Clark [mailto:[email-masked]]
> *Sent:* Friday, July 22, 2016 1:29 PM
> *To:* Birrane, Edward J.
> *Cc:* Elwyn Davies; [email-masked]
>
> Is that an indication that my text was not received, or simply not
> useful?  I'm not quite sure I understand the intent of that message, so
> would appreciate clarification there :)
>
>
>
> Cheers,
>
> Gilbert
>
>
>