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

[Sandy Ginoza <[e-mail]>]

Hi Ben,

Just checking to see if you’ve had a chance to review this document.  Please send along your comments when you can.

Thank you,
RFC Editor/sg

> On Aug 28, 2023, at 2:17 PM, Alanna Paloma <[e-mail]> wrote:
> 
> 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
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>