/[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 18734 - (hide annotations) (download)
Sun Sep 8 14:29:30 2013 UTC (6 years, 6 months ago) by marcus
Original Path: trunk/i2rs-traceability/draft-clarke-i2rs-traceability.txt
File MIME type: text/plain
File size: 23991 byte(s)
Regen the text.

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

  ViewVC Help
Powered by ViewVC 1.1.27