Re: problems with dot1dStpPortDesignatedPort

On Wed, Apr 03, 2002 at 09:35:11AM +0100, Les Bell wrote:
>> In draft-ietf-bridge-bridgemib-smiv2-02.txt,
>> the managed object:
>>
>>     dot1dStpPortDesignatedPort OBJECT-TYPE
>>      SYNTAX      OCTET STRING (SIZE (2))
>>      MAX-ACCESS  read-only
>>      STATUS      current
>>      DESCRIPTION
>>       "The Port Identifier of
>>        the port on the Designated
>>        Bridge for this port's segment."
>>      REFERENCE "IEEE 802.1D-1990: Section 4.5.5.7"
>>     ::= { dot1dStpPortEntry 9 }
>
>The dot1dStpPortDesignatedPort object is defined as an opaque
>octet string and it does not understand the priority and port
>number fields embedded within it.  Therefore, it does not matter
>(to this MIB object) that the boundary between them has changed.

How did you reach that conclusion?
What I see is an object that is clearly a 'Port Identifier' 
which is well defined in the base 802.1D 1990 spec. 

If dot1dStpPortDesignatedPort is opaque, 
how can it be used at all in an interoperable
fashion?

>> So is is possible that some prose be added to
>> the front matter about what a conforming application
>> should expect from a device implementing the BRIDGE-MIB
>> when it device has > 255 ports?
>
>I did not think this was necessary.

I agree if as you say, the octet string is opaque.

>If you have some proposed text, we can discuss it.

If the octet string is not opaque, then something
like this would lead to well defined behavior that
enahances interoperability.

99.99 Special cases: dot1dStpPortDesignatedPort 

If a device has greater than 255 ports, the 
Port Identifier encoding can not be done
with the bit allocations as defined prior 
to IEEE 802.1T. dot1dStpPortDesignatedPort object 
instances greater than 255 are not visible 
to management queries.

Mike MacFaden