Comments on draft-ietf-charmib-rs232-mib-00.txt

[[e-mail]]

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.
[e-mail]
415/688-4627

P.S. Numbers (8) and (9) below should be nuked per the discussion on
     [e-mail] 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 <[e-mail]>); 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 <[e-mail]>); 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 <[e-mail]>); 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 [e-mail]); Wed, 22 Dec 1993 21:52:23 -0800
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Extensions to RFC1317 for SDLC Devices
Date: Wed, 22 Dec 93 21:52:22 PST
From: [e-mail]


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.
[e-mail]
415/688-4627
------- Message 2

Return-Path: [e-mail]
Received: from hubbub.cisco.com by regal.cisco.com with SMTP id AA29473
  (5.67a/IDA-1.5 for <[e-mail]>); 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 <[e-mail]>); 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 <[e-mail]>); Tue, 11 Jan 1994 10:03:16 -0600
Received: by xap.xyplex.com id <[e-mail]>; Tue, 11 Jan 94 11:02:19 -0500
Date: Tue, 11 Jan 94 11:02:19 -0500
Message-Id: <[e-mail]>
From: Bob Stewart <[e-mail]>
To: [e-mail]
Cc: [e-mail]
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