Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
Kent Watsen <kent+ietf@watsen.net> Fri, 26 April 2019 14:25 UTC
Return-Path: <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7598512014B for <netconf@ietfa.amsl.com>; Fri, 26 Apr 2019 07:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 xN6s-ya7bnnA for <netconf@ietfa.amsl.com>; Fri, 26 Apr 2019 07:25:47 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9496312004B for <netconf@ietf.org>; Fri, 26 Apr 2019 07:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556288746; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=PanmhyJlhsJK1PEccuBjc2a0oemcPPge0ucMHULtVjE=; b=VxWytMH0Vkw/tVeIKZ0gf/WfG0wbzTvzc9Y4y9ZSR9qxkBn2a6Yp24bur8S6350g HaJTWvzwOLTXTLi++yjq8DjEfhGMXq4cKZ+F00pAgxsE4OiRIVjiFOmxOYQWXhpyrmE 5O70UCvEZq+dlWTfWWHNd+nHncBvKKexK0D6Ars0=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5966A6B-C1D3-4AB3-8051-6B92283D7129"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 26 Apr 2019 14:25:46 +0000
In-Reply-To: <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de>
Cc: Martin Bjorklund <mbj@tail-f.com>, wang.haiguang.shieldlab@huawei.com, "netconf@ietf.org" <netconf@ietf.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> <20190425.205039.1112892422143145313.mbj@tail-f.com> <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.26-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rwSioXdCLPEX72CA6tixZBx44AE>
Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 14:25:49 -0000
> On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > On Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen wrote: >> >> In the meanwhile, what's the stop-gap solution? - crypto-types >> shouldn't be blocked on YANG Next... >> > > What we have been doing so far is publishing identities / enumerations > without having a common way for implementations to declare the subset > they do support. This seems reasonable since once we add a common > mechanism to report the subset actually implemented, we do not have to > go back and revise the definitions of identities and enumerations. Sounds right, with the clarification that crypto-types should have identities for all (within reason) known algorithms, even if deprecated or obsolete, and that for those algorithms that are deprecated or obsolete, the identity's "status" statement should be set to "deprecated" or "obsolete" accordingly. Haiguang, can you please point the i2nsf group to this thread? Thanks, Kent
- Re: [netconf] The maintenance of the algorithm id… tom petch
- [netconf] The maintenance of the algorithm identi… Wang Haiguang
- Re: [netconf] The maintenance of the algorithm id… Juergen Schoenwaelder
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Martin Bjorklund
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Martin Bjorklund
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Juergen Schoenwaelder
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Wang Haiguang