NM "State of the Area" Report

[IETF NM-AD <[e-mail]>]

			The NM Area Directorate
			-----------------------


The NM area has a Directorate.  The role of the NM-Directorate is three-fold:

    - to consider strategic evolution of the SNMP framework;

    - to provide architectural and engineering guidance to working groups
      which develop MIB modules, at the earliest possible stages; and,

    - to help the NM AD in reviewing submitted I-Ds.

The current NM-Directorate membership is:

    Fred Baker		<[e-mail]>
    Tracy Brown		<[e-mail]>
    Ted Brunner		<[e-mail]>
    Jeff Case		<[e-mail]>
    Deirdre Kostick	<[e-mail]>
    Keith McCloghrie	<[e-mail]>
    Dave Perkins	<[e-mail]>
    Bob Stewart		<[e-mail]>
    Kaj Tesink		<[e-mail]>
    Steve Waldbusser	<[e-mail]>

The NM-Directorate is an advisory entity and has no standards-setting
powers.  The meetings of the NM-Directorate are closed.  The members of the
NM-Directorate are appointed by the NM AD.

For the first role, strategic evolution, the NM-Directorate considers "what
needs to be done next".  Of course, strategic issues may also be pursued in
BOF's at IETF meetings, independently of the NM-Directorate.  Alternately,
you can send a message to me and I will forward it to the NM-Directorate.

For the second role, whenever a WG will be developing a MIB module as a part
of their chartered activities, a member of the NM-Directorate will be asked
to participate in that WG, to provide expert consultation with respect to
SNMP, MIB module design, and standards development.  This assignment will be
a matter of record in the charter.

Finally, for the third role, once a MIB module is completed by a WG, the IESG
asks the NM-Directorate to review the document.  My hope is that this will be
a pro-forma review--after all, a member of the NM-Directorate should have
been assigned to help the WG during their development effort.

		      Policy on SNMPv2 and MIB modules
		      --------------------------------

There are two network management frameworks for the Internet community.
The Internet-standard Network Management Framework is based on SNMPv1:

	1155	Structure of Management Information
	1212	Concise MIB Definitions
	1157	Simple Network Management Protocol
	1215	A Convention for Defining Traps

All of these documents are full Internet standards, with the exception
of 1215 which is an informational document.

SNMPv2 provides the basis for the successor framework:

	1441	Introduction to SNMPv2
	1442	SMI for SNMPv2
	1443	Textual Conventions for SNMPv2
	1444	Conformance Statements for SNMPv2
	1445	Administrative Model for SNMPv2
	1446	Security Protocols for SNMPv2
	1447	Party MIB for SNMPv2
	1448	Protocol Operations for SNMPv2
	1449	Transport Mappings for SNMPv2
	1450	MIB for SNMPv2
	1451	Manager-to-Manager MIB
	1452	Coexistence between SNMPv1 and SNMPv2

All of these documents are proposed Internet standards.

Prior to the entry of SNMPv2 onto the standards-track, MIB modules were
written using the SNMPv1 SMI.  There is a transition policy for writing MIB
modules.

Until the SNMPv2 SMI is a draft Internet-standard:
    All MIB modules submitted by a WG for standardization must use the
    SNMPv2 SMI.  However, the following SNMPv2 syntaxes may not be
    used: BIT STRING, NsapAddress, Counter64, or UInteger32 (either directly
    or through a textual convention).  Further, any existing MIB modules
    updated by a WG must be evaluated and possibly changed to minimize
    the transformation necessary to use the SNMPv2 SMI.  Finally, this
    policy does not apply if the MIB module is being submitted for
    consideration as a full standard.

Once the SNMPv2 SMI is a draft Internet-standard:
    All MIB modules submitted by a WG for standardization must use the
    SNMPv2 SMI, and are allowed to use any SNMPv2 syntax.  Further, any
    MIB existing modules on the standards-track which use the SNMPv1
    SMI will be modified to use the SNMPv2 SMI, making the smallest
    possible set of changes.  In most cases, this means that only the
    IMPORTS statement of the MIB module will change.

Note well:
    Whenever a WG works on a MIB module (either developing it or
    advancing it along the standards-track), that WG will be
    responsible for producing a conformance statement for that MIB.

		      Automated Checking of MIB modules
		      ---------------------------------


A MIB module syntax checking facility is available.  Send the MIB
module in the body of a mail message to:

	[e-mail]

or

	[e-mail]

An automated reply will be returned.  Be sure to IMPORT the OBJECT-TYPE
macro from SNMPv2-SMI, e.g.,

	IMPORTS
	    ...
	    OBJECT-TYPE ...
		FROM SNMPv2-SMI;


Once a MIB module compiles successfully, a check can be made to see if
it can be converted to V1-format.  Send the MIB module in the body
of a mail message to:

	[e-mail]

An automated reply will be returned containing a V1-format of the MIB
module.

	      Policy on Standards for SNMP Agent Extensibility
	      ------------------------------------------------

Although there is considerable interest in IETF standardization of
either an agent extensibility protocol or API or both, this is outside
the scope of IETF standardization.

There are two reasons for this:

1. A key motivation for developing a standard in this area is the
perception that a standard will allow sub-agent implementors to develop
according to a single sub-agent API.  In the best case, such an API
would be highly inefficient on many platforms as it must work with a
reasonably chosen lowest common denominator technology.  In the worst
case, such an API would be impossible to standardize because of the wide
differences in platform capabilities for interprocess communications.

2. An SNMP MIB view is an self-consistent data set, in which only the
external aspects are standardized (i.e., the behavior of operations upon
the variables within a MIB view).  A standard for extensible SNMP agents
must, by definition, specify internal aspects of a MIB view.  This is
known to have serious architectural impacts as manifested, e.g., by the
"sysUpTime problem".  It is unclear as to what other problems are
introduced when the internal properties of MIB views are specified.
It is unrealistic to expect that these architectural impacts are
solvable using a platform-independent standard.

			  Status of Working Groups
			  ------------------------


A working group is either active or inactive.  Active working groups have
charters to develop documents.  Inactive working groups have no charter --
typically because they have completed their previous charter.  These inactive
working groups (and their mailing lists) serve as a forum for implementors.
When a standards-track document produced by a working group is ready for
further evaluation or new documents are appropriate, the working group is
re-chartered accordingly.


AToM MIB (atommib)
   Chair:      Kaj Tesink <[e-mail]>
   Consultant: Keith McCloghrie <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1695 (proposed standard)

The WG is eligible to re-activate in February, 1995.


Bridge MIB (bridge)
   Chair:      Fred Baker <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1493 (draft standard)
				       and RFC 1525 (proposed standard)

The WG is eligible to re-activate now.


Character MIB (charmib)
   Chair:      Bob Stewart <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   waiting for the next state for RFC 1658 (draft standard)
					      RFC 1659 (draft standard)
					      RFC 1660 (draft standard)

The WG is eligible to re-activate now.


Data Link Switching MIB (dlswmib)
   Chair:      Shannon Nix <[e-mail]>
   Consultant: Deirde Kostick <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Active:     in progress

The WG has just started.


DECnet Phase IV MIB (decnetiv)
   Chair:      Jon Saperia <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   waiting for the next stage for RFC 1559 (draft standard)

The WG is eligible to re-activate now.


FDDI MIB (fddimib)
   Chair:      Jeffrey Case <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1285 (proposed standard)
				       and RFC 1512 (proposed standard)

The WG is eligible to re-activate now.


Frame Relay Service MIB (frnetmib)
   Chair:      James Watt <[e-mail]>
   Consultant: Fred Baker <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1604 (proposed standard)

The WG is eligible to re-activate now.


Host Resources MIB (hostmib)
   Chair:      Steven Waldbusser <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next state for RFC 1514 (proposed standard)

The WG is eligible to re-activate now.


IEEE 802.3 Hub MIB (hubmib)
   Chair:      Keith McCloghrie <[e-mail]>
               Donna McMaster <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1515 (proposed standard)
				       and RFC 1516 (draft standard)

The WG is eligible to re-activate now.


Interfaces MIB (ifmib)
   Chair:      Ted Brunner <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1573 (proposed standard)
				       and RFCs 1748-9 (proposed standard)


The WG is eligible to re-activate now to consider RFC 1573.


