Hi Darren,
Thanks for your review.
On Mon, Aug 04, 2025 at 03:15:09PM -0700, Darren Dukes via Datatracker wrote:
> #1 The term filename is used throughout to describe the name that,
> upon change, results in a reset of the manifest number. But
> "filename" is not defined in RFC9286. Do the authors intend to
> refer to FileAndHash or the file name in FileAndHash, something
> else? If FileAndHash or FileList is the target should filename be
> replaced with FileAndHash to be fully resolved to a defined term?
The draft defines the manifest filename in section 2:
A CA specifies its manifest URI by way of an SIA entry with an
accessMethod of id-ad-rpkiManifest (Section 4.8.8.1 of [RFC6487]).
For the purposes of this document, the manifest filename is the
final segment of the path of the accessLocation URI from that SIA
entry.
But possibly the document would be clearer if this paragraph were
moved? E.g., so that it became the second paragraph of section 2?
> #2 Does the process described in section 2 apply to any change in
> the FileList associated with a manifest number or just the file name
> in a single FileAndHash?
The process in section 2 does not relate to the FileList or to any of
the individual FileAndHash entries within the FileList. It instead
relates only to the filename of the manifest itself.
> #3 I had to read the Section 3 "Section 2 contains a specific update
> to [RFC9286]" to understand that section 2 was in fact the update to
> RFC9286. That is worth clarifying in Section 2 itself.
Thanks, the first paragraph of section 2 has been updated to note this
(https://github.com/APNIC-net/draft-sidrops-manifest-numbers/blob/main/draft-ietf-sidrops-manifest-numbers.xml#L222):
For a given CA, an RP MUST NOT reject a new manifest issued by
that CA on the basis of it not having a higher manifestNumber than
a previously-validated manifest if the new manifest has a
different filename from that of the previously-validated manifest.
In other words, an RP has to reset its stored manifestNumber for a
given CA if the CA changes the filename of its manifest. This is
an update to the requirements set out in Section 4.2.1 of
[RFC9286].
-Tom
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
