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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-rfc3709bis-06
Reviewer: Paul Kyzivat
Review Date: 2022-10-25
IETF LC End Date: 2022-10-28
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

Issues:

Major: 0
Minor: 1
Nits:  2

1) MINOR: In Section 4.1 (Extension Format):

The following:

"CAs SHOULD use the one-way hash function that is associated with the 
certificate signature to compute the hash value, and CAs MAY include 
other hash values."

introduces the possibility that a client might not support *any* of the 
provided hash algorithms. This seems bad.

RFC3709 didn't have this problem because it required that an SHA-1 hash 
be included and supported.

This can be fixed by changing "CAs SHOULD" to "CAs MUST".

2) NIT: From IdNits:

** Downref: Normative reference to an Informational RFC: RFC 1952

I think it would be ok to change the reference to Informative.

3) NIT: Typos

In Section 3 (Logotype Data):

s/then each image objects/then each image object/

In Section 7 (Image Formats):

s/The following table lists many commons/The following table lists many 
common/

s/requirements these image formats/requirements for these image formats/

s/the client will receive response/the client will receive a response/

(The last one above appears twice.)

In Section 10 (Privacy Considerations):

s/cache logotype data is cached/cache logotype data/