Dear Eric and *AD (Jim), Eric, we have made this update.
* Jim, please review the latest update in Section 1, where a "MAY" has been added, and let us know if you approve. 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 Thank you! Lynne Bartholomew RFC Production Center > On Jan 23, 2026, at 12:52 PM, Eric Kinzie <[email protected]> wrote: > > Lynne, > >>> Should "Traffic Classification Data Items provided by the modem are" be >>> "The Traffic Classification Data Item provided by the modem is" or possibly >>> "Traffic Classification Sub-Data Items provided by the modem are"? Or does >>> the text refer to multiple instances of the Traffic Classification Data >>> Item defined in RFC 9892 (in which case perhaps this should be clarified)? > > There can be multiple instances of the Traffic Classification Data Item. > Possibly: > > "The Traffic Classification Data Item provided by the modem is defined > in [RFC9892]. In this case, a flow is identified based on information > found in a data plane header, and one or more matches are associated > with a single flow. As stated in [RFC8982], more than one Data Item > MAY be included in a message to provide information on multiple traffic > classifiers. Refer to" . . . > > I think the wording of the second location you pointed out is ok. > > Thanks, > Eric > > On Mon Jan 05 10:11:22 -0800 2026, Lynne Bartholomew wrote: >> Dear authors, >> >> Happy New Year! >> >> We could not find a reply to the following questions. Apologies if we >> missed it. Please advise. >> >> Thank you! >> >> Lynne Bartholomew >> RFC Production Center >> >>> On Dec 23, 2025, at 3:03 PM, Lynne Bartholomew >>> <[email protected]> wrote: >>> >>> Hello again. Forgot to mention that we also see the following text >>> elsewhere in this document: >>> >>> based on the Traffic Classification Data Item defined in >>> [RFC9892] >>> ... >>> flow >>> identification information provided by modems in the Traffic >>> Classification Data Item defined in [RFC9892] >>> ... >>> flow identifier as defined by the Traffic Classification >>> Data Item [RFC9892] >>> >>> Thank you. >>> >>> Lynne Bartholomew >>> RFC Production Center >>> >>> On Dec 23, 2025, at 2:56 PM, Lynne Bartholomew >>> <[email protected]> wrote: >>> >>> Dear authors, >>> >>> Apologies for not spotting this earlier: We see the following text in this >>> document: >>> >>> Traffic Classification Data Items provided by the modem are defined in >>> [RFC9892]. >>> >>> However, it appears that RFC 9892 only defines one Traffic Classification >>> Data Item. Please note that it also defines two Sub-Data Items. >>> >>> Should "Traffic Classification Data Items provided by the modem are" be >>> "The Traffic Classification Data Item provided by the modem is" or possibly >>> "Traffic Classification Sub-Data Items provided by the modem are"? Or does >>> the text refer to multiple instances of the Traffic Classification Data >>> Item defined in RFC 9892 (in which case perhaps this should be clarified)? >>> >>> Thank you. >>> >>> Lynne Bartholomew >>> RFC Production Center >>> >>> >>>> On Dec 22, 2025, at 8:53 AM, Lynne Bartholomew >>>> <[email protected]> wrote: >>>> >>>> Hi, Eric and Bow-Nan. >>>> >>>> We have noted your approvals on the AUTH48 status page: >>>> >>>> https://www.rfc-editor.org/auth48/rfc9893 >>>> >>>> As this document normatively depends on RFC-to-be 9892, it will be >>>> published when RFC-to-be 9892 is published. >>>> >>>> Thank you! >>>> >>>> Lynne Bartholomew >>>> RFC Production Center >>>> >>>>> From: "Cheng, Bow-Nan - 0662 - MITLL" <[email protected]> >>>>> Subject: Re: [EXT] Re: AUTH48: RFC-to-be 9893 >>>>> <draft-ietf-manet-dlep-credit-flow-control-19> for your review >>>>> Date: December 18, 2025 at 6:13:07 PM PST >>>>> To: Lynne Bartholomew <[email protected]>, Eric Kinzie >>>>> <[email protected]> >>>>> Cc: Lou Berger <[email protected]>, "[email protected]" >>>>> <[email protected]>, "[email protected]" <[email protected]>, >>>>> "[email protected]" <[email protected]>, >>>>> "[email protected]" <[email protected]>, >>>>> "[email protected]" <[email protected]>, >>>>> "[email protected]" <[email protected]> >>>>> >>>>> I'm fine with this document moving forward -- thanks >>>> >>>>> On Dec 18, 2025, at 4:15 PM, Eric Kinzie <[email protected]> wrote: >>>>> >>>>> Lynne, >>>>> >>>>> I approve this document in its current form. No further updates needed >>>>> for me. >>>>> >>>>> Thanks, >>>>> Eric >>>>> >>>>> On Mon Dec 15 10:42:42 -0800 2025, Lynne Bartholomew wrote: >>>>>> Dear Bow-Nan and Eric, >>>>>> >>>>>> A reminder that we do not believe that we have heard from 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 9, 2025, at 4:13 PM, Lynne Bartholomew >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi, Lou. >>>>>>> >>>>>>> We have noted your approval on the AUTH48 status page: >>>>>>> >>>>>>> https://www.rfc-editor.org/auth48/rfc9893 >>>>>>> >>>>>>> Thanks to you as well! >>>>>>> >>>>>>> Lynne Bartholomew >>>>>>> RFC Production Center >>>>>>> >>>>>>>> On Dec 8, 2025, at 3:29 PM, Lou Berger <[email protected]> wrote: >>>>>>>> >>>>>>>> The document looks good to me. >>>>>>>> >>>>>>>> Thank you for all the work! >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> On 12/8/2025 1:25 PM, Lynne Bartholomew wrote: >>>>>>>>> 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]
