idnits 2.17.00 (12 Aug 2021) /tmp/idnits61788/draft-lengyel-action-rpc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2006) is 5698 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) -- Looks like a reference, but probably isn't: 'XML' on line 65 == Outdated reference: draft-ietf-netconf-prot has been published as RFC 4741 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netconf B. Lengyel 3 Internet-Draft Ericsson Hungary 4 Intended status: Standards Track October 13, 2006 5 Expires: April 16, 2007 7 Generic Action RPC for Netconf 8 draft-lengyel-action-rpc-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 16, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The NETCONF protocol defines a number of operations to read and write 42 configuration data. However, it does not define actions on the 43 managed nodes. Such actions are useful for 1) operations that do not 44 change the configuration data (e.g. ping) 2) reading or writing a set 45 of data that forms a logical group but might be scattered in 46 different parts of the management data model. 48 This document defines a new Netconf capability supporting a generic 49 operation. A modeling view of how the content of the 50 generic operation can be defined is also described. 52 Please send comments to netconf@ops.ietf.org. To subscribe, use 53 netconf-request@ops.ietf.org. 55 1. Introduction 57 The document introduces the Generic Action Capability. 59 1.1. Definition of Terms 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119. 65 Element: An XML Element[XML]. 67 Managed Node: A network node, which supports NETCONF[1] and has 68 access to management instrumentation. This is also known as the 69 NETCONF server. 71 Managed Object: A collection of one of more Elements that define 72 an abstract thing of interest. 74 Calling Point: A specific Managed Object in the hierarchical data 75 model that is passed to the action as context information. 77 2. Generic Action Capability 79 2.1. Overview 81 The NETCONF protocol defines a number of operations to read and write 82 configuration data. However, it does not define actions on the 83 managed nodes. Such actions are useful for 1) operations that do not 84 change the configuration data (e.g. ping) 2) reading or writing a set 85 of data that form a logical group but might be scattered in different 86 parts of the management data model. 88 There are two basic ways to define such actions: define each action 89 as an individual new operation or define a generic action operation 90 and define the details of the individual actions elsewhere. One 91 obvious possibility is to define actions in the management data 92 model. 94 Using generic action operations is a valid solution that we believe 95 will lead to simpler implementation and usage than defining actions 96 as separate individual operations. 98 Netconf RPCs will often be handled by a number of software entities 99 before they reach their final destination, e.g. intermediate 100 management software, software stacks from third party suppliers, 101 interface handling software, access control enforcers etc. These 102 entities and management software in general will be prepared for 103 different data models but will often not be prepared for changes in 104 the protocol itself: for new node specific action RPCs. New actions 105 might need updates to these software entities. 107 Using generic actions defined in the data model will make it possible 108 to write generic management software like a MIB browser that can 109 issue such actions and at least check their contents based on the 110 data model (name of the action, number and type of the parameters). 112 2.1.1. Modeling 114 There is a need to define what kind of generic actions can be used 115 against a specific managed node. This definition will not be part of 116 the protocol but should be part of the management data model of the 117 node. 119 This allows the node to specify during the initial capability 120 exchange the information model and actions it supports. Many of the 121 actions will be device/manufacturer specific just like the data model 122 itself. It will be easy to handle the action definitions as it is 123 generally accepted that the data model (or at least the non- 124 standardized parts of it) will be different for different products. 126 2.1.1.1. Action Definition 128 Each action will probably be defined in the data model. The exact 129 form of this definition is outside the scope of this document. The 130 following is recommended practice. 132 Name (Mandatory): Each action must have a name to identify it. 134 Calling-Point (Optional): A specific point in the hierarchical 135 data model that is passed to the action as context information. 136 Often actions will be called against a specific interface, virtual 137 router, etc. In other cases there will not be such context, in 138 which case the calling point might be omitted. 140 Description (Mandatory): A description of the action. 142 Parameters (Optional): All parameters included in an action should 143 be defined. For each parameter the following data should be 144 provided: 145 Data type of the parameter 146 Optional/Mandatory 147 Default value 148 Direction the parameter is sent: IN/OUT/INOUT. OUT and INOUT 149 parameters will be returned in the response message. 151 Error Results (mandatory if applicable): Possible error results 152 including their format and what causes the error. This item might 153 not be applicable if the action never produces error result. 155 2.2. Dependencies 157 None. 159 2.3. Capability Identifier 161 The generic-action capability is identified by the following 162 capability string: 164 urn:ietf:params:netconf:capability:generic-action:1.0 166 2.4. New Operations 168 2.4.1. Action 170 The operation executes an action on the managed node. An action has 171 a name, an optional calling point and a number of parameters included 172 in the request. From the above data only the name element is 173 mandatory. Optional data should be passed transparently to the 174 management entity connected to the netconf server. 176 The following XML Schema defines the action operation: 178 179 186 187 188 Schema defining the action operation. 189 190 191 194 197 198 199 200 201 202 The filter must select one specific XML element. 203 Subtree filter: Only a restricted subset of the subtree 204 filter may be used. The subtree filter must select exactly 205 one node based on the use of a content match node. For 206 actions the content match node will select the parent node 207 of the content match node. 208 XPATH filter: Only a restricted subset of XPATH may be 209 used. The location path must start from the root element, 210 use only the child axis and include checks on key elements. 211 212 213 214 215 217 218 219 220 221 222 223 225 226 227 228 229 231 233 235 The following example action restarts virtual router "router1" 236 immediately. 238 239 243 244 restart 245 246 /top/routing/virtual-router["routerName=router1"] 247 248 249 250 immediately 251 252 253 254 256 Positive Response: 258 If the action is successful an is sent. In case the 259 action doesn't return any parameters, the contains a 260 single element. If there are any OUT or INOUT parameters, then 261 an is sent containing a element. The data element 262 will contain all OUT and INOUT parameter elements. 264 The following reply returns a boolean parameter "restart-successful" 265 and an integer parameter 'run-level'. 267 269 271 true 272 5 273 274 276 Negative Response: 278 In all cases, if an error occurs, an is sent that 279 contains an element. 281 2.5. Modifications to Existing Operations 283 None. 285 2.6. Interactions with Other Capabilities 287 None. 289 3. Security Considerations 291 The same considerations as for the base Netconf Protocol [1] are 292 valid. It is assumed that actions are only allowed for an 293 authenticated user after passing some access control mechanism. 295 4. IANA Considerations 297 None (except maybe the capability's URI). 299 Appendix A. Change Log 301 draft-00 Initial version 303 5. References 305 [1] Enns, R., "NETCONF Configuration Protocol", 306 draft-ietf-netconf-prot-12 (work in progress), March 2006. 308 Author's Address 310 Balazs Lengyel 311 Ericsson Hungary 313 Phone: +36-1-4377320 314 Email: balazs.lengyel@ericsson.com 316 Full Copyright Statement 318 Copyright (C) The Internet Society (2006). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).