idnits 2.17.1 draft-zhang-netconf-nacm-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 31 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 28, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6536' is mentioned on line 97, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC6241' is mentioned on line 102, but not defined == Unused Reference: 'RFC1034' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 216, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force QF. Zhang 2 Internet Draft Ericsson 3 Intended status: Standards Track October 28, 2017 4 Expires: April 2018 6 NACM Extension for Stream 7 draft-zhang-netconf-nacm-extension-00.txt 9 Abstract 11 This document defines an extension to the Netconf Access Control 12 Model (NACM) to support notification authorization per event stream. 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 30, 2009. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction ................................................ 2 55 1.1. Terminology ............................................ 3 56 2. Yang Model Extension......................................... 3 57 2.1. The extended Yang Model data node ....................... 3 58 2.2. Outgoing Authorization ................... 4 59 2.3. Tree Diagrams .......................................... 4 60 3. Security Considerations ...................................... 5 61 4. IANA Considerations ......................................... 5 62 5. Normative References......................................... 5 64 1. Introduction 66 RFC5277 (NETCONF Event Notifications) defines the event stream. An 67 event stream is defined as a set of event notifications matching some 68 forwarding criteria. At some point after the NETCONF server receives 69 the internal event from a stream, it is converted to an appropriate 70 XML encoding by the server, and a element is ready to 71 send to all NETCONF sessions subscribed to that stream. In some case, 72 same event type of notification may be part of multiple event 73 streams. 75 RFC6536 (Network Configuration Protocol (NETCONF) Access Control 76 Model) defines the NACM rule for notification, however it only allows 77 user to define notification-name. No stream name can be defined in 78 the NACM rule. 80 As NACM rule can not limit user to only subscriber certain stream, So 81 there is no obvious solution if one user is only allowed to see some 82 events from certain stream, like system-monitor stream and security- 83 monitor stream. So this document is to extend NACM protocol to 84 support such use case. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119]. 93 The following terms are defined used within this document: 95 o 97 The following terms are defined in [RFC6536] and are not redefined 98 here: 100 o NACM 102 The following terms are defined in [RFC6241] and are not redefined 103 here: 105 o Netconf 107 o client 109 o configuration data 111 o server 113 o state data 115 The following terms are defined in [RFC6020] and are not redefined 116 here: 118 o augment 120 o data model 122 o data node 124 o presence container 126 2. Yang Model Extension 128 2.1. The extended Yang Model data node 130 A new leaf, termed as "stream-name", is specificied which stream will 131 be checked during NACM notification rule authorization. 133 The type of "stream-name" is an Union, it can be "matchall-string- 134 type", or string. Type "matchall-string-type" is defined in RFC6536 136 leaf stream-name { 137 type union { 138 type matchall-string-type; 139 type string; 140 } 141 description 142 "This leaf matches if it has the value '*' or if its 143 value equals the requested stream name."; 144 } 146 2.2. Outgoing Authorization 148 For each rule-list entry found, process all rules, in order, until a 149 rule that matches the requested access operation is found. A rule 150 matches if all the following criteria are met: 152 * The rule's "module-name" leaf is "*" or equals the name of the YANG 153 module where the notification is defined. 155 * The rule's "access-operations" leaf has the "read" bit set or has 156 the special value "*". 158 * The rule does not have a "rule-type" defined or the "ruletype" is 159 "notification" and all the following criteria are met: 161 * the "notification-name" is "*" or equals the name of the 162 notification. 163 * the "stream-name" is "*" or equals the name of the stream. 165 2.3. Tree Diagrams 167 A simplified graphical representation of the data model is used in 168 this document. The meaning of the symbols in these diagrams is as 169 follows: 171 o Brackets "[" and "]" enclose list keys. 173 o Abbreviations before data node names: "rw" means configuration 174 (read-write), and "ro" means state data (read-only). 176 o Symbols after data node names: "?" means an optional node, "!" 177 means a presence container, and "*" denotes a list and leaf-list. 179 o Parentheses enclose choice and case nodes, and case nodes are also 180 marked with a colon (":"). 182 o Ellipsis ("...") stands for contents of subtrees that are not 183 shown. 185 module: ietf-netconf-acm 186 augment /nacm:nacm/nacm:rule-list/nacm:rule/nacm:rule- 187 type/nacm:nofication 188 +--rw stream-name? union 190 3. Security Considerations 192 The data model defined does not create any security implications. 194 4. IANA Considerations 196 This draft does not request any IANA action. 198 5. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 204 DOI 10.17487/RFC1034, RFC 1034, November 1987, 205 . 207 [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND 208 SPECIFICATION", DOI 10.17487/RFC1035, RFC 1035, November 209 1987, . 211 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 212 the Network Configuration Protocol (NETCONF)", RFC 6020, 213 DOI 10.17487/RFC6020, October 2010, . 216 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, 217 DOI 10.17487/RFC6021, October 2010, . 220 Authors' Addresses 222 Qifeng Zhang 223 Ericsson (China) Communications Company Ltd. 224 Ericsson Tower, No. 5 Lize East Street, 225 Chaoyang District Beijing 100102, P.R. China 227 Email: qifeng.zhang@ericsson.com