Subject: Re: [nmrg] Minutes of 8th NMRG meeting
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 29 Jan 2001 12:12:25 +0100

>>>>> Juergen Schoenwaelder writes:

Juergen> Thanks very much to szabi and boros for writing up the
Juergen> minutes. I have put them on the NMRG web site now.

The thanks go of course to Szabolcs Boros and Robert Parhonyi. I am
sorry for mixing up these two names.

/js

Date: Sat, 27 Jan 2001 00:27:46 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Minutes of 8th NMRG meeting
Sender: [email-masked]

>>>>> Szabolcs Boros writes:

Szabolcs> Below are the minutes from the 8th NMRG meeting in Austin,
Szabolcs> TX.  szabi boros

Thanks very much to szabi and boros for writing up the minutes. I have
put them on the NMRG web site now.

/js

Date: Wed, 24 Jan 2001 10:56:23 +0100
From: Szabolcs Boros <[email-masked]>
Organization: UTwente
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Minutes of 8th NMRG meeting
Sender: [email-masked]

Szabolcs Boros wrote:
> 
> Below are the minutes from the 8th NMRG meeting in Austin, TX.
> szabi boros
> 

Comments are, of course, welcome...

szabi

Date: Wed, 24 Jan 2001 10:47:37 +0100
From: Szabolcs Boros <[email-masked]>
Organization: UTwente
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Minutes of 8th NMRG meeting
Sender: [email-masked]

Below are the minutes from the 8th NMRG meeting in Austin, TX.
szabi boros

IRTF - NMRG meeting
Austin, Texas
J.J. Pickle Research Campus
December 8-9, 2000

List of Participants (in alphabetical order) 

 1. Sz. Boros (SB) - Univ. of Twente (minute taker) - [email-masked]
 2. M. Brunner (MB) - NEC Europe Ltd. - [email-masked]
 3. D. Durham (DD) - Intel Corp. - [email-masked]
 4. D. Harrington (DH) - Enterasys - [email-masked]
 5. J.P. Martin-Flatin (JP) - AT&T Research Lab - [email-masked]
 *. G. Pavlou - University of Surrey - [email-masked] (2000-12-09)
 6. R. Parhonyi (RP) - Univ. of Twente (minute taker) - [email-masked]
 7. D. Perkins (DP) - SNMPinfo - [email-masked]
 8. A. Pras (AP) - Univ. of Twente (chair) - [email-masked]
 9. J. Schoenwaelder (JP) - TU Braunschweig - [email-masked]
10. D. Sidor (DS) - Nortel Networks - [email-masked]
11. A. Westerinen (AW)- Cisco Systems - [email-masked]
12. B. Wijnen (BW) - Lucent - [email-masked]

****************************************
08-12-2000
****************************************

The purpose of the meeting was defined as learning from each other,
discuss high level things and do not go into details. The title of the
meeting can be formulated as follows: Network Information Modeling
Workshop.

There is a need to define a set of terms:
	- information model (IM)
	- data model (DM)
	- interface
	- conceptual model
	- object oriented (OO) model
and also to answer some questions/issues:
	- IM vs. protocol. Should the IM be protocol independent/neutral?
	- IM vs. API
	- What is the scope of IM?
	- How many models do we need? One or more?
	- What are the benefits of IM? Users of IM? Standards.
	- Should we use OO techniques to describe an IM/DM?
 
Proposal for the IM definition: 
	(a) conceptual model: list of keywords (defines entities)
	(b) structuring all the information keywords
	(c) naming scheme for all the entities
	(d) meta model defined in the entities

An IM should contain:
	- abstracts (conceptual model - modeling the world in abstract objects)
 	- structure:	- data model
			- object model
			- inverted tree
			- ...
	- naming
	- meta model

(also some COPS documents deal with IM)
The DM is related more to object repository.

There are other approaches for an IM:

