Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe technica l meeting, 1/24/01 - 1/26/01)

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 16 Feb 2001 15:40:36 -0500

John,

Thanks for the comments. Additional clarifications follow inline:

John, 

I am confused by the following statements: 

> What the real problem is that QPIM has 
> introduced several 
> notions that are completely lacking in QDDIM: 
> 
>    - constraining the values of a variable or constant 
Doesn't an information model explicitly constrain the allowable values of an
attribute? 

<js>
No. What I'm talking about here is the ability to specify and model
constraints. Saying that an attribute is a uint8 explicitly constrains the
legal range of values that the attribute can take. What I'm looking at is in
addition, constraining the allowable range of values that an attribute can
have for a particular application (e.g., 0-63 instead of 0-127), attaching
special semantics to certain values (as is commonly done in MIBs), and
defining special relationships between a value of an attribute and something
else. OCL would be the easiest (though possibly not the most efficient) way
to do this with our model.
</js>
<ww>
Are you really suggesting dynamic bindings of constraints on attribute? On
my last reading of QPIM, I did not see semantics for this. Is this a new
feature? Can you give an example of how it is specified?
</ww>

>    - constraining the data types of a variable or constant 
Can you explain what you mean here? Are you refering to the semantics of
variables within an expression? If so, isn't this more a function of the
language semantics for the expression of variables (ie. Perl notion of a
variable is somewhat different from C).

<js> See above </js>

>    - binding a variable to a value 
Isn't this also a language semantic? 

<js>
No. For example, in QPIM we may be dealing with an IPAddress, and want to
restrict the values of said variable to just IPv4 addresses that are in CIDR
format.
</js>
<ww>
Does binding refer to an assignment or a dynamic constraint on allowable
values of the variable? In my comment I was assuming the former.
</ww>

It seems to me that QDDIM fits rather nicely into an expression based
language. If we consider a QDDIM object as a structured data type, it maps
rather well. The ultimate question with respect to variables is where the
base variables are defined. Do we use QDDIM or a derivative or do we define
a whole new set of variables that duplicates all the semantics described in
QDDIM?

If we start from scratch, the most convenient approach is to create a list
of possible variables. However, as the list grows longer, organizing the
attributes is inevitable. A good parallel would be Fortran with flat
attributes, C with structures, and Java with classes. Since experience tells
us that structure is inevitable, we may as well define the structures now.
If we do, we have come full circle back to where QDDIM is now.

<js> Sorry, you lost me here. Can you please elaborate? </js>
<ww>
The set of attributes defined as "variables" in QPIM is a subset of a much
larger number of variables that would facilitate the configuration of
network devices. In fact, I would be hard pressed to find an attribute in
QDDIM that would not eventually end up in this list of "variables". That is
just in the QoS space. When we add security, admission control, traffic
engineering, and user identity, the size of this list explodes. Further,
because the list is flat, the interactions between different variables,
reusability, semantic consistency, interrelationships to "extension"
variables also increased the complexity. These are the classic arguements
for why structures are important. This inevitably leads to questions of
scoping which migrates structured variables to classes. Once you have
decided to manage variables within the context of classes, you have QDDIM :)
</ww>

regards, 

-Walter

---

From: John Strassner <[email-masked]>
Date: Sat, 17 Feb 2001 14:08:31 -0800

Please see inline, look for <js2>..</js2>.

regards,
John

At 03:40 PM 2/16/2001 -0500, Weiss, Walter wrote:

>Doesn't an information model explicitly constrain the allowable values of 
>an attribute?
>
><js>
>legal range of values that the attribute can take. What I'm looking at is 
>in addition, constraining the allowable range of values that an attribute 
>can have for a particular application (e.g., 0-63 instead of 0-127), 
>attaching special semantics to certain values (as is commonly done in 
>MIBs), and defining special relationships between a value of an attribute 
>and something else. OCL would be the easiest (though possibly not the most 
>efficient) way to do this with our model.
>
></js>
><ww>

<js2>
You're reading too much into what I said. I never used the word "dynamic". 
I simply said that there are additional constraints that one can impose on 
an attribute. Restricting the range of a uint8 to 0..63 is one such example.
</js2>

>restrict the values of said variable to just IPv4 addresses that are in 
>CIDR format.
>
></js>
><ww>

<js2>
Not sure why you're hung up on dynamic entries. I never said the word dynamic.
</js2>

> language. If we consider a QDDIM object as a structured data type, it 
> maps rather well. The ultimate question with respect to variables is 
> where the base variables are defined. Do we use QDDIM or a derivative or 
> do we define a whole new set of variables that duplicates all the 
> semantics described in QDDIM?
>
>attributes, C with structures, and Java with classes. Since experience 
>tells us that structure is inevitable, we may as well define the 
>structures now. If we do, we have come full circle back to where QDDIM is now.
>
>QDDIM that would not eventually end up in this list of "variables". That 
>is just in the QoS space. When we add security, admission control, traffic 

<js2>
I see no requirement to force people to represent variables or not. 
Furthermore, if they want to represent variables, then this wg has given 
them two different means to accomplish the same task. They can use a 
class-based approach, as in QDDIM, or they can use a finer-grained 
approach, as in QPIM. We should not dictate which representation people 
choose, but it is application-specific.
</js2>