Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <> Thu, 04 April 2019 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 535E11201DE for <>; Thu, 4 Apr 2019 09:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OsJc-ep_Mnrh for <>; Thu, 4 Apr 2019 09:23:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9DB7120142 for <>; Thu, 4 Apr 2019 09:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; 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 <>
Message-ID: <>
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, 04 Apr 2019 16:23:23 +0000
In-Reply-To: <>
Cc: Juergen Schoenwaelder <>, "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.04-
Archived-At: <>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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