Operational Considerations for RADIUS and TLS-PSK
draft-ietf-radext-tls-psk-12

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-radext-tls-psk and RFC 9813, changed IESG state to RFC Published)

[Ballot comment]
In Section 4.2.1:

* Identities SHOULD be in UTF-8 format. Identities with embedded control characters, NUL octets, etc. SHOULD NOT be used.

Why's the second one only a SHOULD NOT?  For that matter, is it redundant to the former SHOULD, which I'm pretty sure doesn't allow them anyway?

* Where the NAI format is expected, identities which are not in NAI format SHOULD be rejected

Same question.

In 6.2.3:

"If a safe decision is not possible, TLS-PSK servers SHOULD reject the resumption and continue with a full handshake."

Why only SHOULD?  What happens to security or interoperability if I don't?  Some guidance to implementers would be helpful here if you want to leave it at SHOULD.

[Ballot comment]
Thanks for working on this specification.

One comment - can't this document title be more descriptive ? like - Guidance/considerations for using TLS-PKS with RADIUS

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-radext-tls-psk-10

Thank you for the work put into this document.

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 Valery Smyslov 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 (non-blocking)

## Title

s/RADIUS and TLS-PSK/Operational Considerations for RADIUS and TLS-PSK/ ?

## Section 1

Please expand PSK at first use ? I.e., move the last paragraph to the top of this section.

Suggest avoiding "we" in an IETF document, e.g., `While we recognize` Possibly using passive voice.

`from a small number of known locations` I think that this BCP also applies when there are a larger number of clients, the "key" here is about a limited set of *known* clients.

## Section 3

Suggest using "Using PSK vs. Certificates" as section title, or simply "Justification of PSK".

## Section 4.1

Suggest to introduce the acronym KDF before the RFC 9258 quote.

Hummm it seems strange to read `Another possibility is to forbid the use of TLS 1.3` in an IETF document... Let's delete this part and keep only `to forbid the use of TLS versions less than TLS 1.3`

How can an implementation check that `which SHOULD be derived from a source with at least 128 bits of entropy` if the PSK comes from outside the RADIUS client/server? The following paragraph seems more appropriate.

## Section 4.2.1

Many "SHOULD" in this section but without any warning about the consequence if the SHOULD are ignored. Let's help the implementers/operators when making their choices.

## Section 4.3

I am afraid that I do not understand how using separate PSK for each client/server pair (which is good) is compatible with `allows administrators to re-use PSKs and PSK Identities`

## Section 6.2

As noted by the idnits tool, please use an IPv6 documentation prefix rather than `192.0.2.0/24` after all we are in 2024 ;-)

# NITS (non-blocking / cosmetic)

## E.g.

AFAIK, in English "e.g." is always followed by a ",".

## Sections 5 & 6

s/the use of a pre-shared key (TLS-PSK) for RADIUS/TLS/the use of a PSK for RADIUS/TLS/ ?

## Use of "source IP"

The document should use "source IP address(es)" instead of "source IP".

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-radext-tls-psk-10
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-radext-tls-psk-10.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Hilarie Orman for the SECDIR review.

I don't feel their comment about key lifetimes or rotation / change procedures is addressed in the document.

I noted the shepherd writeup said the document was sent to UTA and received no comments.

I am not a TLS or RADIUS expert.

Many of my comments are of the form "why not must", for a BCP there SHOULD be more MUSTs... unless there is some good reason, in which case, that reason should be provided.

I also think the document suffered from not having Security Considerations, as requirements, guidance and commentary was sometimes difficult to distinguish.

There are 2 points I want to raise as most concerning (although this is not a DISCUSS):

- User Interface Security Guidance & UTF-8
- Character Encodings of Symmetric Keys

With some restructuring I believe this 2 topics could be better addressed, and the document could be easier to read.

### Encoding Entropy

```
221   Implementations MUST support PSKs of at least 32 octets in length,
222   and SHOULD support PSKs of 64 octets or more.  As the PSKs are
```

```
235   Implementations MUST require that PSKs be at least 16 octets in
236   length, which SHOULD be derived from a source with at least 128 bits
237   of entropy.  That is, short PSKs MUST NOT be permitted to be used,
```

As I understand this section, some of these requirements are for security purposes, (min key length and requirement for it to be produced from a safe random number source) and some are for usability (people want to compare strings, or input a text string into APIs).

This section would be easier to understand, and safer to implement if it were broken down into:

#### Requirements

- length requirements for symmetric keys.
- generating symmetric keys with sufficient entropy.

#### Usability Guidance

- text encoding symmetric keys for comparison, storage or display.
- commenting on consuming text encoded symmetric keys.
- length requirements for text encoded symmetric keys.
- example commands.

### User Interface Considerations

```
321   the same value for PSK and shared secret.  To prevent administrative
322   errors, implementations SHOULD NOT provide user interfaces which
323   allow both PSKs and shared secrets to be entered at the same time.
```

When can this SHOULD be ignored?

You might consider separating the user interface guidance from the implementation guidance.

Later you note:

```
340   for encoding and comparison of PSK identities.  It is RECOMMENDED
341   that systems follow the directions of [RFC9257], Section 6.1.1 when
342   using PSK Identities for RADIUS/TLS.
```

When can this recommendation be ignored?

Copy pasting, and entering unicode apply anywhere you are accepting UTF-8.

Please consider referencing PRECIS:

https://datatracker.ietf.org/doc/rfc8265/

### Why not must?

```
217   It is RECOMMENDED that systems follow the directions of [RFC9257],
218   Section 6 for the use of external PSKs in TLS.  That document
219   provides extremely useful guidance on generating and using PSKs.
```

When can this recommendation be ignored, or phrased another way...
when is it best current practice to not follow the directions of RFC9257?

### Restating RFC9257 6.1.2

```
366   It is up to administrators and implementations as to how they
367   differentiate external PSK identities from session resumption PSK
368   identities used in TLS 1.3 session tickets.  One approach could be to
369   have externally provisioned PSK identities contain an NAI such as
370   described above, while session resumption PSK identities contain
371   large blobs of opaque, encrypted, and authenticated text.  It should
372   then be relatively straightforward to differentiate the two types of
373   identities.  One is UTF-8, the other is not.  One is not
374   authenticated, the other is authenticated.
```

I'm not a TLS expert, but does RFC9257 Section 6.1.2 address this already?
The bit about distinguishing based on UTF-8 is making me nervous...

### Suggested or recommended?

```
418   This validation flow is only suggested.  Other validation methods are
419   possible.
```

This material might be better in an appendix.

### Why not MUST?

```
447   below.  Any identity which is rejected by these validation rules
448   SHOULD cause the server to close the TLS connection.
```

```
457   *  Identities SHOULD be in UTF-8 format.  Identities with embedded
458       control characters, NUL octets, etc.  SHOULD NOT be used.
```

What happens if they are?

### Updates RFC6614?

```
519   [RFC6614] is silent on the subject of PSK identities, which is an
520   issue that we correct here.
```

### Consider consolidating UX recommendations in a single section

```
535   TLS-PSK sessions.  Therefore in order to prevent confusion between
536   shared secrets and TLS-PSKs, management interfaces and APIs need to
537   label PSK fields as "PSK" or "TLS-PSK", rather than as "shared
538   secret".
```

## Nits

### Abstract nits

```
12   This document gives implementation and operational considerations for
13   using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360).
14   The purpose of the document is to help smooth the operational
15   transition from the use of the insecure RADIUS/UDP to the use of the
16   much more secure RADIUS/TLS.
```

I stumbled on document "gives" and "much more secure", consider some rephrasing to improve the tone.

### Who is we?

```
106   much more secure RADIUS/TLS.  While we recognize that using PSKs is
107   often less preferable to using public / private keys, the operational
108   model of PSKs follows the legacy RADIUS "shared secret" model.  As
```

Consider rephrasing.

[Ballot comment]
Thanks to Hilarie Orman for the secdir review.

Section 4.1:  It has been a very long time since I've looked at this.  Why /dev/urandom and not /dev/rand?  I thought urandom wasn't buffered (basically providing whatever was in the buffer at the time, with no guarantee of quality)?  If there is an assumption that the machine has been up and running for 'a while', then that should be stated. [If I'm merely old, and not keeping up with the state of play here, just tell me.]

Section 5, bullet #1:  One might ask why one would choose something other than the recommended cipher suites.

Section 5.1, para 3:  I'd replace 'cracked' with 'successfully attacked', 'broken', 'exploited', or something more formal.

Section 8:  The statement that 'the primary focus is to address security considerations' is a little understated, maybe something like 'this entire draft is about security considerations for Radius'.  In addition, there are added security considerations listed in RFCs 8446, 9257, 9258 (and other RFCs) which might not have applied to Radius w/out the use of external PSKs.  It might make sense to call those out specifically.

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

IANA has completed its review of draft-ietf-radext-tls-psk-09, 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 Sr. Specialist

The following Last Call announcement was sent out (ends 2024-03-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-radext-tls-psk@ietf.org, paul.wouters@aiven.io, radext-chairs@ietf.org, radext@ietf.org, valery@smyslov.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RADIUS and TLS-PSK) to Best Current Practice


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document: - 'RADIUS and TLS-PSK'
  as Best Current Practice

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 2024-03-14. 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


  This document gives implementation and operational considerations for
  using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360).
  The purpose of the document is to help smooth the operational
  transition from the use of the insecure RADIUS/UDP to the use of the
  much more secure RADIUS/TLS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-tls-psk/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6614: Transport Layer Security (TLS) Encryption for RADIUS (Experimental - Internet Engineering Task Force (IETF))
    rfc7360: Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS (Experimental - Internet Engineering Task Force (IETF))
    rfc9257: Guidance for External Pre-Shared Key (PSK) Usage in TLS (Informational - Internet Engineering Task Force (IETF))

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?

The consensus is relatively broad. The draft has passed three WGLCs and the
activity of the WG members was decreasing from one to one. The last changes in the draft
concerned with the TLS session resumptions were discussed by less people, then when the first WGLC
took place. At the same time, these changes were discussed deep enough among few remaining
active WG members and the consensus was solid.

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

No controversy, the consensus is strong.

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.)

No.

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)?

There are at least two implementations of this draft:
  - FreeRADIUS (10+ years, only TLS 1.2)
  - radsecproxy

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.

The document was sent to the UTA WG for review. No comments were provided.

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.

Not applicable.

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?

The document contains no YANG module.

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.

Not applicable.

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?

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?

No issues were identified.

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?

Best Current Practice, as indicated in the text of the document and in the datatracker.

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.

Author has confirmed that he is unaware of any IPR related to this draft:
https://mailarchive.ietf.org/arch/msg/radext/l4-EQ1mLeo36N_U-ztvJ3a3tgFo/

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.

The document has only one author.

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.)

idnits reports three downward references (see below).
It also complains that there is an informative reference to RFC 5077,
which is obsoleted by RFC 8446. In fact, the recommendations from RFC 5077,
while being provided for TLS 1.0 and 1.1, are in practice also used for TLS 1.2,
and RFC 8446 makes no specific recommendations on ticket format (used for PSK identity).
Thus, referencing RFC 5077 seems appropriate.
idnits also falsly thinks that there are examples using only IPv4 addresses
(there are none at all) and there are some code (none as well).

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

No.

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

All normative references are freely available.

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.

There are three normative downward references:
1. RFC 6614 (Experimental)
2. RFC 7360 (Experimental)
3. RFC 9257 (Informational)

The draft updates both RFC 6614 and RFC 7360, thus these references are normative.
The draft also makes use of recommendations from RFC 9257, thus this RFC is also normatively referenced.

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?

