Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Kenneth Vaughn <kvaughn@trevilon.com> Wed, 01 March 2023 18:30 UTC

Return-Path: <kvaughn@trevilon.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8162FC151545; Wed, 1 Mar 2023 10:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=trevilon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwGFRCpYOoNq; Wed, 1 Mar 2023 10:30:14 -0800 (PST)
Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ADDC14CE30; Wed, 1 Mar 2023 10:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T/MMx4O16AoLM5RPrjfFwuC8Yt78l4orkbGXHim/D24=; b=Bf3I97HQcnDs7uwwZPVDEjlspf ghq0lZ8ZAtiE/m55iOwo25j2PEVJanR1OOyR4w9Px4NF0c7mpJ0Y17jtBE7hfqWGU+US/2/6j5kXy l4YaTJ58DUZW5ZcJQCINMfF3B;
Received: from [98.97.177.125] (port=21203 helo=smtpclient.apple) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <kvaughn@trevilon.com>) id 1pXRDP-00008v-RL; Wed, 01 Mar 2023 18:30:12 +0000
From: Kenneth Vaughn <kvaughn@trevilon.com>
Message-Id: <ED692615-B5CF-458B-A911-F965C56BB0DE@trevilon.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0562E045-71AD-4A37-9120-6D6A623A9164"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 01 Mar 2023 13:30:08 -0500
In-Reply-To: <167758765810.37270.16823163994872633891@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-opsawg-tlstm-update@ietf.org, opsawg@ietf.org, opsawg-chairs@ietf.org
To: Lars Eggert <lars@eggert.org>
References: <167758765810.37270.16823163994872633891@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - tre.trevilon.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - trevilon.com
X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com
X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/DwgOa_ZZdFQd8GNkqsNdRGxXKiw>
Subject: Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2023 18:30:18 -0000

See responses below

Regards,
Ken Vaughn

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

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

As Joe point out, there was not a formal MIB doctors review, but the changes were minor and there were less formal reviews by MIB experts. To your point about minor changes potentially creating bugs, I have used the MIB validator at simple web.org to ensure that the MIB compiles without errors.

> ### 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?
I have revised the text to state "The update also emphasizes the [RFC8996] requirement that prohibits the use of TLS versions prior to TLS 1.2 when using SNMP." In other words, RFC 8996 is much broader than SNMP, so this document does not replace that document, but we do highlight the requirement so that readers are aware of the restriction.
 
> ### Missing references
> 
> No reference entries found for these items, which were mentioned in the text:
> `[RFC3413]`, `[RFC2579]`, `[RFC3411]`, `[RFC2578]`, and `[RFC2580]`.
All of these references are part of either STD58 or STD62, both of which are listed under normative references. 

I have not made any changes as it is unclear how this should be handled. 
Do I leave as is? 
Do I change the introduction to the MIB to only state that "This module makes reference to ... [STD58], [STD62], ..." and leave the MIB as is?
Do I change the intro as above and also change the comments in the IMPORTS statement (which would seem to lose valuable informative information)?
Do I change the normative references to cite each of the individual RFCs instead of the STD#s
Do I change the normative references to cite each of the individual RFCs in addition to the STD#s
NOTE: The STD#s are never directly referenced in the text but the other documents in the series provide context and the fact that these are part of a STD is perhaps useful to show as well. I am happy to implement whatever change is appropriate, but I do not know which to choose.

> ### Uncited references
> 
> Document updates `RFC6353`, but does not cite it as a reference, which is a bit
> odd.
I do not understand this comment. The document is cited in the body of the text (e.g., first paragraph of Section 2) and is listed under normative references. I am not sure what additional citation is being proposed.