[Netconf] Access Control Issues/Question
Bert Wijnen <bwijnen@ripe.net> Fri, 01 April 2011 09:07 UTC
Return-Path: <bwijnen@ripe.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17313A67A5 for <netconf@core3.amsl.com>; Fri, 1 Apr 2011 02:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQn6o6DeD7Rs for <netconf@core3.amsl.com>; Fri, 1 Apr 2011 02:07:29 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id C268C3A679F for <netconf@ietf.org>; Fri, 1 Apr 2011 02:07:28 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bwijnen@ripe.net>) id 1Q5aLr-0000UC-4v for netconf@ietf.org; Fri, 01 Apr 2011 11:09:08 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-50d8.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from <bwijnen@ripe.net>) id 1Q5a2w-0002pV-8I for netconf@ietf.org; Fri, 01 Apr 2011 10:49:34 +0200
Message-ID: <4D95919E.4010108@ripe.net>
Date: Fri, 01 Apr 2011 10:49:34 +0200
From: Bert Wijnen <bwijnen@ripe.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e65015a5ee52240f60487771a32ebcb5a
Subject: [Netconf] Access Control Issues/Question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 01 Apr 2011 09:07:30 -0000
WG participants,
Pls comment on this open issues that Martin presented
in his suggested new/improved approach for NACM rule
definitions at our meeting yesterday. The slides
are here:
http://tools.ietf.org/agenda/80/slides/netconf-1.pdf
- Is two levels of nesting enough?
- A common (?) use case is to define one rulelist for
a task, and let some groups access it read-write,
and some read-only. This is not directly supported
– you would need to define two different rule-lists,
e.g. routing- admin and routing-read.
By moving the allowedgroups check from the rule to the
rulelist, we loose some flexibility. If we really need
special handling of a rule for some group, this rule
needs to be defined in a separate rule-list.
- Would it be useful with any objects to help debug a
NACM configuration?
- rpc get-rules group-name ---> list of rules
- rpc check-path group-name path ---> rule execution trace
Bert and Mehmet
- [Netconf] Access Control Issues/Question Bert Wijnen