idnits 2.17.1 draft-ietf-ripv2-mibext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 198 has weird spacing: '...es sent to R...' == Line 216 has weird spacing: '...A list of s...' == Line 257 has weird spacing: '...process which...' == Line 267 has weird spacing: '...tes, in valid...' == Line 277 has weird spacing: '...updates actua...' == (25 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1992) is 11607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '7' on line 576 looks like a reference -- Missing reference section? '3' on line 552 looks like a reference -- Missing reference section? '8' on line 582 looks like a reference -- Missing reference section? '9' on line 588 looks like a reference -- Missing reference section? '1' on line 541 looks like a reference -- Missing reference section? '2' on line 547 looks like a reference -- Missing reference section? '4' on line 558 looks like a reference -- Missing reference section? '5' on line 564 looks like a reference -- Missing reference section? '6' on line 570 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RIP 2 MIB Extension July 1992 4 RIP Version 2 MIB Extension 6 July 6, 1992 8 Gary Malkin 10 Xylogics, Inc. 11 53 Third Avenue 12 Burlington, MA 01803 13 gmalkin@Xylogics.COM 15 Fred Baker 17 Advanced Computer Communications 18 315 Bollay Drive 19 Santa Barbara, California 93117-6014 20 fbaker@acc.com 22 _1. _S_t_a_t_u_s _o_f _t_h_i_s _M_e_m_o 24 This document is an Internet Draft. Internet Drafts are 25 working documents of the Internet Engineering Task Force 26 (IETF), its Areas, and its Working Groups. Note that other 27 groups may also distribute working documents as Internet 28 Drafts). 30 Internet Drafts are draft documents valid for a maximum of six 31 months. Internet Drafts may be updated, replaced, or obsoleted 32 by other documents at any time. It is not appropriate to use 33 Internet Drafts as reference material or to cite them other 34 than as a "working draft" or "work in progress." 36 Please check the I-D abstract listing contained in each 37 Internet Draft directory to learn the current status of this 38 or any other Internet Draft. 40 It is intended that this document will be submitted to the 41 IESG for consideration as a standards document. Distribution 42 of this document is unlimited. 44 Please send comments to ietf-rip@xylogics.com. 46 _2. _A_b_s_t_r_a_c_t 48 This memo defines an experimental portion of the Management 49 Information Base (MIB) for use with network management 50 protocols in TCP/IP-based internets. In particular, it 51 defines objects for managing RIP Version 2. 53 This memo does not specify a standard for the Internet 54 community. 56 _3. _T_h_e _N_e_t_w_o_r_k _M_a_n_a_g_e_m_e_n_t _F_r_a_m_e_w_o_r_k 58 The Internet-standard Network Management Framework consists of 59 three components. They are: 61 RFC 1155 which defines the SMI, the mechanisms used for 62 describing and naming objects for the purpose of management. 63 RFC 1212 defines a more concise description mechanism, which 64 is wholly consistent with the SMI. 66 RFC 1156 which defines MIB-I, the core set of managed objects 67 for the Internet suite of protocols. RFC 1213 defines MIB-II, 68 an evolution of MIB-I based on implementation experience and 69 new operational requirements. 71 RFC 1157 which defines the SNMP, the protocol used for network 72 access to managed objects. 74 The Framework permits new objects to be defined for the 75 purpose of experimentation and evaluation. 77 _4. _O_b_j_e_c_t_s 79 Managed objects are accessed via a virtual information store, 80 termed the Management Information Base or MIB. Objects in the 81 MIB are defined using the subset of Abstract Syntax Notation 82 One (ASN.1) [7] defined in the SMI. In particular, each 83 object has a name, a syntax, and an encoding. The name is an 84 object identifier, an administratively assigned name, which 85 specifies an object type. The object type together with an 86 object instance serves to uniquely identify a specific 87 instanciation of the object. For human convenience, we often 88 use a textual string, termed the OBJECT DESCRIPTOR, to also 89 refer to the object type. 91 The syntax of an object type defines the abstract data 92 structure corresponding to that object type. The ASN.1 93 language is used for this purpose. However, the SMI [3] 94 purposely restricts the ASN.1 constructs which may be used. 95 These restrictions are explicitly made for simplicity. 97 The encoding of an object type is simply how that object type 98 is represented using the object type's syntax. Implicitly 99 tied to the notion of an object type's syntax and encoding is 100 how the object type is represented when being transmitted on 101 the network. 103 The SMI specifies the use of the basic encoding rules of ASN.1 104 [8], subject to the additional requirements imposed by the 105 SNMP. 107 _4._1. _F_o_r_m_a_t _o_f _D_e_f_i_n_i_t_i_o_n_s 109 Section 6 contains contains the specification of all object 110 types contained in this MIB module. The object types are 111 defined using the conventions defined in the SMI, as amended 112 by the extensions specified in [9]. 114 _5. _O_v_e_r_v_i_e_w 116 _5._1. _T_e_x_t_u_a_l _C_o_n_v_e_n_t_i_o_n_s 118 Several new data types are introduced as a textual convention 119 in this MIB document. These textual conventions enhance the 120 readability of the specification and can ease comparison with 121 other specifications if appropriate. It should be noted that 122 the introduction of the these textual conventions has no 123 effect on either the syntax nor the semantics of any managed 124 objects. The use of these is merely an artifact of the 125 explanatory method used. Objects defined in terms of one of 126 these methods are always encoded by means of the rules that 127 define the primitive type. Hence, no changes to the SMI or 128 the SNMP are necessary to accommodate these textual 129 conventions which are adopted merely for the convenience of 130 readers and writers in pursuit of the elusive goal of clear, 131 concise, and unambiguous MIB documents. 133 The new data types are: Validation (the standard "set to 134 invalid causes deletion" type), and RouteTag. The RouteTag 135 type represents the contents of the Route Tag field in the 136 packet header or route entry. 138 _5._2. _S_t_r_u_c_t_u_r_e _o_f _M_I_B 140 The RIP-2 MIB contains global counters useful for detecting 141 the deleterious effects of RIP incompatibilities, an 142 "interfaces" table which contains interface-specific 143 statistics and configuration information, and an optional 144 "neighbor" table containing information that may be helpful in 145 debugging neighbor relationships. Like the protocol itself, 146 this MIB takes great care to preserve compatibility with RIP-1 147 systems, and controls for monitoring and controlling system 148 interactions. 150 _6. _D_e_f_i_n_i_t_i_o_n_s 152 RFCRIP2-MIB DEFINITIONS ::= BEGIN 154 IMPORTS 155 experimental, Counter, TimeTicks, IpAddress 156 FROM RFC1155-SMI 157 OBJECT-TYPE 158 FROM RFC-1212; 160 -- RIP-2 Management Information Base 162 -- Note: IANA has a special curse that it utters over 163 -- people who install the following OID in their systems... 164 rip2 OBJECT IDENTIFIER ::= { experimental 1234 } 166 -- the RouteTag type represents the contents of the 167 -- Route Tag field in the packet header or route entry. 169 RouteTag ::= OCTET STRING (SIZE (2)) 171 -- the Validation type is used for the variable that deletes 172 -- an entry from a table, and ALWAYS takes at least these values: 174 Validation ::= INTEGER { valid (1), invalid (2) } 175 -- The RIP 2 Globals Group. 176 -- Implementation of this group is mandatory for systems that 177 -- implement RIP-2. 179 -- These counters are intended to facilitate debugging quickly 180 -- changing routes or failing neighbors 182 rip2GlobalGroup OBJECT IDENTIFIER ::= { rip2 1 } 184 rip2GlobalRouteChanges OBJECT-TYPE 185 SYNTAX Counter 186 ACCESS read-only 187 STATUS mandatory 188 DESCRIPTION 189 "The number of changes made to the IP Route Da- 190 tabase by RIP." 191 ::= { rip2GlobalGroup 1 } 193 rip2GlobalQueries OBJECT-TYPE 194 SYNTAX Counter 195 ACCESS read-only 196 STATUS mandatory 197 DESCRIPTION 198 "The number of responses sent to RIP queries 199 from other systems." 200 ::= { rip2GlobalGroup 2 } 201 -- RIP Interfaces Groups 202 -- Implementation of these Groups is mandatory for systems that 203 -- implement RIP-2. 205 -- Since RIP versions 1 and 2 do not deal with addressless links, 206 -- it is assumed that RIP "interfaces" are subnets within a 207 -- routing domain. 209 -- The RIP Interface Status Table. 211 rip2IfStatTable OBJECT-TYPE 212 SYNTAX SEQUENCE OF Rip2IfStatEntry 213 ACCESS not-accessible 214 STATUS mandatory 215 DESCRIPTION 216 "A list of subnets which require separate 217 status monitoring in RIP." 218 ::= { rip2 2 } 220 rip2IfStatEntry OBJECT-TYPE 221 SYNTAX Rip2IfStatEntry 222 ACCESS not-accessible 223 STATUS mandatory 224 DESCRIPTION 225 "A Single Routing Domain in a single Subnet." 226 INDEX { rip2IfStatAddress } 227 ::= { rip2IfStatTable 1 } 229 Rip2IfStatEntry ::= 230 SEQUENCE { 231 rip2IfStatAddress 232 IpAddress, 233 rip2IfStatRcvBadPackets 234 Counter, 235 rip2IfStatRcvBadRoutes 236 Counter, 237 rip2IfStatSentUpdates 238 Counter, 239 rip2IfStatStatus 240 Validation 241 } 242 rip2IfStatAddress OBJECT-TYPE 243 SYNTAX IpAddress 244 ACCESS read-only 245 STATUS mandatory 246 DESCRIPTION 247 "The IP Address of this system on the indicated 248 subnet." 249 ::= { rip2IfStatEntry 1 } 251 rip2IfStatRcvBadPackets OBJECT-TYPE 252 SYNTAX Counter 253 ACCESS read-only 254 STATUS mandatory 255 DESCRIPTION 256 "The number of RIP response packets received by 257 the RIP process which were subsequently dis- 258 carded for any reason (e.g. a version 0 packet, 259 or an unknown command type)." 260 ::= { rip2IfStatEntry 2 } 262 rip2IfStatRcvBadRoutes OBJECT-TYPE 263 SYNTAX Counter 264 ACCESS read-only 265 STATUS mandatory 266 DESCRIPTION 267 "The number of routes, in valid RIP packets, 268 which were ignored for any reason (e.g. unknown 269 address family, or invalid metric)." 270 ::= { rip2IfStatEntry 3 } 272 rip2IfStatSentUpdates OBJECT-TYPE 273 SYNTAX Counter 274 ACCESS read-only 275 STATUS mandatory 276 DESCRIPTION 277 "The number of triggered RIP updates actually 278 sent on this interface. This explicitly does 279 NOT include full updates sent containing new 280 information." 281 ::= { rip2IfStatEntry 4 } 282 rip2IfStatStatus OBJECT-TYPE 283 SYNTAX Validation 284 ACCESS read-write 285 STATUS mandatory 286 DESCRIPTION 287 "Writing invalid has the effect of deleting 288 this interface." 289 DEFVAL { valid } 290 ::= { rip2IfStatEntry 5 } 291 -- The RIP Interface Configuration Table. 293 rip2IfConfTable OBJECT-TYPE 294 SYNTAX SEQUENCE OF Rip2IfConfEntry 295 ACCESS not-accessible 296 STATUS mandatory 297 DESCRIPTION 298 "A list of subnets which require separate con- 299 figuration in RIP." 300 ::= { rip2 3 } 302 rip2IfConfEntry OBJECT-TYPE 303 SYNTAX Rip2IfConfEntry 304 ACCESS not-accessible 305 STATUS mandatory 306 DESCRIPTION 307 "A Single Routing Domain in a single Subnet." 308 INDEX { rip2IfConfAddress } 309 ::= { rip2IfConfTable 1 } 311 Rip2IfConfEntry ::= 312 SEQUENCE { 313 rip2IfConfAddress 314 IpAddress, 315 rip2IfConfDomain 316 RouteTag, 317 rip2IfConfAuthType 318 INTEGER, 319 rip2IfConfAuthKey 320 OCTET STRING (SIZE(0..16)), 321 rip2IfConfSend 322 INTEGER, 323 rip2IfConfReceive 324 INTEGER, 325 rip2IfConfDefaultMetric 326 INTEGER, 327 rip2IfConfStatus 328 Validation 329 } 330 rip2IfConfAddress OBJECT-TYPE 331 SYNTAX IpAddress 332 ACCESS read-only 333 STATUS mandatory 334 DESCRIPTION 335 "The IP Address of this system on the indicated 336 subnet." 337 ::= { rip2IfConfEntry 1 } 339 rip2IfConfDomain OBJECT-TYPE 340 SYNTAX RouteTag 341 ACCESS read-write 342 STATUS mandatory 343 DESCRIPTION 344 "Value inserted into the Routing Domain field 345 of all RIP packets sent on this interface." 346 DEFVAL { '0000'h } 347 ::= { rip2IfConfEntry 2 } 349 rip2IfConfAuthType OBJECT-TYPE 350 SYNTAX INTEGER { 351 noAuthentication (1), 352 simplePassword (2) 353 } 354 ACCESS read-write 355 STATUS mandatory 356 DESCRIPTION 357 "The type of Authentication used on this inter- 358 face." 359 DEFVAL { noAuthentication } 360 ::= { rip2IfConfEntry 3 } 361 rip2IfConfAuthKey OBJECT-TYPE 362 SYNTAX OCTET STRING (SIZE(0..16)) 363 ACCESS read-write 364 STATUS mandatory 365 DESCRIPTION 366 "The value to be used as the Authentication Key 367 whenever the corresponding instance of 368 rip2IfConfAuthType has the value simplePass- 369 word. A modification of the corresponding in- 370 stance of rip2IfConfAuthType does not modify 371 the rip2IfConfAuthKey value. 373 If a string shorter than 16 octets is supplied, 374 it will be left-justified and padded to 16 oc- 375 tets, on the right, with nulls (0x00). 377 Reading this object always results in an OCTET 378 STRING of length zero; authentication may not 379 be bypassed by reading the MIB object." 380 DEFVAL { ''h } 381 ::= { rip2IfConfEntry 4 } 383 rip2IfConfSend OBJECT-TYPE 384 SYNTAX INTEGER { 385 doNotSend (1), 386 ripVersion1 (2), 387 rip1Compatible (3), 388 ripVersion2 (4) 389 } 390 ACCESS read-write 391 STATUS mandatory 392 DESCRIPTION 393 "What the router sends on this interface. 394 ripVersion1 implies sending RIP updates compli- 395 ant with RFC 1058. rip1Compatible implies 396 broadcasting RIP-2 updates using RFC 1058 route 397 subsumption rules. ripVersion2 implies multi- 398 casting RIP-2 updates." 399 DEFVAL { rip1Compatible } 400 ::= { rip2IfConfEntry 5 } 401 rip2IfConfReceive OBJECT-TYPE 402 SYNTAX INTEGER { 403 rip1 (1), 404 rip2 (2), 405 rip1OrRip2 (3) 406 } 407 ACCESS read-write 408 STATUS mandatory 409 DESCRIPTION 410 "This indicates which version of RIP updates 411 are to be accepted. Note that rip2 and 412 rip1OrRip2 implies reception of multicast pack- 413 ets." 414 DEFVAL { rip1OrRip2 } 415 ::= { rip2IfConfEntry 6 } 417 rip2IfConfDefaultMetric OBJECT-TYPE 418 SYNTAX INTEGER ( 0..15 ) 419 ACCESS read-write 420 STATUS mandatory 421 DESCRIPTION 422 "This variable indicates what metric is to be 423 used as a default route in RIP updates ori- 424 ginated on this interface. A value of zero in- 425 dicates that no default route should be ori- 426 ginated; in this case, a default route via 427 another router may be propagated." 428 ::= { rip2IfConfEntry 7 } 430 rip2IfConfStatus OBJECT-TYPE 431 SYNTAX Validation 432 ACCESS read-write 433 STATUS mandatory 434 DESCRIPTION 435 "Writing invalid has the effect of deleting 436 this interface." 437 DEFVAL { valid } 438 ::= { rip2IfConfEntry 8 } 439 -- Peer Table 441 -- The RIP Peer Group 442 -- Implementation of this Group is Optional 444 -- This group provides information about active peer 445 -- relationships intended to assist in debugging. 447 rip2PeerTable OBJECT-TYPE 448 SYNTAX SEQUENCE OF Rip2PeerEntry 449 ACCESS not-accessible 450 STATUS mandatory 451 DESCRIPTION 452 "A list of RIP Peers." 453 ::= { rip2 4 } 455 rip2PeerEntry OBJECT-TYPE 456 SYNTAX Rip2PeerEntry 457 ACCESS not-accessible 458 STATUS mandatory 459 DESCRIPTION 460 "Information regarding a single routing peer." 461 INDEX { rip2PeerAddress, rip2PeerDomain } 462 ::= { rip2PeerTable 1 } 464 Rip2PeerEntry ::= 465 SEQUENCE { 466 rip2PeerAddress 467 IpAddress, 468 rip2PeerDomain 469 RouteTag, 470 rip2PeerLastUpdate 471 TimeTicks, 472 rip2PeerVersion 473 INTEGER, 474 rip2PeerRcvBadPackets 475 Counter, 476 rip2PeerRcvBadRoutes 477 Counter 478 } 479 rip2PeerAddress OBJECT-TYPE 480 SYNTAX IpAddress 481 ACCESS read-only 482 STATUS mandatory 483 DESCRIPTION 484 "The IP Address of the Peer System." 485 ::= { rip2PeerEntry 1 } 487 rip2PeerDomain OBJECT-TYPE 488 SYNTAX RouteTag 489 ACCESS read-only 490 STATUS mandatory 491 DESCRIPTION 492 "The value in the Routing Domain field in RIP 493 packets received from the peer." 494 ::= { rip2PeerEntry 2 } 496 rip2PeerLastUpdate OBJECT-TYPE 497 SYNTAX TimeTicks 498 ACCESS read-only 499 STATUS mandatory 500 DESCRIPTION 501 "The value of sysUpTime when the most recent 502 RIP update was received from this system." 503 ::= { rip2PeerEntry 3 } 505 rip2PeerVersion OBJECT-TYPE 506 SYNTAX INTEGER ( 0..255 ) 507 ACCESS read-only 508 STATUS mandatory 509 DESCRIPTION 510 "The RIP version number in the header of the 511 last RIP packet received." 512 ::= { rip2PeerEntry 4 } 513 rip2PeerRcvBadPackets OBJECT-TYPE 514 SYNTAX Counter 515 ACCESS read-only 516 STATUS mandatory 517 DESCRIPTION 518 "The number of RIP response packets from this 519 peer discarded as invalid." 520 ::= { rip2PeerEntry 5 } 522 rip2PeerRcvBadRoutes OBJECT-TYPE 523 SYNTAX Counter 524 ACCESS read-only 525 STATUS mandatory 526 DESCRIPTION 527 "The number of routes from this peer that were 528 ignored because the entry format was invalid." 529 ::= { rip2PeerEntry 6 } 531 END 532 _7. _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s 534 This document was produced by the RIP 2 Working Group. 536 In addition, the comments of the following individuals are 537 also acknowledged: Keith McCloghrie and Frank Kastenholz. 539 _8. _R_e_f_e_r_e_n_c_e_s 541 [1] V. Cerf, IAB Recommendations for the Development of 542 Internet Network Management Standards. Internet Working 543 Group Request for Comments 1052. Network Information 544 Center, SRI International, Menlo Park, California, 545 (April, 1988). 547 [2] V. Cerf, Report of the Second Ad Hoc Network Management 548 Review Group, Internet Working Group Request for Comments 549 1109. Network Information Center, SRI International, 550 Menlo Park, California, (August, 1989). 552 [3] M.T. Rose and K. McCloghrie, Structure and Identification 553 of Management Information for TCP/IP-based internets, 554 Internet Working Group Request for Comments 1155. 555 Network Information Center, SRI International, Menlo 556 Park, California, (May, 1990). 558 [4] K. McCloghrie and M.T. Rose, Management Information Base 559 for Network Management of TCP/IP-based internets, 560 Internet Working Group Request for Comments 1156. 561 Network Information Center, SRI International, Menlo 562 Park, California, (May, 1990). 564 [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 565 Simple Network Management Protocol, Internet Working 566 Group Request for Comments 1157. Network Information 567 Center, SRI International, Menlo Park, California, (May, 568 1990). 570 [6] M.T. Rose (editor), Management Information Base for 571 Network Management of TCP/IP-based internets, Internet 572 Working Group Request for Comments 1158. Network 573 Information Center, SRI International, Menlo Park, 574 California, (May, 1990). 576 [7] Information processing systems - Open Systems 577 Interconnection - Specification of Abstract Syntax 578 Notation One (ASN.1), International Organization for 579 Standardization. International Standard 8824, (December, 580 1987). 582 [8] Information processing systems - Open Systems 583 Interconnection - Specification of Basic Encoding Rules 584 for Abstract Notation One (ASN.1), International 585 Organization for Standardization. International Standard 586 8825, (December, 1987). 588 [9] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB 589 Definitions, Request for Comments 1212, Internet 590 Engineering Task Force, (March, 1991). 592 Table of Contents 594 1 Status of this Memo ................................... 1 595 2 Abstract .............................................. 2 596 3 The Network Management Framework ...................... 2 597 4 Objects ............................................... 2 598 4.1 Format of Definitions ............................... 3 599 5 Overview .............................................. 3 600 5.1 Textual Conventions ................................. 3 601 5.2 Structure of MIB .................................... 4 602 6 Definitions ........................................... 5 603 6.1 Global Counters ..................................... 6 604 6.2 RIP Interface Tables ................................ 7 605 6.3 Peer Table .......................................... 14 606 7 Acknowledgements ...................................... 17 607 8 References ............................................ 18