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

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov 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:
----------------------------------------------------------------------

I am looking forward for this document to be finished and approved as an RFC.
Before I can recommend this, I have several DISCUSS points and comments that I
would like to address:

1) Routing decisions, discovery of endpoints to contact for forwarding and
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 3 relevant
places in the text and suggest some possible ways of addressing my DISCUSS:

5.4. Bundle Forwarding

   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:

     . The bundle protocol agent MAY choose either to forward the
        bundle directly to its destination node(s) (if possible) or to
        forward the bundle to some other node(s) for further
        forwarding. The manner in which this decision is made may
        depend on the scheme name in the destination endpoint ID and/or

Lack of this information (how node to forward to are discovered) would prevent
interoperability. (By comparison, SMTP specification which has somewhat similar
design contains information about how next nodes to forward to are selected.)

I think you need to create a new section in this document specifying
requirements on URI scheme documents and include this as a MUST level
requirement there. (If you already have a document that does this, you can just
normatively point to it.)

        on other state but in any case is beyond the scope of this
        document. If the BPA elects to forward the bundle to some other
        node(s) for further forwarding but finds it impossible to
        select any node(s) to forward the bundle to, then forwarding is
        contraindicated.

     . Provided the bundle protocol agent succeeded in selecting the
        node(s) to forward the bundle to, the bundle protocol agent
        MUST subsequently select the convergence layer adapter(s) whose
        services will enable the node to send the bundle to those
        nodes.  The manner in which specific appropriate convergence
        layer adapters are selected is beyond the scope of this
        document.

Similar to the above: lack of description of how convergence layers are
discovered (for example this might include discovery using DNS or something
else) or, alternatively, a mandatory to implement convergence layer would
affect interoperability. I think you need to add this as a requirement to
section 7 ("Services Required of the Convergence Layer").

Also having some (even non normative) information
about which convergence layer to select if multiple are available would be
useful.

        If the agent finds it impossible to select any
        appropriate convergence layer adapter(s) to use in forwarding
        this bundle, then forwarding is contraindicated.

   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.

2) As pointed out by Benjamin Schwartz:

In 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?

3) As pointed out by Benjamin Schwartz:

In Section 5.6

Error handling: What about CBOR parsing failures?


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

**********************************************************************
* 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 <[e-mail]>:

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 4.1.5.1

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.