Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9QDiJDd025232 for ; Thu, 26 Oct 2006 15:44:19 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 455C85ADB4 for ; Thu, 26 Oct 2006 15:44:19 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06128-04; Thu, 26 Oct 2006 15:44:16 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 19E925ADCB; Thu, 26 Oct 2006 15:44:13 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 679A18177C7; Thu, 26 Oct 2006 15:43:09 +0200 (CEST) Date: Thu, 26 Oct 2006 15:43:09 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20061026134309.GA19769@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] draft utrecht meeting minutes X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 13:44:21 -0000 Hi, I have compiled the draft minutes of the Utrecht meeting and put the online: http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-021.txt Please check the minutes and send me any corrections you find important by November 10th. The minutes are rather detailed and we clearly need to work through them to turn them into a more readable summary. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9KBREIr031989 for ; Fri, 20 Oct 2006 13:27:15 +0200 Received: from harrington73653 (x176.flex.surfnet.nl[192.87.117.176]) by comcast.net (sccrmhc12) with SMTP id <20061020112713012001q3a1e>; Fri, 20 Oct 2006 11:27:13 +0000 From: "David Harrington" To: Date: Fri, 20 Oct 2006 13:24:50 +0200 Message-ID: <02ca01c6f43a$5c436900$b07557c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CB_01C6F44B.1FCC3900" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb0OhLuB5i+OS3IQCey6jjY5qTSAQ== X-IBRFilter-SpamReport: 0.367 () HTML_FONT_BIG,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Mailman-Approved-At: Fri, 20 Oct 2006 14:05:24 +0200 Subject: [nmrg] Vendor Breakout Session.doc X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 11:27:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CB_01C6F44B.1FCC3900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Vendor Breakout Session == VENDORS (room 10) == Claudio Bartolini [V] Petre Dini [V] Liam Fallon [V] Dan Romascanu [V] David Harrington [V] Giorgio Nunzi [V] Bert Wijnen [V] Jurgen Schonwalder [R] == Questions == [V1] Is research still needed on new technologies to transport management information, or can we rely on generic protocols and middleware technologies (such as Corba, Java, Web Services etc) to transfer such information. If research is still needed, what are the specific problems these new technologies have to solve? Discussion of vertical vs horizontal Distinction between device mgmt and upper-level protocols Q: Is research needed on any of the A: taxonomy could benefit from standardization A: SIP is reinventing mgmt - need to do end-to-end mgmt It would be useful to have documents discussing what you are likely to get wrong when you design your own extensions to NM technologies. Will web services work for NM? Research design patterns for NM work? Integration of what's in the market. Federation of spaghetti bowls is difficult because there are no guidelines for how to do it. Access control and identity mgmt - it has impacts on horizontal sharing of device info. DR: people do not know what protocols exist [V2] Is research still needed on languages for data models and/or information models, or research on core data / information models? If yes, what are the specific problems that need to be solved? Li: It seems every researcher want to create new languages. DR: There is a need to build a model for mgmt. Cl: language and data models do not exist, or do people not know that they exist? DR: people are being sent to use things like LDAP, but the specific language does not meet mgmt needs. JS: are the languages wrong? All: no, just different Li: the models are not expressed in an understandable format. BW: CF: data vs info models - data models needed for device-to-device; info is needed for humans to understand the concepts Data models languages must be more interoperable; it will be harder for operators to understand how to actually manage products using different data models. I don't care as much at the info modeling level about the formal design as long as it is capable of expressing the ideas. Pe: Cl: if I am starting to do a project, and want a survey of whether concepts have been expressed, I will find lots of info described in different approaches. Pe: if the concepts are described differently but in the end the concepts are the same, that is not a problem. BW: I don't think we ca ever do a complete info model; I'm not too worried about the info model. Pe: this is a never-ending topic to develop a full model, but it will never be achieved. JS: it can be possible to document some common stuff, Li: but at the last step, the last 5% never gets right. Pe: there are multiple well-documented info models, but they tend to be narrow scope of info (e.g. mission-critical software designs) Gi: one thing missing is the modeling has been done in separate areas. Info modeling has not been done in mgmt systems. Voip mgmt, etc. are not integrated into a full system. What is missing is the integration of mgmt solutions into a product where the pieces need to be integrated. There are good reasons to develop new info/data models, but consideration should be given to integrating with existing models. Li: maybe we don't need models but a framework within which to do modeling. The device-to-EMS and device-to-device communications should use a similar modeling. BW: that's a bottom-up approach compared to CIM/etc that do a top-down approach. DR: anything that has "universal" is suspect. Pe: from a bottom-up approach, how does a device know how to express the mgmt of features that are to be utilized by service providers (NMS above the EMS level)? What is needed in a box to operate the box (as compared to manage the box). DH: as we discuss what needs to be researched, I think we need to look at types of research and the timeframes they are associated with. Universities need to research the more theoretical issues, while vendors need to research more practical and immediately applicable research for products. Summary: skeptical about defining an info model to generate data models. Research on a universal info model isn't very needed. [V3] Is the current approach where devices have hundreds of MIB modules and many thousands of MIB objects, the right one, or do we need something else? If yes, which approaches are considered promising (programmable devices, high-level network element management functions integrated on devices, document-oriented approaches, ...)? Pe: what is already defined is not being implemented. Standard MIBs are agreed upon, but they are not implemented throughout the product, or across product lines, and are not implemented accurately. Are there other approaches needed? Nobody complains that this is wrong, only that it is not completely implemented. BW: do we think it is because customers Pe: complaints come from others' customers where the functionality is missing. Cl: is the effort of mib modeling related to what customers experience? It takes a lot of effort to implement mib modules, would it be best to link those things to the requirements? Which information is important to certain management functionality? There is little published info about what functionality is actually enabled when a specific MIB is implemented. It is very unclear what functionality applications will provide if a given MIB is available. Li: 3GPP resource models specify quite clearly how to do configuration. When config is done, an XML blob is sent to the device, and the device applies it to the element. DR: vendors seem to be doing SNMP support; vendors put their effort where the money is. Pe: engineering is based on meeting requirements. Cl: if Li: highly-detailed MIBs are not easy to work with. BW: SNMPCONF had the ability to write scripts and send them to the device to perform policy-based JS: Once customers can touch the box internally, it becomes a support problem for the vendor. BW,JS: some want to develop scripts but not touch the internals; [V4] What is needed to make a system manageable? What is in particular difficult or expensive from a device / system vendor point of view? Pe: this requires a book. BW: making a device manageable is different than what is need to make a system manageable. Pe: on the device, mgmt is local. Once you go beyond this, it becomes complicated. JS: Could this book be written in five years? Pe: what is the target? If a system is designed without mgmt in mind, it will not be manageable. You need some feature inside that permit this manageability. DR: it is even deeper; protocols need to be designed for manageability. Pe: what is need for protocols to be managed for system usage? BW: and if you're not careful, multiple devices need to managed using different protocols and different data models, and they need to work together in a system, then you have a problem. DR: maybe the IETF needs to play more stronger in enforcing this. BW: what mgmt is being used for service management vs device mgmt. Pe: is clock sync a requirement for system manageability? DR: if a protocol is designed to stateful, do states need to be observable externally? Pe: does a system need to be testable? If so, what must be visible? BW: loopback, rollback, diffserv, ping, continuity, etc. Pe: it become important doing correlation tracking whether a reporting device has a clock or not, how much skew might exist, etc. For some systems this is a must. [V5] How do you monitor research and capitalize research results? Pe: Juergen, how does the research community in Europe decide which projects should be done, and ow do they coordinate the many research topics to focus research, and make the results available? JS: the EU is a political org, and decisions are mad eon political basis. Cl: how does Emanics do this? JS: political thing. Cl: what types of deliverables Pe: I see two big outputs. If big corp is starting the project and embracing a particular result, how does it impact the economy? If students start-up new theoretical projects, Pe: Cisco monitors startups, invests in them, and acquires them Cl: HP is more likely to acquire research than to utilize internal research. BW: IBM also focuses on patents, Nobel prizes, prestige, etc. JS: if you want to measure what is happening outside Pe: most of my time is studying external research. BW: they look at individuals with the capability of being Nobel prize winners, etc. Cl: the Microsoft model acquires companies and that becomes a research division BW: research has become too commercial. They want it to be more applied research. With budget cuts, depts. Need to justify their work. Gi: competencies are established in research depts.; some results are useful. Li: some results are good; some are very good. Use case research works quite well. Gi: technology transfer Li: [V6] Is probabilistic management feasible? [V7] What SLA related research is needed? Do we need them and for what? [V8] What are the three most important research questions to be addressed in the next five years from a vendor perspective? DH: 1) what new products are needed? 2) which new markets can we move into? 3) how can we reduce costs? DR: what network management technologies Cl: cost control is an important area for research - what mgmt technologies can help to reduce Opex and CapEx? Pe: strategic decisions are not outsourced. In general, research is an appendix for exploring things outside the core competitive core. Pe: companies have maps of which MIBs are important for managing functionality. They just are not public. Pe: research is exploration. Gi: if we want to add new value, that is research. Li: how do you manage services across different product types? Three top questions: Gi: programmability for self-mgmt DR: requirements for protocols and requirements for data models All: Access control and identity mgmt and audit trails - it has impacts on horizontal sharing of device info. ------=_NextPart_000_02CB_01C6F44B.1FCC3900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vendor Breakout Session

