Re: [Netconf] Mandatory local configuration in Keystore groupings

Balázs Kovács <balazs.kovacs@ericsson.com> Wed, 29 August 2018 08:26 UTC

Return-Path: <balazs.kovacs@ericsson.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 F1A8512F1A2 for <netconf@ietfa.amsl.com>; Wed, 29 Aug 2018 01:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.332
X-Spam-Level:
X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GYMw2edq; dkim=pass (1024-bit key) header.d=ericsson.com header.b=T4mVpCMa
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 TFwXicYCOeTb for <netconf@ietfa.amsl.com>; Wed, 29 Aug 2018 01:26:02 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05567130E30 for <netconf@ietf.org>; Wed, 29 Aug 2018 01:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1535531160; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dYde1VIOreUz6IPCYyfWpnbz7nBtitwl/xJysyBIwII=; b=GYMw2edqgI8TQ07kWeewVVOKhuhYVhdGBUNe20zGbWUYRgwT0Ex1UcqbSbUFFsDr 7OHOaay4RTdyvnafwJV4keMGdG5OQUZc3ltY6I3rPtYy52lnv4zn7ZhO1sqZBE/L e14itlwZSUsOYxrEh4kdH0Hbcw7s3Ckev7UP7rD+g4U=;
X-AuditID: c1b4fb3a-6ba019c000007a64-c4-5b8658988435
Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.CC.31332.898568B5; Wed, 29 Aug 2018 10:26:00 +0200 (CEST)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 29 Aug 2018 10:25:50 +0200
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 29 Aug 2018 10:25:49 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dYde1VIOreUz6IPCYyfWpnbz7nBtitwl/xJysyBIwII=; b=T4mVpCMaDZNbRs9Vmyz5Ia5ddwbfJk7f/vHQcqv7a/YOjpoc4d9sg51JCLAXetqh+wjRNJ4LsxvvPf2KZnv7sFXCvG//CbqV5IuSgZVCQjKckLL5GiKNFx3IeJALf97TNYMhrIDC7o9BKbvyIJxNns+yhGfmhMHVRA9CBILl4S8=
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2285.eurprd07.prod.outlook.com (10.169.137.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.6; Wed, 29 Aug 2018 08:25:49 +0000
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%3]) with mapi id 15.20.1101.007; Wed, 29 Aug 2018 08:25:48 +0000
From: Balázs Kovács <balazs.kovacs@ericsson.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kwatsen@juniper.net" <kwatsen@juniper.net>, Balázs Lengyel <balazs.lengyel@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAXIgAgADaKnA=
Date: Wed, 29 Aug 2018 08:25:48 +0000
Message-ID: <VI1PR0701MB2016DE32515F393D37D2277E83090@VI1PR0701MB2016.eurprd07.prod.outlook.com>
References: <AD108D78-8E5D-429B-AFA9-8C84430F5186@juniper.net> <20180828.090648.398453385489817261.mbj@tail-f.com> <VI1PR0701MB2016F2754609FAEC242C9D51830A0@VI1PR0701MB2016.eurprd07.prod.outlook.com> <20180828.212338.1325240417175615395.mbj@tail-f.com>
In-Reply-To: <20180828.212338.1325240417175615395.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2285; 6:mGvneH99wta7tSUkK/UxYwF1jkOTLpcy2oVVgOeJJFyM+8En2j3ZWGeo7a/WdB8f4GK2qmwUFJJzGX9wdmRBIFvmiyr/foRhOo7Axq3hwo2u4SnqL5g5V30oa5ypulM6TXg/6YaRmZd9ojHvgbqQknlc3XBG4GETIDrQQ3xnMXlai1wHlvUFGjwvNCpOJTJYQcU37pMnHRBksIB2fbZ0W757a8/FDLVWyOJAuRZGHUIQA9edexE3WYCXwQgakbdYGtQpPueJMhQ1iE3n1xtVueNXRwjB/mCEF7wCwlGFG3YQ+uW2x+5PGva/h5MAySs8UhZcGIhWxdMy1NLXnnVr1s74rV7LLKiuSImTqGAyOJwywTko0B3l3tF3mJ1XgwNkd4RErpxWiUS0xDM/Yd/q9PiqH/7Bf7jntTYKiA/P4M1YOUkYLaIRrFs0lGooec/JnBluXLRyq3qO6d+n5cGO/g==; 5:7cpy0SX+n4wu+AsrXJKQL2lyMU/yB4LsYirCqFfO7EI9dW1kNHDK0QBQlh2LL6Z8PDudnnyKgRiDj9w4gS0VZCq+BCDEhGk8PSGYOGb3pNktLD2Y/4r+/9gkdqYt0AvMpqd1gNlD5YBEVGU0XLeXaLIWAqfkskiXsxOBCbx3cb4=; 7:asidgxwgRQ9hl7vKvEaoP+3fCPsaB0pqDS+HrkW0cJ4fgkTQIWzg1M+v+9yuP9O53fgral700w2/yo4lAmjee3UHERRr9xRUwXt8G50SySSY6vCT0oHapAxHZUAVhi8IEUSj9Uu+7eJ+sAxcWPxoHzcx0w2DXIliHwr+yLc4FtyUUUm9pKYLb4IlzeQpIG5GrzScbhaQlyPC3UPsmPDRCPZP7MTHIguDEMHORmgcz1PKGryooByxfaKCznRYnqiI
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(396003)(136003)(376002)(199004)(13464003)(51444003)(189003)(11346002)(9686003)(446003)(5660300001)(99286004)(4326008)(105586002)(2900100001)(476003)(53936002)(229853002)(14454004)(486006)(6246003)(81156014)(6916009)(25786009)(81166006)(86362001)(305945005)(8936002)(6306002)(3846002)(106356001)(6436002)(85202003)(26005)(186003)(55016002)(102836004)(6506007)(97736004)(76176011)(53546011)(6116002)(68736007)(7696005)(478600001)(2906002)(93886005)(14444005)(256004)(74316002)(966005)(8676002)(33656002)(66066001)(85182001)(54906003)(5250100002)(7736002)(316002)(35224004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2285; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-office365-filtering-correlation-id: 2505714d-2bc2-45a4-5259-08d60d89063c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2285;
x-ms-traffictypediagnostic: VI1PR0701MB2285:
x-microsoft-antispam-prvs: <VI1PR0701MB22859B0283482059F89975DF83090@VI1PR0701MB2285.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(788757137089)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699016); SRVR:VI1PR0701MB2285; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2285;
x-forefront-prvs: 077929D941
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 2Ojo0GQs6xHYkWq1mc6sw7T2Pn94AFhkEjwz/1ab5J+/8ABdOE3wypruNQhSMOJ4r8YwDKNbBKfmMUzrTdUu7LV0MVVTCYinI+co/OUK9iWDOh39LiaSiyDlcKogiRhepgsvbXCAf/+5xvYR+kvwDRTunu7VFViyEoI1+Q41tHS4jUwwFRo3veAsQgBkyTZicQzhCuBHrL0ixOLdB3bDvEEfD6npOzwxitlroi4xpifwfwf288cK1wyKpo6a1XAPBVh0bBIF533QV/rsewEI2bX+tc+SodjIU8cgLFiA+eHjckt9PoXEflHi4kxmk/lENJvoZHJ9VCRHtJhHAXCH5bx/RcC7uJvteUGaz5Zp+fw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2505714d-2bc2-45a4-5259-08d60d89063c
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2018 08:25:48.5176 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2285
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42KZGbG9SHdGRFu0weMdfBYH5rBbdHc/Y7eY uuk2qwOzx5IlP5k8rjddZffY+GsxSwBzFJdNSmpOZllqkb5dAldGz6Z2poI1MRVbVjczNTD+ iexi5OSQEDCR+Lj3E2MXIxeHkMBRRonbHTdYIJxvjBIP+z9COUuYJCZcuMMK4rAITGCWOHVq DitEZgaTxIz2nVDOE0aJA4enMoJMZhNwljj/4jETiC0ioCrxZOdasFnMArMYJbraVoEVCQt4 Sezae5sRoshboqd7PwuEXSbx9t4K5i5GDqB9qhLXPrCBhHkFEiSeLVjPBLGsiUnie+dJdpAa TgFHicWL1EFqGAXEJL6fWgO2l1lAXOLWk/lMEJ8KSCzZc54ZwhaVePn4HytEfazEjtd32CHi ShIzXt1ihbBlJS7N7waHjITAAXaJFxdaoJoNJY6v3M8MkVjKJtG3dTnYoRICvhJdEyoh4icZ JS6/nAa1WUfi0YWpUHa+xNuPU6A2ZEmcWL2LeQKj4Swkx84CGsUsoCmxfpc+RFhRYkr3Q/ZZ YP8LSpyc+YRlASPLKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAZHJwy2+rHYwHnzseYhTg YFTi4X3q0xYtxJpYVlyZe4hRgoNZSYQ3yAAoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNcpzSJK SCA9sSQ1OzW1ILUIJsvEwSnVwBivsCVHOaxdo53vNIPJUu+2+jW1+1bt8tdkjcqu4u35qjNT dKXSl6cmxsv2f05d0+m0SEp39bIqy6hPKxZwMNdaOKwMVH5cauracPr45xWrP2y7q2Tq/N+h QDIlNuKEvJ7B54R5ydWRduJJ2gb/eSJWud49zLXtbPWR/GlNuR29O5z2v+u9q8RSnJFoqMVc VJwIAPL9yUEiAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/LMyS63t0-58VxS86-AyERgqRvZ4>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing 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, 29 Aug 2018 08:26:05 -0000