1.	      IM
	    /  |  \
	   /   |   \
	  /    |    \		--> Conceptual
     --------------------------------------------
	/      |      \		--> Computational - as opposed to conceptual 
				    (term was removed later from the board)
       DM     DM      DM ...	(this can be implemented (MIB, LDAP schema), 
				it's technology specific and standardizable)

	(This model is close to the ITU-T approach.)

2. ODP approach (open distributed processing)

	- Enterprise viewpoint
	- Information viewpoint
	- Computation viewpoint
	- Engineering viewpoint
	- Technology viewpoint

Question: How can the two approaches be mapped? How can this be done?

Structure and meta model belong together.

IM - protocol independent
DM - protocol specific

		     +--------------------------------+
                     |                                |
MAPPING:             |                                v
		     v  			+------------------+
	+---------------+	data m. 	|    abstracts     |
	|		|-->	obj. m.	     <--|    structure     |
	|	IM	|	inverted tree	|    naming (1)    |
	|		|			|    meta model    |
	+---------------+			+------------------+
	  /     |     \	 \				^	    \
	 /      |      \  \				|	    IM
        /       |       \  -----------------------------+
       /        |        \
     naming    DM        DM
    protocol
     (HTTP)
    encoding
     (XML)

   (1)  not yet defined in IETF, but CIM has it.

SMIv2 is a data model. SMIng tries to do the converging of data
models. SMIng is more than a DM, and it has IM flavour.  No
functionality can be put into a DM that is not in the IM.

11:00 - 11:30 Coffie break

OMG people try to implement everything valuable of TINA-C. TINA uses
UML for information view, uses CORBA at computational view.

The IM is conceptual, but it has to be encoded somehow. The encoding
carries the protocol. The DM is more like an encoding. The IM is
independent of CMIP, MIB. The IM is more static. The Computational
model is running on this static IM.  Discussion about the terms:
conceptual and computational.

Maybe "computational" is not the right term because it is not opposed
to "conceptual". What should be instead of "computational"? Isn't
"protocol specific" enough for the DM layer? There were pros and cons.

Though this is not the ideal solution, this is what we have in IETF at
this moment and our goal is to stay within the range of IETF, we don't
define a model for the entire world.

A common proposal for both IETF and DMTF can be pictured:

		       IM			  
		      / | \			 +------> SMI / ASN.1
		     /  |  \			/
		    /	|   \		       /	
		   /	|    +--------------------------+
		 CIM	PIB  |      			|
		/MOF/ /SPPI/ | 				|	Data Model
		 /	|    |	     SNMP MIBs		|
	        /       |    |	        		|
  ---------------------------|--------------------------|--   	wire
	      /		|    |				|
	     | 		|    |	       			|
	    XML	       BER   | 				|	encoding
	 for HTTP	     |				|
	 for LDAP	     +--------------------------+

	 (DMTF)    			(IETF)

ASN.1 was designed to describe protocols (e.g. PDUs). CMIP includes
actions not just values, MIBs have two operations. IM includes the
operations.  DTD and XML schema operate at the same level. XML schema
is broad, is more suited to complex problems. DTD is a simplified
form.

Summarized picture:
			 IM
			/ | \
		      /   |   \
		    /	  |     \
		  CIM	 PIB	MIB				data models
		schema  /SPPI/  /SMI, XML/
		/	  |	     \
	      /		  |	       \ 
  -------------------------------------------------------   	wire
	    /|\		  |		/|\	
	   / | \	  |	       / | \
	   XML for	 BER		BER			encoding
	    HTTP

How important are the BER for Information Modeling?  

There is a difference between "expressing a concept" and "the way to
transmit it over the wire".  "Protocol" encompasses both bottom levels
of the picture; i.e. protocol = actions + encoding.  Mapping MIB into
BER, or CIM into XML is not a 1:1 mapping.  XML is more powerful and
can be used to describe different levels (DM level and encoding
level).  Different Data Models can be expressed in different ways: we
use schemas for CIM, SPPI for PIBs and SMI for MIBs. But XML can be
also used to express a MIB on the DM level. Even more, XML can be used
also for the IM level.  In DMTF the data model is fully Object
Oriented. In SNMP the object model has to be translated into a DM
which is not an OO model. The question is whether DM does contain
information or only the way how the information is encoded. The Data
Model Language (SMI, XML, SPPI or MOF) is the way to express the
information, the DM is only the content.

12:30-13:40 Lunch break

A discussion went on upon the term: "interface".

The term was heavily used in IETF, but with a different meaning than
in ITU-T where interface is part of the functional architecture and it
is the boundary between managed and management entities, while in SNMP
world interface was mostly used in the IF-MIB tables. In the view of
ITU interfaces are between and/or within the Network Element - Network
- Service - Business layers. Interface is different between each of
these levels (interfaces between layers or between elements in the
same layer).

Discussion over introducing OO in IM/DM or not.
MIBs of OSI defined with GDMO look OO.
At IM level could be anything, but typically there should be an OO
approach at this layer. The DM layer doesn't have to be necessarily
OO. However, if DM can be OO, then IM has to map to various DMs,
therefore IM has to be OO. Otherwise how do you map something that is
not OO to a DM that is OO, which is a superset.

If one uses an OO language to have an IM and uses a non-OO language
for DM -> that will not work necessarilly well. One looses information
of a OO model while mapping it to a non-OO model. It won't work
necessarily well if using an non-OO IM and an OO based DM.

OOness is represented in UML; core concepts of UML are inheritance,
classes, attributes and methods, associations and cardinality.  UML is
a graphical notation and has a state model. ITU-T decided that they
want to use things that were considered important (eg. UML). There
could be used the existing languages and not defining a new one. UML
is not the perfect language. ITU-T has another language: SDL
(Specification and Definition Language), it is combined in a project
UML and SDL.

What is an OO model?
The key concepts of an OO model are:
	- abstraction & encapsulation
	- classes (attributes, methods, notifications, behaviour are included) 
	  & instances
	- inheritance
	- relationships
	- naming
Benefits and drawbacks of these characteristics were discussed.

Is it necessary that IM is OO? Yes, because then it is easier to map
it to the OO Data Model.  The formal representation of IM (whether it
is UML or a structured English) is OO, including all features.

There was a consensus upon the fact that people SHOULD use OO
techniques for specifying the IM (specification tools must be able to
do OO). Since the DM is to be choosen based on the protocol, it is not
necessarily OO.

Discussion over the definition of "control model". (CM)
What is a CM? Where it comes from? ITU-T world. ITU has a data -
control - management model.  It's a term to see if there's distinction
between action and data. Control means modifying the characteristics
of specific data. CM should be put in the "methods", instead of having
it between the other models (IM/DM).

15-15:30 Break

Discussions over the characteristics of IM:
	- scope
	- reusability
	- ease of use - focus is on customer
	- how easy you can define?
	- how easy you can implement?

Is there any experience what a good/bad scope is? Can we give examples
for good scope?  It is to be noticed that CIM has a very large scope
(tries to model a large spectrum of things).  Eventually it was agreed
upon that scope can be any of the following: DiffServ, element,
networks/services, generic high level base model, arbitrary systems,
networks/services/business, etc.

IM means reusability of terms, implementation doesn't count here. If
focusing on standards, implementing is not necessarily relevant.

Ease of implementation is indirectly useful.
Question: Is "ease to define" the following explanation: if you can
define high-level concepts can people on lower levels make
implementations? If you have good tools then it's an easy way, but the
model is also important.

What about ease of use? Is it for customers, managers of operators?
Customers demand that you have a consistent model for similar things
on the network to be managed. Ease of use is for the customer.  Is
this important to have it embedded in such a high level model?  It is
not necessarily part of it but it can be added without changing the
underlying protocol.

Discussion over the benefits of OO.
Reusability? Is it such a great attribute of OO?
In theory yes, in practice it's a question. On a long term it seems to
be not so great, because in the beginning there are a few classes and
you can use whatever you want, but on a long term when there are
classes everywhere it would take you too much time to find the base
class that you need and add an attribute. You just have to construct
your own new class.

OO may bring lots of other benefits. For example, an OO model can be
structured.  Summarizing the benefits of OO approach we could say that
in general OO is good, but we should not oversell it.
	- modularity
	- encapsulation: you can modify your implementation without 
	  affecting your interface.
	- inheritance: may not be the strongest benefit, it's a nice
          thing to have as long as you got very clear control over
          it. If the networking environment changes quickly then
          inheritance could be a problem. Inheritance adds
          dependencies and complexity. But it still can be a powerful
          tool. It is necesary to specify explicitly that it is
          dangerous.
	- abstraction
	- naming (in OO terms naming is scoped -> this is an advantage)
	- classes
	- instances
	- relationships: may be benefical
	- methods.

Relationships/methods:

Question: Would it be a good idea to have relationships like in OO
technology?  A relationship in a model documents that there is
something between two entities. One can have relationships just to
point out to attributes, or some other attributes of other entities.
An IM could define classes and relationships, in implementation you
have to define instances and pointers. In IM we don't have pointers
but we have relationships, in a DM we have pointers. Mapping between
these two can be difficult.

Summarizing relationships:

Juergen said that if you start doing it top down it's nice, but if you
have a list of existing things then it can be difficult. You run into
the risk that if you have methods in the IM then they would be heavily
used, creating in your system a lot of code and interactions. That is
something that we should be aware of.

SNMP was designed not to do methods. SNMP was developed from CMIP and
the action capability was deliberately removed because it added such a
complexity. One reason why methods are not in SNMP is because by
limiting the operation improves interoperability, which allows us to
define standards decently. Adding methods will impact
interoperability.

Methods at IM level are different from methods at DM level.
Interoperability issues arise only when adding methods at DM level. In
the process of mapping IM to a specific DM (eg. SNMP) we get rid of
the methods and map them to some (SNMP) specific mechanisms. But if we
are going to define methods in the IM, SNMP will be extended to
support methods.

There are now some MIBs that really need methods and operations. And
SMIng is extensible, this is one of its features. Methods have to be
added to SNMP, because they bring some ease of use, or else, CORBA
will take over.

Scenario: Suppose you have methods in both models, the result would be
lots of code and inefficient communication. Assume people would really
like the methods in the IM then they start using them, so you have
problems because of the inefficient code and communication. That would
be a good reason to convince the people to go to the new version of
SNMP.

****************************************
09-12-2000
****************************************

Discussion about the 3rd agenda item: is SMIng suited for an IM?  The
abstract of the SMIng document states that it is a data model. SMIng
has classes, inheritance, attributes, but no methods. There are events
that map to SNMP notifications. An event is part of a class, while in
SMI it is a standalone thing.

The current SMI was not written for IM. Is SMIng usable for
information modeling?
	- SMIng is a data definition language to replace SMIv2 and SPPI;
	  the underlaying protocols at this moment do not allow method 
	  invocation;
	- a replacement that merges two different languages;
	- it is not the goal of the language to be suited for IM, but it
	  is benefical;
	- it is a protocol independent data definition language.

Q: Does SMIng conform to the definition of IM that we had yesterday?
A: No, because there is no abstract representation of relationships.
 
Q: Would be difficult to map SMIng to IDL?
A: Not more than the mapping of SMIv2 to IDL. When SMIng was designed
   one of the things we had in mind was to make mappings to other DM 
   and protocols such as CORBA IDL not harder.

Reusability is needed in data definitions. SMIng was designed OO to
provide this. Another reason was structuring and ease of use.
Reusability was the main reason to make SMIng OO.

An IM language should be OO, and SMIng does not include methods. SMIng
is a good candidate for DM, but does not qualify for IM. In IM, it is
clear what is a method. We have clear parameters and we know their
semantics. In DM the clarity can be taken and mapped in whatever is
needed. However SMIng is moving to the right direction, and it can
become good IM.

The key elements for an IM should be:
	- OO
	- methods
	- relationships.

Q: What does an IM require in order to model relationships?
A: IM has a concept to describe relationships. You need more than
   pointers, you need a way to formally express relationships. You
   need something to describe and document the relationships.
   Relationships should not only be simulated, but they should be
   built into the language.

Q: Suppose relationships are easy to map to DM. Do we really need methods?
A: Methods would be something that you can always map to the DM, on
   the other hand Jurgen left it out from the SMIng because it would
   be inefficient with current IETF management protocols.  DMTF uses
   UML to present graphically the entities.  Use UML to represent
   something then discuss it, define the MOF. UML is the basics (class
   diagrams & relationships, no sequence diagrams). For modeling
   protocols we need sequence diagrams.  Sequence diagrams are useful
   for identifying the methods.

	+---------------+
	|		| /  "informal"/English	  _____  class diagram
	|      IM	|/			 /	 
	|		|\			/
	+---------------+ \  "formal"/UML  ------------  sequence diagram
	       /|\				\
	      /	| \				 \_____  use cases
	    ...	|  \
		|   \
	   SMIv2|    \SPPI
		|     \
	      MIBs   PIBs
	       / \
	      /   \                  DM
----------------------------------------
            /       \
          BER       BER

It is difficult to do UML without tools. OMG has copyright for UML. We
need ASCII representation of the UML diagrams, IETF has requirement
for ASCII. If the diagrams could be represented in ASCII many people
would be happy. Also need public domain implementations.

Q: Do we have to standardize the IM in the IETF?
A: Yes, IM should be standardized. And it has to be done in ASCII file
   for IETF.

10:45-11:30 Coffie break

Some UML-related ITU-T documents:
	M.3020 - TMN methodology focused on UML
	M.3208.3 - IM using UML
	M.3108.3 - DM using UML
	ITU-T 564/IETF ftp site
	ip address: 47.234.32.16
	user id: anon
	path: /itu_to_ietf/56

DMTF documents:
	www.dmtf.org/spec/cims.html (click on Schema v2.4)
	www.dmtf.org/educ/whit.html (white papers, recommended The CORE Model).

Pointers to IETF? Some relevant documents? WGs?
	SPPI draft, SMIng - RFCs.
	Policy Framework WG, SMIng WG, RAP WG (SPPI), IPSP WG.

OMG with CORBA:
OMG has Telecom Domain Task Force: TMN with CORBA activities. "CORBA
notification service" was produced. OMG did not produce network
models.
	- created corba models for trouble ticketing.
	- study group 4 has some proposals to use CORBA models.
	- docs are going for approval in january 2001.
OMG document: Common Information Structure

3GPP group approved a set of specification for config+fault mgmt, they
created DMs based on CORBA: 32.016, 32.111 docs.  3GPP uses aspects of
class diagrams, but the large part is their own creation, using
structured English.

ATM Forum has a protocol neutral model. ATM Forum uses structured
English.  TINA-C has some docs from 1996. Network Resource IM - TINA.

SUN has some work there (in 3 groups), has created an infrastructure
with object manager.

MS: Win Mgt Info: took the CIM schema and added OO design in a strange way.

CISCO: have DMTF models + extensions: CIM models are used. There was a demo.
www.snia.org

Intel, IBM are working also implementing CIM.

Enterasys is also working with CIM-LDAP stuff, but no success yet.

Q: How much of the work is used in the world? What was implemented and
   being used (deployment)?
A: Some ITU-T docs were just finished, no implementation yet.  Telco's
   in Europe implement and extend proprietary GMDO-CMIP stuff in an
   inconsistent way.

Conclusion: On IM level ITU-T has docs, but they are too new, no
implementations.

12:35-13:20 Lunch break

JS: =presentation of SMIng=
    example:
	module INET-FILTER {
		...
		class Filter {
			attribute DisplayString255 name
			...
		}
	}
	class InetFilter:Filter {
		attribute InetSubnet src;
		attribute InetSubnet dst;
		...
	}
	class InetSubnet {
		attribute InetNetworkEndpoint endpoint;
		attribute InetMask mask;
		...
	}

- multiple inheritance is not allowed (it is way to complicated for 
  the benefits it brings)
- attributes can be overwritten (there are some restrictions)

The XML schema is very similar to SMIng.  General discussion about
SMIv2 and SMIng. Similarities and differences, notifications, events,
mappings to CMIP, DIAMETER, SNMP.

	snmp {
		table ifTable {
			oid interfaces 2;
			index ();
			implements Interface {
				object ifIndex index;
				...
			}
		}
	}

There was a research proposal: mapping to CORBA.

14:50-15:20 Break

Finalization of the meeting:
	- questions answered, 
	- issues discussed.

Q: What to do with the output of this meeting? Are there other issues
   to be addressed?
A: Write an article for the SimpleTimes. It could be a good idea to
   use this output as an input for the NIM group. IM requirements
   document, discuss it on the mailing list.

15:50 Closing of the meeting.

Date: Mon, 15 Jan 2001 12:56:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> Juergen, I am already working on a BOF request for SMIng at
Andrea> IM2001.  I will get this submitted by Monday (the deadline).

Thanks for the info. So I stop my efforts of submitting a similar
proposal. ;-)

Andrea> Regarding policy-based networking, I worked on a prototype
Andrea> system a few years back at Intel, that used events as triggers
Andrea> to evaluate rules.  

[...]

Andrea> I too am personally interested in this and would love to
Andrea> discuss it.

Thanks for your feedback.

/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/>

Reply-To: "John Strassner" <[email-masked]>
From: "John Strassner" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [nmrg] FW: Meeting at the Bellevue office?
Date: Sat, 13 Jan 2001 05:35:39 -0800
Sender: [email-masked]

Sat-Sun would be easier for me

regards,
John
----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 12, 2001 3:47 AM
Subject: Re: [nmrg] FW: Meeting at the Bellevue office?

>
> >>>>> Andrea Westerinen writes:
>
> Andrea> We could meet at the Cisco sales office in
Bellevue.  The main
> Andrea> conference room holds 20.
>
> This sounds great to me. IM 2001 is 14-18 May 2001 (Mo -
Fr). I would
> personally prefer to hold the meeting at the end of the
week before IM
> or even over the weekend (since I will have to stay the
weekend in
> Seattle anyway in order to get an affordable flight).
>
> So what about meeting on May 11-12 (Fr - Sa)? Would
everybody be happy
> with this?
>
> /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: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] Proposed topics for the 9th NMRG meeting
Date: Fri, 12 Jan 2001 21:09:08 -0800
Importance: Normal
Sender: [email-masked]

