On Dec 2, 2025, at 8:38 AM, Eric Kinzie <[email protected]> wrote:
Lynne, please see my responses below.
Thanks,
Eric
On Mon Dec 01 08:33:00 -0800 2025, Lynne Bartholomew wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as necessar=
y) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in =
the
title) for use on <https://www.rfc-editor.org/search>. -->
2) <!-- [rfced] Abstract: As it appears that the two new message types
(Credit Control and Credit Control Response) also figure prominently
in this document (and appear to be mentioned in the document title),
would you like to also mention them in the Abstract?
Original:
This document defines new Dynamic Link Exchange Protocol (DLEP) Data
Items that are used to support credit-based flow control. Credit
window control is used to regulate when data may be sent to an
associated virtual or physical queue. The Data Items are extensible
and reusable.
Possibly:
This document defines new Dynamic Link Exchange Protocol (DLEP) Data
Items that are used to support credit-based flow control. Credit
window control is used to regulate when data may be sent to an
associated virtual or physical queue. These Data Items are
extensible and reusable.
This document also defines new messages that support credit window
control. -->
That change is fine.
3) <!-- [rfced] FYI: We have added expansions for abbreviations where
they are first used, per Section 3.6 of RFC 7322 ("RFC Style Guide")
(https://www.rfc-editor.org/info/rfc7322). Please review the
following expansions to ensure correctness.
DSCP: Differentiated Services Code Point (Figure 1)
MAC: Media Access Control (Section 2)
PCP: Priority Code Point (Figure 1) -->
OK.
4) <!-- [rfced] Section 1: We updated "control plane pause based
mechanism" per RFC 8651. Please let us know any objections.
Original:
For example, a credit-window
scheme for destination-specific flow control which provides aggregate
flow control for both modem and routers has been proposed in
[I-D.ietf-manet-credit-window], and a control plane pause based
mechanism is defined in [RFC8651].
Currently:
For example, a credit-window
scheme for destination-specific flow control that provides aggregate
flow control for both modems and routers has been proposed in
[Credit-Window-Extension], and a mechanism referred to as the
Control-Plane-Based Pause Extension is defined in [RFC8651]. -->
OK.
5) <!-- [rfced] Section 2: We had trouble determining what is listed in
this sentence. We updated as follows. If this is incorrect, please
clarify the text.
Original:
This means that the use of FIDs, TIDs and the
association of a TID to a DLEP destination enables a modem to share
or dedicate resources as needed to match the specifics of its
implementation and its attached transmission technology.
Currently:
This means that the use
of FIDs and TIDs, and the association of a TID to a DLEP destination,
enable a modem to share or dedicate resources as needed to match the
specifics of its implementation and its attached transmission
technology. -->
OK.
6) <!-- [rfced] Section 2.1: We had trouble following this sentence.
Does "framing" mean "frame size" or something else?
Original:
In the example of Ethernet, framing,
header and trailer are all included in this count. -->
"framing" is used here as it is used in the Ethernet standard. I would
prefer to leave this unchanged.
7) <!-- [rfced] Section 2.2.1: We had trouble parsing these sentences.
If the suggested text is not correct, please clarify "having data
traffic available to send, but no credits available".
Original:
Modems will need to balance the
load generated by sending and processing credit window increases
against a router having data traffic available to send, but no
credits available.
...
Routers will need to balance the load
generated by sending and processing credit window requests against
having data traffic available to send, but no credits available.
Suggested:
Modems will need to balance the
load generated by sending and processing credit window increases
against a router that has data traffic available to send but no
available credits.
...
Routers will need to balance the load
generated by sending and processing credit window requests against
having data traffic available to send but no available credits. -->
OK.
8) <!-- [rfced] Section 2.3: Does "a Status Data Item" refer
specifically to the Status Data Item defined in RFC 8175 - in which
case RFC 8175 should be cited here - or does it refer to the Credit
Window Status Data Item as defined in this document?
Original:
In particular, the node parsing
the Data Item MUST terminate the session with a Status Data Item
indicating Invalid Data.
Perhaps:
In particular, the node parsing
the Data Item MUST terminate the session with a Status Data Item
[RFC8175] indicating "Invalid Data".
It refers to the Status Data Item defined in RFC 8175. This wording
is fine. I think it is also ok to remove "; see [RFC8175]" from the
previous sentence if this seems repetitive.
Or possibly:
In particular, the node parsing
the Data Item MUST terminate the session with a Credit Window Status
Data Item indicating "Invalid Data" as defined in [RFC8175]. -->
9) <!-- [rfced] Section 2.3.1: As the dashes initially appeared to be
minus signs, we changed them to colons. If this is incorrect, please
consider whether these entries could be written in some other way.
We also gave the table a title. Please let us know any objections.
If you prefer a different title, please specify.
Original (dashes are broken in order to avoid xml2rfc's "Double
hyphen within comment" error):
Value Scale
- - - - -
0 B - Bytes (Octets)
1 KB - Kilobytes (B/1024)
2 MB - Megabytes (KB/1024)
3 GB - Gigabytes (MB/1024)
Currently:
+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Value | Scale |
+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| 0 | B: Bytes (Octets) |
+- - - -+- - - - - - - - - - - - -+
| 1 | KB: Kilobytes (B/1024) |
+- - - -+- - - - - - - - - - - - -+
| 2 | MB: Megabytes (KB/1024) |
+- - - -+- - - - - - - - - - - - -+
| 3 | GB: Gigabytes (MB/1024) |
+- - - -+- - - - - - - - - - - - -+
Table 1: Valid Scale Field Values -->
That table looks good. No objection.
10) <!-- [rfced] Section 2.3.1: Does "Credit Value" specifically refer
to the Credit Value field, or does it mean "credit value" as used
generally elsewhere in this document (e.g., "appropriate credit
values" as written in Section 2)?
Original:
If the resulting
Credit Value results in the credit window exceeding the represented
Credit Window Max Size, the Credit Window Max Size field value is
used as the new credit window size. -->
It means "credit value" as used generally elsewhere and should not be
capitalized.
New:
If the resulting
credit value results in the credit window exceeding the represented
Credit Window Max Size, the Credit Window Max Size field value is
used as the new credit window size.
11) <!-- [rfced] Section 2.3.2: Because this sentence as written
indicated that the data plane state is updated as needed, we changed
"are" to "is" accordingly (also per "In both cases, a router MUST
also ensure that any data plane state, e.g.,
[I-D.ietf-manet-dlep-credit-flow-control], that is associated with
the TID is updated as needed." in
draft-ietf-manet-dlep-traffic-classification, where it cites this
document). If this is incorrect, please clarify what is being
updated as needed.
Original:
If the traffic classification information is located, the
router MUST ensure that any data plane state that is associated with
the TID and its corresponding FIDs are updated as needed (per
Section 2.1).
Currently:
If the traffic classification information is located, the
router MUST ensure that any data plane state that is associated with
the TID and its corresponding FIDs is updated as needed (per
Section 2.1). -->
OK.
12) <!-- [rfced] Section 2.3.3: Does "a Credit Window Status Data Item
or items" mean "one or more Credit Window Status Data Items" here, or
does "or items" refer to some other types of items other than Data
Items? We ask because we see "Credit Window Status Data Item(s)" in
the next sentence.
Original (the next sentence is included for context):
When a Credit Window Grant Data Item is received in other
message types, the receiving router MUST send a Credit Window Status
Data Item or items reflecting the resulting Credit Window value of
the updated credit window. When the Credit Grant Data Item is
received in a Destination Up Message, the Credit Window Status Data
Item(s) MUST be sent in the corresponding Destination Up Response
Message.
Perhaps:
When a Credit Window Grant Data Item is received in other
message types, the receiving router MUST send one or more Credit
Window Status Data Items reflecting the resultant Credit Window
value of the updated credit window. -->
This means "one or more Credit Window Status Data Items".
New:
For each Credit Window Grant Data Item received in other
message types, the receiving router MUST send a Credit Window Status
Data Item reflecting the resulting Credit Window value of
the updated credit windows.
13) <!-- [rfced] Section 2.3.5: Should "credit request" be "credit
window request" as used generally elsewhere in the text? We don't
see "credit request" used anywhere else in this document or group of
documents (Cluster 541 /
https://www.rfc-editor.org/cluster_info.php?cid=3DC541).
Original:
A special FID value, as defined below, is used to
indicate that a credit request is being made across all queues. -->
Yes, it should be "credit window request".
New:
A special FID value, as defined below, is used to
indicate that a credit window request is being made across all queues.
14) <!-- [rfced] Section 2.3.5: We do not see a Type field in RFC 8175,
but we see a "Data Item Type" field. May we update as suggested
(per Section 11.3 ("DLEP Generic Data Item") of RFC 8175), to
distinguish this definition from the definitions of Length in
Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message Header")
of RFC 8175, which do not mention excluding a "Type" field?
Original:
As specified in [RFC8175], Length is the number of octets in the
Data Item, excluding the Type and Length fields.
Suggested:
As specified in [RFC8175], Length is the number of octets in the
Data Item, excluding the Data Item Type and Length fields. -->
OK.
15) <!-- [rfced] Section 2.3.5: We changed "Credit Increment" to "credi=
t
window increment" here, as we could not find the initial-capitalized
form elsewhere in this document, in the group (cluster) of related
documents, or in any published RFC to date. This update is also in
line with this sentence from Section 2.2.1:
A modem receiving this
message MUST respond with a Credit Control Response Message based on
the received message and Data Item and the processing defined in
Section 2.2.2, which will typically result in credit window
increments being provided.
Please let us know any objections.
Original:
A modem receiving this Data Item MUST provide a Credit Increment for
the indicated credit windows via Credit Window Grant Data Items
carried in a new Credit Control Message.
Currently:
A modem receiving this Data Item MUST provide a credit window
increment for the indicated credit windows via Credit Window Grant
Data Items carried in a new Credit Control Message. -->
OK.
16) <!-- [rfced] Section 2.4: We changed "the mismatch of capabilities"
to "any mismatch in capabilities" per
draft-ietf-manet-dlep-ether-credit-extension. Please let us know any
objections.
Original:
In
either case, the mismatch of capabilities SHOULD be reported to the
user via normal network management mechanisms, such as the user
interface or error logging.
Currently:
In
either case, any mismatch in capabilities SHOULD be reported to the
user via normal network management mechanisms, such as the user
interface or error logging. -->
OK.
17) <!-- [rfced] Section 4: We had trouble following "some updated
references to external documents listed below" in this paragraph.
It appears that "external documents" is intended to refer to
[BCP195], [IEEE-802.1AE], and [IEEE-8802-1X].
However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE Standards
for Local and metropolitan area networks-Port-Based Network Access
Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC
International Standard-Telecommunications and exchange between
information technology systems-Requirements for local and
metropolitan area networks-Part 1X:Port-based network access
control").
May we update as suggested? If not, please clarify the text.
Original:
The transport layer security mechanisms documented in [RFC8175], with
some updated references to external documents listed below, can be
applied to this document.
Suggested:
The transport layer security mechanisms documented in [RFC8175],
along with the latest versions of [BCP195], [IEEE-802.1AE], and
[IEEE-8802-1X] at the time of this writing, can be applied to this
document. -->
The IEEE documents should not be referenced in this sentence.
New:
The transport layer security mechanisms documented in [RFC8175],
along with the latest version of [BCP195] at the time of this writing,
can be applied to this document.
18) <!-- [rfced] [IEEE-802.1AE]: The title listed here does not match
the title found at the provided URL. Is the intent here to
specifically point to Amendment 4 (in which case the citation string
should be changed to [IEEE-802.1AEdk-2023] and the URL should be
changed to <https://ieeexplore.ieee.org/document/10225636>), or would
you prefer to list [IEEE-802.1AE] per
draft-ietf-manet-dlep-traffic-classification-17?
Original:
[IEEE-802.1AE]
"IEEE Standard for Local and metropolitan area networks-
Media Access Control (MAC) Security Amendment 4: MAC
Privacy protection",
<https://ieeexplore.ieee.org/document/8585421>.
As listed in the edited copy of
draft-ietf-manet-dlep-traffic-classification-17:
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018,
December 2018,
<https://ieeexplore.ieee.org/document/8585421>. -->
I don't think it's necessary to specify amendment 4.
New:
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018,
December 2018,
<https://ieeexplore.ieee.org/document/8585421>. -->
19) <!-- [rfced] Appendix B: We changed "traffic classification data sub
items" to "Traffic Classification Sub-Data Items" per
draft-ietf-manet-dlep-traffic-classification and the rest of this
group (Cluster 541 /
https://www.rfc-editor.org/cluster_info.php?cid=3DC541) of documents.
Please let us know any objections.
Original:
[I-D.ietf-manet-dlep-traffic-classification] defines the traffic
classification data sub items such as DiffServ code points that map
to the FIDs.
Currently:
[RFC9892] defines the Traffic
Classification Sub-Data Items, such as DSCPs, that map to the FIDs. -->
OK.
20) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
Reviewed. I haven't found anything that does not comply with the NIST
guidance.
21) <!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following terms were used inconsistently in this document.
We chose to use the latter forms. Please let us know any objections.
Additional Credit (field name, i.e., "Additional Credit:") /
Additional Credits ("Additional Credits field")
credit based flow control / credit-based flow control (added hyphen)
Credit-Based Flow Control (in text) / credit-based flow control
Credit Control message (2 instances) / Credit Control Message
Credit Control Response message (1 instance) /
Credit Control Response Message
Credit Window size (1 instance, i.e., "a Credit Window size") /
credit window size (7 instances, e.g., "an initial credit window
size") (used generally throughout Section 2)
data item / Data Item (per the rest of this document and per this
group (cluster) of documents)
different Credit windows / different credit windows
Messages / messages ("common Messages", "No messages")
(We changed "common Messages" to "common messages".)
Window Association Data Item (2 instances in Appendix B) /
Credit Window Association Data Item (10 instances in text,
the table entry in the IANA Considerations section, and
<https://www.iana.org/assignments/dlep-parameters/>)
OK.
b) The following term appears to be used inconsistently in this
document. Please let us know which form is preferred.
Credit Window / credit window (used generally, e.g., "associated
Credit Window", "associated credit window",
'logical "Credit Window(s)s"')
(Note: We also see 'logical "Credit Windows"' in
draft-ietf-manet-dlep-da-credit-extension. Otherwise, all of the
documents in this group of documents use the lowercase form
"credit window" when used generally.)
Let's use lowercase "credit window" when used generally.
c) Please let us know how/if the following should be made consistent:
Credit Grant Data Item (3 instances in text) /
Credit Window Grant Data Item (~13 instances in text) /
Grant Data Item (2 instances in text) ("each Grant Data Item",
"or Grant Data Item")
Suggested, assuming that these different forms all refer to the
same type of Data Item: Credit Window Grant Data Item, per
<https://www.iana.org/assignments/dlep-parameters/>.
Alternatively, please let us know if the IANA entry needs to
be changed (e.g., from "Credit Window Grant" to "Credit Grant"
or simply "Grant", noting that any such change would not match
the format of the other entries on the page.) -->
These can all be changed to "Credit Window Grant Data Item".
