On Tue Dec 02 13:21:58 -0800 2025, Lynne Bartholomew wrote: > Hi, Eric. Thank you for the email. > > We have updated this document per your notes below. > > A couple follow-up items for you: > > * Please review our update regarding our question 8); it appears that you > approved our "Perhaps" text. We kept both citations for RFC 8175 to avoid > possible confusion between "Status Data Item" and "Credit Window Status Data > Item". Please let us know whether or not our update is correct here (and if > you object to the second citation for RFC 8175).
I approved the "Perhaps" text. Your update is correct. > > * May we change '"Credit Window Initialization"' to '"credit window > initialization"' in this sentence (appears to be used generally and applies > to this document only)? > > Modems provide an initial credit window size at the time of "Credit > Window Initialization". Yes, changing that to lowercase letters makes sense. I also think the quotation marks can be removed, but I'll leave that to your judgement. Thanks, Eric > = = = = = > > The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9893.txt > https://www.rfc-editor.org/authors/rfc9893.pdf > https://www.rfc-editor.org/authors/rfc9893.html > https://www.rfc-editor.org/authors/rfc9893.xml > https://www.rfc-editor.org/authors/rfc9893-diff.html > https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html (side by > side) > https://www.rfc-editor.org/authors/rfc9893-lastdiff.html > https://www.rfc-editor.org/authors/rfc9893-lastrfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > > Thanks again! > > Lynne Bartholomew > RFC Production Center > > > 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". > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
