Response to EPON-MIB-04

HI,

Comments on draft-ietf-hubmib-efm-epon-mib-04.txt - dtp:19-jan-2006

The document is much improved. However, it is not yet ready for
submission to the IESG. The changes introduced many grammar and
some spelling errors (and a couple of formatting problems), which
can be easily fixed. Unfortunately, there are a couple of
fundamental issues that remain. These are:
 1) if an "SNMP MIB walk" was done on the
     a) IF table
     b) bridge table
     c) MAU table
     d) stack table (and inverted stack table)
     e) etherLike interfaces table
     d) and tables defined in the MIB module
   what would be the answers to the following questions for
   OLTs and for ONUs (for both, assume that each has a 1Gig Eth
   interface and an optical interface, and for the OLT, there
   are 3 ONUs connected to the optical interface):
     a) how many entries would be in the IF table
     b) what would the values be for each column in the
         IF table. That is, what are the values of the
         following objects: ifIndex, ifDescr, ifType,
          ifMtu, ifSpeed, ifPhysAddress, ifAdminStatus,
          ifOperStatus, ifLastChange, ifInOctets, ifInUcastPkts,
          ifInNUcastPkts, ifInDiscards, ifInErrors, 
          ifInUnknownProtos, ifOutOctets, ifOutUcastPkts,
          ifOutNUcastPkts, ifOutDiscards, ifOutErrors,
          ifOutQLen
     c) how the values of the above objects determined?
     d) what happens when the value of ifAdmin is set to
         'up(1)', 'down(2)', and 'testing(3)'?
     e) the table dot1dBasePortTable has the mapping of
        bridge ports to interfaces (and "circuit" on that
        interface). What would the values be for the
        objects dot1dBasePortIfIndex and dot1dBasePortCircuit
        when the OLT supported bridging? (By the way,
        document "Definitions of Managed Objects for Bridges"
        was recently updated and, thus, the refs should
        have RFC 4188 and not 1493.)
     f) how many entries would be in table ifMauTable,
        and would be the value of columns in the table.
     g) Are the stack and inverted stack tables used?
        If so, show the stacking relationships.
     h) How many entries are in the etherLike tables
        dot3StatsTable, dot3CollTable, dot3PauseTable,
        and dot3HCStatsTable and what would the values
        be of columns in the tables.
     i) How many entries would be in the tables defined
        in this document, which are:
        dot3MpcpGlobalTable, dot3MpcpParamTable,
        dot3MpcpStatTable, dot3OmpEmulationTable,
        dot3OmpEmulationStatTable, dot3EponFecTable,
        dot3ExtPkgGlobalControlTable,
        dot3ExtPkgControlTable, dot3ExtPkgQueueTable,
        dot3ExtPkgQueueSetsTable and
        dot3ExtPkgOptIfTable.
 2) Which tables in the MIB module allow rows to be created
    and or deleted, and if so, then how? (Note the the phrase
    "Rows at the table are created by direct SNMP management
    setting." is used in the DESCRIPTION for many tables.
    However, there was no information provided as to what
    this means. (I'm guessing that my original comments
    were not completely understood. What I was asking for
    was to include in the DESCRIPTION clause whether or
    not an SNMP SET could be done to columns in a table
    to create or delete a row, and if so, to provide the
    details (or indicate the object definition where the
    details were provided). For example, the TCP connection
    table does not support SNMP SETs to create rows in
    the table. Rows are created as TCP connections
    are created by processes running on the system.
    However, an SNMP SET can be done on object tcpConnState 
    with value 'deleteTCB(12)' to terminate a TCP
    connection (which results in the row being deleted
    from the table). There are plenty of examples of
    using a "RowStatus" object to create and delete
    rows in tables (see the SNMPv3 RFCs, such as RFC 3413).
    In the RMON MIB modules, there are examples of
    control tables and data tables. A row creation
    (or deletion) in a control table results in
    row creation (or row deletion) in data tables.
    Describing how instances are created and deleted,
    (by system operation or configuration, and/or
    via management operations) is a key piece of
    information for the DESCRIPTION clauses of
    tables and rows.

Until the above fundamental issues are resolved,
it doesn't make a lot of sense to spend much time
on other issues such as grouping and conformance.

Note that I did spot a bunch of easy to fix items
that I'm listing below:
 section 1 - the text for the abstract is Ok. I just don't
     get the term "registers" here.
 section 1.1 - It's great to have a list of abbreviations.
     a) However in documents that contain MIB modules, typically
     the modules are extracted, and thus all the explanatory
     is not available. To help, there is a little redundancy
     that is added to the document of putting KEY definitions
     and terms in the DESCRIPTION clause for the MIB module.
     b) I didn't check to see if all the abbreviations were
     actually used. If not, then I would remove them.
     c) I thought CPE was customer premises equipment
 section 1.2.3 - I was confused. Does "Gate messages"
     start a new subsection?
 section 3 (3.1-3.4) - This is still a little skimpy!
     Look at RFC 2863, sections 3.1.1-3.1.18 & 4. Also
     look at RFC 3635, section 3.2 and contained subsections.
 section 4 - tables 1 thru 3. The column head should be
     IEEE802.3ah attribute and not "object"
 In the MIB module, there are several ASN.1 comments that
     that are used to group the definitions. They start
     out with phrase "Editor's note:". I believe the
     grouping is useful, but I'd drop the "Editor's note:"
     phrase. Note the first one is slightly out of order.
     It should be moved to immediately before the
     definition of OID dot3EponMpcpObjects.
 Object dot3MpcpID - the DESCRIPTION needs to be translated
     from GDMO speak to something meaningful in SMIv2.
     (I commented on this before, and still don't see the
     usefulness of the object!)
 Do the objects dot3MpcpOperStatus and dot3MpcpAdminStatus
     ever have different values. If not, then you should
     have one object.
 I really don't follow whether or not you can create LLIDs
     via SNMP. It doesn't seem possible to me, just like
     you can't create TCP connections. Thus, I don't understand
     the object dot3LinkIndex. (And note: a table that
     allows row creation uses "read-create" (and not "read-write")
     for all writable objects in the table.)
 Entries in parallel tables - I asked you to describe the
     expected number of entries in tables. However, many of
     the tables in the MIB module are related, and the text
     was just copied. Instead, if there is a "base table"
     that determines the number of entries, and additional
     tables that have additional info, you should say
     something like "The rows in this table are match the
     rows in table X".
 Transient condition in table dot3MpcpParamTable - it appears
     that this table tries to capture the transient values
     during the time a OLT and ONU are setting up a relationship
     and determining an LLID. Is this a long enough running
     activity that it can be seen, and what LLID value is
     used durring negotiation (can't it change)?
 Object dot3OmpEmulationID - the DESCRIPTION needs to be translated
     from GDMO speak to something meaningful in SMIv2.
     (I commented on this before, and still don't see the
     usefulness of the object!)
 Enum names in DESCRIPTION for object dot3ExtPkgObjectPowerDown -
     The enum names start with lower-case letters and not
     upper-case.
 Queues - I really don't understand the queues. Could some
     intro text be added.
 Indexing - this is somewhat subjective. I don't believe that
     it is proper to define an object in one table (which is not
     an index in that table) and use it for an index in another
     table. This is done in the queue tables and object dot3LinkIndex.


NOTE: this review was not complete. I didn't try to compile the
MIB module or run the document through the nit checker. Also,
I didn't look at the compliances.

-- that's it

Regards,
/david t. perkins