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]
