Telechat Review of draft-ietf-dtn-bpbis-21

Request Review of draft-ietf-dtn-bpbis
Requested rev. no specific revision (document currently at 29)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-04
Requested 2020-01-17
Authors Scott Burleigh, Kevin Fall, Edward Birrane
Draft last updated 2020-01-31
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-21-genart-telechat-bryant-2020-01-31
Posted at
Reviewed rev. 21 (document currently at 29)
Review result Ready with Issues
Review completed: 2020-01-31


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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-dtn-bpbis-21
Reviewer: Stewart Bryant
Review Date: 2020-01-31
IETF LC End Date: None
IESG Telechat date: 2020-02-06


This version is a major improvement on the version that I reviewed earlier. I thank the authors for addressing my earlier review comments. There
are a number of minor issues that the authors ought to look at, particularly around IANA allocation policy.
Major issues: None

Minor issues:

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

SB> I think that this should be a reference to draft-ietf-dtn-bpsec


In Section 10.3 the allocation policy has been changed to Standards Action
which seems wise given the size of the registry. However all the 
registries  called up in 10.1..10.5 are all small and the authors ought 
to consider upgrading them of at least a portion of them to a higher 
bar than at present (they are specification required). Specification 
required can be met by a specification that is not even publicly 
accessible which can grab multiple entries. This is a dangerous position 
to leave small the registries of a Standards Track  protocol.

I have only checked the registries specifically addressed by this specification
and the authors ought to check the other registries in the Bundle Protocol
Namespace to see if any of them are also vulnerable.

Nits/editorial comments:

Note that more robust protection of BP data integrity, as needed,

SB> I that should be ….,if needed,


SB> Bpsec appears as BPsec and bpsec also the noun bpsec is not defined
I assume you mean the BPsec protocol or mechanism or similar.

 The current Bundle Block Types namespace is augmented

SB> I think that strictly you should say:
SB> The current Bundle Block Types registry in the Bundle Protocol Namespace is augmented.

This problem applies to the registries 10.2, 10.3, 10.4, and 10.5