[IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Mon, 12 December 2022 10:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3283C151713; Mon, 12 Dec 2022 02:24:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ipsecme-ikev1-algo-to-historic@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, kivinen@iki.fi, kivinen@iki.fi
X-Test-IDTracker: no
X-IETF-IDTracker: 9.2.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <167084069079.46817.6055063604904352116@ietfa.amsl.com>
Date: Mon, 12 Dec 2022 02:24:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rLZ8xAFZho4pfDGUkbrwrI_qM9o>
Subject: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 10:24:50 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-ipsecme-ikev1-algo-to-historic-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this.  A pretty easy document, and always good to clear out old
cruft.

I do wonder exactly how well understood "deprecated" is in the wider community.

E.g.,

(i) the definition of deprecated in YANG (RFC 7950) is:
   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

(ii) the definition in Java is:
  A program element annotated @Deprecated is one that programmers are
  discouraged from using, typically because it is dangerous, or because a
  better alternative exists. Compilers warn when a deprecated program element
  is used or overridden in non-deprecated code.

I think that the definition that security uses is presumably much closer to
(ii), or not even stronger in sentiment to move away from it?

I tried to search and find a definition in IANA of exactly what deprecated
means, but with no luck.

Perhaps there is already a security definition of deprecated that could be
referenced, or if not, it might be helpful to:
 - in Section 5, unambiguously specify what is meant by deprecated.
 - in Section 7, bind the definition of the Status column back to Section 5.

Regards,
Rob