Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

From: Eric Travis <[email-masked]>
Date: Fri, 2 May 2014 02:38:28 -0400

Will,

I'm a bit confused - which has caused me to pause prior to responding.

A few days ago in this thread, you expressed a concern about scalability:

Also, if we are talking large scale deployments, we really need to address
scalability.  To start with, I know some where investigating use of DTN
for thousands to tens of thousands of units.

Then in advocating an example for the need for bundle authentication
mechanisms, you espoused possibly the least
scalable *policy* for using authentication.

In response to my subsequent blathering (not recopied, but available
below), you reply:

It seems like this assumes a closed system and thus, scaling is not all
> that much of a consideration relative to a global or universal deployment.
>

However, your "I'm not about to let just anyone use my truck" example that
led to my response was hardly advocating an "open" access policy... So, I
suppose I am to take the quoted text to mean that there is no scalability
issue with authentication?

I simply don't understand (nor can I agree to) for "closed"
networks/systems, scaling is not all that much of a consideration relative
to a global or universal deployment).

Hence, I am confused and curious, but more than willing to simply agree to
disagree - with whatever happens to be the argument.
OK, so we're done with that.

Transitioning to the non-sequitur part of your message:

Much of Bundling has, IMHO, always been very space centric.
>   Understandably so, as it did start as Interplanetary Network (IPN) with
> origins in CFDP.
> http://public.ccsds.org/publications/archive/720x1g3.pdf
>
> http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF
>

 No.

and

No.

Addressing the Second No first - IPN/Bundling did NOT have its origins with
CFDP.

You meant that  the *Licklider Transmission Protocol* (*LTP*) has its
origins in CFDP. As I remember, LTP was influenced by and ultimately can
(/does?) replace the "lower half" of CFDP. I *think* BP over LTP can be
used in place of CFDP, but wouldn't trust that equivalence
to be correct.

Certainly CFDP experience influenced at least one of the IPN team members,
but within the group, larger influences on the conceptual development of
Bundling included SMTP, NNTP, UUCP - as well as the evolution of the US
Postal Service (the Pony Express dominated discussions in the very earliest
meetings).

http://www.ietf.org/rfc/rfc2821.txt
http://www.ietf.org/rfc/rfc3977.txt
https://www.ietf.org/rfc/rfc976
https://www.usps.com

All of which can be considered space centric.

Leading to the First No - "Much of Bundling always been space centric":

IPN leaf nodes (in situ networks) performing geological surveys while
rolling around on a distant (extra-terrestrial) rock or floating atop the
Bering Sea were considered equally valid and part of the same problem
space.  If you mean to equate "space centric" with "not
directly/permanently connected with the terrestrial internet", then your
assumption is correct (IMHO).

(Speaking only for *myself*, not anyone else involved with the IPN study)

The defining characteristics underlying the IPN was the assumption that the
problem space could *not* depend  on ubiquitous infrastructure (power,
communications) - whatever infrastructure was required (including time
synchronization) was to be provided
by the network itself. Nor could one assume the ultimate endpoints of
communications would be supporting identical/pairwise-compatible
communications stacks.   (At one point, there were Ten Commandments
regarding IPN assumptions, but the above works for this discussion)

The concept did indeed start with the desire to lay the groundwork for
supporting the eventual deployment  of IP-based networks as part of the
exploration of the Solar System - so I concede that is a "space centric"
goal.

The underlying "Interplanetary" meme provided a non-threatening backdrop to
consider different ways of doing things.  This is analogous to the way
Science Fiction has been used as a non-threatening means for exploring
social issues.

The context for the IPN (and bundling) could just have easily been a
terrestrial environment where nations start deploying national internets,
each with their own naming/addressing systems and some with home-grown
networking stacks (network and transport protocols).  Anticipating the
deploying chunks of the Internet on and around remote rocks and snowballs
was a much more fun/attractive playground.

Fanciful > Distopian.

There has never been anything in bundling mechanisms (IPN or DTN) that was
"space centric". Space applicable, but not space centric.

 But, once this hit DTRNG, I think the hope was to make this more
> universal, which opened up a complete new user space and expectations.
>  However, to date, the terrestrial users have not found the protocol, as
> is, very deployable.  Space is a much smaller and much simpler deployment
> environment.  In many ways, Space  is very small and extremely predictable.
>

Strangely, my feeling has been that, over time, DTN became MORE "space
centric" than IPN.   Opportunistic connectivity seemed to be deprecated for
deterministic connectivity, communications & storage components are
considered to be more fault-tolerant and there seemed to be an increased
reliance of infrastructure (universal clock synchronization via GPS or
NTP). Consideration has seemed to favor deployments into rather controlled
environments. Publication of RFC 5050 seemed to serve as a lock on Bundling
development rather than being a stable checkpoint.  These are all simply my
perceptions, but over time DTN tended to get less interesting (to me).

Actually, space is *very* large, but the space exploration environment is a
lot better curated than a random terrestrial deployment. When deploying in
the space exploration environment one is able to leverage off of a LOT of
engineering and coordination.  The fact that you depict space a "simpler
deployment environment" is a terrific illustration of this.

I'm far from the biggest fan of RFC-5050, but could someone please
articulate what it is about the "protocol" that terrestrial users are
finding "not very deployable"?   Once upon a time, I put up a few DTN2
nodes and didn't find it any more frustrating than deploying Apache or
XMPP...

Regards,

Eric
[email-masked]

