Hi! Thanks for the well written draft. I really liked Appendix B that includes the tried but discarded designs. Issue worth discussing (and it might be a short discussion): Are there any instructions that the DEs needs to make sure that this registry is not populated with PQ-wanna-be Transforms? E.g., I show up my shiny new (and supposedly) PQ resistant alg and the DE says .... Nits: The use of “we” is a style thing that I would change, but if the WG/IESG are good with it I can get on board too. s1.2, last para: “require such a requirement” is a bit awkward. How about “have such a requirement” or “levy such a requirement”? s2, hybrid: I think you might want to include some words by what you mean by “hybrid”? Maybe as simple as copy some of the text from the 1st para of s3.1 forward, “when multiple key exchanges are performed and the calculated shared key depends on all of them”. s3.1, s/Note that with this semantics,/Note that with these semantics, s4.1: s/must/MUST in the DE instructions? s/addition,any/addition, any s5: s/dwarfed/ with thwart or mitigate s/the data need to remain/the data needs to remain A.1: s/as follows/as follows. s/SKEYSEED(1) …. )./SKEYSEED(1) … ) s/{SK_d(1) … SPIr)./{SK_d(1) … SPIr) Is this missing: The updated SKEYSEED value is then used to derive the following keying materials between these two lines: SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) | SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr) A.4:s/a security association/an IKE SA