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

From: Rick Taylor <[email-masked]>
Date: Wed, 19 Aug 2015 14:00:36 +0000

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 15:38:08 +0100

(...good thread summary elided...)

> 1) YANG seems like a good candidate to describe the semantics of bundles 

Yep, that's the information model thing de-jure all right.
I'd not object but would also be fine with this being
done without a formal model. (There are a few folks at the
moment helping various IETF WGs with yang models, so if
this WG took that approach we could ask for that.)

> have to be defined separately for each suggested encoding.

I think there's a few reasonable ways in which this could
be done. I figure if we got consensus on "JSON or CBOR"
that'd be enough for this now and the next level of detail
down could emerge as folks look in more detail.

> much of an embedded developer to point to the best choice.

I'm not fussed about that, but sure that seems reasonable.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2015 16:52:56 +0200

Rick Taylor wrote:
> 1) YANG seems like a good candidate to describe the semantics of bundles 

Sure, everything in the IETF is based on YANG now, right?

YANG has been designed to model data at rest, in a management
information base, as manipulated by the NETCONF protocol.  (That
modeling is somewhat tied to XML, but that is a separate issue.)

YANG is not that great as a language for specifying the data content of
messages.

Grüße, Carsten

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 19:38:19 +0000

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

First some assumptions:

Rick

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