Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2

From: Andrew Smith <[email-masked]>
Date: Mon, 03 Jul 2000 17:54:30 -0700

John,

The 4 categories chosen are a fairly arbitrary taxonomy for grouping
descriptions of somewhat similar things into the same chapter of the document:
things to do with pattern matching on fields within packets are in one chapter,
things to do with measuring packet arrival events against some sort of history
are in another, things to do with pulling packets out of queues onto an output
are in another, etc.. We could rearrange the document into a single chapter, if
that would help you read and understand it, but I fail to see why the document
should not choose whatever arbitrary categories it wants to, if it provides a
structure for the descriptions.

You seem to have a very fixed idea of what "modelling" (sic) means - maybe you'd
like us to change the name of the document to avoid the M word.

Andrew

-----Original Message-----
From:	John Strassner [SMTP:[email-masked]]
Sent:	Wednesday, June 28, 2000 11:46 PM
To:	Andrew Smith; [email-masked]
Subject:	Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2

I got this from several hall discussions. So if this isn't
true, then what is the rationale for separating elements
into the four categories that you've defined? Especially
since all of them, from a modeling point-of-view, provide
actions...

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "'John Strassner'" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 28, 2000 2:14 PM
Subject: RE: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

> John,
>
> I don't know where you get the idea that "number of inputs
and outputs" is
> the fundemental taxonomy of the components of this model.
It's not.
> Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Jul 2000 11:08:30 -0500

I don't think we can get rid of the M word, but we should indeed tune 
both the abstract and the introduction to make it even clearer that this 
is not a formal mathematical model, but rather a conceptual model as the
title says. It's quite meaningful for rigid specifications such as
the MIB and the PIB to be required to be consistent with a conceptual
(non-mathematical) model; it's just not a requirement for rigid
mathematical consistency. 

I didn't see any support on the list for eliminating the TCB concept
as John suggested.

Andrew, apart from that please make whatever edits are needed for the
various bugs that John found in his exhaustive analysis.

  Brian Carpenter
  diffserv co-chair

> > the fundemental taxonomy of the components of this model.

_______________________________________________
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: Wed, 05 Jul 2000 10:56:54 -0700

Will do so - thanks John for pointing out the inconsistencies. Also, note that
it is a *verbal* model, not a visual one - the diagrams are not intended to
define the model, only to illustrate examples of things you can build with the
Lego.

Andrew

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

---

From: "John Strassner" <[email-masked]>
Date: Wed, 5 Jul 2000 23:44:39 -0700

Hi Andrew,

I don't want you to rearrange the document. I don't even
want you to change the modeling [sic] ;-) word. Rather, what
I was trying to understand was the taxonomy used to develop
the model.

Here's the root of the problem. Your four categories are
classification, metering, actions, and queuing. What first
confused me was the "action" category. Classifiers, meters,
markers, droppers, and queues all are "actions" that are
taken on the packet (whereas, for example, counters are not,
even though they are included in your action category). So I
was trying to understand how you defined an "action".

This then led to the more general question of an overall
taxonomy, and how such a taxonomy could be used to build an
information model as well as a data model. Using an OO
approach, I would have preferred to see classifiers, meters,
markers, droppers, and queues all as subclasses of a more
general class that was used as the basis of conditioning
traffic. The model as currently described implies that these
are very different things with not a lot in common.

regards,
John

---

From: "John Strassner" <[email-masked]>
Date: Thu, 6 Jul 2000 00:03:17 -0700

Thanks for this Brian, but I also didn't see any defense of
the TCB as is. If you want to leave the TCB in, then that's
fine, but I think that its existence should be further
validated. For example, I note that both the PIB and the MIB
don't use the TCB.

Therefore, I don't see how the abstract can say that the
model is a basis for building either if such a central
concept of the model is not implemented in either the MIB or
the PIB.

Plus, I would really like to see a response to my questions
about the purpose of the TCB.

thanks in advance and regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Jul 2000 08:31:05 -0700

>>>>> "John" == John Strassner <[email-masked]> writes:
    John> classification, metering, actions, and queuing. What first
    John> confused me was the "action" category. Classifiers, meters,
    John> markers, droppers, and queues all are "actions" that are
    John> taken on the packet (whereas, for example, counters are not,
    John> even though they are included in your action category). So I
    John> was trying to understand how you defined an "action".

  I don't agree at all.
  Queueing and marking might be actions to be taken on the packet.

  But, classifing, and metering are things that the system does with
the packet to establish properties about the packet and/or flow.

    John> approach, I would have preferred to see classifiers, meters,
    John> markers, droppers, and queues all as subclasses of a more
    John> general class that was used as the basis of conditioning
    John> traffic. The model as currently described implies that these
    John> are very different things with not a lot in common.

  I don't think that they have anything in common.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |      ... visiting customers in San Jose.
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>.

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 6 Jul 2000 13:38:09 -0400

> are very different things with not a lot in common.

Jon,

I don't think it is really appropriate to see classifiers, meters,
markers, droppers, and queues all as sub-classes of a more general
class. I don't really see a "Is A" relationship between above objects,
and without which it will be very hard to define a meaningful base
"action" class to derive from. They are cleanly realizable as separate
classes, and that's what the draft neatly does. I think current draft
model is just right.

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Andrew Smith <[email-masked]>
Date: Thu, 06 Jul 2000 10:58:26 -0700

John,

The next version of the MIB (-04) will, indeed, reference the TCB concept. But
only for one specific function, that of determining which TCB a given classifier
element is located in (it is possible to have the same classification patterns
used multiple times along a given path through the functional datapath elements
- we had earlier overlooked this fact so we will need to add TCB as an index).

There are several fairly central concepts in the model draft - TCB is just one
of them (I'd put it slightly less central than the low-level functional element
taxonomy and the idea of hooking together elements with arrow-like plumbing). It
should be used by instantiations of the model (e.g. MIBs, PIBs, schemas) as they
see fit: the MIB happens to focus on a very low-level description of the
functional datapath elements so it needs to reference the TCB concept somewhat
less often (zero times in -03, one time in the coming-soon-to-a-list-near-you
-04). 

I can't speak accurately for the next PIB incarnation but I would imagine it has
a similar level of need for the TCB concept.

There's nothing wrong with this.

Andrew

---

From: Andrew Smith <[email-masked]>
Date: Thu, 06 Jul 2000 10:58:19 -0700

Can you think of a better word than "Action" then? It is really just a label for
a chapter of the document - there's no implication in the text that an Action
element actually does something to change packets that pass through it.

Also, for the benefit of those on this list who haven't waded through the Policy
WG mail-list-morass, could you please explain in words of one syllable or less,
the difference between a data model and an information model?

Andrew

---

From: "John Strassner" <[email-masked]>
Date: Thu, 6 Jul 2000 14:09:49 -0700

Sigh.

I don't want to belabor the issue, but I really don't agree.
You're essentially saying that you don't need a picture to
illustrate a model that takes 46 pages to explain.

I would at least appreciate a response to my comments on the
TCB. Since the MIB and the PIB don't use it, and since a
stated goal of the model is for it to serve as the design
guideline for these two documents, I think that this is a
valid request.

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 05, 2000 10:56 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> > > > the fundemental taxonomy of the components of this
model.
************************************************************
******
> San Francisco, CA 94109, USA          email:
[email-masked]
************************************************************
******

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jul 2000 17:18:26 -0500

John,

Can I try and throw the question back to you?

Since we've established that the TCB has no realisation in the MIB or PIB data
structures, and presumably not in the policy information model, it is clearly 
positioned as a descriptive aid for understanding the conceptual model.

Are you arguing 
1) that it is incorrect or misleading as a descriptive aid (assuming Andrew
   fixes the specific inconsistencies you found)?
or
2) we should not have descriptive aids that do not translate into MIB or
   PIB data structures?

If it's 1) we need to fix it.

If it's 2) we will need to put it to the WG as a consensus question.

   Brian

---

From: "John Strassner" <[email-masked]>
Date: Fri, 7 Jul 2000 00:07:46 -0700

Hi Brijesh,

the IS-A relationship derives from several points:

  - these all represent services that are performed on
    the packet stream, and thus derive from a common class
  - the fact that they can be interconnected in numerous
    ways says that they are all related.

regards,
John
----- Original Message -----
From: "Brijesh Kumar" <[email-masked]>
To: "'John Strassner'" <[email-masked]>; "'Andrew
Smith'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2000 10:38 AM
Subject: RE: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

---

From: "John Strassner" <[email-masked]>
Date: Fri, 7 Jul 2000 00:15:58 -0700

Comments inline.

regards,
John
----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 06, 2000 8:31 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> the packet to establish properties about the packet and/or
flow.

<js>
Au contraire, each of these five functions can be modeled as
a black box that has one or more inputs and one or more
outputs that performs an action on the traffic. So to take
one simple counter-example, a classifier consists of a set
of filters that are used to separate a single input stream
into multiple output streams. Thus, I disagree with you on
two points:

  1) the classifier does not establish properties about the
packet/flow,
     rather it uses filters to split the flow into separate
flows
  2) the action of filtering is clearly an action

The same argument can be made for metering and dropping.

Therefore, from a modeling point-of-view, one can view these
five functions as a set of building blocks that can be
arranged as appropriate (including having multiple copies of
the same building block) to define how particular
conditioning is performed on a given flow. Which in turn
means that they have something in common (as another answer
for the question below).

>   I don't think that they have anything in common.

Of course they do. They all perform actions on the packet.
They all interconnect with each other. They all work
together to condition one flow in a manner that is different
for the conditioning of other flows. etc.

>  Personal: <A
HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richa
rdson/Bio.html">[email-masked]</A>. PGP key
available.
>  Corporate: <A
HREF="mailto:[email-masked]">[email-masked]</A>.

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 07 Jul 2000 09:24:38 -0700

John (and all),

A few comments below, in-line:

>     ways says that they are all related.

I'm not sure what you're getting at here: of course, the
components are related by being basics we can compose
to perform diffserv functions. But we're trying to keep
some emphasis on just what we can do with the interconnection
of these basics and what the basics do. For that reason,
there's an emphasis on how they *differ* and where each is
used. They are not all the same, in fact:

....
> > > traffic.

This is not correct. The diffserv WG has been clear
about this from the start (see RFCs 2474 & 2475): traffic
conditioning is what's done by markers, shapers, droppers
and the like. Classifiers are used to identify and steer
packets. Queues and schedulers and queue management algorithms
are used to implement per-hop behaviors. Your lumping all
of these as "conditioning traffic" does not match the
emerging diffserv standard.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jul 2000 09:41:20 -0700

>>>>> "John" == John Strassner <[email-masked]> writes:
    John> <js> Au contraire, each of these five functions can be modeled as a
    John> black box that has one or more inputs and one or more outputs that
    John> performs an action on the traffic. So to take one simple

  The boxes can not be arranged arbitrarily because some, e.g. classifiers
according to your model, have multiple outputs. You therefore need to model
the connections which is are configuration specific.

    John> 1) the classifier does not establish properties about the
    John> packet/flow, rather it uses filters to split the flow into separate
    John> flows 

    ... according to the properties of the packets!

    John> Therefore, from a modeling point-of-view, one can view these five
    John> functions as a set of building blocks that can be arranged as
    John> appropriate (including having multiple copies of the same building
    John> block) to define how particular conditioning is performed on a
    John> given flow. Which in turn means that they have something in common
    John> (as another answer for the question below).

  So, how does this gain us anything? 
  Do you propose that the information model must now model all possible
interconnections?

    John> Of course they do. They all perform actions on the packet.  They

  They all perform <noun> on the packets for appropriate definitions of <noun>.

  Tell me, what concrete piece of data would be represented by the superclass?

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 7 Jul 2000 14:53:10 -0400