Mail and Directory Management (madman)
   Chair:      Steve Kille <[e-mail]> 
   Consultant: Marshall Rose <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail] (body: "subscribe ietf-madman")
   Inactive:   awaiting the ntext stage for RFCs 1565-1567 (proposed standard)

The WG is eligible to re-activate now.


Modem Management (modemmgt)
   Chair:      Mark S. Lewis <[e-mail]>
   Consultant: Steven Waldbusser <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFC 1696 (proposed standard)

The WG is eligible to re-activate in February, 1995.


Printer MIB (printmib)
   Chair:	Joel Gyllenskog <[e-mail]>
   Consultant:  Steven Waldbusser <[e-mail]>
   WG mail:	[e-mail]
   To join:     [e-mail]
   Active:      awaiting RFC publication of draft-ietf-printmib-printer-mib-03.txt

The chair is working on harmonizing the MIB's character sets with the
IANA registry.


RDBMS MIB (rdbmsmib)
   Chair:	Robert Purvy <[e-mail]>
   Consultant:  Marshall Rose <[e-mail]>
   WG mail:	[e-mail]
   To join:     [e-mail]
   Inactive:    awaiting the next state for RFC 1697 (proposed standard)

The WG is eligible to re-activate in February, 1995.


Remote Monitoring (rmonmib)
   Chair:      Andy Bierman <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Active:     in progress

The WG is working on RMONv2.  The WG is eligible to evaluate RFC 1513
(proposed standard) with respect to the standards track now (although
such an evaluation requires an update to the charter).  The WG is
eligible to evaluate RFC 1757 (draft standard) with respect to the
standards track in July, 1995.


SNA DLC Services MIB (snadlc)
   Chair:      Shannon Nix <[e-mail]>
   Consultant: Deirde Kostick <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Active:     editing draft-ietf-snadlc-llc-mib-01.txt

The WG is completing an LLC-2 MIB.


SNA NAU Services MIB (snanau)
   Chair:      Zbigniew Kielczewski <[e-mail]>
 	       Deirde Kostick <[e-mail]>
   Consultant: David Perkins <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Active:     editing draft-ietf-snanau-appcmib-00.txt

The WG is completing an APPC MIB.


SNMP version 2 (snmpv2)
   Chair:      Bob Stewart <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Active:     the games have begun

The WG is evaluating the SNMPv2 documents with respect to the standards track.


Trunk MIB (trunkmib)
   Chair:      Fred Baker <[e-mail]>
               Tracy Brown <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFCs 1406, 1407 (proposed standard)

The WG is eligible to re-activate now.


Uninterruptible Power Supply (upsmib)
   Chair:      Jeffrey Case <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   Awaiting the next stage for RFC 1628 (Proposed standard)

The WG is eligible to reactiviate now.


X.25 Management Information Base (x25mib)
   Chair:      Dean Throop <[e-mail]>
   WG mail:    [e-mail]
   To join:    [e-mail]
   Inactive:   awaiting the next stage for RFCs 1381-1382 (proposed standard)

