Re: [netconf] ietf crypto types - permanently hidden

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 01 May 2019 18:05 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 E0A3E120130 for <netconf@ietfa.amsl.com>; Wed, 1 May 2019 11:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 L_R7bRrArjmJ for <netconf@ietfa.amsl.com>; Wed, 1 May 2019 11:05:58 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD59120152 for <netconf@ietf.org>; Wed, 1 May 2019 11:05:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3B80F7B7; Wed, 1 May 2019 20:05:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id tI2W7Y3kxwOu; Wed, 1 May 2019 20:05:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 May 2019 20:05:56 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED8F7200E0; Wed, 1 May 2019 20:05:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id PR125wnrEGIL; Wed, 1 May 2019 20:05:55 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6A1A7200DE; Wed, 1 May 2019 20:05:55 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 1 May 2019 20:05:54 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 19CFC3008B86B6; Wed, 1 May 2019 20:05:53 +0200 (CEST)
Date: Wed, 1 May 2019 20:05:53 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
CC: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190501180553.3oidb7x275tgcdz6@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <VI1PR07MB47353B20AF138B5B8B702285833A0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <acef56d17fc64102ae24bb8fcb8c828d@XCH-RCD-007.cisco.com> <CABCOCHS=mETbXUNm4pC45HPLtLu-r6QfX6xQAWCGxb7jfR19_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABCOCHS=mETbXUNm4pC45HPLtLu-r6QfX6xQAWCGxb7jfR19_w@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/cmW-741hd-3IiMu8O3BTgWUHmmc>
Subject: Re: [netconf] ietf crypto types - permanently hidden
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: Wed, 01 May 2019 18:06:00 -0000

On Wed, May 01, 2019 at 09:19:38AM -0700, Andy Bierman wrote:
> 
> This seems to be a good test for whether NMDA is useful as designed.
> It seems obvious that something has to be stored in <running> and
> then transformed as it is applied to <intended>.
>

The issue here seems to be that you create a resource that you would
like to be partially accessible as config and partially not accessible
at all or only as applied config in operational state. The question is
how to model that, i.e., the binding between config part and the
internal state part. Do we have any other similar resources or is this
really a very special case?

We discussed the 'create user account' case where often users ids are
allocated as a side effect of creating an account but the allocated
ids then becomes regular config, i.e., the config can be copied and
restored as one would expect. This is not really the same case that we
have with locally created keys.

An alternative might be to consider a locally generated key entirely
operational state (applied config): You invoke an RPC to create a key
and you give it a name and then it exists as named operational state
(applied config) until you delete that named operational state. If you
want to configure a transport that refers to such a key, you do this
via a name binding, pretty much in the way we apply interface
configuration to an interface with a matching name. Perhaps this is a
model that could work.

Perhaps Martin has even better ideas.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>