> used. They are not all the same, in fact:

Hi Cathleen,

You made a good logical point. I will add a bit OO explanation to it
to make John happy.

Actually, John sees all diff-serve objects derived from a common
action object (which is fine from syntax point of view and some others
may also see that way, but it is inappropriate nevertheless.). To
derive a Queue, a classifier, a meter and a dropper from the same base
action class, though possible in syntax, is actually a very inelegant
OO design. That is the point many others including me were trying to
make.

Let us say, I define a class called: Class
GenAction{GenAction{};null();~GenAction()}
With this definition, it is syntactically possible to create derived
classes as:
Class Meter : Public GenAction {....}, Class Queue : Public GenAction
{ }, Class Qualifier: Public GenAction { } ... etc. However, there is
barely a method (describing behavior) or data elements (describing
attributes) that can be shared between any derived class and the base
class. Class inheritance is only useful when there is some common and
useful behavior/attributes between two classes. This derivation fails
on both criteria. Therefore, it is incorrect from good oo design point
of view to see Diff-serve objects as derived from a common base action
class.

This is the reason - the current draft model is absolutely perfect.

Cheers,

--brijesh

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 07 Jul 2000 13:50:35 -0700

Brijesh Kumar wrote:
...
> This is the reason - the current draft model is absolutely perfect.

Wow...that's the way for the Model draft authors to end
their work week...

---

From: "John Strassner" <[email-masked]>
Date: Sat, 8 Jul 2000 03:43:48 -0700

Hi Brian,

You're right, the TCB does not exist in the policy
information model. And let me reassure you that I have
nothing against descriptive aids! In fact, I was arguing for
a drawing of the canonical representation of the different
stages of conditioning precisely because I think that it
would greatly help to explain the concepts that are
described in the draft.

So what is troubling me are statements like:

  "The model is intended to be abstract and capable of
   representing the configuration parameters important
   to Diffserv functionality for a variety of specific
   router implementations."

and, more importantly,

  "This model serves as the rationale for the design of
   an SNMP MIB [DSMIB] and for other configuration
   interfaces (e.g.  [DSPIB]): these should all be
   based upon and consistent with this model."

The first statement implies that there should be a use for
the TCB. But since the MIB, the PIB, and policy don't use
the TCB, why is it in the model? The second statement is
more troubling, as it says that the model should be used to
help design the MIB and the PIB, as well as other
configuration methods. I believe that the second statement
("This model serves as...") should be removed entirely from
the document.

So my answer to your question depends on what you want to
use this document for, and whether statements such as the
second one referenced above remain in the model. Taking the
path of least pain:

If the second statement is removed, then what I am arguing
is that the inconsistencies that I have found need to be
fixed. Then the follow-on question is how does the TCB help
the reader understand the concepts in the model. My opinion
is that it doesn't, and I wrote two rather long mails
documenting why.

If the authors want to keep the concept of a TCB, then I am
additionally asking the authors to respond to my questions
in the previous two mails, justifying its existence. I truly
think that it doesn't help anything, but rather confuses
things.

Finally, if the infamous second statement is to stay, and
this model is to in fact serve as the rational for the
design of MIBs, PIBs, and other interfaces, then my answer
to your question is, unfortunately, #2 (for the same reason
as above - I don't think the TCB helps at all).

regards,
John

---

From: "John Strassner" <[email-masked]>
Date: Sat, 8 Jul 2000 19:48:02 -0700

Hi Andrew, comments inline.

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2000 10:58 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> John,
>
> The next version of the MIB (-04) will, indeed, reference
the
> TCB concept. But only for one specific function, that of
> determining which TCB a given classifier element is
located
> in (it is possible to have the same classification
patterns
> used multiple times along a given path through the
functional
> datapath elements - we had earlier overlooked this fact so
we
> will need to add TCB as an index).

I don't agree with this. You don't need to use the concept
of a TCB to do this, especially with all of the problems
inherent in the definition of the TCB that I have already
pointed out (which I would really like an answer to). What
we did in our model was define an attribute called
TrafficClass which does this same thing in a simpler and
cleaner way. An update of this draft is currently underway,
and I would encourage you to read it when we finish.

> There are several fairly central concepts in the model
> draft - TCB is just one of them (I'd put it slightly less
> central than the low-level functional element taxonomy and
> the idea of hooking together elements with arrow-like
> plumbing). It should be used by instantiations of the
model
> (e.g. MIBs, PIBs, schemas) as they see fit: the MIB
happens
> to focus on a very low-level description of the functional
> datapath elements so it needs to reference the TCB concept
> somewhat less often (zero times in -03, one time in the
> coming-soon-to-a-list-near-you -04).

Again, I disagree. If the TCB is so important and so
central, it should be referenced many times in both the MIB
and the PIB, as well as be applicable to Policy. Policy is
now, and will remain, TCB-free.

In addition, I wrote two very long emails detailing problems
with the TCB that you haven't responded to. I think that it
is unwise at best to simply insist that the TCB is a
"central concept" without at least answering the questions
that I raised. Indeed, I think that as you try and answer
them, you will soon find that the TCB is more trouble than
it is worth. So I strongly urge you to please read my
comments and try to answer them before you continue with
your use of the TCB.

Again, a key point to note is that we defined a single
attribute as the index that you are looking for, instead of
having to use the entire concept of the TCB. This worked
better, and was much more efficient.

Finally, the notion of high-level or low-level has nothing
to do with anything. If the TCB is so "central", then it
should be able to be applied equally to both high-level
abstractions and low-level implementations. The concept of
the TrafficClass attribute certainly can. ;-)

> I can't speak accurately for the next PIB incarnation but
I would
> imagine it has a similar level of need for the TCB
concept.
> There's nothing wrong with this.

Of course there is. You're saying that the TCB is a central
concept, but that it is OK for implementations to not use
it. That doesn't make any sense.

---

From: "John Strassner" <[email-masked]>
Date: Sat, 8 Jul 2000 15:36:02 -0700

