[dtn] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-bpbis-22: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be
clarified.

Initially the text says:

The scheme identified by the < scheme name > in an endpoint ID is a
   set of syntactic and semantic rules that fully explain how to parse
   and interpret the SSP. The set of allowable schemes is effectively
   unlimited. Any scheme conforming to [URIREG] may be used in a bundle
   protocol endpoint ID.

[URIREG] would suggest that any schema in IANA "Uniform Resource Identifier
(URI) Schemes" Registry’ is valid.  However, later, the text says:

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].

This text suggests that the new Bundle Protocol URI Scheme Type registry should
govern the EID schemes.  However, then the text again cites URIREG.  Perhaps
the intent is that URI's valid per [URIREG] would be registered in the new
bundle protocol registry and values in this new registry would be used.


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

** Figure 1.  Does the second from the left column running “T1/T2” and “N1/N2”
mean that this node has a dual stack of N1+T1 and N2+T2?

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would
assume yes, but don't see that said anywhere?

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to
Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

** Section 3.1.  Per the definition of Registration, and registrations having
two states (active and passive), could you please clarify why one would choose
to be in either state.

** Section 3.3. Per this list of BPA services, please add clarifying language
to the effect that the details of this registration functionality is out of
scope.

** Section 4.
   (Note that, while CBOR permits considerable flexibility in the
   encoding of bundles, this flexibility must not be interpreted as
   inviting increased complexity in protocol data unit structure.)

What is practical guidance should an implementer take from this text?

** Section 4.1.5.2  Per “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.” --
what does it mean to “sustain” the membership? -- how would a node know that
the "nominal operation of the BP no longer depends" of this address binding?

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID    and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is
that behavior described?

** Section 5.1.  Per “When the generation of status reports is enabled, the
decision on whether or not to generate a requested status report is left to the
discretion of the bundle protocol agent.”, can way points also choose not for
forward these reports based on configuration?

** Section 6.1.1.
   Valid status
   report reason codes are defined in Figure 4 below but the list of
   status report reason codes provided here is neither exhaustive nor
   exclusive; supplementary DTN protocol specifications (including, but
   not restricted to, the Bundle Security Protocol [BPSEC]) may define
   additional reason codes.

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status
Report Reason Codes” sub-registry) as the canonical place to understand
semantics of future values?

** Section 9.  Recommend being clearer on the scope of the protections.

OLD:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the integrity and
   confidentiality of bundle blocks are protected while the bundle is
   at rest, awaiting transmission at the next forwarding opportunity,
   as well as in transit.

NEW:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the protections they afford
   apply when while the bundle is at rest, awaiting transmission at
   the next forwarding opportunity,
   as well as in transit.

** Section 9.  How is an implementor supposed to use the guidance in “Note
that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research
topic”?  There is no actionable guidance or pointers to more information.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range
...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using
symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a
spec needs to be written to register a security context to realize this
approach.  Recommend removal.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not
defined anywhere

-- Section 5.4.  s/adapter(s) in order to effect/adapter(s) in order to affect/