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]
