Re: [netconf] updates to client/server drafts

Kent Watsen <> Tue, 11 June 2019 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E70521200B3 for <>; Tue, 11 Jun 2019 13:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 mdaINUeHiOIx for <>; Tue, 11 Jun 2019 13:53:59 -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 DF6D5120090 for <>; Tue, 11 Jun 2019 13:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1560286437; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=qwQKmDLBM5DuZQmyD83/Qx3YK4jBQ2eem7DuwtK4AgE=; b=AWV5pfHyf/t3qLDxZgqH6XJtPW44G/Ar1xhPWK6nsslho3k3W/db/LT6H0LaJetm pKP89aDFU8FG8cAGR7K7Zu2hPrW0fjxSRKRSTF2HG5fGMIY7Ukqm1oySClqG9euoNwK nDI+aF0kIRwxI8Tmx2JHcEGuMhNhfd/xmvqU4obc=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5FF3316A-8833-4121-AFAC-820EA48426C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 11 Jun 2019 20:53:57 +0000
In-Reply-To: <>
Cc: "" <>
To: Juergen Schoenwaelder <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.11-
Archived-At: <>
Subject: Re: [netconf] updates to client/server drafts
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: Tue, 11 Jun 2019 20:54:01 -0000

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?

> A more general note: I assume that humans configuring systems are
> mostly familiar with common file formats for X.509 certificates like
> .pem files or similar. It seems these formats can't be used with the
> YANG module and that tools are needed to extract the pieces of data
> and to ship them to the server. Perhaps usability would be higher if
> the module would support upload/download of X.509 related material in
> commonly used formats.

This comment seems to apply to the entire client/server suite of drafts.  I believe that your statement regards the somewhat heavy use of CMS structures for conveyed certificate chains, rather than the non-standard though nearly ubiquitous concatenation of PEM-encoded certificates.

I believe that bi-directional `openssl` based one-liners exist for converting between CMS and concatenated-PEMs.  Would it help if the crypto-types draft included an Appendix section to supply the `openssl` commands for just the 'trust-anchor-cert-cms' and 'end-entity-cert-cms' typedefs?  [FWIW, constructing said CMS structures in Python is trivial.]

Kent // contributor