Hi again, Donald. We've updated this document as well, per your note below.
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 Thanks as always! Lynne Bartholomew RFC Production Center > On Dec 3, 2025, at 9:52 AM, Donald Eastlake <[email protected]> wrote: > > 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]
