Dear *Jim, We are having difficulty in reaching Bow-Nan Cheng. Bow-Nan's approval is the only approval needed to publish RFCs 9892, 9893, 9894, and 9895.
The AUTH48 status pages for these documents are here: https://www.rfc-editor.org/auth48/rfc9892 https://www.rfc-editor.org/auth48/rfc9893 https://www.rfc-editor.org/auth48/rfc9894 https://www.rfc-editor.org/auth48/rfc9895 Any assistance in getting these documents moved forward is most appreciated! Thank you! Lynne Bartholomew RFC Production Center > On Jan 5, 2026, at 10:17 AM, Lynne Bartholomew > <[email protected]> wrote: > > Dear Bow-Nan, > > We do not believe that we have heard from you regarding this document's > readiness for publication. Please review the document, and let us know > whether further changes are needed or you approve the document for > publication in its current form. > > 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 22, 2025, at 9:04 AM, Lynne Bartholomew >> <[email protected]> wrote: >> >> Hi, Don and Bow-Nan. >> >> Don, we have noted your approval on the AUTH48 status page: >> >> https://www.rfc-editor.org/auth48/rfc9892 >> >> Bow-Nan, we do not believe that we have heard from you regarding this >> document's readiness for publication. Please review the document, and let >> us know whether further changes are needed or you approve the document for >> publication in its current form. >> >> 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 19, 2025, at 8:32 AM, Don Fedyk <[email protected]> wrote: >>> >>> Hi Lynne >>> >>> Thanks for all your work, The document looks good to me, >>> >>> DonFrom: Lynne Bartholomew <[email protected]> >>> Sent: Tuesday, December 16, 2025 11:43 AM >>> To: Don Fedyk <[email protected]> >>> Cc: Lou Berger <[email protected]>; James Guichard >>> <[email protected]>; [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: *[AD] Re: AUTH48: RFC-to-be 9892 >>> <draft-ietf-manet-dlep-traffic-classification-17> for your review >>> Hi, Don. >>> >>> We further updated this document per your note below. >>> >>> 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 15, 2025, at 3:46 PM, Don Fedyk <[email protected]> wrote: >>>> >>>> Hi Lynn >>>> Inline [Don] >>>> >>>> Thanks, >>>> DonFrom: Lynne Bartholomew <[email protected]> >>>> Sent: Monday, December 15, 2025 1:34 PM >>>> To: Don Fedyk <[email protected]> >>>> Cc: Lou Berger <[email protected]>; James Guichard >>>> <[email protected]>; [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: *[AD] Re: AUTH48: RFC-to-be 9892 >>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review >>>> >>>> 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 >>>> >>>> [Don] Yes the latter "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]
