Hi Nimrod, IANA has made their updates, and we have converted the markdown file to RFCXML.
Please review the XML file and its TXT, HTML, and PDF outputs (included below) and let us know if any changes are required or if you approve the RFC for publication. Note that we will only make changes in the XML file moving forward. While this is your approval of the XML and its outputs, we consider this your final assent that the document is ready for publication. We will move the document forward in the publication process once we receive your final approval. This page shows the Final Review status of your document: https://queue.rfc-editor.org/final-review/rfc10015/ — FILES (please refresh): — XML file: https://www.rfc-editor.org/authors/rfc10015.xml Output files: https://www.rfc-editor.org/authors/rfc10015.txt https://www.rfc-editor.org/authors/rfc10015.html https://www.rfc-editor.org/authors/rfc10015.pdf These diff files show changes made during Final Review: https://www.rfc-editor.org/authors/rfc10015-diff.html https://www.rfc-editor.org/authors/rfc10015-rfcdiff.html (side by side) These diff files show all changes made from the approved I-D: https://www.rfc-editor.org/authors/rfc10015-diff.html https://www.rfc-editor.org/authors/rfc10015-rfcdiff.html (side by side) All the best, Kaelin Foody RFC Production Center > On Jul 1, 2026, at 10:11 AM, Kaelin Foody <[email protected]> wrote: > > Hi Amanda, > > The updates look great, thank you. > > All best, > > Kaelin Foody > RFC Production Center > >> On Jun 30, 2026, at 8:34 PM, Amanda Baber via RT <[email protected]> >> wrote: >> >> Hi, >> >> These missing updates are now complete: >> >> https://www.iana.org/assignments/tls-parameters >> >> thanks/apologies, >> Amanda >> >> On Tue Jun 30 15:28:36 2026, [email protected] wrote: >>> Hi IANA, >>> >>> Please make the following changes in the “TLS Cipher Suites” registry >>> at <https://www.iana.org/assignments/tls-parameters/tls- >>> parameters.xhtml#tls-parameters-4>. >>> >>> Please set the “Recommended” column to “D” and add this document as a >>> reference for the four entries below. (These entries appear in the >>> tables in Sections 5.1 and 5.2 of <https://auth48-transition.rfc- >>> editor.org/authors/rfc10015-diff.html> but were not updated.) >>> >>> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA >>> TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA >>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA >>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA >>> >>> Thanks, >>> >>> Kaelin Foody >>> RFC Production Center >>> >>>> On Jun 24, 2026, at 11:50 AM, Paul Wouters >>>> <[email protected]> wrote: >>>> >>>> ah, >>>> >>>> You right, since the document has these, a note to TLS is not needed. >>>> >>>> I find the table at https://github.com/rfc-editor-drafts/FinalReview- >>>> rfc10015/blob/RPC-edits/rfc10015.md#updates-to-rfc-9325-update-9325 >>>> to be clear, I would prefer it over https://auth48-transition.rfc- >>>> editor.org/authors/rfc10015-TEST.html#name-updates-to-rfc-9325 >>>> Paul >>>> >>>> On Tue, Jun 23, 2026 at 6:20 PM Rebecca VanRheenen >>>> <[email protected]> wrote: >>>> Hi Nimrod, >>>> >>>> We sent you an invite; once you accept, you should be able to open >>>> pull requests if needed. >>>> >>>> Thanks for reviewing the issues and for your comments. I’ve updated >>>> the RPC-edits PR accordingly. We now have two open issues — I have >>>> requested input from Paul Wouters on these. >>>> >>>> Thanks! >>>> >>>> Rebecca VanRheenen >>>> RFC Production Center >>>> >>>> >>>> >>>>> On Jun 23, 2026, at 7:57 AM, Nimrod Aviram >>>>> <[email protected]> wrote: >>>>> >>>>> Hi! :-) >>>>> >>>>> a. My github username is: >>>>> nimia >>>>> >>>>> c. I spotted a few minor issues and left comments, other than those >>>>> - LGTM. >>>>> >>>>> I reviewed the issues, most of which LGTM, and left comments. >>>>> >>>>> thanks, >>>>> Nimrod >>>>> >>>>> >>>>> On Tue, 23 Jun 2026 at 16:26, Paul Wouters <[email protected]> >>>>> wrote: >>>>> I believe all corrections and suggestions are correct, with the >>>>> exception of the "Inclusive Language" suggestion for the term >>>>> "premaster" term to be changed to something else. I believe it is >>>>> an unfortunate legacy term we need to keep for that reference (but >>>>> has been replaced in TLS 1.3 already) >>>>> >>>>> The Q12 CAMELLIA ones, I think should be added to the Recommended D >>>>> change set, as it is using the same KEX methods we are obsoleting >>>>> in this document. Perhaps that technically requires a quick note to >>>>> the TLS WG to formally confirm, but I'm sure no one would mind. >>>>> >>>>> Paul >>>>> >>>>> On Tue, Jun 23, 2026 at 6:29 AM Deb Cooley <[email protected]> >>>>> wrote: >>>>> I'm adding Paul Wouters to this chain. He was AD at the time this >>>>> draft entered the queue. >>>>> >>>>> Deb >>>>> >>>>> On Mon, Jun 22, 2026 at 8:10 PM <[email protected]> wrote: >>>>> Authors, >>>>> >>>>> While reviewing this document during Final Review, please resolve >>>>> (as necessary) >>>>> the following questions, which are also in GitHub issues >>>>> (see https://github.com/rfc-editor-drafts/FinalReview- >>>>> rfc10015/issues). >>>>> >>>>> >>>>> 1) <!-- [rfced] Please note that we updated "(D)TLS 1.2" in the >>>>> title of the document as follows. We retained "(D)TLS 1.2" in the >>>>> rest of the document. >>>>> >>>>> Original: >>>>> Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2 >>>>> >>>>> Updated: >>>>> Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2 >>>>> >>>>> We also updated the abbreviated title as follows to more closely >>>>> align with the document title. Note that the abbreviated title >>>>> appears in the running header at the top of each page in the PDF >>>>> output. >>>>> >>>>> Original: >>>>> Deprecating RSA and FFDH(E) >>>>> >>>>> Updated: >>>>> Deprecating Obsolete Key Exchanges in (D)TLS 1.2 >>>>> --> >>>>> >>>>> >>>>> 2) <!-- [rfced] Please review the following questions and changes >>>>> regarding the >>>>> references in this document: >>>>> >>>>> a) [ICA] The URL for this reference entry appears to be broken: >>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.704.7932&rep=rep1&type=pdf >>>>> >>>>> We found the following URL which appears to match the information >>>>> for this reference. May we update to use this URL? >>>>> https://link.springer.com/content/pdf/10.1007/978-3-319-24174- >>>>> 6_21.pdf. >>>>> >>>>> Current: >>>>> [ICA] Jager, T., Schwenk, J., and J. Somorovsky, "Practical >>>>> invalid curve attacks on TLS-ECDH", 21 September 2015, >>>>> <https://citeseerx.ist.psu.edu/viewdoc/ >>>>> download?doi=10.1.1.704.7932&rep=rep1&type=pdf>.] >>>>> >>>>> Perhaps: >>>>> [ICA] Jager, T., Schwenk, J., and J. Somorovsky, "Practical >>>>> invalid curve attacks on TLS-ECDH", SORICS 2015, Part I, >>>>> Lecture Notes in Computer Science, vol. 9326, pp. 407- >>>>> 425, >>>>> DOI 10.1007/978-3-319-24174-6_21, 21 September 2015, >>>>> <https://link.springer.com/content/ >>>>> pdf/10.1007/978-3-319-24174-6_21.pdf>. >>>>> >>>>> b) We have reformatted some of the reference entries to match the >>>>> information provided at the URLs for those entries. Please review >>>>> and let us >>>>> know if you have any objections. >>>>> >>>>> c) We have also added URLs to the following references and >>>>> formatted their >>>>> entries accordingly. Please review and let us know any objections. >>>>> >>>>> [BLEI] >>>>> [ROBOT] >>>>> [XPROT] >>>>> --> >>>>> >>>>> >>>>> 3) <!-- [rfced] Normative reference [I-D.ietf-tls-rfc8446bis] is >>>>> currently in Final Review as RFC 9846. We updated [I-D.ietf-tls- >>>>> rfc8446bis] to [PRE-RFC9846] for now. We will make the final >>>>> updates in RFCXML (i.e., remove "PRE-" in "PRE-RFC9846" and"PRE- >>>>> 9846"). This document will be published at the same time as or >>>>> after RFC 9846. >>>>> --> >>>>> >>>>> >>>>> 4) <!-- [rfced] Abstract: The abstract should be self-contained, so >>>>> we have removed the "i.e." phrase that contains section pointers. >>>>> >>>>> Original: >>>>> This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, >>>>> 5288, >>>>> 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, >>>>> to >>>>> deprecate or discourage - i.e., change to MUST NOT or SHOULD >>>>> NOT, as >>>>> listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, >>>>> and >>>>> Section 5.5 - the use of cipher suites using the above key >>>>> exchange >>>>> methods in (D)TLS 1.2 connections. >>>>> >>>>> Current (removed parenthetical): >>>>> This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, >>>>> 5289, >>>>> 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 >>>>> to >>>>> either deprecate or discourage the use of cipher suites using >>>>> the >>>>> above key exchange methods in (D)TLS 1.2 connections. >>>>> --> >>>>> >>>>> >>>>> 5) <!-- [rfced] We updated the RFCs listed in the "Updates:" field >>>>> in the first-page header to appear in ascending order (per Section >>>>> 4.1.4 of RFC 7322). We also updated the following text to remove >>>>> the duplicate "Section 5.3" and to list the RFCs in ascending >>>>> order. Please review and let us know any concerns. >>>>> >>>>> Original: >>>>> Updates: 9325, 4346, 5246, 4162, >>>>> 6347, 5932, >>>>> 5288, 6209, 6367, 8422, >>>>> 5289, 5469, >>>>> 4785, 4279, 5487, 6655, >>>>> 7905 (if >>>>> approved) >>>>> ... >>>>> This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, >>>>> 5288, >>>>> 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, >>>>> to >>>>> deprecate or discourage - i.e., change to MUST NOT or SHOULD >>>>> NOT, as >>>>> listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, >>>>> and >>>>> Section 5.5 - the use of cipher suites using the above key >>>>> exchange >>>>> methods in (D)TLS 1.2 connections. >>>>> ... >>>>> This document updates [RFC9325], [RFC4346], [RFC5246], >>>>> [RFC4162], >>>>> [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], >>>>> [RFC8422], >>>>> [RFC5289], [RFC4785], [RFC4279], [RFC5487], [RFC6655], [RFC7905] >>>>> and >>>>> [RFC5469] to remediate the above problems, by deprecating and >>>>> discouraging the use of affected cipher suites, as listed in >>>>> Section 5.3 Section 5.2 Section 5.3 Section 5.4 Section 5.5. >>>>> >>>>> Current: >>>>> Updates: 4162, 4279, 4346, 4785, >>>>> 5246, 5288, >>>>> 5289, 5469, 5487, 5932, >>>>> 6209, 6347, >>>>> 6367, 6655, 7905, 8422, 9325 >>>>> ... >>>>> This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, >>>>> 5289, >>>>> 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 >>>>> to >>>>> either deprecate or discourage the use of cipher suites >>>>> using the above key exchange methods in (D)TLS 1.2 connections. >>>>> ... >>>>> This document updates [RFC4162], [RFC4279], [RFC4346], >>>>> [RFC4785], >>>>> [RFC5246], [RFC5288], [RFC5289], [RFC5469], [RFC5487], >>>>> [RFC5932], >>>>> [RFC6209], [RFC6347], [RFC6367], [RFC6655], [RFC7905], >>>>> [RFC8422], and >>>>> [RFC9325] to remediate the above problems, by deprecating and >>>>> discouraging the use of affected cipher suites, as listed in >>>>> Sections >>>>> 5.2, 5.3, 5.4, and 5.5. >>>>> --> >>>>> >>>>> >>>>> 6) <!-- [rfced] Will readers know what "D" in the "Recommended" >>>>> column means? Would adding a short explanation of "D" be helpful? >>>>> >>>>> The following sentence currently appears in Section 7 (IANA >>>>> Considerations), but "D" is first mentioned in Section 5: >>>>> >>>>> Current (IANA Considerations): >>>>> For information about >>>>> the use of "D" in the "Recommended" column, see [RFC9847]. >>>>> >>>>> Perhaps similar text could be placed at the beginning of Section 5 >>>>> as shown below. Let us know your thoughts. >>>>> >>>>> Perhaps: >>>>> 5. Updates to Cipher Suites and TLS ClientCertificateType >>>>> Identifiers >>>>> >>>>> The following subsections mention the use of "D" in the >>>>> "Recommended" >>>>> column of the "TLS Cipher Suites" and "TLS ClientCertificateType >>>>> Identifiers" registries [TLS-REGISTRY]. See [RFC9847] for >>>>> information >>>>> on the use of the "D". >>>>> --> >>>>> >>>>> >>>>> 7) <!-- [rfced] Please insert any keywords (beyond those that >>>>> appear in >>>>> the title) for use on https://www.rfc-editor.org/search. >>>>> --> >>>>> >>>>> >>>>> 8) <!-- [rfced] Should "are already marked" be updated to "were >>>>> previously marked"? >>>>> >>>>> Original: >>>>> Note that these cipher suites >>>>> are already marked as not recommended in the "TLS Cipher Suites" >>>>> registry [tls-registry]. >>>>> >>>>> Perhaps: >>>>> Note that these cipher suites were previously >>>>> marked as not recommended in the "TLS Cipher Suites" registry >>>>> [TLS-REGISTRY]. >>>>> --> >>>>> >>>>> >>>>> 9) <!-- [rfced] Would adding a section pointer be helpful in the >>>>> second sentence below to indicate where the document "records the >>>>> rationale" and "cites prior analyses"?" If so, is "Section 7" >>>>> correct? >>>>> >>>>> Original: >>>>> This document updates them to "Recommended: D" to >>>>> align with [I-D.ietf-tls-rfc8447bis]. It also records the >>>>> rationale >>>>> for discouraging use of these cipher suites, and cites prior >>>>> analyses >>>>> and attacks that demonstrate the associated risks. >>>>> >>>>> Perhaps: >>>>> This document updates them to have "D" in the "Recommended" >>>>> column to >>>>> align with [RFC9847]. This document also records the rationale >>>>> for discouraging use of these cipher suites, and it cites prior >>>>> analyses >>>>> and attacks that demonstrate the associated risks (see Section >>>>> 7). >>>>> --> >>>>> >>>>> >>>>> 10) <!-- [rfced] Table 6 in Section 6 >>>>> >>>>> To apply the updates in Table 6 while looking at https://www.rfc- >>>>> editor.org/rfc/rfc9325.html#section-4.1, the reader may have >>>>> difficulty determining exactly what text is being updated/added. >>>>> For clarity, we suggest replacing Table 6 with OLD/NEW text. >>>>> >>>>> We created the following test file to illustrate the use of OLD/NEW >>>>> text in Section 6 (but please review closely for accuracy if you >>>>> choose to go with this as we are not certain we captured the >>>>> intent): >>>>> >>>>> https://www.rfc-editor.org/authors/rfc10015-TEST.html#name-updates- >>>>> to-rfc-9325 >>>>> https://www.rfc-editor.org/authors/rfc10015-TEST.txt >>>>> --> >>>>> >>>>> >>>>> 11) <!-- [rfced] We have updated the text in the IANA >>>>> Considerations section as follows. Let us know any objections. >>>>> >>>>> Original: >>>>> This document requests IANA to mark the cipher suites from the >>>>> "TLS >>>>> Cipher Suites" registry [tls-registry], under "Transport La<yer >>>>> Security (TLS) Parameters" registry group, listed in Section >>>>> 5.1, >>>>> Section 5.2, Section 5.3, Section 5.4, and the certificate types >>>>> from >>>>> the "TLS ClientCertificateType Identifiers" registry listed in >>>>> Section 5.5 as "D" in the "Recommended" column, see >>>>> [I-D.ietf-tls-rfc8447bis]. >>>>> >>>>> For each registry entry in Section 5.1, Section 5.2, Section 5.3, >>>>> Section 5.4, and Section 5.5, IANA is also requested to update the >>>>> registry entry's Reference column to refer to this document. >>>>> >>>>> Updated: >>>>> The "TLS Cipher Suites" and "TLS ClientCertificateType >>>>> Identifiers" >>>>> registries both appear within the "Transport Layer Security >>>>> (TLS) >>>>> Parameters" registry group [TLS-REGISTRY]. IANA has updated >>>>> entries >>>>> in the "TLS Cipher Suites" registry [TLS-REGISTRY] as indicated >>>>> in >>>>> Sections 5.1, 5.2, 5.3, and 5.4. IANA has also updated entries >>>>> in >>>>> the "TLS ClientCertificateType Identifiers" registry as >>>>> indicated in >>>>> Section 5.5. >>>>> >>>>> For each entry listed in Sections 5.1, 5.2, 5.3, 5.4, and 5.5, IANA >>>>> has set the "Recommended" column to "D" and updated the entry's >>>>> Reference column to refer to this document. For information about >>>>> the use of "D" in the "Recommended" column, see [RFC9847]. >>>>> --> >>>>> >>>>> >>>>> 12) <!-- [rfced] Mismatch between document and IANA registries >>>>> >>>>> a) We note that the following values are listed in the document >>>>> (first two in Section 5.1 and last two in Section 5.2): >>>>> >>>>> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA >>>>> TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA >>>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA >>>>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA >>>>> >>>>> However, in the "TLS Cipher Suites" registry (see >>>>> https://www.iana.org/assignments/tls-parameters/tls- >>>>> parameters.xhtml#tls-parameters-4), the entries for these do not >>>>> have the "Recommended" column set to "D" and do not include this >>>>> document as a reference. Should the entries in the registry be >>>>> updated? If so, we will request that IANA update the registry prior >>>>> to publication. >>>>> >>>>> >>>>> b) We also see discrepancies in the references for the following >>>>> entries in the tables in Sections 5.1, 5.3, and 5.4 when compared >>>>> to the references listed in the "TLS Cipher Suites" registry. >>>>> Should the references listed in the document be updated to match >>>>> the "TLS Cipher Suites" registry? >>>>> >>>>> TLS_DH_DSS_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_DH_RSA_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_DH_anon_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_DHE_DSS_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] [RFC8996] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_DHE_RSA_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] [RFC8996] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_RSA_WITH_DES_CBC_SHA >>>>> Document: [RFC5469] [RFC8996] >>>>> IANA registry: [RFC8996] >>>>> >>>>> TLS_RSA_WITH_IDEA_CBC_SHA >>>>> Document: [RFC5469] [RFC8996] >>>>> IANA registry: [RFC8996] >>>>> >>>>> >>>>> c) We see a similar discrepancies with references for the entries >>>>> in the table in Section 5.5 when compared to the "TLS >>>>> ClientCertificateType Identifiers" registry" >>>>> (https://www.iana.org/assignments/tls-parameters/tls- >>>>> parameters.xhtml#tls-parameters-2). It seems that "[RFC9847]" has >>>>> been added in the registry but not in the document. Should the >>>>> references listed in the document be updated to match the "TLS >>>>> Cipher Suites" registry? >>>>> >>>>> rsa_fixed_dh (3) >>>>> Document: [RFC5246] >>>>> IANA registry: [RFC5246][RFC9847] >>>>> >>>>> dss_fixed_dh (4) >>>>> Document: [RFC5246] >>>>> IANA registry: [RFC5246][RFC9847] >>>>> >>>>> rsa_fixed_ecdh (65) >>>>> Document: [RFC8422] >>>>> IANA registry: [RFC8422][RFC9847] >>>>> >>>>> ecdsa_fixed_ecdh (66) >>>>> Document: [RFC8422] >>>>> IANA registry: [RFC8422][RFC9847] >>>>> --> >>>>> >>>>> >>>>> 13) <!-- [rfced] We see both "cipher suite" (open) and >>>>> "ciphersuite" (closed) used in the document. We updated to the use >>>>> the open form (except in a couple of reference entries) as that is >>>>> most common in the document. Let us know any concerns. >>>>> --> >>>>> >>>>> >>>>> 14) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>> the online >>>>> Style Guide <https://www.rfc- >>>>> editor.org/styleguide/part2/#inclusive_language> >>>>> 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 "premaster" should be updated >>>>> in the text below: >>>>> >>>>> Original: >>>>> However, Raccoon revealed that timing side channels in processing >>>>> TLS >>>>> premaster secrets may be exploited to reveal the encrypted >>>>> premaster >>>>> secret. >>>>> --> >>>>> >>>>> Thank you. >>>>> >>>>> Kaelin Foody and Rebecca VanRheenen >>>>> RFC Production Center >>>>> >>>>> >>>>> >>>>> On Jun 22, 2026, at 5:07 PM, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Your document has now entered Final Review (previously AUTH48). >>>>> >>>>> The document was edited in kramdown-rfc as part of the RPC pilot >>>>> test (see >>>>> https://www.rfc- >>>>> editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). >>>>> >>>>> Final Review is being handled in GitHub as part of the GitHub pilot >>>>> test >>>>> (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github- >>>>> phase-0-pilot-test). >>>>> >>>>> Your document is available for review at: >>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10015 >>>>> >>>>> Please do the following: >>>>> >>>>> a) provide your GitHub username so that we can send you an invite >>>>> to join the repo >>>>> as a collaborator. At minimum, we need a GitHub username for Nimrod >>>>> Aviram (author). >>>>> We can also send invites to Joseph Salowey (document shepherd), >>>>> Deirdre Connolly >>>>> (WG chair), and Sean Turner (WG chair). We have already sent one to >>>>> Deb Cooley (AD). >>>>> >>>>> b) see the README for details on the Final Review process: >>>>> https://github.com/rfc-editor-drafts/FinalReview- >>>>> rfc10015/blob/Approved/README.md >>>>> >>>>> c) review the edits in the RPC-edits pull request: >>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10015/pulls >>>>> >>>>> d) address the issues: >>>>> https://github.com/rfc-editor-drafts/FinalReview-rfc10015/issues >>>>> >>>>> Once the content of the .md file is stable, we will convert it to >>>>> .xml >>>>> and provide the .html, .pdf, .txt, and .xml files for review. >>>>> >>>>> You and your coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Once the document has been reviewed and approved by all of the >>>>> authors, >>>>> it will be published as an RFC. If an author is no longer >>>>> available, >>>>> there are several remedies; see the Unavailable Authors section >>>>> (https://authors.ietf.org/rfc-publication-process#unavailable- >>>>> authors). >>>>> >>>>> Details on the status of your Final Review are here: >>>>> https://queue.rfc-editor.org/final-review/rfc10015/ >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Production Center >>>>> >>>>> -------------------------------------- >>>>> RFC 10015 (draft-ietf-tls-deprecate-obsolete-kex) >>>>> >>>>> Title : Deprecating Obsolete Key Exchange Methods in >>>>> (D)TLS 1.2 >>>>> Author(s) : N. Aviram >>>>> WG Chair(s) : Joseph Salowey, Sean Turner, Deirdre Connolly >>>>> Area Director(s) : Deb Cooley, Christopher Inacio >>>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
