[manet] Rtgdir early review of draft-ietf-manet-dlep-credit-fl ow-control-15

Dhruv Dhody via Datatracker <[email protected]>
Newsgroups gmane.ietf.manet
Message-ID <172345788331.705044.11691082238928278542@dt-datatracker-6df4c9dcf5-t2x2k>
Reviewer: Dhruv Dhody
Review result: Has Nits

# 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


_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.