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]
