Re: Rick Royston's MIB Comments

["Rozman, Chris" <[e-mail]>]

     Here are my feelings with regard to Rick's comments below...
     
     2.  I agree.  We often use a value of zero to disable a feature.
     
     3.  Rick has a good point here.  If the official list isn't kept up to 
     date, people will tend to implement enterprise OIDs for standard 
     capabilities, which will mean that we'll end up with multiple return 
     values for the same capability across vendors.  Not very consistent!
     
     4.  USR modems have four stored phone numbers that are stored in 
     NVRAM.  When configured to autodial on DTR, the modem dials the first 
     stored number.  I would think that what number is dialed could be 
     implementation specific.
     
     5.  I agree.
     
     6.  I agree.
     
     7.  I'm not sure about this one.  Is there a big difference between 
     implementation of ATX among vendors?
     
     8.  Yes.
     
     9.  40 characters in a dial string seems adequate.
     
     10.  I would prefer to see a basic subset implemented in this MIB and if 
     there is a need for this level of detail, it could be put in an enterprise 
     MIB.
     
     11.  {0 0} is an acceptable OID.  It is essentially a null value.  I don't 
     see a problem with it.
     
     12.  I would make it mdmStatsIncomingConnections and make the description 
     explain that it is completed incoming connections that are being counted.
     
     13.  I don't see a need to differentiate between incoming and outgoing 
     abnormal connection terminations.  Why don't we combine these into a single 
     mdmStatsAbnormalConnectTerminations object?
     
     14.  Again, I would just make it mdmStatsOutgoingConnections.
     
     15.  USR has redundant ring detect hardware such that if a modem doesn't 
     answer an incoming call for which it had S0 configured appropriately and 
     DTR was present, network management can report the event as a "Modem 
     ring-no-answer" event.  This is considered an equipment failure.  I don't 
     think users care if the phone rang less than S0 times as the current 
     description implies.
     
     16.  I would assume that we are talking about frames on the link.
     
     Hopefully, this will help push us towards a concensus.
     
     Chris
     
______________________________ Reply Separator _________________________________
Subject: Rick Royston's MIB Comments
Author:  ,"Royston, Rick" <[e-mail]> at Internet 
Date:    1/25/94 9:24 AM
     
     
  Here are my comments to the 1/4/94 MIB
     
  1.  Royston, not Roysten
     
  2.  mdmLineCarrierLossControl  - why not assign mdmLineCarrierLossTime a
      value of 0 and delete this object?
     
  3.  mdmLineCapabilities - what about V.25 bis, V.32 terbo ?  Also who is 
  the keeper of the protocol list?
     
  4.  mdmDTEActionOnDTROffToOn - if an object is defined for a DialNumber,
      it can be treated as other objects with a RAM copy and NVRAM 
  copy(ies). Then enableDial and establishConnection are the same.  I 
  suggest that they be replaced by DialmdmPhoneNumber(2) where 
  mdmPhoneNumber is the name of the preconfigured object
     
  5.  mdmDTEInactivityTimeOut - reference to start/stop switched, changed 
  to async dial
     
  6.  mdmAutoAnswerEnable - this object duplicated the function of 
      mdmRingsBeforeAnswer when its value is 0.  Delete ?
     
  7.  mdmCallProgressDetect - this object is a mess in current modems. I 
  wonder if an enumeration of EverthingInTheModem(5) is reasonable?
     
  8.  mdmResultCodeEnable - replace enable(1) with  enableNumeric and 
      enableVerbose.
     
  9.  mdmStoredDialString - should we define a max length.  I think we use 
  30 or 40.  Comments?
     
  10. mdmCCConnectFailReason - add text to state that not all devices can 
  or will return all of these possible values.  I have problems with this 
  object, but have no good solutions as of now.  Maybe we should minimize 
  this list?
     
  11. mdmCCErrorControlUsed - in description value '{0 0}' ?
     
  12. mdmStatsIncomingConnectionsRequest - rename to 
      mdmStatsIncomingConnectionsAccepted and change desc.
     
  13. mdmStatsIncomingAbnormalTerminations - how is this different from 
  failed connection requests.  All connections abnormally terminate by loss 
  of DCD, or some other means.
     
  14. mdmStatsOutgoingConnectionRequests - rename to 
      mdmStatsOutgoingConnectionsAccepted.
     
  15. mdmStatsRingNoAnswer - description ",but the call was not answered".  
  If the ring detect is separate, the DSP may be ill.
     
  16. mdmStatsSentDataFrames |Recieved DataFrames - line and NOT DTE 
     
  Please comment on my comments asap.  We need to get some concensus before 
  Jan 31.
     
  Rick