Hi Alanna/Karen, all, Thank you for preparing the edited version.
Please see inline. I let my co-authors further comments as appropriate. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : jeudi 19 février 2026 23:49 > À : [email protected]; [email protected]; BOUCADAIR Mohamed > INNOV/NET <[email protected]>; [email protected]; > [email protected] > Cc : [email protected]; [email protected]; netmod- > [email protected]; [email protected]; auth48archive@rfc- > editor.org > Objet : [AD] Re: AUTH48: RFC-to-be 9922 <draft-ietf-netmod- > schedule-yang-10> for your review > > > Authors and *AD, > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source > file. > > *AD, please see question #11. > > 1) <!-- [rfced] FYI - We will do the following when we convert the > file to RFCXML: > > - compact the spacing of the definition lists in Sections 8.1 and > 8.2 > --> [Med] ACK. > > > 2) <!--[rfced] Note that we have updated the short title, which > appears in the running header in the PDF output, as follows. > Please let us know of any objections. > > Original: > Common Schedule YANG > > Current: > YANG Scheduling > --> [Med] This is better. Thanks. > > > 3) <!--[rfced] To avoid awkward hyphenation, may we update this > sentence to read as "objects managed by MIB"? > > Original: > Section 5 discusses the relationship with the Management > Information > Base (MIB) managed objects for scheduling management operations > defined in [RFC3231]. > > Perhaps: > Section 5 discusses the relationship with the objects managed > by > Management Information Base (MIB) for scheduling management > operations > defined in [RFC3231]. > --> > [Med] These are MIB objects. The OLD is accurate. I'm not a change is needed here. > > 4) <!--[rfced] Please clarify "to execute independent of when it > ends". Is the meaning that the validity parameter determines when > a schedule can be started and thus "executed independently from > when it ends"? > > Original: > It determines the latest time that a schedule can be started to > execute independent of when it ends and takes precedence over > similar attributes that are provided at the schedule instance > itself. > > Perhaps: > It determines the latest time that a schedule can be started > and > thus executed independently from when it ends, and it takes > precedence over similar attributes that are provided at the > schedule instance itself. > --> > [Med] You got it :-) The proposed new text is OK. Thanks. > 5) <!--[rfced] May we update this sentence to make the two items > mentioned (i.e., "all schedules on a system" and "too short > schedule > requests") more parallel and thus easier to read? > > Original: > These parameters apply to all schedules on a system and are > meant to > provide guards against stale configuration, too short schedule > requests that would prevent validation by admins of some > critical > systems, etc. > > Perhaps: > These parameters apply to all schedules on a system and are > meant > to provide guards against stale configuration, schedule > requests > that are too short and that would thus prevent validation by > admins > of some critical systems, etc. > -->* [Med] ACK. > > > 6) <!-- [rfced] We note that Section 4.13 of [I-D.ietf-netmod- > rfc8407bis] mentions "default" but doesn't mention "mandatory"; > however, Section 4.14 mentions both "default" and "mandatory". > Should the citations below be updated to point to Section 4.14 > instead? > > Original (Section 3.3.3): > Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], > neither a > "default" nor a "mandatory" substatement is defined here for > both > "frequency" and "interval" parameters because there are cases > (e.g., > profiling) where using these statements is problematic. > > Original (Section 3.3.8): > Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], > neither a > "default" nor a "mandatory" substatement is defined here > because there > are cases (e.g., profiling) where using these statements is > problematic. > --> > [Med] What about the following: NEW: (Section 3.3.3): Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], no "default" substatement is defined here for both "frequency" and "interval" parameters because there are cases (e.g., profiling) where using these statements is problematic. No "mandatory" substatement is defined here for the same reason. (Section 3.3.8): Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], no "default" substatement is defined here because there are cases (e.g., profiling) where using these statements is problematic. No "mandatory" substatement is defined here for the same reason. > > 7) <!--[rfced] For conciseness, may we shorten "the value > indicated by the value of the..." in the sentence below as > follows? > > Original: > The value of the "period-start" instance MUST > NOT exceed the value indicated by the value of "frequency" > instance... > > Perhaps: > The value of the "period-start" instance MUST > NOT exceed the value of the "frequency" instance... > --> [Med] ACK. > > > 8) <!--[rfced] In the title of Figure 9, is the asterisk (*) in > "schedule-status-*" correct? We ask as we do not see this > elsewhere in the document. > > Current: > Figure 9: 'schedule-status-*' Groupings Tree Structure > > Perhaps: > Figure 9: 'schedule-status' Groupings Tree Structure > --> [Med] The OLD is correct. schedule-status-* is used to refer to any of "schedule-status", "schedule-status-with-time-zone", and "schedule-status-with-name". May be add this NEW in Section 2: NEW: "schedule-status-*" refers to any of "schedule-status", "schedule-status-with-time-zone", and "schedule-status-with-name". > > > 9) <!--[rfced] FYI - As RFC 5545 is also cited within the "ietf- > schedule" > module, we've added it to the list of RFCs preceding the module. > > Original: > This module imports types defined in [RFC6991] and [RFC7317]. > > Current: > This module imports types defined in [RFC5545], [RFC6991], and > [RFC7317]. > --> [Med] The original is correct. We don’t import types from RFC5545. That RFC is already cited in the main body, btw. I suggest we revert the change but update 6991 to 9911: NEW: This module imports types defined in [RFC9911] and [RFC7317]. > > > 10) <!--[rfced] FYI - We made the following update to the format > in the "ietf-schedule" YANG module using the formatting option of > pyang. > > Original: > error-message > "Frequency must be provided."; > > Current: > error-message "Frequency must be provided."; > --> [Med] ACK. > > > 11) <!--[rfced] *AD - Security Considerations Questions > > a) FYI - We updated the Security Considerations section to match > the template at > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853a > 3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639071381428252688%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=QMtFMcbZQRxCeaKhS%2BIJXWbvduR%2B1RGOzT > NbFNKUjCw%3D&reserved=0>. > Please review and let us know if any further updates are needed. > > b) As the Writable nodes, Readable nodes, and RFC/action > operations sections are not applicable to this document, do the > following sentences need to be added accordingly (per the > template)? > > - "There are no particularly sensitive writable data nodes." > - "There are no particularly sensitive readable data nodes." > - "There are no particularly sensitive RPC or action operations." > [Med] I don't think this is needed. > c) We note that in the paragraph that relates to the "No data > nodes" > section, there is a sentence missing (i.e., from the template: > "For example, reusing some of these groupings will expose privacy- > related information (e.g., 'node-example')". Is that omission > intentional or should it be added for clarity? > > From the template: > Modules that use the groupings that are defined in this > document > should identify the corresponding security considerations. For > example, reusing some of these groupings will expose > privacy-related information (e.g., 'node-example'). > > Current text in the document: > Modules that use the groupings that are defined in this > document > should identify the corresponding security considerations, for > example: > --> > [Med] We may consider: OLD: Modules that use the groupings that are defined in this document should identify the corresponding security considerations, for example: NEW: Modules that use the groupings that are defined in this document should identify the corresponding security considerations. For example, reusing the following groupings will expose privacy-related information: > > 12) <!--[rfced] In Appendix A, should each example be listed in > separate sourcecode blocks? They are all currently contained > within one block of sourcecode. > --> [Med] I would keep current. > > > 13) <!-- [rfced] FYI, the YANG examples (example-sch-usage-1 - > 8.yang [Med] These were simplified for compactness. That’s said, we can use this extended version: https://raw.githubusercontent.com/netmod-wg/schedule-yang/refs/heads/main/yang/appendix-a-examples and example-scheduled-backup.yang, example-scheduled-link- > bandwidth.yang, > and example-sch-capacity-res.yang) each give errors and warnings > from pyang -ietf. Please confirm this is as expected. > --> [Med] These have only warning that are not important for an example (TLP, cite an RFC, etc.). I think this is OK. > > > 14) <!--[rfced] We note that dates are formatted in different ways > in Appendix A. For example, "January 31, 2025" and "2025-06-01" > are used in Appendices A.1 and A.6, respectively. If these > instances should be consistent, please let us know which form you > prefer. > > Original: > Figure 10 illustrates the example of a requested schedule that > needs > to start no earlier than 08:00 AM, January 1, 2025 and end no > later > than 8:00 PM, January 31, 2025 (Beijing time). > ... > Figure 18 indicates a recurrence that occurs every two days > starting > at 9:00 AM and 3:00 PM for a duration of 30 minutes and 40 > minutes > respectively, from 2025-06-01 to 2025-06-30 in UTC: > --> [Med] I don't think a change is needed here. > > > 15) <!--[rfced] The example module in Appendix B references RFC > 8345 but no corresponding reference entry exists. May we add RFC > 8345 under the Informative References section and update the > running text as follows? > > Original: > The following example module which augments the > "recurrence-utc-with-periods" grouping from "ietf-schedule" > module > shows how a scheduled attribute could be defined. > > Perhaps: > The following example module, which augments the > "recurrence-utc-with-periods" grouping from "ietf-schedule" > module, > shows how a scheduled attribute could be defined. Note that > [RFC8345] and this document are referenced in the module. > --> [Med] ACK. > > > 16) <!--[rfced] FYI, a normative reference to the XML > specification has been added because this document contains XML. > See the IESG statement on "Guidelines for the Use of Formal > Languages in IETF Specifications" > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fietf.org%2Fblog%2Fguidelines-use-formal-languages-ietf- > specifications%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C > cf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d2 > 0%7C0%7C0%7C639071381428275590%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3SiO%2BwRnaf42CZqi3LHFphCRNx9Qx > xzwyG1rDvC4sgw%3D&reserved=0) - specifically "The use of a > language requires a reference to the specification for that > language. This reference is normative, and needs to fulfil the > usual requirements for normative references (Section 7 of RFC > 2026)." Please review where the XML specification is cited and let > us know if you prefer otherwise. [Med] I don't think this is normative as this is only for an example. Please move that entry to be listed as Informative. Thanks. > > Original: > Figure 24 shows a configuration example of a link's bandwidth > that is > scheduled between 2025-12-01 0:00 UTC to the end of 2025-12-31 > with a > daily schedule. > > Current: > Figure 24 shows a configuration example in XML [W3C.XML1.0] > of a link's bandwidth that is scheduled between 2025-12-01 0:00 > UTC > to the end of 2025-12-31 with a daily schedule. > > Normative Reference Entry: > [W3C.XML1.0] > Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M., Ed., > Maler, > E., Ed., and F. Yergeau, Ed., "Extensible Markup Language > (XML) > 1.0 (Fifth Edition)", W3C Recommendation, 26 November 2008, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.w3.org%2FTR%2F2008%2FREC-xml- > 20081126%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853 > a3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0% > 7C0%7C639071381428290895%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > yfQ%3D%3D%7C0%7C%7C%7C&sdata=5xS%2F22xFXfAdjTVRcxNi9NLA%2Bd97CSc9u > y7NoGpHNmI%3D&reserved=0>. > --> > > > 17) <!-- [rfced] Please review the language set for each instance > of sourcecode in the MD file to ensure correctness. If the current > list of preferred values for languages > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- > types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853a3d317 > 4ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 639071381428302806%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=2xIV3Vj0R3uzFljWGRFUJkDtVntbplrgxJHWO7QR0jk > %3D&reserved=0) > does not contain an applicable language, then feel free to let us > know. > Also, it is acceptable to leave the language not set. > --> [Med] YANG modules can be set to "yang", all appendix examples to "json", example in appendices B/C to "xml". > > > 18) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. May we > replace RFC > 6991 with RFC 9911? If yes, this will include updating the > references in the YANG module. > --> [Med] Yes, please. > > > 19) <!-- [rfced] Please review the "Inclusive Language" portion of > the online Style Guide > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Ccf5853a3d3174ad769c508de7009 > 0b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390713814283130 > 45%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=fG0PDJmKf%2F4r4AVFQwIIIxAtOJleHz9VizG55kpbVy8%3D&reserved=0 > > > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for > readers. > > Note that our script did not flag any words in particular, but > this should still be reviewed as a best practice. > --> > [Med] We are using https://github.com/netmod-wg/schedule-yang/blob/main/.github/in-solidarity.yml and nothing was flagged. > > Thank you. > > Alanna Paloma and Karen Moore > RFC Production Center > > > > On Feb 19, 2026, at 2:40 PM, RFC Editor via auth48archive > <[email protected]> wrote: > > *****IMPORTANT***** > > Updated 2026/02/18 > > RFC Authors: > > Your document has now entered AUTH48. > > The document was edited in kramdown-rfc as part of the RPC pilot > test (see > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dpilot_test_kramdown_rfc& > data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853a3d3174ad769 > c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639071 > 381428324714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=qFUtwLXgC5r1iS9nufNc0GGdmidBZTdxKCTz8aVecdY%3D&re > served=0). > > Please review the procedures for AUTH48 using kramdown-rfc: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dpilot_test_instructions_ > completing_auth48_using_kramdown&data=05%7C02%7Cmohamed.boucadair% > 40orange.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40bf > bc48b9253b6f5d20%7C0%7C0%7C639071381428334664%7CUnknown%7CTWFpbGZs > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk > FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=L9LvCYzYbYZW%2BS > XO9S6Om5zrt6s%2FWsTf3wznc8vH6SM%3D&reserved=0 > > Once your document has completed AUTH48, it will be published as > an RFC. > > > Files > ----- > > The files are available here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9922.md&data=05%7C02%7Cmohamed.boucadair > %40orange.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40b > fbc48b9253b6f5d20%7C0%7C0%7C639071381428344729%7CUnknown%7CTWFpbGZ > sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VV3V%2BkeWFl68Y > OAIS2ig3wzdWF5Ac4WbSXzKmdUnV3M%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9922.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639071381428354368%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yz69n0bwtKPP7 > L%2FZVDtbMLc%2BTJnz5vavAJdkCiPywmM%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9922.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639071381428364879%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lckn%2BQJuXVa% > 2Bjvhcuw9cuKhO3aH6za%2FUGCxTLCyBx34%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9922.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639071381428376310%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sJ9HefstOTzvOA > kO6iixasj4JZTArh8r4DciclnHkoE%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9922- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853a3 > d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639071381428386423%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=6hZazC9uLvit%2FJ%2FY8L9sgoFf4vnTTNjeFGx > UnGwCL80%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9922- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf585 > 3a3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639071381428395805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=e010keam7gjrfrmaR%2BrSzbjyyeDuEVGC9Z > %2B4jCyct6U%3D&reserved=0 (side by side) > > Diff of the kramdown: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9922-md- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf5853a3 > d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639071381428405466%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=lFak4dM%2F0jV1leZ7uPGbvlhzFvB4dHEbpLdqe > WYTs5w%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9922-md- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccf585 > 3a3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639071381428415043%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=HM5FCLhLrRC5WI%2B%2F%2FgHY3v8Ob6Df1d > gcvO8d5uB%2F1Z0%3D&reserved=0 (side by side) > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9922&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7Ccf5853a3d3174ad769c508de70090b28%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C639071381428424689%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HCSqZ0JmqHiruzYJfT4 > Vy76WOvu8GmXlKegOgBK%2FhFo%3D&reserved=0 > > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -- > auth48archive mailing list -- [email protected] > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
