NM "State of the Area" Report
IETF NM-AD <firstname.lastname@example.org> Wed, 01 March 1995 15:56 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04988;
1 Mar 95 10:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04982; 1 Mar 95 10:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07528; 1 Mar 95 10:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04950; 1 Mar 95 10:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04889; 1 Mar 95 10:53 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa07460; 1 Mar 95 10:53 EST
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690) id AA25277; Wed, 1 Mar 95 07:52:45 -0800
From: IETF NM-AD <email@example.com>
To: IETF NM-AD <firstname.lastname@example.org>
Subject: NM "State of the Area" Report
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-Description: apologies for the cross-posting
Date: Wed, 01 Mar 1995 07:52:40 -0800
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 <email@example.com> Tracy Brown <firstname.lastname@example.org> Ted Brunner <email@example.com> Jeff Case <firstname.lastname@example.org> Deirdre Kostick <email@example.com> Keith McCloghrie <firstname.lastname@example.org> Dave Perkins <email@example.com> Bob Stewart <firstname.lastname@example.org> Kaj Tesink <email@example.com> Steve Waldbusser <firstname.lastname@example.org> 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: email@example.com or firstname.lastname@example.org 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: email@example.com 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 <firstname.lastname@example.org> Consultant: Keith McCloghrie <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> Consultant: Deirde Kostick <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com Active: in progress The WG has just started. DECnet Phase IV MIB (decnetiv) Chair: Jon Saperia <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> Consultant: Fred Baker <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> Donna McMaster <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <S.Kille@isode.com> Consultant: Marshall Rose <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org (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 <Mark.S.Lewis@Telebit.COM> Consultant: Steven Waldbusser <email@example.com> WG mail: modemmgt@Telebit.com To join: majordomo@Telebit.com 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 <firstname.lastname@example.org> Consultant: Steven Waldbusser <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> Consultant: Marshall Rose <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> Consultant: Deirde Kostick <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> Deirde Kostick <firstname.lastname@example.org> Consultant: David Perkins <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com Active: editing draft-ietf-snanau-appcmib-00.txt The WG is completing an APPC MIB. SNMP version 2 (snmpv2) Chair: Bob Stewart <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org Active: the games have begun The WG is evaluating the SNMPv2 documents with respect to the standards track. Trunk MIB (trunkmib) Chair: Fred Baker <email@example.com> Tracy Brown <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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 <email@example.com> WG mail: firstname.lastname@example.org To join: email@example.com 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 <firstname.lastname@example.org> WG mail: email@example.com To join: firstname.lastname@example.org 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: +1 415 968 1052 Fax: +1 415 968 2510 Email: email@example.com (official IESG business) firstname.lastname@example.org (otherwise)
- NM "State of the Area" Report IETF NM-AD