Juergen, I am already working on a BOF request for SMIng at IM2001.  I will
get this submitted by Monday (the deadline).

Regarding policy-based networking, I worked on a prototype system a few
years back at Intel, that used events as triggers to evaluate rules.  The
events were specified as simple expressions where the variables were the
properties of CIM objects and/or were infrastructure events (ie, instance
creation/deletion).  In this way, we were able to generally specify the
rules, deploy this to systems, and still tie back to specific low-level
objects in the management system.  Initial tests were pretty successful.
The really hard thing was figuring out the right actions - either they were
simple actions/scripts, or you entered an AI engine and did forward/backward
chaining of rules (really hard to get right).  I too am personally
interested in this and would love to discuss it.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Friday, January 12, 2001 3:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting

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

JP> I suggest we assess where we stand w.r.t. information modeling. I
JP> have already begun working on this. Perhaps others would like to
JP> contribute, too.

Fine with me. I think we should first get the article on the table
which folks wanted to write about the last meeting. Based on the
article (which I think should be completed way before the May
meeting), we can see where we want to go next.

JP> I guess an update by Juergen on SMIng and SNMP over TCP would also
JP> be a good idea.

I hope that SNMP over TCP is done by May and in the RFC editor queue.

Similarily, SMIng is not an NMRG issue anymore. You should really
follow (and perhaps contribute to) the SMIng IETF working group.  On
the other hand, I can imagine that there are many people who usually
do not go to IETF meetings and who do not follow WG mailing lists that
may want to chat about the SMIng project. Perhaps it makes sense to
schedule an SMIng BOF at IM 2001 itself?

