Bundle Protocol Version 7

Summary: Needs a YES. Has 3 DISCUSSes. Needs 5 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2020-02-05 for -22)
I support Roman's Discuss.

(1) It's not clear to me that we should be defining new
(near-)application-layer protocols on the standards track without mandatory
security mechanisms.  Even draft-ietf-dtn-bpsec defines a "BPSec threat
model" that is largly the same as the RFC 3552 threat model, in which the
network is completely untrusted and to provide end-to-end communications we
must supply additional security mechanisms, yet BPSec is not required to
implement or use.  I could perhaps see room for allowing waypoint nodes that
do not act as endpoints to remain security-unaware, but the justification
for security-unaware endpoints seems quite lacking.

(2) The state machine for transitions between singleton EID and
non-singleton EID seems highly unclear to be usable in a globally
synchronized manner (I refer specifically to the text in Section "A
node's membership in a given singleton endpoint MUST be sustained at least
until the nominal operation of the Bundle Protocol no longer depends on the
identification of that node using that endpoint's ID").  Distinction between
singleton-EID and non-singleton EID may need to be made an explicit protocol

(3) The forwarding procedure in Section 5.4 refers to a "data label
extension block (to be defined in a future document)" with no reference; it
doesn't really seem like this sort of speculative forward-looking statement
is appropriate in a Proposed Standard.

(4) We discuss using a Previous Node block to "return a bundle to sender"
when forwarding failed, but do not discuss whether Previous Node should be
added (or updated or removed) on transmission, receipt, or both.

(5) The extensibility story seems incompletely described: what should an
implementation do upon receiving a bundle with an unrecognized control flag
bit set, or a block with an unrecognized control flag set?

(6) The use of absolute times for creation timestamps suggests a strong
dependence on accurate time (for nodes that do not acknowledge their lack of
an accurate clock); the consequences of the failure of accurate time should
be discussed in the security considerations section.

(7) Section 4.1.6 should make a statement regarding whether leap seconds are
included or excluded from the count of seconds since the DTN epoch.

(8) The definition of Fragment offset needs to specify whether the lowest
allowed byte index is zero or 1 (I believe zero, from other discussion).

(9) Bundle status reports are only defined to include the creation timestamp
of the bundle whose status is being reported on, but not the sequence number
thereof.  Since we allow nodes without accurate clocks to use a creation
timestamp of zero and rely solely on the sequence number to identify
bundles, it seems that the status reports for such bundles are effectively
useless without the sequence number information.

(10) Please resolve the internal inconsistency in Section 10.6 that
simultaneously claims that potential bundle protocol URI scheme types are
integers of undefined length and only have 255 available codepoints (i.e.,
definite length).
Comment (2020-02-05 for -22)
It's pretty unfortunate that we have to have separate (built-in) CRC
and (dedicated block type) BIB support; a more unified scheme that always
provides cryptographic integrity protection would have simpler encoding
rules.  I rather wonder why it's not possible to roll the CRC as a mechanism
for detecting media-induced errors into the CLA functionality as opposed to
needing to be in the top-level BPA.  Then media not susceptible to errors
could use no or a small CRC and more malleable media could use stronger
CRCs, leaving the decision closer to the knowledge of the transport

Is a registration something that conceptually lives "in the network", or a
purely local matter to the node in question?  What about active vs. passive
state thereof?

The creation timestamp, sequence number, and lifetime can serve to some
extent to detect replay of old data, though given the environments we expect
this to operate in, it may be hard to differentiate a replay from normal
delivery.  I don't see any mechanisms that would allow for detection of
dropped bundles (whether due to attack or other error), though it's not
entirely clear that such a mechanism is possible in these environments.
It may also be worth considering whether there is use for the ability detect
a truncated application-layer "stream" that's a group of bundles related to
each other in some way.  I do see that the protocol is largely focused on
bundles as discrete units, and so expect the answer to be "no", but this is
one of the more standard security mechanisms, so I wanted to explicitly
check.  Similarly, one might imagine a block type that indicates the initial
block types present in a bundle, which could be (required to be) subject to
integrity protection so that removal of blocks could be detected at the
Some further discussion of these points, in terms of the goals for
these environments and what behaviors are actually attained, might be
appropriate in the security considerations section.

Section 3.1

   Application Data Unit (ADU) - 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).

I understand the desire for precision, but this definition feels very
convoluted and could perhaps be made more accessible to an application

   Bundle node - A bundle node (or, in the context of this document,
   simply a "node") is any entity that can send and/or receive bundles.
   Each bundle node has three conceptual components, defined below, as
   shown in Figure 2: a "bundle protocol agent", a set of zero or more
   "convergence layer adapters", and an "application agent".

If a node always has an application agent, won't anything done by that
application agent make the node also part of an endpoint?  Yet we discuss
waypoint nodes that are not endpoints...

   Delivery - A bundle is considered to have been delivered at a node
   subject to a registration as soon as the application data unit that
   is the payload of the bundle, together with any relevant metadata
   (an implementation matter), has been presented to the node's
   application agent in a manner consistent with the state of that

Is this metadata considered attached to the ADU or the bundle or something

   Delivery failure action - The delivery failure action of a
   registration is the action that is to be taken when a bundle that is
   "deliverable" subject to that registration is received at a time
   when the registration is in the Passive state.

Just to check my understanding: with registrations being
per-(node,endpoint), in a case where many nodes are in an endpoint, we'll
undertake a delivery failure action for each node with a passive
registration even if the bundle is successfully delivered to a different
node with an active registration?  How does this interact with the
"report-to" EID?

Section 3.2

   Every CLA implements its own thin layer of protocol, interposed
   between BP and the (usually "top") protocol(s) of the underlying
   native protocol stack; this "CL protocol" may only serve to
   multiplex and de-multiplex bundles to and from the underlying native
   protocol, or it may offer additional CL-specific functionality. The
   manner in which a CLA sends and receives bundles, as well as the
   definitions of CLAs and CL protocols, are beyond the scope of this

We still need to specify what interfaces a CLA needs to present to the BPA,
though!  Section 7 is a start at this (and probably worth cross-referencing
from here), though it feels pretty sparse.

   In the case of a node that serves simply as a BP "router", the AA
   may have no application-specific element at all. The application-

(But earlier we said that a node has all three elements, including an
application agent.  What would the Administrative Element do on such a
"router" node?)

   The destination of every bundle is an endpoint, which may or may not
   be singleton.  The source of every bundle is a node, identified by
   the endpoint ID for some singleton endpoint that contains that node.

It might be worty a forward-reference to Section where we record the
requirement for a valid endpoint ID of a given node.

   The bundle protocol is designed for extensibility.  Bundle protocol
   extensions, documented elsewhere, may extend this specification by:
      . defining additional mandates and constraints on processing
         that conformant bundle protocol agents must perform at
         specified points in the inbound and outbound bundle processing

It's not clear to me how "additional mandates and constraints" can
successfully be imposed by protocol extensions given that the source node
cannot in general know the path(s) the bundle will take.

Section 4.1.2

   When not omitted, the CRC SHALL be represented as a CBOR byte string
   of two bytes (that is, CBOR additional information 2, if CRC type is
   1) or of four bytes (that is, CBOR additional information 4, if CRC
   type is 2); in each case the sequence of bytes SHALL constitute an
   unsigned integer value (of 16 or 32 bits, respectively) in network
   byte order.

This seems to preclude the possibility of any future CRC types being
defined (without an update to this specification).

Section 4.1.3

   If the bundle's source node is omitted (i.e., the source node ID is
   the ID of the null endpoint, which has no members as discussed
   below; this option enables anonymous bundle transmission), then the
   bundle is not uniquely identifiable and all bundle protocol features
   that rely on bundle identity must therefore be disabled: the "Bundle
   must not be fragmented" flag value must be 1 and all status report
   request flag values must be zero.

It's also impossible for the user application to acknowledge such an
anonymous bundle, right, so that flag would also be zero?  Or do such
reports go to the "Report-to EID"?

     . Bits 21-63 are unassigned.

Does this imply a mandatory encoding (width) of the CBOR unsigned integer
representing the flags (and a hard limit on the number of possible flags)?

