Subject: Re: [dtn] JSON + YANG + CBOR? (was CBAR?)

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 19 Aug 2015 19:54:42 +0000

RFC5050 bundling is basically a split of CCSDS CFDP monolithic
application/transport/store and forward into File transfer, Bundling
(RFC5050) and Transport (Licklider) with the hope of automating some of
the routing.  For space, that automation is contract graph routing. (I
seem to remember Scott actually giving the presentation years ago -
perhaps in Chicago or San Diego.) It was not a clean slate start -
unfortunately.

The requirement for things like custody transfer and mixing some of the
network management (report to and the like) with the store and forward
base are, IMHO, remnants of CCSDS CFDP and requirements, desires of the
space community.

Will 

On 8/19/15 3:38 PM, "dtn on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>> with 5050bis, but as someone who has come late to the party, I struggle
>> at times with 5050 being *THE* DTN specification (I understand that
>> there are applicability documents, etc, but 5050 is the king)
>
>some of us early to the party (I was secretary of the ISOC interplanetary
>internet group in, what, 2000?) have exactly the same problem.
>
>DTN is the scenario. bundling is a point-solution approach to that
>scenario, and not a good one.
>
>Lloyd Wood
>http://sat-net.com/L.Wood/dtn
>
>the struggle is real.
>________________________________________
>From: dtn <[email-masked]> on behalf of Rick Taylor
><[email-masked]>
>Sent: Thursday, 20 August 2015 12:00:36 AM
>To: [email-masked]
>Subject: [dtn] JSON + YANG + CBOR? (was CBAR?)
>
>All,
>
>Having waded through the CBOR/JSON threads I want to pick out a few
>themes I have spotted.
>
>First some assumptions:
>
>1) The DTN Bundle protocol deals in blocks with known immutable content,
>blocks with mutable extensible content and protocol-independent payload
>(possibly binary).
>
>2) Convergence Layers (CLs) have different data format requirements
>depending on the kind of links they are using.
>
>3) If it is required, a 'user' protocol between applications and a local
>bundle processing agent (BPA) should be 'modern', i.e. familiar to the
>web generation, and the BPA or CLs should do the conversion to a
>suitable format.
>
>Now, CBOR has been floated by Scott B as a suggested replacement to
>SDNVs in RFC5050bis.  The thread has wandered off into a discussion of
>the merits of JSON as a data format, with some contradictory opinions of
>where and when it is suitable.
>
>Scott and the team have done great work producing 5050 and continuing
>with 5050bis, but as someone who has come late to the party, I struggle
>at times with 5050 being *THE* DTN specification (I understand that
>there are applicability documents, etc, but 5050 is the king)
>
>In 5050 the authors describe bundle format, bundle processing, data
>compression, forwarding considerations, CL responsibilities, and many
>other useful things, but there is a lot of bleed-across between areas:
>SDNVs (a compression method suitable for some links) are used in the
>definition of what fields must be in a bundle block, where the field
>definitions themselves are important to define the processing behaviour,
>not the encoding.
>
>My proposal is to split the focus of the CBAR? (sic) thread into 3
>strands:
>
>1) What is a suitable data definition language to use to define the
>structure and fields required by the bundle protocol, irrespective of
>encoding?
>
>2) What are suitable encodings for the transport of bundles, without
>loss of semantics, by a CL over links of certain characteristics.  Can a
>single protocol be defined in a higher-level form that can be directly
>translated to compressed encoding?
>
>3) Should the DTN-WG produce a specification for a 'client' protocol for
>use on the LAN between an application and a BPA, in the same way IMAP
>and SMTP co-exist?
>
>Because I can't ask questions without giving my own opinion:
>
>1) YANG seems like a good candidate to describe the semantics of bundles
>and blocks.
>
>2) CLs are all different, but this is where CBOR would fit, as well as
>SDNV, but sometimes JSON+GZIP is enough.  The inter-BPA protocol may
>have to be defined separately for each suggested encoding.
>
>3) My gut says something REST/JSON/Web2.0 is the way to go, but I'm too
>much of an embedded developer to point to the best choice.
>
>Thanks for reading this far,
>
>Rick
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn