Dear Bow-Nan, Lou, and Eric, Checking in with you regarding the status of this document. Please let us know whether further updates are needed or you approve this document for publication in its current form.
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 The AUTH48 status page is here: https://www.rfc-editor.org/auth48/rfc9893 Thank you! Lynne Bartholomew RFC Production Center > On Dec 3, 2025, at 9:03 AM, Lynne Bartholomew > <[email protected]> wrote: > > Hi, Eric. Thanks for your prompt reply to our follow-up items! We have > changed '"Credit Window Initialization"' to "credit window initialization" > (quotation marks removed; they're here only to show what was updated). > > This update is reflected in the latest files, which 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 3:58 PM, Eric Kinzie <[email protected]> wrote: >> >> 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]
