802.1 managed variable persistence

Hi,

The early consensus appears to be that we need to clarify the
persistence of some read-write objects [IEEE managed objects] in the
RSTP-MIB, P-BRIDGE-MIB, and Q-BRIDGE-MIB before we standardize the MIB
modules and make them harder to change later. 

The RSTP-MIB read-write objects [management variables] in question
are: dot1dStpVersion [ForceVersion], dot1dStpTxHoldCount
[TxHoldCount], dot1dStpPortProtocolMigration [mcheck],
dot1dStpPortAdminEdgePort [adminEdgePort],
dot1dStpPortAdminPointToPoint [adminPointToPointMAC], and
dot1dStpPortAdminPathCost [Path Cost]. 

It is unclear to me whether we can change the persistence requirement
for the read-write objects originally defined in RFC2674. 

The P-BRIDGE-MIB and Q-BRIDGE-MIB read-write objects from RFC2674 are:
dot1dTrafficClassesEnabled [none], dot1dGmrpStatus
[ApplicantAdministrativeControl], dot1dPortDefaultUserPriority
[UserPriority], dot1dPortNumTrafficClasses [none],
dot1dRegenUserPriority [none], dot1dTrafficClass [none],
dot1dPortGarpJoinTime [JoinTime], dot1dPortGarpLeaveTime [LeaveTime],
dot1dPortGarpLeaveAllTime [LeaveAllTime], dot1dPortGmrpStatus
[ApplicantAdministrativeControl],  dot1qGvrpStatus [802.1Q clause
12.9.2.1/2 ], dot1qStaticUnicastAllowedToGoTo [none],
dot1qStaticUnicastStatus [none], dot1qStaticMulticastStaticEgressPorts
[none], dot1qStaticMulticastForbiddenEgressPorts [none],
dot1qStaticMulticastStatus [none], dot1qPvid [12.10.1.2], and
dot1qPortAcceptableFrameTypes [12.10.1.3].

The new P-BRIDGE-MIB and Q-BRIDGE-MIB objects are:
dot1dPortRestrictedGroupRegistration [IEEE 802.1t 10.3.2.3],
dot1qPortRestrictedVlanRegistration [802.1u 11.2.3.2.3],

Disclaimer: Some of these objects may have statements of persistence
in, say, the containing table row, or are implied by the state
machines of the 802.1 standards. Many of these objects appear to be
persistent from a protocol-sense, but such persistence is not actually
specified. We need clarification. Can somebody point out such table
definitions or 802.1 text that states such persistence, and the
corresponding objects?

For objects where the 802.1 standard does not make such specification,
we will need 802.1 clarification. Can somebody check to see which need
this work done by 802.1?

For objects that were first defined in RFC2674, we will probably need
to limit any persistence requirement to a SHOULD, or MUST NOT assume.

Volunteers to help track down answers?
 
David Harrington
[email protected]
co-chair, IETF Bridge WG