Re: [Bridge-mib] FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t

Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Mon, 16 February 2004 11:59 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 GAA12935 for <bridge-archive@odin.ietf.org>; Mon, 16 Feb 2004 06:59:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshOv-0007sl-Qc for bridge-archive@odin.ietf.org; Mon, 16 Feb 2004 06:59:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GBx18w030293 for bridge-archive@odin.ietf.org; Mon, 16 Feb 2004 06:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshOv-0007sR-HJ; Mon, 16 Feb 2004 06:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshO9-0007rs-7D for bridge-mib@optimus.ietf.org; Mon, 16 Feb 2004 06:58:13 -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 GAA12905 for <bridge-mib@ietf.org>; Mon, 16 Feb 2004 06:58:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshO4-00063s-00 for bridge-mib@ietf.org; Mon, 16 Feb 2004 06:58:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshN7-00061O-00 for bridge-mib@ietf.org; Mon, 16 Feb 2004 06:57:09 -0500
Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AshMC-0005yn-00 for bridge-mib@ietf.org; Mon, 16 Feb 2004 06:56:12 -0500
Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1GBuAmi009413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 Feb 2004 12:56:10 +0100
Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1GBuACw016024; Mon, 16 Feb 2004 12:56:10 +0100
Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i1GBu9MM016021; Mon, 16 Feb 2004 12:56:09 +0100
Date: Mon, 16 Feb 2004 12:56:09 +0100
Message-Id: <200402161156.i1GBu9MM016021@hansa.ibr.cs.tu-bs.de>
From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
To: ah_smith@acm.org
CC: bwijnen@lucent.com, bridge-mib@ietf.org
In-reply-to: <17e501c3f421$b68a7050$1600000a@ANDREWLAPTOP> (ah_smith@acm.org)
Subject: Re: [Bridge-mib] FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t
References: <17e501c3f421$b68a7050$1600000a@ANDREWLAPTOP>
X-IBRFilter-SpamReport: 0 ()
X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang)
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=none autolearn=no version=2.60
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>

>>>>> Andrew Smith writes:

Andrew> As I've said before, I think that's a backwards step. There's
Andrew> no point in having the TC either (a) if you have to still
Andrew> refine its definition/semantics in the DESCRIPTION of any
Andrew> object that uses it, or (b) if the name represents syntax, not
Andrew> semantics

The reason why the name represents syntax and not semantics is that
the TC just says there is a special value (typically zero) where the
interpretation of the special value is up to the usage of the TC.
This has the big benefit that you need to allocate only one special
value. Experience with the InterfaceIndex so far shows that this
seem to work reasonably well.

Andrew> (I don't care how many other TCs people have already defined
Andrew> called "...OrZero" - that does not make them good - if only
Andrew> the syntax is common between various uses of such a TC,
Andrew> without there being common semantics, again I think the TC
Andrew> does not deserve to exist).

While I would agree with this principle in a pure programming
environment, we have to accept that allocating special values
is not as easy in MIB space and putting new semantically rich
TCs on the standards track is a slow operation. This is why
the solution to have fewer but more generic TCs is attractive
in this space.

Andrew> Sorry for the repetitiocity - this argument does seem to be
Andrew> going around in non-diminishing circles.

I like to understand whether there is a real technical reason why the
various usages of the TC must use different numbers. Allocating 4096
or whatever was choosen might be a pain down the road (the IETF has
some experience with number spaces that at some point in time need
to get enlarged, even though this sounded unrealistic when the number
space was defined).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany



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