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