Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-tlstm-update-12: (with DISCUSS and COMMENT)

[Kenneth Vaughn <[e-mail]>]

Thank you for your input. I have made the revisions identified below... Please note the one question that I have about how to document RFC editor requests.

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
[phone] cell
[e-mail]
www.trevilon.com

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Should Section 2.3 or the Security Considerations not reference RFC 9325
> "Recommendations for Secure Use of Transport Layer Security (TLS) and
> Datagram Transport Layer Security (DTLS)" ? For one thing, it documents
> that if one needs to still use TLS 1.2, what options should be used or avoided.
I have added a sentence to the Security Considerations section as follows:

Implementations should consider the latest recommendations on the use of (DTLS), such as that documented in [RFC9325].

NOTE: Within the ITS industry, our current plan is to write our standards to require TLS 1.3 due to the fact that the current deployments of secure SNMP are very limited and we feel it is better to minimize variations at this point than to address the migration path - especially since these standards will not be finalized and deployed for at least a year or more. If you think this is ill-advised, I would be happy to hear the arguments for allowing 1.2.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>        REVISION    "202209090000Z"
>        DESCRIPTION "This version of this MIB module is part of
>                RFC XXXX; see the RFC itself for full legal
>                notices.  This version:
> 
> 
> It will be easy to miss this "RFC XXXX" for the RFC Editor, can be make a clearer note
> for the RFC editor to update that?
Happy to do so, but I'm not sure what you are looking for (I was under the impression that this is how I was supposed to document it and that the RFC editor checked for this text). Is there some special code that I am supposed to use to grab their attention?

> The REVISION is a date. Should that be updated to the publication date, or is it used
> as a sort of early code point ?
It is unclear to me exactly what date this is supposed to point to, but I have updated it to today since I added the OID due to another comment.

>        Historically, the 1-octet hashing algorithm identifier was
>        based on the IANA TLS HashAlgorithm Registry (RFC 5246);
>        however, this registry is only applicable to (D)TLS protocol
>        versions prior to 1.3, which are now designated as obsolete
>        and are not expected to ever support additional values.
> 
> I'm not sure "obsolete" is the right word?
> 
> Also, looking at:
> 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
> snmpTlstmCertCommonName OBJECT-IDENTITY
> 
> I don't see a note the registry is closed.
> 
> Perhaps weaken the claim to just "however, this registry is no longer in use for TLS 1.3
> and above and are not expected to have any new registrations added to it."
Change made


> 
>        The policy for updates is Expert Review.
> 
> Why not specification required or RFC required?  (Or split the range, as Roman alluded to as well)
There was a specific WG request to allow values that were not documented in an RFC (whether any 
will be allowed is another question, but there was at least one person who felt strongly about it and 
there does not seem to be any real disadvantage.

>