Subject: [dtn] DTN BoF Proposal for IETF90

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Jun 2014 22:09:41 +0000

Hello,

Based on discussions on the DTNRG list, here is a revised draft charter
per the suggestions raised (see also attached diffs).

Please respond to this thread for further BoF discussion.

Thanks - Fred
[email-masked]

---

Draft BoF Agenda (2.5hrs):
**************************
1) Problem statement (IETF wg motivation) - 30min

2) RFC5050(bis) - 30min

3) Streamlined Bundle Security Protocol (SBSP) - 30min

4) Bundle-in-Bundle Encapsulation - 15min

5) Security Key Management - 15min

6) Registry for Service Identifiers - 15min

7) Network Management - 15min

Proposed working group charter:
*******************************
Working group name: 

      Delay/Disruption Tolerant Networking Working Group (DTNWG)

Chair(s):

      TBD

Area and Area Director(s):

      Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
                          Martin Stiemerling <mls.ietf at gmail.com>

Responsible Area Director:

      TBD

Mailing list:

      General Discussion: dtn at ietf.org
      To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
      Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html

Description of Working Group:

      The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
      mechanisms for data communications in the presence of long delays
      and/or intermittent connectivity. The work is motivated by well known
      limitations of standard Internet protocols that expect end-to-end
      connectivity between communicating endpoints, sub-second transmission
      delays and robust packet delivery ratios. In environments where these
      favorable conditions do not apply, existing mechanisms such as reliable
      transport protocols and routing protocols can fail to converge resulting
      in communication failures. Furthermore, classical end-to-end security
      associations cannot be coordinated when communicating endpoints cannot
      conduct multi-message keying exchanges in a timely fashion. These
      limitations suggest the need for a new approach. 
      
      Delay-Tolerant Networking (DTN) protocols have been the subject of
      extensive research and development in the Delay-Tolerant Networking
      Research Group of the Internet Research Task Force since 2002.  In
      particular, the DTN Bundle Protocol (RFC 5050) and Licklider
      Transmission Protocol (RFC 5326) have been shown to address the
      issues identified above.  In 2008, BP/LTP was deployed on the EPOXI
      spacecraft in deep space and was used to conduct reliable, automated
      communication for four weeks over a network of 10 nodes in which the
      bottleneck router in the network (the spacecraft) was up to 100 light
      seconds from all other nodes and connectivity with the router was
      subject to periods of disconnection lasting several days.

      The success of the BP/LTP protocol stack -- the core protocols of the
      "DTN Architecture" originally described in RFC 4838 -- in this
      demonstration may be attributed to the following fundamental design
      principles:

	- There is never any expectation of contemporaneous end-to-end
       connectivity between any two network nodes.  Where such connectivity
       is sustained, the protocols leverage it to optimize performance,
       but the possibility of transient but sustained disconnection at
       any time, anywhere in the network, is always recognized.

	- Because end-to-end connectivity can never be assumed, each node
	  on the path between source and destination must be prepared to
	  handle incoming "bundles" of data that cannot immediately be
	  forwarded.  Such bundles must either be stored for future trans-
	  mission or discarded; in the latter case, the network must
	  be informed of this data loss so that an alternative path may
	  be selected, to avoid impairing the usability of the network.

	- Again because end-to-end connectivity can never be assumed,
	  end-to-end conversational data exchange can never be assumed to
	  complete in a timely manner; protocol features that rely on
	  timely conversational data exchange must be excluded from the
	  architecture.  This principle makes the DTN architecture
	  suitable not only for network environments characterized by
	  lengthy disconnection but also for those that are characterized
	  by long signal propagation delays (such as underwater communication
	  by acoustic signals or, worse, interplanetary communication) even
	  when connectivity is continuous.

      The DTNWG believes that protocols adhering to these principles offer
      opportunities for enhancing the functionality of the Internet - in
      particular, for facilitating the extension of the Internet into
      environments such as the ocean floor and deep space in which the core
      Internet protocols operate sub-optimally for the reasons discussed
      earlier.  We believe that the extensive research, demonstration, and
      pilot operations performed to date using the DTNRG protocols, both
      before and after the EPOXI experiment, provides a firm basis for
      publishing Internet standards derived from that work.

      Work items related to Delay/Disruption Tolerant Networking include:

      o A mechanism for the exchange of protocol data units, termed
	"bundles", that are designed to obviate conversational communications
	by containing values for all potentially relevant configuration
	parameters.  These protocol data units are typically larger than
	network-layer packets.  We expect to derive this bundle exchange
	mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050.
        Expected changes from RFC 5050 include (but are not necessarily
        limited to):

           - a compressed bundle header encoding (derived from RFC6260)
           - an immutable primary block structure
           - simplified EID representations (no dictionary)
           - add block ID to extension blocks (e.g. security blocks)
           - move custodian to extension block
           - add simple header and payload integrity checks
           - add simple contact graph routing specification
           - add simple neighbor discovery specification 

      o A security protocol for ensuring that the network in which bundles
	are exchanged is secured against unauthorized access and denial of
	service attacks, and to ensure data integrity and confidentiality
	in that network where necessary.  We expect to derive this security
	protocol from a "streamlined" adaptation of the DTN Bundle Security
	Protocol documented in RFC 6257.

      o An encapsulation protocol for "tunneling" BP traffic within bundles
	that are secured and/or routed in different way from the encapsulated
	bundles.

      o A delay-tolerant security key management scheme for ensuring that
	public keys are certified by a globally trusted authority to protect
	the integrity of the infrastructure.

      o A simple datagram convergence layer protocol for adaptation of the
        bundle protocol to underlying internetworks. We expect to derive
        this convergence layer protocol from the Datagram Convergence
        protocol documented in RFC7122.

      o A delay-tolerant network management protocol for management of the
        infrastructure in the presence of long delays and/or intermittent
        connectivity.

      o A registry for DTN Service Identifiers
  
    The working group will consider extending the current milestones based on
    new information and knowledge gained while working on the initial charter,
    as well as to accommodate new work items beyond the scope of the initial
    phase.  For example, we expect that transport protocols uniquely suited
    to the various communication environments that may need to be traversed
    by a single DTN end-to-end path (operating under BP, at what is termed
    the DTN "convergence layer") will need to be standardized in a second
    phase of the working group's charter; LTP and the Saratoga protocol are
    among the candidates for work in this phase.  These adjustments will be
    accommodated in a working group recharter, assuming the initial
    chartered activities meet their delivery milestones. Possible new work
    items must then still fit into the (rechartered) DTNWG charter scope.
    
Goals and Milestones:
  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
                      working group document. To be Proposed Standard.
  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
                       working group document. To be Proposed Standard.
  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
                      group document. To be Proposed Standard.
  start+9mos - Submit 'Delay Tolerant Networking Security Key Management' as
                      a working group document. To be Proposed Standard.
  start+9mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
               Key Mgmt into a combined draft or keep as separate drafts.
  start+12mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
                as a combined draft or as separate drafts.
  start+12mos - Submit Network Management, Registry and Simple Convergence
                Layer as working group documents.
  start+15mos - Survey appropriate forums (e.g., DTNRG) for emerging
                technologies (e.g., convergence layer protocols, dynamic
                routing protocols, naming and addressing services, etc.)
                ready for transition into IETF DTN Working Group. Publish
                draft on survey results as independent submission related
                to the WG.
  start+18mos - Submit Network Management, Registry and Simple Convergence
                Layer to IESG
  start+18mos - Recharter to accommodate new work items or close Working Group

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 5 Jun 2014 07:32:50 +0000

Hi,

> Draft BoF Agenda (2.5hrs):

that adds up to 2.5h - when were you planning to have charter discussions, etc.? Suggest to focus on 1, and then summarize the suggested work items 2-7 in much less time, leaving an hour at least for discussion.

>      limitations suggest the need for a new approach. 

OK so far.

>      subject to periods of disconnection lasting several days.

At lest the second half of the paragraph above can be eliminated from the charter text. You could even cut the whole thing.

>      publishing Internet standards derived from that work.

You could significantly shorten the body of text above, incl. the bullet list, by simply pointing at some relevant DTNRG RFCs and say that you want to build on what was done before and not go off to reinvent everything.

> 	mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050.

Why "expect to"? It would be good to have agreement whether or not 5050 is the baseline here.

>           - add simple neighbor discovery specification 

List is OK for discussion, but doesn't need to be in the charter.

> 	Protocol documented in RFC 6257.

Again, why "expect to"?

>        infrastructure in the presence of long delays and/or intermittent

For all of those bullets above, are there starting points, or will these be completely new protocol developments? (if the latter, you are setting yourself up for a LOT of work.)

>    items must then still fit into the (rechartered) DTNWG charter scope.

Paragraph can be cut. Charters can change, everyone knows that.

> Goals and Milestones:

Based on the current speed of the CTNRG, all these milestone deltas from start are hugely optimistic. I'd suggest to multiply by a factor of 2-3x.

>  start+18mos - Recharter to accommodate new work items or close Working Group

Lars

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 11:20:20 +0000

As previously expressed on DTNRG, I have a number of concerns about
this proposed BOF to create an IETF DTN WG to do work on the
RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
an RFC5050bis. I'll go through those concerns one by one:

1. I don't see how going standards track can be justified, because:

   a. CCSDS is already working on the bundle protocol as one of their
      blue book standards, based on RFC5050, and any RFC5050bis
      would presumably also be adopted and then modified to make
      a CCSDS standard.
      It's rather like CCSDS restandardizing TCP/IP as SCPS, back
      in the 1990s. That SCPS standardization wasn't used much
      either, not least because CCSDS 'improved' on TCP/IP
      and went incompatible quite quickly. The same will happen
      with the CCSDS bundle protocol, and in adopting RFC5050
      CCSDS has reserved the right to make changes - things like
      Delay Tolerant Payload Conditioning (DTPC) are but the start.
      There's an example of bundle protocol work not requiring
      the IETF. Work on altering and extending the bundle protocol
      is already ongoing in CCSDS.
      Setting up an IETF workgroup to work in parallel would mean
      that a CCSDS liaison would be required, to pay attention
      to their concerns as they try and convince their member space
      agencies to use the bundle protocol, and to prevent their spec
      from diverging (further) from the IETF spec. Really, the work
      is simply more easily done in CCSDS, given that CCSDS is
      pretty much the only customer for bundle protocol, because
      NASA has mandated bundle protocol use from on high.
      NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design
      for NASA's Space Communications and Navigation people.
      JPL is really the primary customer for and user of bundle
      protocol, responsible for promoting its use by other space
      agencies - never an easy task, even with good technologies.

   b. The IETF produces Internet standards. The bundle protocol
      has little bearing on or interaction with Internet standards;
      it's arguably a way to interoperate with the Internet while
      protecting CCSDS from incursion of the Internet, by layering
      over both Internet and CCSDS. Each to their own domains.
      Using TCP as the most common bundle convergence layer (described
      in a draft now seven years old) does not make the bundle protocol
      an internet standard. If it did, then CCSDS's Space Link
      Extension (basically a TCP tunnel carrying CCSDS frames, with
      much added complexity) would also be a candidate for an
      IETF internet standard.
      But, again, that work is best done in CCSDS, where there
      is interest in having it done and there are users. (Some
      of those users may even be willing users.)

   c. The bundle protocol is not mature. Deficiencies have been
      identified, drafts have been written in DTNRG over the years,
      there was little interest, the drafts expired, the bundle
      protocol was never improved. And that's just from demonstrations;
      there has not been extended operational use to my knowledge.
      Attempting to fix the bundle protocol AND push it through as
      standards track at the same time seems unwarranted.
      It may be politically motivated, but it is
      not technically or procedurally justifiable.
      There isn't the userbase or demand needed for the bundle
      protocol to go standards track, and if the IETF did go
      standards track, CCSDS would 'optimize' that standard into
      its own standard, just as was done with SCPS, meaning that
      the IETF would spend a lot of time working on something with
      no benefit to the IETF community or userbase. Extending
      the Internet protocols to the DTN network problem space
      adds value to the internet protocols. A separate protocol
      does not.
      Who would benefit, outside the CCSDS community? And CCSDS
      is their own standards org - an ISO subgroup - to do work
      for that CCSDS community.

2. I don't see why this needs to be done in an IETF WG, because:

   a. going standards track isn't justifiable - see 1.

   b. There's already the IRTF DTNRG, which could clean up its
      own work, but ,after many years and some failed drafts,
      has not.
      Declaring success and saying it is now time to create a
      WG based on DTNRG's achievements is not convincing,
      because those achievements are not impressive.
      (Disclaimer of interest: I authored 'A bundle of problems'
      and have spent considerable years trying to explain and
      address problems with the bundle protocol, with little
      success, after getting it tested in space before NASA's
      EXPOXI/Deep Impact tests took place.
      Fred Templin's problem statement drafts for this putative
      IETF BOF calls on that work.)
      RFC5050bis would make more sense as a DTNRG
      effort, though it would be time for a changing of the
      guard and chairs in DTNRG to infuse some new blood and
      technical judgement - or we're in for another five years
      of what-does-the-end-to-end-principle-really-mean and
      what-about-clocks and rehashing the same old arguments.
      Really, DTNRG needs to get its act together, both
      organizationally and technically.

   c. There's already CCSDS, which has adopted the DTNRG output,
      after pushing for the formation of an Interplanetary
      Internet RG in the first place.

