Re: MIB comments

[Lars Poulsen <[e-mail]>]

I have been in lurker mode through this effort, mostly because I'm
far removed from the people that build the modems I use, and at the
one working group meeting I attended, the room was full of people
with lots of SNMP experience who insisted that the people proposing
the same features in the MIB that I would like to see, were mistaken.

I think the proposal is a great step in the right direction, and if
we could generally expect to get modems with hooks to these items,
it would be significant progress. The recent adjustments seem to
be improvents, too.

Against this general approval of the proposed MIB on its own merits,
stands my feeling that it is functionally very close to V.58, and if I were
a modem builder, I would be more likely to provide a standard management 
capability if there was only one standard to implement to.

All that said, here are some specific notes to Les' message today:

	Date: Fri, 28 Jan 94 00:23:36 -0600
	From: [e-mail]
	To: [e-mail] (Receipt Notification Requested)
	Subject: MIB comments (Part 1)

	2) Who uses V.25bis for async modems?
I have seen this on ZyXEL modems.

	3) V.32terbo is NOT a STANDARD and should not be included here, unless
	you want to include other proprietary modems as well.
It seems desirable to use the same code points as V.58; in addition,
   I should hope that we would have codepoints to describe additional
   protocols in common use. For the next couple of years, the "non-standard"
   V.32terbo will be common. It would seem reasonable to include V.FC,
   PEP and HST as well. But if there is widespread political opposition to
   acknowledge the existence of anything proprietary, we should just match
   V.58.

	4) I believe we have 2 objects in V.58 for auto answer (an enable and a
	ring count) because some manufacturers use '0' to disable auto answer
	whilst others use '255'.
I'm with Mark on this one. One object is cleaner.

	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!
If it is useful to do, we should document one way to do it, rather
   than make a political statement that this is not worth doing, and force
   everyone in to proprietary (and different) ways of doing it.
   I would find it useful to be able to turn escaperecognition on and off
   remotely.

/ Lars Poulsen			Internet E-mail: [e-mail]
  CMC Network Products		Phone: (011-) [phone]
  Hvidovre Strandvej 72 B	Telefax:      [phone]
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait