Hi, Don, Bow-Nan, and Lou. Don, thank you for your reply.
Regarding this reply from you: We changed "the maximum Length for the based on" to "the maximum Length based on". Please let us know if some other words were missing that should be added. > [Don] I believe - checking my math again that this length is on a per > Traiffic Identifier basis. > If every FID was mapped to an explicit DSCP the length would be (2+1+1) * 64 > = 256. > > NEW "under DiffServ Traffic Classification Sub-Data Item" > This > means that the maximum Length for the based on a single DSCP per FID for > this TLV > could be 64 times two ( FID) plus one for (Num DSCPs) plus one octet for a > single DSCP > or 256 octets. > > " Think the error was using 3 instead of 2 and resulting in counting the Num > DSCPs twice" Regarding our question 18)b) and your reply: Which form is preferred for consistency in this document -- priority field, Priority field, or Priority Field? Same question for these two; which form is preferred? Item Types / Item types Num PCPs (1 instance) / NumPCPs (4 instances) >> >> 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 --> > > > > [Don] Good Thanks. > = = = = = Would you like to make this update, mentioned by Donald Eastlake in relation to RFC-to-be 9895? Please read his entire reply (i.e., that nothing is wrong but that consistency might be good). Our question for Donald: >> 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. Donald's reply: > 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 > 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. = = = = = The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9892.txt https://www.rfc-editor.org/authors/rfc9892.pdf https://www.rfc-editor.org/authors/rfc9892.html https://www.rfc-editor.org/authors/rfc9892.xml https://www.rfc-editor.org/authors/rfc9892-diff.html https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-auth48diff.html https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-lastdiff.html https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html Thanks again! Lynne Bartholomew RFC Production Center > On Nov 20, 2025, at 4:03 PM, Don Fedyk <[email protected]> wrote: > > Hi Lynn > > Thank you, sorry, some of those additions came about because of comments on > how large the data items could. The important thing was to make sure the > object was reasonably bouunded but I think I have corrected it below. > > Inline [Don] > > > From: Lynne Bartholomew <[email protected]> > Sent: Thursday, November 20, 2025 12:03 PM > To: Don Fedyk <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; Lou Berger <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected]<[email protected]>; > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9892 > <draft-ietf-manet-dlep-traffic-classification-17> for your review > > Hi, Don. Thank you for your prompt reply! > > We have updated this document per your notes below. > > We have a few follow-up items for you: > > * Apologies; in looking at our question 8) more closely, we see "maximum > Length base on" and wonder if "base on" should be "based on". We also wonder > if "Num DSCPs plus one DSCPs" should be "(Num DSCPs plus one)" (as in showing > an addition). Should we update per our "Possibly" text, or could you provide > a better way to write this sentence? > > >> 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. --> > > > > [Don] Should be "one DSCP". > > Currently: > 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. > > Possibly: > This > means that the maximum Length based on a FID per DSCP for this TLV > could be 64 times 3 plus one for (Num DSCPs plus one) octets, or 320 > octets. > > [Don] I believe - checking my math again that this length is on a per > Traiffic Identifier basis. > If every FID was mapped to an explicit DSCP the length would be (2+1+1) * 64 > = 256. > > NEW "under DiffServ Traffic Classification Sub-Data Item" > This > means that the maximum Length for the based on a single DSCP per FID for > this TLV > could be 64 times two ( FID) plus one for (Num DSCPs) plus one octet for a > single DSCP > or 256 octets. > > " Think the error was using 3 instead of 2 and resulting in counting the Num > DSCPs twice" > > = = = = = > > * Regarding our question 11) and your reply: We updated per your note, > except that > we changed "number octets" to "number of octets". If this is incorrect, > should > "number octets" be clarified? > > >> 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. --> > > > > [Don] I think that is bad math. Sorry. > > > > NEW > > that as length is in octets and each Priority field is 4 bits, the > > total length of this Sub-Data Item is the 2 octets > > of Flow Identifer, plus the 2 octets for NumPCPs and VLAN Identifier > > plus the number octets for Priority Code Points. The number of > > octets for the PCPs is computed by rounding up the NumPCPs > > to the nearest even value and dividing by 2. > > This TLV has maximum length of 4 plus 8 divided by 2 or 8 octets. > > > Currently: > Note > that as the length is in octets and each Priority field is 4 bits, > the total length of this Sub-Data Item is the 2 octets of Flow > Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus > the number of octets for PCPs. The number of octets for the PCPs > is computed by rounding up NumPCPs to the nearest even value and > dividing by 2. This TLV has maximum length of 4 plus 8 divided by > 2 or 8 octets. > > [Don] Yes thanks. > = = = = = > > * Regarding our question 15) and your reply: > > >> 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. --> > > > > [Don] Yes accepted Suggested but the IEEE-8802-1X is the ISO version of > > IEEE-802.1X > > https://ieeexplore.ieee.org/document/9650828 > > > > I think we should use the IEEE version change IEEE-8802-1X to > > IEEE-802.1X. > [Don] The practice is IEEE publishes IEEE802.1X for example, then ISO > republishes it so it is the same document mostly. > However we usually refer to the IEEE base document and did that for IEEE > 802.1Q. > > I thought pasted the corrected URL for Original IEEE spec but maybe I > goofed. Here it is again. IEEE 802.1X-2020 > https://ieeexplore.ieee.org/document/9018454 > > Apologies for our confusion: When we go to > <https://ieeexplore.ieee.org/document/9650828>, > we see "8802-1X-2021 - 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". > Is <https://ieeexplore.ieee.org/document/9650828> the wrong URL? > > We changed the citation string per your note but would like to confirm that > this update > won't be confusing to readers. We also ask because RFC-to-be 9893 cites IEEE > 8802-1X > and uses the citation string "[IEEE-8802-1X]". > > Currently: > [IEEE-802.1X] > IEEE, "8802-1X-2021 - 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", DOI 10.1109/IEEESTD.2021.9650828, IEEE > Std IEEE-802.1X-2021, December 2021, > <https://ieeexplore.ieee.org/document/9650828>. > [DON] use https://ieeexplore.ieee.org/document/9018454 > = = = = = > > * Regarding our question 18)b) and your reply -- please let us know which > form is > preferred for the following three items: > > >> 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 --> > > > > [Don] Good Thanks. > > > = = = = = > > The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9892.txt > https://www.rfc-editor.org/authors/rfc9892.pdf > https://www.rfc-editor.org/authors/rfc9892.html > https://www.rfc-editor.org/authors/rfc9892.xml > https://www.rfc-editor.org/authors/rfc9892-diff.html > https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side by > side) > > https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > > Thanks again! > > Lynne Bartholomew > RFC Production Center > > > > On Nov 18, 2025, at 6:24 AM, Don Fedyk <[email protected]> wrote: > > > > Hi > > > > Thanks My comments inline [Don]. Please let me know if anything is not > > clear. > > > > Thank you > > Don > > > > > > From: [email protected] <[email protected]> > > Sent: Friday, November 14, 2025 4:57 PM > > To: [email protected] <[email protected]>; Lou Berger <[email protected]>; > > Don Fedyk <[email protected]> > > Cc: [email protected] <[email protected]>; > > [email protected] <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] > > <[email protected]>;[email protected] > > <[email protected]> > > Subject: Re: AUTH48: RFC-to-be 9892 > > <draft-ietf-manet-dlep-traffic-classification-17> for your review > > > > 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>. --> > > > > Diffserv Code Points > > Ethernet Priority Code Points. > > > > > > 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. --> > > > > [Don] Ok. > > > > 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? > > > > [Don]The IP transport layer protocol. (Examples: TCP, UDP etc.) > > > > 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. --> > > > > [Don] Suggested: NEW > > Other types of flow identification, e.g., based on > > IP transport layer protocol and ports, may be defined in the future via new > > Sub-Data > > > > 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. --> > > > > [Don] > > Yes Data Item Type vs Type. > > > > 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. --> > > > > [Don] Yes > > > > 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. --> > > > > [Don] NEW > > Each Sub-Data Item has its own length field. > > > > This is all that is needed. Each Sub-Data Item is subject > > to the maximum length of encompassing the Data Item. > > > > 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. > > > > [Don] Value is the same as defined in RFC 8175. > > Repeating this definition is fine. Value is only used for the general > > format. > > > > 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. --> > > > > [Don] Should be "one DSCP". > > > > > > 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. > > --> > > [Don] Correct this is just a reserved Flow Identifier. No IANA > > registration. > > > > 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]. --> > > > > [Don] Good "8 bits long" is better > > r > > 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. --> > > > > [Don] I think that is bad math. Sorry. > > > > NEW > > that as length is in octets and each Priority field is 4 bits, the > > total length of this Sub-Data Item is the 2 octets > > of Flow Identifer, plus the 2 octets for NumPCPs and VLAN Identifier > > plus the number octets for Priority Code Points. The number of > > octets for the PCPs is computed by rounding up the NumPCPs > > to the nearest even value and dividing by 2. > > This TLV has maximum length of 4 plus 8 divided by 2 or 8 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. --> > > [Don] This is correct. > > > > 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. > > > > [Don] This is correct removing either. > > > > 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"/>. --> > > [Don] Yes please remove. > > > > 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. --> > > > > [Don] Yes accepted Suggested but the IEEE-8802-1X is the ISO version of > > IEEE-802.1X > > https://ieeexplore.ieee.org/document/9650828 > > > > I think we should use the IEEE version change IEEE-8802-1X to > > IEEE-802.1X. > > > > > > 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. > > [Don] Good. > > 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. > > [Don] The table referencing [RFC2474] and [IEEE8021Q] is correct for Type > > code 1 and Type code 2 respectively. > > No need to add this document as reference - it is there for the whole table. > > > > 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. > > [Don] This is good. > > ... > > 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). > > [Don] This is good. > > ... > > 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. > > [Don] This update is good. > > > > 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. > > [Don] This is good. > > --> > > 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) > > [Don] Good thanks. > > 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 --> > > [Don] Good Thanks. > > > > 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]