So either CCSDS or DTNRG can do RFC5050 revision work. If
it's to be an RFC, experimental or informational, a revitalised
rechartered DTNRG can do it.
It doesn't need to be an IETF workgroup. It certainly
shouldn't go standards track.

3. The philosophically shaky basis for the bundle protocol:

   a. Delay-tolerant networking is not disruption-tolerant
      networking. Space delays of light-minutes with scheduled
      contacts are not the same as intermittent ad-hoc
      manet-style communications. Different requirements,
      different buffering and storage, different conditions,
      different handling of fragmentation, etc.

   b. The bundle protocol is not DTN. DTN is the scenario,
      in which other approaches (the related CFDP, Haggle,
      the MANET and vehicular DTNs efforts that DTN subsumed
      and rebranded, etc.) exist.
      The bundle protocol is intended to be used in a DTN
      scenario. Branding the bundle protocol as DTN has
      put back non-bundle DTN research a number of years.
      Branding a group only working on the bundle protocol
      as 'DTN' is misleading at best.

   c. Extending the bundle protocol from the original
      Interplanetary Internet problem (which had its own
      IRTF RG which led into a set bundle agenda for
      DTNRG) to cover everything else as well simply hasn't
      worked very well, because the scenarios and use cases
      are different. We design for use cases. To be too
      generalised is to engineer for nothing.

   d. Ignoring the ramifications of the end-to-end principle,
      which are often more subtle than people seem to think
      they are. The bundle protocol's custody transfer
      procedure is a good example of this failing.

   e. The bundle protocol is intended for use in the most
      difficult noisy disrupted networking conditions we know,
      and it can't even sanity check its own headers against
      errors. (But hey, it now has a security protocol that
      _almost_ does that! But which is too complicated, and
      would need to be redone.)
      It's intended for the harshest environments we know,
      but needs reliable synchronized clocks running at
      steady temperatures!
      It's intended for embedded systems, but the design
      is huge and complex! (CFDP has the same problem;
      there's a reason implementers went for a "CFDP lite,"
      and Saratoga exists just because CFDP wasn't performing.
      Would RFC5050bis be "bundling lite"?) 
      There are many 'that makes no sense' moments - normally
      more immediately visible to outsiders not steeped in
      the dogma, politics, and history of DTNRG and CCSDS.

   f. The assumption that a full security suite is desirable
      and necessary at all times. This has derailed DTNRG,
      as emphasis was placed on security work above all
      else, rather than working to the scenario. To be fair
      to the security-focused chairs, the charter that
      established DTNRG from the interplanetary internet
      research group called out security heavily, and they
      ran with that mandate. But the focus has decreased
      work on non-security matters, which is to say,
      everything else.

RFC5050bis might address the latter three problems, but
the first three are intrinsically unsolvable; any solution
will be unsatisfactory. Perhaps not as unsatisfactory as
RFC5050, but unsatisfactory nonetheless.

The real philosophical problem here is the political dogma
that, whatever the problem, the bundle protocol is The
One True Solution.

4. The draft BOF charter is bundle-centric. Which is to say,
   that it's not awfully relevant to internet standards.
   Disclaimer of interest: we've worked on Saratoga and
   HTTP-DTN, which have current internet-drafts, and are
   squarely in the DTN problem space.
   Whenever someone talks about multiple convergence
   layers for the bundle protocol - there's more than for BEEP,
   which just has TCP, but there aren't many - Saratoga may
   be mentioned. But we've found that carrying bundles doesn't
   benefit Saratoga - tested it in space, didn't see the
   advantages. Saratoga does leverage a few Internet things -
   UDP, UDP-Lite, multicast. It does a few scaling things that
   nothing else I've seen does (described in our 2011 TSVAREA
   presentation to IETF 88 in November.) And it's based on
   a decade of operational use in the problem domain.
   HTTP-DTN leverages the HTTP suite and MIME, and comes up
   whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion
   takes place.
   (I suspect that all of Stephen Farrell's N4C work could
   have been done over hop-by-hop HTTP a la HTTP-DTN, and
   would have worked just as well if not better. After all,
   it used TCP.)
   These and other efforts exist in a gap between DTNRG, which
   is aware of the problem space, but thinks the bundle
   protocol is the solution despite mounting evidence to the
   contrary, and TSVWG, where the few actual transport
   experts live, without clout, or funding, or spare time.
   Those efforts are interesting enough to have implementations
   kicking around too.
   And yet, the focus of this putative workgroup and BOF is
   solely on bundling, and not on evaluating these or other
   things that might exist in the problem space. There
   must be other things out there that would be of interest
   to such a DTN workgroup. What is proposed is not a DTN
   workgroup. The charter is basically a bundle workgroup.
   Can an interest in bundling and solely bundling (outside
   CCSDS, which is driving the push to use the bundle protocol)
   be justified for an IETF workgroup? I really don't think so.

5. The bundle protocol work was, I gather, well-funded
   by a number of parties.
   I can't see a follow-on effort being anywhere near
   as well funded.

   a. I have no idea how much money NASA and CCSDS have put
      into this - first CFDP, then bundling, which now has
      to provide a CFDP-like API to the users who were told
      that CFDP was the future, and Licklider (LTP).
      Dragging CCSDS into the modern age of networking
      seems unlikely to ever happen, thanks to CCSDS having
      little in the way of sane layering or separation of
      functionality.
      I do have the luxury of not needing to work on CCSDS.
      But if you want to work on CCSDS protocols, CCSDS is
      the place to go. The IETF is not that place.

   b. DARPA poured money into DTN work - at least twenty
      million dollars, from the press releases I've seen.
      I have no idea what DARPA got out of it in the
      years they were involved; haven't seen the reports.

My point is, all that money and effort and manpower and
over a decade of work and prior experience with CFDP and two
IRTF RGs, we have... RFC5050.
There is nowhere near as much money or effort or manpower
for doing a replacement.
Ergo, it might be suggested that the replacement is unlikely
to be as good as RFC5050, or as good as CFDP; at best,
the usual suspects will have less time and fewer resources
to repeat their original mistakes.

And transport expertise from TSVWG would be needed.
TSVWG is unfashionable, low-visibility, and has even
previously had trouble finding ADs with relevant expertise.
And TSVWG has a full plate with work on its existing
protocols; there is not a lot of expertise, and what there
is is spread thin.
So an RFC505bis effort is unlikely to get the expert
technical input that it sorely needs, even if an IETF
workgroup is set up. (CCSDS doesn't have that transport
focus.)

If, on the other hand, you believe good protocol design
can be done more cheaply and leverage actual Internet
standards to get Internet functionality working in
difficult networks where the full TCP/IP suite has
trouble, your options include Saratoga and HTTP-DTN!
http://saratoga.sourceforge.net/
http://sat-net.com/L.Wood/dtn/http-dtn.html
They'll truly extend the Internet to difficult
environments. The bundle protocol won't.

So, to conclude, there is no justification for going
standards track. There is little justification for an
IETF workgroup. There is more logic in rechartering and
repurposing the IRTF DTNRG, but the work may as well
be left to CCSDS entirely.

RFC5050bis: half-assed, half-baked, reheated.
But hey, ask me what I _really_ think.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/

---

From: Eric Travis <[email-masked]>
Date: Thu, 5 Jun 2014 12:29:18 -0400

Lloyd,

Embedded in your manifesto are two points worthy of discussion/debate
throughout the BoF process:

1) Is the proposed (base) solution - with "minimal" fixes - of sufficient
maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient
interest/resources to advance the state of RFC-5050, how will a new IETF WG
change the dynamic?

As for the rest of it, well...

> But hey, ask me what I _really_ think.

Let the rational, well-reasoned discussion begin...

Eric
[email-masked]

On Thu, Jun 5, 2014 at 7:20 AM, <[email-masked]> wrote:

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

-- 

*The problem with the world is that the intelligent people are full of
doubts, while the stupid ones are full of confidence.*

*
- Charles Bukowski*

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jun 2014 17:31:07 +0000

Hi Lars,

Thanks for your comments on the proposed charter, and see below for
follow-up:

> -----Original Message-----
> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Thursday, June 05, 2014 12:33 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [dtn] DTN BoF Proposal for IETF90
> 
> Hi,
> 
> that adds up to 2.5h - when were you planning to have charter discussions, etc.? Suggest to focus on
> 1, and then summarize the suggested work items 2-7 in much less time, leaving an hour at least for
> discussion.

OK - that seems like a sensible approach.
 
> >      limitations suggest the need for a new approach.

OK.

> At lest the second half of the paragraph above can be eliminated from the charter text. You could even

OK.
 
> You could significantly shorten the body of text above, incl. the bullet list, by simply pointing at
> some relevant DTNRG RFCs and say that you want to build on what was done before and not go off to
> reinvent everything.

OK.

> Now we're getting to the point where the charter text actually starts to matter:

OK.

> Why "expect to"? It would be good to have agreement whether or not 5050 is the baseline here.

We can restate it as: "We will derive...", considering RFC5050 as the
baseline.

> List is OK for discussion, but doesn't need to be in the charter.

OK. Would it be OK if such a list appears in a draft, and the charter
simply points to the draft?

> > 	Protocol documented in RFC 6257.

"We will derive..." ?

> For all of those bullets above, are there starting points, or will these be completely new protocol
> developments? (if the latter, you are setting yourself up for a LOT of work.)

The only item for which there is currently no starting point is
delay-tolerant security key management.

> Paragraph can be cut. Charters can change, everyone knows that.

OK, but we thought it would be helpful to name some recharter candidates
to retain linkage to research activities, i.e., to show that we intend
to allow a path forward for new activities. Can the current paragraph
be compressed to retain the linkage?  

> > Goals and Milestones:
> 
> Based on the current speed of the CTNRG, all these milestone deltas from start are hugely optimistic.
> I'd suggest to multiply by a factor of 2-3x.
> 

Thanks for your comments, Lars. Let me know if you have further
follow-up, and I will roll the changes into a new revision soon.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jun 2014 17:38:45 +0000

Hi Eric,

To point 1), advancement of work items in the IETF is usually based on “rough consensus
and running code” and there is plenty of interoperable running code that implements
RFC5050 and its related specifications – much more than most IETF activities are based on.
As to “rough consensus”, holding a BoF is the first step in determining that.

To point 2), again the BoF will provide a useful measurement of interest.

Thanks – Fred

From: dtn [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Thursday, June 05, 2014 9:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Lloyd,

Embedded in your manifesto are two points worthy of discussion/debate throughout the BoF process:

1) Is the proposed (base) solution - with "minimal" fixes - of sufficient maturity for standardization within the IETF?

2) The existing IRTF DTNRG has not been able to harness sufficient interest/resources to advance the state of RFC-5050, how will a new IETF WG change the dynamic?

Let the rational, well-reasoned discussion begin...
Eric
[email-masked]<mailto:[email-masked]>

On Thu, Jun 5, 2014 at 7:20 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Lloyd Wood

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

--
The problem with the world is that the intelligent people are full of doubts,
while the stupid ones are full of confidence.
                                                                                  - Charles Bukowski

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jun 2014 18:02:00 +0000

Hi Lloyd,

Wading through your points, you seem to be concerned that standardizing
the Bundle Protocol in the IETF will somehow block other approaches from
going forward in the future, but that would not be consistent with my
understanding of the way the IETF operates. There are many examples where
multiple solutions for roughly the same problem space have gone forward
to standards track and have all found widespread application - sometimes
based on the best-fit solution for the particular problem and sometimes
based on market forces.

The purpose of having a standard is so that vendors can independently
create interoperable implementations, and the IETF is the correct forum
for developing internetworking standards.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, June 05, 2014 4:20 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Eric Travis <[email-masked]>
Date: Thu, 5 Jun 2014 14:23:51 -0400

Hi Fred,

While I wasn't intending to advocate either way on the items:

To point 1), advancement of work items in the IETF is usually based on
> “rough consensus

My  "points worthy of discussion/debate throughout the BoF process" seems
to be compatible with your

> As to “rough consensus”, holding a BoF is the first step in determining

I'd contend that the *DTNRG* was the start of that discussion.  The *BoF*
is a continuation of a 7+ year community discussion.

There is an experimental RFC that has achieved interoperability between
multiple independent implementations.
That, however, isn't necessarily a referendum on the maturity of the
protocol(s) themselves.