On Wed, Apr 30, 2014 at 8:46 AM, Ivancic, William D. (GRC-RHN0) <
[email-masked]> wrote:

>   In Line
>
>    From: Eric Travis <[email-masked]>
> Date: Wednesday, April 30, 2014 12:20 AM
> To: William Ivancic <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "Burleigh, Scott
> C (JPL-312G)[Jet Propulsion Laboratory]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
>
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>
> Will,
>
>  Are you suggesting that the (originating) sender should be validated at
> each
>  transfer point (from Bob's truck to my truck to your truck)?
>
>  Not necessarily every transfer point, just transfer points that care.
>
>
>      If this is even possible,
> it certainly won't scale.
>
>  Nor is it enforceable: What if Stephen enters into a secret side
> agreement with Lloyd to encapsulate bundles?
>
>  If they have such an agreement, I don't know that I care.
>
>
>  Way back in the days of the IPN (presumably back in the time "before
> gaining experience with reality" - nod to Lloyd), we used to talk about
>  admissions control...  The bundle sender was to be verified at the entry
> bundle portal. Only authorized sources could submit bundles.   As bundle
> nodes were to be "mutually suspicious" [1], the interacting bundle nodes
> would
> validate each other (at each contact episode) prior to exchanging bundles,
> but  bundles would travel between nodes w/o requiring subsequent
> individual
> source verifications (though there was to be a mandatory integrity check
> to verify
>  a content of the bundle was not altered by the intermediate "sending"
> node).
>
>  It seems like this assumes a closed system and thus, scaling is not all
> that much of a consideration relative to a global or universal deployment.
> Much of Bundling has, IMHO, always been very space centric.
>   Understandably so, as it did start as Interplanetary Network (IPN) with
> origins in CFDP.
> http://public.ccsds.org/publications/archive/720x1g3.pdf
>
> http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF
>
>
>  But, once this hit DTRNG, I think the hope was to make this more
> universal, which opened up a complete new user space and expectations.
>  However, to date, the terrestrial users have not found the protocol, as
> is, very deployable.  Space is a much smaller and much simpler deployment
> environment.  In many ways, Space  is very small and extremely predictable.
>
>
> Once the bundle was "in the system", there was no need to validate the
> source
> of bundles in transit.
>
>  Rather than "not letting just anybody use your truck", you don't let
> just any
>  other truck driver offload it's contents into your truck.  Truck drivers
> are not
> permitted to accept freight from unauthorized customers.
>
>  Thus, assumes a closed network.  No?
>
>
>
>

-- 

*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: <[email-masked]>
Date: Fri, 2 May 2014 08:38:11 +0000

No?

CFDP will in effect serve as a
prototype for the future Interplanetary Internet
(IPN) as envisioned by the IPN Study team: it en-
compasses a subset of the anticipated functionality of
the IPN, and it implements several key IPN design
concepts including store-and-forward operation with
deferred transmission and
concurrent transactions.

-- Burleigh,
OPERATING CFDP IN THE INTERPLANETARY INTERNET

SpaceOps 2002, I believe.

"Much of Bundling always been space centric":

 which would be why CCSDS is trying to standardise the thing.

"The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) "

ubiquitous clocks were in there from the start. ubiquitous perfect comms and storage reliability was assumed.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: dtn-interest <[email-masked]> on behalf of Eric Travis <[email-masked]>
Sent: Friday, 2 May 2014 4:38 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Will,

Then in advocating an example for the need for bundle authentication mechanisms, you espoused possibly the least

In response to my subsequent blathering (not recopied, but available below), you reply:

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.

However, your "I'm not about to let just anyone use my truck" example that led to my response was hardly advocating an "open" access policy... So, I suppose I am to take the quoted text to mean that there is no scalability issue with authentication?

I simply don't understand (nor can I agree to) for "closed" networks/systems, scaling is not all that much of a consideration relative to a global or universal deployment).

Hence, I am confused and curious, but more than willing to simply agree to disagree - with whatever happens to be the argument.
OK, so we're done with that.

Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

No.

and

No.

Addressing the Second No first - IPN/Bundling did NOT have its origins with CFDP.

You meant that  the Licklider Transmission Protocol (LTP) has its origins in CFDP. As I remember, LTP was influenced by and ultimately can (/does?) replace the "lower half" of CFDP. I *think* BP over LTP can be used in place of CFDP, but wouldn't trust that equivalence
to be correct.

Certainly CFDP experience influenced at least one of the IPN team members, but within the group, larger influences on the conceptual development of Bundling included SMTP, NNTP, UUCP - as well as the evolution of the US Postal Service (the Pony Express dominated discussions in the very earliest meetings).

IPN leaf nodes (in situ networks) performing geological surveys while rolling around on a distant (extra-terrestrial) rock or floating atop the Bering Sea were considered equally valid and part of the same problem space.  If you mean to equate "space centric" with "not directly/permanently connected with the terrestrial internet", then your assumption is correct (IMHO).

The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) - whatever infrastructure was required (including time synchronization) was to be provided
by the network itself. Nor could one assume the ultimate endpoints of communications would be supporting identical/pairwise-compatible communications stacks.   (At one point, there were Ten Commandments regarding IPN assumptions, but the above works for this discussion)

The concept did indeed start with the desire to lay the groundwork for supporting the eventual deployment  of IP-based networks as part of the exploration of the Solar System - so I concede that is a "space centric" goal.

The underlying "Interplanetary" meme provided a non-threatening backdrop to consider different ways of doing things.  This is analogous to the way Science Fiction has been used as a non-threatening means for exploring social issues.

The context for the IPN (and bundling) could just have easily been a terrestrial environment where nations start deploying national internets, each with their own naming/addressing systems and some with home-grown networking stacks (network and transport protocols).  Anticipating the deploying chunks of the Internet on and around remote rocks and snowballs was a much more fun/attractive playground.

Fanciful > Distopian.

There has never been anything in bundling mechanisms (IPN or DTN) that was "space centric". Space applicable, but not space centric.

But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.

Strangely, my feeling has been that, over time, DTN became MORE "space centric" than IPN.   Opportunistic connectivity seemed to be deprecated for deterministic connectivity, communications & storage components are considered to be more fault-tolerant and there seemed to be an increased reliance of infrastructure (universal clock synchronization via GPS or NTP). Consideration has seemed to favor deployments into rather controlled environments. Publication of RFC 5050 seemed to serve as a lock on Bundling development rather than being a stable checkpoint.  These are all simply my perceptions, but over time DTN tended to get less interesting (to me).

Actually, space is *very* large, but the space exploration environment is a lot better curated than a random terrestrial deployment. When deploying in the space exploration environment one is able to leverage off of a LOT of engineering and coordination.  The fact that you depict space a "simpler deployment environment" is a terrific illustration of this.

I'm far from the biggest fan of RFC-5050, but could someone please articulate what it is about the "protocol" that terrestrial users are finding "not very deployable"?   Once upon a time, I put up a few DTN2 nodes and didn't find it any more frustrating than deploying Apache or XMPP...

Regards,

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

On Wed, Apr 30, 2014 at 8:46 AM, Ivancic, William D. (GRC-RHN0) <[email-masked]<mailto:[email-masked]>> wrote:
In Line

From: Eric Travis <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 30, 2014 12:20 AM
To: William Ivancic <[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]>>, "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Will,

Are you suggesting that the (originating) sender should be validated at each
transfer point (from Bob's truck to my truck to your truck)?

Nor is it enforceable: What if Stephen enters into a secret side agreement with Lloyd to encapsulate bundles?

Way back in the days of the IPN (presumably back in the time "before
gaining experience with reality" - nod to Lloyd), we used to talk about
admissions control...  The bundle sender was to be verified at the entry
bundle portal. Only authorized sources could submit bundles.   As bundle
nodes were to be "mutually suspicious" [1], the interacting bundle nodes would
validate each other (at each contact episode) prior to exchanging bundles,
but  bundles would travel between nodes w/o requiring subsequent individual
source verifications (though there was to be a mandatory integrity check to verify
a content of the bundle was not altered by the intermediate "sending" node).

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.
Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.

Once the bundle was "in the system", there was no need to validate the source
of bundles in transit.

Rather than "not letting just anybody use your truck", you don't let just any
other truck driver offload it's contents into your truck.  Truck drivers are not
permitted to accept freight from unauthorized customers.

--
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: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Fri, 2 May 2014 15:09:04 +0000

I think this interesting discussion is a bit off-topic for this thread; how about moving it to a new one?

But while we’re here:

·         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP – a superset of what could be done with CFDP.

o   In that sense, CFDP was a prototype for IPN.  An entirely valid way of looking at the basic structure of IPN was to divide the CFDP monolith into three layers: the retransmission procedures of CFDP were eventually re-imagined in LTP, the CFDP store-and-forward overlay procedures were a crude checklist for the basic functionality of the Bundle Protocol, and CFDP itself would be whittled back to just file transfer, for which it was fine.

o   That said, I will certainly agree that most people involved in the early IPN work took their design ideas from their Internet experience rather than from familiarity with CFDP.  Ideas about IPN were always discussed in the context of what had already been shown to work (or not work) in the Internet.

·         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

·         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.  The DTN protocols are usually designed to be suitable for use in space networking, because in most cases that has been the most challenging environment for them: with a few exceptions, if a protocol will work in deep space then getting it to work on the surface of Earth is easy.

·         In particular, I don’t see how DTN can be viewed as growing more space-centric than the IPN work was.

o   Virtually all research published on DTN routing addresses opportunistic connectivity, not scheduled connectivity.

o   I can’t think of any DTN Internet Drafts that presume fault tolerance.  Mechanisms for detecting data corruption, either in transit or in situ, have been included in DTN since the publication of RFC 6257.  One might not care for those mechanisms, but that in itself seems like a pretty slender argument for claiming that DTN is space-centric.

o   Universal clock synchronization via GPS or NTP is a capability that has specifically not been available to spacecraft.  In any case I think removing this dependence is an issue on which DTNRG had long ago reached agreement (the Bundle Age I-D) before turning its attention elsewhere.

All of which, I will suggest, is moot at this point.  The question at hand is who among us is interested in standardizing the DTN protocols within IETF and who is not.  I think we’ve already got some sense of this from the posts so far on this thread, and I think it would be good to hear some more.

Scott

From: dtn-interest [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Thursday, May 01, 2014 11:38 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Will,

No.

and

No.

Fanciful > Distopian.

Regards,
Eric

Will,

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 May 2014 19:17:49 +0000

I will just add that Boeing cares about more than just space-based communications.

Thanks - Fred

From: dtn-interest [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
Sent: Friday, May 02, 2014 8:09 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

But while we’re here:

Scott

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

Will,

No.

and

No.

Fanciful > Distopian.

Regards,
Eric

Will,

---

From: Eric Travis <[email-masked]>
Date: Fri, 2 May 2014 15:43:08 -0400

Lloyd,

Wonderful to hear from you.  I'd been expecting your reply.

I do hope you get your game back soon, as you merely phoned in this effort.

No?

No.

You typed "CFDP IPN" into a search engine and this came up (4th in result
list for me)

This paper was new to me, so thanks!

Did you actually read Scott's paper?

Read the text that you quoted below again, heck read the whole paper - or
start at page 4.

So, still No.

> SpaceOps 2002, I believe.

Doesn't support your assertion,  I know.

So, yes - it really is No.

>   which would be why CCSDS is trying to standardise the thing.

 I imagine that CCSDS is "trying to standardize the thing" because some
member agencies are interested in using it and want to have an expectation
of interoperable cross-support service.  I haven't paid attention to CCSDS
activities in over a decade, but remember there was a push within part NASA
to "standardize" ethernet., a similar push to "standardize" HDLC. I also
know there was a working group for standardizing the encapsulating of IP
datagrams in in CCSDS frames.  By your argument, the motivation was because
ethernet, HDLC and IPv4 are all "space centric".

"The defining characteristics underlying the IPN was the assumption that
>> the problem space could *not* depend  on ubiquitous infrastructure (power,
>> communications) "
>>
>
>

Finally! - you are absolutely correct… unless you are referring to the IPN
rather than DTN.

Ubiquitous clocks:  As I stated in my previous message, the vision was that
one brings the infrastructure with them.  If you need synchronized clocks
you bring it with you.  Spacecraft tend to have excellent clocks - within
the IPN time was envisioned to be provided as a network service (with
proximate spacecraft serving as the local timebase).  If you were deploying
in a cave and needed synchronized time for operations, you bring that
infrastructure with you. Expiration times in bundles are even *more* beyond
the scope of this thread, so if you wanted to present them as proof of your
position, you would still be WRONG.

Ubiquitous perfect comms and storage reliability assumed: Wrong again.  I'm
getting tired, so - Mandatory integrity checking was lost in the transition
from IPN to DTN (it had been rolled into mutual suspicion of nodes).

Now,  am I try to correct you regarding the origins and assumptions of
underlying Saratoga?
Alternatively, I've been having some questions about my 5th birthday party
that you could probably resolve...

No bile, little obvious sarcasm, nothing burying an intelligent insight or
observation.

Simply not your best effort.

Do feel better Lloyd.

Regards,

Eric

On Fri, May 2, 2014 at 4:38 AM, <[email-masked]> wrote:

>  "The defining characteristics underlying the IPN was the assumption that
> the problem space could *not* depend  on ubiquitous infrastructure (power,
> communications) "
>
>
>
>   ------------------------------
> *From:* dtn-interest <[email-masked]> on behalf of Eric
> Travis <[email-masked]>
> *Sent:* Friday, 2 May 2014 4:38 PM
> *To:* Ivancic, William D. (GRC-RHN0)
> *Cc:* [email-masked]
>
> *Subject:* Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>   Will,
>
>  However, your "I'm not about to let just anyone use my truck" example
> that led to my response was hardly advocating an "open" access policy...
> So, I suppose I am to take the quoted text to mean that there is no
> scalability issue with authentication?
>
> networks/systems, scaling is not all that much of a consideration
> relative to a global or universal deployment).
>
>  Hence, I am confused and curious, but more than willing to simply agree
> to disagree - with whatever happens to be the argument.
>  Certainly CFDP experience influenced at least one of the IPN team
> members, but within the group, larger influences on the conceptual
> development of Bundling included SMTP, NNTP, UUCP - as well as the
> evolution of the US Postal Service (the Pony Express dominated discussions
> in the very earliest meetings).
>
> The defining characteristics underlying the IPN was the assumption that
> the problem space could *not* depend  on ubiquitous infrastructure (power,
>  The underlying "Interplanetary" meme provided a non-threatening backdrop
> to consider different ways of doing things.  This is analogous to the way
> Actually, space is *very* large, but the space exploration environment is
> a lot better curated than a random terrestrial deployment. When deploying
> in the space exploration environment one is able to leverage off of a LOT
> of engineering and coordination.  The fact that you depict space a "simpler
> doubts, while the stupid ones are full of confidence. *
>
>
> *
> - Charles Bukowski *
>

-- 

*
- Charles Bukowski*

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 2 May 2014 20:24:10 +0000

Some really nice slides from Scott- seriously.  I found these while preparing for a talk.
These do a nice job of highlight the difference between CFDP and DTN.

http://chapters.comsoc.org/comsig/Slides/Jan2004_BurleighS_IPN_DTN.pdf

Interesting that reactive fragmentation is called out.  I was not a big fan originally, but not I feel it is a requirement.

Has anyone done reactive fragmentation over LTP?  I was the beneficiary over TCP.

Stephen, was your experience with reactive fragmentation over TCP or some other convergence layer?

Will

******************************

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 May 2014 21:59:09 +0100

On 02/05/14 21:24, Ivancic, William D. (GRC-RHN0) wrote:
> Some really nice slides from Scott- seriously.  I found these while
> preparing for a talk. These do a nice job of highlight the difference
> between CFDP and DTN.
> 
>  Interesting that reactive fragmentation is called out.  I was not a
> big fan originally, but not I feel it is a requirement.
> 

Not with our LTP implementation. LTPlib and the LTPCL we
implemented would handle the disruption the LTP session
and not tell the BPA. Not sure about ION. Handing the
problem back to the bundle layer at some point would be
an idea but I've not looked to see if it'd be easy or
hard to code up.

> some other convergence layer?

The N4C stuff was all TCP.

Cheers,
S..

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

---

From: <[email-masked]>
Date: Sat, 3 May 2014 00:50:35 +0000

" I imagine that CCSDS is "trying to standardize the thing" because some  member agencies are interested in using it and want to have an expectation of interoperable cross-support service. "

A more conservative estimate would say that part of one member agency is interested in using it.

" I haven't paid attention to CCSDS activities in over a decade,"

well, yes.

"a push within part NASA to "standardize" ethernet., a similar push to "standardize" HDLC."

HDLC is ISO 13239. CCSDS is effectively an ISO subgroup (ISO TC20/SC13), and it's always been interesting how reluctant CCSDS is to adopt this ISO standard or have it work with its own nominally-ISO standards. But then, isn't the US still using footpounds rather than that ISO metric stuff? And CCSDS is US-driven. When I think of the bundle protocol being used for DTN mules I think of furlongs per fortnight.

Avionics ethernet falls under AFDX Ethernet and under ARINC<http://en.wikipedia.org/wiki/ARINC> Specification 664 Part 7 - no NASA involvement there either.

A better analogy is with SCPS, the push within NASA to standardise TCP/IP, while 'improving' it enough to make it incompatible. But really, you're talking about adoption; getting new technology onboard space missions is just plain hard, whether it's a standard or not.

I regret telling Adrian to leverage spacecraft clocks for expiry times while I was secretary of the IPN.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: Eric Travis <[email-masked]>
Sent: Saturday, 3 May 2014 5:43 AM
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Lloyd,

No?

No.

You typed "CFDP IPN" into a search engine and this came up (4th in result list for me)

Read the text that you quoted below again, heck read the whole paper - or start at page 4.

So, still No.

-- Burleigh,

 I imagine that CCSDS is "trying to standardize the thing" because some  member agencies are interested in using it and want to have an expectation of interoperable cross-support service.  I haven't paid attention to CCSDS activities in over a decade, but remember there was a push within part NASA to "standardize" ethernet., a similar push to "standardize" HDLC. I also know there was a working group for standardizing the encapsulating of IP datagrams in in CCSDS frames.  By your argument, the motivation was because ethernet, HDLC and IPv4 are all "space centric".

Finally! - you are absolutely correct… unless you are referring to the IPN rather than DTN.

Ubiquitous clocks:  As I stated in my previous message, the vision was that one brings the infrastructure with them.  If you need synchronized clocks you bring it with you.  Spacecraft tend to have excellent clocks - within the IPN time was envisioned to be provided as a network service (with proximate spacecraft serving as the local timebase).  If you were deploying in a cave and needed synchronized time for operations, you bring that infrastructure with you. Expiration times in bundles are even *more* beyond the scope of this thread, so if you wanted to present them as proof of your position, you would still be WRONG.

Ubiquitous perfect comms and storage reliability assumed: Wrong again.  I'm getting tired, so - Mandatory integrity checking was lost in the transition from IPN to DTN (it had been rolled into mutual suspicion of nodes).

Now,  am I try to correct you regarding the origins and assumptions of underlying Saratoga?
Alternatively, I've been having some questions about my 5th birthday party that you could probably resolve...

No bile, little obvious sarcasm, nothing burying an intelligent insight or observation.

Do feel better Lloyd.

Regards,

Eric

On Fri, May 2, 2014 at 4:38 AM, <[email-masked]<mailto:[email-masked]>> wrote:

No?

-- Burleigh,

Lloyd Wood
From: dtn-interest <[email-masked]<mailto:[email-masked]>> on behalf of Eric Travis <[email-masked]<mailto:[email-masked]>>

Will,

No.

and

No.

Fanciful > Distopian.

Regards,

Eric

Will,

---

From: Eric Travis <[email-masked]>
Date: Sat, 3 May 2014 03:28:11 -0400

Scott,

I think this interesting discussion is a bit off-topic for this thread; how
> about moving it to a new one?
>
>
>
> But while we’re here:
>
I honestly can't tell if you took offense - if so, I can't imagine why.

But, I think that I just might...

> ·         IPN did indeed have its origins in CFDP.  The original
> motivation for InterPlanetary Networking, as discussed in the very first
> meeting at MCI, was to devise a set of communication standards that would
> be more capable and more extensible than CFDP – a superset of what could be
> done with CFDP.

Wow...  just WOW...

Is that REALLY how you remember the meeting and what you took away from it?

If it had happened that way, I assure you that my response would have been
to wish Adrian, Vint and the rest of you good luck on the endeavor and gone
to the nearest 7-11 to fill out a job application.  I trust that you know
me well enough that I'm not engaging in hyperbole (there was a 7-11 in the
shopping center across the parkway).

Right now, I kind of wish that is how the meeting had gone.

o   In that sense, CFDP was a prototype for IPN.  An entirely valid way of
> looking at the basic structure of IPN was to divide the CFDP monolith into
> three layers: the retransmission procedures of CFDP were eventually
> re-imagined in LTP, the CFDP store-and-forward overlay procedures were a
> crude checklist for the basic functionality of the Bundle Protocol, and
> CFDP itself would be whittled back to just file transfer, for which it was
> fine.
>

Amazing.

 o   That said, I will certainly agree that most people involved in the
> early IPN work took their design ideas from their Internet experience
> rather than from familiarity with CFDP.  Ideas about IPN were always
> discussed in the context of what had already been shown to work (or not
> work) in the Internet.
>

So, a belated thanks are in order for humoring the Internet folks getting
under foot and wasting your time in meetings.
Thanks for carrying the rest of us, buddy.

·         DTN did indeed have its origins in IPN, but it immediately moved
> beyond those origins.  DARPA funded DTN not because they were eager for
> space networking but because they recognized that protocols that would
> solve the problems of space networking would solve some knotty terrestrial
> networking problems as well.
>

 You *do* remember that DARPA also (previously) funded the IPN - based on
my now realigned world view, was it because they (at that time) *were*
interested in the problems of space networking and saw the inherent value
in extending CFDP?

In the case of the DARPA DTN funding (2004-ish), are you referring to the
SPINDLE folks (BBN)?  Why was it that they stopped actively participating
in this RG?

·         So while IPN was certainly space-centric, DTN is not.
> Terrestrial DTN has gotten far more research attention than space
> networking.

Could that partially be related to the difficulty/cost in deploying space
networking experiments?
Or perhaps, not enough knowledge of space operations to formulate a
research proposal?
Or maybe because DTN routing issues are so darn similar to what would have
proposed under a MANET banner?

Hard to tell...

> The DTN protocols are usually designed to be suitable for use in space
> networking, because in most cases that has been the most challenging
> environment for them: with a few exceptions, if a protocol will work in
> deep space then getting it to work on the surface of Earth is easy.

 I can't disagree with the words, but I'm feeling a rationalization and
gross over-simplification.

·         In particular, I don’t see how DTN can be viewed as growing more
> space-centric than the IPN work was.
>

Right now, I'm kind of glad that I've obviously touched on a nerve here. I
will feel bad about that in the morning, but now for now I'm going to savor
it.

I take it your screed is in response to stating my opinion:

>> centric" than IPN.
I'm flattered that you value my opinion so much as to react so strongly.

You do understand that I said nothing about the Bundle Protocol (which
doesn't seem very different between the transition between IPN -> DTN).
When I refer to DTN,  I mean the scope of this Research Group and the
environmental parameters it considers relevant.

I formulated my opinion in reaction to recently spending a week reading the
archives of this mailing list.  It wasn't a pleasant experience. Things
have gotten dismissed because "that is not what I'm interested in".  The
repelling of the BBN Spindle people (the ones that DARPA funded for
"non-space-centric" research) from continued active participation here was
a tremendous loss to the larger RG.

Ultimately, my *opinion* is simply one *opinion* amongst many.

o   Virtually all research published on DTN routing addresses opportunistic
> connectivity, not scheduled connectivity.
>

 As I believe Lloyd recently observed, that is likely because DTN is not
MANET.  With the collapse of MANET, DTN became the new "Organic" - trendy.
>From a funding perspective, MANET is dead, Long live DTN.

o   I can’t think of any DTN Internet Drafts that presume fault tolerance.
> Mechanisms for detecting data corruption, either in transit or in situ,
> have been included in DTN since the publication of RFC 6257.  One might not
> care for those mechanisms, but that in itself seems like a pretty slender
> argument for claiming that DTN is space-centric.
>

Scott, over the past 5 or 6 years, how many Internet Drafts have you seen
that (if successful) would require modification to RFC 5050?  When the
official RG position taken is that (paraphrasing) "we should gather more
experience with RFC 5050 before we consider modifications", are you
surprised few bother to try?

As for RFC 6257 fixing the "problem" - it does indeed make it possible to
detect corruption, but provides no feedback about corrupted delivery. The
bundle is silently discarded at the receiver.  The best-case scenario is
that the bundle has custodial delivery and the retransmission timer
eventually fires.  If you feel that's the best that can be done, I'm really
sorry.  RFC-5050 provides no mechanism to request or react to a
retransmission request.

To be clear, I have no problem with BSP (or the streamlined revision), the
deficiency lies in RFC-5050, and can't be fixed with an external bandage.

o   Universal clock synchronization via GPS or NTP is a capability that has
> specifically *not* been available to spacecraft.  In any case I think
> removing this dependence is an issue on which DTNRG had long ago reached
> agreement (the Bundle Age I-D) before turning its attention elsewhere.
>

And this is reflected in RFC-5050 where?  Did I miss a Bundle Age RFC - and
should Fred include it in his list of RFCs?

All of which, I will suggest, is moot at this point.  The question at hand
> is who among us is interested in standardizing the DTN protocols within
> IETF and who is not.  I think we’ve already got some sense of this from the
> posts so far on this thread, and I think it would be good to hear some more.
>

You need to gauge the level of commitment, rather than the amount of
interest - they are not the same thing.  Ultimately, I think it is going to
depend on what "standardizing the DTN protocols" means... The scope of what
is acceptable to alter/address will ultimately determine the participation.

Regards,

Eric

On Fri, May 2, 2014 at 11:09 AM, Burleigh, Scott C (312G) <
[email-masked]> wrote:

> ·         IPN did indeed have its origins in CFDP.  The original
> motivation for InterPlanetary Networking, as discussed in the very first
> meeting at MCI, was to devise a set of communication standards that would
> be more capable and more extensible than CFDP – a superset of what could be
> done with CFDP.
>
> o   In that sense, CFDP was a prototype for IPN.  An entirely valid way
> of looking at the basic structure of IPN was to divide the CFDP monolith
> into three layers: the retransmission procedures of CFDP were eventually
> re-imagined in LTP, the CFDP store-and-forward overlay procedures were a
> crude checklist for the basic functionality of the Bundle Protocol, and
> CFDP itself would be whittled back to just file transfer, for which it was
> fine.
>
> o   That said, I will certainly agree that most people involved in the
> early IPN work took their design ideas from their Internet experience
> rather than from familiarity with CFDP.  Ideas about IPN were always
> discussed in the context of what had already been shown to work (or not
> work) in the Internet.
>
> ·         DTN did indeed have its origins in IPN, but it immediately
> moved beyond those origins.  DARPA funded DTN not because they were eager
> for space networking but because they recognized that protocols that would
> solve the problems of space networking would solve some knotty terrestrial
> networking problems as well.
>
> ·         So while IPN was certainly space-centric, DTN is not.
> Terrestrial DTN has gotten far more research attention than space
> networking.  The DTN protocols are usually designed to be suitable for use
> in space networking, because in most cases that has been the most
> challenging environment for them: with a few exceptions, if a protocol will
> work in deep space then getting it to work on the surface of Earth is easy.
>
> ·         In particular, I don’t see how DTN can be viewed as growing
> more space-centric than the IPN work was.
>
> o   Virtually all research published on DTN routing addresses
> opportunistic connectivity, not scheduled connectivity.
>
> o   I can’t think of any DTN Internet Drafts that presume fault
> tolerance.  Mechanisms for detecting data corruption, either in transit or
> in situ, have been included in DTN since the publication of RFC 6257.  One
> might not care for those mechanisms, but that in itself seems like a pretty
> slender argument for claiming that DTN is space-centric.
>
> o   Universal clock synchronization via GPS or NTP is a capability that
> has specifically *not* been available to spacecraft.  In any case I think
> removing this dependence is an issue on which DTNRG had long ago reached
> agreement (the Bundle Age I-D) before turning its attention elsewhere.
>
>
>
> All of which, I will suggest, is moot at this point.  The question at hand
> is who among us is interested in standardizing the DTN protocols within
> IETF and who is not.  I think we’ve already got some sense of this from the
> posts so far on this thread, and I think it would be good to hear some more.
>
>
>
> Scott
>
>
>
> *From:* dtn-interest [mailto:[email-masked]] *On Behalf Of
> *Eric Travis
> *Sent:* Thursday, May 01, 2014 11:38 PM
>
> *From: *Eric Travis <[email-masked]>
> *Date: *Wednesday, April 30, 2014 12:20 AM
> *To: *William Ivancic <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> *Subject: *Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>
>
>
> Will,
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]

-- 

*
- Charles Bukowski*

---

From: <[email-masked]>
Date: Sat, 3 May 2014 08:15:03 +0000

"I formulated my opinion in reaction to recently spending a week reading the archives of this mailing list.  It wasn't a pleasant experience."

that whole "Lloyd made a point and wrote it up in detail and the point turned out to be absolutely right but still got ignored and nothing got fixed" thing does get a little monotonous after the first three or so times. Kudos on perservering.

Coincidentally, Fred has written up three drafts referring to some of Lloyd's previous points made five or so years ago, and nothing will get fixed.

RFC5050 has previously been called "half-assed, half-baked" round here.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: dtn-interest <[email-masked]> on behalf of Eric Travis <[email-masked]>
Sent: Saturday, 3 May 2014 5:28:11 PM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Scott,

But while we’re here:

•         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP – a superset of what could be done with CFDP.

Wow...  just WOW...

If it had happened that way, I assure you that my response would have been to wish Adrian, Vint and the rest of you good luck on the endeavor and gone to the nearest 7-11 to fill out a job application.  I trust that you know me well enough that I'm not engaging in hyperbole (there was a 7-11 in the shopping center across the parkway).

Amazing.

So, a belated thanks are in order for humoring the Internet folks getting under foot and wasting your time in meetings.
Thanks for carrying the rest of us, buddy.

•         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

 You *do* remember that DARPA also (previously) funded the IPN - based on my now realigned world view, was it because they (at that time) *were* interested in the problems of space networking and saw the inherent value in extending CFDP?

In the case of the DARPA DTN funding (2004-ish), are you referring to the SPINDLE folks (BBN)?  Why was it that they stopped actively participating in this RG?

•         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.

Could that partially be related to the difficulty/cost in deploying space networking experiments?
Or perhaps, not enough knowledge of space operations to formulate a research proposal?
Or maybe because DTN routing issues are so darn similar to what would have proposed under a MANET banner?

Hard to tell...

The DTN protocols are usually designed to be suitable for use in space networking, because in most cases that has been the most challenging environment for them: with a few exceptions, if a protocol will work in deep space then getting it to work on the surface of Earth is easy.

 I can't disagree with the words, but I'm feeling a rationalization and gross over-simplification.

•         In particular, I don’t see how DTN can be viewed as growing more space-centric than the IPN work was.

Right now, I'm kind of glad that I've obviously touched on a nerve here. I will feel bad about that in the morning, but now for now I'm going to savor it.

Strangely, my feeling has been that, over time, DTN became MORE "space centric" than IPN.

You do understand that I said nothing about the Bundle Protocol (which doesn't seem very different between the transition between IPN -> DTN).  When I refer to DTN,  I mean the scope of this Research Group and the environmental parameters it considers relevant.

I formulated my opinion in reaction to recently spending a week reading the archives of this mailing list.  It wasn't a pleasant experience. Things have gotten dismissed because "that is not what I'm interested in".  The repelling of the BBN Spindle people (the ones that DARPA funded for "non-space-centric" research) from continued active participation here was a tremendous loss to the larger RG.

 As I believe Lloyd recently observed, that is likely because DTN is not MANET.  With the collapse of MANET, DTN became the new "Organic" - trendy.  From a funding perspective, MANET is dead, Long live DTN.

Scott, over the past 5 or 6 years, how many Internet Drafts have you seen that (if successful) would require modification to RFC 5050?  When the official RG position taken is that (paraphrasing) "we should gather more experience with RFC 5050 before we consider modifications", are you surprised few bother to try?

As for RFC 6257 fixing the "problem" - it does indeed make it possible to detect corruption, but provides no feedback about corrupted delivery. The bundle is silently discarded at the receiver.  The best-case scenario is that the bundle has custodial delivery and the retransmission timer eventually fires.  If you feel that's the best that can be done, I'm really sorry.  RFC-5050 provides no mechanism to request or react to a retransmission request.

To be clear, I have no problem with BSP (or the streamlined revision), the deficiency lies in RFC-5050, and can't be fixed with an external bandage.

And this is reflected in RFC-5050 where?  Did I miss a Bundle Age RFC - and should Fred include it in his list of RFCs?

You need to gauge the level of commitment, rather than the amount of interest - they are not the same thing.  Ultimately, I think it is going to depend on what "standardizing the DTN protocols" means... The scope of what is acceptable to alter/address will ultimately determine the participation.

Regards,

Eric

On Fri, May 2, 2014 at 11:09 AM, Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>> wrote:
I think this interesting discussion is a bit off-topic for this thread; how about moving it to a new one?

But while we’re here:

•         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP – a superset of what could be done with CFDP.

•         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

•         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.  The DTN protocols are usually designed to be suitable for use in space networking, because in most cases that has been the most challenging environment for them: with a few exceptions, if a protocol will work in deep space then getting it to work on the surface of Earth is easy.

•         In particular, I don’t see how DTN can be viewed as growing more space-centric than the IPN work was.

Scott

From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Travis
Sent: Thursday, May 01, 2014 11:38 PM

Will,

No.

and

No.

Fanciful > Distopian.

Regards,
Eric

Will,

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 May 2014 14:44:41 +0000

Hi Lloyd,

> Coincidentally, Fred has written up three drafts referring to some of Lloyd's previous points made five or so years ago, and nothing will get fixed.

In the IETF, the purpose of issuing problem statements is to serve as the basis for
initiating working group items. So, perhaps consider this as a first step towards
bringing "Bundle of Problems" into the IETF.

Thanks - Fred

From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, May 03, 2014 1:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Lloyd Wood

Scott,

But while we're here:

* ******** ***** **** ** *** **** ******* * ** *** * ***** ******* ****

**** * ***** **** * **** ********
*         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP - a superset of what could be done with CFDP.

Wow...  just WOW...

Amazing.

So, a belated thanks are in order for humoring the Internet folks getting under foot and wasting your time in meetings.
Thanks for carrying the rest of us, buddy.
*         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

In the case of the DARPA DTN funding (2004-ish), are you referring to the SPINDLE folks (BBN)?  Why was it that they stopped actively participating in this RG?
*         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.

 I can't disagree with the words, but I'm feeling a rationalization and gross over-simplification.
*         In particular, I don't see how DTN can be viewed as growing more space-centric than the IPN work was.

 As I believe Lloyd recently observed, that is likely because DTN is not MANET.  With the collapse of MANET, DTN became the new "Organic" - trendy.  From a funding perspective, MANET is dead, Long live DTN.
o   I can't think of any DTN Internet Drafts that presume fault tolerance.  Mechanisms for detecting data corruption, either in transit or in situ, have been included in DTN since the publication of RFC 6257.  One might not care for those mechanisms, but that in itself seems like a pretty slender argument for claiming that DTN is space-centric.

And this is reflected in RFC-5050 where?  Did I miss a Bundle Age RFC - and should Fred include it in his list of RFCs?
All of which, I will suggest, is moot at this point.  The question at hand is who among us is interested in standardizing the DTN protocols within IETF and who is not.  I think we've already got some sense of this from the posts so far on this thread, and I think it would be good to hear some more.

But while we're here:

*         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP - a superset of what could be done with CFDP.

*         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

*         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.  The DTN protocols are usually designed to be suitable for use in space networking, because in most cases that has been the most challenging environment for them: with a few exceptions, if a protocol will work in deep space then getting it to work on the surface of Earth is easy.

*         In particular, I don't see how DTN can be viewed as growing more space-centric than the IPN work was.

o   I can't think of any DTN Internet Drafts that presume fault tolerance.  Mechanisms for detecting data corruption, either in transit or in situ, have been included in DTN since the publication of RFC 6257.  One might not care for those mechanisms, but that in itself seems like a pretty slender argument for claiming that DTN is space-centric.

All of which, I will suggest, is moot at this point.  The question at hand is who among us is interested in standardizing the DTN protocols within IETF and who is not.  I think we've already got some sense of this from the posts so far on this thread, and I think it would be good to hear some more.

Scott

Will,

No.

and

No.

Fanciful > Distopian.

Regards,
Eric

Will,