Vendor Breakout Session

 

=3D=3D VENDORS (room 10) =
=3D=3D
 
Claudio =
Bartolini [V]
Petre =
Dini [V]
Liam =
Fallon [V]
Dan =
Romascanu [V]
David =
Harrington [V]
Giorgio Nunzi =
[V]
Bert Wijnen [V]
Jurgen =
Schonwalder [R]
 
=3D=3D =
Questions =3D=3D
 
[V1] Is research still =
needed on new technologies to =
transport
     =
management information, or can we rely on generic protocols =
and
     =
middleware technologies (such as Corba, Java, Web Services =
etc)
     to =
transfer such information. If research is still needed, =
what
     are =
the specific problems these new technologies have to =
solve?
 


Discussion of vertical vs horizontal



           =
; Distinction
between device mgmt and upper-level protocols



 



Q: Is research needed on any of the 



A: taxonomy could benefit from standardization



A: SIP is reinventing mgmt – need to do end-to-end mgmt =




 



It would be useful to have documents discussing what you are =
likely to
get wrong when you design your own extensions to NM =
technologies.



Will web services work for NM?



Research design patterns for NM work?



 
Integration of what’s in the market. =
Federation of spaghetti bowls is difficult because there are no =
guidelines for how to do it.
 
Access =
control and identity mgmt – it has impacts on horizontal sharing =
of device info.
 
