Re: MIB comments

["Mark S. Lewis" <[e-mail]>]

>>>>> On Sat, 29 Jan 1994 17:06:15 -0500 (EST), Steven Waldbusser <[e-mail]> said:

> 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?

One of the rules we agreed to was to stick with V.58 unless there was
good justification.  In this case, I think we should stick with V.58.
Have one object (mdmLineCarrierLossTime) with legal values 1-255, with
255 means disable.

> 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.

We should leave out sync objects, but include sync items in
enumerations.  It's easy to include them, plus it brings us more in
line with V.58.

> 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.

We should include any protocols that are implemented by more that one
vendor.  It is not so important which are official standards versus
defacto standards.  We don't need to include protols that are strictly
proprietary (implemented by only one vendor).

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

> Sorry, I don't understand.

What is being suggested is we change the last sentence to the
following.  "This function applies to asyncronous dial operations
only."

>>  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.

Yes delete mdmAutoAnswerEnable and mdmRingsBeforeAnswer value 0 to
mean "no auto-answer"

> 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.

When things get stuck, this isn't a transient state.  I think this
would be a helpful debug object.

Also, I don't like the term "crippled MIB".  The mib we are building
is a core of functionality.  You know--he 80/20 rule.  If it's
crippled, it implies it is not useful.  Is that what you think Les?

>>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

On mdmCCEscapeAction, we are talking about the action that occurs upon
escape.  We are not trying to provide control over the recognition of
the escape sequence since this is problematic.  All I want to see is a
V.58 reference if available.  I am not suggesting we add or delete any
objects.  I would like to avoid the whole escape discussion if
possible.  All we are talking about is this one object and how it
should be defined.

... Mark

==========--------------       Mark S. Lewis      ----------==========
[e-mail]       Telebit Corp.      Voice [phone]