Authors, While reviewing this document during AUTH48, please resolve (as necessary) 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] Section 1: We had trouble following the "and", "or", and "and/or" relationships in this sentence. If the suggested text is not correct, please clarify. Original: The defined mechanism allows for flows to be described in a flexible fashion and when combined with applications such as credit window control, allows credit windows to be shared across traffic sent to multiple DLEP destinations and as part of multiple flows, or used exclusively for traffic sent to a particular destination and/or belonging to a particular flow. Suggested: The defined mechanism allows for flows to be described in a flexible fashion and, when combined with applications such as credit window control, allows credit windows to be (1) shared across traffic sent to multiple DLEP destinations and as part of multiple flows or (2) used exclusively for traffic sent to a particular destination and/or belonging to a particular flow. --> 3) <!-- [rfced] Section 2: Does "based on IP protocol and" (which looks like "based on Internet Protocol protocol and") mean "based on IP protocol type and" or something else? Original: Other types of flow identification, e.g., based on IP protocol and ports, may be defined in the future via new Sub-Data Items. --> 4) <!-- [rfced] Sections 2.1 and 2.1.1: 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: Per [RFC8175] Length is the number of octets in the Data Item, excluding the Type and Length fields. ... Copying [RFC8175], Length is a 16-bit unsigned integer that is the number of octets in the Sub-Data Item, excluding the Type and Length fields. Suggested: Per Section 11.3 of [RFC8175], Length is the number of octets in the Data Item, excluding the Data Item Type and Length fields. ... Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer that is the number of octets in the Sub-Data Item, excluding the Data Item Type and Length fields. --> 5) <!-- [rfced] Section 2.1: For ease of the reader, we changed "below" to "in Section 2.1.1". If this is incorrect, please clarify what "below" refers to. Original: Traffic Classification Sub-Data Item: Zero or more Traffic Classification Sub-Data Items of the format defined below MAY be included. Currently: Traffic Classification Sub-Data Item: Zero or more Traffic Classification Sub-Data Items of the format defined in Section 2.1.1 MAY be included. --> 6) <!-- [rfced] Section 2.1.1: We had trouble following the meaning of "on a per Sub-Data Item Type". Are some words missing? Original: The maximum length is limited on a per Sub-Data Item Type. --> 7) <!-- [rfced] Section 2.1.1: We see that the Value field is mentioned under "Sub-Data Item Type:" but is not otherwise defined. Would you like to add a list item and explanation of the Value field? For example, Section 11.3 of RFC 8175 provides this definition of the Value field: Value: A field of <Length> octets that contains data specific to a particular Data Item. Original: ~ Value... ~ ... Sub-Data Item Type: A 16-bit unsigned integer that indicates the type and corresponding format of the Sub-Data Item's Value field. ... --> 8) <!-- [rfced] Section 2.2: Please clarify "one DSCPs". There appears to be a singular-versus-plural issue (i.e., perhaps either "one DSCP" or "one or more DSCPs" would be correct here). Original: This means that the maximum Length base on a FID per DSCP for this TLV could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320 octets. --> 9) <!-- [rfced] Section 2.2: Please confirm that there is no IANA registration associated with the value "0xFFFF" in this sentence. Original: The value of 0xFFFF is reserved and MUST NOT be used in this field. --> 10) <!-- [rfced] Section 2.2: We changed "is an 8-bit that carries" to "is 8 bits long and carries". If this update is incorrect, please clarify the meaning of "an 8-bit that carries". Original: DS Field: Each DS Field is an 8-bit that carries the DSCP field defined in [RFC2474]. Currently: DS Field: Each DS Field is 8 bits long and carries the DSCP field as defined in [RFC2474]. --> 11) <!-- [rfced] Section 2.3: We had trouble following these sentences. Does "the next higher integer quantity" refer to a higher integer quantity that comes next, or does it mean "the next-higher integer quantity" or "the next-highest integer quantity"? In the equation, does "divided by 2 or 16 octets" mean "divided by either 2 octets or 16 octets", or something else? Original: Note that as length is in octets and each Priority field is 4 bits, the additional length is the value carried in the NumPCPs field divided by two and rounded up to the next higher integer quantity. This TLV has maximum length of 4 plus 8 divided by 2 or 16 octets. --> 12) <!-- [rfced] Section 2.3: We changed "The maximum number of PCPs 8" to "The maximum number of PCPs is 8". If this is incorrect, please clarify the text. Original: The maximum number of PCPs 8. Currently: The maximum number of PCPs is 8. --> 13) <!-- [rfced] Section 2.3: Is "either PCP" correct here? Earlier text indicates that there can be up to 8 PCPs. Original: Note that zero (0) is a valid value for either PCP. Perhaps: Note that zero (0) is a valid value for PCP. --> 14) <!-- [rfced] We found the following two comments in the XML file. May we remove them? First comment: Both the router and the modem need to support this document, DLEP Traffic Classification, and DLEP Credit Flow Control, <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>. Second comment: This document requests the assignment of several values by IANA. All assignments are to registries defined by <xref target="RFC8175" format="default"/>. --> 15) <!-- [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. --> 16) <!-- [rfced] Below are some specific questions relating to IANA text in Section 5.2 of the document. a) FYI - To improve clarity, we added a new table (current Table 2) to show the registration policies and adjusted the original table (current Table 3) to show only the initial contents of the registry. b) In the current Table 3, which shows the initial values of the new registry, [RFC2474] and [IEEE8021Q] are listed as references. Should this document be listed as a reference instead of or in addition to [RFC2474] and [IEEE8021Q]? It seems that this document defines the Diffserv Traffic Classification in Section 2.2 and the Ethernet Traffic Classification in Section 2.3. Please review and let us know if any updates are needed. If needed, we will ask IANA to update the "Traffic Classification Sub-Data Item Type Values" registry prior to publication. Link to registry: https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values> c) Related to the question above, the first two sentences below do not directly indicate that this document defines the two new Sub-Data Items in Sections 2.2 and 2.3, but the third sentence does. Should any of these sentences be updated? Original: This document also introduces DLEP Sub-Data Items, and Sub-Data Items are defined to support DiffServ and Ethernet traffic classification. ... This document defines support for traffic classification using a single new Data Item in Section 2.1 for general support and two new Sub-Data Items are defined to support identification of flows based on DSCPs and PCPs. ... This document defines traffic classification based on a DLEP destination and flows identified by either DiffServ [RFC2475] Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q] Ethernet Priority Code Points (PCPs). Perhaps (updates to first two sentences to indicate that this document defines the two Sub-Data Items; not changes to third sentence): This document also introduces DLEP Sub-Data Items and defines two new Sub-Data Items to support Diffserv and Ethernet traffic classification. ... This document defines support for traffic classification using a single new Data Item (see Section 2.1) for general support and defines two new Sub-Data Items to support identification of flows based on DSCPs and PCPs (see Sections 2.2 and 2.3). ... This document defines traffic classification based on a DLEP destination and flows identified by either Diffserv [RFC2475] Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q] Ethernet Priority Code Points (PCPs). d) May we combine the first paragraph after the current Table 3 and the last paragraph of Section 5.2 as follows? Also, would it be helpful to separate the text after the current Table 3 into a new section so future documents can easily refer to the guidance? Last, we suggest including "Specification Required" in this text as the guidance only applies to registrations with that policy. Original: This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Traffic Classification Sub-Data Item Type Values registry for the DLEP protocol, in accordance with BCP 26 and [RFC8126]. ... To simplify future registrations, it is recommended that this guidance serves as a standard reference for all DLEP-related registries. Future specifications may include a header note pointing to this guidance document. Perhaps: 5.3. Registration Guidance This section provides guidance for registrations in the "Traffic Classification Sub-Data Item Type Values" registry. To simplify future registrations in DLEP-related registries, it is recommended that the guidance in this section apply to all registries within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry group that use the "Specification Required" policy [RFC8126]. Future specifications may point to the guidance in this document. e) Please clarify "two specific registries" here. Is the intent "two specific entries" (i.e., 1 for Diffserv Traffic Classification and 2 for Ethernet Traffic Classification)? Original (the previous sentence included for context): This registry encompasses packet traffic classification, where standard packet header identifiers in packets or data frames indicate Quality of Service (QoS) treatment. It includes two specific registries for widely recognized identifiers used in QoS management for IP and Ethernet networks. Perhaps: This registry encompasses packet traffic classification, where standard packet header identifiers in packets or data frames indicate Quality of Service (QoS) treatment. It includes two specific entries for widely recognized identifiers used in QoS management for IP and Ethernet networks. --> 17) <!-- [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. --> 18) <!-- [rfced] Please let us know if any changes are needed for the following: a) The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections. data item (1 instance) / Data Item (e.g., "the data item", "the Data Item") (per the rest of this document and per this group (cluster) of documents) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. priority field / Priority field / Priority Field (e.g., "priority fields", "Priority fields", "Each Priority Field is", "each Priority field is") Item Types / Item types (e.g., "Traffic Classification Sub-Data Item Types", "Traffic Classification Sub-Data Item types") Num PCPs (1 instance) / NumPCPs (4 instances) (We also see "Num DSCPs" and "Num SDIs".) the individual Sub-Data Item / the individual Sub-Data Items --> Thank you. Lynne Bartholomew and Rebecca VanRheenen RFC Production Center On Nov 14, 2025, at 1:54 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) OLD: old text NEW: new text 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/rfc9892.xml https://www.rfc-editor.org/authors/rfc9892.html https://www.rfc-editor.org/authors/rfc9892.pdf https://www.rfc-editor.org/authors/rfc9892.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9892-diff.html https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9892 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9892 (draft-ietf-manet-dlep-traffic-classification-17) Title : Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item Author(s) : B. Cheng, D. Wiggins, L. Berger, D. Fedyk, 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]
