Subject: [nmrg] RE: Comments on <draft-durham-nim-req-00.txt>
From: "Weiss, Walter" <[email-masked]>
To: "'J.P. Martin-Flatin'" <[email-masked]>
Cc: Network Management Research Group <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 29 Mar 2000 21:04:46 -0500

Jean-Philippe,

Comments Inline...

> > 2) [...]
> > 
> > [Walter] I won't disagree with you here. This is purely a 
> terminology
> > question. The fact is that on the Mumble list, we had a 
> debate about the
> > merits of creating yet another model in the form of PIBs. 
> There was some
> > confusion about terminology, so John Strassner proposed 
> that we use the term
> > "Information Model" to refer to any paradigm independent 
> model and "Data
> > Model" to refer to the application of an information model 
> to a specific
> > paradigm. After some consensus around these terms, it was 
> agreed that these
> > terms would be incorporated in the policy terminology doc. 
> If you prefer a
> > different term or set of terms, I would encourage you to 
> raise your concerns
> > in the context of the policy terminology draft.
> 
> Walter,
> 
> I guess the draft you are referring to is 
> <draft-ietf-policy-terms-01.txt>.
> This I-D was unfortunately obsoleted on March 20; it has now 
> disappeared
> from all the usual archives. I didn't find it either at 
> <http://www.raleigh.ibm.com/maillists/policy/>. Could you 
> please send me a
> copy?
> 
> What is the "Mumble list"? Is it a nickname of the mailing 
> list used by
> the IETF Policy Framework WG?
> 
> Do you think I stand a chance to convince the IETF Policy WG 
> to change its
> terminology or is this a lost cause? The meaning given above 
> to a "data
> model" is different from that taught in all 
> software-engineering classes
> worldwide. Ditto for "information model". Why did you guys 
> redefine these
> well-established phrases?
> 
I agree with all of Juergen's comments here. I would think it is possible to
change the terminology here since this is still an active discussion. I
would encourage you to get involved.
> > 6) [...]
> > 
> > [Walter] I can say with certainty that the DMTF does not 
> have the subject
> > matter experts from the networking community to produce a 
> viable information
> > model (for networks).
> 
> Supposing you are right, this information is by definition 
> short-lived.
> By the time your I-D becomes an RFC, experts might have 
> joined the DMTF
> Network WG. Therefore, you should not write this in my view.
> 
I disagree. The DMTF attracts modelers. It does not attract QoS or Address
Management, or Routing experts.  The fact of the matter is that working
groups like DiffServ, DHCP, etc. are the ones who need to specify conceptual
components and the attributes necessary to manage a cross-section of
different devices. If we did this in the DMTF, then we might as well combine
the DMTF and IETF meetings.

> > 14) A general comment on section 3: Why don't you mandate that the
> > information model be object-oriented? You render mandatory all the
> > characteristics of an object model, but you don't exlicitly mandate
> > object orientation. Why?
> > 
> > [Walter] We probably should be explicit. However, the 
> authors are not
> > entirely in agreement that all the elements that constitute 
> the definition
> > of object-oriented should be incorporated in the model. We 
> chose to include
> > them anyway for the sake of completeness and to encourage 
> discussion.
> > Therefore, when all is said and done, we may not be true to 
> the definition.
> 
> Aren't you splitting hair, here? Why not call it 
> object-oriented, to help
> general understanding, and then give some nuances? There's no 
> consensus in
> the software-engineering community on what is mandatory in an 
> OO model and
> what isn't (if you aren't convinced, just attend ECOOP or 
> OOPSLA once). And
> there's so much OO stuff in your model that I don't see a 
> good reason not
> to call it OO. This time, you would not break a well-accepted 
> definition,
> for sure!
> 
I would suggest that we first review the requirements and develop consensus
on the subset we want to adopt. Then we can decide whether indeed the term
OO would clarify or confuse what we are doing.

regards,

-Walter

Date: Tue, 28 Mar 2000 17:19:54 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Re: Comments on <draft-durham-nim-req-00.txt>
Sender: [email-masked]
Status: RO

>>>>> J P Martin-Flatin writes:

JP> I guess the draft you are referring to is
JP> <draft-ietf-policy-terms-01.txt>.  This I-D was unfortunately
JP> obsoleted on March 20; it has now disappeared from all the usual
JP> archives. I didn't find it either at
JP> <http://www.raleigh.ibm.com/maillists/policy/>. Could you please
JP> send me a copy?

Look instead into <draft-ops-mumble-terminology-00.txt>. There is a
policy terminology design team which is responsible to clear up the
terminology across several IETF WGs.

JP> What is the "Mumble list"? Is it a nickname of the mailing list
JP> used by the IETF Policy Framework WG?

The right place for policy terminology discussions is
<[email-masked]>.

JP> Do you think I stand a chance to convince the IETF Policy WG to
JP> change its terminology or is this a lost cause? The meaning given
JP> above to a "data model" is different from that taught in all
JP> software-engineering classes worldwide. Ditto for "information
JP> model". Why did you guys redefine these well-established phrases?

