[Bridge-mib] Re: VLAn ID

"Tom Petch" <nwnetworks@dial.pipex.com> Thu, 27 February 2003 19:23 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17824 for <bridge-archive@odin.ietf.org>; Thu, 27 Feb 2003 14:23:10 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RJXJc14820 for bridge-archive@odin.ietf.org; Thu, 27 Feb 2003 14:33:19 -0500
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJX8p14811; Thu, 27 Feb 2003 14:33:09 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJWgp14781 for <bridge-mib@optimus.ietf.org>; Thu, 27 Feb 2003 14:32:42 -0500
Received: from colossus.systems.pipex.net (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17792 for <bridge-mib@ietf.org>; Thu, 27 Feb 2003 14:22:02 -0500 (EST)
Received: from tom3 (unknown []) by colossus.systems.pipex.net (Postfix) with SMTP id B973016000563; Thu, 27 Feb 2003 19:25:57 +0000 (GMT)
Message-ID: <013e01c2de95$ba0cf560$0301a8c0@tom3>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Andrew Smith" <ah_smith@acm.org>, "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>
Cc: "'Bridge-Mib (E-mail)'" <bridge-mib@ietf.org>, <mibs@ops.ietf.org>
Date: Thu, 27 Feb 2003 19:12:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
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

I agree
 - clunky to overload the field, a separate flag is more elegant
- should be unsigned not signed
Tom Petch

-----Original Message-----
From: Andrew Smith <ah_smith@acm.org>
To: 'Wijnen, Bert (Bert)' <bwijnen@lucent.com>
Cc: 'Bridge-Mib (E-mail)' <bridge-mib@ietf.org>rg>; mibs@ops.ietf.org
Date: 27 February 2003 18:00
Subject: RE: VLAn ID

>The whole point of defining these TCs in a separate document is to
>"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
>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
>on this - I think most of the people with relevant opinions on this
>already on this thread - but that's the bridge-mib WG chair's call if
>wants to ask himself for help.
>My opinions (I know you're looking for others though ...).
>-----Original Message-----
>From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On
>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.

Bridge-mib mailing list