The WG is eligible to re-activate now.

		    Policy on Formation of Working Groups
		    -------------------------------------

     It is the goal of the IETF to produce standards which:

	- have high technical quality;
	- solve real and immediate problems in the Internet using modest
	  community and computing resources;
	- are accessible to a broad community;
	- are developed in an open and fair manner; and,
	- are developed in a timely manner.

     To assist in achieving this goal, each standardization activity
     (WG) must have the participation of one or more senior technical
     resources within an area.  Without this senior guidance, WGs tend
     to produce documents which are inconsistent with one or more of the
     characteristics above.  (Of course, the presence of senior guidance
     does not guarantee success--senior guidance is a necessary, but not
     sufficient ingredient.)

     A senior technical resource has substantial content-relevant
     experience and extensive experience with the IETF process of
     developing and adopting Internet standards.  As examples, technical
     simplicity and operational scaling are two characteristics of
     Internet architecture with which senior contributors will have had
     considerable experience.

     As membership in the IETF grows, the percentage of senior
     technical resources has been decreasing.  There are two reasons
     for this:  first, many new members, while skilled, do not have
     senior levels of expertise with respect to Internet architecture
     and specifications.  Second, appreciation of the IETF philosophy
     takes time.  Thus, by definition, any new IETF member, regardless
     of their background, initially lacks the shared philosophy necessary
     to be considered a senior technical resource.  Of course, it is
     hoped that, over time, new IETF members will become steeped in the
     culture.

     As the success of the Internet standards process has become more
     visible, the IETF is being asked to consider standardization of an
     increasingly broad range of technologies.  Unfortunately, there
     are insufficient senior technical resources to meet this demand.
     This means that each request for a standardization activity must
     be carefully scrutinized, both to see if it is likely to be
     successful, and for its impact on other standardization
     activities.

     As such, the policy for the formation of new WGs in the Network
     Management area of the IETF is:

  1. Parties interested in starting a new standardization activity
     must first check whether an existing WG is working with that
     technology.  If one is not, the AD will provide the party with a
     list of area consultants.  This list is created, approved, and
     maintained by the AD.

     In the NM area of the IETF, the list of area consultants for *new*
     working groups consists precisely of the membership of the NM area
     Directorate.

  2. The party must then find an area consultant who expresses an
     interest in guiding the activity.  At this stage however, the area
     consultant is not expressing a commitment, merely an interest.  If
     the party is unable to find an interested area consultant, then no
     new WG is formed.

  3. The area consultant will discuss the matter with the AD to
     determine the parameters for a mailing list, a BOF and a charter.
     If after this discussion, the area consultant decides that a
     commitment would be inappropriate, the party is informed, and the
     process goes back to step 2.

  4. The party, under the guidance of the area consultant, determines
     the level of community interest in producing and using the
     technology.  This is first accomplished via e-mail, either through
     an existing list or by creating a new list.  The purpose of this
     activity is to establish an initial vocabulary and set of views,
     and to draft a preliminary, non-binding charter.

  5. The party, under the guidance of the area consultant, requests a
     BOF to be held at the next meeting of the IETF.  The purpose of
     this BOF is to gauge two criteria:

	- community interest in producing the resulting technology
	  (multiple organizations are interested in participating in the
	   WG and in implementing the resulting technology); and,

	- community interest in using the resulting technology (the
	  technology is of broad interest to the Internet community as a
	  whole).

     and also to refine the preliminary, non-binding charter.

     Further, if the technology to be developed is a MIB module, then
     the the purpose of the BOF is to gauge a third criterion:

	- existing vendor-specific MIB modules and user experience with
	  those modules.

     If the AD, who will attend the BOF, isn't satisfied as to the
     demonstration of any of these criteria, the party is informed and
     the process goes back to step 2.

  6. The party, under the guidance of the area consultant, prepares a
     draft charter and begins the charter negotiation process with the
     AD.  When the party, the area consultant, and the AD agree on a
     draft charter, the AD begins the charter negotiation process with
     the IESG.

Note that this policy does not apply to WGs which are currently inactive,
i.e., those which are awaiting re-activation due to standards-track
activity.

		 NM Area Director's Statement of Disclosure
		 ------------------------------------------


     This information is disclosed so that any party may evaluate the
     performance of the NM AD, without having to speculate as to any
     possible conflicts of interest.  As always, questions about
     specific actions by IETF members, WG chairs, or ADs should be
     communicated to that person and/or whoever oversees their work.
     You are encouraged to bring your concerns directly to the AD or to
     the IESG, should any actions cause you any question.


I am Principal of a consultancy corporation: 50% of my time is devoted to
clients, 50% to community service.  The clients neither fund nor direct any
community service.  The corporation supports my participation on the IESG
solely as a matter of community service.  Here is my current client list:

	Client				Market Area
	------------------------------	---------------------------
	Interop Company			US Program Committee

	First Virtual Holdings		Internet Commerce products and services
					(equity participant)

In each market area, I am "exclusive" to that client.  In addition, with the
exception of a small number of shares in PSI, I have no financial interest in
any computer-communications company.  I am the author of several books on
internetworking technologies published by Prentice Hall, for which I receive
royalties.

Finally, I am a member of the board for the Internet Multicasting Service, a
non-profit organization, for which I receive no compensation.


		Dr. Marshall T. Rose
		Principal
		Dover Beach Consulting, Inc.
		420 Whisman Court
		Mountain View, CA  94043-2186
		US

		Tel:	[phone]
		Fax:	[phone]

		Email:	[e-mail] (official IESG business)
			[e-mail]	    (otherwise)