[dtn] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-dtn-bpbis-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. And it is a really interesting
topic !

The document is not really easy to read with some long and convoluted sentence
such as
  "An application data unit is the unit
   of data whose conveyance to the bundle's destination is the purpose
   for the transmission of some bundle that is not a fragment (as
   defined below)."

Another one:
  "The payload for a bundle
   forwarded in response to reception of a bundle is the payload of the
   received bundle."

The above sentences and others make the reading really difficult. Probably too
late to change now...

The section 3.2 go a little too deep IMHO in details (do we care whether the
BPA is general-purpose computer?)

As a side note, I would be interested by the potential use of this bundle
protocol to transport the future webpack ;-)

Please find below some non-blocking COMMENTs.
C1) is there any reason why the reserved bits in section 4.3.1 are not
specified with the usual 'transmitted as 0 and ignored by receiver' ? C2) in
section 4.1.5, is there a registry or a mechanism to avoid / detect identifier
collisions ? C3) just curious, why is it version 7 ? C4) in section 4.3.2, if
the bundle age is expressed in microseconds, then I would suggest to define
exactly 'most recently forwarded': by which component of the bundle node ? is
it measured at the completion of the action (e.g., layer-2 serialization is
finished). Section 5.4 adds some more information but not enough to my taste
(is it when the forwarding decision is made or when the convergence layer has
accepted it). C5) in section 4.3.3., why not following the usual method of
hop-limit starting at a non-zero value and being decremented at each forwarding
operation ? it is like using DTN time from 2000 rather than the usual timestamp
definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel
if there is no real reason C6) the possibility of having a single bundle to
generate multiple reports along its path to the 'report-to' endpoint ID per
section 5.6 could possibly be used for an amplification attacks + resource
exhaustion attack on traversed nodes. Should a rate limiting be mentionned ?
C7) section 5.9, should the re-assembly process time out ? E.g., taking into
account the max bundle age ? C8) section 8, I have hard time to parse the
following "the Bundle Protocol version 7 specification draft (version 6)" even
if I think I got it right C9) section 8, an interop status (if any) between the
three existing implementations would be welcome

I hope that this helps to improve the document,

Regards,

-éric