comments on RFC 1659
"John A. Shriver" <jas@proteon.com> Thu, 21 July 1994 23:45 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25100; 21 Jul 94 19:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25096; 21 Jul 94 19:45 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa04927; 21 Jul 94 19:45 EDT
Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA00612; Thu, 21 Jul 94 16:34:01 -0700
Received: by nsl.pa.dec.com; id AA22020; Thu, 21 Jul 94 16:25:10 -0700
Received: by nsl.pa.dec.com; id AA22016; Thu, 21 Jul 94 16:25:09 -0700
Received: by pobox1.pa.dec.com; id AA20030; Thu, 21 Jul 94 16:24:57 -0700
Received: from monk.proteon.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA28053; Thu, 21 Jul 94 16:16:42 -0700
Received: from ironside.proteon.com by monk.proteon.com (4.1/Proteon-1.5) id AA09702; Thu, 21 Jul 94 19:15:19 EDT
Received: by ironside.proteon.com (4.1/SMI-4.1) id AA06080; Thu, 21 Jul 94 19:15:19 EDT
Date: Thu, 21 Jul 1994 19:15:19 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "John A. Shriver" <jas@proteon.com>
Message-Id: <9407212315.AA06080@ironside.proteon.com>
To: char-mib@decwrl.dec.com
Cc: rlstewart@xap.xyplex.com, jas@proteon.com
Subject: comments on RFC 1659
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.)
- comments on RFC 1659 John A. Shriver