Service Identity in TLS
draft-ietf-uta-rfc6125bis-15

[Ballot comment]
# 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).

## 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

[Ballot comment]
Sadly, I support Lars' Worst DISCUSS Ever.

Thanks for doing the work here.  It's quite well done.  Just a couple of comments:

In Section 2, I find it weird to use SHOULD and MUST language to establish BCP 14 style interoperability requirements on future documents.

Section 1.5 defines "delegated domain" but doesn't use that term anywhere.

[Ballot 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.

[Ballot comment]
I almost balloted DISCUSS, simply to seize Lar's "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"."

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.

[Ballot comment]
Thanks for working on this necessary protocol maintenance.

Even though mentioning QUIC (multiple times) triggered TSV AD's bells I don't have any TSV related comments here. Thanks for Joe Touch for his TSVART review.

[Ballot 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
    user@voice.example.edu and identified by a URI of
    .  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

[Ballot 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

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-uta-rfc6125bis-14

Thank you for the work put into this document.

I find this document update useful ***BUT*** it lacks the support of the new SVCB (draft-ietf-dnsop-svcb-https)... May I recommend that this document is sent back to the WG in order to incorporate the SCVB (it is very similar to SRV IMHO)? I appreciate that the SVCB started in a different WG hence the disconnect even if some authors of the two I-Ds have the same affiliation ;-) I added the SVCB authors in copy to this ballot, just in case.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Orie Steele for the shepherd's detailed write-up including the WG consensus, *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Component or label ?

The text uses terms like `component of a domain name` while RFC 8499 (DNS terminology) would prefer to use `label of a domain name`. Most parts of the document correctly use 'labels' but there are some use of 'component'.

## Section 1.4.2

s/Certificates representing client identities other than as described above, such as rfc822Name, are beyond the scope of this document/Certificates representing client identities, such as rfc822Name, other than as described above are beyond the scope of this document/ to simplify the parsing ?

# NITS

## Section 1.4.2

`for our purposes we care`, RFCs usually do not use a personal voice. But this is a matter of taste.

[Ballot comment]
Thank you to Derrell Piper for the SECDIR review.

Thank you for this critical maintenance to RFC6125.

** Section 5.

  If the certificate will be used for only a single type of application
  service, the service provider SHOULD request a certificate that
  includes DNS-ID or IP-ID values that identify that service or, if
  appropriate for the application service type, SRV-ID or URI-ID values
  that limit the deployment scope of the certificate to only the
  defined application service type.

Given the scope of the document being restricted to DNS-, IP-, SRV-, and URI-ID, what is the circumstances under which this “SHOULD” guidance would NOT be followed?
 
  If a service provider offers multiple application service types and
  wishes to limit the applicability of certificates using SRV-IDs or
  URI-IDs, they SHOULD request multiple certificates, rather than a
  single certificate containing multiple SRV-IDs or URI-IDs each
  identifying a different application service type.

The SHOULD in this text implies there is an alternative to requesting multiple certificates?  What is that?

** Section 6.1.1
  *  If a server for the application service type is typically
      associated with a URI for security purposes (i.e., a formal
      protocol document specifies the use of URIs in server
      certificates), then the reference identifier SHOULD be a URI-ID.

I appreciate that this is unchanged language from RFC6125.  If the application service is using a URI, under what circumstances would the reference identifier NOT be a URI-ID?

** Section 6.2
  The
  search succeeds if any presented identifier matches one of the
  reference identifiers, at which point the client SHOULD stop the
  search.

What is the standardized behavior if the client keeps looking after the first match (i.e., it is a SHOULD, not a MUST to stop)?

** From idnits:

  == Outdated reference: draft-ietf-tls-subcerts has been published as RFC
    9345

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-uta-rfc6125bis-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-07-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-uta-rfc6125bis@ietf.org, orie@transmute.industries, paul.wouters@aiven.io, uta-chairs@ietf.org, uta@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service Identity in TLS) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'Service Identity in TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-07-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Many application technologies enable secure communication between two
  entities by means of Transport Layer Security (TLS) with Internet
  Public Key Infrastructure Using X.509 (PKIX) certificates.  This
  document specifies procedures for representing and verifying the
  identity of application services in such interactions.

  This document obsoletes RFC 6125.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/



No IPR declarations have been submitted directly on this I-D.

Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Petr Špaček. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-uta-rfc6125bis-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-05-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-uta-rfc6125bis@ietf.org, orie@transmute.industries, paul.wouters@aiven.io, uta-chairs@ietf.org, uta@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service Identity in TLS) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'Service Identity in TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-05-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Many application technologies enable secure communication between two
  entities by means of Transport Layer Security (TLS) with Internet
  Public Key Infrastructure Using X.509 (PKIX) certificates.  This
  document specifies procedures for representing and verifying the
  identity of application services in such interactions.

  This document obsoletes RFC 6125.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-uta-rfc6125bis

