Hi, Don. We further updated this document per your note below.
The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9892.txt https://www.rfc-editor.org/authors/rfc9892.pdf https://www.rfc-editor.org/authors/rfc9892.html https://www.rfc-editor.org/authors/rfc9892.xml https://www.rfc-editor.org/authors/rfc9892-diff.html https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-auth48diff.html https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-lastdiff.html https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html Thank you! Lynne Bartholomew RFC Production Center > On Dec 15, 2025, at 3:46 PM, Don Fedyk <[email protected]> wrote: > > Hi Lynn > Inline [Don] > > Thanks, > DonFrom: Lynne Bartholomew <[email protected]> > Sent: Monday, December 15, 2025 1:34 PM > To: Don Fedyk <[email protected]> > Cc: Lou Berger <[email protected]>; James Guichard > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]> > Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9892 > <draft-ietf-manet-dlep-traffic-classification-17> for your review > > Hi, Don. > > Please let us know whether or not we should make a further update regarding > the following (copied from our 12/8/2025 email below): > > > Don, we still have one more question for you; apologies for missing this > > one earlier. Should the following be made consistent? > > > > across the Data Item and not the individual Sub-Data Item / > > across the Data Item and not the individual Sub-Data Items > > [Don] Yes the latter "across the Data Item and not the individual Sub-Data > Items" > > > > > > We are asking about "individual Sub-Data Item" vs. "individual Sub-Data > Items". We are fine with leaving as is if this isn't an issue. > > Thank you! > > Lynne Bartholomew > RFC Production Center > > > On Dec 10, 2025, at 11:29 AM, Lynne Bartholomew > > <[email protected]> wrote: > > > > Hi, Lou. > > > > We've noted your approval on the AUTH48 status page. Please let us know if > > your note did not indicate approval, and we'll revert: > > > > https://www.rfc-editor.org/auth48/rfc9892 > > > > Thank you! > > > > Lynne Bartholomew > > RFC Production Center > > > >> On Dec 10, 2025, at 10:26 AM, Lou Berger <[email protected]> wrote: > >> > >> Lynne, > >> > >> Thank you - this looks good to me. > >> > >> Lou > >> > >> On 12/9/2025 7:08 PM, Lynne Bartholomew wrote: > >>> Hi, Lou, Don, and *Jim. > >>> > >>> Lou, we've updated this document per your note below. > >>> > >>> *Jim, please review the latest update to the text under "Length:" in > >>> Section 2.2, and let us know if you approve. > >>> > >>> The latest files are posted here. Please refresh your browser: > >>> > >>> https://www.rfc-editor.org/authors/rfc9892.txt > >>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>> https://www.rfc-editor.org/authors/rfc9892.html > >>> https://www.rfc-editor.org/authors/rfc9892.xml > >>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) > >>> https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side by > >>> side) > >>> https://www.rfc-editor.org/authors/rfc9892-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by > >>> side) > >>> > >>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > >>> > >>> Thank you! > >>> > >>> Lynne Bartholomew > >>> RFC Production Center > >>> > >>>> On Dec 9, 2025, at 7:09 AM, Don Fedyk <[email protected]> wrote: > >>>> > >>>> Hi > >>>> > >>>> I agree with Lou the maximum value is the Length of single sub data item > >>>> - one FID makes more sense. > >>>> > >>>> Don > >>>> On Dec 8, 2025, at 3:26 PM, Lou Berger <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> I believe I see an error in > >>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>> In the following. The total provide is for the data item not the > >>>> sub-data item length. > >>>> > >>>> Length: > >>>> Variable > >>>> > >>>> Length is defined above. For this Sub-Data Item, it is equal to > >>>> three (3) octets plus the value of the Num DSCPs field. This > >>>> means that the maximum Length based on a single DSCP per FID for > >>>> this TLV could be 64 times two (FID) plus one for (Num DSCPs) plus > >>>> one octet for a single DSCP or 256 octets. The definition can be > >>>> in multiple Sub-Data Items that are much smaller than this. > >>>> > >>>> > >>>> OLD > >>>> This > >>>> means that the maximum Length based on a single DSCP per FID for > >>>> this TLV could be 64 times two (FID) plus one for (Num DSCPs) plus > >>>> one octet for a single DSCP or 256 octets. > >>>> NEW > >>>> This > >>>> means that the maximum Length value is 3 + 64 or 67 octets. > >>>> Thanks, > >>>> Lou > >>>> > >>>> On 12/8/2025 1:18 PM, Lynne Bartholomew wrote: > >>>>> Dear Don, Bow-Nan, and Lou. > >>>>> > >>>>> Checking in with you regarding the status of this document. Please let > >>>>> us know whether further updates are needed or you approve this document > >>>>> for publication in its current form. > >>>>> > >>>>> Don, we still have one more question for you; apologies for missing > >>>>> this one earlier. Should the following be made consistent? > >>>>> > >>>>> across the Data Item and not the individual Sub-Data Item / > >>>>> across the Data Item and not the individual Sub-Data Items > >>>>> > >>>>> The latest files are posted here. Please refresh your browser: > >>>>> > >>>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9892.html > >>>>> https://www.rfc-editor.org/authors/rfc9892.xml > >>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) > >>>>> https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side by > >>>>> side) > >>>>> https://www.rfc-editor.org/authors/rfc9892-lastdiff.html > >>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by > >>>>> side) > >>>>> > >>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > >>>>> > >>>>> The AUTH48 status page is here: > >>>>> > >>>>> https://www.rfc-editor.org/auth48/rfc9892 > >>>>> > >>>>> Thank you! > >>>>> > >>>>> Lynne Bartholomew > >>>>> RFC Production Center > >>>>> > >>>>> > >>>>>> On Dec 2, 2025, at 1:26 PM, Lynne Bartholomew > >>>>>> <[email protected]> wrote: > >>>>>> > >>>>>> Hi, Jim. So noted: > >>>>>> > >>>>>> https://www.rfc-editor.org/auth48/rfc9892 > >>>>>> > >>>>>> Thank you! > >>>>>> > >>>>>> Lynne Bartholomew > >>>>>> RFC Production Center > >>>>>> > >>>>>> > >>>>>>> On Dec 2, 2025, at 9:07 AM, James Guichard > >>>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>> Update looks okay for me. Approved. > >>>>>>> > >>>>>>> Jim > >>>>>>> > >>>>>>> Get Outlook for iOS > >>>>>>> From: Lynne Bartholomew <[email protected]> > >>>>>>> Sent: Monday, December 1, 2025 3:18:51 PM > >>>>>>> To: Don Fedyk <[email protected]>; James Guichard > >>>>>>> <[email protected]> > >>>>>>> Cc: [email protected] <[email protected]>; Lou Berger > >>>>>>> <[email protected]>; [email protected] > >>>>>>> <[email protected]>; [email protected] <[email protected]>; > >>>>>>> [email protected] <[email protected]>; [email protected] > >>>>>>> <[email protected]>;[email protected] > >>>>>>> <[email protected]> > >>>>>>> Subject: *[AD] Re: AUTH48: RFC-to-be 9892 > >>>>>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review Hi, > >>>>>>> Don and *AD (Jim). > >>>>>>> > >>>>>>> * Jim, please review the updates to the "VLAN Identifier (VID):" > >>>>>>> paragraph in Section 2.3, and let us know if you approve. We ask for > >>>>>>> your approval because the updates could be considered "beyond > >>>>>>> editorial". > >>>>>>> > >>>>>>> > >>>>>>> Don, no worries, and we hope that you had a good holiday weekend. > >>>>>>> > >>>>>>> We have made further updates to this document per your notes below, > >>>>>>> but we still have one more question for you; apologies for missing > >>>>>>> this one earlier. Should the following be made consistent? > >>>>>>> > >>>>>>> across the Data Item and not the individual Sub-Data Item / > >>>>>>> across the Data Item and not the individual Sub-Data Items > >>>>>>> > >>>>>>> The latest files are posted here. Please refresh your browser: > >>>>>>> > >>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>>>>>> https://www.rfc-editor.org/authors/rfc9892.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side) > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side > >>>>>>> by side) > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastdiff.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by > >>>>>>> side) > >>>>>>> > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > >>>>>>> > >>>>>>> Thank you! > >>>>>>> > >>>>>>> Lynne Bartholomew > >>>>>>> RFC Production Center > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Dec 1, 2025, at 9:23 AM, Don Fedyk <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Hi Lynn > >>>>>>>> > >>>>>>>> Sorry for the delay, short work week last week. > >>>>>>>> > >>>>>>>> Inline [Don] > >>>>>>>> > >>>>>>>> Thank You, > >>>>>>>> Don > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> From: Lynne Bartholomew <[email protected]> > >>>>>>>> Sent: Monday, November 24, 2025 12:46 PM > >>>>>>>> To: Don Fedyk <[email protected]>; [email protected] > >>>>>>>> <[email protected]>; Lou Berger <[email protected]> > >>>>>>>> Cc: [email protected] <[email protected]>; > >>>>>>>> [email protected] <[email protected]>; > >>>>>>>> [email protected]<[email protected]>; > >>>>>>>> [email protected]<[email protected]>; > >>>>>>>> [email protected] > >>>>>>>> <[email protected]>;[email protected] > >>>>>>>> <[email protected]> > >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9892 > >>>>>>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review > >>>>>>>> > >>>>>>>> Hi, Don, Bow-Nan, and Lou. > >>>>>>>> > >>>>>>>> Don, thank you for your reply. > >>>>>>>> > >>>>>>>> Regarding this reply from you: We changed "the maximum Length for > >>>>>>>> the based on" to "the maximum Length based on". Please let us know > >>>>>>>> if some other words were missing that should be added. > >>>>>>>> > >>>>>>>> > >>>>>>>>> [Don] I believe - checking my math again that this length is on a > >>>>>>>>> per Traiffic Identifier basis. > >>>>>>>>> If every FID was mapped to an explicit DSCP the length would be > >>>>>>>>> (2+1+1) * 64 = 256. > >>>>>>>>> > >>>>>>>>> NEW "under DiffServ Traffic Classification Sub-Data Item" > >>>>>>>>> This > >>>>>>>>> means that the maximum Length for the based on a single DSCP per > >>>>>>>>> FID for this TLV > >>>>>>>>> could be 64 times two ( FID) plus one for (Num DSCPs) plus one > >>>>>>>>> octet for a single DSCP > >>>>>>>>> or 256 octets. > >>>>>>>>> > >>>>>>>>> " Think the error was using 3 instead of 2 and resulting in > >>>>>>>>> counting the Num DSCPs twice" > >>>>>>>>> > >>>>>>>> Regarding our question 18)b) and your reply: > >>>>>>>> > >>>>>>>> Which form is preferred for consistency in this document -- priority > >>>>>>>> field, Priority field, or Priority Field? > >>>>>>>> > >>>>>>>> [Don] Priority Field > >>>>>>>> > >>>>>>>> Same question for these two; which form is preferred? > >>>>>>>> > >>>>>>>> Item Types / Item types > >>>>>>>> > >>>>>>>> Item Types (used in RFC 8175) > >>>>>>>> > >>>>>>>> > >>>>>>>> Num PCPs (1 instance) / NumPCPs (4 instances) > >>>>>>>> > >>>>>>>> [Don] Ahh, Ascii Art limited us to NumPCPs I would use that > >>>>>>>> everywhere to make it consistent. > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> b) The following terms appear to be used inconsistently in this > >>>>>>>>>>>> document. Please let us know which form is preferred. > >>>>>>>>>>>> > >>>>>>>>>>>> priority field / Priority field / Priority Field > >>>>>>>>>>>> (e.g., "priority fields", "Priority fields", > >>>>>>>>>>>> "Each Priority Field is", "each Priority field is") > >>>>>>>>>>>> > >>>>>>>>>>>> Item Types / Item types (e.g., "Traffic Classification Sub-Data > >>>>>>>>>>>> Item > >>>>>>>>>>>> Types", "Traffic Classification Sub-Data Item types") > >>>>>>>>>>>> > >>>>>>>>>>>> Num PCPs (1 instance) / NumPCPs (4 instances) > >>>>>>>>>>>> (We also see "Num DSCPs" and "Num SDIs".) > >>>>>>>>>>>> the individual Sub-Data Item / the individual Sub-Data Items --> > >>>>>>>>>>>> > >>>>>>>>>> [Don] Good Thanks. > >>>>>>>>>> > >>>>>>>> = = = = = > >>>>>>>> > >>>>>>>> Would you like to make this update, mentioned by Donald Eastlake in > >>>>>>>> relation to RFC-to-be 9895? Please read his entire reply (i.e., that > >>>>>>>> nothing is wrong but that consistency might be good). > >>>>>>>> > >>>>>>>> [Don] The VID in this douement is 12bits. The largest it can be is > >>>>>>>> 0xFFE. Therefore the value of 0x000 would be the corresponing > >>>>>>>> representation but not used much. I don't see a problem with zero(0) > >>>>>>>> in this case but when I maeked up up I guess 0x000 is more > >>>>>>>> consistent.. As far as the reserved values those are inherited from > >>>>>>>> IEEE 802.1Q. > >>>>>>>> See mark up below. [Don] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Our question for Donald: > >>>>>>>> > >>>>>>>> > >>>>>>>>>> 2. In companion document RFC-to-be 9892, should we ask the authors > >>>>>>>>>> if the "zero (0)" in the following paragraph should be updated to > >>>>>>>>>> list the hex value 0x0000, as was done per your second update note > >>>>>>>>>> (further below) for this document? We ask because we see two > >>>>>>>>>> instances of "The value 0xFFFF is reserved" in RFC-to-be 9892: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> VLAN Identifier (VID): > >>>>>>>>>> A 12-bit unsigned integer field indicating the VLAN to be used in > >>>>>>>>>> traffic classification. A value of zero (0) indicates that the > >>>>>>>>>> VID is to be ignored and any VID is to be accepted during traffic > >>>>>>>>>> classification. Any explicitly mapped VLANs are matched first. > >>>>>>>>>> Any VLANs that do not have a mapping will then map to this default > >>>>>>>>>> mapping. > >>>>>>>>>> > >>>>>>>> Donald's reply: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Well, I don't think the two occurrences of 0xFFFF in this document > >>>>>>>>> have anything to do with this because they refer to the FID, not the > >>>>>>>>> VID. However, I think the full change to this text that I suggested > >>>>>>>>> for this (except the self-referential reference to 9892) would be > >>>>>>>>> good > >>>>>>>>> so > >>>>>>>>> > >>>>>>>>> OLD > >>>>>>>>> A value of zero (0) indicates that the > >>>>>>>>> VID is to be ignored and any VID is to be accepted during traffic > >>>>>>>>> classification. > >>>>>>>>> NEW > >>>>>>>>> VID value zero (0x0000) is used > >>>>>>>>> to indicate that the VID is ignored and VID 0xFFFF is > >>>>>>>>> reserved. Any other VID value from 0x0001 through 0xFFFE can be > >>>>>>>>> used in traffic classification. > >>>>>>>>> > >>>>>>>> [Don] > >>>>>>>> NEW > >>>>>>>> > >>>>>>>>> VID value zero (0x000) is used > >>>>>>>>> to indicate that the VID is ignored and VID 0xFFF is reserved. > >>>>>>>>> Any other VID value from 0x001 through 0xFFE can be > >>>>>>>>> used in traffic classification. > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Perhaps you should suggest the above to the authors. > >>>>>>>>> > >>>>>>>>> Actually, use of "(0)" is not wrong, it's just that it seems much > >>>>>>>>> more > >>>>>>>>> consistent for all the VIDs (VLAN IDs) to be given in the same hex > >>>>>>>>> format. > >>>>>>>>> > >>>>>>>> = = = = = > >>>>>>>> > >>>>>>>> The latest files are posted here. Please refresh your browser: > >>>>>>>> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side > >>>>>>>> by side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastdiff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > >>>>>>>> > >>>>>>>> Thanks again! > >>>>>>>> > >>>>>>>> Lynne Bartholomew > >>>>>>>> RFC Production Center > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Nov 20, 2025, at 4:03 PM, Don Fedyk <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>> Hi Lynn > >>>>>>>>> > >>>>>>>>> Thank you, sorry, some of those additions came about because of > >>>>>>>>> comments on how large the data items could. The important thing was > >>>>>>>>> to make sure the object was reasonably bouunded but I think I have > >>>>>>>>> corrected it below. > >>>>>>>>> > >>>>>>>>> Inline [Don] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: Lynne Bartholomew <[email protected]> > >>>>>>>>> Sent: Thursday, November 20, 2025 12:03 PM > >>>>>>>>> To: Don Fedyk <[email protected]> > >>>>>>>>> Cc: [email protected] <[email protected]>; > >>>>>>>>> [email protected] <[email protected]>; Lou Berger > >>>>>>>>> <[email protected]>; [email protected] <[email protected]>; > >>>>>>>>> [email protected] <[email protected]>; > >>>>>>>>> [email protected]<[email protected]>;[email protected]<[email protected]>; > >>>>>>>>> [email protected] <[email protected]> > >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9892 > >>>>>>>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review > >>>>>>>>> > >>>>>>>>> Hi, Don. Thank you for your prompt reply! > >>>>>>>>> > >>>>>>>>> We have updated this document per your notes below. > >>>>>>>>> > >>>>>>>>> We have a few follow-up items for you: > >>>>>>>>> > >>>>>>>>> * Apologies; in looking at our question 8) more closely, we see > >>>>>>>>> "maximum Length base on" and wonder if "base on" should be "based > >>>>>>>>> on". We also wonder if "Num DSCPs plus one DSCPs" should be "(Num > >>>>>>>>> DSCPs plus one)" (as in showing an addition). Should we update per > >>>>>>>>> our "Possibly" text, or could you provide a better way to write > >>>>>>>>> this sentence? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 8) <!-- [rfced] Section 2.2: Please clarify "one DSCPs". There > >>>>>>>>>>> appears > >>>>>>>>>>> to be a singular-versus-plural issue (i.e., perhaps either "one > >>>>>>>>>>> DSCP" > >>>>>>>>>>> or "one or more DSCPs" would be correct here). > >>>>>>>>>>> > >>>>>>>>>>> Original: > >>>>>>>>>>> This > >>>>>>>>>>> means that the maximum Length base on a FID per DSCP for this TLV > >>>>>>>>>>> could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320 > >>>>>>>>>>> octets. --> > >>>>>>>>>>> > >>>>>>>>>> [Don] Should be "one DSCP". > >>>>>>>>>> > >>>>>>>>> Currently: > >>>>>>>>> This > >>>>>>>>> means that the maximum Length base on a FID per DSCP for this TLV > >>>>>>>>> could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320 > >>>>>>>>> octets. > >>>>>>>>> > >>>>>>>>> Possibly: > >>>>>>>>> This > >>>>>>>>> means that the maximum Length based on a FID per DSCP for this TLV > >>>>>>>>> could be 64 times 3 plus one for (Num DSCPs plus one) octets, or 320 > >>>>>>>>> octets. > >>>>>>>>> > >>>>>>>>> [Don] I believe - checking my math again that this length is on a > >>>>>>>>> per Traiffic Identifier basis. > >>>>>>>>> If every FID was mapped to an explicit DSCP the length would be > >>>>>>>>> (2+1+1) * 64 = 256. > >>>>>>>>> > >>>>>>>>> NEW "under DiffServ Traffic Classification Sub-Data Item" > >>>>>>>>> This > >>>>>>>>> means that the maximum Length for the based on a single DSCP per > >>>>>>>>> FID for this TLV > >>>>>>>>> could be 64 times two ( FID) plus one for (Num DSCPs) plus one > >>>>>>>>> octet for a single DSCP > >>>>>>>>> or 256 octets. > >>>>>>>>> > >>>>>>>>> " Think the error was using 3 instead of 2 and resulting in > >>>>>>>>> counting the Num DSCPs twice" > >>>>>>>>> > >>>>>>>>> = = = = = > >>>>>>>>> > >>>>>>>>> * Regarding our question 11) and your reply: We updated per your > >>>>>>>>> note, except that > >>>>>>>>> we changed "number octets" to "number of octets". If this is > >>>>>>>>> incorrect, should > >>>>>>>>> "number octets" be clarified? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 11) <!-- [rfced] Section 2.3: We had trouble following these > >>>>>>>>>>> sentences. > >>>>>>>>>>> Does "the next higher integer quantity" refer to a higher integer > >>>>>>>>>>> quantity that comes next, or does it mean "the next-higher integer > >>>>>>>>>>> quantity" or "the next-highest integer quantity"? In the equation, > >>>>>>>>>>> does "divided by 2 or 16 octets" mean "divided by either 2 octets > >>>>>>>>>>> or > >>>>>>>>>>> 16 octets", or something else? > >>>>>>>>>>> > >>>>>>>>>>> Original: > >>>>>>>>>>> Note > >>>>>>>>>>> that as length is in octets and each Priority field is 4 bits, the > >>>>>>>>>>> additional length is the value carried in the NumPCPs field > >>>>>>>>>>> divided by two and rounded up to the next higher integer quantity. > >>>>>>>>>>> This TLV has maximum length of 4 plus 8 divided by 2 or 16 > >>>>>>>>>>> octets. --> > >>>>>>>>>>> > >>>>>>>>>> [Don] I think that is bad math. Sorry. > >>>>>>>>>> > >>>>>>>>>> NEW > >>>>>>>>>> that as length is in octets and each Priority field is 4 bits, the > >>>>>>>>>> total length of this Sub-Data Item is the 2 octets > >>>>>>>>>> of Flow Identifer, plus the 2 octets for NumPCPs and VLAN > >>>>>>>>>> Identifier > >>>>>>>>>> plus the number octets for Priority Code Points. The number of > >>>>>>>>>> octets for the PCPs is computed by rounding up the NumPCPs > >>>>>>>>>> to the nearest even value and dividing by 2. > >>>>>>>>>> This TLV has maximum length of 4 plus 8 divided by 2 or 8 octets. > >>>>>>>>>> > >>>>>>>>> Currently: > >>>>>>>>> Note > >>>>>>>>> that as the length is in octets and each Priority field is 4 bits, > >>>>>>>>> the total length of this Sub-Data Item is the 2 octets of Flow > >>>>>>>>> Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus > >>>>>>>>> the number of octets for PCPs. The number of octets for the PCPs > >>>>>>>>> is computed by rounding up NumPCPs to the nearest even value and > >>>>>>>>> dividing by 2. This TLV has maximum length of 4 plus 8 divided by > >>>>>>>>> 2 or 8 octets. > >>>>>>>>> > >>>>>>>>> [Don] Yes thanks. > >>>>>>>>> = = = = = > >>>>>>>>> > >>>>>>>>> * Regarding our question 15) and your reply: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 15) <!-- [rfced] Section 4: We had trouble following "some updated > >>>>>>>>>>> references to external documents listed below" in this paragraph. > >>>>>>>>>>> It appears that "external documents" is intended to refer to > >>>>>>>>>>> [BCP195], [IEEE-802.1AE], and [IEEE-8802-1X]. > >>>>>>>>>>> However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE > >>>>>>>>>>> Standards > >>>>>>>>>>> for Local and metropolitan area networks-Port-Based Network Access > >>>>>>>>>>> Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC > >>>>>>>>>>> International Standard-Telecommunications and exchange between > >>>>>>>>>>> information technology systems-Requirements for local and > >>>>>>>>>>> metropolitan area networks-Part 1X:Port-based network access > >>>>>>>>>>> control"). > >>>>>>>>>>> May we update as suggested? If not, please clarify the text. > >>>>>>>>>>> Original: > >>>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>>> with > >>>>>>>>>>> some updated references to external documents listed below, can be > >>>>>>>>>>> applied to this document. > >>>>>>>>>>> Suggested: > >>>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>>> along with the latest versions of [BCP195], [IEEE-802.1AE], and > >>>>>>>>>>> [IEEE-8802-1X] at the time of this writing, can be applied to this > >>>>>>>>>>> document. --> > >>>>>>>>>>> > >>>>>>>>>> [Don] Yes accepted Suggested but the IEEE-8802-1X is the ISO > >>>>>>>>>> version of IEEE-802.1X > >>>>>>>>>> https://ieeexplore.ieee.org/document/9650828 > >>>>>>>>>> > >>>>>>>>>> I think we should use the IEEE version change IEEE-8802-1X to > >>>>>>>>>> IEEE-802.1X. > >>>>>>>>>> > >>>>>>>>> [Don] The practice is IEEE publishes IEEE802.1X for example, then > >>>>>>>>> ISO republishes it so it is the same document mostly. > >>>>>>>>> However we usually refer to the IEEE base document and did that for > >>>>>>>>> IEEE 802.1Q. > >>>>>>>>> > >>>>>>>>> I thought pasted the corrected URL for Original IEEE spec but maybe > >>>>>>>>> I goofed. Here it is again. IEEE 802.1X-2020 > >>>>>>>>> https://ieeexplore.ieee.org/document/9018454 > >>>>>>>>> > >>>>>>>>> Apologies for our confusion: When we go to > >>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>, > >>>>>>>>> we see "8802-1X-2021 - IEEE/ISO/IEC International > >>>>>>>>> Standard-Telecommunications and exchange > >>>>>>>>> between information technology systems--Requirements for local and > >>>>>>>>> metropolitan area > >>>>>>>>> networks--Part 1X:Port-based network access control". > >>>>>>>>> Is <https://ieeexplore.ieee.org/document/9650828> the wrong URL? > >>>>>>>>> > >>>>>>>>> We changed the citation string per your note but would like to > >>>>>>>>> confirm that this update > >>>>>>>>> won't be confusing to readers. We also ask because RFC-to-be 9893 > >>>>>>>>> cites IEEE 8802-1X > >>>>>>>>> and uses the citation string "[IEEE-8802-1X]". > >>>>>>>>> > >>>>>>>>> Currently: > >>>>>>>>> [IEEE-802.1X] > >>>>>>>>> IEEE, "8802-1X-2021 - IEEE/ISO/IEC International Standard- > >>>>>>>>> Telecommunications and exchange between information > >>>>>>>>> technology systems--Requirements for local and > >>>>>>>>> metropolitan area networks--Part 1X:Port-based network > >>>>>>>>> access control", DOI 10.1109/IEEESTD.2021.9650828, IEEE > >>>>>>>>> Std IEEE-802.1X-2021, December 2021, > >>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>. > >>>>>>>>> [DON] use https://ieeexplore.ieee.org/document/9018454 > >>>>>>>>> = = = = = > >>>>>>>>> > >>>>>>>>> * Regarding our question 18)b) and your reply -- please let us know > >>>>>>>>> which form is > >>>>>>>>> preferred for the following three items: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> b) The following terms appear to be used inconsistently in this > >>>>>>>>>>> document. Please let us know which form is preferred. > >>>>>>>>>>> > >>>>>>>>>>> priority field / Priority field / Priority Field > >>>>>>>>>>> (e.g., "priority fields", "Priority fields", > >>>>>>>>>>> "Each Priority Field is", "each Priority field is") > >>>>>>>>>>> > >>>>>>>>>>> Item Types / Item types (e.g., "Traffic Classification Sub-Data > >>>>>>>>>>> Item > >>>>>>>>>>> Types", "Traffic Classification Sub-Data Item types") > >>>>>>>>>>> > >>>>>>>>>>> Num PCPs (1 instance) / NumPCPs (4 instances) > >>>>>>>>>>> (We also see "Num DSCPs" and "Num SDIs".) > >>>>>>>>>>> the individual Sub-Data Item / the individual Sub-Data Items --> > >>>>>>>>>>> > >>>>>>>>>> [Don] Good Thanks. > >>>>>>>>>> > >>>>>>>>> = = = = = > >>>>>>>>> > >>>>>>>>> The latest files are posted here. Please refresh your browser: > >>>>>>>>> > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by > >>>>>>>>> side) > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48diff.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html (side > >>>>>>>>> by side) > >>>>>>>>> > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html > >>>>>>>>> > >>>>>>>>> Thanks again! > >>>>>>>>> > >>>>>>>>> Lynne Bartholomew > >>>>>>>>> RFC Production Center > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On Nov 18, 2025, at 6:24 AM, Don Fedyk <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> Thanks My comments inline [Don]. Please let me know if anything is > >>>>>>>>>> not clear. > >>>>>>>>>> > >>>>>>>>>> Thank you > >>>>>>>>>> Don > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> From: [email protected] <[email protected]> > >>>>>>>>>> Sent: Friday, November 14, 2025 4:57 PM > >>>>>>>>>> To: [email protected] <[email protected]>; Lou Berger > >>>>>>>>>> <[email protected]>; Don Fedyk <[email protected]> > >>>>>>>>>> Cc: [email protected] <[email protected]>; > >>>>>>>>>> [email protected] <[email protected]>; > >>>>>>>>>> [email protected]<[email protected]>; > >>>>>>>>>> [email protected] <[email protected]>; > >>>>>>>>>> [email protected]<[email protected]>;[email protected] > >>>>>>>>>> <[email protected]> > >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9892 > >>>>>>>>>> <draft-ietf-manet-dlep-traffic-classification-17> for your review > >>>>>>>>>> > >>>>>>>>>> Authors, > >>>>>>>>>> > >>>>>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>>>>> necessary) the following questions, which are also in the source > >>>>>>>>>> file. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > >>>>>>>>>> appear in the > >>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>. --> > >>>>>>>>>> > >>>>>>>>>> Diffserv Code Points > >>>>>>>>>> Ethernet Priority Code Points. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2) <!-- [rfced] Section 1: We had trouble following the "and", > >>>>>>>>>> "or", and > >>>>>>>>>> "and/or" relationships in this sentence. If the suggested text is > >>>>>>>>>> not > >>>>>>>>>> correct, please clarify. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> The defined mechanism allows > >>>>>>>>>> for flows to be described in a flexible fashion and when combined > >>>>>>>>>> with applications such as credit window control, allows credit > >>>>>>>>>> windows to be shared across traffic sent to multiple DLEP > >>>>>>>>>> destinations and as part of multiple flows, or used exclusively for > >>>>>>>>>> traffic sent to a particular destination and/or belonging to a > >>>>>>>>>> particular flow. > >>>>>>>>>> > >>>>>>>>>> Suggested: > >>>>>>>>>> The defined mechanism allows > >>>>>>>>>> for flows to be described in a flexible fashion and, when combined > >>>>>>>>>> with applications such as credit window control, allows credit > >>>>>>>>>> windows to be (1) shared across traffic sent to multiple DLEP > >>>>>>>>>> destinations and as part of multiple flows or (2) used exclusively > >>>>>>>>>> for traffic sent to a particular destination and/or belonging to a > >>>>>>>>>> particular flow. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Ok. > >>>>>>>>>> > >>>>>>>>>> 3) <!-- [rfced] Section 2: Does "based on IP protocol and" (which > >>>>>>>>>> looks > >>>>>>>>>> like "based on Internet Protocol protocol and") mean "based on IP > >>>>>>>>>> protocol type and" or something else? > >>>>>>>>>> > >>>>>>>>>> [Don]The IP transport layer protocol. (Examples: TCP, UDP etc.) > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> Other types of flow identification, e.g., based on > >>>>>>>>>> IP protocol and ports, may be defined in the future via new > >>>>>>>>>> Sub-Data > >>>>>>>>>> Items. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Suggested: NEW > >>>>>>>>>> Other types of flow identification, e.g., based on > >>>>>>>>>> IP transport layer protocol and ports, may be defined in the > >>>>>>>>>> future via new Sub-Data > >>>>>>>>>> > >>>>>>>>>> 4) <!-- [rfced] Sections 2.1 and 2.1.1: We do not see a Type field > >>>>>>>>>> in > >>>>>>>>>> RFC 8175, but we see a "Data Item Type" field. May we update as > >>>>>>>>>> suggested (per Section 11.3 ("DLEP Generic Data Item") of RFC > >>>>>>>>>> 8175), > >>>>>>>>>> to distinguish this definition from the definitions of Length in > >>>>>>>>>> Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message > >>>>>>>>>> Header") > >>>>>>>>>> of RFC 8175, which do not mention excluding a "Type" field? > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> Per [RFC8175] Length is the number of octets in the Data Item, > >>>>>>>>>> excluding the Type and Length fields. > >>>>>>>>>> ... > >>>>>>>>>> Copying [RFC8175], Length is a 16-bit unsigned integer that is the > >>>>>>>>>> number of octets in the Sub-Data Item, excluding the Type and > >>>>>>>>>> Length fields. > >>>>>>>>>> > >>>>>>>>>> Suggested: > >>>>>>>>>> Per Section 11.3 of [RFC8175], Length is the number of octets in > >>>>>>>>>> the > >>>>>>>>>> Data Item, excluding the Data Item Type and Length fields. > >>>>>>>>>> ... > >>>>>>>>>> Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer > >>>>>>>>>> that is the number of octets in the Sub-Data Item, excluding the > >>>>>>>>>> Data Item Type and Length fields. --> > >>>>>>>>>> > >>>>>>>>>> [Don] > >>>>>>>>>> Yes Data Item Type vs Type. > >>>>>>>>>> > >>>>>>>>>> 5) <!-- [rfced] Section 2.1: For ease of the reader, we changed > >>>>>>>>>> "below" > >>>>>>>>>> to "in Section 2.1.1". If this is incorrect, please clarify what > >>>>>>>>>> "below" refers to. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> Traffic Classification Sub-Data Item: > >>>>>>>>>> Zero or more Traffic Classification Sub-Data Items of the format > >>>>>>>>>> defined below MAY be included. > >>>>>>>>>> > >>>>>>>>>> Currently: > >>>>>>>>>> Traffic Classification Sub-Data Item: > >>>>>>>>>> Zero or more Traffic Classification Sub-Data Items of the format > >>>>>>>>>> defined in Section 2.1.1 MAY be included. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Yes > >>>>>>>>>> > >>>>>>>>>> 6) <!-- [rfced] Section 2.1.1: We had trouble following the > >>>>>>>>>> meaning of > >>>>>>>>>> "on a per Sub-Data Item Type". Are some words missing? > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> The maximum length is limited on a per Sub-Data > >>>>>>>>>> Item Type. --> > >>>>>>>>>> > >>>>>>>>>> [Don] NEW > >>>>>>>>>> Each Sub-Data Item has its own length field. > >>>>>>>>>> > >>>>>>>>>> This is all that is needed. Each Sub-Data Item is subject > >>>>>>>>>> to the maximum length of encompassing the Data Item. > >>>>>>>>>> > >>>>>>>>>> 7) <!-- [rfced] Section 2.1.1: We see that the Value field is > >>>>>>>>>> mentioned > >>>>>>>>>> under "Sub-Data Item Type:" but is not otherwise defined. Would you > >>>>>>>>>> like to add a list item and explanation of the Value field? > >>>>>>>>>> > >>>>>>>>>> For example, Section 11.3 of RFC 8175 provides this definition of > >>>>>>>>>> the > >>>>>>>>>> Value field: > >>>>>>>>>> > >>>>>>>>>> Value: A field of <Length> octets that contains data specific to a > >>>>>>>>>> particular Data Item. > >>>>>>>>>> > >>>>>>>>>> [Don] Value is the same as defined in RFC 8175. > >>>>>>>>>> Repeating this definition is fine. Value is only used for the > >>>>>>>>>> general format. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> ~ Value... ~ > >>>>>>>>>> ... > >>>>>>>>>> Sub-Data Item Type: > >>>>>>>>>> A 16-bit unsigned integer that indicates the type and > >>>>>>>>>> corresponding format of the Sub-Data Item's Value field. ... --> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 8) <!-- [rfced] Section 2.2: Please clarify "one DSCPs". There > >>>>>>>>>> appears > >>>>>>>>>> to be a singular-versus-plural issue (i.e., perhaps either "one > >>>>>>>>>> DSCP" > >>>>>>>>>> or "one or more DSCPs" would be correct here). > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> This > >>>>>>>>>> means that the maximum Length base on a FID per DSCP for this TLV > >>>>>>>>>> could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320 > >>>>>>>>>> octets. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Should be "one DSCP". > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 9) <!-- [rfced] Section 2.2: Please confirm that there is no IANA > >>>>>>>>>> registration > >>>>>>>>>> associated with the value "0xFFFF" in this sentence. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> The value of 0xFFFF is reserved and MUST NOT be used in > >>>>>>>>>> this field. > >>>>>>>>>> --> > >>>>>>>>>> [Don] Correct this is just a reserved Flow Identifier. No IANA > >>>>>>>>>> registration. > >>>>>>>>>> > >>>>>>>>>> 10) <!-- [rfced] Section 2.2: We changed "is an 8-bit that > >>>>>>>>>> carries" to > >>>>>>>>>> "is 8 bits long and carries". If this update is incorrect, please > >>>>>>>>>> clarify the meaning of "an 8-bit that carries". > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> DS Field: > >>>>>>>>>> Each DS Field is an 8-bit that carries the DSCP field defined in > >>>>>>>>>> [RFC2474]. > >>>>>>>>>> > >>>>>>>>>> Currently: > >>>>>>>>>> DS Field: > >>>>>>>>>> Each DS Field is 8 bits long and carries the DSCP field as > >>>>>>>>>> defined in [RFC2474]. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Good "8 bits long" is better > >>>>>>>>>> r > >>>>>>>>>> 11) <!-- [rfced] Section 2.3: We had trouble following these > >>>>>>>>>> sentences. > >>>>>>>>>> Does "the next higher integer quantity" refer to a higher integer > >>>>>>>>>> quantity that comes next, or does it mean "the next-higher integer > >>>>>>>>>> quantity" or "the next-highest integer quantity"? In the equation, > >>>>>>>>>> does "divided by 2 or 16 octets" mean "divided by either 2 octets > >>>>>>>>>> or > >>>>>>>>>> 16 octets", or something else? > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> Note > >>>>>>>>>> that as length is in octets and each Priority field is 4 bits, the > >>>>>>>>>> additional length is the value carried in the NumPCPs field > >>>>>>>>>> divided by two and rounded up to the next higher integer quantity. > >>>>>>>>>> This TLV has maximum length of 4 plus 8 divided by 2 or 16 octets. > >>>>>>>>>> --> > >>>>>>>>>> > >>>>>>>>>> [Don] I think that is bad math. Sorry. > >>>>>>>>>> > >>>>>>>>>> NEW > >>>>>>>>>> that as length is in octets and each Priority field is 4 bits, the > >>>>>>>>>> total length of this Sub-Data Item is the 2 octets > >>>>>>>>>> of Flow Identifer, plus the 2 octets for NumPCPs and VLAN > >>>>>>>>>> Identifier > >>>>>>>>>> plus the number octets for Priority Code Points. The number of > >>>>>>>>>> octets for the PCPs is computed by rounding up the NumPCPs > >>>>>>>>>> to the nearest even value and dividing by 2. > >>>>>>>>>> This TLV has maximum length of 4 plus 8 divided by 2 or 8 octets. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 12) <!-- [rfced] Section 2.3: We changed "The maximum number of > >>>>>>>>>> PCPs 8" > >>>>>>>>>> to "The maximum number of PCPs is 8". If this is incorrect, please > >>>>>>>>>> clarify the text. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> The maximum number of PCPs 8. > >>>>>>>>>> > >>>>>>>>>> Currently: > >>>>>>>>>> The maximum number of PCPs is 8. --> > >>>>>>>>>> [Don] This is correct. > >>>>>>>>>> > >>>>>>>>>> 13) <!-- [rfced] Section 2.3: Is "either PCP" correct here? > >>>>>>>>>> Earlier text indicates > >>>>>>>>>> that there can be up to 8 PCPs. > >>>>>>>>>> > >>>>>>>>>> Original: > >>>>>>>>>> Note that zero (0) is a valid value for either PCP. > >>>>>>>>>> > >>>>>>>>>> Perhaps: > >>>>>>>>>> Note that zero (0) is a valid value for PCP. > >>>>>>>>>> > >>>>>>>>>> [Don] This is correct removing either. > >>>>>>>>>> > >>>>>>>>>> 14) <!-- [rfced] We found the following two comments in the XML > >>>>>>>>>> file. > >>>>>>>>>> May we remove them? > >>>>>>>>>> First comment: > >>>>>>>>>> Both the router and the modem need to support this document, > >>>>>>>>>> DLEP Traffic Classification, and DLEP Credit Flow Control, > >>>>>>>>>> <xref target="I-D.ietf-manet-dlep-credit-flow-control" > >>>>>>>>>> format="default"/>. > >>>>>>>>>> Second comment: > >>>>>>>>>> This document requests the assignment of several values by IANA. > >>>>>>>>>> All > >>>>>>>>>> assignments are to registries defined by <xref target="RFC8175" > >>>>>>>>>> format="default"/>. --> > >>>>>>>>>> [Don] Yes please remove. > >>>>>>>>>> > >>>>>>>>>> 15) <!-- [rfced] Section 4: We had trouble following "some updated > >>>>>>>>>> references to external documents listed below" in this paragraph. > >>>>>>>>>> It appears that "external documents" is intended to refer to > >>>>>>>>>> [BCP195], [IEEE-802.1AE], and [IEEE-8802-1X]. > >>>>>>>>>> However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE Standards > >>>>>>>>>> for Local and metropolitan area networks-Port-Based Network Access > >>>>>>>>>> Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC > >>>>>>>>>> International Standard-Telecommunications and exchange between > >>>>>>>>>> information technology systems-Requirements for local and > >>>>>>>>>> metropolitan area networks-Part 1X:Port-based network access > >>>>>>>>>> control"). > >>>>>>>>>> May we update as suggested? If not, please clarify the text. > >>>>>>>>>> Original: > >>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>> with > >>>>>>>>>> some updated references to external documents listed below, can be > >>>>>>>>>> applied to this document. > >>>>>>>>>> Suggested: > >>>>>>>>>> The transport layer security mechanisms documented in [RFC8175], > >>>>>>>>>> along with the latest versions of [BCP195], [IEEE-802.1AE], and > >>>>>>>>>> [IEEE-8802-1X] at the time of this writing, can be applied to this > >>>>>>>>>> document. --> > >>>>>>>>>> > >>>>>>>>>> [Don] Yes accepted Suggested but the IEEE-8802-1X is the ISO > >>>>>>>>>> version of IEEE-802.1X > >>>>>>>>>> https://ieeexplore.ieee.org/document/9650828 > >>>>>>>>>> > >>>>>>>>>> I think we should use the IEEE version change IEEE-8802-1X to > >>>>>>>>>> IEEE-802.1X. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 16) <!-- [rfced] Below are some specific questions relating to > >>>>>>>>>> IANA text in > >>>>>>>>>> Section 5.2 of the document. > >>>>>>>>>> a) FYI - To improve clarity, we added a new table (current Table > >>>>>>>>>> 2) to show > >>>>>>>>>> the registration policies and adjusted the original table (current > >>>>>>>>>> Table 3) to > >>>>>>>>>> show only the initial contents of the registry. > >>>>>>>>>> [Don] Good. > >>>>>>>>>> b) In the current Table 3, which shows the initial values of the > >>>>>>>>>> new registry, > >>>>>>>>>> [RFC2474] and [IEEE8021Q] are listed as references. Should this > >>>>>>>>>> document be > >>>>>>>>>> listed as a reference instead of or in addition to [RFC2474] and > >>>>>>>>>> [IEEE8021Q]? > >>>>>>>>>> It seems that this document defines the Diffserv Traffic > >>>>>>>>>> Classification in > >>>>>>>>>> Section 2.2 and the Ethernet Traffic Classification in Section > >>>>>>>>>> 2.3. Please > >>>>>>>>>> review and let us know if any updates are needed. If needed, we > >>>>>>>>>> will ask IANA > >>>>>>>>>> to update the "Traffic Classification Sub-Data Item Type Values" > >>>>>>>>>> registry > >>>>>>>>>> prior to publication. > >>>>>>>>>> [Don] The table referencing [RFC2474] and [IEEE8021Q] is correct > >>>>>>>>>> for Type code 1 and Type code 2 respectively. > >>>>>>>>>> No need to add this document as reference - it is there for the > >>>>>>>>>> whole table. > >>>>>>>>>> > >>>>>>>>>> Link to registry: > >>>>>>>>>> https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values> > >>>>>>>>>> c) Related to the question above, the first two sentences below do > >>>>>>>>>> not > >>>>>>>>>> directly indicate that this document defines the two new Sub-Data > >>>>>>>>>> Items in > >>>>>>>>>> Sections 2.2 and 2.3, but the third sentence does. Should any of > >>>>>>>>>> these > >>>>>>>>>> sentences be updated? > >>>>>>>>>> Original: > >>>>>>>>>> This document also introduces DLEP Sub-Data Items, and Sub-Data > >>>>>>>>>> Items are > >>>>>>>>>> defined to support DiffServ and Ethernet traffic classification. > >>>>>>>>>> ... > >>>>>>>>>> This document defines support for traffic classification using a > >>>>>>>>>> single new Data Item in Section 2.1 for general support and two new > >>>>>>>>>> Sub-Data Items are defined to support identification of flows based > >>>>>>>>>> on DSCPs and PCPs. > >>>>>>>>>> [Don] This is good. > >>>>>>>>>> ... > >>>>>>>>>> This document defines traffic classification based on a DLEP > >>>>>>>>>> destination and flows identified by either DiffServ [RFC2475] > >>>>>>>>>> Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q > >>>>>>>>>> [IEEE8021Q] > >>>>>>>>>> Ethernet Priority Code Points (PCPs). > >>>>>>>>>> Perhaps (updates to first two sentences to indicate that this > >>>>>>>>>> document defines > >>>>>>>>>> the two Sub-Data Items; not changes to third sentence): > >>>>>>>>>> This document also introduces DLEP Sub-Data Items and defines two > >>>>>>>>>> new > >>>>>>>>>> Sub-Data Items to support Diffserv and Ethernet traffic > >>>>>>>>>> classification. > >>>>>>>>>> ... > >>>>>>>>>> This document defines support for traffic classification using a > >>>>>>>>>> single new Data Item (see Section 2.1) for general support and > >>>>>>>>>> defines two new > >>>>>>>>>> Sub-Data Items to support identification of flows based > >>>>>>>>>> on DSCPs and PCPs (see Sections 2.2 and 2.3). > >>>>>>>>>> [Don] This is good. > >>>>>>>>>> ... > >>>>>>>>>> This document defines traffic classification based on a DLEP > >>>>>>>>>> destination and flows identified by either Diffserv [RFC2475] > >>>>>>>>>> Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q > >>>>>>>>>> [IEEE8021Q] > >>>>>>>>>> Ethernet Priority Code Points (PCPs). > >>>>>>>>>> d) May we combine the first paragraph after the current Table 3 > >>>>>>>>>> and the last > >>>>>>>>>> paragraph of Section 5.2 as follows? Also, would it be helpful to > >>>>>>>>>> separate the > >>>>>>>>>> text after the current Table 3 into a new section so future > >>>>>>>>>> documents can > >>>>>>>>>> easily refer to the guidance? Last, we suggest including > >>>>>>>>>> "Specification Required" > >>>>>>>>>> in this text as the guidance only applies to registrations with > >>>>>>>>>> that policy. > >>>>>>>>>> Original: > >>>>>>>>>> This section provides guidance to the Internet Assigned Numbers > >>>>>>>>>> Authority (IANA) regarding registration of values related to the > >>>>>>>>>> Traffic Classification Sub-Data Item Type Values registry for the > >>>>>>>>>> DLEP protocol, in accordance with BCP 26 and [RFC8126]. > >>>>>>>>>> ... > >>>>>>>>>> To simplify future registrations, it is recommended that this > >>>>>>>>>> guidance serves as a standard reference for all DLEP-related > >>>>>>>>>> registries. Future specifications may include a header note > >>>>>>>>>> pointing > >>>>>>>>>> to this guidance document. > >>>>>>>>>> Perhaps: > >>>>>>>>>> 5.3. Registration Guidance > >>>>>>>>>> This section provides guidance for registrations in the "Traffic > >>>>>>>>>> Classification Sub-Data Item Type Values" registry. To simplify > >>>>>>>>>> future > >>>>>>>>>> registrations in DLEP-related registries, it is recommended that > >>>>>>>>>> the > >>>>>>>>>> guidance in this section apply to all registries within the > >>>>>>>>>> "Dynamic Link > >>>>>>>>>> Exchange Protocol (DLEP) Parameters" registry group that use the > >>>>>>>>>> "Specification Required" policy [RFC8126]. Future specifications > >>>>>>>>>> may point to the guidance in this document. > >>>>>>>>>> [Don] This update is good. > >>>>>>>>>> > >>>>>>>>>> e) Please clarify "two specific registries" here. Is the intent > >>>>>>>>>> "two specific > >>>>>>>>>> entries" (i.e., 1 for Diffserv Traffic Classification and 2 for > >>>>>>>>>> Ethernet > >>>>>>>>>> Traffic Classification)? > >>>>>>>>>> Original (the previous sentence included for context): > >>>>>>>>>> This registry encompasses packet traffic classification, where > >>>>>>>>>> standard packet header identifiers in packets or data frames > >>>>>>>>>> indicate > >>>>>>>>>> Quality of Service (QoS) treatment. It includes two specific > >>>>>>>>>> registries for widely recognized identifiers used in QoS management > >>>>>>>>>> for IP and Ethernet networks. > >>>>>>>>>> Perhaps: > >>>>>>>>>> This registry encompasses packet traffic classification, where > >>>>>>>>>> standard packet header identifiers in packets or data frames > >>>>>>>>>> indicate > >>>>>>>>>> Quality of Service (QoS) treatment. It includes two specific > >>>>>>>>>> entries for widely recognized identifiers used in QoS management > >>>>>>>>>> for IP and Ethernet networks. > >>>>>>>>>> [Don] This is good. > >>>>>>>>>> --> > >>>>>>>>>> 17) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>>>>>>>> the > >>>>>>>>>> online Style Guide at > >>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, > >>>>>>>>>> and let us know if any changes are needed. Updates of this nature > >>>>>>>>>> typically result in more precise language, which is helpful for > >>>>>>>>>> readers. > >>>>>>>>>> Note that our script did not flag any words in particular, but this > >>>>>>>>>> should still be reviewed as a best practice. --> > >>>>>>>>>> 18) <!-- [rfced] Please let us know if any changes are needed for > >>>>>>>>>> the > >>>>>>>>>> following: > >>>>>>>>>> a) The following term was used inconsistently in this document. > >>>>>>>>>> We chose to use the latter form. Please let us know any objections. > >>>>>>>>>> data item (1 instance) / Data Item (e.g., "the data item", > >>>>>>>>>> "the Data Item") (per the rest of this document and per this > >>>>>>>>>> group (cluster) of documents) > >>>>>>>>>> [Don] Good thanks. > >>>>>>>>>> b) The following terms appear to be used inconsistently in this > >>>>>>>>>> document. Please let us know which form is preferred. > >>>>>>>>>> priority field / Priority field / Priority Field > >>>>>>>>>> (e.g., "priority fields", "Priority fields", > >>>>>>>>>> "Each Priority Field is", "each Priority field is") > >>>>>>>>>> Item Types / Item types (e.g., "Traffic Classification Sub-Data > >>>>>>>>>> Item > >>>>>>>>>> Types", "Traffic Classification Sub-Data Item types") > >>>>>>>>>> Num PCPs (1 instance) / NumPCPs (4 instances) > >>>>>>>>>> (We also see "Num DSCPs" and "Num SDIs".) > >>>>>>>>>> the individual Sub-Data Item / the individual Sub-Data Items --> > >>>>>>>>>> [Don] Good Thanks. > >>>>>>>>>> > >>>>>>>>>> Thank you. > >>>>>>>>>> Lynne Bartholomew and Rebecca VanRheenen > >>>>>>>>>> RFC Production Center > >>>>>>>>>> On Nov 14, 2025, at 1:54 PM, [email protected] wrote: > >>>>>>>>>> *****IMPORTANT***** > >>>>>>>>>> Updated 2025/11/14 > >>>>>>>>>> RFC Author(s): > >>>>>>>>>> -------------- > >>>>>>>>>> Instructions for Completing AUTH48 > >>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>>>>>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>>>>>>> If an author is no longer available, there are several remedies > >>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>>>>>>>> You and you coauthors are responsible for engaging other parties > >>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing > >>>>>>>>>> your approval. > >>>>>>>>>> Planning your review > >>>>>>>>>> --------------------- > >>>>>>>>>> Please review the following aspects of your document: > >>>>>>>>>> * RFC Editor questions > >>>>>>>>>> Please review and resolve any questions raised by the RFC Editor > >>>>>>>>>> that have been included in the XML file as comments marked as > >>>>>>>>>> follows: > >>>>>>>>>> <!-- [rfced] ... --> > >>>>>>>>>> These questions will also be sent in a subsequent email. > >>>>>>>>>> * Changes submitted by coauthors > >>>>>>>>>> Please ensure that you review any changes submitted by your > >>>>>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>>>>> agree to changes submitted by your coauthors. > >>>>>>>>>> * Content > >>>>>>>>>> Please review the full content of the document, as this cannot > >>>>>>>>>> change once the RFC is published. Please pay particular attention > >>>>>>>>>> to: > >>>>>>>>>> - IANA considerations updates (if applicable) > >>>>>>>>>> - contact information > >>>>>>>>>> - references > >>>>>>>>>> * Copyright notices and legends > >>>>>>>>>> Please review the copyright notice and legends as defined in > >>>>>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>>>>> (TLP – https://trustee.ietf.org/license-info). > >>>>>>>>>> * Semantic markup > >>>>>>>>>> Please review the markup in the XML file to ensure that elements of > >>>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>>>>>>>> and <artwork> are set correctly. See details at > >>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>>>>>>>> * Formatted output > >>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>>>>> formatted output, as generated from the markup in the XML file, is > >>>>>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>>>>> limitations compared to the PDF and HTML. > >>>>>>>>>> Submitting changes > >>>>>>>>>> ------------------ > >>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>>>>>>>>> all > >>>>>>>>>> the parties CCed on this message need to see your changes. The > >>>>>>>>>> parties > >>>>>>>>>> include: > >>>>>>>>>> * your coauthors > >>>>>>>>>> * [email protected] (the RPC team) > >>>>>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>>>>> responsible ADs, and the document shepherd). > >>>>>>>>>> * [email protected], which is a new archival mailing > >>>>>>>>>> list > >>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>>>>> list: > >>>>>>>>>> * More info: > >>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>>>>>>>> * The archive itself: > >>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>>>>>>>> If needed, please add a note at the top of the message that you > >>>>>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>>>>> [email protected] will be re-added to the CC list and > >>>>>>>>>> its addition will be noted at the top of the message. > >>>>>>>>>> You may submit your changes in one of two ways: > >>>>>>>>>> An update to the provided XML file > >>>>>>>>>> — OR — > >>>>>>>>>> An explicit list of changes in this format > >>>>>>>>>> Section # (or indicate Global) > >>>>>>>>>> OLD: > >>>>>>>>>> old text > >>>>>>>>>> NEW: > >>>>>>>>>> new text > >>>>>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>>>>> explicit > >>>>>>>>>> list of changes, as either form is sufficient. > >>>>>>>>>> We will ask a stream manager to review and approve any changes > >>>>>>>>>> that seem > >>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion > >>>>>>>>>> of text, > >>>>>>>>>> and technical changes. Information about stream managers can be > >>>>>>>>>> found in > >>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream > >>>>>>>>>> manager. > >>>>>>>>>> Approving for publication > >>>>>>>>>> -------------------------- > >>>>>>>>>> To approve your RFC for publication, please reply to this email > >>>>>>>>>> stating > >>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>>>>>>>> as all the parties CCed on this message need to see your approval. > >>>>>>>>>> Files > >>>>>>>>>> ----- > >>>>>>>>>> The files are available here: > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt > >>>>>>>>>> Diff file of the text: > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by > >>>>>>>>>> side) > >>>>>>>>>> Diff of the XML: > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html > >>>>>>>>>> Tracking progress > >>>>>>>>>> ----------------- > >>>>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9892 > >>>>>>>>>> Please let us know if you have any questions. > >>>>>>>>>> Thank you for your cooperation, > >>>>>>>>>> RFC Editor > >>>>>>>>>> -------------------------------------- > >>>>>>>>>> RFC9892 (draft-ietf-manet-dlep-traffic-classification-17) > >>>>>>>>>> Title : Dynamic Link Exchange Protocol (DLEP) Traffic > >>>>>>>>>> Classification Data Item > >>>>>>>>>> Author(s) : B. Cheng, D. Wiggins, L. Berger, D. Fedyk, Ed. > >>>>>>>>>> WG Chair(s) : Don Fedyk, Ronald in 't Velt, Donald E. Eastlake 3rd > >>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >>>>>>>>>> Velde > >>>>>>>>>> > >>>>>>> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