Can you please tell us (and the IETF folks) what is teached on all
software-engineering classes worldwide? It has been a real problem
that people use terms such as data model, schema, information model,
meta model with different interpretations which has been a great
source of mis-understandings within the IETF.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

From: "J.P. Martin-Flatin" <[email-masked]>
To: "Weiss, Walter" <[email-masked]>
Cc: Network Management Research Group <[email-masked]>, "J.P.  Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
Subject: [nmrg] Re: Comments on <draft-durham-nim-req-00.txt> 
Date: Tue, 28 Mar 2000 17:01:20 +0200
Sender: [email-masked]
Status: RO

On Fri, 24 Mar 2000 00:37:09 -0500, "Weiss, Walter" wrote:
> 
> 2) [...]
> 
> [Walter] I won't disagree with you here. This is purely a terminology
> question. The fact is that on the Mumble list, we had a debate about the
> merits of creating yet another model in the form of PIBs. There was some
> confusion about terminology, so John Strassner proposed that we use the term
> "Information Model" to refer to any paradigm independent model and "Data
> Model" to refer to the application of an information model to a specific
> paradigm. After some consensus around these terms, it was agreed that these
> terms would be incorporated in the policy terminology doc. If you prefer a
> different term or set of terms, I would encourage you to raise your concerns
> in the context of the policy terminology draft.

Walter,

I guess the draft you are referring to is <draft-ietf-policy-terms-01.txt>.
This I-D was unfortunately obsoleted on March 20; it has now disappeared
from all the usual archives. I didn't find it either at 
<http://www.raleigh.ibm.com/maillists/policy/>. Could you please send me a
copy?

What is the "Mumble list"? Is it a nickname of the mailing list used by
the IETF Policy Framework WG?

Do you think I stand a chance to convince the IETF Policy WG to change its
terminology or is this a lost cause? The meaning given above to a "data
model" is different from that taught in all software-engineering classes
worldwide. Ditto for "information model". Why did you guys redefine these
well-established phrases?

> 6) [...]
> 
> [Walter] I can say with certainty that the DMTF does not have the subject
> matter experts from the networking community to produce a viable information
> model (for networks).

Supposing you are right, this information is by definition short-lived.
By the time your I-D becomes an RFC, experts might have joined the DMTF
Network WG. Therefore, you should not write this in my view.

> 14) A general comment on section 3: Why don't you mandate that the
> information model be object-oriented? You render mandatory all the
> characteristics of an object model, but you don't exlicitly mandate
> object orientation. Why?
> 
> [Walter] We probably should be explicit. However, the authors are not
> entirely in agreement that all the elements that constitute the definition
> of object-oriented should be incorporated in the model. We chose to include
> them anyway for the sake of completeness and to encourage discussion.
> Therefore, when all is said and done, we may not be true to the definition.

Aren't you splitting hair, here? Why not call it object-oriented, to help
general understanding, and then give some nuances? There's no consensus in
the software-engineering community on what is mandatory in an OO model and
what isn't (if you aren't convinced, just attend ECOOP or OOPSLA once). And
there's so much OO stuff in your model that I don't see a good reason not
to call it OO. This time, you would not break a well-accepted definition,
for sure!

Jean-Philippe

____________________________________________________________
J.P. Martin-Flatin, EPFL-DSC-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]       Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Mon, 27 Mar 2000 17:33:44 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] FWD: RE: Comments on <draft-durham-nim-req-00.txt>
Sender: [email-masked]
Status: RO

I am forwarding the attached message, which is a response to JP's
comments. I have added Walter Weiss to the nmrg.posters list so that
subsequent mails from Walter will go directly to the nmrg list.

/js

------- Start of forwarded message -------
Date: Fri, 24 Mar 2000 06:37:52 +0100 (MET)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from ["Weiss, Walter" <[email-masked]>]   

>From schoenw  Fri Mar 24 06:37:50 2000
From: "Weiss, Walter" <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>, [email-masked],
        [email-masked]
Cc: Network Management Research Group <[email-masked]>
Subject: RE: Comments on <draft-durham-nim-req-00.txt>
Date: Fri, 24 Mar 2000 00:37:09 -0500

JP,

Thanks for the thorough review. Comments in two parts below and to your text
doc (embedded).

regards,

- -Walter
> 
> Please find enclosed some comments on <draft-durham-nim-req-00.txt>
> (release of March 9, 2000). I fully agree with the point you make in
> the abstract. I think there are many good things in your I-D. Have
> you looked at ODMA and the work done by the OMG?

Truth be told, we are aware of a number of activities by a variety of
standards bodies and consortia in this space (including TIPHON, Parley, and
the TMF). I have not kept abreast of all these activities. However, I am
compiling a rather large list of additional activities that need to be
monitored more closely.

> I am not following
> these efforts closely, but I think they could be useful to you. You
> might also be interested in reading this article:
> 
>   A.I. Riviere and M. Sibilla. "Management Information Models
>   Integration: From Existing Approaches to New Unifying Guidelines".
>   Journal of Network and Systems Management, 6(3):333-356, 1998.
> 
This sounds interesting. I will take a look.

- -----------------

