RE: [Bridge-mib] RE: VLAn ID

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Thu, 14 August 2003 21:36 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27483 for <bridge-archive@odin.ietf.org>; Thu, 14 Aug 2003 17:36:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPlK-0001aq-KU for bridge-archive@odin.ietf.org; Thu, 14 Aug 2003 17:36:03 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ELa2A8006104 for bridge-archive@odin.ietf.org; Thu, 14 Aug 2003 17:36:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPlK-0001a2-7v; Thu, 14 Aug 2003 17:36:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPkc-0001Yy-Fo for bridge-mib@optimus.ietf.org; Thu, 14 Aug 2003 17:35:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27444 for <bridge-mib@ietf.org>; Thu, 14 Aug 2003 17:35:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nPka-00067S-00 for bridge-mib@ietf.org; Thu, 14 Aug 2003 17:35:16 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19nPkZ-00066P-00 for bridge-mib@ietf.org; Thu, 14 Aug 2003 17:35:15 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7ELYf723431 for <bridge-mib@ietf.org>; Thu, 14 Aug 2003 16:34:42 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <NR1Y3H2W>; Thu, 14 Aug 2003 23:34:36 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550236179D@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Bridge-Mib (E-mail)" <bridge-mib@ietf.org>, "MIBs (E-mail)" <mibs@ops.ietf.org>
Cc: Les Bell <Les_Bell@eur.3com.com>, Tony Jeffree <tony@jeffree.co.uk>, "C. M. Heard" <heard@pobox.com>
Subject: RE: [Bridge-mib] RE: VLAn ID
Date: Thu, 14 Aug 2003 23:34:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

So... what do we do for a common (or a few) common TCs.
Anyone wants to write a I-D for it?

It seems like we would define the VlanIDOrAny as (0..4095)
now and make 4095 mean "wildcard"

There is another MIB coming up in the IPCDN WG that wants
to define a VlanIDOrAny (not a TC, but the concetp) for
one of their objects. If we could give them guidance on 
what to do (soon), that would be great.

Thanks,
Bert 

> -----Original Message-----
> From: Les Bell [mailto:Les_Bell@eur.3com.com]
> Sent: dinsdag 10 juni 2003 12:10
> To: C. M. Heard
> Cc: Tony Jeffree; MIBs (E-mail); Bridge-Mib (E-mail)
> Subject: Re: [Bridge-mib] RE: VLAn ID
> 
> 
> 
> 
> 
> I agree that no changes are required to clause 12 of 802.1Q.
> 
> Les...
> 
> 
> 
> 
> 
> "C. M. Heard" <heard@pobox.com>@ietf.org on 07/06/2003 04:07:22
> 
> Sent by:  bridge-mib-admin@ietf.org
> 
> 
> To:   Tony Jeffree <tony@jeffree.co.uk>
> cc:   "MIBs , "Bridge-Mib
> Subject:  [Bridge-mib] RE: VLAn ID
> 
> 
> On Fri, 6 Jun 2003, in a message forwarded by Bert Wijnen,
> Tony Jeffree wrote:
> > We have concluded that the use of 4095 as a wildcard is
> > acceptable to 802.1, and we will make any necessary changes to
> > 802.1Q in due course to relax the current stated restriction.
> > However, we need to know whether that is all that needs to be
> > done to 802.1Q - i.e., is there any need to change our
> > definitions of the managed objects in the document (Clause 12)
> > to reflect the interpretation of 4095 as a wildcard, or is this
> > simply an issue for the SNMP machinery to handle?
> 
> After a quick look at 802.1Q-1998, 802.1u-2001, and 802.1v-2001 it
> appears to me that no changes are required to clause 12 of 802.1Q.
> 
> Can any Bridge-Mib folk confirm that?
> 
> //cmh
> 
> _______________________________________________
> Bridge-mib mailing list
> Bridge-mib@ietf.org
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 
> 
> 
> 

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