For those entities whose needs are satisfied with RFC-5050, a
standards-track document is not necessary for deployment.
Actually, a standards-track document is never *really* necessary.  There
are many middleware/application level "things" deployed
that are not based on IETF standards.  The presumption of the BoF seems to
be that RFC-5050 is NOT "there yet".  So, the
question is how close to maturity is close enough to go into a standards
trajectory.

>From the discussions on the list, there has been a lot of very promising
dialog of the nature of
"Yeah, it would be useful to *explore* Foo and/or Bar", from some people
that - frankly - pleasantly surprised me.

This leads to the question - has the solution space been adequately
explored to have confidence that the result is
a mature (NOT perfect)?  If not, will the WG be able to take it further
than the RG was capable (and why is that true)?

That's a question, not a statement on my part.

I think the level of interest is relatively high within the DTNRG - and
will likely be so for a DTN WG.  The question
really is if/how will that translate into measurable progress (fixing the -
some long acknowledged - nits in the protocol
specification.

The original idea of a RFC5050.Bis was floated two (three?) years ago as
part of the most recent Google meeting.  It failed to gain
traction, despite what seemed to be a fair amount of community interest.

Is the lack of movement within the DTNRG simply because of the (lack of)
path to a standards track RFC?

The question for the BoF is, what caused the evolutionary pause, and how
will a WG prevent it from stalling again.

Just to be clear,  I'm in favor of a BoF and currently undecided/agnostic
on support of a WG, these types of discussions would
be useful to me (at the very least).

Regards,

Eric

On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L <[email-masked]>
wrote:

> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Eric Travis
> *Sent:* Thursday, June 05, 2014 9:29 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>
> *Subject:* Re: [dtn] DTN BoF Proposal for IETF90
>
>
>
> Lloyd,
>
>

-- 

*
- Charles Bukowski*

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jun 2014 18:42:49 +0000

Hi Eric,

It is true that having an official IETF standard is not a necessary precondition for one
or more  vendors to move forward with widely-deployed implementations. I should
know; I wrote one:

http://www.rfc-editor.org/rfc/rfc5214.txt

But, having an IETF standard is a demonstration that rough consensus has deemed
the work as standards-worthy – a community stamp of approval, or at least “no
objection”.

About level of interest,  I believe there is still energy in DTNRG and at least some of
that energy is spilling over into these discussions.

Thanks - Fred

From: Eric Travis [mailto:[email-masked]]
Sent: Thursday, June 05, 2014 11:24 AM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Hi Fred,

My  "points worthy of discussion/debate throughout the BoF process" seems to be compatible with your
As to “rough consensus”, holding a BoF is the first step in determining that.

I'd contend that the *DTNRG* was the start of that discussion.  The *BoF* is a continuation of a 7+ year community discussion.

There is an experimental RFC that has achieved interoperability between multiple independent implementations.
That, however, isn't necessarily a referendum on the maturity of the protocol(s) themselves.
For those entities whose needs are satisfied with RFC-5050, a standards-track document is not necessary for deployment.
Actually, a standards-track document is never *really* necessary.  There are many middleware/application level "things" deployed
that are not based on IETF standards.  The presumption of the BoF seems to be that RFC-5050 is NOT "there yet".  So, the
question is how close to maturity is close enough to go into a standards trajectory.

From the discussions on the list, there has been a lot of very promising dialog of the nature of
"Yeah, it would be useful to *explore* Foo and/or Bar", from some people that - frankly - pleasantly surprised me.
This leads to the question - has the solution space been adequately explored to have confidence that the result is
a mature (NOT perfect)?  If not, will the WG be able to take it further than the RG was capable (and why is that true)?

I think the level of interest is relatively high within the DTNRG - and will likely be so for a DTN WG.  The question
really is if/how will that translate into measurable progress (fixing the - some long acknowledged - nits in the protocol
specification.
The original idea of a RFC5050.Bis was floated two (three?) years ago as part of the most recent Google meeting.  It failed to gain
traction, despite what seemed to be a fair amount of community interest.
Is the lack of movement within the DTNRG simply because of the (lack of) path to a standards track RFC?
The question for the BoF is, what caused the evolutionary pause, and how will a WG prevent it from stalling again.

Just to be clear,  I'm in favor of a BoF and currently undecided/agnostic on support of a WG, these types of discussions would
be useful to me (at the very least).
Regards,
Eric
[email-masked]<mailto:[email-masked]>

On Thu, Jun 5, 2014 at 1:38 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Travis
Sent: Thursday, June 05, 2014 9:29 AM
To: [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]>

Lloyd,

Lloyd Wood

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 23:05:50 +0000

(snipping IESG, who know this stuff, from cc)

Fred,

RFC5214, which you wrote, is NOT an "official IETF standard".

It's informational for the community - see the 'Category: Informational'

at top left.

Being published as an RFC is NOT at all the same as being a standards-track

candidate or being evaluated as an IETF standard.

http://www.rfc-editor.org/search/rfc_search_detail.php?rfc=2026

See RFC2026 and whatever updates it these days - there are about a dozen

later RFCs on nuances of how this standards process actually works, though

the distinction is lost on outsiders (and, come to think of it, on some of my

coauthors, who just see a technical specification). Laymen often have trouble
telling the difference between an internet-draft and a published RFC;

the nuances of the categories are beyond that.

http://en.wikipedia.org/wiki/Internet_Standard

has a layman introduction of sorts.

Do you actually understand what you are asking for in proposing a BOF and WG

to produce a standards document, and why the IETF draws a difference between

"experimental RFC" or "informational RFC" and "standards-track document"?

"Category: Standards Track" has a far higher bar.

> the work as standards-worthy – a community stamp of approval, or at least “no

In brief, no. The RFCs that are IETF standards and standards-track documents

get more scrutiny than mere rough consensus. RFCs can be published with

objections and warnings documented in them; see, for example, the warning

on the informational RFC4938, where the IESG and the workgroup threw up

their hands in horror at the whole thing, but since this PPPoE hack was

already shipping, better to have it documented than not.

Oh, and "I should know, I wrote one" is also an ad-hominem argument,

which is to say, a logical fallacy - but at least it's not alone there. Good job.

So, now that you know this, do you want to re-evaluate your request

for an IETF WG to produce a standards document? The bundle protocol

was ready for an experimental RFC. But it's nowhere near mature

enough for standards track.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: Templin, Fred L <[email-masked]>
Sent: Friday, 6 June 2014 4:42 AM
To: Eric Travis
Cc: Wood L Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dtn] DTN BoF Proposal for IETF90

Hi Eric,

Thanks - Fred

Hi Fred,

Thanks – Fred

Lloyd,

Lloyd Wood

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jun 2014 23:15:30 +0000

Hi Lloyd,

I realized after I posted that my language was ambiguous - my point is exactly that
RFC5214 IS NOT an "official IETF standard", yet it is widely deployed in common
systems.  I did not at all intend to make any claim that it was a standard - only to
concur with Eric's point that:

"Actually, a standards-track document is never *really* necessary."

I apologize that I cited one of my own publications; I'm sure no one in these
discussions has ever done that before.

Thanks - Fred

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 05, 2014 4:06 PM
To: Templin, Fred L; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dtn] DTN BoF Proposal for IETF90

Fred,

at top left.

> the work as standards-worthy - a community stamp of approval, or at least "no
> objection".

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 6 June 2014 4:42 AM
To: Eric Travis
Cc: Wood L Dr (Electronic Eng); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN BoF Proposal for IETF90

Hi Eric,

But, having an IETF standard is a demonstration that rough consensus has deemed
the work as standards-worthy - a community stamp of approval, or at least "no
objection".

Thanks - Fred

From: Eric Travis [mailto:[email-masked]]
Sent: Thursday, June 05, 2014 11:24 AM
To: Templin, Fred L
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]>
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Hi Fred,

To point 1), advancement of work items in the IETF is usually based on "rough consensus
and running code" and there is plenty of interoperable running code that implements
RFC5050 and its related specifications - much more than most IETF activities are based on.

My  "points worthy of discussion/debate throughout the BoF process" seems to be compatible with your
As to "rough consensus", holding a BoF is the first step in determining that.

To point 1), advancement of work items in the IETF is usually based on "rough consensus
and running code" and there is plenty of interoperable running code that implements
RFC5050 and its related specifications - much more than most IETF activities are based on.
As to "rough consensus", holding a BoF is the first step in determining that.

Thanks - Fred

Lloyd,

Lloyd Wood

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2014 00:00:10 +0000

Hi Lars,

Here is an update to the proposed charter based on your suggestions
(see also attached diffs).

Thanks - Fred

---

2) RFC5050(bis) - 15min

3) Streamlined Bundle Security Protocol (SBSP) - 15min

4) Bundle-in-Bundle Encapsulation - 10min

5) Security Key Management - 10min

6) Registry for Service Identifiers - 10min

7) Network Management - 10min

8) Open Discussion - 50min

Chair(s):

      TBD

      TBD

Mailing list:

      
      issues identified above in substantial fielded deployments [1].

      The success of the BP/LTP protocol stack -- the core protocols of the
      "DTN Architecture" originally described in RFC 4838 -- may be attributed
      to the following fundamental design principles:

	- There is never any expectation of contemporaneous end-to-end
          connectivity between any two network nodes.

	  forwarded.

	  architecture.

      The DTNWG believes that protocols adhering to these principles offer
      opportunities for enhancing the functionality of the Internet - in
      particular, for facilitating the extension of the Internet into
      environments such as the ocean floor and deep space in which the core
      Internet protocols operate sub-optimally for the reasons discussed
      earlier.  We believe that the extensive research, demonstration, and
      pilot operations performed to date using the DTNRG protocols provides
      a firm basis for publishing Internet standards derived from that work.

      o A mechanism for the exchange of protocol data units, termed
	"bundles", that are designed to obviate conversational communications
	by containing values for all potentially relevant configuration
	parameters.  These protocol data units are typically larger than
	network-layer packets.  We will derive this bundle exchange mechanism
        from the DTN Bundle Protocol (BP) documented in RFC 5050. Changes from
        RFC 5050 will appear in a soon-to-be-published RFC 5050(bis).

	in that network where necessary.  We will derive this security

      o A simple datagram convergence layer protocol for adaptation of the
        bundle protocol to underlying internetworks. We expect to derive
        this convergence layer protocol from the Datagram Convergence
        protocol documented in RFC 7122.

  
    The working group will consider extending the current milestones based on
    new information and knowledge gained while working on the initial charter,
    as well as to accommodate new work items beyond the scope of the initial
    phase.  For example, we expect that transport protocols such as LTP and
    the Saratoga protocol are among the candidates for work in this phase.
    
Goals and Milestones:
  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
               working group document. To be Proposed Standard.
  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
               working group document. To be Proposed Standard.
  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
               group document. To be Proposed Standard.
  start+12mos - Submit 'Delay Tolerant Networking Security Key Management' as
                a working group document. To be Proposed Standard.
  start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
                Key Mgmt into a combined draft or keep as separate drafts.
  start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
                as a combined draft or as separate drafts.
  start+18mos - Submit Network Management, Registry and Simple Convergence
                Layer as working group documents.
  start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
                technologies (e.g., convergence layer protocols, dynamic
                routing protocols, naming and addressing services, etc.)
                ready for transition into IETF DTN Working Group. Publish
                draft on survey results as independent submission related
                to the WG.
  start+24mos - Submit Network Management, Registry and Simple Convergence
                Layer to IESG
  start+24mos - Recharter to accommodate new work items or close Working Group

[1] BP/LTP deployment on EPOXI spacecraft [2008]

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 04:24:23 +0000

Fred,

CCSDS exerts lockin on space agencies. It's very resistant to market forces (like, you know, TCP/IP), and utterly resistant to multiple competing solutions - which is why the bundle protocol was developed and pushed. It's rather analogous to the telcos developing ATM in the 1990s to meet their needs, and then doing that development in the ATM Forum. The IETF sat happily by, shaking its head for the most part.

The question is, why should the IETF spend further time and effort for CCSDS on the bundle protocol to preserve the CCSDS bulwark against IP, where there are other things its experts could be doing that benefit actual IETF protocols? The bundle protocol is politically favoured by CCSDS, but is not technically good.

(Also, it's unclear, from this discussion, that when you say 'a standard' whether you mean 'a published RFC' or 'a standards-track RFC' or 'a standard'. Those are progressively higher bars.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Templin, Fred L <[email-masked]>
Sent: Friday, 6 June 2014 4:02 AM
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dtn] DTN BoF Proposal for IETF90

Hi Lloyd,

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2014 15:45:12 +0000

Hi Lloyd,

Independent submissions can be submitted directly to the ISE editor
as either Experimental or Informational category without AD sponsorship.
These documents are reviewed by the IESG for conflicts with existing
working groups, but are not necessarily reviewed for technical content.

