Thank you for this useful I-D. I enjoyed reading it and I learned a lot. 

I have a concern that I think can be easily addressed related to making the document better suited for archival publication in the RFC series:

I suggest you consider and rephrase "Therefore, the true state of quantum computer advancement is likely several years ahead of the publicly available research." -- The statement ought to be about what is "currently" or "expected"  "at the date this is published" to avoid portions of text being mis-cited in the future by others.

Similarly could the phrase: "... key sizes of the symmetric algorithms that are currently deployed today to counter the quadratic speedup and maintain current security level", be more clear if written like: 
"... key sizes of the symmetric algorithms that being developed at the time of publication to counter the quadratic speedup and maintain current security level".

Please check: There are other places where "current" would usefully be similarly clarified when it describes the state of the art.

Please could you provide references and expansions to common cryptography terms, since this RFC will be useful to a more general audiance, e.g.: RSA, AES, ECC, HQC (etc).

Thanks also to the TSV-ART reviewer, please consider the following comments that were provided:

Nits:
Section 2.1:
"However, quantum operations are fundamentally different from classical ones,
whereas 2^{64} classical operations can be efficiently parallelized, 2^{64}
quantum operations must be performed serially, making them infeasible on
practical quantum computers" This sentence could be reworded without the use of
`whereas`, it was a bit confusing for me to read at first.

Section 6.1:
"Key Encapsulation mechanism based on the hardness on learning with errors in
algebraically unstructured lattices." Did you mean based on the hardness of?

My thanks to the authors and the WG for putting together this very informative document.

In general, I found the document to be a good read as someone with very little background on PQC (or crypto for that matter). However, someone wanting to do a deep dive may find several references missing if they were to use this document as a starting point in their study.

I have a few comments/suggestions to share:

1) I am concerned how this document will age as an RFC. More concerned that it does not mislead someone reading it after say 2-3 years. There are terms like "state-of-the-art", "current", "ongoing", etc. that need some qualification/clarification. There are a few sentences that specifically invoke "at the time of publishing" - is that only for those statements or applies more generally? Perhaps a disclaimer in both the abstract and introduction that indicates that the information is at the time of publication (can that be said with strong enough conviction?) or something on those lines?

2) Suggest adding "French" before "National Agency for the Security of Information Systems" (if not using its native French name) on the same lines as qualifying other agencies such as NSA, NIST and BSI. Also, CNSA needs a USA prefix (btw the reference link didn't work for me). 

3) Any suitable public references for Grover's and Shor's algorithms? There are more such instances where references would be helpful for someone wanting to dive deeper.

4) There are quite a few instances to fix about abbreviation/expansion on first use and references for the same. Some are present on later use while others are not (e.g., HQC = Hamming Quasi-Cyclic). I'll leave that to the authors and RFC Editor. 

5) Section 12.2, could you clarify the meaning of the word "signing oracle"? Is there an alternate/simpler term that can be used?

** Section 1
   The National Security Agency (NSA) of the United States released an
   article on future PQC algorithm requirements for US national security
   systems [CNSA2-0] based on the need to protect against deployments of
   CRQCs in the future.  The German Federal Office for Information
   Security (BSI) has also released a PQC migration and recommendations
   document [BSI-PQC] which largely aligns with United States National
   Institute of Standards and Technology (NIST) and NSA guidance, but
   differs on some of the guidance.

-- Are these references needed?  Are there other government statements to reference?

-- Is the difference in guidance between the US and Germany important?  Relevant to mention here?

** Section 4.
   *  Content encryption: Content encryption typically refers to the
      encryption of the data using symmetric key algorithms, such as
      AES, to ensure confidentiality.  The threat to symmetric
      cryptography is discussed in Section 3.1.

Seems odd to mention symmetric algorithms given that this section opens with “Any asymmetric cryptographic algorithm …” and is framed around replacement constructed.  The summary of the referenced Section 3.1 appears to me to be that no replacement will occur and Section 5 opens with “ In the context of PQC, symmetric-key cryptographic algorithms are generally not directly impacted by quantum computing advancements.”

** Section 10.2.1
   Understanding
   IND-CCA2 security is generally not necessary for developers migrating
   to using an IETF-vetted key establishment method (KEM) within a given
   protocol or flow. 

-- As this isn’t an absolute statement, when would developers needs to understand IND-CCA2?

-- Is this statement needed?

** Section 10.2.1
   IND-CCA2 is a widely accepted security notion for
   public key encryption mechanisms, making it suitable for a broad
   range of applications.  IETF specification authors should include all
   security concerns in the "Security Considerations" section of the
   relevant RFC and not rely on implementers being experts in
   cryptographic theory.

Is this intended to provide constraining or normative guidance to the IETF stream of RFCs?  Is this needed?
'
** Section 12.
   The table below denotes the five security levels provided by NIST for
   PQC algorithms.  Neither NIST nor the IETF make any specific
   recommendations about which security level to use.
…
   This
   information is a re-print of information provided in the NIST PQC
   project [NIST] as of time this document is published.

-- Perhaps include this last sentence in the beginning to set expectations

-- Per “Neither NIST … makes any specific recommendation about the security level to use”, is not accurate the way this is stated.  NIST does in fact make recommendation on which algorithms to use in other publications (or might do so in the future).

** Section 14.3.4.  As this subject matter isn’t PQC relevant, strongly recommend removal.

** Section 14.3.5.  It isn’t clear what the reader would do this summary.  It also isn’t clear it will age well.  Recommend removal.