Subject: [dtn] Representation of Bundle Protocol

From: Marius Feldmann <[email-masked]>
Date: Mon, 18 Jul 2016 19:17:27 +0200

Dear all,

yes, I am aware of some discussion about this topic during the last
months. Nevertheless, due to the sound impression that no real consensus
has been reached (this impression has been intensified during the WG
meeting today), I want to bring it up again to achieve a rough consensus:

What is the precise reason, to remove the protocol representation from
the Bundle Protocol draft starting in draft-ietf-dtn-bpbis-01?

In my opinion there should be one canonical representation directly
specified within the Bundle Protocol standard that should be supported
by all implementations. Otherwise, the "standard" gets implementation
dependent which is not really what it should be.

Furthermore, supporting various on-wire formats by design seems to
introduce additional work reducing the deployment probability of the
Bundle Protocol.

Would those supporting a representation free version of the core Bundle
Protocol specification please provide arguments for the proposed approach?

Marius

---

From: <[email-masked]>
Date: Tue, 19 Jul 2016 06:37:32 +0000

Dear everyone,
I would like to expand upon Marius' statement: having a singular wire representation for BpBis does not necessarily prevent the implementation of "esoteric" implementations, it just pushes them out of the core specification.

It should be possible to create an interface between full-fledged BP agents and remote nodes which can speak in whatever format suits their application. The way this was proposed yesterday was as an "API at a distance." One of these services could produce or consume bundles in a known format (JSON-over-HTTP) via a connection to a gateway, which in turn connects to the BPA. That producer/consumer doesn't have to care about things like routing. To wit, one could create (for example) a simple JSON-over-HTTP implementation of the bundle protocol. Does this have to be a fully-featured BPA? Absolutely not. Could it interoperate with BpBis-based BPAs? Yeah, totally. 

>From the IETF perspective, I believe that interoperability would be simplified: We (as a WG) must create encapsulation rules (which may be as simple as "The JSON dictionary is sent via HTTP and formatted as follows."), without having to analyze every single interaction between encoding, CLA, implementation, etc... This does bring up another question, expanding upon Marius: Do folks who require "special" encodings for BpBis actually require the entirety of the stack? 

Thanks,
Jeremy

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Monday, July 18, 2016 7:17 PM
To: [email-masked]
Subject: [dtn] Representation of Bundle Protocol

Dear all,

yes, I am aware of some discussion about this topic during the last months. Nevertheless, due to the sound impression that no real consensus has been reached (this impression has been intensified during the WG meeting today), I want to bring it up again to achieve a rough consensus:

What is the precise reason, to remove the protocol representation from the Bundle Protocol draft starting in draft-ietf-dtn-bpbis-01?

In my opinion there should be one canonical representation directly specified within the Bundle Protocol standard that should be supported by all implementations. Otherwise, the "standard" gets implementation dependent which is not really what it should be.

Furthermore, supporting various on-wire formats by design seems to introduce additional work reducing the deployment probability of the Bundle Protocol.

Would those supporting a representation free version of the core Bundle Protocol specification please provide arguments for the proposed approach?

Marius

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 19 Jul 2016 07:03:21 +0000

I also am concerned with the multi-encoding approach, and also wonder if it is the best way to meet what seems to be competing requirements.

Requirement 1 being to keep the encoding of bundles very efficient for processing in resource constrained nodes/links.

Requirement 2 to make writing bundle agents easy by leveraging existing Internet mechanisms/ecosystems/concepts which all produce inefficient encodings.

Supporting multiple encodings is certainly one way to do this, but it leads to MANY unknowns related to negotiation, end-to-end security, topology, configuration, and other items best left to an IRTF group (IMO).

But what to do?

I wonder if there is a way to meet both requirements above with a single encoding scheme. That we select CBOR as that encoding scheme and spend out engineering time figuring out a way to provide the tools that convert between JSON and CBOR, or XML and CBOR, etc...

We have already convinced ourselves that translations amongst encodings would be both mechanical and deterministic and possible to undertake at
"encoding gateways" in the network. From there it seems a small step to suppose that such translation could be done locally on any node whose internal bundle representation is not CBOR, to make encoding translations a private matter at the node, and to maintain a single wire representation.

Said another way, is our time better spent engineering translation tools for rather than performing applied research into the nature of end-to-end services in a heterogenously encoded overlay?

Also, I think Jeremy makes an interesting point: what is a BPA proper? Can a bundle creator and a bundle consumer be different than a BPA? If so, perhaps BPAs speak a single wire encoding and bundle creators and consumers speak to the BPA (and each other) in different encodings. I am not certain that sidesteps all of the end-to-end issues but... It might. At least I think it worth a look.

And pictures. Somewhere in all of this I think pictures would be helpful. :)

-Ed

Sent with Good Work (www.good.com)

From: [email-masked] <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, Jul 19, 2016, 2:37 AM
To: [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Representation of Bundle Protocol

Dear everyone,

Thanks,
Jeremy

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Monday, July 18, 2016 7:17 PM
To: [email-masked]
Subject: [dtn] Representation of Bundle Protocol

Dear all,

Marius

---

From: Joerg Ott <[email-masked]>
Date: Tue, 19 Jul 2016 11:00:14 +0200

Hi,

I was actually wondering about the very same issue.  I couldn't follow
the list discussions for a while and I am really surprised to see
multiple encodings being considered.  The last time I witnessed this
as a design from the outset was H.248/MEGACO when people defined a
binary and textual protocol representation (besides maybe different
encodings that could be chosen for ASN.1).  Needless to say that this
didn't help much.

I don't see a very strong need for sophisticated expressiveness for
a layer 3.5 protocol even in the space case.  So I guess that simplicity
and efficient parsing should be our guides.

I am missing the really convincing case for more than a single
encoding.  As suggested before, one could do a separate document
if a real need arises, but I would like to push the responsibility
to those who perceive this need.

Jörg

On 19.07.16 09:03, Birrane, Edward J. wrote:
> I also am concerned with the multi-encoding approach, and also wonder if
> it is the best way to meet what seems to be competing requirements.
>
> Requirement 1 being to keep the encoding of bundles very efficient for
> processing in resource constrained nodes/links.
>
> Requirement 2 to make writing bundle agents easy by leveraging existing
> Internet mechanisms/ecosystems/concepts which all produce inefficient
> encodings.
>
> Supporting multiple encodings is certainly one way to do this, but it
> leads to MANY unknowns related to negotiation, end-to-end security,
> topology, configuration, and other items best left to an IRTF group (IMO).
>
> But what to do?
>
> I wonder if there is a way to meet both requirements above with a single
> encoding scheme. That we select CBOR as that encoding scheme and spend
> out engineering time figuring out a way to provide the tools that
> convert between JSON and CBOR, or XML and CBOR, etc...
>
> We have already convinced ourselves that translations amongst encodings
> would be both mechanical and deterministic and possible to undertake at
> "encoding gateways" in the network. From there it seems a small step to
> suppose that such translation could be done locally on any node whose
> internal bundle representation is not CBOR, to make encoding
> translations a private matter at the node, and to maintain a single wire
> representation.
>
> Said another way, is our time better spent engineering translation tools
> for rather than performing applied research into the nature of
> end-to-end services in a heterogenously encoded overlay?
>
> Also, I think Jeremy makes an interesting point: what is a BPA proper?
> Can a bundle creator and a bundle consumer be different than a BPA? If
> so, perhaps BPAs speak a single wire encoding and bundle creators and
> consumers speak to the BPA (and each other) in different encodings. I am
> not certain that sidesteps all of the end-to-end issues but... It might.
> At least I think it worth a look.
>
> *From: [email-masked] <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Tuesday, Jul 19, 2016, 2:37 AM
> *To: [email-masked] <[email-masked]
> <mailto:[email-masked]>>, [email-masked] <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *Re: [dtn] Representation of Bundle Protocol
>
> Dear everyone,
> I would like to expand upon Marius' statement: having a singular wire
> representation for BpBis does not necessarily prevent the implementation
> of "esoteric" implementations, it just pushes them out of the core
> specification.
>
> It should be possible to create an interface between full-fledged BP
> agents and remote nodes which can speak in whatever format suits their
> application. The way this was proposed yesterday was as an "API at a
> distance." One of these services could produce or consume bundles in a
> known format (JSON-over-HTTP) via a connection to a gateway, which in
> turn connects to the BPA. That producer/consumer doesn't have to care
> about things like routing. To wit, one could create (for example) a
> simple JSON-over-HTTP implementation of the bundle protocol. Does this
> have to be a fully-featured BPA? Absolutely not. Could it interoperate
> with BpBis-based BPAs? Yeah, totally.
>
>>From the IETF perspective, I believe that interoperability would be simplified: We (as a WG) must create encapsulation rules (which may be as simple as "The JSON dictionary is sent via HTTP and formatted as follows."), without having to analyze every single interaction between encoding, CLA, implementation, etc... This does
> bring up another question, expanding upon Marius: Do folks who require
> "special" encodings for BpBis actually require the entirety of the stack?
>
> Thanks,
> Jeremy
>
>

---

From: Sebastian Schildt <[email-masked]>
Date: Tue, 19 Jul 2016 11:14:34 +0200

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?

Sebastian

> Am 19.07.2016 um 08:37 schrieb <[email-masked]> <[email-masked]>:
> 
> Dear everyone,

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 19 Jul 2016 11:44:12 +0200

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

On Tue, Jul 19, 2016 at 11:14 AM, Sebastian Schildt <[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?

Spencer

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 19 Jul 2016 11:53:38 +0200

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

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Tue, 19 Jul 2016 11:19:44 +0000

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 Tue, Jul 19, 2016 at 11:14 AM, Sebastian Schildt <[email-masked] <mailto:[email-masked]> 

		wrote:

		Hello,

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 19 Jul 2016 11:32:43 +0000

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

From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, Jul 19, 2016, 7:19 AM
To: Marc Blanchet <[email-masked]<mailto:[email-masked]>>, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked] <[email-masked]<mailto:[email-masked]>>, Sebastian Schildt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Representation of Bundle Protocol

Hi

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135

-----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

                wrote:

                Hello,

Marc.

        Spencer

        dtn mailing list

---

From: <[email-masked]>
Date: Tue, 19 Jul 2016 11:47:03 +0000

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,

 -Ed

Sent with Good Work (www.good.com<http://www.good.com>)
From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, Jul 19, 2016, 7:19 AM
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]>>
Subject: Re: [dtn] Representation of Bundle Protocol

Hi

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
[email-masked]<mailto:[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]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Sebastian Schildt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Representation of Bundle Protocol

                wrote:

                Hello,

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]> <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: Rick Taylor <[email-masked]>
Date: Tue, 19 Jul 2016 12:20:29 +0000

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
>   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
>  
> 
> 
> 
> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]>
> To: Marc Blanchet <[email-masked]>, Spencer Dawkins at
> IETF <[email-masked]>
> Cc: [email-masked] <[email-masked]>, Sebastian Schildt <[email-masked]
> -bs.de>
>         On Tue, Jul 19, 2016 at 11:14 AM, Sebastian Schildt <schildt@
> ibr.cs.tu-bs.de <mailto:[email-masked]> 
> 
>                 wrote:
> 
>                 Hello,
> 
> one of my next question (as co-chair): if we have more than one,
> which one is mandatory?.
> 
> Marc.
> 
>         Spencer
>

---

From: Sebastian Schildt <[email-masked]>
Date: Tue, 19 Jul 2016 14:47:13 +0200

Rick, all

I am no sure if we really had a consensus as in your summary, but the use cases of having a "core" network and the ability to inject (and get) bundles in a more friendly format on the edge/for apps that not neccessarily include a full agent have definetely been the use cases discussed. So in my opinion mandating something like CBOR as mandatory for a compliant BPA would fine (as seperate Draft or directly in BPbis), however we should take care to make it as easy as possible for other encodings to be developed/added to the ecosystem. 

Possibly they could just be tied to convergence layers that do the translation on the fly (as we did for the MIME encoding of RFC505 a while ago), but then it is important to make sure we really have enough information in the CBOR to make this translation feasible.

Sebastian

> Am 19.07.2016 um 14:20 schrieb Rick Taylor <[email-masked]>:
> 
> All,
>

---

From: Joerg Ott <[email-masked]>
Date: Tue, 19 Jul 2016 14:57:24 +0200

When we are talking scenarios, are we talking about real ones (in terms
of needs) or perceived ones?

---

From: Rick Taylor <[email-masked]>
Date: Tue, 19 Jul 2016 13:03:21 +0000

All,

Jorg: I wasn't the one proposing the scenarios, just mentioning what I
remembered of the discussion at the mic in Prague (I think).

Sebastian: I was trying to say that I believe consensus seems to be
multiple encodings in the core is a bad idea.

I was one of those suggesting CBOR as an alternative encoding to the
5050 SDNV format as it is already known to transcode to other encodings
well (ignoring it's conciseness).

Rick

On Tue, 2016-07-19 at 14:57 +0200, Joerg Ott wrote:
> > I am no sure if we really had a consensus as in your summary, but
> > the use cases of having a "core" network and the ability to inject
> > (and get) bundles in a more friendly format on the edge/for apps
> > that not neccessarily include a full agent have definetely been the
> > use cases discussed. So in my opinion mandating something like CBOR
> > as mandatory for a compliant BPA would fine (as seperate Draft or
> > directly in BPbis), however we should take care to make it as easy
> > as possible for other encodings to be developed/added to the
> > ecosystem.
> > 
> > Possibly they could just be tied to convergence layers that do the
> > translation on the fly (as we did for the MIME encoding of RFC505 a
> > while ago), but then it is important to make sure we really have
> > enough information in the CBOR to make this translation feasible.
> > 
> > Sebastian
> > 
> > > 
> > > > From: dtn [mailto:[email-masked]] On Behalf Of Birrane,
> > > > Edward
> > > > J.
> > > > To: Sheehe, Charles J. (GRC-LCA0); Marc Blanchet; Spencer
> > > > Dawkins at
> > > > IETF
> > > > Is there truly no way to reconcile these? The IOT has many
> > > > resource
> > > > constrained devices.
> > > > 
> > > > "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.
> > > > 
> > > > 
> > > > 
> > > >                 As have understood the discussion, everybody
> > > > would be
> > > > fine, to have a
> > > >                 single representation of the BP, however
> > > > agreement
> > > > coud not be achieved,
> > > >                 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
> > > >                 techology stacks. Stuffing a custom binary
> > > > format
> > > > over websockets to a
> > > >                 As these requirements are impossible to
> > > > reconcile (at
> > > > least that has been
> > > >                 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,
> > > >         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

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 02:02:07 +0000

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,

Opinions please...

Rick

---

From: Marius Feldmann <[email-masked]>
Date: Wed, 20 Jul 2016 08:14:51 +0200

This sounds like a very good direction.

Is there any analysis around that compares SDNV and CBOR (plus maybe
further approaches) in regards of our central requirements (compactness
of representation, ease of implementation)?

Marius

---

From: Gilbert Clark <[email-masked]>
Date: Wed, 20 Jul 2016 02:47:46 -0400

As a note here: SDNV is not a general purpose encoding, so I don't think
it's necessarily really all that directly comparable with CBOR, is it?

I'm personally a fan of using old-school fixed length fields (a la IP) to
the extent that is possible, at least partially because fixed length fields
reduce processing overhead for anything that might need to inspect or
switch on bundle headers.

That said, I also don't personally have a problem with any generalized
encoding either ... as long as it's not XML :)

-Gilbert

On Jul 20, 2016 2:15 AM, "Marius Feldmann" <[email-masked]>
wrote:

> > 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];
> [email-masked]

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 20 Jul 2016 09:57:04 +0000

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]<mailto:[email-masked]>>
Date: Tuesday, Jul 19, 2016, 10:02 PM
To: Rick Taylor <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dtn] Representation of Bundle Protocol

Scott

All,

Opinions please...

Rick

---

From: Marius Feldmann <[email-masked]>
Date: Wed, 20 Jul 2016 12:11:39 +0200

Hi Gilbert,

On 20.07.2016 08:47, Gilbert Clark wrote:
>
> As a note here: SDNV is not a general purpose encoding, so I don't
> think it's necessarily really all that directly comparable with CBOR,
> is it?
>
For sure SDNV is not a general purpose encoding. Just to clearify this:
I was referring to a Bundle Protocol representation leveraging SDNV.

Marius

> I'm personally a fan of using old-school fixed length fields (a la IP)
> to the extent that is possible, at least partially because fixed
> length fields reduce processing overhead for anything that might need
> to inspect or switch on bundle headers.
>
> On Jul 20, 2016 2:15 AM, "Marius Feldmann"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     > 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] <mailto:[email-masked]>]
>     on behalf of Rick Taylor [[email-masked]
>     <mailto:[email-masked]>]
>     > 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]>
>     > On Tue, 2016-07-19 at 11:47 +0000, [email-masked]
>     <mailto:[email-masked]> wrote:
>     >> All,
>     >> From: dtn [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Birrane, Edward
>     >> J.
>     >> Cc: [email-masked] <mailto:[email-masked]>; Sebastian Schildt
>     >> Sent with Good Work (www.good.com <http://www.good.com>)
>     >>
>     >> 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]
>     >> -bs.de <http://bs.de>>
>     >> [email-masked] <mailto:[email-masked]>
>     >> Office: 216-433-5179 <tel:216-433-5179>
>     >>
>     >> From: dtn [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Marc Blanchet
>     >> 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] <mailto:[email-masked]>>
>     >>
>     >>                 wrote:
>     >>
>     >>                 Hello,
>     >>
>     >>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: <[email-masked]>
Date: Wed, 20 Jul 2016 10:20:46 +0000

+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.

-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

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Rick Taylor [[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:
> If this doesn't fly with the WG, why not go a slightly different way:
> wants to do something different (and it doesn't matter if that is
> format. The BpBis "considerations and requirements for alternate
> encodings" section would suddenly become extremely short: "Alternate
> data loss between".
> Cc: [email-masked]<mailto:[email-masked]>; Sebastian Schildt
> 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>
> I think we haven't reached that discussion point yet. It was clearly

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 20 Jul 2016 10:23:57 +0000

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).

From: [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] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>, [email-masked] <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked] <[email-masked]<mailto:[email-masked]>>, [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

I concur.

-Ed

Scott

All,

Opinions please...

Rick

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 14:40:45 +0000

Let's not go crazy.  I think the role of the BPA is actually quite precisely and comprehensively defined, both in RFC 5050 and in the bpbis spec; there's not a lot of rethinking needed.  We're not contemplating a radical new idea here; I see no need to blow everything up, start over again from scratch, renegotiate the BP specification, etc., etc. Let's see if we can finish these specifications before the end of the century.

The work that would be needed to realize the concept we are converging on, I think, is simply:

  1.  Merge the CBOR representation spec back into the bpbis spec.
  2.  Write a new specification for a protocol that is nothing more than the production and consumption of data objects in JSON representation whose elements map exactly to some subset of the elements of bundles.  (By definition these objects are *not* "bundles", because the bpbis spec defines exactly what bundles look like.  They are "bundle transmission requests" and "bundle reception notices", or something along that line.)

We should also recognize somewhere that additional instances of (2) might be needed for other representations in the future, but that's not a consideration for now.

Scott
________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, July 20, 2016 3:20 AM
To: [email-masked]; Burleigh, Scott C (312B); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dtn] Representation of Bundle Protocol

+1.

Thanks,
jeremy

I concur.

-Ed

Sent with Good Work (www.good.com<redir.aspx?REF=sdxTwQ35hkGw6glhLeM9u3jeDByV5IdsfGVyQ42VU_YwvZ2oqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
From: Burleigh, Scott C (312B) <[email-masked]<redir.aspx?REF=Xn7Bo9EurrveLE7iJanZsWfXjBJYFRUfyUkeTNORXLQwvZ2oqLDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>>
Date: Tuesday, Jul 19, 2016, 10:02 PM
To: Rick Taylor <[email-masked]<redir.aspx?REF=cV6v3zOyq5W3zhHSfPLeVO-pqH3AM-r7Z7EONiZGMjowvZ2oqLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>>, [email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..> <[email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>, [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> <[email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>>, [email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..> <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>, Birrane, Edward J. <[email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>>, [email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
Cc: [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, [email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.> <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
Subject: RE: [dtn] Representation of Bundle Protocol

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Rick Taylor [[email-masked]]
Sent: Tuesday, July 19, 2016 5:20 AM
To: [email-masked]<redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>; [email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; [email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: Re: [dtn] Representation of Bundle Protocol

All,

Opinions please...

Rick

On Tue, 2016-07-19 at 11:47 +0000, [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> wrote:
> From: dtn [mailto:[email-masked]<redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] On Behalf Of Birrane, Edward
> J.
> Cc: [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; Sebastian Schildt
> Sent with Good Work (www.good.com<redir.aspx?REF=uhqABFQuYM8Gr_tA9wl4RZEcfrgJVIPb37RckzqbB_ORHqCoqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
>
> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>
> To: Marc Blanchet <[email-masked]<redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>, Spencer Dawkins at
> IETF <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
> Cc: [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, Sebastian Schildt <[email-masked]
<redir.aspx?REF=GM9a2Umuzm7dsVCZhEUlLxDNC1hhnsZx76fQ03b2zRqRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUlMGI.>> -bs.de>
> [email-masked]<redir.aspx?REF=s8NcSMrbTfoc0SH0ZNYApA_SfzRiQ2017Exn6l7gY9-RHqCoqLDTCAFtYWlsdG86Q2hhcmxlcy5KLlNoZWVoZUBOQVNBLkdPVg..>
> Office: 216-433-5179
>
> From: dtn [mailto:[email-masked]<redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] On Behalf Of Marc Blanchet
> To: Spencer Dawkins at IETF <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
> Cc: [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; Sebastian Schildt <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
> ibr.cs.tu-bs.de <mailto:[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
>
>                 wrote:
>
>                 Hello,
>
>         [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <mailto:[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>
>         https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>
>
> [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
> https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>
> [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
> https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>
_______________________________________________
dtn mailing list
[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 14:53:08 +0000

Which, now that I think of it, is a cleaner way to think of this new capability.  If these bundle-data producers and consumers are at the edge of the network, then the "transformer" function can actually more easily live at the top of the DTN stack: it sends/receives JSON-encoded data in the course of receiving and sending bundles, i.e., it's a BP application.  It's not at the convergence layer at all.

Scott
________________________________
From: dtn [[email-masked]] on behalf of Burleigh, Scott C (312B) [[email-masked]]
Sent: Wednesday, July 20, 2016 7:40 AM
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

Scott

+1.

Thanks,
jeremy

I concur.

-Ed

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

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

All,

Opinions please...

Rick

On Tue, 2016-07-19 at 11:47 +0000, [email-masked]<UrlBlockedError.aspx> wrote:
> From: dtn [mailto:[email-masked]<UrlBlockedError.aspx>] On Behalf Of Birrane, Edward
> J.
> Cc: [email-masked]<UrlBlockedError.aspx>; Sebastian Schildt
> Sent with Good Work (www.good.com<UrlBlockedError.aspx>)
>
> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<UrlBlockedError.aspx>>
> To: Marc Blanchet <[email-masked]<UrlBlockedError.aspx>>, Spencer Dawkins at
> IETF <[email-masked]<UrlBlockedError.aspx>>
> Cc: [email-masked]<UrlBlockedError.aspx> <[email-masked]<UrlBlockedError.aspx>>, Sebastian Schildt <[email-masked]
<UrlBlockedError.aspx>> -bs.de>
> [email-masked]<UrlBlockedError.aspx>
> Office: 216-433-5179
>
> From: dtn [mailto:[email-masked]<UrlBlockedError.aspx>] On Behalf Of Marc Blanchet
> To: Spencer Dawkins at IETF <[email-masked]<UrlBlockedError.aspx>>
> Cc: [email-masked]<UrlBlockedError.aspx>; Sebastian Schildt <[email-masked]<UrlBlockedError.aspx>>
> ibr.cs.tu-bs.de <mailto:[email-masked]<UrlBlockedError.aspx>>
>
>                 wrote:
>
>                 Hello,
>
>         [email-masked]<UrlBlockedError.aspx> <mailto:[email-masked]<UrlBlockedError.aspx>>
>         https://www.ietf.org/mailman/listinfo/dtn<UrlBlockedError.aspx>
>
> [email-masked]<UrlBlockedError.aspx>
> https://www.ietf.org/mailman/listinfo/dtn<UrlBlockedError.aspx>
> [email-masked]<UrlBlockedError.aspx>
> https://www.ietf.org/mailman/listinfo/dtn<UrlBlockedError.aspx>
_______________________________________________
dtn mailing list
[email-masked]<UrlBlockedError.aspx>
https://www.ietf.org/mailman/listinfo/dtn<UrlBlockedError.aspx>

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 20 Jul 2016 16:58:48 +0200

On 20 Jul 2016, at 16:53, Burleigh, Scott C (312B) wrote:

> Which, now that I think of it, is a cleaner way to think of this new 
> capability.  If these bundle-data producers and consumers are at the 
> edge of the network, then the "transformer" function can actually more 
> easily live at the top of the DTN stack: it sends/receives 
> JSON-encoded data in the course of receiving and sending bundles, 
> i.e., it's a BP application.  It's not at the convergence layer at 
> all.

right. that is really the only place I could see these additional 
encodings being processed, to keep the basic processing and forwarding 
of bundles within the network being as simple and efficient as possible. 
I can’t imagine having intermediate nodes to start mangling 
encoding… it just does not make sense to me.

Marc.

> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Let's not go crazy.  I think the role of the BPA is actually quite 
> precisely and comprehensively defined, both in RFC 5050 and in the 
> bpbis spec; there's not a lot of rethinking needed.  We're not 
> contemplating a radical new idea here; I see no need to blow 
> everything up, start over again from scratch, renegotiate the BP 
> specification, etc., etc. Let's see if we can finish these 
> specifications before the end of the century.
>
>   2.  Write a new specification for a protocol that is nothing more 
> than the production and consumption of data objects in JSON 
> representation whose elements map exactly to some subset of the 
> elements of bundles.  (By definition these objects are *not* 
> "bundles", because the bpbis spec defines exactly what bundles look 
> like.  They are "bundle transmission requests" and "bundle reception 
> notices", or something along that line.)
>
> We should also recognize somewhere that additional instances of (2) 
> might be needed for other representations in the future, but that's 
> not a consideration for now.
>
> Scott
> To: [email-masked]; Burleigh, Scott C (312B); 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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:
>
> ·         The BPA MUST provide send/receive functionality to local 
> applications, including transformation layers for bundle producers and 
> consumers.
>
> ·         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
>
> To: Burleigh, Scott C (312B); Rick Taylor; [email-masked]; 
> Mayer, Jeremy; [email-masked]; 
> 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]<UrlBlockedError.aspx>>
> To: Rick Taylor 
> <[email-masked]<UrlBlockedError.aspx>>, 
> [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>, 
> [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>, 
> [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>, Birrane, Edward J. 
> <[email-masked]<UrlBlockedError.aspx>>, 
> [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>
> Cc: [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>, 
> [email-masked]<UrlBlockedError.aspx> 
> <[email-masked]<UrlBlockedError.aspx>>
> 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 -- 
> 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
> To: [email-masked]<UrlBlockedError.aspx>; 
> [email-masked]<UrlBlockedError.aspx>; 
> [email-masked]<UrlBlockedError.aspx>; 
> [email-masked]<UrlBlockedError.aspx>; 
> [email-masked]<UrlBlockedError.aspx>
> Cc: [email-masked]<UrlBlockedError.aspx>; 
> [email-masked]<UrlBlockedError.aspx>
> On Tue, 2016-07-19 at 11:47 +0000, 
> [email-masked]<UrlBlockedError.aspx> wrote:
>> All,
>> From: Sheehe, Charles J. (GRC-LCA0) 
>> <[email-masked]<UrlBlockedError.aspx>>
>> Cc: [email-masked]<UrlBlockedError.aspx> 
>> <[email-masked]<UrlBlockedError.aspx>>, Sebastian Schildt 
>> <[email-masked]
>> To: Spencer Dawkins at IETF 
>> <[email-masked]<UrlBlockedError.aspx>>
>> <[email-masked]<UrlBlockedError.aspx>>
>> ibr.cs.tu-bs.de 
>> <mailto:[email-masked]<UrlBlockedError.aspx>>
>>
>>                 wrote:
>>
>>                 Hello,
>>
>> <mailto:[email-masked]<UrlBlockedError.aspx>>
>>

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 20 Jul 2016 17:08:27 +0200

> notices", or something along that line.)

There is another variation of this and I’m not yet sure which one I 
would prefer, but I put it on the table:

- keep the CBOR representation in a separate document
- bpbis spec refers to CBOR as _the_ mandatory encoding
- have other encodings in other documents

the benefit here is a somewhat decoupling but still achieving the 
mandatory requirement, and make it more easy to define other encodings 
(since they would have very similar document structure than the CBOR 
one).

The bpbis and CBOR encoding would then be considered as a bundle in the 
processing of the documents through wg LC, IETF LC, IESG, etc…

Regards, Marc.

> Sent with Good Work 
> (www.good.com<redir.aspx?REF=sdxTwQ35hkGw6glhLeM9u3jeDByV5IdsfGVyQ42VU_YwvZ2oqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
> <[email-masked]<redir.aspx?REF=Xn7Bo9EurrveLE7iJanZsWfXjBJYFRUfyUkeTNORXLQwvZ2oqLDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>>
> <[email-masked]<redir.aspx?REF=cV6v3zOyq5W3zhHSfPLeVO-pqH3AM-r7Z7EONiZGMjowvZ2oqLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>>, 
> [email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..> 
> <[email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>, 
> [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> 
> <[email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>>, 
> [email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..> 
> <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>, 
> Birrane, Edward J. 
> <[email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>>, 
> [email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.> 
> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
> Cc: 
> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, 
> [email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.> 
> <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
> To: 
> [email-masked]<redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; 
> [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>; 
> [email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; 
> [email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; 
> [email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
> Cc: 
> [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; 
> [email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
> [email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> 
> wrote:
>> All,
>> From: dtn 
>> [mailto:[email-masked]<redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] 
>> On Behalf Of Birrane, Edward
>> J.
>> Cc: 
>> [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; 
>> Sebastian Schildt
>> Sent with Good Work 
>> (www.good.com<redir.aspx?REF=uhqABFQuYM8Gr_tA9wl4RZEcfrgJVIPb37RckzqbB_ORHqCoqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
>>
>> <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>
>> To: Marc Blanchet 
>> <[email-masked]<redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>, 
>> Spencer Dawkins at
>> IETF 
>> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
>> Cc: 
>> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, 
>> Sebastian Schildt <[email-masked]
>> From: dtn 
>> [mailto:[email-masked]<redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] 
>> On Behalf Of Marc Blanchet
>> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
>> Cc: 
>> [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; 
>> Sebastian Schildt 
>> <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
>> <mailto:[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
>>
>>                 wrote:
>>
>>                 Hello,
>>
>> <mailto:[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>
>>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 15:22:38 +0000

Marc, I see the advantage of having a document that could serve as a model for other representation documents, but I now think that the CBOR spec would actually not be a good model.  That's because the CBOR representation would necessarily encompass all elements of Bundle Protocol -- and would actually be augmented by the CBOR representations of extension blocks as extension block specifications (such as bpspec) are developed -- while I now think the JSON (XML, etc.) representation specification(s) need not address anything more than the elements of BP that are always exposed to BP applications: destination, report-to, payload, custody transfer flag, etc.

Scott
________________________________
From: Marc Blanchet [[email-masked]]
Sent: Wednesday, July 20, 2016 8:08 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

  1.  Merge the CBOR representation spec back into the bpbis spec.
  2.  Write a new specification for a protocol that is nothing more than the production and consumption of data objects in JSON representation whose elements map exactly to some subset of the elements of bundles. (By definition these objects are not "bundles", because the bpbis spec defines exactly what bundles look like. They are "bundle transmission requests" and "bundle reception notices", or something along that line.)

There is another variation of this and I’m not yet sure which one I would prefer, but I put it on the table:

  *   keep the CBOR representation in a separate document
  *   bpbis spec refers to CBOR as the mandatory encoding
  *   have other encodings in other documents

the benefit here is a somewhat decoupling but still achieving the mandatory requirement, and make it more easy to define other encodings (since they would have very similar document structure than the CBOR one).

The bpbis and CBOR encoding would then be considered as a bundle in the processing of the documents through wg LC, IETF LC, IESG, etc…

Regards, Marc.

Scott

From: [email-masked]<redir.aspx?REF=cpk2oKmdLGVX3GbKLC0DIWQjpyUBoRSY_XsUO6R6pa4B_ji-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> [[email-masked]<redir.aspx?REF=cpk2oKmdLGVX3GbKLC0DIWQjpyUBoRSY_XsUO6R6pa4B_ji-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>]
Sent: Wednesday, July 20, 2016 3:20 AM
To: [email-masked]<redir.aspx?REF=qqey-FTo01_U8FcrSGERk5pWFGlUVn-KkbYFi9LtdNIB_ji-sLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; Burleigh, Scott C (312B); [email-masked]<redir.aspx?REF=T_75FFu9wAfYLhvW7gaQlcUCYoBBMBV6qHmiGB1lrNoB_ji-sLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>; [email-masked]<redir.aspx?REF=9uM3aejh25oeqHyboDl06BmxOW7BjqA58HNwjy9Pd6MB_ji-sLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=KK7MDXqbv1tvP_HDHESNJDKXbcI-eLw-pqzuIhpgsyUB_ji-sLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=8sPyZKEEEpKZ2YEH_T2o5uBvRNJMgtS3EB3uAxjXVpcB_ji-sLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=WzOKYqyPHTXEMF-8x00b1W4Jla8Hku5kATrwwDHuG74B_ji-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=FJHMgRBeV1clbjl1SaH02_Kbse1jW8CCyNKes6pkTRZiXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: RE: [dtn] Representation of Bundle Protocol

+1.

Thanks,
jeremy

From: Birrane, Edward J. [mailto:[email-masked]<redir.aspx?REF=eFd2A0_dZGCOI1SlBe-VYxrFevYCEPZNTAP6FQKbontiXzu-sLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>]
Sent: Wednesday, July 20, 2016 11:57 AM
To: Burleigh, Scott C (312B); Rick Taylor; [email-masked]<redir.aspx?REF=Nxin0bHY4WPiq7Lt50ms8nYIMXNRm3slZ-Z4btfQ9cxiXzu-sLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; Mayer, Jeremy; [email-masked]<redir.aspx?REF=kMrYeWTD-bnf5LcGlhhHy3qQD-FKuLUIkH4QXd4SQQFiXzu-sLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=VDLmAT81YuCrbFvmVy-y9-qEAMETX15vH3Wt7oxV1RliXzu-sLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=FJHMgRBeV1clbjl1SaH02_Kbse1jW8CCyNKes6pkTRZiXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: RE: [dtn] Representation of Bundle Protocol

I concur.

-Ed

Sent with Good Work (www.good.com<redir.aspx?REF=m-76cxLbMllYWhnxkgtk7MZx2QByQESE7VtrK2oP7UtiXzu-sLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t><redir.aspx?REF=sdxTwQ35hkGw6glhLeM9u3jeDByV5IdsfGVyQ42VU_YwvZ2oqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
From: Burleigh, Scott C (312B) <[email-masked]<redir.aspx?REF=Xn7Bo9EurrveLE7iJanZsWfXjBJYFRUfyUkeTNORXLQwvZ2oqLDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>>
Date: Tuesday, Jul 19, 2016, 10:02 PM
To: Rick Taylor <[email-masked]<redir.aspx?REF=cV6v3zOyq5W3zhHSfPLeVO-pqH3AM-r7Z7EONiZGMjowvZ2oqLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>>, [email-masked]<redir.aspx?REF=Nxin0bHY4WPiq7Lt50ms8nYIMXNRm3slZ-Z4btfQ9cxiXzu-sLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..><redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..> <[email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>, [email-masked]<redir.aspx?REF=oiT_t1ElPdUd1IiwPhLJptzXo3TqAAI1KIsJYUHR4FJiXzu-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..><redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> <[email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>>, [email-masked]<redir.aspx?REF=kMrYeWTD-bnf5LcGlhhHy3qQD-FKuLUIkH4QXd4SQQFiXzu-sLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..><redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..> <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>, Birrane, Edward J. <[email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>>, [email-masked]<redir.aspx?REF=VDLmAT81YuCrbFvmVy-y9-qEAMETX15vH3Wt7oxV1RliXzu-sLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.><redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, [email-masked]<redir.aspx?REF=FJHMgRBeV1clbjl1SaH02_Kbse1jW8CCyNKes6pkTRZiXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.><redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.> <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
Subject: RE: [dtn] Representation of Bundle Protocol

Scott

From: dtn [[email-masked]<redir.aspx?REF=BkkknLPGjgLvVmt3zkJ8OWxAs1RSFZMr-Sy6eAl_zi5iXzu-sLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] on behalf of Rick Taylor [[email-masked]<redir.aspx?REF=5rsCcJyH7EmalCJ4buVMpi9zdu1AWdr99u23-Bp1D_JiXzu-sLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>]
Sent: Tuesday, July 19, 2016 5:20 AM
To: [email-masked]<redir.aspx?REF=Nxin0bHY4WPiq7Lt50ms8nYIMXNRm3slZ-Z4btfQ9cxiXzu-sLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..><redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=oiT_t1ElPdUd1IiwPhLJptzXo3TqAAI1KIsJYUHR4FJiXzu-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..><redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>; [email-masked]<redir.aspx?REF=kMrYeWTD-bnf5LcGlhhHy3qQD-FKuLUIkH4QXd4SQQFiXzu-sLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..><redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=eFd2A0_dZGCOI1SlBe-VYxrFevYCEPZNTAP6FQKbontiXzu-sLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..><redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; [email-masked]<redir.aspx?REF=VDLmAT81YuCrbFvmVy-y9-qEAMETX15vH3Wt7oxV1RliXzu-sLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.><redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=FJHMgRBeV1clbjl1SaH02_Kbse1jW8CCyNKes6pkTRZiXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.><redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: Re: [dtn] Representation of Bundle Protocol

All,

Opinions please...

Rick

On Tue, 2016-07-19 at 11:47 +0000, [email-masked]<redir.aspx?REF=oiT_t1ElPdUd1IiwPhLJptzXo3TqAAI1KIsJYUHR4FJiXzu-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..><redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> wrote:

All,

Thanks,
Jeremy
From: dtn [mailto:[email-masked]<redir.aspx?REF=BkkknLPGjgLvVmt3zkJ8OWxAs1RSFZMr-Sy6eAl_zi5iXzu-sLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.><redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] 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]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; Sebastian Schildt
Subject: Re: [dtn] Representation of Bundle Protocol

Chuck,

-Ed

Sent with Good Work (www.good.com<redir.aspx?REF=m-76cxLbMllYWhnxkgtk7MZx2QByQESE7VtrK2oP7UtiXzu-sLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t><redir.aspx?REF=uhqABFQuYM8Gr_tA9wl4RZEcfrgJVIPb37RckzqbB_ORHqCoqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)

Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>, Sebastian Schildt <[email-masked]<redir.aspx?REF=hWeI78vD6REuikWKwYWlqOURUnjfiRY6FzFaOCoMCk9iXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHU.>

Hi

Is there truly no way to reconcile these? The IOT has many resource
constrained devices.

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]<redir.aspx?REF=Ns_eMRp9Dd6z4bIRiCqGYuePEIAPmw3IcHx515H-htJiXzu-sLDTCAFtYWlsdG86Q2hhcmxlcy5KLlNoZWVoZUBOQVNBLkdPVg..><redir.aspx?REF=s8NcSMrbTfoc0SH0ZNYApA_SfzRiQ2017Exn6l7gY9-RHqCoqLDTCAFtYWlsdG86Q2hhcmxlcy5KLlNoZWVoZUBOQVNBLkdPVg..>
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]<redir.aspx?REF=BkkknLPGjgLvVmt3zkJ8OWxAs1RSFZMr-Sy6eAl_zi5iXzu-sLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.><redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] On Behalf Of Marc Blanchet
Sent: Tuesday, July 19, 2016 5:54 AM
To: Spencer Dawkins at IETF <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; Sebastian Schildt <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>
Subject: Re: [dtn] Representation of Bundle Protocol

ibr.cs.tu-bs.de [email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.<redir.aspx?REF=-ZpcDf-G-oCpr9Qpqcy4BMaDiuMAr-ORb63PTOTU3o1iXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGUlM0NyZWRpci5hc3B4P1JFRj13QlFUSzdGbWhEWkZhWFdOQTZabFQ1QzJsLTE4cmtUMVpTYTcxbXROcnl5UkhxQ29xTERUQ0FGdFlXbHNkRzg2YzJOb2FXeGtkRUJwWW5JdVkzTXVkSFV0WW5NdVpHVS4.>>

            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?

Marc.

    Spencer

    dtn mailing list

dtn mailing list
[email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=e0ACPkXrEe8AfgLc9Wzj-FzDNpRFM9hSxlRmZPCH4-piXzu-sLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..><redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>

dtn mailing list
[email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=e0ACPkXrEe8AfgLc9Wzj-FzDNpRFM9hSxlRmZPCH4-piXzu-sLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..><redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>

dtn mailing list
[email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=e0ACPkXrEe8AfgLc9Wzj-FzDNpRFM9hSxlRmZPCH4-piXzu-sLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..><redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>

dtn mailing list
[email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>
https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=e0ACPkXrEe8AfgLc9Wzj-FzDNpRFM9hSxlRmZPCH4-piXzu-sLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg..>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 Jul 2016 16:50:56 +0000

Hi, I think it was me who first uttered the word "CBOR" several IETFs ago, so obviously
I approve incorporating the encoding in 5050(bis).

I believe that for any encoding there is a tradeoff between processing overhead and
bits-on-the-wire overhead, and I believe reduced bits-on-the-wire is the more
important consideration. But, the encoding scheme should not influence the way
data at rest is partitioned, and for SDNV we see artifacts of the way the encoding
works in the way the numeric numbering values are partitioned for "ipn" at least.
I do not think we should have any such artifacts in any new numbering/addressing
schemes we may develop.

Thanks - Fred
[email-masked]

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Wednesday, July 20, 2016 8:23 AM
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Scott
Cc: [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]>

  1.  Write a new specification for a protocol that is nothing more than the production and consumption of data objects in JSON representation whose elements map exactly to some subset of the elements of bundles. (By definition these objects are not "bundles", because the bpbis spec defines exactly what bundles look like. They are "bundle transmission requests" and "bundle reception notices", or something along that line.)

There is another variation of this and I'm not yet sure which one I would prefer, but I put it on the table:

The bpbis and CBOR encoding would then be considered as a bundle in the processing of the documents through wg LC, IETF LC, IESG, etc...

Regards, Marc.

Scott

+1.

Thanks,
jeremy

I concur.

-Ed

Sent with Good Work (www.good.com<redir.aspx?REF=m-76cxLbMllYWhnxkgtk7MZx2QByQESE7VtrK2oP7UtiXzu-sLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t><redir.aspx?REF=sdxTwQ35hkGw6glhLeM9u3jeDByV5IdsfGVyQ42VU_YwvZ2oqLDTCAFodHRwOi8vd3d3Lmdvb2QuY29t>)
From: Burleigh, Scott C (312B) <[email-masked]<redir.aspx?REF=Xn7Bo9EurrveLE7iJanZsWfXjBJYFRUfyUkeTNORXLQwvZ2oqLDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.<mailto:[email-masked]%3credir.aspx?REF=Xn7Bo9EurrveLE7iJanZsWfXjBJYFRUfyUkeTNORXLQwvZ2oqLDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>>>
Date: Tuesday, Jul 19, 2016, 10:02 PM
To: Rick Taylor <[email-masked]<redir.aspx?REF=cV6v3zOyq5W3zhHSfPLeVO-pqH3AM-r7Z7EONiZGMjowvZ2oqLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t<mailto:[email-masked]%3credir.aspx?REF=cV6v3zOyq5W3zhHSfPLeVO-pqH3AM-r7Z7EONiZGMjowvZ2oqLDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>>>, [email-masked]<redir.aspx?REF=Nxin0bHY4WPiq7Lt50ms8nYIMXNRm3slZ-Z4btfQ9cxiXzu-sLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..><redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..> <[email-masked]<redir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..<mailto:[email-masked]%3credir.aspx?REF=zBTGTr2HfEj85PbdXAnQofbscNBcU5E6gmTkDt3iFRQwvZ2oqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>>, [email-masked]<redir.aspx?REF=oiT_t1ElPdUd1IiwPhLJptzXo3TqAAI1KIsJYUHR4FJiXzu-sLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..><redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> <[email-masked]<redir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..<mailto:[email-masked]%3credir.aspx?REF=IsvvtBLVAaEdiokimFm5zin9CtGsh8m-P-pYsK2kq2eRHqCoqLDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>>>, [email-masked]<redir.aspx?REF=kMrYeWTD-bnf5LcGlhhHy3qQD-FKuLUIkH4QXd4SQQFiXzu-sLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..><redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..> <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..<mailto:[email-masked]%3credir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>>, Birrane, Edward J. <[email-masked]<redir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..<mailto:[email-masked]%3credir.aspx?REF=m_UmCe1gezOTq9lvFZSf1CIE58c24nqiop8063VwwkyRHqCoqLDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>>>, [email-masked]<redir.aspx?REF=VDLmAT81YuCrbFvmVy-y9-qEAMETX15vH3Wt7oxV1RliXzu-sLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.><redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.> <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.<mailto:[email-masked]%3credir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn<mailto:[email-masked]%3credir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>>, [email-masked]<redir.aspx?REF=FJHMgRBeV1clbjl1SaH02_Kbse1jW8CCyNKes6pkTRZiXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.><redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.> <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.<mailto:[email-masked]%3credir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>>
Subject: RE: [dtn] Representation of Bundle Protocol

Scott

All,

Opinions please...

Rick

All,

Thanks,
Jeremy

Chuck,

-Ed

From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]<redir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..<mailto:[email-masked]%3credir.aspx?REF=XLe0Z_L1K2izVpwOsNjjB1G4gTkiy6FrEuME5guNiJaRHqCoqLDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>>>
Date: Tuesday, Jul 19, 2016, 7:19 AM
To: Marc Blanchet <[email-masked]<redir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..<mailto:[email-masked]%3credir.aspx?REF=5vERLV75h3M-QNGj-Q6dcXHP_FoTcQCFctD8Dgy-iZGRHqCoqLDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>>>, Spencer Dawkins at
IETF <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.<mailto:[email-masked]%3credir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn> <[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn<mailto:[email-masked]%3credir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>>, Sebastian Schildt <[email-masked]<redir.aspx?REF=hWeI78vD6REuikWKwYWlqOURUnjfiRY6FzFaOCoMCk9iXzu-sLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHU.>

Hi

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135

"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]<redir.aspx?REF=BkkknLPGjgLvVmt3zkJ8OWxAs1RSFZMr-Sy6eAl_zi5iXzu-sLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.><redir.aspx?REF=m_YfTHryhyMw8M498Ap7hcLovyreXqIXjPpyKmILgmuRHqCoqLDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] On Behalf Of Marc Blanchet
Sent: Tuesday, July 19, 2016 5:54 AM
To: Spencer Dawkins at IETF <[email-masked]<redir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.<mailto:[email-masked]%3credir.aspx?REF=WJ8bS7w1mSZ4YR_uIpmrf5ulPVKmJF3xmTTVe6gmyceRHqCoqLDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>>>
Cc: [email-masked]<redir.aspx?REF=LOoXuTrdRlCIf_1Jr8SVUltSXsev5FRx5TL8KNAA-7diXzu-sLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn><redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; Sebastian Schildt <[email-masked]<redir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.<mailto:[email-masked]%3credir.aspx?REF=wBQTK7FmhDZFaXWNA6ZlT5C2l-18rkT1ZSa71mtNryyRHqCoqLDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>>>
Subject: Re: [dtn] Representation of Bundle Protocol

            wrote:

            Hello,

fine, to have a

least that has been

the the same time,

would not be one

Marc.

    Spencer

    dtn mailing list

   [email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn<mailto:[email-masked]%3credir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>> <mailto:[email-masked]<redir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn<mailto:[email-masked]%3credir.aspx?REF=naBgz-dvrhI05B7dyex_HIqbjqXy-Y0YFrRWsF0yetiRHqCoqLDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>>>

  https://www.ietf.org/mailman/listinfo/dtn<redir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg<https://www.ietf.org/mailman/listinfo/dtn%3credir.aspx?REF=YTob5ItvlhS1bxn_RC5iw69t1uQpCv93cwhssmemve6RHqCoqLDTCAFodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bg>..>

dtn mailing list

dtn mailing list

dtn mailing list

dtn mailing list

---

From: <[email-masked]>
Date: Wed, 20 Jul 2016 18:47:59 +0000

Sorry if I was unclear, but I am not proposing redeveloping BP. I think that we're in agreement, the transformation layer should act as an application, and should not require anything special from the BPA.

Thanks,
Jeremy

From: Burleigh, Scott C (312B) [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 4:53 PM
To: Mayer, Jeremy; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dtn] Representation of Bundle Protocol

Scott
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]>

Scott
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]]
Sent: Wednesday, July 20, 2016 3:20 AM
To: [email-masked]<mailto:[email-masked]>; Burleigh, Scott C (312B); [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
+1.

Thanks,
jeremy

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

I concur.

-Ed

Scott

All,

Opinions please...

Rick

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 20 Jul 2016 23:14:16 +0200

Sounds fine. So we are rolling CBOR as _the_ encoding in. Either directly in Bpbis or as (mandatory) second draft. We should probably have a vote on the "if" and "how"?

As for potential handy alternative representations of a bundle, people can describe them seperately (by describing a mapping to the canonical CBOR or mapping to the abstract structures defined in Bpbis).

Putting alternative encodings "on top" of the stack is actually quite similar to what the IBR-DTN API is doing today: It accepts and serves you bundles in an easy ASCII "protocol". I could imagine switching this to some sort standardized encoding, that would hopefully also be implemented by other BPAs, so code/apps interfacing and injecting bundles in such a way could more easily be shared between BPAs.

Convergence layers should not need to deal  with a gazillion of encodings and complicated handshakes. (I would however argue that from an implementation standpoint it is still possible to build lets say a websocket CL that spits out JSON by default. But I think that is really an implementation thing, and has no impact on the actual specification of a potential JSON encoding).

Sebastian

P.S.: The above is meant as a summary, because I felt we already converged. If it is controversial, I did not listen carefully enough or did not understand some of you :)

> Am 20.07.2016 um 20:47 schrieb <[email-masked]> <[email-masked]>:
> 
> Sorry if I was unclear, but I am not proposing redeveloping BP. I think that we’re in agreement, the transformation layer should act as an application, and should not require anything special from the BPA.
>  
> Thanks,
> Jeremy
>  
> Merge the CBOR representation spec back into the bpbis spec.
> Write a new specification for a protocol that is nothing more than the production and consumption of data objects in JSON representation whose elements map exactly to some subset of the elements of bundles.  (By definition these objects are *not* "bundles", because the bpbis spec defines exactly what bundles look like.  They are "bundle transmission requests" and "bundle reception notices", or something along that line.)
>  
> From: Burleigh, Scott C (312B) <[email-masked]>
> 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]>

---

From: Marius Feldmann <[email-masked]>
Date: Wed, 20 Jul 2016 21:39:50 +0000

Well, I fully support the approach to have a single, mandatory  
encoding defined directly in the bpis specification and render  
alternate bundle encoding definitions possible via supplementary  
documents.

I fully disagree that the mandatory encoding should be CBOR.

Marius

Zitat von Sebastian Schildt <[email-masked]>:

> Sounds fine. So we are rolling CBOR as _the_ encoding in. Either  
> directly in Bpbis or as (mandatory) second draft. We should probably  
> have a vote on the "if" and "how"?
>
> As for potential handy alternative representations of a bundle,  
> people can describe them seperately (by describing a mapping to the  
> canonical CBOR or mapping to the abstract structures defined in  
> Bpbis).
>
> Putting alternative encodings "on top" of the stack is actually  
> quite similar to what the IBR-DTN API is doing today: It accepts and  
> serves you bundles in an easy ASCII "protocol". I could imagine  
> switching this to some sort standardized encoding, that would  
> hopefully also be implemented by other BPAs, so code/apps  
> interfacing and injecting bundles in such a way could more easily be  
> shared between BPAs.
>
> Convergence layers should not need to deal  with a gazillion of  
> encodings and complicated handshakes. (I would however argue that  
> from an implementation standpoint it is still possible to build lets  
> say a websocket CL that spits out JSON by default. But I think that  
> is really an implementation thing, and has no impact on the actual  
> specification of a potential JSON encoding).
>
>
> Sebastian
>
> P.S.: The above is meant as a summary, because I felt we already  
> converged. If it is controversial, I did not listen carefully enough  
> or did not understand some of you :)
>
>
>> Sorry if I was unclear, but I am not proposing redeveloping BP. I  
>> think that we’re in agreement, the transformation layer should act  
>> as an application, and should not require anything special from the  
>> BPA.
>>
>> Thanks,
>> Jeremy
>>
>> To: Mayer, Jeremy; [email-masked];  
>> Which, now that I think of it, is a cleaner way to think of this  
>> new capability.  If these bundle-data producers and consumers are  
>> at the edge of the network, then the "transformer" function can  
>> actually more easily live at the top of the DTN stack: it  
>> sends/receives JSON-encoded data in the course of receiving and  
>> sending bundles, i.e., it's a BP application.  It's not at the  
>> convergence layer at all.
>>
>> Scott
>> Write a new specification for a protocol that is nothing more than  
>> the production and consumption of data objects in JSON  
>> like.  They are "bundle transmission requests" and "bundle  
>> reception notices", or something along that line.)
>>
>> 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:
>> applications, including transformation layers for bundle producers  
>> and consumers.
>> To: Burleigh, Scott C (312B); Rick Taylor;  
>> [email-masked]; Mayer, Jeremy;  
>> function of roles and responsibilities not just "the thing that  
>> talks CBOR".
>>
>> producers/consumers" wanted to network amongst themselves without  
>> an intermediary BPA, to include security and routing/forwarding  
>> etc...
>>
>> -Ed
>>
>>
>> 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]>
>> would instead exchange data items conforming to such a protocol

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 22:19:15 +0000

Marius, can you explain why you don't support a single CBOR encoding?  What encoding would you prefer, and why?  I definitely think we should be open to alternatives, but CBOR looks pretty good to me.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Marius Feldmann [[email-masked]]
Sent: Wednesday, July 20, 2016 2:39 PM
To: [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Marius

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 20 Jul 2016 22:23:51 +0000

Sebastian, I think we are on the same page here.  I believe the concept of putting alternate encodings "on top" of the stack is in effect supported by the DTN2 RPC interface as well, so I think we are on well-plowed ground.  And I am a big fan of delegating functionality to the convergence layer in general, but in this instance I really think it's cleaner to delegate "up" to the application layer.

Scott
________________________________
From: Sebastian Schildt [[email-masked]]
Sent: Wednesday, July 20, 2016 2:14 PM
To: [email-masked]
Cc: Burleigh, Scott C (312B); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Sebastian

Am 20.07.2016 um 20:47 schrieb <[email-masked]<redir.aspx?REF=j6iJbS-oH3Nizo8qR2lL-1fHVYvpDyjLhdDmQJuwSvZO9iIC7LDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>> <[email-masked]<redir.aspx?REF=j6iJbS-oH3Nizo8qR2lL-1fHVYvpDyjLhdDmQJuwSvZO9iIC7LDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>>:

Thanks,
Jeremy

From: Burleigh, Scott C (312B) [mailto:[email-masked]<redir.aspx?REF=0NF-6zMZ9mjD6Sbop-P5FAiyibuB7EwmVcJGii86KA1O9iIC7LDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>]
Sent: Wednesday, July 20, 2016 4:53 PM
To: Mayer, Jeremy; [email-masked]<redir.aspx?REF=Tcnix2-2U3UR25tFlSGY_5wRyQVoMsKv8r-P5sovOOFO9iIC7LDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; [email-masked]<redir.aspx?REF=81sx8GnO7hGTxM_hrpaeD7Tnb01Rcscpo6emRFrEeJBO9iIC7LDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>; [email-masked]<redir.aspx?REF=kojPfmfXFI_GwLtGY99rua30pxkQG6IPmRgbIx0IhTZO9iIC7LDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=FrNn7h4HU9Ikpc_-IhXqov-JVUL_fiE1J5TQTOKRdktO9iIC7LDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=8IiDXLwnc52diFaLXzNfxhyTey7Ek2nc4POU3VBR-exO9iIC7LDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=P3bdEhekFJEPw1FtEXBdSIAQmmITpp81GcDOuOUT8FJO9iIC7LDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=T5et0jdpgzL4L76f5vUrNTgkqAFWt_ESO972OXu40jxO9iIC7LDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: RE: [dtn] Representation of Bundle Protocol

Scott
________________________________
From: dtn [[email-masked]<redir.aspx?REF=h5zc_nt8TWV9ugiYAGUUVdzrY25Cm3G8wvNFqBtCZVFO9iIC7LDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] on behalf of Burleigh, Scott C (312B) [[email-masked]<redir.aspx?REF=0NF-6zMZ9mjD6Sbop-P5FAiyibuB7EwmVcJGii86KA1O9iIC7LDTCAFtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y.>]
Sent: Wednesday, July 20, 2016 7:40 AM
To: [email-masked]<redir.aspx?REF=j6iJbS-oH3Nizo8qR2lL-1fHVYvpDyjLhdDmQJuwSvZO9iIC7LDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>; [email-masked]<redir.aspx?REF=Tcnix2-2U3UR25tFlSGY_5wRyQVoMsKv8r-P5sovOOFO9iIC7LDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; [email-masked]<redir.aspx?REF=81sx8GnO7hGTxM_hrpaeD7Tnb01Rcscpo6emRFrEeJBO9iIC7LDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>; [email-masked]<redir.aspx?REF=kojPfmfXFI_GwLtGY99rua30pxkQG6IPmRgbIx0IhTZO9iIC7LDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=FrNn7h4HU9Ikpc_-IhXqov-JVUL_fiE1J5TQTOKRdktO9iIC7LDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=8IiDXLwnc52diFaLXzNfxhyTey7Ek2nc4POU3VBR-exO9iIC7LDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=P3bdEhekFJEPw1FtEXBdSIAQmmITpp81GcDOuOUT8FJO9iIC7LDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=T5et0jdpgzL4L76f5vUrNTgkqAFWt_ESO972OXu40jxO9iIC7LDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: Re: [dtn] Representation of Bundle Protocol
Let's not go crazy.  I think the role of the BPA is actually quite precisely and comprehensively defined, both in RFC 5050 and in the bpbis spec; there's not a lot of rethinking needed.  We're not contemplating a radical new idea here; I see no need to blow everything up, start over again from scratch, renegotiate the BP specification, etc., etc. Let's see if we can finish these specifications before the end of the century.

Scott
________________________________
From: [email-masked]<redir.aspx?REF=j6iJbS-oH3Nizo8qR2lL-1fHVYvpDyjLhdDmQJuwSvZO9iIC7LDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..> [[email-masked]<redir.aspx?REF=j6iJbS-oH3Nizo8qR2lL-1fHVYvpDyjLhdDmQJuwSvZO9iIC7LDTCAFtYWlsdG86SmVyZW15Lk1heWVyQGRsci5kZQ..>]
Sent: Wednesday, July 20, 2016 3:20 AM
To: [email-masked]<redir.aspx?REF=Tcnix2-2U3UR25tFlSGY_5wRyQVoMsKv8r-P5sovOOFO9iIC7LDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>; Burleigh, Scott C (312B); [email-masked]<redir.aspx?REF=81sx8GnO7hGTxM_hrpaeD7Tnb01Rcscpo6emRFrEeJBO9iIC7LDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>; [email-masked]<redir.aspx?REF=kojPfmfXFI_GwLtGY99rua30pxkQG6IPmRgbIx0IhTZO9iIC7LDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; [email-masked]<redir.aspx?REF=FrNn7h4HU9Ikpc_-IhXqov-JVUL_fiE1J5TQTOKRdktO9iIC7LDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=8IiDXLwnc52diFaLXzNfxhyTey7Ek2nc4POU3VBR-exO9iIC7LDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=P3bdEhekFJEPw1FtEXBdSIAQmmITpp81GcDOuOUT8FJO9iIC7LDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=T5et0jdpgzL4L76f5vUrNTgkqAFWt_ESO972OXu40jxO9iIC7LDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: RE: [dtn] Representation of Bundle Protocol
+1.

•         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]<redir.aspx?REF=Tcnix2-2U3UR25tFlSGY_5wRyQVoMsKv8r-P5sovOOFO9iIC7LDTCAFtYWlsdG86RWR3YXJkLkJpcnJhbmVAamh1YXBsLmVkdQ..>]
Sent: Wednesday, July 20, 2016 11:57 AM
To: Burleigh, Scott C (312B); Rick Taylor; [email-masked]<redir.aspx?REF=kojPfmfXFI_GwLtGY99rua30pxkQG6IPmRgbIx0IhTZO9iIC7LDTCAFtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYQ..>; Mayer, Jeremy; [email-masked]<redir.aspx?REF=FrNn7h4HU9Ikpc_-IhXqov-JVUL_fiE1J5TQTOKRdktO9iIC7LDTCAFtYWlsdG86Y2hhcmxlcy5qLnNoZWVoZUBuYXNhLmdvdg..>; [email-masked]<redir.aspx?REF=8IiDXLwnc52diFaLXzNfxhyTey7Ek2nc4POU3VBR-exO9iIC7LDTCAFtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20.>
Cc: [email-masked]<redir.aspx?REF=P3bdEhekFJEPw1FtEXBdSIAQmmITpp81GcDOuOUT8FJO9iIC7LDTCAFtYWlsdG86ZHRuQGlldGYub3Jn>; [email-masked]<redir.aspx?REF=T5et0jdpgzL4L76f5vUrNTgkqAFWt_ESO972OXu40jxO9iIC7LDTCAFtYWlsdG86c2NoaWxkdEBpYnIuY3MudHUtYnMuZGU.>
Subject: RE: [dtn] Representation of Bundle Protocol

I concur.

-Ed

Scott
From: dtn [[email-masked]<redir.aspx?REF=h5zc_nt8TWV9ugiYAGUUVdzrY25Cm3G8wvNFqBtCZVFO9iIC7LDTCAFtYWlsdG86ZHRuLWJvdW5jZXNAaWV0Zi5vcmc.>] on behalf of Rick Taylor [[email-masked]<redir.aspx?REF=81sx8GnO7hGTxM_hrpaeD7Tnb01Rcscpo6emRFrEeJBO9iIC7LDTCAFtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29t>]

All,

Opinions please...

Rick

> Cc: [email-masked]<UrlBlockedError.aspx> <[email-masked]<UrlBlockedError.aspx>>, Sebastian Schildt <[email-masked]
<UrlBlockedError.aspx>> -bs.de<redir.aspx?REF=7TfEsg6LPiNPYI8K2YT6W_2Juui9IM8LkbLMkXPnSpBO9iIC7LDTCAFodHRwOi8vYnMuZGU.>>
> ibr.cs.tu-bs.de<redir.aspx?REF=FxTfwNilSWz316jJxZqk64OAfumULehJ1Xb5OsipZBJO9iIC7LDTCAFodHRwOi8vaWJyLmNzLnR1LWJzLmRl> <mailto:[email-masked]<UrlBlockedError.aspx>>
>
>                 wrote:
>
>                 Hello,
>

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 20 Jul 2016 22:49:00 +0000

Hi Sebastian,

From: dtn [mailto:[email-masked]] On Behalf Of Sebastian Schildt
Sent: woensdag 20 juli 2016 23:14
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Except that these would not be full bundles, but just the bundle payload and a number of parameters destined to go into fields of the Primary Block. Other fields of the Primary Block, e.g. the creation timestamp, would by necessity have to be filled in by the BPA itself.

Ronald

Sebastian

Am 20.07.2016 um 20:47 schrieb <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>:
Sorry if I was unclear, but I am not proposing redeveloping BP. I think that we’re in agreement, the transformation layer should act as an application, and should not require anything special from the BPA.

Thanks,
Jeremy

To: Mayer, Jeremy; [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]>

Scott
From: dtn [[email-masked]<mailto:[email-masked]>] on behalf of Burleigh, Scott C (312B) [[email-masked]<mailto:[email-masked]>]

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

Thanks,
jeremy

I concur.

-Ed

Scott
From: dtn [[email-masked]<mailto:[email-masked]>] on behalf of Rick Taylor [[email-masked]<mailto:[email-masked]>]

All,

Opinions please...

Rick

> Cc: [email-masked]<UrlBlockedError.aspx> <[email-masked]<UrlBlockedError.aspx>>, Sebastian Schildt <[email-masked]
<UrlBlockedError.aspx>> -bs.de<http://bs.de>>
> ibr.cs.tu-bs.de<http://ibr.cs.tu-bs.de> <mailto:[email-masked]<UrlBlockedError.aspx>>
>
>                 wrote:
>
>                 Hello,
>
_______________________________________________
dtn mailing list
[email-masked]<UrlBlockedError.aspx>
https://www.ietf.org/mailman/listinfo/dtn<UrlBlockedError.aspx>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Marius Feldmann <[email-masked]>
Date: Thu, 21 Jul 2016 13:42:35 +0200

Hi Scott,

> Marius, can you explain why you don't support a single CBOR encoding?  What encoding would you prefer, and why?  I definitely think we should be open to alternatives, but CBOR looks pretty good to…

Let me first answer the second question:
Well, in my opinion the canonical format should be as simple to
understand and to implement as possible. Thus, dependencies and
missunderstanding should be avoided.

I would love to see a very simple fixed-length variant of all fields
where it is possible. In the cases of the variable length fields
(specifically, EIDs), we have to determine which information they should
be able to represent and afterwards determine a very simple format -
e.g. UTF8 or ASCII encoded strings using a whitespace as delimiter or a
length prefix.

This variant would make the Bundle Protocol very easy to understand.
Furthermore, this approach offers a huge flexibility as a basis for
>alternative< representations such as maybe a CBOR representation.

Now the first question:
We are talking about a canonical representation. CBOR introduces
additional complexity in contrast to the approach sketched above. I have
the sound impression that CBOR has been selected because the overall
promise sounds nice, not because it has been really analyzed if it fits
our requirements. There seems to be only a minority who fully advocates
CBOR.
CBOR is a format intended to provide binary representations of JSON and
we use it in another context. This is not really a clean approach for a
canonical representation - it does not fit to my "as simple as possible"
perspective.
Furthermore, CBOR adds redundancy by providing the type information
encoded into the values (this information is already provided by the
standard) and partially even may stand in our way making the
representation of what we want to represent problematic (specifically,
how do you do a CRC calculation using a CRC field which is changing in
size?).

Marius

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 21 Jul 2016 16:50:06 +0000

Hi, Marius.  Thanks for this clarification.  Let me offer a counter-argument.

First, and fundamentally, I believe we have moved away altogether from supporting multiple alternative bundle encoding variants.  Instead, I think we have converged (at least in this conversation) on defining only a single valid encoding for bundles - i.e., the protocol data records sent and received by Bundle Protocol nodes - but any number of possible encodings for bundle transmission request and bundle reception notice messages (terminology still up for discussion).

These messages, which are *not bundles* as they contain only the bundle data items that are visible to applications, are exchanged between network-edge applications and entities that I will for the moment call "bundle service providers", which are Bundle Protocol applications that invoke the services of bundle protocol agents.  The messages sent and received by bundle service providers can be encoded in JSON, XML, whatever is convenient for the edge applications; certainly a variant that is simplified in exactly the way you describe would be fine.

Separately, the single, mandatory format of the bundles themselves is where CBOR seems to be a good fit.

I certainly agree that misunderstandings in the specification must be eliminated, but I think the CBOR specification itself is very clear and I believe the CBOR bundle representation document is also clear and unambiguous; if there are items that you think can be misunderstood because of their CBOR representation, I would be very glad to know about them.

CBOR is not quite as easy to understand and implement as a format based on fixed-length integers and null-terminated strings would be, but I don't think that is a strong argument against it.  Certainly we could optimize the BP design for minimal coding effort, but development of bundle protocol agents incurs mostly non-recurring costs; optimizing instead for performance reduces the recurring costs of operating all bundle protocol nodes far into the future.

More to the point, for some kinds of deployment scenarios - I'm thinking specifically of space flight missions - data formats that consume a lot of unnecessary bandwidth would likely disqualify the protocol from consideration at all.  Fixed-length fields are especially problematic.  If you define fields sizes that are too small you risk limiting the range of applications for which the protocol can be used and/or you risk being unable to accommodate future growth.  But if you define large field sizes that eliminate these risks you waste bytes every time you transmit a bundle.  Whitespace-delimiting is simple but it wastes processing cycles every time a value must be copied or compared.  Length prefixes are great; they're exactly what CBOR is based on.

Does this address your concerns, or do we still disagree?

Scott

________________________________________
From: dtn [[email-masked]] on behalf of Marius Feldmann [[email-masked]]
Sent: Thursday, July 21, 2016 4:42 AM
To: [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Hi Scott,

Now the first question:

Marius

---

From: Gilbert Clark <[email-masked]>
Date: Thu, 21 Jul 2016 20:01:46 -0400

Quick comment inline:

Fixed-length fields are especially problematic.  If you define fields sizes
> that are too small you risk limiting the range of applications for which
> the protocol can be used and/or you risk being unable to accommodate future
> growth.  But if you define large field sizes that eliminate these risks you
> waste bytes every time you transmit a bundle.  Whitespace-delimiting is
> simple but it wastes processing cycles every time a value must be copied or
> compared.  Length prefixes are great; they're exactly what CBOR is based on.
>

Length prefixes are, on the computation side, more expensive than fixed
length fields.  Variable length elements require scanning fields of the
packet prior to the desired elements, whereas fixed-length elements allow
for a direct index to a certain point in a packet.  The difference in
relative expense will become more significant as more of the header must be
examined to find the desired field.  Also, mispredicted branches when
parsing (or cases where no prediction is supported) can also incur
significant computational expense (e.g. as could be encountered when
switching off of a CBOR type) when compared to an extraction used to read a
field that is of a known type.  There are also other considerations (e.g.
data / instruction cache efficiency) which could either work either for or
against CBOR.  Of course, the encoding overhead of the bundle could also
turn out to be insignificant when compared to the overhead of whatever
convergence layer is used, or when compared to the logic necessary to make
routing / security / other decisions within the BPA itself, or ... etc.

tl;dr - I think it's really kind of hard to say anything conclusive about
performance at all without first actually profiling / testing the thing
that needs to be optimized :)

-Gilbert

> > Marius, can you explain why you don't support a single CBOR encoding?
> What encoding would you prefer, and why?  I definitely think we should be
> open to alternatives, but CBOR looks pretty good to me.
>

---

From: Rick Taylor <[email-masked]>
Date: Fri, 22 Jul 2016 08:46:33 +0000

I can see your point Gilbert: from a BP requirements perspective, there
are features in CBOR that we just do not need.

So, if we were to develop a bespoke encoding for BP we would need at
least the following properties:

* Ability to specify whether an optional field is present
* Ability to specify the multiplicity of a multi-value field
* Ability to compress large numbers efficiently

Now, CBOR already supplies these properties with a rough cost of 4
bits, and although CBOR provides a lot more capability that we don't
need, I worry that we could burn a lot of cycles developing a protocol
that would perhaps save us 1 or 2 bits per field - and I just don't
think that is a good use of the WG's time.

What CBOR does give us for free:

* A reasonable level of maturity - a lot of eyes have already looked at
it and implemented the tools.
* The IETF has already looked at the security/privacy use-cases.  These
usecases may not be entirely relevant to us, but the WG will need to
prove to the IESG that such concerns have been considered at the
protocol/encoding layer, which is a non-trivial task.

I think the selection of CBOR as the core encoding for BP is a
pragmatic one: it's not a perfect match, but it's a good fit that is
available now.

Regards,

Rick

(Speaking personally not as a chair)

On Thu, 2016-07-21 at 20:01 -0400, Gilbert Clark wrote:
> Quick comment inline:
>
>
> > Fixed-length fields are especially problematic.  If you define
> > fields sizes that are too small you risk limiting the range of
> > applications for which the protocol can be used and/or you risk
> > being unable to accommodate future growth.  But if you define large
> > field sizes that eliminate these risks you waste bytes every time
> > you transmit a bundle.  Whitespace-delimiting is simple but it
> > wastes processing cycles every time a value must be copied or
> Length prefixes are, on the computation side, more expensive than
> fixed length fields.  Variable length elements require scanning
> fields of the packet prior to the desired elements, whereas fixed-
> length elements allow for a direct index to a certain point in a
> packet.  The difference in relative expense will become more
> significant as more of the header must be examined to find the
> desired field.  Also, mispredicted branches when parsing (or cases
> where no prediction is supported) can also incur significant
> computational expense (e.g. as could be encountered when switching
> off of a CBOR type) when compared to an extraction used to read a
> field that is of a known type.  There are also other considerations
> (e.g. data / instruction cache efficiency) which could either work
> either for or against CBOR.  Of course, the encoding overhead of the
> bundle could also turn out to be insignificant when compared to the
> overhead of whatever convergence layer is used, or when compared to
> the logic necessary to make routing / security / other decisions
> within the BPA itself, or ... etc.
>
> tl;dr - I think it's really kind of hard to say anything conclusive
> about performance at all without first actually profiling / testing
> the thing that needs to be optimized :)
>
> -Gilbert
>
> > > Marius, can you explain why you don't support a single CBOR
> > encoding?  What encoding would you prefer, and why?  I definitely
> > think we should be open to alternatives, but CBOR looks pretty good
> > to me.
> >
> > >>> 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.
> > >>>
> > I-D
> > >>>> From: Sheehe, Charles J. (GRC-LCA0) <[email-masked]
> > >

---

From: Marius Feldmann <[email-masked]>
Date: Fri, 22 Jul 2016 15:54:59 +0200

Hi Scott,

thank you for the additional discussion. I get the point to have a
compact representation.

Nevertheless, this could also be achieved by defining a compression
mechanism for the canonical representation e.g. in a further RFC.

But lets go back to CBOR:

1. As I have stated, CBOR is redundant: It contains the type information
directly encoded into the representation (so, it also addresses the T
part of TLV). Is this really necessary for a standardized protocol? The
information type is defined by the standard so I do not get the reason
to select a format that puts this information additionally into the
transmitted data.

2. Furthermore, as I have mentioned, I do not understand, how the CRC
calculation is done if a CRC field of variable length is present in the
Bundle Protocol header as it is the case if CBOR is used. To quote from
the bpbis draft: "The CRC SHALL be computed over the concatenation of
all bytes of the primary block including the CRC field itself, which for
this purpose is temporarily populated with the value zero." - if the CRC
field is included into the CRC calculation and is of variable length:
Could you explain, how the CRC calculation is done?

Marius

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 22 Jul 2016 11:34:51 -0400

Hi Rick:

I didn't intend to imply that I'm opposed to CBOR: I only intended to imply
that performance considerations as never as straightforward as they may
seem, and that therefore using performance as a rationale either for or
against CBOR strikes me as odd.

To me, the actual encoding selected seems to be a bit of a wash: I'm
actually not certain the additional overhead incurred by CBOR is terribly
relevant, if only because BP is only ever as efficient as the convergence
layer it runs on top of.  That's not to say that link efficiency shouldn't
at all be considered at the BP level, only that such considerations should
be taken with a grain of salt: those 5 bits we save at the BP level lose
their relevancy when the convergence layer upon which BP is running isn't
designed with similar considerations in mind (read: IPv6).  Yes, CBOR could
turn out to add significant processing overhead to bundles ... or, when
considered in conjunction with the convergence layers BP is running on top
of, it also might not.  In the end, I also doubt that we care: if CBOR is
too much overhead, there's always the option to use a different encoding
internally and only speak CBOR at the edges of the network.  If, on the
other hand, our convergence layer generates too much overhead, we can do
the same with that as well.

Now, with that said, I *do* wonder why the bundle protocol headers need to
be *complex enough* to warrant the use CBOR (or, in CBOR's absence, a
relatively complex encoding specified by the WG) in the first place ... but
that, I think, is a completely different conversation :)

Cheers,
Gilbert

On Fri, Jul 22, 2016 at 4:46 AM, Rick Taylor <[email-masked]

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 23 Jul 2016 21:14:11 +0000

Hi, Marius.  You're right, CBOR does include "major type" encoding in the first 3 bits of the octet that - in the case of an unsigned integer - states the length of the value, and this is information we don't really need to provide.  On the other hand, if we are going to be sending variable-length integers (to reconcile our need for compact representation with our need for flexibility, to accommodate future growth and a wide range of deployment environments) then we are probably going to be encoding that length in an octet anyway, in which case we have already bought those bits.  They don't cost anything, so the fact that they are redundant doesn't seem to matter very much, at least to me.

And while it is true that an implementation that presented a CRC-16 in a CBOR unsigned integer of, say, 64 bits would be CBOR-compliant, in my view it would not be BP-compliant.  That's because section 4.5.2 says "the length and nature of the CRC SHALL be as indicated by the CRC type"; to me, that means that if the CRC type in the block says "CRC-16" then the length of the CRC must be 16 bits.  The CRC is really not of variable length; it's just represented in an encoding that does not in itself restrict the length of the CRC - only the protocol specification does that.

Now, you might very well argue that this makes the entire first octet of the CBOR representation of the CRC unnecessary, and I would have to agree.  It might be more efficient to discard the CRC type altogether and instead simply infer the CRC type from the first byte of the CRC field (in CBOR representation): if the value of the "additional information" (last 5 bits) of that byte is 25 then the CRC is a CRC-16, if 26 then a CRC-32, and if zero then the CRC value is omitted.

This is the sort of optimization that we could not do when we were limiting ourselves to abstract data items in bpbis but that is now possible if we are going to define representation in the protocol specification.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Friday, July 22, 2016 6:55 AM
To: [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

Hi Scott,

thank you for the additional discussion. I get the point to have a compact representation.

Nevertheless, this could also be achieved by defining a compression mechanism for the canonical representation e.g. in a further RFC.

1. As I have stated, CBOR is redundant: It contains the type information directly encoded into the representation (so, it also addresses the T part of TLV). Is this really necessary for a standardized protocol? The information type is defined by the standard so I do not get the reason to select a format that puts this information additionally into the transmitted data.

2. Furthermore, as I have mentioned, I do not understand, how the CRC calculation is done if a CRC field of variable length is present in the Bundle Protocol header as it is the case if CBOR is used. To quote from the bpbis draft: "The CRC SHALL be computed over the concatenation of all bytes of the primary block including the CRC field itself, which for this purpose is temporarily populated with the value zero." - if the CRC field is included into the CRC calculation and is of variable length:
Could you explain, how the CRC calculation is done?

Marius

On 21.07.2016 18:50, Burleigh, Scott C (312B) wrote:
> (specifically, EIDs), we have to determine which information they 
> should be able to represent and afterwards determine a very simple 
> format - e.g. UTF8 or ASCII encoded strings using a whitespace as 
> delimiter or a length prefix.
>
> additional complexity in contrast to the approach sketched above. I 
> have the sound impression that CBOR has been selected because the 
> overall promise sounds nice, not because it has been really analyzed 
> if it fits our requirements. There seems to be only a minority who 
> fully advocates CBOR.
> CBOR is a format intended to provide binary representations of JSON 
> and we use it in another context. This is not really a clean approach 
> for a canonical representation - it does not fit to my "as simple as possible"
> perspective.
>>>> think that we're in agreement, the transformation layer should act 
>>>> [mailto:[email-masked]]
>>>> Ed, you're right. Not only does the role (or functional overview) 
>>>> (sorry Rick). It may just be me, but I can't see any large 
>>>> *         The BPA MUST provide send/receive functionality to local
>>>> *         A transformation layer MUST NOT change the content of the
>>>> *         A transformation layer MUST NOT provide routing
>>>> 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'
>>>> 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
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>> Edward J.
>>>>> 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.
>>>>>
>>>>> both their own encoding document and address the considerations 
>>>>> and requirements of an alternate encoding.
>>>>>
>>>>>  -Ed
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Cc: [email-masked] <[email-masked]>, Sebastian Schildt 
>>>>> <[email-masked] -bs.de>
>>>>> resource constrained devices.
>>>>>
>>>>> Feynman What you do makes a difference and you have to decide what 
>>>>> kind of difference you want to make.
>>>>>
>>>>>
>>>>>
>>>>>         On Tue, Jul 19, 2016 at 11:14 AM, Sebastian Schildt 
>>>>> <schildt@ ibr.cs.tu-bs.de <mailto:[email-masked]>
>>>>>
>>>>>                 wrote:
>>>>>
>>>>>                 Hello,
>>>>>
>>>>> effcient coding possible as to
>>>>> super- verboe JSON or XML here
>>>>> there is nor "primary"
>>>>> well designed, which will
>>>>>                 help all encodings.
>>>>>
>>>>> 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
>>>>>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 23 Jul 2016 22:15:04 +0000

I agree with Rick on this.

Optimizing for any single property will always be highly advantageous for some user/developer community and highly disadvantageous for others.  I think that would be a mistake.  This was the original motivation for supporting multiple native bundle representations, but postings on this list have made a persuasive case for not doing that.

The alternative we are now looking at is to support only a single native bundle representation that combines relatively efficient bandwidth utilization (compact binary representation), relatively low demand for processor cycles (binary representation with explicit length markings), easy accommodation of future growth and a wide range of deployment environments (variable-length values), and - ideally - pre-existing infrastructure in the Internet (i.e., not the SDNV-based representation documented in RFC 5050).

Separately, the requirement for easy integration into Web-based ecosystems is met by the concept of exchanging bundle transmission parameters in application-layer messages between end-user applications and bundle service providers.

Clearly this sort of architecture is sub-optimal in different ways for all user/developer communities, but I think it can be made tolerable for all of them and I think that is what we are after.

Scott

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Friday, July 22, 2016 1:47 AM
To: [email-masked]; Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] Representation of Bundle Protocol

I can see your point Gilbert: from a BP requirements perspective, there are features in CBOR that we just do not need.

So, if we were to develop a bespoke encoding for BP we would need at least the following properties:

Now, CBOR already supplies these properties with a rough cost of 4 bits, and although CBOR provides a lot more capability that we don't need, I worry that we could burn a lot of cycles developing a protocol that would perhaps save us 1 or 2 bits per field - and I just don't think that is a good use of the WG's time.

* A reasonable level of maturity - a lot of eyes have already looked at it and implemented the tools.
* The IETF has already looked at the security/privacy use-cases.  These usecases may not be entirely relevant to us, but the WG will need to prove to the IESG that such concerns have been considered at the protocol/encoding layer, which is a non-trivial task.

I think the selection of CBOR as the core encoding for BP is a pragmatic one: it's not a perfect match, but it's a good fit that is available now.

Regards,

Rick

On Thu, 2016-07-21 at 20:01 -0400, Gilbert Clark wrote:
> fixed length fields.  Variable length elements require scanning fields 
> of the packet prior to the desired elements, whereas fixed- length 
> elements allow for a direct index to a certain point in a packet.  The 
> difference in relative expense will become more significant as more of 
> the header must be examined to find the desired field.  Also, 
> mispredicted branches when parsing (or cases where no prediction is 
> supported) can also incur significant computational expense (e.g. as 
> could be encountered when switching off of a CBOR type) when compared 
> to an extraction used to read a field that is of a known type.  There 
> are also other considerations (e.g. data / instruction cache 
> efficiency) which could either work either for or against CBOR.  Of 
> course, the encoding overhead of the bundle could also turn out to be 
> insignificant when compared to the overhead of whatever convergence 
> layer is used, or when compared to the logic necessary to make routing 
> / security / other decisions within the BPA itself, or ... etc.
>
> > -
> > e.g. UTF8 or ASCII encoded strings using a whitespace as delimiter 
> > or a length prefix.
> >
> > have
> > and
> > idea,
> > anyone
> > <schildt@

---

From: Brian Sipos <[email-masked]>
Date: Mon, 25 Jul 2016 19:09:14 +0000

For what it is worth, I have been doing some experimenting with the BPbis/CBOR draft and COTS CBOR libraries (C, C++, and Python). The one major thing that I got out of this is that for the most part the COTS libraries do not provide field-level control over the contents of CBOR initial byte or encoded-octets. This may be fine for the decoder, but it poses issues when attempting to adhere to anything except the "major type" specified in the BPbis/CBOR draft.

For arrays this means that BPbis may specify a preference for definite/indefinite canonical forms, but if using a COTS encoder then the output will likely always be the definite form. This also goes for byte-strings and text-strings.

For numeric values, a COTS encoder will typically compress the encoding as much as possible. This means that the original "bit size" of the value is lost by the encoder. For this reason, sing the "bit size" of a CBOR integer to determine whether CRC-16, CRC-32, etc. is being used is a bad path to go down.

My short take-away is that I think "Postel's law" applies in this situation, so that BPbis should really only enforce the CBOR major type while the specific encoding must be left to the implementation. This puts extra effort on the decoder implementation, but no more effort than is required by CBOR itself. This also allows use of existing COTS software libraries. Certainly, BPbis can enforce things beyond the encoded value, such as "... array SHALL be exactly 7 elements long." rather than enforcing "... array shall have add'l info value 7".

---

From: Rick Taylor <[email-masked]>
Date: Tue, 26 Jul 2016 08:53:54 +0000

Brian, All,

+1.  

I agree with Brian on this.  I must admit that on my first reading of
the BPbis/CBOR draft I did think it was over specified in terms of the
minor-type and tag requirements.  I know our in-house CBOR library only
allows the user to specify the major types, and uses heuristics to
compress efficiently, and I imagine that applies to most others as
well.

I was doing some reading on the way home from Berlin on what other
consumers of CBOR do to specify their schemas in drafts, and I believe
COSE demonstrates a quite elegant way forward: They refer to a draft
going through the Apps Area working group called the 'CBOR Data
Definition Language' (https://tools.ietf.org/html/draft-greevenbosch-ap
psawg-cbor-cddl-08) that provides a simple DDL for specifying how to
encode messages in CBOR.

Brian, or anyone else, would you like to join me in trying to knock-up
an informal BPbis block definition in CDDL?  I don't think it needs to
be a draft in it's own right, but it might prove useful for the
BPbis/CBOR work.

Comments?

Rick

On Mon, 2016-07-25 at 19:09 +0000, Brian Sipos wrote:
> For what it is worth, I have been doing some experimenting with the
> BPbis/CBOR draft and COTS CBOR libraries (C, C++, and Python). The
> one major thing that I got out of this is that for the most part the
> COTS libraries do not provide field-level control over the contents
> of CBOR initial byte or encoded-octets. This may be fine for the
> decoder, but it poses issues when attempting to adhere to anything
> except the "major type" specified in the BPbis/CBOR draft.
> 
> For arrays this means that BPbis may specify a preference for
> definite/indefinite canonical forms, but if using a COTS encoder then
> the output will likely always be the definite form. This also goes
> for byte-strings and text-strings.
> For numeric values, a COTS encoder will typically compress the
> encoding as much as possible. This means that the original "bit size"
> of the value is lost by the encoder. For this reason, sing the "bit
> size" of a CBOR integer to determine whether CRC-16, CRC-32, etc. is
> being used is a bad path to go down.
> 
> My short take-away is that I think "Postel's law" applies in this
> situation, so that BPbis should really only enforce the CBOR major
> type while the specific encoding must be left to the implementation.
> This puts extra effort on the decoder implementation, but no more
> effort than is required by CBOR itself. This also allows use of
> existing COTS software libraries. Certainly, BPbis can enforce things
> beyond the encoded value, such as "... array SHALL be exactly 7
> elements long." rather than enforcing "... array shall have add'l
> info value 7".

---

From: Brian Sipos <[email-masked]>
Date: Tue, 26 Jul 2016 12:43:13 +0000

Rick,

I would be willing to give it a try, but I've had bad experience with similar "JSON schema" (as an I-D which never had good uptake and fizzled-out).

Because BP is so relatively static (bundles shrink and grow by blocks, rather than individual fields) I really don't see any problem with each field specifying a major type (if possible) as is already done, and some detailed text explaining what contents are valid, canonical, etc. (which is also already there for the most part). BP doesn't allow much variation in types, so I expect that there would be no use for the more complex choice, optional, etc. definitions.

Regardless of how specified, the two concrete things that I would avoid are:

1. Don't specify specific encoding of arrays, byte-strings, or text-strings. Just specify required element-count, string-length (min/max), etc.

2. Don't use integer fields to encode fixed-size values. I'm looking specifically at "Bundle Processing Control Flags" and the CRCs. If it should be exactly 16 bits, then I think it should use a byte-string with required size 2-bytes. This is less important for flags (as the size doesn't affect the semantics) but is important for the CRC because a "zero value" placeholder CRC must have a specific encoded size (as Gilbert C. mentioned earlier).

________________________________
From: Rick Taylor <[email-masked]>
Sent: Tuesday, July 26, 2016 4:53:54 AM
To: [email-masked]; Brian Sipos
Subject: Re: [dtn] Representation of Bundle Protocol

Brian, All,

+1.

Comments?

Rick

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Jul 2016 19:30:43 +0200

Attached please find a CDDL representation that I wrote in March to understand (and replace) a bit more than half the English text in draft-burleigh-dtn-rs-cbor-00 (I can understand CDDL much faster and much more accurately than English text).  I haven’t had much time to follow the draft since, but could continue this work if there is interest.

By the way, CDDL is not a “schema language” (even though it can be used as one): its purpose is to solve the same problem that ABNF solved for text-based protocols.  Since CDDL is already being used in a number of IETF protocol efforts, I would say the chances are quite good that it does not “fizzle out”…

Grüße, Carsten

On 26 July 2016 at 10:56:39, Rick Taylor ([email-masked]) wrote:

Brian, All,  

+1.    

Comments?  

Rick