Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1
draft-ietf-lamps-rfc7030est-clarify-10

[[ questions ]]

[ section 5.2 ]

* Did you want this "response data must" to be "... MUST"?

[[ nits ]]

[ abstract ]

* s/were presented/were present/?

Thanks to Joel for the OpsDir review!

I, too, wonder why there’s a need to still cite RFC 2616 here.

The reference to RFC 5212 (Requirements for GMPLS-Based Multi-Region and
Multi-Layer Networks (MRN/MLN)) in the ASN.1 module needs to be replaced
by 5912 (New ASN.1 Modules for the Public Key Infrastructure Using X.509
(PKIX)).  Note that the last-call announcement claimed (properly,
according to the state of the document) that there is a downref to 5212,
but 5912 is already in the registry so we should not need to re-run the
IETF LC.

It seems like we might want to move EIDs 4384, 5904, 5107, and 5108 out
of status "Reported" (i.e., to "Hold for Document Update") before
publishing this document.

Abstract

   This document updates RFC7030: Enrollment over Secure Transport (EST)
   to resolve some errata that were reported, and which has proven to
   cause interoperability issues when RFC7030 was extended.

nit: singular/plural mismatch "has proven"/"errata that were reported".

Section 4

   Responses to attribute request messages MUST be encoded as the
   content-type of "application/csrattrs", and are to be "base64"
   [RFC2045] encoded.  The syntax for application/csrattrs body is as

Should this be 4648 (not 2045)?

Section 5.2

   Replace:

       If the content-type is not set, the response data MUST be a
       plaintext human-readable error message.

   with:

       If the content-type is not set, the response data must be a
       plaintext human-readable error message.

Why do we lose the 2119 "MUST" here?  We kept it in Section 5.1.

Section 10.1

RFC 8179 is listed but does not seem to be cited anywhere.

Section 10.2

One could perhaps argue that RFC 2985 should be normative, but it
doesn't seem very important.

Appendix A

  id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 }

Pedantically, RFC 7030 spells it as "{id-aa 54}" but I'm not actually
complaining about doing it this way.

RFC 2616 is obsolete and should probably be replaced by one of its successors.

Thanks for this document, I found it easy to read.

No concerns, just some minor nits:

1.  Introduction

   This document deals with errata numbers [errata4384], [errata5107],
   [errata5108], and [errata5904].

   This document deals explicitely with [errata5107] and [errata5904] in
   Section 3. [errata5108] is dealt with in section Section 5.

   [errata4384] is closed by correcting the ASN.1 Module in Section 4.

Typo on explicitly, but I would propose merge these three paragraphs into one:

E.g. 
   This document deals with [errata5107] and [errata5904] in
   Section 3. [errata5108] is dealt with in Section 5.  [errata4384] is
   closed by correcting the ASN.1 Module in Section 4.

There are also some paragraph indentation issues that could be tweaked in sections 3.2.3 & 3.2.4, or if the tooling is tricky to fix this then you could leave a note to flag it for the RFC editor.

7.  Security Considerations

applies also => also apply