1) Page 3, lines 2-4, you say that in Web-based management, "data
structures are defined in the absence of standards". I disagree: The
DMTF is working precisely on this. The CIM schemas that are expected
to come out of the different working groups this year should be
considered as "standards", if we call an IETF MIB a standard. I don't
think the IETF should implicitly deny the work done by the DMTF.

[Walter] What we were refering to was not the WBEM activity but rather the
popular use web-based management applications embedded in web servers on
networking devices.

2) I think you should define your terminology in the abstract. Page 3,
you state: "What is required is a common representation of data (an
"information model"). A few lines further, you say: "The purpose of an
information model is to represent data in a manner that is independent
of technology and implementation.". Stricto sensu, this is wrong
because you show only part of the picture. Defining an information
model encompasses three things:

 * First and foremost, the definition of the management data itself;
   e.g., SNMP MIBs and CIM schemas.

 * Second, the definition of a metamodel which governs the expressive-
   ness of your information model; e.g., SMIv2 with SNMP.

 * Third, the representation of data; e.g., with SNMP, MIB variables
   are organized as an inverted hierarchical tree; e.g., in MIB-II, the
   error rate for inbound traffic through interface #3 is represented
   as 1.3.6.1.2.1.2.2.1.14.3; e.g., Java objects with JMX.

In the SNMP realm, the definition of an information model is primarily
concerned with the definition of the entities in the MIB (which is
difficult), and secondarily with the representation of these entities
(which is often very easy).

There seems to be some confusion about the meaning of the phrase
"information model" within the IETF community. I already pointed out
a similar confusion to Juergen Schoenwaelder, who is one of the driving
forces in the SNMPv3 WG. In the SNMP world, the information model
consists of all the MIBs, SMIv1, and SMIv2. In WBEM, it consists of
all CIM schemas and MOF.

[Walter] I won't disagree with you here. This is purely a terminology
question. The fact is that on the Mumble list, we had a debate about the
merits of creating yet another model in the form of PIBs. There was some
confusion about terminology, so John Strassner proposed that we use the term
"Information Model" to refer to any paradigm independent model and "Data
Model" to refer to the application of an information model to a specific
paradigm. After some consensus around these terms, it was agreed that these
terms would be incorporated in the policy terminology doc. If you prefer a
different term or set of terms, I would encourage you to raise your concerns
in the context of the policy terminology draft.

3) Page 3, you state: "The purpose of an information model *is* to
represent data in a manner that is independent of technology and
implementation". I would rephrase this sentence as follows: "We claim
that the purpose of an information model should be to define and
represent data in a manner that is independent of technology and
implementation". Your verb "is" is wrong: Typically, information models
are not technology-independent today. But I agree that it would be a
good idea to change habits and make information models technology-
independent.

[Walter] As I said in 2 above, we were using the terms referenced in the
terminology draft. However, it is reasonable to reference the terminology
draft explicictly in this context to make this clearer.

4) Page 3, at the end of the abstract, you state: "that describe the
conventions for the information model and the information model itself".
I find it confusing. If I understand you correctly, I suggest you
rephrase it as follows: "that describe the information model and its
metamodel".

[Walter] We had discussions amoung the authors because some thought it was
too vague. As I recall, conventions referred to the equivalent of SMI while
the information model itself referred to the actual data structures being
defined.

5) Page 4, you state: "This will in turn produce domain-specific data
models that are all derived from a common network information model".
Later, you say: "transforming the information model into specific data 
models".  I don't like your terminology here. For you, a data model is
a particular instance of an information model: It is technology and
implementation dependent. Usually, in computer science, "data model"
is opposed to "object model". A typical criticism of information
modeling in the SNMP world is that it aims at producing data models,
whereas most people would rather use object models (this is addressed
by the DMTF with CIM). I therefore suggest you use "generic information
model" and "specific information model" instead.

[Walter] See comments to 2 and 3 above. As a side note, I would agree that
the term domain-specific was a poor choice. In my mind this could be
interpreted to mean either technologies (DiffServ, DHCP) or management
paradigms (COPS, SNMP, HTTP, CORBA, LDAP, etc.) This should be fixed.

6) Page 5, you should delete: "Finally, the DMTF does not have the
subject matter experts in networking, as does the IETF". It is polemic,
wrong, and useless. Some companies have moved their experts from the
IETF to the DMTF because they thought that the IETF was deadlocked with
SNMP. I would rather the IETF and DMTF work together than criticize
each other. This is not a U.S. presidential election...    :-)

[Walter] I can say with certainty that the DMTF does not have the subject
matter experts from the networking community to produce a viable information
model (for networks). That is not to say that the DMTF does not have subject
matter experts. There is a strong representation from the host community
that has done some good work in the area of systems and devices. However, in
networks, the number of subject matter experts are virtually non-existent. I
started participating a year and a half ago and David started six months
ago, and the two of us have a good understanding of QoS. There is noone else
that I could point to that understands the other aspects of networking to
the same extent we have an understanding of QoS. The main point here is not
to critize the DMTF but rather to recognize that the IETF needs to take more
responsibility to define these models as part of the process of
standardizing new technologies. I have little confidence that the DMTF is
going to attract the expertise necessary to do this work independently. If I
am wrong, it will be with a smile on my face because I don't care were the
work is done. However, I have attended virtually every meeting of the
networks working group of the DMTF, so I know what it will take to change
the situation.

