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

From: "John Strassner" <[email-masked]>
Date: Sat, 1 Jul 2000 12:19:22 -0700

I think the fundamental problem that I have with this draft
is that when it says "Model", I keep expecting to see a
generic diagram that shows how the different functional
elements described in the draft can fit together to perform
higher-level functions. Although there are some examples
that show how some functions can be implemented, there is
no generic model to use as a design guide. I believe that
this needs to be added before the draft can go to Last
Call.

Perhaps the solution to this is to combine this draft with
the generic model in the soon-to-be-released QoS Device info
model draft. I'd certainly be willing to help in this
regard, and so would my co-authors.

As to your request, here are detailed comments (keeping this
major problem of mine in line) on all sections up to section
8 (not including the TCB-specific feedback I've given
earlier). I'll try and finish a review of the remaining
sections, but I think that there is quite a lot of issues
that need to be dealt with. I suggest that this draft is not
ready for a Last Call just yet.

I would like to know if this new version of the draft will
incorporate my previous feedback on the TCB-ectomy? I've
seen no response at all...

...but as requested, here are some more issues:

Global mis-spellings:

  multiplexor should be multiplexer
  modelling, modelled, etc should be modeling, modeled, etc.

Abstract, pg 1
--------------
In the sentence that starts:

  "This model defines the general functional datapath..."

Comments:
There are three points to be raised:

  1) "general functional" is an odd phrase. I would
     suggest eliminating "general".
  2) multiplexOr is mis-spelled, it should be multiplexer.
  3) the document sometimes uses the phrase "monitor" and
     sometimes uses the phrase "counter". Please pick one
     and use it consistently.

Glossary, pgs 3 and 4:
----------------------
The definitions of classifier and filter don't agree.

The definition of a Classifier is:
  A functional datapath element which consists of
  filters which select packets based on the content
  of packet headers or other packet data...

The definition of a Filter is:
  A set of wildcard, prefix, masked, range and/or
  exact match conditions on the components of a
  packet's classification key.

I would suggest that you change "on the components of a
packet's classification key" in the definition of a filter
to "that operate on either the content of packet headers or
other derived packet data", and also insert "derived"
between "other" and "packet" in the definition of a
Classifier.

Glossary, page 4
----------------
I object to the term "Queuing Block". The queuing block that
you are describing is made up of several elements, including
one or more queues, one or more droppers, and some decision
logic that decides whether to store-and-forward or drop.

I think that the Queuing Block should be separated into its
constituent components.

Glossary, page 4
----------------
I find it odd that you define shaping but not policing. I
think you should add the following (or a better)
definition for policing (especially since you use the term
on page 21 and subsequently but never define it). Here's
a suggested start:

  "The process that limits a traffic flow to a configured
   bit rate."

Glossary, page 4
----------------
I'm a tad uncomfortable with the definition of shaping. It's
not wrong, but it misses the point. The point of shaping is
to regulate traffic flow to an average or peak bit rate. You
imply that by saying "...conform to some defined traffic
profile" but never really specify what that means. I think
it would be better if you spelled out explicitly that
shaping means regulating the traffic flow.

Section 3.1, page 5
-------------------
The draft says:

  "Traffic Conditioning (TC) actions of Marking, Absolute
   Dropping, Counting and Multiplexing."

Comments:
This begs everal questions:

  1) Why is algorithmic dropping excluded?
  2) Counting and Multiplexing aren't conditioning actions
  3) Why is queuing NOT a traffic conditioning action?
  4) Why is metering NOT a traffic conditioning action?
  5) Why is classification NOT a traffic conditioning
     action? (Note that the various figures that attempt
     to illustrate what a TCB is include queuing,
     classification, and metering as part of the Traffic
     Conditioning).

I would prefer that at least metering and queuing are deemed
part of traffic conditioning. I would be overjoyed if
classification was also considered part of queuing...

Section 3.1, page 5
-------------------
Further down, the draft says:

  "Queueing elements, including capabilities of algorithmic
   dropping."

Comments:
Why are algorithmic droppers buried within a queue? They can
certainly exist outside of a queue...

Section 3.1, page 5
-------------------
Further down, the draft says:

  "This model is in the form of a connected directed
   acyclic graph (DAG) ..."

Comments:
This works well for everything except the scheduler. The
scheduler controls elements. Thus, it is not on the data
path per se, but is rather on the control path.

