Re: [dtn-interest] RFC 5050 revision?

[William Immerman <[e-mail]>]

I'd like to comment on one aspect of these questions from the point of view of a newbie to DTN, and one who is more focussed on use of DTN than on research into the protocol(s).

I've visited with a number of people who I believe (should) see DTN as a solution to their common set of problems, and many believe that their existing one-off implementations are solutions. One of my observations to them that seems to be opening doors is the potential that DTN will permit their devices/subsystems to interoperate with others. I've also observed without contradiction that these won't be the last systems they build that face these issues, and that no one would adopt their stovepipe solution as THE basis for a common solution, but that the DTN community's work may serve that purpose. Finally, I've had to field a bunch of questions about the maturity of DTN, and I've had a difficult enough time explaining to would-be sponsors that a lot of the less mature aspects are in implementations and ancillary components/protocols (e.g., routing, naming), but that the DTN community has at least converged largely on BP as a core protocol with proven capability and which interoperates over multiple implementations. This explanation seems to have had a mildly calming effect.

I'm concerned that a substantial effort to replace 5050 might undermine some of these arguments, and that every time a leg is knocked out from under us we make it more difficult for people with needs to choose to adopt DTN.

This doesn't mean that there wouldn't be good reason to examine changes to 5050 at this time: if there are things that people have found obstruct adoption and can be fixed without negative impact on other uses, that'd be very positive. Likewise, I don't mean to say people should stop researching core problems, just expressing concerns that if a proposal is based mainly on how somebody might do it differently if starting fresh, they might want to consider the chilling effect that optimization might have on getting users on board now. There's a lot of potential utility to DTN, but it still addresses a population that is, for some observers, a niche, albeit an important and sizable niche. If we fragment that niche too much, we may end up with no critical mass of support.

Thanks,
Bill Immerman
 
On May 15, 2012, at 4:01 PM, Stephen Farrell wrote:

> 
> Hi all,
> 
> As Joerg noted we're interested in whether or not,
> and if so how, folks would like to do some work on an
> update or revision for RFC 5050, or ideas for
> alternatives to the BP or additional DTN protocols.
> 
> Things we're interested in hearing about, are:
> 
> - Should we rev 5050? why? why not?
> - What do you not like about 5050? how'd you fix that?
> - What is missing from 5050? how'd you add that?
> - What's great about 5050? why'd you keep that?
> - What 2119 MUST/SHOULD/MAY would you change and why?
> - What DTN research questions would you like to tackle
>  where RFC 5050 (or implementations thereof) are
>  a barrier?
> 
> In addition, we'd be interested in hearing whether
> folks would like to explore doing DTN based not on
> a straight revision of the BP, but maybe e.g. based
> on CoAP, SPDY, websockets, or other protocols.
> 
> Or, if you've something else to say/suggest, fo
> ahead and do that too.
> 
> At this point the goal is to gather and discuss
> ideas on the list, with a view to seeing what's of
> interest to RG participants.
> 
> If we get a bunch of ideas, then we'll try to
> organise those a bit and start separate threads.
> For now, if you can respond to this mail, that'll
> help us track the discussion later.
> 
> Later on, the question of who's actually willing to
> do stuff will get more interesting, since that's how
> things get done - just saying that it "must be so"
> is frequently trumped by the fact that someone else
> has the energy to actually do something.
> 
> Lastly, none of this means that there's anything
> wrong with RFC 5050 which has been great for both
> doing DTN experiments and for the CCSDS folks who're
> building on it for their work. (And in case CCSDS
> people get process-scared, no, nothing will ever
> change the existing RFCs, so documents referring
> to them are unaffected.)
> 
> Cheers,
> Stephen, Kevin, Joerg.
> 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>