RE: NIM requirements/conventions (was Re: Methods in the NIM requirements)

["Andrea Westerinen" <andreawest@mindspring.com>]

Wow, I have been trying to not add to the "methods" mails, and I get pulled
in by reference :-).  I still strongly believe that methods are required and
think that Joel Halpern gave one of the best explanations of methods and
mappings (at least for SNMP) ... "There are a number of SNMP objects which
exist as mechanisms to represent operations in a pure attribute syntax.  If
one is trying to represent those
operations in a Network Information Model (when they belong in the model)
then I would hope that one would use operations / methods rather than
attributes."

Now, back to the reference to me in the mail below ... "Andrea disagrees
with you. One of Andrea's arguments for methods seems to be to encapsulate a
behavior into a transaction (the reference to "go")." I am not sure what I
am disagreeing with, but methods represent (ie, model) behavior and
operation.  ("Transaction" is an overloaded term that I would rather not use
in conjunction with a generic "method".)  My reference to a "go" attribute
in SNMP is summed up in Joel's statement above.  It is not equal to a
transaction.

OTOH, if a behavior/operation conveys or requests transactional semantics
(and this is what the modelers specify), then mappings and implementations
should do their best to carry this out.  If they can not, then this should
be documented.

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> John Strassner
> Sent: Saturday, May 13, 2000 3:11 PM
> To: Weiss, Walter; nim@ops.ietf.org
> Subject: Re: NIM requirements/conventions (was Re: Methods in the NIM
> requirements)
>
>
> Walter,
>
> thanks for the message, this helps clarify things. I've just
> re-read the NIM draft, and I think that we are crossing
> wires because the requirements that you are referring to are
> not in the draft (curiously enough, methods are ;-) )
>
> Your position is summed up by your statement:
>
>   > 2. For me, the primary value of the modeling
>   >    activity is to define a consistent set of
>   >    management interfaces to embedded systems.
>
> This is the source of the problem - to me, an information
> model is by definition independent not just of specific
> repository and interface, but also of APIs and interfaces to
> embedded systems.
>
> So I would suggest that you revise the draft to include your
> requirement for interfaces to embedded systems. However, I
> still don't understand what these interfaces have to do with
> the information model per se. Rather, these are a function
> of the mapping from an information model to a data model.
>
> The rest of the comments really depend on whether embedded
> systems requirements should be a part of this effort, so
> I'll defer commenting on them until that is cleared up.
> However, your last two issues do need a comment:
>
> With respect to my comment "Transactional semantics isn't in
> the information model...", you write:
>
> > This comment is contradictory with earlier statements
> > you made. There are clearly elements that you want to
> > model that are repository and protocol-specific.
>
> No, it is not contradictory at all. The fact that there are
> elements that are repository- and protocol-specific is why
> they are in the mapping of an information model to a data
> model and not in the information model.
>
> > Events and User Access rights are both in the
> > requirements doc. I believe you have endorsed
> > including event notification in the information model.
> > Yet, in your last comment you argue that transactional
> > semantics are repository and protocol-specific and
> > therefore should not be in the model.
>
> What does event notification have to do with transactional
> semantics? A notification is simply a message saying that an
> entity has something interesting. It does NOT mean or imply
> an operation that requires transactional semantics.
>
> > Your previous statement also argues for a strategy that
> > restricts the model to those features that are commonly
> > available in a cross-section of protocols (something you
> > argue against later in your last message).
>
> Huh? I said, and I quote:
>
>  "> > If a repository, like a directory, can't support
>   > > these features, then it is the job of the mapping
>   > > to support it in some other way (e.g., by using
>   > > middleware in conjunction with the directory to
>   > > support the desired semantics)."
>
> In other words, the information model should model the
> information without regard to protocol or repository
> limitations. The mapping can use the information model to
> make up for the deficiencies of the repository or protocol.
>
> > I also get the distinct impression that Andrea disagrees
> > with you. One of Andrea's arguements for methods seems
> > to be to encapsulate a behavior into a
> > transaction (the reference to "go"):...
>
> Well, we'll have to ask Andrea, but I don't get that
> impression reading her quote. Please reread my above
> explanation.
>
> > If transactional semantics are not part of the model,
> > the benefits of methods is greatly deminished. On the
> > other hand, if they are part of the model, then my
> > earlier example (and other examples I have not raised yet)
> > raise some serious mapping issues that may undermine the
> > overall benefits of the information model.
>
> Please reread my above statement. I'm not arguing against
> transactional semantics, and I don't know why you think I
> am.
>
> regards,
> John
>

<further appended mails snipped>