[Sidrops] Francesca Palombini's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-sidrops-6486bis-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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/



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

Thank you for the work on this document

I have an easy to fix point that should be address before publication (although
it probably does not rise to the level of DISCUSS). I also have a number of
minor comments (answers will be appreciated) and nits.

Francesca

# Major

1. -----

   objects from a successful fetch.  This implies that the RP MUST not

FP: This should be "MUST NOT" (rather than "MUST not")

# Minor

2. -----

FP: as noted by the shepherd, there are some references to fix:

  * RFC 6485 needs to be replaced with RFC 7935

The following references need to be removed as they are not used.

  == Unused Reference: 'RFC6482'
  == Unused Reference: 'RFC6493'
  == Unused Reference: 'RFC8209'
  == Unused Reference: 'RFC8488'  (this was even last called as downref)

3. -----

      monotonically for each newly-generated Manifest.  Each RP MUST
      verify that a purported "new" Manifest contains a higher
      manifestNumber than previously-validated Manifests.

FP: This should contain a sentence about what the RP has to do if verification
fails (I expect ignore the "new" Manifest). Same comment for the thisUpdate
field:

      Manifest.  Each RP MUST verify that this field value is greater
      (more recent) than the most recent Manifest it has validated.

And for the text in Section 5.1:

       Note: An RP MUST verify all mandated syntactic constraints, i.e.,
       constraints imposed on a CA via a "MUST".

       publication point that is described by the manifest.  (RPs are
       required to verify the CMS signature.)

4. ------

      nextUpdate time.  Each manifest encompasses a CRL, and the
      nextUpdate field of the manifest SHOULD match that of the CRL's
      nextUpdate field, as the manifest will be re-issued when a new CRL

FP: What are the exception cases where it is expected not to match (i.e. what
is the reason for the SHOULD here)?

5. -----

   The RP MUST check that the current time (translated to UTC) is
   between thisUpdate and nextUpdate.  If the current time lies within

FP: I am not sure the parenthesis needs to be there - this seems like an
unnecessary implementation detail.

# Nits

6. -----

  *  all published signed objects that are verifiable using EE

FP: Please expand all acronyms (EE, OID) on first use

7. -----

   termed a "one-time-use" EE certificate [RFC6487]

FP: missing period