Thanks everyone! This has been a long time coming!
On 1/20/26, 12:43 PM, "Lynne Bartholomew" <[email protected] <mailto:[email protected]>> wrote: !-------------------------------------------------------------------| This Message Is From an External Sender This message came from outside the Laboratory. |-------------------------------------------------------------------! Hi, Bow-Nan. We have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9892 <https://www.rfc-editor.org/auth48/rfc9892> As we now have all approvals, we will prepare this document, along with RFCs 9893, 9894, and 9895, for publication shortly. Thank you! Lynne Bartholomew RFC Production Center > On Jan 20, 2026, at 9:36 AM, Cheng, Bow-Nan - 0662 - MITLL <[email protected] > <mailto:[email protected]>> wrote: > > Lynne, > > My apologies again for the delay -- I'm good to go with it thanks! > > On 1/20/26, 12:30 PM, "Lynne Bartholomew" <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside the Laboratory. > |-------------------------------------------------------------------! > > > Hello. Checking in with you regarding the status of this document. Please > advise. > > > Thank you! > > > Lynne Bartholomew > RFC Production Center > > >> On Jan 12, 2026, at 10:47 AM, Lynne Bartholomew >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> >> Thank you, Don! >> >>> On Jan 12, 2026, at 10:35 AM, Don Fedyk <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>> >>> I will check with Lou if there is another way to contact Bow-Nan. >>> >>> Don From: Lynne Bartholomew <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> Sent: Monday, January 12, 2026 1:33 PM >>> To: James Guichard <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> Cc: [email protected] <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; Don Fedyk >>> <[email protected] <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>; Lou Berger <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>; [email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>; [email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>><[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[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/rfc9892> >>> <https://www.rfc-editor.org/auth48/rfc9892> >>> <https://www.rfc-editor.org/auth48/rfc9892>> >>> https://www.rfc-editor.org/auth48/rfc9893 >>> <https://www.rfc-editor.org/auth48/rfc9893> >>> <https://www.rfc-editor.org/auth48/rfc9893> >>> <https://www.rfc-editor.org/auth48/rfc9893>> >>> https://www.rfc-editor.org/auth48/rfc9894 >>> <https://www.rfc-editor.org/auth48/rfc9894> >>> <https://www.rfc-editor.org/auth48/rfc9894> >>> <https://www.rfc-editor.org/auth48/rfc9894>> >>> https://www.rfc-editor.org/auth48/rfc9895 >>> <https://www.rfc-editor.org/auth48/rfc9895> >>> <https://www.rfc-editor.org/auth48/rfc9895> >>> <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] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> <mailto:[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.txt> >>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>> https://www.rfc-editor.org/authors/rfc9892.html >>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>>>> <mailto:[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 >>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>> <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.txt> >>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>> wrote: >>>>>> >>>>>> Hi Lynne >>>>>> >>>>>> Thanks for all your work, The document looks good to me, >>>>>> >>>>>> DonFrom: Lynne Bartholomew <[email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[email protected]>>> >>>>>> Sent: Tuesday, December 16, 2025 11:43 AM >>>>>> To: Don Fedyk <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>> Cc: Lou Berger <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>>>; James Guichard >>>>>> <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>> <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>> <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>> <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>> <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>> <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>>; [email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[email protected]>><[email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[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.txt> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> Hi Lynn >>>>>>> Inline [Don] >>>>>>> >>>>>>> Thanks, >>>>>>> DonFrom: Lynne Bartholomew <[email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>> >>>>>>> Sent: Monday, December 15, 2025 1:34 PM >>>>>>> To: Don Fedyk <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> Cc: Lou Berger <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; James Guichard >>>>>>> <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[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] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[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 >>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>> <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] >>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>> <mailto:[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.txt> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>> <mailto:[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] >>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> I believe I see an error in >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt >>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>> <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.txt> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html>> >>>>>>>>>>>> >>>>>>>>>>>> The AUTH48 status page is here: >>>>>>>>>>>> >>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9892 >>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>> <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] >>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, Jim. So noted: >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9892 >>>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>>> <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] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Update looks okay for me. Approved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> Get Outlook for iOS >>>>>>>>>>>>>> From: Lynne Bartholomew <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>> >>>>>>>>>>>>>> Sent: Monday, December 1, 2025 3:18:51 PM >>>>>>>>>>>>>> To: Don Fedyk <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; James >>>>>>>>>>>>>> Guichard <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>> >>>>>>>>>>>>>> Cc: [email protected] <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; Lou >>>>>>>>>>>>>> Berger <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; >>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>>>;[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>> <mailto:[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.txt> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Lynn >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for the delay, short work week last week. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Inline [Don] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank You, >>>>>>>>>>>>>>> Don >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Lynne Bartholomew <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>> >>>>>>>>>>>>>>> Sent: Monday, November 24, 2025 12:46 PM >>>>>>>>>>>>>>> To: Don Fedyk <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; >>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; Lou >>>>>>>>>>>>>>> Berger <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>>>>>> Cc: [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>>;[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[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.txt> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-lastdiff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastdiff.html>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-lastrfcdiff.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-xmldiff1.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[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] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>> >>>>>>>>>>>>>>>> Sent: Thursday, November 20, 2025 12:03 PM >>>>>>>>>>>>>>>> To: Don Fedyk <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>>>>>>> Cc: [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; Lou Berger <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>;[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>> <mailto:[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 >>>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828> >>>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828> >>>>>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9018454> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9018454> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9018454>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apologies for our confusion: When we go to >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828&gt;>>, >>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828&gt;>> 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> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828>> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828&gt;>>. >>>>>>>>>>>>>>>> [DON] use https://ieeexplore.ieee.org/document/9018454 >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9018454> >>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9018454> >>>>>>>>>>>>>>>> <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.txt> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.xml >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-diff.html >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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-auth48diff.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48diff.html>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.html> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-auth48rfcdiff.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-xmldiff1.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html>> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.html> >>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff2.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] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks My comments inline [Don]. Please let me know if >>>>>>>>>>>>>>>>> anything is not clear. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>> Don >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>> >>>>>>>>>>>>>>>>> Sent: Friday, November 14, 2025 4:57 PM >>>>>>>>>>>>>>>>> To: [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; Lou >>>>>>>>>>>>>>>>> Berger <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>; Don >>>>>>>>>>>>>>>>> Fedyk <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>>>>>>>> Cc: [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>>; [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>><[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>>;[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[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> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/search>> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/search>> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/search&gt;>>. --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828> >>>>>>>>>>>>>>>>> <https://ieeexplore.ieee.org/document/9650828> >>>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values&gt;>> >>>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>>, >>>>>>>>>>>>>>>>> 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] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[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/ >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/faq/> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/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 >>>>>>>>>>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>>>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>>. >>>>>>>>>>>>>>>>> * 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] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[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] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>> >>>>>>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/> >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/> >>>>>>>>>>>>>>>>> <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] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[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.xml> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.xml>> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.html >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.html>> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.pdf >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.pdf>> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892.txt >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892.txt> >>>>>>>>>>>>>>>>> <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-diff.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-diff.html>> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-rfcdiff.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 >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html> >>>>>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9892> >>>>>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>> >>>>> >>>> >> > > > >
smime.p7s
Description: S/MIME cryptographic signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