Hi Andrew,

glad to know that action was more innocent than it sounded
;-) How about function?

I know you meant it in a kind way, but the policy group does
have, as you put it, a "morass" of mail because these
concepts are in reality quite hard to define. That's another
reason why I'm being very anal-retentive about the words in
your draft. But as for the definitions:

An information model is a technology-independent
specification of the characteristics of a set of objects,
and their relationships to other objects in a managed
environment, with no reference to either storage methods,
access protocols, or technologies.

A data model is a concrete representation of the
characteristics of a set of objects in terms appropriate to
a specific data storage and access technology.

Thus, when we talk about data models, we always have a
specific context in mind that is a function of at least the
type of data store that contains the data and the type of
access protocol(s) that is (are) being used. When we talk
about an information model, we are "just" talking about data
and behavior describing managed objects, and the
relationships between those managed objects, without regard
to specific data stores or access protocols that are going
to be used.

HTH,
John

----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2000 10:58 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> > > The 4 categories chosen are a fairly arbitrary
taxonomy
> > for grouping
> > > things to do with measuring packet arrival events
against
> > some sort of history
> > > are in another, things to do with pulling packets out
of
> > queues onto an output
> > > are in another, etc.. We could rearrange the document
into
> > a single chapter, if
> > > that would help you read and understand it, but I fail
to
> > see why the document
> > > should not choose whatever arbitrary categories it
wants
> > to, if it provides a
> > > like us to change the name of the document to avoid
the M
> > word.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Jul 2000 13:00:18 -0500

Let me try and put this to bed, as the Internet-Drafts deadline is close.

1). There has been no support on the list that I have seen for John Strassner's
objections to the existence of the TCB in the model. So it should stay in for
the imminent revision of the draft. At the latest during WG last call, we
will have to verify the WG consensus on the retention of the TCB.

2). John also sent a large number of detailed comments. The authors of the model
need to respond to all of those that remain relevant given 1). In view of the
shortage of time, those responses can be in the form of updates to the draft-
it would be nice to also respond point by point to John's messsages, but that
doesn't have to be before the deadline.

Thanks

   Brian Carpenter
   diffserv co-chair

---

From: "John Strassner" <[email-masked]>
Date: Sun, 9 Jul 2000 12:28:17 -0700

Comments inline.

regards,
John
----- Original Message -----
From: "Kathleen Nichols" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>; "'Andrew Smith'"
<[email-masked]>; <[email-masked]>
Sent: Friday, July 07, 2000 9:24 AM
Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

> used. They are not all the same, in fact:

??? IS-A is an object-oriented term, and means that a
subclass is a type of a superclass. Since the subclass and
superclass exist in the same hierarchy, of course they are
related. Furthermore, the subclass is built to refine the
behavior of its superclas. In other words, the subclass
exists because it is different than its superclass.

So I don't follow your above comment at all.

> > > > taxonomy, and how such a taxonomy could be used to
build
> > an

The "lumping" of them all into a single superclass is indeed
correct from an OO point-of-view, since they all work
together to implement different traffic conditioning. We
appear to be having a semantic argument - you can't
condition traffic until you can separate it into different
flows that are conditioned differently. "Lumping" them into
a common superclass captures this fact.

---

From: "John Strassner" <[email-masked]>
Date: Sun, 9 Jul 2000 12:43:31 -0700

I completely disagree with your analysis. First off, I
listed about 10 pages of problems with the current draft, so
I hardly think it is "perfect". Second, one of the problems
in the current model is that they need to link up different
elements to identify how each of the elements (classifiers,
markers, etc.) work together to provide different types of
conditioning for each type of traffic.

The solution proposed in the draft is to use a TCB. Again,
please refer to my three long emails defining problems with
the TCB. Plus, since it is just a black box with a single
input and output, tell me how it can relate the different
instances that you define below together?

Obviously, it can't. So by making a common superclass with
common attributes and relationships, you solve this problem.
For example, if we define an attribue TrafficClass, then
this can be used as a selector to link the different
elements together. And it IS a common property (which by the
way the TCB doesn't have).

So before you pass judgment and lecture me on OO design
practices, please point out specific problems with the
approach, other than saying that it isn't possible with no
reason. As an example, you state:

  >To derive a Queue, a classifier, a meter and a
  >dropper from the same base action class, though
  >possible in syntax, is actually a very inelegant
  >OO design.

First point, I never said that they were derived from the
same base action class. Secondly, we've all agreed that in
general, to condition traffic, we need one or more instances
of each of these classes (plus others you didn't list) and
need to specify how they are inter-connected. The model
fails in doing this. However, if we have an OO model, with
all of these derived from a common superclass, then we can
define a single, common relationship that can relate any
subclass to any other subclass.

This is a simple, elegant design.

John
----- Original Message -----
From: "Brijesh Kumar" <[email-masked]>
To: "'Kathleen Nichols'" <[email-masked]>; "'John
Strassner'" <[email-masked]>
Cc: "'Andrew Smith'" <[email-masked]>;
<[email-masked]>
Sent: Friday, July 07, 2000 11:53 AM
Subject: RE: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

---

From: "John Strassner" <[email-masked]>
Date: Sun, 9 Jul 2000 12:51:31 -0700

Really? If it was perfect, then I wouldn't have written 10
pages of comments.

I really don't think that we're done here.

John
----- Original Message -----
From: "Kathleen Nichols" <[email-masked]>
To: <[email-masked]>
Cc: "'John Strassner'" <[email-masked]>; "'Andrew
Smith'" <[email-masked]>; <[email-masked]>
Sent: Friday, July 07, 2000 1:50 PM
Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

---

From: "John Strassner" <[email-masked]>
Date: Sun, 9 Jul 2000 13:00:07 -0700

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 07, 2000 9:41 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> the connections which is are configuration specific.

<js>
EXACTLY my point, so why didn't you complain because the
conceptual model draft takes great pains NOT to specify an
order.

The OO model defines a common base class that defines a
relationship between any of its subclasses (classifier,
meter, marker, dropper, queue). This relationship has
properties that enable one to identify the particular
subclasses that are connected.
</js>

>     ... according to the properties of the packets!

<js> Not necessarily. The current queue depth has nothing to
do with the properties of the packet.
</js>

>   Do you propose that the information model must now model
all possible

<js>
See above. One of the problems in the conceptual model is
that it specifically doesn't say how its building blocks are
inter-connected, or what can go in what order (e.g.,
starting the TCB with an absolute dropper would be an
unfortunate, but legal, thing to do). This model is trying
to fix that.
</js>

>   Tell me, what concrete piece of data would be
represented by the superclass?

Two examples are as follows. The superclass defines (for
example) an Enable property that enables the subclass to be
present or not present in the model, but still part of a
canonical form (kind of what the conceptual model was trying
to do with its null action concept, but in a more general
way). It defines a relationship, inherited by all
subclasses, that enables two subclasses (same or different
instances) to be connected together according to a number of
criteria.

---

From: Andrew Smith <[email-masked]>
Date: Sun, 09 Jul 2000 23:28:33 -0700

John,

Thanks for that "heart-to-heart" (HTH) message :-)

The draft in question is then purely an "information model" with no pretence
of offering optimal implementation. Which makes me wonder why you are
getting all hung-up in your other messages about "efficiency" and what
"worked better".  I really think you need to sit down with Fred, Steve,
Yoram, Kwok and Dan (perhaps with Brian'n'Kathie present to offer
simultaneous translation and binding arbitration services) at IETF and
figure out what's wrong - we're certainly talking past each other in that
other thread (e.g. to me a "traffic class" has all sorts of implications,
none of which match up with your proposed use of it to describe TCB-like
things).

Andrew

----- Original Message -----
From: "John Strassner" <[email-masked]>
To: "Andrew Smith" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 08, 2000 3:36 PM
Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1
of 2

---

From: "Brijesh Kumar" <[email-masked]>
Date: Mon, 10 Jul 2000 11:00:07 -0400

John Strassner writes;

> way the TCB doesn't have).

Hi John,

Thanks for nicely explaining your model and viewpoints. It is now lot
easier to understand your concerns with the current draft.

> This is a simple, elegant design.

Ok! I see what you mean.
I shall leave it for the authors of the draft to address the issues
raised in your mail.

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Dave Hotlosz <[email-masked]>
Date: Mon, 10 Jul 2000 08:40:52 -0700

Hi,
This maybe beyond the scope of this WG but it is a real issue. Many
venders now support multiple NICs on the same network using the  same ip
address and same MAC addresses for each interface.This gives you  a much
higher transmit rate than receive rate in the current implimentations.

Load and balancing determines which physical interface the data goes
out. So the question is should the Shaping and ingress policing be done
for the load balancing module or on the per physical interface?

Will the diffserve model take into account the case where a interface
has a transmitt rate greater than 2 times the receive rate? Or as far as
diffserve is concerned this is not a problem.

Excuse me if I'm way off base here I just wanted to express one concern
I have in implimenting diffserve.

Also I'd prefer to see ingress and egress nodes defined in a seperate
document as thier actions are clearly different from DS boundry and
interior nodes.

Thanks,
    Dave Hotlosz

---

From: "John Strassner" <[email-masked]>
Date: Mon, 10 Jul 2000 09:55:21 -0700

Hi Andrew,

I'd be happy to sit down with any and all at the IETF, I'll
be in Sunday morning.

Hopefully, we are crossing tracks on semantics (once the
technical inconsistencies have been solved, and I reiterate
that having identified them in my previous message, I am
happy to help fix them if you and/or the authors want me
to).

I don't believe, however, that I have mentioned
"efficiency". "Works better" is related to us talking past
each other w.r.t. what a "model" is (and no, please don't
remove the word ;-) ). Related to that, Andrea is moving
forward as the lead editor in the new Polterm draft, which
should also help a bit.

My main concern was in the perception that this was an
implementation guide, which the words imply but your's,
Brian's, and others' words don't imply, so that will help a
lot too.

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 09, 2000 11:28 PM
Subject: Re: [Diffserv] Comments on the TCB of the

> Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1
> > > Can you think of a better word than "Action" then? It
is
> > really just a label for
> > > a chapter of the document - there's no implication in
the
> > text that an Action
> > > Also, for the benefit of those on this list who
haven't
> > waded through the Policy
> > > WG mail-list-morass, could you please explain in words
of
> > one syllable or less,
> > > > want you to change the modeling [sic] ;-) word.
Rather,
> > what
> > > > taken on the packet (whereas, for example, counters
are
> > not,
> > > > even though they are included in your action
category).
> > So I
build
> > > > traffic. The model as currently described implies
that
> > these
> > > > > descriptions of somewhat similar things into the
same
> > > > chapter of the document:
> > > > > things to do with pattern matching on fields
within
> > > > packets are in one chapter,
> > > > > You seem to have a very fixed idea of what
"modelling"
> > > > (sic) means - maybe you'd
> > > > > I got this from several hall discussions. So if
this
> > isn't
> > > > > > I don't know where you get the idea that "number
of
> > > > inputs
> > > > > and outputs" is
> > > > > > the fundemental taxonomy of the components of
this

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2000 14:26:32 -0500

Dave,

Diffserv is blind this issue because it is a one-way definition, i.e.
there is no relationship between outbound and inbound traffic on the
same interface. 

I can't see any reason why the router that is doing the inbound
load sharing shouldn't use the DSCP to assist it in doing the load
sharing, but that is a localised issue so I don't think it needs
standards work.

I'm not sure what you mean by ingress and egress nodes. Boundary routers
are the ingress and egress nodes for DS domains. Do you by any chance
mean traffic sources and destinations?

  Brian

---

From: "Brijesh Kumar" <[email-masked]>
Date: Mon, 10 Jul 2000 17:06:22 -0400

Dave Hotlosz wrote:

> From: [email-masked]

> for the load balancing module or on the per physical interface?

Hi Dave,

Because two physical interfaces are being treated as one logical
interface, I would think that ingress policing should be done at the
load balancing level. This will ensure that the traffic conforms to
the defined rate irrespective of actual physical interface it comes
from.  The location for traffic shaping depends on where you do your
egress queueing. If a common egress queue is maintained for both
interfaces, then it is to be done at the load balancing level.
However, if both physical interfaces maintain their separate egress
queues then, I think, traffic shaping should be done at per physical
interface level. In this case egress queueing on each card is no
different than on a system with a single physical interface.

> diffserve is concerned this is not a problem.

It is a matter of defining SLAs so that suitable parameters are set
correctly. IMHO, the Diff-serve model shouldn't be affected by actual
realization of physical interfaces or asymmetrical nature of
interfaces (well, ADSL interfaces are the same too).

> document as thier actions are clearly different from DS boundry and

I don't think you need that as the model doesn't say that each node or
each interface will implement all Diff-Serve components. So you can
pick and choose what to implement and where.

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Dave Hotlosz <[email-masked]>
Date: Mon, 10 Jul 2000 15:10:56 -0700

Hi,
Thanks for the answers to my previous questions. Thats was what I thought
also.

But I have found no reference to jumbo frame support. Will this be
unsupported and  there will be only standard frame DS domains and no
jumbo frame DS domains? Or will there be both jumbo and standard frame DS
domains or one type of DS domain to support both.

I haven't looked but are jumbo frames defined in PHB or PDB? Or are jumbo
frames now planned to be supported by all routers by default.

I know not all routers currently support jumbo frames . I'm just trying
to figure out if DS is taking jumbo frames into consideration at this
time. It makes sense as the quickest way to transfer data is with larger
frame sizes.

I know for tcp based traffic mixing jumbo/standard frames are no problems
as the window sizes are negotiated. But for udp traffic mixing jumbo and
standard frames does not work.

Any consideration of jumbo frames and DS domains at this time?

Thanks,
    Dave Hotlosz

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2000 10:22:24 -0500

Please define jumbo frame. Apart from the fact that diffserv is allergic
to fragmentation, I don't see why there would be any special issues.

   Brian

---

From: Dave Hotlosz <[email-masked]>
Date: Tue, 11 Jul 2000 08:55:30 -0700

JUmbo frames are simply ethernet MTU sizes of 9k. Some switches currently
support jumbo frames (alteon, extreme and others). My main concern is if DS
switches will support jumbo frames as a requirement. This maynot be a issue as
more and more switches now offer jumbo frame support.

The problem would be if a DS domain had a mixture of switches in which not all
switches jsupport jumbo frames.

Again this maynot be a issue but larger MTU sizes (jumbo frames) are becoming
very common and in the near future smaller MTU sizes 1500 will become less and
less common. TCP will negotiate MTU frame sizes so that is not a problem. UDP
will not and that will cause problems.

Thanks,
    Dave Hotlosz

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2000 15:36:32 -0500

Well, the same issue would apply to IPv6 jumbograms except that in IPv6 we
have forbidden en route fragmentation by construct. That's why I wanted 
to be sure what you meant.

I don't think the diffserv standard can forbid IPv4 fragmentation; however
the architecture does make it clear that fragmentation breaks diffserv
because it makes multi-field classification impossible in the general
case. But you wouldn't want your packets fragmented even without
diffserv, which is what MTU discovery is for. I see it as an SLA issue,
not something the IETF can define.

  Brian

---

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

John,

1. You mentioned "efficiency" in your message sent Thursday, July 06, 2000 10:58
AM (enclosed). I guess you meant efficieny of words typed or characters in the
draft or something.

2. I loook forward to seeing Andrea's definition of "model".

3. I am struggling to find where in the -03 model draft you think implies that
it is an implementation guide - please clarify. If there is nowhere then I guess
that removes your main concern with the draft.

Meanwhile, an updated draft has to be submitted - I hope it will address some of
your concerns but I'm not optimistic that it will solve all.

Andrew

Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2
From: John Strassner
To: Andrew Smith; Brian E Carpenter
Cc: [email-masked]
Date: Sat, 8 Jul 2000 21:09:52 -0800

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2000 10:58 AM
Subject: Re: [Diffserv] Comments on the TCB of the

the
located
patterns
functional
we

model
happens

I would
concept.

---

From: "John Strassner" <[email-masked]>
Date: Thu, 13 Jul 2000 07:14:35 -0700

Comments inline.

regards,
John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>; "Fred Baker" <[email-masked]>
Sent: Thursday, July 13, 2000 12:31 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> AM (enclosed). I guess you meant efficieny of words typed
or characters in the

Thanks for finding this. The full quote was:

"Again, a key point to note is that we defined a single
attribute as the index that you are looking for, instead of
having to use the entire concept of the TCB. This worked
better, and was much more efficient."

So efficiency here doesn't have to do with how easily
characters are typed; rather, it meant that the use of the
TrafficClass attribute was a more efficient way of defining
the index that you were looking for instead of trying to use
the entire concept of the TCB, which doesn't have such an
index. If that really is at the risk of being confused with
how easily characters can be typed please let me know and
I'll rewrite my comments. ;-(

> that removes your main concern with the draft.

I've stated this several times, here is (again) the primary
quote that worries me (from the abstract):

"This model serves as the rationale for the design of an
SNMP MIB [DSMIB] and for other configuration interfaces
(e.g.  [DSPIB]): these should all be based upon and
consistent with this model."

If phrases like "...serves as the rationale for the
design..." and "...based upon and consistent with this
model" is not a guide to implementation, what do they mean?
Again, I would be happy if you simply deleted this entire
sentence.

> > > of offering optimal implementation. Which makes me
wonder
> > why you are
> > > "worked better".  I really think you need to sit down
with
> > Fred, Steve,
> > > Yoram, Kwok and Dan (perhaps with Brian'n'Kathie
present
> > to offer
> > > simultaneous translation and binding arbitration
services)
> > at IETF and
> > > other thread (e.g. to me a "traffic class" has all
sorts
> > of implications,
> > > > I know you meant it in a kind way, but the policy
group
> > does
> > > > reason why I'm being very anal-retentive about the
words
> > in
> > > > characteristics of a set of objects in terms
appropriate
> > > > specific context in mind that is a function of at
least
> > the
> > > > type of data store that contains the data and the
type
> > > > about an information model, we are "just" talking
about
> > data
> > > > > element actually does something to change packets
that
> > > > pass through it.
> > > > > the difference between a data model and an
information
> > > > model?
> > > > >
> > > > > Andrew
> > > > >
> > > > >
> > > > > John Strassner wrote:
> > > > > >
> > > > > > Hi Andrew,
> > > > > >
> > > > > > I don't want you to rearrange the document. I
don't
> > even
> > > > > > I was trying to understand was the taxonomy used
to
> > > > develop
> > > > > > the model.
> > > > > >
> > > > > > Here's the root of the problem. Your four
categories
> > are
> > > > > > classification, metering, actions, and queuing.
What
> > > > first
> > > > > > confused me was the "action" category.
Classifiers,
> > > > meters,
> > > > > > markers, droppers, and queues all are "actions"
that
> > > > > > information model as well as a data model. Using
an
> > OO
> > > > > > approach, I would have preferred to see
classifiers,
> > > > meters,
> > > > > > markers, droppers, and queues all as subclasses
of a
> > > > more
> > > > > > > are in another, things to do with pulling
packets
> > out
> > > > > > > that would help you read and understand it,
but I
> > fail
> > > > > > > true, then what is the rationale for
separating
> > > > elements
> > > > > > > since all of them, from a modeling
point-of-view,
> > > > provide

---

From: Andrew Smith <[email-masked]>
Date: Thu, 13 Jul 2000 10:06:14 -0700

1. I don't see how "efficiency" can be applied to an "information model" (by
your definition). These don't, by definition, have indices.

3. OK - by "implementation" I thought you were talking about "this is how to
implement a router" kinds of things. So I think you are talking about
"implementation of a data model": in that case, yes, it is supposed to guide 
you in how to do that. What's wrong with that? How else are you going to
implement data models? Is everyone else going to do it their own way?

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jul 2000 13:10:36 -0500

> implement data models? Is everyone else going to do it their own way?

I think the correct word for the MIB, the PIB and any other data definitions
is "specification", not "implementation". The model is not intended to be
a rigid guide to product designers. It is however intended that data 
definitions should be specified consistently with it. But the model does
not purport to be mathematically complete mathematically self-consistent,
and it's informational in nature. So we can't demand a mathematical
degree of consistency between the data definitions and the model - it's
just strong guidance.

   Brian

---

From: "Andrea Westerinen" <[email-masked]>
Date: Thu, 13 Jul 2000 11:57:30 -0700

To jump in this thread, since PolTerm definitions are referenced (I love
spontaneous publicity :-) ....

I would like to be clear that PolTerm is defining "information model" and
"data model".  Here are the current terms:
$ information model
An abstraction and representation of the entities in a managed environment,
their properties, attributes and operations, and the way that they relate to
each other. It is independent of any specific repository, application,
protocol, or platform.
$ data model
A mapping of the contents of an information model into a form that is
specific to a particular type of data store or repository.  A "data model"
is basically the rendering of an information model according to a specific
set of mechanisms for representing, organizing, storing and handling data.
It has three parts [DecSupp]:
-	A collection of data structures such as lists, tables, relations, etc.
-	A collection of operations that can be applied to the structures such as
retrieval, update, summation, etc.
-	A collection of integrity rules that define the legal states (set of
values) or changes of state (operations on values).
(See also "information model.")

We are not defining "model" since that is a very overloaded term and not
directly applicable to policy.

I would agree with John that the "Conceptual Model" is not an "information
model" in that it does not detail specific properties, associations, etc.
It does discuss concepts - of which a TCB is a concept.  However, since TCB
was not previously modeled (until MIB -04, I am told), one might ask whether
it is a "good" concept.  But that is a different question.  Typically, in OO
design, your nouns (concepts) equate to classes.

WRT "efficiency" and "info models", I would say that these terms are
related.  "Efficiency" implies fewer/more intuitive classes and properties,
rather than "processing efficiency".  The point about TrafficClass as an
"index" is related to TrafficClass as a valid property in an info model,
conveying a certain labeling/indexing semantic - not an "index" into an
"info model".  It seems that a property is more "efficient" than a new class
representing a TCB, to which other classes must be associated.

WRT "implementation" and "data models", as seen in the definition above, a
data model does dictate an implementation (i.e., a data store).  If there
are standards around this (for example, LDAP schema), then the
implementation is defined.  If not (sadly), people are free to do things
their own way, but should/must maintain the semantics of the information
model.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Andrew Smith
Sent: Thursday, July 13, 2000 10:06 AM
To: John Strassner
Cc: [email-masked]; Fred Baker
Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model -
msg 1 of 2

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jul 2000 14:59:59 -0500

Andrea,

Thanks for the clarifications. In turn let me repeat for the Nth time
that the diffserv conceptual model is not intended to be and never
claimed to be a formal information or OO model with mathematical
conformance requirements. 

  Brian

---

From: "Andrea Westerinen" <[email-masked]>
Date: Thu, 13 Jul 2000 14:27:08 -0700

I think that we are all agreeing.  However, I saw a comment from Andrew in
another mail sent on Sunday that said, "The draft in question is then purely
an "information model" with no pretence of offering optimal implementation."

So, that triggered my statement below.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Thursday, July 13, 2000 1:00 PM
To: Andrea Westerinen
Cc: Andrew Smith; John Strassner; [email-masked]; Fred Baker
Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model -
msg 1 of 2

Andrea,

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jul 2000 16:08:24 -0500

