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

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton 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:
----------------------------------------------------------------------

Thanks for this document, just a couple of minor comments:

1) Section 4.2.1. Manifest

   nextUpdate:
      This field contains the time at which the next scheduled manifest
      will be issued.  The value of nextUpdate MUST be later than the
      value of thisUpdate.  The specification of the GeneralizedTime
      value is the same as required for the thisUpdate field.

      If the authority alters any of the items that it has published in
      the repository publication point, then the authority MUST issue a
      new manifest.  Even if no changes are made to objects at a
      publication point, a new manifest MUST be issued before the
      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
      is published.  When a new manifest is issued before the time
      specified in nextUpdate of the current manifest, the CA MUST also
      issue a new CRL that revokes the EE certificate corresponding to
      the old manifest.

Although this last sentence is not wrong, am I right in thinking that this
sentence isn't specific to when the manifest is issued, i.e., isn't it the case
that that CA MUST issue a new CRL whenever a new manifest is issues for any
reason (e.g., as per 5.1, step 2)?  If so, perhaps this sentence could be
tweaked to make that clearer.

2) 5.2.  Considerations for Manifest Generation

   A new manifest MUST be issued and published before the nextUpdate
   time.

Should any guidance be given about how far before the nextUpdate time a new
manifest should be issued.  E.g., is publishing right at the nextUpdate time
(e.g., 1 millisecond before) sufficient , or does it make sense to publish it a
bit earlier than the nextUpdate time?

Nits:

4.1.  eContentType

   The eContentType for a manifest is defined as id-ct-rpkiManifest and
   has the numerical value of 1.2.840.113549.1.9.16.1.26.

Would numerical object identifier, or numerical OID, be better than numerical
value here?

4.2.  eContent

I would have preferred for "file" to be "filename" in the structure, but I
presume that this can't be changed at this stage anyway ...

Regards,
Rob