MIB comments

[David Lovering 303-497-5673 <[e-mail]>]

Dear Lars, et. al:

  Regarding the recent notes on the MIB, I have relatively little to add to
Lars' comments.  However, as an armchair MIB enthusiast and modem-bank
administrator by trade I would like to make a few points and ask for some
clarification.

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

  Obviously it would be unwise to include any element which is protected as
the intellectual property of a company.  However, even such blatantly 
proprietary modem standards such as V.FAST (and less blatant ones such as
V.FC and PEP) have certain common elements of performance and control which
would be ameniable to a MIB definition, particularly if the generalized
structure applies equally well to a broad cross-section of modem products
from different vendors.  That is why MIBs are useful.

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

  Not only do I agree that using one object rather than two suits this situa-
tion better, but I would hold out for the '0' as a disabling feature.  Not
only is the circuitry required to realize this easier to do (even though most
folks use PLAs for their modem chips, it still requires JEDEC gate masks to
make the templates for them), it also leaves the option of using 255 as a
sort of open-ended "wait for infinity".  

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

  Although the "+++" escape methodology is the intellectual property of Hayes
(and is presumably licensed to other modem manufacturers for a hefty fee), I
would still regard having some kind of escape sequence definition as a necessary
evil.  Also, if one admits this need, then it also becomes necessary to include
a guard-time to ensure reasonable distinctions between the guard sequence and
real data.  

  One possible solution is to use a BREAK as a means of interrupting the data
stream in order to revert to "command mode" (or whatever it is referred to
in TIA-602).  Since BREAK is not a character [and quite deliberately so!], it
shouldn't infringe on anyone's pet escape sequence.  Moreover, every modem of
recent vintage has the means to detect BREAK [it shows up as a framing error,
and is used as such by the in-band autospeed algorithms].  However, it is
still occassionally necessary to send BREAK to the distant modem/host; this is
managed by concatenated BREAKS (with a reasonable guard time delay in between);
the first BREAK merely asserts the command mode, and the second triggers the
issuance of the BREAK to the distant host.  This would not interfere with the
use of BREAK as an autospeed selector, since after the initial "locking on" of
the two modem devices, this function is disabled anyway (and remains so as long
as carrier is asserted).

  I advance this suggestion rather reluctantly, since the mission of the MIB
team is to devise a MIB architecture that supports existing technology rather
than to require non-traditional solutions (which may not be adopted by the
manufacturers).  In any case, the idea of some method of transitioning between
command-mode and data-mode should not be made independant of SNMP influence;
it is far too important and pervasive.

  Whatever method of "escaping" is ultimately arrived at as the "correct" one,
it will still require a means of enabling and/or disabling it, and may include
other incidental variables (such as mdmEscapeGuardDelay,  mdmEscapeCharacter,
and mdmEscapeCharacterRepetitions perhaps?).  Perhaps the safest way to deal
with this is to explicity define only the enabling/disabling directive, and
allow some reasonable number of optional mdmEscapeOption variables which are
subject to the whim of the modem manufacturer.  A gut feeling tells me that
four might be a reasonable working maximum for the number of such variables.

  -- Dave Lovering
     NIST/CSCD
     [e-mail]

-------------------------------------------------------------------------------
  "The opinions expressed above are those of the author, and may not represent
  those of the agency... or anybody else, for that matter".
-------------------------------------------------------------------------------