Subject: Implementation Survey

From: "Dan Romascanu ELdevmt-TA" <[email-masked]>
Date: Mon, 4 May 98 15:56:19 +0300

Please find in the following the questionnaire for the implementation 
survey concerning RFC 2108 and RFC 2239 (Repeater MIB and MAU MIB 
repectively).

You are welcome to send the responses to the whole list or to my address 
directly. I will do my best to keep the responses cofidential. As we 
discussed in LA, anybody who does not feel confortable in sending me his 
responses, may use the services of a proxy to keep his/her anonimity.

According to the WG schedule, we should get the results by the end of 
June, but - of course - the sooner, the better.

Dan

--------------------------------------------------------------------------
------
Dan Romascanu,
Systems Architecture Group Manager,
LANNET Ltd.,
Voice: 972-3-645-8414, e-mail: [email-masked]
--------------------------------------------------------------------------
------

RFC 2108 and RFC 2239 Implementation Questionnaire for Agent Developers
--------------------------------------------------------------------------
--------------------

Please fill out one questionnaire for each different type
of managed system developed by your organization that supports
the Repeater MIB, RFC 2108 (or a MIB module derived from the
Repeater MIB), and/or the MAU MIB, RFC 2239 (or a MIB module derived from 
the
MAU MIB). 

The HUB MIB WG needs the following information to help
in the evaluation of the Repeater MIB, RFC 2108, and the MAU
MIB, RFC 2239.

Background
----------

Specifications that are intended to become Internet Standards evolve
through a set of maturity levels known as the "standards track".
During this evolution, specifications must go through rigorous
definition, analysis, and deployment to become a "Full" Internet
standard. The first level for a specification is called "Proposed".
The next level is "Draft", and the last level is "Full".

The goals of the Internet standards process are:
   o  technical excellence;
   o  prior implementation and testing;
   o  clear, short, and easily understandable documentation;
   o  openness and fairness;  and
   o  timeliness.

The following from the RFC 2026 - Internet Standards Process
are the requirements for a specification to be advanced to the
Draft Standard status.

   4.1.2  Draft Standard

A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.  If patented or otherwise controlled technology
   is required for implementation, the separate implementations must
   also have resulted from separate exercise of the licensing process.
   Elevation to Draft Standard is a major advance in status, indicating
   a strong belief that the specification is mature and will be useful.

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.  This documentation should be submitted to the
   Area Director with the protocol action request. (see Section 6)

   A Draft Standard must be well-understood and known to be quite
   stable, both in its semantics and as a basis for developing an
   implementation.  A Draft Standard may still require additional or
   more widespread field experience, since it is possible for
   implementations based on Draft Standard specifications to demonstrate
   unforeseen behavior when subjected to large-scale use in production
   environments.

A Draft Standard is normally considered to be a final specification,
   and changes are likely to be made only to solve specific problems
   encountered.  In most circumstances, it is reasonable for vendors to
   deploy implementations of Draft Standards into a disruption sensitive
   environment.

RFC 2108 - Repeater MIB
-------------------------------

On the following questions, please add additional text
or another answer where appropriate to fully describe
your system.

Describe your managed system:
  1) Which of the following best describes the physical
     characteristics of your managed system:
     a) non-modular (i.e., a "box" with no addition/removal
        of repeater ports)
     b) modular (i.e., a chassis or box with modules or
        cards which can add and/or remove repeater ports)
     c) stackable system (i.e., separate boxes connected
        together)
     d) other (please describe)

  2) Does the agent that implements the repeater MIB manage
     one, or more than one repeater-units?
     a) one
     b) fixed number based on device backplane (how many)
     c) multiple based on device backplane and/or cards
        installed in the device (what is theoretical maximum)

Describe your implementation:

  1) Is table rptrGroupTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

2) Is table rptrPortTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

3) Is table rptrInfoTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

4) Is table rptrMonitorPortTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

 5) Is table rptrMonitor100PortTable implemented?
 a)  no
      b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is not a 100 Mb/s repeater

6) Is table rptrMonTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

7) Is table rptrMon100Table implemented?
 a)  no
      b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is not a 100 Mb/s repeater

8) Is table rptrAddrSearchTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

9) Is table rptrAddrTrackTable implemented?
     a) no
     b) yes, all objects with STATUS current.
     c) partially - describe differences relative to the standard

10) Is table rptrExtAddrTrackTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard

11) Is table rptrTopNPortControlTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard

12) Is table rptrTopNPortTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard

  13) Is trap rptrInfoHealth implemented?
      a) no
      b) yes, but not for all conditions (describe)
      c) yes, for all cases including changes in value of
         rptrOperStatus, and completion of a non-disruptive test

  14) Are additional objects returned in varBind list for
      trap rptrInfoHealth?
      a) trap not implemented
      b) no
      c) yes (describe)

  15) Are multiple occurrences of trap rptrInfoHealth throttled?
      a) trap not implemented
      b) no (describe)
      c) yes

  16) Is trap rptrInfoResetEvent implemented?
      a) no
      b) yes

  17) Are additional objects returned in varBind list for
      trap rptrInfoResetEvent?
      a) trap not implemented
      b) no
      c) yes (describe)

  18) Are multiple occurrences of trap rptInfoResetEvent throttled?
      a) trap not implemented
      b) no (describe)
      c) yes

 19)  Is the agent implementation used / was tested with any management 
application? (if more than one apply, fill all that apply)
 a)  no - we manufacture only agent code
 b)  yes - with MIB browsers
 c)  yes - with proprietary application we developed
 d)  yes - with third party application (detail)

RFC 2239 - MAU MIB
-------------------------------

On the following questions, please add additional text
or another answer where appropriate to fully describe
your system.

Describe your managed system:
  1) Which of the following best describes the physical
     characteristics of your managed system:
     a) non-modular (i.e., a "box" with no addition/removal
        of ports/interfaces)
     b) modular (i.e., a chassis or box with modules or
        cards which can add and/or remove ports/interfaces)
     c) stackable system (i.e., separate boxes connected
        together)
     d) other (please describe)

 2)  Is the managed device:
 a)  a repeater
 b)  other type of device - detail
 
Describe your implementation:

  1) Is table rpMauTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is not a repeater

2) Is table rpJackTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is not a repeater

3) Is table ifMauTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is a repeater and rpMauTable is used 
instead

4) Is table ifJackTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device is a repeater and rpJackTable is used 
instead

5) Is table ifMauAutoNegTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device does not support AutoNegociation

6) Is table broadMauBasicTable implemented?
     a) no
     b) yes, all objects with STATUS current.
 c)  partially - describe differences relative to the standard
 d)  N/A - the managed device has no managed broadband MAUs

7) Is trap rpMauJabberTrap implemented?
      a) no
 b)  yes, but with differences from the standard - detail
 c)  yes
 d)  N/A - the managed device is not a repeater

8) Are multiple occurrences of trap rpMauJabberTrap throttled?
      a) trap not implemented
      b) no (describe)
      c) yes

  9) Is trap ifMauJabberTrap implemented?
      a) no
 b)  yes, but with differences from the standard - detail
 c)  yes
 d)  N/A - the managed device is a repeater and implements 
rpMauJabberTrap

10) Are multiple occurrences of trap ifMauJabberTrap throttled?
      a) trap not implemented
      b) no (describe)
      c) yes

 11) Is the agent implementation used / was tested with any management 
application? (if more than one apply, fill all that apply)
 a)  no - we manufacture only agent code
 b)  yes - with MIB browsers
 c)  yes - with proprietary application we developed
 d)  yes - with third party application (detail)