Section 4.1.4

     . This block must be replicated in every fragment.  (Boolean)

     . Transmission of a status report is requested if this block
        can't be processed.  (Boolean)

     . Block must be removed from the bundle if it can't be processed.

     . Bundle must be deleted if this block can't be processed.

nit: perhaps we could reorder this list to match the order in which the bit
flags are allocated?


   Each BP endpoint ID (EID) SHALL be represented as a CBOR array
   comprising a 2-tuple.

nit: Is there a reason to not just say "a CBOR array of two elements"?

   The first item of the array SHALL be the code number identifying the
   endpoint's URI scheme [URI], as defined in the registry of URI
   scheme code numbers for Bundle Protocol maintained by IANA as
   described in Section 10. [URIREG].  Each URI scheme code number

I'm not sure why [URIREG] is the reference here; it has nothing to do with
the "code numbers for Bundle Protocol".

     . If the EID's URI scheme is "ipn" then the SSP SHALL be
        represented as a CBOR array comprising a 2-tuple.  The first

[same comment about "two elements"]

        item of this array SHALL be the EID's node number represented
        as a CBOR unsigned integer.  The second item of this array
        SHALL be the EID's service number represented as a CBOR
        unsigned integer.

Where are node and service numbers defined?

     . Definitions of the CBOR representations of the SSPs of EIDs
        encoded in other URI schemes are included in the specifications
        defining those schemes.

This feels kind of weird; the vast majority of URI schemes are not going to
define CBOR encoding rules for their SSPs, but above we claim that bundle
protocol is usable with any registered URI scheme.  Absent some mechanism
for a separate document from the scheme definition to specify the CBOR
encoding rules for the SSP, these claims are incompatible.


      . The EID of any singleton endpoint of which a node is a member
        MAY be used to identify that node. A "node ID" is an EID that
        is used in this way.
      . A node's membership in a given singleton endpoint MUST be
        sustained at least until the nominal operation of the Bundle
        Protocol no longer depends on the identification of that node
        using that endpoint's ID.

Per the Discuss point, this feels like it's unworkable in practice; if we
had a way to reliably distribute knowledge of which EIDs are usable as node
IDs and/or are in use as node IDs, we could also use that mechanism to
distribute lots of other useful things, like key material, revocation
information, etc.  Since we claim to not be able to do those things, it's a
little boggling to see a claim that we can do this for node IDs.  It kind of
seems like we may have to make a fundamental distinction between "singleton
EIDs" and "EIDs that may have multiple member nodes" in order to get these
properties to be workable globally.

Section 4.1.7

   The second item of the array SHALL be the creation timestamp's
   sequence number, represented as a CBOR unsigned integer.

We haven't introduced the term "sequence number" yet.

Section 4.1.8

   Block-type-specific data in each block (other than the primary
   block) SHALL be the applicable CBOR representation of the content of

nit: as a stylistic matter, this qualification seems too important to
relegate to a parenthetical.

Section 4.2.1

We probably want to check for consistency between what's here and what's
covered in the section-4 intro -- both use normative keywords, and Section 4
talks about the penultimate array item being the payload block, which we
don't mention here.

Section 4.2.2

   The primary block of each bundle SHALL be immutable.  The values of
   all fields in the primary block must remain unchanged from the time
   the block is created to the time it is delivered.

Is there a technical mechanism that can enforce this?

   Lifetime: The lifetime field is an unsigned integer that indicates
   the time at which the bundle's payload will no longer be useful,
   encoded as a number of microseconds past the creation time. (For
   high-rate deployments with very brief disruptions, fine-grained
   expression of bundle lifetime may be useful.)  When a bundle's age

Does this mean that we assume that the creation time has microsecond
accuracy as a reference even though it is only encoded with seconds-level

   the CRC type.  The CRC SHALL be computed over the concatenation of
   all bytes (including CBOR "break" characters) of the primary block
   including the CRC field itself, which for this purpose SHALL be
   temporarily populated with the value zero.

nit: the CRC is a CBOR byte string; "the value zero" assumes an implied
encoding of that byte string.  Perhaps "all bytes zero" is better.