Section 3.1.1, Datapath, pages 5-6
----------------------------------
The description of the routing core is problematic. In
general, the routing core has both a control plane as
well as a data plane. Thus, there is a fundamental
difference between system tasks (running routing
protocols, maintaining routing tables, maintaining
accounting counters, etc.) and packet operations
(switching and otherwise manipulating packets, rewriting
packet haeaders, generating and consuming packets, etc.).
The draft attempts to mush these two together, which is
incorrect.

It appears that what you are trying to describe as the
"routing core" is in reality just the datapath that is
shared between the different interfaces. Please rename
the term "routing core" to something like datapath
(which can itself take a number of different forms).

Section 3.1.1, page 6
---------------------
The draft says:

  "The components of interest on the ingress/egress
   interfaces are the traffic classifiers, traffic
   conditioning (TC) components, and the queueing
   components ..."

Comments:
So what happened to meters? You've consciously split
them out in previous and subsequent sections...

3.1.2. Configuration and Management Interface, pg 6
---------------------------------------------------
The last paragraph in this section says:

  "Specific policy objectives are presumed to be
   installed by or retrieved from policy management
   mechanisms. However, diffserv routers are subject
   to implementation decisions which form a meta-
   policy that scopes the kinds of policies which
   can be created."

Comments:
First, the term "policy objectives" is undefined. I have no
idea what you mean by this term. Plus, I would suggest that
you submit it to the Polterm group so that it can be defined
across multiple workgroups.

Second, you need to define the term "policy management
mechanisms". The same comment applies to it being submitted
to Polterm.

Third, I can't parse the last sentence at all. Note that
meta-policy means "policy describing a policy", so:

  1) how does this affect this draft
  2) what meta-policy are you talking about
  3) what policies are you describing that are
     controlled by the meta-policy

The easiest solution is, imho, to delete this entire
paragraph. Otherwise, you need to define these terms,
explain how they relate to this draft, and link up with
Polterm to ensure that they have a common definition that is
satisfactory to the multiple workgroups that will want to
use them.

Section 3.2, Hierarchical Model..., pg 7
----------------------------------------
The first sentence of this section again leaves out meters:

  "This document focuses on the Diffserv-specific components
   of the router: classification, traffic conditioning and
   queueing functions."

Comments:
Please add in metering, or better, redefine traffic
conditioning such that it includes metering, especially
since it re-appears three sentences later. I personally
wouldn't mind it including classification and queuing as
well, but that's another battle...

Section 3.2, pg 7:
------------------
The last sentence reads:

  "The TC functionality is implemented by a combination of
   classification, action, meter and queueing elements."

Comments:
First, this is contradictory with the above descriptions.
Second, it begs the question, if these are all parts of
traffic conditioning, why are they classified into different
stages? The object-oriented model of this functionality that
is in a soon-to-be-released version of the QoS Device model
defines a common class that classifiers, meters, markers,
droppers, and queues all subclass from.

The good news is that this fits the above (quoted) statement
from the model. The bad news is that throughout the draft,
an artificial differentiation between these elements is
emphasized. From a modeling point-of-view, these elements
all perform actions on the traffic, and should be treated as
equals.

Section 3.2, pg 8:
------------------
The draft continues:

  "...to perform four QoS control functions in the
   datapath on traffic in each direction:

  - Classify each message according to some set of rules.
  - If necessary, determine whether the data stream the
    message is part of is within or outside its rate by
    metering the stream.
  - Perform a set of resulting actions, including applying
    a drop policy appropriate to the classification and
    queue in question and perhaps additionally marking the
    traffic with a ...DSCP...
  - Enqueue the traffic for output in the appropriate
    queue, which may either shape the traffic or simply
    forward it with some minimum rate or maximum latency.

Comments:
I'd like to make the following points:

First, the first bullet item above clearly states that
classifiers should NOT be considered optional elements.
Common sense dictates this too. ;-)  Yet throughout the
draft, it is emphasized that each of the traffic
conditioning elements is optional. You need to make an
exception for classifiers.

Second, you very well might want to rate-limit the traffic
before it hits the classifier.

Third, classification and metering are certainly actions
from a modeling point-of-view. I don't understand why you
separate them from markers and droppers. And for that
matter, queues also perform an action, so I have the same
question.

Fourth, the queue may also drop traffic. Note that this
doesn't mean that I changed my mind and like "queuing block"
;-) I simply want the enumeration of ACTIONS (hint hint) to
be complete.

