[Bridge-mib] RE: VLAn ID

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