[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Methods in the NIM requirements
> I agree with Andrea's remarks. I am also not sure why you want to
> put rules on information modeling requirements document.
> If necessary we can give some high level guidance.
> But a lot of it has to be done on a case by case basis.
> Modeling is an art and as has been pointed out in many books
> often there are no right or wrong answers. The critical
> need is the model should support the requirements
> for the specific application.
I can take this one of two ways. One way to take this is to say that the
organization of information into structures and the relationships between
those structures and other structures is an art. This is true. That has been
the case with MIBs, Databases, Directory Schemas, and software
implementations in general.
If you are saying that the choice of when to use methods is an art, we have
a serious problem. This makes an already difficult problem much more
subjective. Striving for consistency in an environment of subjective
decisions is inherently contradictory.
> The example you have for Bandwidth scheduler has defined attributes.
> However, I think this was done assuming a specific protocol
> paradigm. I would like to start on what requirements
> the scheduler is to satisfy, what information has to be
> present to meet the requirements before
> making them all as attributes.
In point of fact, the example comes directly from the networks model of CIM.
The model is not protocol or paradigm specific. However, this portion of the
model also has no methods yet. Therefore, it is ripe as an example/case
study on the proper application of methods.
I appreciate the fact that examples are problematic in the context of
nebulous concepts like models. The bottom line is that the IETF is a
community of engineers. Concepts are defined in terms that the majority of
readers (engineers) can understand. If we can't bridge the gap, we must
shrink the gap (make it simpler) or we doom ourselves to failure.