Section 4.1, Filters
--------------------
I found the discussion very good with one exception: the
discussion seemed to assume a single matching strategy
(match-first). To suite the goals called out in the
abstract, I would suggest that you add in a small discussion
of different matching strategies and how that affects what
is processed by the filters.

It would also be more complete to discuss the use of
cascading classifiers here, though you do give an example of
that later in the draft.

Section 4.1.2, Overlapping Filters, pg 12
-----------------------------------------
It's unclear why you discuss the problems involved in
overlapping filters and then say "it's beyond the scope of
this document".  I think you should either drop this
discussion or talk about it in more detail. In particular,
if you choose the latter, then you have the opportunity to
tie in management functions and policies with the data
forwarding. This could lead to a tighter link not just
between policies as defined in the Policy Framework, but
also specific data models (e.g., PIBs and MIBs).

Section 5, Meters, pg 14
------------------------
Note the repeated "is is" in the first sentence. Also, I
don't understand how a meter is going to be used for
statistics (the draft says):

  "Alternatively, it might also be used for out-of-band
   management functions like statistics monitoring for
  billing applications."

Section 5.1, pg 18
------------------
There is  discrepancy between the definition of Profile1 and
the text below its description. The definition of Profile1
defines the AverageRate as 120 kbps, but the text below it
refers to 12 kbits.

Section 5.5, pg 20
------------------
I'm confused as to why a Null Meter is defined, but no other
Null elements are defined in the draft. I think that
consistency is paramount here - either remove this
definition or add null element definitions for the other
elements.

Section 6, Action Elements, pg 20-21
------------------------------------
(Andrew, here is a specific reference which also leads me to
believe that number of inputs and outputs was one of the
means use to classify elements).

The draft says:

  "The classifiers and meters described up to this point are
   fan-out elements which are generally used to determine
   the appropriate action to apply to a packet. The set of
   possible actions include:

   -    Marking
   -    Absolute Dropping
   -    Multiplexing
   -    Counting
   -    Null action - do nothing"

Comments:
First, I don't understand why classifiers and meters are not
also considered actions. Second, I don't understand why
counting is considered an action, since it doesn't affect
the traffic stream. Third, I'm not sure what to call
multiplexing, but it seems fundamentally different than
classification, metering, marking, dropping, and queuing.
Finally, how can a null action be an action?

Section 6, pg 21
----------------
The draft says:

  "Shaping, sometimes considered as a TC action, is
   treated as a part of the queueing module in this
   model, as is the use of Algorithmic Dropping
   techniques - see section 7."

Comments:
From a modeling point-of-view, I don't think that it is a
good idea to bundle in functions that do not only exist
within another function. Implementations exist where shaping
and dropping is done separate from queuing, and therefore
shaping and dropping should not be hidden within a queue.
Furthermore, from a management point-of-view, bundling
shaping and dropping within queuing makes it harder to
separate the management of these functions from the
management of the queue itself. And since the queue doesn't
have to have either of these functions, the management of
the queue should not be tied to the management of these
other functions.

Section 6, pg 21
----------------
The draft continues:

  "Policing is modelled as the combination of either
   a meter or a scheduler with either an absolute
   dropper or an algorithmic dropper..."

Comments:
I don't agree with this definition. There are two different
problems:

First, the purpose of policing is to limit the traffic flow
to a configured bit rate. When you say "...meter or a
scheduler..." that is incorrect - a scheduler can not limit
a traffic flow.

Second, I'm confused why you say "...either an absolute
dropper or an algorithmic dropper". Presumably what you are
modeling is:

         +-----+
         |     |-->Conforming traffic is forwarded
         |     |
 input-->|Meter|   +-------+
         |     |-->|Dropper|
         +-----+   +-------+

So why would you use an algorithmic dropper if the purpose
is to limit the rate of the traffic?

Section 6.1, Marker, page 21
----------------------------
Markers are also parameterized by decision logic which
determines whether they are allowed to (re)mark a packet.
Please add this.

Section 6.2, Absolute Dropper, page 21
--------------------------------------
I don't think that a distinction should be made between an
absolute dropper and an algorithmic dropper. The former is
simply a degenerate case of the latter. And again, the
latter should not be hidden within a queue, which does not
need to have a dropper to function.

Please combine these into a single element.

