Re: [OPSAWG] AD review of draft-ietf-opsawg-tlstm-update-10

2023-02-06 Thread Rob Wilton (rwilton)
Hi Kenneth,

Apologies for the delay in progressing this. -11 is fine.

Just closing off a couple of questions inline below.


From: Kenneth Vaughn 
Sent: 23 December 2022 15:13
To: Rob Wilton (rwilton) 
Cc: draft-ietf-opsawg-tlstm-update@ietf.org; opsawg@ietf.org
Subject: Re: AD review of draft-ietf-opsawg-tlstm-update-10

Rob,

Thank you for your detailed comments. Please see my detailed responses inline 
below.

In general, I accepted the comments and reflected the changes in -11; the only 
two exceptions are that I did not add any requirements regarding the usage of 
hash algorithms based on prior WG discussions and I am unclear what issue you 
had with the editor's address field.

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com


On Dec 19, 2022, at 11:09 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

(1) p 4, sec 2.3.  TLS Version

TLSTMv1.3 MUST only be used with
  (D)TLS version 1.2 and later.

It wasn't clear to me exactly what is meant by TLSTMv1.3, and this is the only 
use of this term.  Could you be more specific here please?
I removed the "v1.3", which was erroneous text from a previous draft.


(2) p 6, sec 4.  MIB Module Definition

  Redistribution and use in source and binary forms, with or
  without modification, is permitted pursuant to, and subject
  to the license terms contained in, the Revised BSD License
  set forth in Section 4.c of the IETF Trust's Legal Provisions
  Relating to IETF Documents
  (http://trustee.ietf.org/license-info)."

Please add the RFC 2119 boilerplate text to this MIB.  E.g.,

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Done


(3) p 9, sec 4.  MIB Module Definition

 An SnmpTLSFingerprint value is composed of a 1-octet hashing
 algorithm ...

This description somewhat mixes the definition of what the field is, along with 
some historical context.  Hence, I suggest that it might be helpful to split 
the description between what the field is now vs how is was derived.
Change made


It also wasn't clear to me whether there is a restriction that only versions of 
(D)TLS greater than 1.3 may use an algorithm value greater than 8, and whether 
that restriction must be stated here.
The WG expressed that the hash algorithm used by the fingerprint did not have 
to track the (D)TLS usage and the selection is manufacturer specific. Thus, it 
would seem as if we should remain silent on this issue.

[Rob Wilton (rwilton)]
Okay, makes sense.



Nit level comments:

(4) p 8, sec 4.  MIB Module Definition

Typo, potenitally -> potentially
Corrected


(5) p 15, sec 4.  MIB Module Definition

  certificate, then additional rows MUST be searched looking

Extra line break in the description above?
Corrected


(6) p 27, sec 5.  Security Considerations

  SNMP versions prior to SNMPv3 did not include adequate security.
  Even if the network itself is secure (for example, by using IPsec),
  even then, there is no control as to who on the secure network is
  allowed to access and GET/SET (read/change/create/delete) the objects
  in this MIB module.

Suggest eliding the "even then" since the sentence starts with "Even ..."
Corrected by deleting the "even then"


(7) p 31, sec 8.2.  Informative References

  Kenneth Vaughn (editor)
  Trevilon LLC
  1060 Highway 107 South
  Del Rio, TN 37727
  United States of America
  Phone: +1 571 331 5670
  Email: kvau...@trevilon.com
Unclear what the comment is

[Rob Wilton (rwilton)]
Sorry, an unfortunately artifact from my comment script, you can ignore it.

Regards,
Rob



Grammar nits from an automated tool:
Grammar Warnings:
Section: 3.2, draft text:
This document does not specify an application profile, hence all of the 
compliance requirements in [RFC8446] apply.
Warning:  Consider using all the.
Suggested change:  "all the"
Corrected



Section: 6, draft text:
IANA is asked to create a new registry called the SNMP-TLSTM HashAlgorithm 
Registry in the Structure of Management Information (SMI) Numbers (MIB Module 
Registrations) Group and to update the proposed URL reference in the above MIB 
( listed as "https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml"; 
under SnmpTLSFingerprint), if needed, to accurately reflect its location.
Warning:  Don't put a space after the opening parenthesis.
Suggested change:  "("
Corrected



Regards,
Rob

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] Last Call: (Updates to the TLS Transport Model for SNMP) to Proposed Standard

2023-02-06 Thread The IESG


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Updates to
the TLS Transport Model for SNMP'
   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-c...@ietf.org mailing lists by 2023-02-20. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document updates RFC 6353 "Transport Layer Security (TLS)
   Transport Model for the Simple Network Management Protocol (SNMP)",
   to reflect changes necessary to support Transport Layer Security
   Version 1.3 (TLS 1.3) and Datagram Transport Layer Security Version
   1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".  This
   document is compatible with (D)TLS 1.2 and is intended to be
   compatible with future versions of SNMP and (D)TLS.

   This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/



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





___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg