RE: Draft-ietf-bridge-bridgemib-smiv2 Issues Resolution

Hi,

1) I agree with your analysis on the Priority objects.
2) I think the topologychange object has been changed in a way that
could break existing (non-RSTP-knowledgeable) applications that are
run against an RSTP-supporting agent, 
3) the range has been constrained in the revision. This is probably
not a problem, but it is a semantic change.

I think these changes are technically illegal, but if the WG accepts
them, I can live with that.
If nobody objects, I will close this issue, and submit the document
with these changes.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, January 06, 2005 5:40 PM
> To: David B Harrington
> Cc: [email protected]
> Subject: Re: [Bridge-mib] Draft-ietf-bridge-bridgemib-smiv2 
> Issues Resolution
> 
> On Wed, Jan 05, 2005 at 01:22:58PM -0500, David B Harrington wrote:
> 
> > UNRESOLVED ISSUES:
> > 
> > #543: smiv2-06: semantic changes; the following objects changed
> > semantics of an existing object: dot1dPortPriority,
> > dot1dStpTimeSinceTopologyChange, and dot1dStaticAllowedToGoTo.
These
> > objects were modified to support 802.1t semantics. Since 802.1t
> > implementations have been fielded before this mib becomes
available,
> > the behavior of current agent implementations might be
non-compliant
> > with the updated definitions. Even an implementation that claims
> > compliance to bridgeCompliance1493 will be impacted because the
> > semantics of objects from RFC 1493 have been changed. 
> 
> dot1dStpPriority:
> dot1dStpPortPriority:
> 
> I think the change is really a clarification that only a subset of
> the original value range is allowed for bridges that comply to IEEE
> 802.1t or IEEE 802.1w so I do not see a real problem here for
_agent_
> implementations. Bridges supporting IEEE 802.1t or IEEE 802.1w
likely
> reject values which are outside the set of legal values and I would
> guess that this is exactly what is currently implemented and
deployed.
> Can someone confirm my guess?
> 
> dot1dStpTimeSinceTopologyChange:
> 
> Can't really judge the difference since I do not know enough about
> RSTP and tcWhile timers. Can someone explain what the impact of this
> change might be?
> 
> dot1dStaticAllowedToGoTo:
> 
> I am not sure what the issue here is. Did this semantically chance
> at all?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>