RE: 802.1 managed variable persistence

The IEEE 802.1 WG discussed this issue at the IEEE 802 Plenary meeting,
on 7/18.=20

1. All objects in this list were reviewed. The IEEE 802.1 WG advice is
that all the objects in the list submitted by Dave need to be persistent
across reboots, with the exception of the dot1dStpPortProtocolMigration
object, which has a timely behavior, the manager command being valid
only for a limited number of seconds after being applied.=20
2. The IEEE 802.1 WG advices that persistence be clarified in the text
of the Bridge MIB WG documents currently under review
3. In the future, as the MIB development work will be taken over by the
IEEE 802.1 WG, clarifications of read-write variables persistence will
become part of the IEEE 802.1 standards.=20

Regards,

Dan



> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of David B Harrington
> Sent: Thursday, June 16, 2005 6:33 PM
> To: 'Bridge-Mib (E-mail)'
> Cc: 'Congdon, Paul T (ProCurve)'; 'Wijnen,Bert (Bert)';=20
> [email protected]
> Subject: [Bridge-mib] 802.1 managed variable persistence
>=20
> Hi,
>=20
> The early consensus appears to be that we need to clarify the=20
> persistence of some read-write objects [IEEE managed objects]=20
> in the RSTP-MIB, P-BRIDGE-MIB, and Q-BRIDGE-MIB before we=20
> standardize the MIB modules and make them harder to change later.=20
>=20
> The RSTP-MIB read-write objects [management variables] in question
> are: dot1dStpVersion [ForceVersion], dot1dStpTxHoldCount=20
> [TxHoldCount], dot1dStpPortProtocolMigration [mcheck],=20
> dot1dStpPortAdminEdgePort [adminEdgePort],=20
> dot1dStpPortAdminPointToPoint [adminPointToPointMAC], and=20
> dot1dStpPortAdminPathCost [Path Cost].=20
>=20
> It is unclear to me whether we can change the persistence=20
> requirement for the read-write objects originally defined in RFC2674.=20
>=20
> The P-BRIDGE-MIB and Q-BRIDGE-MIB read-write objects from RFC2674 are:
> dot1dTrafficClassesEnabled [none], dot1dGmrpStatus=20
> [ApplicantAdministrativeControl],=20
> dot1dPortDefaultUserPriority [UserPriority],=20
> dot1dPortNumTrafficClasses [none], dot1dRegenUserPriority=20
> [none], dot1dTrafficClass [none], dot1dPortGarpJoinTime=20
> [JoinTime], dot1dPortGarpLeaveTime [LeaveTime],=20
> dot1dPortGarpLeaveAllTime [LeaveAllTime], dot1dPortGmrpStatus=20
> [ApplicantAdministrativeControl],  dot1qGvrpStatus [802.1Q clause
> 12.9.2.1/2 ], dot1qStaticUnicastAllowedToGoTo [none],=20
> dot1qStaticUnicastStatus [none], dot1qStaticMulticastStaticEgressPorts
> [none], dot1qStaticMulticastForbiddenEgressPorts [none],=20
> dot1qStaticMulticastStatus [none], dot1qPvid [12.10.1.2], and=20
> dot1qPortAcceptableFrameTypes [12.10.1.3].
>=20
> The new P-BRIDGE-MIB and Q-BRIDGE-MIB objects are:
> dot1dPortRestrictedGroupRegistration [IEEE 802.1t 10.3.2.3],=20
> dot1qPortRestrictedVlanRegistration [802.1u 11.2.3.2.3],
>=20
> Disclaimer: Some of these objects may have statements of=20
> persistence in, say, the containing table row, or are implied=20
> by the state machines of the 802.1 standards. Many of these=20
> objects appear to be persistent from a protocol-sense, but=20
> such persistence is not actually specified. We need=20
> clarification. Can somebody point out such table definitions=20
> or 802.1 text that states such persistence, and the=20
> corresponding objects?
>=20
> For objects where the 802.1 standard does not make such=20
> specification, we will need 802.1 clarification. Can somebody=20
> check to see which need this work done by 802.1?
>=20
> For objects that were first defined in RFC2674, we will=20
> probably need to limit any persistence requirement to a=20
> SHOULD, or MUST NOT assume.
>=20
> Volunteers to help track down answers?
> =20
> David Harrington
> [email protected]
> co-chair, IETF Bridge WG
> =20
>=20
>=20
>=20
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>=20