Thank you for the review, Stewart.
WG: these are the PRs to address the review:
https://github.com/lamps-wg/x509-shbs/pull/19
Further comments below.
On 2024-10-25 11:40 a.m., Stewart Bryant via Datatracker wrote:
Reviewer: Stewart Bryant Review result: Ready with Nits 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 <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. 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.
The draft references RFC 8554, which is the description of the LMS/HSS algorithm, and is in the downref registry.
RFC 8391 is the description of the XMSS(MT) algorithm.
If RFC 8554 can be in the downref registry then I think RFC 8391 should be as well.
We've attempted to be a bit more helpful: https://github.com/lamps-wg/x509-shbs/pull/19====== 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?
I'm not sure what you're asking for here. Remove the TLAs in the Abstract? In several related RFCs (8391, 8554, 8708), TLAs or 4LAs are used in the abstract. And those are the only three that I've checked.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.
Three of these are proper names or French/German agency names with accented characters. The fourth was too long because it's using an I-D name in a reference, although coincidentally I fixed the I-D name reference and it's short enough now. I've added an RFC
EDITOR note to ensure the I-D name is replaced with the final RFC.
=========
=========
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
There are no IPv6 addresses, it's probably coming from the pretty-print of the example keys and certificates.=========
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