JP> I would be interested in discussing policy-based networking,
JP> especially how to link high-level policy MIBs/schemata with
JP> low-level network and systems management MIBs/schemata. Is this
JP> interest shared by other members of this group?

This is IMHO a tough question and something I am personally interested
in. I guess you can make $$$ if you have an answer to this problem. ;-)

/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/>

Date: Fri, 12 Jan 2001 12:54:53 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting
Sender: [email-masked]

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

JP> I suggest we assess where we stand w.r.t. information modeling. I
JP> have already begun working on this. Perhaps others would like to
JP> contribute, too.

Fine with me. I think we should first get the article on the table
which folks wanted to write about the last meeting. Based on the
article (which I think should be completed way before the May
meeting), we can see where we want to go next.

JP> I guess an update by Juergen on SMIng and SNMP over TCP would also
JP> be a good idea.

I hope that SNMP over TCP is done by May and in the RFC editor queue.

Similarily, SMIng is not an NMRG issue anymore. You should really
follow (and perhaps contribute to) the SMIng IETF working group.  On
the other hand, I can imagine that there are many people who usually
do not go to IETF meetings and who do not follow WG mailing lists that
may want to chat about the SMIng project. Perhaps it makes sense to
schedule an SMIng BOF at IM 2001 itself?

JP> I would be interested in discussing policy-based networking,
JP> especially how to link high-level policy MIBs/schemata with
JP> low-level network and systems management MIBs/schemata. Is this
JP> interest shared by other members of this group?

This is IMHO a tough question and something I am personally interested
in. I guess you can make $$$ if you have an answer to this problem. ;-)

/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/>

Date: Fri, 12 Jan 2001 12:47:25 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] FW: Meeting at the Bellevue office?
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> We could meet at the Cisco sales office in Bellevue.  The main
Andrea> conference room holds 20.

This sounds great to me. IM 2001 is 14-18 May 2001 (Mo - Fr). I would
personally prefer to hold the meeting at the end of the week before IM
or even over the weekend (since I will have to stay the weekend in
Seattle anyway in order to get an affordable flight).

So what about meeting on May 11-12 (Fr - Sa)? Would everybody be happy
with this?

/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/>

Date: Thu, 11 Jan 2001 10:36:16 -0500
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
Organization: AT&T Labs Research
To: NMRG <[email-masked]>
Subject: [nmrg] Proposed topics for the 9th NMRG meeting
Sender: [email-masked]

Hi,

I suggest we assess where we stand w.r.t. information modeling. I have 
already begun working on this. Perhaps others would like to contribute, too.

I guess an update by Juergen on SMIng and SNMP over TCP would also be a 
good idea.

I would be interested in discussing policy-based networking, especially how 
to link high-level policy MIBs/schemata with low-level network and systems 
management MIBs/schemata. Is this interest shared by other members of this 
group?