Individual submissions can be submitted via AD sponsorship for
Experimental, Informational or even Proposed Standard. These documents
receive a technical review from the IESG and (if approved) are published
by the RFC Editor.

Working groups are chartered to publish Experimental, Informational or
Proposed Standards. The intended outcome of the BoF is the formation of
an IETF working group chartered to produce Proposed Standards.

Thanks - Fred

> Sent: Thursday, June 05, 2014 9:24 PM
> To: Templin, Fred L; [email-masked]; [email-masked]
> CCSDS exerts lockin on space agencies. It's very resistant to market forces (like, you know, TCP/IP),
> and utterly resistant to multiple competing solutions - which is why the bundle protocol was developed
> and pushed. It's rather analogous to the telcos developing ATM in the 1990s to meet their needs, and
> then doing that development in the ATM Forum. The IETF sat happily by, shaking its head for the most
> part.
> 
> The question is, why should the IETF spend further time and effort for CCSDS on the bundle protocol to
> preserve the CCSDS bulwark against IP, where there are other things its experts could be doing that
> benefit actual IETF protocols? The bundle protocol is politically favoured by CCSDS, but is not
> technically good.
> 
> (Also, it's unclear, from this discussion, that when you say 'a standard' whether you mean 'a
> published RFC' or 'a standards-track RFC' or 'a standard'. Those are progressively higher bars.)
> 
> Lloyd Wood

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2014 18:44:17 +0000

See below for updated charter with pointer to new doc (diffs attached).

Thanks - Fred

---

2) RFC5050(bis) - 15min

Chair(s):

      TBD

      TBD

Mailing list:

      

      o A mechanism for the exchange of protocol data units, termed
	"bundles", that are designed to obviate conversational communications
	by containing values for all potentially relevant configuration
	parameters.  These protocol data units are typically larger than
	network-layer packets. We will derive this bundle exchange mechanism
        from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing
        a new document [2], where appendix A and B provide an update summary.

  
    
Goals and Milestones:

[1] "BP/LTP deployment on EPOXI spacecraft" [2008]
[2] "Proposed Revised Bundle Protocol" [2014],
    https://datatracker.ietf.org/doc/draft-burleigh-bpv7/

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Fri, 6 Jun 2014 20:48:00 +0000

Fred, a couple of suggested tweaks to the charter:

-	From "documented in RFC 5050 by publishing a new document [2], where appendix A and B provide an update summary" to "documented in RFC 5050 by publishing a new document for which [2] is a proposed first draft (where appendix A provides a summary of the proposed changes)."

-	Maybe it would make the work plan look less challenging if other existing Internet Drafts were cited?  There are current I-Ds for SBSP and BIBE, at least.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, June 06, 2014 11:44 AM
To: [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Thanks - Fred

---

2) RFC5050(bis) - 15min

Chair(s):

      TBD

      TBD

Mailing list:

      

  
    
Goals and Milestones:

[1] "BP/LTP deployment on EPOXI spacecraft" [2008] [2] "Proposed Revised Bundle Protocol" [2014],
    https://datatracker.ietf.org/doc/draft-burleigh-bpv7/

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2014 21:55:39 +0000

Hi Scott,

> Fred, a couple of suggested tweaks to the charter:

Yes to both - see below for the update, plus attached diffs.

Thanks - Fred

---

2) RFC5050(bis) - 15min

Chair(s):

      TBD

      TBD

Mailing list:

      

      o A mechanism for the exchange of protocol data units, termed
	"bundles", that are designed to obviate conversational communications
	by containing values for all potentially relevant configuration
	parameters.  These protocol data units are typically larger than
	network-layer packets. We will derive this bundle exchange mechanism
        from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing
        a new document for which [2] is a proposed first draft (where
        appendix A provides a summary of the proposed changes).

  
    
Goals and Milestones:
  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
               working group document [2]. To be Proposed Standard.
  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
               working group document [3]. To be Proposed Standard.
  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
               group document [4]. To be Proposed Standard.
  start+12mos - Submit 'Delay Tolerant Networking Security Key Management' as
                a working group document. To be Proposed Standard.
  start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
                Key Mgmt into a combined draft or keep as separate drafts.
  start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
                as a combined draft or as separate drafts.
  start+18mos - Submit Network Management [5], Registry [6] and Simple
                Convergence Layer [7] as working group documents.
  start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
                technologies (e.g., convergence layer protocols, dynamic
                routing protocols, naming and addressing services, etc.)
                ready for transition into IETF DTN Working Group. Publish
                draft on survey results as independent submission related
                to the WG.
  start+24mos - Submit Network Management, Registry and Simple Convergence
                Layer to IESG
  start+24mos - Recharter to accommodate new work items or close Working Group

[1] "BP/LTP deployment on EPOXI spacecraft" [2008],
    http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf  
[2] "Proposed Revised Bundle Protocol" [2014],
    https://datatracker.ietf.org/doc/draft-burleigh-bpv7/
[3] "Streamlined Bundle Security Protocol Specification" [2014],
    https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/
[4] "Bundle-in-Bundle Encapsulation" [2013],
    http://tools.ietf.org/id/draft-irtf-burleigh-bibe
[5] "Delay Tolerant Network Management Protocol" [2013],
    http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp
[6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011],
    https://datatracker.ietf.org/doc/rfc6255/
[7] "Datagram Convergence Layers ..." [2014],
    https://datatracker.ietf.org/doc/rfc7122/

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jun 2014 15:45:56 +0000

Hi Lloyd,

> then doing that development in the ATM Forum. The IETF sat happily by, shaking its head for the most

I don't see it at all that the bundle protocol is analogous to ATM.
ATM was about turning the Internet into "the matrix" - everything
lined up so neat and homogeneous - no room for diversity - an
innovation killer. The Internet is about accommodating diversity,
and we are surely seeing that play out with the way the Internet
has evolved.

DTN (and the bundle protocol) is about interconnecting Internets.
Let each Internet evolve according to its own characteristics, then
hook them up at the edges. BP is all about accommodating diversity.  
 
> benefit actual IETF protocols? The bundle protocol is politically favoured by CCSDS, but is not

I don't understand "preserve the CCSDS bulwark against IP". BP is
designed to connect IP internetworks and uses actual IETF protocols.

Also, "not technically good" is not much of a technical assessment.
You have published "Bundle of Problems", and as I have said it provides
a useful problem statement to build on in a new revision of RFC5050.
Protocols evolve based on insights gained through operational experience;
none of them are perfect in their first iteration.

Thanks - Fred

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 9 Jun 2014 23:55:27 -0400

Fred,

  I wanted to concur on the changes to the BOF agenda times. Some time discussing security, management, and 5050bis are good ways to prime the larger discussion for the charter of the proposed working group. I also think the updated working group charter goals and milestones are more appropriate. I have a few notes for security and management, which I will put forward in different messages to preserve threading.

-Ed
  
________________________________________
From: dtn [[email-masked]] On Behalf Of Templin, Fred L [[email-masked]]
Sent: Friday, June 06, 2014 2:44 PM
To: [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Thanks - Fred

---

2) RFC5050(bis) - 15min

Chair(s):

      TBD

      TBD

Mailing list:

Goals and Milestones:

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 08:40:37 +0000

Hi Fred,

I see I'll need to explain my ATM analogy to the bundle protocol
in a bit more detail.

Please bear with me while I do that and step through some history, before going
into some IETF/CCSDS interaction nuances. (Understanding the needs of the
Consultative Committee for Space Data Systems is key to understanding why the
bundle protocol exists.)

A brief history of ATM

ATM was developed by a single community - telcos with some very restrictive
legacy voice requirements - and passed onto a larger audience as the one true
way to handle true QoS and high-speed switching with Proper Managed
Multiplexing. It had processing performance and other problems, and
was then bypassed by market forces and technical developments, even
though few ever said outright that 'ATM is technically poor'. And it's no
longer used much, even in its core community. Technology has moved on.

Jon Crowcroft's 'J'accuse, ATM' end2end-interest piece from 1994 gives
a flavour of this while it was happening.
https://groups.google.com/forum/#!topic/info.ietf/HCe2X7jzuNY
Daniel Stevenson's 'Electro Political Correctness and High-Speed Networking
or why ATM is Like a Nose,' from the same era, gives more technical detail of
the problems, including the legacy echo cancellation reasons and
compromising that led to that 48-byte payload.

Few actually working on ATM complained much, in public. There were a
number of US research projects, with a number of European research
projects following on after to catch onto what seemed like a good trend.
(Disclaimer of interest: my PhD work was funded by European projects
bringing up the tail end of the ATM infatuation. MPLS seemed like a useful
way out of wholeheartedly committing to anything involving ATM. And
that's why I'm using ATM as the example instead of the earlier OSI stuff.)

ATM was not revised to fix its problems.
The world moved on to better things.

A brief history of the Bundle Protocol

Similarly, the bundle protocol was developed by and for a single community
- NASA-led CCSDS for the 'interplanetary internet' - and passed to a larger
audience as the one true way to handle delay-tolerant networking. (Fall's
2003 SIGCOMM paper was seminal in that; it gave the MANET/ad-hoc crowd
a new focus and banner to wave. Impressive going for a conference paper with
no actual results, widely cited, very influential, and rightly deserving of awards
for being so!)

However, it's sometimes hard to tell a truly useful vision from a momentary
hallucination. "Delay-tolerant networking" soon turned out to be badly scoped,
hence the rise of "disruption-tolerant networking" for the more MANET-ish
and military crowd. DARPA evaluated the bundle protocol, and moved on.
CCSDS and NASA stuck with it.

CCSDS and space agencies are largely resistant to market forces, and slow
to accept technical change; the risks of change are high compared to the
possible rewards. CCSDS is positively risk-friendly compared to people
actually designing for missions. There's also little room for diversity in CCSDS.

CCSDS also has a strong 'not invented here' culture - as an ISO subgroup,
CCSDS even refuses to carry the ISO standard 13239 HDLC. (disclaimer of
interest: we've done some neat things with HDLC from a router in space,
which is why I know enough to make that point as a minor example.)

But then, NASA isn't quite onboard with ISO units of measurement, either.
Hey, ISO's useful - as far as it goes, but not too far. It's nice to be part of a
standards body, but actually commit to using their standards? Really?
Allow HDLC and open the door to layering and IP? No way. In CCSDS,
any layering is an inefficiency, to be designed out. Much engineering
time is spent on this.

Unlike the open-to-everyone IETF, CCSDS is a more closed community
for aerospace - you only get on their mailing lists via space agency
sponsorship, the traditional ISO 'nominated subject matter expert' model.

CCSDS is trapped with a pre-packet processing model, and that needs to change.
CCSDS does not have particularly strong expertise in packetised networking,
which is why SCPS was brought in almost wholesale from TCP/IP in the 1990s
before being modified, and why the IRTF workgroups were set up to help
CCSDS out with the Interplanetary Internet idea; the SIGCCOMM paper
got a lot of people onboard for that. 

CCSDS needs to both outsource the development it can't do that well itself,
and yet control its own destiny and standards, by modifying the results. Those
two goals are somewhat incompatible. So if the IETF were to help CCSDS
out with a standards-track workgroup and do the work to get a published
standard, CCSDS would promptly 'improve' it as was done with SCPS, and
as is currently being done by standardising DTPC, DTNMP and other pieces
around the core bundle protocol, in cooperation with European projects
bringing up the tail end of the DTN movement. (DARPA et al. having
already left the building.) And 'not invented here' becomes 'invented here'
with a CCSDS blue book, which is the kind of thing that e.g. the International
Space Station crowd would be comfortable with.

Given that CCSDS is standardising a whole bunch of pieces that the core
bundle protocol needs, and is restandardising RFC5050 into a blue book,
CCSDS can do the RFC5050bis work as well. Perhaps not as well as the IETF
might if serious IETF effort was brought to bear on it, but the IRTF DTNRG
and RFC5050 already suggests what might result.

It's not as if anyone else other than CCSDS aspires to use the bundle protocol
operationally, so CCSDS may as well own RFC5050bis from the start. And selling
RFC5050bis to the space agencies to adopt is CCSDS's problem.

I don't see an upside for the IETF community in doing this standards work for
CCSDS. And I don't see an upside for the DTN/MANET community, research
or operational, as the bundle protocol restricts innovation by proposing
one homogenous, non-diverse, straitjacket for everyone. Rather as ATM did.

Instead, the world needs to embrace innovation and move on from the
Bundle Protocol.

The bundle protocol is not about connecting different types of internets -
other than IP and CCSDS, what other types of internets are in the picture?
Layering over the top just as IP layered over everything is a  wellmeaning
early idea, nothing more. IP internetworks can be connected using.... IP.
CCSDS has to use IP on the ground, but is strongly resistant to using it
in space. CCSDS is going to have trouble getting missions to accept
layering the bundle protocol over the top of their links. The inefficiencies!
But the bundle protocol is the solution that CCSDS has invested in
heavily.

