Subject: RE: [Bridge-mib] 802.1 managed variable persistence

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 20 Jul 2005 00:25:43 +0300

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

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

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

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 20 Jul 2005 00:04:00 +0300

Regards,

Dan

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 20 Jul 2005 17:20:18 -0400

FYI.
These are my recommendations to the editor.
Bert has subsequently requested a clarifying description that new
implemntations MUST retain the values, and existing implementations
SHOULD be changed if necessary to retain these values.

David Harrington
[email-masked]
co-chair, IETF Bridge WG

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Tuesday, July 19, 2005 9:57 PM
> To: 'David Levi'
> Cc: 'Romascanu, Dan (Dan)'; [email-masked]; 'Congdon, 
> Paul T (ProCurve)'; [email-masked]
> Subject: FW: [Bridge-mib] 802.1 managed variable persistence
> 
> Hi Dave,
> 
> Can you add a sentence to the description of each of these objects
> (except dot1dStpPortProtocolMigration) describing persistence
> requirements.
> 
> For all objects that were already defined in RFC2674, it would
> probably be wrong to make conformant implementations non-conformant
by
> adding a new requirement, so I suggest the text: "The value of this
> object SHOULD be retained across reinitializations of the management
> system."
> 
> For all the new read-write objects listed, I suggest  "The value of
> this object MUST be retained across reinitializations of the
> management system." 
> 
> Then can you submit the documents for publication? Please include in
> the submission the fact that the documents are in AD Evaluation;
that
> might get them published faster. Because of meeting cutoffs, I
believe
> the docs won't be published until after Paris, and Bert and the IESG
> probably wouldn't have time to deal with them before then anyway.
> 
> Thanks,
> dbh
> 
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> > Sent: Tuesday, July 19, 2005 5:04 PM
> > 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
> > 
> > 1. All objects in this list were reviewed. The IEEE 802.1 WG
advice
> is