Bridge MIB (bridge)

Les Bell | 8 Jul 2002 16:55

IETF-54 meeting


I have booked a slot in the schedule for the Bridge-MIB WG in Yokohama.
However, as the document editors/authors cannot attend the meeting, and I
believe the current drafts are ready to go for a last call, I wanted to get the
opinion of the Working Group as to whether there is any need to go ahead with
this meeting.  I am also unable to attend the meeting, but Dan Romascanu has
volunteered to chair the meeting in my absence, if required.

No-one has raised any issues for the agenda so far.  If you feel that there is a
need to hold a meeting in Yokohama, then please reply to the mailing list by end
of Wednesday, 10th July, and please state what it is we need to discuss.

The current drafts are:

Definitions of Managed Objects for Bridges
http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-03.txt

Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol
http://www.ietf.org/internet-drafts/draft-ietf-bridge-rstpmib-03.txt

Definitions of Managed Objects for Bridges with TrafficClasses, Multicast
Filtering and Virtual LAN Extensions
http://www.ietf.org/internet-drafts/draft-ietf-bridge-ext-v2-00.txt

Definitions for Port Access Control (IEEE 802.1X) MIB
http://www.ietf.org/internet-drafts/draft-ietf-bridge-8021x-00.txt

Les...

headers

Michael MacFaden | 9 Jul 2002 02:44

Re: IETF-54 meeting

On Mon, Jul 08, 2002 at 03:55:51PM +0100, Les Bell wrote:
>I believe the current drafts are ready to go for a last call, I wanted to get the
>opinion of the Working Group as to whether there is any need to go ahead with
>this meeting.  

I won't be attending Yokohama but wanted to comment on two issues 
I have previously raised in previous versions of the BRIDGE-MIB draft
which remain in draft-ietf-bridge-bridgemib-smiv2-03.txt.

First, the REFERENCE clause changes do help improve the chances of
interoperable implementations. Yet I still think these two ancient 
objects have interoperability issues.

1) dot1dStpPortEnable
   I believe there needs to be some text added to the front matter
   to describe the relationship between ifAdminStatus and dot1dStpPortEnable. 
   What is the relationship between ifAdminStatus and dot1dStpPortEnable? 
     a) none, 
     b) represent same value (as embodied in cisco catalyst implementation)
     c) represent different layers (port level, vs protocol level) (kzm expectation?)

   background info: http://www.macfaden.com/ietf/bridge-test-results.txt

2) dot1dStpPortPriority
   The wording could be more specific as to what the issue is. 
   It currently reads:

    "The value of the priority field which is contained in
     the first (in network byte order) octet of the (2 octet long) Port ID.  
     The other octet of the Port ID is given by the value of

(Continue reading)