[dtn-interest] Comments on the bundling draft

[Manikantan Ramadas <[e-mail]>]

Some thoughts/comments/suggestions on
draft-irtf-dtnrg-bundle-spec-02.txt :

* Sec 2.3.2 We might need a RegistrationError.indication primitive to
serve the case (for example) if the default failure action requested
of deferring bundle delivery until a period of passive or active
reception by the application was unacceptable to the bundle agent (for
storage or other administrative considerations). A bundle-agent may
also choose to reject a request by the application to run a procedure
provided by the application while deferring bundles for security
reasons, say. Besides the Register.request, a
Change_registration.request requesting changes as in the above
examples, may also deserve a RegistrationError.indication.

* Sec 2.5.2 II para, II line, may be you want to call this one
CancelBundle.request to be in Sync. with the title as we have with all
other request primitives? Just caught my eye, thats all.

* Sec 2.5.10 SendError.indication : Since the bundling application
uniquely refers to each Send request with a SendTokenBinding, isn't it
enough if we just return the SendTokenBinding parameter instead of all
those parameters we are returning?

* Closing out Section 2,  May be we need a table(s) of reason-codes to
be sent back as a parameter along with SendError.indication and
RegistrationError.indication primitives? Reason-codes for
SendError.indication could include reasons like :

 o No route to host (ever)
 o Can't meet lifespan (if the bundle agent was aware of the link
schedules)

While RegistrationError.indication could include reason-codes for
stuff like :
 o Can't defer delivery
 o Can't run user-specified procedure

* This is just a curiosity question: Why have we left Reserved spaces
for bundle header type values interspersed like 0x03, 0x04, 0x06
instead of having all the Reserved values towards the end?

* Sec 3.3, ASCII diagrams illustrating bit allotment for Class of
Service Flags and Payload Security would be nice!

* Sec 3.7. This has been raised in a recent thread on DTN Security.
But just for the sake of completeness : we need to clearly say what
happens under reactive fragmentation when bundles authentication
breaks at the receiver. Although reactive fragmentation is likely to
be a rather corner case (at least for links with relatively long
uptimes), we go thru' all this pain just to make sure NOT to lose bits
that made all this way but were corrupted just because the link went
down right in the middle of transmission, right? But this is all
useless if the receiving bundle agent is going to throw such a
fragmented bundle anyways since it was inauthentic.

* Sec 4.2 Step 1, last-but-1 line : you mean the "sending bundle
agent" here right? Or, I don't understand whats going on here.

* Sec 4.4 Bundle Fowarding : Before beginning with Step 2, how do we
handle cases such as 

 o This bundle must have taken the wrong path to reach us because we
have no route to the destination region (ever)

 o We have a route to the destination region, but the link is down
now, and  based on link schedules we know that we can't meet the
TTL when the link would become available next. In such a case, it
seems good not to bother saving the bundle, but rather send back an
error message.

* Sec 4.5.1 Bundle Fragmentation, towards the end when we discuss
reactive fragmentation. All of this discussion seems to assume that
reactive fragmentation happened while transmitting the final payload
section of the bundle. May be a few lines on what to do when the link
went down while transmitting say like the Dictionary Header could be
useful?

* Sec 5.1 Table 5. This one is rather a matter of style. The table
only lists the value of status flag while the discussion below the
table uses clauses like "if the bundle fragment bit is set..", "if the
bundle-forwarded bit is set.." etc instead of saying "if the value was
0x80.." etc.  While it is clear to me that the
bundle fragment bit is the MSB and the bundle-forwarded bit is the
third LSB, may be adding a "Bit" column by the side of the "Value"
column or having a simple ASCII diagram instead of the table
illustrating the flag assignment, would make me happy. But this is
certainly a low priority objection/comment.

* Sec 5.2 Table 7 The values 0x03 - 0x06 clearly don't go with a
Status flag 0x01 (Custody Transfer Succeeded) (Table 6). May be we
need a Status flag assignment in Table 6 that stands for Custody
Transfer Failed (may be 0x00)?

- Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________