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

[Brian E Carpenter <[e-mail]>]

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

Andrea Westerinen wrote:
> 
> 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: [e-mail] [mailto:[e-mail]]On Behalf
> Of Brian E Carpenter
> Sent: Thursday, July 13, 2000 1:00 PM
> To: Andrea Westerinen
> Cc: Andrew Smith; John Strassner; [e-mail]; Fred Baker
> Subject: Re: [Diffserv] Comments on the TCB of the Conceptual Model -
> msg 1 of 2
> 
> 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
> 
> Andrea Westerinen wrote:
> >
> > 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: [e-mail] [mailto:[e-mail]]On Behalf
> > Of Andrew Smith
> > Sent: Thursday, July 13, 2000 10:06 AM
> > To: John Strassner
> > Cc: [e-mail]; Fred Baker
> > 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
> > 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
> >
> > John Strassner wrote:
> > >
> > > Comments inline.
> > >
> > > regards,
> > > John
> > > ----- Original Message -----
> > > From: "Andrew Smith" <[e-mail]>
> > > To: "John Strassner" <[e-mail]>
> > > Cc: <[e-mail]>; "Fred Baker" <[e-mail]>
> > > Sent: Thursday, July 13, 2000 12:31 AM
> > > Subject: Re: [Diffserv] Comments on the TCB of the
> > > Conceptual Model - msg 1 of 2
> > >
> > > > 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.
> > >
> > > 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. ;-(
> > >
> > > > 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.
> > >
> > > 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.
> > >
> > > > 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
> > > >
> > > >
> >
> > _______________________________________________
> > diffserv mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> > _______________________________________________
> > diffserv mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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