Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <kent+ietf@watsen.net> Thu, 04 April 2019 16:23 UTC

Return-Path: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-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 535E11201DE for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 09:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] 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 OsJc-ep_Mnrh for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 09:23:24 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DB7120142 for <netconf@ietf.org>; Thu, 4 Apr 2019 09:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554395003; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=3yc5dGWtckO4MmKToMD1v1elt/XcQy0Kztcp3PCRz8s=; b=VMRH3/NJi6P2YBsgJR8Nu9GWx3GTpIQ2INKVrOVLlXJSpkIiAVUen5gQE/u1VDr2 Mo/zs5CAc0/avYV0HteHKwrpTswiT13QgiV3twDUGfHO/HKYE+5ts3Oe/t6JR4CZbE3 2yi8skKlt5mIbCUj4WbYHJEcqBFO9EeED4NOQDyc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_66F9B161-BC13-4EDA-ABF7-1A2A87CAA7BC"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 4 Apr 2019 16:23:23 +0000
In-Reply-To: <20190403.134424.1377386644961079970.mbj@tail-f.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <VI1PR07MB47351FF76BBF6C56AC6E64B5835E0@VI1PR07MB4735.eurprd07.prod.outlook.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.04-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FwQFj4P3rxEFVFgg7B8sCecGSLU>
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: Thu, 04 Apr 2019 16:23:27 -0000


>> and the creation of a private key that becomes (protected)
>> configuration is similar to the creation of a user account, where an
>> unused uid is allocated that becomes configuration.
> 
> AFAIK there is no standard model defined that actually do this.

Mostly true, though one might claim that <edit-config> is an example 
of an RPC that modifies configuration.


> The closest thing we have is the "type" of an interface:
> 
>           When an interface entry is created, a server MAY
>           initialize the type leaf with a valid value, e.g., if it
>           is possible to derive the type from the name of the
>           interface.
> 
> If private keys are handled like this, then I can accept it.  

This is not what is being asked for here.


> But we
> should NOT introduce special actions/rpcs that manipulate the
> configuration.


Why not?  Not that it's a valid justification, but vendors do it already.
What would it take to make it be not "special"?   Would adding a
standard (yang-next?) "modifies-configuration" leaf to the action/rpc
definition suffice?

FWIW, I do agree with Balazs, and argued as much a couple years
ago, that the current approach is not best practice.  That said, I'm
more interested in the general-purpose use of rpcs/actions this way.

We have always said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?


Kent // contributor