Hi Behcet, Thank you for your review. Updated text is in this commit: https://github.com/timbru/draft-sidrops-publication-server-bcp/commit/2b441e82332516e886628b2cad0103e33ec8f73c
See inline, for quick responses. > On 9 Sep 2026, at 21:44, Behcet Sarikaya via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-sidrops-publication-server-bcp > Title: Best Practices for Operating Resource Public Key Infrastructure (RPKI) > Publication Services Reviewer: Behcet Sarikaya Review result: Ready with > Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-sidrops-publication-server-bcp-10 > > Reviewer: Behcet Sarikaya > Review Date: 2026-09-09 > IETF LC End Date: 2026-09-11 > IESG Telechat date: Not scheduled for a teletext > > Summary:The document is intended to be a BCP to describe operating Resource > Public Key > Infrastructure publication engine and its associated publicly > accessible rsync and RPKI Repository Delta Protocol repositories. > > It has many issues, editorial which I mainly concentrated and technical as can > be seen in other reviews. Major issues: > > Minor issues: > > Nits/editorial comments: > > Section 1 > > Par. 3 > Publication services operations t > > a hanging t??? Dangling sentence was removed. Apologies, overlooked this when editing. > Par.4 > > These services typically include the > Publication Enging (backend) and the public facing repositories for > RRDP and rsync functions. > > Enging -> Engine This was already fixed in an earlier commit (after publication of -10) > > Par. 5 > seperation of functions -> > separation of functions ack > > Par 6 > In a addition some guidance is provided for CA operators in as far as > CA operator choices relate to publication > -> In addition ... ack > There is a figure in Section 1 with no caption As the figure is introduced in the text and not referenced elsewhere I don't think it needs a caption. > Section 2.3 > RP Relying Party > This document discusses the use of RP in routing however there is another very > important area where RP is used, in identity protocols like OAUTH 2.0. The > resources they protect in each case are completely different. This leads to a > confusion in readers mind. I think the document should have one or two > paragraphs to explain this unfortunate (?) name convention or if there are > places where they interact. Answered by Job in another thread. > > Section 4.1 > 2nd par. > the acronym CDN is expanded here but already used in Section 1 twice. Ok, I expended the mention in the text of section 1 instead. I left the acronym in the figure because of space. Thank for you for the review. Tim > > _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
