Last Call Review of draft-ietf-dtn-bpbis-17

Request Review of draft-ietf-dtn-bpbis
Requested rev. no specific revision (document currently at 29)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-11-12
Requested 2019-10-29
Authors Scott Burleigh, Kevin Fall, Edward Birrane
Draft last updated 2019-11-06
Completed reviews Genart Last Call review of -17 by Stewart Bryant (diff)
Genart Telechat review of -21 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant 
State Completed
Review review-ietf-dtn-bpbis-17-genart-lc-bryant-2019-11-06
Posted at
Reviewed rev. 17 (document currently at 29)
Review result Not Ready
Review completed: 2019-11-06


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-dtn-bpbis-17
Reviewer: Stewart Bryant
Review Date: 2019-11-06
IETF LC End Date: 2019-11-12
IESG Telechat date: Not scheduled for a telechat


There are quite a number of issues that need to be attended to in this document.

None of that is fundamental to the protocol itself, but work is needed to make this ready for
publication as a Proposed Standard.


Major issues:

It is not clear what the status of this RFC will be relative to RFC5050. 
If it modifies the status of RFC5050 it needs to make this clear in the 
boilerplate, Abstract and Introduction.


     . 0 indicates "no CRC is present."
     . 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
     . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."

SB> I am surprised that in these more modern times something stronger 
than a CRC is not used, for example a crypto hash. Particularly given the 
harsh environment that this is targeting.

     . The bundle contains a "manifest" extension block.  (Boolean)
SB> Given that manifest is not defined yet this seems out of place in an ST text

Relative to the section DTN Time:

   Unix epoch time is the next best option.  Like TAI, Unix epoch time
   is simply a count of seconds elapsed since a standard epoch.  Unlike
   TAI, the current value of Unix epoch time is provided by virtually
   all operating systems on which BP is likely to run.

SB> This section needs to be checked by a time expert. 

SB> I think you are saying that you use Unix time, but Unix time 
includes leap seconds by double increment, so I don’t think 
you are using that because that would give you the measurement 
error you are concerned about. I think that what you are using is 
a monotonically increasing time based on the Unix epoch. I think 
that is what PTP (IEEE1588) is using and PTP might be a better 
reference. PTP is likely to become more available in spacecraft 
anyway, since it is finding deployment in precision measurement
 applications. Thus I am not sure I understand why UET is more 
accessible on spacecraft than TAI. Presumably the spacecraft are using 
free-running clocks and so will drift, although I understand that 
work is in progress to provide time sync to spacecraft for 
navigation purposes.

 The argument in this section seems long and will become dated. 
Surely all you need to say is that you need a monotonically 
increasing time system such as TAI or UNIX time(), and out of 
software convenience you choose the latter. However I don’t 
think that is what you are actually doing. What I think you are doing 
is using TAI with a free running clock that you accept will drift.

SB> A lot of the text in this section is not really normative and 
perhaps belongs in a non-normative appendix.


   The following extension block types are reserved for extension
   blocks for which a need is anticipated but for which no definitions
   yet exist:

     . Block type 13 is reserved for the anticipated Manifest Block.
SB> This should really be handled through an IANA registry. It seems 
strange to have text that is semi-definative about anticipated 
features in a proposed standard. Same for types 14 and 15. 
They should not be in ST text until they are standard.

In the Security Section

   Note that, while the primary block must remain in the clear for
   routing purposes, the Bundle Protocol can be protected against
   traffic analysis to some extent by using bundle-in-bundle
   encapsulation to tunnel bundles to a safe forward distribution
   point: the encapsulated bundle forms the payload of an encapsulating
   bundle, and that payload block may be encrypted by a BCB.

SB> Is there a definition of the bundle in bundle protocol?

SB> The material that follows seems to be defining protocol which 
is unusual in a security section. I would be better to define protocol 
in the body of the text or simply point to a definition in another document.


10.1. Bundle Block Types
SB> The namespaces do not seem to be identified.

SB> The IANA reference for new allocations ought to be to this RFC

SB> Given that this is a Standards Document I am surprised that 
references to RFC5050 are not replaced with references to this RFC. 
Does this indicate that RFC5050 is expected to remain a current protocol. 
If so we are in the odd position of a ST text relying on definitions in an 
Experimental text. This is something that the IESG needs to consider.

   The registration policy is changed to "Expert Review". Given the
   maximum number of bits available, the allocation should only be
   approved with a well-defined specification and proof of real usage.

SB> I am surprised that it (or some part of it) is not changed to one 
of the more difficult critera, such as Standards Action. Also I am 
surprised that there are no private use or experimental allocations.


11.1. Normative References

   [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work
   In Progress, October 2015.

SB> I am not sure what this points to but I think it is RFC6257 
which is experimental and hence is a downref. This needs the proper ref 
and the downref addressing.

   [CRC16] ITU-T Recommendation X.25, p. 9, section,
   International Telecommunications Union, October 1996.
SB> This shows up in nits as a downref, but I am sure it is OK,

   [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization
   of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE
   Transact. on Communications, Vol. 41, No. 6, June 1993.

SB> I am not sure what the policy is WRT having a normative ref to an IEEE paper.
SB> Information on CRC32C is more accessibly found in RFC3385

   [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual,
   Fifth Edition", Bell Telephone Laboratories Inc., June 1974.  See

SB> I am sure this is a fine document but again I am not sure if 
you can point to it as normative.


   This work is freely adapted from RFC 5050, which was an effort of
   the Delay Tolerant Networking Research Group. 

SB> Is it simply adapted? What is the relative standing of the two?
As far as I can see this Standard relies on definitions provided by that RFC.

Appendix B.                  CDDL expression
SB> What is the licence position for the code that follows?


Minor issues:

10.2. Primary Bundle Protocol Version

   The current Primary Bundle Protocol Version Registry is augmented by
   adding the following value.
SB> This is normally expressed as a request for IANA to take an action on a namespace.


10.4. Block Processing Control Flags

   The current Block Processing Control Flags Registry is augmented by
   adding a column identifying the version of the Bundle protocol
   (Bundle Protocol Version) that applies to the related BP version.
   The current values in the registry should have the Bundle Protocol
   Version set to the value 6 or "6, 7", as shown below.

SB> Again no namespace specified.


10.6. Bundle Protocol URI scheme types

   The Bundle Protocol has a URI scheme type field - an unsigned
   integer of undefined length - for which IANA is requested to create
   and maintain a new registry named "Bundle Protocol URI Scheme Type

SB> In which namespace?

SB> I am surprised that in an 8bit field there are not more reserved 
values that require more considered  action to release.

Appendix A.                 For More Information

   Please refer comments to DTN Working Group documents
   are located at  The
   original Delay Tolerant Networking Research Group (DTNRG) Web site
   is located at

SB> That does not seem right for a PS document.


Nits/editorial comments:

   Note: The choice of Unix epoch time as the scale on which time
   values in DTN are expressed may need some explanation.
SB> The above looks like a spurious editors’ note, instead of the introduction to the text that follows.


   Step 2: The bundle protocol agent MUST determine whether or not
   forwarding is contraindicated for any of the reasons listed in
   Figure 4. In particular:

SB> contraindicated is a very erudite word, but I wonder how many 
of the readers, particularly those who are not native English speakers 
will understand it. Perhaps a simpler word might me used. If not then it 
ought to be defined in the text.