summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7922.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7922.txt')
-rw-r--r--doc/rfc/rfc7922.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc7922.txt b/doc/rfc/rfc7922.txt
new file mode 100644
index 0000000..6c71165
--- /dev/null
+++ b/doc/rfc/rfc7922.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Clarke
+Request for Comments: 7922 G. Salgueiro
+Category: Informational C. Pignataro
+ISSN: 2070-1721 Cisco
+ June 2016
+
+
+ Interface to the Routing System (I2RS)
+ Traceability: Framework and Information Model
+
+Abstract
+
+ This document describes a framework for traceability in the Interface
+ to the Routing System (I2RS) and the information model for that
+ framework. It specifies the motivation, requirements, and use cases,
+ and defines an information model for recording interactions between
+ elements implementing the I2RS protocol. This framework provides a
+ consistent tracing interface for components implementing the I2RS
+ architecture to record what was done, by which component, and when.
+ It aims to improve the management of I2RS implementations, and can be
+ used for troubleshooting, auditing, forensics, and accounting
+ purposes.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7922.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 1]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology and Conventions .....................................3
+ 3. Motivation ......................................................4
+ 4. Use Cases .......................................................4
+ 5. Information Model ...............................................5
+ 5.1. I2RS Traceability Framework ................................5
+ 5.2. I2RS Trace Log Fields ......................................7
+ 5.3. End of Message Marker .....................................11
+ 6. Examples .......................................................11
+ 7. Operational Guidance ...........................................11
+ 7.1. Trace Log Creation ........................................12
+ 7.2. Trace Log Temporary Storage ...............................12
+ 7.3. Trace Log Rotation ........................................13
+ 7.4. Trace Log Retrieval .......................................13
+ 7.4.1. Retrieval via Syslog ...............................14
+ 7.4.2. Retrieval via I2RS Information Collection ..........14
+ 7.4.3. Retrieval via I2RS Pub/Sub .........................14
+ 8. Security Considerations ........................................15
+ 9. References .....................................................16
+ 9.1. Normative References ......................................16
+ 9.2. Informative References ....................................16
+ Acknowledgments ...................................................17
+ Authors' Addresses ................................................17
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 2]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+1. Introduction
+
+ The architecture for the Interface to the Routing System [RFC7921]
+ specifies that I2RS clients wishing to retrieve or change the routing
+ state on a routing element MUST authenticate to an I2RS agent. The
+ I2RS client will have a unique identity it provides for
+ authentication, and should provide another opaque identity for
+ applications communicating through it. The programming of routing
+ state will produce a return code containing the results of the
+ specified operation and associated reason(s) for the result. All of
+ this is critical information to be used for understanding the history
+ of I2RS interactions.
+
+ This document defines the framework necessary to trace those
+ interactions between the I2RS client and I2RS agent. It goes on to
+ describe use cases for traceability within I2RS. Based on these use
+ cases, the document proposes an information model and reporting
+ requirements to provide for effective recording of I2RS interactions.
+ In this context, effective troubleshooting means being able to
+ identify what operation was performed by a specific I2RS client via
+ the I2RS agent, what was the result of the operation, and when that
+ operation was performed.
+
+2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ The architecture specification for I2RS [RFC7921] defines additional
+ terms used in this document that are specific to the I2RS domain,
+ such as "I2RS agent", "I2RS client", etc. The reader is expected to
+ be familiar with the terminology and concepts defined in [RFC7921].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 3]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+3. Motivation
+
+ As networks scale and policy becomes an increasingly important part
+ of the control plane that creates and maintains the forwarding state,
+ operational complexity increases as well. I2RS offers more granular
+ and coherent control over policy and control-plane state, but it also
+ removes or reduces the locality of the policy that has been applied
+ to the control plane at any individual forwarding device. The
+ ability to automate and abstract even complex policy-based controls
+ highlights the need for an equally scalable traceability function to
+ provide recording at event-level granularity of the evolution of the
+ routing system compliant with the requirements of I2RS (Section 5 of
+ [RFC7920]).
+
+4. Use Cases
+
+ An obvious motivation for I2RS traceability is the need to
+ troubleshoot and identify root causes of problems in these
+ increasingly complex routing systems. For example, since I2RS is a
+ high-throughput multi-channel, full duplex, and highly responsive
+ interface, I2RS clients may be performing a large number of
+ operations on I2RS agents concurrently or at nearly the same time and
+ quite possibly in very rapid succession. As these many changes are
+ made, the network reacts accordingly. These changes might lead to a
+ race condition, performance issues, data loss, or disruption of
+ services. In order to isolate the root cause of these issues, it is
+ critical that a network operator or administrator has visibility into
+ what changes were made via I2RS at a specific time.
+
+ Some network environments have strong auditing requirements for
+ configuration and runtime changes. Other environments have policies
+ that require saving logging information for operational or regulatory
+ compliance considerations. These requirements therefore demand that
+ I2RS provides an account of changes made to network element routing
+ systems.
+
+ As I2RS becomes increasingly pervasive in routing environments, a
+ traceability model that supports controllable trace log retention
+ using a standardized structured data format offers significant
+ advantages, such as the ability to create common tools supporting
+ automated testing, and facilitates the following use cases:
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 4]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+ o real-time monitoring and troubleshooting of router events;
+
+ o automated event correlation, trend analysis, and anomaly
+ detection;
+
+ o offline (manual or tools-based) analysis of router state evolution
+ from the retained trace logs;
+
+ o enhanced network audit, management, and forensic analysis
+ capabilities;
+
+ o improved accounting of routing system operations; and
+
+ o providing a standardized format for incident reporting and test
+ logging.
+
+5. Information Model
+
+ These sections describe the I2RS traceability information model and
+ the details about each of the fields to be logged.
+
+5.1. I2RS Traceability Framework
+
+ This section describes a framework for I2RS traceability based on the
+ I2RS Architecture.
+
+ The interaction between the optional network application that drives
+ client activity, I2RS client, I2RS agent, the Routing System, and the
+ data captured in the I2RS trace log is shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 5]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+ +---------------+
+ +----------------+ |
+ |Application | |
+ |.............. | | 0 or more Applications
+ | Application ID | +
+ +----------------+
+ ^
+ |
+ |
+ v
+ +-------------+
+ +-------------+ |
+ |I2RS Client | |
+ |.............| | 1 or more Clients
+ | Client ID | +
+ +-------------+
+ ^
+ |
+ |
+ v
+ +-------------+ +-----------------------------+
+ |I2RS Agent |---------------->|Trace Log |
+ | | |.............................|
+ +-------------+ |Log Entry [1 .. N] |
+ | ^ |.............................|
+ | | |Event ID |
+ | | |Starting Timestamp |
+ | | |Request State |
+ | | |Client ID |
+ | | |Client Priority |
+ | | |Secondary ID |
+ Operation + | | Result Code |Client Address |
+ Op Data | | |Requested Operation |
+ | | |Applied Operation |
+ | | |Operation Data Present |
+ | | |Requested Operation Data |
+ | | |Applied Operation Data |
+ | | |Transaction ID |
+ | | |Result Code |
+ | | |Ending Timestamp |
+ | | |Timeout Occurred |
+ v | |End Of Message |
+ +-------------+ +-----------------------------+
+ |Routing |
+ |System |
+ +-------------+
+
+ Figure 1: I2RS Interaction Trace Log Capture
+
+
+
+Clarke, et al. Informational [Page 6]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+5.2. I2RS Trace Log Fields
+
+ The following fields comprise an I2RS trace log. These fields ensure
+ that each I2RS interaction can be properly traced back to the client
+ that made the request at a specific point in time.
+
+ The list below describes the fields captured in the I2RS trace log.
+ This list represents a common set of fields that MUST appear in all
+ I2RS trace logs. In addition to these fields, I2RS agent
+ implementations MAY choose to log additional fields such as I2RS
+ client vendor or agent statistics like free memory, performance
+ metrics, etc.
+
+ Event ID: This is a unique identifier for each event in the I2RS
+ trace log. An event can be a client authenticating with the
+ agent, a client to agent operation, or a client disconnecting from
+ an agent. Operation events can either be logged atomically upon
+ completion (in which case they will have both a Starting and an
+ Ending Timestamp field) or they can be logged at the beginning of
+ each Request State transition. Since operations can occur from
+ the same client at the same time, it is important to have an
+ identifier that can be unambiguously associated to a specific
+ entry. If each state transition is logged for an operation, the
+ same ID MUST be used for each of the Request State log entries.
+ In this way, the life of a request can be easily followed in the
+ I2RS trace log. Beyond the requirement that the Event ID MUST be
+ unique for each event, the specific type and value is left up to
+ the implementation.
+
+ Starting Timestamp: The specific time at which the I2RS operation
+ enters the specified Request State within the agent. If the log
+ entry covers the entire duration of the request, then this will be
+ the time that it was first received by the agent. This field MUST
+ be present in all entries that specify the beginning of the state
+ transition, as well as those entries that log the entire duration
+ of the request. The time is passed in the full timestamp format
+ [RFC3339], including the date and offset from Coordinated
+ Universal Time (UTC). Given that many I2RS operations can occur
+ in rapid succession, the fractional seconds element of the
+ timestamp MUST be used to provide adequate granularity.
+ Fractional seconds SHOULD be expressed with at least three
+ significant digits in second.microsecond format.
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 7]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+ Request State: The state of the given operation within the I2RS
+ agent state machine at the specified Starting or Ending
+ Timestamps. The I2RS agent SHOULD generate a log entry at the
+ moment a request enters and exits a state. Upon entering a new
+ state, the log entry will have a Starting Timestamp set to the
+ time of entry and no Ending Timestamp. Upon exiting a state, the
+ log entry will have an Ending Timestamp set to the time of exit
+ and no Starting Timestamp. The progression of the request through
+ its various states can be linked using the Event ID. The states
+ can be one of the following values:
+
+ PENDING: The request has been received and queued for
+ processing.
+
+ IN PROCESS: The request is currently being handled by the I2RS
+ agent.
+
+ COMPLETED: The request has reached a terminal point.
+
+ Every state transition SHOULD be logged unless doing so will put
+ an undue performance burden on the I2RS agent. However, an entry
+ with the Request State set to COMPLETED MUST be logged for all
+ operations. If the COMPLETED state is the only entry for a given
+ request, then it MUST have both Starting and Ending Timestamps
+ that cover the entire duration of the request from ingress to the
+ agent until completion.
+
+ Client Identity: The I2RS client identity used to authenticate the
+ client to the I2RS agent.
+
+ Client Priority: The I2RS client priority assigned by the access
+ control model that authenticates the client. For example, this
+ can be set by the Network Configuration Protocol (NETCONF) Access
+ Control Model (NACM) as described in [RFC6536].
+
+ Secondary Identity: This is an opaque identity that may be known to
+ the client from a controlling network application. This is used
+ to trace the network application driving the actions of the
+ client. The client may not provide this identity to the agent if
+ there is no external network application driving the client.
+ However, this field MUST be logged even if the client does not
+ provide a Secondary Identity. In that case, the field will be
+ logged with an empty value.
+
+ Client Address: This is the network address of the client that
+ connected to the agent. For example, this may be an IPv4 or an
+ IPv6 address.
+
+
+
+
+Clarke, et al. Informational [Page 8]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+ Requested Operation: This is the I2RS operation that was requested
+ to be performed. For example, this may be an add route operation
+ if a route is being inserted into a routing table. This may not
+ be the operation that was actually applied to the agent.
+
+ In the case of a client authenticating to the agent, the Requested
+ Operation MUST be "CLIENT AUTHENTICATE". In the case of a client
+ disconnecting from the agent, the Requested Operation MUST be
+ "CLIENT DISCONNECT".
+
+ Applied Operation: This is the I2RS operation that was actually
+ performed. This can differ from the Requested Operation in cases
+ where the agent cannot satisfy the Requested Operation. This
+ field may not be logged unless the Request State is COMPLETED.
+
+ Operation Data Present: This is a Boolean field that indicates
+ whether or not additional per-Operation Data is present.
+
+ Requested Operation Data: This field comprises the data passed to
+ the agent to complete the desired operation. For example, if the
+ operation is a route add operation, the Operation Data would
+ include the route prefix, prefix length, and next-hop information
+ to be inserted as well as the specific routing table to which the
+ route will be added. If Operation Data is provided, then the
+ Operation Data Present field MUST be set to TRUE. Some operations
+ may not provide operation data. In those cases, the Operation
+ Data Present field MUST be set to FALSE, and this field MUST be
+ empty. This may not represent the data that was used for the
+ operation that was actually applied on the agent.
+
+ When a client authenticates to the agent, the Requested Operation
+ Data MUST contain the client priority. Other attributes such as
+ credentials used for authentication MAY be logged.
+
+ Applied Operation Data: This field comprises the data that was
+ actually applied as part of the Applied Operation. If the agent
+ cannot satisfy the Requested Operation with the Requested
+ Operation Data, then this field can differ from the Requested
+ Operation Data. This field will be empty unless the Requested
+ Operation Data was specified. This field may not be logged unless
+ the Request State is COMPLETED.
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 9]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+ Transaction ID: The Transaction Identity represents that this
+ particular operation is part of a long-running I2RS transaction
+ that can consist of multiple, related I2RS operations. Using this
+ value, one can relate multiple log entries together as they are
+ part of a single, overall I2RS operation. This is an optional
+ field that may not be logged unless the event is part of a long-
+ running transaction.
+
+ Result Code: This field holds the result of the operation once the
+ Request State is COMPLETED. In the case of Routing Information
+ Base (RIB) operations, this MUST be the return code as specified
+ in Section 4 of [RIBINFO]. The operation may not complete with a
+ result code in the case of a timeout. If the operation fails to
+ complete, it MUST still log the attempted operation with an
+ appropriate result code.
+
+ Timeout Occurred: This is a Boolean field that indicates whether or
+ not a timeout occurred in the operation. When this is true, the
+ value of the Ending Timestamp MUST be set to the time the agent
+ recorded for the timeout occurrence. This field may not be logged
+ unless the Request State is COMPLETED.
+
+ Ending Timestamp: The specific time at which the I2RS operation
+ exits the specified Request State within the I2RS agent. If the
+ log entry covers the entire duration of the request, then this
+ will be the time that the request reached a terminal point within
+ the agent. This field MUST be present in all entries that specify
+ the ending of the state transition, as well as those entries that
+ log the entire duration of the request. The time is passed in the
+ full timestamp format [RFC3339], including the date and offset
+ from Coordinated Universal Time (UTC). See the description for
+ Starting Timestamp above for the proper format of the Ending
+ Timestamp.
+
+ End Of Message: Each log entry SHOULD have an appropriate End Of
+ Message (EOM) indicator. See Section 5.3 below for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 10]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+5.3. End of Message Marker
+
+ Because of variability within I2RS trace log fields, implementors
+ MUST use a format-appropriate End Of Message (EOM) indicator in order
+ to signify the end of a particular record. That is, regardless of
+ format, the I2RS trace log MUST provide a distinct way of
+ distinguishing between the end of one record and the beginning of
+ another. For example, in a linear-formatted log (similar to a
+ syslog) the EOM marker may be a newline character. In an XML-
+ formatted log, the schema would provide for element tags that denote
+ the beginning and end of records. In a JSON-formatted log, the
+ syntax would provide record separation (likely by comma-separated
+ array elements).
+
+6. Examples
+
+ This section shows a sample of what the fields and values could look
+ like.
+
+ Event ID: 1
+ Starting Timestamp: 2013-09-03T12:00:01.21+00:00
+ Request State: COMPLETED
+ Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66
+ Client Priority: 100
+ Secondary ID: com.example.RoutingApp
+ Client Address: 2001:db8:c0c0::2
+ Requested Operation: ROUTE_ADD
+ Applied Operation: ROUTE_ADD
+ Operation Data Present: TRUE
+ Requested Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64
+ NEXT-HOP 2001:db8:cafe::1
+ Applied Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64
+ NEXT-HOP 2001:db8:cafe::1
+ Transaction ID: 2763461
+ Result Code: SUCCESS(0)
+ Timeout Occurred: FALSE
+ Ending Timestamp: 2013-09-03T12:00:01.23+00:00
+
+7. Operational Guidance
+
+ Specific operational procedures regarding temporary log storage,
+ rollover, retrieval, and access of I2RS trace logs is out of scope
+ for this document. Organizations employing I2RS trace logging are
+ responsible for establishing proper operational procedures that are
+ appropriately suited to their specific requirements and operating
+ environment. In this section, we only provide fundamental and
+ generalized operational guidelines that are implementation
+ independent.
+
+
+
+Clarke, et al. Informational [Page 11]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+7.1. Trace Log Creation
+
+ The I2RS agent interacts with the Routing and Signaling functions of
+ the Routing Element. Since the I2RS agent is responsible for
+ actually making the routing changes on the associated network device,
+ it creates and maintains a log of operations that can be retrieved to
+ troubleshoot I2RS-related impact to the network. Changes that occur
+ to the network element's local configuration outside of the I2RS
+ protocol that preempt I2RS state will only be logged if the network
+ element notifies the I2RS agent.
+
+7.2. Trace Log Temporary Storage
+
+ The trace information may be temporarily stored either in an
+ in-memory buffer or as a file local to the agent. Care should be
+ given to the number of I2RS operations expected on a given agent so
+ that the appropriate storage medium is used, and to maximize the
+ effectiveness of the log while not impacting the performance and
+ health of the agent. client requests may not always be processed
+ synchronously or within a bounded time period. Consequently, to
+ ensure that trace log fields, such as "Operation" and "Result Code",
+ are part of the same trace log record, buffering of the trace log
+ entries may be required. This buffering may result in additional
+ resource load on the agent and the network element.
+
+ Section 7.3 discusses rotating the trace log in order to preserve the
+ operation history without exhausting agent or network device
+ resources. It is perfectly acceptable, therefore, to use both an
+ in-memory buffer for recent operations while rotating or archiving
+ older operations to a local file.
+
+ It is outside the scope of this document to specify the
+ implementation details (i.e., size, throughput, data protection,
+ etc.) for the physical storage of the I2RS log file. In terms of
+ data retention, attention should be paid to the length of time that
+ the I2RS trace log data is kept when that data contains security- or
+ privacy-sensitive attributes. The longer this data is retained, the
+ higher the impact if it were to be leaked. It is also possible that
+ legislation may impose some additional requirements on the minimum
+ and/or maximum durations for which some kinds of data may be
+ retained.
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 12]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+7.3. Trace Log Rotation
+
+ In order to prevent the exhaustion of resources on the I2RS agent or
+ its associated network device, it is RECOMMENDED that the I2RS agent
+ implements trace log rotation. The details on how this is achieved
+ are left to the implementation and are outside the scope of this
+ document. However, it should be possible to do a file rotation based
+ on either the time or size of the current trace log. If file
+ rollover is supported, multiple archived log files should be
+ supported in order to maximize the troubleshooting and accounting
+ benefits of the trace log.
+
+7.4. Trace Log Retrieval
+
+ Implementors are free to provide their own, proprietary interfaces
+ and develop custom tools to retrieve and display the I2RS trace log.
+ These may include the display of the I2RS trace log as command-line
+ interface (CLI) output. However, a key intention of defining this
+ information model is to establish a vendor-agnostic and consistent
+ interface to collect I2RS trace data. Correspondingly, retrieval of
+ the data should also be made vendor-agnostic.
+
+ Despite the fact that export of I2RS trace log information could be
+ an invaluable diagnostic tool for off-box analysis, exporting this
+ information MUST NOT interfere with the ability of the agent to
+ process new incoming operations.
+
+ The following three sections describe potential ways the trace log
+ can be accessed. The use of I2RS pub/sub for accessing trace log
+ data is mandatory-to-implement, while others are optional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 13]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+7.4.1. Retrieval via Syslog
+
+ The syslog protocol [RFC5424] is a standard way of sending event
+ notification messages from a host to a collector. However, the
+ protocol does not define any standard format for storing the
+ messages, and thus implementors of I2RS tracing would be left to
+ define their own format. So, while the data contained within the
+ syslog message would adhere to this information model, and may be
+ consumable by a human operator, it would not be easily parseable by a
+ machine. Syslog MAY be employed as a means of retrieving or
+ disseminating the I2RS trace log contents.
+
+ If syslog is used for trace log retrieval, then existing logging
+ infrastructure and capabilities of syslog [RFC5424] should be
+ leveraged without the need to define or extend existing formats.
+ That is, the various fields described in Section 5.2 SHOULD be
+ modeled and encoded as Structured Data Elements (referred to as
+ "SD-ELEMENT"), as described in Section 6.3.1 of [RFC5424].
+
+7.4.2. Retrieval via I2RS Information Collection
+
+ Section 7.7 of the I2RS architecture [RFC7921] defines a mechanism
+ for information collection. The information collected includes
+ obtaining a snapshot of a large amount of data from the network
+ element. It is the intent of I2RS to make this data available in an
+ implementor-agnostic fashion. Therefore, the I2RS trace log SHOULD
+ be made available via the I2RS information collection mechanism
+ either as a single snapshot or via a subscription stream.
+
+7.4.3. Retrieval via I2RS Pub/Sub
+
+ Section 7.6 of the I2RS architecture [RFC7921] goes on to describe
+ notification mechanisms for a feed of changes happening within the
+ I2RS layer. Specifically, the requirements for a publish-subscribe
+ system for I2RS are defined in [RFC7923]. I2RS agents MUST support
+ publishing I2RS trace log information to that feed as described in
+ [RFC7923]. Subscribers would then receive a live stream of I2RS
+ interactions in trace log format and could flexibly choose to do a
+ number of things with the log messages. For example, the subscribers
+ could log the messages to a datastore, aggregate, and summarize
+ interactions from a single client, etc. The full range of potential
+ activities is virtually limitless and the details of how they are
+ performed are outside the scope of this document, however.
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 14]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+8. Security Considerations
+
+ The I2RS trace log, like any log file, reveals the state of the
+ entity producing it as well as the identifying information elements
+ and detailed interactions of the system containing it. The
+ information model described in this document does not itself
+ introduce any security issues, but it does define the set of
+ attributes that make up an I2RS log file. These attributes may
+ contain sensitive information, and thus should adhere to the
+ security, privacy, and permission policies of the organization making
+ use of the I2RS log file.
+
+ It is outside the scope of this document to specify how to protect
+ the stored log file, but it is expected that adequate precautions and
+ security best practices such as disk encryption, appropriately
+ restrictive file/directory permissions, suitable hardening and
+ physical security of logging entities, mutual authentication,
+ transport encryption, channel confidentiality, and channel integrity
+ if transferring log files. Additionally, the potentially sensitive
+ information contained in a log file SHOULD be adequately anonymized
+ or obfuscated by operators to ensure its privacy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 15]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
+ Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
+ <http://www.rfc-editor.org/info/rfc3339>.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
+ DOI 10.17487/RFC5424, March 2009,
+ <http://www.rfc-editor.org/info/rfc5424>.
+
+ [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
+ Nadeau, "An Architecture for the Interface to the Routing
+ System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
+ <http://www.rfc-editor.org/info/rfc7921>.
+
+ [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
+ for Subscription to YANG Datastores", RFC 7923,
+ DOI 10.17487/RFC7923, June 2016.
+
+9.2. Informative References
+
+ [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
+ Protocol (NETCONF) Access Control Model", RFC 6536,
+ DOI 10.17487/RFC6536, March 2012,
+ <http://www.rfc-editor.org/info/rfc6536>.
+
+ [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
+ Statement for the Interface to the Routing System",
+ RFC 7923, DOI 10.17487/RFC7923, June 2016,
+ <http://www.rfc-editor.org/info/rfc7920>.
+
+ [RIBINFO] Bahadur, N., Ed., Kini, S., Ed., and J. Medved, "Routing
+ Information Base Info Model", Work in Progress,
+ draft-ietf-i2rs-rib-info-model-08, October 2015.
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 16]
+
+RFC 7922 I2RS Traceability June 2016
+
+
+Acknowledgments
+
+ The authors would like to thank Alia Atlas for her initial feedback
+ and overall support for this work. Additionally, the authors
+ acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel
+ Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog
+ Lee, Sue Hares, Mach Chen, Alex Clemm, Stephen Farrell, Benoit
+ Claise, Les Ginsberg, Suresh Krishnan, and Elwyn Davies for their
+ reviews, contributed text, and suggested improvements to this
+ document.
+
+Authors' Addresses
+
+ Joe Clarke
+ Cisco Systems, Inc.
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+
+ Phone: +1-919-392-2867
+ Email: jclarke@cisco.com
+
+
+ Gonzalo Salgueiro
+ Cisco Systems, Inc.
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+
+ Email: gsalguei@cisco.com
+
+
+ Carlos Pignataro
+ Cisco Systems, Inc.
+ 7200-11 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+
+ Email: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+Clarke, et al. Informational [Page 17]
+