Section 6.3, Multiplexer, pg 22
-------------------------------
I don't think that this should be classified as an action
element. The mux is not changing any traffic parameters, bit
in the header, etc. - it is simply combining multiple
traffic streams. It should be separated out into a different
category (perhaps combined with counters).

Section 6.4, Counter, pg 22
---------------------------
This is clearly not an action element, as it has nothing to
do with the data path. It should be separated out into a
different category (perhaps combined with counters).

Section 6.5, Null Action, pg 22
-------------------------------
I honestly don't see the purpose of this element. But, if
you really want to have it, then it should be consistently
modeled. This means that there should be a null meter and a
null queue, for example. I would make an exception for
classifiers - not having a classifier means you are dealing
with one flow, which is not interesting.

But I'd really rather see this removed.

Section 7, Queuing Blocks, pgs 22-23
------------------------------------
As previously stated, I do not think that it is a good idea
to bury different functional elements that can exist on
their own (e.g., a dropper) within a queuing block. I think
that a much cleaner model is to separate out the components
of what you are defining as a queuing block. Then, you can
differentiate between simple queues (that just stores and
forwards) and other, more complicated, structures.

The last four sentences make no sense to me. They are:

  "There is no conformance to this model. The model can be
   used to represent a broad variety of possible
   implementations. However, it need not necessarily map
   one-to-one with physical queueing systems in a specific
   router implementation. Implementors should map the
   configurable parameters of the implementation's
   queueing systems to these queueing block parameters as
   appropriate to achieve equivalent behaviors."

First, if there is "no conformance to this model", why is it
being presented in this draft?

Second, the remaining three sentences describe a giant loop
hole that implies that there may be a large divergence
between this model and a real implementation. But, the
abstract (pgs 1-2) says:

  "...intended to be abstract and capable of representing
   the configuration parameters important to Diffserv
   functionality for a variety of specific router
   implementations. It is not intended as a guide to
   hardware implementation.

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

These last three sentences on queuing do not meet the
requirements of the first quoted paragraph from the
abstract. Furthermore, the second quoted paragraph of the
abstract implies that the model should be specific enough to
"serve as the rational for the design of an SNMP MIB, etc.".
These four sentences from the description of the queuing
block clearly don't meet these requirements.

Therefore, I strongly suggest that this is symptomatic of
trying to combine too much functionality into a single
block. I aso strongly recommend that you abstract the
queuing block into a set of simpler components in order to
meet the goals of the abstract.

Section 7.1, Queueing Model, pg 23
----------------------------------
First, I disagree that functional decomposition has actually
been used. If it had, you wouldn't have had to waffle so
much in the preceding section as to whether it corresponded
to a physical implementation or not.

Second, there are typos in the following excerpt:

  "These elements which may be connected together either
   dynamically or statically to construct queueing
   blocks. A queueing block is thus composed of of..."

The problems are:

  1) remove "which" in the first sentence (unless you meant
     something else)
  2) "of" is repeated

Finally, the queuing block is defined as follows:

  "one or more FIFOs, one or more Schedulers and zero or
   more Algorithmic Droppers"

Why is the storage element limited to a FIFO?

Section 7.1.1, pg 24
--------------------
The draft says:

  "FIFOs in this model are modelled without inherent limits
   on their depth - obviously this does not reflect the
   reality of implementations: FIFO size limits are
   modelled here by an algorithmic dropper associated with
   the FIFO, typically at its input."

Again, isn't the purpose of the model to model reality? Why
is a FIFO being modeled this way?

The draft goes on to say:

  "It is quite likely that, every FIFO will be preceded by
   an algorithmic dropper. One exception might be the case
   where the packet stream has already been policed to a
   profile that can never exceed the scheduler bandwidth
   available at the FIFO's output - this would not need
   an algorithmic dropper at the input to the FIFO."

This is a great reason why an algorithmic dropper should NOT
be required to be part of a queuing block, and that th
queuing block should be separated into its constituent
components.

Section 7.1.1, pg 24
--------------------
I agree with the editorial comment that a FIFO should be
modeled as having a single input preceded by a mux if
necessary. Again, this gets you out of the problem of using
a definition that can not apply universally to all types of
FIFOs.

Section 7.1.1, pg 24
--------------------
The draft says:

  "Typically, the FIFO element of this model will be
   implemented as a FIFO data structure. However, this
   does not preclude implementations which are not
   strictly FIFO, in that they also support operations
   that remove or examine packets...other than at the
   head or tail."

Again, why is just a FIFO data structure identified as being
part of the queue? I think that you should have a more
general model, where you are modeling the ability to store
and forward packets. Either keep the actual implementation
unspecified, or define a range of different data structures
that could be used. I would vote for the latter, because the
draft does not depend on the type of data storage that is
being used.

Furthermore, it is unclear why you are describing more
complex relationships (e.g., multiple buffer pools, and
whether they can be shared among FIFOs or not). If you're
going to describe it, then it should be modeled, otherwise
the description should be truncated (e.g., why tlk about
buffer pools when the FIFO model doesn't mention them?).

Finally, the draft says:

  "Note that a FIFO must provide triggers and/or current
   state information to other elements upstream and
   downstream from it..."

I completely agree, but why isn't this modeled as part of
the diagrams that model either the queuing block?

Section 7.1.2, Scheduler, pg 25
-------------------------------
The draft says:

  "A scheduler is an element which gates the departure
   of each packet that arrives at one of its inputs,
   based on a service discipline."

Comments:
I disagree. The packets don't necessarily arrive at the
input of the scheduler. Rather, in the most general sense,
the scheduler is a set of decision logic that implements an
algorithm that services the queue. The packets in most cases
(all I can think of) arrive at the queue, not at the
scheduler.

This error permeates the rest of this section, so I won't
repeat my comments.

Section 7.1.3, Algorithmic Dropper, pg 27
-----------------------------------------
I don't like the side-effect model discussed in the second
paragraph, and think that it should be removed. Algorithmic
droppers should be treated as first-class entities, not as
side-effects.

And, the two descriptions are NOT equivalent. This is
because the former can also be used to describe a
stand-alone dropper, while the latter can only be used to
model a dropper embedded in another element.

Section 7.1.3. pg 27
--------------------
The third paragraph says:

  "...need...to relate information about which
   classifier element was matched by a packet from a
   Classifier to an Algorithmic Dropper. This is
   modelled here as a reverse pointer from one of the
   drop probability calculation algorithms inside the
   dropper to the classifier element that selects
   this algorithm."

This seems to violate the "four stages of processing" that
you refer to throughout the draft, in that the dropper is
NOT modeled as being connected directly to the classifier
(see Section 7.1.4, which doesn't include this as one of the
options in constructing a queuing block).

Another point: although I do agree that this relationship
may be needed, I also think that other elements need this
relationship. You may want to either look at or use the
model that we have developed in the new version of the QoS
Device Model I-D.

I specifically disagree with your statement that the use of
a "classification identifier" was more clumsy. This is
exactly what we used in the QoS Device Model I-D, and it
leads to a simpler and more powerful representation than the
scheme described in this draft. I say this because none of
your figures model this level of detail (in fact, curiously,
the applicable figures separate out the algorithmic dropper
from the queue) whereas the QoS Device Model I-D can model
that level of detail.

Section 7.1.3, pgs 29-30
------------------------

You refer to having to embed a classifier to achieve some
functionality. This should never be the case - the model
should have sufficient flexibility to represent whatever
discipline is required.

I'm also confused by this discussion, because all of the
figures in the examples (figures 5-7, 9, and 10) ALL show
the dropper as having a single input.

Therefore, I think that the discussion could be simplified
considerably by simply requiring that a dropper has one
input. Alternatively, if you don't want to do this, then
please add in an example into one of these figures where a
dropper has more than one input.

Section 7.1.4, pg 30
--------------------
The draft says:

  "A queueing block is constructed by concatenation of
   these elements so as to meet the meta-policy
   objectives of the implementation, subject to the
   grammar rules specified in this section."

Comments:
There's that magic word again, meta-policy. I have no idea
what this is referring to in this context, and would
appreciate a definition of the term and an explanation of
what this sentence means.

Section 7.1.4, pg 30
--------------------

The draft continues:

  "Typically, a queueing block will have relatively
   many elements in parallel and few in series."

I'm not sure I agree, could you elaborate on this? It seems
to me that even if there were multiple queues controlled by
a single scheduler, you still have multiple elements in
series. This may just be semantics...

The draft continues:

  "Iteration and recursion are not supported
   constructs in this grammar. "

I have not seen anything close to a grammar in this draft.
What is this statement trying to say, or should it just be
removed?

The draft continues:

  "A queueing block must have at least one FIFO, at
   least one dropper, and at least one scheduler."

This conflicts with the text in section 7.1, second
paragraph, pg 23, which reads:

  "A queueing block is thus composed of of one or
   more FIFOs, one or more Schedulers and zero or
   more Algorithmic Droppers."

Note the mismatch in dropper vs. Algorithmic Dropper and "at
least one dropper" vs. "zero or more Algorithmic Droppers".

The draft continues:

  "1) The input of a FIFO may be the input of the
      queueing block or it may be connected to the
      output of a dropper or to an output of a
      scheduler."

Sorry, but you're mixing up the data path with the control
path. The FIFO's data path is NOT connected to the
scheduler; rather, the scheduler tells the FIFO what to do.
This error is repeated in the second and fourth points
following the above quoted text.

The draft continues:

  "...schedulers may operate in series..."

I don't understand how this can be literally true. You're
tying two elements together whose purpose is to control data
path elements. Surely there is a data path element that is
between these. So, in your example, you would have
scheduler control a shaping function, the output of the
shaping function would then feed a different queue
controlled by a different scheduler. Specifically, the
schedulers would NOT talk directly to each other.

regards,
John

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: "Andrew Smith" <[email-masked]>;
<[email-masked]>
Sent: Thursday, June 29, 2000 12:53 PM
Subject: Re: [Diffserv] Comments on the TCB of the
Conceptual Model - msg 1 of 2

> John,
>
> Just to be clear: we are expecting to ship a new
> version of this draft within a few days, which will
> be Last Called for Informational. So if you have
> more comments, we need them soon. Very soon. You
> certainly can't proceed on the assumption that
> there will be much more time for comment on this
> document, which has been around for a long time
> and is well overdue already.
>
>   Brian
>
> John Strassner wrote:
> >
> > Brian,
> >
> > thanks, I agree. I won't send anymore comments on
> > the model draft until we can straighten out TCBs.
> >
> > regards,
> > John
> > ----- Original Message -----
> > From: "Brian E Carpenter" <[email-masked]>
> > To: "John Strassner" <[email-masked]>
> > Cc: "Andrew Smith" <[email-masked]>;
> > <[email-masked]>
> > Sent: Thursday, June 29, 2000 7:17 AM
> > Subject: Re: [Diffserv] Comments on the TCB of the
> > Conceptual Model - msg 1 of 2
> >
> > > John,
> > >
> > > I think the best thing is for the model authors
> > > to noodle to put together a considered response
> > > to your comments...this will clearly take more
> > > than a moment or two. But thanks very much for
> > > your detailed review.
> > >
> > >   Brian
> > >
> > > John Strassner wrote:
> > > >
> > > > 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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jul 2000 11:07:24 -0500

John,

> this needs to be added before the draft can go to Last

This is not the intention of the document. It is made very clear,
I think, that it is a loose model as a guideline for the MIB
and the PIB, and that it is non-normative and is not a specific
implementation guide. So the sense of the WG has certainly not 
been to move it in the direction you suggest. What I get from
your comment is that we need to strengthen the disclaimer to make
this even more explicit and unmistakable. 
> model draft. 

Since it is not intended to be a formal model, and is intended
to be at a significantly finer granularity than I believe
the policy model was expected to cover, frankly I don't see
this as a likely solution. 

   Brian

---

From: "John Strassner" <[email-masked]>
Date: Tue, 4 Jul 2000 11:00:29 -0700

Hi Brian, comments inline.

regards,
John
----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "John Strassner" <[email-masked]>
Cc: "Diff Serv" <[email-masked]>
Sent: Monday, July 03, 2000 9:07 AM
Subject: Re: [Diffserv] Comments on the TCB of the

> this even more explicit and unmistakable.

Well, the abstract of the draft says, and I quote:

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

This seems like pretty strong words to me that specifically
state that this document should be capable for use as the
design guideline for MIBs and PIBs.

If this is true, then I humbly submit that a picture is
worth a thousand words. Furthermore, this is supposed to be
a model, and if the model doesn't show how functions are
generically configured, it isn't a model.

> this as a likely solution.

If it isn't intended to be a formal model, why is it called
a model? No pun intended, but I fail to see the purpose of
this draft in this case.

As far as level of granularity, please read the QoS device
draft, I think you'll be a bit surprised here.