Comments on Modem MIB draft

"Mark S. Lewis" <mlewis@telebit.com> Thu, 27 January 1994 19:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09896; 27 Jan 94 14:35 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09892; 27 Jan 94 14:35 EST
Received: from apache.telebit.com by CNRI.Reston.VA.US id aa14968; 27 Jan 94 14:35 EST
Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA09060 to ietf-archive@cnri.reston.va.us; Thu, 27 Jan 94 11:18:14 PST
Received: from yoyo.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA12355 to modemmgt@apache.Sunnyvale.Telebit.COM; Thu, 27 Jan 94 11:18:12 PST
Date: Thu, 27 Jan 1994 11:18:12 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Mark S. Lewis" <mlewis@telebit.com>
Message-Id: <9401271918.AA12355@america.Sunnyvale.Telebit.COM>
Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA09314; Thu, 27 Jan 94 11:18:12 PST
To: modemmgt@telebit.com
Subject: Comments on Modem MIB draft
Reply-To: Mark.S.Lewis@telebit.com
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"

Here are my comments on draft-ietf-modemmgt-mdmmib-01.txt, dated
January 14, 1994.  Plus I tried to address the issues Rick and Chris
brought up...

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

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.

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.

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?

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.

Page 13: mdmDTEActionOnDTROnToOff - what is V.58 reference or are we
inventing this? Can we shorten the name to mdmDTEActionDTROnToOFF?

Page 14: mdmDTEActionOnDTROffToOn - what is V.58 reference or are we
inventing this? Can we shorten the name to mdmDTEActionDTROffToOn?  I
don't like the enableDial, autAnswerEnable, establishConnection
enumerations. I don't think they are sufficiently clear.

(I don't understand Rick's suggestion for mdmDTEActionOnDTROffToOn.
Perhaps you could write-up the object and send it to the list.)

Page 14: mdmDTESyncTimingSource - Why do we need this?  Is it
important to read this or set it?  This is part of the V.58 signal
converter group which was dropped from the core group.

Page 15: mdmDTESyncAsyncMode - what is the V.58 reference?  How is
this useful?

Page 16: let's be consistent and use mdmCCRingsBeforeAnswer = 0 to
mean disable autoanswer and drop mdmCCAutoAnswerEnable.

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

Page 18: mdmCCResultCodeEnable how about these enumerations
disable(1), enableNumeric(2), enableVerbose(3)?

Page 18: mdmCCEscapeAction - V.58 reference?

Page 19: mdmCCConnectFailReason - how about we use the same
enumerations as V.58 callCleared?  It looks like a reasonable list but
it doesn't provide any details on the each enumeration like we are
trying to do.  If we want to keep the list in the mib, we will need
to do some work work on the descriptions.

Page 22: mdmCCCurrentLineRate - We should rename it
mdmCCDCERateUsed to show this is the DCE rate not the DTE
rate. Also, V.58 transmissionSignallingRateActive has objects for both
transmit and receive.  We probably only need one but should specify in
the description the transmit rate is shown if they are different.

To be consistent, I think we should have a similar object to show the
DTE rate - mdmDTERateUsed.  This would be a read-only object which
references V.58 startStopDteInterfaceSpeed
startStopDteInterfaceSpeedAdaptation.  V.58 let's you control how the
speed is determined.  In our core, we would just show what the DTE
rate that is currently in use.

Page 23: mdmCCErrorControlUsed - what should be the no compression
value? Likewise for mdmCCCompressionTypeUsed.

Page 25/26: I like Chris Rozman's suggestion to make
mdmStats{Incoming,Outgoing}ConnectionRequests into just
mdmStats{Incoming,Outgoing}Connections

Page 25/26: I would like to get rid of
mdmStats{Incoming,Outgoing}AbnormalTerminations and just count
mdmStats{Incoming,Outgoing}ConnectionFailures.  I don't think the
difference is significant.

I disagree with Chris and believe we should count both
{Incoming,Outgoing} failures.  According to my suggestion, we have
left 4 objects:

	mdmStats{Incoming,Outgoing}Connections
	mdmStats{Incoming,Outgoing}ConnectionFailures.

Page 27:  I agree with Rick change mdmStatsRingNoAnswer description to
", but the call was not answered."

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

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

Page 31:  I use my middle initial "S" in my name because it is a
rather common name.

Anyone else care to comment on the draft.  Thanks.

... Mark

==========--------------       Mark S. Lewis      ----------==========
Mark.S.Lewis@Telebit.com       Telebit Corp.      Voice (408) 745-3232