Re: [dtn-interest] RFC 5050 revision?

[<[e-mail]>]

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

No surprises there - the chairs of this group have always been very focused on security.

But many embedded systems don't need, want, or can afford the overheads and complexity of the BP security protocols, so mandating security will make the bundle protocol even less relevant to operational dtns than it is now. 

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

The absolute time requirement has indeed prevented adoption of the BP.

However, mandating the security protocol may well need absolute time anyway... I imagine that uniquely identifying a bundle (or preventing replay attacks?) becomes less straightforward without timestamps.

> I'd also like to see some bits of current
> work finished (e.g CL RFCs),

since the TCP convergence layer draft expired in 2008, and 99+% of bundle transfers rely on the Internet (because TCP/IP is widely available and bundling's just built on top) and use the TCP convergence layer, getting that published would seem to be essential.

http://tools.ietf.org/html/draft-irtf-dtnrg-tcp-clayer-02

(Any reliability that the bundle protocol is perceived to have is probably due to its reliance on TCP. Mandating the security protocol forces a degree of reliability, but at a performance cost.)

> and also progression
> of the BPQ work we've been doing and on
> key management.

Key management and revocation without absolute time could be... interesting.

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