Lynne, > > Should "Traffic Classification Data Items provided by the modem are" be > > "The Traffic Classification Data Item provided by the modem is" or possibly > > "Traffic Classification Sub-Data Items provided by the modem are"? Or does > > the text refer to multiple instances of the Traffic Classification Data > > Item defined in RFC 9892 (in which case perhaps this should be clarified)?
There can be multiple instances of the Traffic Classification Data Item. Possibly: "The Traffic Classification Data Item provided by the modem is defined in [RFC9892]. In this case, a flow is identified based on information found in a data plane header, and one or more matches are associated with a single flow. As stated in [RFC8982], more than one Data Item MAY be included in a message to provide information on multiple traffic classifiers. Refer to" . . . I think the wording of the second location you pointed out is ok. Thanks, Eric On Mon Jan 05 10:11:22 -0800 2026, Lynne Bartholomew wrote: > Dear authors, > > Happy New Year! > > We could not find a reply to the following questions. Apologies if we missed > it. Please advise. > > Thank you! > > Lynne Bartholomew > RFC Production Center > > > On Dec 23, 2025, at 3:03 PM, Lynne Bartholomew > > <[email protected]> wrote: > > > > Hello again. Forgot to mention that we also see the following text > > elsewhere in this document: > > > > based on the Traffic Classification Data Item defined in > > [RFC9892] > > ... > > flow > > identification information provided by modems in the Traffic > > Classification Data Item defined in [RFC9892] > > ... > > flow identifier as defined by the Traffic Classification > > Data Item [RFC9892] > > > > Thank you. > > > > Lynne Bartholomew > > RFC Production Center > > > > On Dec 23, 2025, at 2:56 PM, Lynne Bartholomew > > <[email protected]> wrote: > > > > Dear authors, > > > > Apologies for not spotting this earlier: We see the following text in this > > document: > > > > Traffic Classification Data Items provided by the modem are defined in > > [RFC9892]. > > > > However, it appears that RFC 9892 only defines one Traffic Classification > > Data Item. Please note that it also defines two Sub-Data Items. > > > > Should "Traffic Classification Data Items provided by the modem are" be > > "The Traffic Classification Data Item provided by the modem is" or possibly > > "Traffic Classification Sub-Data Items provided by the modem are"? Or does > > the text refer to multiple instances of the Traffic Classification Data > > Item defined in RFC 9892 (in which case perhaps this should be clarified)? > > > > Thank you. > > > > Lynne Bartholomew > > RFC Production Center > > > > > >> On Dec 22, 2025, at 8:53 AM, Lynne Bartholomew > >> <[email protected]> wrote: > >> > >> Hi, Eric and Bow-Nan. > >> > >> We have noted your approvals on the AUTH48 status page: > >> > >> https://www.rfc-editor.org/auth48/rfc9893 > >> > >> As this document normatively depends on RFC-to-be 9892, it will be > >> published when RFC-to-be 9892 is published. > >> > >> Thank you! > >> > >> Lynne Bartholomew > >> RFC Production Center > >> > >>> From: "Cheng, Bow-Nan - 0662 - MITLL" <[email protected]> > >>> Subject: Re: [EXT] Re: AUTH48: RFC-to-be 9893 > >>> <draft-ietf-manet-dlep-credit-flow-control-19> for your review > >>> Date: December 18, 2025 at 6:13:07 PM PST > >>> To: Lynne Bartholomew <[email protected]>, Eric Kinzie > >>> <[email protected]> > >>> Cc: Lou Berger <[email protected]>, "[email protected]" > >>> <[email protected]>, "[email protected]" <[email protected]>, > >>> "[email protected]" <[email protected]>, > >>> "[email protected]" <[email protected]>, > >>> "[email protected]" <[email protected]>, > >>> "[email protected]" <[email protected]> > >>> > >>> I'm fine with this document moving forward -- thanks > >> > >>> On Dec 18, 2025, at 4:15 PM, Eric Kinzie <[email protected]> wrote: > >>> > >>> Lynne, > >>> > >>> I approve this document in its current form. No further updates needed > >>> for me. > >>> > >>> Thanks, > >>> Eric > >>> > >>> On Mon Dec 15 10:42:42 -0800 2025, Lynne Bartholomew wrote: > >>>> Dear Bow-Nan and Eric, > >>>> > >>>> A reminder that we do not believe that we have heard from you regarding > >>>> the status of this document. Please let us know whether further updates > >>>> are needed or you approve this document for publication in its current > >>>> form. > >>>> > >>>> The latest files are posted here. Please refresh your browser: > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9893.txt > >>>> https://www.rfc-editor.org/authors/rfc9893.pdf > >>>> https://www.rfc-editor.org/authors/rfc9893.html > >>>> https://www.rfc-editor.org/authors/rfc9893.xml > >>>> https://www.rfc-editor.org/authors/rfc9893-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by side) > >>>> https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > >>>> https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html (side by > >>>> side) > >>>> https://www.rfc-editor.org/authors/rfc9893-lastdiff.html > >>>> https://www.rfc-editor.org/authors/rfc9893-lastrfcdiff.html (side by > >>>> side) > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > >>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > >>>> https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > >>>> > >>>> The AUTH48 status page is here: > >>>> > >>>> https://www.rfc-editor.org/auth48/rfc9893 > >>>> > >>>> Thank you! > >>>> > >>>> Lynne Bartholomew > >>>> RFC Production Center > >>>> > >>>>> On Dec 9, 2025, at 4:13 PM, Lynne Bartholomew > >>>>> <[email protected]> wrote: > >>>>> > >>>>> Hi, Lou. > >>>>> > >>>>> We have noted your approval on the AUTH48 status page: > >>>>> > >>>>> https://www.rfc-editor.org/auth48/rfc9893 > >>>>> > >>>>> Thanks to you as well! > >>>>> > >>>>> Lynne Bartholomew > >>>>> RFC Production Center > >>>>> > >>>>>> On Dec 8, 2025, at 3:29 PM, Lou Berger <[email protected]> wrote: > >>>>>> > >>>>>> The document looks good to me. > >>>>>> > >>>>>> Thank you for all the work! > >>>>>> > >>>>>> Lou > >>>>>> > >>>>>> On 12/8/2025 1:25 PM, Lynne Bartholomew wrote: > >>>>>>> Dear Bow-Nan, Lou, and Eric, > >>>>>>> > >>>>>>> Checking in with you regarding the status of this document. Please > >>>>>>> let us know whether further updates are needed or you approve this > >>>>>>> document for publication in its current form. > >>>>>>> > >>>>>>> The latest files are posted here. Please refresh your browser: > >>>>>>> > >>>>>>> https://www.rfc-editor.org/authors/rfc9893.txt > >>>>>>> https://www.rfc-editor.org/authors/rfc9893.pdf > >>>>>>> https://www.rfc-editor.org/authors/rfc9893.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893.xml > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-diff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by side) > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html (side > >>>>>>> by side) > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastdiff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastrfcdiff.html (side by > >>>>>>> side) > >>>>>>> > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > >>>>>>> > >>>>>>> The AUTH48 status page is here: > >>>>>>> > >>>>>>> https://www.rfc-editor.org/auth48/rfc9893 > >>>>>>> > >>>>>>> Thank you! > >>>>>>> > >>>>>>> Lynne Bartholomew > >>>>>>> RFC Production Center > >>>>>>> > >>>>>>>> On Dec 3, 2025, at 9:03 AM, Lynne Bartholomew > >>>>>>>> <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Hi, Eric. Thanks for your prompt reply to our follow-up items! We > >>>>>>>> have changed '"Credit Window Initialization"' to "credit window > >>>>>>>> initialization" (quotation marks removed; they're here only to show > >>>>>>>> what was updated). > >>>>>>>> > >>>>>>>> This update is reflected in the latest files, which are posted here. > >>>>>>>> Please refresh your browser: > >>>>>>>> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893.txt > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html (side > >>>>>>>> by side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastdiff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastrfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > >>>>>>>> > >>>>>>>> Thanks again! > >>>>>>>> > >>>>>>>> Lynne Bartholomew > >>>>>>>> RFC Production Center > >>>>>>>> > >>>>>>>>> On Dec 2, 2025, at 3:58 PM, Eric Kinzie <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>> On Tue Dec 02 13:21:58 -0800 2025, Lynne Bartholomew wrote: > >>>>>>>>>> Hi, Eric. Thank you for the email. > >>>>>>>>>> > >>>>>>>>>> We have updated this document per your notes below. > >>>>>>>>>> > >>>>>>>>>> A couple follow-up items for you: > >>>>>>>>>> > >>>>>>>>>> * Please review our update regarding our question 8); it appears > >>>>>>>>>> that you approved our "Perhaps" text. We kept both citations for > >>>>>>>>>> RFC 8175 to avoid possible confusion between "Status Data Item" > >>>>>>>>>> and "Credit Window Status Data Item". Please let us know whether > >>>>>>>>>> or not our update is correct here (and if you object to the second > >>>>>>>>>> citation for RFC 8175). > >>>>>>>>> I approved the "Perhaps" text. Your update is correct. > >>>>>>>>> > >>>>>>>>>> * May we change '"Credit Window Initialization"' to '"credit > >>>>>>>>>> window initialization"' in this sentence (appears to be used > >>>>>>>>>> generally and applies to this document only)? > >>>>>>>>>> > >>>>>>>>>> Modems provide an initial credit window size at the time of "Credit > >>>>>>>>>> Window Initialization". > >>>>>>>>> Yes, changing that to lowercase letters makes sense. I also think > >>>>>>>>> the > >>>>>>>>> quotation marks can be removed, but I'll leave that to your > >>>>>>>>> judgement. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Eric > >>>>>>>>> > >>>>>>>>>> = = = = = > >>>>>>>>>> > >>>>>>>>>> The latest files are posted here. Please refresh your browser: > >>>>>>>>>> > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893.txt > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893.pdf > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893.xml > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-diff.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by > >>>>>>>>>> side) > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html > >>>>>>>>>> (side by side) > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastdiff.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-lastrfcdiff.html (side > >>>>>>>>>> by side) > >>>>>>>>>> > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > >>>>>>>>>> > >>>>>>>>>> Thanks again! > >>>>>>>>>> > >>>>>>>>>> Lynne Bartholomew > >>>>>>>>>> RFC Production Center > >>>>>>>>>> > >>>>>>>>>>> On Dec 2, 2025, at 8:38 AM, Eric Kinzie <[email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Lynne, please see my responses below. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Eric > >>>>>>>>>>> > >>>>>>>>>>> On Mon Dec 01 08:33:00 -0800 2025, Lynne Bartholomew wrote: > >>>>>>>>>>>>> Authors, > >>>>>>>>>>>>> > >>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>>>>>>>> necessar= > >>>>>>>>>>>>> y) the following questions, which are also in the source file. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > >>>>>>>>>>>>> appear in = > >>>>>>>>>>>>> the > >>>>>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>. --> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2) <!-- [rfced] Abstract: As it appears that the two new > >>>>>>>>>>>>> message types > >>>>>>>>>>>>> (Credit Control and Credit Control Response) also figure > >>>>>>>>>>>>> prominently > >>>>>>>>>>>>> in this document (and appear to be mentioned in the document > >>>>>>>>>>>>> title), > >>>>>>>>>>>>> would you like to also mention them in the Abstract? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> This document defines new Dynamic Link Exchange Protocol (DLEP) > >>>>>>>>>>>>> Data > >>>>>>>>>>>>> Items that are used to support credit-based flow control. > >>>>>>>>>>>>> Credit > >>>>>>>>>>>>> window control is used to regulate when data may be sent to an > >>>>>>>>>>>>> associated virtual or physical queue. The Data Items are > >>>>>>>>>>>>> extensible > >>>>>>>>>>>>> and reusable. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Possibly: > >>>>>>>>>>>>> This document defines new Dynamic Link Exchange Protocol (DLEP) > >>>>>>>>>>>>> Data > >>>>>>>>>>>>> Items that are used to support credit-based flow control. > >>>>>>>>>>>>> Credit > >>>>>>>>>>>>> window control is used to regulate when data may be sent to an > >>>>>>>>>>>>> associated virtual or physical queue. These Data Items are > >>>>>>>>>>>>> extensible and reusable. > >>>>>>>>>>>>> > >>>>>>>>>>>>> This document also defines new messages that support credit > >>>>>>>>>>>>> window > >>>>>>>>>>>>> control. --> > >>>>>>>>>>> That change is fine. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 3) <!-- [rfced] FYI: We have added expansions for > >>>>>>>>>>>>> abbreviations where > >>>>>>>>>>>>> they are first used, per Section 3.6 of RFC 7322 ("RFC Style > >>>>>>>>>>>>> Guide") > >>>>>>>>>>>>> (https://www.rfc-editor.org/info/rfc7322). Please review the > >>>>>>>>>>>>> following expansions to ensure correctness. > >>>>>>>>>>>>> > >>>>>>>>>>>>> DSCP: Differentiated Services Code Point (Figure 1) > >>>>>>>>>>>>> MAC: Media Access Control (Section 2) > >>>>>>>>>>>>> PCP: Priority Code Point (Figure 1) --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 4) <!-- [rfced] Section 1: We updated "control plane pause > >>>>>>>>>>>>> based > >>>>>>>>>>>>> mechanism" per RFC 8651. Please let us know any objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> For example, a credit-window > >>>>>>>>>>>>> scheme for destination-specific flow control which provides > >>>>>>>>>>>>> aggregate > >>>>>>>>>>>>> flow control for both modem and routers has been proposed in > >>>>>>>>>>>>> [I-D.ietf-manet-credit-window], and a control plane pause based > >>>>>>>>>>>>> mechanism is defined in [RFC8651]. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> For example, a credit-window > >>>>>>>>>>>>> scheme for destination-specific flow control that provides > >>>>>>>>>>>>> aggregate > >>>>>>>>>>>>> flow control for both modems and routers has been proposed in > >>>>>>>>>>>>> [Credit-Window-Extension], and a mechanism referred to as the > >>>>>>>>>>>>> Control-Plane-Based Pause Extension is defined in [RFC8651]. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 5) <!-- [rfced] Section 2: We had trouble determining what is > >>>>>>>>>>>>> listed in > >>>>>>>>>>>>> this sentence. We updated as follows. If this is incorrect, > >>>>>>>>>>>>> please > >>>>>>>>>>>>> clarify the text. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> This means that the use of FIDs, TIDs and the > >>>>>>>>>>>>> association of a TID to a DLEP destination enables a modem to > >>>>>>>>>>>>> share > >>>>>>>>>>>>> or dedicate resources as needed to match the specifics of its > >>>>>>>>>>>>> implementation and its attached transmission technology. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> This means that the use > >>>>>>>>>>>>> of FIDs and TIDs, and the association of a TID to a DLEP > >>>>>>>>>>>>> destination, > >>>>>>>>>>>>> enable a modem to share or dedicate resources as needed to > >>>>>>>>>>>>> match the > >>>>>>>>>>>>> specifics of its implementation and its attached transmission > >>>>>>>>>>>>> technology. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 6) <!-- [rfced] Section 2.1: We had trouble following this > >>>>>>>>>>>>> sentence. > >>>>>>>>>>>>> Does "framing" mean "frame size" or something else? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> In the example of Ethernet, framing, > >>>>>>>>>>>>> header and trailer are all included in this count. --> > >>>>>>>>>>> "framing" is used here as it is used in the Ethernet standard. I > >>>>>>>>>>> would > >>>>>>>>>>> prefer to leave this unchanged. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 7) <!-- [rfced] Section 2.2.1: We had trouble parsing these > >>>>>>>>>>>>> sentences. > >>>>>>>>>>>>> If the suggested text is not correct, please clarify "having > >>>>>>>>>>>>> data > >>>>>>>>>>>>> traffic available to send, but no credits available". > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> Modems will need to balance the > >>>>>>>>>>>>> load generated by sending and processing credit window increases > >>>>>>>>>>>>> against a router having data traffic available to send, but no > >>>>>>>>>>>>> credits available. > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> Routers will need to balance the load > >>>>>>>>>>>>> generated by sending and processing credit window requests > >>>>>>>>>>>>> against > >>>>>>>>>>>>> having data traffic available to send, but no credits available. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Suggested: > >>>>>>>>>>>>> Modems will need to balance the > >>>>>>>>>>>>> load generated by sending and processing credit window increases > >>>>>>>>>>>>> against a router that has data traffic available to send but no > >>>>>>>>>>>>> available credits. > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> Routers will need to balance the load > >>>>>>>>>>>>> generated by sending and processing credit window requests > >>>>>>>>>>>>> against > >>>>>>>>>>>>> having data traffic available to send but no available credits. > >>>>>>>>>>>>> --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 8) <!-- [rfced] Section 2.3: Does "a Status Data Item" refer > >>>>>>>>>>>>> specifically to the Status Data Item defined in RFC 8175 - in > >>>>>>>>>>>>> which > >>>>>>>>>>>>> case RFC 8175 should be cited here - or does it refer to the > >>>>>>>>>>>>> Credit > >>>>>>>>>>>>> Window Status Data Item as defined in this document? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> In particular, the node parsing > >>>>>>>>>>>>> the Data Item MUST terminate the session with a Status Data Item > >>>>>>>>>>>>> indicating Invalid Data. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Perhaps: > >>>>>>>>>>>>> In particular, the node parsing > >>>>>>>>>>>>> the Data Item MUST terminate the session with a Status Data Item > >>>>>>>>>>>>> [RFC8175] indicating "Invalid Data". > >>>>>>>>>>> It refers to the Status Data Item defined in RFC 8175. This > >>>>>>>>>>> wording > >>>>>>>>>>> is fine. I think it is also ok to remove "; see [RFC8175]" from > >>>>>>>>>>> the > >>>>>>>>>>> previous sentence if this seems repetitive. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Or possibly: > >>>>>>>>>>>>> In particular, the node parsing > >>>>>>>>>>>>> the Data Item MUST terminate the session with a Credit Window > >>>>>>>>>>>>> Status > >>>>>>>>>>>>> Data Item indicating "Invalid Data" as defined in [RFC8175]. --> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 9) <!-- [rfced] Section 2.3.1: As the dashes initially > >>>>>>>>>>>>> appeared to be > >>>>>>>>>>>>> minus signs, we changed them to colons. If this is incorrect, > >>>>>>>>>>>>> please > >>>>>>>>>>>>> consider whether these entries could be written in some other > >>>>>>>>>>>>> way. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We also gave the table a title. Please let us know any > >>>>>>>>>>>>> objections. > >>>>>>>>>>>>> If you prefer a different title, please specify. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original (dashes are broken in order to avoid xml2rfc's "Double > >>>>>>>>>>>>> hyphen within comment" error): > >>>>>>>>>>>>> Value Scale > >>>>>>>>>>>>> - - - - - > >>>>>>>>>>>>> 0 B - Bytes (Octets) > >>>>>>>>>>>>> 1 KB - Kilobytes (B/1024) > >>>>>>>>>>>>> 2 MB - Megabytes (KB/1024) > >>>>>>>>>>>>> 3 GB - Gigabytes (MB/1024) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>>>>>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D+ > >>>>>>>>>>>>> | Value | Scale | > >>>>>>>>>>>>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>>>>>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D+ > >>>>>>>>>>>>> | 0 | B: Bytes (Octets) | > >>>>>>>>>>>>> +- - - -+- - - - - - - - - - - - -+ > >>>>>>>>>>>>> | 1 | KB: Kilobytes (B/1024) | > >>>>>>>>>>>>> +- - - -+- - - - - - - - - - - - -+ > >>>>>>>>>>>>> | 2 | MB: Megabytes (KB/1024) | > >>>>>>>>>>>>> +- - - -+- - - - - - - - - - - - -+ > >>>>>>>>>>>>> | 3 | GB: Gigabytes (MB/1024) | > >>>>>>>>>>>>> +- - - -+- - - - - - - - - - - - -+ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Table 1: Valid Scale Field Values --> > >>>>>>>>>>> That table looks good. No objection. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 10) <!-- [rfced] Section 2.3.1: Does "Credit Value" > >>>>>>>>>>>>> specifically refer > >>>>>>>>>>>>> to the Credit Value field, or does it mean "credit value" as > >>>>>>>>>>>>> used > >>>>>>>>>>>>> generally elsewhere in this document (e.g., "appropriate credit > >>>>>>>>>>>>> values" as written in Section 2)? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> If the resulting > >>>>>>>>>>>>> Credit Value results in the credit window exceeding the > >>>>>>>>>>>>> represented > >>>>>>>>>>>>> Credit Window Max Size, the Credit Window Max Size field value > >>>>>>>>>>>>> is > >>>>>>>>>>>>> used as the new credit window size. --> > >>>>>>>>>>> It means "credit value" as used generally elsewhere and should > >>>>>>>>>>> not be > >>>>>>>>>>> capitalized. > >>>>>>>>>>> > >>>>>>>>>>> New: > >>>>>>>>>>> If the resulting > >>>>>>>>>>> credit value results in the credit window exceeding the > >>>>>>>>>>> represented > >>>>>>>>>>> Credit Window Max Size, the Credit Window Max Size field value is > >>>>>>>>>>> used as the new credit window size. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 11) <!-- [rfced] Section 2.3.2: Because this sentence as > >>>>>>>>>>>>> written > >>>>>>>>>>>>> indicated that the data plane state is updated as needed, we > >>>>>>>>>>>>> changed > >>>>>>>>>>>>> "are" to "is" accordingly (also per "In both cases, a router > >>>>>>>>>>>>> MUST > >>>>>>>>>>>>> also ensure that any data plane state, e.g., > >>>>>>>>>>>>> [I-D.ietf-manet-dlep-credit-flow-control], that is associated > >>>>>>>>>>>>> with > >>>>>>>>>>>>> the TID is updated as needed." in > >>>>>>>>>>>>> draft-ietf-manet-dlep-traffic-classification, where it cites > >>>>>>>>>>>>> this > >>>>>>>>>>>>> document). If this is incorrect, please clarify what is being > >>>>>>>>>>>>> updated as needed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> If the traffic classification information is located, the > >>>>>>>>>>>>> router MUST ensure that any data plane state that is associated > >>>>>>>>>>>>> with > >>>>>>>>>>>>> the TID and its corresponding FIDs are updated as needed (per > >>>>>>>>>>>>> Section 2.1). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> If the traffic classification information is located, the > >>>>>>>>>>>>> router MUST ensure that any data plane state that is associated > >>>>>>>>>>>>> with > >>>>>>>>>>>>> the TID and its corresponding FIDs is updated as needed (per > >>>>>>>>>>>>> Section 2.1). --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 12) <!-- [rfced] Section 2.3.3: Does "a Credit Window Status > >>>>>>>>>>>>> Data Item > >>>>>>>>>>>>> or items" mean "one or more Credit Window Status Data Items" > >>>>>>>>>>>>> here, or > >>>>>>>>>>>>> does "or items" refer to some other types of items other than > >>>>>>>>>>>>> Data > >>>>>>>>>>>>> Items? We ask because we see "Credit Window Status Data > >>>>>>>>>>>>> Item(s)" in > >>>>>>>>>>>>> the next sentence. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original (the next sentence is included for context): > >>>>>>>>>>>>> When a Credit Window Grant Data Item is received in other > >>>>>>>>>>>>> message types, the receiving router MUST send a Credit Window > >>>>>>>>>>>>> Status > >>>>>>>>>>>>> Data Item or items reflecting the resulting Credit Window value > >>>>>>>>>>>>> of > >>>>>>>>>>>>> the updated credit window. When the Credit Grant Data Item is > >>>>>>>>>>>>> received in a Destination Up Message, the Credit Window Status > >>>>>>>>>>>>> Data > >>>>>>>>>>>>> Item(s) MUST be sent in the corresponding Destination Up > >>>>>>>>>>>>> Response > >>>>>>>>>>>>> Message. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Perhaps: > >>>>>>>>>>>>> When a Credit Window Grant Data Item is received in other > >>>>>>>>>>>>> message types, the receiving router MUST send one or more Credit > >>>>>>>>>>>>> Window Status Data Items reflecting the resultant Credit Window > >>>>>>>>>>>>> value of the updated credit window. --> > >>>>>>>>>>> This means "one or more Credit Window Status Data Items". > >>>>>>>>>>> > >>>>>>>>>>> New: > >>>>>>>>>>> For each Credit Window Grant Data Item received in other > >>>>>>>>>>> message types, the receiving router MUST send a Credit Window > >>>>>>>>>>> Status > >>>>>>>>>>> Data Item reflecting the resulting Credit Window value of > >>>>>>>>>>> the updated credit windows. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 13) <!-- [rfced] Section 2.3.5: Should "credit request" be > >>>>>>>>>>>>> "credit > >>>>>>>>>>>>> window request" as used generally elsewhere in the text? We > >>>>>>>>>>>>> don't > >>>>>>>>>>>>> see "credit request" used anywhere else in this document or > >>>>>>>>>>>>> group of > >>>>>>>>>>>>> documents (Cluster 541 / > >>>>>>>>>>>>> https://www.rfc-editor.org/cluster_info.php?cid=3DC541). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> A special FID value, as defined below, is used to > >>>>>>>>>>>>> indicate that a credit request is being made across all queues. > >>>>>>>>>>>>> --> > >>>>>>>>>>> Yes, it should be "credit window request". > >>>>>>>>>>> New: > >>>>>>>>>>> A special FID value, as defined below, is used to > >>>>>>>>>>> indicate that a credit window request is being made across all > >>>>>>>>>>> queues. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 14) <!-- [rfced] Section 2.3.5: We do not see a Type field in > >>>>>>>>>>>>> RFC 8175, > >>>>>>>>>>>>> but we see a "Data Item Type" field. May we update as suggested > >>>>>>>>>>>>> (per Section 11.3 ("DLEP Generic Data Item") of RFC 8175), to > >>>>>>>>>>>>> distinguish this definition from the definitions of Length in > >>>>>>>>>>>>> Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message > >>>>>>>>>>>>> Header") > >>>>>>>>>>>>> of RFC 8175, which do not mention excluding a "Type" field? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> As specified in [RFC8175], Length is the number of octets in the > >>>>>>>>>>>>> Data Item, excluding the Type and Length fields. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Suggested: > >>>>>>>>>>>>> As specified in [RFC8175], Length is the number of octets in the > >>>>>>>>>>>>> Data Item, excluding the Data Item Type and Length fields. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 15) <!-- [rfced] Section 2.3.5: We changed "Credit Increment" > >>>>>>>>>>>>> to "credi= > >>>>>>>>>>>>> t > >>>>>>>>>>>>> window increment" here, as we could not find the > >>>>>>>>>>>>> initial-capitalized > >>>>>>>>>>>>> form elsewhere in this document, in the group (cluster) of > >>>>>>>>>>>>> related > >>>>>>>>>>>>> documents, or in any published RFC to date. This update is > >>>>>>>>>>>>> also in > >>>>>>>>>>>>> line with this sentence from Section 2.2.1: > >>>>>>>>>>>>> > >>>>>>>>>>>>> A modem receiving this > >>>>>>>>>>>>> message MUST respond with a Credit Control Response Message > >>>>>>>>>>>>> based on > >>>>>>>>>>>>> the received message and Data Item and the processing defined in > >>>>>>>>>>>>> Section 2.2.2, which will typically result in credit window > >>>>>>>>>>>>> increments being provided. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please let us know any objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> A modem receiving this Data Item MUST provide a Credit > >>>>>>>>>>>>> Increment for > >>>>>>>>>>>>> the indicated credit windows via Credit Window Grant Data Items > >>>>>>>>>>>>> carried in a new Credit Control Message. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> A modem receiving this Data Item MUST provide a credit window > >>>>>>>>>>>>> increment for the indicated credit windows via Credit Window > >>>>>>>>>>>>> Grant > >>>>>>>>>>>>> Data Items carried in a new Credit Control Message. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 16) <!-- [rfced] Section 2.4: We changed "the mismatch of > >>>>>>>>>>>>> capabilities" > >>>>>>>>>>>>> to "any mismatch in capabilities" per > >>>>>>>>>>>>> draft-ietf-manet-dlep-ether-credit-extension. Please let us > >>>>>>>>>>>>> know any > >>>>>>>>>>>>> objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> In > >>>>>>>>>>>>> either case, the mismatch of capabilities SHOULD be reported to > >>>>>>>>>>>>> the > >>>>>>>>>>>>> user via normal network management mechanisms, such as the user > >>>>>>>>>>>>> interface or error logging. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> In > >>>>>>>>>>>>> either case, any mismatch in capabilities SHOULD be reported to > >>>>>>>>>>>>> the > >>>>>>>>>>>>> user via normal network management mechanisms, such as the user > >>>>>>>>>>>>> interface or error logging. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 17) <!-- [rfced] Section 4: We had trouble following "some > >>>>>>>>>>>>> updated > >>>>>>>>>>>>> references to external documents listed below" in this > >>>>>>>>>>>>> paragraph. > >>>>>>>>>>>>> It appears that "external documents" is intended to refer to > >>>>>>>>>>>>> [BCP195], [IEEE-802.1AE], and [IEEE-8802-1X]. > >>>>>>>>>>>>> > >>>>>>>>>>>>> However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE > >>>>>>>>>>>>> Standards > >>>>>>>>>>>>> for Local and metropolitan area networks-Port-Based Network > >>>>>>>>>>>>> Access > >>>>>>>>>>>>> Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC > >>>>>>>>>>>>> International Standard-Telecommunications and exchange between > >>>>>>>>>>>>> information technology systems-Requirements for local and > >>>>>>>>>>>>> metropolitan area networks-Part 1X:Port-based network access > >>>>>>>>>>>>> control"). > >>>>>>>>>>>>> > >>>>>>>>>>>>> May we update as suggested? If not, please clarify the text. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> The transport layer security mechanisms documented in > >>>>>>>>>>>>> [RFC8175], with > >>>>>>>>>>>>> some updated references to external documents listed below, can > >>>>>>>>>>>>> be > >>>>>>>>>>>>> applied to this document. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Suggested: > >>>>>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>>>>> along with the latest versions of [BCP195], [IEEE-802.1AE], and > >>>>>>>>>>>>> [IEEE-8802-1X] at the time of this writing, can be applied to > >>>>>>>>>>>>> this > >>>>>>>>>>>>> document. --> > >>>>>>>>>>> The IEEE documents should not be referenced in this sentence. > >>>>>>>>>>> > >>>>>>>>>>> New: > >>>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>>> along with the latest version of [BCP195] at the time of this > >>>>>>>>>>> writing, > >>>>>>>>>>> can be applied to this document. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 18) <!-- [rfced] [IEEE-802.1AE]: The title listed here does > >>>>>>>>>>>>> not match > >>>>>>>>>>>>> the title found at the provided URL. Is the intent here to > >>>>>>>>>>>>> specifically point to Amendment 4 (in which case the citation > >>>>>>>>>>>>> string > >>>>>>>>>>>>> should be changed to [IEEE-802.1AEdk-2023] and the URL should be > >>>>>>>>>>>>> changed to <https://ieeexplore.ieee.org/document/10225636>), or > >>>>>>>>>>>>> would > >>>>>>>>>>>>> you prefer to list [IEEE-802.1AE] per > >>>>>>>>>>>>> draft-ietf-manet-dlep-traffic-classification-17? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> [IEEE-802.1AE] > >>>>>>>>>>>>> "IEEE Standard for Local and metropolitan area networks- > >>>>>>>>>>>>> Media Access Control (MAC) Security Amendment 4: MAC > >>>>>>>>>>>>> Privacy protection", > >>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/8585421>. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As listed in the edited copy of > >>>>>>>>>>>>> draft-ietf-manet-dlep-traffic-classification-17: > >>>>>>>>>>>>> [IEEE-802.1AE] > >>>>>>>>>>>>> IEEE, "IEEE Standard for Local and metropolitan area > >>>>>>>>>>>>> networks-Media Access Control (MAC) Security", > >>>>>>>>>>>>> DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018, > >>>>>>>>>>>>> December 2018, > >>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/8585421>. --> > >>>>>>>>>>> I don't think it's necessary to specify amendment 4. > >>>>>>>>>>> > >>>>>>>>>>> New: > >>>>>>>>>>> [IEEE-802.1AE] > >>>>>>>>>>> IEEE, "IEEE Standard for Local and metropolitan area > >>>>>>>>>>> networks-Media Access Control (MAC) Security", > >>>>>>>>>>> DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018, > >>>>>>>>>>> December 2018, > >>>>>>>>>>> <https://ieeexplore.ieee.org/document/8585421>. --> > >>>>>>>>>>> > >>>>>>>>>>>>> 19) <!-- [rfced] Appendix B: We changed "traffic > >>>>>>>>>>>>> classification data sub > >>>>>>>>>>>>> items" to "Traffic Classification Sub-Data Items" per > >>>>>>>>>>>>> draft-ietf-manet-dlep-traffic-classification and the rest of > >>>>>>>>>>>>> this > >>>>>>>>>>>>> group (Cluster 541 / > >>>>>>>>>>>>> https://www.rfc-editor.org/cluster_info.php?cid=3DC541) of > >>>>>>>>>>>>> documents. > >>>>>>>>>>>>> Please let us know any objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Original: > >>>>>>>>>>>>> [I-D.ietf-manet-dlep-traffic-classification] defines the traffic > >>>>>>>>>>>>> classification data sub items such as DiffServ code points that > >>>>>>>>>>>>> map > >>>>>>>>>>>>> to the FIDs. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently: > >>>>>>>>>>>>> [RFC9892] defines the Traffic > >>>>>>>>>>>>> Classification Sub-Data Items, such as DSCPs, that map to the > >>>>>>>>>>>>> FIDs. --> > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion > >>>>>>>>>>>>> of the > >>>>>>>>>>>>> online Style Guide at > >>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, > >>>>>>>>>>>>> and let us know if any changes are needed. Updates of this > >>>>>>>>>>>>> nature > >>>>>>>>>>>>> typically result in more precise language, which is helpful for > >>>>>>>>>>>>> readers. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Note that our script did not flag any words in particular, but > >>>>>>>>>>>>> this > >>>>>>>>>>>>> should still be reviewed as a best practice. --> > >>>>>>>>>>> Reviewed. I haven't found anything that does not comply with the > >>>>>>>>>>> NIST > >>>>>>>>>>> guidance. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 21) <!-- [rfced] Please let us know if any changes are needed > >>>>>>>>>>>>> for the > >>>>>>>>>>>>> following: > >>>>>>>>>>>>> > >>>>>>>>>>>>> a) The following terms were used inconsistently in this > >>>>>>>>>>>>> document. > >>>>>>>>>>>>> We chose to use the latter forms. Please let us know any > >>>>>>>>>>>>> objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Additional Credit (field name, i.e., "Additional Credit:") / > >>>>>>>>>>>>> Additional Credits ("Additional Credits field") > >>>>>>>>>>>>> > >>>>>>>>>>>>> credit based flow control / credit-based flow control (added > >>>>>>>>>>>>> hyphen) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit-Based Flow Control (in text) / credit-based flow control > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit Control message (2 instances) / Credit Control Message > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit Control Response message (1 instance) / > >>>>>>>>>>>>> Credit Control Response Message > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit Window size (1 instance, i.e., "a Credit Window size") / > >>>>>>>>>>>>> credit window size (7 instances, e.g., "an initial credit window > >>>>>>>>>>>>> size") (used generally throughout Section 2) > >>>>>>>>>>>>> > >>>>>>>>>>>>> data item / Data Item (per the rest of this document and per > >>>>>>>>>>>>> this > >>>>>>>>>>>>> group (cluster) of documents) > >>>>>>>>>>>>> > >>>>>>>>>>>>> different Credit windows / different credit windows > >>>>>>>>>>>>> > >>>>>>>>>>>>> Messages / messages ("common Messages", "No messages") > >>>>>>>>>>>>> (We changed "common Messages" to "common messages".) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Window Association Data Item (2 instances in Appendix B) / > >>>>>>>>>>>>> Credit Window Association Data Item (10 instances in text, > >>>>>>>>>>>>> the table entry in the IANA Considerations section, and > >>>>>>>>>>>>> <https://www.iana.org/assignments/dlep-parameters/>) > >>>>>>>>>>> OK. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> b) The following term appears to be used inconsistently in this > >>>>>>>>>>>>> document. Please let us know which form is preferred. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit Window / credit window (used generally, e.g., "associated > >>>>>>>>>>>>> Credit Window", "associated credit window", > >>>>>>>>>>>>> 'logical "Credit Window(s)s"') > >>>>>>>>>>>>> (Note: We also see 'logical "Credit Windows"' in > >>>>>>>>>>>>> draft-ietf-manet-dlep-da-credit-extension. Otherwise, all of > >>>>>>>>>>>>> the > >>>>>>>>>>>>> documents in this group of documents use the lowercase form > >>>>>>>>>>>>> "credit window" when used generally.) > >>>>>>>>>>> Let's use lowercase "credit window" when used generally. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> c) Please let us know how/if the following should be made > >>>>>>>>>>>>> consistent: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Credit Grant Data Item (3 instances in text) / > >>>>>>>>>>>>> Credit Window Grant Data Item (~13 instances in text) / > >>>>>>>>>>>>> Grant Data Item (2 instances in text) ("each Grant Data Item", > >>>>>>>>>>>>> "or Grant Data Item") > >>>>>>>>>>>>> Suggested, assuming that these different forms all refer to the > >>>>>>>>>>>>> same type of Data Item: Credit Window Grant Data Item, per > >>>>>>>>>>>>> <https://www.iana.org/assignments/dlep-parameters/>. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alternatively, please let us know if the IANA entry needs to > >>>>>>>>>>>>> be changed (e.g., from "Credit Window Grant" to "Credit Grant" > >>>>>>>>>>>>> or simply "Grant", noting that any such change would not match > >>>>>>>>>>>>> the format of the other entries on the page.) --> > >>>>>>>>>>> These can all be changed to "Credit Window Grant Data Item". > >>>>> > >>>> > >> > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
