Great! Thank you for the quick turnaround, Amanda! Lynne Bartholomew RFC Production Center
> On Dec 23, 2025, at 5:35 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > This is done: https://www.iana.org/assignments/dlep-parameters > > thanks, > Amanda > > On Tue Dec 23 20:57:34 2025, [email protected] wrote: >> Dear IANA, >> >> Please make the following update on >> <https://www.iana.org/assignments/dlep-parameters/>, in the "Traffic >> Classification Sub-Data Item Type Values" registry: >> >> OLD: >> DiffServ Traffic Classification >> >> NEW: >> Diffserv Traffic Classification >> >> 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] <rfc-editor@rfc- >>>> editor.org>; [email protected] <[email protected]>; manet- >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; auth48archive@rfc- >>>> editor.org<[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] <rfc-editor@rfc- >>>>> editor.org>; [email protected] <[email protected]>; manet- >>>>> [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] <rfc- >>>>>>>>>>>> [email protected]>; [email protected] <manet- >>>>>>>>>>>> [email protected]>; [email protected] <manet- >>>>>>>>>>>> [email protected]>; >>>>>>>>>>>> [email protected]<[email protected]>;auth48archive@rfc- >>>>>>>>>>>> editor.org <[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]>; manet- >>>>>>>>>>>>> [email protected]<[email protected]>; >>>>>>>>>>>>> [email protected]<[email protected]>; >>>>>>>>>>>>> [email protected]<[email protected]>;auth48archive@rfc- >>>>>>>>>>>>> editor.org <[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] >>>>>>>>>>>>>> editor.org> >>>>>>>>>>>>>> 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] <manet- >>>>>>>>>>>>>> [email protected]>; [email protected] <manet- >>>>>>>>>>>>>> [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] <rfc-editor@rfc- >>>>>>>>>>>>>>> editor.org> >>>>>>>>>>>>>>> Sent: Friday, November 14, 2025 4:57 PM >>>>>>>>>>>>>>> To: [email protected] <[email protected]>; Lou Berger >>>>>>>>>>>>>>> <[email protected]>; Don Fedyk <[email protected]> >>>>>>>>>>>>>>> Cc: [email protected] <rfc-editor@rfc- >>>>>>>>>>>>>>> editor.org>; [email protected] <[email protected]>; >>>>>>>>>>>>>>> [email protected]<[email protected]>; >>>>>>>>>>>>>>> [email protected] <[email protected]>; >>>>>>>>>>>>>>> [email protected]<[email protected]>;auth48archive@rfc- >>>>>>>>>>>>>>> editor.org <[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]
