Re: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-03.txt

Michael MacFaden <mrm@riverstonenet.com> Mon, 27 May 2002 05:15 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03764 for <bridge-archive@odin.ietf.org>; Mon, 27 May 2002 01:15:04 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18916 for bridge-archive@odin.ietf.org; Mon, 27 May 2002 01:15:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18901; Mon, 27 May 2002 01:15:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18872 for <bridge-mib@optimus.ietf.org>; Mon, 27 May 2002 01:15:23 -0400 (EDT)
Received: from agile.yagosys.com ([63.198.118.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03756 for <bridge-mib@ietf.org>; Mon, 27 May 2002 01:14:59 -0400 (EDT)
Received: (qmail 2673 invoked by uid 10041); 27 May 2002 05:15:20 -0000
Date: Sun, 26 May 2002 22:15:20 -0700
From: Michael MacFaden <mrm@riverstonenet.com>
To: bridge-mib@ietf.org
Subject: Re: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-03.txt
Message-ID: <20020526221520.C2410@riverstonenet.com>
References: <917063BAB0DDB043AF5FAA73C7A835D417302F@windlord.WWP.COM> <004f01c20485$cc0ab350$87885ac2@Alexr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004f01c20485$cc0ab350$87885ac2@Alexr>
User-Agent: Mutt/1.3.22i
X-Operating-System: GNU/Linux 2.4.18
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <bridge-mib.ietf.org>
X-BeenThere: bridge-mib@ietf.org

On Sun, May 26, 2002 at 09:20:20AM +0200, Alex Ruzin wrote:
>Actually I only meant to make the definition for this
>object *semantically* better. Are you agree with my proposition
>"in general", except "MAX-ACCESS"? Do you think, that definition
>of this object has to be improved?
>If so, I propose
>
>    dot1dStpPortEnable OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        dummyReadValue(0),
>                        forceBlock(1),
>                        forceDisable(2)
>                   }
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "'Force Port State' of the port. Both GET and GETNEXT operation
>              always return value dummyReadValue(0). An attempt to write the value
>             dummyReadValue(0) must cause an error."
>        REFERENCE
>            "IEEE 802.1D-1998: Section 14.8.2.2"
>        ::= { dot1dStpPortEntry 4 }
>
>Your comments and/or proposition, please?

The operation of this object is clear but such a redefinition
would not be allowed by IESG mib doctors as it is not backward compatible. 

If this definition were for a new object, then I don't see why there is
a need for a dummyReadValue other than to create a write-only style access.
The SMIv2 dropped write-only access for a purpose and as such most MIB 
doctors would discourage its use.

I think dot1dStpPortEnable should be left as-is but the front matter
should explain how this object was supposed to operate since it 
is clear that many vendors did not implement it according to 
the original authors intentions.

Mike MacFaden

_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib