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]
