Subject: ds0/ds1/ds3 mapping of ifTable

From: Jason Perreault <[email-masked]>
Date: Tue, 31 Mar 1998 10:56:56 -0500

Just looking for some clarifications....

1. Mapping of ifOperStatus

None of the ds0/ds1/ds3 MIB drafts explicitly
describe the conditions under which those 
interfaces take on the various ifOperStatus 
values.

The ds1/ds3 draft text that describes performance
parameters *does* say that linkUp and linkDown
traps are generated according to the interface's
UAS available/unavailable state, respectively. 

Is it correct to assume, for ds1/ds3, that entering/leaving 
unavailable state aligns with ifOperStatus entering/leaving the
'down' state?

(In contrast, RFC1595 SONET MIB associates ifOperStatus
'down' with the occurrence of a defect, whether or not
it persists long enough to cause Unavailable to be declared.
In fact, it appears from the SONET MIB description that sufficient
CVs over a 10-second interval could cause Unavailable to 
be declared, absent any defects, in which case the interface 
would be unavailable but ifOperStatus would be 'up'????).

2. Mapping of ifLinkUpDownTrapEnable for ds0/ds0Bundle

The text describing ifLinkUpDownTrapEnable for ds0/ds0Bundle
interfaces says "Set to disabled(2). Supports read-only access."

Re "read-only access", is this intended to be a MUST, a SHOULD,
or a MAY? 

Is this meant to suggest that ifOperStatus for ds0/ds0Bundle
interfaces are 'slaved' to the underlying ds1 interface, so they
are either 'up' or 'lowerLayerDown', but never 'down'; thus they
generate no linkUp/linkDown traps?

Thanks for any help.

Jason Perreault
Redstone Communications Inc.
[email-masked]