/[marcuscom]/IETF/trunk/i2rs-traceability/draft-clarke-i2rs-traceability.xml
ViewVC logotype

Annotation of /IETF/trunk/i2rs-traceability/draft-clarke-i2rs-traceability.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 18742 - (hide annotations) (download) (as text)
Tue Sep 17 22:49:07 2013 UTC (6 years, 6 months ago) by marcus
Original Path: trunk/i2rs-traceability/draft-clarke-i2rs-traceability.xml
File MIME type: text/xml
File size: 26193 byte(s)
Fix Carlos' last name.

Found by:	gsalguei

1 marcus 18717 <?xml version="1.0" encoding="US-ASCII"?>
2     <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3     <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
4     <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
5     <!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
6 marcus 18726 <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
7 marcus 18720 <!ENTITY RFC4122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4122.xml">
8     <!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
9 marcus 18717 <!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
10 marcus 18730 <!ENTITY RFC5737 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5737.xml">
11 marcus 18718 <!ENTITY I2RS-ARCHITECTURE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
12 marcus 18726 <!ENTITY I2RS-PROBLEM-STATEMENT SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
13 marcus 18717 <!ENTITY I2RS-RIB-INFO-MODEL SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nitinb-i2rs-rib-info-model.xml">
14 marcus 18740 <!ENTITY I2RS-PUBSUB-SEC SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.camwinget-i2rs-pubsub-sec.xml">
15 marcus 18717 ]>
16     <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
17     <?rfc toc="yes"?>
18 marcus 18725 <?rfc tocompact="yes"?>
19 marcus 18717 <?rfc tocdepth="4"?>
20 marcus 18725 <?rfc tocindent="yes"?>
21 marcus 18717 <?rfc symrefs="yes"?>
22 marcus 18725 <?rfc sortrefs="yes"?>
23     <?rfc comments="yes"?>
24     <?rfc inline="yes"?>
25     <?rfc compact="yes"?>
26     <?rfc subcompact="no"?>
27 marcus 18717 <rfc category="info" docName="draft-clarke-i2rs-traceability-00" ipr="trust200902">
28     <front>
29 marcus 18740 <title abbrev="I2RS Traceability">
30     Traceability in the Interface to the Routing System (I2RS)</title>
31 marcus 18717 <author fullname="Joe Clarke" initials="J." surname="Clarke">
32 marcus 18718 <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
33 marcus 18717 <address>
34     <postal>
35     <street>7200-12 Kit Creek Road</street>
36     <city>Research Triangle Park</city>
37     <region>NC</region>
38     <code>27709</code>
39     <country>US</country>
40     </postal>
41     <phone>+1-919-392-2867</phone>
42     <email>jclarke@cisco.com</email>
43     </address>
44     </author>
45 marcus 18725 <author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
46 marcus 18740 <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
47 marcus 18725 <address>
48     <postal>
49     <street>7200-12 Kit Creek Road</street>
50     <city>Research Triangle Park</city>
51     <region>NC</region>
52     <code>27709</code>
53     <country>US</country>
54     </postal>
55     <email>gsalguei@cisco.com</email>
56     </address>
57     </author>
58 marcus 18742 <author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
59 marcus 18740 <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
60     <address>
61     <postal>
62     <street>7200-12 Kit Creek Road</street>
63     <city>Research Triangle Park</city>
64     <region>NC</region>
65     <code>27709</code>
66     <country>US</country>
67     </postal>
68     <email>cpignata@cisco.com</email>
69     </address>
70     </author>
71 marcus 18718 <date/>
72 marcus 18717 <area>Routing</area>
73     <workgroup>I2RS</workgroup>
74     <keyword>I2RS</keyword>
75 marcus 18725 <keyword>I2RS Traceability</keyword>
76 marcus 18717 <keyword>Traceability</keyword>
77     <abstract>
78 marcus 18740 <t>This document describes a framework for traceability in the
79     Interface to the Routing System (I2RS). It specifies the motivation,
80     requirements, use cases, and defines an information model for
81     recording interactions between elements implementing the I2RS
82 marcus 18725 protocol. This framework provides a consistent tracing interface
83 marcus 18740 for components implementing the I2RS architecture to
84     record what was done, by which component, and when. It aims to
85 marcus 18725 improve the management of I2RS implementations, and can be used
86     for troubleshooting, auditing, forensics, and accounting
87     purposes.</t>
88 marcus 18717 </abstract>
89     </front>
90     <middle>
91 marcus 18725 <section anchor="intro" title="Introduction">
92 marcus 18717 <t>The architecture for the Interface to the Routing System
93 marcus 18725 (<xref target="I-D.ietf-i2rs-architecture"/>) specifies that
94     I2RS Clients wishing to retrieve or change routing state on a
95 marcus 18740 routing element MUST authenticate to an I2RS Agent. The I2RS
96 marcus 18725 Client will have a unique identity it provides for
97     authentication, and should provide another, opaque identifier
98 marcus 18740 for applications (or actors) communicating through it. The programming of
99     routing state will produce in a return code containing the results of
100     the specified operation and associated reason(s) for the result.
101     All of this is critical information to be used for understanding the
102     history of I2RS interactions.</t>
103     <t>This document specifies requirements, use cases, and describes the
104 marcus 18725 information model for traceability attributes that must be
105     collected and logged by I2RS Agents in order to effectively
106 marcus 18740 record I2RS interactions. In this context, effective
107 marcus 18725 troubleshooting means being able to identify what operation was
108     performed by a specific I2RS Client, what was the result of the
109     operation, and when that operation was performed.</t>
110 marcus 18740 <t>
111     Discussions about the retention of the data logged as part of I2RS
112     traceability, while important, are outside of the scope of this document.
113     </t>
114 marcus 18717 </section>
115 marcus 18725 <section anchor="terminology" title="Terminology">
116     <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
117     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
118     "OPTIONAL" in this document are to be interpreted as described
119     in <xref target="RFC2119"/>.</t>
120     <t>The architecture specification for I2RS <xref target="I-D.ietf-i2rs-architecture"/> defines additional terms
121     used in this document that are specific to the I2RS domain, such
122     as "I2RS Agent", "I2RS Client", etc. The reader is expected to
123     be familiar with the terminology and concepts defined in <xref target="I-D.ietf-i2rs-architecture"/>.</t>
124 marcus 18718 </section>
125 marcus 18725 <section anchor="motivation" title="Motivation and Use Cases">
126     <t>As networks grow, so too does the scale and complexity of
127     routing systems. I2RS offers a standard, programmatic interface
128     allowing improved automation and more granular control over an
129     increasingly dynamic routing and signaling state. This ability
130     to automate even complex policy-based controls highlights the
131     need for an equally scalable traceability function to provide
132     event-level granularity of the routing system compliant with the
133 marcus 18740 requirements of I2RS (Section 5 of <xref target="I-D.ietf-i2rs-problem-statement"/>).</t>
134 marcus 18725 <t>An obvious motivation for I2RS traceability is the need to
135 marcus 18740 troubleshoot and identify root-causes of problems in these increasingly
136     complex routing systems. For
137 marcus 18725 example, since I2RS is a high-throughput multi-channel, full
138     duplex and highly responsive interface, I2RS Clients may be
139     performing a large number of operations on I2RS Agents
140     concurrently or at nearly the same time and quite possibly in
141     very rapid succession. As these many changes are made, the
142     network reacts accordingly. These changes might lead to a race
143     condition, performance issues, data loss, or disruption of
144     services. In order to isolate the root cause of these issues it
145     is critical that a network operator or administrator has
146     visibility into what changes were made via I2RS at a specific
147     time.</t>
148 marcus 18740 <!--
149     JC: What is the action in this paragraph? Is this attempting to limit
150     scope. I agree the regulatory compliance may apply some stricter
151     requirements on audting and logs. Are we going to say that such
152     requirements are beyond the scope of this doc?
153     <t>
154     Some routing environments have more stringent traceability requirements
155     due to business or regulatory compliance policies, or simply as an incident or outage
156     root causing analysis policy.
157     </t>
158     -->
159     <t>As I2RS becomes increasingly pervasive in routing environments, a
160 marcus 18725 traceability model offers significant advantages and facilitates
161     the following use cases:</t>
162     <t>
163     <list style="symbols">
164     <t>Automated event correlation, trend analysis, and anomaly
165     detection.</t>
166     <t>Trace log storage for offline (manual or tools)
167     analysis.</t>
168     <t>Improved accounting of routing system transactions.</t>
169     <t>Standardized structured data format for writing common
170     tools.</t>
171     <t>Common reference for automated testing and incident
172     reporting.</t>
173     <t>Real-time monitoring and troubleshooting.</t>
174     <t>Enhanced network audit, management and forensic analysis
175     capabilities.</t>
176     </list>
177     </t>
178     </section>
179     <section anchor="information_model" title="Information Model">
180 marcus 18740 <section anchor="info_framework" title="I2RS Traceability Framework">
181     <t>This section describes a framework for I2RS traceability
182     based on the I2RS Architecture. Some notable elements on the
183     architecture are highlighted herein.</t>
184 marcus 18725 <t>The interaction between the optional northbound actor, I2RS
185     Client, I2RS Agent, the Routing System and the data captured
186 marcus 18732 in the I2RS trace log is shown in <xref target="i2rs_interaction_trace"/>.<vspace blankLines="30"/></t>
187 marcus 18719 <figure align="center" anchor="i2rs_interaction_trace" title="I2RS Interaction Trace Log Capture">
188 marcus 18725 <artwork align="center"><![CDATA[
189 marcus 18718 +-------------+
190     |Actor |
191     |.............|
192     | Actor ID |
193     +-------------+
194 marcus 18727 ^
195 marcus 18719 :
196     :
197 marcus 18718 V
198     +-------------+
199     |I2RS Client |
200     |.............|
201     | Client ID |
202     +-------------+
203 marcus 18727 ^
204 marcus 18718 |
205     |
206     V
207     +-------------+ +-----------------------------+
208     |I2RS Agent |---------------->|Trace Log |
209     | | |.............................|
210     +-------------+ |Timestamp |
211     ^ |Client ID |
212 marcus 18727 | ^ |Actor ID |
213 marcus 18719 Operation + | Result Code |Client Address |
214 marcus 18727 Op Data | |Operation |
215 marcus 18719 V | |Operation Data |
216     V |Result Code |
217     +-------------+ +-----------------------------+
218     |Routing |
219 marcus 18718 |System |
220     +-------------+
221 marcus 18725 ]]></artwork>
222 marcus 18718 </figure>
223 marcus 18740 </section>
224     <section anchor="info_required" title="I2RS Trace Log Mandatory Fields">
225     <t>In order to ensure that each I2RS interaction can be
226     properly traced back to the Client that made the request at a
227     specific point in time, the following information MUST be
228     collected and stored by the Agent.</t>
229 marcus 18725 <t>The list below describes the fields captured in the I2RS
230     trace log.</t>
231 marcus 18718 <t>
232     <list style="hanging">
233     <t hangText="Timestamp: ">The specific time, adhering to
234 marcus 18725 <xref target="RFC3339"/> format, at which the I2RS
235     transaction occurred. Given that many I2RS transactions
236     can occur in rapid succession, the use of fractional
237     seconds MUST be used to provide adequate granularity.</t>
238     <t hangText="Client Identifier: ">The I2RS Client
239     identifier used to authenticate the Client to the I2RS
240     Agent.</t>
241 marcus 18732 <t hangText="Actor Identifier: ">This is an opaque
242     identifier that may be known to the Client from a
243     northbound controlling application. This is used to trace
244     the northbound actor driving the actions of the Client.
245 marcus 18733 The Client may not provide this identifier to the Agent if
246 marcus 18732 there is no external actor driving the Client. However,
247     this field MUST be logged. If the Client does not provide
248     an actor ID, then the Agent MUST log an empty field.</t>
249 marcus 18725 <t hangText="Client Address: ">This is the network address
250     of the client that connected to the Agent. For example,
251 marcus 18732 this may be an IPv4 or IPv6 address. [Note: will I2RS
252     support interactions that have no network address? If so
253     this field will need to be updated.]</t>
254 marcus 18725 <t hangText="Operation: ">This is the I2RS operation
255     performed. For example, this may be an add route operation
256     if a route is being inserted into a routing table.</t>
257     <t hangText="Operation Data: ">This field comprises the
258     data passed to the Agent to complete the desired
259     operation. For example, if the operation is a route add
260     operation, the Operation Data would include the route
261     prefix, prefix length, and next hop information to be
262     inserted as well as the specific routing table to which
263     the route will be added. The operation data can also
264 marcus 18732 include interface information. Some operations MAY not
265     provide operation data, and in those cases this field MUST
266 marcus 18740 be logged as a NULL string.</t>
267 marcus 18725 <t hangText="Result Code: ">This field holds the result of
268     the operation. In the case of RIB operations, this MUST be
269 marcus 18732 the return code as specified in Section 4 of <xref target="I-D.nitinb-i2rs-rib-info-model"/>. The operation
270     may not complete with a result code in the case of a
271     timeout. If the operation fails to complete, it MUST still
272     log the attempted operation with an appropriate result
273     code (e.g., a result code indicating a timeout).</t>
274 marcus 18718 </list>
275     </t>
276 marcus 18725 </section>
277     <section anchor="info_optional" title="I2RS Trace Log Extensibility and Optional Fields">
278 marcus 18732 <t/>
279     <t>[NOTE: This section is TBD based on further development of
280     I2RS WG milestones.]</t>
281 marcus 18738 <t/>
282 marcus 18725 </section>
283     <section anchor="syntax" title="I2RS Trace Log Syntax">
284     <t>The following describes the trace log information model
285     using Augmented Backus-Naur Form (ABNF) syntax <xref target="RFC5234"/>:</t>
286     <figure>
287 marcus 18727 <artwork type="abnf"><![CDATA[i2rs-trace-log = timestamp client-id actor-id client-addr operation
288     operation-data result-code
289 marcus 18721 client-id = uuid
290     actor-id = byte-string
291 marcus 18727 byte-string = *( %x01-09 / %x0B-0C / %x0E-FF )
292 marcus 18725 ; any byte except NUL, CR or LF
293 marcus 18721 client-addr = IP-literal / IPv4address
294     operation = ALPHA *( ALPHA / "_" / "-" / "(" / ")" )
295     operation-data = *VCHAR
296 marcus 18725 result-code = 1*( ALPHA / DIGIT / "-" / "_" / "(" / ")" ) ]]></artwork>
297     </figure>
298     <t>The ABNF syntax rules &lt;IP-literal&gt;,
299     &lt;IPv4address&gt;, and &lt;sub-delims&gt; are specified in
300     <xref target="RFC3986"/>. The core rules &lt;DIGIT&gt;,
301 marcus 18738 &lt;ALPHA&gt; and &lt;VCHAR&gt; are used as described in
302     Appendix B of <xref target="RFC5234"/>.</t>
303 marcus 18725 <t>Here, &lt;uuid&gt; is specified in <xref target="RFC4122"/>. The idea of using a UUID for the Client
304 marcus 18732 identifier ensures the ID is unique not just in the scope of
305     the current I2RS Agent, but across Agents as well. This
306     ensures that two clients that are unaware of each other will
307     not allocate the same Client ID. That does not preclude two
308     Clients acting as one for purposes of high availability from
309     sharing the same UUID as generated by one one of the Clients.
310     [Note: the format of the Client ID has not yet been decided by
311     the I2RS WG. This is subject to change.]</t>
312 marcus 18725 <t>The &lt;timestamp&gt; field is defined in <xref target="RFC3339"/>. As stated in <xref target="info_required"/> the fractional second format MUST be
313     used to provide proper granularity.</t>
314     <t>The values for &lt;operation&gt;, &lt;operation-data&gt;
315     and &lt;result-code&gt; are suggestions as the protocol has
316     not been defined yet. By making these human-readable (as
317     opposed to opcodes) the log becomes more easily consumable by
318     operators and administrators trying to troubleshoot issues
319     relating to I2RS. Even in cases where the operations or codes
320     might appear as opcodes on the wire, their textual
321     translations MUST be included in the log. The opcodes
322     themselves MAY appear in parentheses after the textual
323     representation.</t>
324 marcus 18718 </section>
325 marcus 18725 </section>
326     <section title="Examples">
327 marcus 18731 <t>Here is a proposed sample of what the fields might look like
328 marcus 18732 in an I2RS trace log. This is only an early proposal. These
329     values are subject to change.</t>
330 marcus 18731 <figure>
331     <artwork><![CDATA[
332 marcus 18730 Timestamp: 2013-09-03T12:00:01.21+00:00
333     Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66
334     Actor ID: com.example.RoutingApp
335     Client Address: 192.0.2.2
336     Operation: ROUTE_ADD
337     Operation Data: PREFIX 203.0.113.0 PREFIX-LEN 24 NEXT-HOP
338     198.51.100.1
339     Result Code: SUCCESS(0)
340 marcus 18731 ]]></artwork>
341     </figure>
342 marcus 18740 <!--
343     Why do you need this?
344 marcus 18732 <t>The IP addresses used in the examples in this document
345     correspond to the documentation address blocks 192.0.2.0/24
346     (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24
347     (TEST-NET-3) as described in <xref target="RFC5737"/>.</t>
348 marcus 18740 -->
349 marcus 18725 </section>
350     <section anchor="operational_guidance" title="Operational Guidance">
351     <t/>
352 marcus 18740 <t>Specific operational procedures regarding temporary log storage,
353 marcus 18732 rollover, retrieval, and access of I2RS trace logs is out of
354     scope for this document. Organizations employing I2RS trace
355     logging are responsible for establishing proper operational
356     procedures that are appropriately suited to their specific
357     requirements and operating environment. In this section we only
358     provide fundamental and generalized operational guidelines that
359     are implementation-independent.</t>
360 marcus 18725 <t/>
361     <section anchor="responsibilities" title="Trace Log Creation">
362     <t>The I2RS Agent interacts with the Routing and Signaling
363     functions of the Routing Element. Since the I2RS Agent is
364     responsible for actually making the routing changes on the
365     associated network device, it creates and maintains a log of
366     transactions that can be retrieved to troubleshoot
367     I2RS-related impact to the network.</t>
368 marcus 18717 </section>
369 marcus 18740 <section anchor="trace_storage" title="Trace Log Temporary Storage">
370     <t>The trace information may be temporarily stored either in an
371     in-memory buffer or as a file local to the Agent. Care should be given
372 marcus 18732 to the number of I2RS transactions expected on a given agent
373     so that the appropriate storage medium is used and to maximize
374     the effectiveness of the log while not impacting the
375     performance and health of the Agent. <xref target="log_rotation"/> talks about rotating the trace log in
376     order to preserve the transaction history without exhausting
377     Agent or network device resources. It is perfectly acceptable,
378     therefore, to use both an in-memory buffer for recent
379     transactions while rotating or archiving older transactions to
380     a local file.</t>
381     <t>It is outside the scope of this document to specify the
382     implementation details (i.e., size, throughput, data
383     protection, privacy, etc.) for the physical storage of the
384 marcus 18740 I2RS log file. Data retention policies of the I2RS traceability
385     log is also outside the scope of this document.</t>
386 marcus 18732 </section>
387 marcus 18725 <section anchor="log_rotation" title="Trace Log Rotation">
388     <t>In order to prevent the exhaustion of resources on the I2RS
389     Agent or its associated network device, the I2RS trace log
390     implementation MAY choose to implement a configurable rotation
391 marcus 18732 schedule. It SHOULD be possible to do file rotation based on
392     either time or size of the current trace log. If file rollover
393     is supported, multiple archived log files SHOULD be supported
394     in order to maximize the troubleshooting and accounting
395     benefits of the trace log.</t>
396 marcus 18717 </section>
397 marcus 18725 <section anchor="log_retrieval" title="Trace Log Retrieval">
398     <t>Implementors are free to provide their own, proprietary
399 marcus 18732 interfaces and develop custom tools to retrieve and display
400     the I2RS trace log. These may include the display of the I2RS
401     trace log as Command Line Interface (CLI) output. However, a
402     key intention of defining this information model is to
403     establish an implementor-agnostic and consistent interface to
404     collect I2RS trace data. Correspondingly, retrieval of the
405     data should also be made implementor-agnostic.</t>
406 marcus 18738 <t>The following three sections describe potential ways the
407     trace log can be accessed. At least one of these three MUST be
408     used, with the I2RS mechanisms being preferred as they are
409     implementor-independent approaches to retrieving the data.</t>
410 marcus 18725 <section anchor="trace_syslog" title="Retrieval Via Syslog">
411     <t>The syslog protocol <xref target="RFC5424"/> is a
412 marcus 18732 standard way of sending event notification messages from a
413 marcus 18725 host to a collector. However, the protocol does not define
414     any standard format for storing the messages, and thus
415     implementors of I2RS tracing would be left to define their
416     own format. So, while the data contained within the syslog
417     message would adhere to this information model, and may be
418     consumable by a human operator, it would not be easily
419     parseable by a machine. Therefore, syslog MAY be employed as
420     a means of retrieving or disseminating the I2RS trace log
421     contents.</t>
422     </section>
423 marcus 18737 <section anchor="i2rs_info_retrieval" title="Retrieval Via I2RS Information Collection">
424 marcus 18725 <t>Section 6.7 of the I2RS architecture <xref target="I-D.ietf-i2rs-architecture"/> defines a mechanism
425     for information collection. The information collected
426     includes obtaining a snapshot of a large amount of data from
427     the network element. It is the intent of I2RS to make this
428     data available in an implementor-agnostic fashion.
429     Therefore, the I2RS trace log SHOULD be made available via
430     the I2RS information collection mechanism either as a single
431     snapshot or via a subscription stream.</t>
432     </section>
433 marcus 18735 <section anchor="pub_sub_retrieval" title="Retrieval Via I2RS Pub-Sub">
434 marcus 18738 <t>Section 6.7 of the I2RS architecture <xref target="I-D.ietf-i2rs-architecture"/> goes on to define a
435     publish-subscribe mechanism for a feed of changes happening
436     within the I2RS layer. I2RS Agents SHOULD support publishing
437     I2RS trace log information to that feed as described in that
438     document. Subscribers would then receive a live stream of
439     I2RS interactions in trace log format and could flexibly
440     choose to do a number of things with the log messages. For
441     example, the subscribers could log the messages to a
442     datastore, aggregate and summarize interactions from a
443 marcus 18740 single client, etc. Using pub-sub for the purpose
444     of logging I2RS interactions augments the areas described
445     by <xref target="I-D.camwinget-i2rs-pubsub-sec"/>.
446     The full range of potential activites is
447 marcus 18738 virtually limitless and the details of how they are
448     performed are outside the scope of this document,
449     however.</t>
450 marcus 18735 </section>
451 marcus 18725 </section>
452 marcus 18717 </section>
453     <section anchor="IANA" title="IANA Considerations">
454 marcus 18725 <t>This document makes no request of IANA.</t>
455 marcus 18717 </section>
456     <section anchor="Security" title="Security Considerations">
457 marcus 18732 <t>The I2RS trace log, like any log file, reveals the state of
458     the entity producing it as well as the identifying information
459     elements and detailed interactions of the system containing it.
460     The information model described in this document does not itself
461     introduce any security issues, but it does define the set of
462     attributes that make up an I2RS log file. These attributes may
463     contain sensitive information and thus should adhere to the
464     security, privacy and permission policies of the organization
465 marcus 18738 making use of the I2RS log file.</t>
466 marcus 18732 <t>It is outside the scope of this document to specify how to
467     protect the stored log file, but it is expected that adequate
468     precautions and security best practices such as disk encryption,
469     appropriately restrictive file/directory permissions, suitable
470     hardening and physical security of logging entities, mutual
471     authentication, transport encryption, channel confidentiality,
472     and channel integrity if transferring log files. Additionally,
473     the potentially sensitive information contained in a log file
474     SHOULD be adequately anonymized or obfuscated by operators to
475     ensure its privacy.</t>
476 marcus 18717 </section>
477     </middle>
478     <back>
479     <references title="Normative References">
480 marcus 18732 &RFC2119;
481    
482     &I2RS-ARCHITECTURE;
483    
484     &I2RS-PROBLEM-STATEMENT;
485    
486     &RFC3986;
487    
488     &RFC4122;
489    
490     &RFC5234;
491 marcus 18717 </references>
492     <references title="Informative References">
493 marcus 18732 &I2RS-RIB-INFO-MODEL;
494    
495     &RFC3339;
496    
497     &RFC5424;
498    
499 marcus 18740 &I2RS-PUBSUB-SEC;
500    
501     <!--
502 marcus 18732 &RFC5737;
503 marcus 18740 -->
504 marcus 18717 </references>
505     </back>
506     </rfc>

  ViewVC Help
Powered by ViewVC 1.1.27