7) Page 5, at the beginning of section 3.1, replace "complimentary"
with "complementary" (twice).

[Walter] Ok.

8) Page 6, section 3.2, what are these "keys"? Those used for strong
security?

[Walter] This requires a bit of context. In CIM, keys are used as
identifiers for object instances. There are many rules in CIM to deal with
maintaining addressing consistency and backwards compatibility. Within the
DMTF, the application of keys and the semantics surrounding keys have been
the source for many arguements. Because it makes the model more complicated
and polarizes the vendors whose implementations of CIM assume specific
restrictions on the use of keys, it was felt that specifying it in the model
would add controversy and slow standards development.

9) Page 6, section 3.3, line 1, delete "such".

[Walter] Ok.

10) Page 6, section 3.3, you leave it to the working group to decide
on the definition language for the textual representation of the
information model. What about suggesting (but not imposing) to use XML?

[Walter] I am agnostic on this because there are too many with opinions. If
there is broad consensus around XML, that is great. However, effort has also
been expended on MIB and CIM representations and I don't want to be
dismissive of these alternatives.

11) Page 6, section 3.4, you use the NIM acronym but you forgot to
define it before.

[Walter] We may have only covered this in the abstract. Sorry.

12) Page 7, bullet "constraints for classes", there is a typo after
"Class B": A quote was replaced by an 8-bit character.

[Walter] Ok.

13) Page 8, a carriage return is missing between sections 3.9 and 3.10.

[Walter] Ok.

14) A general comment on section 3: Why don't you mandate that the
information model be object-oriented? You render mandatory all the
characteristics of an object model, but you don't exlicitly mandate
object orientation. Why?

[Walter] We probably should be explicit. However, the authors are not
entirely in agreement that all the elements that constitute the definition
of object-oriented should be incorporated in the model. We chose to include
them anyway for the sake of completeness and to encourage discussion.
Therefore, when all is said and done, we may not be true to the definition.

15) Page 9, section 3.12: I totally disagree. Subscription to subsets
of data is desirable, but it has nothing to do with the definition of
an information model. This section should be deleted.

[Walter] This was one of the elements that we decided deserved broader
discussion before a disposition was reached. Therefore, we will keep it in
until we have a quorum one way or the other.

16) Page 9, section 3.13: Means for testing compliance should be
recommended, not mandated.

[Walter] This was wishful thinking. For all intents, this activity would
fall outside the purview of the IETF. However, it is a crucial component to
the long term success of this approach.

17) Page 10, section 3.15, same typo as described above after
"Class XYZ".

[Walter] Ok.

18) Page 10, replace "Where IPADDRESSMASK" with "where IPADDRESSMASK".

[Walter] Ok.

19) Page 12, definition of CIM: Replace "Mangement" with "Management"
and delete extra white space before "Common".

[Walter] Ok.

20) Page 13, reference for CIM: You should refer to a specific document
instead of simply giving a URL pointing to the latest specification of
CIM. CIM is regularly updated by the DMTF, and some of your statements
may be wrong in 2-3 years.

[Walter] Fair enough. Thanks again for all the comments.
------- End of forwarded message -------

Date: Mon, 27 Mar 2000 16:30:34 +0200
From: Ron Sprenkels <[email-masked]>
Organization: University of Twente
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Re: Policy 2001
Sender: [email-masked]
Status: RO

> Policy 2001:  Workshop on Policies for Distributed Systems and Networks
> 29-31 January 2001
> Hosted by:  HP Laboratories, Bristol, UK

I've added this one to the events page. Looks interesting.

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group 
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)

Date: Mon, 27 Mar 2000 15:18:52 +0200
From: Ron Sprenkels <[email-masked]>
Organization: University of Twente
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Minutes of the 6th NMRG meeting held March 16-17 at the University of  Twente, Enschede, The Netherlands.
Sender: [email-masked]
Status: RO

Minutes of the 6th Network Management Research Group meeting, held at
the University of Twente in Enschede, The Netherlands on march 16-17,
2000.

Present: Juergen Schoenwaelder (JS), Frank Strauss (FS), Aiko Pras
(AP), Szabolcs Boros (SB), Robert Parhonyi (RP), Ron Sprenkels (RS,
minutes), Bert-Jan van Beijnum (BB), Bert Wijnen (BW)

Agenda

1) Data modeling
2) SMIng and operations
3) SNMP architecture extensions for operations
4) SNMP protocol extensions for operations

Agenda Item #1: Data modeling

Discussion of <draft-durham-nim-req-00.txt> on Network Information
Model Requirements. The draft proposes to develop a technology
independent network information model, and map it to existing data
models. AP has strong doubts if this idea will work. He mentions a few
earlier attempts at this that failed. Issue: Only the lowest common
denominator of the target data models can be used effectively.  Issue:
How does an architecture relate to an information model.

