# Andy Newton, ART AD, comments for draft-ietf-sidrops-manifest-numbers-07
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sidrops-manifest-numbers-07.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


Thanks for the work on this document.

## Comments

### Concur with Éric and Gorry

I have the same comment here as Éric and Gorry. Could the SHOULD NOT on 163 be a MUST NOT?
Could the SHOULD on 166 be a MUST?

163        have no purpose.  To avoid this outcome, CAs SHOULD NOT use new
164        filenames for manifests except in situations where such a change is
165        necessary to address the invalidity problem described in this
166        document.  Similarly, an RP SHOULD alert its operators when a

### Unnecessarily Normative

While this advice is good, is the SHOULD on line 205 specific enough to use 2119 language?
In my opinion, the lower-cased version is appropriate as the advice is too generic.

204        invalidity scenario.  RPs that encounter other permanent invalidity
205        scenarios SHOULD also consider how those can be addressed such that
206        the scenario does not require the relevant CA or TA to perform a key
207        rollover operation.  For example, in the event that an RP recognises

Thanks to Barry Leiba for their secdir review.

This draft appears to be well written and clear.  I appreciate the redundant mechanisms (manifestNumber and thisUpdate) which allows you to make improvements with one mechanism while still relying on the other.

Thanks for the work done in this document even if I wonder whether it will ever be required. 

Rather than changing the filename, wouldn't it be easier to allow the 'counter' to wrap back to 0 and force all manifest to never use 0 ? Should an explanation of the technical choice appear in this I-D ?

Why not "MUST" rather than "SHOULD" in 
```
To avoid this outcome, CAs SHOULD NOT use new filenames for manifests except in situations where such a change is necessary to address the invalidity problem described in this document. Similarly, an RP SHOULD alert its operators when a manifest filename changes for a given CA.
```

A key sentence for me is `purported new manifest has a more recent thisUpdate than the cached manifest` in the security considerations, strongly suggest to also write so in the introduction.

Finally, citing the implementations is not enough IMHO. I.e., the "implementations section" does not comply with section 2 of RFC 7942 by location and contents.

Thanks for this I-D.

I have one question (shared with Eric V), Why is the RFC2119 keyword "MUST" rather than "SHOULD" in: 

"To avoid this outcome, CAs SHOULD NOT use new filenames for manifests except in situations where such a change is necessary to address the invalidity problem described in this document. Similarly, an RP SHOULD alert its operators when a manifest filename changes for a given CA."

I also have two comments requesting more insight from the receiver perspective, for which I'd appreciate a response for my own understaning, but I expect could be clarufied to avoid any doubt by others:

The I-D says:
"RPs MUST verify that the URI"
- I'm sure this is clear in the mind of the editor, and maybe others also, could you please simply also write what is required to happen when the verification fails?

The I-D later says: "MUST ensure that none of
   the manifest filenames in the previous CA certificate appear in the
   newly-issued CA certificate."
- As a consumer of the certificate, could you please simply also write what is required to happen when the such filenames do appear in a new certficate?

Once the charter is appropriate, this document seems clear and well-written.

With regard to the SHOULD NOT change filenames, I will note that one common versioning approach in some areas is to give every version a unique filename which will never change (immutable), such that all prior versions can be retrieved if needed. Thus, I can conceive of a CA that chooses to change the filename with each new manifest, such that the old manifests remain available for comparison purposes. If the filename is no longer considered a security mechanism, it's unclear that this deployment pattern needs to be discouraged.