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
- [Netconf] Mandatory local configuration in Keysto… Balazs Lengyel
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen