Subject: [Diffserv] Comment on DiffServ MIB & PIB

From: "Durham, David" <[email-masked]>
Date: Fri, 7 Jul 2000 16:54:05 -0700

We are currently working on the DiffServ PIB to better bring it into
alignment with the DiffServ MIB. Basically, we are changing some of the PIB
object names to conform to the MIB object names.

Nevertheless, I believe one table name in the MIB doesn't quite jive. The
diffServClassifierTable in the MIB isn't really a classifier at all. It is
simply a binding from an entry in the real sixTupleClassificationTable to
the appropriate next step (eg. meter block). Calling such a binding a
classifier seems somewhat redundant if not incorrect. I would suggest a
better name for this MIB table would be "TargetTable" since it is targeting
the traffic conditioning functions to a particular filter. 

Cheers,
-Dave

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Andrew Smith <[email-masked]>
Date: Thu, 13 Jul 2000 00:30:51 -0700

Dave,

I guess nobody else has an opinion on this so I'll chime in with one. 

1. The diffServClassifierTable implements the datapath functional element called
a "Classifier element" in the conceptual model draft. So I guess you're
proposing we change the name of that one too.

2. I don't understand what you mean by saying it "isn't really a classifier" but
is "simply a binding". No of course it is not a classifier (you need gates and
volts to build one of those), it is a representation of the control structures
for a classifier element. In the MIB, it is a block of information that connects
up (a) a filter pattern to compare against (a pointer to a filter entry in a
separate table which might be a 6-tuple filter or whatever else you might choose
to define) (b) a next element describing what to do with traffic that matches
the filter and (c) assorted other control info. What's wrong with it being a
"binding"? The whole MIB is full of bindings like this. 

3. I don't understand what you mean by "targeting the traffic conditioning
functions to a particular filter": if you mean that the filter selects the
traffic conditioning functions then I think (a) you've got it backwards: the
filter is the one targeting the t.c. (the t.c. is the thing being targeted) (b)
that's only part of the whole story: a MEter element also is involved in
determining which traffic is acted on by things like droppers, markers etc.

4. The name "target" doesn't work for me. What's wrong with
diffServClassifierEntry? Thats what it is representing.

Maybe you could relate your comments to the conceptual model draft first - the
MIB just follows on from that and uses terminology derived from it.

Andrew

-- 
******************************************************************
Andrew Smith                            tel: +1 415 345 1627
1001 Chestnut St.                       fax: +1 415 345 1827
San Francisco, CA 94109, USA          email: [email-masked]
******************************************************************