Re: VLAn ID

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

-----Original Message-----
From: Andrew Smith <[email protected]>
To: 'Wijnen, Bert (Bert)' <[email protected]>
Cc: 'Bridge-Mib (E-mail)' <[email protected]>; [email protected]
<[email protected]>
Date: 27 February 2003 18:00
Subject: 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: [email protected] [mailto:[email protected]] On
Behalf
>Of Wijnen, Bert (Bert)
>Sent: Thursday, February 27, 2003 8:36 AM
>To: Randy Presuhn (E-mail)
>Cc: Bridge-Mib (E-mail); [email protected]
>Subject: VLAn ID
>
>
>Randy, you wrote:
>>To:   [email protected]
>>cc:   [email protected] (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
>
>
>