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]
