Hi Megan, After reviewing the changes, I do not have any further comments. I approve publication of the document.
regards Nic > -----Ursprüngliche Nachricht----- > Von: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Gesendet: Mittwoch, 2. Juli 2025 18:22 > An: Christian Schmutzer (cschmutz) <cschm...@cisco.com> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; steven.gring...@verizon.com; > Whittaker, Jeremy M <jeremy.whitta...@verizon.com>; Leymann, Nicolai > <n.leym...@telekom.de>; Brown, Christopher <cbr...@ciena.com>; pals- > a...@ietf.org; pals-chairs <pals-cha...@ietf.org>; Stewart Bryant > <stewart.bry...@gmail.com>; Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org > Betreff: Re: AUTH48: RFC-to-be 9801 <draft-ietf-pals-ple-15> for your review > > Hi Christian, > > Thanks for clarifying! We added in the "downstream" as requested and > slightly updated the reference to RFC 9800 to match what was recently > published (please refresh to view these changes: we combined them with the > last round). > > We have marked your approval at the AUTH48 status page (see link below). > As this closes out all of queries from our end, once we receive approvals from > your coauthors, we will move forward in the publication process. > > The files have been posted here (please refresh): > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.txt&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702078829647%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=G%2BlEgz0d6R8ISfcNKLNhCf3oaJP4DSAtIwuo%2BjnU5pw%3D&reserv > ed=0 > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.pdf&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702078859762%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=JMYyQMOIgz5nUc3ByNY40RRk%2BHRndl%2BdwHBwP2usmQs%3D&r > eserved=0 > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.html&data=05%7C02%7CN.Leymann%40t > elekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf > 68b04a5eeb25f5c4f%7C0%7C0%7C638870702078876029%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C > &sdata=Yv4edQRLjlIEFKtn1%2BGNaGWqLhBMPUEZKzPGoZxq8vk%3D&reser > ved=0 > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.xml&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702078890758%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=KT6t%2BcRO4k6bBbapZq18zwwYMsXHrrPTUdEomLV2JJU%3D&reserv > ed=0 > > The relevant diff files have been posted here (please refresh): > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754 > d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C638870702078906950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=78EnN2PCQycUcaH30Q > n%2Bn76EanwBrAoSk%2BxD3fbiixQ%3D&reserved=0 (comprehensive diff) > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f > 550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% > 7C0%7C0%7C638870702078936172%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > WFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=AOWBfXZ3TDld > EYsR5FdU%2BPAddkiUm8DkHpzkdVJN%2FK0%3D&reserved=0 (AUTH48 > changes only) > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48rfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba2 > 3f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f > %7C0%7C0%7C638870702078960981%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2FODWtoecl > hmATueihE5TlcmhjIKwKQ64%2FWYgeFncg%2F0%3D&reserved=0 (AUTH48 > side by side) > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > lastdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550 > 754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0 > %7C0%7C638870702078984944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Cq7Lebl0z9OjQnbZ > WJZRbvgRdsQN%2F7ZMQu5COhGU%2B5I%3D&reserved=0 > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > lastrfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f5 > 50754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 > C0%7C0%7C638870702079007912%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=m7f9HUzudiUEHI > 605j10fjLMdWSBg31egA32mepKaSI%3D&reserved=0 (side by side) > > Please contact us with any further updates/questions/comments you may > have. > > The AUTH48 status page for this document is available here: > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauth48%2Frfc9801&data=05%7C02%7CN.Leymann%40teleko > m.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b0 > 4a5eeb25f5c4f%7C0%7C0%7C638870702079030446%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdat > a=LgPn9MVgHm%2FMMqsmZ3OUA5EAhOxMd60hfbtO6ki6bVI%3D&reserve > d=0 > > Thank you. > > RFC Editor/mf > > > > On Jul 2, 2025, at 12:07 AM, Christian Schmutzer (cschmutz) > <cschm...@cisco.com> wrote: > > > > Hi Megan, > > > >> Please clarify the change requested. Note that we changed "appropriate > specific fault propagation signal" to "appropriate fault-indication signal" in > Section 5.2.1. Perhaps this was related? > > > > > > Yes this was related. I was even thinking to make that part exactly the same > as the other appearances you already changed (include the "downstream" as > well) -> "appropriate downstream fault-indication signal". > > > > At this stage I am good from my side and I approve the document for > publication > > > > Thank you very much Megan for all your help ! > > > > Christian > > > >> On 01.07.2025, at 17:33, Megan Ferguson <mfergu...@staff.rfc- > editor.org> wrote: > >> > >> Hi Christian, > >> > >> Thanks for your reply and careful review. > >> > >> We have updated as requested. With regard to: > >> > >>> the slight spelling diff in section 5.2 and 7.2.2 was not intentional > >> > >> Please clarify the change requested. Note that we changed "appropriate > specific fault propagation signal" to "appropriate fault-indication signal" in > Section 5.2.1. Perhaps this was related? > >> > >> With the completion of these updates, the only remaining use of "native" is > in the expansion of NSP, which is how it was used in the cited RFC 3985, so we > assume that should stay as is. > >> > >> Please review the files carefully as we do not make changes after > publication. > >> > >> The files have been posted here (please refresh): > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.txt&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079052791%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=G7%2BNmkD2pWxDITTWCSlkFbBvXRZ7ktts0HfC7xObR4I%3D&reserve > d=0 > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.pdf&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079078403%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=7yAxlb3EI7PvIneuZRAWsmBhjUIsNKVrVeobyl%2BpqHs%3D&reserved= > 0 > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.html&data=05%7C02%7CN.Leymann%40t > elekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf > 68b04a5eeb25f5c4f%7C0%7C0%7C638870702079099107%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C > &sdata=KcbfD5cUIQyemt6DWWl%2B60va23Bts%2B%2F0WZnC4JUWYYI%3 > D&reserved=0 > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.xml&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079118603%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=PmdVRosHE4mdXwiGYgf5CjychDwExFbzFx1oUUTNRvg%3D&reserved= > 0 > >> > >> The relevant diff files have been posted here (please refresh): > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754 > d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C638870702079137323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=iFpfpKwyiDWP58fjS6O3 > 02v9pqsCakPuliQH2dSVNOA%3D&reserved=0 (comprehensive diff) > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f > 550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% > 7C0%7C0%7C638870702079156779%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > WFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=UjmF0KNd3575 > awFvsPndtTku1YAtLRQAGobDa4Y0nHE%3D&reserved=0 (AUTH48 changes > only) > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48rfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba2 > 3f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f > %7C0%7C0%7C638870702079176576%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=RmaseC0cH9r > mrlAefoAPMt9TYRbU5%2BSnRtVm4JlXrf4%3D&reserved=0 (AUTH48 side by > side) > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > lastdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550 > 754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0 > %7C0%7C638870702079195363%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=X%2Fl9P5P5ClYpBk > Q1NDrmUaN2psrpELe%2BrcnlKowVvPA%3D&reserved=0 > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > lastrfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f5 > 50754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 > C0%7C0%7C638870702079214143%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=VkxdmiARjlHe8Rsi > vNj%2BisY0dXwwpL0U8jcE0%2B7bVr4%3D&reserved=0 (side by side) > >> > >> Please contact us with any further updates/questions/comments you may > have. > >> > >> We will await approvals from each of the parties listed on the AUTH48 > status page prior to moving forward to publication. > >> > >> The AUTH48 status page for this document is available here: > >> > >> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauth48%2Frfc9801&data=05%7C02%7CN.Leymann%40teleko > m.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b0 > 4a5eeb25f5c4f%7C0%7C0%7C638870702079233615%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdat > a=O0Ff%2BTw7B2yZnV%2FCVWCUV0unoYo9oyEN9n719qhb2VI%3D&reser > ved=0 > >> > >> Thank you. > >> > >> RFC Editor/mf > >> > >>> On Jul 1, 2025, at 5:54 AM, Christian Schmutzer (cschmutz) > <cschm...@cisco.com> wrote: > >>> > >>> Hi Megan, > >>> > >>> Thank you for the quick turnaround and the detailed explanation on the > approach for the abbreviations . no further changes required there. > >>> > >>> The <aside> changes for the notes look good. > >>> > >>> Also the other changes look good ! > >>> > >>> > >>> Three remaining nits (if I may): > >>> > >>> 1. Section 5.1 and C-SID vs CSID > >>> > >>> RFC9800-to-be is using CSID, I think we should use the same. Which > means adding "CSID: compressed SID" to section 3.1 and no expansion in > section 5.1, just mentioning of CSID > >>> > >>> 2. Replacing "native" > >>> > >>> In sections 5.2 and 7.2.2 we have several sentences saying "inject . > appropriate specific fault . signal" > >>> > >>> I think saying "appropriate specific" is somewhat redundant (without the > "service" in between which refers to the emulated service defined in section > 4) > >>> > >>> Thinking about it again I wonder, if it is best if drop the word > >>> "specific" and > we simply make all these sentences say ". inject the appropriate downstream > fault-indication signal .". In the end they all refer to the same thing, the > slight > spelling diff in section 5.2 and 7.2.2 was not intentional > >>> > >>> 3. LEN changes > >>> > >>> Reading this paragraph again I think I gave improper guidance (i.e. the > section # was wrong), sorry about that. Here a proposal > >>> > >>> CURRENT: > >>> > >>> LEN: > >>> In accordance with Section 3 of [RFC4385], the length field MUST > >>> always be set to zero as there is no padding added to the PLE > >>> packet. The preconfigured size of the PLE payload MUST be assumed > >>> to be as described in Section 5.2; if the actual packet size is > >>> inconsistent with this length, the packet MUST be considered > >>> malformed. To detect malformed packets the default, preconfigured > >>> or signaled payload size MUST be assumed. > >>> > >>> NEW: > >>> > >>> LEN: > >>> In accordance with Section 3 of [RFC4385], the length field MUST > >>> always be set to zero as there is no padding added to the PLE > >>> packet. The size of the PLE payload MUST be assumed > >>> to be as described in Section 6; if the actual packet size is > >>> inconsistent with this, the packet MUST be considered > >>> malformed. > >>> > >>> > >>> Cheers > >>> Christian > >>> > >>>> On 30.06.2025, at 22:20, Megan Ferguson <mfergu...@staff.rfc- > editor.org> wrote: > >>>> > >>>> Christian, > >>>> > >>>> Thank you for your reply, guidance, and detailed review. We have some > follow up questions/comments below marked with [rfced] for you to take a > look at: > >>>> > >>>> 1) Regarding: > >>>> > >>>>>> b) We cut abbreviations from the list in Section 3.1 that were not > >>>>>> used in the document after that list. Please let us know any > >>>>>> objections. > >>>>> > >>>>> You mean if there expansion at first use but no second use in the > document, then the abbreviation will not be in the list of section 3.1? > >>>>> > >>>>> If so, no objections > >>>> > >>>> [rfced] Meaning either: > >>>> > >>>> a) they were not mentioned at all other than in the list in Section 3.1. > >>>> For > example, Autonomous System was included in the list in Section 3.1, but we > could find no instances of AS, ASes, autonomous system, or Autonomous > System in the body of the document. > >>>> > >>>> b) they were only used once in the document and appeared next to the > expansion at that place (e.g., Virtual Tributary (VT)). > >>>> > >>>> 2) Regarding: > >>>> > >>>>> Btw I don't want to make matters worse. I just realised some of those > things while trying to figure out how to respond here ;-) > >>>> > >>>> [rfced] We've tried to structure as follows for the ease of the reader > >>>> and > to match use in past RFCs: > >>>> > >>>> -expand on first use if they occur before Section 3.1 and if repeated in > 3.1, we left them there > >>>> -if the first use was in Section 3.1, cut any later expansions > >>>> -it is ok to have starred abbreviations in Section 3.1 (left these alone) > >>>> -it is ok to have starred abbreviations in the text and not in Section > >>>> 3.1 > whether or not they are expanded (as they are well known (left these alone)) > >>>> > >>>> Please let us know if any further changes are desired. > >>>> > >>>> > >>>>>> 25) <!-- [rfced] Please review whether any of the notes in this > document > >>>>>> should be in the <aside> element. It is defined as "a container > >>>>>> for content that is semantically less important or tangential to > >>>>>> the content that surrounds it" > >>>>>> > (https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > ors.ietf.org%2Fen%2Frfcxml- > vocabulary%23aside&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbb > a23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c > 4f%7C0%7C0%7C638870702079247939%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=E3hEdnfSlSF > 7w14%2Fmbv49FC6ZyvMv%2F3Z92DCrF1TopU%3D&reserved=0). > >>>>>> --> > >>>>> > >>>>> I was not aware of the aside element. I think it makes sense to put all > the notes into aside elements > >>>> > >>>> [rfced] Please review our updates to using the <aside> element. We have > put only the paragraphs beginning with "Note:" into the element. If > subsequent paragraphs should also go in <aside> please let us know. > >>>> > >>>> 3) Regarding: > >>>>>> 11) <!--[rfced] Please confirm that the following uses of PLE should > >>>>>> not > >>>>>> be flipped in their expansions: > >>>>>> > >>>>>> Original: > >>>>>> > >>>>>> * ES-PLE : PLE Errored Seconds > >>>>>> > >>>>>> * SES-PLE : PLE Severely Errored Seconds > >>>>>> > >>>>>> * UAS-PLE : PLE Unavailable Seconds > >>>>>> > >>>>>> Perhaps: > >>>>>> > >>>>>> * ES-PLE : Errored Seconds PLE > >>>>>> > >>>>>> * SES-PLE : Severely Errored Seconds PLE > >>>>>> > >>>>>> * UAS-PLE : Unavailable Seconds PLE > >>>>>> > >>>>>> --> > >>>>> > >>>>> Good question. I honestly don't know what is the best (I am not a > English native speaker). The terms ES-PLE, SES-PLE and UAS-PLE are inspired > by Y.1563 which defines SESETH where the ETH is in subscript. To do the same > but avoid the subscript I simply used -PLE > >>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .itu.int%2Frec%2FT-REC- > Y.1563%2Fen&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f55 > 0754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C > 0%7C0%7C638870702079261496%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=DaoN98VbUeUkXu > OPgMx2lMaY%2FZ77k4n12i%2FdC0wEOBA%3D&reserved=0 > >>>>> > >>>>> Sadly Y1563 doesn't expand the whole term SESETH so we can't take an > exact example from that document. > >>>>> > >>>>> If you feel the flipped expansion still makes sense from a language > standpoint then lets flip them > >>>> > >>>> [rfced] After some internal discussion, we believe the best course of > action is to leave these as you had them. Please disregard our query. > >>>> > >>>> We believe we have incorporated all other changes as requested. > >>>> > >>>> Please review the files carefully as we do not make changes after > publication. > >>>> > >>>> The files have been posted here (please refresh): > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.txt&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079274951%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=gkupjtI%2BY2ECDqefL1XpMF2uFUy3IE0csXcrhjdV2Ks%3D&reserved=0 > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.pdf&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079288653%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=T2M5spuUyXmW8sraS4VJqvOFa7C2OZJCFC%2B%2Fynv4Q18%3D&res > erved=0 > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.html&data=05%7C02%7CN.Leymann%40t > elekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf > 68b04a5eeb25f5c4f%7C0%7C0%7C638870702079301943%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C > &sdata=3qaIPvKjzakVb4b2PZkgR7NPmk3Nrwm8TTar6fZaggA%3D&reserved > =0 > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.xml&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079316495%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=plX%2F%2B2CYMZIbQmxyVukO7tUlfA%2F4fOkYwCRUiHM3LRw%3D&r > eserved=0 > >>>> > >>>> The relevant diff files have been posted here (please refresh): > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754 > d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C638870702079331237%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=pmwr85FYorrZZBzNAAE > WnoPqHG2lpVIPgt5EjmBM2zw%3D&reserved=0 (comprehensive diff) > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f > 550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% > 7C0%7C0%7C638870702079344781%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > WFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=BxbJwwWBm9 > UHVknsxKJxqfa2SocGH%2B1cFrhTyod9aWE%3D&reserved=0 (AUTH48 > changes only) > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > auth48rfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba2 > 3f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f > %7C0%7C0%7C638870702079357925%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=aYxd7Lo6HRM > ODB8FJqLwwd9miU5Nyk8X5g3rBXWo4dw%3D&reserved=0 (AUTH48 side > by side) > >>>> > >>>> Please contact us with any further updates/questions/comments you > may have. > >>>> > >>>> We will await approvals from each of the parties listed on the AUTH48 > status page prior to moving forward to publication. > >>>> > >>>> The AUTH48 status page for this document is available here: > >>>> > >>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauth48%2Frfc9801&data=05%7C02%7CN.Leymann%40teleko > m.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b0 > 4a5eeb25f5c4f%7C0%7C0%7C638870702079370970%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdat > a=vW5ibJmktLwAQHyVKE%2BS9GF4pLPv%2Fxt2Q0HUqx%2FRivk%3D&reser > ved=0 > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/mf > >>>> > >>>> > >>>> > >>>> > >>>>> On Jun 30, 2025, at 12:48 PM, Christian Schmutzer (cschmutz) > <cschmutz=40cisco....@dmarc.ietf.org> wrote: > >>>>> > >>>>> Dear RFC Editor Team, > >>>>> > >>>>> Sorry it took a little while to process the very detailed review of > >>>>> yours. > >>>>> > >>>>> Please find inline feedback and change proposals as appropriate for the > comments > >>>>> > >>>>> > >>>>> In addition to your comments here one change that came to my mind > while reviewing > >>>>> > >>>>> section 7.3 : Should we make the following changes to stay consistent > with the rest of the document? > >>>>> > >>>>> OLD: > >>>>> Once unavailability is detected, ES and SES counts SHALL be inhibited > >>>>> up to the point where the unavailability was started. Once > >>>>> unavailability is removed, ES and SES that occurred along the > >>>>> clearing period SHALL be added to the ES and SES counts. > >>>>> > >>>>> NEW: > >>>>> Once unavailability is detected, ES-PLE and SES-PLE counts SHALL be > inhibited > >>>>> up to the point where the unavailability was started. Once > >>>>> unavailability is removed, ES-PLE and SES-PLE that occurred along the > >>>>> clearing period SHALL be added to the ES-PLE and SES-PLE counts. > >>>>> > >>>>> > >>>>> Please let me know if there are any questions on the responses and > whether you need more details. > >>>>> > >>>>> Regards > >>>>> Christian > >>>>> > >>>>>> Begin forwarded message: > >>>>>> > >>>>>> From: rfc-edi...@rfc-editor.org > >>>>>> Subject: Re: AUTH48: RFC-to-be 9801 <draft-ietf-pals-ple-15> for your > review > >>>>>> Date: 21. June 2025 at 03:47:04 CEST > >>>>>> To: <steven.gring...@verizon.com>, <jeremy.whitta...@verizon.com>, > <n.leym...@telekom.de>, <cschm...@cisco.com>, <cbr...@ciena.com> > >>>>>> Cc: <rfc-edi...@rfc-editor.org>, <pals-...@ietf.org>, <pals- > cha...@ietf.org>, <stewart.bry...@gmail.com>, > <gunter.van_de_ve...@nokia.com>, <auth48archive@rfc-editor.org> > >>>>>> > >>>>>> Authors, > >>>>>> > >>>>>> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > >>>>>> > >>>>>> 1) <!--[rfced] We note that the abbreviated title for this document is > >>>>>> currently "PLE". We have updated this to "PLE over PSNs" to more > >>>>>> closely match the full title. Please let us know any objections. > >>>>>> --> > >>>>> > >>>>> No objections > >>>>> > >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>>>>> the title) for use on > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fsearch&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbb > a23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c > 4f%7C0%7C0%7C638870702079386899%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=87dolzjQcw > LMkDyvFjyXVnwmPM1nabcDDCdFE84Rkm8%3D&reserved=0. --> > >>>>> > >>>>> pseudowires, circuit emulation, structure-agnostic emulation, bit- > stream payload, SR-MPLS, SRv6, IWF > >>>>> > >>>>>> 3) <!--[rfced] We had a few notes about the titles in Section 3: > >>>>>> > >>>>>> a) Please note that we have updated the title of Section 3 to use > >>>>>> plural "Models" as it appears that more than one model is discussed in > >>>>>> Section 3.2 (or at least repeated from RFC 4197). Please review and > >>>>>> let us know any objections. > >>>>> > >>>>> No objections > >>>>> > >>>>>> b) Please note that we have updated the title of Section 3.1 to > >>>>>> "Abbreviations" as all terms in that section seem to be expansions. > >>>>>> Please let us know any concerns. > >>>>>> --> > >>>>> > >>>>> No objections, but looks like the files you provided don't have this > change yet? > >>>>> > >>>>>> 4) <!-- [rfced] We note that [RFC3985] does not contain the term > "Virtual > >>>>>> Private Wire Service" or the abbreviation "VPWS". Please review > >>>>>> this citation for accuracy. > >>>>>> > >>>>>> Original: > >>>>>> VPWS - Virtual Private Wire Service [RFC3985] > >>>>>> --> > >>>>> > >>>>> Indeed. Lets use instead rfc4664 which defines VPWS and references > rfc3985. > >>>>> > >>>>>> 5) <!--[rfced] Can you clarify the use of "whereas" in this text? > >>>>>> > >>>>>> Original: > >>>>>> PLE embraces the minimum intervention principle outlined in > >>>>>> Section 3.3.5 of [RFC3985] whereas the data is flowing through the > >>>>>> PLE encapsulation layer as received without modifications. > >>>>>> > >>>>>> > >>>>>> Perhaps: > >>>>>> While PLE embraces the minimum intervention principle outlined in > >>>>>> Section 3.3.5 of [RFC3985], in this case, the data is flowing through > the > >>>>>> PLE encapsulation layer as received without modifications. > >>>>>> > >>>>>> --> > >>>>> > >>>>> We meant to say "which means". The "While . in this case " does sound > a bit choppy to me. How about the following two options? > >>>>> > >>>>> NEW Option1: > >>>>> PLE embraces the minimum intervention principle outlined in > >>>>> Section 3.3.5 of [RFC3985], hence the data is flowing through the > >>>>> PLE encapsulation layer as received without modifications. > >>>>> > >>>>> NEW Option2: > >>>>> PLE embraces the minimum intervention principle outlined in > >>>>> Section 3.3.5 of [RFC3985], which means the data is flowing through > the > >>>>> PLE encapsulation layer as received without modifications. > >>>>> > >>>>> > >>>>>> 6) <!--[rfced] In the following, does PE1 generate the clock difference > >>>>>> transferred? Or should the last part of this sentence be passive > >>>>>> voice (i.e., "is transferred" instead of "transferred")? > >>>>>> > >>>>>> Original: > >>>>>> For the reverse direction PE1 does generate the attachment circuit > >>>>>> clock J and the clock difference between G and D (locked to I) > >>>>>> transferred from PE2 to PE1. > >>>>>> --> > >>>>> > >>>>> Good catch. It should be passive voice "is transferred" because the > >>>>> clock > difference was actually generated by PE2 > >>>>> > >>>>>> 7) <!--[rfced] Is there an "and" relationship between the items in the > >>>>>> lists like those found in Section 4.2.2 (and elsewhere)? > >>>>>> > >>>>>> Original: > >>>>>> > >>>>>> The CE-bound NSP function MUST perform > >>>>>> > >>>>>> * PCS code sync (section 49.2.9 of [IEEE802.3]) > >>>>>> > >>>>>> * descrambling (section 49.2.10 of [IEEE802.3]) > >>>>>> > >>>>>> in order to properly > >>>>>> > >>>>>> * transform invalid 66B code blocks into proper error control > >>>>>> characters /E/ (section 49.2.4.11 of [IEEE802.3]) > >>>>>> > >>>>>> * insert Local Fault (LF) ordered sets (section 46.3.4 of > >>>>>> [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE > >>>>>> packets are received with the L-bit being set > >>>>>> > >>>>>> Perhaps: > >>>>>> > >>>>>> The CE-bound NSP function MUST perform: > >>>>>> > >>>>>> * PCS code sync (Section 49.2.9 of [IEEE802.3]) and > >>>>>> > >>>>>> * descrambling (Section 49.2.10 of [IEEE802.3]) > >>>>>> > >>>>>> in order to properly: > >>>>>> > >>>>>> * transform invalid 66B code blocks into proper error control > >>>>>> characters /E/ (section 49.2.4.11 of [IEEE802.3]) and > >>>>>> > >>>>>> * insert Local Fault (LF) ordered sets (Section 46.3.4 of > >>>>>> [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE > >>>>>> packets are received with the L bit set. > >>>>>> > >>>>>> --> > >>>>> > >>>>> Yes there is an and relationship. The proposal sounds good > >>>>> > >>>>>> 8) <!--[rfced] We note that RFC-to-be 9800 > >>>>>> (draft-ietf-spring-srv6-srh-compression-27) uses Destination > >>>>>> Address field. Please review the following and let us know if > >>>>>> updates are necessary: > >>>>>> > >>>>>> Original: > >>>>>> The first SID is only placed in the destination IPv6 address field. > >>>>>> --> > >>>>> > >>>>> Yes it's a good idea to align to the nomenclature of the SRH compression > draft. > >>>>> > >>>>> NEW: > >>>>> The first SID is only placed in the Destination Address field of the > >>>>> IPv6 > header. > >>>>> > >>>>> > >>>>>> 9) <!--[rfced] Please clarify "to detect malformed packets the > >>>>>> default": > >>>>>> does this mean "to detect malformed packets by default" or is > >>>>>> another rephrasing necessary? > >>>>>> > >>>>>> Original: > >>>>>> To detect malformed packets the default, preconfigured or signaled > >>>>>> payload size MUST be assumed. > >>>>>> --> > >>>>> > >>>>> No it does not. The description of LEN is a slight variation of what is > written in RFC4553 section 4.3.1 where the LEN is always set to 0. How about > the following? > >>>>> > >>>>> NEW: > >>>>> The preconfigured size of the PLE payload MUST be assumed to be as > described in Section 5.2, and if the actual packet size is inconsistent with > this > length, the packet MUST be considered malformed. > >>>>> > >>>>> > >>>>>> 10) <!--[rfced] Please review this use of "both": > >>>>>> > >>>>>> Original: > >>>>>> The same PT value MAY be reused both for direction and between > >>>>>> different PLE VPWS. > >>>>>> > >>>>>> > >>>>>> Perhaps A: > >>>>>> The same PT value MAY be reused for both directions and between > >>>>>> different PLE VPWS. > >>>>>> > >>>>>> Perhaps B: > >>>>>> The same PT value MAY be reused both for directionality and > >>>>>> between different PLE VPWS. > >>>>>> > >>>>>> --> > >>>>> > >>>>> Option A is what we meant > >>>>> > >>>>>> 11) <!--[rfced] Please confirm that the following uses of PLE should > >>>>>> not > >>>>>> be flipped in their expansions: > >>>>>> > >>>>>> Original: > >>>>>> > >>>>>> * ES-PLE : PLE Errored Seconds > >>>>>> > >>>>>> * SES-PLE : PLE Severely Errored Seconds > >>>>>> > >>>>>> * UAS-PLE : PLE Unavailable Seconds > >>>>>> > >>>>>> Perhaps: > >>>>>> > >>>>>> * ES-PLE : Errored Seconds PLE > >>>>>> > >>>>>> * SES-PLE : Severely Errored Seconds PLE > >>>>>> > >>>>>> * UAS-PLE : Unavailable Seconds PLE > >>>>>> > >>>>>> --> > >>>>> > >>>>> Good question. I honestly don't know what is the best (I am not a > English native speaker). The terms ES-PLE, SES-PLE and UAS-PLE are inspired > by Y.1563 which defines SESETH where the ETH is in subscript. To do the same > but avoid the subscript I simply used -PLE > >>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .itu.int%2Frec%2FT-REC- > Y.1563%2Fen&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f55 > 0754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C > 0%7C0%7C638870702079399925%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Jo37HjqhzSKgMXV > 7Ub078QYxc9nhs6UxDY4Ib%2BRQVxo%3D&reserved=0 > >>>>> > >>>>> Sadly Y1563 doesn't expand the whole term SESETH so we can't take an > exact example from that document. > >>>>> > >>>>> If you feel the flipped expansion still makes sense from a language > standpoint then lets flip them > >>>>> > >>>>>> 12) <!--[rfced] Please review our edits to the following to ensure we > have > >>>>>> captured your intended meaning. > >>>>>> > >>>>>> Original: > >>>>>> Possible options, but not exhaustively, are a Diffserv-enabled > >>>>>> [RFC2475] PSN with a per domain behavior [RFC3086] supporting > >>>>>> Expedited Forwarding [RFC3246]. Traffic-engineered paths through > the > >>>>>> PSN with bandwidth reservation and admission control applied. Or > >>>>>> capacity over-provisioning. > >>>>>> > >>>>>> Current: > >>>>>> Possible options, but not exhaustively, are as follows: > >>>>>> > >>>>>> * a Diffserv-enabled (see [RFC2475]) PSN with a per-domain behavior > (see [RFC3086]) supporting Expedited Forwarding (se > >>>>>> e [RFC3246]), > >>>>>> > >>>>>> * traffic-engineered paths through the PSN with bandwidth > reservation and admission control applied, or > >>>>>> > >>>>>> * capacity over-provisioning. > >>>>>> > >>>>>> --> > >>>>> > >>>>> Great suggestion and you have captured the meaning perfectly and > made the text way more easy to read. > >>>>> > >>>>>> 13) <!--[rfced] Please confirm the use of "threads" (and not "threats") > in > >>>>>> the following: > >>>>>> > >>>>>> Original: > >>>>>> Clock synchronization leveraging PTP is sensitive to Packet Delay > >>>>>> Variation (PDV) and vulnerable to various threads and attack vectors. > >>>>>> > >>>>>> --> > >>>>> > >>>>> Good catch, this is about security and should have been "threats" :-) > >>>>> > >>>>>> 14) <!-- [rfced] Reference [G.824] was flagged as not being cited > anywhere in the text. Please review and let us know w > >>>>>> here it should be cited or if the reference entry should be removed.--> > >>>>> > >>>>> You can remove it, I forgot to get rid of it > >>>>> > >>>>>> 15) <!-- [rfced] [G.8262] This ITU-T Recommendation was superseded > in > >>>>>> October 2024. We have updated this reference to use the most > >>>>>> current version. Please let us know if you have any > >>>>>> objections.--> > >>>>> > >>>>> No objections > >>>>> > >>>>>> 16) <!-- [rfced] [FC-PI-2] The original URL for this reference - > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits4042006&data=05%7C02%7C > N.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a980%7C > bde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638870702079412374 > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4000 > 0%7C%7C%7C&sdata=bGvKD7Il7MplBVzkKLxyssFk3oRHVrOBJwWeHRnIoDs > %3D&reserved=0 - leads to an > >>>>>> error page on the ANSI webstore. We found the following URL that > >>>>>> points to the most recent version of this INCITS document. We have > >>>>>> updated this reference to use that URL. We have also updated the date > >>>>>> for this reference from 2006 to 2016 to match the information at the > >>>>>> URL. Please let us know if you have any objections. -> > >>>>> > >>>>> No objections > >>>>> > >>>>>> 17) <!-- [rfced] [FC-PI-5] A more recent version of this INCITS > document is > >>>>>> avaialable here: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits4792011s2021&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020794 > 24566%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=PdY3p7KPkyHGm%2BzYYzD1pHhJ8obz2bvrs8h > m8R2rFGc%3D&reserved=0. May we > >>>>>> update this reference to use the most current version?--> > >>>>> > >>>>> Yes, please update > >>>>> > >>>>>> 18) <!-- [rfced] [FC-PI-5am1] A more recent version of this INCITS > >>>>>> document is avaialable here: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits4792011am2016r2021&data= > 05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb > 984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707 > 02079437111%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C40000%7C%7C%7C&sdata=Xgz9w69BovTPZuQVFayTY5wSDzWfGz > Wcl%2FR770%2BP8Gk%3D&reserved=0. May > >>>>>> we update this reference to use the most current version?--> > >>>>> > >>>>> Yes, please update > >>>>> > >>>>>> 19) <!-- [rfced] For [FC-PI-6]: A more recent version of this INCITS > >>>>>> document is avaialable here: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits5332016r2021&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020794 > 49101%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=DvJiNpvNI7oUdVCghmp18HyLXVd9BwZmrDXdj > dMJSMw%3D&reserved=0. May > >>>>>> we update this reference to use the most current version?--> > >>>>> > >>>>> Yes, please update but I think you have the wrong URL. The one you > show here is FC-PI-6P > >>>>> > >>>>> Please use > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits5122015r2020&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020794 > 61266%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=q5P%2BE1gSXvHPNKmsRYe%2F5QNr9dErRLkA > Sn2mdX6tFz4%3D&reserved=0 > >>>>> > >>>>>> 20) <!-- [rfced] [FC-PI-6P]: A more recent version of this INCITS > document > >>>>>> is avaialable here: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebs > tore.ansi.org%2Fstandards%2Fincits%2Fincits5332016r2021&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020794 > 73258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=Sv6g9YtpKwgYXhyat7hxtyYzIBIPNm63laHn63d > 4rhs%3D&reserved=0. May > >>>>>> we update this reference to use the most current version?--> > >>>>> > >>>>> Yes, please update > >>>>> > >>>>>> 21) <!--[rfced] Please review instances in which a slash character "/" > >>>>>> is > >>>>>> used and consider if "and", "or", or "and/or" might be clearer > >>>>>> for the reader. --> > >>>>> > >>>>> I found one instance that falls in this category. Is the proposed change > still easy to read? Its a triple or > >>>>> > >>>>> Original: > >>>>> Each second with at least one packet lost or a PLOS/DEG defect SHALL be > counted as ES-PLE. Each second with a PLR greater than 15% or a PLOS/DEG > defect SHALL be counted as SES-PLE. > >>>>> > >>>>> NEW: > >>>>> Each second with at least one packet lost or a PLOS defect or a DEG > defect SHALL be counted as ES-PLE. Each second with a PLR greater than 15% > or a PLOS defect or DEG defect SHALL be counted as SES-PLE. > >>>>> > >>>>>> 22) <!--[rfced] We had the following questions related to terminology > used throughout the document: > >>>>>> > >>>>>> a) We see multiple similar forms of the following terms. Please let us > know if/how they should be made consistent: > >>>>>> > >>>>>> bit stream vs. bit-stream > >>>>>> lane vs. Lane > >>>>>> > >>>>>> --> > >>>>> > >>>>> Yes, please change to bit-stream and lane consistently > >>>>> > >>>>> > >>>>>> 23) <!-- [rfced] We had the following questions related to > abbreviations > >>>>>> used throughout the document: > >>>>>> > >>>>>> a) FYI - We have added expansions for abbreviations upon first use per > >>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >>>>>> expansion in the document carefully to ensure correct use. > >>>>> > >>>>> Expansions look good > >>>>> > >>>>>> b) We cut abbreviations from the list in Section 3.1 that were not > >>>>>> used in the document after that list. Please let us know any > >>>>>> objections. > >>>>> > >>>>> You mean if there expansion at first use but no second use in the > document, then the abbreviation will not be in the list of section 3.1? > >>>>> > >>>>> If so, no objections > >>>>> > >>>>>> c) We see multiple expansions for the same abbreviation in the list > >>>>>> below. Please let us know the correct expansion: > >>>>>> > >>>>>> VC - Virtual Container and Virtual Circuit > >>>>> > >>>>> Virtual Container is correct > >>>>> > >>>>>> PMD - Physical Medium Dependent and Physical Media Dependent > >>>>> > >>>>> Physical Medium Dependent is correct > >>>>> > >>>>>> d) We have made some slight updates to the list of abbreviations in > >>>>>> Section 3.1 in order to more closely match their cited references or > >>>>>> to more closely match the expansions used in RFCs generally. Please > >>>>>> review carefully and let us know if any further updates are necessary. > >>>>> > >>>>> Looks good > >>>>> > >>>>>> e) Please let us know how you would like to expand the abbreviation > >>>>>> "OOF". Should it be "Out of Frame"? > >>>>> > >>>>> Yes, "Out of Frame" is correct > >>>>> > >>>>>> f) We will cut repeat expansions from abbreviations after first use > >>>>>> (to match the guidance at > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7CN > .Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbd > e4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638870702079485774% > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4000 > 0%7C%7C%7C&sdata=uNGlWrQe3tVGulTaQim7MegovnvYLzafTQR3fmD%2F > Y%2Fk%3D&reserved=0) for the > >>>>>> following unless we hear objection: > >>>>>> > >>>>>> TDM > >>>>>> LF > >>>>>> ACH > >>>>>> CBR > >>>>>> LSP > >>>>>> NOS > >>>>>> PDV > >>>>>> PLR > >>>>>> PMD > >>>>>> PTP > >>>>>> RTCP > >>>>>> SRTP > >>>>>> SD > >>>>>> SID > >>>>>> CSID > >>>>>> TTS > >>>>>> NSP > >>>>>> FEC > >>>>>> PCS > >>>>>> LPI > >>>>>> PLOS > >>>>>> DEG > >>>>>> > >>>>>> --> > >>>>> > >>>>> Did you already do some cleanup? In the version you shared > (rfc9801.txt) I only see three abbreviations with multiple expansions > >>>>> > >>>>> LF > >>>>> NOS > >>>>> PDV > >>>>> > >>>>> > >>>>> While doing the scrub of the document and cross-checking it with your > list I also realised that there are quite a few abbreviations never expanded. > Some of them have a * in > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dabbrev_list&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020794 > 97992%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=eqHDSgsCu11h5jwCk%2FhrBhNPkFWiHW4CdJ > 17fwWp61U%3D&reserved=0, so I guess no expansion needed. But should > they then also be removed from the list of section 3.1? Also some of them not > having a * > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dabbrev_list&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020795 > 10203%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=0Sl2kemAHO60bbFV0Y7j%2F43Popas1K7BLPh > ZanOT%2FDI%3D&reserved=0 are missing in the list of section 3.1 > >>>>> > >>>>> RTP > >>>>> OTN > >>>>> LOS > >>>>> PMA > >>>>> MS-AIS > >>>>> AIS-L > >>>>> INCITS > >>>>> LOF > >>>>> OOF > >>>>> OTUk > >>>>> LOM > >>>>> ODUk > >>>>> ODUk-AIS > >>>>> MTU > >>>>> LDP > >>>>> RSVP-TE > >>>>> TLV > >>>>> FIB > >>>>> SRv6 > >>>>> EVPN-VPWS > >>>>> RDI > >>>>> TCP > >>>>> ICMP > >>>>> IEEE > >>>>> AIS-L > >>>>> MPLS > >>>>> UAS > >>>>> > >>>>> Btw I don't want to make matters worse. I just realised some of those > things while trying to figure out how to respond here ;-) > >>>>> > >>>>>> 24) <!-- [rfced] FYI - We updated artwork to sourcecode with the type > >>>>>> "pseudocode" in Section 5.1.1. Please confirm that this is > >>>>>> correct. > >>>>>> > >>>>>> In addition, please consider whether the "type" attribute of any > >>>>>> sourcecode element should be set and/or has been set correctly. > >>>>>> > >>>>>> The current list of preferred values for "type" is available at > >>>>>> > <https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- > types&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754d8 > c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0% > 7C638870702079523258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2BVVuDFnylblGy3yc1oV > WPPl82MkquOuSZ4kILnWzlgM%3D&reserved=0>. > >>>>>> If the current list does not contain an applicable type, feel free to > >>>>>> suggest additions for consideration. Note that it is also acceptable > >>>>>> to leave the "type" attribute not set. > >>>>>> --> > >>>>> > >>>>> Pseudocode is good. The artwork use is similar to section 4.1.1 of > RFC9800-to-be. Or RFC8986 section 4.1 > >>>>> > >>>>>> 25) <!-- [rfced] Please review whether any of the notes in this > document > >>>>>> should be in the <aside> element. It is defined as "a container > >>>>>> for content that is semantically less important or tangential to > >>>>>> the content that surrounds it" > >>>>>> > (https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > ors.ietf.org%2Fen%2Frfcxml- > vocabulary%23aside&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbb > a23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c > 4f%7C0%7C0%7C638870702079540629%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=uxEeEFNlXxd > nvrgM1%2BO6po%2F6eenG8%2B05QtWc41zUpmc%3D&reserved=0). > >>>>>> --> > >>>>> > >>>>> I was not aware of the aside element. I think it makes sense to put all > the notes into aside elements > >>>>> > >>>>>> 26) <!-- [rfced] Some author comments are present in the XML. Please > >>>>>> confirm that no updates related to these comments are > >>>>>> outstanding. Note that the comments will be deleted prior to > >>>>>> publication. > >>>>>> --> > >>>>> > >>>>> No updates pending. Those were background infos I added over time > but didn't remove > >>>>> > >>>>>> 27) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>>>> online Style Guide > >>>>>> > <https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0 > 2%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a98 > 0%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6388707020795 > 57029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C40000%7C%7C%7C&sdata=SbFD5PkU4b%2Bl%2Fs0Gcg9giW50YporsVKBE > 3jPlxt6UCw%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. > >>>>>> > >>>>>> For example, please consider whether the following should be > updated: > >>>>>> > >>>>>> native > >>>>>> --> > >>>>> > >>>>> Good catch, here my proposal to change the appearances of "native". I > don't think there are other changes needed > >>>>> > >>>>> OLD: > >>>>> performing operations on the native data received from the CE > >>>>> > >>>>> NEW: > >>>>> performing operations on the data received from the CE > >>>>> > >>>>> > >>>>> OLD: > >>>>> L > >>>>> Set by the PE to indicate that data carried in the payload is > >>>>> invalid due to an attachment circuit fault. The downstream PE > >>>>> MUST send appropriate replacement data. The NSP MAY inject an > >>>>> appropriate native fault propagation signal. > >>>>> > >>>>> NEW: > >>>>> L > >>>>> Set by the PE to indicate that data carried in the payload is > >>>>> invalid due to an attachment circuit fault. The downstream PE > >>>>> MUST send appropriate replacement data. The NSP MAY inject the > >>>>> service specific native fault propagation signal. > >>>>> > >>>>> > >>>>> OLD: > >>>>> Whenever the VPWS is not operationally up, the CE-bound NSP > function > >>>>> MUST inject the appropriate native downstream fault-indication > >>>>> signal. > >>>>> > >>>>> NEW: > >>>>> Whenever the VPWS is not operationally up, the CE-bound NSP > function > >>>>> MUST inject the service specific downstream fault-indication > >>>>> signal. > >>>>> > >>>>> > >>>>> OLD: > >>>>> them in the jitter buffer. The CE-bound NSP function will continue > >>>>> to inject the appropriate native downstream fault-indication signal > >>>>> until a preconfigured number of payload s stored in the jitter > >>>>> buffer. > >>>>> > >>>>> NEW: > >>>>> them in the jitter buffer. The CE-bound NSP function will continue > >>>>> to inject the service specific downstream fault-indication signal > >>>>> until a preconfigured number of payload s stored in the jitter > >>>>> buffer. > >>>>> > >>>>> > >>>>> OLD: > >>>>> Whenever the L bit is set in the PLE control word of a received PLE > >>>>> packet, the CE-bound NSP function SHOULD inject the appropriate > >>>>> native downstream fault-indication signal instead of streaming out > >>>>> the payload. > >>>>> > >>>>> NEW: > >>>>> Whenever the L bit is set in the PLE control word of a received PLE > >>>>> packet, the CE-bound NSP function SHOULD inject the service > >>>>> Specific downstream fault-indication signal instead of streaming out > >>>>> the payload. > >>>>> > >>>>> > >>>>> OLD: > >>>>> While the PLOS defect is declared, the CE-bound NSP function MUST > >>>>> inject the appropriate native downstream fault-indication signal. > >>>>> > >>>>> NEW: > >>>>> While the PLOS defect is declared, the CE-bound NSP function MUST > >>>>> inject the service specific downstream fault-indication signal. > >>>>> > >>>>> > >>>>> > >>>>>> Thank you. > >>>>>> > >>>>>> RFC Editor/mf > >>>>>> > >>>>>> *****IMPORTANT***** > >>>>>> > >>>>>> Updated 2025/06/20 > >>>>>> > >>>>>> 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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7CN.Leymann%40telekom.de%7Ccb > ba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5 > c4f%7C0%7C0%7C638870702079570364%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=shW%2BR > olLaXiXsOUIDAIlQCglSOpu1FfglV%2B9eUlXIlo%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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrust > ee.ietf.org%2Flicense- > info&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754d8c > 084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0% > 7C638870702079585262%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=sXbzEPBPO47zViy37x4k%2 > BdUno%2FUny%2BUjt%2Bnr774MBRY%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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faut > hors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f5507 > 54d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0% > 7C0%7C638870702079599036%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=51VtQ9G1RCpab%2B > RoEIbHFlGk2xWynTKnIBfNPRUS%2Bgs%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 > >>>>>> > >>>>>> * rfc-edi...@rfc-editor.org (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). > >>>>>> > >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>> list: > >>>>>> > >>>>>> * More info: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaila > rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7CN.Leymann%40telekom.de%7Ccb > ba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5 > c4f%7C0%7C0%7C638870702079612378%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=b4qvUQV > X7RskjwDvt4MUAdEwXBUBvrfDDYLbuZ%2F83Ls%3D&reserved=0 > >>>>>> > >>>>>> * The archive itself: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaila > rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 > CN.Leymann%40telekom.de%7Ccbba23f550754d8c084708ddb984a980%7 > Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C63887070207962505 > 3%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C400 > 00%7C%7C%7C&sdata=9xuJ6JVGw4xXgc2p0XhC4SxrFDO9pCNynkCUvi5Nzfk > %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, > >>>>>> auth48archive@rfc-editor.org 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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.xml&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079638786%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=r%2BjzXavbwwrYePPQwgbRrdm9IlLYTApuZ4WGG5Z6TXc%3D&reserved > =0 > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.html&data=05%7C02%7CN.Leymann%40t > elekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf > 68b04a5eeb25f5c4f%7C0%7C0%7C638870702079651227%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C > &sdata=2PioYE%2FgVt8tcVWaIdFyPS6Lm61BVyHRJ0l8PrXP6o8%3D&reserve > d=0 > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.pdf&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079663724%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=r670gT%2F%2Bk8K9VLm9ae3PoifKj8XvwaW4R2YlhkpNdww%3D&rese > rved=0 > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauthors%2Frfc9801.txt&data=05%7C02%7CN.Leymann%40tel > ekom.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C638870702079676485%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&s > data=P6Mu760YHP0GdtEhMohDzcF2yldcr2L%2B4CmwLQgdU10%3D&reser > ved=0 > >>>>>> > >>>>>> Diff file of the text: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > diff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f550754 > d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C638870702079695844%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=ipweyVraXGtOBrGsp7pYs > oWrzs1rDtewuQUEP6YEsew%3D&reserved=0 > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > rfcdiff.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f5507 > 54d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0% > 7C0%7C638870702079713392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=pRuTW6imhKr7cbKnd > t04%2BBEo0BQf8Vmhf7tl81EE2gM%3D&reserved=0 (side by side) > >>>>>> > >>>>>> Diff of the XML: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc-editor.org%2Fauthors%2Frfc9801- > xmldiff1.html&data=05%7C02%7CN.Leymann%40telekom.de%7Ccbba23f55 > 0754d8c084708ddb984a980%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C > 0%7C0%7C638870702079731732%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=vr8kO0yymcRHk9r > %2F8Mr0dSQCUyTstDdnqRuQpDBSa3Y%3D&reserved=0 > >>>>>> > >>>>>> > >>>>>> Tracking progress > >>>>>> ----------------- > >>>>>> > >>>>>> The details of the AUTH48 status of your document are here: > >>>>>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .rfc- > editor.org%2Fauth48%2Frfc9801&data=05%7C02%7CN.Leymann%40teleko > m.de%7Ccbba23f550754d8c084708ddb984a980%7Cbde4dffc4b604cf68b0 > 4a5eeb25f5c4f%7C0%7C0%7C638870702079746240%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdat > a=0SbCFOeXj1WLSYPdj557wp0sarQCVHWpEHMRcYDQlZI%3D&reserved=0 > >>>>>> > >>>>>> Please let us know if you have any questions. > >>>>>> > >>>>>> Thank you for your cooperation, > >>>>>> > >>>>>> RFC Editor > >>>>>> > >>>>>> -------------------------------------- > >>>>>> RFC9801 (draft-ietf-pals-ple-15) > >>>>>> > >>>>>> Title : Private Line Emulation over Packet Switched Networks > >>>>>> Author(s) : S. Gringeri, J. Whittaker, N. Leymann, C. > >>>>>> Schmutzer, C. > Brown > >>>>>> WG Chair(s) : Andrew G. Malis, Stewart Bryant > >>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