Hi Martin,

I provided answers to Kent, which is mainly around modeling concerns I anticipate based on your previous discussion. Let's continue there.
Br,
Balazs

-----Original Message-----
From: Martin Bjorklund <mbj@tail-f.com> 
Sent: Tuesday, August 28, 2018 9:24 PM
To: Balázs Kovács <balazs.kovacs@ericsson.com>
Cc: kwatsen@juniper.net; Balázs Lengyel <balazs.lengyel@ericsson.com>; netconf@ietf.org
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Hi,

Balázs Kovács <balazs.kovacs@ericsson.com> wrote:

[...]

> Balazs> In our opinion with Balazs L., we think it would be
> disadvantageous to change the model by ruining the containment 
> relationship between certificate and corresponding asymmetric key. The 
> action of 'generate-asymmetric-key' is typically something that should 
> have effect on the 'running' configuration too (by setting the 
> mandatory leaves) since the user wants to continue working with the 
> result by deploying certificates or anything else related to the 
> created asymmetric key that needs configuration.
> 
> Balazs L.> In the NMDA RFC it is specifically indicated that 
> actions/rpcs MAY modify the content of other datastores.
> https://tools.ietf.org/html/rfc8342#section-6.2
> In my view this is a general pattern that an action/rpc creates some 
> configuration that the operator (CLI/Netconf/Restconf) may need to 
> extend or change. In this case the action/rpc shall modify the running 
> config not just operational.

