[netconf] ietf-netconf-acm extensions

Michal Vaško <mvasko@cesnet.cz> Thu, 18 July 2019 06:52 UTC

Return-Path: <mvasko@cesnet.cz>
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 31EA8120606 for <netconf@ietfa.amsl.com>; Wed, 17 Jul 2019 23:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 Kj8q1VfxtNv4 for <netconf@ietfa.amsl.com>; Wed, 17 Jul 2019 23:51:58 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1C51200EC for <netconf@ietf.org>; Wed, 17 Jul 2019 23:51:58 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 0F7D76021F; Thu, 18 Jul 2019 08:51:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1563432716; bh=7InUIHANfh/0KEMEpVoAV1W7rdzKHVxTs7VqpXkj2YQ=; h=To:Date:Subject:From; b=HUH64V3+QtMIJaBjDakuEfrS3PHDIl5gkvZwLKeNll6DTgtPFDL7T6YQtdkGrciNj LOVWoE1jzcnH8KhQceX6cIJWvneonKvijltE5ce8Gs3rOPNASNiN7ygUkim1chAgf9 IG5bHr7ydkav1ZIHCkbVtp08MWQM18DqFkC3HvQg=
Content-Type: text/plain; charset="utf-8"
To: "netconf" <netconf@ietf.org>
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Thu, 18 Jul 2019 08:51:56 +0200
Message-ID: <5e52-5d301700-29-5aa79a00@178123885>
X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FXF1zsxPlOroustwYbTND5dCkFs>
Subject: [netconf] ietf-netconf-acm extensions
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, 18 Jul 2019 06:52:01 -0000

Hi,

I would like to ask for some clarification of NACM extensions meaning when performing an <edit-config> because my current understanding is most likely wrong. I will illustrate on an example using ietf-netconf-acm@2018-02-14 data.

running configuration:

<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
  <enable-nacm>true</enable-nacm>
  <write-default>true</write-default>
</nacm>

An arbitrary user (not root, so not the recovery session) sends this <edit-config> config:

<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
  <enable-nacm>false</enable-nacm>
</nacm>

Now, NACM rules are being applied:
1) On the "nacm" container no access is required (default "merge" operation on an already existing node [1] 5th paragraph)
2) On the "enable-nacm" write access should be required (decided at 12. in [2])

So the access is granted and NACM is now disabled. I understand this is mostly due to "write-default" being "permit" but what about the "default-deny-all" extension instance on the top-level "nacm" container? I think it was meant to deny any access to the NACM data for every user without explicit NACM rule. Effectively, it does absolutely nothing because the top-level container can always exist (I guess it depends on the implementation) so for every <edit-config> no access will be required for this node. Am I missing something?

Regards,
Michal

[1] https://tools.ietf.org/html/rfc8341#page-17
[2] https://tools.ietf.org/html/rfc8341#section-3.4.5