All normative references are published RFCs.

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.

No.

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).

The document contains 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.

Not applicable.

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?

The consensus is relatively broad. The draft has passed three WGLCs and the
activity of the WG members was decreasing from one to one. The last changes in the draft
concerned with the TLS session resumptions were discussed by less people, then when the first WGLC
took place. At the same time, these changes were discussed deep enough among few remaining
active WG members and the consensus was solid.

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

No controversy, the consensus is strong.

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.)

No.

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)?

There are at least two implementations of this draft:
  - FreeRADIUS (10+ years, only TLS 1.2)
  - radsecproxy

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.

The document was sent to the UTA WG for review. No comments were provided.

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.

Not applicable.

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?

The document contains no YANG module.

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.

Not applicable.

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?

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?

No issues were identified.

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?

Best Current Practice, as indicated in the text of the document and in the datatracker.

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.

Author has confirmed that he is unaware of any IPR related to this draft:
https://mailarchive.ietf.org/arch/msg/radext/l4-EQ1mLeo36N_U-ztvJ3a3tgFo/

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.

The document has only one author.

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.)

idnits reports three downward references (see below).
It also complains that there is an informative reference to RFC 5077,
which is obsoleted by RFC 8446. In fact, the recommendations from RFC 5077,
while being provided for TLS 1.0 and 1.1, are in practice also used for TLS 1.2,
and RFC 8446 makes no specific recommendations on ticket format (used for PSK identity).
Thus, referencing RFC 5077 seems appropriate.
idnits also falsly thinks that there are examples using only IPv4 addresses
(there are none at all) and there are some code (none as well).

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

No.

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

All normative references are freely available.

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.

There are three normative downward references:
1. RFC 6614 (Experimental)
2. RFC 7360 (Experimental)
3. RFC 9257 (Informational)

The draft updates both RFC 6614 and RFC 7360, thus these references are normative.
The draft also makes use of recommendations from RFC 9257, thus this RFC is also normatively referenced.

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?

All normative references are published RFCs.

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.

No.

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).

The document contains 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.

Not applicable.

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?

The consensus is relatively broad. The draft has passed several WGLCs and the
activity of the WG members was decreasing. The last changes concerned with
TLS session resumptions were backed by far less people, then during the first WGLC.
At the same time, these changes were deep enough discussed among few remaining
active WG members and the consensus was solid.

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

No controversy, the consensus is strong.

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.)

No.

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)?

There are at least two implementations of this draft:
  - FreeRADIUS (10+ years, only TLS 1.2)
  - radsecproxy

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.

The document was sent to the UTA WG for review. No comments were provided.

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.

Not applicable.

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?

The document contains no YANG module.

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.

Not applicable.

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?

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?

No issues were identified.

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?

Best Current Practice, as indicated in the text of the document and in the datatracker.

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.

Author has confirmed that he is unaware of any IPR related to this draft:
https://mailarchive.ietf.org/arch/msg/radext/l4-EQ1mLeo36N_U-ztvJ3a3tgFo/

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.

The document has only one author.

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.)

idnits reports three downward references (see below).
It also complains that there is an informative reference to RFC 5077,
which is obsoleted by RFC 8446. In fact, the recommendations from RFC 5077,
while being provided for TLS 1.0 and 1.1, are in practice also used for TLS 1.2,
and RFC 8446 makes no specific recommendations on ticket format (used for PSK identity).
Thus, referencing RFC 5077 seems appropriate.

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

No.

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

All normative references are freely available.

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.

There are three normative downward references:
1. RFC 6614 (Experimental)
2. RFC 7360 (Experimental)
3. RFC 9257 (Informational)

The draft updates both RFC 6614 and RFC 7360, thus these references are normative.
The draft also makes use of recommendations from RFC 9257, thus this RFC is also normatively referenced.

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?

All normative references are published RFCs.

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.

No.

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).

The document contains 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.

Not applicable.