Re: RFC1317 Sync Table

Bob Stewart <rlstewart@eng.xyplex.com> Thu, 20 August 1992 14:38 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02345; 20 Aug 92 10:38 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02341; 20 Aug 92 10:38 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa08180; 20 Aug 92 10:40 EDT
Received: by inet-gw-2.pa.dec.com; id AA19604; Thu, 20 Aug 92 07:36:26 -0700
Received: by nsl.pa.dec.com; id AA18622; Thu, 20 Aug 92 07:35:59 -0700
Received: by inet-gw-2.pa.dec.com; id AA19554; Thu, 20 Aug 92 07:35:51 -0700
Received: by xap.xyplex.com id <AA20504@xap.xyplex.com>; Thu, 20 Aug 92 12:33:33 -0500
Date: Thu, 20 Aug 92 12:33:33 -0500
Message-Id: <9208201733.AA20504@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: throop@dg-rtp.dg.com
Cc: char-mib@pa.dec.com
In-Reply-To: Dean D. Throop's message of Wed, 19 Aug 1992 16:48:48 -0400 <9208192048.AA04007@walrus>
Subject: Re: RFC1317 Sync Table

Hi, Dean.  I think it was that X.25/LAPB guy that suggested we needed the sync
table.  He shoulda thought a little deeper.  :-)}

You're onto an interesting general problem.  As the hardware gets more
helpful, it makes things more opaque.  Information you REALLY need for
management can end up hidden unless hardware manufacturers specifically plan
for it.  Given that you're finding it impossible to implement, I find myself
wondering if what we put in the MIB for interrupted frames is truly useful.
So frames were interrupted by modem signals or aborted by the other end?  So
what?  What problem does that indicate that you couldn't find another way, and
what do you do about it?  Perhaps for Draft Standard status we should
deprecate rs232SyncPortInterruptedFrames and maybe rs232SyncPortAbortedFrames.
We definitely need expert/implementation advice.  

As for the modem change counters, that's a bit easier.  I checked the RFC and
although there is a missing statement of intent, it DOES say, for
rs232PortInSigNumber and rs232PortOutSigNumber, that it covers only signals
the software can detect or assert.  The missing intent was this is only to
include signals it is useful to monitor so closely.  Hmmmm.  As I think about
it, we didn't include a judgement as you can argue it's useful to know that
CTS/RTS flow control is switching a lot, or is stuck in a particular state,
even though the feature was aimed more toward the signals that usually change
slower and get screwed up more often.  Actually, flow-control operation is
handled elsewhere, so perhaps we could be clearer about CTS/RTS.

As far as the missing counters, hmmmmm again.  If we thought of it at all, we
probably expected such things to be part of a higher level MIB.  The
synchronous section was added right at the end, and we were thinking
characters rather than frames.  At least some of what you suggest should
probably be considered.  I do recall that we avoided interpretation of
hardware signals and related algorithms as it varied to much among
implementations.

	Bob