Hi Mike, Thank you for the update of your ballot position.. I put some inline comments to your comments and will address remaining points in an updated version of the draft. I think several of them are already addressed in the updated versions.
Best regards Steffen > -----Original Message----- > From: Mike Bishop via Datatracker <nore...@ietf.org> > Sent: Monday, May 12, 2025 5:14 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de; i...@kovatsch.net > Subject: Mike Bishop's No Objection on draft-ietf-anima-brski-prm-21: (with > COMMENT) > > Mike Bishop has entered the following ballot position for > draft-ietf-anima-brski-prm-21: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to > https://www.ietf.or/ > g%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C9845670bbd > 3a49ffa0a508dd91679b04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638826596342578431%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=S23EKT4Iw31RvT%2BI7OYnuZPIyERmo9L > LIvUw56y0uwM%3D&reserved=0 > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker/. > ietf.org%2Fdoc%2Fdraft-ietf-anima-brski- > prm%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C9845670bbd3a49f > fa0a508dd91679b04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8826596342617070%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=1zRUNfkGZcXZ9AEdyAczwdFRIZJDStSj7nsxD2 > nIT6s%3D&reserved=0 > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my previous DISCUSS. > > Please see > https://datatracker/. > ietf.org%2Fdoc%2Fstatement-iesg-handling-ballot-positions- > 20220121%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C9845670bbd > 3a49ffa0a508dd91679b04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638826596342650059%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=e1dtGYTfiLwqP8%2BmIiFlm2ohII%2BRQq > UwjdDjTpe%2BVTU%3D&reserved=0 > for more details on handling ballot positions. These comments are offered > purely to improve the document, and their incorporation is at the discretion > of > the authors and the responsible AD. > > ===================== > > In 5.1, can the contents of the slide be extracted and placed as a figure in > the document, or is there a reason we need to deep-link into an old > presentation? [stf] We had the slide included as it provides a n architecture and process overview of BRSKI-PRM and was asked for by the AD. As we did not have the possibility to provide the same level of detail using an embedded graphic, we decided for the link. BTW, for BRSKI-AE (meanwhile RFC 9733 we did the same. This is not a justification but just to state that the approach has been taken before. > Section 7.3 appears in neither of the tables in 6.2/6.3; upon further reading, > I see that's because the endpoint is already defined in RFC8995. However, as > the behavior is modified in this document I suggest noting the existence of > behavior changes in 6.3, even if it's not a new endpoint. It helps make > Section > 6 a more complete roadmap of the forthcoming section. [stf] I added a hint regarding Section 7.3 in Section 6.3 just below the table in former revisions of the draft. I did not put it into the table as it is not an additional endpoint. > The third paragraph of 6.3.1 seems unclear. Perhaps reword this? [stf] Do you have a suggestion here? The intention was to underline that the Registrar may be configurable to only support dedicated Registrar-Agents, based on the Registrar-Agent certificate. > Check your usage of the terms "HTTP(S)", "HTTPS", and "HTTP-over-TLS". I > assume > that the first two are intended to differentiate when TLS is optional and when > it's required, but the latter two seem duplicative of each other. [stf] Ah, I addressed this already in former revisions, but forgot to update the heading of Appendix B. We will stick to HTTP(S). > Some of the 2119 language in 7.x is unneeded; a few examples: > - "MUST begin" could simply be "begins". The Agent is acting in its own time > when it wants to begin the process. - "SHALL trigger" could simply be > "triggers", and so on. - "MASA ... MUST support the same formats" is simply a > statement of a correct deployment, not a protocol conformance issue. If the > MASA doesn't support the format, the agent will get the 415 status code > described below. [stf] These have already been incorporated in earlier revisions. > The requirements on the formats of the messages are appropriate 2119 targets, > however, as is the Pledge's response when a trigger message is received. > > Given the multiple ways that processing caCerts could fail, it might be worth > permitting some optional error detail in 7.7.2 for the Registrar-Agent to log > and/or debug. > > Appendix A.2 defines the culinary term "parboiled" and references its use in > RFC 8995. It appears that while 8995 uses it in the filename of one example, > it > does not use the term to define any portion of the protocol, nor does this > document. If its use is widespread among implementers and it is > useful/necessary to know, elevate it to a Section 2 definition and use it as > appropriate throughout the document. Otherwise, it seems like the term could > be > dropped entirely without loss of clarity. [stf] Has been changed in earlier revisions of the draft. > > Nits: > > - Section 4 has several extraneous commas. > - Expand "incl." in 5.1 > - Consider expanding/defining CMS on first use or in Terminology, including a > reference directly to RFC 5652 - Section 7.6, inconsistent capitalization of > R/registrar and "to optimize [this process]"? - Section 7.7, extra comma after > "only be done" - Section 11 has bullet points that render as in-line asterisks [stf] Has been updated accordingly in former revisions of the draft. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
