Re: [dtn-interest] RFC 5050 revision?

["Burleigh, Scott C (313B)" <[e-mail]>]

I agree with at least the first part of your list, Stephen, and probably the rest as well except that I haven't been following BPQ closely enough to comment.  I think the BABs, at least, should be MUST implement (so long as they can be turned off in deployment); I'm all for getting rid of the dictionary, and I'd propose CBHE as the generic compression that takes its place; and I think we've got to support aggregated bundle age as an alternative to authoritative bundle creation time for bundle expiration purposes.  And I think this does require a new version of BP.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Friday, May 18, 2012 10:05 AM
To: Stephen Farrell
Cc: DTN interest
Subject: Re: [dtn-interest] RFC 5050 revision?


So, replying to my own mail, at least in part, and not as chair,..

I'd think I'd like to see a rev of the BP that includes the security stuff from day 1 as a MUST implement, that gets rid of the dictionary in favour of some kind of generic compression (if IPR-free) and that also loses the absolute time requirement. I think that'd be best done as a new BP version that didn't have to be backwards compatible with the 5050, and we'd want to define a way for (some?) CLs to negotiate versions of the BP to make sure that smooth migration was possible.

I'd also like to see some bits of current work finished (e.g CL RFCs), and also progression of the BPQ work we've been doing and on key management.

I'm sure there's more but those are my main things for now.

S

On 05/15/2012 09: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
> 
> 
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest