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]
