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]
