First off, I believe we have addressed most of your concerns in previous mail messages and in the requirements doc itself. I believe, in fact, that this version of the requirements doc is more explicit about the goals then the previous version. So, for the benefit of some recent new subscribers to the list, let me give my sense of where we are and what we still need to address.
The basic premise of this work is that there are more and more divergent data structures being defined in a protocol specific way. With the competitive landscape growing with new protocols for managing networks, there is increasing pressure on the IETF's subject matter experts to define new data structures for each of these protocols. We are seeing this pressure in the form of directory schemas, PIBs, MIBs, Policy MIBs (SNMPCONF), and policy information models targeted for PCIM. In fact there are more on the horizon, but these are the ones we are concerned with now. It is becoming increasingly challenging for the subject matter experts for various technologies like MPLS and DiffServ to sustain the effort involved in defining and harmonizing all of these data structures. The specific goal (as it was envisioned by the original advocates of this work) was specificly to reduce this burden by providing an infrastructure to define data structures in a protocol independent way, with enough detail so as to minimize the burden associated with mapping these structures to various protocol specific data structures.
One of the legitimate concerns you raise is: How far do we want to go? One alternative is to only define a graphical description with accompanying textual definitions of the attributes and methods. On the other extreme, another alternative is to actually use or specify a language that describes the attribute and method relationships with enough detail that a mechanical means for mapping those structures to specific protocols could be supported.
The debates about the various requirements that occurred over the course of the past few months were an attempt to solidify those requirements that people felt needed to be included in order to meet the above stated goal. During these discussions, some lack of clarity in the goals surfaced and this has hopefully been addressed in this latest version of the requirements document. In turn this convergence on the requirements also implied a course of action which did not suggest that we only focus on a graphical respresentation. Rather, the focus on the various requirements suggested a strong interest in specifying or using some type of modeling or data definition language.
There was also very clear concensus around the desirability of using OO concepts including inheritence, associations, and methods to solve the problem stated above. I would specifically agree that not all the issues were fleshed out. This was the main reason for some parallel work taking place to propose guidelines for the use of these various constructs.
As to the question of languages, if these other issues have been addressed in sufficient detail, then we should begin discussing how we can solve this problem. In other words, what language provides the best fit for our needs as represented in the requirements doc. That said, if there are folks who would like to have another round of discussions on the various requirements, that is an obvious precursor to opening any discussion on language alternatives. Naturally, a more detailed discussion of the goals is also a precursor. Therefore, if there are any clarifications, refinements, or details that folks would like to raise with respect to these goals, these comments would be most welcome.
Ok. So that was the party line:) Now let's discuss a concern I share with you. One of the comments reflected concern for how this activity would work with the larger IETF body. If we consider this work as a tool for excellerating the process of defining data models for managing networks, there is a real question as to if and how it will be deployed. I have stated publicly on numerous occassions that I am not interested in coming up with yet another language (existing or new) that adds work rather than deminish it. On the other hand, it will be hard to place dependencies on other working groups when the outcome is still in question. Hence, I see little value in advocating a model for using the results of this activity (to the IETF at large) until after this activity is formalized and the outcome of the work is a little clearer.
From: Andrea Westerinen [mailto:email@example.com]
Sent: Tuesday, July 25, 2000 2:24 AM
To: Durham, David; Walter Weiss; firstname.lastname@example.org
Cc: Bert Wijnen (Bert)
Subject: RE: Status update
Let me take a stab at where I think that NIM is going wrong and not yielding
consensus/productive conclusions ...
It is trying to decide what are valid OO concepts (like whether we include
methods and associations in the model) before we have defined the design
goals. We must decide first on our goals and scope. There may indeed be no
methods - or they may be fundamental to the model. You can't know until
you've made some basic decisions as to scope and requirements. For example,
if you only want to model current state and not affect state, then you are
unlikely to need methods. (I personally don't agree with only modeling
state, but it is just an example.)
What really is the end game behind NIM? Do we really want an implementation
independent info model across all IETF WGs (across the network), or only a
high level model of basic constructs (ie, network services, protocol
endpoints, etc.), or what? Do we want to use OO design techniques? Maybe
we only want to abstract and inherit basic attributes defined in MIBs (just
add inheritance to MIBs)? Until you define these things, you need to leave
your "tool box" open. Otherwise, you end up with something tailored to a
specific implementation and set of tools, which is either too wide ranging
or too narrow - and you might as well have started with a specific
implementation to begin with.
I also believe that the process followed so far is backwards - in that we
could discuss languages until hell freezes over - but what we need to decide
first is whether the IETF wants to do OO-based info modeling, how it relates
to all the other IETF WGs (DiffServ, Policy, MPLS, ...) and how it relates
to existing work/standards that our customers hear about. Depending on the
answers to these questions, all current discussions (your OO tool set,
industry's prior art (ie, CIM, DEN, GDMO, etc.), and even your language) may
all be moot and unnecessary debates.
The current requirements document does not define the scope of the problem -
but does talk about sets of features. This is a typical problem in software
engineering (lots of features, no way to tell when you are done). The
document states that OO techniques should be used, that a constraint
language is needed (property value constraints or object
creation/modification constraints - how do you decide?), and that constructs
like embedded objects are needed. However, although these concepts may be
individually reasonable and valid "features" of an information model, they
may not be applicable in this work that is called NIM.
Many hundreds of mails went back and forth over many months, and I still had
no answers about what NIM is/would be, or if I agreed with it. I did not
care to argue in the abstract about what is or is not good OO technique.
This is why I asked my name to be removed from the draft.
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of
Sent: Friday, July 21, 2000 2:14 PM
To: 'Andrea Westerinen'; Walter Weiss; email@example.com
Cc: Bert Wijnen (Bert)
Subject: RE: Status update
Sorry, I just realized that my previous responses to this issue were
Anyway, to say it again publicly, it is entirely my fault as I left your
name on the document. I did this as your contributions to the document were
left intact, and not removed as I had thought your conditions for authorship
revocation were stated to Walter (it helps to keep all the authors
informed)... But, now that I apparently caused this little ruckus, I hope it
will give you an opportunity to explain why (since we have never actually
talked about it). I believe your contribution to this effort will be
necessary for it to be successful, given your expertise in OO modeling. If
this effort is taking the wrong direction, then I would like to know why, so
that I can help make sure it doesn't.
If we cannot resolve your issues, than I do not see how NIM could ever be
successful. The idea is to bring subject matter experts together, working
within the context of a common model, not turn them away packing...
Regardless of the personalities involved.
> -----Original Message-----
> From: Andrea Westerinen [mailto:firstname.lastname@example.org]
> Sent: Wednesday, July 19, 2000 6:52 PM
> To: Walter Weiss; email@example.com
> Cc: Bert Wijnen (Bert)
> Subject: RE: Status update
> I am surprised that even though I asked specifically for my
> name to be taken
> off of the requirements draft as an author, it still remains.
> This is not
> standard practice in posting a draft, and I again request
> that my name be
> removed as an author.
> I will need to read the draft (which is surprising since I am
> listed as an
> author) to find out what you updated in the 01 version in
> capturing "all the
> issues and consensus to date on the list". It was not clear
> to me that we
> did indeed reach consensus.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com]On Behalf Of
> Walter Weiss
> Sent: Wednesday, July 19, 2000 11:06 AM
> To: 'firstname.lastname@example.org'
> Subject: Status update
> I apologize for the long delay. Between my ramping up on my
> new job and a
> number of other standards related activities, I have dropped the ball.
> However, we have not been completely idle. Dave Durham and I
> have completed
> a rev of the requirements doc that Dave has kindly been
> posted to the IETF
> We have also gotten approval for a BOF in Pittsburgh that
> Jeff Case and I
> will be co-chairing. An agenda will be sent out shortly. Due to some
> logistical issues, we are holding this session on Wednesday morning
> concurrent with DiffServ session 2 and MPLS session 1. If it is at all
> possible, I will try to get the time changed. However, I am
> not optimistic.
> I would like to emphasis that despite my recent distractions,
> it is becoming
> increasingly apparent that some work in this space is necessary as the
> issues associated with the definition of various management
> related data
> structures in DiffServ (MIB, PIB, QoS model, QoS device
> model, policy MIB
> and directory schema) are now leaking into Security, AAA and MPLS.
> Finally, since this latest version of the requirements draft captures
> (hopefully) all the issues and consensus to date on the list,
> it is now
> appropriate to start discussing the most appropriate language for
> representing models. This is planned to be part of the
> agenda. However, if
> people want to provide the list or the chairs with suggestions or
> recommendations for a grammar that satisfies the requirements
> for expressing
> the information model as described in this most recent draft,
> that would be
> greatly appreciated. Ideally some early discussion on the
> list would help
> move things along. Less ideally, a list that the chairs compiled from
> private emails would also be satisfactory.