RE: 802.1 managed variable persistence

This sounds like a reasonable request and the best way to get a
response.  Mick usually puts together the schedule. I've copied Mick.
If Mick and Tony agree, we should post this to the 802.1 mailing list to
get volunteers and/or input from the WG that can be synthesized.  I'll
be happy to post the question to the list.

Paul

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]]=20
Sent: Sunday, June 19, 2005 11:49 AM
To: [email protected]; Bridge-Mib (E-mail)
Cc: Congdon, Paul T (ProCurve); Wijnen,Bert (Bert); [email protected]
Subject: RE: [Bridge-mib] 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]
> [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] in the=20
> RSTP-MIB, P-BRIDGE-MIB, and Q-BRIDGE-MIB before we standardize the MIB

> modules and make them harder to change later.
>=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
> It is unclear to me whether we can change the persistence requirement=20
> for the read-write objects originally defined in RFC2674.
>=20
> The P-BRIDGE-MIB and Q-BRIDGE-MIB read-write objects from RFC2674 are:
> dot1dTrafficClassesEnabled [none], dot1dGmrpStatus=20
> [ApplicantAdministrativeControl], dot1dPortDefaultUserPriority=20
> [UserPriority], dot1dPortNumTrafficClasses [none],=20
> dot1dRegenUserPriority [none], dot1dTrafficClass [none],=20
> dot1dPortGarpJoinTime [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 persistence=20
> in, say, the containing table row, or are implied by the state=20
> machines of the 802.1 standards. Many of these objects appear to be=20
> persistent from a protocol-sense, but such persistence is not actually

> specified. We need clarification. Can somebody point out such table=20
> definitions 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 specification,

> we will need 802.1 clarification. Can somebody check to see which need

> this work done by 802.1?
>=20
> For objects that were first defined in RFC2674, we will probably need=20
> to limit any persistence requirement to a 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