IETF Logo Mail Archive

Re: Last Call: <draft-housley-suite-b-to-historic-03.txt> (Reclassification of Suite B Documents to Historic Status) to Informational RFC

Paul Hoffman <paul.hoffman@icann.org> Tue, 20 February 2018 21:45 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB94F12DA3D; Tue, 20 Feb 2018 13:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To1bLtfSSrhX; Tue, 20 Feb 2018 13:45:31 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AA1120724; Tue, 20 Feb 2018 13:45:31 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Feb 2018 13:45:30 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 20 Feb 2018 13:45:30 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: IETF <ietf@ietf.org>
CC: "draft-housley-suite-b-to-historic@ietf.org" <draft-housley-suite-b-to-historic@ietf.org>
Subject: Re: Last Call: <draft-housley-suite-b-to-historic-03.txt> (Reclassification of Suite B Documents to Historic Status) to Informational RFC
Thread-Topic: Last Call: <draft-housley-suite-b-to-historic-03.txt> (Reclassification of Suite B Documents to Historic Status) to Informational RFC
Thread-Index: AQHTqpQf0kIgBFc6r0aiIcEQ6W62ow==
Date: Tue, 20 Feb 2018 21:45:29 +0000
Message-ID: <A1DADA0C-CBD6-4FB5-97E0-C9288F540C6C@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_61DEC069-9C95-4176-9A72-EC01F9D72CD8"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/oExfbszvjG16CVVo7ivtU_0JAlI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2018 21:45:35 -0000

This document seems fine in general. I have concern about a possible misperception that one document that is made historic by it (RFC 6460) could affect the standards status of two documents that refer to it, namely RFC 6650 and RFC 8253. To prevent the misperception, I propose the following additions in Section 4.5:

   RFC 6605, "Elliptic Curve Digital Signature Algorithm (DSA) for
   DNSSEC" [RFC6605], states that material was copied liberally from RFC
   6460.
becomes
   RFC 6605, "Elliptic Curve Digital Signature Algorithm (DSA) for
   DNSSEC" [RFC6605], states that material was copied liberally from RFC
   6460. The standards status of RFC 6605 is not affected by RFC 6460
   being moved to Historic status.

   RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the
   Path Computation Element Communication Protocol (PCEP)" [RFC8253],
   points RFC 6460 for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.  Both of these
   ciphersuites are defined in [RFC5289], which would have been a better
   reference.
becomes
   RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the
   Path Computation Element Communication Protocol (PCEP)" [RFC8253],
   points RFC 6460 for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.  Both of these
   ciphersuites are defined in [RFC5289], which would have been a better
   reference. Regardless, the standards status of RFC 8253 is not
   affected by RFC 6460 being moved to Historic status.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email