Lars Eggert has entered the following ballot position for draft-ietf-tls-subcerts-14: 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/about/groups/iesg/statements/handling-ballot-positions/ 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/doc/draft-ietf-tls-subcerts/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-tls-subcerts-14 CC @larseggert Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s). ## Comments ### Section 6, paragraph 2 ``` This document also defines an ASN.1 module for the DelegationUsage certificate extension in Appendix A. IANA has registered value 95 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the DelegationUsage certificate extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. ``` See Martin Duke's comment on using the Cloudflare space; I have the same question. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `man`; alternatives might be `individual`, `people`, `person` * Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`, `unacceptable`, `inapplicable`, `revoked`, `rescinded` ### IP addresses Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges: `1.3.5.1` and `5.5.7.0`. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 4.2, paragraph 1 ``` - This documnt defines a new X.509 extension, DelegationUsage, to be + This document defines a new X.509 extension, DelegationUsage, to be + + ``` ### Outdated references Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may be on purpose). ### Grammar/style #### Paragraph 2 ``` his document describes a mechanism to to overcome some of these limitations ^^^^^ ``` Possible typo: you repeated a word. #### Section 5.1, paragraph 1 ``` tial's private key is thus important and access control mechanisms SHOULD be ^^^^ ``` Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). #### Section 6, paragraph 1 ``` f early revocation. Since it is short lived, the expiry of the delegated cre ^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 7, paragraph 1 ``` ime could be unique and thus privacy sensitive clients, such as browsers in i ^^^^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
