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

From: "Rohit Rohit" <[email-masked]>
Date: Thu, 23 May 2002 11:21:10 -0700

Hi Alex, 

  I have never heard of "MAX-ACCESS  write-only"

  I have heard it to be read-only; read-write or read-create.

  Thanks
  Rohit

-----Original Message-----
From: Alex Ruzin [mailto:[email-masked]]
Sent: Thursday, May 23, 2002 8:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-03.txt

[This comment isn't devoted to this edition of the draft,
but to all previous editions too]

It seems to me, that the object dot1dStpPortEnable doesn't reflect a *port
state*
as it is defined in "IEEE 802.1D-1998: Section 8.5.5.2"; rather it
correspondents to "Force port state" from Section 14.8.2.2.
I propose to discuss an option to:
1) do this object "MAX-ACCESS  write-only"
2) set possible values as
        SYNTAX      INTEGER {
                        forceBlock(1),
                        forceDisable(2)
                    }
3) change REFERENCE: "IEEE 802.1D-1998: Section 14.8.2.2"

Yours faithfully, Alex

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Thursday, May 23, 2002 1:30 PM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: [Bridge-mib] I-D
> ACTION:draft-ietf-bridge-bridgemib-smiv2-03.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Bridge MIB Working Group of the IETF.
>
> 	Title		: Definitions of Managed Objects for Bridges
> 	Author(s)	: K. Norseth, E. Bell
> 	Filename	: draft-ietf-bridge-bridgemib-smiv2-03.txt
> 	Pages		: 36
> 	Date		: 22-May-02
>
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in TCP/IP based internets.
> In particular it defines objects for managing MAC bridges based on
> the IEEE 802.1D-1998 standard between Local Area Network (LAN)
> segments.  Provisions are made for support of transparent bridging.
> Provisions are also made so that these objects apply to bridges
> connected by subnetworks other than LAN segments.
> The MIB presented in this memo is a direct translation of the BRIDGE
> MIB defined in [RFC1493], to the SMIv2 syntax required for current
> IETF MIB standards.  This memo obsoletes RFC 1493.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemi
b-smiv2-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-bridge-bridgemib-smiv2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-bridge-bridgemib-smiv2-03.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: [email-masked] (Alex Ruzin)
Date: Sun, 26 May 2002 09:20:20 +0200

OK, OK, OK...
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?
Alex

On Thursday, May 23, 2002 8:16 PM Michael MacFaden wrote:
Michael > See RFC 2578 page 9, in SMIv2 MAX-ACCESS does not support 
Michael > "write-only "

On Thursday, May 23, 2002 8:21 PM Rohit Rohit wrote:
Rohit>   I have never heard of "MAX-ACCESS  write-only"
Rohit>   I have heard it to be read-only; read-write or read-create.

---

From: Michael MacFaden <[email-masked]>
Date: Sun, 26 May 2002 22:15:20 -0700

On Sun, May 26, 2002 at 09:20:20AM +0200, Alex Ruzin wrote:
>              always return value dummyReadValue(0). An attempt to write the value

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

---

From: Ali Chanaui <[email-masked]>
Date: Sun, 26 May 2002 23:18:08 -0700 (PDT)

I have another question (it seems to me,
it dedicated rather to [email-masked]).

If Port has been done forceDisable(2) or
disabled(2) - does this Port take place in Active
Topology?
I mean: does it forward frames, leran addresses?
Does it participate in GVRP, etc.?

Ali

--- Michael MacFaden <[email-masked]> wrote:
> >              always return value
> dummyReadValue(0). An attempt to write the value

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com