[Uta] Lars Eggert's Discuss on draft-ietf-uta-rfc6125bis-14: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

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
     [e-mail] 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