DR: =
people do not know what protocols exist
 
 
[V2] Is research still =
needed on languages for data models =
and/or
     =
information models, or research on core data / information =
models?
     If =
yes, what are the specific problems that need to be =
solved?
 
 
Li: It =
seems every researcher want to create new languages. =

DR: There =
is a need to build a model for mgmt.
Cl: =
language and data models do not exist, or do people not know that they =
exist?
DR: =
people are being sent to use things like LDAP, but the specific language =
does not meet mgmt needs.
JS: are =
the languages wrong?
All: no, =
just different
Li: the =
models are not expressed in an understandable =
format.
BW: CF: =
data vs info models – data models needed for device-to-device; =
info is needed for humans to understand the =
concepts
Data =
models languages must be more interoperable; it will be harder for =
operators to understand how to actually manage products using different =
data models. I don’t care as much at the info modeling level about =
the formal design as long as it is capable of expressing the =
ideas.
Pe: =

Cl: if I =
am starting to do a project, and want a survey of whether concepts have =
been expressed, I will find lots of info described in different =
approaches.
Pe: if =
the concepts are described differently but in the end the concepts are =
the same, that is not a problem.
BW: I =
don’t think we ca ever do a complete info model; I’m not too =
worried about the info model. 
Pe: this =
is a never-ending topic to develop a full model, but it will never be =
achieved.
JS: it =
can be possible to document some common stuff, =

Li: but =
at the last step, the last 5% never gets =
right.
Pe: there =
are multiple well-documented info models, but they tend to be narrow =
scope of info (e.g. mission-critical software =
designs)
Gi: one =
thing missing is the modeling has been done in separate areas. Info =
modeling has not been done in mgmt systems. Voip mgmt, etc. are not =
integrated into a full system. What is missing is the integration of =
mgmt solutions into a product where the pieces need to be integrated. =
There are good reasons to develop new info/data models, but =
consideration should be given to integrating with existing =
models.
Li: maybe =
we don’t need models but a framework within which to do modeling. =
The device-to-EMS and device-to-device communications should use a =
similar modeling.
BW: =
that’s a bottom-up approach compared to CIM/etc that do a top-down =
approach.
DR: =
anything that has “universal” is =
suspect.
 
Pe: from =
a bottom-up approach, how does a device know how to express the mgmt of =
features that are to be utilized by  service providers (NMS above =
the EMS level)? What is needed in a box to operate the box (as compared =
to manage the box). 
 
