MIB comments

[Steven Waldbusser <[e-mail]>]

Rick Royston writes:
> 2.  mdmLineCarrierLossControl  - why not assign mdmLineCarrierLossTime a
>      value of 0 and delete this object?

Mark Lewis writes:
>Page 9/10: mdmLineCarrierLossControl - why not assign
>mdmLineCarrierLossTime a value of 0 and delete this object?  This is
>like V.58 except it used 255 to disable.

Les Brown writes:
>1) On mdmLineCarrierLossTime, I would expect a value of '0' to be
>interpretted by many modems as  'disconnect immediately', not 'never
>disconnect on loss of carrier'.

We currently have a range of (1..X), so '0' is not currently a valid
value.  I think we should either decide that it makes sense to
disconnect immediately and change the range to (0..X); or, use zero as
a distinguished value for 'disabled' and delete the
mdmLineCarrierLossControl object.  I suspect that there were good
reasons for us and V.58 to not use zero, so I'm leaning towards the
latter.  Does it ever make sense to tell the modem to disconnect
immediately?

Rick Royston writes:
> 3.  mdmLineCapabilities - what about V.25 bis, V.32 terbo ?  Also who is 
> the keeper of the protocol list?

This protocol list should include all non-vendor-specific protocols.
This list will be updated by this working group and published in this
MIB as it goes through the standards track and through the IANA
(Internet Assigned Numbers Authority) after the document reaches full
standard.  Vendor-specific protocols should be registered in vendor-specific
MIBs.

Les Brown writes:
>2) Who uses V.25bis for async modems? Are we considering sync objects?
>Who uses V.26bis and V.26ter?

These are not objects, but identifiers for different protocols.  When
we decided not to instrument sync modems, it was not from a desire to
break sync modems, but to lessen our workload.  Many (most?) objects
in this MIB will be useful for managing sync modems.  Adding these
identifiers is simple, costs very little, and ensures that the MIB
objects are as widely useful as possible.

Les Brown writes:
>3) V.32terbo is NOT a STANDARD and should not be included here,
>unless you want to include other proprietary modems as well.

V.32terbo may not be standardized by an accredited standards body, but
the reality is that it is as much a standard, from the customer's
perspective, as V.32.  It is not vendor-specific.  If one buys two
V.32terbo modems from different vendors, one should expect
interoperability between them (well, no less interoperability than
V.32bis modems).  We should include all relevant publicly available
standards/specifications.  For example, by this guideline V.32bis
and V.32terbo would be in, while PEP would be out.

Mark Lewis writes:
>Page 12: how about we add v21, v23CC, v23SC, v25bis, v26bis, v26ter,
>v27ter, v32terbo?, v34 to the mdmLineCapabilities OID list so it is
>the same as V.58 gntnModulationSchemesSupported.

I agree.

I believe at least Hayes, Microcom, and Rockwell have shipped products
based on an interim version of V.Fast.  Do these implement the same
specification or any common specifications?  (Do they all use the same
chip?)  If so, is there a name for the spec that they use? (V.FC?)
BTW, do they interoperate?

Rick Royston writes:
>  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

I'm confused by the spec as it stands.  What does it mean to "prepare
to dial an outgoing call"?  Is enableDial redundant?  Was that Rick's
point?

I shortened the names in my draft as Mark suggested:
mdmDTEActionOnDTROffToOn => mdmDTEActionDTROffToOn

>  5.  mdmDTEInactivityTimeOut - reference to start/stop switched, changed 
>  to async dial

Sorry, I don't understand.

>  6.  mdmAutoAnswerEnable - this object duplicated the function of 
>      mdmRingsBeforeAnswer when its value is 0.  Delete ?

V.58 defines ringsBeforeAnswer as 0..15.  What do they mean by 0 and 1?
Should we also use 0?  Which of the following is 0 rings? 1 ring?

    ASAP
    leading edge of first ring ( is this the same as ASAP?)
    trailing edge of first ring

If the results of this line of questioning is that zero is unused,
then I agree that we should use zero as "no auto-answer", and delete
mdmAutoAnswerEnable.

>  7.  mdmCallProgressDetect - this object is a mess in current modems. I 
>  wonder if an enumeration of EverthingInTheModem(5) is reasonable?

Sorry, I don't understand.

Mark Lewis writes:
>Page 17: I think we should add a mdmCCCallProgressState (before
>mdmCCCallProgressDetect) like callProgressState from V.58.  This
>should be a read-only variable.

Les Brown writes:
>5) On call progress state, this is a very transient condition, that
>is, each state is only active for a short period of time. Do we really
>want to have this in this crippled MIB?

Good point Les.  I agree.  This object wouldn't really add much.

>  8.  mdmResultCodeEnable - replace enable(1) with  enableNumeric and 
>      enableVerbose.

Good idea. I've changed this in my draft.  Does anyone think we
shouldn't do this?

>  9.  mdmStoredDialString - should we define a max length.  I think we use 
>  30 or 40.  Comments?

Note that the following is 40 characters long without a country code.

9,102880,4122686628,,,,,,,mycredit#here.

I think 64 would be a reasonable number.  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?

Adding such text wouldn't be a big deal.

> 11. mdmCCErrorControlUsed - in description value '{0 0}' ?

0.0 is OK.

>  12. mdmStatsIncomingConnectionsRequest - rename to 
>      mdmStatsIncomingConnectionsAccepted and change desc.

Noting that failures + successes = requests, we need to decide which
two variables are most useful.

o Sometimes I want to know how many calls are failing so that I can work
  at keeping this number zero.

o Sometimes I want to know how many calls have been attempted because
  it gives me an indication of how many times a customer wished to use
  my service.

o Sometimes I want to know how many calls have succeeded because it
  tells me how many times we have provided service.

I originally thought that attempts were more important.  If anyone
would really rather have successes, thats fine.  Above all, we
shouldn't spend a lot of time on this because it is not really that
important.

>  13. mdmStatsIncomingAbnormalTerminations - how is this different from 
>  failed connection requests.  All connections abnormally terminate by loss 
>  of DCD, or some other means.

ConnectionConnectionFailures are calls that were answered but the
modems failed to sync up.  It is important to note this separately
from abnormalTerminations because it often indicates misconfiguration
or incompatibilities.  AbnormalTerminations are calls that sync'd up,
but were dropped in the middle.

Your point about all connections terminating by loss of DCD is
interesting.  Is there a simple way to differentiate abnormal
terminations from normal terminations?  Or will
successfulConnections == abnormalTerminations?

Chris Rozman writes:
> 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?

I guess that once a call is established, incoming/outgoing has little
correlation with reliability.  Pending the answer to the previous
question, I agree with your suggestion.

>  15. mdmStatsRingNoAnswer - description ",but the call was not answered".  
>  If the ring detect is separate, the DSP may be ill.

Sounds reasonable

>  16. mdmStatsSentDataFrames |Recieved DataFrames - line and NOT DTE

Yes.

BTW, some line modulations schemes don't have frames, right? (ie no LAPM)?
Here's an example of what one of the descriptions should look
like to account for this: "The number of data frames sent on the line
interface.  This counter should not increment when the line interface
is not in a frame-oriented mode."  Does this text do the job?  Should
I use different words?  (I want to make sure nobody misinterprets and
counts every character as a frame.)

Mark Lewis writes:
>Page 5: how about we reverse the order of mdmGroups and mdmCompliances
>to match the order in the mib draft.

Fine.

>Page 6/23/24: If mdmStoredDialString & index are part of the Call
>Control group, how about we prefix all the stored dial stuff with
>mdmCCStored.

OK.

>Page 10: mdmLineCompressionEfficiency - since mdmDataCompressionGroup
>was dropped do we want this objects?  If so, does it belong in the
>mdmLine or mdmStats table.  Also, there is a discrepency about how it
>is computed.  V.58 compressionEffeciency says IN/OUT*.01, while the
>mib says IN/OUT*100.  Why isn't it just IN divided by OUT?

We agreed some time ago that this object was important, regardless of
whether we had a compression group.  There was a comment in the MIB
for some time to this effect.  I replaced the comment with this
object, modeled after V.58.  I think you're right about moving it to
the statistics group.

The object's semantics agrees with V.58, there is just a notational
difference re .01 vs. 100.  The object is multiplied by 100 so that it
can be encoded in an integer and still provide some granularity.

I'd like to add the following text to the description:
"If this call used no compression, then this number shall be 100."

Mark Lewis writes:
>Page 22: mdmCCCurrentLineRate - We should rename it
>mdmCCDCERateUsed to show this is the DCE rate not the DTE

Les Brown writes:
>8) Current line rate is OK. The 'line' rate is understood to be the DCE rate.

I agree.  I think it's pretty clear now.

>To be consistent, I think we should have a similar object to show the
>DTE rate - mdmDTERateUsed.

This is in the RS232 MIB or the character MIB.

>Page 27:  do we need mdmStatsDTERingNoAnswers?  I vote we just count
>mdmStatsRingNoAnswer.

DTERingNoAnswers tells me that my users are being screwed because the
terminal server is not ready or is misconfigured or the cable fell
out.  This is a big operational problem because it will often stop
a hunt group dead.

Now let me make an observation.  If we were to delete this, we could
word ringNoAnswers so that it explicitely included DTERingNoAnswers.
Then when the operator noticed that ringNoAnswers was incrementing,
she could use the RS232 MIB to check to see if DTR is the problem.
This issue to keep it is an issue of simplicity and signal to noise
ratio.  You want objects that flag serious problems to have high
signal/noise ratios.  The question is how big a deal this condition
is.  I'd like to hear from other operational people on this.

>Page ?: We should cite V.58 in a reference section.

Yes.

>6) On mdmEscapeAction, if this relates to the '+++' escape to command
>mode, this  was intentionally left out of TIA-602 and V.58 since there
>is IPR involved and the company that owns the patent did not agree to
>the nondiscriminatory etc terms. This should be left out!

The MIB says:
"The modem's action upon successfully recognizing the 'escape to
command mode' character sequence."

I suppose that '+++' is an escape to command mode character sequence.
There may be others as well (with or without Hayes' guard times, etc).
Whatever sequence is used, proprietary or not, patented or not, this
object can be used to control what the modem does when it sees the
sequence.

Learning and controlling this behavior of a modem is very important
when tracking down user problems such as misconfigured modems.



Steve