March 15th 2023.

Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals,
  with others being silent, or did it reach broad agreement?

  a. The document passes the WGLC in July 2022 with plenty of reviews and was about to be sent to the IESG,
    but at the last moment a suggestion was made to include handling of IP addresses in certificates too
    (which was considered out of scope for this document before, since it was focused on domain names).
    After some discussion a consensus was achieved to make this addition and thus to delay the publication.
    During the second WGLC in the fall of 2022 the activity of the WG was relatively low, with only few reviews.
    Later, early in 2023, there was good discussion regarding how much detail to apply regarding internationalized domain names.
    I believe the document represents broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  a. The document was originally published as an individual draft in February 2021 with a modest goal of updating RFC 6125
    to disallow a common practice of using the commonName attribute in certificates to represent service identities that
    can be represented in the subjectAlternativeName. The draft was adopted in April 2021 with strong support from WG
    members. It was very well discussed in the ML right after its adoption and during this discussion the WG made a
    decision (backed up by the responsible AD) to create a replacement document for RFC 6125 instead of updating it.
    Some of the original authors of RFC 6125 agreed to co-author a -bis document, and the draft received a
    lot of attention from WG members with a good level of discussion.

  b. There has been some controversy regarding how much detail should be provided on IDNA2003 / IDNA2008 / UTS-46.
    Chairs ran a call for consensus and concluded that the working group had no consensus to profile or
    elaborate in great detail on the differences between IDNA2008 and UTS-46.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
  If so, please summarize the areas of conflict in separate email messages to the responsible Area Director.
  (It should be in a separate email because this questionnaire is publicly available.)

  a. Not to our knowledge.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated plans to implement?
  Are any existing implementations reported somewhere, either in the document
  itself (as RFC 7942 recommends) or elsewhere (where)?

  a. There are many implementations because RFC 6125 is cited by dozens of specs.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations,
  and would it therefore benefit from their review? Have those reviews occurred?
  If yes, describe which reviews took place.

  a. Opdsdir provided an early review:
    i. https://mailarchive.ietf.org/arch/msg/uta/PybBEjGBcYEH42v4dHABs3xBgq8/
  b. I18n provided an unofficial review:
    i. https://mailarchive.ietf.org/arch/msg/uta/nVtcFhJri8T7mW36Jmb4DoHXbbg/
  c. Secdir provided a review:
    i. https://mailarchive.ietf.org/arch/msg/uta/5X3it5mygcgw3A8kNOdQSE-_yHQ/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  a. N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the recommended validation tools for syntax and formatting validation?
  If there are any resulting errors or warnings, what is the justification
  for not fixing them at this time? Does the YANG module comply with the
  Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

  a. N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  a. Reviews were performed on the mailing list, there was no automated checking.

Document Shepherd Checks

9. Based on the shepherd's review of the document,
  is it their opinion that this document is needed,
  clearly written, complete, correctly designed,
  and ready to be handed off to the responsible Area Director?

  a. Yes.

10. Several IETF Areas have assembled lists of common issues that their
  reviewers encounter. For which areas have such issues been identified and addressed?
  For which does this still need to happen in subsequent Reviews?

  a. N/A

11. What type of RFC publication is being requested on the IETF stream (Best
  Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)?
  Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

  a. Proposed Standard, see answer to (2), Yes, data tracker indicates "Intended RFC status: Proposed Standard"

12. Have reasonable efforts been made to remind all authors of the intellectual
  property rights (IPR) disclosure obligations described in BCP 79?
  To the best of your knowledge, have all required disclosures been filed?
  If not, explain why. If yes, summarize any relevant discussion,
  including links to publicly-available messages when applicable.

  a. Yes, I have asked the authors privately and they confirmed they are not aware of any IPR issues related to the document.

13. Has each author, editor, and contributor shown their willingness to be listed as such?
  If the total number of authors and editors on the front page is greater than five, please provide a justification.

  a. Yes

14. Document any remaining I-D nits in this document. Simply running the idnits
  tool is not enough; please review the "Content Guidelines" on authors.ietf.org.
  (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)
 
  a. There are no major I-D nits.
 
15. Should any informative references be normative or vice-versa? See the IESG
  Statement on Normative and Informative References.

  a. Not to our knowledge.

16. List any normative references that are not freely available to anyone. Did
  the community have sufficient access to review any such normative references?

  a. None.

17. Are there any normative downward references (see RFC 3967 and BCP 97)
  that are not already listed in the DOWNREF registry? If so, list them.

  a. Not to our knowledge.

18. Are there normative references to documents that are not ready to be
  submitted to the IESG for publication or are otherwise in an unclear state?
  If so, what is the plan for their completion?

  a. No.

19. Will publication of this document change the status of any existing RFCs? If
  so, does the Datatracker metadata correctly reflect this and are those RFCs listed
  on the title page, in the abstract, and discussed in the
  introduction? If not, explain why and point to the part of the document
  where the relationship of this document to these other RFCs is discussed.

  a. This document will obsolete RFC 6125.

20. Describe the document shepherd's review of the IANA considerations section,
  especially with regard to its consistency with the body of the document.
  Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified.
  Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

  a. There are no IANA considerations

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

  a. There are no IANA considerations.

Document Shepherd Write-Up for draft-ietf-uta-rfc6125bis

March 15th 2023.

Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals,
  with others being silent, or did it reach broad agreement?

  a. The document passes the WGLC in July 2022 with plenty of reviews and was about to be sent to the IESG,
    but at the last moment a suggestion was made to include handling of IP addresses in certificates too
    (which was considered out of scope for this document before, since it was focused on domain names).
    After some discussion a consensus was achieved to make this addition and thus to delay the publication.
    During the second WGLC in the fall of 2022 the activity of the WG was relatively low, with only few reviews.
    Later, early in 2023, there was good discussion regarding how much detail to apply regarding internationalized domain names.
    I believe the document represents broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  a. The document was originally published as an individual draft in February 2021 with a modest goal of updating RFC 6125
    to disallow a common practice of using the commonName attribute in certificates to represent service identities that
    can be represented in the subjectAlternativeName. The draft was adopted in April 2021 with strong support from WG
    members. It was very well discussed in the ML right after its adoption and during this discussion the WG made a
    decision (backed up by the responsible AD) to create a replacement document for RFC 6125 instead of updating it.
    Some of the original authors of RFC 6125 agreed to co-author a -bis document, and the draft received a
    lot of attention from WG members with a good level of discussion.

  b. There has been some controversy regarding how much detail should be provided on IDNA2003 / IDNA2008 / UTS-46.
    Chairs ran a call for consensus and concluded that the working group had no consensus to profile or
    elaborate in great detail on the differences between IDNA2008 and UTS-46.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
  If so, please summarize the areas of conflict in separate email messages to the responsible Area Director.
  (It should be in a separate email because this questionnaire is publicly available.)

  a. Not to our knowledge.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated plans to implement?
  Are any existing implementations reported somewhere, either in the document
  itself (as RFC 7942 recommends) or elsewhere (where)?

  a. There are many implementations because RFC 6125 is cited by dozens of specs.

Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations,
  and would it therefore benefit from their review? Have those reviews occurred?
  If yes, describe which reviews took place.

  a. Opdsdir provided an early review:
    i. https://mailarchive.ietf.org/arch/msg/uta/PybBEjGBcYEH42v4dHABs3xBgq8/
  b. I18n provided an unofficial review:
    i. https://mailarchive.ietf.org/arch/msg/uta/nVtcFhJri8T7mW36Jmb4DoHXbbg/
  c. Secdir provided a review:
    i. https://mailarchive.ietf.org/arch/msg/uta/5X3it5mygcgw3A8kNOdQSE-_yHQ/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  a. N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the recommended validation tools for syntax and formatting validation?
  If there are any resulting errors or warnings, what is the justification
  for not fixing them at this time? Does the YANG module comply with the
  Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

  a. N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  a. Reviews were performed on the mailing list, there was no automated checking.

Document Shepherd Checks

9. Based on the shepherd's review of the document,
  is it their opinion that this document is needed,
  clearly written, complete, correctly designed,
  and ready to be handed off to the responsible Area Director?

  a. Yes.

10. Several IETF Areas have assembled lists of common issues that their
  reviewers encounter. For which areas have such issues been identified and addressed?
  For which does this still need to happen in subsequent Reviews?

  a. N/A

11. What type of RFC publication is being requested on the IETF stream (Best
  Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)?
  Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

  a. Proposed Standard, see answer to (2), Yes, data tracker indicates "Intended RFC status: Proposed Standard"

12. Have reasonable efforts been made to remind all authors of the intellectual
  property rights (IPR) disclosure obligations described in BCP 79?
  To the best of your knowledge, have all required disclosures been filed?
  If not, explain why. If yes, summarize any relevant discussion,
  including links to publicly-available messages when applicable.

  a. Yes, I have asked the authors privately and they confirmed they are not aware of any IPR issues related to the document.

13. Has each author, editor, and contributor shown their willingness to be listed as such?
  If the total number of authors and editors on the front page is greater than five, please provide a justification.

  a. Yes

14. Document any remaining I-D nits in this document. Simply running the idnits
  tool is not enough; please review the "Content Guidelines" on authors.ietf.org.
  (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)
 
  a. There are no major I-D nits.
 
15. Should any informative references be normative or vice-versa? See the IESG
  Statement on Normative and Informative References.

  a. Not to our knowledge.

16. List any normative references that are not freely available to anyone. Did
  the community have sufficient access to review any such normative references?

  a. None.

17. Are there any normative downward references (see RFC 3967 and BCP 97)
  that are not already listed in the DOWNREF registry? If so, list them.

  a. Not to our knowledge.

18. Are there normative references to documents that are not ready to be
  submitted to the IESG for publication or are otherwise in an unclear state?
  If so, what is the plan for their completion?

  a. No.

19. Will publication of this document change the status of any existing RFCs? If
  so, does the Datatracker metadata correctly reflect this and are those RFCs listed
  on the title page, in the abstract, and discussed in the
  introduction? If not, explain why and point to the part of the document
  where the relationship of this document to these other RFCs is discussed.

  a. This document will obsolete RFC 6125.

20. Describe the document shepherd's review of the IANA considerations section,
  especially with regard to its consistency with the body of the document.
  Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified.
  Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

  a. There are no IANA considerations

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

  a. There are no IANA considerations.