Authors, While reviewing this document during AUTH48, please resolve (as necessary) 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. --> 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) --> 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]. --> 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. --> 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. --> 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. --> 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". 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: +=======+=========================+ | Value | Scale | +=======+=========================+ | 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 --> 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. --> 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). --> 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. --> 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=C541). Original: A special FID value, as defined below, is used to indicate that a credit 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. --> 15) <!-- [rfced] Section 2.3.5: We changed "Credit Increment" to "credit 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. --> 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. --> 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. --> 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>. --> 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=C541) 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. --> 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. --> 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/>) 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.) 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.) --> Thank you. Lynne Bartholomew and Rebecca VanRheenen RFC Production Center On Nov 14, 2025, at 2:00 PM, [email protected] wrote: *****IMPORTANT***** Updated 2025/11/14 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9893.xml https://www.rfc-editor.org/authors/rfc9893.html https://www.rfc-editor.org/authors/rfc9893.pdf https://www.rfc-editor.org/authors/rfc9893.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9893-diff.html https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9893-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9893 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9893 (draft-ietf-manet-dlep-credit-flow-control-19) Title : Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items Author(s) : B. Cheng, D. Wiggins, S. Ratliff, L. Berger, E. Kinzie, Ed. WG Chair(s) : Don Fedyk, Ronald in 't Velt, Donald E. Eastlake 3rd Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
