Re: [dtn-interest] [Fwd: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct]

[Scott Burleigh <[e-mail]>]

Stephen Farrell wrote:
> 
> FYI. Another few comments from the IRSG poll.
> 
> Can one of the DTN arch authors take up responding to these?
> (Note that the commenters are not "against" DTN or the
> progress of this document, but they do raise some common
> points, so maybe our output will be better if we can handle
> their comments now.)
> 
> And the sooner the better of course;-)
> Cheers,
> S.
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
> From:
> Mark Allman <[e-mail]>
> Date:
> Wed, 01 Nov 2006 15:56:09 -0500
> To:
> Aaron Falk <[e-mail]>
> 
> To:
> Aaron Falk <[e-mail]>
> CC:
> Internet Steering Group <[e-mail]>
> 
> 
>>      o  'not ready to publish' -- requires a thorough read, reasonably
>>         detailed review, and actionable comments.
> 
> Me.
> 
>>      o  'no objection' -- I don't object if this document goes forward;
>>         I've read the document (perhaps quickly); I have some small
>>         comments which are not show stoppers; I don't have great
>>         expertise in the area.
> 
> I gave this a quick read and don't have a detailed review and so I
> cannot say "not ready to publish".  But, I would like to see a few
> things cleaned up ...
> 
> A few comments (and a couple others under separate cover):
> 
>   + 3.1: It seems that there is an obvious attack here which is to just
>     take up a node's disk with junk bundles.  It is a resource attack
>     and it is not exactly clear to me what to do about that.  But, one
>     could think about ways to, for instance, make sure a conversation is
>     wanted by both endpoints somehow.  A 3WHS sounds like no fun, but
>     maybe some general sort of notion that spaceship1 and earthlab1
>     communicate could be propagated somehow and then at least the
>     traffic could be vetted a bit by the intermediate nodes.

I think that's exactly what the "reciprocal suspicion" notion of the bundle security model is supposed to provide, in a 3WHS-free manner.  Maybe this needs to be emphasized in the architecture document?

>     Basically, we're building this system whereby we count on
>     store-and-forward and we know we're going to have to STORE a bunch
>     more than in traditional networks and yet there is seemingly little
>     attention paid to management of this storage resource.
> 
>     (Or, maybe I missed something in my haste.)

Except we don't really want to pay too much attention to that storage management in these protocol documents because it's mostly a local implementation matter.  Being able to deal with this kind of thing autonomously goes to the essence of the DTN model -- it must *not* be a matter of negotiation, because you can never count on a negotiation converging quickly enough to work.

>   + I might have read too quickly, but what is the difference between
>     the messages in 3.6.1 and 3.6.2?  Why are there two lists?  It felt
>     weird and maybe I read too quickly to appreciate the subtle
>     distinction.  But, I did read twice.  So, maybe this needs better
>     described.

I think 3.6.1 just describes the flags while 3.6.2 talks about the resulting messages.  Clarify in the text somehow?

>   + 3.7 should appear earlier in the document, I think.  It provides
>     some context that would have helped me in the sections that are now
>     previous to it.  (This goes along with Tom's comment of terminology
>     definitions being needed, I think.)

That sounds okay to me.

Scott