RE: VLAn ID

Any chance you can stirr up that 'ballot' process?
Some people are waiting for a solution in IETF MIB land.

Thanks,
Bert 

> -----Original Message-----
> From: Les Bell [mailto:[email protected]]
> Sent: woensdag 7 mei 2003 9:06
> To: Wijnen, Bert (Bert)
> Cc: Andrew Smith; 'Bridge-Mib (E-mail)'; [email protected];
> [email protected]; [email protected]
> Subject: RE: VLAn ID
> 
> 
> 
> 
> 
> This was discussed at the March meeting.  The decision was to 
> conduct an email
> 'ballot' to determine if anyone had any objections to using 
> 4095 as a wildcard
> VLAN ID.  I have not heard about the details of how, or when, 
> this will take
> place.
> 
> Les...
> 
> 
> 
> 
> 
> "Wijnen, Bert (Bert)" <[email protected]> on 06/05/2003 18:43:42
> 
> Sent by:  "Wijnen, Bert (Bert)" <[email protected]>
> 
> 
> To:   Les Bell/GB/3Com, Andrew Smith <[email protected]>
> cc:   "'Wijnen, Bert , "'Bridge-Mib , [email protected]
> Subject:  RE: VLAn ID
> 
> 
> 
> 
> Les, Did you get any feedback after that March 9th meeting?
> If not, Can you poll Mick Seaman?
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Les Bell [mailto:[email protected]]
> > Sent: vrijdag 28 februari 2003 17:27
> > To: Andrew Smith
> > Cc: 'Wijnen, Bert (Bert)'; 'Bridge-Mib (E-mail)'; [email protected]
> > Subject: RE: VLAn ID
> >
> >
> >
> >
> >
> > I have asked for the opinion of the IEEE 802.1 Task Force
> > Chair, Mick Seaman, on
> > this proposal.  He believes that the use of 4095 as a
> > wildcard VLAN-ID would be
> > okay, but he wants to discuss it formally at the IEEE 802
> > meeting in Dallas
> > (week commencing March 9).  I will be attending this meeting.
> >
> > Les...
> >
> >
> >
> >
> >
> > "Andrew Smith" <[email protected]> on 27/02/2003 17:53:56
> >
> > Sent by:  "Andrew Smith" <[email protected]>
> >
> >
> > To:   "'Wijnen, Bert \
> > cc:   "'Bridge-Mib \, [email protected] (Les Bell/GB/3Com)
> > 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
>