I think that special actions/rpc that modify config should be avoided in probably all cases.  The text in 8342 handles generic rpcs like "edit-data" etc.

*if* you design an action to modify config, it needs to take at least the datastore as an input parameter.

In this particular case, I see no reason to have a special action to modify the configuration of keys.


/martin




> 
> Br,
> Balazs K. and Balazs L.
> 
> -----Original Message-----
> From: Netconf <netconf-bounces@ietf.org> On Behalf Of Martin Bjorklund
> Sent: Tuesday, August 28, 2018 9:07 AM
> To: kwatsen@juniper.net
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] Mandatory local configuration in Keystore 
> groupings
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > 
> >  
> > > > BTW, all private keys should have nacm:default-deny-all.
> > 
> > Updated in my local copy.  Added to the "asymmetric-key-pair-grouping"
> > grouping, so all downstream users inherit it as well.
> > 
> > 
> > 
> > > I think that the operation "generate-asymmetric-key" only affects 
> > > "permanently-hidden" keys, doesn't it?  If the client wants 
> > > visible keys, it will configure them in the config datastores.
> > 
> > It wasn't so locked down before.  How about the following two changes?
> > 
> > 1. Updated the action's description statement:
> > 
> >       action generate-asymmetric-key {
> >         description
> >           "Requests the device to generate an asymmetric key using
> >            the specified asymmetric key algorithm.  This action is
> >            used to request the system the generate a key that is
> >            'permanently-hidden', perhaps because it is protected
> >            by a cryptographic hardware module.  The resulting
> >            asymmetric key is considered operational state and
> >            hence present only in <operational>.";
> > 
> > 2. updated the enum's description statement:
> > 
> >           enum "permanently-hidden" {
> >             description
> >              "The private key is inaccessible due to being
> >               protected by the system (e.g., a cryptographic
> >               hardware module).  It is not possible to 
> >               configure a permanently hidden key, as a real
> >               private key value must be set.  Permanently
> >               hidden keys cannot be archived or backed up.";
> >           }   
> 
> Ok.
> 
> > > > Regarding the name, s/hardware-protected/permanently-hidden/?
> > >
> > > I think this is better.
> > 
> > Okay, but maybe it should be just "hidden"?
> 
> Both work for me.
> 
> > >> Now you have me second-guessing this.  Maybe a device, without 
> > >> special hardware, could present the illusion of a 
> > >> permanently-hidden private key - it's completely inaccessible 
> > >> from the device's supported interfaces, though actually present 
> > >> on the filesystem.
> > >
> > > This is what I would like to support.
> > 
> > Okay.
> > 
> > 
> > 
> > >> >> Unsure what you mean.  Currently all these values are configurable.
> > >> >> Or are you trying to find a way to only "configure" them in 
> > >> >> <operational>?
> > >> >
> > >> > Yes, *if* my use case of not exposing the private keys is 
> > >> > supported, then it would be useful to be able to generate the 
> > >> > keys off-box, and install them into <operational>.
> > >> 
> > >> Hmmm, sounds like *configuration*, not something goes into 
> > >> <operational>.
> > >> 
> > >> And, even if you did, that doesn't mean the keys are 
> > >> permanently-hidden.
> > >> I suppose the model could let the client set that parameter as 
> > >> well, but it somewhat defeats to goal of *never* having the 
> > >> private key exposed, not even as a once in a lifetime kind of thing.
> > >> That’s just my opinion, we should ask for more opinions if you're 
> > >> not convinced.
> > >
> > > I'm not convinced either way, actually ;-)  It would be good to 
> > > hear other opinions as well.
> > 
> > We could define a "load-asymmetric-key" action that has that behavior?
> 
> Yes; if we decide to support this use case.  What do others think?
> 
> > > This is what I would expect as well, but the model is not quite 
> > > designed for this currently.  For example, suppose I generate a 
> > > HSM-protected key with "generate-asymmetric-key".  It is then 
> > > present in <operational>, with a public key etc.  Now I want to 
> > > configure a certification for this key, so I have to create an 
> > > entry in the "asymmetric-key" list, where I have to set both the 
> > > private-key and public-key leafs (they are both mandatory); so I 
> > > assume I have to use the exact values reported in <operational>?
> > 
> > Hmmm, using the same value could work, but it doesn't seem intuitive 
> > and, from a general modelling perspective, doesn't scale e.g., what 
> > if there were 100 descendants?
> 
> Exactly my point.
> 
> > A couple other options:
> > 
> >  a) make each leaf (algorithm, public-key, private-key) type be a
> >     union having an enumerated value like "in-operational"
> 
> This feels clumsy and also doesn't really scale.
> 
> >  b) replace the three "mandatory true" with three "must" expressions
> >     that assert either all or none of the leafs are set.
> 
> Better, but also has scaling issues in the general case.
> 
> 
> > > Another design could be to have the certificates in a separate 
> > > list, with leafrefs (require-instance false) into the "asymmetric-key"
> > > list.
> > 
> > Perhaps, but let's see if we can make this work first.
> 
> Ok, let's look at the alternatives:
> 
> (A)
> 
>   container keystore {
>     container asymmetric-keys {
>       list asymmetric-key {
>         key name;
> 
>         leaf name { ... }
>         leaf algorithm { ... }
>         leaf public-key { ... }
>         leaf private-key { ... }
> 
>         must "(algorithm and public-key and private-key)
>               or not (algorithm or public-key or private-key)";
> 
>         container certificates {
>           list certificate { ... }
>         }
>     }
>   }
> 
> 
> (B)
> 
>   container keystore {
>     container asymmetric-keys {
>       list asymmetric-key {
>         key name;
> 
>         leaf name { ... }
>         leaf algorithm { mandatory true; ... }
>         leaf public-key { mandatory true; ... }
>         leaf private-key { mandatory true; ... }
> 
>     }
> 
>     container certificates {
>       list certificate {
>         ...
>         leaf key {
>           leafref {
>             path "../../../asymmetric-keys/asymmetric-key/name";
>           }
>           require-instance false;
>           mandatory true;
>         }
>         ...
>       }
>     }
>   }
> 
> 
> I think model B is cleaner.
> 
> 
> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf