[Last-Call] Genart last call review of draft-ietf-lamps-x509-shbs-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

======

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

=========



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux