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

>>>>> 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