RE: Response to EPON-MIB-04

HI,

Please describe a simple situation, and provide a list of the
instances. Then I can help you with the indexing in the MIB
object definitions.

Also descsribe what events cause a new instance to be created
or deleted.

Regards,
/david t. perkins

On Tue, 7 Feb 2006, Lior Khermosh wrote:

>  
> Dan,
> Please see answers in line.
> 
> Also during this session I had some second thoughts on some of the
> changes I have integrated in the last review. Specifically as to use a
> linkIndex inside the MIB tables instead of using the ifIndex of the
> virtual links. Although it is not exactly as the IEEE layering for the
> EPON (the MPCP and P2PE layers are a single layer and not N virtual
> links) the specification of the MIB is more simpler and more neat. There
> are no multiple rows for each virtual link and the duplication is
> generated by the ifIndex for the virtual links (like it was in draft
> 03). That way it is more similar to the tables which will be held for
> the virtual MACs management. I am still considering it and I will try to
> discuss it with David and then provide the draft ASAP.
> 
> 
> Best regards,
> Lior
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]] 
> Sent: Monday, January 23, 2006 9:06 AM
> To: David T. Perkins; Lior Khermosh
> Cc: Hub MIB
> Subject: 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. 
> >> Changed.
> 
> 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 removed the creation by management. The rows are created when a
> virtual link is established (ONU registers) and deleted when a virtual
> link is deleted (ONU deregisters). I have added clarification in the
> text.
> 
> 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
> > 
> > 
> > 
> ************************************************************************
> This footnote confirms that this email message has been scanned by
> Passave mail scanner for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************************************************************************
> This footnote confirms that this email message has been scanned by Passave mail scanner
> for the presence of malicious code, vandals & computer viruses.
> ************************************************************************
>