Section 4.2.3

   Every block other than the primary block (all such blocks are termed
   "canonical" blocks) SHALL be represented as a CBOR array; the number
   of elements in the array SHALL be 5 (if CRC type is zero) or 6

Is this an invariant that future-defined block types must also adhere to?

        computed over the concatenation of all bytes of the block
        (including CBOR "break" characters) including the CRC field
        itself, which for this purpose SHALL be temporarily populated
        with the value zero.

[same comment as above re. "all bytes zero"]

Section 4.3.2

   The Bundle Age block, block type 7, contains the number of
   microseconds that have elapsed between the time the bundle was
   created and time at which it was most recently forwarded.  It is

(Are we again assuming the creation time to have microsecond accuracy even
though the precision of representation is in seconds?)

   The block-type-specific data of this block is an unsigned integer
   containing the age of the bundle in microseconds, which SHALL be
   represented as a CBOR unsigned integer item. (The age of the bundle
   is the sum of all known intervals of the bundle's residence at
   forwarding nodes, up to the time at which the bundle was most
   recently forwarded, plus the summation of signal propagation time
   over all episodes of transmission between forwarding nodes.
   Determination of these values is an implementation matter.) If the

I get that determination of these times will depend on the CLA(s) in use,
but it sounds like we are making a hard requirement that an accurate value
with microseconds precision is available?  That seems like a pretty
stringent requirement to place on the underlying transport technologies.

   bundle's creation time is zero, then the bundle MUST contain exactly
   one (1) occurrence of this type of block; otherwise, the bundle MAY
   contain at most one (1) occurrence of this type of block.  A bundle
   MUST NOT contain multiple occurrences of the bundle age block, as
   this could result in processing anomalies.

I'm a bit confused at the formal state of this extension block type.  Up in
Section 4.3 we said that not all nodes will implement processing or
production of extension blocks, but this text is in the core spec and says
that this extension block MUST be present under some conditions.  Is this
implicitly predicated on the implementation in question supporting Bundle
Age, or is it a hard requirement?

Section 4.3.3

Where do we discuss the consequences of nodes failing to implement the Hop
Count extension block (as is apparently allowed by Section 4.3)?

   unsigned integer. A bundle MAY contain at most one (1) occurrence of
   this type of block.

nit: I think this is "MAY contain this type of block" but "MUST contain at
most 1 occurrence".

Section 5.1

   Note that requesting status reports for any single bundle might
   easily result in the generation of (1 + (2 *(N-1))) status report

[(1 + (2 *(N-1))) might be more concisely expressed as ((2*N) -1).]

     . A "bundle reception status report" is a bundle status report
        with the "reporting node received bundle" flag set to 1.
     . A "bundle forwarding status report" is a bundle status report
        with the "reporting node forwarded the bundle" flag set to 1.
     . A "bundle delivery status report" is a bundle status report
        with the "reporting node delivered the bundle" flag set to 1.
     . A "bundle deletion status report" is a bundle status report
        with the "reporting node deleted the bundle" flag set to 1.

These strings (the flag names) appear twice in the document: here and in
Section 6.1.1; neither location explicitly says that it *defines* the flag
values (though the latter does seem to actually do so, in the prose).

Section 5.3

   Step 1: If the bundle's destination endpoint is an endpoint of which
   the node is a member, the bundle delivery procedure defined in
   Section 5.7 MUST be followed and for the purposes of all subsequent
   processing of this bundle at this node the node's membership in the
   bundle's destination endpoint SHALL be disavowed; specifically, even
   though the node is a member of the bundle's destination endpoint,
   the node SHALL NOT undertake to forward the bundle to itself in the
   course of performing the procedure described in Section 5.4.

The discussion so far in the document has not prepared me for the notion
that a bundle would continue to be forwarded even after it has been
delivered.  Please put a description somewhere of why this might occur.
(Also, nit(?): everything in this paragraph is contingent on the node being
a member of the destination endpoint, right?)

Section 5.4

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

I'm a bit confused by this wording, since Figure 4 is in essence a table of
status report reason codes, i.e., values that appear on the wire in status
report messages.  The contents of that table are not, logically, actual
*reasons*, but rather the protocol contants.  It seems like it would be
better to refer to some (possibly prose) description of the actual
situations that would induce a "failure to forward" condition (and cause the
generation of a report using one of those codes).
Furthermore, Figure 4 only contains those codes that are currently defined;
future extensions can define additional codes as well.
(This is not the only place where Figure 4 is referenced as an alleged list
of reasons to not forward.)

   Step 4: For each node selected for forwarding, the bundle protocol
   agent MUST invoke the services of the selected convergence layer
   adapter(s) in order to effect the sending of the bundle to that
   node. [...]

I appreciate the proper use of effect(v) -- thanks!

         Determining the time at which the bundle protocol agent
   invokes convergence layer adapter services is a BPA implementation
   matter.  Determining the time at which each convergence layer
   adapter subsequently responds to this service invocation by sending
   the bundle is a convergence-layer adapter implementation matter.

I appreciate that the actual procedures involved will depend on the CLAs
and, to large extent, BPA implementation, but without giving some
requirements as to what properties are needed, this protocol is incomplete.
I could make a BPA implementation that chooses to never invoke CLA services
and that would comply with this text (yet would not be a usable
implementation at all).

     . If the bundle contains a data label extension block (to be
        defined in a future document) then that data label value MAY
        identify procedures for determining the order in which

This doesn't feel like it needs to be a normative "MAY" vs. descriptive

     . If the bundle has a bundle age block, as defined in 4.3.2.
        above, then at the last possible moment before the CLA
        initiates conveyance of the bundle via the CL protocol the
        bundle age value MUST be increased by the difference between
        the current time and the time at which the bundle was received
        (or, if the local node is the source of the bundle, created).

This does not seem to account for the transmission time from the previous
node to this one, which was a required component in the definition of the
bundle age.

   In that event, processing proceeds from Step 4 of Section 5.4.

[This is Section 5.4, so this is self-referential.]

   If completion of the data sending procedures by all selected
   convergence layer adapters HAS resulted in successful forwarding of

["HAS" is not a BCP 14 keyword.]

   the bundle, or if it has not but the bundle protocol agent does not
   choose to initiate another attempt to forward the bundle, then:
        endpoint ID. The reason code on this bundle forwarding status
        report MUST be "no additional information".

It's kind of weird to use "no additional information" for both the "success"
case and the "I just decided not to" case.

Section 5.4.1

   Otherwise, when -- at some future time - the forwarding of this

nit: two hyphens for the second em dash.

Section 5.6

Why is "Block unintelligible" used for both CRC failures and "extension not

Section 5.8

I suggest to replace "fragmented bundle" with "bundle being fragmented", for

     . Beyond these rules, replication of extension blocks in the
        fragments is an implementation matter.

It seems prudent to give some indication of how the BPsec blocks are managed
across fragmentation.

Section 5.9

   If the concatenation -- as informed by fragment offsets and payload
   lengths -- of the payloads of all previously received fragments with

nit: talking about this as "concatenation of all fragment payloads" is a bit
risky, since we admit the possibility of overlapping fragments; would it be
better to talk about "recovering the full application-data-unit-length byte
array by inserting fragment contents at the indicated offsets"?

     . This byte array -- the reassembled application data unit --
        MUST replace the payload of this fragment.
     . The "Reassembly pending" retention constraint MUST be removed
        from every other fragment whose payload is a subset of the
        reassembled application data unit.

Why is the last-received fragment special that it's payload is replaced by
the entire payload?  Wouldn't it make more sense to promote the fragment
with offset zero, since that is guaranteed to have the right extension

Section 6.1.1

There's a lot of nested arrays here; some examples would really help clarify
the structure.

   Each item of the bundle status information array SHALL be a bundle
   status item represented as a CBOR array; the number of elements in
   each such array SHALL be either 2 (if the value of the first item of
   this bundle status item is 1 AND the "Report status time" flag was

["AND" is not a BCP 14 keyword]

It's somewhat surprising to have several of the reason codes in the figure
that appear with no accompanying prose discussion of when they might be

With the presence of a "traffic pared" report code, one wonders if it might
be worth defining a mechanism to consolidate multiple status reports, so
that one might report (e.g.) paring several bundles in a single status report.

Section 6.2

   Step 1: The administrative record must be constructed. If the
   administrative record references a bundle and the referenced bundle
   is a fragment, the administrative record MUST contain the fragment
   offset and fragment length.

To be clear: this is normative guidance that applies to all administrative
record types that may be defined in the future?

Section 7.2

     . sending a bundle to a bundle node that is reachable via the
        convergence layer protocol;
     . notifying the bundle protocol agent when it has concluded its
        data sending procedures with regard to a bundle;
     . delivering to the bundle protocol agent a bundle that was sent
        by a bundle node via the convergence layer protocol.

   The convergence layer service interface specified here is neither
   exhaustive nor exclusive. That is, supplementary DTN protocol
   specifications (including, but not restricted to, the Bundle
   Security Protocol [BPSEC]) may expect convergence layer adapters
   that serve BP implementations conforming to those protocols to
   provide additional services such as reporting on the transmission
   and/or reception progress of individual bundles (at completion
   and/or incrementally), retransmitting data that were lost in

How is "reporting on the transmission and/or reception progress of
individual bundles" different from the bullet points above?

Section 8

       . the Bundle Protocol (BP, RFC 5050),
       . the Bundle Protocol version 7 specification draft (version 6),

Is this still accurate?  We're on version 21 of the draft, now, not version
6, and it rather defies belief that there have been no protocol-relevant
changes since version -06.  (I understand this will get removed before
publication as an RFC, but it would be somewhat telling if the
implementation efforts had stalled.)

Section 9

Should we discuss the risk that the presence of "reassembly pending"
retention constraints pose of a DoS on node storage, or do we think that's
adequately covered already?

   Additionally, convergence-layer protocols that ensure authenticity
   of communication between adjacent nodes in BP network topology
   SHOULD be used where available, to minimize the ability of

"Authenticity of communication" requires some sense of identity and
credentials associated thereto; with the current formulation of node
identities as EID URIs, I'm not sure what sort of credentials would be used
for this purpose.  Can you give some examples?

   different blocks.  One possible variation is to sign and/or encrypt
   blocks using symmetric keys securely formed by Diffie-Hellman
   procedures (such as EKDH) using the public and private keys of the
   sending and receiving nodes.  For this purpose, the key distribution
   problem reduces to the problem of trustworthy delay-tolerant
   distribution of public keys, a current research topic.

It's important to inject some fresh entropy when using static-static DH for
key generation, as otherwise the problems from cryptographic key reuse
become basically unbearable.

Section 10.1

Technically we're codepoint squatting for the new allocations here (unless
we say that these are "suggested values"), in a specification-required
registry.  I assume the experts (as authors/shepherd) are aware of this work
and would not allocate the requested codepoints to another document, though,
so I am not making this a Discuss point.

   |     6    |     4 | Payload Confidentiality Blk | [RFC6257]     |

We already have rows that spill over to another line; spelling out "Block"
as is done in the current registry contents seems best.

Section 10.3

Why is RFC-to-be listed as a reference for bits 7-13 when the applicable
version is only 6 (not 7)?

Section 10.5

[same note about codepoint-squatting]

   |     6,7 |        5 | Destination endpoint ID          |[RFC5050],|

   |         |          |    unintelligible                |RFC-to-be |

The current wording is "Destination endpoint ID unavailable", so this is
requesting a content change.

   |     6,7 |        8 | Block unintelligible             |[RFC6255],|

   |         |          |                                  |RFC-to-be |

The registry currently shows RFC 5050 as a reference, not RFC 6255.

   |     6   |      255 | Reserved                         |[RFC6255] |

Not also RFc-to-be?

Section 10.6

   The Bundle Protocol has a URI scheme type field - an unsigned
   integer of undefined length - for which IANA is requested to create

(All CBOR unsigned integers are of "indefinite" (variable) length.  Also
note that RFC 7049 prefers to use "indefinite length" over "undefined
length", but also that 7049 does not use "indefinite length" for integers.)

    |            1 | dtn                         | RFC-to-be         |

    |            2 | ipn                         | [RFC6260]         |

Why is "ipn" left with RFC6260 as the reference even though we are updating
its registration in this document just as we are for "dtn"?

Section 10.7 (and with minimal changes, 10.8)

   dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

Is there supposed to be more (or less) to that comment?

        receives the bundle.  In both cases (and indeed in all bundle
        processing), the node that receives a bundle should verify its
        authenticity and validity before operating on it in any way.

How is this possible in the absence of BPSEC?  Does this imply a
recommendation or requirement to implement BPSEC?

Section 11.1

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

I agree with the directorate reviewer that we need to give a more concrete
reference here (e.g., draft-ietf-dtn-bpsec)

Section 11.2

The way in which we reference [UTC] is arguably normative.

Appendix B

   start = bundle / #6.55799(bundle)

This is the tag for "self-describe [sic] CBOR" per RFC 7049; did Carsten
make any indication that a more specific tag could/should be allocated for

   ; The root bundle array

   bundle = [primary-block, *extension-block, payload-block]

I see that CDDL does not have provisions for noting indefinite- vs.
definite-length encoding, so a comment here might be in order.

   bundleflagbits = &(

     reserved: 21,

RFC 8610 seems to suggest that omitting reserved bits may be appropriate (to
disallow them from being set within this CDDL model).  (Similarly for the

(Mirja Kühlewind) Discuss

Discuss (2020-02-03 for -21)
I looked up RFC 4838 and there is a section on congestion control, however it only says:
"Congestion control is an ongoing research topic."
Unfortunately this document also doesn't give any further advise about congestion control but as a PS it really should. I understand that the bundle protocol is basically an application layer protocol on top of a transport that should care about congestion control, however, the document doesn't talk much about anything related to that underlying protocol. It would be important to specify requirements for the underlying transport protocol, indicating that is must be congestion controlled or rate limited (see RFC8085 as a reference for rate limiting of (uni-direction) UDP-based protocols).

Further this sentence in Sec 5.1 needs more clarification:
“For this reason, the generation of status reports MUST be
   disabled by default and enabled only when the risk of excessive
   network traffic is deemed acceptable.”
It is not clear when it makes sense to enable and if enables one should probably also implement some filtering and rate limiting.
Comment (2020-02-03 for -21)
1) One general comment on the style of the document: I found it actually quite hard to read. I think it would help to add some overview text from time to time instead of going into all the details right away. E.g. maybe provide some kind of short summary/overview at the beginning of section 5 like the “Life cycle of a bundle“. In contrast I think you could cut down the section on concepts a bit (move some the implementation related notes to the appendix). Further, compared to the previous RFC, now that CBOR is used the text because actually more abstract. I think it would actually help to put CDDL fragment in body of document.

2) Sec 4.1.3 and 4.1.4: Maybe use normative language here for all or most of the musts, e.g. 
s/then all status report request flag values must be zero/then all status report request flag values MUST be zero/

3) Quick question on Sec 4.2.2:
“Version number SHALL be
   represented as a CBOR unsigned integer item.”
The document says that this version is not backward compatible. Is the version number the only field that can be used to identify the bundle protocol?

Alvaro Retana Discuss

Discuss (2020-02-06 for -22)

   The registration policy for this namespace is changed to "Standards
   Action". Given the limited number of bits available, the allocation
   should only be granted for a standards-track RFC approved by the

The original BP work (rfc5050) is a product of the IRTF.  The new registration policy blocks the ability for anyone outside the IETF to register new values.  I understand the need to conserve resources, and the intent to Obsolete rfc5050 in a separate document, which should mean that future work on the BP is done in the IETF.  That process hasn't been done yet.

I am balloting DISCUSS on this point of the process so that the needed steps can catch up and the group of documents can progress together.

[Note that changing the registration policy to allow work from outside the IETF to use the registries would also lead me to clear this DISCUSS.  However, I don't think that is necessary.]
Comment (2020-02-06 for -22)
I support Ben's DISCUSS.

Magnus Westerlund (was Yes) Discuss

Discuss (2020-06-29 for -25)
Holding discuss to ensure IANA is satisfied, which they are pending 2 minor editorial fixes.
Comment (2020-06-29 for -25)
No email
send info
I consider Mirja's discuss to be resolved.

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2020-02-06 for -22)
I support Benjamin's first DISCUSS point.

The registration templates in 10.7 and 10.8 should include iesg@ietf.org as the contact information for the change controller.

Roman Danyliw (was Discuss) No Objection

Comment (2020-02-24 for -23)
No email
send info
Thank you for addressing my DISCUSS and COMMENTs items.

(Suresh Krishnan) No Objection

Barry Leiba No Objection

Comment (2020-02-05 for -22)
I support the Sec ADs’ DISCUSS and comment points.  I have only a small thing to add to what’s already been said:

— Section 1 —
You mention RFC5050 several times here, but it isn’t actually cited as a reference until Section 10.1.  You would normally put it in as a citation the first time, at the beginning of Section 1, and I think you should.

(Alexey Melnikov) (was Discuss) No Objection

Comment (2020-02-20 for -23)
No email
send info
I am clearing my DISCUSS with understanding that future work will be done in this area:

1) Retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details.
Below I describe 1 remaining relevant place in the text and suggest some possible ways of addressing my DISCUSS:

   Step 5: When all selected convergence layer adapters have informed
   the bundle protocol agent that they have concluded their data
   sending procedures with regard to this bundle, processing may depend
   on the results of those procedures.  If completion of the data
   sending procedures by all selected convergence layer adapters has
   not resulted in successful forwarding of the bundle (an
   implementation-specific determination that is beyond the scope of
   this specification), then the bundle protocol agent MAY choose (in
   an implementation-specific manner, again beyond the scope of this
   specification) to initiate another attempt to forward the bundle.

Similar to the above: retries affect interoperability and should be documented
as description of a convergence layer document.
I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer").

   In that event, processing proceeds from Step 4 of Section 5.4.

* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"

The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:
This draft’s content seems sound but the text is difficult to understand and needs some editorial improvements.

## Abstract

Nit: Abstract should be before status.
Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”.

## Section 1

Title: If this document doesn’t describe the operation, routing, or management of bundles, maybe it doesn’t describe a complete protocol.  Consider retitling to “Bundle Protocol Version 7: Format and Architecture”

[[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position is stronger than this statement.

## Section 4.1.3

Nit: It would be clearer to move the reserved and unassigned flags to an IANA considerations section, here and throughout.

## Section 4

Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.”  This seems like a misuse of the word “item”.  I would suggest “The array SHALL be terminated by a CBOR “break” stop code.”  Similarly in Section 4.2.1.

## Section 4.1.4

Clarity: The “(Boolean)” specifiers seem redundant.  What is a non-boolean flag?

Clarity: The two lists here seem redundant.  Can they be collapsed?

Clarity: The phrasing “...the value of the "Transmit status report if block can't be processed" flag in every canonical block…” suggests that these flags should be named or numbered before attempting to describe them.

## Section

These two sentences seem contradictory:

* “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID.”
* “The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers”

Please rephrase.

[[Alexey]]: This is similar to Roman's DISCUSS.

## Section 5.4.2

Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block.

Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop?

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

##Section 5.6

Error handling: What about CBOR parsing failures?

[[Alexey]]: I included these in the DISCUSS portion of my ballot.

## Section 5.8

Clarity: The insistence, here and earlier, that a bundle is only fragmented into two packets, and that this can then be performed recursively, seems unhelpful.  Bundles can be fragmented into arbitrarily many pieces, and this binary subdivision concept is not actually present in the protocol.  I suggest removing it from the text as well.

## Section 6.1

Formatting: This table is excessive for a single value.

Clarity: The text specifies the contents twice, which is unhelpful for comprehension.

## Section 10

Formatting: The extra line breaks in the vertical dividers are distracting.  Please fill them in or remove the breaks if possible.

(Adam Roach) No Objection

Éric Vyncke No Objection

Comment (2020-02-03 for -21)
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,



Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Martin Vigoureux No Record

Robert Wilton No Record