I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-x509-shbs-08 Reviewer: Stewart Bryant Review Date: 2024-10-25 IETF LC End Date: 2024-10-25 IESG Telechat date: Not scheduled for a telechat Summary: From a GENART perspective a well written document with an editorial/procedural matters that should be addressed. I made no attempt to validate the correctness of the syntax which I assume will be undertaken by others. Major issues: None Minor issues: There are a few downref errors reported. Two are in the downref registry and are thus OK. The two of significance are thus: ** Downref: Normative reference to an Informational RFC: RFC 8391 -- Possible downref: Non-RFC (?) normative reference: ref. ‘SP800208' The RFC 8391 error needs to be formally addressed. The SP800208 error is a pointer to the work of a reputable body and thus should be accepted as OK. ====== 537 is released. Drop the new signature and hit your PANIC button if 538 you spot OTS key reuse. An interesting turn of phrase, but I am not entirely sure how to implement it :) Maybe a piece of text should be added to give some implementation advice? Nits/editorial comments: I am not sure if expansions of TLAs in the Abstract is adequate (or allowed). I think they need to be expanded in the body of the document. ========= ID-Nits picks up the following: draft-ietf-lamps-x509-shbs-08.txt: -(641): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(651): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 641 [ANSSI] Agence nationale de la sécurité des systèmes d’information 651 [BSI] Bundesamt für Sicherheit in der Informationstechnik (BSI), ========= ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ========= == There are 4 instances of lines with non-ascii characters in the document. Ideally these should be addressed before the document goes to the RFC Editor. ========= ========= There was also a comment that == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. I could not find it and I suspect that this is spurious =========