[Bridge-mib] RE: VLAn ID

"Andrew Smith" <ah_smith@acm.org> Fri, 28 February 2003 09:02 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17809 for <bridge-archive@odin.ietf.org>; Fri, 28 Feb 2003 04:02:54 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9DHn10286 for bridge-archive@odin.ietf.org; Fri, 28 Feb 2003 04:13:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9D9p10279; Fri, 28 Feb 2003 04:13:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RI0mp07780 for <bridge-mib@optimus.ietf.org>; Thu, 27 Feb 2003 13:00:48 -0500
Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13848 for <bridge-mib@ietf.org>; Thu, 27 Feb 2003 12:50:11 -0500 (EST)
Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oSEP-0006mA-00; Thu, 27 Feb 2003 09:54:05 -0800
From: "Andrew Smith" <ah_smith@acm.org>
To: "'Wijnen, Bert \(Bert\)'" <bwijnen@lucent.com>
Cc: "'Bridge-Mib \(E-mail\)'" <bridge-mib@ietf.org>, <mibs@ops.ietf.org>
Date: Thu, 27 Feb 2003 09:53:56 -0800
Message-ID: <046701c2de89$35d1c160$1500000a@ANDREWLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501062FA1@nl0006exch001u.nl.lucent.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Bridge-mib] RE: VLAn ID
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-BeenThere: bridge-mib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Id: <bridge-mib.ietf.org>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Bert,

The whole point of defining these TCs in a separate document is to serve
"possible future (yet-undefined) needs" - why else would we bother to
break them out in a separate document or module? 

The need to use VlanIdOrAny as an index in the future seems likely to
me. It is especially likely if you believe that we're trying to set a
precedent here for how to represent "some sort of packet field or
don't-care". Personally, I think it's a bit clunky to overload the value
like this - a separate flag object is more elegant, but, if we're
comfortable with the overloading, I'd go with Randy and say (as I did
before - maybe you missed my message?) that the syntax here should be
unsigned, not signed (I understand the practical reasons for the
non-negative-index restriction in SNMP but it is a limitation on the
SMIv2 language). I don't think there's a need to consult with IEEE 802
on this - I think most of the people with relevant opinions on this are
already on this thread - but that's the bridge-mib WG chair's call if he
wants to ask himself for help.

My opinions (I know you're looking for others though ...).

Andrew


-----Original Message-----
From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf
Of Wijnen, Bert (Bert)
Sent: Thursday, February 27, 2003 8:36 AM
To: Randy Presuhn (E-mail)
Cc: Bridge-Mib (E-mail); mibs@ops.ietf.org
Subject: VLAn ID


Randy, you wrote:
>To:   bridge-mib@ietf.org
>cc:   mibs@ops.ietf.org (Les Bell/GB/3Com)
>Subject:  Re: [Bridge-mib] VLAN-ID
>
>Hi -
>
>I think it would be better if the "any" value in the *OrAny TC were
>a non-negative value so that the type could be used to define an
>index.  There may not be a need today, but thinking ahead to
>representing policy-like things wouldn't hurt.
>

As far as I can tell, you seem to be the only one sofar who 
has spoken up on the idea of not having a negative value
for the "any" for the VlanIdOrAny TC that I proposed.

You do not claim an immediate need, but a possible future
(yet-undefined) need.

S


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