Hello. Checking in with you regarding the status of this document. Please advise.
Thank you! Lynne Bartholomew RFC Production Center > On Jan 12, 2026, at 10:47 AM, Lynne Bartholomew > <[email protected]> wrote: > > Thank you, Don! > >> On Jan 12, 2026, at 10:35 AM, Don Fedyk <[email protected]> wrote: >> >> I will check with Lou if there is another way to contact Bow-Nan. >> >> Don From: Lynne Bartholomew <[email protected]> >> Sent: Monday, January 12, 2026 1:33 PM >> To: James Guichard <[email protected]> >> Cc: [email protected] <[email protected]>; Don Fedyk <[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 >> 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]
