idnits 2.17.1 draft-ietf-i2rs-traceability-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2016) is 2931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-06 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-08 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS J. Clarke 3 Internet-Draft G. Salgueiro 4 Intended status: Informational C. Pignataro 5 Expires: October 19, 2016 Cisco 6 April 17, 2016 8 Interface to the Routing System (I2RS) Traceability: Framework and 9 Information Model 10 draft-ietf-i2rs-traceability-08 12 Abstract 14 This document describes a framework for traceability in the Interface 15 to the Routing System (I2RS) and information model for that 16 framework. It specifies the motivation, requirements, use cases, and 17 defines an information model for recording interactions between 18 elements implementing the I2RS protocol. This framework provides a 19 consistent tracing interface for components implementing the I2RS 20 architecture to record what was done, by which component, and when. 21 It aims to improve the management of I2RS implementations, and can be 22 used for troubleshooting, auditing, forensics, and accounting 23 purposes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 19, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. I2RS Traceability Framework . . . . . . . . . . . . . . . 4 65 5.2. I2RS Trace Log Mandatory Fields . . . . . . . . . . . . . 6 66 5.3. End of Message Marker . . . . . . . . . . . . . . . . . . 8 67 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Operational Guidance . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Trace Log Creation . . . . . . . . . . . . . . . . . . . 9 70 7.2. Trace Log Temporary Storage . . . . . . . . . . . . . . . 9 71 7.3. Trace Log Rotation . . . . . . . . . . . . . . . . . . . 10 72 7.4. Trace Log Retrieval . . . . . . . . . . . . . . . . . . . 10 73 7.4.1. Retrieval Via Syslog . . . . . . . . . . . . . . . . 10 74 7.4.2. Retrieval Via I2RS Information Collection . . . . . . 11 75 7.4.3. Retrieval Via I2RS Pub-Sub . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The architecture for the Interface to the Routing System 87 ([I-D.ietf-i2rs-architecture]) specifies that I2RS Clients wishing to 88 retrieve or change routing state on a routing element MUST 89 authenticate to an I2RS Agent. The I2RS Client will have a unique 90 identity it provides for authentication, and should provide another, 91 opaque identity for applications communicating through it. The 92 programming of routing state will produce a return code containing 93 the results of the specified operation and associated reason(s) for 94 the result. All of this is critical information to be used for 95 understanding the history of I2RS interactions. 97 This document describes use cases for I2RS traceability. Based on 98 these use cases, the document proposes an information model and 99 reporting requirements to provide for effective recording of I2RS 100 interactions. In this context, effective troubleshooting means being 101 able to identify what operation was performed by a specific I2RS 102 Client, what was the result of the operation, and when that operation 103 was performed. 105 Discussions about the retention of the data logged as part of I2RS 106 traceability, while important, are outside of the scope of this 107 document. 109 2. Terminology and Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The architecture specification for I2RS [I-D.ietf-i2rs-architecture] 116 defines additional terms used in this document that are specific to 117 the I2RS domain, such as "I2RS Agent", "I2RS Client", etc. The 118 reader is expected to be familiar with the terminology and concepts 119 defined in [I-D.ietf-i2rs-architecture]. 121 3. Motivation 123 As networks scale and policy becomes an increasingly important part 124 of the control plane that creates and maintains the forwarding state, 125 operational complexity increases as well. I2RS offers more granular 126 and coherent control over policy and control plane state, but it also 127 removes or reduces the locality of the policy that has been applied 128 to the control plane at any individual forwarding device. The 129 ability to automate and abstract even complex policy-based controls 130 highlights the need for an equally scalable traceability function to 131 provide event-level granularity of the routing system compliant with 132 the requirements of I2RS (Section 5 of 133 [I-D.ietf-i2rs-problem-statement]). 135 4. Use Cases 137 An obvious motivation for I2RS traceability is the need to 138 troubleshoot and identify root-causes of problems in these 139 increasingly complex routing systems. For example, since I2RS is a 140 high-throughput multi-channel, full duplex and highly responsive 141 interface, I2RS Clients may be performing a large number of 142 operations on I2RS Agents concurrently or at nearly the same time and 143 quite possibly in very rapid succession. As these many changes are 144 made, the network reacts accordingly. These changes might lead to a 145 race condition, performance issues, data loss, or disruption of 146 services. In order to isolate the root cause of these issues it is 147 critical that a network operator or administrator has visibility into 148 what changes were made via I2RS at a specific time. 150 Some network environments have strong auditing requirements for 151 configuration and runtime changes. Other environments have policies 152 that require saving logging information for operational or regulatory 153 compliance considerations. These requirements therefore demand that 154 I2RS provides an account of changes made to network element routing 155 systems. 157 As I2RS becomes increasingly pervasive in routing environments, a 158 traceability model offers significant advantages and facilitates the 159 following use cases: 161 o Automated event correlation, trend analysis, and anomaly 162 detection; 164 o Trace log storage for offline (manual or tools) analysis; 166 o Improved accounting of routing system operations; 168 o Standardized structured data format for writing common tools; 170 o Common reference for automated testing and incident reporting; 172 o Real-time monitoring and troubleshooting; 174 o Enhanced network audit, management and forensic analysis 175 capabilities. 177 5. Information Model 179 5.1. I2RS Traceability Framework 181 This section describes a framework for I2RS traceability based on the 182 I2RS Architecture. Some notable elements on the architecture are in 183 this section. 185 The interaction between the optional northbound application, I2RS 186 Client, I2RS Agent, the Routing System and the data captured in the 187 I2RS trace log is shown in Figure 1. 189 +----------------+ 190 |Application | 191 |.............. | 192 | Application ID | 193 +----------------+ 194 ^ 195 | 0 .. N 196 | 197 V 198 +-------------+ 199 |I2RS Client | 200 |.............| 201 | Client ID | 202 +-------------+ 203 ^ 204 | 1 .. N 205 | 206 V 207 +-------------+ +-----------------------------+ 208 |I2RS Agent |---------------->|Trace Log | 209 | | |.............................| 210 +-------------+ |Log Entry [1 .. N] | 211 ^ |.............................| 212 | |Request Timestamp | 213 | |Client ID | 214 | |Client Priority | 215 | ^ |Secondary ID | 216 Operation + | Result Code |Client Address | 217 Op Data | |Requested Operation | 218 V | |Applied Operation | 219 | |Operation Data Present | 220 | |Requested Operation Data | 221 | |Applied Operation Data | 222 | |Transaction ID | 223 | |Result Code | 224 | |Result Timestamp | 225 | |Timeout Occurred | 226 V |End Of Message | 227 +-------------+ +-----------------------------+ 228 |Routing | 229 |System | 230 +-------------+ 232 Figure 1: I2RS Interaction Trace Log Capture 234 5.2. I2RS Trace Log Mandatory Fields 236 In order to ensure that each I2RS interaction can be properly traced 237 back to the Client that made the request at a specific point in time, 238 the following information MUST be collected and stored by the Agent. 240 The list below describes the fields captured in the I2RS trace log. 242 Entry ID: This is a unique identifier for each entry in the I2RS 243 trace log. Since multiple operations can occur from the same 244 Client at the same time, it is important to have an identifier 245 that can be unambiguously associated to a specific entry. 247 Request Timestamp: The specific time at which the I2RS operation 248 was received by the Agent. The time is passed in the [RFC3339] 249 format. Given that many I2RS operations can occur in rapid 250 succession, the use of fractional seconds MUST be used to provide 251 adequate granularity. Fractional seconds SHOULD be expressed 252 using human-readable 32-bit second and 32-bit microsecond 253 granularity in second.microsecond format. 255 Client Identity: The I2RS Client identity used to authenticate the 256 Client to the I2RS Agent. 258 Client Priority: The I2RS Client priority assigned by the access 259 control model that authenticates the Client. For example, this 260 can be set by the NETCONF Access Control Model (NACM) as described 261 in [RFC6536]. 263 Secondary Identity: This is an opaque identity that may be known to 264 the Client from a northbound controlling application. This is 265 used to trace the northbound application driving the actions of 266 the Client. The Client may not provide this identity to the Agent 267 if there is no external application driving the Client. However, 268 this field MUST be logged. If the Client does not provide an 269 application ID, then the Agent MUST log an UNAVAILABLE value in 270 the field. 272 Client Address: This is the network address of the Client that 273 connected to the Agent. For example, this may be an IPv4 or IPv6 274 address. 276 Requested Operation: This is the I2RS operation that was requested 277 to be performed. For example, this may be an add route operation 278 if a route is being inserted into a routing table. This may not 279 be the operation that was actually applied to the Agent. 281 Applied Operation: This is the I2RS operation that was actually 282 performed. This can differ from the Requested Operation in cases 283 where the Agent cannot satisfy the Requested Operation. 285 Operation Data Present: This is a Boolean field that indicates 286 whether or not addition per-Operation Data is present. 288 Requested Operation Data: This field comprises the data passed to 289 the Agent to complete the desired operation. For example, if the 290 operation is a route add operation, the Operation Data would 291 include the route prefix, prefix length, and next hop information 292 to be inserted as well as the specific routing table to which the 293 route will be added. If Operation Data is provided, then the 294 Operation Data Present field MUST be set to TRUE. Some operations 295 may not provide operation data. In those cases, the Operation 296 Data Present field MUST be set to FALSE, and this field MUST be 297 empty. This may not represent the data that was used for the 298 operation that was actually applied on the Agent. 300 Applied Operation Data: This field comprises the data that was 301 actually applied as part of the Applied Operation. If the Agent 302 cannot satisfy the Requested Operation with the Requested 303 Operation Data, then this field can differ from the Requested 304 Operation Data. 306 Transaction ID: The Transaction Identity represents that this 307 particular operation is part of a long-running I2RS transaction 308 that can consist of multiple, related I2RS operations. Using this 309 value, one can relate multiple log entries together as they are 310 part of a single, overall I2RS operation. 312 Result Code: This field holds the result of the operation. In the 313 case of RIB operations, this MUST be the return code as specified 314 in Section 4 of [I-D.ietf-i2rs-rib-info-model]. The operation may 315 not complete with a result code in the case of a timeout. If the 316 operation fails to complete, it MUST still log the attempted 317 operation with an appropriate result code (e.g., a result code 318 indicating a timeout). 320 Timeout Occurred: This is a Boolean field that indicates whether or 321 not a timeout occurred in the operation. When this is true, the 322 value of the Result Timestamp MUST be set to the time the Agent 323 recorded for the timeout occurrence. 325 Result Timestamp: The specific time at which the I2RS operation was 326 completed by the Agent. The time is passed in the [RFC3339] 327 format. Given that many I2RS operations can occur in rapid 328 succession, the use of fractional seconds MUST be used to provide 329 adequate granularity. Fractional seconds SHOULD be expressed 330 using human-readable 32-bit second and 32-bit microsecond 331 granularity in second.microsecond format. 333 End Of Message: Each log entry SHOULD have an appropriate End Of 334 Message (EOM) indicator. See section Section 5.3 below for more 335 details. 337 5.3. End of Message Marker 339 Because of variability within I2RS trace log fields, implementors 340 MUST use a format-appropriate end of message (EOM) indicator in order 341 to signify the end of a particular record. That is, regardless of 342 format, the I2RS trace log MUST provide a distinct way of 343 distinguishing between the end of one record and the beginning of 344 another. For example, in a linear formated log (similar to syslog) 345 the EOM marker may be a newline character. In an XML formated log, 346 the schema would provide for element tags that denote beginning and 347 end of records. In a JSON formated log, the syntax would provide 348 record separation (likely by comma-separated array elements). 350 6. Examples 352 This section shows a sample of what the fields and values could look 353 like. 355 Entry ID: 1 356 Request Timestamp: 2013-09-03T12:00:01.21+00:00 357 Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66 358 Client Priority: 100 359 Secondary ID com.example.RoutingApp 360 Client Address: 2001:db8:c0c0::2 361 Requested Operation: ROUTE_ADD 362 Applied Operation: ROUTE_ADD 363 Operation Data Present: TRUE 364 Requested Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 365 NEXT-HOP 2001:db8:cafe::1 366 Applied Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 367 NEXT-HOP 2001:db8:cafe::1 368 Transaction ID: 2763461 369 Result Code: SUCCESS(0) 370 Timeout Occurred: FALSE 371 Result Timestamp: 2013-09-03T12:00:01.23+00:00 373 7. Operational Guidance 375 Specific operational procedures regarding temporary log storage, 376 rollover, retrieval, and access of I2RS trace logs is out of scope 377 for this document. Organizations employing I2RS trace logging are 378 responsible for establishing proper operational procedures that are 379 appropriately suited to their specific requirements and operating 380 environment. In this section we only provide fundamental and 381 generalized operational guidelines that are implementation- 382 independent. 384 7.1. Trace Log Creation 386 The I2RS Agent interacts with the Routing and Signaling functions of 387 the Routing Element. Since the I2RS Agent is responsible for 388 actually making the routing changes on the associated network device, 389 it creates and maintains a log of operations that can be retrieved to 390 troubleshoot I2RS-related impact to the network. 392 7.2. Trace Log Temporary Storage 394 The trace information may be temporarily stored either in an in- 395 memory buffer or as a file local to the Agent. Care should be given 396 to the number of I2RS operations expected on a given Agent so that 397 the appropriate storage medium is used and to maximize the 398 effectiveness of the log while not impacting the performance and 399 health of the Agent. Client requests may not always be processed 400 synchronously or within a bounded time period. Consequently, to 401 ensure that trace log fields, such as "Operation" and "Result Code", 402 are part of the same trace log record it may require buffering of the 403 trace log entries. This buffering may result in additional resource 404 load on the Agent and the network element. 406 Section 7.3 discusses rotating the trace log in order to preserve the 407 operation history without exhausting Agent or network device 408 resources. It is perfectly acceptable, therefore, to use both an in- 409 memory buffer for recent operations while rotating or archiving older 410 operations to a local file. 412 It is outside the scope of this document to specify the 413 implementation details (i.e., size, throughput, data protection, 414 privacy, etc.) for the physical storage of the I2RS log file. Data 415 retention policies of the I2RS traceability log is also outside the 416 scope of this document. 418 7.3. Trace Log Rotation 420 In order to prevent the exhaustion of resources on the I2RS Agent or 421 its associated network device, it is RECOMMENDED that the I2RS Agent 422 implements trace log rotation. The details on how this is achieved 423 are left to the implementation and outside the scope of this 424 document. However, it should be possible to do file rotation based 425 on either time or size of the current trace log. If file rollover is 426 supported, multiple archived log files should be supported in order 427 to maximize the troubleshooting and accounting benefits of the trace 428 log. 430 7.4. Trace Log Retrieval 432 Implementors are free to provide their own, proprietary interfaces 433 and develop custom tools to retrieve and display the I2RS trace log. 434 These may include the display of the I2RS trace log as Command Line 435 Interface (CLI) output. However, a key intention of defining this 436 information model is to establish an vendor-agnostic and consistent 437 interface to collect I2RS trace data. Correspondingly, retrieval of 438 the data should also be made vendor-agnostic. 440 Despite the fact that export of I2RS trace log information could be 441 an invaluable diagnostic tool for off-box analysis, exporting this 442 information MUST NOT interfere with the ability of the Agent to 443 process new incoming operations. 445 The following three sections describe potential ways the trace log 446 can be accessed. At least one of these three MUST be used, with the 447 I2RS mechanisms being preferred as they are vendor-independent 448 approaches to retrieving the data. 450 7.4.1. Retrieval Via Syslog 452 The syslog protocol [RFC5424] is a standard way of sending event 453 notification messages from a host to a collector. However, the 454 protocol does not define any standard format for storing the 455 messages, and thus implementors of I2RS tracing would be left to 456 define their own format. So, while the data contained within the 457 syslog message would adhere to this information model, and may be 458 consumable by a human operator, it would not be easily parseable by a 459 machine. Syslog MAY be employed as a means of retrieving or 460 disseminating the I2RS trace log contents. 462 If syslog is used for trace log retrieval, then existing logging 463 infrastructure and capabilities of syslog [RFC5424] should be 464 leveraged without the need to define or extend existing formats. For 465 example, the various fields described in Section 5.2 SHOULD be 466 modeled and encoded as Structured Data Elements (referred to as "SD- 467 ELEMENT"), as described in Section 6.3.1 of [RFC5424]. 469 7.4.2. Retrieval Via I2RS Information Collection 471 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture] 472 defines a mechanism for information collection. The information 473 collected includes obtaining a snapshot of a large amount of data 474 from the network element. It is the intent of I2RS to make this data 475 available in an implementor-agnostic fashion. Therefore, the I2RS 476 trace log SHOULD be made available via the I2RS information 477 collection mechanism either as a single snapshot or via a 478 subscription stream. 480 7.4.3. Retrieval Via I2RS Pub-Sub 482 Section 7.6 of the I2RS architecture [I-D.ietf-i2rs-architecture] 483 goes on to describe notification mechanisms for a feed of changes 484 happening within the I2RS layer. Specifically, the requirements for 485 a publish-subscribe system for I2RS are defined in 486 [I-D.ietf-i2rs-pub-sub-requirements]. I2RS Agents SHOULD support 487 publishing I2RS trace log information to that feed as described in 488 that document. Subscribers would then receive a live stream of I2RS 489 interactions in trace log format and could flexibly choose to do a 490 number of things with the log messages. For example, the subscribers 491 could log the messages to a datastore, aggregate and summarize 492 interactions from a single Client, etc. The full range of potential 493 activites is virtually limitless and the details of how they are 494 performed are outside the scope of this document, however. 496 8. IANA Considerations 498 This document makes no request of IANA. 500 9. Security Considerations 502 The I2RS trace log, like any log file, reveals the state of the 503 entity producing it as well as the identifying information elements 504 and detailed interactions of the system containing it. The 505 information model described in this document does not itself 506 introduce any security issues, but it does define the set of 507 attributes that make up an I2RS log file. These attributes may 508 contain sensitive information and thus should adhere to the security, 509 privacy and permission policies of the organization making use of the 510 I2RS log file. 512 It is outside the scope of this document to specify how to protect 513 the stored log file, but it is expected that adequate precautions and 514 security best practices such as disk encryption, appropriately 515 restrictive file/directory permissions, suitable hardening and 516 physical security of logging entities, mutual authentication, 517 transport encryption, channel confidentiality, and channel integrity 518 if transferring log files. Additionally, the potentially sensitive 519 information contained in a log file SHOULD be adequately anonymized 520 or obfuscated by operators to ensure its privacy. 522 10. Acknowledgments 524 The authors would like to thank Alia Atlas for her initial feedback 525 and overall support for this work. Additionally, the authors 526 acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel 527 Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog 528 Lee, Sue Hares, Mach Chen, and Alex Clemm for their reviews, 529 contributed text, and suggested improvements to this document. 531 11. References 533 11.1. Normative References 535 [I-D.ietf-i2rs-architecture] 536 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 537 Nadeau, "An Architecture for the Interface to the Routing 538 System", draft-ietf-i2rs-architecture-13 (work in 539 progress), February 2016. 541 [I-D.ietf-i2rs-problem-statement] 542 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 543 Routing System Problem Statement", draft-ietf-i2rs- 544 problem-statement-10 (work in progress), February 2016. 546 [I-D.ietf-i2rs-pub-sub-requirements] 547 Voit, E., Clemm, A., and A. Prieto, "Requirements for 548 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 549 requirements-06 (work in progress), April 2016. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, 553 DOI 10.17487/RFC2119, March 1997, 554 . 556 11.2. Informative References 558 [I-D.ietf-i2rs-rib-info-model] 559 Bahadur, N., Kini, S., and J. Medved, "Routing Information 560 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 561 in progress), October 2015. 563 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 564 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 565 . 567 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 568 DOI 10.17487/RFC5424, March 2009, 569 . 571 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 572 Protocol (NETCONF) Access Control Model", RFC 6536, 573 DOI 10.17487/RFC6536, March 2012, 574 . 576 Authors' Addresses 578 Joe Clarke 579 Cisco Systems, Inc. 580 7200-12 Kit Creek Road 581 Research Triangle Park, NC 27709 582 US 584 Phone: +1-919-392-2867 585 Email: jclarke@cisco.com 587 Gonzalo Salgueiro 588 Cisco Systems, Inc. 589 7200-12 Kit Creek Road 590 Research Triangle Park, NC 27709 591 US 593 Email: gsalguei@cisco.com 595 Carlos Pignataro 596 Cisco Systems, Inc. 597 7200-12 Kit Creek Road 598 Research Triangle Park, NC 27709 599 US 601 Email: cpignata@cisco.com