Updates to the TLS Transport Model for SNMP
draft-ietf-opsawg-tlstm-update-15

Thank you for the work on this document.

I was going to have the same comment as Roman's first point. Additionally, and in any case, it would be good in my opinion to expand the Expert Guidelines, as the only guideline right now is "consult the security area" (and even then, it's only encouraged).

For more input about what I think should be there, RFC 8126 says it best:
  The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  **It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.**  It is also a good idea to include, when possible, a sense
   of whether many registrations are expected over time, or if the
   registry is expected to be updated infrequently or in exceptional
   circumstances only.

Thanks for this document. Thanks also to Joe Clarke for the detailed and helpful shepherd writeup.

I noticed one nit that I don’t think I’ve seen mentioned yet, “SMNPv3” -> “SNMPv3”.

# GEN AD review of draft-ietf-opsawg-tlstm-update-12

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VI00LPj0gVfsGW_qOfw9JlGAJdE).

## Comments

### Paragraph 2
```
                Updates to the TLS Transport Model for SNMP
                     draft-ietf-opsawg-tlstm-update-12
```
Was there a mibdoctors review of this I-D? Should there be?

### Section 1, paragraph 1
```
     This document updates and clarifies how the rules of [RFC6353] apply
     when using Transport Layer Security (TLS) or Datagram Transport Layer
     Security (DTLS) versions later than 1.2.  This document jointly
     refers to these two protocols as "(D)TLS".  The update also
     incorporates the [RFC8996] update, which prohibits the use of TLS
     versions prior to TLS 1.2. 
```
Should this document then not also obsolete RFC8996?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC3413]`, `[RFC2579]`, `[RFC3411]`, `[RFC2578]`, and `[RFC2580]`.

### Uncited references

Document updates `RFC6353`, but does not cite it as a reference, which is a bit
odd.

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

Reference `[RFC5953]` to `RFC5953`, which was obsoleted by `RFC6353` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

### Grammar/style

#### Section 4, paragraph 28
```
s not specify converting to lowercase so this involves an extra step). This
                                     ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 4, paragraph 90
```
nd this hash value MUST match exactly or the connection MUST NOT be establis
                                     ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

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

** Section 6. Per the new IANA registry:

-- Is the WG sure that expert review for the entire registry is sufficient?  I’ll point out that the “TLS HashAlgorithm” from which it forked defines ranges for code points (to include standards track … expert review).  

-- I applaud the design of this registry incorporating the notion of “Recommended”.  Based on the TLS experience of using that flag, specifically Section 5 of RFC8447, does stronger guidance need to be added on the threshold for getting a “Y” and the semantics of “N”.  In RFC8847, “Recommended=Y” requires a standards track; and “Recommended=N” allows for the possibility that the proposed algorithm is not “flawed”, simply that it hasn’t been reviewed by the IETF.

Thanks for working on this specification. Special thanks for the shepherd's write-up, it was very helpful.

I was just wondering - as there is an intended impact on the future here, 

   "Renegotiation of sessions is not supported as it is not supported by TLS 1.3."

what is the intended implication on the application of future versions of TLS?

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tlstm-update-12
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points.

Special thanks to Joe Clarke for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### MIB Doctor review

Like Lars, I wonder whether there was a MIB doctor review.

### Section 3.1

This text is repeated, is it on purpose ?
```
The reason 0-RTT is disallowed is that there are no "safe" messages that if replayed will be guaranteed to cause no harm at a server side: all incoming notification or command responses are meant to be acted upon only once. See Security considerations section for further details
```

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

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments