This document concerns security considerations on how ML-KEM should be integrated into protocols; not security considerations for implementing ML-KEM (which I think are indeed better covered by a draft that documents the algorithm itself). Perhaps the title can be slightly changed to reflect this, though? Adding “Usage of” or “Applications” in some way might be sufficient, and could help make finding this draft easier.
Another small nit is the discussion on decapsulation failures:
[..] For all three parameter sets, the probability is so low that most likely an actual decapsulation failure will never be seen for any ML-KEM exchange anywhere (not only for your protocol, but over all protocols that uses ML-KEM).
I suggest writing “honest decapsulation failure” or “randomly occurring decapsulation failure” to further emphasise this is separate from the malicious case.
Both of these are pretty pedantic, however, so if you disagree then no hard feelings :-)
https://mailarchive.ietf.org/arch/msg/cfrg/s8awRO4tkRbHItJzinIw9OjiJfY/
did have the following two nits:
This document concerns security considerations on how ML-KEM should be integrated into protocols; not security considerations for implementing ML-KEM (which I think are indeed better covered by a draft that documents the algorithm itself). Perhaps the title can be slightly changed to reflect this, though? Adding “Usage of” or “Applications” in some way might be sufficient, and could help make finding this draft easier.
Another small nit is the discussion on decapsulation failures:
I suggest writing “honest decapsulation failure” or “randomly occurring decapsulation failure” to further emphasise this is separate from the malicious case.
Both of these are pretty pedantic, however, so if you disagree then no hard feelings :-)