- Every formally expressed information model is technology dependent,
  which contradicts the goal to be technology independent.

- What is the problem an information model is trying to solve?
  (a) industry cost reduction
  (b) IETF cost reduction
  You only get only a cost reduction if the
      - costs for developing the NIM
      - costs for learning how to use the NIM
      - costs for tools etc.
  balance the savings from having a NIM.

BW: Do we need a network information model? Is this still timely work?
(RS: no notes on the answer)

AP: Information or data models are at different levels. SMI is at
lowest level, SPPI is slightly higher, GDMO yet higher, CIM highest
level. Above all that, the general to be defined information model,
that should map to the listed lower level concrete models.

AP: SMI and CIM are the key models. BW: What about CORBA.  Security,
is it the thing that causes the problem? BW: I don't think so: SNMPv3
added security to the Internet Management Framework, but still v3 is
not widely implemented, deployed or used.

Groups like ETSI, typhoon (an IP telephony project), ITU, do work on
information modeling.

Is OSI management still used? JS: It is used e.g. to manage GSM
networks or SDH networks.

Is SNMP used for systems management? AP: no, BW, JS: yes. There is
the host resources MIB, and proprietary MIBs are used for systems
management, although the big market is using proprietary protocols.

JS: IETF only has limited human resources to do actual work. The IETF
may reach a point where everybody is spending all his time monitoring
everybody else and nobody is doing actual work anymore.

Starting a IETF working group on information modeling can be seen as a
political statement against DMTF/CIM.

<[email-masked]> is the mailinglist for the NIM discussions. It was
announced at the ietf-announce mailinglist. BW suggests to post
comments on draft-durham-nim-req-00.txt to this list.

Problem why cooperation DMTF and policy framework does not go well:
One experience is that mapping CIM to LDAP is difficult.

-- coffee break --

There is a big book on CORBA specification translations and
interactions translations. (RS: I think this was mentioned by JS, no
notes on the context) The mapping from SMIv2 to IDL works, but has a
versioning problem. JS implemented it.

The SPPI basically adds two operations (install/remove) to the SMIv2.

JS: Common LDAP schemas are not widely deployed or standardized.

JS: The main goal of the SMIng work is to be able to map SMIng to
SMIv2, and obsoleting the need for SPPI. In addition, design decisions
should be made taking into account existing mappings (e.g. SMIv2 to
CORBA IDL). (Don't make them more complicated if it can be avoided.)
It has not been a goal so far to define new mappings.

AP: Readability and reusability of specifications work against each
other. (The example of the GDMO registration tree, and references to
it from MIB specs in GDMO was discussed shortly.)

Requirement no. 15 is about compound data types: not mappable to SMIv2
right now. BW: similar issue was counter64. 'We' made constraints when
it could be used. Maybe it is OK to add compound types even if they
can't be mapped to SMIv2 or the current flavor of SNMPv3.

-- lunch break --

Summary of the debate of this morning on the information models.

- Defining a high level information model without taking lower level
  models to map to into account will not likely succeed.

- The level of SMIng was moved slightly up to prevent the need for
  SPPI and to evolve the SNMP framework.

- How to decide what goes into SMIng and what not?

- Naming within SMIng: Classes versus Tables.

SMIng solves the SMI part of the 64 bit integer problem.

Issue: Where to limit the scope of the SMIng effort to. To SMIv2 and
SPPI (lowest level) or include IDL, and or LDAP.

Supporting policies in the repository could give support from the
groups that define them; Opening up SMIng to include a mapping to LDAP
could improve support.

BW: Could you express a Policy Framework schema in SMIng? JS: SMIng
was not designed for that...

AP proposes to do a feasibility study to a SMIng to LDAP mapping. JS:
Need an SMIng "guru" and an LDAP "guru". Potentially takes a week per
person. JS: What is the purpose, technical or political? Consensus:
for the better part political.

JS: Are there LDAP experts in Europe? BW knows one in Norway; and
maybe Harald Alvestrand. And there might be more in Scandinavia; Eric
Huizer might know a few people that have this kind of knowledge.

When doing the exercise of a SMIng to LDAP Schema mapping, since SMIng
is not fixed yet, this would also mean revising some of the SMIng
design decisions.

For the feasibility study, probably FS or JS should be involved.

More data models to map to? BW: WMI Web-based Management Interface (of
Microsoft)?

<draft-dacosta-snmp-object-dependency-00.txt>: This draft is on a MIB
object dependency expression language. AP thinks its too complex, you
lose more than you gain. JS: Some of the issues raised by the draft
will go away by adding operations to SMIng. The draft helps to
automatically generate management applications. The draft is mainly
useful for boxes that have writable objects.

JS: This type of extension could be supported in the form of an SMIng
extension rather than being a core language feature. The SMIng already
supports an extension mechanism. What is still needed is an annotation
mechanism.

BW: What to advise the writer of the document (dacosta)? JS: Advise to
use SMIng. It solves some of the problems already (operations) and can
solve the rest (by using extensions).

BW: Annotations could also be used to add semantic annotations to
objects. Counter value x means this, value between y and z means that,
and you should take this action, and so on.

Action Item: BW will send dacosta a response, mentioning the possible
future of SMIng and how it addresses the issues in his draft.

-- coffee break --

Agenda Item #2: SMIng

AP: Could you also define SMIng in XML? JS: No, because XML uses tags,
and SMIng uses keywords. ;-)

