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
|
Network Working Group V. Cerf
Request for Comments: 1052 NRI
April 1988
IAB Recommendations for the Development of
Internet Network Management Standards
Status of this Memo
This memo is intended to convey to the Internet community and other
interested parties the recommendations of the Internet Activities
Board (IAB) for the development of network management protocols for
use in the TCP/IP environment. The memo does NOT, in and of itself,
define or propose an Official Internet Protocol. It does reflect,
however, the policy of the IAB with respect to further network
management development in the short and the long term. Distribution
of this memo is unlimited.
Background
At the IAB meeting on 21 March 88 in videoconference, the report of
the Ad Hoc Network Management Review Committee was reviewed. The
recommendations of the committee were endorsed by the IAB and
direction given to the chairman of the Internet Engineering Task
Force to take the necessary steps to implement the recommendations.
The IAB expressed its gratitude for the efforts of the HEMS, SNMP and
CMIP/CMIS working groups and urged that parties with technical
interest in the outcome of the network management working groups
convey their ideas and issues to the relevant working group chairmen.
The IETF chairman was directed to form two new working groups, one of
which would be responsible for the further specification and
definition of elements to be included in the Management Information
Base (MIB). The other would be responsible for defining extensions
to the Simple Network Management Protocol to accommodate the short-
term needs of the network vendor and operator communities. The
longer-term needs of the Internet community are to be met using the
ISO CMIS/CMIP framework as a basis. A working group of the IETF
exists for this work and would continue its work, coordinating with
the two new groups and reporting to the IETF chairman for guidance.
The output of the MIB working group is to be provided to both the
SNMP working group and the CMIS/CMIP ["Netman"] working group so as
to assure compatibility of monitored items for both network
management frameworks.
Cerf [Page 1]
^L
RFC 1052 Internet Management April 1988
Specific Recommendations
The IAB recommends that the Simple Network Management Protocol be
adopted as the BASIS for network management in the short-term.
Extensions may be required to the existing SNMP specification to
accommodate additional data types or to deal with functional or
performance issues arising as multiple SNMP implementations are
deployed and applied, especially in multi-vendor applications.
The SNMP working group constituted by the IETF is charged with
considering requirements not met by the present SNMP definition,
defining extensions, if necessary, to accommodate these needs, and
preparing revisions of the SNMP specifications to address any new
extensions.
The IAB urges the working group to be extremely sensitive to the need
to keep SNMP simple, to work quickly to come to concensus on any
revisions needed and to promulgate expeditiously the results of its
work in one or more RFCs within the next 90 days. The IETF chairman
is responsible for resolving disagreements arising if they cannot be
resolved within the working group and is instructed to escalate
problems quickly to the IAB should resolution not be forthcoming.
The IAB further recommends that the MIB working group begin its work
equally expeditiously, taking as its starting inputs the MIB
definitions found in the existing High-Level Entity Management
Systems (HEMS) RFC-1024, the SNMP IDEA-11, and CMIS/CMIP IDEAs.
It is the intention of the IAB that the MIB definitions be applied
both to the SNMP system in the short term and CMIS/CMIP for TCP/IP in
the longer term. The three working groups will have to coordinate
their efforts carefully to achieve these objectives:
1. Rapid convergence and definition for SNMP.
2. Rapid convergence and definition for the TCP/IP MIB.
3. Provision for transitioning from SNMP to CMIP/CMIS.
4. Early demonstration of the CMIP/CMIS capability using the
TCP/IP MIB.
The IAB remains extremely interested in progress towards these goals
and intends to have representation, whenever possible, in the various
working group and IETF plenary activities.
Cerf [Page 2]
^L
RFC 1052 Internet Management April 1988
REPORT OF THE AD HOC NETWORK MANAGEMENT REVIEW COMMITTEE
Edited by Vinton Cerf, Chairman
March 1988
EXECUTIVE SUMMARY
On 29 February 88, an ad hoc committee was convened to review the
network management options for the Internet in particular and the
TCP/IP protocol suite in general. This meeting was called at the
request of the Internet Activities Board in the course of exercising
its responsibilities to the Federal Research Internet Coordinating
Council (FRICC) and by the MITRE Corporation as a consequence of its
work for the U.S. Air Force on the ULANA project.
At the conclusion of the one day meeting, it was agreed that the
following recommendations be forwarded to the Internet Activities
Board chairman, Dr. David C. Clark, for consideration at the next IAB
meeting scheduled for 21 March:
1. In the short term, the Internet community should adopt and
adapt the Simple Network Management Protocol (SNMP) for use as the
basis of common network management throughout the system.
(Rationale: The software is available and in operation.)
2. In the longer term, the Internet research community and the
vendors should develop, deploy and test a network management
system based on the International Standards Organization (ISO)
Common Management Information Services/Common Management
Information Protocol (CMIS/CMIP).
(Rationale: The Internet community can take the high ground in
protocol development by virtue of the experimental environment in
which it can operate. Recommendations to the ISO from this
community, the IAB and the vendors will carry great weight if they
are in the language of the ISO common network management system
and if they are rooted in actual experience with implementation
and use in the field.)
3. Responsibility for the SNMP effort should be placed in the
hands of an IETF task force.
(Rationale: Eliminate vendor-specific bias or control over the
SNMP and its evolution and harmonize inputs from the Internet
community.)
Cerf [Page 3]
^L
RFC 1052 Internet Management April 1988
4. As a high priority effort, define an extended Management
Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into
closer conformance with the MIB defined for the experimental
HighLevel Entity Management System (HEMS).
(Rationale: The HEMS effort produced a very thorough and widely-
discussed set of elements to monitor, along with definitions of
the semantics of these elements. The current SNMP definitions are
more restricted and the CMIP definitions less precise.
Implementation of SNMP in a timely and useful fashion through the
Internet cannot be satisfactorily completed without such a
definition of information elements in hand.)
The ad hoc committee therefore recommends immediate action by the
IAB on all four of these points. It should be noted that this
resolution would not have been possible in such a timely way
without the statesman-like efforts of Craig Partridge who, at the
end of the day, recommended that the HEMS effort be withdrawn from
consideration so as to pave the way for an Internet-wide
agreement. In consideration of this unselfish act, the ad hoc
committee urges the IAB to approve the recommendations above and
to instruct the IETF to move quickly to accept and act on the SNMP
items requiring completion.
1. INTRODUCTION
During its development history, the community of researchers,
developers, implementors and users of the DARPA/DoD TCP/IP protocol
suite have experimented with a wide range of protocols in a variety
of different networking environments. The Internet has grown,
especially in the last few years, as a result of the widespread
availability of software and hardware supporting this system. The
scaling of the size and scope of the Internet and increased use of
its technology in commercial applications has underscored for
researchers, developers and vendors the need for a common network
management framework within which TCP/IP products can be made to
work.
In recognition of this need, several efforts were started to develop
network management concepts which might be applied to the Internet
and to the internet technology in general. Three of these efforts
had made sufficient progress by the end of 1987 that it became clear
that some choices had to be made or the community would find itself
with a set of incompatible network management tools. These efforts
included the High-Level Entity Management System (HEMS), the Simple
Gateway Monitoring Protocol (SGMP) and the Common Management
Information Service/Protocol.
Cerf [Page 4]
^L
RFC 1052 Internet Management April 1988
The latter is an ISO initiative which was adapted to Internet use in
a vendor-initiated effort. The HEMS work was carried out in the
context of the Gateway Monitoring group of the Internet Engineering
Task Force. The SGMP effort was carried out largely in the practical
context of the NYSERNET and SURAnet regional networks which needed
network management facilities to operate satisfactorily.
Independent of the general Internet situation and requirements, the
U.S. Air Force has been pursuing a Universal Local Area Network
Architecture (ULANA) for its own use. The principal agent for the
development of the ULANA specifications is the MITRE Corporation.
Faced with several long and short term network management options,
the MITRE ULANA specification team initiated an effort with
substantial vendor participation called the NETMAN working group.
It was against this fabric of various options that the IAB appointed
a chairman to convene a review committee to discuss these various
options and to make recommendations on long and short term choices.
The MITRE Corporation co-sponsored this work to further its aims in
the specification of the ULANA design.
Reference material listed at the end of this report was provided in
advance of the meeting.
2. DISCUSSION
Rather than attempting to produce minutes of the meeting, this
section summarizes in very high level terms the substance of the
discussion which took place during most of the meeting. Presentation
viewgraphs can be made available to IAB/FRICC members interested in
their contents.
The agenda was followed fairly closely with the technical
presentations made in the order suggested: HEMS, SGMP, CMIP/CMIS.
The HEMS effort has established a benchmark for other network
management work in the sense that it took a comprehensive conceptual
view of the problem and went into considerable detail on the design
of the underlying management information database, the mechanics of
access to and reporting of information, considerations of scaling and
performance (e.g., Query Language vs Remote Procedure Call style),
definition of information required and so on. HEMS has been
implemented in an experimental version from which some encouraging
performance measurements were taken. Serious vendor interest in this
protocol was expressed by Cisco Systems and implementation efforts
were under way as of the meeting.
The SGMP effort, though somewhat less documented, was rooted in a
Cerf [Page 5]
^L
RFC 1052 Internet Management April 1988
practical need for network management tools for the NYSERNET,
SURAnet, and, by extension, other components of the Internet.
Implementations of it exist, in its RFC-1028 form (probably with some
experimental extensions based on experience gained from the initial
work), and are in use today. Serious vendor support for this work is
found at Proteon and, more recently, in the NSFNET effort by MERIT,
IBM and MCI, specifically in the IBM Network Switching System (NSS)
nodes. Applications running above SGMP exist and provide useful
monitoring information, presented in easily grasped form.
The ISO CMIS/CMIP effort, voluminously documented, has had almost no
implementation as yet. Reports from Unisys/SDC about an experimental
implementation were heard at the meeting. There is substantial
momentum in the international community for the adoption of this
service and protocol suite for network management. The Draft
Proposal is out for its second ballot (it failed to make Draft
International Standard on its first ballot). There is vocal vendor
support for this work, based on the premise that ultimately the ISO
protocol suite will propagate and the vendors must support it.
In general, all of the network management proposals make use of the
Abstract Syntax Notation 1 (ASN.1) which has emerged from the ISO
efforts as a kind of lingua franca for the representation of
arbitrary data structures. The data types used in the SGMP
Management Information Base (aspects of network components to be
monitored) are the most restricted of the three proposals, confined
to integers and octet strings only. HEMS has the most extensive
Management Information Base and added some rather unique ideas such
as self-knowledge about what could be monitored so that a
device/unit/component could respond to a query asking "what can you
tell me about yourself and your operation and how is it represented?"
(!). CMIS/CMIP is probably the broadest in scope, but less precisely
defined at this point, with respect to information which should be
monitored. The draft RFCs referenced above relating to the CMIS/CMIP
concerning items to be monitored are still in the definition stages.
A point made strongly by the HEMS team was their concern that a
Remote Operations basis for CMIP may not scale well into a very large
Internet which needs to be monitored from a few central sites.
Remote Operations is a term used by ISO and means, roughly, what the
Internet community has long referred to as Remote Procedure Calls.
If each atomic action is a Remote Procedure Call, the HEMS team
argues that increasing Internet size and potential delays may vastly
constrain the amount and timeliness of information which can be
collected. The HEMS design uses, instead, a general query language
approach which permits more elaborate, multi-variable queries to be
formulated at the requesting site and processed at the responding
site(s).
Cerf [Page 6]
^L
RFC 1052 Internet Management April 1988
Although it does substantial injustice to the very lucid and helpful
presentations by representatives of each of the network management
research groups, I have chosen to leave out much of the detail from
this report and move directly to the points of agreement which were
reached by the Committee.
3. POINTS OF AGREEMENT
(i) Future Internet development is a joint interest of the R&D
community, the vendor community and the user community.
[Editor's comment: The development of the Internet is now not only
dependent on research work, but on the hardware and software of
vendors selling to both commercial ("internet") and the research
environment ("Internet"). Moreover, the Internet users are not all
concerned with network research; many of the components of the
Internet are based on vendor-supplied and supported subsystems.]
(ii) We still don't have a common understanding of what
[Inter]Network Management really is.
[Editor's comment: We haven't tried to manage the Internet as a
collection of autonomous systems in an effective way, yet.]
(iii) We will learn what [Inter]Network Management is by doing it.
(a) in as large a scale as is possible
(b) with as much diversity of implementation as possible
(c) over as wide a range of protocol layers as possible
(d) with as much administrative diversity as we can stand.
(iv) There are more than HEMS, SGMP and CMIS/CMIP as potential
candidates:
HEMS, SGMP, CMIS/CMIP [multiple profiles], NETVIEW,
LANMANAGER, Network Computing Forum "Fat Document"...
[Editor's comment: The multiplicity of options is motivation for
coalescing the energy of the Internet environment around single short
and long term foci so as to make more substantial progress in really
understanding network management per point (iii).]
(v) Define the Management Information Base for TCP/IP suite NOW!
(vi) Seek a seat for IETF on ANSI, ISO and/or CCITT!!!
Cerf [Page 7]
^L
RFC 1052 Internet Management April 1988
[Editor's comment: This may actually be feasible.]
(vii) Define a CMIS interface to any of the surviving network
management schemes so as to provide a migration path to ISO.
4. RESOLUTION AND CONCLUSIONS
In a dramatic act of statesmanship, Craig Partridge volunteered that
the HEMS proposal be dropped in favor of the other two efforts, SGMP
and CMIS/CMIP - IF THIS WOULD LEAD TO INTERNET-WIDE AGREEMENT ON A
NETWORK MANAGEMENT PLAN FOR THE SHORT AND LONG TERM.
A rationale for the long term was proposed, based on the assumption
that the ISO initiatives, and the U.S. Government issuance of the
GOSIP guidelines, would ultimately require at least the Government
users, and hence their vendor suppliers, to use ISO-based protocols
and tools. In this rationale, the Internet research community and its
vendors would "take the high ground" in network management by
implementing the CMIS/CMIP on top of the TCP/IP protocol suite and
deploy it widely for experimental use in the Internet.
Neither the ISO nor any other organization, including the Corporation
for Open Systems (COS) has anything close to the laboratory in large
that the Internet represents. By taking the initiative, the Internet
working groups can establish credibility based on experience which
will make it far more feasible to affect the evolution of the ISO
network management and other related efforts. The Internet community
will be able to speak with authority about problems with the design
or definition of CMIS/CMIP based on real implementation experience
and use, rather than solely analytic means.
In the short term, however, the Internet desperately needs tools to
apply to the operational management problems associated with its
rapid growth. Given the present state of advanced implementation of
the SGMP and its relative simplicity, the general agreement was that
SGMP (or its re-named successor, SNMP) should be quickly brought to
more complete specification for widespread implementation and use.
In short, the ad hoc committee recommends:
1. In the short term, the Internet community should adopt and
adapt the Simple Network Management Protocol (SNMP) for use as the
basis of common network management throughout the system.
(Rationale: The software is available and in operation.)
2. In the longer term, the Internet research community and the
vendors should develop, deploy and test a network management
Cerf [Page 8]
^L
RFC 1052 Internet Management April 1988
system based on the International Standards Organization (ISO)
Common Management Information Services/Common Management
Information Protocol (CMIS/CMIP).
(Rationale: The Internet community can take the high ground in
protocol development by virtue of the experimental environment in
which it can operate. Recommendations to the ISO from this
community, the IAB and the vendors will carry great weight if they
are in the language of the ISO common network management system
and if they are rooted in actual experience with implementation
and use in the field.)
3. Responsibility for the SNMP effort should be placed in the
hands of an IETF task force.
(Rationale: Eliminate vendor-specific bias or control over the
SNMP and its evolution and harmonize inputs from the Internet
community.)
4. As a high priority effort, define an extended Management
Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into
closer conformance with the MIB defined for the experimental
HighLevel Entity Management System (HEMS). (Rationale:
The HEMS effort produced a very thorough and widely-discussed set
of elements to monitor, along with definitions of the semantics of
these elements. The current SNMP definitions are more restricted
and the CMIP definitions less precise. Implementation of SNMP in a
timely and useful fashion through the Internet cannot be
satisfactorily completed without such a definition of information
elements in hand.)
Cerf [Page 9]
^L
RFC 1052 Internet Management April 1988
MEMBERS OF THE AD HOC NET MANAGEMENT REVIEW COMMITTEE
Amatzia Ben-Artzi
Sytek Corp.
1225 Charleston Rd.
Mountain View, CA 94043
Amatzia@amadeus.stanford.edu
Bob Braden
USC-ISI
4676 Admiralty Way
Marina del Rey, CA 90292
braden@isi.edu
Jeff Case
University of Tennessee
200 Stokely Management Center
Knoxville, TN 37996
case@utkcs2.cs.utk.edu
Vint Cerf - Chairman
Corp. for National Research Initiatives
1895 Preston White Dr., Suite 100
Reston, VA 22091
(703) 620-8990
Cerf@ISI.EDU
Chuck Davin
Proteon, Inc.
2 Technology Dr.
Westborough, MA 01536
jrd@monk.proteon.com
Stephen Dunford
UNISYS Corp.
System Development Corporation
5151 Camino Road
Camarillo, CA 93010
dunford@cam.unisys.com
Mark Fedor
NYSERNET
125 Jordan Road
Troy, NY 12180
fedor@nisc.nyser.net
Cerf [Page 10]
^L
RFC 1052 Internet Management April 1988
Phill Gross - IETF Chairman
MITRE Corporation
1820 Dolley Madison Blvd.
McLean, VA 22012
Gross@Gateway.MITRE.Org
Lee LaBarre
MITRE Corporation
Burlington Road
Bedford, MA 01730
cel@mitre-bedford.arpa
Dan Lynch
Advanced Computing Environments
480 San Antonio Rd.
Mountain View, CA 94040
Lynch@isi.edu
Jim Mathis
Apple Computer, Inc.
MS 27-0
20525 Mariani Ave.
Cupertino, CA 95014
Mathis@Apple.com
Craig Partridge
BBN Labs
10 Moulton St.
Cambridge, MA 02238
craig@bbn.com
Marshall T. Rose
The Wollongong Group, Inc.
1129 San Antonio Road
Palo Alto, CA 94043
MRose@twg.com
Greg Satz
Cisco Systems
1360 Willow Rd., Suite 201
Menlo Park, CA 94301
satz@cisco.com
Martin Lee Schoffstall
NYSERNET
125 Jordan Road
Troy, NY 12180
schoff@nisc.nyser.net
Cerf [Page 11]
^L
RFC 1052 Internet Management April 1988
Glenn Trewitt
Center for Integrated Systems, Room 216
Stanford University
Stanford, CA 94305
Trewitt@amadeus.stanford.edu
MEETING LOCATION: San Diego Supercomputer Center, UC San Diego
LOCAL ARRANGEMENTS: Paul Love, SDSC
MEETING DATE: 29 February 1988
AGENDA ITEMS:
0900 Introductions and Objectives/Cerf
0915 HEMS: Craig Partridge and Glenn Trewitt
1030 Break
1045 SGMP - Jeff Case
1145 CMIP/CMIS - Amatzia Ben-Artzi
1245 Lunch Break
1430 TCP/IP and ISO: Politics, Technology, Penetration/Cerf
1530 Break
1545 Tradeoffs among alternate paths (Discussion)
1700 Resolution of alternatives
1730 Summary of conclusions/actions
1800 Adjourn
Cerf [Page 12]
^L
RFC 1052 Internet Management April 1988
REFERENCES
The following reference material was provided in advance of the
meeting. Note that some of the citations include informal
descriptors (such as IDEA numbers or DRAFT letter codes), for
example, IDEA-13 or DRAFT-AAAA. IDEA notes may be updated from time
to time reusing the same number. The IDEA notes are the working
notes of the Engineering Task Force. The DRAFT is a temporary
notation and may not be meaningful for more than a few months.
HEMS
(1) Craig Partridge, "A UNIX Implementation of HEMS", USENIX,
February 1988. [Available from C. Partridge, BBN Labs]
(2) Craig Partridge and Glenn Trewitt, "The High-Level Entity
Management System", RFC-1021.
(3) Craig Partridge and Glenn Trewitt, "The High-Level Entity
Management Protocol", RFC-1022.
(4) Glenn Trewitt and Craig Partridge, "The HEMS Monitoring and
Control Language", RFC-1023.
(5) Craig Partridge and Glenn Trewitt, "HEMS Variable
Definitions", RFC-1024.
(6) Craig Partridge and Glenn Trewitt, "The High-Level Entity
Management System", IEEE Network magazine, March 1988.
SGMP/SNMP
(1) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
Simple Gateway Monitoring Protocol", RFC-1028, November 1987.
(2) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
Simple Network Management Protocol", IDEA-11, February 1988,
obsoletes RFC-1028 when issued.
(3) Jeffrey R. Case, James R. Davin, Mark S. Fedor, Martin L.
Schoffstall, "Introduction to the Simple Gateway Monitoring
Protocol", IEEE Network Magazine, March 1988.
CMIS/CMIP
(1) Amatzia Ben-Artzi, "Network Management for TCP/IP Network: An
Overview", IDEA-12, February 1988.
Cerf [Page 13]
^L
RFC 1052 Internet Management April 1988
(2) Lee LaBarre, " TCP/IP Network Management Implementors
Agreements", IDEA-13, January 1988.
(3) Lee LaBarre, "Data Link Layer Management Information:
MAC802.3", DRAFT-MMMM, February 1988.
(4) Lee LaBarre, "Network Layer Management Information: IP",
DRAFT-NNNN, February 1988.
(5) Marshall Rose, "ISO Presentation Services on Top of TCP/IP-
based Internets", DRAFT-PPPP, February 1988.
(6) Lee LaBarre, "Structure and Identification of Management
Information for the Internet", DRAFT-SMI, February 1988.
(7) Lee LaBarre, "Transport Layer Management Information: TCP",
DRAFT-TTTT, February 1988.
(8) Lee LaBarre, "Transport Layer Management Information: UDP",
DRAFT-UUUU, February 1988.
(9) ISO/IEC JTC 1/21 N 2058, "2nd DP 9595-1 Information Processing
Systems - Open Systems Interconnection - Management Information
Service Definition - Part 1: Overview", December 1987.
(10) ISO/IEC JTC 1/21 N 2059, "2nd DP 9595-2, Information
Processing Systems - Open Systems Interconnection - Management
Information Service Definition - Part 2: Common Management
Information Service Definition", December 1987.
(11) ISO/IEC JTC 1/21 N 2060, "2nd DP 9596-2, Information
Processing Systems - Open Systems Interconnection - Management
Information Protocol Specification - Part 2: Common Management
Information Protocol", December 1987.
(12) ISO/TC97/SC21/WG4 N 472, "US Comments on the Proposal for
Extension of the Common Management Information Services and
Protocol: Creation and Deletion Functions", November 1987.
(13) JTC1/SC21/WG4 N 482, "Proposal to extend M-Set and M-
Confirmed-Set to allow adding and removing values of a multi-
valued attribute", November 1987.
(14) S. Mark Klerer, "The OSI Management Architecture: An
Overview", IEEE Network Magazine, March 1988.
Cerf [Page 14]
^L
|