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]