Given that, I can't see anyone in NASA standing up today and saying 'this bundle
protocol really isn't much good'. Too much would be at stake politically.
It would be like standing up in the 1970s and saying 'I think this side-mounted
solid-booster ceramic-tiled space shuttle is quite unsafe and possibly a rather
bad idea.' The shuttle was the one solution, and that was that. To suggest
otherwise would be a career-limiting moment, going against the tide.
(In hindsight, the problems with the shuttle are now obvious to layman
historians:
http://idlewords.com/2005/08/a_rocket_to_nowhere.htm )

"It is difficult to get a man to understand something,
when his salary depends upon his not understanding it!"
-- Upton Sinclair

Our "A bundle of problems" paper [1] was intended to provide a problem
statement - when it was written, in late 2008, after first attempting to take
the points in it to the research group. We even put 'problems' in the name. 
And most of our problem points were obtained through simple analysis, which
our tests rather predictably bore out. It is now 2014, and in over five years
none of the problems raised have been remedied in the design of the bundle
protocol. Because to do so would be to admit that the bundle protocol is, in fact,
flawed. Rather like ATM, or like the space shuttle.

And the world has moved on from ATM and from the space shuttle.
It didn't try to do them over with a version 2.

[1] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems
Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',
IEEE Aerospace Conference, Big Sky, Montana, March 2009.  16 pages.
("the bundle protocol is not technically good"
is just my brief TL;DR summary of those 16 pages.)
http://dx.doi.org/10.1109/AERO.2009.4839384

best regards

Lloyd Wood
Sent: Tuesday, 10 June 2014 1:45 AM

Hi Lloyd,

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jun 2014 15:10:57 +0000

Hi Lloyd,

You don't need to lecture me about ATM - I was there in the late
80's and early 90's when Digital Equipment Corporation was trying
to make a go at ATM and OSI networking ("DECnet Phase V"). Both
crashed and burned (and later so did the company), but that has
nothing whatsoever to do with DTN.

About the rest of your message, your distaste for the origins of
the Bundle Protocol is clear but that has nothing to do with the
way forward for DTN and the Bundle Protocol as an open solution
within the IETF. All protocols get there start somewhere, but this
is not about dragging along legacy. Rather, it is about forming a
community of interest to establish open standards within the IETF
based on the participation of a diverse set of individuals.

I was going to send a separate message, but this seems like a
useful starting point. This is a call to the list for a show of
hands as to who would like to see a BoF held at IETF90. Please
respond to this message thread if you would like to see a BoF.

Thanks - Fred

> Sent: Tuesday, June 10, 2014 1:41 AM

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jun 2014 15:44:34 +0000

Let me make this clearer and decoupled from earlier discussions:

Who would like to see a DTN BoF at IETF90?

Thanks - Fred

---

From: "Krupiarz, Christopher" <[email-masked]>
Date: Tue, 10 Jun 2014 11:52:09 -0400

Fred,

I would like to see a DTN BoF at IETF90.

Chris Krupiarz
JHU/APL

---

From: ccaini <[email-masked]>
Date: Tue, 10 Jun 2014 17:51:36 +0200

Dear Fred, I am in favor.
Yours,
   Carlo Caini

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 10 Jun 2014 16:10:42 +0000

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Templin, Fred L [[email-masked]]
Sent: Tuesday, June 10, 2014 8:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Thanks - Fred

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 Jun 2014 11:20:33 -0500

> Who would like to see a DTN BoF at IETF90?

Speaking as just one AD: That does not make it any clearer, as 
demonstrated by the three people who've already said, without comment, 
"I want a BOF". Lots of people want BOFs, but that isn't in and of 
itself a reason to have one. What matters here are whether there are 
reasons to have one (e.g., "There's real potential work here and we 
should talk about whether we can do it in the IETF"), reasons *not* to 
have one (e.g., "Getting together in a room is likely to generate lots 
of heat and no light and we shouldn't waste people's time"), and some 
evaluation of which is more likely to be true.

Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF 
should conclude that there's nothing to do here") rather than as reasons 
to not hold the BOF at all, and I'd like to hear from him whether 
there's reason to believe that the holding of the BOF itself is 
problematic for some reason. But having people pile on saying, "Yes, we 
should hold a BOF" is not useful. At least not to me.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Ramachandran, Vignesh R. (Vinny)" <[email-masked]>
Date: Tue, 10 Jun 2014 12:26:40 -0400

I am also in favor.

Best, 
Vinny Ramachandran

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jun 2014 16:36:11 +0000

Hi Pete,

Yes, I agree that the question called could benefit from more
context. The formal BoF request is found here:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#

and has the following description:

  "The DTN BoF will investigate interest in transitioning technologies
   developed in the IRTF DTN research group into standards-track activities
   through the formation of a new IETF working group. The BoF will present
   a draft working group charter, including work items based on the DTN
   Bundle Protocol (BP). The goal of the BoF will be to discuss the draft
   charter and present the candidate work items, as well as to determine
   the level of support for conducting the work in the IETF. The desired
   end state is the formation of a new working group soon after IETF90."

So, perhaps the better question would be who would agree that
this justification for holding a BoF has merit?

Thanks - Fred

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Tuesday, June 10, 2014 9:21 AM
> To: Templin, Fred L

---

From: "Krupiarz, Christopher" <[email-masked]>
Date: Tue, 10 Jun 2014 12:52:37 -0400

I would agree that this justification for holding a BoF has merit. :)

Sorry for being blunt, but after years of reading the dtn-interest mailing
list, I don¹t see how more emails on whether to hold a BoF is going to
make any difference.  There¹s a group that thinks BP is a good idea;
there¹s a group that doesn¹t.  Other than resolving this through a show of
hands, I don¹t see a path out.  There is not going to be a consensus.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 10 Jun 2014 13:04:46 -0400

I would like to see a DTN BoF at IETF90 and will be there to participate.

-Ed

---
Ed Birrane
Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> Sent: Tuesday, June 10, 2014 11:45 AM

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 Jun 2014 11:58:10 -0500

On 6/10/14 11:36 AM, Templin, Fred L wrote:
> [...]

Let's reverse it. Let's presume that people do agree that this 
justification for the BOF has merit. We've heard some of those voices 
already, and as far as I can tell nobody has said that there are too few 
people who care, so asking who thinks it has merit is just knocking over 
a straw man.

The right question is who *disagrees* that there is merit in holding a 
BOF. If nobody does, that's good info. If there is disagreement (framed 
as a reason not to hold the BOF, not simply reasons to conclude that a 
WG should not be eventually formed), that will give proponents a chance 
to reply to those concerns. At this point, I don't really care how many 
people think there's a justification to hold the BOF.

Separately, I'm happy to see the discussion of the *outcome* of the BOF 
continue (whether a WG is likely to be successful and produce something 
useful). But let's leave that separate from the discussion of whether 
there should be a BOF at all.

pr

---

From: "Krupiarz, Christopher" <[email-masked]>
Date: Tue, 10 Jun 2014 13:14:28 -0400

Pete,

Your answer is better than mine.  That makes sense to frame it as you have
it.  

Chris

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 10 Jun 2014 13:45:56 -0400

Pete,

   Completely agree that it would be useful to understand any position advocating a BoF as undesirable, separate from a discussion on the merits of a DTN IETF WG.

  I think Fred has identified a useful charter describing useful work that could be accomplished in a working group. I (perhaps naively) interpret responses of "I would like to see a BoF" as an endorsement of his concept, goals, milestones, and likely impact. As you point out, simple "voting" is not helpful, but a past criticism has been that there is disagreement between the space and terrestrial communities in this area and showing a diversity of support for the proposed work is input.  

So, let me clarify my previous comment of "I would support a BoF":

  I would support a BoF in both time and resources because I believe that Fred's charter, to particularly include the proposed Bpv7, security standards, and management standards, represent real potential work that would result in adoptable, deployable RFCs. I think a BoF should inform the discussion of the impact of such a working group, and since I expect that impact to be > 0, I am willing to devote time and effort to the standards process and to help shepherd the adoption of the outputs of the working group in areas where I am able and where it is appropriate.

  I am unaware of a position that states that there is no need to alter 5050, that security standards are either solved or unnecessary, or that existing management solutions scale with disruption or delay. It has been expressed to me, several times, the value of a non-experimental RFC in the context of operational deployment. So I would truly be surprised if there was a consensus that the proposed work is not necessary.

  Perhaps further discussion of the desired "exit criteria" of the BOF meeting would also be useful?

-Ed

---
Ed Birrane

> From: dtn [mailto:[email-masked]] On Behalf Of Pete Resnick
> Sent: Tuesday, June 10, 2014 12:21 PM
> To: Templin, Fred L
> Speaking as just one AD: That does not make it any clearer, as demonstrated
> by the three people who've already said, without comment, "I want a BOF".
> Lots of people want BOFs, but that isn't in and of itself a reason to have one.
> What matters here are whether there are reasons to have one (e.g.,
> "There's real potential work here and we should talk about whether we can
> do it in the IETF"), reasons *not* to have one (e.g., "Getting together in a
> room is likely to generate lots of heat and no light and we shouldn't waste
> people's time"), and some evaluation of which is more likely to be true.
> 
> Most of Lloyd's comments can be taken as BOF input (e.g., "The BOF should
> conclude that there's nothing to do here") rather than as reasons to not hold
> the BOF at all, and I'd like to hear from him whether there's reason to believe
> that the holding of the BOF itself is problematic for some reason. But having
> people pile on saying, "Yes, we should hold a BOF" is not useful. At least not
> to me.
> 
> pr
> 
> --

---

From: Marius Feldmann <[email-masked]>
Date: Tue, 10 Jun 2014 18:08:12 +0000

I would like to see a DTN BoF at IETF90 (though I can only participate  
remotely).

Marius

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 22:54:00 +0000

Ed says:
> I (perhaps naively) interpret responses of "I would like to see a BoF" 
> as an endorsement of his concept, goals, milestones, and likely impact. 

as do I. And I do not endorse the outlined concept, the stated goals,
or the milestones, and believe that there will be no useful impact.

>people think there's a justification to hold the BOF.

This DTN  BOF aims to set up a WG to bring the bundle protocol to standards
track. I believe there is no merit in holding this BOF, because there
is no merit in bringing the bundle protocol to IETF standards track.
I've previously given my reasoning.

There are a number of topics asking for BOFs and time at IETF 90:
http://tools.ietf.org/bof/trac/

I view the DTN BOF as the least deserving of time, and would not
want to disadvantage another BOF request simply to give time to
DTN over that BOF. DTN is, in my view, the least deserving of those
requests.

There's already a DTNRG where the bundle protocol has gotten 
time and attention. I would be in favour of a last DTNRG
meeting at a following IETF to wrap up any remaining items,
and then shutting that research group down as concluded.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Pete Resnick <[email-masked]>
Sent: Wednesday, 11 June 2014 2:58 AM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

pr

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 11 Jun 2014 02:15:46 +0000

Lloyd's concern, as I understand it, is that there is limited time for BoFs at IETF90; if time is allotted to a BoF whose topic is the possible formation of a standards-track working group for the DTN protocols then some other worthy BoF request must be denied.

That seems like a valid concern to me, but I nonetheless think that a DTN BoF should be scheduled at IETF90.  My reason for this is that I think forming a working group aimed at standardizing the DTN protocols for the Internet is important and worthwhile.  Whether it is more important and worthwhile than the objectives of the other IETF90 BoF requests is a topic that we haven't explored on this list.  I'm happy to try to contribute to that discussion if that's the discussion we need to have.  But in the meantime I can try to explain briefly my opinion of the importance of forming a DTN working group in IETF.

My interest in DTN does indeed originally stem from wanting to be able to integrate space flight mission communications with Internet communications on Earth.  The best way to do that seemed -- and seems -- to me to develop standardized end-to-end protocols above the Internet transport layer.  As Lloyd has pointed out, the main protocol we have been working on resides at the same layer of the stack as HTTP.  But where HTTP was (as I understand it) specifically designed for the exchange of hypertext between clients and servers, Bundle Protocol and its supporting protocols were instead specifically designed for the peer-to-peer exchange of data of arbitrary semantics where the round-trip time between peers might routinely -- for one reason or another -- be measured in milliseconds, minutes, or days at various times.

It may well be possible to adapt HTTP to accomplish this purpose, just as I expect it would be possible to use Bundle Protocol to exchange hypertext between clients and servers.  But in each case I believe there are carefully considered operational features that make the protocols particularly well-suited to the jobs they were designed to do.  So I think the Internet would be well served by formal standardization of the protocols that have been developed in the DTN Research Group.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Pete Resnick [[email-masked]]
Sent: Tuesday, June 10, 2014 9:58 AM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

pr

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jun 2014 02:49:04 +0000

I would just add that the technologies that are subject of this
proposed BoF are represented by far more interoperable running
code and open functional specifications than is typical for new
starts. So, there is reason to believe that an eventual working
group would have a substantial starting basis to build on.

However, I do not see that it is our business to speculate as to
how much room is available for BoFs for the IETF90 schedule, nor
which BoFs are more deserving than others.

Thanks - Fred

> From: Burleigh, Scott C (312G) [mailto:[email-masked]]
> Sent: Tuesday, June 10, 2014 7:16 PM
> To: Pete Resnick; Templin, Fred L
> Lloyd's concern, as I understand it, is that there is limited time for BoFs at IETF90; if time is
> allotted to a BoF whose topic is the possible formation of a standards-track working group for the DTN
> protocols then some other worthy BoF request must be denied.
> 
> That seems like a valid concern to me, but I nonetheless think that a DTN BoF should be scheduled at
> IETF90.  My reason for this is that I think forming a working group aimed at standardizing the DTN
> protocols for the Internet is important and worthwhile.  Whether it is more important and worthwhile
> than the objectives of the other IETF90 BoF requests is a topic that we haven't explored on this list.
> I'm happy to try to contribute to that discussion if that's the discussion we need to have.  But in
> the meantime I can try to explain briefly my opinion of the importance of forming a DTN working group
> in IETF.
> 
> My interest in DTN does indeed originally stem from wanting to be able to integrate space flight
> mission communications with Internet communications on Earth.  The best way to do that seemed -- and
> seems -- to me to develop standardized end-to-end protocols above the Internet transport layer.  As
> Lloyd has pointed out, the main protocol we have been working on resides at the same layer of the
> stack as HTTP.  But where HTTP was (as I understand it) specifically designed for the exchange of
> hypertext between clients and servers, Bundle Protocol and its supporting protocols were instead
> specifically designed for the peer-to-peer exchange of data of arbitrary semantics where the round-
> trip time between peers might routinely -- for one reason or another -- be measured in milliseconds,
> minutes, or days at various times.
> 
> It may well be possible to adapt HTTP to accomplish this purpose, just as I expect it would be
> possible to use Bundle Protocol to exchange hypertext between clients and servers.  But in each case I
> believe there are carefully considered operational features that make the protocols particularly well-
> suited to the jobs they were designed to do.  So I think the Internet would be well served by formal
> standardization of the protocols that have been developed in the DTN Research Group.
> 
> Scott

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 11 Jun 2014 13:49:30 +0100

Hi.

I would be happy to see a BoF at IETF90, but I think we need to be
clearer about what would be the expected usage of the work that would
come out a WG that was formed as a result.  I have the impression from
what I have seen on the mailing list that the work might well be
dominated by the requirements of the space use case but the charter is
currently silent on the intentions.  

Personally I am keen to see DTN used in space but I am also still a
believer in terrestrial usage.  There is clearly a tension between
getting something done quickly and efficiently for the space case where
there is potential for (relatively) short term (nothing is really that
short term in space exploration!) deployment, and updating the BP etc in
a way that will also move along the terrestrial usage where the
requirements are slightly different and not so well set in concrete.

The lack of clarity over intended usage could well have a bad impact on
the WG if it results in disagreements over the specifications.  It also
shows up in what is *not* in the charter. most notably in the absence of
any consideration of how to route the bundles that BPbis handles.  IMO a
DTN system that doen't address bundle routing is only half-baked. 

There seems to be a reasonable concensus that Contact Graph Routing
(CGR) would be appropriate for the space case.  Now this is primarily a
centralized all-informed oracle based system so there isn't the need to
exchange advertisements and such like but it strikes me that there are
aspects of a CGR that might need standardization such as disseminating
contact and route information to remote nodes, notifying the oracle of
traffic requests and ideas for handling failures such as notifying the
oracle that things didn't work as intended.  I therefore think that work
on CGR should be part of the charter at least (I understood that CCSDS
was thinking about it but that work seems to have stalled).

On the terretrial front, one of the major barriers to progress has been
the lack of an effective, reasonably general purpose, opportunistic
routing protocol despite the immense amount of academic work that has
been put in.  I believe (and am trying to put some concrete answers into
practice) that this is a soluble problem but it limits the current
deployability of DTN outside the space sector.

It may be that this problem is seen as a show stopper for the
terrestrial use case and, hence, that the WG should be entirely devoted
to the space case.  Personally I think this would be a shame and I would
be less enthusiastic about working with this limited agenda.  However,
if that agenda is the case, the charter ought to be clear and the IESG
needs to be aware of where things are going. 

BTW I concur with Lars that the timescales in the charter proposal are
wildly optimistic.

Regards,
Elwyn

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 11 Jun 2014 15:49:10 +0200

Hello everybody!

> requirements are slightly different and not so well set in concrete.

While it is true that requirements for space scenarios seems to be much clearer, we (IBR) have been using the BP solely for various terrestial scenarios over the last years. While not everything is perfect, we had a profound feeling that the BP is sort of "good enough". Of course we followed the various semi-regular what-is-time? what-is-end-to-end? SDNV-Flexble-or-Epic-Fail? discussions on dtn-interest. The key point is: Mostly we _followed_, not so much participated. Of course there have been some heated lunch break discussions over all these things within our group, but for the most part it did not matter that much in the application.

Consider, that today we use "responsive" desktop-like applications written in Javascript using text-based JSON formats over non-latency optimized links using HTTP protocols. That is (literally) wrong on so many levels. Some hacky/impressive engeneering such as WebSockets/SPDY and ridicoulously optimized JavaScript engines  etc. are used to make it less painful. But it works fine, doesn't it? So we feel, compared to that,  we are of to quite a good start with the BP!

So generally, we are in favor of the idea of slightly polishing/repairing the BP without starting from scratch. Which is the correct path or institution to do it, and whether the BoF is the correct way to go, we can not say. The inner workings of the IETF and stuff are magical to us.

> DTN system that doen't address bundle routing is only half-baked. 

I know we had some discussion at some conference or workshop about this. I believe routing (as in "a better Epidemic/Prophet") is not neccessary for terrestrial DTN applications. Most of the time we have small scale networks (Flooding/Gossipping is fine), or highly application-specific solutions (nobody would use a general purpose routing mechanism if the application is public transportation). For interconnection we have the internet/ip, so we just need naming there. I know, we can have the discussion and agree to disagree, so I would rephrase it like this

"IMO a DTN system that doesn't address bundle routing is only half-baked. "
Yes, defintely. At least you should know how to get stuff from A to B in your application.

However I would add
"Routing is of no concern for the core BP(bis) specification"
Just as the IPv(4/6) main specs do not say much about routing. 

So there could be specifications on top specifying routing mechanisms. And if the space-community knows exactly what they want, they should go forward with it. I feel this does not hurt us terrestrial guys. The most magic routing mechansim should still work on top of an unmodified BP. In our implementation, once two nodes meet there is a magical routing handshake, so the  peers knows what routing the communication partner is using. That might be the only  thing that should be nailed in an official way on top of the current BP to be safe for the future (some baseline approaches such as "only direct delivery please" could be made mandatory) .

> deployability of DTN outside the space sector.
Again, I think it is not such a large barrier, even though usable general purpose large-scale opportunistic routing would certainly be nice. 

> needs to be aware of where things are going. 

I think that barrier for terrestrial applications would not get any harder to cross, even if the WG focusses more on space missions. As long as us terrestrians keep an open eye to what is done and make sure nothing important gets cut away form the BP and the system remains open enough with regard to routing. Developing and specifying the perfect, mandatory opportunistic routing within the WG would probably fail, because as you have pointed out so far "despite the immense amount of academic work that has been put in" nothing came out. 

But that is no reason to be less enthusiastic! :)

MfG

Sebastian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jun 2014 15:56:31 +0000

Hi Elwyn,

See below for some responses:

> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2014 5:50 AM
> To: Templin, Fred L

The charter is open for discussion as input to the BoF. I too
want for the charter to point the way to uses cases beyond just
space-based. 

> believer in terrestrial usage.

Concur.

> There is clearly a tension between

Whatever gets standardized should apply equally for space-based
and terrestrial. If more is needed to fully support opportunistic
terrestrial use cases beyond what is accomplished in the initial
chartered work items, then the additional items will be brought
in through a rechater.

> DTN system that doen't address bundle routing is only half-baked.

The initial charter calls for a simple CL; it could also call
for a simple routing mechanism, e.g., CGR.

> was thinking about it but that work seems to have stalled).