Well, one terminology trap here is that we hope to publish the
diffserv Conceptual Model as an Informational RFC - easy to
turn that into an Informational Model published as a
Conceptual RFC :-)

   Brian

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 13 Jul 2000 22:49:45 +0100 (BST)

> directly applicable to policy.

Call me a semantics quibbler, but if you can't define 'model', you
can't define 'information model' - and defining 'data model' in terms
of 'information model' is a cop-out of the first order.

I'd be ashamed of this intellectual cack-handedness.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Andrea Westerinen" <[email-masked]>
Date: Thu, 13 Jul 2000 15:04:47 -0700

Sorry, but I disagree.  An info model is a generic description of entities,
properties, relationships.  A data model is a tie to a specific data store -
data models are positioned this way in several text books, as well.  Not
tieing the two together would be less than correct since it leads to a bunch
of similar, but indistinguishable terms.

Saying we should define a "model" gives us a definition like Webster's ...

a structural design; a pattern of something to be made; an example for
imitation or emulation

So, we can certainly put this in the glossary, but it does not directly
relate to policy, nor does it add anything to the existing definitions.

Andrea

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Thursday, July 13, 2000 2:50 PM
To: Andrea Westerinen
Cc: Andrew Smith; John Strassner; [email-masked]; Fred Baker
Subject: RE: [Diffserv] Comments on the TCB of the Conceptual Model -
msg 1of 2

L.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jul 2000 16:46:52 -0500

Lloyd,

If you want to pursue that point, I think the policy WG would
be the place to do it, not diffserv.

   Brian

---

From: Andrew Smith <[email-masked]>
Date: Thu, 13 Jul 2000 21:41:18 -0700

Andrea,

Sorry, that was back when I thought John was referring to gates and lines of
code when he used the word "implementation". He's actually implementing at
several levels of abstraction above the rest of us. I certainly don't think
either of the words "efficient" or "optimal" could/should be applied to this
draft.

Andrew

---

From: "John Strassner" <[email-masked]>
Date: Fri, 14 Jul 2000 16:04:11 -0700

Why is this so hard?

Of course an information model can represent an index, it is
just an attribute with a specific set of semantics. And no,
I don't see how "my" definition of an information model
precludes defining an attribute as an index. Please explain.

In addition, the second connotation was that if all you were
trying to do was to implement an index, it is much easier to
implement that index using a single attribute as opposed to
an amorphous blob like the TCB. This leads to a more
efficient implementation.

With regard to point #3, what I have said repeatedly is that
if the conceptual model is supposed to guide the
implementation of a data model (your words this time), then
that clearly means that concepts central to the conceptual
model should appear in the implementation. And the point
that I was making is that the PIB, MIB, and policy model, so
far, did not include many of those central concepts, such as
the TCB.

So again, I was asking you to remove (or at least make a
less forceful statement) about the conceptual model being
used to guide the implementation of a data model.

John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: <[email-masked]>; "Fred Baker" <[email-masked]>
Sent: Thursday, July 13, 2000 10:06 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> > > AM (enclosed). I guess you meant efficieny of words
typed
> > > 3. I am struggling to find where in the -03 model
draft
> > you think implies that
> > > it is an implementation guide - please clarify. If
there
> > is nowhere then I guess
> > > Meanwhile, an updated draft has to be submitted - I
hope
> > it will address some of
> > > your concerns but I'm not optimistic that it will
solve
> > all.

---

From: "John Strassner" <[email-masked]>
Date: Fri, 14 Jul 2000 18:38:41 -0700

Hi Brian,

thanks for your message, this is a critical point that I've
been trying to get across, and I appreciate your response.

regards,
John

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Andrew Smith" <[email-masked]>
Cc: "John Strassner" <[email-masked]>; <[email-masked]>;
"Fred Baker" <[email-masked]>
Sent: Thursday, July 13, 2000 11:10 AM
Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

typed
draft
there
an
hope
solve

---

From: "John Strassner" <[email-masked]>
Date: Sun, 16 Jul 2000 05:18:26 -0700

Huh? One doesn't implement an information model, as it is
not bound to any specific repository. As previously stated,
specific data models that are bound to specific data stores
are derived from an information model.

And I'm not necessarily implementing at several layers of
abstraction about you - an information model can describe
low-level data too. It just tries to describe it in a
common, as opposed to data store-specific, way.

John
----- Original Message -----
From: "Andrew Smith" <[email-masked]>
To: "Andrea Westerinen" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2000 9:41 PM
Subject: Re: [Diffserv] Comments on the TCB of the

> > From: [email-masked]
[mailto:[email-masked]]On Behalf
> > Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model -
> > > An abstraction and representation of the entities in a
managed
> > environment,
> > > their properties, attributes and operations, and the
way that they relate
> > > -       A collection of data structures such as lists,
tables, relations,
> > etc.
> > > -       A collection of operations that can be applied
to the structures
> > such as
> > > -       A collection of integrity rules that define
the legal states (set
> > > It does discuss concepts - of which a TCB is a
concept.  However, since
> > TCB
> > > was not previously modeled (until MIB -04, I am told),
one might ask
> > whether
> > > it is a "good" concept.  But that is a different
question.  Typically, in
> > > related.  "Efficiency" implies fewer/more intuitive
classes and
> > properties,
> > > "info model".  It seems that a property is more
"efficient" than a new
> > class
> > > From: [email-masked]
[mailto:[email-masked]]On Behalf
> > > Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model -
> > > msg 1 of 2
> > >
> > > 1. I don't see how "efficiency" can be applied to an
"information model"
> > (by
> > > 3. OK - by "implementation" I thought you were talking
about "this is how
> > > "implementation of a data model": in that case, yes,
it is supposed to
> > guide
> > > > > AM (enclosed). I guess you meant efficieny of
words typed
> > > > > 2. I loook forward to seeing Andrea's definition
of
> > > > "model".
draft
there
> > > > > Meanwhile, an updated draft has to be submitted -
I hope
solve