Hi, Don, Bow-Nan, and Lou. We do not believe that we received a reply from you regarding our questions in the email below. Please review, and let us know how this document should be updated.
Thank you! Lynne Bartholomew RFC Production Center > On Nov 24, 2025, at 9:46 AM, Lynne Bartholomew > <[email protected]> wrote: > > 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]
