RE: 802.1 managed variable persistence

Tony, Paul,

Would it be possible to include clarification of the managed variables
persistence on the agenda of the San Francisco meeting?  Maybe establish
an ad-hoc to work on this during the meeting, and feed back the
information to the IETF Bridge MIB WG?=20

Thanks and Regards,=20

Dan
=20

> -----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