I approve the draft.

-Tim

________________________________
From: Madison Church <[email protected]>
Sent: Monday, May 18, 2026 11:06 AM
To: Dimitrios Schoinianakis (Nokia) 
<[email protected]>; [email protected] 
<[email protected]>; K Tirumaleswar Reddy (Nokia) 
<[email protected]>; Aritra Banerjee (Nokia) 
<[email protected]>; Mike Ounsworth <[email protected]>; Tim Hollebeek 
<[email protected]>
Cc: [email protected] <[email protected]>; [email protected] 
<[email protected]>; [email protected] <[email protected]>; 
[email protected] <[email protected]>; [email protected] 
<[email protected]>; [email protected] 
<[email protected]>
Subject: Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> for 
your review

Hi Dimitrios,

Thank you for your reply! We have noted your approval of the document’s content 
on the AUTH48 status page (see 
https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/auth48/rfc9958___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmViMzY6ZWVhYzY5NGU2ZDUzNGU0M2ViYzRmMTVlZGNkMWY0OWJjMmJhOGZjZTY0OTFiMzYyMGUxZTA4ZDBiZjkwMjE0NDpwOlQ6Rg).

Once we receive approval from Tim, we will move forward with RFCXML conversion 
and complete formatting updates.

Thank you!

Madison Church
RFC Production Center

> On May 18, 2026, at 2:18 AM, Dimitrios Schoinianakis (Nokia) 
> <[email protected]> wrote:
>
> P {margin-top:0;margin-bottom:0;} I approve the draft.
>
> Best,
> -δ
>
> -----Original Message-----
> From: Madison Church <[email protected]>
> Sent: Friday, May 15, 2026 7:39 PM
> To: Aritra Banerjee (Nokia) <[email protected]>; Mike Ounsworth 
> <[email protected]>; K Tirumaleswar Reddy (Nokia) 
> <[email protected]>; Dimitrios Schoinianakis (Nokia) 
> <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; 
> [email protected]; [email protected]; [email protected]; 
> [email protected]; [email protected]
> Subject: Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> for 
> your review
>
>
> CAUTION: This is an external email. Please be very careful when clicking 
> links or opening attachments. See the URL nok.it/ext for additional 
> information.
>
>
>
> Hi,
>
> This is a friendly weekly reminder that we await content approvals from 
> Dimitrios and Tim. Once we receive them, we will move forward with RFCXML 
> conversion of this document. At that time, we will ask for approvals for 
> formatting, which will be the final approvals needed for publication. For 
> details of the AUTH48 process in kramdown-rfc (including the two-part 
> approval process), see 
> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjAxNDc6ZWE5YzUwYjcwYzQ0MWRiZmJmOTJkOTAzOWJmOTJlMzFlN2Q5MDczMzNiNTU1M2ZmYTFiZjM3YzI2ZTdiYjczNzpwOlQ6Rg.
>
> Thank you!
>
> Madison Church
> RFC Production Center
>
> > On May 8, 2026, at 12:34 PM, Madison Church <[email protected]> 
> > wrote:
> >
> > Hi Aritra,
> >
> > Thank you for your reply! We have noted your approval of the document’s 
> > contents on the AUTH48 status page (see 
> > https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/auth48/rfc9958___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjFhMWI6MjAzNTNlYjYwMGRhYmE3NDYzN2ZiMDFmY2E0NDg0ZmY2ODhmZmNkNDRkODJjNTQ2YzAxOTUyNWRjN2E2OTIxMTpwOlQ6Rg).
> >  Once we receive approvals from Dimitrios and Tim, we will move forward 
> > with RFCXML conversion and complete formatting updates. For details of the 
> > AUTH48 process in kramdown-rfc (including the two-part approval process), 
> > see 
> > https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmFhYzI6MjkzMjJiNDYwM2JjMzAxMzZhYmM1MGQzNDQ2N2I5YTg3MTg1ODVhMjYyZjY0ZTIyYzc3ZDhhYWU4ZDg3ZDlmNjpwOlQ6Rg.
> >
> > Thank you!
> >
> > Madison Church
> > RFC Production Center
> >
> >> On May 8, 2026, at 1:32 AM, Aritra Banerjee (Nokia) 
> >> <[email protected]> wrote:
> >>
> >> Hi Madison,
> >> I have reviewed the latest AUTH48 version of the document and am satisfied 
> >> with the proposed updates. The revisions and changes looks good to me.
> >> I confirm that I am happy with the latest version and approve RFC-to-be 
> >> 9958 it for publication.
> >> Regards,
> >> Aritra.
> >>
> >> From: Madison Church <[email protected]>
> >> Date: Thursday, 7 May 2026 at 21:39
> >> To: Mike Ounsworth <[email protected]>; K Tirumaleswar Reddy (Nokia)
> >> <[email protected]>; Aritra Banerjee (Nokia)
> >> <[email protected]>; Dimitrios Schoinianakis (Nokia)
> >> <[email protected]>;
> >> [email protected] <[email protected]>
> >> Cc: [email protected] <[email protected]>;
> >> [email protected] <[email protected]>;
> >> [email protected] <[email protected]>; [email protected]
> >> <[email protected]>; [email protected]
> >> <[email protected]>; [email protected]
> >> <[email protected]>; [email protected]
> >> <[email protected]>
> >> Subject: Re: AUTH48: RFC-to-be 9958
> >> <draft-ietf-pquip-pqc-engineers-14> for your review
> >>
> >>
> >> CAUTION: This is an external email. Please be very careful when clicking 
> >> links or opening attachments. See the URL nok.it/ext for additional 
> >> information.
> >>
> >>
> >>
> >> Hi Mike,
> >>
> >> Thank you for your reply! We have noted your approval of the document’s 
> >> content on the AUTH48 status page (see 
> >> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/auth48/rfc9958___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjEwNzg6ZTJkNGNkMjAxZjBkOTAwMzNiNzNhMGQzN2M4YmY1NzU4Y2NlNjNkYTI1MzM3YjAzYjkxM2ZhNWY5NDc5YjgyODpwOlQ6Rg).
> >>
> >> Once we receive approvals from Aritra, Dimitrios, and Tim, we will move 
> >> forward with RFCXML conversion and complete formatting updates. For 
> >> details of the AUTH48 process in kramdown-rfc (including the two-part 
> >> approval process), see 
> >> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmM4NzI6ZjRkNzY0ZjgyYTYxMWFkNDg4MDczNTkzYTM5ZjIwMjhmNWVlZWY3M2MwYzIzYTgyMzVmM2U3NWI0NmZmNDQ4NjpwOlQ6Rg.
> >>
> >> Thank you!
> >>
> >> Madison Church
> >> RFC Production Center
> >>
> >>> On May 7, 2026, at 12:58 PM, Mike Ounsworth <[email protected]> wrote:
> >>>
> >>> I have also reviewed the diff top-to-bottom: great grammatical and 
> >>> consistency changes. Nothing jumped out to me as adversely affecting the 
> >>> technical meaning. Very well done!
> >>>
> >>> I also approve publication.
> >>>
> >>>
> >>> -Mike Ounsworth
> >>>
> >>> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> >>>
> >>>
> >>> "An expert is a person who has found out by his own painful
> >>> experience all the mistakes that one can make in a very narrow
> >>> field.” -- Niels Bohr
> >>>
> >>> On Wednesday, May 6th, 2026 at 5:43 AM, K Tirumaleswar Reddy (Nokia) 
> >>> <[email protected]> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I've finished reviewing the diff and I am happy to report that the 
> >>>> updates look good to me.
> >>>> I approve the publication of the specification.
> >>>>
> >>>> Cheers,
> >>>> -Tiru
> >>>>
> >>>> -----Original Message-----
> >>>> From: Madison Church <[email protected]>
> >>>> Sent: Wednesday, May 6, 2026 3:19 AM
> >>>> To: K Tirumaleswar Reddy (Nokia) <[email protected]>;
> >>>> Aritra Banerjee (Nokia) <[email protected]>; Dimitrios
> >>>> Schoinianakis (Nokia)
> >>>> <[email protected]>;
> >>>> [email protected]; [email protected];
> >>>> [email protected]
> >>>> Cc: [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; [email protected]
> >>>> Subject: Re: AUTH48: RFC-to-be 9958
> >>>> <draft-ietf-pquip-pqc-engineers-14> for your review
> >>>>
> >>>>
> >>>> CAUTION: This is an external email. Please be very careful when clicking 
> >>>> links or opening attachments. See the URL nok.it/ext for additional 
> >>>> information.
> >>>>
> >>>>
> >>>>
> >>>> Hi Authors,
> >>>>
> >>>> Tirumaleswar - Thank you for your reply! We have updated the document 
> >>>> per your response. Please see inline for a few followup items for your 
> >>>> review (note that we have cut resolved questions to limit the length of 
> >>>> this thread). Aside from the brief notes below, we have no further 
> >>>> questions relating to content at this time.
> >>>>
> >>>>> On May 1, 2026, at 6:51 AM, K Tirumaleswar Reddy (Nokia) 
> >>>>> <[email protected]> wrote:
> >>>>>
> >>>>> Hi,
> >>>>> Please see inline [TR]
> >>>>> -----Original Message-----
> >>>>> From: [email protected] <[email protected]>
> >>>>> Sent: Monday, April 27, 2026 11:44 PM
> >>>>> To: Aritra Banerjee (Nokia) <[email protected]>; K
> >>>>> Tirumaleswar Reddy (Nokia) <[email protected]>;
> >>>>> Dimitrios Schoinianakis (Nokia)
> >>>>> <[email protected]>;
> >>>>> [email protected]; [email protected]
> >>>>> Cc: [email protected]; [email protected];
> >>>>> [email protected]; [email protected];
> >>>>> [email protected]; [email protected]
> >>>>> Subject: Re: AUTH48: RFC-to-be 9958
> >>>>> <draft-ietf-pquip-pqc-engineers-14> for your review
> >>>>> CAUTION: This is an external email. Please be very careful when 
> >>>>> clicking links or opening attachments. See the URL nok.it/ext for 
> >>>>> additional information.
> >>>>>  Authors,
> >>>>> While reviewing this document during AUTH48, please resolve (as 
> >>>>> necessary) the following questions, which are also in the source file.
> >>>>> 1) <!-- [rfced] FYI - We will do the following when we convert the file 
> >>>>> to RFCXML:
> >>>>> a) Correct author names in reference entry for 
> >>>>> draft-ietf-pquip-pqc-hsm-constrained.
> >>>>> Current:
> >>>>>  [I-D.ietf-pquip-pqc-hsm-constrained]
> >>>>>             Reddy.K, T., Wing, D., S, B., and K. Kwiatkowski,
> >>>>>             "Adapting Constrained Devices for Post-Quantum
> >>>>>             Cryptography", Work in Progress, Internet-Draft, draft-
> >>>>>             ietf-pquip-pqc-hsm-constrained-02, 18 October 2025,
> >>>>>             
> >>>>> <https://url.avanan.click/v2/r01/___https://datatracker.ietf.org/doc/html/draft-ietf-pquip-___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjJhYTk6NGJlM2I3ZjBhMDgzMjM0OWE0YThhNmE0ZjhkMTkyMTg5M2NiNzE0N2U2N2M2Mzk5MDU5OWRmY2M1YTM0MWU0MjpwOlQ6Rg
> >>>>>             pqc-hsm-constrained-02>.
> >>>>> -->
> >>>>> [TR] Okay
> >>>>>
> >>>>> 4) <!-- [rfced] In Sections 5.1.1, 5.1.2, and 6.1, may we update the 
> >>>>> lists to better indicate the term being defined? We suggest placing the 
> >>>>> term rather than the citation before the colon. See the suggested text 
> >>>>> in a), b), and c) below.
> >>>>> We also have some additional questions regarding Section 5.1.2:
> >>>>> - How should "FN" in "FN-DSA" be expanded? Perhaps as "Fast-Fourier 
> >>>>> Transform over NTRU-Lattice-Based Digital Signature Algorithm"?
> >>>>> [TR] Yes.
> >>>>> - The FN-DSA entry includes pointers to Sections 8.1 and 10.2, but
> >>>>> ML-DSA and SLH-DSA are also mentioned in those setions. Should the
> >>>>> pointers to Sections
> >>>>> 8.1 and 10.2 apply to all entries?
> >>>>> [TR] Section 8.1 covers lattice-based cryptography and is therefore 
> >>>>> applicable only to ML-DSA and FN-DSA, not to SLH-DSA (which is 
> >>>>> hash-based, covered in Section 8.2). Section 10.2 applies to all three.
> >>>>> - We do not see "FN-DSA" mentioned in the URL listed for [FN-DSA]. 
> >>>>> Please review. Also, should this reference be to FIPS 206, or should 
> >>>>> the relationship between FIPS 206 and Fast Fourier/Falcon be explained 
> >>>>> for the reader? It seems that FIPS 206 is still in draft form.
> >>>>> [TR] FIPS 206 has not yet been released by NIST. The current reference 
> >>>>> correctly points to 
> >>>>> https://url.avanan.click/v2/r01/___https://falcon-sign.info/___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjMyYTU6OTY4YWJmMDY2ZjFmMDQxODk1MWJiODcyNDE5MWQ4MDIxNjE0ODhhNjFjMGIzY2M5MzI4YjhkNGFhYTU3YjNlOTpwOlQ6Rg,
> >>>>>  which is the FALCON project website. The text in the draft should make 
> >>>>> clear that FN-DSA is the name NIST has assigned to FALCON for the 
> >>>>> forthcoming FIPS 206 standard, but since that standard is not yet 
> >>>>> published, the FALCON project website remains the appropriate reference 
> >>>>> for now.
> >>>>
> >>>> [rfced] Thank you for this information! We will consult with our 
> >>>> citation specialist for any additional changes that need to be made to 
> >>>> this reference. For now, we have updated Sections 5.1.1, 5.1.2, and 6.1 
> >>>> according to our initial AUTH48 questions with the following change in 
> >>>> Section 5.1.2 to address FIPS 206. Please let us know if this text needs 
> >>>> any further updates.
> >>>>
> >>>> Current:
> >>>> FN-DSA:  Fast-Fourier Transform over NTRU-Lattice-Based Digital 
> >>>> Signature Algorithm. See [FN-DSA]; note that, at the time of 
> >>>> publication, FIPS 206 has not been published.
> >>>>
> >>>>> a) Section 5.1.1
> >>>>> Original
> >>>>>  *  [ML-KEM]: Module-Lattice-based Key-Encapsulation Mechanism
> >>>>>     Standard (FIPS-203).
> >>>>>   *  [HQC]: Hamming Quasi-Cyclic coding algorithm which is based on the
> >>>>>     hardness of the syndrome decoding problem for quasi-cyclic
> >>>>>     concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the
> >>>>>     Hamming metric.  Reed-Muller (RM) codes are a class of block
> >>>>>     error-correcting codes commonly used in wireless and deep-space
> >>>>>     communications, while Reed-Solomon (RS) codes are widely used to
> >>>>>     detect and correct multiple-bit errors.  HQC has been selected as
> >>>>>     part of the NIST post-quantum cryptography project but has not yet
> >>>>>     been standardized.
> >>>>> Perhaps:
> >>>>>  ML-KEM:  Module-Lattice-Based Key Encapsulation Mechanism. See
> >>>>>     FIPS 203 [ML-DSA].
> >>>>> [TR] In the above line, replace ML-DSA with ML-KEM
> >>>>>   HQC:  Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on 
> >>>>> the
> >>>>>     hardness of the syndrome decoding problem for quasi-cyclic
> >>>>>     concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the
> >>>>>     Hamming metric.  Reed-Muller (RM) codes are a class of block
> >>>>>     error-correcting codes commonly used in wireless and deep-space
> >>>>>     communications, while Reed-Solomon (RS) codes are widely used to
> >>>>>     detect and correct multiple-bit errors.  HQC has been selected as
> >>>>>     part of the NIST post-quantum cryptography project but has not yet
> >>>>>     been standardized.
> >>>>> b) Section 5.1.2
> >>>>> Original:
> >>>>>   *  [ML-DSA]: Module-Lattice-Based Digital Signature Standard (FIPS-
> >>>>>      204).
> >>>>>    *  [SLH-DSA]: Stateless Hash-Based Digital Signature (FIPS-205).
> >>>>>    *  [FN-DSA]: FN-DSA is a lattice signature scheme (FIPS-206)
> >>>>>      (Section 8.1 and Section 10.2).
> >>>>> Perhaps:
> >>>>>  ML-DSA:  Module-Lattice-Based Digital Signature Algorithm. See FIPS
> >>>>>     204 [ML-DSA].
> >>>>>   SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. See FIPS
> >>>>>     205 [SLH-DSA].
> >>>>>   FN-DSA:  Fast-Fourier Transform over NTRU-Lattice-Based Digital
> >>>>>     Signature Algorithm. See FIPS 206 [FN-DSA].
> >>>>>   For more information about these, see Sections 8.1 and 10.2.
> >>>>> [TR] For more information about these, see Sections 8.1, 8.2 and 10.2.
> >>>>> c) Section 6.1
> >>>>> Original:
> >>>>>  *  [FrodoKEM]: Key Encapsulation mechanism based on the hardness of
> >>>>>     learning with errors in algebraically unstructured lattices.
> >>>>>   *  [ClassicMcEliece]: Based on the hardness of syndrome decoding of
> >>>>>     Goppa codes.  Goppa codes are a class of error-correcting codes
> >>>>>     that can correct a certain number of errors in a transmitted
> >>>>>     message.  The decoding problem involves recovering the original
> >>>>>     message from the received noisy codeword.
> >>>>>   *  [NTRU]: Key encapsulation mechanism based on the "N-th degree
> >>>>>     Truncated polynomial Ring Units" (NTRU) lattices.  Variants
> >>>>>     include Streamlined NTRU Prime (sntrup761), which is leveraged for
> >>>>>     use in SSH [I-D.ietf-sshm-ntruprime-ssh].
> >>>>> Perhaps:
> >>>>>  FrodoKEM:  KEM based on the hardness of learning with errors in
> >>>>>     algebraically unstructured lattices. See [FrodoKEM].
> >>>>>   Classic McEliece:  KEM based on the hardness of syndrome decoding of
> >>>>>     Goppa codes.  Goppa codes are a class of error-correcting codes
> >>>>>     that can correct a certain number of errors in a transmitted
> >>>>>     message.  The decoding problem involves recovering the original
> >>>>>     message from the received noisy codeword. See [ClassicMcEliece].
> >>>>>   NTRU:  KEM based on the "N-th degree Truncated polynomial Ring
> >>>>>     Units" (NTRU) lattices.  Variants include Streamlined NTRU Prime
> >>>>>     (sntrup761), which is leveraged for use in SSH [RFC9941]. See 
> >>>>> [NTRU].
> >>>>> -->
> >>>>> [TR] Okay.
> >>>>>
> >>>>> 15) <!-- [rfced] References
> >>>>> a) FYI - We note that draft-hale-mls-combiner-01 has been replaced with 
> >>>>> draft-ietf-mls-combiner-02. Should this reference entry be updated 
> >>>>> accordingly? Note that the title has changed.
> >>>>> Original:
> >>>>>  [I-D.hale-mls-combiner]
> >>>>>             Joël, Hale, B., Mularczyk, M., and X. Tian, "Flexible
> >>>>>             Hybrid PQ MLS Combiner", Work in Progress, Internet-Draft,
> >>>>>             draft-hale-mls-combiner-01, 26 September 2024,
> >>>>>             
> >>>>> <https://url.avanan.click/v2/r01/___https://datatracker.ietf.org/doc/html/draft-hale-mls-___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjljZmU6YTI5ZjNmMDU2M2U4ODUyZjMyMmFjMjU4OWVkNzhiYzYzZGRmMzNiYjRjNTQ0Y2I1ZDVjMjUzNDk3NGM3ODdlNzpwOlQ6Rg
> >>>>>             combiner-01>.
> >>>>> Perhaps:
> >>>>>  [PQ-MLS]
> >>>>>             Tian, X., Hale, B., Mularczyk, M., and J. Alwen, "Amortized
> >>>>>             PQ MLS Combiner", Work in Progress, Internet-Draft,
> >>>>>             draft-ietf-mls-combiner-02, 20 October 2025,
> >>>>>             
> >>>>> <https://url.avanan.click/v2/r01/___https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmJhNDc6M2Y3MzFiOGMzNzA1MzBmY2I3NDg5MTNlMjFhMWE1NDFhYjhlMTAxM2NiODk1MmQ4ODg1MGQyNjQyZDg4MWIxNzpwOlQ6Rg>.
> >>>>> [TR] Yes.
> >>>>
> >>>> [rfced] Noted! We will include this change once we convert to RFCXML.
> >>>>
> >>>>> 17) <!-- [rfced] Would you like to make use of <sup> for
> >>>>> superscript in this document? In the HTML and PDF, it appears as 
> >>>>> superscript. In the text output, <sup> generates a^b, which was used in 
> >>>>> the original document. (Note that if you would like to use <sup>, we 
> >>>>> will make the update once the file is converted to RFCXML.)  Instances 
> >>>>> in document:
> >>>>> 2^{64}
> >>>>> 2^c
> >>>>> 2^{(128−c)/2}
> >>>>> 2^64
> >>>>> -->
> >>>>> [TR] Looks good, Thanks.
> >>>>
> >>>> [rfced] We will include these changes once we convert to RFCXML.
> >>>>
> >>>> Please review the contents of the document carefully. Contact us with 
> >>>> any further updates or with your approval of the document’s contents in 
> >>>> its current form. We will await approvals from each author prior to 
> >>>> moving forward with formatting updates.
> >>>>
> >>>> For details of the AUTH48 process in kramdown-rfc (including the 
> >>>> two-part approval process), see 
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmIyNGE6NTU0ZjZhYjVjNWQ0MzA4NGQ2MTIwYWRlMWJjZDlmMjkyNTIxM2ZkZTY0N2QwYWVhNmE0YzdlZDMyODE3MDE3NjpwOlQ6Rg.
> >>>>
> >>>> The files have been posted here (please refresh):
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958.txt___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmE3ODc6MWQ3ZDI4YzFhNzk4Mzk5M2VlY2UwY2VmYTI3ODU2YjI4OTUzOTBkN2E4MTAyZjAzMTA0MDcyYzhlMjZlYWZiMjpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmU4MmQ6MWU2MGZlMjMzMGRjNjM5ZDgyZDhiZDQzZWQ5YThjYTJiYmI4MzhmOGEzMzg5YTg3MmU3NWZhMGYxMzhhNmUxNzpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmVkZTk6Zjk2MzNkZjBjMTllYzE3YjMyMTViODAzOTc3MmE3OTU5ZDAzNTRkMjE3ZGVkZjViZjI4NTc3YjFkZDQ3M2ExODpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958.xml___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjQzNWM6NDczMDZlZGU0ZTc5OGU4ZjQ1MzMwNmM1OWU4ZmIyYzA0MTQwMDQ3MDIxNWQ0MmY5NTZkZTg5ZjkxMTg0MjZkYzpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958.md___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjdmNjk6ZjhiZGJmZTY2MDMxNTM2MzBjNDZlZmYzOTM3NjA1OWNiNDhhNWQ5OGM0MDU4ZDllMDY1NTNlOTExMGE5YWNjNDpwOlQ6Rg
> >>>>
> >>>> The relevant diff files have been posted here (please refresh):
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-diff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjQ3ZTI6OTIwOGNjM2NkZmU0MzI2MTlmZTE1NjQzZDE4OWMzZWIxOTNkNDJhN2ExZDc1MDhiMjQxNGYxNzUxZWE3Mzk3ODpwOlQ6Rg
> >>>> (comprehensive diff)
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-rfcdiff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmQ0OTA6YWFmOTk4OGZhMGRiZjkyMDM3MGJmODE1OTVkYzhjMzZkMWE1MDkyMmM1MjgyYTY5ZmI2NzhmMGU4MGE4ZmM1YjpwOlQ6Rg
> >>>>  (side by
> >>>> side)  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-auth48diff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjliOWM6Zjk4YzQ3NzJlYjhkMGEzNTczYjRjNzRmNDE5ZjEwZjA0Mzc0ZmUxODIxODc0ODhjNjhiMWY4NTE2YzkyY2FmZjpwOlQ6Rg
> >>>> (AUTH48 changes only)
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-auth48rfcdiff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjMzODQ6M2Q0NTc0NzQ1OTM4NDE3YjAwYzYyNDU1NTQ2NTFiNGQwYzNhNjQ2OGI4ODJkOWNhYTE1ZGE0MjJmMTllZTdiMzpwOlQ6Rg
> >>>>  (side
> >>>> by side)
> >>>>
> >>>> Markdown diffs:
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-md-diff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmQwMzk6MWE0MTc2ZmU5N2Y3YzU0OWRlMWVkNWU4MGVhYmNiMDE1MGVmMmMxNDYzOThkOGI3OGFiMjg4Y2QzYjgyMWMyYTpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-md-rfcdiff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OjhmM2E6MzAzYmY4ZWVmMzZkOTU4MDUxODI1MmQyYTI2Y2RjMGRhNjg2OGNlNzc0MTk4YTZlODE4ZDJjYzY4ZTQ3OTQwYTpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-md-auth48diff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmI3MTc6OGIxMmViYTRjZDQ2OGQyMDNmMjZjMzcyYjY3YjI5YmQ2MDI1ZjhkMjA3ZjU1NGRkODg5NmM0NjllMDI4NzgyZjpwOlQ6Rg
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/authors/rfc9958-md-auth48rfcdiff.html___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmRlMmE6NzMzMzkxZmVhYzdmMGY1MTA2Zjg1Mzc1MzE0N2ZkY2VlZjA0OWQ3MzQ5OTc1MGE4YzEzMzQ0ZDZiZjcxZTNlNzpwOlQ6Rg
> >>>>
> >>>> For the AUTH48 status of this document, please see:
> >>>>  
> >>>> https://url.avanan.click/v2/r01/___https://www.rfc-editor.org/auth48/rfc9958___.YXAzOmRpZ2ljZXJ0OmE6bzplYmE1Mzk0MzNkNjA0ZmRiNGE3ZjI3ZWI4YjNiYTc0ZDo3OmVmNDA6NDdhYzJlMDVlZWJkMGFiNWNiYzk1ZGUwMGI5MmU4ZTUyYmJiMzRiODhhMWI0NzY5ZjQ1NTc3NDdhOTI0NTkyYjpwOlQ6Rg
> >>>>
> >>>> Thank you!
> >>>> Madison Church
> >>>> RFC Production Center
> >>>>
> >>>>
> >>
> >
>


-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to