[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NIM requirements/conventions (was Re: Methods in the NIM requirements)
- To: "'Mark A. Carlson'" <email@example.com>, firstname.lastname@example.org
- Subject: RE: NIM requirements/conventions (was Re: Methods in the NIM requirements)
- From: "Weiss, Walter" <WWeiss@lucentctc.com>
- Date: Tue, 2 May 2000 12:20:49 -0400
- Delivery-date: Tue, 02 May 2000 09:22:02 -0700
- Envelope-to: email@example.com
This is a very nice summary. Comments inline.
> -----Original Message-----
> From: Mark A. Carlson [mailto:firstname.lastname@example.org]
> An information model needs to be able to be mapped to any number of
> data models such as:
> Repositories - Directories, databases, etc.
> Protocols - SNMP
> APIs - C++, Java, etc.
This was in the requirements doc. In addition, my discussion with John leads
me to believe that we should also expand this to describe supported
paradigms, since protocols are an embodyment of a paradigm. For example,
some paradigms are follow a push model while others follow a pull model.
Specifically, a device may have configuration pushed to it via SNMP or a
device may pull configuration using LDAP (or some other protocol). More
importantly, some paradigms are synchronous (transactional) while others are
asynchronous. I have provided some examples of this previously. Here is
another example. In some cases an SNMP SET will cause an immediate change in
the state of the device (like the BandwidthAllocation assignment). In other
cases, an SNMP SET will be written to NVRAM and will only take effect after
a reboot. Sometimes this is assumed in the standard making the transaction
change config as opposed to change state. In other cases it is an
implementation choice. We should be able to accomodate both cases in the
model. Therefore, I think these are reasonable requirements to add.
> Even though the information model should be independent of any
> mapping to a data model, thought needs to be given to conventions
> that might make a mapping difficult or impossible.
> The information model needs to support properties of objects that
> have various usage semantics, for example: strict READ/WRITE,
> READ/CLEAR, WRITE-only, READ-only, etc. All of these semantics
> need support in the information model, however, there is a
> requirement for supporting certain semantics differently.
Ok. At my first glance I thought you were talking about attributes here but
you really mean the object. That's fine.
> Object properties that only have the semantics of READ/WRITE or
> READ-only are (by convention?) called ATTRIBUTES. (Is this correct?)
> <Is this special classification of semantics due to the ease of
> mapping to repositories?>
> Objects also have behavior (defined as something other than mutating
> or accessing a property - except for the CLEAR semantic) that need to
> be modeled. The convention for modeling this behavior is to specify
> it as a METHOD with (presumably) passed parameters, returned values
> or exceptions, all of which are typed, etc.
> Object properties that have semantics other than ATTRIBUTE will need
> to have METHODs defined that specify these other semantics (such as
> mutating the property to a reset state). (Question: how do you relate
> these property mutator methods back to the property they mutate?
> Is there a requirement for method/property naming conventions?)
As I said yesterday, I think the METHODs requirement is not up to snuff in
the requirements doc. Concerns about overspecification aside, the more
precisely we specify the operational boundaries of METHODS, the more
interoperable they are and the more precisely we can assess various language
> Finally, since METHODs are difficult to map to repositories, they
> should only be used to model non-ATTRIBUTE property semantics or
> other object behavior. However, this should be at the
> discretion of the
This one sets my hair on end. I agree with the principle, but the reason I
have been pushing so hard on this point is because I believed that people's
definition of "behavior" was all over the map. If we can't put our finger on
the criteria for using an attribute or method, than usage will be open to
interpretation and the choice of which is used will be more a function of
who wrote the object.
It is quite clear that we will need a guidelines document here. Is there
interest in the group for starting such a document? This work would focus
the discussion of the Methods off of the list to just the authors and allow
the list to continue with requirements. I think the guidelines also would be
useful in the language discussion. If you are opposed to this work, send it
to the list. If you would like to voluteer, send me a note.