Lars Eggert has entered the following ballot position for draft-ietf-uta-rfc6125bis-14: Discuss
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-uta-rfc6125bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-uta-rfc6125bis-14 CC @larseggert Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/kKymWzL6jRgmCfLhf0A8IJATMMQ). ## Discuss ### Section 4.2, paragraph 4 ``` Consider a SIP-accessible voice-over-IP (VoIP) server at the host voice.example.edu servicing SIP addresses of the form u...@voice.example.edu and identified by a URI of <sip:voice.example.edu>. A certificate for this service would include a URI-ID of sip:voice.example.edu (see [SIP-CERTS]) along with a DNS-ID of voice.example.edu. ``` This has got to be the most pedantic Discuss ever, but AFAICT "example.edu" is not in fact a valid example domain, i.e., it's missing from https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### 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 `traditional`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` ## 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. ### Outdated references Document references `draft-ietf-tls-subcerts`, but that has been published as `RFC9345`. ### URLs These URLs in the document can probably be converted to HTTPS: * http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf ### Grammar/style #### Section 4.1, paragraph 1 ``` SIP as described in [SIP-SIPS]). Typically this identifier type would supple ^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Typically". #### Section 4.2, paragraph 4 ``` s or IP-IDs. Again, because of multi-protocol attacks this practice is discou ^^^^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 6.2, paragraph 7 ``` DNS domain names more generally. Therefore the use of wildcard characters as ^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Therefore". ## 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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
