Hi, Don. Please let us know whether or not we should make a further update regarding the following (copied from our 12/8/2025 email below):
> Don, we still have one more question for you; apologies for missing this one > earlier. Should the following be made consistent? > > across the Data Item and not the individual Sub-Data Item / > across the Data Item and not the individual Sub-Data Items We are asking about "individual Sub-Data Item" vs. "individual Sub-Data Items". We are fine with leaving as is if this isn't an issue. Thank you! Lynne Bartholomew RFC Production Center > On Dec 10, 2025, at 11:29 AM, Lynne Bartholomew > <[email protected]> wrote: > > Hi, Lou. > > We've noted your approval on the AUTH48 status page. Please let us know if > your note did not indicate approval, and we'll revert: > > https://www.rfc-editor.org/auth48/rfc9892 > > Thank you! > > Lynne Bartholomew > RFC Production Center > >> On Dec 10, 2025, at 10:26 AM, Lou Berger <[email protected]> wrote: >> >> Lynne, >> >> Thank you - this looks good to me. >> >> Lou >> >> On 12/9/2025 7:08 PM, Lynne Bartholomew wrote: >>> Hi, Lou, Don, and *Jim. >>> >>> Lou, we've updated this document per your note below. >>> >>> *Jim, please review the latest update to the text under "Length:" in >>> Section 2.2, and let us know if you approve. >>> >>> 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 >>> >>> Thank you! >>> >>> Lynne Bartholomew >>> RFC Production Center >>> >>>> On Dec 9, 2025, at 7:09 AM, Don Fedyk <[email protected]> wrote: >>>> >>>> Hi >>>> >>>> I agree with Lou the maximum value is the Length of single sub data item - >>>> one FID makes more sense. >>>> >>>> Don >>>> On Dec 8, 2025, at 3:26 PM, Lou Berger <[email protected]> wrote: >>>> >>>> Hi, >>>> I believe I see an error in https://www.rfc-editor.org/authors/rfc9892.txt >>>> In the following. The total provide is for the data item not the sub-data >>>> item length. >>>> >>>> Length: >>>> Variable >>>> >>>> Length is defined above. For this Sub-Data Item, it is equal to >>>> three (3) octets plus the value of the Num DSCPs field. This >>>> means that the maximum Length 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. The definition can be >>>> in multiple Sub-Data Items that are much smaller than this. >>>> >>>> >>>> OLD >>>> This >>>> means that the maximum Length 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. >>>> NEW >>>> This >>>> means that the maximum Length value is 3 + 64 or 67 octets. >>>> Thanks, >>>> Lou >>>> >>>> On 12/8/2025 1:18 PM, Lynne Bartholomew wrote: >>>>> Dear Don, Bow-Nan, and Lou. >>>>> >>>>> Checking in with you regarding the status of this document. Please let us >>>>> know whether further updates are needed or you approve this document for >>>>> publication in its current form. >>>>> >>>>> Don, we still have one more question for you; apologies for missing this >>>>> one earlier. Should the following be made consistent? >>>>> >>>>> across the Data Item and not the individual Sub-Data Item / >>>>> across the Data Item and not the individual Sub-Data Items >>>>> >>>>> 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 >>>>> >>>>> The AUTH48 status page is here: >>>>> >>>>> https://www.rfc-editor.org/auth48/rfc9892 >>>>> >>>>> Thank you! >>>>> >>>>> Lynne Bartholomew >>>>> RFC Production Center >>>>> >>>>> >>>>>> On Dec 2, 2025, at 1:26 PM, Lynne Bartholomew >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi, Jim. So noted: >>>>>> >>>>>> https://www.rfc-editor.org/auth48/rfc9892 >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Lynne Bartholomew >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>>> On Dec 2, 2025, at 9:07 AM, James Guichard >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Update looks okay for me. Approved. >>>>>>> >>>>>>> Jim >>>>>>> >>>>>>> Get Outlook for iOS >>>>>>> From: Lynne Bartholomew <[email protected]> >>>>>>> Sent: Monday, December 1, 2025 3:18:51 PM >>>>>>> To: Don Fedyk <[email protected]>; James Guichard >>>>>>> <[email protected]> >>>>>>> Cc: [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: *[AD] Re: AUTH48: RFC-to-be 9892 >>>>>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review Hi, >>>>>>> Don and *AD (Jim). >>>>>>> >>>>>>> * Jim, please review the updates to the "VLAN Identifier (VID):" >>>>>>> paragraph in Section 2.3, and let us know if you approve. We ask for >>>>>>> your approval because the updates could be considered "beyond >>>>>>> editorial". >>>>>>> >>>>>>> >>>>>>> Don, no worries, and we hope that you had a good holiday weekend. >>>>>>> >>>>>>> We have made further updates to this document per your notes below, but >>>>>>> we still have one more question for you; apologies for missing this one >>>>>>> earlier. Should the following be made consistent? >>>>>>> >>>>>>> across the Data Item and not the individual Sub-Data Item / >>>>>>> across the Data Item and not the individual Sub-Data Items >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Lynne Bartholomew >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Dec 1, 2025, at 9:23 AM, Don Fedyk <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Lynn >>>>>>>> >>>>>>>> Sorry for the delay, short work week last week. >>>>>>>> >>>>>>>> Inline [Don] >>>>>>>> >>>>>>>> Thank You, >>>>>>>> Don >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Lynne Bartholomew <[email protected]> >>>>>>>> Sent: Monday, November 24, 2025 12:46 PM >>>>>>>> To: Don Fedyk <[email protected]>; [email protected] >>>>>>>> <[email protected]>; Lou Berger <[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 >>>>>>>> >>>>>>>> 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? >>>>>>>> >>>>>>>> [Don] Priority Field >>>>>>>> >>>>>>>> Same question for these two; which form is preferred? >>>>>>>> >>>>>>>> Item Types / Item types >>>>>>>> >>>>>>>> Item Types (used in RFC 8175) >>>>>>>> >>>>>>>> >>>>>>>> Num PCPs (1 instance) / NumPCPs (4 instances) >>>>>>>> >>>>>>>> [Don] Ahh, Ascii Art limited us to NumPCPs I would use that everywhere >>>>>>>> to make it consistent. >>>>>>>> >>>>>>>> >>>>>>>>>>>> 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). >>>>>>>> >>>>>>>> [Don] The VID in this douement is 12bits. The largest it can be is >>>>>>>> 0xFFE. Therefore the value of 0x000 would be the corresponing >>>>>>>> representation but not used much. I don't see a problem with zero(0) >>>>>>>> in this case but when I maeked up up I guess 0x000 is more >>>>>>>> consistent.. As far as the reserved values those are inherited from >>>>>>>> IEEE 802.1Q. >>>>>>>> See mark up below. [Don] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>>>> >>>>>>>> [Don] >>>>>>>> NEW >>>>>>>> >>>>>>>>> VID value zero (0x000) is used >>>>>>>>> to indicate that the VID is ignored and VID 0xFFF is reserved. >>>>>>>>> Any other VID value from 0x001 through 0xFFE 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]
