# 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