Re: [Bridge-mib] 802.1s mib
"Tom Petch" <nwnetworks@dial.pipex.com> Sat, 03 April 2004 18:18 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for <bridge-archive@odin.ietf.org>; Sat, 3 Apr 2004 13:18:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9piU-0006lz-CB for bridge-archive@odin.ietf.org; Sat, 03 Apr 2004 13:18:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33II2Q7026036 for bridge-archive@odin.ietf.org; Sat, 3 Apr 2004 13:18:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9piT-0006li-RJ; Sat, 03 Apr 2004 13:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9piQ-0006ku-1P for bridge-mib@optimus.ietf.org; Sat, 03 Apr 2004 13:17:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28859 for <bridge-mib@ietf.org>; Sat, 3 Apr 2004 13:17:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9piO-0000h8-00 for bridge-mib@ietf.org; Sat, 03 Apr 2004 13:17:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9phX-0000bX-00 for bridge-mib@ietf.org; Sat, 03 Apr 2004 13:17:03 -0500
Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1B9pgf-0000NV-00 for Bridge-mib@ietf.org; Sat, 03 Apr 2004 13:16:09 -0500
Received: from tom3 (1Cust208.tnt4.lnd1.gbr.da.uu.net [62.188.17.208]) by colossus.systems.pipex.net (Postfix) with SMTP id CBBCC1C00061; Sat, 3 Apr 2004 19:15:35 +0100 (BST)
Message-ID: <011901c419a7$63263e20$0301a8c0@tom3>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: "Harrington, David" <dbh@enterasys.com>
Cc: Bridge-mib@ietf.org
Subject: Re: [Bridge-mib] 802.1s mib
Date: Sat, 03 Apr 2004 19:12:42 +0100
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
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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
Just to be clear on the basics (which I think I am), I think you need to mind your p's and q's or in this case s's and Q's. IEEE Std 802.1Q tm, 2003 Edition incorporates IEEE Std 802.1s tm, -2002 so .1s is history. This is not to say it won't appear in many product websites for years to come, even in places yet more inaccurately as .1S; but strictly, it has gone. And of course this is a difference between IETF, where RFC1157 refers to the same string of ASCII in perpetuity and 802.1Q does not; the latter needs a qualifying date. So any .1Q MIB module needs a qualifier after it. And while these IEEE publications do contain PICS proforma, they do not - for me - contain much by way of conformance, certainly not the macro-specified conformance that is now part of any IETF MIB module. So while the IEEE may have a good data model ready to be turned into a MIB module, I think there is much work to be done in producing meaningful subsets for remote management and IMO the actual IEEE document structure is not a good place to start, ie MIB modules should cut across document boundaries. It then becomes unrealistic to talk of a .1s or .1Q MIB module. Tom Petch -----Original Message----- From: Harrington, David <dbh@enterasys.com> To: Tony Jeffree <tony@jeffree.co.uk>; Congdon, Paul T (ProCurve) <paul.congdon@hp.com> Cc: Romascanu, Dan (Dan) <dromasca@avaya.com>; Bridge-mib@ietf.org <Bridge-mib@ietf.org> Date: 03 April 2004 14:56 Subject: [Bridge-mib] 802.1s mib > > >On a related note, shouldn't the .1s MIB be part of an > updated Q-BRIDGE > >MIB instead of a separate MIB? > > Absolutely. S is now part of Q anyway. > Will all implementors of Q also implement S, or is it an optional part of Q? If it is an optional part of Q, then it would probably be best to write a separate mib that supplements the Q mib. This approach is generally easier for implementors and users. Note that you can have multiple mib modules defined in the same document. Updating mibs: SNMP has some strict rules about versioning of mibs, detailed in the SMIv2 documents (RFCs 2578, 79, and 80). It is important to follow these rules to ensure interoperability between agent implementations and manager implementations, which are often implemented by different vendors. A technology standard such as Q might be able to be modified, and a device either supports the old way or the new way, but with SNMP it is almost always a requirement that multi-vendor applications support both ways, so the two ways cannot be in conflict (with very few clearly-identified exceptions) or it can cause real interoperability problems. Having a separate mib for optional functionality helps to ensure that mibs like the Q mib don't change, so people can count on it for interoperability. dbh _______________________________________________ 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
- [Bridge-mib] 802.1s mib Harrington, David
- Re: [Bridge-mib] 802.1s mib Tom Petch