[sidr] Ben Campbell's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-09: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-rpki-validation-reconsidered-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-sidr-rpki-validation-reconsidered/



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

Thanks for resolving my DISCUSS points. I note that there is new explanatory
text in the abstract. I suggest similar text be added in an introductory
section in the body, since readers are known to sometimes skip the abstract.

I am leaving my other comments below for documentation purposes; I leave it to
the authors and shepherd to decide if they are sufficiently addressed.

-------------------

Substantive:

- General: There's a lot of amending going on here--does this draft really not
update any RFCs (e.g. 6487)?

- 4.2.4.4:
-- "Any extension not thus identified MUST NOT appear in
       certificate x." (Repeats multiple times)
That seems to prevent future extensibility. Is that the intent?

-- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
       appear on a CRL issued by the CA represented by certificate x-1"
Is this intended as a requirement to check CRLs? If so, please say that
explicitly.

Editorial:

-4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern
repeats in several sections.)he

- 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or
   both, MUST be present in all RPKI certificates, and if present, MUST
   be marked critical."
"... and if present..." seems redundant, since the previous clause said one
MUST be present.

- 4.3.4.3: "... values are NOT supported..."
a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the
all-caps is just for emphasis, but we typically reserve that for RFC 2119
keywords.

- 4.2.4.4 :
-- "Certificate validation requires verifying that all of the following
   conditions hold, in addition to the certification path validation
   criteria specified in Section 6 of [RFC5280]."

The "... in addition to..." part doesn't seem quite true. For example, making
sure the current date fits in the active range, ensuring a cert is signed by
the issuer, etc.  are already covered in 5280.

- - "...certificate MUST contain all
       extensions defined in section 4.8 of [RFC6487] that must be
       present."
That seems tautologically true. If this is a statement of fact, then please
avoid the MUST. If this is really a new normative requirement, then I'm
confused at the intent.

-- "all extensions defined in section 4.8 of
       [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
       present. "
It would be more reader-friendly to mention what extensions are defined in
4.8.9.

-- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
Inconsistent voice.

-- list entry 7, 4th bullet: "If the IP Address Delegation extension is present
in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension."
That seems identical to the first bullet. Should it has said "AS Address
Delegation extension"?