Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-sdi-12: 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.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in the -12 (and -11? My notes claim I reviewed the -10, though the datatracker history says it was the -11; perhaps there was some skew between when I opened the doc and balloted). They get most of the way to where I want us to be, so I'm switching to No Objection. That said, the Abstract and Introduction still feel like they're slightly overstating the confidentiality protection attainable with this mechanism: The Abstract currently says "to provide confidentiality to initial configuration during bootstrapping", but we may need to hedge that a bit more, e.g., that this is partial or limited confidentiality. Similarly, Section 1 currently says "while maintaining confidentiality of the initial configuration", and would get similar treatment. Finally, I see that you took my suggestion of using "directory service" instead of "Certificate Publication Server". It may be worth a reference for this concept -- e.g., Section 2.1 of RFC 5280 references both [X.500] and RFC 4510 as potential ways to provide directory service for obtaining certificates. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
