Hi Madison,
thanks for your detailed work.
I approve for publication.
/Carlos
---
--
Carlos Martinez-Cagnazzo
LACNIC
On 2024-12-04 14:30, Madison Church wrote:
Hi Tom,
Thank you for your prompt reply (and apologies for missing those edits
earlier)! We have updated the files accordingly. Please let us know if
any further updates are necessary. We will await approvals from each
author prior to moving forward in the publication process.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9691.txt
https://www.rfc-editor.org/authors/rfc9691.pdf
https://www.rfc-editor.org/authors/rfc9691.html
https://www.rfc-editor.org/authors/rfc9691.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9691-diff.html
https://www.rfc-editor.org/authors/rfc9691-rfcdiff.html
https://www.rfc-editor.org/authors/rfc9691-auth48diff.html
https://www.rfc-editor.org/authors/rfc9691-alt-diff.html
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9691
Thank you!
RFC Editor/mc
On Dec 3, 2024, at 4:50 PM, Tom Harrison <t...@apnic.net> wrote:
Hi Madison,
Thanks for these updates.
On Tue, Dec 03, 2024 at 11:50:15AM -0600, Madison Church wrote:
Thank you for your reply and thorough review! We have updated the
document as requested and all of our questions have been addressed.
Please review the document carefully to ensure satisfaction as we do
not make changes once it has been published as an RFC. Contact us
with any further updates or with your approval of the document in
its current form. We will await approvals from each author prior to
moving forward in the publication process.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9691.txt
https://www.rfc-editor.org/authors/rfc9691.pdf
https://www.rfc-editor.org/authors/rfc9691.html
https://www.rfc-editor.org/authors/rfc9691.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9691-diff.html
https://www.rfc-editor.org/authors/rfc9691-rfcdiff.html
https://www.rfc-editor.org/authors/rfc9691-auth48diff.html
https://www.rfc-editor.org/authors/rfc9691-alt-diff.html
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9691
A few small edits:
- The abstract now has:
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in
the
Resource Public Key Infrastructure (RPKI) to locate and validate
Trust Anchor (TA) Certification Authority (CA) certificate used in
RPKI validation.
but it should be:
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in
the
Resource Public Key Infrastructure (RPKI) to locate and validate
a Trust Anchor (TA) Certification Authority (CA) certificate used
in
RPKI validation.
i.e. 'validate Trust Anchor ... certificate' -> 'validate a Trust
Anchor ... certificate'.
- The 'Maintaining Multiple TA Key Pairs' section has:
An RP that can process TAK objects will only ever use one public
key for validation: either the current public key or the successor
public key once the relevant acceptance timer has expired.
There should be a comma after 'current public key', in order to
make it clearer that the acceptance timer is relevant to the
successor public key only.
- In the same section, the following:
If a TA uses a single remote publication server (per per [RFC8181])
for its key pairs per, then it MUST include all <publish/> and
<withdraw/> Protocol Data Units (PDUs) for the products of each of
its key pairs in a single query in order to reduce the risk of RPs
seeing inconsistent data in the TA's RPKI repositories.
should be:
If a TA uses a single remote publication server (per [RFC8181])
for its key pairs, then it MUST include all <publish/> and
<withdraw/> Protocol Data Units (PDUs) for the products of each of
its key pairs in a single query in order to reduce the risk of RPs
seeing inconsistent data in the TA's RPKI repositories.
i.e. the two extra instances of 'per' should be removed.
- The overview has:
If they remain unchanged as at that time, then the RP will fetch
the successor public key, update its local state with that public
key and its associated certification location(s), and continue
processing using that public key.
'certification' in the above should be 'certificate' (missed this
in the previous edit, sorry).
-Tom
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
