Early Review of draft-ietf-manet-dlep-credit-flow-control-15
review-ietf-manet-dlep-credit-flow-control-15-rtgdir-early-dhody-2024-08-12-00

# RTGDIR review of draft-ietf-manet-dlep-credit-flow-control

Hello,

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-credit-flow-control/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached. As this document is
post-working-group-last-call, my focus for the review was to determine whether
the document is ready to be published.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-manet-dlep-credit-flow-control-15
Reviewer: Dhruv Dhody
Review Date: 12 Aug 2024
Intended Status: Standards Track

## Summary:

This is a well-written document with a clear specification that should be easy
to follow for an implementer. I have a few comments and nits.

## Comments:

* I went into the archive to understand the split and relationships between
documents. Perhaps authors will consider adding it as an appendix for future
readers.

* Section 1; What is the correct reference for "Credit Windows"? Is it
[I-D.ietf-manet-credit-window]? Should it be a normitive reference then as
"Credit Window" is a fundamental concept for this I-D? Or perhaps Section 2 can
stand on its own?

* Section 2.1; Suggest adding "(including any MAC overhead)" to "The credit
window is decremented by the number of sent octets."

* Section 2.3; In this text -- "Any errors or inconsistencies encountered in
parsing Data Items are handled in the same fashion as any other data item
parsing error encountered in DLEP, see [RFC8175]. In particular, the node
parsing the Data Item MUST terminate the session with a Status Data Item
indicating Invalid Data."; the second statement is trying to rephrase existing
RFC 8175 text and thus the use of MUST here is inappropriate.

* Section 2.4; I fail to understand the reason for MAY in "Modems MAY support
the configuration of the number of credit windows (queues) to advertise to a
router". IMHO it should be a SHOULD :)

* Section 4; My personal preference is that security consideration should
highlight security mechanisms from RFC 8175. Is it possible to highlight some
that are specifically related to Credit-Based Flow Control?

* Section 5.1; please update the name of the registry to "Message Type Values".
Update the description in the table to include the term "Message" to align with
https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#message-type-values

## Nits:

* Expand DLEP in the Title

* Expand on first use - DSCP

* Please use a hyphen for "link related", "pause based", "per flow", "window
based", "modem attached", "per destination", "fine grain", "DLEP identified",
"destination specific"

* Appendix A; Please merge paragraphs 2 and 4 as they both mourn the loss of
David.

Thanks!
Dhruv