[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Requirements Modifications - Trying Again



I originally sent this to the mailing list on Sunday, but it bounced back
because I didn't use the email address from which I had subscribed to the
mailing list...trying again.

Jamie

I would like to add some more motivation/rationale behind a couple of the
requirements.

#14 - Instance Pointer
It is common when data modeling to reference another object instead of
embedding the referenced object inside of the object doing the referencing.
This is also important as it allows objects to have independent lifetimes as
well as be referenced by many objects.

#33 - Classes
I agree with the motivation - I think it is a good thing to be able to group
attributes together for reuse.  However, I am wondering if the name classes
can be changed to something more generic.  I don't know of "structures" are
any better, but I would like to see a different description.

#34 - Single Inheritance
I see this important because as more WGs move to data modeling, it is
natural to model using OO methodologies.  For example, in the IPsec Policy
WG we are modeling the IPsec configuration policy
(draft-ietf-ipsp-config-policy-model-02.txt), which derives from the Policy
Core Information Model from the Policy Framework WG.  Both are modeled using
OO methodolgy and make extensive use of single inheritance.  In addition to
the abstract model, the WG is defining a PIB
(draft-ietf-ipsp-ipsecpib-02.txt) and a MIB
(draft-ietf-ipsp-ipsec-conf-mib-00.txt) as concrete instantiations of the
abstract model.

#35 - Abstract vs. Concrete Classes
When doing data modeling us OO methodologies, it is important to be able to
define an abstract class, which contains some set of attributes common to
all derived classes, but which is never meant to be instantiated by itself.
Again, an example is the IPsec policy configuration model - in that model,
we have the idea of an IPsec transform.  There are current three transforms
in the model - AH, ESP, and IPCOMP.  All three share a set of attributes.
Instead of repeating the definitions of these attributes in each derived
class, the attributes are defined in an abstract base class and all three
derive from the abstract base class.

#2 - Human Readability
One thing I have noticed reading the IPsec PIB and MIB documents is that the
semantics of the model being presented are easily lost.  The reason this is
important to me is as a co-author on the IPsec policy model, I want to make
sure that the PIB and MIB are semantically equivalent to the policy model so
that they represent the same information.  Parsing through the SMI and SPPI
to understand the semantics of the particular derivation for me is
excruciatingly painful.  I think that a language that is more akin to C
would make that human parsing of the PIB/MIB much easier.  As it stands now,
I am relegated to drawing pictures of the tables in order to understand what
is going on.

Jamie Jason
Intel Architecture Labs
jamie.jason@intel.com


----------------------------------------------------------------
Jamie Jason                       email: jamie.jason@intel.com
Intel Architecture Labs           phone: 503-264-9531
2111 NE 25th Avenue               fax:   503-264-9428
Hillsboro, OR 97124
                          
"To give anything less than your best is to sacrifice the gift."
 - Steve Prefontaine

All opinions expressed are:
1.  Entirely my own.
2.  Not necessarily shared by my employer.
3.  Unencumbered by the thought process.
----------------------------------------------------------------