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]
