idnits 2.17.1 draft-ietf-i2rs-traceability-10.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 (May 13, 2016) is 2905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-06 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == 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 (~~), 4 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: November 14, 2016 Cisco 6 May 13, 2016 8 Interface to the Routing System (I2RS) Traceability: Framework and 9 Information Model 10 draft-ietf-i2rs-traceability-10 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 November 14, 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 Fields . . . . . . . . . . . . . . . . . . 6 66 5.3. End of Message Marker . . . . . . . . . . . . . . . . . . 9 67 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Operational Guidance . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Trace Log Creation . . . . . . . . . . . . . . . . . . . 10 70 7.2. Trace Log Temporary Storage . . . . . . . . . . . . . . . 10 71 7.3. Trace Log Rotation . . . . . . . . . . . . . . . . . . . 11 72 7.4. Trace Log Retrieval . . . . . . . . . . . . . . . . . . . 11 73 7.4.1. Retrieval Via Syslog . . . . . . . . . . . . . . . . 12 74 7.4.2. Retrieval Via I2RS Information Collection . . . . . . 12 75 7.4.3. Retrieval Via I2RS Pub-Sub . . . . . . . . . . . . . 12 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 11.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 defines the framework necessary to trace those 98 interactions between the I2RS Client and I2RS Agent. It goes on to 99 describe use cases for traceability within I2RS. Based on these use 100 cases, the document proposes an information model and reporting 101 requirements to provide for effective recording of I2RS interactions. 102 In this context, effective troubleshooting means being able to 103 identify what operation was performed by a specific I2RS Client via 104 the I2RS Agent, what was the result of the operation, and when that 105 operation was performed. 107 2. Terminology and Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 The architecture specification for I2RS [I-D.ietf-i2rs-architecture] 114 defines additional terms used in this document that are specific to 115 the I2RS domain, such as "I2RS Agent", "I2RS Client", etc. The 116 reader is expected to be familiar with the terminology and concepts 117 defined in [I-D.ietf-i2rs-architecture]. 119 3. Motivation 121 As networks scale and policy becomes an increasingly important part 122 of the control plane that creates and maintains the forwarding state, 123 operational complexity increases as well. I2RS offers more granular 124 and coherent control over policy and control plane state, but it also 125 removes or reduces the locality of the policy that has been applied 126 to the control plane at any individual forwarding device. The 127 ability to automate and abstract even complex policy-based controls 128 highlights the need for an equally scalable traceability function to 129 provide recording at event-level granularity of the evolution of the 130 routing system compliant with the requirements of I2RS (Section 5 of 131 [I-D.ietf-i2rs-problem-statement]). 133 4. Use Cases 135 An obvious motivation for I2RS traceability is the need to 136 troubleshoot and identify root-causes of problems in these 137 increasingly complex routing systems. For example, since I2RS is a 138 high-throughput multi-channel, full duplex and highly responsive 139 interface, I2RS Clients may be performing a large number of 140 operations on I2RS Agents concurrently or at nearly the same time and 141 quite possibly in very rapid succession. As these many changes are 142 made, the network reacts accordingly. These changes might lead to a 143 race condition, performance issues, data loss, or disruption of 144 services. In order to isolate the root cause of these issues it is 145 critical that a network operator or administrator has visibility into 146 what changes were made via I2RS at a specific time. 148 Some network environments have strong auditing requirements for 149 configuration and runtime changes. Other environments have policies 150 that require saving logging information for operational or regulatory 151 compliance considerations. These requirements therefore demand that 152 I2RS provides an account of changes made to network element routing 153 systems. 155 As I2RS becomes increasingly pervasive in routing environments, a 156 traceability model that supports controllable trace log retention 157 using a standardized structured data format offers significant 158 advtanges, such as the ability to create common tools supporting 159 automated testing, and facilitates the following use cases: 161 o Real-time monitoring and troubleshooting of router events; 163 o Automated event correlation, trend analysis, and anomaly 164 detection; 166 o Offline (manual or tools-based) analysis of router state evolution 167 from the retained trace logs; 169 o Enhanced network audit, management and forensic analysis 170 capabilities; 172 o Improved accounting of routing system operations; and 174 o Providing a standardized format for incident reporting and test 175 logging. 177 5. Information Model 179 These sections describe the I2RS traceability information model and 180 the detail corresponding to each of the fields to be logged. 182 5.1. I2RS Traceability Framework 184 This section describes a framework for I2RS traceability based on the 185 I2RS Architecture. 187 The interaction between the optional network application that drives 188 Client activity, I2RS Client, I2RS Agent, the Routing System and the 189 data captured in the I2RS trace log is shown in Figure 1. 191 +---------------+ 192 +----------------+ | 193 |Application | | 194 |.............. | | 0 or more Applications 195 | Application ID | + 196 +----------------+ 197 ^ 198 | 199 | 200 v 201 +-------------+ 202 +-------------+ | 203 |I2RS Client | | 204 |.............| | 1 or more Clients 205 | Client ID | + 206 +-------------+ 207 ^ 208 | 209 | 210 v 211 +-------------+ +-----------------------------+ 212 |I2RS Agent |---------------->|Trace Log | 213 | | |.............................| 214 +-------------+ |Log Entry [1 .. N] | 215 | ^ |.............................| 216 | | |Event ID | 217 | | |Starting Timestamp | 218 | | |Request State | 219 | | |Client ID | 220 | | |Client Priority | 221 | | |Secondary ID | 222 Operation + | | Result Code |Client Address | 223 Op Data | | |Requested Operation | 224 | | |Applied Operation | 225 | | |Operation Data Present | 226 | | |Requested Operation Data | 227 | | |Applied Operation Data | 228 | | |Transaction ID | 229 | | |Result Code | 230 | | |Ending Timestamp | 231 | | |Timeout Occurred | 232 v | |End Of Message | 233 +-------------+ +-----------------------------+ 234 |Routing | 235 |System | 236 +-------------+ 238 Figure 1: I2RS Interaction Trace Log Capture 240 5.2. I2RS Trace Log Fields 242 The following fields comprise an I2RS Trace Log. These fields ensure 243 that each I2RS interaction can be properly traced back to the Client 244 that made the request at a specific point in time. 246 The list below describes the fields captured in the I2RS trace log. 248 Event ID: This is a unique identifier for each event in the I2RS 249 trace log. An event can be a Client authenticating with the 250 Agent, a Client to Agent operation, or a Client disconnecting from 251 an Agent. Operation events can either be logged atomically upon 252 completion (in which case they will have both a Starting and an 253 Ending Timestamp field) or they can be logged at the beginning of 254 each Request State transition. Since operations can occur from 255 the same Client at the same time, it is important to have an 256 identifier that can be unambiguously associated to a specific 257 entry. If each state transition is logged for an operation, the 258 same ID MUST be used for each of Request State log entries In this 259 way, the life of a request can be easily followed in the I2RS 260 trace log. Beyond the requirement that the Event ID MUST be 261 unique for each event, the specific type and value is left up to 262 the implementation. 264 Starting Timestamp: The specific time at which the I2RS operation 265 enters the specified Request State within the Agent. If the log 266 entry covers the entire duration of the request, then this will be 267 time the was first received by the Agent. This field MUST be 268 present in all entries that specify the beginning of the state 269 transition, as well as those entries that log the entire duration 270 of the request. The time is passed in the full [RFC3339] format 271 including date and offset from Coordinated Universal Time (UTC). 272 Given that many I2RS operations can occur in rapid succession, the 273 fractional seconds element of the timestamp MUST be used to 274 provide adequate granularity. Fractional seconds SHOULD be 275 expressed with at least three significant digits in 276 second.microsecond format. 278 Request State: The state of the given operation within the I2RS 279 Agent state machine at the specified Starting or Ending 280 Timestamps. The I2RS Agent SHOULD generate a log entry at the 281 moment a request enters and exits a state. Upon entering a new 282 state, the log entry will have a Starting Timestamp set to the 283 time of entry and no Ending Timestamp. Upon exiting a state, the 284 log entry will have an Ending Timestamp set to the time of exit 285 and no Starting Timestamp. The progression of the request through 286 its various states and be linked using the Event ID. The states 287 can be one of the following values: 289 PENDING: The request has been received and queued for 290 processing. 292 IN PROCESS: The request is currently being handled by the I2RS 293 Agent. 295 COMPLETED: The request has reached a terminal point. 297 Every state transition SHOULD be logged unless doing so will put 298 an undue performance burden on the I2RS Agent. However, an entry 299 with Request State set to COMPLETED MUST be logged for all 300 operations. If the COMPLETED state is the only entry for a given 301 request, then it MUST have both Starting and Ending Timestamps 302 that cover the entire duration of the request from ingress to the 303 Agent until completion. 305 Client Identity: The I2RS Client identity used to authenticate the 306 Client to the I2RS Agent. 308 Client Priority: The I2RS Client priority assigned by the access 309 control model that authenticates the Client. For example, this 310 can be set by the NETCONF Access Control Model (NACM) as described 311 in [RFC6536]. 313 Secondary Identity: This is an opaque identity that may be known to 314 the Client from a controlling network application. This is used 315 to trace the network application driving the actions of the 316 Client. The Client may not provide this identity to the Agent if 317 there is no external network application driving the Client. 318 However, this field MUST be logged even if the Client does not 319 provide a Secondary Identity. In that case, the field will be 320 logged with an empty value. 322 Client Address: This is the network address of the Client that 323 connected to the Agent. For example, this may be an IPv4 or IPv6 324 address. 326 Requested Operation: This is the I2RS operation that was requested 327 to be performed. For example, this may be an add route operation 328 if a route is being inserted into a routing table. This may not 329 be the operation that was actually applied to the Agent. 331 In the case of a Client authenticating to the Agent, the Requested 332 Operation MUST be "CLIENT AUTHENTICATE". In the case of a Client 333 disconnecting from the Agent, the Requested Operation MUST be 334 "CLIENT DISCONNECT". 336 Applied Operation: This is the I2RS operation that was actually 337 performed. This can differ from the Requested Operation in cases 338 where the Agent cannot satisfy the Requested Operation. This 339 field may not be logged unless the Request State is COMPLETED. 341 Operation Data Present: This is a Boolean field that indicates 342 whether or not addition per-Operation Data is present. 344 Requested Operation Data: This field comprises the data passed to 345 the Agent to complete the desired operation. For example, if the 346 operation is a route add operation, the Operation Data would 347 include the route prefix, prefix length, and next hop information 348 to be inserted as well as the specific routing table to which the 349 route will be added. If Operation Data is provided, then the 350 Operation Data Present field MUST be set to TRUE. Some operations 351 may not provide operation data. In those cases, the Operation 352 Data Present field MUST be set to FALSE, and this field MUST be 353 empty. This may not represent the data that was used for the 354 operation that was actually applied on the Agent. 356 When a Client authenticates to the Agent, the Requested Operation 357 Data MUST contain the Client priority. Other attributes such as 358 credentials used for authentication MAY be logged. 360 Applied Operation Data: This field comprises the data that was 361 actually applied as part of the Applied Operation. If the Agent 362 cannot satisfy the Requested Operation with the Requested 363 Operation Data, then this field can differ from the Requested 364 Operation Data. This field will be empty unless Requested 365 Operation Data was specified. This field may not be logged unless 366 the Request State is COMPLETED. 368 Transaction ID: The Transaction Identity represents that this 369 particular operation is part of a long-running I2RS transaction 370 that can consist of multiple, related I2RS operations. Using this 371 value, one can relate multiple log entries together as they are 372 part of a single, overall I2RS operation. This is an optional 373 field that may not be logged unless the event is part of a long- 374 running transaction. 376 Result Code: This field holds the result of the operation once the 377 Request State is COMPLETED. In the case of Routing Information 378 Base (RIB) operations, this MUST be the return code as specified 379 in Section 4 of [I-D.ietf-i2rs-rib-info-model]. The operation may 380 not complete with a result code in the case of a timeout. If the 381 operation fails to complete, it MUST still log the attempted 382 operation with an appropriate result code. 384 Timeout Occurred: This is a Boolean field that indicates whether or 385 not a timeout occurred in the operation. When this is true, the 386 value of the Ending Timestamp MUST be set to the time the Agent 387 recorded for the timeout occurrence. This field may not be logged 388 unless the Request State is COMPLETED. 390 Ending Timestamp: The specific time at which the I2RS operation 391 exits the specified Request State within the I2RS Agent. If the 392 log entry covers the entire duration of the request, then this 393 will be time the request reached a terminal point within the 394 Agent. This field MUST be present in all entries that specify the 395 ending of the state transition, as well as those entries that log 396 the entire duration of the request. The time is passed in the 397 full [RFC3339] format including date and offset from Coordinated 398 Universal Time (UTC). See the description for Starting Timestamp 399 above for the proper format of Ending Timestamp. 401 End Of Message: Each log entry SHOULD have an appropriate End Of 402 Message (EOM) indicator. See section Section 5.3 below for more 403 details. 405 5.3. End of Message Marker 407 Because of variability within I2RS trace log fields, implementors 408 MUST use a format-appropriate end of message (EOM) indicator in order 409 to signify the end of a particular record. That is, regardless of 410 format, the I2RS trace log MUST provide a distinct way of 411 distinguishing between the end of one record and the beginning of 412 another. For example, in a linear formated log (similar to syslog) 413 the EOM marker may be a newline character. In an XML formated log, 414 the schema would provide for element tags that denote beginning and 415 end of records. In a JSON formated log, the syntax would provide 416 record separation (likely by comma-separated array elements). 418 6. Examples 420 This section shows a sample of what the fields and values could look 421 like. 423 Event ID: 1 424 Starting Timestamp: 2013-09-03T12:00:01.21+00:00 425 Request State: COMPLETED 426 Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66 427 Client Priority: 100 428 Secondary ID: com.example.RoutingApp 429 Client Address: 2001:db8:c0c0::2 430 Requested Operation: ROUTE_ADD 431 Applied Operation: ROUTE_ADD 432 Operation Data Present: TRUE 433 Requested Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 434 NEXT-HOP 2001:db8:cafe::1 435 Applied Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 436 NEXT-HOP 2001:db8:cafe::1 437 Transaction ID: 2763461 438 Result Code: SUCCESS(0) 439 Timeout Occurred: FALSE 440 Ending Timestamp: 2013-09-03T12:00:01.23+00:00 442 7. Operational Guidance 444 Specific operational procedures regarding temporary log storage, 445 rollover, retrieval, and access of I2RS trace logs is out of scope 446 for this document. Organizations employing I2RS trace logging are 447 responsible for establishing proper operational procedures that are 448 appropriately suited to their specific requirements and operating 449 environment. In this section we only provide fundamental and 450 generalized operational guidelines that are implementation- 451 independent. 453 7.1. Trace Log Creation 455 The I2RS Agent interacts with the Routing and Signaling functions of 456 the Routing Element. Since the I2RS Agent is responsible for 457 actually making the routing changes on the associated network device, 458 it creates and maintains a log of operations that can be retrieved to 459 troubleshoot I2RS-related impact to the network. Changes that occur 460 to the network element's local configuration outside of the I2RS 461 protocol that preempt I2RS state will only be logged if the network 462 element notifies the I2RS Agent. 464 7.2. Trace Log Temporary Storage 466 The trace information may be temporarily stored either in an in- 467 memory buffer or as a file local to the Agent. Care should be given 468 to the number of I2RS operations expected on a given Agent so that 469 the appropriate storage medium is used and to maximize the 470 effectiveness of the log while not impacting the performance and 471 health of the Agent. Client requests may not always be processed 472 synchronously or within a bounded time period. Consequently, to 473 ensure that trace log fields, such as "Operation" and "Result Code", 474 are part of the same trace log record it may require buffering of the 475 trace log entries. This buffering may result in additional resource 476 load on the Agent and the network element. 478 Section 7.3 discusses rotating the trace log in order to preserve the 479 operation history without exhausting Agent or network device 480 resources. It is perfectly acceptable, therefore, to use both an in- 481 memory buffer for recent operations while rotating or archiving older 482 operations to a local file. 484 It is outside the scope of this document to specify the 485 implementation details (i.e., size, throughput, data protection, 486 etc.) for the physical storage of the I2RS log file. In terms of 487 data retention, attention should be paid the length of time I2RS 488 trace log data is kept when that data contains security or privacy- 489 sensitive attributes. The longer this data is retained, the higher 490 the impact if it were to be leaked. It is also possible that 491 legislation may impose some additional requirements on the minimum 492 and/or maximum durations for which some kinds of data may be 493 retained. 495 7.3. Trace Log Rotation 497 In order to prevent the exhaustion of resources on the I2RS Agent or 498 its associated network device, it is RECOMMENDED that the I2RS Agent 499 implements trace log rotation. The details on how this is achieved 500 are left to the implementation and outside the scope of this 501 document. However, it should be possible to do file rotation based 502 on either time or size of the current trace log. If file rollover is 503 supported, multiple archived log files should be supported in order 504 to maximize the troubleshooting and accounting benefits of the trace 505 log. 507 7.4. Trace Log Retrieval 509 Implementors are free to provide their own, proprietary interfaces 510 and develop custom tools to retrieve and display the I2RS trace log. 511 These may include the display of the I2RS trace log as Command Line 512 Interface (CLI) output. However, a key intention of defining this 513 information model is to establish a vendor-agnostic and consistent 514 interface to collect I2RS trace data. Correspondingly, retrieval of 515 the data should also be made vendor-agnostic. 517 Despite the fact that export of I2RS trace log information could be 518 an invaluable diagnostic tool for off-box analysis, exporting this 519 information MUST NOT interfere with the ability of the Agent to 520 process new incoming operations. 522 The following three sections describe potential ways the trace log 523 can be accessed. The use of I2RS Pub-Sub for accessing trace log 524 data is mandatory-to-implement, while others are optional. 526 7.4.1. Retrieval Via Syslog 528 The syslog protocol [RFC5424] is a standard way of sending event 529 notification messages from a host to a collector. However, the 530 protocol does not define any standard format for storing the 531 messages, and thus implementors of I2RS tracing would be left to 532 define their own format. So, while the data contained within the 533 syslog message would adhere to this information model, and may be 534 consumable by a human operator, it would not be easily parseable by a 535 machine. Syslog MAY be employed as a means of retrieving or 536 disseminating the I2RS trace log contents. 538 If syslog is used for trace log retrieval, then existing logging 539 infrastructure and capabilities of syslog [RFC5424] should be 540 leveraged without the need to define or extend existing formats. 541 That is, the various fields described in Section 5.2 SHOULD be 542 modeled and encoded as Structured Data Elements (referred to as "SD- 543 ELEMENT"), as described in Section 6.3.1 of [RFC5424]. 545 7.4.2. Retrieval Via I2RS Information Collection 547 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture] 548 defines a mechanism for information collection. The information 549 collected includes obtaining a snapshot of a large amount of data 550 from the network element. It is the intent of I2RS to make this data 551 available in an implementor-agnostic fashion. Therefore, the I2RS 552 trace log SHOULD be made available via the I2RS information 553 collection mechanism either as a single snapshot or via a 554 subscription stream. 556 7.4.3. Retrieval Via I2RS Pub-Sub 558 Section 7.6 of the I2RS architecture [I-D.ietf-i2rs-architecture] 559 goes on to describe notification mechanisms for a feed of changes 560 happening within the I2RS layer. Specifically, the requirements for 561 a publish-subscribe system for I2RS are defined in 562 [I-D.ietf-i2rs-pub-sub-requirements]. I2RS Agents MUST support 563 publishing I2RS trace log information to that feed as described in 564 that document. Subscribers would then receive a live stream of I2RS 565 interactions in trace log format and could flexibly choose to do a 566 number of things with the log messages. For example, the subscribers 567 could log the messages to a datastore, aggregate and summarize 568 interactions from a single Client, etc. The full range of potential 569 activites is virtually limitless and the details of how they are 570 performed are outside the scope of this document, however. 572 8. IANA Considerations 574 This document makes no request of IANA. 576 9. Security Considerations 578 The I2RS trace log, like any log file, reveals the state of the 579 entity producing it as well as the identifying information elements 580 and detailed interactions of the system containing it. The 581 information model described in this document does not itself 582 introduce any security issues, but it does define the set of 583 attributes that make up an I2RS log file. These attributes may 584 contain sensitive information and thus should adhere to the security, 585 privacy and permission policies of the organization making use of the 586 I2RS log file. 588 It is outside the scope of this document to specify how to protect 589 the stored log file, but it is expected that adequate precautions and 590 security best practices such as disk encryption, appropriately 591 restrictive file/directory permissions, suitable hardening and 592 physical security of logging entities, mutual authentication, 593 transport encryption, channel confidentiality, and channel integrity 594 if transferring log files. Additionally, the potentially sensitive 595 information contained in a log file SHOULD be adequately anonymized 596 or obfuscated by operators to ensure its privacy. 598 10. Acknowledgments 600 The authors would like to thank Alia Atlas for her initial feedback 601 and overall support for this work. Additionally, the authors 602 acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel 603 Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog 604 Lee, Sue Hares, Mach Chen, Alex Clemm, Stephen Farrell, Benoit 605 Claise, Les Ginsberg, Suresh Krishnan, and Elwyn Davies for their 606 reviews, contributed text, and suggested improvements to this 607 document. 609 11. References 610 11.1. Normative References 612 [I-D.ietf-i2rs-architecture] 613 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 614 Nadeau, "An Architecture for the Interface to the Routing 615 System", draft-ietf-i2rs-architecture-15 (work in 616 progress), April 2016. 618 [I-D.ietf-i2rs-pub-sub-requirements] 619 Voit, E., Clemm, A., and A. Prieto, "Requirements for 620 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 621 requirements-06 (work in progress), April 2016. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 629 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 630 . 632 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 633 DOI 10.17487/RFC5424, March 2009, 634 . 636 11.2. Informative References 638 [I-D.ietf-i2rs-problem-statement] 639 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 640 Routing System Problem Statement", draft-ietf-i2rs- 641 problem-statement-10 (work in progress), February 2016. 643 [I-D.ietf-i2rs-rib-info-model] 644 Bahadur, N., Kini, S., and J. Medved, "Routing Information 645 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 646 in progress), October 2015. 648 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 649 Protocol (NETCONF) Access Control Model", RFC 6536, 650 DOI 10.17487/RFC6536, March 2012, 651 . 653 Authors' Addresses 654 Joe Clarke 655 Cisco Systems, Inc. 656 7200-12 Kit Creek Road 657 Research Triangle Park, NC 27709 658 US 660 Phone: +1-919-392-2867 661 Email: jclarke@cisco.com 663 Gonzalo Salgueiro 664 Cisco Systems, Inc. 665 7200-12 Kit Creek Road 666 Research Triangle Park, NC 27709 667 US 669 Email: gsalguei@cisco.com 671 Carlos Pignataro 672 Cisco Systems, Inc. 673 7200-12 Kit Creek Road 674 Research Triangle Park, NC 27709 675 US 677 Email: cpignata@cisco.com