Subject: [Bridge-mib] 802.1 managed variable persistence

From: "David B Harrington" <[email-masked]>
Date: Thu, 16 Jun 2005 11:32:49 -0400

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-masked]
co-chair, IETF Bridge WG

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 19 Jun 2005 21:48:44 +0300

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? 

Thanks and Regards, 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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)'; 
> [email-masked]
> Subject: [Bridge-mib] 802.1 managed variable persistence
> 
> Hi,
> 
> 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. 
> 
> It is unclear to me whether we can change the persistence 
> requirement for the read-write objects originally defined in RFC2674. 
> 
> [ApplicantAdministrativeControl], 
> dot1dPortDefaultUserPriority [UserPriority], 
> dot1dPortNumTrafficClasses [none], dot1dRegenUserPriority 
> [none], dot1dTrafficClass [none], dot1dPortGarpJoinTime 
> [JoinTime], dot1dPortGarpLeaveTime [LeaveTime], 
> 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.
>

---

From: "Congdon, Paul T (ProCurve)" <[email-masked]>
Date: Thu, 23 Jun 2005 23:43:24 -0700

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-masked]] 
Sent: Sunday, June 19, 2005 11:49 AM
To: [email-masked]; Bridge-Mib (E-mail)
Cc: Congdon, Paul T (ProCurve); Wijnen,Bert (Bert); [email-masked]
Subject: RE: [Bridge-mib] 802.1 managed variable persistence

Tony, Paul,

Thanks and Regards, 

Dan