1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
|
Network Working Group K. McCloghrie, Editor
Request for Comments: 1229 Hughes LAN Systems, Inc.
May 1991
Extensions to the Generic-Interface MIB
Status of this Memo
This RFC contains definitions of managed objects used as experimental
extensions to the generic interfaces structure of MIB-II. This memo
is a product of the SNMP Working Group of the Internet Engineering
Task Force (IETF). This RFC specifies an IAB standards track
protocol for the Internet community, and requests discussion and
suggestions for improvements. Please refer to the current edition of
the "IAB Official Protocol Standards" for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Table of Contents
1. Abstract .............................................. 1
2. The Network Management Framework....................... 1
3. Objects ............................................... 2
4. Overview .............................................. 3
4.1 Generic Interface Extension Table .................... 3
4.2 Generic Interface Test Table ......................... 3
4.3 Generic Receive Address Table ........................ 4
5. Definitions ........................................... 5
6. Acknowledgements ...................................... 14
7. References ............................................ 15
8. Security Considerations................................ 15
9. Author's Address....................................... 16
1. Abstract
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it defines managed object
types as experimental extensions to the generic interfaces structure
of MIB-II.
2. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212
SNMP Working Group [Page 1]
^L
RFC 1229 Interface MIB Extensions May 1991
defines a more concise description mechanism, which is wholly
consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. RFC 1213, defines MIB-II, an
evolution of MIB-I based on implementation experience and new
operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
3. Objects
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
this purpose. However, the SMI [3] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP.
Section 5 contains the specification of all object types in this
section of the MIB. The object types are defined using the
conventions specified in the SMI, as amended by the extensions
specified in [9].
SNMP Working Group [Page 2]
^L
RFC 1229 Interface MIB Extensions May 1991
4. Overview
The Internet Standard MIB [4,6] contains a group of management
objects pertaining to a network device's generic network
interface(s). These objects are generic in the sense that they apply
to all network interfaces, irrespective of the type of communication
media and protocols used on such interfaces. This has proved to be
necessary but not sufficient; there are efforts underway to define
additional MIB objects which are specific to particular media and
lower-level (subnetwork-layer and below) protocol stacks.
However, some of these efforts have identified objects which are
required (or at least useful), but are not specific to the
interface-type on which the effort is focusing. In order to avoid
redundancy, it is better that such objects be defined as extensions
to the generic interface group, rather than defined in multiple
specific-interface-type MIBs.
This memo defines the resultant extensions to the generic interface
group. These extensions are spread over three tables: the generic
Interface Extension table, the generic Interface Test table, and the
generic Receive Address table.
4.1. Generic Interface Extension Table
This table consists of new objects applicable to all types of
subnetwork interface.
4.2. Generic Interface Test Table
This section defines objects which allow a network manager to
instruct an agent to test an interface for various faults. A few
common types of tests are defined in this document but most will be
defined elsewhere, dependent on the particular type of interface.
After testing, the object ifExtnsTestResult can be read to determine
the outcome. If an agent cannot perform the test, ifExtnsTestResult
is set to so indicate. The object ifExtnsTestCode can be used to
provide further test-specific or interface-specific (or even
enterprise-specific) information concerning the outcome of the test.
Only one test can be in progress on each interface at any one time.
If one test is in progress when another test is invoked, the second
test is rejected. Some agents may reject a test when a prior test is
active on another interface.
When a test is invoked, the identity of the originator of the request
and the request-id are saved by the agent in the objects
ifExtnsTestRequestId and ifExtnsTestCommunity. These values remain
set until the next test is invoked. In the (rare) event that the
SNMP Working Group [Page 3]
^L
RFC 1229 Interface MIB Extensions May 1991
invocation of tests by two network managers were to overlap, then
there would be a possibility that the first test's results might be
overwritten by the second test's results prior to the first results
being read. This unlikely circumstance can be detected by a network
manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId at
the same time as the test results are retrieved, and ensuring that
the results are for the desired request.
In general, a Management station must not retransmit a request to
invoke a test for which it does not receive a response; instead, it
properly inspects an agent's MIB to determine if the invocation was
successful. The invocation request is retransmitted only if the
invocation was unsuccessful.
Some tests may require the interface to be taken off-line or may even
require the agent to be rebooted after completion of the test. In
these circumstances, communication with the management station
invoking the test may be lost until after completion of the test.
The agent should make every effort to transmit a response to the
request that invoked the test prior to losing communication. When
the agent is restored to normal service, the results of the test are
properly made available in the appropriate objects. Note that this
requires that the ifIndex value assigned to an interface must be
unchanged even if the test causes a reboot. An agent must reject any
test for which it cannot, perhaps due to resource constraints, make
available at least the minimum amount of information after that test
completes.
4.3. Generic Receive Address Table
This table contains objects relating to an interface's support for
receiving packets/frames at more than one address on the same
interface.
SNMP Working Group [Page 4]
^L
RFC 1229 Interface MIB Extensions May 1991
5. Definitions
RFC1229-MIB DEFINITIONS ::= BEGIN
-- Extensions to MIB-II's Generic Interface Table
IMPORTS
experimental, Counter FROM RFC1155-SMI
DisplayString, PhysAddress FROM RFC1213-MIB
OBJECT-TYPE FROM RFC-1212;
ifExtensions OBJECT IDENTIFIER ::= { experimental 6 }
-- Generic Interface Extension Table
--
-- This group of objects is mandatory for all types of
-- subnetwork interface.
ifExtnsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interfaces extension entries.
The number of entries is given by the value
of ifNumber, defined in [4,6]."
::= { ifExtensions 1 }
ifExtnsEntry OBJECT-TYPE
SYNTAX IfExtnsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An extension to the interfaces entry,
defined in [4,6], containing additional
objects at the subnetwork layer and below
for a particular interface."
INDEX { ifExtnsIfIndex }
::= { ifExtnsTable 1 }
IfExtnsEntry ::=
SEQUENCE {
ifExtnsIfIndex
SNMP Working Group [Page 5]
^L
RFC 1229 Interface MIB Extensions May 1991
INTEGER,
ifExtnsChipSet
OBJECT IDENTIFIER,
ifExtnsRevWare
DisplayString,
ifExtnsMulticastsTransmittedOks
Counter,
ifExtnsBroadcastsTransmittedOks
Counter,
ifExtnsMulticastsReceivedOks
Counter,
ifExtnsBroadcastsReceivedOks
Counter,
ifExtnsPromiscuous
INTEGER
}
ifExtnsIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains
extended management information. The value
of this object for a particular interface
has the same value as the ifIndex object,
defined in [4,6], for the same interface."
::= { ifExtnsEntry 1 }
ifExtnsChipSet OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the hardware chip
set being used in the interface. The
assignment of OBJECT IDENTIFIERs to various
types of hardware chip sets is managed
by the IANA. If the hardware chip set is
unknown, the object identifier
unknownChipSet OBJECT IDENTIFIER ::= { 0 0 }
is returned. Note that unknownChipSet is a
syntactically valid object identifier, and
any conformant implementation of ASN.1 and
the BER must be able to generate and
SNMP Working Group [Page 6]
^L
RFC 1229 Interface MIB Extensions May 1991
recognize this value."
::= { ifExtnsEntry 2 }
ifExtnsRevWare OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An arbitrary octet string that describes
the firmware version of this interface.
It is intended that this should be human
readable. It must only contain ASCII
printable characters. Typically this
will be the firmware version of the main
interface software."
::= { ifExtnsEntry 3 }
ifExtnsMulticastsTransmittedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully
transmitted to a subnetwork or link-layer
multicast destination address other than a
broadcast address. For a MAC layer protocol,
this includes both Group and Functional
addresses."
::= { ifExtnsEntry 4 }
ifExtnsBroadcastsTransmittedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully
transmitted to a subnetwork or link-layer
broadcast addresses. It does not include
frames sent to a multicast address."
::= { ifExtnsEntry 5 }
ifExtnsMulticastsReceivedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully received
that are directed to an active subnetwork
SNMP Working Group [Page 7]
^L
RFC 1229 Interface MIB Extensions May 1991
or link-layer multicast address (for a MAC
layer protocol, this includes both Group and
Functional addresses). This does not include
frames directed to a broadcast address, nor
frames received with errors."
::= { ifExtnsEntry 6 }
ifExtnsBroadcastsReceivedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully received
that are directed to a subnetwork or
link-layer broadcast address. This does not
include frames received with errors."
::= { ifExtnsEntry 7 }
ifExtnsPromiscuous OBJECT-TYPE
SYNTAX INTEGER {
true(1),
false(2)
}
ACCESS read-only -- Note: agent implementors are
-- encouraged to extend this
-- access to read-write if that
-- makes sense in their agent.
STATUS mandatory
DESCRIPTION
"This object has a value of false(2) if
this interface only accepts packets/frames
that are addressed to this station. This
object has a value of true(1) when the
station accepts all packets/frames
transmitted on the media. The value
true(1) is only legal on certain types of
media. If legal, setting this object to a
value of true(1) may require the interface
to be reset before becoming effective."
::= { ifExtnsEntry 8 }
--
-- Generic Interface Test Table
--
-- This group of objects is optional, but if the table is
-- implemented, all objects in the table must be implemented.
SNMP Working Group [Page 8]
^L
RFC 1229 Interface MIB Extensions May 1991
ifExtnsTestTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsTestEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains one entry per interface."
::= { ifExtensions 2 }
ifExtnsTestEntry OBJECT-TYPE
SYNTAX IfExtnsTestEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry containing objects for invoking
tests on an interface."
INDEX { ifExtnsTestIfIndex }
::= { ifExtnsTestTable 1 }
IfExtnsTestEntry ::=
SEQUENCE {
ifExtnsTestIfIndex
INTEGER,
ifExtnsTestCommunity
OCTET STRING,
ifExtnsTestRequestId
INTEGER,
ifExtnsTestType
OBJECT IDENTIFIER,
ifExtnsTestResult
INTEGER,
ifExtnsTestCode
OBJECT IDENTIFIER
}
ifExtnsTestIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains
information on interface tests. The value
of this object for a particular interface
has the same value as the ifIndex object,
defined in [4,6], for the same interface."
::= { ifExtnsTestEntry 1 }
SNMP Working Group [Page 9]
^L
RFC 1229 Interface MIB Extensions May 1991
ifExtnsTestCommunity OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the name of the SNMP
authentication community [5] which was used
to authenticate the SNMP Message which invoked
the current or most recent test on this
interface. If the authentication community
is unknown or undefined, this value contains
the zero-length string."
::= { ifExtnsTestEntry 2 }
ifExtnsTestRequestId OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the value of the
request-id field in the SNMP PDU [5] which
invoked the current or most recent test on
this interface. If the request-id is
unknown or undefined, this value contains
the value zero."
::= { ifExtnsTestEntry 3 }
ifExtnsTestType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A control variable used to start and stop
operator-initiated interface tests.
Most OBJECT IDENTIFIER values assigned
to tests are defined elsewhere, in associ-
ation with specific types of interface.
However, this document assigns a value for
a full-duplex loopback test, and defines the
special meanings of the subject identifier:
noTest OBJECT IDENTIFIER ::= { 0 0 }
When the value noTest is written to this
object, no action is taken unless a test is
in progress, in which case the test is
aborted. Writing any other value to this
object is only valid when no test is
SNMP Working Group [Page 10]
^L
RFC 1229 Interface MIB Extensions May 1991
currently in progress, in which case the
indicated test is initiated.
Note that noTest is a syntactically valid
object identifier, and any conformant
implementation of ASN.1 and BER must be able
to generate and recognize this value.
When read, this object always returns
the most recent value that ifExtnsTestType
was set to. If it has not been set since
the last initialization of the network
management subsystem on the agent, a value
of noTest is returned."
::= { ifExtnsTestEntry 4 }
wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 }
-- full-duplex loopback test
testFullDuplexLoopBack OBJECT IDENTIFIER ::=
{ wellKnownTests 1 }
ifExtnsTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the result of the most
recently requested test, or the value
none(1) if no tests have been requested since
the last reset. Note that this facility
provides no provision for saving the results
of one test when starting another, as could
be required if used by multiple managers
concurrently."
::= { ifExtnsTestEntry 5 }
ifExtnsTestCode OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
SNMP Working Group [Page 11]
^L
RFC 1229 Interface MIB Extensions May 1991
"This object contains a code which contains
more specific information on the test result,
for example an error-code after a failed
test. Error codes and other values this
object may take are specific to the type of
interface and/or test. However, one subject
identifier:
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
for use if no additional result code is
available.
Note that testCodeUnknown is a
syntactically valid object identifier, and
any conformant implementation of ASN.1 and
the BER must be able to generate and
recognize this value."
::= { ifExtnsTestEntry 6 }
-- Generic Receive Address Table
--
-- This group of objects is mandatory for all types of
-- interfaces which can receive packets/frames addressed to
-- more than one address.
ifExtnsRcvAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains an entry for each
address (broadcast, multicast, or uni-cast)
for which the system will receive packets/
frames on a particular interface. When an
interface is operating in promiscuous mode,
entries are only required for those addresses
for which the system would receive frames
were it not operating in promiscuous mode."
::= { ifExtensions 3 }
ifExtnsRcvAddrEntry OBJECT-TYPE
SYNTAX IfExtnsRcvAddrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of objects identifying an address
for which the system will accept packets/
SNMP Working Group [Page 12]
^L
RFC 1229 Interface MIB Extensions May 1991
frames on a particular interface."
INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress }
::= { ifExtnsRcvAddrTable 1 }
IfExtnsRcvAddrEntry ::=
SEQUENCE {
ifExtnsRcvAddrIfIndex
INTEGER,
ifExtnsRcvAddress
PhysAddress,
ifExtnsRcvAddrStatus
INTEGER
}
ifExtnsRcvAddrIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of ifIndex, defined in [4,6], of an
interface which recognizes this entry's
address."
::= { ifExtnsRcvAddrEntry 1 }
ifExtnsRcvAddress OBJECT-TYPE
SYNTAX PhysAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An address for which the system will accept
packets/frames on this entry's interface."
::= { ifExtnsRcvAddrEntry 2 }
ifExtnsRcvAddrStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
invalid(2),
volatile(3),
nonVolatile(4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object has the value nonVolatile(4)
for those entries in the table which are
valid and will not be deleted by the next
restart of the managed system. Entries
having the value volatile(3) are valid
SNMP Working Group [Page 13]
^L
RFC 1229 Interface MIB Extensions May 1991
and exist, but have not been saved, so
that will not exist after the next
restart of the managed system. Entries
having the value other(1) are valid and
exist but are not classified as to whether
they will continue to exist after the next
restart. Entries having the value invalid(2)
are invalid and do not represent an address
for which an interface accepts frames.
Setting an object instance to one of
the values other(1), volatile(3), or
nonVolatile(4) causes the corresponding
entry to exist or continue to exist, and
to take on the respective status as regards
the next restart of the managed system.
Setting an object instance to the value
invalid(2) causes the corresponding entry
to become invalid or cease to exist.
It is an implementation-specific matter
as to whether the agent removes an
invalidated entry from the table.
Accordingly, management stations must be
prepared to receive tabular information
from agents that corresponds to entries not
currently in use. Proper interpretation of
such entries requires examination of the
relevant ifExtnsRcvAddrStatus object
instance."
DEFVAL { volatile }
::= { ifExtnsRcvAddrEntry 3 }
END
6. Acknowledgements
Most of the MIB objects defined in this document were originally
proposed as a part of a MIB for management of IEEE 802.5 Token Ring
networks, as prepared by:
Eric B. Decker, cisco Systems, Inc., and
Richard Fox, Synoptics Inc.
In addition, the comments of the following individuals are
acknowledged:
James R. Davin, MIT-LCS
Stan Froyd, ACC
Frank Kastenholz, Racal Interlan
SNMP Working Group [Page 14]
^L
RFC 1229 Interface MIB Extensions May 1991
Dave Perkins, 3Com
Marshall T. Rose, PSI
Bob Stewart, Xyplex
David Waitzman, BBN
Wengyik Yeong, PSI
7. References
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] Rose M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
Performance Systems International, March 1991.
[7] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems,
March 1991.
8. Security Considerations
Security issues are not discussed in this memo.
SNMP Working Group [Page 15]
^L
RFC 1229 Interface MIB Extensions May 1991
9. Author's Address
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com
SNMP Working Group [Page 16]
^L
|