This is a well written draft, with just the right amount/level of detail for (what I would imagine is) the target audience.

- "There are also applications where future checks on past authenticity play a role, such as long-lived digital signatures on  legal documents." I'm not sure this is a good motivation here, since such infrastructure should already support crypto agility, such as transition from RSA-1024 to RSA-2048 (e.g. by providing manual services to update signatures). However this may be a good place to discuss long-term signatures that are at the heart of PKI, namely intermediate PKI certs that often have long validity, sometimes as long as 10 years. (The comment also applies to Sec. 1.2.2).

- "It is intended as a resource for designers and implementers of hybrid signature schemes" - I'm not sure we have the requisite consensus, but I would have liked to see here something about IETF process. For example, "We expect the IETF to standardize particular hybrid signature schemes for some of its protocols." Creating hybrid schemes is difficult and we don't want a plethora of them.

- "are one reason for to consider" - redundant "for"?

- Definition of stripping attack: you explain the mechanics of the attack, but not the semantics, i.e. why is this an attack. In many cases if Alice signs M ("I owe Bob $10") with two different algorithms, a stripping attack will result in the same message, signed by the same entity, and completely valid (assuming for example the verifier trusts one of the component signatures). Edit: an explanation is provided later but would be more useful at this point.

- "it is more likely that vulnerabilities will represent a weakening of security than a full "break"." - I'm not sure this follows from the existence of intensive analysis. This statement needs further clarification or past examples to support it.

- "Note that unlike EUF-CMA security, SUF-CMA security of the hybrid scheme may rely on SUF-CMA security of both component schemes achieving SUF-CMA, depending on the hybridization approach." - something is not quite right with this sentence.

- Terminology: the acronyms EUF-CMA, SUF-CMA need to be explained or a reference given to their definitions. Similarly "functional transition" and "security transition".

- The term "backward(s) compatibility" appears to be used in a very specific, technical sense, but again is used before it is defined. Ironically "backwards compatibility" needs a forward reference.

- "Backwards compatibility may be further decomposed to subcategories where component key provenance is either separate or hybrid so as to support implementations that cannot recognize (and/or process) hybrid signatures or keys" - I find this categorization strange, since legacy verifiers by definition can only process component signatures (and keys) that are separate.

- Notation: in the Terminology section commas are used in the regular manner to denote function parameters, "Verify(pk, sig, m)", but later on commas are used to denote concatenation, "Sigma_1.Sign(hybridAlgID, m)". A more standard notation would have been friendlier, "Sigma_1.Sign(hybridAlgID || m)".

- The "need for approval" section is very strange in an IETF document, especially since none of the authors is (as far as I can tell) authorized to speak for NIST. It would be a lot more useful if NIST provided official clarifications about the points that were identified as open.

- "This vulnerability is particularly an issue among concatenated or nested hybrid signature schemes when component verification." - this sentence is incomplete.

- "It should be noted that weak non-separability is insufficient for mitigating risks of component forgeries." - please add a section number to the reference to the Composite draft.