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]
