RE: Response to EPON-MIB-04

David,

Thank you for the review and the latest comments. 

Lior,

Can you please address David's questions? 

I believe that David is asking for clarifications, maybe an example that
would clarify his question 1. This new text could expand Section 3
'Relationship of the EFM EPON MIB to other MIBs'. By the way, 'Relation
to other MIB Modules' would be a better name for this section. 

With respect to David's question #2, the text 'Rows at the table are
created by direct SNMP management setting." seems wrong. David's
question is correct, if rows in these tables are created dynamically by
management operations on the specific table, you need to use "RowStatus"
objects for the specific table. If this was not the intention, the text
should be eliminated and you should mention in the DESCRIPTION clauses
in each table how each row shows up, maybe as result of operations
performed on other tables, or corresponding to existing ports on the
device, or something else. 

I am also feeling very uncomfortable with holding discussions around a
non-submitted draft.  I would like to ask Lior to submit draft 04
immediately. If the issues cannot be clarified and a revised draft
submitted in the next couple of days, it can be as it was distributed on
the mailing list last December.  

Regards,

Dan


 
 

> -----Original Message-----
> From: David T. Perkins [mailto:[email protected]] 
> Sent: Friday, January 20, 2006 9:01 AM
> To: [email protected]
> Cc: Romascanu, Dan (Dan); Hub MIB
> Subject: 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  
> 
> 
>