[dnsdir] Warren Kumari's Yes on draft-ietf-uta-rfc6125bis-14: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-uta-rfc6125bis-14: Yes

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I almost balloted DISCUSS, simply to seize Lars' "most pedantic Discuss ever"
crown, but I decided that the entertainment potential wasn't really worth it:
"I think that the convention / standard terminology is "subject alternative
name" or "subjectAltName", not "subjectAlternativeName"."

Instead, because the document is so very readable, I'm balloting Yes.

Nits:
"TLS uses the words client and server, where the client is the entity that
initiates the connection." - this might be better as 'TLS uses the words
"client" and "server", where the client is the entity that initiates the
connection.'

"During the course of processing, a client might be exposed to identifiers that
look like but are not reference identifiers." - "...look like, but are not..."

"Any intermediate values are not reference identifiers and MUST NOT be treated
as such. [...] However, an application might define a process for
authenticating these intermediate identifiers in a way that then allows them to
be used as a reference identifier; see for example [SMTP-TLS]." -  erm... I
know what you are trying to say here (at least I think that I do), but, as
written this seems logically inconsistant.  Perhaps something like: "Unless an
application defines a process for authenticating intermediate identifiers in a
way that then allows them to be used as a reference identifier (see for example
[SMTP-TLS]), any intermediate values are not reference identifiers and MUST NOT
be treated as such."... or something...

Question:
"Note also that by policy, Top-Level Domains ([DNS-TERMS]) do not start with a
digit (see Section 2.2.1.3.2 of [ICANN-AGB]); ..." - yup, that does indeed seem
to be the current policy, but another round of new TLDs seems imminent and it
isn't clear (to me at least) that this will always be true. Should the document
note that this is not set in stone?

Notes:
I agree with Eric's comments / suggestions re: support of the new SVCB
(draft-ietf-dnsop-svcb-https) mechanism. Unless there is a really good reason
to not mention it, it seems like it should be discussed.

I'd also like to thank the DNSDIR ( Petr Špaček -
https://datatracker.ietf.org/doc/review-ietf-uta-rfc6125bis-12-dnsdir-lc-spacek-2023-06-21/
) and OPSDIR ( Quin Wu -
https://datatracker.ietf.org/doc/review-ietf-uta-rfc6125bis-08-opsdir-early-wu-2022-12-16/
) for their helpful reviews, and to the authors for working with them to
address the comments.