JS: You can define a DTD to define the same information. You can write
a backend that generates XML. However, the real purpose of such an XML
representation is IMHO to use it as an exchange format because it will
not be easily human readable.

JS: Don't mix up representing actual instances of information in XML
and describing the structure of information in XML.

AP: XML is fashionable, so it might be a selling point for SMIng.

XML format could be good for making modules accessible easily, because
there are lots of tools (like parsers, embedded in different packages)
for XML, and you don't depend on libsmi being available everywhere.

Issues: Is it useful to have compound types? And are they useful even
without operations that work on compound types. Do you require a
mapping to SMIv2?

Issue: Discriminated union types (for sparse tables) are also needed.

Issue: Compound data types. Put them in right away? Consensus: Put
them in at the first go, then make the mapping to a protocol that
doesn't know about them an issue, or assume that the underlying
protocol can ship them and make that the issue.

How to get the SMIng accepted in IETF? You need tools. Tools are
there, libsmi. Libsmi is getting popular. SMIng parser is currently
not as fully tested as the SMIv1/SMIv2 one.

Issue: Motivation for using agent caps as an example for the extension
mechanism. It is useful to put in some motivating text in the document
for this.

The SMIng document is a large document. If you compare it to its SMIv2
counterparts including the ASN.1 definition, this is to be expected of
course. Proposed additions to the document:

 o A section in the introduction on how to read the document,
   something like "If you are reader type X , you can skip these
   parts..."

 o A section that lists the differences between SMIv2 and SMIng.

Some issues with SMIng:

 - Display hints for unsigneds (cannot be mapped back and forth to
   SMIv2, since SMIv2 does not support them).

 - Compliance groups for notifications and objects: SMIv2 has separate
   constructs for these, whereas SMIng does not. This gives problems
   if a SMIng document puts notifications and objects into the same
   compliance group.

 - IpAddress type is now deprecated, as are some other types of v2.

SMIng relaxed some restrictions, e.g. putting index objects in groups.

Pretty soon in the IETF, the long-term solution for 64 integer data
types will be addressed and a WG started. At that point the SMIng work
should be submitted to the IETF.

How this will be accepted in the SNMP community in the IETF is an open
question; there might be some problems there.

-- coffee break --

Agenda item: Operation types in SMIng

Issues:

 o creates and deletes clauses (constructors and destructors)

 o where can operations be defined (bound to single table, multiple
   tables or not to tables at all)

 o returning of results (single result, vector of results)

 o returning of errors (restricted to enumerations currently)

 o sequences of operations to get a device in a defined state. Get the
   state from a device, something to send it back to get back into the
   current state.

 o What are the invocation semantics of operations? At most once,
   exactly once, at least once.

 o synchronous or asynchronous operations

Transport and operations: Do we need to support the invocation of
operations over UDP? Lets seriously consider not supporting operations
over UDP. UDP gives some problems in case of operations, including
arbitrary sized responses.

Second day of the meeting (March 17, 2000)
==========================================

Bert Wijnen is not present today at the meeting.

Announcement: JS wrote an experimental XML back-end to libsmi
yesterday after dinner and beer. More work is needed to formally
define this.

issue: constructors and destructors. Do we need to provide special
language constructs to support them? In SMIv2, the RowStatus is
usually bound to a single table entry.

Do operations need to be bound to data structures? Examples:
traceroute, reboot system, remote ping.

JS: Scalars in SMI should not have been invented; a set of scalars
with a common root is a degenerated case of a table. Having scalars as
a special language construct just makes the world more complex.

COPS gives every 'table' its own create and destroy 'method'.

Discussion on where to bind operations to. OO binds operations always
to classes; in a one on one manner. Side-effects are still allowed.
UML develops into the 'lingua franca' of modeling (JS) and UML has no
notion of operations without objects; every operation is bound to an
object class.

Options for binding are
 - operations not bound to anything
 - bound to exactly one table (or group of scalars)
 - bound to one or more tables

There is no complete consensus on where (if anywhere) to bind
operations to: AP supports unbound operations, JS and others support
operations bound to a single table (or group of scalars).

-- coffee break (Bert-Jan leaves the meeting) --

Example of an operation: Testing an interface.

