Re: [netconf] updates to client/server drafts

Martin Bjorklund <mbj@tail-f.com> Thu, 13 June 2019 11:00 UTC

Return-Path: <mbj@tail-f.com>
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 79FBE120276 for <netconf@ietfa.amsl.com>; Thu, 13 Jun 2019 04:00:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 DfcUU3ryZ7Vp for <netconf@ietfa.amsl.com>; Thu, 13 Jun 2019 04:00:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E487412013F for <netconf@ietf.org>; Thu, 13 Jun 2019 04:00:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D4161AE0331; Thu, 13 Jun 2019 13:00:20 +0200 (CEST)
Date: Thu, 13 Jun 2019 13:00:24 +0200 (CEST)
Message-Id: <20190613.130024.515576855897220606.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: kent+ietf@watsen.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20190613061155.mpuudt25lmze4bzk@anna.jacobs.jacobs-university.de>
References: <20190611174024.bbtb2vnoeef3ym4f@anna.jacobs.jacobs-university.de> <0100016b4851a036-a68c7d52-37a1-497c-b401-4551ee2b26d5-000000@email.amazonses.com> <20190613061155.mpuudt25lmze4bzk@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-GdDGIOSX3TF08PJX3XsayAUgP4>
Subject: Re: [netconf] updates to client/server drafts
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, 13 Jun 2019 11:00:26 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Tue, Jun 11, 2019 at 08:53:57PM +0000, Kent Watsen wrote:
> > Hi Juergen,
> > 
> > Thanks for broaching the topic, I'm hoping we can suss out such things before the drafts enter Last Call in 2-3 weeks.
> > 
> > 
> > >> 1) in crypto-types, replaced the 'action' statements with 'crypt-hash' like equivalents.  If folks don't like the "verbs", then we can simply remove them, having no solution for asking the device to generate a key or install a hidden key.
> > >> 
> > > 
> > > I am not sure this approach. This just hides the discussion in a
> > > special purpose construction:
> > > 
> > >               Without the optional '-and-hidden' postfix, the generated
> > >               key pair is stored in the configuration data store as if
> > >               the values had been configured by the client.
> > 
> > 
> > True, this special purpose construction sidesteps us needing to resolve the larger "can actions effect configuration" discussion.  But perhaps that is okay given that the need to have actions effecting configuration is exceedingly rare?   It's clear that you're not thrilled by this approach, but it's unclear if the reason you're not thrilled is because of the approach or because it's sidestepping the larger discussion.    Also, what do you propose we do about it?  Choices:
> > 
> > a) nix the "verbs", leaving the solution for asking the device to generate a key and install a hidden key to a future update.
> > b) resurrect the 'action' based discussion.
> > c) cautiously move forward with the "verbs" approach.
> > d) something else?
> 
> I am strictly against hiding actions by encoding 'verbs' in an ad-hoc
> data format. I rather not support creation of keys on the device.

Remember we had this cases:

1.  upload of keys
2a. generation of keys on the box that will go into hardware protected
    storage (and never be accessible)
2b. generation of keys on the box that will be stored on disk
    (and never be accessible over the mgmt interface)
3.  generation of keys on the box that become (protected) configuration


I think the previous version of the draft (with YANG actions) handles
1 and 2 (a and b with trivial updates).

It is only (3) that we don't have a solution for that everybody
accepts.

So perhaps we should solve 1 and 2a and 2b, and publish that, and
leave 3 for the future?


/martin