JP

Juergen Schoenwaelder wrote:
 >
 > We also agreed in Austin to organize a meeting next to the IM 2001
 > conference in May 2001. If some of you have concrete proposals where
 > and when to meet or topics we should address, please let me know so
 > that we can plan ahead.

Date: Tue, 9 Jan 2001 15:20:18 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] New Visions for Large-Scale Networks: Research and Applications 
Sender: [email-masked]

Those of you interested in long-term visions and research directions
may want to take a look at:

<http://www.eventmakeronline.com/sta/view/index.asp?meetingid=5>

The IRSG chair would actually like to see contributions from the
IRTF on that meeting. So if someone has a vision to write up...

/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: "Andrea Westerinen" <[email-masked]>
To: "Network Management Research Group" <[email-masked]>
Subject: [nmrg] FW: Meeting at the Bellevue office?
Date: Tue, 2 Jan 2001 19:23:10 -0800
Importance: Normal
Sender: [email-masked]
Status: O
Content-Length: 1175
Lines: 36

We could meet at the Cisco sales office in Bellevue.  The main conference
room holds 20.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, December 20, 2000 3:59 AM
To: Network Management Research Group
Subject: [nmrg] welcome new list members

I just added George Pavlou, Dave Sidor, Marcus Brunner and John
Strassner to the NMRG mailing list.

One of the next things we have to do is to get the minutes from the
last meeting finalzed and to start work on a paper which makes the
results produced by the last meeting accessible to a larger audience.

We also agreed in Austin to organize a meeting next to the IM 2001
conference in May 2001. If some of you have concrete proposals where
and when to meet or topics we should address, please let me know so
that we can plan ahead.

/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/>

Date: Tue, 02 Jan 2001 19:16:22 -0800
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Alarms, Events, and Notifications
Sender: [email-masked]
Status: O
Content-Length: 648
Lines: 19

HI,

The DISMAN WG is trying to add a new work item to their charter
to create a MIB module for alarm reporting based on X.733. I believe
that this is an important addition, but one that is difficult due in
a large part to terminology (and one that should not try to map
X.733 to SNMP).

Are there any good papers or books on management via exception
reporting? Are there any reviews or critiques of X.733?

Does anyone know of any EXACT implementation of X.733? (I've seen
several MIB modules based on concepts from X.733, and I've even
defined one myself. However, none I've seen were a direct translation
of X.733.)

Regards,
/david t. perkins