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
- RFC1317 Sync Table Dean D. Throop
- Re: RFC1317 Sync Table Bob Stewart
- Re: RFC1317 Sync Table Dean D. Throop
- Re: RFC1317 Sync Table Bob Stewart