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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548256054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=09DDAgF%2FxfvuvrNfBn3dYVuJrjuzfs4vOx07TXQrmfQ%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548314669%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4ghjUSpbeBNUTtpMVQpxueTVSCyrXEh1toAwCBzXGJk%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548336925%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xWCmNUGVgRrhZzwGc65%2Fzq1qyCrmZTMsZRoNFrS1F9A%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548379329%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nTnAEXo1Ex%2Be8zeQDVqlJhQpFVMny8DekDh7o4pxf8g%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548432509%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hvp2hnggmPpy3EPldSChPlzeYtet6iXYy%2Bx7AQiMTK4%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548456131%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6crfrepNix%2BApvKH0C5MBukZvmCnD5iNTNQ09wpCpkA%3D&reserved=0 >> (side by side) >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548477246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g96I7lIbQIyR3n71hou5IEjpOqM9xLcZ5Xa%2BJHJ6ANI%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548499085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=95xwQxekRwGztuUArVKApKCMrHJI1UjmCq6LxvG3VVc%3D&reserved=0 >> (side by side) >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-lastdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548528450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SpuYd%2BA2J0ptor9998xzw1ZDgv9GBNDqi45c867VJQo%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-lastrfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548548631%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UEM%2BRE1RxdHWOCEcaKiIk%2Bf%2FE9A4d4fU%2FkmsZ2WVeu0%3D&reserved=0 >> (side by side) >> >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548568298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z1bXwygNZMVG6xlOPx1zai0KaPjxOMtbnJ%2F4D6flo4Y%3D&reserved=0 >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff2.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548588875%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CtHyFqbKzOXd9fq%2F8C%2BQJxHFkarzfmdDSpBvd1AmZEg%3D&reserved=0 >> >> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548608268%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vjpPShdcPWcZJj%2FCiamsFVxu90rVZOFJ%2BiaFm4M6dEg%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548627827%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xl9xIIoZ1SDapTWkmTSt2s2%2BpP6zHaq%2FVegXQ4djVqw%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548648851%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YqSm5hnsDhLDJ4A3916kALbZehBrKLP3hapj9m53k2g%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548672549%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PHDp1eAznhxZAPbj7l6TxPweMcbJXRzHvAGDUBiG5eg%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548698031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pDIweKxhX%2FlIok2p8OXtq9wUdG2pGmG1hxbzqNmT6Mw%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548718694%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2UVOVOrRLxkOJRMmwPsNF2uzIwrOyUL7e6lomSG%2B9pI%3D&reserved=0 >>> (side by side) >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548738587%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IB1OzhQHd8gC%2Bh3JTQnJWhDcefDLsvhUwSe6QYChT%2Fw%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548758944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lsI3YF01YdkOmzemWyOcmOjcrGJg0N7BclKdaotSWdw%3D&reserved=0 >>> (side by side) >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-lastdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548779796%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oYQiVbyWd0yhTc81pEm4vklenF3XdK825Pkq%2FWncSW8%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-lastrfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548801278%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZxNaJBpKvo9YnpDSV0%2FzGTd5rK%2BvIFPiugMzgh9mrcA%3D&reserved=0 >>> (side by side) >>> >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171548822484%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yhKTjC8iDo367FxCVW%2FRlXveekMXTAWOdikheG0VTJI%3D&reserved=0 >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff2.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549225066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TFYR9n%2BuxT0IycP9m2Hx%2B5ws%2Bh04uYDBiWM6P0a0%2FRs%3D&reserved=0 >>> >>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9650828&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549256826%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qQPQgkFqL68FyebrogbfilUcCyJh%2BpQnMvF1Aq3MXEM%3D&reserved=0 >>>>> >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9018454&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549286757%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sNKo2aj4dSZw0aFTiHam15VfjuCnaSmVYqVqR857Ago%3D&reserved=0 >>>> >>>> Apologies for our confusion: When we go to >>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9650828&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549657749%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y%2FtMf8ZBWTrWrQbsk0%2BcT9bO4gBtdvFMY4ddvuG%2BV6Q%3D&reserved=0>, >>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9650828&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549728575%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FjEfu0yIvuxxa%2FEDnrSFIQlkINLM4JWv1Jb36BbFA94%3D&reserved=0> >>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9650828&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171549793300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MNVIO%2FTwVSOPs5TZhlH439PD4w%2F5xTuQSRHqF4xAkBM%3D&reserved=0>. >>>> [DON] use >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9018454&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550173752%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yNOaPatHbkjZtLahw0TYjBVo%2FSLkko1FOho2tdGyE8s%3D&reserved=0 >>>> = = = = = >>>> >>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550227638%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qza%2F5wF6MjWbh2oK%2FkWLmUABViCVA02%2FyYiVyFYhF3A%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550250407%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hTgO91TViosVTJGNYS1taCZOV%2BjuPsIeL94nndCX3cQ%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550272449%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LxZHFzP1MIUCryw1NMT98ljm%2F2sMjpWeK77so7ZSeAw%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550293291%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4qy2%2FqQG4hyJEtovvyoUbWZ%2BOx09jfWTlRdDimHczJA%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550313681%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9CFShCteEEKCmjY%2FALB1Lq997OjSDAV8ze0IyMMAD0U%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550333807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yz4pVSOcI0OSvizx2mAKgYu%2FOIulLak8zyIPrfjh8sI%3D&reserved=0 >>>> (side by side) >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550355757%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fsXiQP8QPgfA2L1rxvSv4vfhEGJOh7HoqtMo65cxNQ4%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550377252%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Gl%2FNIlvKx2HM1Hbqwt5HnMkT8SpQZVPZJicMmqlKlxQ%3D&reserved=0 >>>> (side by side) >>>> >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550397376%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KBrOsudjzZ74CW7iztAJTSlPTinBvxqjmQ%2FEvRKqsnM%3D&reserved=0 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff2.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550419089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rzluXGe1LSewN40O%2ByUIYZ54tjI91GQydBNjBApH520%3D&reserved=0 >>>> >>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550458288%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XP%2FqauQ%2F%2FaBJJwQFZUdp%2Bkk6o7sEHtxrvg567mWDRwM%3D&reserved=0>. >>>>> --> >>>>> >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F9650828&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550496045%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0hJjdV9JWWH%2BrnhetWJ0yqBZQRfd4sL1lLXxSqLYp0k%3D&reserved=0 >>>>> >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fdlep-parameters%2Fdlep-parameters.xhtml%23traffic-classification-sub-data-item-type-values&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550518029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BUM7t%2BgEWvFZwpa72dXyQs%2BGfhoDzBAh2Iw76nuPpF0%3D&reserved=0> >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550537848%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=drETOplCYFXs3mnYOxgCk8USdPrf4idkuG%2Fq4g3jxjQ%3D&reserved=0>, >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550558484%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ed%2BODMBBj96NeuTB4J1%2FaSnaru8Y2UfK13KYpH0ivJg%3D&reserved=0). >>>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550579694%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZgvzhAIFGhdBS27TCxhISjjH0oNGSudzmTv35Vktpk8%3D&reserved=0). >>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550599977%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YIgXL3bVcDlquGq%2BhKxFxqCHDClqIU6x2CLRWB3LVfQ%3D&reserved=0>. >>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550621216%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZnuMWuKJD%2B6mc3l2YvrdPhd3j5wqbiI1ur56Fwnx5z4%3D&reserved=0 >>>>> * The archive itself: >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550642967%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bV6eiSAKUHS1oaTq8LveOq2TUO7GD0P%2BCDdK0OsyVog%3D&reserved=0 >>>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550663089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f5La6SV3J5I7Gp0xCEivst2Atu6RJqa3GmyPcTlSAc4%3D&reserved=0 >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550683596%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W7Y15AxR3q6cl3W5qmN5DljczpkluE9dYXil4y1Kx6U%3D&reserved=0 >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550702435%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CdADorW6I%2B%2B88%2Bom2yrzzguqBNn3Vqw%2BA82lV2GlhzQ%3D&reserved=0 >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550723983%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bAQcGFJmdsYD%2Fyi8b46NkjsaQ02dlQANzlUrCm6oANM%3D&reserved=0 >>>>> Diff file of the text: >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550867267%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a6Ff2iPoURMZ8Rpcmz931kEhLeMH5AqG5g%2BbcY07w3o%3D&reserved=0 >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171550959625%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DfCEIJRNrxFko6vur3uXno7Sf5b6QFpPM6KwFWME3Lk%3D&reserved=0 >>>>> (side by side) >>>>> Diff of the XML: >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9892-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171551001871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mhx%2FDPfVLwaHRiMG8voNK%2F7USzRY0ZvRG7AitHv%2Bv1U%3D&reserved=0 >>>>> Tracking progress >>>>> ----------------- >>>>> The details of the AUTH48 status of your document are here: >>>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9892&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd814e0e4a9124f8363c108de3116dfcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639002171551023988%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V02bUvrioC9xtPwP7GMpRyFf4KC86QTJtOiR7SWIyAQ%3D&reserved=0 >>>>> 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]
