Re: RFC1317 Sync Table

["Dean D. Throop" <[e-mail]>]

> From: Bob Stewart <[e-mail]>
> To: [e-mail]
> 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.  :-)}

:-) Actually as I recall the rs232SyncPortInterruptedFrames object
came from someone else consulted by the rs-232 MIB chair but it
didn't seem worth digging through the archive to be sure.
 
> 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.  

I believe deprecating rs232SyncPortInterruptedFrames would be a good idea.
As for AbortedFrames, that is easy to implement (all chips report it), and
can occasioually provide insight into improperly configured lines.  
Since it is there, I say keep it.
 
> 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.

There are many different signals defined so I doubt anyone will use all
of them.  We might want to clarify the intent of the MIB when going
to draft standard.  Maybe strongly recommend DTR and DSR while saying
others should be available as appropriate for the implementation.
 
> 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.

Even if we don't add them to the current MIB it would be a good idea 
to start a list of things people find useful.  These object could
be put into private MIBs for now adn used as input for when the 
MIB is redone sometime in the future.

Dean Throop		[e-mail]