[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.