operation ifTest {
  oid       ifMIBOperations.2;
  arguments (ifIndex InterfaceIndex,
             testType Enumeration (test1(1), test2(2));
  errors    (ifIndexInvalid(1), ifIndexInUse(2));
  results   (result Enumeration (success(1), failed(2), aborted(3));
  description
    ".....";
};

The usual OID registration tree structure of a MIB specification is
below, extended with a branch to locate Operations in.

|
+- xxxObjects
|
+- xxxNotification
|
+- xxxCompliance
|
+- xxxOperations

Where to define operations?

(a) First option to bind the operation to the ifTable:

    table ifTable {
      ... the operation definition ...
    };

(b) Second option is to add to the operation definition a reference
    that identifies the scope: 

    operation ifTest {
      scope ifTable;
      ... the rest of the operation definition ...
    };

(c) Third option is to use SMIng annotations:

    annotation ifTableAnnotatation1 {
      oid ....
      scope ifTable;
      ... the operation definition ...
    };

Consensus: Put operations inside table definitions, and allow the
annotation mechanism to add operations in separate documents to
existing tables.

Asynchronous example with a separate test table:

table ifTestTable {
  ... normal table definitions ...
  operation runTest {
    oid ifMIBOperations.1;
    arguments (ifIndex InterfaceIndex,
               testType Enumeration (t1(1), t2(2)),
    errors ...
    description
      "... says that the result is shipped via a notification ...";
    result(ifTestTableIndex Unsigned32);
  };
  operation stopTest {
    ... the rest of the operation definition ...
  };
  operation purgeTest {
    oid ifMIBOperations.3;
    arguments (ifTestIndex Unsigned32);
    error (invalidIndex(0));
    description
      "...";
  };
}

Second example of an operation: Rebooting a system.

option 1:

annotation systemAnnot1 {
  oid snmpMIBOperations.1;
  scope system;
  operation reboot {
    ...
  };
};

option 2:

operation reboot {
  oid snmpMIBOperations.1;
  arguments (when DateAndTime);
  errors (invalidDateAndTime(1));
  ...
}

Reboot turns out to be a table after all. If you want to be able to
schedule reboots in advance (reboot in 24 hours)), you probably also
want to be able to cancel scheduled reboots.

-- lunch break --

Multiple results should be supported. We need a way to indicate how
many results may be returned (exactly one, 1 or more, 0 or more, ...).

Enumerations are sufficient as error codes.

We assume 'at most once' or better semantics for operation invocations.

Strange reboot example: An operation invoker invokes the reboot
operation on a device, and the device immediately reboots, before even
confirming the proper reception of the operation invocation.

We do not support the strange reboot example; operation invocations
are confirmed. The invoker can tell that the invocation actually
succeeded.

Agenda point #3: SNMP architecture extensions for operations

Two additional architectural function blocks: Operation Invoker (OI)
and Operation Performer (OP).

Access control is an issue; where to call isAccessAllowed ASI?

AgentX consequences: If operations are in different subagents than the
data they operate on, who calls isAccessAllowed?

Agenda item on SNMP protocol operations not covered (lack of time).

Action items:

 o JS and FS take up the action item to update SMIng spec: to add
   annotations as a core feature to SMIng instead of having it as an
   extension (as described in the DSOM '99 paper).

 o JS and FS: Add a rationale why agentcaps are not handled as a core
   feature of the language and may be better handled as an extension
   of the core SMIng language.

 o JS: Work on architecture extensions for SNMP; what goes into and
   what comes out of the Operation Performer (OP) and Operation
   Invoker (OI) blocks. Need to specify the relevant ASIs.

 o Implementation experience on operations would be really cool.  AP:
   Twente will work on it; in particular SB and Bert Helthuis.

 o Item: Small example MIB with operations. Use this to get
   implementation experience.

 o Item: Real MIB with operations. Potential candidate: Diffserv
   Policy PIB, turn it into SMIng MIB with operations.

 o Work item: Extend SMIng parser to understand operations, extend
   libsmi data structures, possibly generate code stubs from that.

-- meeting closed --

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group 
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
cc: Network Management Research Group <[email-masked]>, "J.P.  Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
Subject: [nmrg] Comments on <draft-durham-nim-req-00.txt>
Date: Wed, 22 Mar 2000 11:46:32 +0100
Sender: [email-masked]
Status: RO

This is a multipart MIME message.

--==_Exmh_3667946560
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

                                                  Copy: IRTF NMRG RG

Walter, David, and Andrea,

Please find enclosed some comments on <draft-durham-nim-req-00.txt>
(release of March 9, 2000). I fully agree with the point you make in
the abstract. I think there are many good things in your I-D. Have
you looked at ODMA and the work done by the OMG? I am not following
these efforts closely, but I think they could be useful to you. You
might also be interested in reading this article:

  A.I. Riviere and M. Sibilla. "Management Information Models
  Integration: From Existing Approaches to New Unifying Guidelines".
  Journal of Network and Systems Management, 6(3):333-356, 1998.

JP

____________________________________________________________
J.P. Martin-Flatin, EPFL-DSC-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]       Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

--==_Exmh_3667946560
Content-Type: text/plain ; name="nim.txt"; charset=iso-8859-1
Content-Description: nim.txt
Content-Disposition: attachment; filename="nim.txt"
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

1) Page 3, lines 2-4, you say that in Web-based management, "data
structures are defined in the absence of standards". I disagree: The
DMTF is working precisely on this. The CIM schemas that are expected
to come out of the different working groups this year should be
considered as "standards", if we call an IETF MIB a standard. I don't
think the IETF should implicitly deny the work done by the DMTF.

2) I think you should define your terminology in the abstract. Page 3,
you state: "What is required is a common representation of data (an
"information model"). A few lines further, you say: "The purpose of an
information model is to represent data in a manner that is independent
of technology and implementation.". Stricto sensu, this is wrong
because you show only part of the picture. Defining an information
model encompasses three things:

 * First and foremost, the definition of the management data itself;
   e.g., SNMP MIBs and CIM schemas.

 * Second, the definition of a metamodel which governs the expressive-
   ness of your information model; e.g., SMIv2 with SNMP.

 * Third, the representation of data; e.g., with SNMP, MIB variables
   are organized as an inverted hierarchical tree; e.g., in MIB-II, the
   error rate for inbound traffic through interface #3 is represented
   as 1.3.6.1.2.1.2.2.1.14.3; e.g., Java objects with JMX.

