Re: [Bridge-mib] IETF-54 meeting

Michael MacFaden <> Tue, 09 July 2002 00:43 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id UAA21112 for <>; Mon, 8 Jul 2002 20:43:46 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id UAA11660 for; Mon, 8 Jul 2002 20:44:37 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id UAA11647; Mon, 8 Jul 2002 20:44:36 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id UAA11615 for <>; Mon, 8 Jul 2002 20:44:35 -0400 (EDT)
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with SMTP id UAA21109 for <>; Mon, 8 Jul 2002 20:43:42 -0400 (EDT)
Received: (qmail 32510 invoked by uid 10041); 9 Jul 2002 00:44:03 -0000
Date: Mon, 8 Jul 2002 17:44:03 -0700
From: Michael MacFaden <>
Subject: Re: [Bridge-mib] IETF-54 meeting
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4i
X-Operating-System: GNU/Linux 2.4.18
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

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:

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
     dot1dStpPort.  On newer bridges, permissible values are 0-240, in
     steps of 16."

I don't believe this change is backward compatible at all.  You can't
simply change the values one can use.  This entirely new semantic requires 
a new object.  I simply can't see IESG MIB module reviewers accepting 
this a change. And exactly what is a "newer bridge" anyway? 

Mike MacFaden

Bridge-mib mailing list