idnits 2.17.1 draft-ietf-i2rs-traceability-11.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 18, 2016) is 2893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 2 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 19, 2016 Cisco 6 May 18, 2016 8 Interface to the Routing System (I2RS) Traceability: Framework and 9 Information Model 10 draft-ietf-i2rs-traceability-11 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 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 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. 247 This list represents a common set of fields that MUST appear in all 248 I2RS trace logs. In addition to these fields, I2RS Agent 249 implementations MAY choose to log additional fields such as I2RS 250 Client vendor or Agent statistics like free memory, performance 251 metrics, etc. 253 Event ID: This is a unique identifier for each event in the I2RS 254 trace log. An event can be a Client authenticating with the 255 Agent, a Client to Agent operation, or a Client disconnecting from 256 an Agent. Operation events can either be logged atomically upon 257 completion (in which case they will have both a Starting and an 258 Ending Timestamp field) or they can be logged at the beginning of 259 each Request State transition. Since operations can occur from 260 the same Client at the same time, it is important to have an 261 identifier that can be unambiguously associated to a specific 262 entry. If each state transition is logged for an operation, the 263 same ID MUST be used for each of Request State log entries In this 264 way, the life of a request can be easily followed in the I2RS 265 trace log. Beyond the requirement that the Event ID MUST be 266 unique for each event, the specific type and value is left up to 267 the implementation. 269 Starting Timestamp: The specific time at which the I2RS operation 270 enters the specified Request State within the Agent. If the log 271 entry covers the entire duration of the request, then this will be 272 time the was first received by the Agent. This field MUST be 273 present in all entries that specify the beginning of the state 274 transition, as well as those entries that log the entire duration 275 of the request. The time is passed in the full [RFC3339] format 276 including date and offset from Coordinated Universal Time (UTC). 277 Given that many I2RS operations can occur in rapid succession, the 278 fractional seconds element of the timestamp MUST be used to 279 provide adequate granularity. Fractional seconds SHOULD be 280 expressed with at least three significant digits in 281 second.microsecond format. 283 Request State: The state of the given operation within the I2RS 284 Agent state machine at the specified Starting or Ending 285 Timestamps. The I2RS Agent SHOULD generate a log entry at the 286 moment a request enters and exits a state. Upon entering a new 287 state, the log entry will have a Starting Timestamp set to the 288 time of entry and no Ending Timestamp. Upon exiting a state, the 289 log entry will have an Ending Timestamp set to the time of exit 290 and no Starting Timestamp. The progression of the request through 291 its various states and be linked using the Event ID. The states 292 can be one of the following values: 294 PENDING: The request has been received and queued for 295 processing. 297 IN PROCESS: The request is currently being handled by the I2RS 298 Agent. 300 COMPLETED: The request has reached a terminal point. 302 Every state transition SHOULD be logged unless doing so will put 303 an undue performance burden on the I2RS Agent. However, an entry 304 with Request State set to COMPLETED MUST be logged for all 305 operations. If the COMPLETED state is the only entry for a given 306 request, then it MUST have both Starting and Ending Timestamps 307 that cover the entire duration of the request from ingress to the 308 Agent until completion. 310 Client Identity: The I2RS Client identity used to authenticate the 311 Client to the I2RS Agent. 313 Client Priority: The I2RS Client priority assigned by the access 314 control model that authenticates the Client. For example, this 315 can be set by the NETCONF Access Control Model (NACM) as described 316 in [RFC6536]. 318 Secondary Identity: This is an opaque identity that may be known to 319 the Client from a controlling network application. This is used 320 to trace the network application driving the actions of the 321 Client. The Client may not provide this identity to the Agent if 322 there is no external network application driving the Client. 323 However, this field MUST be logged even if the Client does not 324 provide a Secondary Identity. In that case, the field will be 325 logged with an empty value. 327 Client Address: This is the network address of the Client that 328 connected to the Agent. For example, this may be an IPv4 or IPv6 329 address. 331 Requested Operation: This is the I2RS operation that was requested 332 to be performed. For example, this may be an add route operation 333 if a route is being inserted into a routing table. This may not 334 be the operation that was actually applied to the Agent. 336 In the case of a Client authenticating to the Agent, the Requested 337 Operation MUST be "CLIENT AUTHENTICATE". In the case of a Client 338 disconnecting from the Agent, the Requested Operation MUST be 339 "CLIENT DISCONNECT". 341 Applied Operation: This is the I2RS operation that was actually 342 performed. This can differ from the Requested Operation in cases 343 where the Agent cannot satisfy the Requested Operation. This 344 field may not be logged unless the Request State is COMPLETED. 346 Operation Data Present: This is a Boolean field that indicates 347 whether or not addition per-Operation Data is present. 349 Requested Operation Data: This field comprises the data passed to 350 the Agent to complete the desired operation. For example, if the 351 operation is a route add operation, the Operation Data would 352 include the route prefix, prefix length, and next hop information 353 to be inserted as well as the specific routing table to which the 354 route will be added. If Operation Data is provided, then the 355 Operation Data Present field MUST be set to TRUE. Some operations 356 may not provide operation data. In those cases, the Operation 357 Data Present field MUST be set to FALSE, and this field MUST be 358 empty. This may not represent the data that was used for the 359 operation that was actually applied on the Agent. 361 When a Client authenticates to the Agent, the Requested Operation 362 Data MUST contain the Client priority. Other attributes such as 363 credentials used for authentication MAY be logged. 365 Applied Operation Data: This field comprises the data that was 366 actually applied as part of the Applied Operation. If the Agent 367 cannot satisfy the Requested Operation with the Requested 368 Operation Data, then this field can differ from the Requested 369 Operation Data. This field will be empty unless Requested 370 Operation Data was specified. This field may not be logged unless 371 the Request State is COMPLETED. 373 Transaction ID: The Transaction Identity represents that this 374 particular operation is part of a long-running I2RS transaction 375 that can consist of multiple, related I2RS operations. Using this 376 value, one can relate multiple log entries together as they are 377 part of a single, overall I2RS operation. This is an optional 378 field that may not be logged unless the event is part of a long- 379 running transaction. 381 Result Code: This field holds the result of the operation once the 382 Request State is COMPLETED. In the case of Routing Information 383 Base (RIB) operations, this MUST be the return code as specified 384 in Section 4 of [I-D.ietf-i2rs-rib-info-model]. The operation may 385 not complete with a result code in the case of a timeout. If the 386 operation fails to complete, it MUST still log the attempted 387 operation with an appropriate result code. 389 Timeout Occurred: This is a Boolean field that indicates whether or 390 not a timeout occurred in the operation. When this is true, the 391 value of the Ending Timestamp MUST be set to the time the Agent 392 recorded for the timeout occurrence. This field may not be logged 393 unless the Request State is COMPLETED. 395 Ending Timestamp: The specific time at which the I2RS operation 396 exits the specified Request State within the I2RS Agent. If the 397 log entry covers the entire duration of the request, then this 398 will be time the request reached a terminal point within the 399 Agent. This field MUST be present in all entries that specify the 400 ending of the state transition, as well as those entries that log 401 the entire duration of the request. The time is passed in the 402 full [RFC3339] format including date and offset from Coordinated 403 Universal Time (UTC). See the description for Starting Timestamp 404 above for the proper format of Ending Timestamp. 406 End Of Message: Each log entry SHOULD have an appropriate End Of 407 Message (EOM) indicator. See section Section 5.3 below for more 408 details. 410 5.3. End of Message Marker 412 Because of variability within I2RS trace log fields, implementors 413 MUST use a format-appropriate end of message (EOM) indicator in order 414 to signify the end of a particular record. That is, regardless of 415 format, the I2RS trace log MUST provide a distinct way of 416 distinguishing between the end of one record and the beginning of 417 another. For example, in a linear formated log (similar to syslog) 418 the EOM marker may be a newline character. In an XML formated log, 419 the schema would provide for element tags that denote beginning and 420 end of records. In a JSON formated log, the syntax would provide 421 record separation (likely by comma-separated array elements). 423 6. Examples 425 This section shows a sample of what the fields and values could look 426 like. 428 Event ID: 1 429 Starting Timestamp: 2013-09-03T12:00:01.21+00:00 430 Request State: COMPLETED 431 Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66 432 Client Priority: 100 433 Secondary ID: com.example.RoutingApp 434 Client Address: 2001:db8:c0c0::2 435 Requested Operation: ROUTE_ADD 436 Applied Operation: ROUTE_ADD 437 Operation Data Present: TRUE 438 Requested Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 439 NEXT-HOP 2001:db8:cafe::1 440 Applied Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64 441 NEXT-HOP 2001:db8:cafe::1 442 Transaction ID: 2763461 443 Result Code: SUCCESS(0) 444 Timeout Occurred: FALSE 445 Ending Timestamp: 2013-09-03T12:00:01.23+00:00 447 7. Operational Guidance 449 Specific operational procedures regarding temporary log storage, 450 rollover, retrieval, and access of I2RS trace logs is out of scope 451 for this document. Organizations employing I2RS trace logging are 452 responsible for establishing proper operational procedures that are 453 appropriately suited to their specific requirements and operating 454 environment. In this section we only provide fundamental and 455 generalized operational guidelines that are implementation- 456 independent. 458 7.1. Trace Log Creation 460 The I2RS Agent interacts with the Routing and Signaling functions of 461 the Routing Element. Since the I2RS Agent is responsible for 462 actually making the routing changes on the associated network device, 463 it creates and maintains a log of operations that can be retrieved to 464 troubleshoot I2RS-related impact to the network. Changes that occur 465 to the network element's local configuration outside of the I2RS 466 protocol that preempt I2RS state will only be logged if the network 467 element notifies the I2RS Agent. 469 7.2. Trace Log Temporary Storage 471 The trace information may be temporarily stored either in an in- 472 memory buffer or as a file local to the Agent. Care should be given 473 to the number of I2RS operations expected on a given Agent so that 474 the appropriate storage medium is used and to maximize the 475 effectiveness of the log while not impacting the performance and 476 health of the Agent. Client requests may not always be processed 477 synchronously or within a bounded time period. Consequently, to 478 ensure that trace log fields, such as "Operation" and "Result Code", 479 are part of the same trace log record it may require buffering of the 480 trace log entries. This buffering may result in additional resource 481 load on the Agent and the network element. 483 Section 7.3 discusses rotating the trace log in order to preserve the 484 operation history without exhausting Agent or network device 485 resources. It is perfectly acceptable, therefore, to use both an in- 486 memory buffer for recent operations while rotating or archiving older 487 operations to a local file. 489 It is outside the scope of this document to specify the 490 implementation details (i.e., size, throughput, data protection, 491 etc.) for the physical storage of the I2RS log file. In terms of 492 data retention, attention should be paid the length of time I2RS 493 trace log data is kept when that data contains security or privacy- 494 sensitive attributes. The longer this data is retained, the higher 495 the impact if it were to be leaked. It is also possible that 496 legislation may impose some additional requirements on the minimum 497 and/or maximum durations for which some kinds of data may be 498 retained. 500 7.3. Trace Log Rotation 502 In order to prevent the exhaustion of resources on the I2RS Agent or 503 its associated network device, it is RECOMMENDED that the I2RS Agent 504 implements trace log rotation. The details on how this is achieved 505 are left to the implementation and outside the scope of this 506 document. However, it should be possible to do file rotation based 507 on either time or size of the current trace log. If file rollover is 508 supported, multiple archived log files should be supported in order 509 to maximize the troubleshooting and accounting benefits of the trace 510 log. 512 7.4. Trace Log Retrieval 514 Implementors are free to provide their own, proprietary interfaces 515 and develop custom tools to retrieve and display the I2RS trace log. 516 These may include the display of the I2RS trace log as Command Line 517 Interface (CLI) output. However, a key intention of defining this 518 information model is to establish a vendor-agnostic and consistent 519 interface to collect I2RS trace data. Correspondingly, retrieval of 520 the data should also be made vendor-agnostic. 522 Despite the fact that export of I2RS trace log information could be 523 an invaluable diagnostic tool for off-box analysis, exporting this 524 information MUST NOT interfere with the ability of the Agent to 525 process new incoming operations. 527 The following three sections describe potential ways the trace log 528 can be accessed. The use of I2RS Pub-Sub for accessing trace log 529 data is mandatory-to-implement, while others are optional. 531 7.4.1. Retrieval Via Syslog 533 The syslog protocol [RFC5424] is a standard way of sending event 534 notification messages from a host to a collector. However, the 535 protocol does not define any standard format for storing the 536 messages, and thus implementors of I2RS tracing would be left to 537 define their own format. So, while the data contained within the 538 syslog message would adhere to this information model, and may be 539 consumable by a human operator, it would not be easily parseable by a 540 machine. Syslog MAY be employed as a means of retrieving or 541 disseminating the I2RS trace log contents. 543 If syslog is used for trace log retrieval, then existing logging 544 infrastructure and capabilities of syslog [RFC5424] should be 545 leveraged without the need to define or extend existing formats. 546 That is, the various fields described in Section 5.2 SHOULD be 547 modeled and encoded as Structured Data Elements (referred to as "SD- 548 ELEMENT"), as described in Section 6.3.1 of [RFC5424]. 550 7.4.2. Retrieval Via I2RS Information Collection 552 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture] 553 defines a mechanism for information collection. The information 554 collected includes obtaining a snapshot of a large amount of data 555 from the network element. It is the intent of I2RS to make this data 556 available in an implementor-agnostic fashion. Therefore, the I2RS 557 trace log SHOULD be made available via the I2RS information 558 collection mechanism either as a single snapshot or via a 559 subscription stream. 561 7.4.3. Retrieval Via I2RS Pub-Sub 563 Section 7.6 of the I2RS architecture [I-D.ietf-i2rs-architecture] 564 goes on to describe notification mechanisms for a feed of changes 565 happening within the I2RS layer. Specifically, the requirements for 566 a publish-subscribe system for I2RS are defined in 567 [I-D.ietf-i2rs-pub-sub-requirements]. I2RS Agents MUST support 568 publishing I2RS trace log information to that feed as described in 569 that document. Subscribers would then receive a live stream of I2RS 570 interactions in trace log format and could flexibly choose to do a 571 number of things with the log messages. For example, the subscribers 572 could log the messages to a datastore, aggregate and summarize 573 interactions from a single Client, etc. The full range of potential 574 activites is virtually limitless and the details of how they are 575 performed are outside the scope of this document, however. 577 8. IANA Considerations 579 This document makes no request of IANA. 581 9. Security Considerations 583 The I2RS trace log, like any log file, reveals the state of the 584 entity producing it as well as the identifying information elements 585 and detailed interactions of the system containing it. The 586 information model described in this document does not itself 587 introduce any security issues, but it does define the set of 588 attributes that make up an I2RS log file. These attributes may 589 contain sensitive information and thus should adhere to the security, 590 privacy and permission policies of the organization making use of the 591 I2RS log file. 593 It is outside the scope of this document to specify how to protect 594 the stored log file, but it is expected that adequate precautions and 595 security best practices such as disk encryption, appropriately 596 restrictive file/directory permissions, suitable hardening and 597 physical security of logging entities, mutual authentication, 598 transport encryption, channel confidentiality, and channel integrity 599 if transferring log files. Additionally, the potentially sensitive 600 information contained in a log file SHOULD be adequately anonymized 601 or obfuscated by operators to ensure its privacy. 603 10. Acknowledgments 605 The authors would like to thank Alia Atlas for her initial feedback 606 and overall support for this work. Additionally, the authors 607 acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel 608 Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog 609 Lee, Sue Hares, Mach Chen, Alex Clemm, Stephen Farrell, Benoit 610 Claise, Les Ginsberg, Suresh Krishnan, and Elwyn Davies for their 611 reviews, contributed text, and suggested improvements to this 612 document. 614 11. References 615 11.1. Normative References 617 [I-D.ietf-i2rs-architecture] 618 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 619 Nadeau, "An Architecture for the Interface to the Routing 620 System", draft-ietf-i2rs-architecture-15 (work in 621 progress), April 2016. 623 [I-D.ietf-i2rs-pub-sub-requirements] 624 Voit, E., Clemm, A., and A. Prieto, "Requirements for 625 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 626 requirements-09 (work in progress), May 2016. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 634 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 635 . 637 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 638 DOI 10.17487/RFC5424, March 2009, 639 . 641 11.2. Informative References 643 [I-D.ietf-i2rs-problem-statement] 644 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 645 Routing System Problem Statement", draft-ietf-i2rs- 646 problem-statement-11 (work in progress), May 2016. 648 [I-D.ietf-i2rs-rib-info-model] 649 Bahadur, N., Kini, S., and J. Medved, "Routing Information 650 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 651 in progress), October 2015. 653 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 654 Protocol (NETCONF) Access Control Model", RFC 6536, 655 DOI 10.17487/RFC6536, March 2012, 656 . 658 Authors' Addresses 659 Joe Clarke 660 Cisco Systems, Inc. 661 7200-12 Kit Creek Road 662 Research Triangle Park, NC 27709 663 US 665 Phone: +1-919-392-2867 666 Email: jclarke@cisco.com 668 Gonzalo Salgueiro 669 Cisco Systems, Inc. 670 7200-12 Kit Creek Road 671 Research Triangle Park, NC 27709 672 US 674 Email: gsalguei@cisco.com 676 Carlos Pignataro 677 Cisco Systems, Inc. 678 7200-12 Kit Creek Road 679 Research Triangle Park, NC 27709 680 US 682 Email: cpignata@cisco.com