I think that is a reasonable suggestion, and would be happy to
entertain suggestions on charter amendments. But, do we need to
do that before the BoF or as an output of the BoF?

> deployability of DTN outside the space sector.

Not necessarily. I think we can also consider coordinated
terrestrial use cases where CGR is sufficient as in-scope
for the initial charter.
 
> needs to be aware of where things are going.

Agree that the charter needs to point the way to a broader set
of use cases beyond space-based and coordinated terrestrial even
if it is beyond the scope of the initial work items.

> BTW I concur with Lars that the timescales in the charter proposal are

Which of the work items do you believe have unrealistic timescales?

Thanks - Fred

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 11 Jun 2014 19:21:27 +0100

Hi, Sebastian.

In the light of what you say below, I think it would be useful to
suggest a couple of use cases that should be kept in mind during the
update of the BP so that we can incorporate them into the charter asap.

More below...

On Wed, 2014-06-11 at 15:49 +0200, Sebastian Schildt wrote:
> While it is true that requirements for space scenarios seems to be
> much clearer, we (IBR) have been using the BP solely for various
> terrestial scenarios over the last years. While not everything is
> perfect, we had a profound feeling that the BP is sort of "good
> enough". Of course we followed the various semi-regular what-is-time?
> what-is-end-to-end? SDNV-Flexble-or-Epic-Fail? discussions on
> dtn-interest. The key point is: Mostly we _followed_, not so much
> participated. Of course there have been some heated lunch break
> discussions over all these things within our group, but for the most
> part it did not matter that much in the application.

Indeed I have been involved in a number of projects that have tried out
various routing schemes but, as you say, for most purposes the BP is
"good enough".  I have identified a number of issues that need
addressing but this is not the moment to go into them. 
> 
> Consider, that today we use "responsive" desktop-like applications
> written in Javascript using text-based JSON formats over non-latency
> optimized links using HTTP protocols. That is (literally) wrong on so
> many levels. Some hacky/impressive engeneering such as WebSockets/SPDY
> and ridicoulously optimized JavaScript engines  etc. are used to make
> it less painful. But it works fine, doesn't it? So we feel, compared
> to that,  we are of to quite a good start with the BP!

Definitely +several!  
> 
> So generally, we are in favor of the idea of slightly
> polishing/repairing the BP without starting from scratch.

Agreed.  The difficulty will be deciding what constitutes slightly.
Again that is a discussion either at the BOF or more likely once the WG
is approved.

>  Which is the correct path or institution to do it, and whether the
> BoF is the correct way to go, we can not say. The inner workings of
> the IETF and stuff are magical to us.

The key thing is to get a standards track specification for BPbis.  This
is most conveniently done with an IETF WG which can coordinate
activities both within the work on the BPbis draft and with the
auxiliary items mentioned in the charter. For that the process needs a
BoF and, if the BoF goes well, approval by the IESG/IAB to form a new
WG.

Tomorrow is a key day when the decision to allow the BoF to take place
is made by the IESG/IAB. 

> 
> However, the point is: I feel, even if the following efforts will have
> a slight focus on space applications, not much will be lost for
> terrestrial applications, if things are still based on the BP.
> Especially if the main difference is seen as routing:
> 
> > 
> I know we had some discussion at some conference or workshop about
> this. I believe routing (as in "a better Epidemic/Prophet") is not
> neccessary for terrestrial DTN applications. Most of the time we have
> small scale networks (Flooding/Gossipping is fine), or highly
> application-specific solutions (nobody would use a general purpose
> routing mechanism if the application is public transportation). For
> interconnection we have the internet/ip, so we just need naming there.
> I know, we can have the discussion and agree to disagree, so I would
> rephrase it like this
> 

Absolutely:  My opinion is that the charter needs to say something about
routing immediately.  This wouldn't affect the work items already
identified but would add an extra item or two to begin the process of
specifying both CGR and getting the requirements in place for an
opportunistic protocol.  This is partly political to show that we
haven't forgotten routing and partly to snsure we don't do anything too
stupid in the other work items that will later screw up routing
(addressing is a key area!)
> 
> So there could be specifications on top specifying routing mechanisms.
> And if the space-community knows exactly what they want, they should
> go forward with it. I feel this does not hurt us terrestrial guys. 

Probably not.. but we need to keep a good watching brief and contribute
as necessary to ensure that this remains the case! (as you say below).

> The most magic routing mechansim should still work on top of an
> unmodified BP. In our implementation, once two nodes meet there is a
> magical routing handshake, so the  peers knows what routing the
> communication partner is using. That might be the only  thing that
> should be nailed in an official way on top of the current BP to be
> safe for the future (some baseline approaches such as "only direct
> delivery please" could be made mandatory) .

I *think* what I am hearing here is that we should have a standardized
discovery protocol.  I agree (and I think it has been mentioned
elsewhere on the list).
> Again, I think it is not such a large barrier, even though usable
> general purpose large-scale opportunistic routing would certainly be
> nice. 
> 
> > 
> I think that barrier for terrestrial applications would not get any
> harder to cross, even if the WG focusses more on space missions. As
> long as us terrestrians keep an open eye to what is done and make sure
> nothing important gets cut away form the BP and the system remains
> open enough with regard to routing. 

Again +several!

> Developing and specifying the perfect, mandatory opportunistic routing
> within the WG would probably fail, because as you have pointed out so
> far "despite the immense amount of academic work that has been put in"
> nothing came out.

Right.  I am not proposing that we do that in this phase.  Get CGR
sorted out and any bits standardized that ought to be.  In parallel
(maybe back in DTNRG or just privately) try to sort out the
opportunistic protocol and if we do, come back later to get it
standardized.
> But that is no reason to be less enthusiastic! :)
Good!

Regards,
Elwyn

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 11 Jun 2014 13:59:45 -0500

On 06/11/2014 01:21 PM, Elwyn Davies wrote:
>> "IMO a DTN system that doesn't address bundle routing is only half-baked."

So, Martin and I haven't divided up the TSV BOFs yet, so I might be the 
responsible AD or I might be the irresponsible AD, but speaking as at 
least one of those two possibilities ...

Why would DTN routing be part of the work that might or might not be 
chartered in TSV?

Lumping transport and routing (and whatever else) in the IRTF DTNRG 
makes perfect sense, but I would have thought that we'd split transport 
and routing in an IETF WG.

Could someone help me understand?

Thanks,

Spencer

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 11 Jun 2014 20:03:36 +0100

Hi, Fred.

It looks like we are more or less singing from the same hymn sheet (or
whatever) here.

I would say that we should update the charter asap since it will be
discussed by the IESG/IAB probably tomorrow and it would be desirable to
make it clear what we are trying to achieve and that it hangs together
as a system.

Some specific points for the charter :

>From my experience of BoFS, I would say that you need to allow at least
30 minutes at the end for general discussion and decision 'hums'.
Accordingly you will have to claw back some time from all or most of the
segments.  It might be possible to scrap the registry discussion
altogether as it is a bit detailed.  Maybe replace it with a brief
discussion on routing mainly devoted to CGR.

Put in some other terrestrial use cases and generally even up the
balance between space and terrestrial.  I'll try and produce some actual
words later in a concrete redraft of the charter (also taking into
account Lars' comments).

I think that Lars is roughly right on the timescales... multiply
everything by 2 or maybe 3.

I would add two and possibly three or four work items:
- Specify a node discovery protocol (standards track)
- Describe the operation of CGR in a DTN BPbis environment
(informational doc) and identify if there is any useful standardization
work that needs to be done (this might be specifying information formats
for bundles passing contact schedules, traffic requests and
notifications about in a CGR network - could possibly be new BP block
types).
- (If the CGR work decides it is useful) Specify the information formats
and/or block types for CGR. (could be in a recharter)
 - (maybe) Specify requirements for a general purpose opportunistic
routing protocol.

Regards,
Elwyn

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 11 Jun 2014 22:04:31 +0200

Hi Elwyn, Hi *

> update of the BP so that we can incorporate them into the charter asap.

ok, so since we are rather implementation-driven, these points might be too technical/specific at this point, but here goes my wishlist. All of these things we really did use for some of our applications.

1. Network Types: I think the main differences are in the contact qualities: Hard-scheduled fully-deterministic IPN, and "soft-scheduled" things like public transportation (schedule+uncertainty, we put nodes on trams for example) and fully opportunistic (think mobile phones, we are doing Android apps). While most differences here would need to be absorbed by whatever routing is employed, and do not have an impact on the protocol per-se the latter two cases imply that:

2. We need discovery. I guess here the key thing is a generic description of a node. So far we have been using some variants of IPND. We have used that idea not only for IP, but also use it for ZigBee, and store a similar structure in the DHT when announcing nodes. What should be carried over to a standard is the general (extensible) key-value idea. Something like this could be specified as a prerequsite during node-to-node handshake. How to use this apart from node handshake (i.e. using IP multicast as is the case for IPND, or put it in an IEEE 802.15.4 datagram or whatever), should not be in the core specs. 
  2a) I guess one or two standard convergence layers should be proposed. Those could also specify how, on their medium (if it is not just PtP anyway) discovery is realized, preferably using the node-handshake data structure mentioned in 2

3. I don't want to revive the holy time-wars, but in our experience at the moment it s quite perfect that you can have "real" timestamps (expire this on christmas!) as well as the age block (throw it away after 2 months). Depending on the application, one works better than the other, so we really, really think we should make sure BP keeps both possibilites. Maybe some thought needs to be put into how to interoperate between both modes of operation (when should an age bloock be replaced with an expiration and vice versa. Alternatively just forbid mixing both worlds ..)

4. Not my area of expertise, but as has been said many times here: Bundle Security is a must, and needs to be simplified. While this might be an as-large a can of worms as routing, I think key management should be at least be "adressed". For example some of my colleagues have been worked implementing a "trust level" for exchanged keys. So they use every opportunitiy (as they might be scarce) between node contacts to exchange keys following a "trust on first use" model. This implies a lower trust level for a key than an user initiated exchange with verficiation, which for example you might want to visulaize if your application is an  end-user app on a mobile phone

5. Make sure delays can be months or milliseconds (it is fine now)

So going back to the bigger picture

- Applications: Make sure there is nothing in the protocol that fundamentally precludes the use of fully determinitic and fully opportunisitic scenarios.  Make sure ms delay (we are using this to remotely control robots from a mobile phone), work the same as days/weeks months. This is already working now, and we do not want to loose those capabilities for no good reason

- A generic discovery/handshake, i.e. nothing that every CL or routing needs to do for itself

- Allow relative (sensor nodes without RTC) and aboslute time (cold storage, disks, flash drives).

- Include streamlined security. Think about key exchange. 

That is all :) As I warned you before, this may be a little bit too technical at this stage. The main point is, while maybe some parts of what we currently have in our documents are a bit wishy-washy or have gotten overly general/complex, there is also lot of (not-hurting) flexibility that we should not loose.

MfG

Sebastian

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 12 Jun 2014 00:08:46 +0100

Hi, Spencer.

I'll try and rationalise why I think we might want to go this way...
see below.

> Could someone help me understand?

I'll try a bit...

1. DTN is a distinct architecture that does not really match the
terminology used to distinguish the areas in the IETF.  You could make a
perfectly valid case for the Bundle Protocol finding a home in Apps, TSV
or Internet areas.. and there is a management piece.  And it's new as a
standards track so it isn't going to get its own area and it's quite
small.  So we would be really grateful if you can give us a home until
we grow up. But enough of this neediness!

2. As a new system there are a number of parts that need to be in place
to have the bare bones of a complete system.  Arguably we should at the
very least be going for a SEC area WG to do the SBSP and maybe an OPS
area WG to do the management part (which isn't just a MIB).  Whether we
have critical mass to do all of these things in separate WGs in parallel
I wouldn't like to say.  However they are rather more closely coupled in
the DTN bundle architecture than in the conventional IP architecture and
would need to be closely coordinated.  The "routing" component is the
other piece which really needs to be in place to achieve a complete
story.

3. The space use case is most likely to get production deployment in the
short to medium term.  I put "routing" in quotes because the expected
way that DTN bundles will be forwarded is using Contact Graph Routing.
This is not a distributed system.  It is more in the nature of a
centralized application or oracle that is all-informed as regards
contact opportunities and traffic loads and provides a forwarding
schedule for nodes that is loaded into nodes in advance - effectively an
extension of the management story.  At least one implementation exists
(ION) but it is not formally documented and AFAIK there is no
standardized way for nodes to interact with the oracle to give it
information and find out what they should be doing.  It seems to me that
this part ought to be documented and standardized to complete a
minimalist DTN system for space (and for some terrestrial applications
also).

4. The opportunistic routing story is not something we can start on at
present as we don't know what it will be yet.  This would be nearer a
real routing story although (a.s.) still be entirely different from IP
routing systems. If and when we have a solution to standardize, this one
may well be worth its own WG but that is a story for another day.  What
might make sense is to devote some effort to a requirements document to
ensure that the BPbis can handle what is needed.

5. So overall, I see that CGR is effectively an aspect of management
rather than a routing protocol in the IP sense when it comes to bits on
the wire/aether.  So, Spencer, if you are prepared to host the
management part in the existing charter, then CGR can be viewed as an
extension of this.    

I hope this helps a bit.
 
Cheers,
Elwyn

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 11 Jun 2014 23:08:47 -0500

Hi, Elwyn,

Thanks for the quick and helpful response. See inline.

Spencer

> management part in the existing charter, then CGR can be viewed as an

None of this surprises me a lot (I never worked on DTN, but did pay 
attention to it from time to time). I was responding to a note about 
keeping options open for routing, and wondered if having a completely 
different home for routing would help enforce that separation.

IIUC, the first targeted use case can base routing decisions on a 
centralized oracle, so wouldn't particularly benefit from RTG clue; if 
you are able to keep a solid fence between the rest of DTN and routing 
in a single working group, any subsequent work that looks more like The 
Distributed Routing System We Know And Love could be spun up in a RTG 
working group, if that seems helpful, with the subsequent output 
parachuted in as a CGR replacement.

Did I get that right?

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 12 Jun 2014 08:05:44 +0100

Hi, Spencer.

Phew!

A bit more below..

> parachuted in as a CGR replacement.

Almost.  It is unlikely that the space use case would ever use anything
but CGR for the foreseeable future.  Celestial mechanics, resource
scheduling on the ground stations and for the most part unidirectional
links means that anything more opportunistic isn't realistic. Other
forms of routing would support more terrestrial use cases and extend the
penetration of DTN rather than replacing CGR.

Cheers,
Elwyn

---

From: Nikolaos Bezirgiannidis <[email-masked]>
Date: Thu, 12 Jun 2014 10:47:11 +0300

Hi Elwyn, All

I agree that CGR standardization will be an important initial step towards the right direction for the DTN WG. More below.

> minimalist DTN system for space (and for some terrestrial applications

In the management part, just to inform you that in last year’s Chants workshop we have presented Contact Plan Update Protocol (CPUP) and a dissemination mechanism to reactively inform nodes about contact plan updates. It is also in our future plans to implement it in ION.

http://dl.acm.org/citation.cfm?id=2505499

Regards,
Nikos

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 12 Jun 2014 06:34:56 -0500

> penetration of DTN rather than replacing CGR.

Thanks for the clue :-)

And I'm fine housing the centralized "routing-lite" function in the same 
working group, unless Adrian or Alia clue-by-four me (which is 
appreciated when it's needed).

Spencer

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 12 Jun 2014 16:41:50 +0200

Hi all,

Yes, it is time to work on a charter on **this list**.

One point that came up during the IESG review is if the charter should 
include work that re-evalutes the DTN architecture and figures out if 
other protocols are neeeded or if the choices for the bundle protocol is 
the right forward.

Thanks,

   Martin

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jun 2014 14:54:21 +0000

Hello Martin,

> Yes, it is time to work on a charter on **this list**.

See below for the current draft charter:

Fred

---

Chair(s):

      TBD

      TBD

Mailing list:

      

  
    
Goals and Milestones:

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 12 Jun 2014 17:07:30 +0200

Hi,

two small remarks

> 	  timely conversational data exchange must be excluded from the

The third point seems redundant. Also during contact between two nodes (not end-to-end) you might have for example some handshaking that "rely on timely conversational data exchange". Maybe you rather want to say something about whether and how unidirectional links are supported.

> 	the integrity of the infrastructure.
Seems a pretty bad idea for most applications. Not only, but especially in a DTN.  I think while key management is definitely a very(!) important point, the charter should not already fix a "solution" (that some might argue is none). What about a more neutral

> Delay-tolerant security key management schemes that can protect the integrity of a DTN  network

MfG

Sebastian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jun 2014 16:59:27 +0000

Hi Sebastian,

> From: Sebastian Schildt [mailto:[email-masked]]
> Sent: Thursday, June 12, 2014 8:08 AM
> To: Templin, Fred L
> Cc: Martin Stiemerling; Elwyn Davies; [email-masked]
> The third point seems redundant.

I'm not sure I see a problem with leaving the bullet as is, because the
previous bullet talks about hop-by-hop considerations while the bullet
in question talks about end-to-end. Is there a problem with leaving what
we already have?

> Also during contact between two nodes (not end-to-end) you might have
> for example some handshaking that "rely on timely conversational data
> exchange". Maybe you rather want
> to say something about whether and how unidirectional links are supported.

How would the envisioned convergence layers deal with unidirectional
links? I.e., if we can't get some acknowledgment of reception then
there is no way to ensure reliable delivery. Or, am I missing your
point?

> Seems a pretty bad idea for most applications. Not only, but especially in a DTN.  I think while key
> management is definitely a very(!) important point, the charter should not already fix a "solution"
> (that some might argue is none). What about a more neutral
> 

I'm OK with making a more neutral statement, but we should have an idea
from the onset as to whether we want to standardize one solution to the
problem or multiple solutions. For example, do we anticipate different
solutions for different use cases, or a one-size-fits-all.

Thoughts?

Thanks - Fred

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 12 Jun 2014 19:47:56 +0200

Hi Fred, 

> in question talks about end-to-end. Is there a problem with leaving what

I guess I was typing the mail while thinking. So when reading this, I thought about what you meant by "timely conversational data exchange", because of course for communication between arbitrary endpoints (end-to-end) we can not do it. That  is the essence of DTN, so I was puzzled, why it was explicitly mentioned here. Then I thought about "contacts", i.e. two nodes connected directly via a CL exchanging BP data. In that case - at least in all  usecases I have experienced - those two nodes could do a lot of request-reply stuff for handshaking/synchronizing storages, talk about routing etc. So it did not seem good to me, if the paragraph could be understood to exclude that mode of operation.

> there is no way to ensure reliable delivery. Or, am I missing your

I kept thinking (woah.. seems I really did a lot of thinking today:) ) about space applications, where maybe you already have a delay of "minutes" upon a direct contact, and thus would want to avoid roundtrips for BP housekeeping, which is why I came to think about the extreme case of unidirectional node-to-node links. I do not need them at all. But do the space guys need them? 
With the current BP it is certainly possible: Blast a valid bundle over some link, using a convergence layer that has no additonal hadnshake built in, and it should work. So I just think it is an interesting question, whether future BP should be able to work over unidirectional links. A mandatory handshake on the BP level would prevent this.

So in a nuthsell: I have nothing against the paragraph as it is, but  I felt it just restates the obvious, and then weird thoughts came flying through my mind :)

> solutions for different use cases, or a one-size-fits-all.

I am not clear myself, how much of this should be specified. Definitely we would need the notion of keys and how to flag bundles as signed or encrypted with such-and-such algorithm and key. I think this is what the current BSP does, and what a streamlined version provides. I would also argue, that some generic protocol to exchange keys is probably useful. Apart from that, things really differ, depending on whether you just want to use a vanilla public/private key system, whether you want to built certificates on top, or whether you intend to use some ID-based cryptography. 

As people might need different solutions, just saying for example "Ok we use X509 and are done with it“, might not be a good idea. I really think an important question for the WG later is, "how much" do we specify. An example I am a little more familiar with: IEEE 802.15.4. The specification basically just says, „Ok you can use AES, the key is this long, switch on this flag to show it is AES." And that is that. Where do the keys come from? Your problem! Now there IS also Zigbee, an  industry supported standard which provides higher layers on top of 802.15.4. ZigBee says more about key exchange and related stuff. But then again: Nobody uses ZigBee! Most people/companies who call their stuff ZigBee basically just use the 802.15.4 base spec and do their own stuff on top. Go figure. So the art is to specify enough, that it will not be useless, but not too much so that it is overly complex or does not fit any application. Therefore I think, for the initial charta, the point should really be quite open and neutral.

Hope this makes things clearer :)

MfG

Sebastian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jun 2014 18:25:52 +0000

Hi Sebastian,

> Sent: Thursday, June 12, 2014 10:48 AM
> To: Templin, Fred L
> I guess I was typing the mail while thinking. So when reading this, I thought about what you meant by
> "timely conversational data exchange", because of course for communication between arbitrary endpoints
> (end-to-end) we can not do it. That  is the essence of DTN, so I was puzzled, why it was explicitly
> mentioned here.

IMHO, it is worth mentioning here because BP is a transport over which
end-to-end conversational data exchanges between endpoints will often
not be possible. This is a paradigm-breaking concept to the transport
area, and so seems worth mentioning to set the right context.

> Then I thought about "contacts", i.e. two nodes connected directly via a CL exchanging
> BP data. In that case - at least in all  usecases I have experienced - those two nodes could do a lot
> of request-reply stuff for handshaking/synchronizing storages, talk about routing etc. So it did not
> seem good to me, if the paragraph could be understood to exclude that mode of operation.

That would be a hop-by-hop consideration, which is intended to be
covered by the previous bullet:

==> 	- Because end-to-end connectivity can never be assumed, each node
==> 	  on the path between source and destination must be prepared to
==> 	  handle incoming "bundles" of data that cannot immediately be
==> 	  forwarded.

Do you suggest any changes to this bullet?
 
> I kept thinking (woah.. seems I really did a lot of thinking today:) ) about space applications, where
> maybe you already have a delay of "minutes" upon a direct contact, and thus would want to avoid
> roundtrips for BP housekeeping, which is why I came to think about the extreme case of unidirectional
> node-to-node links. I do not need them at all. But do the space guys need them?
> With the current BP it is certainly possible: Blast a valid bundle over some link, using a convergence
> layer that has no additonal hadnshake built in, and it should work. So I just think it is an
> interesting question, whether future BP should be able to work over unidirectional links. A mandatory
> handshake on the BP level would prevent this.

What does anyone else think about unidirectional link? Any text change
suggestions?

> So in a nuthsell: I have nothing against the paragraph as it is, but  I felt it just restates the
> obvious, and then weird thoughts came flying through my mind :)

Since this is intended for the IETF transport area where discussing DTN
is essentially breaking new ground, I think it is useful to include the
bullets for the benefit of new readers who may have no former experience
with DTN and hence insufficient context for understanding the charter.
Is it OK for you?

> I am not clear myself, how much of this should be specified. Definitely we would need the notion of
> keys and how to flag bundles as signed or encrypted with such-and-such algorithm and key. I think this
> is what the current BSP does, and what a streamlined version provides. I would also argue, that some
> generic protocol to exchange keys is probably useful. Apart from that, things really differ, depending
> on whether you just want to use a vanilla public/private key system, whether you want to built
> certificates on top, or whether you intend to use some ID-based cryptography.
> 
> As people might need different solutions, just saying for example "Ok we use X509 and are done with
> it", might not be a good idea. I really think an important question for the WG later is, "how much" do
> we specify. An example I am a little more familiar with: IEEE 802.15.4. The specification basically
> just says, "Ok you can use AES, the key is this long, switch on this flag to show it is AES." And that
> is that. Where do the keys come from? Your problem! Now there IS also Zigbee, an  industry supported
> standard which provides higher layers on top of 802.15.4. ZigBee says more about key exchange and
> related stuff. But then again: Nobody uses ZigBee! Most people/companies who call their stuff ZigBee
> basically just use the 802.15.4 base spec and do their own stuff on top. Go figure. So the art is to
> specify enough, that it will not be useless, but not too much so that it is overly complex or does not
> fit any application. Therefore I think, for the initial charta, the point should really be quite open
> and neutral.

I don't mind taking a slightly revised version of your proposed bullet:

  o A delay-tolerant security key management scheme that can protect
    the integrity of a DTN network.

Would that be OK?

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 12 Jun 2014 23:58:15 +0000

This is the wrong venue for a technical deep dive on this topic, but because it bears on the charter I want to mention it: I have been thinking for some time that CGR -- operating on contact plans that are extended to include not only scheduled contacts but also contacts that are predicted with less than 100% confidence -- might be a general enough framework to hang opportunistic routing on as well, leveraging huge chunks of the innovative routing practice that has already emerged in academic research.

I'm happy to try to defend this modest proposal in another thread.  For now, I at least wanted to add a vote of optimism that a general solution to the problem of DTN routing might be possible and to agree that investigating that possibility would be a worthwhile topic for the charter.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, June 11, 2014 8:57 AM
To: Elwyn Davies
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

....

> The lack of clarity over intended usage could well have a bad impact 
> on the WG if it results in disagreements over the specifications.  It 
> also shows up in what is *not* in the charter. most notably in the 
> absence of any consideration of how to route the bundles that BPbis 
> handles.  IMO a DTN system that doen't address bundle routing is only half-baked.

The initial charter calls for a simple CL; it could also call for a simple routing mechanism, e.g., CGR.

> (CGR) would be appropriate for the space case.  Now this is primarily 
> a centralized all-informed oracle based system so there isn't the need 
> to exchange advertisements and such like but it strikes me that there 
> are aspects of a CGR that might need standardization such as 
> disseminating contact and route information to remote nodes, notifying 
> the oracle of traffic requests and ideas for handling failures such as 
> notifying the oracle that things didn't work as intended.  I therefore 
> think that work on CGR should be part of the charter at least (I 
> understood that CCSDS was thinking about it but that work seems to have stalled).

I think that is a reasonable suggestion, and would be happy to entertain suggestions on charter amendments. But, do we need to do that before the BoF or as an output of the BoF?

> On the terretrial front, one of the major barriers to progress has 
> been the lack of an effective, reasonably general purpose, 
> opportunistic routing protocol despite the immense amount of academic 
> work that has been put in.  I believe (and am trying to put some 
> concrete answers into

Not necessarily. I think we can also consider coordinated terrestrial use cases where CGR is sufficient as in-scope for the initial charter.

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 00:02:18 +0000

Martin,

are minutes or a recording of that IESG review discussion available?

thanks,

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: dtn <[email-masked]> on behalf of Martin Stiemerling <[email-masked]>
Sent: Friday, 13 June 2014 12:41 AM
To: Elwyn Davies; Templin, Fred L; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Hi all,

Thanks,

   Martin

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Fri, 13 Jun 2014 00:22:38 +0000

Making sure that the charter addresses all of the capabilities that Sebastian identifies here make sense to me.  On #3 in particular, I enthusiastically agree: both mechanisms have value, and I think we can devise specifications that will let them coexist and interoperate in the same world.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Sebastian Schildt
Sent: Wednesday, June 11, 2014 1:05 PM
To: Elwyn Davies
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN BoF Proposal for IETF90

Hi Elwyn, Hi *

MfG

Sebastian

>>> getting something done quickly and efficiently for the space case 
>>> where there is potential for (relatively) short term (nothing is 
>>> really that short term in space exploration!) deployment, and 
>>> updating the BP etc in a way that will also move along the 
>>> terrestrial usage where the requirements are slightly different and not so well set in concrete.
>> 
> Indeed I have been involved in a number of projects that have tried 
> out various routing schemes but, as you say, for most purposes the BP 
> is "good enough".  I have identified a number of issues that need 
>> many levels. Some hacky/impressive engeneering such as 
>> WebSockets/SPDY and ridicoulously optimized JavaScript engines  etc. 
>> are used to make it less painful. But it works fine, doesn't it? So 
>> we feel, compared to that,  we are of to quite a good start with the BP!
> 
> Definitely +several!  
>> 
> Again that is a discussion either at the BOF or more likely once the 
> WG is approved.
> 
> The key thing is to get a standards track specification for BPbis.  
> This is most conveniently done with an IETF WG which can coordinate 
>> However, the point is: I feel, even if the following efforts will 
>> have a slight focus on space applications, not much will be lost for 
>>> on the WG if it results in disagreements over the specifications.  
>>> It also shows up in what is *not* in the charter. most notably in 
>>> the absence of any consideration of how to route the bundles that 
>>> BPbis handles.  IMO a DTN system that doen't address bundle routing is only half-baked.
>> 
>> 
> Absolutely:  My opinion is that the charter needs to say something 
> about routing immediately.  This wouldn't affect the work items 
> already identified but would add an extra item or two to begin the 
> process of specifying both CGR and getting the requirements in place 
> for an opportunistic protocol.  This is partly political to show that 
> we haven't forgotten routing and partly to snsure we don't do anything 
> too stupid in the other work items that will later screw up routing 
> Probably not.. but we need to keep a good watching brief and 
> contribute as necessary to ensure that this remains the case! (as you say below).
> 
>>> opportunistic routing protocol despite the immense amount of 
>>> academic work that has been put in.  I believe (and am trying to put 
>>> some concrete answers into
>>> terrestrial use case and, hence, that the WG should be entirely 
>>> devoted to the space case.  Personally I think this would be a shame 
>>> and I would be less enthusiastic about working with this limited 
>>> agenda.  However, if that agenda is the case, the charter ought to 
>>> be clear and the IESG needs to be aware of where things are going.
>> 
>> long as us terrestrians keep an open eye to what is done and make 
>> sure nothing important gets cut away form the BP and the system 
>> remains open enough with regard to routing.
> 
> Again +several!
> 
>> Developing and specifying the perfect, mandatory opportunistic 
>> routing within the WG would probably fail, because as you have 
>> pointed out so far "despite the immense amount of academic work that has been put in"
>> nothing came out.
>