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]
