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

On 28/04/14 08:54, Joerg Ott wrote:
> IIRC, I remarked back then, that adding a To: and From: fields (granted,
> you call them differently) to HTTP has been done before (aka SIP).
> Let's not repeat this exercise (we know where this can lead to :-)
> And, no, I am not suggesting you should be using SIP instead, even
> though it would be closer.
> 
> It's just that adding feature to a system it wasn't designed for is
> going to be as easy as it seems at the first glance (adding routing,
> etc.)

That is a danger, yes. But doing minimal changes to 5050 also
has a danger - that the result is never really deployed. So I
think the question for now seems to be whether or not to make
much simpler terrestrial deployment a first class goal for the
putative WG.

I'd like the answer to be "yes," but I do agree that there's
a case that can be made for a minimal-change approach. That
latter is a lot less interesting for me though as I think there
are just very few situations that justify rolling out an entirely
different infrastructure for a DTN.

S.

> 
> Jörg
> 
> On 27.04.2014 16:40, l.wood@surrey.ac.uk wrote:
>> if you're  enabling a web server for DTN,
>> why use the bundle protocol?
>>
>> http://sat-net.com/L.Wood/dtn/http-dtn.html
>>
>> Lloyd Wood
>> http://about.me/lloydwood
>> ________________________________________
>> From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of
>> Stephen Farrell [stephen.farrell@cs.tcd.ie]
>> Sent: 27 April 2014 14:00
>> To: Joerg Ott; Templin, Fred L; dtn-interest@irtf.org
>> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
>>
>> Hiya,
>>
>> On 27/04/14 09:03, Joerg Ott wrote:
>>> While I see Stephen's point on the tooling, I don't agree with
>>> this since tool fashion changes (including the praise for text-based
>>> encoding in the IETF at some layers).  We have built commercial
>>> products for terrestrial use based upon RFC 5050 and, really,
>>> the tool part isn't the problem.  The security part is where
>>> we want to be more sensible towards protocol re-use.
>>
>> Fair point. OTOH, I think its a real fail that one can't
>> e.g. just install an Apache web server module to DTN enable
>> your web proxy or something similar. Having to build an
>> entirely new overlay for 5050 that doesn't re-use anything
>> already deployed makes it much less likely to be used IMO.
>> Actually, that's not just opinion, its based on our
>> experience trying to deploy stuff we've piloted that worked
>> but always seems to be too much trouble for non-subsidised
>> deployments.
>>
>> That is not something that will change just because the
>> RFC is in the IETF stream. But I think we should be able to
>> fix that with a 5050bis while also keeping the ability to
>> gateway to 5050 DTNs.
>>
>> To be clear, I don't want that we aim to DTN-enable the web, I
>> want us to consider terrestrial deployability and making that
>> as easy as possible as first class requirements. If the means
>> to get that were not related to HTTP (though HTTP/2.0 timing
>> might just still be fortuitous here), but say related to
>> some OpenWRT build for homenet, then that'd also be just
>> dandy.
>>
>> S.
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> dtn-interest@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> dtn-interest@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>>
> 