comments on RFC 1659

["John A. Shriver" <[e-mail]>]

I have quite a few comments on the changes between RFC 1317 and RFC
1659.  Some are trivial, some strike me as serious errors.

1) You have introduced and x21 rs232PortType value.  However, you have
not defined the "C" (control) and "I" (indication) modem control
signals used by X.21, so it is impossible to properly export an X.21
port, since X.21 is the only CCITT interface not using the V.24
signals.  Only half the solution.

2) X.21 is a lot more than a modem interface.  It is an entire dialing
protocol, which could easily use an entire MIB for itself.

For instance, you would want to give the internal state machine
values, the timeouts, etc.  (Ugh, shudder, a baby version of X.25.)
HOWEVER, X.21 is such an arhcitectural crock (BISYNC dialing for an
HDLC line), that nobody really impelements the dialing protocol.  They
just use the "leased line subset".  Thus, if we just provide C and I,
that will probably be good enough.  (V.25 bis has replaces X.21 in the
hearts of implementors.  Anyone brave enough to write a MIB for that?)

3) There is an obvious "cut and paste" typo in the DESCRIPTION for
rs232SyncPortTable. 

4) The rs232SyncPortIdlePattern only has mark(1) and space(2) values.
I don't know of anything that uses Space idle between frames, but Flag
is REAL common -- the typical default.  There should be a flag(3).
This strikes me as a big error.  (Or, do I completely misunderstand
what this element is exporting?  The description is hyper-terse -- not
the way to get consistent implementations.)

5) Almost everything in the new rs232SyncSDLCGroup part of
rs232SyncPortTable is every bit as applicable to async ports as sync
ports.  I'd say it belongs in the rs232PortTable.  (Doesn't anyone
remember Bell 202 modems, IBM 2741 terminals, etc?)  For that matter,
why is it treated as SDLC-specific?  The PPP group released PPP over
HDLC framing today!  Isn't SDLC just a special case of HDLC.  (How
about exporting the HDLC supported classes of procedure?)

6) The DESCRIPTION in rs232InSigName and rs232OutSigName lies.  The
rts, cts, etc., names are NOT the ones that will be found in the cited
RS-232-C.  Those are certainly the most common nicknames, and the ones
everyone uses, but they are NOT ensconced in any standard I know.

I'd recommend rewriting the description as follows, for clarity:

       DESCRIPTION
           "Identification of a hardware signal, as follows:

	       name   RS-232  V.24    Definition

               rts    CA      105     Request to Send
               cts    CB      106     Clear to Send
               dsr    CC      107     Data Set Ready
               dtr    CD      108/2   Data Terminal Ready
               ri     CE      125     Ring Indicator
               dcd    CF      109     Received Line Signal Detector
               sq     CG      110     Signal Quality Detector
               srs    CH/CI   111/112 Data Signaling Rate Selector
               srts   SCA     120     Secondary Request to Send
               scts   SCB     121     Secondary Clear to Send
               sdcd   SCF     122     Secondary Received Line Signal Detector
            "

While srs is mapping two different signals into the same name, I don't
really care, since I don't know of anything using it anymore.  Modern
modems negotiate and adjust speed on their own.

Also, citing RS-232-C is awfully dated by now...  How about EIA-232-D,
or the latest EIA/TIA-232-E?  (Of course, that makes the MIB's name a
bit dated.)

7) There are certainly other modem control signals that might be quite
interesting, especially the loopback ones.  Some are even
semi-standardarized on the ISO 2110 (25-pin, a/k/a RS-232) connector,
and they certainly are well-standardized on V.35 and RS-449.

8) How about EIA/TIA-574?  That's the standard for the 9-pin connector
so common on personal computers and other high density devices.
Should we add that to rs232PortType, namely eia574(7)?  Or should we
add a connector type to the rs232PortTable?

There's also an EIA/TIA standard for async over an 8-pin modular phone
jack.  (I don't have the number in my catalog here.)