DH: as we =
discuss what needs to be researched, I think we need to look at types of =
research and the timeframes they are associated with. Universities need =
to research the more theoretical issues, while vendors need to research =
more practical and immediately applicable research for =
products.
 
Summary: =
skeptical about defining an info model to generate data models. Research =
on a universal info model isn’t very =
needed.
 
 
 
[V3] Is the current approach =
where devices have hundreds of MIB
     =
modules and many thousands of MIB objects, the right one, or =
do
     we =
need something else? If yes, which approaches are =
considered
     =
promising (programmable devices, high-level network =
element
     =
management functions integrated on devices, =
document-oriented
     =
approaches, ...)?
 
Pe: what =
is already defined is not being implemented. Standard MIBs are agreed =
upon, but they are not implemented throughout the product, or across =
product lines, and are not implemented accurately. Are there other =
approaches needed? Nobody complains that this is wrong, only that it is =
not completely implemented.
BW: do we =
think it is because customers 
Pe: =
complaints come from others’ customers where the functionality is =
missing.
Cl: is =
the effort of mib modeling related to what customers experience? It =
takes a lot of effort to implement mib modules, would it be best to link =
those things to the requirements? Which information is important to =
certain management functionality?
 
There is =
little published info about what functionality is actually enabled when =
a specific MIB is implemented. It is very unclear what functionality =
applications will provide if a given MIB is =
available.
 
Li: 3GPP =
resource models specify quite clearly how to do configuration. When =
config is done, an XML blob is sent to the device, and the device =
applies it to the element.
 
DR: =
vendors seem to be doing SNMP support; vendors put their effort where =
the money is.
Pe: =
engineering is based on meeting requirements. =

Cl: if =

Li: =
highly-detailed MIBs are not easy to work =
with.
BW: =
SNMPCONF had the ability to write scripts and send them to the device to =
perform policy-based 
JS: Once =
customers can touch the box internally, it becomes a support problem for =
the vendor.
BW,JS: =
some want to develop scripts but not touch the internals; =

 
 
[V4] What is needed to make =
a system manageable? What is in =
particular
     =
difficult or expensive from a device / system vendor point =
of
     =
view?
 
Pe: this =
requires a book. 
BW: =
making a device manageable is different than what is need to make a =
system manageable.
Pe: on =
the device, mgmt is local. Once you go beyond this, it becomes =
complicated.
JS: Could =
this book be written in five years?
Pe: what =
is the target? If a system is designed without mgmt in mind, it will not =
be manageable. You need some feature inside that permit this =
manageability.
DR: it is =
even deeper; protocols need to be designed for manageability. =

Pe: what =
is need for protocols to be managed for system usage? =

BW: and =
if you’re not careful, multiple devices need to managed using =
different protocols and different data models, and they need to work =
together in a system, then you have a =
problem.
DR: maybe =
the IETF needs to play more stronger in enforcing =
this.
BW: what =
mgmt is being used for service management vs device mgmt. =

Pe: is =
clock sync a requirement for system =
manageability?
DR: if a =
protocol is designed to stateful, do states need to be observable =
externally?
Pe: does =
a system need to be testable? If so, what must be =
visible?
BW: =
loopback, rollback, diffserv, ping, continuity, =
etc.
Pe: it =
become important doing correlation tracking whether a reporting device =
has a clock or not, how much skew might exist, etc. For some systems =
this is a must.
 
 
[V5] How do you monitor =
research and capitalize research =
results?
 
Pe: =
Juergen, how does the research community in Europe decide which projects =
should be done, and ow do they coordinate the many research topics to =
focus research, and make the results =
available?
JS: the =
EU is a political org, and decisions are mad eon political =
basis.
Cl: how =
does Emanics do this?
JS: =
political thing.
Cl: what =
types of deliverables 
Pe: I see =
two big outputs. If big corp is starting the project and embracing a =
particular result, how does it impact the economy? If students start-up =
new theoretical projects, 
 
Pe: Cisco =
monitors startups, invests in them, and acquires =
them
Cl: HP is =
more likely to acquire research than to utilize internal =
research.
BW: IBM =
also focuses on patents, Nobel prizes, prestige, =
etc.
JS: if =
you want to measure what is happening =
outside
Pe: most =
of my time is studying external research.
BW: they =
look at individuals with the capability of being Nobel prize winners, =
etc.
Cl: the =
Microsoft model acquires companies and that becomes a research =
division
BW: =
research has become too commercial. They want it to be more applied =
research. With budget cuts, depts. Need to justify their =
work.
Gi: =
competencies are established in research depts.; some results are =
useful. 
Li: some =
results are good; some are very good. Use case research works quite =
well.
Gi: =
technology transfer
Li: =

 
 
[V6] Is probabilistic =
management feasible?
 
 
 
[V7] What SLA related =
research is needed? Do we need them and for =
what?
 
 
 
[V8] What are the three most =
important research questions to be
     =
addressed in the next five years from a vendor =
perspective?



 



DH: 1) what new products are needed? 2) which new markets can we =
move
into? 3) how can we reduce costs?



 



DR: what network management technologies 



Cl: cost control is an important area for research – what =
mgmt
technologies can help to reduce Opex and CapEx?



Pe: strategic decisions are not outsourced. In general, research =
is an
appendix for exploring things outside the core competitive =
core.



Pe: companies have maps of which MIBs are important for managing
functionality. They just are not public.



Pe: research is exploration. 



Gi: if we want to add new value, that is =
research.



Li: how do you manage services across different product =
types?



 



Three top questions:



Gi: programmability for self-mgmt



DR: requirements for protocols and requirements for data =
models



All: Access control and identity mgmt and audit trails – =
it has
impacts on horizontal sharing of device info.



 
------=_NextPart_000_02CB_01C6F44B.1FCC3900-- Received: from redflag.CS.Princeton.EDU (redflag.CS.Princeton.EDU [128.112.136.72]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9HAWKjq023912 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 17 Oct 2006 12:32:21 +0200 Received: from LapCat (h-64-105-4-162.atlngahp.covad.net [64.105.4.162]) (authenticated bits=0) by redflag.CS.Princeton.EDU (8.13.7/8.13.7) with ESMTP id k9HAWGZD013875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 17 Oct 2006 06:32:19 -0400 (EDT) From: "Jennifer Rexford" To: Date: Tue, 17 Oct 2006 06:32:18 -0400 Organization: Princeton University Message-ID: <007f01c6f1d7$87352eb0$d7b1060a@LapCat> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acbx14VHI+mFHUyaQSaeGEADqWrERQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=-1 adultscore=0 adjust=0 reason=safe engine=3.0.0-0609290000 definitions=main-0610170000 X-IBRFilter-SpamReport: -0.904 () BAYES_30 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Mailman-Approved-At: Wed, 18 Oct 2006 08:08:43 +0200 Subject: [nmrg] Workshop on Internet Network Management X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jrex@CS.Princeton.EDU List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 10:32:23 -0000 Hi folks, I thought the people on this list might be interested in the program of a workshop on Internet network management that was held at SIGCOMM'06 in Pisa last month. See http://research.microsoft.com/~dmaltz/inm06/program.html for details. -- Jen Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9H8Sljp002921 for ; Tue, 17 Oct 2006 10:28:47 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A8CE55ADAB for ; Tue, 17 Oct 2006 10:28:47 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02897-08; Tue, 17 Oct 2006 10:28:44 +0200 (CEST) Received: from boskop.local (unknown [10.71.237.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 612295AD63; Tue, 17 Oct 2006 10:23:40 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 90765810D6A; Tue, 17 Oct 2006 10:23:38 +0200 (CEST) Date: Tue, 17 Oct 2006 10:23:38 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20061017082338.GB11200@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] workshop preparation X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 08:28:49 -0000 Hi, the workshop is coming up soon and I am looking forward to be in Utrecht and to see many of you person. A rough agenda has been posted on the meeting web page a while ago. On Thursday, we will give every participant some 10 minutes to explain his/her research statement. We will provide a reader with all the statements on paper so people can use the printouts to make notes or mark questions. The idea of this first round is to explain and discuss the submitted research statements so that we all understand them. It is perfectly fine to do round this without prepared slides (in fact we prefer to run this without slides in order to not loose a lot of time with switching notebooks and stuff like that). During the afternoon, we will break-out in smaller groups to address specific questions. We (the organizers) will prepare some questions for the various groups and I am sure more questions will come up when we go through the position statements together. On Friday, we will start with a short summary presentation produced by the smaller groups and afterwards we will discuss the conclusions and try to produce a kind of a research roadmap. Have a safe trip to Utrecht! /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9G95eEY004377 for ; Mon, 16 Oct 2006 11:05:40 +0200 Received: from leeuwarden.cs.utwente.nl (leeuwarden.ewi.utwente.nl [130.89.10.54]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9G95aFQ029357; Mon, 16 Oct 2006 11:05:36 +0200 (MEST) Received: from [152.81.3.41] (aiko.loria.fr [152.81.3.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leeuwarden.cs.utwente.nl (Postfix) with ESMTP id 2596837C7FD; Mon, 16 Oct 2006 11:05:38 +0200 (CEST) Message-ID: <45334B61.3010506@utwente.nl> Date: Mon, 16 Oct 2006 11:05:37 +0200 From: Aiko Pras User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Harrington , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Re: Nmrg meeting References: <02bd01c6ef07$f8cb7250$0600a8c0@china.huawei.com> <20061014080213.GA6184@noname> In-Reply-To: <20061014080213.GA6184@noname> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.538 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 16 Oct 2006 11:05:37 +0200 (MEST) X-IBRFilter-SpamReport: -1.524 () BAYES_01 Cc: X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 09:05:42 -0000 Hi David Juergen Schoenwaelder wrote: > On Fri, Oct 13, 2006 at 04:41:33PM -0400, David Harrington wrote: > >> Will we be able to have a podcast of the NMRG meeting? I didn't plan that. Since I expect quite some "unstructured" discussion, the creation of such podcast would require to have microphones for each participant. > I assume it only makes sense > to record parts of the meeting since a two day workshop podcast might > exceed what human souls can reasonably handle. ;-) I agree with that. Unless the podcast is used for people who, for some kind of disease, cannot get asleep. ;-) Bye Aiko Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9E82JEY001296 for ; Sat, 14 Oct 2006 10:02:19 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 639075AD6B; Sat, 14 Oct 2006 10:02:19 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12002-01; Sat, 14 Oct 2006 10:02:16 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8AF8D5ACF6; Sat, 14 Oct 2006 10:02:16 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 235E780EB88; Sat, 14 Oct 2006 10:02:13 +0200 (CEST) Date: Sat, 14 Oct 2006 10:02:13 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20061014080213.GA6184@noname> Mail-Followup-To: David Harrington , nmrg@ibr.cs.tu-bs.de References: <02bd01c6ef07$f8cb7250$0600a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02bd01c6ef07$f8cb7250$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Re: Nmrg meeting X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2006 08:02:21 -0000 On Fri, Oct 13, 2006 at 04:41:33PM -0400, David Harrington wrote: > Will we be able to have a podcast of the NMRG meeting? Aiko is our "master of podcasting" - so he will be able to comment on the feasibility from the technical side. I assume it only makes sense to record parts of the meeting since a two day workshop podcast might exceed what human souls can reasonably handle. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k9DKhqEY009425 for ; Fri, 13 Oct 2006 22:43:52 +0200 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc12) with SMTP id <20061013204351012002eqode>; Fri, 13 Oct 2006 20:43:51 +0000 From: "David Harrington" To: , Date: Fri, 13 Oct 2006 16:41:33 -0400 Message-ID: <02bd01c6ef07$f8cb7250$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbvB+STitjflOXDSvCuVR43bXWjiQ== X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Mailman-Approved-At: Sat, 14 Oct 2006 09:58:38 +0200 Cc: Subject: [nmrg] Nmrg meeting X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2006 20:43:54 -0000 Hi, Will we be able to have a podcast of the NMRG meeting? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id k97NjNm6022948 for ; Sun, 8 Oct 2006 01:45:23 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 31AED581A3 for ; Sun, 8 Oct 2006 01:45:23 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00487-06; Sun, 8 Oct 2006 01:45:20 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 73F745631A; Sun, 8 Oct 2006 01:45:20 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id DD0158082AE; Sun, 8 Oct 2006 01:45:19 +0200 (CEST) Date: Sun, 8 Oct 2006 01:45:19 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20061007234519.GC383@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] nmrg/emanics workshop position statements and agenda online X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.4 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2006 23:45:24 -0000 Hi, I have linked the position statements I have received so far to the meeting web page: http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2006/utrecht/ I took the freedom to edit the texts so that they all share the same plain ASCII format. If I screwed up your statement, please drop me a note and I will fix things. We (the organizers) like to invite you to read these statements and to also post questions / comments on this list if you find statements unclear or you have other thoughts on what you have read. We have also just posted a draft agenda on the web page. Our idea is to review the position statements on Thursday and then break out into groups to work on specific questions. On Friday, we plan to discuss the results produced by the various groups and then try to converge towards a common conclusion where network management research should focus during the next say 5 year. /js PS: Some position statements are still missing; I still like to receive them... -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany