[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-rp-06: 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-sidrops-rp/



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

Section 2

   RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
   changed data objects in the repository system and cache them locally.

nit(?): perhaps "changed" requires a bit more explanation.

Section 2.1

   TAL acquisition and processing are specified in Section 3 of
   [RFC8630].

I'm not really convinced that the referenced section discusses
specifically TAL *acquisition*.

Section 2.2

   by using the SIA and AIA extensions.  Detailed specifications of SIA
   and AIA extensions in a resource certificate are described in
   Section 4 of [RFC6487].

(Subsections thereof, though I trust that the reader should be able to
figure this out.)

Section 3.1

   established by Section 4 of [RFC6487].  This means that all
   extensions mandated by Section 4.8 of [RFC6487] must be present and
   value of each extension must be within the range specified by this
   RFC.  Moreover, any extension excluded by Section 4.8 of [RFC6487]

nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp
will become, in this context).

   Section 7.1 of [RFC6487] gives the procedure that the RP should
   follow to verify resource certificate and syntax.

"verify resource certificate and syntax" seems a little broad; the
referenced section seems specific to validating the extension defined in
RFC 3779.

Section 3.2

   Certificate Authorities that want to reduce aspects of operational
   fragility will migrate to the new OIDs [RFC8360], informing the RP of
   using an alternative RPKI validation algorithm.  An RP is expected to
   support the amended procedure to handle with accidental over-claim.

nit: I suggest s/with accidental over-claim/accidental overclaim/.

Section 3.3

   Processing of a CRL that is not consistent with a manifest is a
   matter of local policy, as described in the fourth paragraph of
   Section 6.6 of [RFC6486].

Is the fifth paragraph relevant, also?

Section 4.1

   Note that these checks are necessary, but not sufficient.  Additional
   validation checks must be performed based on the specific type of
   signed object.

These additional validations are covered in the following sections, it
seems -- should we mention that here?

Section 4.2.4

   contain an IP Address Delegation extension.  The validation procedure
   used for BGPsec Router Certificates is identical to the validation
   procedure described in Section 7 of [RFC6487], but using the
   constraints applied come from specification of Section 7 of
   [RFC8209].

nit: if it does something differently, it's no longer "identical"; maybe
"analogous" or it's following the validation procedure [...] with
additional constraints"?
That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not
sure what the "constraints applied come from" is intended to say.

Section 7

The validation steps discussed throughout this document are also pretty
important to the security of the system as a whole.

Section 10.1

I'm not sure that RFC 5280 actually is normative here.  (That might be
the first time I've ever said that!)

Section 10.2

I think that RFCs 6489, 6916, and 8634 are probably better as normative.