Subject: [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08

From: Ines Robles via Datatracker <[email-masked]>
Date: Wed, 08 Jul 2020 12:16:19 -0700

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

Document: draft-ietf-lamps-rfc7030est-clarify-08
Reviewer: Ines Robles
Review Date: 2020-07-08
IETF LC End Date: 2020-07-09
IESG Telechat date: Not scheduled for a telechat

Summary:

This document updates RFC7030 to address errata.  This document deprecates the
specification of "Content-Transfer-Encoding" headers for EST endpoints.  This
document fixes some
   syntactical errors in ASN.1 that were presented.

The document is clear and well written. I have some minor nits/questions

Major issues: None

Minor issues: None

Nits/editorial comments/questions:

1- It would be nice to add in Terminology section that the document uses the
terminology of RFC7030 and RFC5272

2- Introduction: "reports from implementers suggest..." It would be nice to add
reference/s here

3- Security Considerations:

It would be nice to add smth like "security considerations from RFC7030 applies
also for the clarifications described in this document."

5- IANA Considerations:
It would be nice to add the specific registry that IANA should update.
For example, instead of "IANA is requested to update the "Reference" column for
the Asymmetric Decryption Key Identifier attribute to also include a reference
to
   this document." you could add smth like (if applicable): " IANA is requested
   to update the registry SMI Security for S/MIME Attributes
   (1.2.840.113549.1.9.16.2) "
with the reference of this document as follows:

Decimal - Description                   -Reference
54      id-aa-asymmDecryptKeyID  [RFC7030] [ThisDocument]

4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...}

4.1-   pkcs9(9) should be pkcs-9(9) ?

4.2-   aa(2) should be id-aa(2) ?

Thank you for this document,

Ines.

---

From: Russ Housley <[email-masked]>
Date: Wed, 8 Jul 2020 15:37:04 -0400

Ines:

Thanks for the very carful review.  I'll tackle the ones about the ASN.1...

> 4.1-   pkcs9(9) should be pkcs-9(9) ?

Both are used in different modules.  They have become synonyms.  That said, we should pick one, and the use it in the two places where this is used.

The hyphen is used in RFC 6268, where we import some things, so I suggest we use the hyphen here too.

> 4.2-   aa(2) should be id-aa(2) ?

No.  This one is correct.

Russ

---

From: Ines Robles <[email-masked]>
Date: Thu, 9 Jul 2020 12:20:41 +0300

Hi Russ,

Thank you very much for your reply,

Best,

Ines

On Wed, Jul 8, 2020 at 10:37 PM Russ Housley <[email-masked]> wrote:

> Both are used in different modules.  They have become synonyms.  That
> said, we should pick one, and the use it in the two places where this is
> used.
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2020 20:56:37 -0400

> 2- Introduction: "reports from implementers suggest..." It would be nice to add

Well, I'm not sure how I can add a reference to private emails.
I can ask the implementers to write a public email if that is intended.
Please advise.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2020 21:00:47 -0400

> also for the clarifications described in this document."

done.

    > 4.1-   pkcs9(9) should be pkcs-9(9) ?

I have done this as per Russ Housley's suggestion.

    > 4.2-   aa(2) should be id-aa(2) ?

I have not done this.

This is in version -09.

---

From: Ines Robles <[email-masked]>
Date: Mon, 13 Jul 2020 09:52:02 +0300

Hi Michael,

Yes, that would be great, if possible.

Thank you,

Ines