Hi, On Wed, Dec 3, 2025 at 11:51 AM Lynne Bartholomew <[email protected]> wrote: > > Dear Lou and Donald, > > As we just requested for RFC-to-be 9894 -- > > The authors of companion document RFC-to-be 9893 have changed 'logical > "Credit Window(s)"' to 'logical "credit window(s)"', because they went with > lowercase "credit window(s)" where this term is used generally. > > For consistency within this group of DLEP documents, may we change 'logical > "Credit Windows"' to 'logical "credit windows"' in this document as well?
I am OK with changing to lowercase. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > Currently: > ... a router to a modem. This mechanism utilizes one or more logical > "Credit Windows", each of which is typically associated with a > > Thank you! > > Lynne Bartholomew > RFC Production Center > > > On Nov 26, 2025, at 12:55 PM, Lynne Bartholomew > > <[email protected]> wrote: > > > > Hi again, Lou. We've noted your approval for this document as well: > > > > https://www.rfc-editor.org/auth48/rfc9895 > > > > Because this document normatively depends on RFCs 9892 and 9893, it will be > > published along with those documents after we have all approvals. > > > > Thanks again! > > > > Lynne Bartholomew > > RFC Production Center > > > >> On Nov 26, 2025, at 9:09 AM, Lou Berger <[email protected]> wrote: > >> > >> Thank you all for the comments/review. I agree that the change 0x0000 > >> isn't really needed or helpful. That said it is the same as a simple 0, so > >> I can live with it being either way. > >> Thanks, > >> Lou > >> ---------- > >> On November 25, 2025 1:32:56 PM Lynne Bartholomew > >> <[email protected]> wrote: > >>> Hi, Donald. > >>> We have noted your approval on the AUTH48 status page: > >>> https://www.rfc-editor.org/auth48/rfc9895 > >>> Thank you very much for your help with this document and RFC-to-be 9894! > >>> Lynne Bartholomew > >>> RFC Production Center > >>>> On Nov 25, 2025, at 9:52 AM, Donald Eastlake <[email protected]> wrote: > >>>> Hi Lynne, > >>>> I have reviewed this rfc-to-be and approve publication. > >>>> Thanks, > >>>> Donald > >>>> =============================== > >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>> 2386 Panoramic Circle, Apopka, FL 32703 USA > >>>> [email protected] > >>>> On Mon, Nov 24, 2025 at 12:06 PM Lynne Bartholomew > >>>> <[email protected]> wrote: > >>>> Hi, Donald. Apologies for the delayed reply. > >>>> We have updated Section 3 per your note below. We'll update RFC-to-be > >>>> 9894 shortly and will ask the authors of RFC-to-be 9892 if they would > >>>> like to update the "VLAN Identifier (VID):" definition per your note. > >>>> The latest files are posted here. Please refresh your browser: > >>>> https://www.rfc-editor.org/authors/rfc9895.txt > >>>> https://www.rfc-editor.org/authors/rfc9895.pdf > >>>> https://www.rfc-editor.org/authors/rfc9895.html > >>>> https://www.rfc-editor.org/authors/rfc9895.xml > >>>> https://www.rfc-editor.org/authors/rfc9895-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9895-rfcdiff.html (side by side) > >>>> https://www.rfc-editor.org/authors/rfc9895-auth48diff.html > >>>> https://www.rfc-editor.org/authors/rfc9895-auth48rfcdiff.html (side by > >>>> side) > >>>> https://www.rfc-editor.org/authors/rfc9895-lastdiff.html > >>>> https://www.rfc-editor.org/authors/rfc9895-lastrfcdiff.html (side by > >>>> side) > >>>> https://www.rfc-editor.org/authors/rfc9895-xmldiff1.html > >>>> https://www.rfc-editor.org/authors/rfc9895-xmldiff2.html > >>>> Thank you! > >>>> Lynne Bartholomew > >>>> RFC Production Center > >>>>> On Nov 17, 2025, at 7:24 PM, Donald Eastlake <[email protected]> wrote: > >>>>> Hi Lynne, > >>>>> See below. > >>>>> On Mon, Nov 17, 2025 at 3:19 PM Lynne Bartholomew > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> Hi again, Donald. Thanks for another quick reply! We have updated > >>>>>> this document as well, per your notes below. > >>>>>> Regarding your second update note from further below: > >>>>>>> Section 3, 3rd paragraph, 2nd sentence, seems a bit incomplete and > >>>>>>> fuzzy. I believe the following is clearer. > >>>>>>> OLD > >>>>>>> VID value zero (0) is used by > >>>>>>> [RFC9892] to indicate that the VID is ignored and any other VID > >>>>>>> value is > >>>>>>> used in traffic classification. > >>>>>>> NEW > >>>>>>> VID value zero (0x0000) is used by > >>>>>>> [RFC9892] to indicate that the VID is ignored and VID 0xFFFF is > >>>>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>>>> used in traffic classification. > >>>>>> > >>>>>> We are having trouble parsing the "NEW" text. Does it mean > >>>>>> VID value zero (0x0000) is used by > >>>>>> [RFC9892] to indicate that (1) the VID is ignored and (2) VID 0xFFFF is > >>>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>>> used in traffic classification. > >>>>>> or > >>>>>> VID value zero (0x0000) is used by > >>>>>> [RFC9892] to indicate that the VID is ignored. VID 0xFFFF is > >>>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>>> used in traffic classification. > >>>>>> ? > >>>>>> Seems like the latter, but please advise. > >>>>> > >>>>> Yes, you are correct. It is the latter. > >>>>>> = = = = = > >>>>>> A couple more follow-up questions: > >>>>>> 1. Should "composed of" be changed to "built on" in RFC-to-be 9894 > >>>>>> as well, as was done per your first note further below for this > >>>>>> document? > >>>>>> From the latest rfc9894.txt: > >>>>>> The extension defined in this document is composed of the mechanisms > >>>>> > >>>>> Yes, I think the change should be made in RFC-to-be 9894 as well. > >>>>>> 2. In companion document RFC-to-be 9892, should we ask the authors > >>>>>> if the "zero (0)" in the following paragraph should be updated to > >>>>>> list the hex value 0x0000, as was done per your second update note > >>>>>> (further below) for this document? We ask because we see two > >>>>>> instances of "The value 0xFFFF is reserved" in RFC-to-be 9892: > >>>>> > >>>>>> > >>>>>> VLAN Identifier (VID): > >>>>>> A 12-bit unsigned integer field indicating the VLAN to be used in > >>>>>> traffic classification. A value of zero (0) indicates that the > >>>>>> VID is to be ignored and any VID is to be accepted during traffic > >>>>>> classification. Any explicitly mapped VLANs are matched first. > >>>>>> Any VLANs that do not have a mapping will then map to this default > >>>>>> mapping. > >>>>> > >>>>> Well, I don't think the two occurrences of 0xFFFF in this document > >>>>> have anything to do with this because they refer to the FID, not the > >>>>> VID. However, I think the full change to this text that I suggested > >>>>> for this (except the self-referential reference to 9892) would be good > >>>>> so > >>>>> OLD > >>>>> A value of zero (0) indicates that the > >>>>> VID is to be ignored and any VID is to be accepted during traffic > >>>>> classification. > >>>>> NEW > >>>>> VID value zero (0x0000) is used by > >>>>> to indicate that the VID is ignored and VID 0xFFFF is > >>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>> used in traffic classification. > >>>>> Perhaps you should suggest the above to the authors. > >>>>> Actually, use of "(0)" is not wrong, it's just that it seems much more > >>>>> consistent for all the VIDs (VLAN IDs) to be given in the same hex > >>>>> format. > >>>>> Thanks, > >>>>> Donald > >>>>> =============================== > >>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>>> 2386 Panoramic Circle, Apopka, FL 32703 USA > >>>>> [email protected] > >>>>>> = = = = = > >>>>>> The latest files are posted here. Please refresh your browser: > >>>>>> https://www.rfc-editor.org/authors/rfc9895.txt > >>>>>> https://www.rfc-editor.org/authors/rfc9895.pdf > >>>>>> https://www.rfc-editor.org/authors/rfc9895.html > >>>>>> https://www.rfc-editor.org/authors/rfc9895.xml > >>>>>> https://www.rfc-editor.org/authors/rfc9895-diff.html > >>>>>> https://www.rfc-editor.org/authors/rfc9895-rfcdiff.html (side by side) > >>>>>> https://www.rfc-editor.org/authors/rfc9895-auth48diff.html > >>>>>> https://www.rfc-editor.org/authors/rfc9895-auth48rfcdiff.html (side by > >>>>>> side) > >>>>>> https://www.rfc-editor.org/authors/rfc9895-xmldiff1.html > >>>>>> https://www.rfc-editor.org/authors/rfc9895-xmldiff2.html > >>>>>> Thanks again for your attentiveness to these documents! > >>>>>> Lynne Bartholomew > >>>>>> RFC Production Center > >>>>>>> On Nov 16, 2025, at 8:18 PM, Donald Eastlake <[email protected]> wrote: > >>>>>>> Hi, > >>>>>>> On Fri, Nov 14, 2025 at 5:12 PM <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Authors, > >>>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>>> necessary) the following questions, which are also in the source > >>>>>>>> file. > >>>>>>>> 1) <!-- [rfced] Document title: FYI, for ease of the reader and per > >>>>>>>> our > >>>>>>>> process, we expanded "DLEP" in the title. Please review. > >>>>>>>> Original: > >>>>>>>> DLEP IEEE 802.1Q Aware Credit Window Extension > >>>>>>>> Currently: > >>>>>>>> Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window > >>>>>>>> Extension --> > >>>>>>> > >>>>>>> OK. > >>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear > >>>>>>>> in the title) for use on <https://www.rfc-editor.org/search>. --> > >>>>>>> > >>>>>>> I don't know of any added keywords. > >>>>>>>> 3) <!-- [rfced] Section 1: Are one or more words missing from this > >>>>>>>> sentence? If neither suggestion below is correct, please clarify > >>>>>>>> what is shared. > >>>>>>>> Original: > >>>>>>>> Credit windows > >>>>>>>> may be allocated on either a shared or a per-flow basis. > >>>>>>>> Suggestion #1 (flows are shared): > >>>>>>>> Credit windows > >>>>>>>> may be allocated on either a shared-flow or per-flow basis. > >>>>>>>> Suggestion #2 (windows are shared): > >>>>>>>> Credit windows > >>>>>>>> may be allocated on either a shared-window or per-flow basis. --> > >>>>>>> > >>>>>>> Well, #2 is correct. But maybe it would be clearer to say > >>>>>>> Credit windows may be shared across multiple flows or used on a per > >>>>>>> flow basis. > >>>>>>>> 4) <!-- [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. --> > >>>>>>> > >>>>>>> I do not think any changes are needed for this reason. > >>>>>>>> 5) <!-- [rfced] The following term appears to be used inconsistently > >>>>>>>> in this document. Please let us know which form is preferred. > >>>>>>>> IEEE 802.1Q Aware Credit Window Type Value / > >>>>>>>> IEEE 802.1Q Aware Credit Window Extension Type Value --> > >>>>>>> > >>>>>>> I think the more complete version with the word "Extension" is good. > >>>>>>> See further suggested changes below. > >>>>>>>> Thank you. > >>>>>>>> Lynne Bartholomew and Rebecca VanRheenen > >>>>>>>> RFC Production Center > >>>>>>>> On Nov 14, 2025, at 2:10 PM, [email protected] wrote: > >>>>>>>> *****IMPORTANT***** > >>>>>>>> Updated 2025/11/14 > >>>>>>>> RFC Author(s): > >>>>>>>> -------------- > >>>>>>>> Instructions for Completing AUTH48 > >>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>>>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>>>>> If an author is no longer available, there are several remedies > >>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>>>>>> You and you coauthors are responsible for engaging other parties > >>>>>>>> (e.g., Contributors or Working Group) as necessary before providing > >>>>>>>> your approval. > >>>>>>>> Planning your review > >>>>>>>> --------------------- > >>>>>>>> Please review the following aspects of your document: > >>>>>>>> * RFC Editor questions > >>>>>>>> Please review and resolve any questions raised by the RFC Editor > >>>>>>>> that have been included in the XML file as comments marked as > >>>>>>>> follows: > >>>>>>>> <!-- [rfced] ... --> > >>>>>>>> These questions will also be sent in a subsequent email. > >>>>>>>> * Changes submitted by coauthors > >>>>>>>> Please ensure that you review any changes submitted by your > >>>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>>> agree to changes submitted by your coauthors. > >>>>>>>> * Content > >>>>>>>> Please review the full content of the document, as this cannot > >>>>>>>> change once the RFC is published. Please pay particular attention > >>>>>>>> to: > >>>>>>>> - IANA considerations updates (if applicable) > >>>>>>>> - contact information > >>>>>>>> - references > >>>>>>>> * Copyright notices and legends > >>>>>>>> Please review the copyright notice and legends as defined in > >>>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>>> (TLP – https://trustee.ietf.org/license-info). > >>>>>>>> * Semantic markup > >>>>>>>> Please review the markup in the XML file to ensure that elements of > >>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>>>>>> and <artwork> are set correctly. See details at > >>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>>>>>> * Formatted output > >>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>>> formatted output, as generated from the markup in the XML file, is > >>>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>>> limitations compared to the PDF and HTML. > >>>>>>>> Submitting changes > >>>>>>>> ------------------ > >>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>>>>>>> all > >>>>>>>> the parties CCed on this message need to see your changes. The > >>>>>>>> parties > >>>>>>>> include: > >>>>>>>> * your coauthors > >>>>>>>> * [email protected] (the RPC team) > >>>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>>> responsible ADs, and the document shepherd). > >>>>>>>> * [email protected], which is a new archival mailing list > >>>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>>> list: > >>>>>>>> * More info: > >>>>>>>> > >>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>>>>>> * The archive itself: > >>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>>>>>> If needed, please add a note at the top of the message that you > >>>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>>> [email protected] will be re-added to the CC list and > >>>>>>>> its addition will be noted at the top of the message. > >>>>>>>> You may submit your changes in one of two ways: > >>>>>>>> An update to the provided XML file > >>>>>>>> — OR — > >>>>>>>> An explicit list of changes in this format > >>>>>>>> Section # (or indicate Global) > >>>>>>> > >>>>>>> Section 2, first stentence. Saying "composed of" makes it sound like > >>>>>>> its all in RFCs 9892 and 9893 with nothing added by this document. > >>>>>>> Suggest the following: > >>>>>>> OLD > >>>>>>> The extension defined in this document is composed of the mechanisms > >>>>>>> and processing defined in [RFC9892] and [RFC9893]. > >>>>>>> NEW > >>>>>>> The extension defined in this document is built on the mechanisms > >>>>>>> and processing defined in [RFC9892] and [RFC9893]. > >>>>>>> Section 3, 3rd paragraph, 2nd sentence, seems a bit incomplete and > >>>>>>> fuzzy. I believe the following is clearer. > >>>>>>> OLD > >>>>>>> VID value zero (0) is used by > >>>>>>> [RFC9892] to indicate that the VID is ignored and any other VID > >>>>>>> value is > >>>>>>> used in traffic classification. > >>>>>>> NEW > >>>>>>> VID value zero (0x0000) is used by > >>>>>>> [RFC9892] to indicate that the VID is ignored and VID 0xFFFF is > >>>>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>>>> used in traffic classification. > >>>>>>> Thanks, > >>>>>>> Donald > >>>>>>> =============================== > >>>>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>>>>> 2386 Panoramic Circle, Apopka, FL 32703 USA > >>>>>>> [email protected] > >>>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>>> explicit > >>>>>>>> list of changes, as either form is sufficient. > >>>>>>>> We will ask a stream manager to review and approve any changes that > >>>>>>>> seem > >>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of > >>>>>>>> text, > >>>>>>>> and technical changes. Information about stream managers can be > >>>>>>>> found in > >>>>>>>> the FAQ. Editorial changes do not require approval from a stream > >>>>>>>> manager. > >>>>>>>> Approving for publication > >>>>>>>> -------------------------- > >>>>>>>> To approve your RFC for publication, please reply to this email > >>>>>>>> stating > >>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>>>>>> as all the parties CCed on this message need to see your approval. > >>>>>>>> Files > >>>>>>>> ----- > >>>>>>>> The files are available here: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895.txt > >>>>>>>> Diff file of the text: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895-rfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> Diff of the XML: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9895-xmldiff1.html > >>>>>>>> Tracking progress > >>>>>>>> ----------------- > >>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9895 > >>>>>>>> Please let us know if you have any questions. > >>>>>>>> Thank you for your cooperation, > >>>>>>>> RFC Editor > >>>>>>>> -------------------------------------- > >>>>>>>> RFC9895 (draft-ietf-manet-dlep-ether-credit-extension-09) > >>>>>>>> Title : DLEP IEEE 802.1Q Aware Credit Window Extension > >>>>>>>> Author(s) : D. Wiggins, L. Berger, D. Eastlake 3rd, Ed. > >>>>>>>> WG Chair(s) : Don Fedyk, Ronald in 't Velt, Donald E. Eastlake > >>>>>>>> 3rd > >>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >>>>>>>> Velde > >>>> > >>> > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
