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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 18755 - (hide annotations) (download)
Sat Sep 28 23:57:38 2013 UTC (6 years, 6 months ago) by marcus
File MIME type: text/plain
File size: 26709 byte(s)
Regenerate text.

1 marcus 18717
2    
3    
4 marcus 18729
5 marcus 18717 I2RS J. Clarke
6 marcus 18726 Internet-Draft G. Salgueiro
7 marcus 18746 Intended status: Informational C. Pignataro
8 marcus 18755 Expires: April 01, 2014 Cisco
9     September 28, 2013
10 marcus 18717
11    
12 marcus 18746 Interface to the Routing System (I2RS) Traceability: Framework and
13     Information Model
14 marcus 18717 draft-clarke-i2rs-traceability-00
15    
16     Abstract
17    
18 marcus 18741 This document describes a framework for traceability in the Interface
19 marcus 18746 to the Routing System (I2RS) and information model for that
20     framework. It specifies the motivation, requirements, use cases, and
21     defines an information model for recording interactions between
22     elements implementing the I2RS protocol. This framework provides a
23     consistent tracing interface for components implementing the I2RS
24     architecture to record what was done, by which component, and when.
25     It aims to improve the management of I2RS implementations, and can be
26     used for troubleshooting, auditing, forensics, and accounting
27     purposes.
28 marcus 18717
29 marcus 18729 Status of This Memo
30 marcus 18717
31     This Internet-Draft is submitted in full conformance with the
32     provisions of BCP 78 and BCP 79.
33    
34     Internet-Drafts are working documents of the Internet Engineering
35     Task Force (IETF). Note that other groups may also distribute
36     working documents as Internet-Drafts. The list of current Internet-
37     Drafts is at http://datatracker.ietf.org/drafts/current/.
38    
39     Internet-Drafts are draft documents valid for a maximum of six months
40     and may be updated, replaced, or obsoleted by other documents at any
41     time. It is inappropriate to use Internet-Drafts as reference
42     material or to cite them other than as "work in progress."
43    
44 marcus 18755 This Internet-Draft will expire on April 01, 2014.
45 marcus 18717
46     Copyright Notice
47    
48     Copyright (c) 2013 IETF Trust and the persons identified as the
49     document authors. All rights reserved.
50    
51     This document is subject to BCP 78 and the IETF Trust's Legal
52     Provisions Relating to IETF Documents
53    
54    
55    
56 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 1]
57 marcus 18717
58 marcus 18726 Internet-Draft I2RS Traceability September 2013
59 marcus 18717
60    
61 marcus 18746 (http://trustee.ietf.org/license-info) in effect on the date of
62     publication of this document. Please review these documents
63 marcus 18741 carefully, as they describe your rights and restrictions with respect
64 marcus 18726 to this document. Code Components extracted from this document must
65     include Simplified BSD License text as described in Section 4.e of
66 marcus 18718 the Trust Legal Provisions and are provided without warranty as
67     described in the Simplified BSD License.
68    
69 marcus 18717 Table of Contents
70    
71 marcus 18729 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
72 marcus 18746 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
73 marcus 18729 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 3
74     4. Information Model . . . . . . . . . . . . . . . . . . . . . . 4
75 marcus 18741 4.1. I2RS Traceability Framework . . . . . . . . . . . . . . . 4
76     4.2. I2RS Trace Log Mandatory Fields . . . . . . . . . . . . . 5
77     4.3. I2RS Trace Log Extensibility and Optional Fields . . . . 6
78     4.4. I2RS Trace Log Syntax . . . . . . . . . . . . . . . . . . 6
79 marcus 18729 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
80 marcus 18734 6. Operational Guidance . . . . . . . . . . . . . . . . . . . . 8
81     6.1. Trace Log Creation . . . . . . . . . . . . . . . . . . . 8
82 marcus 18741 6.2. Trace Log Temporary Storage . . . . . . . . . . . . . . . 8
83 marcus 18747 6.3. Trace Log Rotation . . . . . . . . . . . . . . . . . . . 9
84 marcus 18734 6.4. Trace Log Retrieval . . . . . . . . . . . . . . . . . . . 9
85     6.4.1. Retrieval Via Syslog . . . . . . . . . . . . . . . . 9
86 marcus 18737 6.4.2. Retrieval Via I2RS Information Collection . . . . . . 9
87 marcus 18747 6.4.3. Retrieval Via I2RS Pub-Sub . . . . . . . . . . . . . 10
88 marcus 18735 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
89 marcus 18734 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
90 marcus 18741 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
91     9.1. Normative References . . . . . . . . . . . . . . . . . . 10
92     9.2. Informative References . . . . . . . . . . . . . . . . . 11
93 marcus 18734 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
94 marcus 18717
95     1. Introduction
96    
97     The architecture for the Interface to the Routing System
98 marcus 18726 ([I-D.ietf-i2rs-architecture]) specifies that I2RS Clients wishing to
99 marcus 18741 retrieve or change routing state on a routing element MUST
100 marcus 18726 authenticate to an I2RS Agent. The I2RS Client will have a unique
101 marcus 18718 identity it provides for authentication, and should provide another,
102 marcus 18741 opaque identifier for applications (or actors) communicating through
103     it. The programming of routing state will produce in a return code
104     containing the results of the specified operation and associated
105     reason(s) for the result. All of this is critical information to be
106     used for understanding the history of I2RS interactions.
107 marcus 18717
108 marcus 18735
109    
110    
111 marcus 18746
112 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 2]
113 marcus 18735
114     Internet-Draft I2RS Traceability September 2013
115    
116    
117 marcus 18746 This document specifies requirements, use cases, and describes the
118     information model for traceability attributes that must be collected
119     and logged by I2RS Agents in order to effectively record I2RS
120 marcus 18718 interactions. In this context, effective troubleshooting means being
121     able to identify what operation was performed by a specific I2RS
122     Client, what was the result of the operation, and when that operation
123 marcus 18717 was performed.
124    
125 marcus 18741 Discussions about the retention of the data logged as part of I2RS
126     traceability, while important, are outside of the scope of this
127     document.
128    
129 marcus 18746 2. Terminology and Conventions
130 marcus 18726
131 marcus 18717 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133     document are to be interpreted as described in [RFC2119].
134    
135 marcus 18726 The architecture specification for I2RS [I-D.ietf-i2rs-architecture]
136     defines additional terms used in this document that are specific to
137     the I2RS domain, such as "I2RS Agent", "I2RS Client", etc. The
138     reader is expected to be familiar with the terminology and concepts
139     defined in [I-D.ietf-i2rs-architecture].
140 marcus 18717
141 marcus 18746 The IP addresses used in the example in this document correspond to
142     the documentation address blocks 192.0.2.0/24 (TEST-NET-1),
143     198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24 (TEST-NET-3) as
144     described in [RFC5737].
145    
146 marcus 18726 3. Motivation and Use Cases
147 marcus 18717
148 marcus 18726 As networks grow, so too does the scale and complexity of routing
149     systems. I2RS offers a standard, programmatic interface allowing
150     improved automation and more granular control over an increasingly
151     dynamic routing and signaling state. This ability to automate even
152     complex policy-based controls highlights the need for an equally
153     scalable traceability function to provide event-level granularity of
154     the routing system compliant with the requirements of I2RS (Section 5
155 marcus 18741 of [I-D.ietf-i2rs-problem-statement]).
156 marcus 18717
157 marcus 18726 An obvious motivation for I2RS traceability is the need to
158 marcus 18741 troubleshoot and identify root-causes of problems in these
159     increasingly complex routing systems. For example, since I2RS is a
160     high-throughput multi-channel, full duplex and highly responsive
161     interface, I2RS Clients may be performing a large number of
162     operations on I2RS Agents concurrently or at nearly the same time and
163     quite possibly in very rapid succession. As these many changes are
164     made, the network reacts accordingly. These changes might lead to a
165 marcus 18746
166    
167    
168 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 3]
169 marcus 18746
170     Internet-Draft I2RS Traceability September 2013
171    
172    
173 marcus 18741 race condition, performance issues, data loss, or disruption of
174     services. In order to isolate the root cause of these issues it is
175     critical that a network operator or administrator has visibility into
176     what changes were made via I2RS at a specific time.
177 marcus 18718
178 marcus 18749 Some network environments have strong auditing requirements for
179     configuration and runtime changes. Other environments have internal
180     policies to save logging information for operational considerations.
181     These requirements therefore demand that I2RS provides an account of
182     changes made to network element routing systems.
183    
184 marcus 18741 As I2RS becomes increasingly pervasive in routing environments, a
185     traceability model offers significant advantages and facilitates the
186     following use cases:
187 marcus 18718
188 marcus 18726 o Automated event correlation, trend analysis, and anomaly
189     detection.
190 marcus 18718
191 marcus 18726 o Trace log storage for offline (manual or tools) analysis.
192 marcus 18718
193 marcus 18726 o Improved accounting of routing system transactions.
194 marcus 18718
195 marcus 18726 o Standardized structured data format for writing common tools.
196    
197     o Common reference for automated testing and incident reporting.
198    
199     o Real-time monitoring and troubleshooting.
200    
201     o Enhanced network audit, management and forensic analysis
202     capabilities.
203    
204     4. Information Model
205    
206 marcus 18741 4.1. I2RS Traceability Framework
207 marcus 18726
208 marcus 18741 This section describes a framework for I2RS traceability based on the
209     I2RS Architecture. Some notable elements on the architecture are
210     highlighted herein.
211 marcus 18717
212 marcus 18718 The interaction between the optional northbound actor, I2RS Client,
213     I2RS Agent, the Routing System and the data captured in the I2RS
214     trace log is shown in Figure 1.
215 marcus 18717
216 marcus 18734
217    
218    
219    
220    
221    
222    
223    
224 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 4]
225 marcus 18734
226     Internet-Draft I2RS Traceability September 2013
227    
228    
229 marcus 18718 +-------------+
230     |Actor |
231     |.............|
232     | Actor ID |
233     +-------------+
234 marcus 18727 ^
235 marcus 18720 :
236     :
237 marcus 18718 V
238     +-------------+
239     |I2RS Client |
240     |.............|
241     | Client ID |
242     +-------------+
243 marcus 18727 ^
244 marcus 18718 |
245     |
246     V
247     +-------------+ +-----------------------------+
248     |I2RS Agent |---------------->|Trace Log |
249     | | |.............................|
250     +-------------+ |Timestamp |
251     ^ |Client ID |
252 marcus 18727 | ^ |Actor ID |
253 marcus 18720 Operation + | Result Code |Client Address |
254 marcus 18727 Op Data | |Operation |
255 marcus 18720 V | |Operation Data |
256     V |Result Code |
257     +-------------+ +-----------------------------+
258     |Routing |
259 marcus 18718 |System |
260     +-------------+
261 marcus 18717
262 marcus 18718 Figure 1: I2RS Interaction Trace Log Capture
263 marcus 18717
264 marcus 18741 4.2. I2RS Trace Log Mandatory Fields
265    
266     In order to ensure that each I2RS interaction can be properly traced
267     back to the Client that made the request at a specific point in time,
268     the following information MUST be collected and stored by the Agent.
269    
270 marcus 18718 The list below describes the fields captured in the I2RS trace log.
271 marcus 18717
272     Timestamp: The specific time, adhering to [RFC3339] format, at
273 marcus 18718 which the I2RS transaction occurred. Given that many I2RS
274     transactions can occur in rapid succession, the use of fractional
275     seconds MUST be used to provide adequate granularity.
276 marcus 18717
277    
278 marcus 18734
279    
280 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 5]
281 marcus 18734
282     Internet-Draft I2RS Traceability September 2013
283    
284    
285 marcus 18741 Client Identifier: The I2RS Client identifier used to authenticate
286     the Client to the I2RS Agent.
287    
288     Actor Identifier: This is an opaque identifier that may be known to
289     the Client from a northbound controlling application. This is
290     used to trace the northbound actor driving the actions of the
291 marcus 18727 Client. The Client may not provide this identifier to the Agent
292 marcus 18734 if there is no external actor driving the Client. However, this
293 marcus 18727 field MUST be logged. If the Client does not provide an actor ID,
294     then the Agent MUST log an empty field.
295 marcus 18717
296     Client Address: This is the network address of the client that
297     connected to the Agent. For example, this may be an IPv4 or IPv6
298 marcus 18728 address. [Note: will I2RS support interactions that have no
299     network address? If so this field will need to be updated.]
300 marcus 18717
301     Operation: This is the I2RS operation performed. For example, this
302     may be an add route operation if a route is being inserted into a
303     routing table.
304    
305     Operation Data: This field comprises the data passed to the Agent
306     to complete the desired operation. For example, if the operation
307     is a route add operation, the Operation Data would include the
308     route prefix, prefix length, and next hop information to be
309     inserted as well as the specific routing table to which the route
310 marcus 18718 will be added. The operation data can also include interface
311 marcus 18727 information. Some operations MAY not provide operation data, and
312 marcus 18741 in those cases this field MUST be logged as a NULL string.
313 marcus 18717
314     Result Code: This field holds the result of the operation. In the
315     case of RIB operations, this MUST be the return code as specified
316 marcus 18728 in Section 4 of [I-D.nitinb-i2rs-rib-info-model]. The operation
317     may not complete with a result code in the case of a timeout. If
318     the operation fails to complete, it MUST still log the attempted
319     operation with an appropriate result code (e.g., a result code
320     indicating a timeout).
321 marcus 18717
322 marcus 18741 4.3. I2RS Trace Log Extensibility and Optional Fields
323 marcus 18720
324 marcus 18734 [NOTE: This section is TBD based on further development of I2RS WG
325     milestones.]
326 marcus 18720
327 marcus 18741 4.4. I2RS Trace Log Syntax
328 marcus 18720
329 marcus 18726 The following describes the trace log information model using
330     Augmented Backus-Naur Form (ABNF) syntax [RFC5234]:
331 marcus 18728
332 marcus 18741
333    
334    
335    
336 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 6]
337 marcus 18741
338     Internet-Draft I2RS Traceability September 2013
339    
340    
341 marcus 18727 i2rs-trace-log = timestamp client-id actor-id client-addr operation
342     operation-data result-code
343 marcus 18722 client-id = uuid
344     actor-id = byte-string
345 marcus 18727 byte-string = *( %x01-09 / %x0B-0C / %x0E-FF )
346 marcus 18726 ; any byte except NUL, CR or LF
347 marcus 18722 client-addr = IP-literal / IPv4address
348     operation = ALPHA *( ALPHA / "_" / "-" / "(" / ")" )
349     operation-data = *VCHAR
350     result-code = 1*( ALPHA / DIGIT / "-" / "_" / "(" / ")" )
351 marcus 18720
352 marcus 18729
353 marcus 18727 The ABNF syntax rules <IP-literal>, <IPv4address>, and <sub-delims>
354 marcus 18736 are specified in [RFC3986]. The core rules <DIGIT>, <ALPHA> and
355     <VCHAR> are used as described in Appendix B of [RFC5234].
356 marcus 18720
357 marcus 18727 Here, <uuid> is specified in [RFC4122]. The idea of using a UUID for
358     the Client identifier ensures the ID is unique not just in the scope
359     of the current I2RS Agent, but across Agents as well. This ensures
360     that two clients that are unaware of each other will not allocate the
361     same Client ID. That does not preclude two Clients acting as one for
362     purposes of high availability from sharing the same UUID as generated
363 marcus 18728 by one one of the Clients. [Note: the format of the Client ID has
364     not yet been decided by the I2RS WG. This is subject to change.]
365 marcus 18727
366 marcus 18724 The <timestamp> field is defined in [RFC3339]. As stated in
367 marcus 18741 Section 4.2 the fractional second format MUST be used to provide
368 marcus 18720 proper granularity.
369    
370     The values for <operation>, <operation-data> and <result-code> are
371     suggestions as the protocol has not been defined yet. By making
372     these human-readable (as opposed to opcodes) the log becomes more
373     easily consumable by operators and administrators trying to
374     troubleshoot issues relating to I2RS. Even in cases where the
375     operations or codes might appear as opcodes on the wire, their
376     textual translations MUST be included in the log. The opcodes
377     themselves MAY appear in parentheses after the textual
378     representation.
379    
380 marcus 18726 5. Examples
381 marcus 18720
382 marcus 18730 Here is a proposed sample of what the fields might look like in an
383     I2RS trace log. This is only an early proposal. These values are
384     subject to change.
385 marcus 18720
386 marcus 18730
387    
388 marcus 18734
389 marcus 18747
390    
391    
392 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 7]
393 marcus 18734
394     Internet-Draft I2RS Traceability September 2013
395    
396    
397 marcus 18747 Timestamp: 2013-09-03T12:00:01.21+00:00
398     Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66
399     Actor ID: com.example.RoutingApp
400 marcus 18741 Client Address: 192.0.2.2
401     Operation: ROUTE_ADD
402     Operation Data: PREFIX 203.0.113.0 PREFIX-LEN 24 NEXT-HOP
403     198.51.100.1
404     Result Code: SUCCESS(0)
405 marcus 18730
406 marcus 18741
407 marcus 18726 6. Operational Guidance
408 marcus 18717
409 marcus 18741 Specific operational procedures regarding temporary log storage,
410     rollover, retrieval, and access of I2RS trace logs is out of scope
411     for this document. Organizations employing I2RS trace logging are
412     responsible for establishing proper operational procedures that are
413     appropriately suited to their specific requirements and operating
414     environment. In this section we only provide fundamental and
415     generalized operational guidelines that are implementation-
416     independent.
417 marcus 18726
418 marcus 18734 6.1. Trace Log Creation
419 marcus 18726
420 marcus 18734 The I2RS Agent interacts with the Routing and Signaling functions of
421     the Routing Element. Since the I2RS Agent is responsible for
422     actually making the routing changes on the associated network device,
423     it creates and maintains a log of transactions that can be retrieved
424     to troubleshoot I2RS-related impact to the network.
425    
426 marcus 18741 6.2. Trace Log Temporary Storage
427 marcus 18734
428 marcus 18741 The trace information may be temporarily stored either in an in-
429     memory buffer or as a file local to the Agent. Care should be given
430     to the number of I2RS transactions expected on a given agent so that
431     the appropriate storage medium is used and to maximize the
432     effectiveness of the log while not impacting the performance and
433     health of the Agent. Section 6.3 talks about rotating the trace log
434     in order to preserve the transaction history without exhausting Agent
435     or network device resources. It is perfectly acceptable, therefore,
436     to use both an in-memory buffer for recent transactions while
437     rotating or archiving older transactions to a local file.
438 marcus 18727
439 marcus 18734 It is outside the scope of this document to specify the
440     implementation details (i.e., size, throughput, data protection,
441 marcus 18741 privacy, etc.) for the physical storage of the I2RS log file. Data
442     retention policies of the I2RS traceability log is also outside the
443     scope of this document.
444 marcus 18730
445    
446    
447    
448 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 8]
449 marcus 18734
450     Internet-Draft I2RS Traceability September 2013
451    
452    
453 marcus 18747 6.3. Trace Log Rotation
454    
455 marcus 18718 In order to prevent the exhaustion of resources on the I2RS Agent or
456 marcus 18717 its associated network device, the I2RS trace log implementation MAY
457     choose to implement a configurable rotation schedule. It SHOULD be
458 marcus 18734 possible to do file rotation based on either time or size of the
459     current trace log. If file rollover is supported, multiple archived
460     log files SHOULD be supported in order to maximize the
461     troubleshooting and accounting benefits of the trace log.
462 marcus 18717
463 marcus 18726 6.4. Trace Log Retrieval
464 marcus 18717
465 marcus 18734 Implementors are free to provide their own, proprietary interfaces
466     and develop custom tools to retrieve and display the I2RS trace log.
467     These may include the display of the I2RS trace log as Command Line
468     Interface (CLI) output. However, a key intention of defining this
469     information model is to establish an implementor-agnostic and
470     consistent interface to collect I2RS trace data. Correspondingly,
471     retrieval of the data should also be made implementor-agnostic.
472 marcus 18717
473 marcus 18739 The following three sections describe potential ways the trace log
474     can be accessed. At least one of these three MUST be used, with the
475     I2RS mechanisms being preferred as they are implementor-independent
476     approaches to retrieving the data.
477 marcus 18718
478 marcus 18726 6.4.1. Retrieval Via Syslog
479 marcus 18717
480     The syslog protocol [RFC5424] is a standard way of sending event
481 marcus 18734 notification messages from a host to a collector. However, the
482 marcus 18717 protocol does not define any standard format for storing the
483     messages, and thus implementors of I2RS tracing would be left to
484     define their own format. So, while the data contained within the
485     syslog message would adhere to this information model, and may be
486 marcus 18718 consumable by a human operator, it would not be easily parseable by a
487 marcus 18727 machine. Therefore, syslog MAY be employed as a means of retrieving
488     or disseminating the I2RS trace log contents.
489    
490 marcus 18737 6.4.2. Retrieval Via I2RS Information Collection
491 marcus 18727
492     Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture]
493     defines a mechanism for information collection. The information
494 marcus 18717 collected includes obtaining a snapshot of a large amount of data
495     from the network element. It is the intent of I2RS to make this data
496     available in an implementor-agnostic fashion. Therefore, the I2RS
497 marcus 18718 trace log SHOULD be made available via the I2RS information
498     collection mechanism either as a single snapshot or via a
499     subscription stream.
500 marcus 18717
501    
502 marcus 18734
503    
504 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 9]
505 marcus 18734
506     Internet-Draft I2RS Traceability September 2013
507    
508    
509 marcus 18747 6.4.3. Retrieval Via I2RS Pub-Sub
510    
511 marcus 18735 Section 6.7 of the I2RS architecture [I-D.ietf-i2rs-architecture]
512     goes on to define a publish-subscribe mechanism for a feed of changes
513     happening within the I2RS layer. I2RS Agents SHOULD support
514 marcus 18739 publishing I2RS trace log information to that feed as described in
515     that document. Subscribers would then receive a live stream of I2RS
516     interactions in trace log format and could flexibly choose to do a
517     number of things with the log messages. For example, the subscribers
518     could log the messages to a datastore, aggregate and summarize
519 marcus 18741 interactions from a single client, etc. Using pub-sub for the
520     purpose of logging I2RS interactions augments the areas described by
521     [I-D.camwinget-i2rs-pubsub-sec]. The full range of potential
522 marcus 18739 activites is virtually limitless and the details of how they are
523     performed are outside the scope of this document, however.
524 marcus 18735
525     7. IANA Considerations
526    
527 marcus 18726 This document makes no request of IANA.
528 marcus 18717
529 marcus 18726 8. Security Considerations
530 marcus 18717
531 marcus 18734 The I2RS trace log, like any log file, reveals the state of the
532     entity producing it as well as the identifying information elements
533     and detailed interactions of the system containing it. The
534     information model described in this document does not itself
535     introduce any security issues, but it does define the set of
536     attributes that make up an I2RS log file. These attributes may
537     contain sensitive information and thus should adhere to the security,
538     privacy and permission policies of the organization making use of the
539     I2RS log file.
540 marcus 18717
541 marcus 18734 It is outside the scope of this document to specify how to protect
542     the stored log file, but it is expected that adequate precautions and
543     security best practices such as disk encryption, appropriately
544     restrictive file/directory permissions, suitable hardening and
545     physical security of logging entities, mutual authentication,
546     transport encryption, channel confidentiality, and channel integrity
547     if transferring log files. Additionally, the potentially sensitive
548     information contained in a log file SHOULD be adequately anonymized
549     or obfuscated by operators to ensure its privacy.
550 marcus 18717
551 marcus 18741 9. References
552 marcus 18717
553 marcus 18741 9.1. Normative References
554 marcus 18717
555 marcus 18741 [I-D.ietf-i2rs-architecture]
556 marcus 18735
557    
558    
559    
560 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 10]
561 marcus 18735
562     Internet-Draft I2RS Traceability September 2013
563    
564    
565 marcus 18727 Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
566     Nadeau, "An Architecture for the Interface to the Routing
567     System", draft-ietf-i2rs-architecture-00 (work in
568     progress), August 2013.
569    
570 marcus 18726 [I-D.ietf-i2rs-problem-statement]
571     Atlas, A., Nadeau, T., and D. Ward, "Interface to the
572 marcus 18729 Routing System Problem Statement", draft-ietf-i2rs-
573     problem-statement-00 (work in progress), August 2013.
574 marcus 18726
575 marcus 18718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
576     Requirement Levels", BCP 14, RFC 2119, March 1997.
577 marcus 18717
578 marcus 18726 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
579 marcus 18729 Resource Identifier (URI): Generic Syntax", STD 66, RFC
580     3986, January 2005.
581 marcus 18726
582 marcus 18720 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
583 marcus 18729 Unique IDentifier (UUID) URN Namespace", RFC 4122, July
584     2005.
585 marcus 18717
586 marcus 18720 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
587     Specifications: ABNF", STD 68, RFC 5234, January 2008.
588 marcus 18717
589 marcus 18741 9.2. Informative References
590 marcus 18717
591 marcus 18741 [I-D.camwinget-i2rs-pubsub-sec]
592     Beck, K., Cam-Winget, N., and D. McGrew, "Using the
593     Publish-Subscribe Model in the Interface to the Routing
594     System", draft-camwinget-i2rs-pubsub-sec-00 (work in
595     progress), July 2013.
596    
597 marcus 18718 [I-D.nitinb-i2rs-rib-info-model]
598     Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
599 marcus 18729 Information Base Info Model", draft-nitinb-i2rs-rib-info-
600     model-02 (work in progress), August 2013.
601 marcus 18717
602 marcus 18728 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
603     Internet: Timestamps", RFC 3339, July 2002.
604 marcus 18717
605 marcus 18728 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
606 marcus 18717
607 marcus 18746 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
608     Reserved for Documentation", RFC 5737, January 2010.
609    
610 marcus 18727 Authors' Addresses
611    
612 marcus 18735
613    
614    
615    
616 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 11]
617 marcus 18735
618     Internet-Draft I2RS Traceability September 2013
619    
620    
621 marcus 18727 Joe Clarke
622     Cisco Systems, Inc.
623     7200-12 Kit Creek Road
624     Research Triangle Park, NC 27709
625     US
626    
627     Phone: +1-919-392-2867
628     Email: jclarke@cisco.com
629    
630    
631 marcus 18726 Gonzalo Salgueiro
632 marcus 18741 Cisco Systems, Inc.
633 marcus 18726 7200-12 Kit Creek Road
634     Research Triangle Park, NC 27709
635     US
636    
637     Email: gsalguei@cisco.com
638    
639    
640 marcus 18741 Carlos Pignataro
641     Cisco Systems, Inc.
642     7200-12 Kit Creek Road
643     Research Triangle Park, NC 27709
644     US
645 marcus 18726
646 marcus 18741 Email: cpignata@cisco.com
647 marcus 18726
648    
649    
650 marcus 18735
651    
652    
653    
654    
655    
656    
657    
658    
659    
660    
661    
662    
663    
664    
665    
666    
667    
668    
669    
670    
671    
672 marcus 18755 Clarke, et al. Expires April 01, 2014 [Page 12]

  ViewVC Help
Powered by ViewVC 1.1.27