Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc7030est-clarify-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 06 Aug 2020 19:25:39 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-rfc7030est-clarify-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2020 13:52:57 -0400

Martin Duke asks that we replace RFC2616 with something newer.
The document actually references 2616, 7230 and 7231.  RFC2616 would have
been current at the time RFC7030 was published, and some thing are more
clearly articulated in 2616, but never-the-less ignored by RFC7030.
RFC7231 is less clear.

I also took the edits from Robert Wilton.

In the replace/with replacements,  I had not made [RFCXXXX] an actual
reference as I had used code blocks (artwork), where references are not expanded.

I am uncertain, XML-stylistically what to do here.

I don't think that the "Replace:" should result in actual references,
but the with: block should probably results in a new reference to the
relevant documents.
I have made sure, I think that I have all the references. Two were missing.

    > but 5912 is already in the registry so we should not need to re-run the

Oops. That's definitely a typo, I think.

    > publishing this document.

okay, I leave this to a responsible AD to do (Roman, I think).

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

fixed.

    > Should this be 4648 (not 2045)?

The original document that said to base64 encode them was RFC2045 (MIME)
The current base64 spec is RFC4648.  I take your point that here, it makes
sense to reference the base64 spec.

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

fixed.
Also noted by Erik Kline.

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

typo for RFC8174, I think. Removed.

    > doesn't seem very important.

The text and reference repeat what RFC7030 had.

    > complaining about doing it this way.

okay.
https://github.com/mcr/ietf-lamps-rfc7030est-clarifications/commit/eee1df925b6d8d34673a6f891ee8111b7e1f2356

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [