Hello All: After reviewing the changes I approve publication of the document.
Steve Gringeri On Mon, Jul 7, 2025 at 9:11 AM Whittaker, Jeremy M < jeremy.whitta...@verizon.com> wrote: > Hi Megan, > > After reviewing the changes, I do not have any further comments. I approve > publication of the document. > Jeremy Whittaker > > On Fri, Jul 4, 2025 at 7:15 AM <n.leym...@telekom.de> wrote: > >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fauth&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=ybF7jvgYKCsnbL84y1ldk6tHFGaO6wpSKCit9UpucYE&e= >> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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://urldefense.proofpoint.com/v2/url?u=https-3A__deu01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=6fPJCwRO0do4cldIyE8VQAdOEs2S0E75XOoPZvwE6HI&m=yO_v_QnQGnVZml6qakrhLcsFR8kuPS7G7-4S7wHSgJXjiKh1cKibNqrPJDIxFw9Z&s=FAXVpUL6fgQq-wR5JBCAdBkWc4J-3IlwzRpcuEq8z5o&e= >> > .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. >> > >>>>>> >> > >> > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
