CURRENT_MEETING_REPORT_



Reported by Amatzi Ben-Artzi/ 3Com

Minutes of February 22, 1989

The Lan Manager MIB working group met Wednesday, 2/22/89 in Sunnyvale,
CA for our first meeting.  The meeting was very productive and generated
a long list of output and action items.  Below is a summery of the
meeting and major decisions reached.

The minutes cover seven topics:

  1. Introduction
  2. The Group's Objectives
  3. To Proxy or Not?
  4. Initial Documents and Editors
  5. Relationship to the MIB WG
  6. Mailing List
  7. Timetable

Introduction to the Lan Manager.

Amatzia gave a short introduction on the Lan Manager.  The emphasis is
on the management interoperability issues between the Lan Manager as a
standard in the workgroup environment and the standards being developed
in the ``enterprise" environment.  As both are based on the TCP/IP it is
important that they can cooperate.  Microsoft offered to provide a more
extensive overview of the LanManager if people will find it useful.
Please send me feedback on this one!!

Group's Objective

The objective of the group is to define the MIB (and relevant related
mechanisms) needed to allow management overlap between the workgroup
environment (Lan Manager based) and the enterprise environment (based on
TCP/IP management).

We found that it translated into four basic areas:


  1. Define a set of management information out of the existing Lan
     Manager objects to allow for useful management from a TCP/IP based
     manager.
  2. Define extensions to the TCP/SMI where appropriate.
  3. Develop requirements for additional network management information,
     as needed, and work to extend the Lan Manager interfaces to support
     such information.
  4. Define the mechanisms of exchange of management information between
     clients and servers so that proxies can be developed.

                                   1






Proxy or Not?

We concluded that the manager need to have access to the management
information in every client in a direct way.  It amounts to the
following:


   o A client may have a Management/TCP stack.
   o A client may be supported by a server that acts as ``proxy'' on his
     behalf.
   o The manager need not be aware of which one of the techniques above
     is being used in the workgroup.


However, we recognized that in the proxy mode, the server may have two
types of objects:  server resident, and client resident.  For the second
type, a server-client mechanism has to be developed to allow the
implementation of a proxy.

Initial Documents and Editors

The following documents have been identified as needed.  Initial editors
were also selected.


   o SMI Extensions:  Pranati Kapadia, HP
   o MIB Objects:  Jim Greuel, HP
   o NDIS Extensions (not assigned)
   o Transport APIs for NM Information access (not assigned)
   o Client-Server management protocol (Amatzia Ben-Artzi, 3Com)


Relationship to the MIB group

A real objective of this MIB group is to work under the ``BIG'' MIB
group.  One implication was that the MIB specification should follow the
1066 RFC (specifying all attributes as ``objects'') with an appendix
that actually describe the containment relationship (Same technique that
was used in the CMOT RFC to re-state the supported MIB)

A big question mark is SMI. Can we live with the guideline of ``no SMI
extensions'' ?  We shall address it when the first required extension
shows.  We do know, however, that EVENTS (or alerts, or alarms) are a
big issue, but we where not sure if this was an SMI issue or what.

We also feel very strongly that the recommendation of the previous MIB
group should be followed:  Lan Manager should be assigned a number of
the MIB (Like TCP, IP, or CMOT) and define it objects under this branch.
Then, bring them forward to the larger group for discussion and
approval.  ONLY EXPERIMENTAL OBJECTS SHOULD BE PLACED UNDER THE
EXPERIMENTAL BRANCH.


                                   2






The whole branch is OPTIONAL, so people who don't implement it do not
have to worry about conformance.  It seems like we would want, for
simplicity of conformance, at least initially, to say:  the branch is
optional, but if you implement it, it is ALL mandatory.  The target is
roughly 20 - 30 objects initially.

Mailing list

Welcome a new mailing list:

LanManWG@spam.istc.sri.com

As usual, there is also a LanManWG-request.

Timetable

March 17:  First draft proposal for MIB objects in the mail.

March 31:  Comments are due back to the editor

April 11-14:  IETF meeting.  We shall meet sometime there to discuss the
proposed draft (currently planned as a half-day meeting)

Thanks to all the participants for a very effective meeting.

Attendees

aguilar@istc.sri.com                     SRI
jimg@hpcnd.hp.com                        H-P
...!ucbvax!mtxinu!excelan!ramesh          Excelan
...microsoft!henrysa                     Microsoft
geo@ub.com                               Ungerman-Bass
kapadia@hpda.hp.com                      H-P
davep@esd.3com.com                       3Com
jcham@mbunix.mitre.org                    Mitre
Hunter@nmfecc.arpa                       Laurence Livermore Lab
...!ucbvax!mtxinu!excelan!pramod          Excellan
jonab@cam.unisys.com                     Unisys
kzm@twg.com                              The Wollongong Group
amatzia@spd.3com.com                     3Com



                                   3