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
