Subject: RE: [Hubmib] Response to EPON-MIB-04

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 22 Jan 2006 20:52:59 +0200

David,

I have no strong feelings on this, but I still would argue that EFM is a
better prefix. Although true that EFM OAM may apply to any Ethernet
link, this is kind of a side effect, it still was designed as part of
the 802.3ah project. EFM is the name the whole planet knows this
technology, and it is recognized as such in the overview section of
clause 67 of the IEEE document quoted by you. Moreover, we did not
follow a strict dot3 prefixing policy in the past, starting now when the
last MIB modules are on the exit gate seems a little odd.

I agree with you on the need of consistency between the module name and
the identifiers of the module and object names. 

Regards,

Dan

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Sunday, January 22, 2006 8:40 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Hub MIB
> Subject: RE: [Hubmib] Response to EPON-MIB-04
> 
> HI,
> 
> First, I was pointing out an inconsistancy between the module 
> name and the descriptor for the the MODULE-IDENTITY.
> In lior's lastest I-D, there are
>    DOT3-EFM-EPON-MIB DEFINITIONS ::= BEGIN
>     <<text deleted>>
>    dot3EponMIB MODULE-IDENTITY
> 
> This is inconsistent. Thus, the module name should be  
> DOT3-EPON-MIB or the descriptor should be  dot3EfmEponMIB
> 
> However, with regards to the naming scheme for the collection 
> of documents, I believe the that "EFM"
> is not approapriate for the dot3 OAM MIB module (since it 
> applies to any dot3 technology), and whether or not the EFM 
> is part of the EPON or CU MIB modules, this is something for 
> the WG to decide.
> However, it seems to me that EFM is a marketing term and the 
> dot3 is more appropriate. The 802.3ah document calls the CU 
> and EPON technology "Subscriber access networks" in the 
> document title, and then and inside the document there are 
> phrases like:
> 67.1 Overview
> This clause provides information on building Ethernet 
> subscriber access networks, also referred to as "Ethernet in 
> the First Mile", or EFM networks. 
> 
> Given than "copper" when describing dot3 is ambiguous, then 
> an additional adjective is needed. But with EPON, there is no 
> ambiguity. Thus, I suggest the following module names:
>   DOT3-EPON-MIB (or DOT3-EFM-EPON-MIB)
>   DOT3-EFM-CU-MIB
>   DOT3-OAM-MIB 
> 
> Then have consistent descriptors for items defined in the MIB 
> modules. For the lastest OAM and EPON modules, the prefixes 
> are dot3Oam and dot3Epon (plus dot3Mpcp, dot3OmpE, etc).
> The CU module has prefixe emfCu.
> 
> On Sun, 22 Jan 2006, Romascanu, Dan (Dan) wrote:
> > What is exactly the rationale for this request, David? 
> > 
> > The other MIB modules in the family are named EFM-COMMON-MIB and 
> > EFM-CU-MIB. If we are to look for consistency, the names of the MIB 
> > modules defined in this document should be EFM-EPON-MIB and 
> > EFM-EPON-DEVICE-MIB.
> > 
> > Regards,
> > 
> > Dan
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:[email-masked]]
> > > Sent: Friday, January 20, 2006 7:43 PM
> > > To: [email-masked]
> > > Cc: Romascanu, Dan (Dan); Hub MIB
> > > Subject: Re: [Hubmib] Response to EPON-MIB-04
> > > 
> > > HI,
> > > 
> > > Just saw one more small item. The MIB module is named 
> > > "DOT3-EFM-EPON-MIB". I suggest that the name "DOT3-EPON-MIB"
> > > be used instead.
> > > 
> > > Regards,
> > > /david t. perkins
> 
> Regards,
> /david t. perkins
> 
> 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 23 Jan 2006 09:06:10 +0200

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

> Sent: Friday, January 20, 2006 9:01 AM
> 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  
> 
> 
>