Re: [auth48] [Ben] AUTH48: RFC-to-be 9382 <draft-irtf-cfrg-spake2-26> for your review

[Alanna Paloma <[e-mail]>]

Hi Ben,

This is another reminder that we await your updates to this document prior to moving forward with the publication process.

Thank you,
RFC Editor/ap

> On Aug 21, 2023, at 10:16 AM, Alanna Paloma <[e-mail]> wrote:
> 
> Hi Ben,
> 
> This reminder that we await your updates to this document before moving forward with the publication process.
> 
> Thank you,
> RFC Editor/ap
> 
>> On Aug 14, 2023, at 9:48 AM, Alanna Paloma <[e-mail]> wrote:
>> 
>> Hi Ben,
>> 
>> This is friendly reminder that we await your suggested updates to this document before continuing forward with the publication process.
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>>> On Aug 4, 2023, at 1:41 PM, Sandy Ginoza <[e-mail]> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Great - thanks for letting us know!  We will wait to hear from you.
>>> 
>>> Thanks!
>>> Sandy 
>>> 
>>>> On Aug 4, 2023, at 1:27 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>> 
>>>> Hi Sandy,
>>>> 
>>>> I looked through the diff last week and found some edits to make (at least one
>>>> where an added comma changed the meaning).
>>>> 
>>>> I'm queued up to read through the rendered doc maybe next week and plan to
>>>> batch all suggested edits together.
>>>> 
>>>> Thanks,
>>>> 
>>>> Ben
>>>> 
>>>> On Fri, Aug 04, 2023 at 01:21:44PM -0700, Sandy Ginoza wrote:
>>>>> Hi Ben,
>>>>> 
>>>>> This is a friendly reminder that we await your review.  Note that your coauthor has approved the document for publication. 
>>>>> 
>>>>> Colin and Stanislav, we have not heard from Ben since mid-June.  Please consider whether you would like to approve the document in Ben’s absence if we do not hear from him (see https://www.rfc-editor.org/faq/#missingauthor).  
>>>>> 
>>>>> The files are available here: 
>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>> 
>>>>> AUTH48 diff: 
>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html
>>>>> 
>>>>> Comprehensive diffs: 
>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9382-rfcdiff.html
>>>>> 
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/sg
>>>>> 
>>>>> 
>>>>>> On Jul 12, 2023, at 8:56 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Ben,
>>>>>> 
>>>>>> Please let us know if you plan to review the document or if you would like to select one of the options that Stanislav has mentioned below.
>>>>>> 
>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/ap
>>>>>> 
>>>>>>> On Jul 5, 2023, at 9:15 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Ben,
>>>>>>> 
>>>>>>> This is another friendly reminder that we await your choice regarding the two options that Stanislav has outlined below.
>>>>>>> 
>>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>> 
>>>>>>> Once you have made your choice, we will move this document forward in the publication process.
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> RFC Editor/ap
>>>>>>> 
>>>>>>>> On Jun 28, 2023, at 9:12 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi Ben,
>>>>>>>> 
>>>>>>>> This is a friendly reminder that we await your choice of the options outlined by Stanislav:
>>>>>>>> 
>>>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> RFC Editor/ap
>>>>>>>> 
>>>>>>>>> On Jun 19, 2023, at 3:59 PM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Ben,
>>>>>>>>> 
>>>>>>>>> This is another friendly reminder that we await your choice regarding the two options that Stanislav has outlined below.
>>>>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> RFC Editor/ap
>>>>>>>>> 
>>>>>>>>>> On Jun 12, 2023, at 12:19 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Allana, Stanislav,
>>>>>>>>>> 
>>>>>>>>>> I think my schedule is going to open up around Thursday this week; I will aim
>>>>>>>>>> to take a closer look at the document and choose an option then.
>>>>>>>>>> 
>>>>>>>>>> Sorry for all the delays,
>>>>>>>>>> 
>>>>>>>>>> Ben
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jun 12, 2023 at 10:05:28AM -0700, Alanna Paloma wrote:
>>>>>>>>>>> Hi Ben,
>>>>>>>>>>> 
>>>>>>>>>>> This is a friendly reminder that we await your choice regarding the two options that Stanislav has outlined below.
>>>>>>>>>>> 
>>>>>>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Jun 5, 2023, at 6:19 AM, Stanislav V. Smyshlyaev <[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Dear Ben,
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you please choose between the two options (or suggest that we do something else if some other actions look better)?
>>>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Stanislav (for CFRG chairs)
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Jun 2, 2023 at 8:09 AM Stanislav V. Smyshlyaev <[e-mail]> wrote:
>>>>>>>>>>>> Hi Ben,
>>>>>>>>>>>> 
>>>>>>>>>>>> As I understand, essentially we have two options now:
>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it allows Alanna to finish the AUTH48 and move the document forward immediately.
>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the Contributors section.
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you please choose between these two options?
>>>>>>>>>>>> 
>>>>>>>>>>>> P.S.: Another option, following the IESG Statement on AUTH48 (see https://www.ietf.org/about/groups/iesg/statements/auth48/), seems to be inapplicable now, since you have responded.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Stanislav
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Jun 2, 2023 at 7:30 AM Benjamin Kaduk <[e-mail]> wrote:
>>>>>>>>>>>> Hi Alanna,
>>>>>>>>>>>> 
>>>>>>>>>>>> I had replied to Chris Wood on a separate thread, but I'm in the process of
>>>>>>>>>>>> moving house and will not be able to do anything useful with this document for
>>>>>>>>>>>> another week or so.
>>>>>>>>>>>> 
>>>>>>>>>>>> That said, I'm also not strongly attached to my name appearing on it, so if
>>>>>>>>>>>> there is reason to publish quickly I'm willing to be demoted to a contributor
>>>>>>>>>>>> or something.
>>>>>>>>>>>> 
>>>>>>>>>>>> -Ben
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Jun 01, 2023 at 02:08:18PM -0700, Alanna Paloma wrote:
>>>>>>>>>>>>> Hi Stanislav,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We have not yet heard from Ben Kaduk regarding this document's readiness for publication. Please consider whether you would like to approve in Ben's absence (see https://www.rfc-editor.org/faq/#missingauthor).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On May 25, 2023, at 8:41 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Ben,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This is a friendly reminder that we await your approval prior to moving this document forward in the publication process.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff between last version and this)
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff diff between last version and this)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On May 17, 2023, at 8:20 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi Ben,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Just a reminder that we await your approval prior to moving this document forward in the publication process.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff between last version and this)
>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff diff between last version and this)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On May 10, 2023, at 11:00 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Ben,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> This is a friendly reminder that we await your approval prior to moving this document forward in the publication process.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff between last version and this)
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff diff between last version and this)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On May 3, 2023, at 9:53 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hi Stanislav and Watson,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thank you for your replies. We have removed the parenthetical text. The change can be see in the files below (please refresh your browser).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff between last version and this)
>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff diff between last version and this)
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On May 3, 2023, at 9:35 AM, Stanislav V. Smyshlyaev <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> No objections from me either. 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Stanislav 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, 3 May 2023 at 20:33, Watson Ladd <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>> Yes, I think that's a good idea.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, May 3, 2023 at 8:49 AM Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Hi Watson, Ben, and Stanislav,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Per feedback from Eliot Lear re. companion document RFC-to-be 9383, may we remove the parenthetical “(set up the protocol”) from the diagram in Section 3.1?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On May 2, 2023, at 10:16 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> So, this really is editorial.  The correction that Watson suggested is just fine, and consistency is useful.  But if it's possibly to consistently remove across both, that would be good.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On May 2, 2023, at 8:58 AM, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Hi Stanislav, Watson, and Ben,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> We have noted Stanislav’s and Watson’s approvals on the AUTH48 status page:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Additionally, we have updated “therefore prevent” to “therefore prevents”, per the nit pointed out by Watson.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 4:45 PM, Watson Ladd <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Section 3.2
>>>>>>>>>>>>>>>>>>>>> OLD:  "Including this list would ensure that both parties agree upon the
>>>>>>>>>>>>>>>>>>>>> same set of supported protocols and therefore prevent downgrade
>>>>>>>>>>>>>>>>>>>>> attacks."
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> NEW: "Including this list would ensure that both parties agree upon the
>>>>>>>>>>>>>>>>>>>>> same set of supported protocols and therefore prevents downgrade attacks"
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> NOTE: this changes the subject from the parties to the inclusion. The
>>>>>>>>>>>>>>>>>>>>> difference is the s on prevents.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> After that nit we can consider the document APPROVED.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The latest files are posted here. Please refresh your browser:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff between last version and this)
>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff diff between last version and this)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> We will await any further changes you may have and approval from Ben prior to moving this document forward in the publication process.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 8:21 PM, Stanislav V. Smyshlyaev <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Dear Alanna,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thank you, I approve the changes.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Tue, 2 May 2023 at 03:21, Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>> Watson, Stanislav*,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> *Stanislav - As Document Shepherd, please review the following changes and let us know if you approve. They can be seen in this file: https://www.rfc-editor.org/authors/rfc9382-auth48diff.html
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 1) Section 3.3: updated text
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>> This prevents man-in-the-middle attackers from inserting themselves into
>>>>>>>>>>>>>>>>>>>>> the exchange.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>>>>>>> This use of the transcript ensures any manipulation of the messages sent
>>>>>>>>>>>>>>>>>>>>> is reflected in the keys.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 2) Section 9.2: added informative reference
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> [NIST.SP.800-56Ar3]
>>>>>>>>>>>>>>>>>>>>> National Institute of Standards and Technology,
>>>>>>>>>>>>>>>>>>>>> "Recommendation for Pair-Wise Key-Establishment Schemes
>>>>>>>>>>>>>>>>>>>>> Using Discrete Logarithm Cryptography", Revision 3, NIST
>>>>>>>>>>>>>>>>>>>>> Special Publication 800-56A,
>>>>>>>>>>>>>>>>>>>>> DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
>>>>>>>>>>>>>>>>>>>>> <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 3) Appendix B: added sentence
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>>>>>>> Line breaks have been added due to line-length limitations.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Watson - Thank you for the quick reply. We have updated the files accordingly.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> The latest files are posted here. Please refresh your browser:
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (last version to this one)
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 1:53 PM, Watson Ladd <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On Mon, May 1, 2023, 1:24 PM Alanna Paloma <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Hi Watson,
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Thank you for your reply. We have updated the files accordingly. Please note that we have some follow-up queries and notes.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 1) Regarding your response to the query below, should this reference be listed as a normative or informative reference?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Informative
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 10) <!--[rfced] Should this sentence include a citation after "NIST.SP.800-56Ar3"?
>>>>>>>>>>>>>>>>>>>>>>>>> If so, please provide the reference information.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> Standards such as NIST.SP.800-56Ar3
>>>>>>>>>>>>>>>>>>>>>>>>> suggest taking mod p of a hash value that is 64 bits longer than that
>>>>>>>>>>>>>>>>>>>>>>>>> needed to represent p to remove statistical bias introduced by the
>>>>>>>>>>>>>>>>>>>>>>>>> modulation.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Yes it should. citation information Barker, E. , Chen, L. , Roginsky,
>>>>>>>>>>>>>>>>>>>>>>>> A. , Vassilev, A. and Davis, R. (2018), Recommendation for Pair-Wise
>>>>>>>>>>>>>>>>>>>>>>>> Key-Establishment Schemes Using Discrete Logarithm Cryptography,
>>>>>>>>>>>>>>>>>>>>>>>> Special Publication (NIST SP), National Institute of Standards and
>>>>>>>>>>>>>>>>>>>>>>>> Technology, Gaithersburg, MD, [online],
>>>>>>>>>>>>>>>>>>>>>>>> https://doi.org/10.6028/NIST.SP.800-56Ar3
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 2) Please carefully review the updated line breaks in the test vectors in Appendix B and let us know if further updates are necessary.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> spake2: A='server', B='client'
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> There seems to be a spurious
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 123456789012345678901234567890123456789012345678901234567890123456789012
>>>>>>>>>>>>>>>>>>>>>> after TT and then an empty line before HASH(TT),
>>>>>>>>>>>>>>>>>>>>>> unlike the others. This should be removed. (Was in the original and I
>>>>>>>>>>>>>>>>>>>>>> didn't see it).
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 3) FYI, we have made the following updates in Section 6 to reflect RFC 9383.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>> For P256:
>>>>>>>>>>>>>>>>>>>>>>> For P384:
>>>>>>>>>>>>>>>>>>>>>>> For P521:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>>>>>>>>> For P-256:
>>>>>>>>>>>>>>>>>>>>>>> For P-384:
>>>>>>>>>>>>>>>>>>>>>>> For P-521:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> SGTM
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48 changes)
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (last version to this one)
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> One more version, and then I will take a very careful look and likely
>>>>>>>>>>>>>>>>>>>>>> approve unless I see anything else.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 9:11 AM, Watson Ladd <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Here is the response to the questions. Apologies for the delays
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 4, 2023 at 1:07 AM <[e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Authors,
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 1) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743
>>>>>>>>>>>>>>>>>>>>>>>>> have been adhered to in this document.  -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> They have been.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 2) <!--[rfced] May we update the title as follows?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> SPAKE2, a PAKE
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> Symmetric Password-Authenticated Key Exchange (SPAKE2)
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> How about "SPAKE2, a Password-Authenticated Key Exchange"?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 4) <!--[rfced] FYI, we have expanded "SPAKE2" as "symmetric password-authenticated
>>>>>>>>>>>>>>>>>>>>>>>>> key exchange".  Please let us know if you prefer otherwise.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer to leave it as SPAKE2: there are many symmetric
>>>>>>>>>>>>>>>>>>>>>>>> password-authenticated key exchanges out there.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> This document describes SPAKE2 which is a protocol for two parties
>>>>>>>>>>>>>>>>>>>>>>>>> that share a password to derive a strong shared key without
>>>>>>>>>>>>>>>>>>>>>>>>> disclosing the password.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>>>>>>>>>>> This document describes the symmetric password-authenticated key exchange (SPAKE2),
>>>>>>>>>>>>>>>>>>>>>>>>> which is a protocol for two parties that share a password to derive a strong
>>>>>>>>>>>>>>>>>>>>>>>>> shared key without disclosing the password.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 5) <!--[rfced] For clarity, may we update this sentence as follows?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> Applications that need a symmetric PAKE (password authenticated key exchange)
>>>>>>>>>>>>>>>>>>>>>>>>> and where hashing onto an elliptic curve at execution time is not
>>>>>>>>>>>>>>>>>>>>>>>>> possible can use SPAKE2.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> Applications that need a symmetric PAKE, but are unable to hash onto an
>>>>>>>>>>>>>>>>>>>>>>>>> elliptic curve at execution time, can use SPAKE2.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Sounds good
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 6) <!--[rfced] Section 3.1: Does "setup protocol" mean
>>>>>>>>>>>>>>>>>>>>>>>>> "the setup protocol" or "set up the protocol"?  We ask
>>>>>>>>>>>>>>>>>>>>>>>>> because the other items in the diagrams (of this document
>>>>>>>>>>>>>>>>>>>>>>>>> and RFC-to-be 9383) start with verbs ("compute", "derive",
>>>>>>>>>>>>>>>>>>>>>>>>> and "check").
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>>    |       (setup protocol)    |
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>>    |   (set up the protocol)   |
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> FYI, your reply to this question will be discussed with the
>>>>>>>>>>>>>>>>>>>>>>>>> authors of RFC-to-be 9383 because that document also
>>>>>>>>>>>>>>>>>>>>>>>>> uses "setup protocol" in a diagram in Section 3.1.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Set up the protocol is clearer, let's do that.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 7) <!--[rfced] FYI, we have updated "gap Diffie-Hellman" to "GDH"
>>>>>>>>>>>>>>>>>>>>>>>>> when it appears after the initial expansion.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> SGTM
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 8) <!--[rfced] May we point directly to Table 1 in these two sentences from
>>>>>>>>>>>>>>>>>>>>>>>>> Section 3.2 and Appendix A? FYI, "Table 1" will be a link in the
>>>>>>>>>>>>>>>>>>>>>>>>> HTML and PDF outputs.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> We fix two elements M and N in
>>>>>>>>>>>>>>>>>>>>>>>>> the prime-order subgroup of G as defined in the table in this
>>>>>>>>>>>>>>>>>>>>>>>>> document for common groups, as well as a generator P of the (large)
>>>>>>>>>>>>>>>>>>>>>>>>> prime-order subgroup of G.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> We fix two elements, M and N, in
>>>>>>>>>>>>>>>>>>>>>>>>> the prime-order subgroup of G, as defined in Table 1 of this
>>>>>>>>>>>>>>>>>>>>>>>>> document for common groups, as well as generator P of the (large)
>>>>>>>>>>>>>>>>>>>>>>>>> prime-order subgroup of G.
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> This section describes the algorithm that was used to generate the
>>>>>>>>>>>>>>>>>>>>>>>>> points M and N in the table in Section 6.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> This section describes the algorithm that was used to generate
>>>>>>>>>>>>>>>>>>>>>>>>> points M and N in Table 1.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> SGTM.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 9) <!--[rfced] Should "intermediate keying material (IKM)" be changed to
>>>>>>>>>>>>>>>>>>>>>>>>> "input keying material (IKM)" as in RFC 5869 (which is cited in both this
>>>>>>>>>>>>>>>>>>>>>>>>> document and RFC-to-be 9383)?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> KDF(ikm, salt, info, L) is a key-derivation function that takes as
>>>>>>>>>>>>>>>>>>>>>>>>> input a salt, intermediate keying material (IKM), ...
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> FYI, your reply to this question will be discussed with the authors
>>>>>>>>>>>>>>>>>>>>>>>>> of RFC-to-be 9383 because it also uses "intermediate".
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Yes it should be.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 10) <!--[rfced] Should this sentence include a citation after "NIST.SP.800-56Ar3"?
>>>>>>>>>>>>>>>>>>>>>>>>> If so, please provide the reference information.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> Standards such as NIST.SP.800-56Ar3
>>>>>>>>>>>>>>>>>>>>>>>>> suggest taking mod p of a hash value that is 64 bits longer than that
>>>>>>>>>>>>>>>>>>>>>>>>> needed to represent p to remove statistical bias introduced by the
>>>>>>>>>>>>>>>>>>>>>>>>> modulation.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Yes it should. citation information Barker, E. , Chen, L. , Roginsky,
>>>>>>>>>>>>>>>>>>>>>>>> A. , Vassilev, A. and Davis, R. (2018), Recommendation for Pair-Wise
>>>>>>>>>>>>>>>>>>>>>>>> Key-Establishment Schemes Using Discrete Logarithm Cryptography,
>>>>>>>>>>>>>>>>>>>>>>>> Special Publication (NIST SP), National Institute of Standards and
>>>>>>>>>>>>>>>>>>>>>>>> Technology, Gaithersburg, MD, [online],
>>>>>>>>>>>>>>>>>>>>>>>> https://doi.org/10.6028/NIST.SP.800-56Ar3
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 11) <!--[rfced] We are having some difficulty parsing this sentence. How should
>>>>>>>>>>>>>>>>>>>>>>>>> it be updated?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> This variant MUST be used when it is not possible to determine which
>>>>>>>>>>>>>>>>>>>>>>>>> of A and B should use M or N, due to asymmetries in the protocol
>>>>>>>>>>>>>>>>>>>>>>>>> flows or the desire to use only a single shared secret with nil
>>>>>>>>>>>>>>>>>>>>>>>>> identities for authentication.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> This variant MUST be used when it is not possible to determine whether
>>>>>>>>>>>>>>>>>>>>>>>>> A or B should use M or N, due to asymmetries in the protocol
>>>>>>>>>>>>>>>>>>>>>>>>> flows or the desire to use only a single shared secret with nil
>>>>>>>>>>>>>>>>>>>>>>>>> identities for authentication.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I think the second is clearer.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 12) <!-- [rfced] Would you like the references to be alphabetized
>>>>>>>>>>>>>>>>>>>>>>>>> or left in their current order?
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Alphebetized please
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 13) <!-- [rfced] The following reference is not cited in the text.  Please
>>>>>>>>>>>>>>>>>>>>>>>>> let us know where it should be cited or if it should be deleted from
>>>>>>>>>>>>>>>>>>>>>>>>> the References section.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> [TDH]      Cash, D., Kiltz, E., and V. Shoup, "The Twin-Diffie
>>>>>>>>>>>>>>>>>>>>>>>>> Hellman Problem and Applications", 2008.  EUROCRYPT 2008.
>>>>>>>>>>>>>>>>>>>>>>>>> Volume 4965 of Lecture notes in Computer Science, pages
>>>>>>>>>>>>>>>>>>>>>>>>> 127-145.  Springer-Verlag, Berlin, Germany.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I think it should be removed.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 14) <!--[rfced] Should "the table below" be changed to "Table 1"?
>>>>>>>>>>>>>>>>>>>>>>>>> We note that no table appears below this sentence from Appendix A.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> For each curve in the table below, we construct a string using the
>>>>>>>>>>>>>>>>>>>>>>>>> curve OID from [RFC5480] (as an ASCII string) or its name, combined
>>>>>>>>>>>>>>>>>>>>>>>>> with the needed constant...
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> It should be table 1.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 15) <!-- [rfced] Appendix A: FYI, due to the line-length limitation of
>>>>>>>>>>>>>>>>>>>>>>>>> 69 characters within the sourcecode element, we have added a line break
>>>>>>>>>>>>>>>>>>>>>>>>> as follows. Please let us know if would like to change the indentation.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> hashes = [iterated_hash(seed, i) for i in range(start, start + n)]
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Current:
>>>>>>>>>>>>>>>>>>>>>>>>> hashes = [iterated_hash(seed, i)
>>>>>>>>>>>>>>>>>>>>>>>>>  for i in range(start, start + n)]
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> That works.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 16) <!--[rfced] The test vectors in Appendix B.1 include lines that exceed
>>>>>>>>>>>>>>>>>>>>>>>>> the 72-character limit. Please let us know where to insert line breaks.
>>>>>>>>>>>>>>>>>>>>>>>>> To summarize the line-length limitations:
>>>>>>>>>>>>>>>>>>>>>>>>> * 72 characters for artwork elements. (Note: in the text output,
>>>>>>>>>>>>>>>>>>>>>>>>> the renderer will "outdent" into the left margin for artwork
>>>>>>>>>>>>>>>>>>>>>>>>> that is over 69 characters.)
>>>>>>>>>>>>>>>>>>>>>>>>> * 69 characters for sourcecode elements.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> For example, may they simply be wrapped at 72 chars as follows?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Simple wrapping will be fine, but best would be to wrap always an even
>>>>>>>>>>>>>>>>>>>>>>>> number of characters.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> Hash(TT) = 0x0e0672dc86f8e45565d338b0540abe6915bdf72e2b35b5c9e5663168e960a91b
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I think
>>>>>>>>>>>>>>>>>>>>>>>> HASH(TT)=0x0e0672dc86f8e45565d338b0540abe6915bdf72e2b35b5c9e5663168e9
>>>>>>>>>>>>>>>>>>>>>>>> 60a91b
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> would be slightly better as then we'd always preserve the bytes
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Also, please let us know if you'd like to add a sentence like
>>>>>>>>>>>>>>>>>>>>>>>>> "Line breaks have been added due to line-length limitations"
>>>>>>>>>>>>>>>>>>>>>>>>> (as in RFC 7790 and other documents).
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I think that should be added.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 17) <!--[rfced] Is having a division for Appendix B.1 necessary? It seems to
>>>>>>>>>>>>>>>>>>>>>>>>> be all the content of Appendix B, so could Appendix B simply be renamed?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Sounds good.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>>>>>>>>>>> Appendix B.  Test Vectors
>>>>>>>>>>>>>>>>>>>>>>>>> B.1.  SPAKE2 Test Vectors
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>>>>>>>>>>>>>> Appendix B.  SPAKE2 Test Vectors
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> (FYI, the one large artwork element has been separated into
>>>>>>>>>>>>>>>>>>>>>>>>> 4 artwork elements, as there seem to be 4 invocations. Please let
>>>>>>>>>>>>>>>>>>>>>>>>> us know if you prefer otherwise.)
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 18) <!--[rfced] In running text, this term appears to be hyphenated
>>>>>>>>>>>>>>>>>>>>>>>>> inconsistently. Please review it and let us know if/how it
>>>>>>>>>>>>>>>>>>>>>>>>> may be made consistent.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> SHA256 (3 instances) vs. SHA-256 (1 instance)
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> We note this issue also affects draft-irtf-cfrg-vrf-15, which
>>>>>>>>>>>>>>>>>>>>>>>>> is in this document cluster,
>>>>>>>>>>>>>>>>>>>>>>>>> e.g., no hyphen:
>>>>>>>>>>>>>>>>>>>>>>>>> "choices for Hash are SHA256 or SHA512 [RFC6234]" in this document
>>>>>>>>>>>>>>>>>>>>>>>>> vs. hyphenated:
>>>>>>>>>>>>>>>>>>>>>>>>> "Hash is SHA-512 as specified in [RFC6234]" in draft-irtf-cfrg-vrf-15.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Let us hyphenate.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 19) <!-- [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.  For example, please consider
>>>>>>>>>>>>>>>>>>>>>>>>> whether "man-in-the-middle" should be updated.
>>>>>>>>>>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> In section 3.3
>>>>>>>>>>>>>>>>>>>>>>>> OLD
>>>>>>>>>>>>>>>>>>>>>>>> "This prevents man-in-the-middle attackers from inserting themselves
>>>>>>>>>>>>>>>>>>>>>>>> into the exchange"
>>>>>>>>>>>>>>>>>>>>>>>> NEW
>>>>>>>>>>>>>>>>>>>>>>>> "This use of the transcript ensures any manipulation of the messages
>>>>>>>>>>>>>>>>>>>>>>>> sent is reflected in the keys".
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap/ar
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On Apr 3, 2023, [e-mail] wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Updated 2023/04/03
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>>>>>>>>>>>>>>> --------------
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>>>>>>>>>>>>>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.
>>>>>>>>>>>>>>>>>>>>>>>>> If an author is no longer available, there are several remedies
>>>>>>>>>>>>>>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties
>>>>>>>>>>>>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>>>>>>>>>>>>>>>>>>>>>> your approval.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Planning your review
>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  RFC Editor questions
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>>>>>>>>>>>>>>>>>>>>>> that have been included in the XML file as comments marked as
>>>>>>>>>>>>>>>>>>>>>>>>> follows:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Changes submitted by coauthors
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>>>>>>>>>>>>>>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>>>>>>>>>>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Content
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review the full content of the document, as this cannot
>>>>>>>>>>>>>>>>>>>>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>>>>>>>>>>>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>>>>>>>>>>>>>>>> - contact information
>>>>>>>>>>>>>>>>>>>>>>>>> - references
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>>>>>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>>>>>>>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Semantic markup
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of
>>>>>>>>>>>>>>>>>>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>>>>>>>>>>>>>>>>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>>>>>>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Formatted output
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>>>>>>>>>>>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is
>>>>>>>>>>>>>>>>>>>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>>>>>>>>>>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Submitting changes
>>>>>>>>>>>>>>>>>>>>>>>>> ------------------
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>>>>>>>>>>>>>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties
>>>>>>>>>>>>>>>>>>>>>>>>> include:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  your coauthors
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>>>>>>>>>>>>>>>>>>>>> IETF Stream participants are your working group chairs, the
>>>>>>>>>>>>>>>>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  [e-mail], which is a new archival mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion
>>>>>>>>>>>>>>>>>>>>>>>>> list:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  More info:
>>>>>>>>>>>>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  The archive itself:
>>>>>>>>>>>>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>>>>>>>>>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>>>>>>>>>>>>>>>>> If needed, please add a note at the top of the message that you
>>>>>>>>>>>>>>>>>>>>>>>>> have dropped the address. When the discussion is concluded,
>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail] will be re-added to the CC list and
>>>>>>>>>>>>>>>>>>>>>>>>> its addition will be noted at the top of the message.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>>>>>>>>>>>>>>>> — OR —
>>>>>>>>>>>>>>>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> OLD:
>>>>>>>>>>>>>>>>>>>>>>>>> old text
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>>>>>>>>>>>>> new text
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit
>>>>>>>>>>>>>>>>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>>>>>>>>>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>>>>>>>>>>>>>>>>>>>>>>>> and technical changes.  Information about stream managers can be found in
>>>>>>>>>>>>>>>>>>>>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Approving for publication
>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>>>>>>>>>>>>>>>>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>>>>>>>>>>>>>>>>>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Files
>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> The files are available here:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-rfcdiff.html (side by side)
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-xmldiff1.html
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> The following files are provided to facilitate creation of your own
>>>>>>>>>>>>>>>>>>>>>>>>> diff files of the XML.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.original.v2v3.xml
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>>>>>>>>>>>>>>>>>>>>>>> only:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.form.xml
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> RFC9382 (draft-irtf-cfrg-spake2-26)
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Title            : SPAKE2, a PAKE
>>>>>>>>>>>>>>>>>>>>>>>>> Author(s)        : W. Ladd, B. Kaduk, Ed.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>