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