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
- Comments on Modem MIB draft Mark S. Lewis