draft-ietf-netconf-access-control-00.txt   draft-ietf-netconf-access-control-01.txt 
Internet Engineering Task Force A. Bierman Internet Engineering Task Force A. Bierman
Internet-Draft Brocade Internet-Draft Brocade
Intended status: Standards Track M. Bjorklund Intended status: Standards Track M. Bjorklund
Expires: March 6, 2011 Tail-f Systems Expires: April 28, 2011 Tail-f Systems
September 2, 2010 October 25, 2010
Network Configuration Protocol Access Control Model Network Configuration Protocol Access Control Model
draft-ietf-netconf-access-control-00 draft-ietf-netconf-access-control-01
Abstract Abstract
The standardization of network configuration interfaces for use with The standardization of network configuration interfaces for use with
the NETCONF protocol requires a structured and secure operating the NETCONF protocol requires a structured and secure operating
environment, which promotes human usability and multi-vendor environment, which promotes human usability and multi-vendor
interoperability. There is a need for standard mechanisms to interoperability. There is a need for standard mechanisms to
restrict NETCONF protocol access for particular users to a pre- restrict NETCONF protocol access for particular users to a pre-
configured subset of all available NETCONF operations and content. configured subset of all available NETCONF operations and content.
This document discusses requirements for a suitable access control This document discusses requirements for a suitable access control
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 6, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 9 skipping to change at page 4, line 9
5.3.2. Session Establishment . . . . . . . . . . . . . . . . 24 5.3.2. Session Establishment . . . . . . . . . . . . . . . . 24
5.3.3. 'access-denied' Error Handling . . . . . . . . . . . . 24 5.3.3. 'access-denied' Error Handling . . . . . . . . . . . . 24
5.3.4. Incoming RPC Message Validation . . . . . . . . . . . 24 5.3.4. Incoming RPC Message Validation . . . . . . . . . . . 24
5.3.5. Data Node Access Validation . . . . . . . . . . . . . 27 5.3.5. Data Node Access Validation . . . . . . . . . . . . . 27
5.3.6. Outgoing <rpc-reply> Authorization . . . . . . . . . . 29 5.3.6. Outgoing <rpc-reply> Authorization . . . . . . . . . . 29
5.3.7. Outgoing <notification> Authorization . . . . . . . . 30 5.3.7. Outgoing <notification> Authorization . . . . . . . . 30
5.4. Data Model Definitions . . . . . . . . . . . . . . . . . . 33 5.4. Data Model Definitions . . . . . . . . . . . . . . . . . . 33
5.4.1. High Level Procedures . . . . . . . . . . . . . . . . 33 5.4.1. High Level Procedures . . . . . . . . . . . . . . . . 33
5.4.2. Data Organization . . . . . . . . . . . . . . . . . . 33 5.4.2. Data Organization . . . . . . . . . . . . . . . . . . 33
5.4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 34 5.4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 34
5.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 49 5.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 50
5.6. Security Considerations . . . . . . . . . . . . . . . . . 49 5.6. Security Considerations . . . . . . . . . . . . . . . . . 50
6. Normative References . . . . . . . . . . . . . . . . . . . . . 51 6. Normative References . . . . . . . . . . . . . . . . . . . . . 52
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 52 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 53
A.1. <groups> Example . . . . . . . . . . . . . . . . . . . . . 52 A.1. <groups> Example . . . . . . . . . . . . . . . . . . . . . 53
A.2. <module-rule> Example . . . . . . . . . . . . . . . . . . 53 A.2. <module-rule> Example . . . . . . . . . . . . . . . . . . 54
A.3. <rpc-rule> Example . . . . . . . . . . . . . . . . . . . . 54 A.3. <rpc-rule> Example . . . . . . . . . . . . . . . . . . . . 55
A.4. <data-rule> Example . . . . . . . . . . . . . . . . . . . 56 A.4. <data-rule> Example . . . . . . . . . . . . . . . . . . . 57
A.5. <notification-rule> Example . . . . . . . . . . . . . . . 58 A.5. <notification-rule> Example . . . . . . . . . . . . . . . 59
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 59 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 60
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61
C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 C.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 C.2. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
The NETCONF protocol does not provide any standard mechanisms to The NETCONF protocol does not provide any standard mechanisms to
restrict the operations and content that each user is authorized to restrict the operations and content that each user is authorized to
use. use.
There is a need for inter-operable management of the controlled There is a need for inter-operable management of the controlled
access to operator selected portions of the available NETCONF content access to operator selected portions of the available NETCONF content
within a particular server. within a particular server.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
in [RFC4741], and [RFC5277]. It contains five main sections: in [RFC4741], and [RFC5277]. It contains five main sections:
1. Authentication Requirements 1. Authentication Requirements
2. Access Control Requirements 2. Access Control Requirements
3. NETCONF Authentication and Authorization Model 3. NETCONF Authentication and Authorization Model
4. NETCONF Access Control Model (NACM) 4. NETCONF Access Control Model (NACM)
5. YANG Data Model (nacm.yang) 5. YANG Data Model (ietf-nacm.yang)
1.1. Terminology 1.1. Terminology
1.1.1. Requirements Notation 1.1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1.2. NETCONF Terms 1.1.2. NETCONF Terms
skipping to change at page 19, line 14 skipping to change at page 19, line 14
5.1.2. External Dependencies 5.1.2. External Dependencies
The NETCONF [RFC4741] protocol is used for all management purposes The NETCONF [RFC4741] protocol is used for all management purposes
within this document. The server must support the features within this document. The server must support the features
identified by the 'NETCONF-base' capability. It is expected that the identified by the 'NETCONF-base' capability. It is expected that the
mandatory transport mapping NETCONF Over SSH [RFC4742] is also mandatory transport mapping NETCONF Over SSH [RFC4742] is also
supported by the server, and that the server has access to the user supported by the server, and that the server has access to the user
name associated with each session. name associated with each session.
The YANG Data Modeling Language [I-D.ietf-netmod-yang] is used to The YANG Data Modeling Language [RFC6020] is used to define the
define the NETCONF data models specified in this document. The YANG NETCONF data models specified in this document. The YANG instance-
instance-identifier data type can be used to configure data-node- identifier data type can be used to configure data-node-specific
specific access control rules. access control rules.
5.1.3. Message Processing Model 5.1.3. Message Processing Model
The following diagram shows the NETCONF message flow model, including The following diagram shows the NETCONF message flow model, including
the points at which access control is applied, during NETCONF message the points at which access control is applied, during NETCONF message
processing. processing.
+-------------------------+ +-------------------------+
| session | | session |
| (username) | | (username) |
skipping to change at page 34, line 39 skipping to change at page 34, line 39
configuration database access. configuration database access.
list <notification-rule>: Configures the access control rules for list <notification-rule>: Configures the access control rules for
controlling delivery of <notification> events. controlling delivery of <notification> events.
5.4.3. YANG Module 5.4.3. YANG Module
The following YANG module is provided to specify the normative The following YANG module is provided to specify the normative
NETCONF content that must by supported by the server. NETCONF content that must by supported by the server.
<CODE BEGINS> file="nacm@2010-06-29.yang" The ietf-nacm YANG module imports typedefs from [RFC6021].
module nacm { // RFC Ed.: please update the date to the date of publication
<CODE BEGINS> file="ietf-nacm@2010-10-25.yang"
module ietf-nacm {
namespace "urn:ietf:params:xml:ns:yang:ietf-nacm";
namespace "file://draft-bierman-netconf-access-control-02.txt";
prefix "nacm"; prefix "nacm";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
"IETF"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"Andy Bierman <andy.bierman@brocade.com> "WG Web: <http://tools.ietf.org/wg/netconf/>
Martin Bjorklund <mbj@tail-f.com>"; WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
Editor: Andy Bierman
<mailto:andy.bierman@brocade.com>
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>";
description description
"NETCONF Server Access Control Model"; "NETCONF Server Access Control Model.
revision 2010-09-02 { Copyright (c) 2010 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
//reference "RFC XXXX";
// RFC Ed.: remove this note
// Note: extracted from draft-ietf-netconf-access-control-01.txt
// RFC Ed.: please update the date to the date of publication
revision "2010-10-25" {
description description
"Initial version (work-in-progress)."; "Initial version";
reference
"RFC XXXX: Network Configuration Protocol Access Control Model";
} }
/* /*
* Extension statements * Extension statements
*/ */
extension secure { extension secure {
description description
"Used to indicate that the data model node "Used to indicate that the data model node
represents a sensitive security system parameter. represents a sensitive security system parameter.
skipping to change at page 38, line 39 skipping to change at page 39, line 30
"NETCONF Access Rights. "NETCONF Access Rights.
The string '*' indicates that all possible access The string '*' indicates that all possible access
rights apply to the access rule. Otherwise, only rights apply to the access rule. Otherwise, only
the specific access rights represented by the bit names the specific access rights represented by the bit names
that are present apply to the access rule."; that are present apply to the access rule.";
} }
typedef nacm-group-name-type { typedef nacm-group-name-type {
type string { type string {
length "1..max"; length "1..max";
pattern "~\*[.*]"; pattern "[^\*].*";
} }
description description
"Name of administrative group that can be "Name of administrative group that can be
assigned to the user, and specified in assigned to the user, and specified in
an access control rule."; an access control rule.";
} }
typedef nacm-action-type { typedef nacm-action-type {
type enumeration { type enumeration {
enum permit { enum permit {
skipping to change at page 39, line 38 skipping to change at page 40, line 29
This XPath expression is evaluated in the following context: This XPath expression is evaluated in the following context:
o The set of namespace declarations are those in scope on o The set of namespace declarations are those in scope on
the leaf element where this type is used. the leaf element where this type is used.
o The set of variable bindings contains one variable, o The set of variable bindings contains one variable,
'USER', which contains the name of user of the current 'USER', which contains the name of user of the current
session. session.
o The function library is the core function library, but note o The function library is the core function library, but
that due to the syntax restrictions of an note that due to the syntax restrictions of an
instance-identifier, no functions are allowed. instance-identifier, no functions are allowed.
o The context node is the root node in the data tree."; o The context node is the root node in the data tree.";
} }
typedef md5-crypt { typedef md5-crypt {
type string { type string {
pattern "$0$.* | $1$[a-zA-Z0-9./]{2,8}$.*"; pattern "$0$.* | $1$[a-zA-Z0-9./]{2,8}$.*";
} }
description description
skipping to change at page 49, line 4 skipping to change at page 49, line 45
description description
"Name of the module defining this "Name of the module defining this
notification event type."; notification event type.";
} }
leaf notification-name { leaf notification-name {
type string; type string;
description description
"Name of the notification event."; "Name of the notification event.";
} }
uses common-rule-parms; uses common-rule-parms;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 5 Figure 5
5.5. IANA Considerations 5.5. IANA Considerations
There are two actions that are requested of IANA: There are two actions that are requested of IANA: This document
registers one URI in "The IETF XML Registry". Following the format
in [RFC3688], the following has been registered.
1. register data model schema namespace URI (TBD) URI: urn:ietf:params:xml:ns:yang:ietf-nacm
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
2. register data model name ('nacm') This document registers one module in the "YANG Module Names"
registry. Following the format in [RFC6020], the following has been
registered.
name: ietf-nacm
namespace: urn:ietf:params:xml:ns:yang:ietf-nacm
prefix: nacm
reference: RFC XXXX
// RFC Ed.: Replace XXX with actual RFC number
// and remove this note
5.6. Security Considerations 5.6. Security Considerations
This entire document discusses access control requirements and This entire document discusses access control requirements and
mechanisms for restricting NETCONF protocol behavior within a given mechanisms for restricting NETCONF protocol behavior within a given
session. session.
Configuration of the access control system is highly sensitive to Configuration of the access control system is highly sensitive to
system security. A server may choose not to allow any user system security. A server may choose not to allow any user
configuration to some portions of it, such as the global security configuration to some portions of it, such as the global security
skipping to change at page 51, line 14 skipping to change at page 52, line 14
6. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)", RFC 4742, Configuration Protocol over Secure SHell (SSH)", RFC 4742,
December 2006. December 2006.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In
User Service (RADIUS) Authorization for Network Access User Service (RADIUS) Authorization for Network Access
Server (NAS) Management", RFC 5607, July 2009. Server (NAS) Management", RFC 5607, July 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010.
[W3C.REC-xml] [W3C.REC-xml]
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
xml, October 2000, <http://www.w3.org/TR/REC-xml>. xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[I-D.ietf-netmod-yang]
Bjorklund, M., "YANG - A data modeling language for the
Network Configuration Protocol (NETCONF)",
draft-ietf-netmod-yang-13 (work in progress), June 2010.
[I-D.ietf-netmod-yang-types]
Schoenwaelder, J., "Common YANG Data Types",
draft-ietf-netmod-yang-types-09 (work in progress),
April 2010.
Appendix A. Usage Examples Appendix A. Usage Examples
The following XML snippets are provided as examples only, to The following XML snippets are provided as examples only, to
demonstrate how NACM can be configured to perform some access control demonstrate how NACM can be configured to perform some access control
tasks. tasks.
A.1. <groups> Example A.1. <groups> Example
There must be at least one <group> entry in order for any of the There must be at least one <group> entry in order for any of the
access control rules to be useful. access control rules to be useful.
The following XML shows arbitrary groups, and is not intended to The following XML shows arbitrary groups, and is not intended to
represent any particular use-case. represent any particular use-case.
<nacm xmlns="file://draft-bierman-netconf-access-control-02.txt"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-nacm">
<groups> <groups>
<group> <group>
<name>admin</name> <name>admin</name>
<user-name>admin</user-name> <user-name>admin</user-name>
<user-name>andy</user-name> <user-name>andy</user-name>
</group> </group>
<group> <group>
<name>monitor</name> <name>monitor</name>
<user-name>wilma</user-name> <user-name>wilma</user-name>
skipping to change at page 53, line 15 skipping to change at page 54, line 15
3. The nacm:guest group contains 2 users named 'guest' and 3. The nacm:guest group contains 2 users named 'guest' and
'guest@example.com'. 'guest@example.com'.
A.2. <module-rule> Example A.2. <module-rule> Example
Module rules are used to control access to all the content defined in Module rules are used to control access to all the content defined in
a specific module. These rules are checked after none of the a specific module. These rules are checked after none of the
specific rules (i.e., rpc-rule, data-rule, or notification-rule) specific rules (i.e., rpc-rule, data-rule, or notification-rule)
matched the current access request. matched the current access request.
<nacm xmlns="file://draft-bierman-netconf-access-control-02.txt"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-nacm">
<rules> <rules>
<module-rule> <module-rule>
<module-name>ietf-netconf-monitoring</module-name> <module-name>ietf-netconf-monitoring</module-name>
<rule-name>mod-1</rule-name> <rule-name>mod-1</rule-name>
<allowed-rights>*</allowed-rights> <allowed-rights>*</allowed-rights>
<allowed-group>guest</allowed-group> <allowed-group>guest</allowed-group>
<nacm-action>deny</nacm-action> <nacm-action>deny</nacm-action>
<comment> <comment>
Do not allow guests any access to the netconf Do not allow guests any access to the netconf
monitoring information. monitoring information.
skipping to change at page 55, line 5 skipping to change at page 56, line 5
operation supported by the server. operation supported by the server.
mod-4: This rule allows the admin group complete access to all mod-4: This rule allows the admin group complete access to all
content in the server. No subsequent rule will match for the content in the server. No subsequent rule will match for the
admin group, because of this module rule. admin group, because of this module rule.
A.3. <rpc-rule> Example A.3. <rpc-rule> Example
RPC rules are used to control access to a specific RPC operation. RPC rules are used to control access to a specific RPC operation.
<nacm xmlns="file://draft-bierman-netconf-access-control-02.txt"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-nacm">
<rules> <rules>
<rpc-rule> <rpc-rule>
<module-name>ietf-netconf</module-name> <module-name>ietf-netconf</module-name>
<rpc-name>kill-session</rpc-name> <rpc-name>kill-session</rpc-name>
<rule-name>rpc-1</rule-name> <rule-name>rpc-1</rule-name>
<allowed-group>monitor</allowed-group> <allowed-group>monitor</allowed-group>
<allowed-group>guest</allowed-group> <allowed-group>guest</allowed-group>
<nacm-action>deny</nacm-action> <nacm-action>deny</nacm-action>
<comment> <comment>
Do not allow the monitor or guest group Do not allow the monitor or guest group
skipping to change at page 56, line 20 skipping to change at page 57, line 20
rpc-3: This rule allows the monitor group to invoke the NETCONF rpc-3: This rule allows the monitor group to invoke the NETCONF
<edit-config> RPC operation. This rule will have no real affect <edit-config> RPC operation. This rule will have no real affect
unless the 'exec-default' leaf is set to 'deny'. unless the 'exec-default' leaf is set to 'deny'.
A.4. <data-rule> Example A.4. <data-rule> Example
Data rules are used to control access to specific (config and non- Data rules are used to control access to specific (config and non-
config) data nodes within the NETCONF content provided by the server. config) data nodes within the NETCONF content provided by the server.
<nacm xmlns="file://draft-bierman-netconf-access-control-02.txt"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-nacm">
<rules> <rules>
<data-rule> <data-rule>
<rule-name>data-1</rule-name> <rule-name>data-1</rule-name>
<path>/nacm</path> <path>/nacm</path>
<allowed-rights>*</allowed-rights> <allowed-rights>*</allowed-rights>
<allowed-group>guest</allowed-group> <allowed-group>guest</allowed-group>
<nacm-action>deny</nacm-action> <nacm-action>deny</nacm-action>
<comment> <comment>
Deny the guest group any access to the /nacm data. Deny the guest group any access to the /nacm data.
</comment> </comment>
skipping to change at page 58, line 15 skipping to change at page 59, line 15
admin-itf: This rule gives the admin group read-write access to all admin-itf: This rule gives the admin group read-write access to all
acme <interface>. entries. This is an example of an unreachable acme <interface>. entries. This is an example of an unreachable
rule because the 'mod-3' rule already gives the admin group full rule because the 'mod-3' rule already gives the admin group full
access to this data. access to this data.
A.5. <notification-rule> Example A.5. <notification-rule> Example
Notification rules are used to control access to a specific Notification rules are used to control access to a specific
notification event type. notification event type.
<nacm xmlns="file://draft-bierman-netconf-access-control-02.txt"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-nacm">
<rules> <rules>
<notification-rule> <notification-rule>
<module-name>acme-system</module-name> <module-name>acme-system</module-name>
<notification-name>sys-config-change</notification-name> <notification-name>sys-config-change</notification-name>
<rule-name>notif-1</rule-name> <rule-name>notif-1</rule-name>
<allowed-group>monitor</allowed-group> <allowed-group>monitor</allowed-group>
<allowed-group>guest</allowed-group> <allowed-group>guest</allowed-group>
<nacm-action>deny</nacm-action> <nacm-action>deny</nacm-action>
<comment> <comment>
Do not allow the guest or monitor groups Do not allow the guest or monitor groups
skipping to change at page 60, line 9 skipping to change at page 61, line 9
9. Should the default access levels (e.g., read-default) be more 9. Should the default access levels (e.g., read-default) be more
restrictive by default? Shiuld these defaults be a vendor restrictive by default? Shiuld these defaults be a vendor
decision? An operator decision? It is important that the server decision? An operator decision? It is important that the server
be able to install a factory default <nacm> container if needed. be able to install a factory default <nacm> container if needed.
Appendix C. Change Log Appendix C. Change Log
-- RFC Ed.: remove this section before publication. -- RFC Ed.: remove this section before publication.
C.1. 00 C.1. 00-01
Updated YANG anf YANG Types references.
Updated module namespace URI to standard format.
Updated module header meta-data to standard format.
Filled in IANA section.
C.2. 00
Initial version cloned from Initial version cloned from
draft-bierman-netconf-access-control-02.txt. draft-bierman-netconf-access-control-02.txt.
Authors' Addresses Authors' Addresses
Andy Bierman Andy Bierman
Brocade Brocade
Email: andy.bierman@brocade.com Email: andy.bierman@brocade.com
 End of changes. 32 change blocks. 
55 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/