[dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dtn-bpbis-21: 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 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:
----------------------------------------------------------------------

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?