In the SNMP realm, the definition of an information model is primarily
concerned with the definition of the entities in the MIB (which is
difficult), and secondarily with the representation of these entities
(which is often very easy).

There seems to be some confusion about the meaning of the phrase
"information model" within the IETF community. I already pointed out
a similar confusion to Juergen Schoenwaelder, who is one of the driving
forces in the SNMPv3 WG. In the SNMP world, the information model
consists of all the MIBs, SMIv1, and SMIv2. In WBEM, it consists of
all CIM schemas and MOF.

3) Page 3, you state: "The purpose of an information model *is* to
represent data in a manner that is independent of technology and
implementation". I would rephrase this sentence as follows: "We claim
that the purpose of an information model should be to define and
represent data in a manner that is independent of technology and
implementation". Your verb "is" is wrong: Typically, information models
are not technology-independent today. But I agree that it would be a
good idea to change habits and make information models technology-
independent.

4) Page 3, at the end of the abstract, you state: "that describe the
conventions for the information model and the information model itself".
I find it confusing. If I understand you correctly, I suggest you
rephrase it as follows: "that describe the information model and its
metamodel".

5) Page 4, you state: "This will in turn produce domain-specific data
models that are all derived from a common network information model".
Later, you say: "transforming the information model into specific data =

models".  I don't like your terminology here. For you, a data model is
a particular instance of an information model: It is technology and
implementation dependent. Usually, in computer science, "data model"
is opposed to "object model". A typical criticism of information
modeling in the SNMP world is that it aims at producing data models,
whereas most people would rather use object models (this is addressed
by the DMTF with CIM). I therefore suggest you use "generic information
model" and "specific information model" instead.

6) Page 5, you should delete: "Finally, the DMTF does not have the
subject matter experts in networking, as does the IETF". It is polemic,
wrong, and useless. Some companies have moved their experts from the
IETF to the DMTF because they thought that the IETF was deadlocked with
SNMP. I would rather the IETF and DMTF work together than criticize
each other. This is not a U.S. presidential election...    :-)

7) Page 5, at the beginning of section 3.1, replace "complimentary"
with "complementary" (twice).

8) Page 6, section 3.2, what are these "keys"? Those used for strong
security?

9) Page 6, section 3.3, line 1, delete "such".

10) Page 6, section 3.3, you leave it to the working group to decide
on the definition language for the textual representation of the
information model. What about suggesting (but not imposing) to use XML?

11) Page 6, section 3.4, you use the NIM acronym but you forgot to
define it before.

12) Page 7, bullet "constraints for classes", there is a typo after
"Class B": A quote was replaced by an 8-bit character.

13) Page 8, a carriage return is missing between sections 3.9 and 3.10.

14) A general comment on section 3: Why don't you mandate that the
information model be object-oriented? You render mandatory all the
characteristics of an object model, but you don't exlicitly mandate
object orientation. Why?

15) Page 9, section 3.12: I totally disagree. Subscription to subsets
of data is desirable, but it has nothing to do with the definition of
an information model. This section should be deleted.

16) Page 9, section 3.13: Means for testing compliance should be
recommended, not mandated.

17) Page 10, section 3.15, same typo as described above after
"Class XYZ".

18) Page 10, replace "Where IPADDRESSMASK" with "where IPADDRESSMASK".

19) Page 12, definition of CIM: Replace "Mangement" with "Management"
and delete extra white space before "Common".

20) Page 13, reference for CIM: You should refer to a specific document
instead of simply giving a URL pointing to the latest specification of
CIM. CIM is regularly updated by the DMTF, and some of your statements
may be wrong in 2-3 years.

--==_Exmh_3667946560--

Date: Mon, 13 Mar 2000 18:37:01 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] meeting preparation
Sender: [email-masked]
Status: RO

Here are a few IDs that you should read in order to prepare yourself
for the meeting at the end of this week:

<draft-durham-nim-req-00.txt>
<draft-dacosta-snmp-object-dependency-00.txt>
<draft-irtf-nmrg-sming-02.txt>
<draft-irtf-nmrg-smi-ops-00.txt>
<draft-irtf-nmrg-snmp-ops-00.txt>

In the light of <draft-durham-nim-req-00.txt>, we need to discuss what
our research group's position on future information modeling and/or
data modeling work is. So I would like to add that discussion to our
agenda as the first item since the outcome may influence the other
agenda items.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>