Re: [Last-Call] INT directorate Review of draft-ietf-lamps-rfc3709bis-07

[Donald Eastlake <d3e3e3@xxxxxxxxx>]

Hi Russ,

I am satisfied with your resolutions of all of my comments.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@xxxxxxxxx

On Fri, Nov 25, 2022 at 1:31 PM Russ Housley <housley@xxxxxxxxxxxx> wrote:

Donald:

Thanks for the careful review.  I'll post an update after the rest of the comments come in.

On Nov 23, 2022, at 6:25 PM, Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:

I am an assigned INT directorate reviewer for <draft-ietf-lamps-rfc3709bis-07.txt>. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION.

This document is generally in quite good shape. It specifies a certificate extension for including logotypes in public key certificates and attribute certificates. As such, usual INT Area considerations play very little part in the draft.

The following are minor issues (typos, misspelling, minor text improvements) with the document:

Section 9, Page 21: In the paragraph on has algorithm collisions, consider "vulnerable to collision attacks." -> "vulnerable to collision attacks such as MD5 [RFC6151]."

Sure.  I'll add the reference.

Nits:

Section 3, Page 7: "between of" -> "of between"

Dropping "of" seems to be even better.

Section 3. Page 8: "more than one of the audio object" -> "more than one of the audio objects"

Fixed.

Section 7, Page 18:
 - I think ".ext" as the column header for extension is a bit obscure. How about ".ext" -> "Extension"?

Okay.  I made that change.

 - It seems odd to require support for .svgz but not .svg since you obviously have to support .svg internally if you support .svgz.

The row above includes .svg, which is used when there is no compression.

Section 10, Page 23: "hide the name resolution" -> "hides the name resolution"

Fixed.

Stylistic:

Section 1.1, Page 4:
"the user in conscious contact with the result of a certificate-based identification process," ->
"to the user's attention a certificate-based identification,"

I'd prefer to keep the wording used in RFC 3709 to minimize the diff.

Section 4.1, Pages 11&12: There are three flavors of logotype defined and for each of them the same statement occurs that it "MAY be present in an end entity certificate, a CA certificate, or an attribute certificate." I would factor that out of the three sub paragraphs and change the lead in line from "Logotype types defined in this specification are:" to something like "Three Logotypes are specified in this section below. Each of them "MAY be present in an end entity certificate, a CA certificate, or an attribute certificate."

As above, I prefer to keep the RFC 3709 wording.

Russ

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call