Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05859; 1 Mar 94 12:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05855; 1 Mar 94 12:27 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa11945; 1 Mar 94 12:27 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA20456; Tue, 1 Mar 94 09:20:12 -0800 Received: by nsl.pa.dec.com; id AA10305; Tue, 1 Mar 94 08:26:58 -0800 Received: by nsl.pa.dec.com; id AA10301; Tue, 1 Mar 94 08:26:57 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA24679; Tue, 1 Mar 94 08:23:52 -0800 Received: by xap.xyplex.com id ; Tue, 1 Mar 94 11:29:43 -0500 Date: Tue, 1 Mar 94 11:29:43 -0500 Message-Id: <9403011629.AA04311@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: mrose.iesg@dbc.mtview.ca.us, char-mib@pa.dec.com Subject: Re: Recommendation for Character, RS-232, and Parallel MIBs My previous message said I'd list the Internet Drafts, but I didn't. They are: draft-ietf-charmib-mib-00.txt draft-ietf-charmib-rs232-mib-00.txt draft-ietf-charmib-ppl-mib-00.txt I suppose that was fairly obvious, but it's best to be complete. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16602; 2 Mar 94 19:14 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16598; 2 Mar 94 19:14 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa20387; 2 Mar 94 19:14 EST Received: from regal.cisco.com by hubbub.cisco.com with SMTP id AA04396 (8.6.4/IDA-1.5 for snadlcmib@cisco.com); Wed, 2 Mar 1994 15:54:18 -0800 Message-Id: <199403022354.AA04396@hubbub.cisco.com> To: char-mib@decwrl.dec.com Cc: snadlcmib@cisco.com Subject: Comments on draft-ietf-charmib-rs232-mib-00.txt Date: Wed, 02 Mar 94 15:54:17 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: wclark@cisco.com We noticed that none of the requests from the SNA DLC MIB working group were included in the draft-ietf-charmib-rs232-mib-00.txt submission of a couple of days ago. I'm not sure why they were ignored since I do believe they are of general interest. In fact, I would bet there are more RS-232 serial lines in the world that run the SDLC protocol and need these objects than not. This list of SDLC-induced objects comes from real-world requirements ... most of them were the same serial interface characteristics that were missing from cisco's original serial drivers and hardware. In the earlier years of cisco, we required the end device be changed to meet the requirements of our serial interface. This shortcoming cost us some business and has since been rectified. (No, Martha, the whole world is not full-duplex NRZ running HDLC.) The latest numbers I heard were that there is an estimated 500,000 serial lines out there that run SDLC. I think they deserve some attention. Wayne Clark, Editor of SNA DLC MIB cisco Systems, Inc. wclark@cisco.com 415/688-4627 P.S. Numbers (8) and (9) below should be nuked per the discussion on char-mib@decwrl.dec.com on January 13, 1994. However, the rest of them apply. ------- Forwarded Messages Return-Path: wclark Received: from hubbub.cisco.com by regal.cisco.com with SMTP id AA00356 (5.67a/IDA-1.5 for ); Wed, 22 Dec 1993 22:02:37 -0800 Received: from host6 (host6.apertus.com) by hubbub.cisco.com with SMTP id AA02095 (8.6.4/IDA-1.5 for ); Wed, 22 Dec 1993 22:02:32 -0800 Received: from hubbub.cisco.com by host6 with SMTP id AA20945 (5.65c/IDA-1.4.4 for ); Wed, 22 Dec 1993 23:52:58 -0600 Received: from regal.cisco.com by hubbub.cisco.com with SMTP id AA01971 (8.6.4/IDA-1.5 for snadlcmib@apertus.com); Wed, 22 Dec 1993 21:52:23 -0800 Message-Id: <199312230552.AA01971@hubbub.cisco.com> To: char-mib@decwrl.dec.com Cc: snadlcmib@apertus.com Subject: Extensions to RFC1317 for SDLC Devices Date: Wed, 22 Dec 93 21:52:22 PST From: wclark@cisco.com To the Char MIB Working Group - The SNA DLC MIB Working Group is nearing the end of its work towards defining a MIB for SDLC devices. We have collectively identified a few objects for physical-layer entities that are unique to the SDLC environment and logically reside in the management of RS-232-like devices (i.e. RFC1317 and it's successors). We would very much like to have a dialogue between the SNA DLC MIB Working Group and the Character MIBs Working Group so that the needs of SDLC serial interfaces can be included with your work. The RS-232 MIB (RFC1317) deficiences that are noted below were compiled during a discussion at the APPN Implementor's Workshop (AIW) on September 29, 1993 and ensuing email discussions in the SNA DLC MIB Working Group. Looking at RFC1317, it appears as if these MIB objects would go into rs232SyncPortTable. Assuming this, we've included the MIB objects with each attribute. We've used the style of RFC1317 to minimize the impact on the current MIB. Please consider this only as a straw-man proposal. We've assigned DEFVALs to best match the attributes of FDX, NRZ-encoded synchronous serial links like the original MIB authors probably assumed. (1) Role rs232SyncPortRole OBJECT-TYPE SYNTAX INTEGER { dte(1), dce(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The role the device is playing that is using this port. dte means the device is performing the role of data terminal equipment dce means the device is performing the role of data circuit-terminating equipment." DEFVAL { dce } ::= { rs232SyncPortEntry 8 } (2) Encoding rs232SyncPortEncoding OBJECT-TYPE SYNTAX INTEGER { nrz(1), nrzi(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The bit stream encoding technique that is in effect for this port. nrz for Non-Return to Zero encoding nrzi for Non-Return to Zero Inverted encoding." DEFVAL { nrz } ::= { rs232SyncPortEntry 9 } (3) RTS control rs232SyncPortRTSControl OBJECT-TYPE SYNTAX INTEGER { controlled(1), constant(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The method used to control the Request To Send (RTS) signal. controlled when the DTE is asserts RTS each time data needs to be transmitted and drops RTS at some point after data transmission begins. If rs232SyncPortRole is 'dte', the RTS is an output signal. The device will issue a RTS and wait for a CTS from the DCE before starting to transmit. If rs232SyncPortRole is 'dce', the RTS is an input signal. The device will issue a CTS only after having received RTS and waiting the rs232SyncPortRTSCTSDelay interval. constant when the DTE constantly asserts RTS." DEFVAL { constant } ::= { rs232SyncPortEntry 10 } (4) RTS-CTS delay rs232SyncPortRTSCTSDelay OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The interval (in milliseconds) that the DCE must wait after it sees RTS asserted before asserting CTS. This object exists in support of older synchronous devices that cannot recognize CTS within a certain interval after it asserts RTS." DEFVAL { 0 } ::= { rs232SyncPortEntry 11 } (5) Mode of Operation rs232SyncPortMode OBJECT-TYPE SYNTAX INTEGER { fdx(1), hdx(2), simplex-receive(3), simplex-send(4) } ACCESS read-write STATUS mandatory DESCRIPTION "The mode of operation of the port with respect to the direction and simultaneity of data transfer. fdx when frames on the data link can be transmitted and received at the same time hdx when frames can either be received from the data link or transmitted onto the data link but not at the same time. simplex-receive when frames can only be received on this data link. simplex-send when frames can only be sent on this data link." DEFVAL { fdx } ::= { rs232SyncPortEntry 12 } (6) Idle Pattern rs232SyncPortIdlePattern OBJECT-TYPE SYNTAX INTEGER { mark(1), space(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The bit pattern used to indicate an idle line." DEFVAL { space } ::= { rs232SyncPortEntry 13 } (7) Minimum Number of Flags rs232SyncPortMinFlags OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The minimum number of flag patterns this port needs in order to recognize the end of one frame and the start of the next. Plausible values are 1 and 2." DEFVAL { 2 } ::= { rs232SyncPortEntry 14 } (8) Runt Frames rs232SyncPortRunts OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames received that were too short to be meaningful to the data link protocol." ::= { rs232SyncPortEntry 15 } (9) Giant Frames rs232SyncPortGiants OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames received that were too long to be meaningful to the data link protocol." ::= { rs232SyncPortEntry 16 } Regards, ----------- Wayne Clark, Editor of SNA DLC MIB cisco Systems, Inc. wclark@cisco.com 415/688-4627 ------- Message 2 Return-Path: stewart@xyplex.com Received: from hubbub.cisco.com by regal.cisco.com with SMTP id AA29473 (5.67a/IDA-1.5 for ); Tue, 11 Jan 1994 08:15:49 -0800 Received: from host6 (host6.apertus.com) by hubbub.cisco.com with SMTP id AA01700 (8.6.4/IDA-1.5 for ); Tue, 11 Jan 1994 08:15:47 -0800 Received: from xap.xyplex.com by host6 with SMTP id AA24196 (5.65c/IDA-1.4.4 for ); Tue, 11 Jan 1994 10:03:16 -0600 Received: by xap.xyplex.com id ; Tue, 11 Jan 94 11:02:19 -0500 Date: Tue, 11 Jan 94 11:02:19 -0500 Message-Id: <9401111602.AA02096@xap.xyplex.com> From: Bob Stewart To: char-mib@decwrl.dec.com Cc: snadlcmib@apertus.com Subject: Re: Extensions to RFC1317 for SDLC Devices Wayne Clark's message with proposed objects for the RS-232 MIB fell in the black hole with the rest of my Christmas vacation mail. I just got a copy of it, and here are my comments. > The SNA DLC MIB Working Group is nearing the end of its work > towards defining a MIB for SDLC devices. We have collectively > identified a few objects for physical-layer entities that are > unique to the SDLC environment and logically reside in the > management of RS-232-like devices (i.e. RFC1317 and it's > successors). At the time that we put the synch group in, we considered several other objects, among them one for encoding (nrz/nrzi). For reasons that I couldn't find at the moment, we decided to leave them out, probably because most implementations didn't care or couldn't implement them, or didn't want them controllable. I also recall leaving out modem signal handling algorithms on purpose, because they vary so much. We were trimming what wasn't common enough, against the "no optional" rule. With SNMPv2, we now have a richer mechanism for compliance specification. Overall, if the proposed objects truly are SDLC objects of general interest, it seems reasonable to add them to the synch group and make them a separate compliance group, for SDLC. *** Opinions please, on the preceding paragraph. *** Along that line, are the runt and giant counters something that belong at the level of an RS-232 interface? They are a frame-level concept, and will not have complementary frame counters from the Interface group. They seem out of place to me. Bob ------- End of Forwarded Messages   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04607; 3 Mar 94 10:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04603; 3 Mar 94 10:35 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa09101; 3 Mar 94 10:35 EST Received: from xap.xyplex.com by hubbub.cisco.com with SMTP id AA04404 (8.6.4/IDA-1.5 for ); Thu, 3 Mar 1994 07:20:38 -0800 Received: by xap.xyplex.com id ; Thu, 3 Mar 94 10:25:51 -0500 Date: Thu, 3 Mar 94 10:25:51 -0500 Message-Id: <9403031525.AA28766@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: char-mib@pa.dec.com, snadlcmib@cisco.com Subject: Consensus Check - SDLC Objects for RS-232 MIB A few people spoke in favor of adding some SDLC-related objects to the RS-232 MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. They could be added as a separate compliance group for SDLC, but I didn't do so due to the general apathy. The following test of consensus is intended to insite response. Depending on the response, I may try the other way around. ******** Consensus Test ********* Are there strong objections to leaving out the proposed SDLC objects? Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04712; 3 Mar 94 10:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04707; 3 Mar 94 10:41 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa09195; 3 Mar 94 10:41 EST Received: from xap.xyplex.com by hubbub.cisco.com with SMTP id AA04280 (8.6.4/IDA-1.5 for ); Thu, 3 Mar 1994 07:15:32 -0800 Received: by xap.xyplex.com id ; Thu, 3 Mar 94 10:20:45 -0500 Date: Thu, 3 Mar 94 10:20:45 -0500 Message-Id: <9403031520.AA28711@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: char-mib@pa.dec.com, snadlcmib@cisco.com In-Reply-To: wclark@cisco.com's message of Wed, 02 Mar 94 15:54:17 PST <199403022354.AA04396@hubbub.cisco.com> Subject: Re: Comments on draft-ietf-charmib-rs232-mib-00.txt I'll take full responsibility for leaving out the SDLC objects. I considered putting them in, then waffled, based on little support for them. In the general quiet, I certainly may have misread the silent interest. Let me try the email consensus test that worked well for SNMPv2. I'll see if I can shake supporters loose. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05128; 3 Mar 94 10:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05124; 3 Mar 94 10:58 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa09522; 3 Mar 94 10:58 EST Received: from nbkanata.Newbridge.COM by hubbub.cisco.com with SMTP id AA05229 (8.6.4/IDA-1.5 for ); Thu, 3 Mar 1994 07:43:05 -0800 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA09309; Thu, 3 Mar 94 10:41:00 EST Received: from fields.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA08873; Thu, 3 Mar 94 10:40:58 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <9403031540.AA08873@Newbridge.COM> Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB To: Bob Stewart Date: Thu, 3 Mar 1994 10:45:32 -0500 (EST) Cc: char-mib@pa.dec.com, snadlcmib@cisco.com In-Reply-To: <9403031525.AA28766@xap.xyplex.com> from "Bob Stewart" at Mar 3, 94 10:25:51 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1144 Bob Stewart writes: | |A few people spoke in favor of adding some SDLC-related objects to the RS-232 |MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. |They could be added as a separate compliance group for SDLC, but I didn't do |so due to the general apathy. The following test of consensus is intended to |insite response. Depending on the response, I may try the other way around. | |******** Consensus Test ********* | |Are there strong objections to leaving out the proposed SDLC objects? +------- I have needed at least three of those objects for a product destinted for a non-SDLC environment (role, idle pattern and number of flags). In addition, I needed RTSControl, Delay and simplex vs duplex in another product. I should note that the first product is a router but the second is more tradition data comms gear. So yes, I would object to leaving out the objects. -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06589; 3 Mar 94 12:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06585; 3 Mar 94 12:41 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa11688; 3 Mar 94 12:41 EST Received: from netlink1.netlink.com by hubbub.cisco.com with SMTP id AA10012 (8.6.4/IDA-1.5 for ); Thu, 3 Mar 1994 09:22:37 -0800 Received: by netlink1.netlink.com (5.57/Ultrix3.0-C) id AA05042; Thu, 3 Mar 94 12:24:27 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shannon Nix Date: Thu, 3 Mar 94 12:22:40 EST Message-Id: <44565.sdn@[192.154.57.1]> X-Popmail-Charset: English To: char-mib@pa.dec.com, snadlcmib@cisco.com Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB On Thu, 3 Mar 94 10:25:51 -0500, Bob Stewart wrote: >A few people spoke in favor of adding some SDLC-related objects to the RS-232 >MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. >They could be added as a separate compliance group for SDLC, but I didn't do >so due to the general apathy. The following test of consensus is intended to >insite response. Depending on the response, I may try the other way around. > >******** Consensus Test ********* > >Are there strong objections to leaving out the proposed SDLC objects? > > Bob Hi Bob, I believe that the "general apathy" that you refer to was actually a mistaken impression that your dissenting comment on ONLY two of the proposed objects implied acceptance of the balance. I can certainly assert, as chair of the SNA DLC MIB WG, that the unanimous concensus within our group was to request that these objects be added to the RS-232 MIB. They appeared, without exception, in every vendor- specific SDLC MIB submitted, but we all agreed that they were really physical-level objects. Its very simple: One can NOT support SDLC without those objects. We have a number of vendors implementing and planning to implement the SDLC MIB. These implementors have to get that information from somewhere. We certainly prefer that it is from the standard MIB module at the appropriate layer, the RS-232 MIB. Regards, Shannon (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*)(*) Shannon Nix (*)(*)(*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) Netlink, Inc. (*)(*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) 3214 Spring Forest Rd. (*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) Raleigh N.C. 27604 USA (*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) Phone: (919)-878-8612 (*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) Fax: (919)-872-2132 (*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*) Internet: sdn@netlink.com (*)(*)(*)(*)(*)(*)(*) (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09419; 3 Mar 94 14:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09415; 3 Mar 94 14:59 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa14772; 3 Mar 94 14:59 EST Received: from access1.digex.net by hubbub.cisco.com with SMTP id AA15888 (8.6.4/IDA-1.5 for ); Thu, 3 Mar 1994 11:20:49 -0800 Received: by access1.digex.net id AA29182 (5.67a8/IDA-1.5 for snadlcmib@cisco.com); Thu, 3 Mar 1994 14:20:46 -0500 Date: Thu, 3 Mar 1994 14:20:46 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: A N Ananth Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB To: char-mib@pa.dec.com, snadlcmib@cisco.com In-Reply-To: <9403031525.AA28766@xap.xyplex.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A few people spoke in favor of adding some SDLC-related objects to the RS-232 > MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. > They could be added as a separate compliance group for SDLC, but I didn't do > so due to the general apathy. The following test of consensus is intended to > insite response. Depending on the response, I may try the other way around. > > ******** Consensus Test ********* > > Are there strong objections to leaving out the proposed SDLC objects? we would be IN FAVOUR of including these objects in the RS-232 MIB. we are in the process implementing X.25 support (RFC1381/2) and are quite frankly baffled as to how some of these objects were missed in the RS-232 MIB (eg NRZ/NRZI). we plan to implement the proposed SDLC MIB soon and would thus vote yes. ananth Phone: (410) 765-9281 Prism Communications Inc "See the colours"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09776; 3 Mar 94 15:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09772; 3 Mar 94 15:17 EST Received: from large.cisco.com by CNRI.Reston.VA.US id aa15372; 3 Mar 94 15:16 EST Received: from [198.92.30.83] (macip-dialup-37.cisco.com [198.92.30.83]) by large.cisco.com (8.6.5/8.6.5) with SMTP id LAA15443; Thu, 3 Mar 1994 11:44:18 -0800 Message-Id: <199403031944.LAA15443@large.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Mar 1994 11:41:57 -0800 To: Bob Stewart , char-mib@pa.dec.com, snadlcmib@cisco.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: sberl@cisco.com Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB At 10:25 AM 3/3/94 -0500, Bob Stewart wrote: >A few people spoke in favor of adding some SDLC-related objects to the RS-232 >MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. >They could be added as a separate compliance group for SDLC, but I didn't do >so due to the general apathy. The following test of consensus is intended to >insite response. Depending on the response, I may try the other way around. > >******** Consensus Test ********* > >Are there strong objections to leaving out the proposed SDLC objects? > > Bob We will be implementing the SDLC MIB and would like to see these objects included in the RS-232 MIB. Steve Berl Cisco Systems, Inc. (415) 324-5212   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02870; 4 Mar 94 8:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02866; 4 Mar 94 8:37 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa05785; 4 Mar 94 8:37 EST Received: from relay2.UU.NET by hubbub.cisco.com with SMTP id AA24071 (8.6.4/IDA-1.5 for ); Fri, 4 Mar 1994 05:22:58 -0800 Received: from uucp6.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwftt22740; Fri, 4 Mar 94 08:21:28 -0500 Received: from ssiny.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 4 Mar 1994 08:21:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Norm Friedman Date: Fri, 4 Mar 94 08:12:09 -0500 Message-Id: <19023.9403041312@ssiny.ssiny.com> To: char-mib@pa.dec.com, rlstewart@xap.xyplex.com, snadlcmib@cisco.com Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB Please add the SDLC objects. Norm Friedman Systems Strategies/Apertus   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03696; 4 Mar 94 9:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03691; 4 Mar 94 9:09 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa06567; 4 Mar 94 9:09 EST Received: from relay1.UU.NET by hubbub.cisco.com with SMTP id AA24772 (8.6.4/IDA-1.5 for ); Fri, 4 Mar 1994 05:52:51 -0800 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwftv11452; Fri, 4 Mar 94 08:51:29 -0500 Received: from ssiny.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 4 Mar 1994 08:51:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: steven schwell Date: Fri, 4 Mar 94 08:52:49 -0500 Message-Id: <19387.9403041352@ssiny.ssiny.com> To: char-mib@pa.dec.com, rlstewart@xap.xyplex.com, snadlcmib@cisco.com Subject: Re: Consensus Check - SDLC Objects for RS-232 MIB We would definitely like to see those objects added to the RS232 MIB. --- Steven Schwell (steve@ssiny.com) (uunet!ssiny!steve) Systems Strategies Inc. / Apertus Technologies Inc. 212-279-1515 x345 225 W34th Street Suite 500 New York, NY 10122-0598   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04179; 4 Mar 94 9:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04173; 4 Mar 94 9:38 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa07144; 4 Mar 94 9:38 EST Received: from xap.xyplex.com by hubbub.cisco.com with SMTP id AA25549 (8.6.4/IDA-1.5 for ); Fri, 4 Mar 1994 06:23:40 -0800 Received: by xap.xyplex.com id ; Fri, 4 Mar 94 09:27:55 -0500 Date: Fri, 4 Mar 94 09:27:55 -0500 Message-Id: <9403041427.AA24393@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: char-mib@pa.dec.com, snadlcmib@cisco.com Subject: SDLC Objects, Reprise I love it when something works. Clearly I was wrong in leaving out the SDLC objects. They indeed have a constituancy. I'll add them. ****** Consensus Check ****** Are there strong objections to adding the SDLC objects as an SDLC compliance group? Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06491; 4 Mar 94 11:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06487; 4 Mar 94 11:29 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa09532; 4 Mar 94 11:29 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA24925; Fri, 4 Mar 94 08:17:45 -0800 Received: by nsl.pa.dec.com; id AA18995; Fri, 4 Mar 94 07:18:19 -0800 Received: by nsl.pa.dec.com; id AA18991; Fri, 4 Mar 94 07:18:18 -0800 Received: from mail.bellcore.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA09199; Fri, 4 Mar 94 07:12:06 -0800 Received: from ginsu4 (ginsu4.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA16316; Fri, 4 Mar 1994 10:06:53 -0500 Return-Path: Received: by ginsu4 (4.1/4.7) id AA01536; Fri, 4 Mar 94 10:15:03 EST Date: Fri, 4 Mar 94 10:15:03 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tracy Brown X-Station-Sent-From: ginsu4.bellcore.com Message-Id: <9403041515.AA01536@ginsu4> To: mrose@dbc.mtview.ca.us, rlstewart@xap.xyplex.com, tacox@ginsu4.bellcore.com, char-mib@pa.dec.com Subject: review of 3 I-Ds Bob, Here are my comments on the three MIBs: draft-ietf-charmib-mib-00.txt draft-ietf-charmib-rs232-mib-00.txt draft-ietf-charmib-ppl-mib-00.txt (Quick review was helped by 6 more inches of snow that fell Wednesday night, and the ability to work at home. How bad is it in NH/MA Bob? It is the tundra in NJ! Spring will never come!) Character MIB: -- You use the words "experimental portion in" in the Introduction? Should you say "extension to" instead. This MIB is not an experimental MIB? -- have you gotten an ifType from IANA? -- InterfaceIndex does not pass MOSY (warning) From mosy: warning: object "charPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "charSessPortIndex" has unknown SYNTAX "InterfaceIndex" What are we doing about this issue? -- charSessConnectId is an InstancePointer: what does it point to? First accessible object in the MIB? -- charAsyncGroup is not defined as an OBJECT-GROUP same for charSyncGroup (There are no other objects in MIB; every object is in charGroup?) -- charPortSessionMaximum should have a SYNTAX of INTEGER if it is to be further bounded; see RFC1442. Same with charPortSessionIndex. Same with charSessIndex. Parallel-printer-like MIB: -- You use the words "experimental portion in" in the Introduction? Should you say "extension to" instead. This is not an experimental MIB? -- InterfaceIndex does not pass MOSY (warning) From mosy: warning: object "paraPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "paraInSigPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "paraOutSigPortIndex" has unknown SYNTAX "InterfaceIndex" -- There is an END clause before the conformance information RS-232-like MIB: -- You use the words "experimental portion in" in the Introduction? Should you say "extension to" instead. This is not an experimental MIB? -- InterfaceIndex does not pass MOSY (warning) From mosy: warning: object "rs232PortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "rs232AsyncPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "rs232AsyncPortBits" has unknown SYNTAX "Integer" warning: object "rs232SyncPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "rs232InSigPortIndex" has unknown SYNTAX "InterfaceIndex" warning: object "rs232OutSigPortIndex" has unknown SYNTAX "InterfaceIndex" -- There is an END clause before the conformance information -- How does ifSpeed in the ifMIB relate to rs232PortInSpeed and rs232PortOutSpeed? -- rs232AsyncPortBits has a SYNTAX of Integer should be INTEGER. Tracy =========================================== Tracy A. Brown Broadband Data Services and Consulting Bellcore NVC 1C-354 331 Newman Springs Rd. Red Bank, NJ 07701 email: tacox@mail.bellcore.com vmail: (908) 758-2107 fax: (908) 758-4177 ===========================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14412; 4 Mar 94 17:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14406; 4 Mar 94 17:15 EST Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa18794; 4 Mar 94 17:15 EST Received: from xap.xyplex.com by hubbub.cisco.com with SMTP id AA13433 (8.6.4/IDA-1.5 for ); Fri, 4 Mar 1994 13:23:02 -0800 Received: by xap.xyplex.com id ; Fri, 4 Mar 94 16:17:33 -0500 Date: Fri, 4 Mar 94 16:17:33 -0500 Message-Id: <9403042117.AA04743@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: internet-drafts@CNRI.Reston.VA.US Cc: char-mib@decwrl.dec.com, snadlcmib@cisco.com Subject: Internet Draft RS-232 MIB with SDLC draft RS-232-like MIB 4 March 1994 RS-232-like MIB 4 March 1994 Bob Stewart Xyplex, Inc. rlstewart@eng.xyplex.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires 4 September 1994 [Page 1] draft RS-232-like MIB 4 March 1994 1. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS- 232-like devices. Expires 4 September 1994 [Page 2] draft RS-232-like MIB 4 March 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 4 September 1994 [Page 3] draft RS-232-like MIB 4 March 1994 3. Overview The RS-232-like Hardware Device MIB applies to interface ports that might logically support the Interface MIB, a Transmission MIB, or the Character MIB. The most common example is an RS-232 port with modem signals. The RS-232-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB. The MIB includes multiple similar types of hardware, and as a result contains objects not applicable to all of those types. The compliance definitions herein thus have a general group for all implementations, and separate groups for the different types of ports, such as asynchronous and synchronous. The RS-232-like Hardware Port MIB includes RS-232, RS-422, RS-423, V.35, and other asynchronous or synchronous, serial physical links with a similar set of control signals. The MIB contains objects that relate to physical layer connections. Such connections may provide interesting hardware signals (other than for basic data transfer), such as RNG and DCD. Hardware ports also have such attributes as speed and bits per character. The MIB comprises one base object and four tables, detailed in the following sections. The tables contain objects for all ports, asynchronous ports, and input and output control signals. 3.1. Relationship to Interface MIB The RS-232-like MIB is one of many MIBs designed for complementary use as described in the Interface MIB [5]. In most implementations where it is present, it will be in the lowest interface sublayer, that is, the RS-232-like MIB represents the physical layer, providing service to higher layers such as the Character MIB [6] or PPP MIB [7]. The Interface MIBs ifTestTable and ifRcvAddressTable are not relevant to the RS-232-like MIB. The RS-232-like MIB is relevant for ifType values rs232(33), v35(45), and perhaps others. Expires 4 September 1994 [Page 4] draft RS-232-like MIB 4 March 1994 The RS-232-like MIB complements the conformance groups ifGeneralGroup, and ifFixedLengthGroup. Usefulness of error counters in this MIB depends on the octet counters in ifFixedLengthGroup. Expires 4 September 1994 [Page 5] draft RS-232-like MIB 4 March 1994 4. Definitions RS-232-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; rs232 MODULE-IDENTITY LAST-UPDATED "9403041700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for RS-232-like hardware devices." ::= { transmission 33 } Expires 4 September 1994 [Page 6] draft RS-232-like MIB 4 March 1994 -- Generic RS-232-like information rs232Number OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports (regardless of their current state) in the RS-232-like general port table." ::= { rs232 1 } -- RS-232-like General Port Table rs232PortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of rs232Number." ::= { rs232 2 } rs232PortEntry OBJECT-TYPE SYNTAX Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a port." INDEX { rs232PortIndex } ::= { rs232PortTable 1 } Rs232PortEntry ::= SEQUENCE { rs232PortIndex InterfaceIndex, rs232PortType INTEGER, rs232PortInSigNumber Integer32, rs232PortOutSigNumber Integer32, rs232PortInSpeed Integer32, rs232PortOutSpeed Expires 4 September 1994 [Page 7] draft RS-232-like MIB 4 March 1994 Integer32, rs232PortInFlowType INTEGER, rs232PortOutFlowType INTEGER } rs232PortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port, corresponding to the same value of ifIndex. By convention and if possible, hardware port numbers map directly to external connectors. The value for each port must remain constant at least from one re-initialization of the network management agent to the next." ::= { rs232PortEntry 1 } rs232PortType OBJECT-TYPE SYNTAX INTEGER { other(1), rs232(2), rs422(3), rs423(4), v35(5), x21(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's hardware type." ::= { rs232PortEntry 2 } rs232PortInSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input signals for the port in the input signal table (rs232PortInSigTable). The table contains entries only for those signals the software can detect and that are useful to observe." ::= { rs232PortEntry 3 } rs232PortOutSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires 4 September 1994 [Page 8] draft RS-232-like MIB 4 March 1994 "The number of output signals for the port in the output signal table (rs232PortOutSigTable). The table contains entries only for those signals the software can assert and that are useful to observe." ::= { rs232PortEntry 4 } rs232PortInSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's input speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 5 } rs232PortOutSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's output speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 6 } rs232PortInFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of input flow control. 'none' indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated hardware signals." ::= { rs232PortEntry 7 } rs232PortOutFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of output flow control. 'none' indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated Expires 4 September 1994 [Page 9] draft RS-232-like MIB 4 March 1994 hardware signals." ::= { rs232PortEntry 8 } Expires 4 September 1994 [Page 10] draft RS-232-like MIB 4 March 1994 -- RS-232-like Asynchronous Port Table rs232AsyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 3 } rs232AsyncPortEntry OBJECT-TYPE SYNTAX Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for an asynchronous port." INDEX { rs232AsyncPortIndex } ::= { rs232AsyncPortTable 1 } Rs232AsyncPortEntry ::= SEQUENCE { rs232AsyncPortIndex InterfaceIndex, rs232AsyncPortBits INTEGER, rs232AsyncPortStopBits INTEGER, rs232AsyncPortParity INTEGER, rs232AsyncPortAutobaud INTEGER, rs232AsyncPortParityErrs Counter32, rs232AsyncPortFramingErrs Counter32, rs232AsyncPortOverrunErrs Counter32 } rs232AsyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only Expires 4 September 1994 [Page 11] draft RS-232-like MIB 4 March 1994 STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232AsyncPortEntry 1 } rs232AsyncPortBits OBJECT-TYPE SYNTAX Integer (5..8) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of bits in a character." ::= { rs232AsyncPortEntry 2 } rs232AsyncPortStopBits OBJECT-TYPE SYNTAX INTEGER { one(1), two(2), oneAndHalf(3), dynamic(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of stop bits." ::= { rs232AsyncPortEntry 3 } rs232AsyncPortParity OBJECT-TYPE SYNTAX INTEGER { none(1), odd(2), even(3), mark(4), space(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's sense of a character parity bit." ::= { rs232AsyncPortEntry 4 } rs232AsyncPortAutobaud OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control for the port's ability to automatically sense input speed. When rs232PortAutoBaud is 'enabled', a port may autobaud to values different from the set values for speed, parity, and character size. As a result a network management system may temporarily observe values different from what was previously set." Expires 4 September 1994 [Page 12] draft RS-232-like MIB 4 March 1994 ::= { rs232AsyncPortEntry 5 } rs232AsyncPortParityErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a parity error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 6 } rs232AsyncPortFramingErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a framing error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 7 } rs232AsyncPortOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with an overrun error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 8 } Expires 4 September 1994 [Page 13] draft RS-232-like MIB 4 March 1994 -- RS-232-like Synchronous Port Table rs232SyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 4 } rs232SyncPortEntry OBJECT-TYPE SYNTAX Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a synchronous port." INDEX { rs232SyncPortIndex } ::= { rs232SyncPortTable 1 } Rs232SyncPortEntry ::= SEQUENCE { rs232SyncPortIndex InterfaceIndex, rs232SyncPortClockSource INTEGER, rs232SyncPortFrameCheckErrs Counter32, rs232SyncPortTransmitUnderrunErrs Counter32, rs232SyncPortReceiveOverrunErrs Counter32, rs232SyncPortInterruptedFrames Counter32, rs232SyncPortAbortedFrames Counter32, rs232SyncPortRole INTEGER, rs232SyncPortEncoding INTEGER, rs232SyncPortRTSControl INTEGER, rs232SyncPortRTSCTSDelay Integer32, Expires 4 September 1994 [Page 14] draft RS-232-like MIB 4 March 1994 rs232SyncPortMode INTEGER, rs232SyncPortIdlePattern INTEGER, rs232SyncPortMinFlags Integer32 } rs232SyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232SyncPortEntry 1 } rs232SyncPortClockSource OBJECT-TYPE SYNTAX INTEGER { internal(1), external(2), split(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Source of the port's bit rate clock. 'split' means the tranmit clock is internal and the receive clock is external." ::= { rs232SyncPortEntry 2 } rs232SyncPortFrameCheckErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames with an invalid frame check sequence, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 3 } rs232SyncPortTransmitUnderrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be transmitted on the port since system Expires 4 September 1994 [Page 15] draft RS-232-like MIB 4 March 1994 re-initialization and while the port state was 'up' or 'test' because data was not available to the transmitter in time." ::= { rs232SyncPortEntry 4 } rs232SyncPortReceiveOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be received on the port since system re-initialization and while the port state was 'up' or 'test' because the receiver did not accept the data in time." ::= { rs232SyncPortEntry 5 } rs232SyncPortInterruptedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be received or transmitted on the port due to loss of modem signals since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 6 } rs232SyncPortAbortedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames aborted on the port due to receiving an abort sequence since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 7 } rs232SyncPortRole OBJECT-TYPE SYNTAX INTEGER { dte(1), dce(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The role the device is playing that is using this port. dte means the device is performing the role of Expires 4 September 1994 [Page 16] draft RS-232-like MIB 4 March 1994 data terminal equipment dce means the device is performing the role of data circuit-terminating equipment." DEFVAL { dce } ::= { rs232SyncPortEntry 8 } rs232SyncPortEncoding OBJECT-TYPE SYNTAX INTEGER { nrz(1), nrzi(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The bit stream encoding technique that is in effect for this port. nrz for Non-Return to Zero encoding nrzi for Non-Return to Zero Inverted encoding." DEFVAL { nrz } ::= { rs232SyncPortEntry 9 } rs232SyncPortRTSControl OBJECT-TYPE SYNTAX INTEGER { controlled(1), constant(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The method used to control the Request To Send (RTS) signal. controlled when the DTE is asserts RTS each time data needs to be transmitted and drops RTS at some point after data transmission begins. If rs232SyncPortRole is 'dte', the RTS is an output signal. The device will issue a RTS and wait for a CTS from the DCE before starting to transmit. If rs232SyncPortRole is 'dce', the RTS is an input signal. The device will issue a CTS only after having received RTS and waiting the rs232SyncPortRTSCTSDelay interval. constant when the DTE constantly asserts RTS." DEFVAL { constant } Expires 4 September 1994 [Page 17] draft RS-232-like MIB 4 March 1994 ::= { rs232SyncPortEntry 10 } rs232SyncPortRTSCTSDelay OBJECT-TYPE SYNTAX Integer32 ACCESS read-write STATUS mandatory DESCRIPTION "The interval (in milliseconds) that the DCE must wait after it sees RTS asserted before asserting CTS. This object exists in support of older synchronous devices that cannot recognize CTS within a certain interval after it asserts RTS." DEFVAL { 0 } ::= { rs232SyncPortEntry 11 } rs232SyncPortMode OBJECT-TYPE SYNTAX INTEGER { fdx(1), hdx(2), simplex-receive(3), simplex-send(4) } ACCESS read-write STATUS mandatory DESCRIPTION "The mode of operation of the port with respect to the direction and simultaneity of data transfer. fdx when frames on the data link can be transmitted and received at the same time hdx when frames can either be received from the data link or transmitted onto the data link but not at the same time. simplex-receive when frames can only be received on this data link. simplex-send when frames can only be sent on this data link." DEFVAL { fdx } ::= { rs232SyncPortEntry 12 } rs232SyncPortIdlePattern OBJECT-TYPE SYNTAX INTEGER { mark(1), space(2) } ACCESS read-write STATUS mandatory Expires 4 September 1994 [Page 18] draft RS-232-like MIB 4 March 1994 DESCRIPTION "The bit pattern used to indicate an idle line." DEFVAL { space } ::= { rs232SyncPortEntry 13 } rs232SyncPortMinFlags OBJECT-TYPE SYNTAX Integer32 ACCESS read-write STATUS mandatory DESCRIPTION "The minimum number of flag patterns this port needs in order to recognize the end of one frame and the start of the next. Plausible values are 1 and 2." DEFVAL { 2 } ::= { rs232SyncPortEntry 14 } Expires 4 September 1994 [Page 19] draft RS-232-like MIB 4 March 1994 -- Input Signal Table rs232InSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port input control signal entries implemented and visible to the software on the port, and useful to monitor." ::= { rs232 5 } rs232InSigEntry OBJECT-TYPE SYNTAX Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Input control signal status for a hardware port." INDEX { rs232InSigPortIndex, rs232InSigName } ::= { rs232InSigTable 1 } Rs232InSigEntry ::= SEQUENCE { rs232InSigPortIndex InterfaceIndex, rs232InSigName INTEGER, rs232InSigState INTEGER, rs232InSigChanges Counter32 } rs232InSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232InSigEntry 1 } rs232InSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), Expires 4 September 1994 [Page 20] draft RS-232-like MIB 4 March 1994 scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232InSigEntry 2 } rs232InSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232InSigEntry 3 } rs232InSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232InSigEntry 4 } Expires 4 September 1994 [Page 21] draft RS-232-like MIB 4 March 1994 -- Output Signal Table rs232OutSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port output control signal entries implemented and visible to the software on the port, and useful to monitor." ::= { rs232 6 } rs232OutSigEntry OBJECT-TYPE SYNTAX Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Output control signal status for a hardware port." INDEX { rs232OutSigPortIndex, rs232OutSigName } ::= { rs232OutSigTable 1 } Rs232OutSigEntry ::= SEQUENCE { rs232OutSigPortIndex InterfaceIndex, rs232OutSigName INTEGER, rs232OutSigState INTEGER, rs232OutSigChanges Counter32 } rs232OutSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232OutSigEntry 1 } rs232OutSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), Expires 4 September 1994 [Page 22] draft RS-232-like MIB 4 March 1994 scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232OutSigEntry 2 } rs232OutSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232OutSigEntry 3 } rs232OutSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232OutSigEntry 4 } END Expires 4 September 1994 [Page 23] draft RS-232-like MIB 4 March 1994 -- conformance information rs232Conformance OBJECT IDENTIFIER ::= { rs232 7 } rs232Groups OBJECT IDENTIFIER ::= { rs232Conformance 1 } rs232Compliances OBJECT IDENTIFIER ::= { rs232Conformance 2 } -- compliance statements rs232Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have RS-232-like hardware interfaces." MODULE -- this module MANDATORY-GROUPS { rs232Group } GROUP rs232AsyncGroup DESCRIPTION "The Asynch group is mandatory only for those SNMPv2 entities which have asynchronous interfaces Rs-232-like." GROUP rs232SyncGroup DESCRIPTION "The Synch group is mandatory only for those SNMPv2 entities which have synchronous interfaces Rs-232-like." ::= { rs232Compliances 1 } Expires 4 September 1994 [Page 24] draft RS-232-like MIB 4 March 1994 -- units of conformance rs232Group OBJECT-GROUP OBJECTS { rs232Number, rs232PortIndex, rs232PortType, rs232PortInSigNumber, rs232PortOutSigNumber, rs232PortInSpeed, rs232PortOutSpeed, rs232PortInFlowType, rs232PortOutFlowType, rs232InSigPortIndex, rs232InSigName, rs232InSigState, rs232InSigChanges, rs232OutSigPortIndex, rs232OutSigName, rs232OutSigState, rs232OutSigChanges } STATUS current DESCRIPTION "A collection of objects providing information applicable to all RS-232-like interfaces." ::= { rs232Groups 1 } rs232AsyncGroup OBJECT-GROUP OBJECTS { rs232AsyncPortIndex, rs232AsyncPortBits, rs232AsyncPortStopBits, rs232AsyncPortParity, rs232AsyncPortAutobaud, rs232AsyncPortParityErrs rs232AsyncPortFramingErrs, rs232AsyncPortOverrunErrs } STATUS current DESCRIPTION "A collection of objects providing information applicable to asynchronous RS-232-like interfaces." ::= { rs232Groups 2 } rs232SyncGroup OBJECT-GROUP OBJECTS { rs232SyncPortIndex, rs232SyncPortClockSource, rs232SyncPortFrameCheckErrs, rs232SyncPortTransmitUnderrunErrs, rs232SyncPortReceiveOverrunErrs, rs232SyncPortInterruptedFrames, rs232SyncPortAbortedFrames } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces." ::= { rs232Groups 3 } rs232SyncSDLCGroup OBJECT-GROUP OBJECTS { rs232SyncPortRole, rs232SyncPortEncoding, rs232SyncPortRTSControl, Expires 4 September 1994 [Page 25] draft RS-232-like MIB 4 March 1994 rs232SyncPortRTSCTSDelay, rs232SyncPortMode, rs232SyncPortIdlePattern, rs232SyncPortMinFlags } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces running SDLC." ::= { rs232Groups 4 } END Expires 4 September 1994 [Page 26] draft RS-232-like MIB 4 March 1994 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. Expires 4 September 1994 [Page 27] draft RS-232-like MIB 4 March 1994 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F.J. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for Character Stream Devices", RFC ????, Xyplex, Inc., ?Mon?, 1994. [7] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June, 1993. Expires 4 September 1994 [Page 28] draft RS-232-like MIB 4 March 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com Phone: 508-952-4816 Email: rlstewart@eng.xyplex.com Expires 4 September 1994 [Page 29] draft RS-232-like MIB 4 March 1994 Table of Contents 1 Introduction .................................................... 2 2 The SNMPv2 Network Management Framework ......................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 3.1 Relationship to Interface MIB ................................. 4 4 Definitions ..................................................... 6 5 Acknowledgements ................................................ 27 6 References ...................................................... 28 7 Security Considerations ......................................... 29 8 Author's Address ................................................ 29 Expires 4 September 1994 [Page 30]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18093; 4 Mar 94 20:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18089; 4 Mar 94 20:36 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa01015; 4 Mar 94 20:36 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA20034; Fri, 4 Mar 94 17:17:23 -0800 Received: by nsl.pa.dec.com; id AA28131; Fri, 4 Mar 94 17:16:49 -0800 Received: by nsl.pa.dec.com; id AA28127; Fri, 4 Mar 94 17:16:48 -0800 Received: from relay1.UU.NET by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA19801; Fri, 4 Mar 94 17:10:48 -0800 Received: from uucp5.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwfvo12068; Fri, 4 Mar 94 20:09:22 -0500 Received: from synclib.UUCP by uucp5.uu.net with UUCP/RMAIL ; Fri, 4 Mar 1994 20:09:28 -0500 Received: from alan.sync.com by synclib.sync.COM id aa11983; Fri, 4 Mar 94 17:07:48 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alan K. Bartky, Manager of Technology" To: char-mib@pa.dec.com, snadlcmib@cisco.com Subject: RE: Consensus Check - SDLC Objects for RS-232 MIB Reply-To: alan@synclib.sync.com Date: Fri, 4 Mar 94 17:06:56 PST Message-Id: <9403050106.382BB4@alan.sync.com> X-Mailer: SelectMAIL 1.0 I believe that you will find that in actuallity only the NRZ/NRZI parameter and the port idle patter pertains directly to SDLC. The other parameters are used by either X.25/HDLC and other synchronous protocols. Certainly most of the parmeters are simple to implement as many implementations (HDLC ones) can just default the values. Here are some of the reasons we at Sync Research think the parameters are important. (These comments are based on Wayne's email message of December 22, 1993) (1) Sync Port Role. All of Sync Research's latest products have the ability (regardless of running Sync or Async) to be software configured as DCE or DTE. This field is of importance to us. It is also certainly usefull for even fixed devices for information purposes. Devices that can't be reconfigured should certainly know and could report their role as DCE or DTE. (2) Encoding Only SDLC (to my knowledge uses NRZI encoding), but this is an easy parameter for HDLC (only allow/report NRZ) and is required for SDLC. (3)RTS control and (4)delay. In out products we support RTS switched control for both bisync, univac and SDLC protocols. Proper configuration of these parameters is critical to Synchronous port operation. (Yes we do support SNMP for Bisync ports!) (5) Mode of Operation There are other protocols besides SDLC that are HDX protocols (again we support Bisync with SNMP support). Setting of this parameter is crucial for SDLC. HDLC, Frame Relay, etc. can set/report FDX. (6) Port Idle pattern. This is usefull and required for some SDLC devices. It seems that flags as an option was missed (i.e. options should be mark, space or flags). Again HDLC/Frame relay ports can easily default this parm (to flags) and not make it setable. (7) Minimum number of flags This is usefull for determining problems. Some devices do not support single flag separation (especially at high speeds). If an attached device requires more flags than 1, setting this object will allow it to operate (We have a lot of field experience on Frame Relay, X.25/HDLC and SDLC that have required us to insert more than one flag in order to get an interface to work properly). The description might need to be rewritten to beter define it's need. Devices that don't support adding or controlling the number of flags between frames could hard code it. (8) Runt and (9) Giant Frames Frames that are too small or large is a usefull concept for all synchronous protocols! Regards, Alan K. Bartky Manager of Technology Sync Research Inc. 7 Studebaker Irvine, CA. 92718-2013 (714) 588-2070 FAX: (714) 588-2080 email: alan@sync.com --- Begin Included Message (edited) --- From POP2-Server@synclib Fri Mar 4 16:31:56 1994 Date: Thu, 3 Mar 94 10:25:51 -0500 Message-Id: <9403031525.AA28766@xap.xyplex.com> From: Bob Stewart To: xyplex.com!pa.dec.com!char-mib@uunet.UUCP, xyplex.com!cisco.com!snadlcmib@uunet.UUCP Subject: Consensus Check - SDLC Objects for RS-232 MIB Content-Length: 503 Status: A few people spoke in favor of adding some SDLC-related objects to the RS-232 MIB. They were reposted just recently by Wayne Clark, SNA SDLC MIB editor. They could be added as a separate compliance group for SDLC, but I didn't do so due to the general apathy. The following test of consensus is intended to insite response. Depending on the response, I may try the other way around. ******** Consensus Test ********* Are there strong objections to leaving out the proposed SDLC objects? Bob --- End Included Message ---   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08517; 7 Mar 94 11:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08496; 7 Mar 94 11:49 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21290; 7 Mar 94 11:49 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08448; 7 Mar 94 11:49 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08244; 7 Mar 94 11:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: char-mib@decwrl.dec.com X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-charmib-rs232-mib-01.txt Date: Mon, 07 Mar 94 11:42:05 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403071142.aa08244@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Character MIB Working Group of the IETF. Title : RS-232-like MIB Author(s) : B. Stewart Filename : draft-ietf-charmib-rs232-mib-01.txt Pages : 30 Date : 03/04/1994 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-charmib-rs232-mib-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-charmib-rs232-mib-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940304163545.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-charmib-rs232-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-charmib-rs232-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940304163545.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17359; 7 Mar 94 17:30 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17355; 7 Mar 94 17:30 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa01230; 7 Mar 94 17:30 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA05873; Mon, 7 Mar 94 14:19:05 -0800 Received: by nsl.pa.dec.com; id AA08610; Mon, 7 Mar 94 13:50:22 -0800 Received: by nsl.pa.dec.com; id AA08606; Mon, 7 Mar 94 13:50:19 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA17562; Mon, 7 Mar 94 13:42:35 -0800 Received: by xap.xyplex.com id ; Mon, 7 Mar 94 16:33:10 -0500 Date: Mon, 7 Mar 94 16:33:10 -0500 Message-Id: <9403072133.AA14284@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: tacox@mail.bellcore.com Cc: mrose@dbc.mtview.ca.us, char-mib@pa.dec.com In-Reply-To: Tracy Brown's message of Fri, 4 Mar 94 10:15:03 EST <9403041515.AA01536@ginsu4> Subject: Re: review of 3 I-Ds WG Members, Tracy is reviewing our Internet Drafts for the Network Management Directorate. Tracy, Thanks. >(Quick review was helped by 6 more inches of snow that >fell Wednesday night, and the ability to work at home. >How bad is it in NH/MA Bob? It is the tundra in NJ! >Spring will never come!) We got dumped on Wednesday, too. My 1/4 mile, semi-verticle driveway got plowed late Thursday afternoon, then it snowed some more Friday, and the guy didn't plow it. I got stuck Friday, Saturday various vehicles went in and out, some 4-wheel drive, then Sunday morning it had frozen and my son got stuck. New Hampshire looks like Antarctica with trees. Back to business. >Character MIB: > >-- You use the words "experimental portion in" in the Introduction? >Should you say "extension to" instead. This MIB is >not an experimental MIB? Leftover boilerplate. Fixed. >-- have you gotten an ifType from IANA? No. I'll request that. >-- InterfaceIndex does not pass MOSY (warning) >>From mosy: >warning: object "charPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "charSessPortIndex" has unknown SYNTAX "InterfaceIndex" >What are we doing about this issue? I started to change the IMPORTS to RFC-1573, then became unsure, since the module that contains the textual convention is IF-MIB. I believe that should do it, barring problems with compilers. >-- charSessConnectId is an InstancePointer: what does it >point to? >First accessible object in the MIB? The definition of the textual convention says that it's the first columnar object in the conceptual row. >-- charAsyncGroup is not defined as an OBJECT-GROUP >same for charSyncGroup (There are no other objects in MIB; >every object >is in charGroup?) Cut and paste error. Those should have been deleted. Ther is only one group. >-- charPortSessionMaximum should have a SYNTAX of INTEGER >if it is to be further bounded; see RFC1442. >Same with charPortSessionIndex. >Same with charSessIndex. The SEQUENCE and the OBJECT-TYPE for charPortSessionMaximum were out of synch. The OBJECT-TYPE has a bounds, so I changed the SEQUENCE to INTEGER. Similar deal for charPortSessionIndex, and charSessIndex. They're bounded and are both INTEGERS. >Parallel-printer-like MIB: > >-- You use the words "experimental portion in" in the Introduction? >Should you say "extension to" instead. This is >not an experimental MIB? Fixed. >-- InterfaceIndex does not pass MOSY (warning) >>From mosy: >warning: object "paraPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "paraInSigPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "paraOutSigPortIndex" has unknown SYNTAX "InterfaceIndex" Same excuse as for Character MIB. >-- There is an END clause before the conformance information Fixed. >RS-232-like MIB: > >-- You use the words "experimental portion in" in the Introduction? >Should you say "extension to" instead. This is >not an experimental MIB? Fixed. >-- InterfaceIndex does not pass MOSY (warning) >>From mosy: >warning: object "rs232PortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "rs232AsyncPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "rs232AsyncPortBits" has unknown SYNTAX "Integer" >warning: object "rs232SyncPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "rs232InSigPortIndex" has unknown SYNTAX "InterfaceIndex" >warning: object "rs232OutSigPortIndex" has unknown SYNTAX "InterfaceIndex" Same excuse as Parallel MIB >-- There is an END clause before the conformance information Fixed. >-- How does ifSpeed in the ifMIB relate to rs232PortInSpeed and >rs232PortOutSpeed? Uhhhhh. I suppose all we can do is pick one for it to match. I pick rs232PortOutSpeed. I added that to the "Relationship to Interface MIB" section. >-- rs232AsyncPortBits has a SYNTAX of Integer should be >INTEGER. Fixed. I've made these changes and will wait a while to see if any other comments come in. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04540; 19 Mar 94 21:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04536; 19 Mar 94 21:31 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14787; 19 Mar 94 21:31 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16155; Sat, 19 Mar 94 18:20:27 -0800 Received: by nsl.pa.dec.com; id AA21264; Sat, 19 Mar 94 17:51:03 -0800 Received: by nsl.pa.dec.com; id AA21260; Sat, 19 Mar 94 17:51:02 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA29380; Sat, 19 Mar 94 17:49:07 -0800 Received: by xap.xyplex.com id ; Sat, 19 Mar 94 20:49:57 -0500 Date: Sat, 19 Mar 94 20:49:57 -0500 Message-Id: <9403200149.AA00838@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: internet-drafts@CNRI.Reston.VA.US Cc: char-mib@pa.dec.com Subject: New RS-232 MIB Draft draft RS-232-like MIB 15 March 1994 RS-232-like MIB 15 March 1994 Bob Stewart Xyplex, Inc. rlstewart@eng.xyplex.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires 15 September 1994 [Page 1] draft RS-232-like MIB 15 March 1994 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. Expires 15 September 1994 [Page 2] draft RS-232-like MIB 15 March 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 15 September 1994 [Page 3] draft RS-232-like MIB 15 March 1994 3. Overview The RS-232-like Hardware Device MIB applies to interface ports that might logically support the Interface MIB, a Transmission MIB, or the Character MIB. The most common example is an RS-232 port with modem signals. The RS-232-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB. The MIB includes multiple similar types of hardware, and as a result contains objects not applicable to all of those types. The compliance definitions herein thus have a general group for all implementations, and separate groups for the different types of ports, such as asynchronous and synchronous. The RS-232-like Hardware Port MIB includes RS-232, RS-422, RS-423, V.35, and other asynchronous or synchronous, serial physical links with a similar set of control signals. The MIB contains objects that relate to physical layer connections. Such connections may provide interesting hardware signals (other than for basic data transfer), such as RNG and DCD. Hardware ports also have such attributes as speed and bits per character. The MIB comprises one base object and four tables, detailed in the following sections. The tables contain objects for all ports, asynchronous ports, and input and output control signals. 3.1. Relationship to Interface MIB The RS-232-like MIB is one of many MIBs designed for complementary use as described in the Interface MIB [5]. In most implementations where it is present, it will be in the lowest interface sublayer, that is, the RS-232-like MIB represents the physical layer, providing service to higher layers such as the Character MIB [6] or PPP MIB [7]. The Interface MIBs ifTestTable and ifRcvAddressTable are not relevant to the RS-232-like MIB. The RS-232-like MIB is relevant for ifType values rs232(33), v35(45), and perhaps others. Expires 15 September 1994 [Page 4] draft RS-232-like MIB 15 March 1994 The RS-232-like MIB complements the conformance groups ifGeneralGroup, and ifFixedLengthGroup. For interfaces that implement rs232PortInSpeed and rs232PortOutSpeed, the value of ifSpeed is the same as rs232PortOutSpeed. Usefulness of error counters in this MIB depends on the octet counters in ifFixedLengthGroup. Expires 15 September 1994 [Page 5] draft RS-232-like MIB 15 March 1994 4. Definitions RS-232-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; rs232 MODULE-IDENTITY LAST-UPDATED "9403151700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for RS-232-like hardware devices." ::= { transmission 33 } Expires 15 September 1994 [Page 6] draft RS-232-like MIB 15 March 1994 -- Generic RS-232-like information rs232Number OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports (regardless of their current state) in the RS-232-like general port table." ::= { rs232 1 } -- RS-232-like General Port Table rs232PortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of rs232Number." ::= { rs232 2 } rs232PortEntry OBJECT-TYPE SYNTAX Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a port." INDEX { rs232PortIndex } ::= { rs232PortTable 1 } Rs232PortEntry ::= SEQUENCE { rs232PortIndex InterfaceIndex, rs232PortType INTEGER, rs232PortInSigNumber Integer32, rs232PortOutSigNumber Integer32, rs232PortInSpeed Integer32, rs232PortOutSpeed Expires 15 September 1994 [Page 7] draft RS-232-like MIB 15 March 1994 Integer32, rs232PortInFlowType INTEGER, rs232PortOutFlowType INTEGER } rs232PortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port, corresponding to the same value of ifIndex. By convention and if possible, hardware port numbers map directly to external connectors. The value for each port must remain constant at least from one re-initialization of the network management agent to the next." ::= { rs232PortEntry 1 } rs232PortType OBJECT-TYPE SYNTAX INTEGER { other(1), rs232(2), rs422(3), rs423(4), v35(5), x21(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's hardware type." ::= { rs232PortEntry 2 } rs232PortInSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input signals for the port in the input signal table (rs232PortInSigTable). The table contains entries only for those signals the software can detect and that are useful to observe." ::= { rs232PortEntry 3 } rs232PortOutSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires 15 September 1994 [Page 8] draft RS-232-like MIB 15 March 1994 "The number of output signals for the port in the output signal table (rs232PortOutSigTable). The table contains entries only for those signals the software can assert and that are useful to observe." ::= { rs232PortEntry 4 } rs232PortInSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's input speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 5 } rs232PortOutSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's output speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 6 } rs232PortInFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of input flow control. 'none' indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated hardware signals." ::= { rs232PortEntry 7 } rs232PortOutFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of output flow control. 'none' indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated Expires 15 September 1994 [Page 9] draft RS-232-like MIB 15 March 1994 hardware signals." ::= { rs232PortEntry 8 } Expires 15 September 1994 [Page 10] draft RS-232-like MIB 15 March 1994 -- RS-232-like Asynchronous Port Table rs232AsyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 3 } rs232AsyncPortEntry OBJECT-TYPE SYNTAX Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for an asynchronous port." INDEX { rs232AsyncPortIndex } ::= { rs232AsyncPortTable 1 } Rs232AsyncPortEntry ::= SEQUENCE { rs232AsyncPortIndex InterfaceIndex, rs232AsyncPortBits INTEGER, rs232AsyncPortStopBits INTEGER, rs232AsyncPortParity INTEGER, rs232AsyncPortAutobaud INTEGER, rs232AsyncPortParityErrs Counter32, rs232AsyncPortFramingErrs Counter32, rs232AsyncPortOverrunErrs Counter32 } rs232AsyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only Expires 15 September 1994 [Page 11] draft RS-232-like MIB 15 March 1994 STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232AsyncPortEntry 1 } rs232AsyncPortBits OBJECT-TYPE SYNTAX INTEGER (5..8) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of bits in a character." ::= { rs232AsyncPortEntry 2 } rs232AsyncPortStopBits OBJECT-TYPE SYNTAX INTEGER { one(1), two(2), oneAndHalf(3), dynamic(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of stop bits." ::= { rs232AsyncPortEntry 3 } rs232AsyncPortParity OBJECT-TYPE SYNTAX INTEGER { none(1), odd(2), even(3), mark(4), space(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's sense of a character parity bit." ::= { rs232AsyncPortEntry 4 } rs232AsyncPortAutobaud OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control for the port's ability to automatically sense input speed. When rs232PortAutoBaud is 'enabled', a port may autobaud to values different from the set values for speed, parity, and character size. As a result a network management system may temporarily observe values different from what was previously set." Expires 15 September 1994 [Page 12] draft RS-232-like MIB 15 March 1994 ::= { rs232AsyncPortEntry 5 } rs232AsyncPortParityErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a parity error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 6 } rs232AsyncPortFramingErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a framing error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 7 } rs232AsyncPortOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with an overrun error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 8 } Expires 15 September 1994 [Page 13] draft RS-232-like MIB 15 March 1994 -- RS-232-like Synchronous Port Table rs232SyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 4 } rs232SyncPortEntry OBJECT-TYPE SYNTAX Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a synchronous port." INDEX { rs232SyncPortIndex } ::= { rs232SyncPortTable 1 } Rs232SyncPortEntry ::= SEQUENCE { rs232SyncPortIndex InterfaceIndex, rs232SyncPortClockSource INTEGER, rs232SyncPortFrameCheckErrs Counter32, rs232SyncPortTransmitUnderrunErrs Counter32, rs232SyncPortReceiveOverrunErrs Counter32, rs232SyncPortInterruptedFrames Counter32, rs232SyncPortAbortedFrames Counter32, rs232SyncPortRole INTEGER, rs232SyncPortEncoding INTEGER, rs232SyncPortRTSControl INTEGER, rs232SyncPortRTSCTSDelay Integer32, Expires 15 September 1994 [Page 14] draft RS-232-like MIB 15 March 1994 rs232SyncPortMode INTEGER, rs232SyncPortIdlePattern INTEGER, rs232SyncPortMinFlags Integer32 } rs232SyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232SyncPortEntry 1 } rs232SyncPortClockSource OBJECT-TYPE SYNTAX INTEGER { internal(1), external(2), split(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Source of the port's bit rate clock. 'split' means the tranmit clock is internal and the receive clock is external." ::= { rs232SyncPortEntry 2 } rs232SyncPortFrameCheckErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames with an invalid frame check sequence, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 3 } rs232SyncPortTransmitUnderrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be transmitted on the port since system Expires 15 September 1994 [Page 15] draft RS-232-like MIB 15 March 1994 re-initialization and while the port state was 'up' or 'test' because data was not available to the transmitter in time." ::= { rs232SyncPortEntry 4 } rs232SyncPortReceiveOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be received on the port since system re-initialization and while the port state was 'up' or 'test' because the receiver did not accept the data in time." ::= { rs232SyncPortEntry 5 } rs232SyncPortInterruptedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be received or transmitted on the port due to loss of modem signals since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 6 } rs232SyncPortAbortedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames aborted on the port due to receiving an abort sequence since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 7 } rs232SyncPortRole OBJECT-TYPE SYNTAX INTEGER { dte(1), dce(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The role the device is playing that is using this port. dte means the device is performing the role of Expires 15 September 1994 [Page 16] draft RS-232-like MIB 15 March 1994 data terminal equipment dce means the device is performing the role of data circuit-terminating equipment." DEFVAL { dce } ::= { rs232SyncPortEntry 8 } rs232SyncPortEncoding OBJECT-TYPE SYNTAX INTEGER { nrz(1), nrzi(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The bit stream encoding technique that is in effect for this port. nrz for Non-Return to Zero encoding nrzi for Non-Return to Zero Inverted encoding." DEFVAL { nrz } ::= { rs232SyncPortEntry 9 } rs232SyncPortRTSControl OBJECT-TYPE SYNTAX INTEGER { controlled(1), constant(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The method used to control the Request To Send (RTS) signal. controlled when the DTE is asserts RTS each time data needs to be transmitted and drops RTS at some point after data transmission begins. If rs232SyncPortRole is 'dte', the RTS is an output signal. The device will issue a RTS and wait for a CTS from the DCE before starting to transmit. If rs232SyncPortRole is 'dce', the RTS is an input signal. The device will issue a CTS only after having received RTS and waiting the rs232SyncPortRTSCTSDelay interval. constant when the DTE constantly asserts RTS." DEFVAL { constant } Expires 15 September 1994 [Page 17] draft RS-232-like MIB 15 March 1994 ::= { rs232SyncPortEntry 10 } rs232SyncPortRTSCTSDelay OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The interval (in milliseconds) that the DCE must wait after it sees RTS asserted before asserting CTS. This object exists in support of older synchronous devices that cannot recognize CTS within a certain interval after it asserts RTS." DEFVAL { 0 } ::= { rs232SyncPortEntry 11 } rs232SyncPortMode OBJECT-TYPE SYNTAX INTEGER { fdx(1), hdx(2), simplex-receive(3), simplex-send(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The mode of operation of the port with respect to the direction and simultaneity of data transfer. fdx when frames on the data link can be transmitted and received at the same time hdx when frames can either be received from the data link or transmitted onto the data link but not at the same time. simplex-receive when frames can only be received on this data link. simplex-send when frames can only be sent on this data link." DEFVAL { fdx } ::= { rs232SyncPortEntry 12 } rs232SyncPortIdlePattern OBJECT-TYPE SYNTAX INTEGER { mark(1), space(2) } MAX-ACCESS read-write STATUS current Expires 15 September 1994 [Page 18] draft RS-232-like MIB 15 March 1994 DESCRIPTION "The bit pattern used to indicate an idle line." DEFVAL { space } ::= { rs232SyncPortEntry 13 } rs232SyncPortMinFlags OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum number of flag patterns this port needs in order to recognize the end of one frame and the start of the next. Plausible values are 1 and 2." DEFVAL { 2 } ::= { rs232SyncPortEntry 14 } Expires 15 September 1994 [Page 19] draft RS-232-like MIB 15 March 1994 -- Input Signal Table rs232InSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port input control signal entries implemented and visible to the software on the port, and useful to monitor." ::= { rs232 5 } rs232InSigEntry OBJECT-TYPE SYNTAX Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Input control signal status for a hardware port." INDEX { rs232InSigPortIndex, rs232InSigName } ::= { rs232InSigTable 1 } Rs232InSigEntry ::= SEQUENCE { rs232InSigPortIndex InterfaceIndex, rs232InSigName INTEGER, rs232InSigState INTEGER, rs232InSigChanges Counter32 } rs232InSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232InSigEntry 1 } rs232InSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), Expires 15 September 1994 [Page 20] draft RS-232-like MIB 15 March 1994 scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232InSigEntry 2 } rs232InSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232InSigEntry 3 } rs232InSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232InSigEntry 4 } Expires 15 September 1994 [Page 21] draft RS-232-like MIB 15 March 1994 -- Output Signal Table rs232OutSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port output control signal entries implemented and visible to the software on the port, and useful to monitor." ::= { rs232 6 } rs232OutSigEntry OBJECT-TYPE SYNTAX Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Output control signal status for a hardware port." INDEX { rs232OutSigPortIndex, rs232OutSigName } ::= { rs232OutSigTable 1 } Rs232OutSigEntry ::= SEQUENCE { rs232OutSigPortIndex InterfaceIndex, rs232OutSigName INTEGER, rs232OutSigState INTEGER, rs232OutSigChanges Counter32 } rs232OutSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232OutSigEntry 1 } rs232OutSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), Expires 15 September 1994 [Page 22] draft RS-232-like MIB 15 March 1994 scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232OutSigEntry 2 } rs232OutSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232OutSigEntry 3 } rs232OutSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232OutSigEntry 4 } Expires 15 September 1994 [Page 23] draft RS-232-like MIB 15 March 1994 -- conformance information rs232Conformance OBJECT IDENTIFIER ::= { rs232 7 } rs232Groups OBJECT IDENTIFIER ::= { rs232Conformance 1 } rs232Compliances OBJECT IDENTIFIER ::= { rs232Conformance 2 } -- compliance statements rs232Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have RS-232-like hardware interfaces." MODULE -- this module MANDATORY-GROUPS { rs232Group } GROUP rs232AsyncGroup DESCRIPTION "The Asynch group is mandatory only for those SNMPv2 entities which have asynchronous interfaces Rs-232-like." GROUP rs232SyncGroup DESCRIPTION "The Synch group is mandatory only for those SNMPv2 entities which have synchronous interfaces Rs-232-like." ::= { rs232Compliances 1 } Expires 15 September 1994 [Page 24] draft RS-232-like MIB 15 March 1994 -- units of conformance rs232Group OBJECT-GROUP OBJECTS { rs232Number, rs232PortIndex, rs232PortType, rs232PortInSigNumber, rs232PortOutSigNumber, rs232PortInSpeed, rs232PortOutSpeed, rs232PortInFlowType, rs232PortOutFlowType, rs232InSigPortIndex, rs232InSigName, rs232InSigState, rs232InSigChanges, rs232OutSigPortIndex, rs232OutSigName, rs232OutSigState, rs232OutSigChanges } STATUS current DESCRIPTION "A collection of objects providing information applicable to all RS-232-like interfaces." ::= { rs232Groups 1 } rs232AsyncGroup OBJECT-GROUP OBJECTS { rs232AsyncPortIndex, rs232AsyncPortBits, rs232AsyncPortStopBits, rs232AsyncPortParity, rs232AsyncPortAutobaud, rs232AsyncPortParityErrs, rs232AsyncPortFramingErrs, rs232AsyncPortOverrunErrs } STATUS current DESCRIPTION "A collection of objects providing information applicable to asynchronous RS-232-like interfaces." ::= { rs232Groups 2 } rs232SyncGroup OBJECT-GROUP OBJECTS { rs232SyncPortIndex, rs232SyncPortClockSource, rs232SyncPortFrameCheckErrs, rs232SyncPortTransmitUnderrunErrs, rs232SyncPortReceiveOverrunErrs, rs232SyncPortInterruptedFrames, rs232SyncPortAbortedFrames } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces." ::= { rs232Groups 3 } rs232SyncSDLCGroup OBJECT-GROUP OBJECTS { rs232SyncPortRole, rs232SyncPortEncoding, rs232SyncPortRTSControl, Expires 15 September 1994 [Page 25] draft RS-232-like MIB 15 March 1994 rs232SyncPortRTSCTSDelay, rs232SyncPortMode, rs232SyncPortIdlePattern, rs232SyncPortMinFlags } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces running SDLC." ::= { rs232Groups 4 } END Expires 15 September 1994 [Page 26] draft RS-232-like MIB 15 March 1994 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. Expires 15 September 1994 [Page 27] draft RS-232-like MIB 15 March 1994 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F.J. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for Character Stream Devices", RFC ????, Xyplex, Inc., ?Mon?, 1994. [7] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June, 1993. Expires 15 September 1994 [Page 28] draft RS-232-like MIB 15 March 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com Phone: 508-952-4816 Email: rlstewart@eng.xyplex.com Expires 15 September 1994 [Page 29] draft RS-232-like MIB 15 March 1994 Table of Contents 1 Introduction .................................................... 2 2 The SNMPv2 Network Management Framework ......................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 3.1 Relationship to Interface MIB ................................. 4 4 Definitions ..................................................... 6 5 Acknowledgements ................................................ 27 6 References ...................................................... 28 7 Security Considerations ......................................... 29 8 Author's Address ................................................ 29 Expires 15 September 1994 [Page 30]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04558; 19 Mar 94 21:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04554; 19 Mar 94 21:36 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14887; 19 Mar 94 21:36 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16024; Sat, 19 Mar 94 18:17:40 -0800 Received: by nsl.pa.dec.com; id AA21282; Sat, 19 Mar 94 17:56:28 -0800 Received: by nsl.pa.dec.com; id AA21278; Sat, 19 Mar 94 17:56:28 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA29551; Sat, 19 Mar 94 17:52:39 -0800 Received: by xap.xyplex.com id ; Sat, 19 Mar 94 20:53:44 -0500 Date: Sat, 19 Mar 94 20:53:44 -0500 Message-Id: <9403200153.AA00980@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: char-mib@pa.dec.com Subject: New MIB Drafts The MIB drafts filling your mailboxes reflect the few comments I got, mostly minor edits. The major edit responds to the NM Directorate review and an attempt to get an ifType for 'character'. The Directorate decided that the Character MIB is not a proper candidate for the ifTable, since it isn't a network interface. I modified the MIB accordingly, reinstating the deprecated objects and making the charPortIndex its own space that might parallel the ifIndexes of its RS-232 ports. I added an object for the ifIndex of lower level hardware, assuming that any lower level hardware can be wiggled into the ifTable (parallel made it). I believe these will represent our final drafts, unless I made more mistakes. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04572; 19 Mar 94 21:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04568; 19 Mar 94 21:37 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14904; 19 Mar 94 21:37 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16058; Sat, 19 Mar 94 18:18:03 -0800 Received: by nsl.pa.dec.com; id AA21252; Sat, 19 Mar 94 17:51:01 -0800 Received: by nsl.pa.dec.com; id AA21248; Sat, 19 Mar 94 17:51:00 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA29401; Sat, 19 Mar 94 17:49:29 -0800 Received: by xap.xyplex.com id ; Sat, 19 Mar 94 20:50:21 -0500 Date: Sat, 19 Mar 94 20:50:21 -0500 Message-Id: <9403200150.AA00855@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: internet-drafts@CNRI.Reston.VA.US Cc: char-mib@pa.dec.com Subject: New Parallel MIB Draft draft Parallel-printer-like MIB 7 March 1994 Parallel-printer-like MIB 7 March 1994 Bob Stewart Xyplex, Inc. rlstewart@eng.xyplex.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires 7 September 1994 [Page 1] draft Parallel-printer-like MIB 7 March 1994 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. Expires 7 September 1994 [Page 2] draft Parallel-printer-like MIB 7 March 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 7 September 1994 [Page 3] draft Parallel-printer-like MIB 7 March 1994 3. Overview The Parallel-printer-like Hardware Device MIB applies to interface ports that would most probably support the Character MIB. The most common example is Centronics-like printer port. The Parallel-printer-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB. The Parallel-printer-like Hardware Port MIB includes Centronics-like and Data-Products-like parallel physical links with a similar set of control signals. The MIB contains objects that relate to physical layer connections. The MIB comprises one base object and three tables, detailed in the following sections. The tables contain objects for ports and input and output control signals. 3.1. Relationship to Interface MIB The Parallel-printer-like MIB is one of many MIBs designed for complementary use as described in the Interface MIB [5]. In most implementations where it is present, it will be in the lowest interface sublayer, that is, the Parallel-printer-like MIB represents the physical layer, providing service to higher layers such as the Character MIB [6]. Although it is unlikely that a parallel printer port will actually be used as a network interface, which is the intent of the Interface MIB, the Parallel-printer-like MIB is closely connected to the Character MIB, which can share hardware interfaces with network operation, and relate to the RS-232 MIB [7]. The Interface MIBs ifTestTable and ifRcvAddressTable are not relevant to the Parallel-printer-like MIB. The Parallel-printer-like MIB is relevant for ifType values para(34) and perhaps others. The Parallel-printer-like MIB complements the conformance groups ifGeneralGroup, and ifFixedLengthGroup. Usefulness of error counters in this MIB depends on the octet counters Expires 7 September 1994 [Page 4] draft Parallel-printer-like MIB 7 March 1994 in ifFixedLengthGroup. Expires 7 September 1994 [Page 5] draft Parallel-printer-like MIB 7 March 1994 4. Definitions PARALLEL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; para MODULE-IDENTITY LAST-UPDATED "9403071700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for Parallel-printer-like hardware devices." ::= { transmission 34 } Expires 7 September 1994 [Page 6] draft Parallel-printer-like MIB 7 March 1994 -- Generic Parallel-printer-like information paraNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports (regardless of their current state) in the Parallel-printer-like port table." ::= { para 1 } -- the Parallel-printer-like Port table paraPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of paraNumber." ::= { para 2 } paraPortEntry OBJECT-TYPE SYNTAX ParaPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a port." INDEX { paraPortIndex } ::= { paraPortTable 1 } ParaPortEntry ::= SEQUENCE { paraPortIndex InterfaceIndex, paraPortType INTEGER, paraPortInSigNumber Integer32, paraPortOutSigNumber Integer32 } paraPortIndex OBJECT-TYPE Expires 7 September 1994 [Page 7] draft Parallel-printer-like MIB 7 March 1994 SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port, corresponding to the same value of ifIndex. By convention and if possible, hardware port numbers map directly to external connectors. The value for each port must remain constant at least from one re-initialization of the network management agent to the next." ::= { paraPortEntry 1 } paraPortType OBJECT-TYPE SYNTAX INTEGER { other(1), centronics(2), dataproducts(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's hardware type." ::= { paraPortEntry 2 } paraPortInSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input signals for the port in the input signal table (paraPortInSigTable). The table contains entries only for those signals the software can detect and that are useful to observe." ::= { paraPortEntry 3 } paraPortOutSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output signals for the port in the output signal table (paraPortOutSigTable). The table contains entries only for those signals the software can assert and that are useful to observe." ::= { paraPortEntry 4 } Expires 7 September 1994 [Page 8] draft Parallel-printer-like MIB 7 March 1994 -- Parallel-printer-like Input Signal Table paraInSigTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaInSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port input control signal entries." ::= { para 3 } paraInSigEntry OBJECT-TYPE SYNTAX ParaInSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Input control signal status for a hardware port." INDEX { paraInSigPortIndex, paraInSigName } ::= { paraInSigTable 1 } ParaInSigEntry ::= SEQUENCE { paraInSigPortIndex InterfaceIndex, paraInSigName INTEGER, paraInSigState INTEGER, paraInSigChanges Counter32 } paraInSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of paraPortIndex for the port to which this entry belongs." ::= { paraInSigEntry 1 } paraInSigName OBJECT-TYPE SYNTAX INTEGER { power(1), online(2), busy(3), paperout(4), fault(5) } MAX-ACCESS read-only STATUS current Expires 7 September 1994 [Page 9] draft Parallel-printer-like MIB 7 March 1994 DESCRIPTION "Identification of a hardware signal." ::= { paraInSigEntry 2 } paraInSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { paraInSigEntry 3 } paraInSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { paraInSigEntry 4 } Expires 7 September 1994 [Page 10] draft Parallel-printer-like MIB 7 March 1994 -- Output Signal Table paraOutSigTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaOutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port output control signal entries." ::= { para 4 } paraOutSigEntry OBJECT-TYPE SYNTAX ParaOutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Output control signal status for a hardware port." INDEX { paraOutSigPortIndex, paraOutSigName } ::= { paraOutSigTable 1 } ParaOutSigEntry ::= SEQUENCE { paraOutSigPortIndex InterfaceIndex, paraOutSigName INTEGER, paraOutSigState INTEGER, paraOutSigChanges Counter32 } paraOutSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of paraPortIndex for the port to which this entry belongs." ::= { paraOutSigEntry 1 } paraOutSigName OBJECT-TYPE SYNTAX INTEGER { power(1), online(2), busy(3), paperout(4), fault(5) } MAX-ACCESS read-only STATUS current Expires 7 September 1994 [Page 11] draft Parallel-printer-like MIB 7 March 1994 DESCRIPTION "Identification of a hardware signal." ::= { paraOutSigEntry 2 } paraOutSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { paraOutSigEntry 3 } paraOutSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { paraOutSigEntry 4 } Expires 7 September 1994 [Page 12] draft Parallel-printer-like MIB 7 March 1994 -- conformance information paraConformance OBJECT IDENTIFIER ::= { para 5 } paraGroups OBJECT IDENTIFIER ::= { paraConformance 1 } paraCompliances OBJECT IDENTIFIER ::= { paraConformance 2 } -- compliance statements paraCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have Parallel-printer-like hardware interfaces." MODULE -- this module MANDATORY-GROUPS { paraGroup } ::= { paraCompliances 1 } Expires 7 September 1994 [Page 13] draft Parallel-printer-like MIB 7 March 1994 -- units of conformance paraGroup OBJECT-GROUP OBJECTS { paraNumber, paraPortIndex, paraPortType, paraPortInSigNumber, paraPortOutSigNumber, paraInSigPortIndex, paraInSigName, paraInSigState, paraInSigChanges, paraOutSigPortIndex, paraOutSigName, paraOutSigState, paraOutSigChanges } STATUS current DESCRIPTION "A collection of objects providing information applicable to all Parallel-printer-like interfaces." ::= { paraGroups 1 } END Expires 7 September 1994 [Page 14] draft Parallel-printer-like MIB 7 March 1994 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. Expires 7 September 1994 [Page 15] draft Parallel-printer-like MIB 7 March 1994 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F.J. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for Character Stream Devices", RFC ????, Xyplex, Inc., ?Mon?, 1994. [7] Stewart, B., "Definitions of Managed Objects for RS-232-like Devices", RFC ????, Xyplex, Inc., Expires 7 September 1994 [Page 16] draft Parallel-printer-like MIB 7 March 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com Phone: 508-952-4816 Email: rlstewart@eng.xyplex.com Expires 7 September 1994 [Page 17] draft Parallel-printer-like MIB 7 March 1994 Table of Contents 1 Introduction .................................................... 2 2 The SNMPv2 Network Management Framework ......................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 3.1 Relationship to Interface MIB ................................. 4 4 Definitions ..................................................... 6 5 Acknowledgements ................................................ 15 6 References ...................................................... 16 7 Security Considerations ......................................... 17 8 Author's Address ................................................ 17 Expires 7 September 1994 [Page 18]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04582; 19 Mar 94 21:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04578; 19 Mar 94 21:38 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14916; 19 Mar 94 21:38 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16071; Sat, 19 Mar 94 18:18:20 -0800 Received: by nsl.pa.dec.com; id AA21258; Sat, 19 Mar 94 17:51:02 -0800 Received: by nsl.pa.dec.com; id AA21254; Sat, 19 Mar 94 17:51:01 -0800 Received: from xap.xyplex.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA29250; Sat, 19 Mar 94 17:45:46 -0800 Received: by xap.xyplex.com id ; Sat, 19 Mar 94 20:46:32 -0500 Date: Sat, 19 Mar 94 20:46:32 -0500 Message-Id: <9403200146.AA00823@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: internet-drafts@CNRI.Reston.VA.US Cc: char-mib@pa.dec.com Subject: New Character MIB Draft draft Character MIB 18 March 1994 Character MIB 18 March 1994 Bob Stewart Xyplex, Inc. rlstewart@eng.xyplex.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Expires 18 September 1994 [Page 1] draft Character MIB 18 March 1994 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. Expires 18 September 1994 [Page 2] draft Character MIB 18 March 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires 18 September 1994 [Page 3] draft Character MIB 18 March 1994 3. Overview The Character MIB applies to ports that carry a character stream, whether physical or virtual, serial or parallel, synchronous or asynchronous. The most common example of a character stream device is a hardware terminal port with an RS-232 interface. Another common hardware example is a parallel printer port, say with a Centronics interface. The concept also includes virtual terminal ports, such as a software connection point for a remote console. The Character MIB is mandatory for all systems that offer character stream ports. This includes, for example, terminal servers, general- purpose time-sharing hosts, and even such systems as a bridge with a (virtual) console port. It may or may not include character ports that do not support network sessions, depending on the system's needs. The Character MIB's central abstraction is a port. Physical ports have a one-to-one correspondence with hardware ports. Virtual ports are software entities analogous to physical ports, but with no hardware connector. Each port supports one or more sessions. A session represents a virtual connection that carries characters between the port and some partner. Sessions typically operate over a stack of network protocols. A typical session, for example, uses Telnet over TCP. The MIB comprises one base object and two tables, detailed in the following sections. The tables contain objects for ports and sessions. The MIB intentionally contains no distinction between what is often called permanent and operational or volatile data bases. For the purposes of this MIB, handling of such distinctions is implementation specific. 3.1. Relationship to Interface MIB The Character MIB does not relate directly to the Interface MIB [1], since it is not intrinsically a network interface. On the other hand, in most implementations where it is present, it will be above a physical sublayer interface, such as the RS-232-like [2] or Parallel-printer-like [3] MIBs. Expires 18 September 1994 [Page 4] draft Character MIB 18 March 1994 4. Definitions CHARACTER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI AutonomousType, InstancePointer FROM SNMPv2-TC InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; char MODULE-IDENTITY LAST-UPDATED "9403181700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for character stream devices." ::= { mib-2 19 } PortIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each character port in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub- layer must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization. Expires 18 September 1994 [Page 5] draft Character MIB 18 March 1994 In a system where the character ports are attached to hardware with an ifIndex, it is conventional, but not required, to make the character port index equal to the corresponding ifIndex." SYNTAX Integer32 Expires 18 September 1994 [Page 6] draft Character MIB 18 March 1994 -- Generic Character information charNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in charPortTable, regardless of their current state." ::= { char 1 } -- the Character Port table charPortTable OBJECT-TYPE SYNTAX SEQUENCE OF CharPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of charNumber." ::= { char 2 } charPortEntry OBJECT-TYPE SYNTAX CharPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a character port." INDEX { charPortIndex } ::= { charPortTable 1 } CharPortEntry ::= SEQUENCE { charPortIndex PortIndex, charPortName DisplayString, charPortType INTEGER, charPortHardware AutonomousType, charPortReset INTEGER, charPortAdminStatus Expires 18 September 1994 [Page 7] draft Character MIB 18 March 1994 INTEGER, charPortOperStatus INTEGER, charPortLastChange TimeTicks, charPortInFlowType INTEGER, charPortOutFlowType INTEGER, charPortInFlowState INTEGER, charPortOutFlowState INTEGER, charPortInCharacters Counter32, charPortOutCharacters Counter32, charPortAdminOrigin INTEGER, charPortSessionMaximum INTEGER, charPortSessionNumber Gauge32, charPortSessionIndex INTEGER, charPortInFlowTypes OCTET STRING, charPortOutFlowTypes OCTET STRING, charPortLowerIfIndex InterfaceIndex } charPortIndex OBJECT-TYPE SYNTAX PortIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each character port, corresponding to the same value of ifIndex." ::= { charPortEntry 1 } charPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) MAX-ACCESS read-write Expires 18 September 1994 [Page 8] draft Character MIB 18 March 1994 STATUS current DESCRIPTION "An administratively assigned name for the port, typically with some local significance." ::= { charPortEntry 2 } charPortType OBJECT-TYPE SYNTAX INTEGER { physical(1), virtual(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's type, 'physical' if the port represents an external hardware connector, 'virtual' if it does not." ::= { charPortEntry 3 } charPortHardware OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to hardware MIB definitions specific to a physical port's external connector. For example, if the connector is RS-232, then the value of this object refers to a MIB sub-tree defining objects specific to RS-232. If an agent is not configured to have such values, the agent returns the object identifier: nullHardware OBJECT IDENTIFIER ::= { 0 0 } " ::= { charPortEntry 4 } charPortReset OBJECT-TYPE SYNTAX INTEGER { ready(1), execute(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control to force the port into a clean, initial state, both hardware and software, disconnecting all the port's existing sessions. In response to a get-request or get-next-request, the agent always returns 'ready' as the value. Setting the value to 'execute' causes a reset." ::= { charPortEntry 5 } Expires 18 September 1994 [Page 9] draft Character MIB 18 March 1994 charPortAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), off(3), maintenance(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's desired state, independent of flow control. 'enabled' indicates that the port is allowed to pass characters and form new sessions. 'disabled' indicates that the port is allowed to pass characters but not form new sessions. 'off' indicates that the port is not allowed to pass characters or have any sessions. 'maintenance' indicates a maintenance mode, exclusive of normal operation, such as running a test. 'enabled' corresponds to ifAdminStatus 'up'. 'disabled' and 'off' correspond to ifAdminStatus 'down'. 'maintenance' corresponds to ifAdminStatus 'test'." ::= { charPortEntry 6 } charPortOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), maintenance(3), absent(4), active(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's actual, operational state, independent of flow control. 'up' indicates able to function normally. 'down' indicates inability to function for administrative or operational reasons. 'maintenance' indicates a maintenance mode, exclusive of normal operation, such as running a test. 'absent' indicates that port hardware is not present. 'active' indicates up with a user present (e.g. logged in). 'up' and 'active' correspond to ifOperStatus 'up'. 'down' and 'absent' correspond to ifOperStatus 'down'. 'maintenance' corresponds to ifOperStatus 'test'." ::= { charPortEntry 7 } charPortLastChange OBJECT-TYPE Expires 18 September 1994 [Page 10] draft Character MIB 18 March 1994 SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the port entered its current operational state. If the current state was entered prior to the last reinitialization of the local network management subsystem, then this object contains a zero value." ::= { charPortEntry 8 } -- charPortInFlowType is deprecated in favor of -- charPortInFlowTypes charPortInFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), xonXoff(2), hardware(3), ctsRts(4), dsrDtr(5) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The port's type of input flow control. 'none' indicates no flow control at this level or below. 'xonXoff' indicates software flow control by recognizing XON and XOFF characters. 'hardware' indicates flow control delegated to the lower level, for example a parallel port. 'ctsRts' and 'dsrDtr' are specific to RS-232-like ports. Although not architecturally pure, they are included here for simplicity's sake." ::= { charPortEntry 9 } -- charPortOutFlowType is deprecated in favor of -- charPortOutFlowTypes charPortOutFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), xonXoff(2), hardware(3), ctsRts(4), dsrDtr(5) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The port's type of output flow control. 'none' indicates no flow control at this level or below. 'xonXoff' indicates software flow control by recognizing XON and XOFF characters. 'hardware' Expires 18 September 1994 [Page 11] draft Character MIB 18 March 1994 indicates flow control delegated to the lower level, for example a parallel port. 'ctsRts' and 'dsrDtr' are specific to RS-232-like ports. Although not architecturally pure, they are included here for simplicy's sake." ::= { charPortEntry 10 } charPortInFlowState OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), stop(3), go(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of input flow control on the port. 'none' indicates not applicable. 'unknown' indicates this level does not know. 'stop' indicates flow not allowed. 'go' indicates flow allowed." ::= { charPortEntry 11 } charPortOutFlowState OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), stop(3), go(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of output flow control on the port. 'none' indicates not applicable. 'unknown' indicates this level does not know. 'stop' indicates flow not allowed. 'go' indicates flow allowed." ::= { charPortEntry 12 } charPortInCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters detected as input from the port since system re-initialization and while the port operational state was 'up', 'active', or 'maintenance', including, for example, framing, flow control (i.e. XON and XOFF), each occurrence of a BREAK condition, locally-processed input, and input sent to all sessions." ::= { charPortEntry 13 } Expires 18 September 1994 [Page 12] draft Character MIB 18 March 1994 charPortOutCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters detected as output to the port since system re-initialization and while the port operational state was 'up', 'active', or 'maintenance', including, for example, framing, flow control (i.e. XON and XOFF), each occurrence of a BREAK condition, locally-created output, and output received from all sessions." ::= { charPortEntry 14 } charPortAdminOrigin OBJECT-TYPE SYNTAX INTEGER { dynamic(1), network(2), local(3), none(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively allowed origin for establishing session on the port. 'dynamic' allows 'network' or 'local' session establishment. 'none' disallows session establishment." ::= { charPortEntry 15 } charPortSessionMaximum OBJECT-TYPE SYNTAX INTEGER (-1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent sessions allowed on the port. A value of -1 indicates no maximum. Setting the maximum to less than the current number of sessions has unspecified results." ::= { charPortEntry 16 } charPortSessionNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of open sessions on the port that are in the connecting, connected, or disconnecting state." ::= { charPortEntry 17 } Expires 18 September 1994 [Page 13] draft Character MIB 18 March 1994 charPortSessionIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of charSessIndex for the port's first or only active session. If the port has no active session, the agent returns the value zero." ::= { charPortEntry 18 } charPortInFlowTypes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's types of input flow control at the software level. Hardware-level flow control is independently controlled by the appropriate hardware-level MIB. A value of zero indicates no flow control. Depending on the specific implementation, any or all combinations of flow control may be chosen by adding the values: 128 xonXoff, recognizing XON and XOFF characters 64 enqHost, ENQ/ACK to allow input to host 32 enqTerm, ACK to allow output to port " ::= { charPortEntry 19 } charPortOutFlowTypes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's types of output flow control at the software level. Hardware-level flow control is independently controlled by the appropriate hardware-level MIB. A value of zero indicates no flow control. Depending on the specific implementation, any or all combinations of flow control may be chosen by adding the values: Expires 18 September 1994 [Page 14] draft Character MIB 18 March 1994 128 xonXoff, recognizing XON and XOFF characters 64 enqHost, ENQ/ACK to allow input to host 32 enqTerm, ACK to allow output to port " ::= { charPortEntry 20 } charPortLowerIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the lower level hardware supporting this character port, zero if none." ::= { charPortEntry 21 } -- the Character Session table charSessTable OBJECT-TYPE SYNTAX SEQUENCE OF CharSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port session entries." ::= { char 3 } charSessEntry OBJECT-TYPE SYNTAX CharSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a character port session." INDEX { charSessPortIndex, charSessIndex } ::= { charSessTable 1 } CharSessEntry ::= SEQUENCE { charSessPortIndex PortIndex, charSessIndex INTEGER, charSessKill INTEGER, charSessState Expires 18 September 1994 [Page 15] draft Character MIB 18 March 1994 INTEGER, charSessProtocol AutonomousType, charSessOperOrigin INTEGER, charSessInCharacters Counter32, charSessOutCharacters Counter32, charSessConnectionId InstancePointer, charSessStartTime TimeTicks } charSessPortIndex OBJECT-TYPE SYNTAX PortIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of charPortIndex for the port to which this session belongs." ::= { charSessEntry 1 } charSessIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The session index in the context of the port, a non-zero positive integer. Session indexes within a port need not be sequential. Session indexes may be reused for different ports. For example, port 1 and port 3 may both have a session 2 at the same time. Session indexes may have any valid integer value, with any meaning convenient to the agent implementation." ::= { charSessEntry 2 } charSessKill OBJECT-TYPE SYNTAX INTEGER { ready(1), execute(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control to terminate the session. In response to Expires 18 September 1994 [Page 16] draft Character MIB 18 March 1994 a get-request or get-next-request, the agent always returns 'ready' as the value. Setting the value to 'execute' causes termination." ::= { charSessEntry 3 } charSessState OBJECT-TYPE SYNTAX INTEGER { connecting(1), connected(2), disconnecting(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the session, disregarding flow control. 'connected' indicates that character data could flow on the network side of session. 'connecting' indicates moving from nonexistent toward 'connected'. 'disconnecting' indicates moving from 'connected' or 'connecting' to nonexistent." ::= { charSessEntry 4 } charSessProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The network protocol over which the session is running. Other OBJECT IDENTIFIER values may be defined elsewhere, in association with specific protocols. However, this document assigns those of known interest as of this writing." ::= { charSessEntry 5 } wellKnownProtocols OBJECT IDENTIFIER ::= { char 4 } protocolOther OBJECT IDENTIFIER ::= { wellKnownProtocols 1 } protocolTelnet OBJECT IDENTIFIER ::= { wellKnownProtocols 2 } protocolRlogin OBJECT IDENTIFIER ::= { wellKnownProtocols 3 } protocolLat OBJECT IDENTIFIER ::= { wellKnownProtocols 4 } protocolX29 OBJECT IDENTIFIER ::= { wellKnownProtocols 5 } protocolVtp OBJECT IDENTIFIER ::= { wellKnownProtocols 6 } charSessOperOrigin OBJECT-TYPE SYNTAX INTEGER { unknown(1), network(2), local(3) } MAX-ACCESS read-only Expires 18 September 1994 [Page 17] draft Character MIB 18 March 1994 STATUS current DESCRIPTION "The session's source of establishment." ::= { charSessEntry 6 } charSessInCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This session's subset of charPortInCharacters." ::= { charSessEntry 7 } charSessOutCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This session's subset of charPortOutCharacters." ::= { charSessEntry 8 } charSessConnectionId OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to additional local MIB information. This should be the highest available related MIB, corresponding to charSessProtocol, such as Telnet. For example, the value for a TCP connection (in the absence of a Telnet MIB) is the object identifier of tcpConnState. If an agent is not configured to have such values, the agent returns the object identifier: nullConnectionId OBJECT IDENTIFIER ::= { 0 0 } " ::= { charSessEntry 9 } charSessStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime in MIB-2 when the session Expires 18 September 1994 [Page 18] draft Character MIB 18 March 1994 entered connecting state." ::= { charSessEntry 10 } Expires 18 September 1994 [Page 19] draft Character MIB 18 March 1994 -- conformance information charConformance OBJECT IDENTIFIER ::= { char 5 } charGroups OBJECT IDENTIFIER ::= { charConformance 1 } charCompliances OBJECT IDENTIFIER ::= { charConformance 2 } -- compliance statements charCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have Character hardware interfaces." MODULE -- this module MANDATORY-GROUPS { charGroup } ::= { charCompliances 1 } Expires 18 September 1994 [Page 20] draft Character MIB 18 March 1994 -- units of conformance charGroup OBJECT-GROUP OBJECTS { charNumber, charPortIndex, charPortName, charPortType, charPortHardware, charPortReset, charPortAdminStatus, charPortOperStatus, charPortLastChange, charPortInFlowState, charPortOutFlowState, charPortAdminOrigin, charPortSessionMaximum, charPortInFlowTypes, charPortOutFlowTypes, charPortInCharacters, charPortOutCharacters, charPortSessionNumber, charPortSessionIndex, charPortLowerIfIndex, charSessPortIndex, charSessIndex, charSessKill, charSessState, charSessProtocol, charSessOperOrigin, charSessInCharacters, charSessOutCharacters, charSessConnectionId, charSessStartTime } STATUS current DESCRIPTION "A collection of objects providing information applicable to all Character interfaces." ::= { charGroups 1 } END Expires 18 September 1994 [Page 21] draft Character MIB 18 March 1994 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. Expires 18 September 1994 [Page 22] draft Character MIB 18 March 1994 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F.J. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for RS-232-like Hardware Devices", RFC ????, Xyplex, Inc., ?Mon?, 1994. [7] Stewart, B., "Definitions of Managed Objects for Parallel-printer- like Hardware Devices", RFC ????, Xyplex, Inc., ?Mon?, 1994. Expires 18 September 1994 [Page 23] draft Character MIB 18 March 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com Phone: 508-952-4816 Email: rlstewart@eng.xyplex.com Expires 18 September 1994 [Page 24] draft Character MIB 18 March 1994 Table of Contents 1 Introduction .................................................... 2 2 The SNMPv2 Network Management Framework ......................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 4 3.1 Relationship to Interface MIB ................................. 4 4 Definitions ..................................................... 5 5 Acknowledgements ................................................ 22 6 References ...................................................... 23 7 Security Considerations ......................................... 24 8 Author's Address ................................................ 24 Expires 18 September 1994 [Page 25]   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07406; 22 Mar 94 10:38 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05980; 22 Mar 94 10:37 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07336; 22 Mar 94 10:37 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06896; 22 Mar 94 10:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: char-mib@decwrl.dec.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-charmib-mib-01.txt Date: Tue, 22 Mar 94 10:31:42 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403221031.aa06896@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Character MIB Working Group of the IETF. Title : Character MIB Author(s) : B. Stewart Filename : draft-ietf-charmib-mib-01.txt Pages : 25 Date : 03/21/1994 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-charmib-mib-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-charmib-mib-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940321091323.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-charmib-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-charmib-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940321091323.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07411; 22 Mar 94 10:38 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05982; 22 Mar 94 10:37 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07347; 22 Mar 94 10:37 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id ab06929; 22 Mar 94 10:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: char-mib@decwrl.dec.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-charmib-ppl-mib-01.txt Date: Tue, 22 Mar 94 10:31:52 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403221031.ab06929@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Character MIB Working Group of the IETF. Title : Parallel-printer-like MIB Author(s) : B. Stewart Filename : draft-ietf-charmib-ppl-mib-01.txt Pages : 18 Date : 03/21/1994 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer-like devices. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-charmib-ppl-mib-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-charmib-ppl-mib-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940321092405.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-charmib-ppl-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-charmib-ppl-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940321092405.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07946; 22 Mar 94 10:48 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06435; 22 Mar 94 10:48 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07921; 22 Mar 94 10:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06918; 22 Mar 94 10:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: char-mib@decwrl.dec.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-charmib-rs232-mib-02.txt Date: Tue, 22 Mar 94 10:31:48 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403221031.aa06918@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Character MIB Working Group of the IETF. Title : RS-232-like MIB Author(s) : B. Stewart Filename : draft-ietf-charmib-rs232-mib-02.txt Pages : 30 Date : 03/21/1994 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-charmib-rs232-mib-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-charmib-rs232-mib-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940321091933.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-charmib-rs232-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-charmib-rs232-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940321091933.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03937; 26 Mar 94 17:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03933; 26 Mar 94 17:33 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa12501; 26 Mar 94 17:33 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA14150; Sat, 26 Mar 94 14:16:07 -0800 Received: by nsl.pa.dec.com; id AA02240; Sat, 26 Mar 94 12:50:49 -0800 Received: by nsl.pa.dec.com; id AA02236; Sat, 26 Mar 94 12:50:48 -0800 Received: from nbkanata.Newbridge.COM by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA23611; Sat, 26 Mar 94 12:47:23 -0800 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA10032; Sat, 26 Mar 94 15:43:31 EST Received: from fields.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA02324; Sat, 26 Mar 94 15:43:28 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <9403262043.AA02324@Newbridge.COM> Subject: Re: I-D ACTION:draft-ietf-charmib-rs232-mib-02.txt To: char-mib@pa.dec.com Date: Sat, 26 Mar 1994 15:50:01 -0500 (EST) In-Reply-To: <9403221031.aa06918@IETF.CNRI.Reston.VA.US> from "Internet-Drafts@CNRI.Reston.VA.US" at Mar 22, 94 10:31:48 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 427 Hi: Would it be possible to used "Extended" (or some other such word) for the compliance groups including the new objects ? These objects are useful for applications other than SDLC ... -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17151; 27 Mar 94 18:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17147; 27 Mar 94 18:11 EST Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa02068; 27 Mar 94 18:11 EST Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA20135; Sun, 27 Mar 94 14:19:40 -0800 Received: by nsl.pa.dec.com; id AA13122; Sun, 27 Mar 94 13:20:20 -0800 Received: by nsl.pa.dec.com; id AA13118; Sun, 27 Mar 94 13:20:19 -0800 Received: by pobox1.pa.dec.com; id AA21875; Sun, 27 Mar 94 13:20:08 -0800 Received: from [134.177.1.95] by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20003; Sun, 27 Mar 94 13:17:34 -0800 Received: from immer (immer.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA02101; Sun, 27 Mar 94 13:16:05 PST Received: by immer (4.1/2.0N) id AA11505; Sun, 27 Mar 94 13:13:42 PST Message-Id: <9403272113.AA11505@immer> Date: Sun, 27 Mar 94 13:13:42 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Perkins To: james@newbridge.com, char-mib@pa.dec.com Subject: Re: I-D ACTION:draft-ietf-charmib-rs232-mib-02.txt James, Once an OBJECT-GROUP or MODULE-COMPLIANCE is defined, it MAY NOT BE CHANGED semanticly. This means that objects may not be added or removed, or the syntax, access, or other clauses modified. If you want a change, then another OBJECT-GROUP or MODULE-COMPLIANCE (or agent-capabilities, or object-type, or notification-type) needs to be defined. It must have a difference OID value and use a different object-descriptor value. /dave perkins, synoptics, 408-764-1516