Subject: Re: [nmrg] Re: Next NMRG meeting
From: Aiko Pras <[email-masked]>
To: [email-masked]
Date: Wed, 28 Jun 2006 17:23:42 +0200
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Juergen Schoenwaelder wrote:
> Please let me know if you have any comments on the planned meeting.

Looks interesting to me ;-)
I'll try to follow via the Internet.

Aiko

Date: Wed, 28 Jun 2006 17:16:32 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked], Aiko Pras <[email-masked]>
Cc: Aiko Pras <[email-masked]>
Subject: [nmrg] Re: Next NMRG meeting
Reply-To: [email-masked]

On Wed, Jun 28, 2006 at 09:44:35AM +0200, Aiko Pras wrote:
 
> As opposed to my previous email on the list, I decided not to attend the 
> IETF-NMRG meeting in Montreal. I've been traveling too much this year; 
> it is time to do some work ;-)

Since Aiko won't make it to Montreal and we are not able to carry one
of our graduate students to Montreal either, I will have to do more
presentations myself. I discussed with Aiko the consequences and we
came up with the following updated agenda proposal:

Monday July 10, 2006, Room 519A:

17:40 	Administrivia				Chair(s)
17:45 	NMRG Status Report '2006		Juergen Schoenwaelder
18:00 	SNMP Traffic Measurements Overview 	Juergen Schoenwaelder
18:20 	Initial Results				Juergen Schoenwaelder
18:40 	Discussion of Measurement Activities 	Everybody
19:20 	Future Work				Everybody
19:40 	Wrapup					Chair(s)

David Harrington is going to chair the meeting - thanks to you and the
others who offered help.

Since we expect to have some people walking in who do not follow the
NMRG closely, I like to spend some 15 minutes at the beginning to give
a status report what the NMRG has been doing in the past and how I
believe how it works right now.

I will then present the work that is going on (although not highly
visible on the mailing list) to collect SNMP traces from production
networks, to build tools to process them, and analyze the output
generated. Afterwards, I will report first analysis results from some
of the traces we already have.

Next to general feedback on the work going on, one particular goal is
also to get people excited who run production networks or who have
good contacts to people who run production networks to help us achieve
a wider coverage of different types of production networks. We are
also interested to learn about new questions that might be answered by
analyzing the traces and which are not yet covered in the measurement
ID. Quite some discussion time has been allocated into the schedule
for this.

Before we wrap up, I also like to get input on potential future work
items for the NMRG (and of course we also like new volunteers). One
concrete topic is a workshop which has been proposed to organize
together with a European project focusing on network and service
management research where we like to identify and document the most
important research challenges in this area to be tackled in the next 5
years or so.

Please let me know if you have any comments on the planned meeting or
if you feel you need to have some time allocated in the schedule.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 28 Jun 2006 09:44:35 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Cc: 
Subject: [nmrg] Next NMRG meeting

Hi

As opposed to my previous email on the list, I decided not to attend the 
IETF-NMRG meeting in Montreal. I've been traveling too much this year; 
it is time to do some work ;-)

Bye

Aiko

From: "David B Harrington" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] IETF66 meeting
Date: Tue, 27 Jun 2006 11:05:10 -0400
Cc: 

Humph! I don't know what page I was looking at before or whether I was
searching the wrong way, but somehow I missed it. Oh well.

Thanks,
dbh 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 10:57 AM
> To: David B Harrington; [email-masked]
> Subject: RE: [nmrg] IETF66 meeting
> 
> What agenda are you looking at? I see nmrg scheduled for 
> Monday evening
> (last two sessions) at
> https://datatracker.ietf.org/public/meeting_agenda_html.cgi?me
> eting_num=
> 66. 
> 
> Regards,
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of David B 
> Harrington
> > Sent: Tuesday, June 27, 2006 4:57 PM
> > To: [email-masked]
> > Subject: [nmrg] IETF66 meeting
> > 
> > Hi,
> > 
> > I didn't find nmrg on the final ietf66 agenda. Did it get bumped?
> > 
> > David Harrington
> > [email-masked]
> > [email-masked]
> > [email-masked]
> > 
> > --
> > !! This message is brought to you via the `nmrg' mailing list.
> > !! Please do not reply to this message to unsubscribe. To 
> > unsubscribe or adjust !! your settings, send a mail message 
> > to <[email-masked]> !! or look at 
> > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > 
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] IETF66 meeting
Date: Tue, 27 Jun 2006 17:57:11 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, <[email-masked]>
Cc: 

What agenda are you looking at? I see nmrg scheduled for Monday evening
(last two sessions) at
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=
66. 

Regards,

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Tuesday, June 27, 2006 4:57 PM
> To: [email-masked]
> Subject: [nmrg] IETF66 meeting
> 
> Hi,
> 
> I didn't find nmrg on the final ietf66 agenda. Did it get bumped?
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> 
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Date: Tue, 27 Jun 2006 09:57:07 -0400
Subject: [nmrg] IETF66 meeting

Hi,

I didn't find nmrg on the final ietf66 agenda. Did it get bumped?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

content-class: urn:content-classes:message
Date: Mon, 19 Jun 2006 09:32:42 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, "Ops-Nm \(E-mail\)" <[email-masked]>, <[email-masked]>
Cc: 
Subject: [nmrg] FW: I-D ACTION:draft-harrington-text-mib-doc-template-00.txt

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6936A.2B0189D4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Friday, June 16, 2006 10:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-harrington-text-mib-doc-template-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: A Template for Documents Containing a MIB
Module
	Author(s)	: D. Harrington
	Filename	: draft-harrington-text-mib-doc-template-00.txt
	Pages		: 10
	Date		: 2006-6-16
=09
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing [TODO].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-harrington-text-mib-doc-templa
te-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-harrington-text-mib-doc-template-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-harrington-text-mib-doc-template-00.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C6936A.2B0189D4
Content-Type: application/octet-stream;
	name="ATT895148.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT895148.TXT
Content-Disposition: attachment;
	filename="ATT895148.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTE2MTQ0MDQzLkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcnJpbmd0b24tdGV4dC1t
aWItZG9jLXRlbXBsYXRlLTAwLnR4dA0K

------_=_NextPart_001_01C6936A.2B0189D4
Content-Type: application/octet-stream;
	name="draft-harrington-text-mib-doc-template-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-harrington-text-mib-doc-template-00.URL
Content-Disposition: attachment;
	filename="draft-harrington-text-mib-doc-template-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1oYXJyaW5ndG9uLXRleHQtbWliLWRvYy10ZW1wbGF0ZS0wMC50eHQNCg==

------_=_NextPart_001_01C6936A.2B0189D4
Content-Type: text/plain;
	name="ATT895149.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT895149.txt
Content-Disposition: attachment;
	filename="ATT895149.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C6936A.2B0189D4--

From: Michael Alexander <[email-masked]>
Subject: Re: [nmrg] IESG thoughts on network management
Date: Sun, 18 Jun 2006 22:19:26 +0200
To: Benoit Claise <[email-masked]>
Cc: Margaret Wasserman <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "David T. Perkins" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]

that makes a lot of sense since it would emphasize in the first place  
which objects are managed and the underlying data model/framework.  
The access method (i.e. the protocol) MAY be listed. The protocol  
would therefore not continue to serve as the  shortcut around  
describing managability in a structured way.

- Michael
On 17.06.2006, at 22:19, Benoit Claise wrote:

> David, All,
>> HI,
>>
>> Very interesting thread, with many sub issues, so here goes:
>>
>> 1) There was a lot of terminology used in the IESG report
>>    that I wasn't quite sure of the meaning. Dan - can you
>>    provide a few short descriptions.
>> 2) I looked at JP's paper. Note that it was published
>>    in 1999. Many of the issues remain. However, it could
>>    be republished today with AJAX instead of applets,
>>    and use XML to transport management info. The result
>>    would be timely. There are parts that I agree with,
>>    and others I don't, but maybe JP and I should have
>>    a private conversation.
>> 3) On modelling, I've been singing the same tune for
>>    many years. At the highest level, management is all
>>    about deciding what you want done, configuring the
>>    system to do it, monitoring the system to make sure
>>    you are getting done what you wanted, and, if needed,
>>    changing the system configuration to better match
>>    what you wanted done. To accompish management
>>    (again at a high level), the following management
>>    operations are performed: create and delete instances
>>    of management info, performance management actions,
>>    retrieve values of management information, and
>>    asynch report events. Different management protocols
>>    have different specific ways that operations are
>>    performed and management information is described.
>>    For example, in SNMP, there is no explicit "perform
>>    action" operation. However, "action operations" are
>>    supported by SNMP by "clever" definitions of
>>    management info using the limited operations
>>    in SNMP. Creating those clever definitions,
>>    or reading someone else's and getting back to
>>    the action are preety easy tasks for "MIB
>>    experts", but not for casual SNMP users.
>>    Skipping a few steps in this example to get
>>    to the point... All management protocols that I've
>>    seen have their strenghts and weaknesses. But
>>    all must address the high level uses of
>>    management.
>> 4) This is sort of a .
>>    The data types in SNMP's SMI have been stalled since
>>    the early 90's. Please, lets' add "unsignedInt64",
>>    "signedInt64", "Float and Double (using IEEE encoding
>>    and semantics, NOT ASN.1 encoding and semantics)",
>>    and "discriminated unions". I believe that this
>>    has been one of the top reasons why people don't
>>    want to using SNMP's SMI for data modelling.
>>    Another top reason is the limitations in the
>>    identification of instances (translated - indexing),
>>    and in describing in programmic way the relationships
>>    between instances.
>> 5) Another theme I've been singing for many years is
>>    the need for a team in developing management solutions.
>>    That is, it is "crazy talk" or maybe "crazy think" to
>>    believe that one person knows 1) the technology,
>>    2) how the technology is used (and how it fails)
>>    in deployments, 3) how to efficiently and cost
>>    effectively manage devices containing the technology
>>    (this means design and write code for "management apps"
>>    and "instrumentation"). The result that I've seen
>>    is that different standards groups are dominated
>>    by different sorts of experts, and they like to
>>    use management protocols and schemas for management
>>    info that matches their area of background (and bias).
>>
> Good point. This is the same situation on the customer sides: the  
> guys deploying the technology are not the ones managing it.
> I've always been wondering why we had to wait for so long for the  
> MPLS MIBs, long after the MPLS protocol design. Maybe that's the  
> reason?
> My point is that manageability is most of the time an after-thought.
>
> What about this simple solution? Add a compulsory "Manageability  
> Considerations" section in any IETF draft.
> Note: I remember that this idea was discussed a couple of years ago  
> on one of the IETF mailing list...
> Let me take an analogy. I'm certainly not a security expert, but  
> for each of my draft, I have either to investigate the security  
> aspects, or get security experts to bring their experience in the  
> draft. The "Manageability Considerations" should work the same.
> Possible options are:
>     - manageability is done via X and Y
>     - no management because .... (there is maybe a reason why IP  
> phone are not managed via SNMP, to come back to Dan's example)
>     - management defined in draft/RFC ...
>     - monitoring is required but configuration is not.
>     - etc...
>
> Now, imposing a protocol and a data model in this section is a  
> different story.
> However, if protocol designers would think (a little bit) of  
> management (fault, configuration, accounting, performance) at the  
> design time, that would be an achievement already IMHO.
>
> Regards, Benoit.
>
>> I'm stopping now. This message is already too long.
>>
>> Enjoy,
>> /david t. perkins
>>
>> On Mon, 12 Jun 2006, Margaret Wasserman wrote:
>>
>>> Hi Bert,
>>>
>>>
>>>> I agree that a mixture of protocols for management on a
>>>> single device easily starts to look like a spagetthi bowl and
>>>> may make (even rudimentary) management if the device
>>>> difficult/problematic.
>>>>
>>>> At the other hand, if a WG is not interested and does not do
>>>> a good job at designing a MIB module, then that is not
>>>> helpfull either. So... what do you propose?
>>>>
>>> I do not hold the view that "There must be only one".  However, I  
>>> don't
>>> consider "Let a thousand flowers bloom" to be the only alternative.
>>>
>>> If there is no one protocol that will meet the requirements of  
>>> both protocol
>>> designers and operators/administrators, then I think that we need  
>>> to have
>>> more than one.  And, in fact, we already have more than one.  I  
>>> also think
>>> we need to understand _why_ we have more than one management  
>>> protocol into
>>> the IETF protocol suite and have some coherent idea of where and  
>>> when each
>>> management protocol will be used.  Ideally, we would also  
>>> understand how to
>>> access (some of?) the same management information using different  
>>> protocols,
>>> as appropriate based on the role and purpose of each protocol.
>>>
>>> I am confused by the way the IESG's conclusion ties together data  
>>> modeling
>>> and the choice of management protocol.  I'm concerned we'll get  
>>> into a
>>> situation where the "best" data modeling language for a given  
>>> protocol will
>>> simply be the language with which the authors are most familiar  
>>> or the one
>>> they'd most like to learn, and that little or no thought will be  
>>> given to
>>> how the complete system (consisting of this protocol and several  
>>> related
>>> protocols) will be managed.  I consider choosing how a protocol  
>>> will be
>>> managed based on which data modeling language is most convenient  
>>> to be the
>>> opposite of designing a system for manageability.
>>>
>>> If I had to choose my Nirvana, it wouldn't be that everyone in  
>>> the IETF
>>> would use whatever data modeling language and management protocol  
>>> they
>>> preferred, it would be finding a way to define our information  
>>> models in a
>>> more management-protocol-agnostic fashion (hopefully earlier in  
>>> the protocol
>>> definition process) and being able to map that model (in as  
>>> deterministic a
>>> way as possible) onto the various data models for the various  
>>> management
>>> protocols.
>>>
>>> I'm not sure what it would mean to shift from "management by  
>>> SNMP" to
>>> "design for manageability", nor do I understand what the IESG  
>>> meant when
>>> they said that SNMP is "stuck on a single vertical model", so  
>>> there may be
>>> parts of the IESG's conclusions that I am failing to understand  
>>> properly.
>>> Dan, could you offer a bit more insight into what problems the  
>>> IESG was
>>> trying to solve and what you intend to change (if anything) based  
>>> on these
>>> conclusions?
>>>
>>> Margaret
>>>
>>>
>>
>
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To  
> unsubscribe or adjust
> !! your settings, send a mail message to <[email-masked] 
> bs.de>
> !! or look at http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/ 
> listinfo/nmrg.

Content-class: urn:content-classes:message
Date: Sun, 18 Jun 2006 10:36:58 +0100
From: "Jeffry" <[email-masked]>
To: [email-masked]
Subject: [nmrg] Woman wants man is able

------_=_NextPart_001_01C69139.55268311
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C69139.55268311"

------_=_NextPart_002_01C69139.55268311
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

  <http://uvrbkf.outpigs.com/?76312634>=20
  oBPIjOLDCe0u8TzUQ9J73r64yxUGJPOpizCauoFsIUCXR2SsNXd67P9zJJfSBROKfyw4xqGwLgkN
  PBinwcpwsd74FW67Ia5qArWWk5E316gRwfHRkJjeACOEkdnHmfkOxheKVPPG0bHuHvaUUA1EShhZ7Lf
  iFRiO0egKJSvA5WyECfTynSe2RYamxIszj1oqnPfaMITPQmYBFS9LAL9baKkLUnWb0k0xr
  1Lm4PlVL2H2HAuHhBBTZi52ineiEDjMWqcNbuiddPoZdD5egy3dBgoVbAedOePclWYj7KZY
  ryHZOzwwuuLy06vOdsi0SJMiLMRQzcm9ynre8L4UvKiN8W1TPqdTL52RV49gduyldncRf5yU
  dmyefCdvnhXX6yKOd40tBgocXMYQv7DtiA1lBARGqQuRH3FbIxzDCeP6fDjHnYdmfTnonFVVHKinA
  62JSzNmQE4faBZkU7FeanUijgsKYKYRHlEEyxW1idrLLhdbjyLV5Ez48bvhLOVtxFuzRaH8c2AKtWb
  9ah3b6YtHZ1RUwBG0g8RKt6JjC0FYpAdV8bM2pLqj3FdsvQH6ah6CgS3vm70dlAWs1JiV2KhD
  aOKu6b5465x74jeZZaFU4vg2fwnAqgfIa4q97vEtzL4SJbTWS2EoKoRpoW1qzP0gb1o2RHjDLA
  5TFNCrQZX1zfoC2qQKA7goMNbEyQa7CvaIhCv1DpxpGzN5OD2FdZVmQF4o3JEnDNdTDLmBMxPD7

  

------_=_NextPart_002_01C69139.55268311
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a href=3D"http://uvrbkf.outpigs.com/?76312634"><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none'><img border=3D0 =
 id=3D"_x0000_i1025" =
src=3D"cid:[email-masked]"></span></font></a><o:p></o:p><=
/span></font></p>
<font style=3D'color:#F0F0F0'>
oBPIjOLDCe0u8TzUQ9J73r64yxUGJPOpizCauoFsIUCXR2SsNXd67P9zJJfSBROKfyw4xqGwLgkN<br>
PBinwcpwsd74FW67Ia5qArWWk5E316gRwfHRkJjeACOEkdnHmfkOxheKVPPG0bHuHvaUUA1EShhZ7Lf<br>
iFRiO0egKJSvA5WyECfTynSe2RYamxIszj1oqnPfaMITPQmYBFS9LAL9baKkLUnWb0k0xr<br>
1Lm4PlVL2H2HAuHhBBTZi52ineiEDjMWqcNbuiddPoZdD5egy3dBgoVbAedOePclWYj7KZY<br>
ryHZOzwwuuLy06vOdsi0SJMiLMRQzcm9ynre8L4UvKiN8W1TPqdTL52RV49gduyldncRf5yU<br>
dmyefCdvnhXX6yKOd40tBgocXMYQv7DtiA1lBARGqQuRH3FbIxzDCeP6fDjHnYdmfTnonFVVHKinA<br>
62JSzNmQE4faBZkU7FeanUijgsKYKYRHlEEyxW1idrLLhdbjyLV5Ez48bvhLOVtxFuzRaH8c2AKtWb<br>
9ah3b6YtHZ1RUwBG0g8RKt6JjC0FYpAdV8bM2pLqj3FdsvQH6ah6CgS3vm70dlAWs1JiV2KhD<br>
aOKu6b5465x74jeZZaFU4vg2fwnAqgfIa4q97vEtzL4SJbTWS2EoKoRpoW1qzP0gb1o2RHjDLA<br>
5TFNCrQZX1zfoC2qQKA7goMNbEyQa7CvaIhCv1DpxpGzN5OD2FdZVmQF4o3JEnDNdTDLmBMxPD7
</font>
</div>

</body>

</html>

------_=_NextPart_002_01C69139.55268311--

------_=_NextPart_001_01C69139.55268311
Content-Type: image/gif;
	name="image058.gif"
Content-ID: <[email-masked]>
Content-Description: image058.gif
Content-Location: image058.gif
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C69139.55268311--

Content-class: urn:content-classes:message
Date: Sun, 18 Jun 2006 10:09:31 +0300
From: "Sadie" <[email-masked]>
To: [email-masked]
Subject: [nmrg] Save your budget, powerful medicine for a low price.

------_=_NextPart_001_01C69139.62211933
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C69139.62211933"

------_=_NextPart_002_01C69139.62211933
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

  <http://uvrbkf.outpigs.com/?76312634>=20
  C3lRRAyKHUBWdc98cUZ0fvGS41xfJcpYxLgOEnK1roXeCmbTg6ey280Nvb52f0IM1bnV6TZhrVWG
  SSJJPjn563mCm8woP7Uc6DrauJOvmJW1NKRWifoFYItjnuXUewaJIIOXiKDa3hVuoNBd8UDLk02nWRI
  cE3nIcfEpba0lnB0W1ykWKD9eZFW1M8WwsNnuwGLPux7HJIJLMC7KM2Bnc9PUvKulxrHpT
  7m4WnB1Zmvvx62lij2kVzK2A9aeGJyzh6siXfzbXvYIffp5x1wEB9BFSW87E19vdF87bg0S
  K47BITQBfHo7EfczftnkL8S7ioqX6lssCEC1WagXmdxOEGwxrgusrMBmqPNksFRr7Oy7BvN4
  ZrTWbjhZTQgdJTxo9902vR8ozXD5oO7PGzn1IiEANhtLYF9YSYc4FYlnzrrlj3szYM9TYCxZZbx1n
  J2uG5jxeodaJzDZLwFExIHO7vHD9H9nyJujdMOwG4Lmm0iLPcBW52F46HCNrSFfzIsctCrLaFtMYq9
  y9jwWKcG7QW9pucobdkrSYd0MKpr1RB5vsvOaoVwWSQFXqcbEL7lUtNdD5s4X0cuzWhXnX1rS
  hRArwixL3JpffrdOqzMqo2rPy1yeMQmCIxnsbe9nW0CM8MDgUpmrvi8qccfNLwezrZu5574fRg
  b3kwyjjgnGVuLLBhV2bwqwLD1DWKWQ6FCbgARwYjVJD7WjVhePRWrhf4Jl6sxr7hUNiZL4hYsoS

  

------_=_NextPart_002_01C69139.62211933
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a href=3D"http://uvrbkf.outpigs.com/?76312634"><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none'><img border=3D0 =
 id=3D"_x0000_i1025" =
src=3D"cid:[email-masked]"></span></font></a><o:p></o:p><=
/span></font></p>
<font style=3D'color:#F0F0F0'>
C3lRRAyKHUBWdc98cUZ0fvGS41xfJcpYxLgOEnK1roXeCmbTg6ey280Nvb52f0IM1bnV6TZhrVWG<br>
SSJJPjn563mCm8woP7Uc6DrauJOvmJW1NKRWifoFYItjnuXUewaJIIOXiKDa3hVuoNBd8UDLk02nWRI<br>
cE3nIcfEpba0lnB0W1ykWKD9eZFW1M8WwsNnuwGLPux7HJIJLMC7KM2Bnc9PUvKulxrHpT<br>
7m4WnB1Zmvvx62lij2kVzK2A9aeGJyzh6siXfzbXvYIffp5x1wEB9BFSW87E19vdF87bg0S<br>
K47BITQBfHo7EfczftnkL8S7ioqX6lssCEC1WagXmdxOEGwxrgusrMBmqPNksFRr7Oy7BvN4<br>
ZrTWbjhZTQgdJTxo9902vR8ozXD5oO7PGzn1IiEANhtLYF9YSYc4FYlnzrrlj3szYM9TYCxZZbx1n<br>
J2uG5jxeodaJzDZLwFExIHO7vHD9H9nyJujdMOwG4Lmm0iLPcBW52F46HCNrSFfzIsctCrLaFtMYq9<br>
y9jwWKcG7QW9pucobdkrSYd0MKpr1RB5vsvOaoVwWSQFXqcbEL7lUtNdD5s4X0cuzWhXnX1rS<br>
hRArwixL3JpffrdOqzMqo2rPy1yeMQmCIxnsbe9nW0CM8MDgUpmrvi8qccfNLwezrZu5574fRg<br>
b3kwyjjgnGVuLLBhV2bwqwLD1DWKWQ6FCbgARwYjVJD7WjVhePRWrhf4Jl6sxr7hUNiZL4hYsoS
</font>
</div>

</body>

</html>

------_=_NextPart_002_01C69139.62211933--

------_=_NextPart_001_01C69139.62211933
Content-Type: image/gif;
	name="image015.gif"
Content-ID: <[email-masked]>
Content-Description: image015.gif
Content-Location: image015.gif
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C69139.62211933--

Date: Sat, 17 Jun 2006 22:19:45 +0200
From: Benoit Claise <[email-masked]>
To: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] IESG thoughts on network management
Cc: Margaret Wasserman <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.
--------------010601080302050904000706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David, All,
> HI,
>
> Very interesting thread, with many sub issues, so here goes:
>
> 1) There was a lot of terminology used in the IESG report
>    that I wasn't quite sure of the meaning. Dan - can you
>    provide a few short descriptions.
> 2) I looked at JP's paper. Note that it was published
>    in 1999. Many of the issues remain. However, it could
>    be republished today with AJAX instead of applets,
>    and use XML to transport management info. The result
>    would be timely. There are parts that I agree with,
>    and others I don't, but maybe JP and I should have
>    a private conversation.
> 3) On modelling, I've been singing the same tune for
>    many years. At the highest level, management is all
>    about deciding what you want done, configuring the
>    system to do it, monitoring the system to make sure
>    you are getting done what you wanted, and, if needed,
>    changing the system configuration to better match
>    what you wanted done. To accompish management
>    (again at a high level), the following management
>    operations are performed: create and delete instances
>    of management info, performance management actions,
>    retrieve values of management information, and
>    asynch report events. Different management protocols
>    have different specific ways that operations are
>    performed and management information is described.
>    For example, in SNMP, there is no explicit "perform
>    action" operation. However, "action operations" are
>    supported by SNMP by "clever" definitions of
>    management info using the limited operations
>    in SNMP. Creating those clever definitions,
>    or reading someone else's and getting back to
>    the action are preety easy tasks for "MIB
>    experts", but not for casual SNMP users.
>    Skipping a few steps in this example to get
>    to the point... All management protocols that I've
>    seen have their strenghts and weaknesses. But
>    all must address the high level uses of
>    management.
> 4) This is sort of a <rant>.
>    The data types in SNMP's SMI have been stalled since
>    the early 90's. Please, lets' add "unsignedInt64",
>    "signedInt64", "Float and Double (using IEEE encoding
>    and semantics, NOT ASN.1 encoding and semantics)",
>    and "discriminated unions". I believe that this
>    has been one of the top reasons why people don't
>    want to using SNMP's SMI for data modelling.
>    Another top reason is the limitations in the
>    identification of instances (translated - indexing),
>    and in describing in programmic way the relationships
>    between instances. </rant>
> 5) Another theme I've been singing for many years is
>    the need for a team in developing management solutions.
>    That is, it is "crazy talk" or maybe "crazy think" to
>    believe that one person knows 1) the technology,
>    2) how the technology is used (and how it fails)
>    in deployments, 3) how to efficiently and cost
>    effectively manage devices containing the technology
>    (this means design and write code for "management apps"
>    and "instrumentation"). The result that I've seen
>    is that different standards groups are dominated
>    by different sorts of experts, and they like to
>    use management protocols and schemas for management
>    info that matches their area of background (and bias).
>   
Good point. This is the same situation on the customer sides: the guys 
deploying the technology are not the ones managing it.
I've always been wondering why we had to wait for so long for the MPLS 
MIBs, long after the MPLS protocol design. Maybe that's the reason?
My point is that manageability is most of the time an after-thought.

What about this simple solution? Add a compulsory "Manageability 
Considerations" section in any IETF draft.
Note: I remember that this idea was discussed a couple of years ago on 
one of the IETF mailing list...
Let me take an analogy. I'm certainly not a security expert, but for 
each of my draft, I have either to investigate the security aspects, or 
get security experts to bring their experience in the draft. The 
"Manageability Considerations" should work the same.
Possible options are:
    - manageability is done via X and Y
    - no management because .... (there is maybe a reason why IP phone 
are not managed via SNMP, to come back to Dan's example)
    - management defined in draft/RFC ...
    - monitoring is required but configuration is not.
    - etc...

Now, imposing a protocol and a data model in this section is a different 
story.
However, if protocol designers would think (a little bit) of management 
(fault, configuration, accounting, performance) at the design time, that 
would be an achievement already IMHO.

Regards, Benoit.

> I'm stopping now. This message is already too long. 
>
> Enjoy,
> /david t. perkins    
>
> On Mon, 12 Jun 2006, Margaret Wasserman wrote:
>   
>> Hi Bert,
>>
>>     
>>> I agree that a mixture of protocols for management on a 
>>> single device easily starts to look like a spagetthi bowl and 
>>> may make (even rudimentary) management if the device 
>>> difficult/problematic.
>>>
>>> At the other hand, if a WG is not interested and does not do 
>>> a good job at designing a MIB module, then that is not 
>>> helpfull either. So... what do you propose? 
>>>       
>> I do not hold the view that "There must be only one".  However, I don't
>> consider "Let a thousand flowers bloom" to be the only alternative.
>>
>> If there is no one protocol that will meet the requirements of both protocol
>> designers and operators/administrators, then I think that we need to have
>> more than one.  And, in fact, we already have more than one.  I also think
>> we need to understand _why_ we have more than one management protocol into
>> the IETF protocol suite and have some coherent idea of where and when each
>> management protocol will be used.  Ideally, we would also understand how to
>> access (some of?) the same management information using different protocols,
>> as appropriate based on the role and purpose of each protocol.
>>
>> I am confused by the way the IESG's conclusion ties together data modeling
>> and the choice of management protocol.  I'm concerned we'll get into a
>> situation where the "best" data modeling language for a given protocol will
>> simply be the language with which the authors are most familiar or the one
>> they'd most like to learn, and that little or no thought will be given to
>> how the complete system (consisting of this protocol and several related
>> protocols) will be managed.  I consider choosing how a protocol will be
>> managed based on which data modeling language is most convenient to be the
>> opposite of designing a system for manageability.
>>
>> If I had to choose my Nirvana, it wouldn't be that everyone in the IETF
>> would use whatever data modeling language and management protocol they
>> preferred, it would be finding a way to define our information models in a
>> more management-protocol-agnostic fashion (hopefully earlier in the protocol
>> definition process) and being able to map that model (in as deterministic a
>> way as possible) onto the various data models for the various management
>> protocols.
>>
>> I'm not sure what it would mean to shift from "management by SNMP" to
>> "design for manageability", nor do I understand what the IESG meant when
>> they said that SNMP is "stuck on a single vertical model", so there may be
>> parts of the IESG's conclusions that I am failing to understand properly.
>> Dan, could you offer a bit more insight into what problems the IESG was
>> trying to solve and what you intend to change (if anything) based on these
>> conclusions?
>>
>> Margaret
>>
>>     
>
>   

--------------010601080302050904000706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
David, All,<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">HI,

Very interesting thread, with many sub issues, so here goes:

1) There was a lot of terminology used in the IESG report
   that I wasn't quite sure of the meaning. Dan - can you
   provide a few short descriptions.
2) I looked at JP's paper. Note that it was published
   in 1999. Many of the issues remain. However, it could
   be republished today with AJAX instead of applets,
   and use XML to transport management info. The result
   would be timely. There are parts that I agree with,
   and others I don't, but maybe JP and I should have
   a private conversation.
3) On modelling, I've been singing the same tune for
   many years. At the highest level, management is all
   about deciding what you want done, configuring the
   system to do it, monitoring the system to make sure
   you are getting done what you wanted, and, if needed,
   changing the system configuration to better match
   what you wanted done. To accompish management
   (again at a high level), the following management
   operations are performed: create and delete instances
   of management info, performance management actions,
   retrieve values of management information, and
   asynch report events. Different management protocols
   have different specific ways that operations are
   performed and management information is described.
   For example, in SNMP, there is no explicit "perform
   action" operation. However, "action operations" are
   supported by SNMP by "clever" definitions of
   management info using the limited operations
   in SNMP. Creating those clever definitions,
   or reading someone else's and getting back to
   the action are preety easy tasks for "MIB
   experts", but not for casual SNMP users.
   Skipping a few steps in this example to get
   to the point... All management protocols that I've
   seen have their strenghts and weaknesses. But
   all must address the high level uses of
   management.
4) This is sort of a &lt;rant&gt;.
   The data types in SNMP's SMI have been stalled since
   the early 90's. Please, lets' add "unsignedInt64",
   "signedInt64", "Float and Double (using IEEE encoding
   and semantics, NOT ASN.1 encoding and semantics)",
   and "discriminated unions". I believe that this
   has been one of the top reasons why people don't
   want to using SNMP's SMI for data modelling.
   Another top reason is the limitations in the
   identification of instances (translated - indexing),
   and in describing in programmic way the relationships
   between instances. &lt;/rant&gt;
5) Another theme I've been singing for many years is
   the need for a team in developing management solutions.
   That is, it is "crazy talk" or maybe "crazy think" to
   believe that one person knows 1) the technology,
   2) how the technology is used (and how it fails)
   in deployments, 3) how to efficiently and cost
   effectively manage devices containing the technology
   (this means design and write code for "management apps"
   and "instrumentation"). The result that I've seen
   is that different standards groups are dominated
   by different sorts of experts, and they like to
   use management protocols and schemas for management
   info that matches their area of background (and bias).
  </pre>
</blockquote>
Good point. This is the same situation on the customer sides: the guys
deploying the technology are not the ones managing it.<br>
I've always been wondering why we had to wait for so long for the MPLS
MIBs, long after the MPLS protocol design. Maybe that's the reason?<br>
My point is that manageability is most of the time an after-thought.<br>
<br>
What about this simple solution? Add a compulsory "Manageability
Considerations" section in any IETF draft.<br>
Note: I remember that this idea was discussed a couple of years ago on
one of the IETF mailing list...<br>
Let me take an analogy. I'm certainly not a security expert, but for
each of my draft, I have either to investigate the security aspects, or
get security experts to bring their experience in the draft. The
"Manageability Considerations" should work the same. <br>
Possible options are:<br>
&nbsp;&nbsp;&nbsp; - manageability is done via X and Y<br>
&nbsp;&nbsp;&nbsp; - no management because .... (there is maybe a reason why IP phone
are not managed via SNMP, to come back to Dan's example)<br>
&nbsp;&nbsp;&nbsp; - management defined in draft/RFC ...<br>
&nbsp;&nbsp;&nbsp; - monitoring is required but configuration is not.<br>
&nbsp;&nbsp;&nbsp; - etc...<br>
<br>
Now, imposing a protocol and a data model in this section is a
different story.<br>
However, if protocol designers would think (a little bit) of management
(fault, configuration, accounting, performance) at the design time,
that would be an achievement already IMHO.<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">
I'm stopping now. This message is already too long. 

Enjoy,
/david t. perkins    

On Mon, 12 Jun 2006, Margaret Wasserman wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Bert,

    </pre>
    <blockquote type="cite">
      <pre wrap="">I agree that a mixture of protocols for management on a 
single device easily starts to look like a spagetthi bowl and 
may make (even rudimentary) management if the device 
difficult/problematic.

At the other hand, if a WG is not interested and does not do 
a good job at designing a MIB module, then that is not 
helpfull either. So... what do you propose? 
      </pre>
    </blockquote>
    <pre wrap="">I do not hold the view that "There must be only one".  However, I don't
consider "Let a thousand flowers bloom" to be the only alternative.

If there is no one protocol that will meet the requirements of both protocol
designers and operators/administrators, then I think that we need to have
more than one.  And, in fact, we already have more than one.  I also think
we need to understand _why_ we have more than one management protocol into
the IETF protocol suite and have some coherent idea of where and when each
management protocol will be used.  Ideally, we would also understand how to
access (some of?) the same management information using different protocols,
as appropriate based on the role and purpose of each protocol.

I am confused by the way the IESG's conclusion ties together data modeling
and the choice of management protocol.  I'm concerned we'll get into a
situation where the "best" data modeling language for a given protocol will
simply be the language with which the authors are most familiar or the one
they'd most like to learn, and that little or no thought will be given to
how the complete system (consisting of this protocol and several related
protocols) will be managed.  I consider choosing how a protocol will be
managed based on which data modeling language is most convenient to be the
opposite of designing a system for manageability.

If I had to choose my Nirvana, it wouldn't be that everyone in the IETF
would use whatever data modeling language and management protocol they
preferred, it would be finding a way to define our information models in a
more management-protocol-agnostic fashion (hopefully earlier in the protocol
definition process) and being able to map that model (in as deterministic a
way as possible) onto the various data models for the various management
protocols.

I'm not sure what it would mean to shift from "management by SNMP" to
"design for manageability", nor do I understand what the IESG meant when
they said that SNMP is "stuck on a single vertical model", so there may be
parts of the IESG's conclusions that I am failing to understand properly.
Dan, could you offer a bit more insight into what problems the IESG was
trying to solve and what you intend to change (if anything) based on these
conclusions?

Margaret

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

--------------010601080302050904000706--

Date: Wed, 14 Jun 2006 15:06:46 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "J.P. Martin-Flatin" <[email-masked]>
Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>, [email-masked]

Fixed. The web page concerned is updated by a real
push model, so it may be an hour or two before the
update appears.

    Brian

J.P. Martin-Flatin wrote:
> Fine with me
> 
> JP
> 
> On 13.06.2006 11:45, Romascanu, Dan (Dan) wrote:
> 
>> So the clarification that is needed would be:
>>
>> OLD:
>> - very much based on one 'push' model protocol
>>
>> NEW:
>> - very much based on one 'push' model protocol in what concerns
>> configuration management operations
>>
>> Brian, if this change is confirmed by JP would a correction be possible,
>> for a more accurate record?
>> Dan
>>
>>
>>  
>>  
>>
>>> -----Original Message-----
>>> From: J.P. Martin-Flatin [mailto:[email-masked]] Sent: 
>>> Tuesday, June 13, 2006 12:05 PM
>>> To: Romascanu, Dan (Dan)
>>> Cc: Brian Carpenter; [email-masked]
>>> Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
>>>
>>> Hi Dan,
>>>
>>> There seems to be quite a difference between what you say here and 
>>> what appears in the minutes of the IESG Retreat at:
>>>
>>>    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
>>>
>>> I agree that network operators usually configure network devices by 
>>> pushing configurations to them. This pertains to configuration 
>>> management.
>>>
>>> I disagree that "the current management framework ... [is] very much 
>>> based on one 'push' model protocol", as stated in item 11, para 1, 
>>> because most of the time SNMP-based management platforms rely on 
>>> polling for transferring management data. Managers pull data (OIDs) 
>>> off agents, and agents rarely push data on their own. This pertains 
>>> to monitoring, not to configuration management.
>>>
>>> I suggest the minutes be updated. Item 11, para 1 should say 
>>> explicitly that you talk about configuration management here.
>>>
>>> JP
>>>
>>>
>>> On 12.06.2006 16:41, Romascanu, Dan (Dan) wrote:
>>>
>>>> Hi JP,
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of J.P. 
>>>
>>> Martin-Flatin
>>>
>>>>> Sent: Monday, June 12, 2006 5:27 PM
>>>>> To: Brian Carpenter
>>>>> Cc: [email-masked]
>>>>> Subject: [nmrg] Re: Notes from IESG Retreat held in May
>>>>>
>>>>> 1) Para 1, bullet 3: The current SNMP protocol is based on 
>>>
>>> "pull" not
>>>
>>>>> "push". See my IM 1999 paper:
>>>>>
>>>>>     http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf
>>>>
>>>>
>>>> I was not aware about your paper, and still need to read it 
>>>
>>> attentively.
>>>
>>>> The terminology that I am using is quite widely used (I 
>>>
>>> believe) and
>>>
>>>> is looking at the management operations from the perspective of a 
>>>> network operator performing configuration operations on a network 
>>>> device. It seems that you were using an inverse convention 
>>>
>>> in your paper.
>>>
>>>> Dan
>>
>>
> 

Date: Wed, 14 Jun 2006 14:21:51 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
Cc: Brian Carpenter <[email-masked]>, [email-masked]
Reply-To: "J.P. Martin-Flatin" <[email-masked]>

Fine with me

JP

On 13.06.2006 11:45, Romascanu, Dan (Dan) wrote:
> So the clarification that is needed would be:
> 
> OLD: 
> 
> - very much based on one 'push' model protocol
> 
> NEW: 
> 
> - very much based on one 'push' model protocol in what concerns
> configuration management operations
> 
> Brian, if this change is confirmed by JP would a correction be possible,
> for a more accurate record? 
> 
> Dan
> 
> 
>  
>  
> 
>> -----Original Message-----
>> From: J.P. Martin-Flatin [mailto:[email-masked]] 
>> Sent: Tuesday, June 13, 2006 12:05 PM
>> To: Romascanu, Dan (Dan)
>> Cc: Brian Carpenter; [email-masked]
>> Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
>>
>> Hi Dan,
>>
>> There seems to be quite a difference between what you say 
>> here and what appears in the minutes of the IESG Retreat at:
>>
>>    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
>>
>> I agree that network operators usually configure network 
>> devices by pushing configurations to them. This pertains to 
>> configuration management.
>>
>> I disagree that "the current management framework ... [is] 
>> very much based on one 'push' model protocol", as stated in 
>> item 11, para 1, because most of the time SNMP-based 
>> management platforms rely on polling for transferring 
>> management data. Managers pull data (OIDs) off agents, and 
>> agents rarely push data on their own. This pertains to 
>> monitoring, not to configuration management.
>>
>> I suggest the minutes be updated. Item 11, para 1 should say 
>> explicitly that you talk about configuration management here.
>>
>> JP
>>
>>
>> On 12.06.2006 16:41, Romascanu, Dan (Dan) wrote:
>>> Hi JP,
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of J.P. 
>> Martin-Flatin
>>>> Sent: Monday, June 12, 2006 5:27 PM
>>>> To: Brian Carpenter
>>>> Cc: [email-masked]
>>>> Subject: [nmrg] Re: Notes from IESG Retreat held in May
>>>>
>>>> 1) Para 1, bullet 3: The current SNMP protocol is based on 
>> "pull" not 
>>>> "push". See my IM 1999 paper:
>>>>
>>>>     http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf
>>>
>>> I was not aware about your paper, and still need to read it 
>> attentively.
>>> The terminology that I am using is quite widely used (I 
>> believe) and 
>>> is looking at the management operations from the perspective of a 
>>> network operator performing configuration operations on a network 
>>> device. It seems that you were using an inverse convention 
>> in your paper.
>>> Dan
> 

Date: Tue, 13 Jun 2006 15:46:33 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Romascanu, Dan \(Dan\)" <[email-masked]>
Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
Cc: "J.P. Martin-Flatin" <[email-masked]>, [email-masked]

Sure. The notes are only notes, but I can easily update them.

    Brian

Romascanu, Dan (Dan) wrote:
> So the clarification that is needed would be:
> 
> OLD: 
> 
> - very much based on one 'push' model protocol
> 
> NEW: 
> 
> - very much based on one 'push' model protocol in what concerns
> configuration management operations
> 
> Brian, if this change is confirmed by JP would a correction be possible,
> for a more accurate record? 
> 
> Dan
> 
> 
>  
>  
> 
>
>>-----Original Message-----
>>From: J.P. Martin-Flatin [mailto:[email-masked]] 
>>Sent: Tuesday, June 13, 2006 12:05 PM
>>To: Romascanu, Dan (Dan)
>>Cc: Brian Carpenter; [email-masked]
>>Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
>>
>>Hi Dan,
>>
>>There seems to be quite a difference between what you say 
>>here and what appears in the minutes of the IESG Retreat at:
>>
>>   http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
>>
>>I agree that network operators usually configure network 
>>devices by pushing configurations to them. This pertains to 
>>configuration management.
>>
>>I disagree that "the current management framework ... [is] 
>>very much based on one 'push' model protocol", as stated in 
>>item 11, para 1, because most of the time SNMP-based 
>>management platforms rely on polling for transferring 
>>management data. Managers pull data (OIDs) off agents, and 
>>agents rarely push data on their own. This pertains to 
>>monitoring, not to configuration management.
>>
>>I suggest the minutes be updated. Item 11, para 1 should say 
>>explicitly that you talk about configuration management here.
>>
>>JP
>>
>>
>>On 12.06.2006 16:41, Romascanu, Dan (Dan) wrote:
>>
>>>Hi JP,
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>>[mailto:[email-masked]] On Behalf Of J.P. 
>>
>>Martin-Flatin
>>
>>>>Sent: Monday, June 12, 2006 5:27 PM
>>>>To: Brian Carpenter
>>>>Cc: [email-masked]
>>>>Subject: [nmrg] Re: Notes from IESG Retreat held in May
>>>>
>>>
>>>>1) Para 1, bullet 3: The current SNMP protocol is based on 
>>
>>"pull" not 
>>
>>>>"push". See my IM 1999 paper:
>>>>
>>>>    http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf
>>>
>>>
>>>I was not aware about your paper, and still need to read it 
>>
>>attentively.
>>
>>>The terminology that I am using is quite widely used (I 
>>
>>believe) and 
>>
>>>is looking at the management operations from the perspective of a 
>>>network operator performing configuration operations on a network 
>>>device. It seems that you were using an inverse convention 
>>
>>in your paper.
>>
>>>Dan
>>
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] Re: Notes from IESG Retreat held in May
Date: Tue, 13 Jun 2006 13:20:26 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "J.P. Martin-Flatin" <[email-masked]>, [email-masked], Brian Carpenter <[email-masked]>

 

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Tuesday, June 13, 2006 1:02 PM
> To: Romascanu, Dan (Dan)
> Cc: J.P. Martin-Flatin; Brian Carpenter; [email-masked]
> Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
> 
> Dan,
> 
> > So the clarification that is needed would be:
> >
> > OLD: 
> >
> > - very much based on one 'push' model protocol
> >
> > NEW: 
> >
> > - very much based on one 'push' model protocol in what concerns 
> > configuration management operations
> >
> > Brian, if this change is confirmed by JP would a correction be 
> > possible, for a more accurate record?
> The most basic functions of network management are handled by 
> such protocols as DHCP and PPP on the front end with Radius 
> on the back end. 
> In no way could these mechanisms be considered "push".  You 
> might say they're not configuration management operations but 
> then we're quibbling over terms, and I'd argue that if 
> they're not, it's because we actually know how to reliably 
> configure those objects from a management system. 
> But push/pull is a bad way to look at all of this.  If a 
> manager wants to make a change with immediate effect, push is 
> needed.  For scaling purposes in large environments, pull is 
> also needed.  The connection model is far more critical than 
> push/pull.
> 
> Eliot
> 

I agree. What was meant to say is that the SNMP-based management
framework is 'push' when it comes to protocol operations for
configuration management. Brrrr .. Too many words. Is this wordsmithing
that important? The message I believe it's clear - part of the world
believes that the IETF management framework equals the SNMP-based
management framework, and this is not true for all management operations
and protocols in the IETF space, as in the examples that you gave. We
need to accommodate reality, while building a management framework and a
set of standards that will ensure interoperable management. 

Dan

Date: Tue, 13 Jun 2006 12:02:28 +0200
From: Eliot Lear <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>
Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
Cc: "J.P. Martin-Flatin" <[email-masked]>, [email-masked], Brian Carpenter <[email-masked]>

Dan,

> So the clarification that is needed would be:
>
> OLD: 
>
> - very much based on one 'push' model protocol
>
> NEW: 
>
> - very much based on one 'push' model protocol in what concerns
> configuration management operations
>
> Brian, if this change is confirmed by JP would a correction be possible,
> for a more accurate record? 
The most basic functions of network management are handled by such
protocols as DHCP and PPP on the front end with Radius on the back end. 
In no way could these mechanisms be considered "push".  You might say
they're not configuration management operations but then we're quibbling
over terms, and I'd argue that if they're not, it's because we actually
know how to reliably configure those objects from a management system. 
But push/pull is a bad way to look at all of this.  If a manager wants
to make a change with immediate effect, push is needed.  For scaling
purposes in large environments, pull is also needed.  The connection
model is far more critical than push/pull.

Eliot

content-class: urn:content-classes:message
Subject: RE: [nmrg] Re: Notes from IESG Retreat held in May
Date: Tue, 13 Jun 2006 12:45:41 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>
Cc: Brian Carpenter <[email-masked]>, [email-masked]

So the clarification that is needed would be:

OLD: 

- very much based on one 'push' model protocol

NEW: 

- very much based on one 'push' model protocol in what concerns
configuration management operations

Brian, if this change is confirmed by JP would a correction be possible,
for a more accurate record? 

Dan

 

> -----Original Message-----
> From: J.P. Martin-Flatin [mailto:[email-masked]] 
> Sent: Tuesday, June 13, 2006 12:05 PM
> To: Romascanu, Dan (Dan)
> Cc: Brian Carpenter; [email-masked]
> Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
> 
> Hi Dan,
> 
> There seems to be quite a difference between what you say 
> here and what appears in the minutes of the IESG Retreat at:
> 
>    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> 
> I agree that network operators usually configure network 
> devices by pushing configurations to them. This pertains to 
> configuration management.
> 
> I disagree that "the current management framework ... [is] 
> very much based on one 'push' model protocol", as stated in 
> item 11, para 1, because most of the time SNMP-based 
> management platforms rely on polling for transferring 
> management data. Managers pull data (OIDs) off agents, and 
> agents rarely push data on their own. This pertains to 
> monitoring, not to configuration management.
> 
> I suggest the minutes be updated. Item 11, para 1 should say 
> explicitly that you talk about configuration management here.
> 
> JP
> 
> 
> On 12.06.2006 16:41, Romascanu, Dan (Dan) wrote:
> > Hi JP,
> > 
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of J.P. 
> Martin-Flatin
> >> Sent: Monday, June 12, 2006 5:27 PM
> >> To: Brian Carpenter
> >> Cc: [email-masked]
> >> Subject: [nmrg] Re: Notes from IESG Retreat held in May
> >>
> > 
> >> 1) Para 1, bullet 3: The current SNMP protocol is based on 
> "pull" not 
> >> "push". See my IM 1999 paper:
> >>
> >>     http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf
> > 
> > 
> > I was not aware about your paper, and still need to read it 
> attentively.
> > The terminology that I am using is quite widely used (I 
> believe) and 
> > is looking at the management operations from the perspective of a 
> > network operator performing configuration operations on a network 
> > device. It seems that you were using an inverse convention 
> in your paper.
> > 
> > Dan
> 

Date: Tue, 13 Jun 2006 11:04:57 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] Re: Notes from IESG Retreat held in May
Cc: Brian Carpenter <[email-masked]>, [email-masked]
Reply-To: "J.P. Martin-Flatin" <[email-masked]>

Hi Dan,

There seems to be quite a difference between what you say here and what 
appears in the minutes of the IESG Retreat at:

   http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt

I agree that network operators usually configure network devices by pushing 
configurations to them. This pertains to configuration management.

I disagree that "the current management framework ... [is] very much based 
on one 'push' model protocol", as stated in item 11, para 1, because most 
of the time SNMP-based management platforms rely on polling for 
transferring management data. Managers pull data (OIDs) off agents, and 
agents rarely push data on their own. This pertains to monitoring, not to 
configuration management.

I suggest the minutes be updated. Item 11, para 1 should say explicitly 
that you talk about configuration management here.

JP

On 12.06.2006 16:41, Romascanu, Dan (Dan) wrote:
> Hi JP,
> 
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of J.P. Martin-Flatin
>> Sent: Monday, June 12, 2006 5:27 PM
>> To: Brian Carpenter
>> Cc: [email-masked]
>> Subject: [nmrg] Re: Notes from IESG Retreat held in May
>>
> 
>> 1) Para 1, bullet 3: The current SNMP protocol is based on 
>> "pull" not "push". See my IM 1999 paper:
>>
>>     http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf
> 
> 
> I was not aware about your paper, and still need to read it attentively.
> The terminology that I am using is quite widely used (I believe) and is
> looking at the management operations from the perspective of a network
> operator performing configuration operations on a network device. It
> seems that you were using an inverse convention in your paper. 
> 
> Dan

content-class: urn:content-classes:message
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 21:35:26 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

My wording was poor. I did not mean saying that recommending a one
protocol / one data model was not useful or was a complete failure. What
I meant is that the 'one size fits all' did not succeed to stop other
types of management interfaces developing within the IETF or out of it.
But, yes, the effort was worthwhile, and even successful and relevant in
some specific segments and you are making a good point about the
reasons. 

Dan

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, June 12, 2006 7:42 PM
> To: Romascanu, Dan (Dan); 'Margaret Wasserman'; 'J.P. 
> Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
> Hi,
> 
> I disagree that "standardizing one protocol and recommending 
> one type of data model did not help too much for the last ten years".
> 

Date: Mon, 12 Jun 2006 09:46:26 -0700 (PDT)
From: "David T. Perkins" <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Subject: RE: [nmrg] IESG thoughts on network management
Cc: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]

HI,

Very interesting thread, with many sub issues, so here goes:

1) There was a lot of terminology used in the IESG report
   that I wasn't quite sure of the meaning. Dan - can you
   provide a few short descriptions.
2) I looked at JP's paper. Note that it was published
   in 1999. Many of the issues remain. However, it could
   be republished today with AJAX instead of applets,
   and use XML to transport management info. The result
   would be timely. There are parts that I agree with,
   and others I don't, but maybe JP and I should have
   a private conversation.
3) On modelling, I've been singing the same tune for
   many years. At the highest level, management is all
   about deciding what you want done, configuring the
   system to do it, monitoring the system to make sure
   you are getting done what you wanted, and, if needed,
   changing the system configuration to better match
   what you wanted done. To accompish management
   (again at a high level), the following management
   operations are performed: create and delete instances
   of management info, performance management actions,
   retrieve values of management information, and
   asynch report events. Different management protocols
   have different specific ways that operations are
   performed and management information is described.
   For example, in SNMP, there is no explicit "perform
   action" operation. However, "action operations" are
   supported by SNMP by "clever" definitions of
   management info using the limited operations
   in SNMP. Creating those clever definitions,
   or reading someone else's and getting back to
   the action are preety easy tasks for "MIB
   experts", but not for casual SNMP users.
   Skipping a few steps in this example to get
   to the point... All management protocols that I've
   seen have their strenghts and weaknesses. But
   all must address the high level uses of
   management.
4) This is sort of a <rant>.
   The data types in SNMP's SMI have been stalled since
   the early 90's. Please, lets' add "unsignedInt64",
   "signedInt64", "Float and Double (using IEEE encoding
   and semantics, NOT ASN.1 encoding and semantics)",
   and "discriminated unions". I believe that this
   has been one of the top reasons why people don't
   want to using SNMP's SMI for data modelling.
   Another top reason is the limitations in the
   identification of instances (translated - indexing),
   and in describing in programmic way the relationships
   between instances. </rant>
5) Another theme I've been singing for many years is
   the need for a team in developing management solutions.
   That is, it is "crazy talk" or maybe "crazy think" to
   believe that one person knows 1) the technology,
   2) how the technology is used (and how it fails)
   in deployments, 3) how to efficiently and cost
   effectively manage devices containing the technology
   (this means design and write code for "management apps"
   and "instrumentation"). The result that I've seen
   is that different standards groups are dominated
   by different sorts of experts, and they like to
   use management protocols and schemas for management
   info that matches their area of background (and bias).

I'm stopping now. This message is already too long. 

Enjoy,
/david t. perkins    

On Mon, 12 Jun 2006, Margaret Wasserman wrote:
> 
> Hi Bert,
> 
> > I agree that a mixture of protocols for management on a 
> > single device easily starts to look like a spagetthi bowl and 
> > may make (even rudimentary) management if the device 
> > difficult/problematic.
> > 
> > At the other hand, if a WG is not interested and does not do 
> > a good job at designing a MIB module, then that is not 
> > helpfull either. So... what do you propose? 
> 
> I do not hold the view that "There must be only one".  However, I don't
> consider "Let a thousand flowers bloom" to be the only alternative.
> 
> If there is no one protocol that will meet the requirements of both protocol
> designers and operators/administrators, then I think that we need to have
> more than one.  And, in fact, we already have more than one.  I also think
> we need to understand _why_ we have more than one management protocol into
> the IETF protocol suite and have some coherent idea of where and when each
> management protocol will be used.  Ideally, we would also understand how to
> access (some of?) the same management information using different protocols,
> as appropriate based on the role and purpose of each protocol.
> 
> I am confused by the way the IESG's conclusion ties together data modeling
> and the choice of management protocol.  I'm concerned we'll get into a
> situation where the "best" data modeling language for a given protocol will
> simply be the language with which the authors are most familiar or the one
> they'd most like to learn, and that little or no thought will be given to
> how the complete system (consisting of this protocol and several related
> protocols) will be managed.  I consider choosing how a protocol will be
> managed based on which data modeling language is most convenient to be the
> opposite of designing a system for manageability.
> 
> If I had to choose my Nirvana, it wouldn't be that everyone in the IETF
> would use whatever data modeling language and management protocol they
> preferred, it would be finding a way to define our information models in a
> more management-protocol-agnostic fashion (hopefully earlier in the protocol
> definition process) and being able to map that model (in as deterministic a
> way as possible) onto the various data models for the various management
> protocols.
> 
> I'm not sure what it would mean to shift from "management by SNMP" to
> "design for manageability", nor do I understand what the IESG meant when
> they said that SNMP is "stuck on a single vertical model", so there may be
> parts of the IESG's conclusions that I am failing to understand properly.
> Dan, could you offer a bit more insight into what problems the IESG was
> trying to solve and what you intend to change (if anything) based on these
> conclusions?
> 
> Margaret
> 

From: "David B Harrington" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Margaret Wasserman'" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 12:41:50 -0400
Cc: 

Hi,

I disagree that "standardizing one protocol and recommending one type
of data model did not help too much for the last ten years".

In the evolution of Internet technologies, just as in Darwinian
evolution, you need both lots of mutations and a winnowing process -
natural selection or economic selection. CLI is designed to support
managing the constant mutation of technologies; the publication of
standardized data models, such as MIB modules, represents only a
snapshot of a portion of the result of natural selection at some point
in time. 

The MIB has been successful at making the naturally-selected concepts
of Internet technologies available to management applications,
especially using one IETF-standard protocol. The MIB is just a subset
of an overall, constantly evolving information model. The MIB is
useful for monitoring precisely because we can reach rough consensus
on a subset of things to monitor. The MIB is not usually useful for
configuring a complete device because we cannot reach agreement on all
aspects of a complete device. The MIB is not even useful for totally
configuring specific technologies because we cannot reach agreement on
all the things that need to be configured to support specific
technologies.  

The rest of the information model has not been standardized precisely
because it is still mutating too rapidly for us to reach agreement. We
can agree on a subset of data that is useful for monitoring Vlans, for
example, but we have been unsuccessful at standardizing all the
parameters needed to configure Vlans on all vendors' devices, and
probably never will.

I think standardizing and recommending one protocol for the last ten
years has helped the industry tremendously. It helped us establish a
baseline. But we did so largely ignoring additional protocols and data
models operators need to manage the un-winnowed, constantly mutating,
portion of the information model, primarily because we did not
understand it well enough to engineer any standardized solutions. With
the experience of the past ten years, especially aided by a common
understanding learned from using one protocol and one data model, and
seeing where it worked well and where it didn't, we now are able to
see where additional helpful engineering work could be done. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Monday, June 12, 2006 10:53 AM
> To: Margaret Wasserman; J.P. Martin-Flatin; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
> Well, yes, maybe - but such is life. The reality is that different
> management protocols are being used for different IETF protocols, or
> even for  different management operations. Standardizing one
protocol
> and recommending one type of data model did not help too much for
the
> last ten years. It led however to a lot of energy being 
> channeled in the
> wrong direction, and to some IETF protocols never being managed by a
> IETF management protocols. 
> 
> A change of focus from 'management by SNMP' to 'manageability' is
the
> approach that I am suggesting to discuss. 
> 
> Dan
> 
> PS - I will try to keep as quiet as I can for the time being, 
> because my
> intention is really at this phase to trigger a discussion. 
>  
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Margaret 
> Wasserman
> > Sent: Monday, June 12, 2006 5:29 PM
> > To: 'J.P. Martin-Flatin'; [email-masked]
> > Subject: RE: [nmrg] IESG thoughts on network management
> > 
> >  
> > Taking a quote from the URL that JP sent:
> > 
> > "It was felt that it's time for a change of approach in the 
> > IETF, from a reflexive "write a MIB" to a proactive "design 
> > for manageability."
> > One of the key design aspects of management is the data 
> > model, and the choice of data model can be crucial.
> > For example, decide whether a MIB, an LDAP structure, or a 
> > non-IETF solution is the best way to model a particular protocol.
> > The protocol to use for management will follow from this 
> > rather than being SNMP by definition."
> > 
> > Do these thoughts seem problematic or short-sited to others?  
> > 
> > Given that different IETF protocols are often combined into a 
> > single system, and I'm concerned that this approach might 
> > lead to a situation where multiple management protocols are 
> > required for even rudimentary management/monitoring of a 
> > single IETF protocol-based system.
> > 
> > Thoughts?
> > 
> > Margaret
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of J.P. 
> > Martin-Flatin
> > > Sent: Monday, June 12, 2006 10:19 AM
> > > To: [email-masked]
> > > Subject: [nmrg] IESG thoughts on network management
> > > 
> > > I suggest you read item 11 at:
> > > 
> > >    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> > > 
> > > JP
> > > --
> > > !! This message is brought to you via the `nmrg' mailing list.
> > > !! Please do not reply to this message to unsubscribe. To 
> > unsubscribe 
> > > or adjust !! your settings, send a mail message to 
> > > <[email-masked]> !! or look at 
> > > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > > 
> > 
> > --
> > !! This message is brought to you via the `nmrg' mailing list.
> > !! Please do not reply to this message to unsubscribe. To 
> > unsubscribe or adjust !! your settings, send a mail message 
> > to <[email-masked]> !! or look at 
> > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > 
> 
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust
> !! your settings, send a mail message to 
> <[email-masked]>
> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 18:56:21 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

(The previous message included the presentation from the Boston retreat,
but led to the message exceeding the max size. I took it out meantime,
to keep the conversation flowing)

Margaret,

For clarification, the document pointed by Brian are the minutes of the
retreat. There are no IESG conclusions here, but rather the minutes
taker reflected a presentation that I gave and some of the following
discussions. The result of these discussions was a recommendation to
write an Internet-Draft which should focus the discussion and deal with
the 'what problem we are trying to solve' question. 

In the presentation that I used at the IESG meeting there are more
questions there then recommendations. A variant of this preso will be
probably be brought to trigger discussions in the OPS area meeting in
Montreal. There also may be some discussions about data model planning
that come close to your 'Nirvana' idea, and you are invited to
contribute if you have the bandwidth. 

For the record, I agree that "Let a thousand flowers bloom" is not a
good approach. On the other hand neither is 'one-protocol-fits-all'. To
use an example from the domain where I am doing management work for the
last few years, there is practically no IP phone managed by SNMP out
there. There may be a reason for this, and we want to find it. 

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Monday, June 12, 2006 6:25 PM
> To: 'Wijnen, Bert (Bert)'; 'J.P. Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
> 
> Hi Bert,
> 
> > I agree that a mixture of protocols for management on a 
> single device 
> > easily starts to look like a spagetthi bowl and may make (even 
> > rudimentary) management if the device difficult/problematic.
> > 
> > At the other hand, if a WG is not interested and does not do a good 
> > job at designing a MIB module, then that is not helpfull 
> either. So... 
> > what do you propose?
> 
> I do not hold the view that "There must be only one".  
> However, I don't consider "Let a thousand flowers bloom" to 
> be the only alternative.
> 
> If there is no one protocol that will meet the requirements 
> of both protocol designers and operators/administrators, then 
> I think that we need to have more than one.  And, in fact, we 
> already have more than one.  I also think we need to 
> understand _why_ we have more than one management protocol 
> into the IETF protocol suite and have some coherent idea of 
> where and when each management protocol will be used.  
> Ideally, we would also understand how to access (some of?) 
> the same management information using different protocols, as 
> appropriate based on the role and purpose of each protocol.
> 
> I am confused by the way the IESG's conclusion ties together 
> data modeling and the choice of management protocol.  I'm 
> concerned we'll get into a situation where the "best" data 
> modeling language for a given protocol will simply be the 
> language with which the authors are most familiar or the one 
> they'd most like to learn, and that little or no thought will 
> be given to how the complete system (consisting of this 
> protocol and several related
> protocols) will be managed.  I consider choosing how a 
> protocol will be managed based on which data modeling 
> language is most convenient to be the opposite of designing a 
> system for manageability.
> 
> If I had to choose my Nirvana, it wouldn't be that everyone 
> in the IETF would use whatever data modeling language and 
> management protocol they preferred, it would be finding a way 
> to define our information models in a more 
> management-protocol-agnostic fashion (hopefully earlier in 
> the protocol definition process) and being able to map that 
> model (in as deterministic a way as possible) onto the 
> various data models for the various management protocols.
> 
> I'm not sure what it would mean to shift from "management by 
> SNMP" to "design for manageability", nor do I understand what 
> the IESG meant when they said that SNMP is "stuck on a single 
> vertical model", so there may be parts of the IESG's 
> conclusions that I am failing to understand properly.
> Dan, could you offer a bit more insight into what problems 
> the IESG was trying to solve and what you intend to change 
> (if anything) based on these conclusions?
> 
> Margaret
> 
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 18:50:49 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C68E37.F9E04531
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Margaret,

For clarification, the document pointed by Brian are the minutes of the
retreat. There are no IESG conclusions here, but rather the minutes
taker reflected a presentation that I gave and some of the following
discussions. The result of these discussions was a recommendation to
write an Internet-Draft which should focus the discussion and deal with
the 'what problem we are trying to solve' question.=20

I am attaching the presentation that I used at the IESG meeting, which
is probably a better basis for the discussion. As you can see there are
more questions there then recommendations. A variant of this preso will
be probably be brought to trigger discussions in the OPS area meeting in
Montreal. There also may be some discussions about data model planning
that come close to your 'Nirvana' idea, and you are invited to
contribute if you have the bandwidth.=20

For the record, I agree that "Let a thousand flowers bloom" is not a
good approach. On the other hand neither is 'one-protocol-fits-all'. To
use an example from the domain where I am doing management work for the
last few years, there is practically no IP phone managed by SNMP out
there. There may be a reason for this, and we want to find it.=20

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Monday, June 12, 2006 6:25 PM
> To: 'Wijnen, Bert (Bert)'; 'J.P. Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
>=20
>=20
> Hi Bert,
>=20
> > I agree that a mixture of protocols for management on a=20
> single device=20
> > easily starts to look like a spagetthi bowl and may make (even=20
> > rudimentary) management if the device difficult/problematic.
> >=20
> > At the other hand, if a WG is not interested and does not do a good=20
> > job at designing a MIB module, then that is not helpfull=20
> either. So...=20
> > what do you propose?
>=20
> I do not hold the view that "There must be only one". =20
> However, I don't consider "Let a thousand flowers bloom" to=20
> be the only alternative.
>=20
> If there is no one protocol that will meet the requirements=20
> of both protocol designers and operators/administrators, then=20
> I think that we need to have more than one.  And, in fact, we=20
> already have more than one.  I also think we need to=20
> understand _why_ we have more than one management protocol=20
> into the IETF protocol suite and have some coherent idea of=20
> where and when each management protocol will be used. =20
> Ideally, we would also understand how to access (some of?)=20
> the same management information using different protocols, as=20
> appropriate based on the role and purpose of each protocol.
>=20
> I am confused by the way the IESG's conclusion ties together=20
> data modeling and the choice of management protocol.  I'm=20
> concerned we'll get into a situation where the "best" data=20
> modeling language for a given protocol will simply be the=20
> language with which the authors are most familiar or the one=20
> they'd most like to learn, and that little or no thought will=20
> be given to how the complete system (consisting of this=20
> protocol and several related
> protocols) will be managed.  I consider choosing how a=20
> protocol will be managed based on which data modeling=20
> language is most convenient to be the opposite of designing a=20
> system for manageability.
>=20
> If I had to choose my Nirvana, it wouldn't be that everyone=20
> in the IETF would use whatever data modeling language and=20
> management protocol they preferred, it would be finding a way=20
> to define our information models in a more=20
> management-protocol-agnostic fashion (hopefully earlier in=20
> the protocol definition process) and being able to map that=20
> model (in as deterministic a way as possible) onto the=20
> various data models for the various management protocols.
>=20
> I'm not sure what it would mean to shift from "management by=20
> SNMP" to "design for manageability", nor do I understand what=20
> the IESG meant when they said that SNMP is "stuck on a single=20
> vertical model", so there may be parts of the IESG's=20
> conclusions that I am failing to understand properly.
> Dan, could you offer a bit more insight into what problems=20
> the IESG was trying to solve and what you intend to change=20
> (if anything) based on these conclusions?
>=20
> Margaret
>=20
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To=20
> unsubscribe or adjust !! your settings, send a mail message=20
> to <[email-masked]> !! or look at=20
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
>=20

------_=_NextPart_001_01C68E37.F9E04531
Content-Type: application/vnd.ms-powerpoint;
	name="Network Management Complexities_01.ppt"
Content-Transfer-Encoding: base64
Content-Description: Network Management Complexities_01.ppt
Content-Disposition: attachment;
	filename="Network Management Complexities_01.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAbgAAAAAAAAAA
EAAAZgAAAAEAAAD+////AAAAAG8AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C68E37.F9E04531--

From: "Margaret Wasserman" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 11:24:59 -0400
Cc: 

Hi Bert,

> I agree that a mixture of protocols for management on a 
> single device easily starts to look like a spagetthi bowl and 
> may make (even rudimentary) management if the device 
> difficult/problematic.
> 
> At the other hand, if a WG is not interested and does not do 
> a good job at designing a MIB module, then that is not 
> helpfull either. So... what do you propose? 

I do not hold the view that "There must be only one".  However, I don't
consider "Let a thousand flowers bloom" to be the only alternative.

If there is no one protocol that will meet the requirements of both protocol
designers and operators/administrators, then I think that we need to have
more than one.  And, in fact, we already have more than one.  I also think
we need to understand _why_ we have more than one management protocol into
the IETF protocol suite and have some coherent idea of where and when each
management protocol will be used.  Ideally, we would also understand how to
access (some of?) the same management information using different protocols,
as appropriate based on the role and purpose of each protocol.

I am confused by the way the IESG's conclusion ties together data modeling
and the choice of management protocol.  I'm concerned we'll get into a
situation where the "best" data modeling language for a given protocol will
simply be the language with which the authors are most familiar or the one
they'd most like to learn, and that little or no thought will be given to
how the complete system (consisting of this protocol and several related
protocols) will be managed.  I consider choosing how a protocol will be
managed based on which data modeling language is most convenient to be the
opposite of designing a system for manageability.

If I had to choose my Nirvana, it wouldn't be that everyone in the IETF
would use whatever data modeling language and management protocol they
preferred, it would be finding a way to define our information models in a
more management-protocol-agnostic fashion (hopefully earlier in the protocol
definition process) and being able to map that model (in as deterministic a
way as possible) onto the various data models for the various management
protocols.

I'm not sure what it would mean to shift from "management by SNMP" to
"design for manageability", nor do I understand what the IESG meant when
they said that SNMP is "stuck on a single vertical model", so there may be
parts of the IESG's conclusions that I am failing to understand properly.
Dan, could you offer a bit more insight into what problems the IESG was
trying to solve and what you intend to change (if anything) based on these
conclusions?

Margaret

Date: Mon, 12 Jun 2006 17:15:32 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "J.P. Martin-Flatin" <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] Re: Notes from IESG Retreat held in May

> 2) Para 4, li 3: "WEBM" -> "WBEM/CIM"

Thanks, I'll fix the typo in my original at least.

Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 17:10:18 +0200
From: "Grosso Enrico" <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

This is a multi-part message in MIME format.

------=_NextPart_000_135210_01C68E43.146D53A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
in the telco industry, new approaches are under investigations for
management of home networks for triple play services, and as an example
please take CWMP protocol and TR-069/TR-111 management from DSL Forum.

So reading this issue 11 below from IESG sounds interesting, especially
if future collaboration/convergence of industry efforts into IETF could
happen.

Regards

Enrico Grosso
Telecom Italia (www.telecomitalia.it)
[email-masked]
Phone: +39 011 2288046
Mobile: +39 335 7854037

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of J.P. Martin-Flatin
Sent: Monday, June 12, 2006 4:19 PM
To: [email-masked]
Subject: [nmrg] IESG thoughts on network management

I suggest you read item 11 at:

   http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt

JP
--
!! This message is brought to you via the `nmrg' mailing list.
!! Please do not reply to this message to unsubscribe. To unsubscribe or
adjust !! your settings, send a mail message to
<[email-masked]> !! or look at
http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons =
above and may contain confidential information. If you have received the =
message in error, be informed that any use of the content hereof is =
prohibited. Please return it immediately to the sender and delete the =
message. Should you have any questions, please contact us by replying to =
[email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
                        
------=_NextPart_000_135210_01C68E43.146D53A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 =
Transitional//EN"><HTML><HEAD><META HTTP-EQUIV=3D"Content-Type" =
CONTENT=3D"text/html; =
charset=3Diso-8859-1"></HEAD><BODY><DIV>&nbsp;</DIV>Hi all,<BR>in the =
telco industry, new approaches are under investigations =
for<BR>management of home networks for triple play services, and as an =
example<BR>please take CWMP protocol and TR-069/TR-111 management from =
DSL Forum.<BR><BR>So reading this issue 11 below from IESG sounds =
interesting, especially<BR>if future collaboration/convergence of =
industry efforts into IETF could<BR>happen.<BR><BR>Regards<BR><BR>Enrico =
Grosso<BR>Telecom Italia =
(www.telecomitalia.it)<BR>[email-masked]<BR>Phone: +39 =
011 2288046<BR>Mobile: +39 335 7854037<BR><BR><BR><BR>-----Original =
Message-----<BR>From: [email-masked] =
[mailto:[email-masked]]<BR>On Behalf Of J.P. =
Martin-Flatin<BR>Sent: Monday, June 12, 2006 4:19 PM<BR>To: =
[email-masked]<BR>Subject: [nmrg] IESG thoughts on network =
management<BR><BR>I suggest you read item 11 at:<BR><BR>   =
http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt<BR><BR>JP<BR>--<=
BR>!! This message is brought to you via the `nmrg' mailing list.<BR>!! =
Please do not reply to this message to unsubscribe. To unsubscribe =
or<BR>adjust !! your settings, send a mail message =
to<BR><[email-masked]> !! or look =
at<BR>http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.<BR><=
DIV><FONT size=3D2><FONT=20
face=3D"Courier =
New">--------------------------------------------------------------------=
<BR>CONFIDENTIALITY=20
NOTICE<BR>This message and its attachments are addressed solely to the=20
persons<BR>above and may contain confidential information. If you have=20
received<BR>the message in error, be informed that any use of the =
content=20
hereof<BR>is prohibited. Please return it immediately to the sender and=20
delete<BR>the message. Should you have any questions, please contact us=20
by<BR>replying to </FONT><A =
href=3D"mailto:[email-masked]"><FONT=20
face=3D"Courier New">[email-masked]</FONT></A><FONT=20
face=3D"Courier New">.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Thank=20
you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
</FONT><A href=3D"http://www.telecomitalia.it"><FONT=20
face=3D"Courier New">www.telecomitalia.it</FONT></A><BR><FONT=20
face=3D"Courier =
New">--------------------------------------------------------------------=
</FONT></FONT></DIV>
</BODY></HTML>
------=_NextPart_000_135210_01C68E43.146D53A0--

content-class: urn:content-classes:message
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 17:53:16 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

Well, yes, maybe - but such is life. The reality is that different
management protocols are being used for different IETF protocols, or
even for  different management operations. Standardizing one protocol
and recommending one type of data model did not help too much for the
last ten years. It led however to a lot of energy being channeled in the
wrong direction, and to some IETF protocols never being managed by a
IETF management protocols. 

A change of focus from 'management by SNMP' to 'manageability' is the
approach that I am suggesting to discuss. 

Dan

PS - I will try to keep as quiet as I can for the time being, because my
intention is really at this phase to trigger a discussion. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Monday, June 12, 2006 5:29 PM
> To: 'J.P. Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
>  
> Taking a quote from the URL that JP sent:
> 
> "It was felt that it's time for a change of approach in the 
> IETF, from a reflexive "write a MIB" to a proactive "design 
> for manageability."
> One of the key design aspects of management is the data 
> model, and the choice of data model can be crucial.
> For example, decide whether a MIB, an LDAP structure, or a 
> non-IETF solution is the best way to model a particular protocol.
> The protocol to use for management will follow from this 
> rather than being SNMP by definition."
> 
> Do these thoughts seem problematic or short-sited to others?  
> 
> Given that different IETF protocols are often combined into a 
> single system, and I'm concerned that this approach might 
> lead to a situation where multiple management protocols are 
> required for even rudimentary management/monitoring of a 
> single IETF protocol-based system.
> 
> Thoughts?
> 
> Margaret
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of J.P. 
> Martin-Flatin
> > Sent: Monday, June 12, 2006 10:19 AM
> > To: [email-masked]
> > Subject: [nmrg] IESG thoughts on network management
> > 
> > I suggest you read item 11 at:
> > 
> >    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> > 
> > JP
> > --
> > !! This message is brought to you via the `nmrg' mailing list.
> > !! Please do not reply to this message to unsubscribe. To 
> unsubscribe 
> > or adjust !! your settings, send a mail message to 
> > <[email-masked]> !! or look at 
> > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > 
> 
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

Date: Mon, 12 Jun 2006 16:44:52 +0200
From: Eliot Lear <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Subject: Re: [nmrg] IESG thoughts on network management
Cc: "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]

Margaret Wasserman wrote:
>  
> Taking a quote from the URL that JP sent:
>
> "It was felt that it's time for a change of approach in the IETF, from
> a reflexive "write a MIB" to a proactive "design for manageability."
> One of the key design aspects of management is the data model,
> and the choice of data model can be crucial.
> For example, decide whether a MIB, an LDAP structure, or a
> non-IETF solution is the best way to model a particular protocol.
> The protocol to use for management will follow from this rather
> than being SNMP by definition."
>
> Do these thoughts seem problematic or short-sited to others?  
>   
Only if nirvana looks bad!  But precisely what does this mean?  For
instance, those layers Dan talks about exist for a practical reason:
reuse.  If there's no reuse then it's all just overhead.  This was, IMHO
the great thing that Marshall Rose, Steve Kille, and others demonstrated
with Quipu, the full scale X.500 experiment that ran on the Internet for
quite some time (Do YOU remember your chosen endangered species for CN? 
Mine was The Hornero) and one of the reasons we have LDAP.  So for
instance, what's an appropriate management model for HTTP?  Especially
given that it's really the standard transport these days.

There are lots of bumps and dead ends on the way to Nirvana.  Knowing
how to manage something often requires a lot of experience, and so we
have to be careful to how we do the above without creating yet another
grand unified theory that ends up on the shelf.

So, I'm not saying that Dan is wrong, but proceed with caution.  There
be dragons here!

Eliot

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Margaret Wasserman <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 16:44:28 +0200
Cc: 

Inline

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Margaret Wasserman
> Sent: Monday, June 12, 2006 16:29
> To: 'J.P. Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
> 
>  
> Taking a quote from the URL that JP sent:
> 
>    "It was felt that it's time for a change of approach in the IETF, from
>    a reflexive "write a MIB" to a proactive "design for manageability."
>    One of the key design aspects of management is the data model,
>    and the choice of data model can be crucial.
>    For example, decide whether a MIB, an LDAP structure, or a
>    non-IETF solution is the best way to model a particular protocol.
>    The protocol to use for management will follow from this rather
>    than being SNMP by definition."
> 
> Do these thoughts seem problematic or short-sited to others?  
> 
> Given that different IETF protocols are often combined into a single system,
> and I'm concerned that this approach might lead to a situation where
> multiple management protocols are required for even rudimentary
> management/monitoring of a single IETF protocol-based system.
> 
> Thoughts?
> 

I agree that a mixture of protocols for management on a single device easily
starts to look like a spagetthi bowl and may make (even rudimentary) management
if the device difficult/problematic.

At the other hand, if a WG is not interested and does not do a good job at
designing a MIB module, then that is not helpfull either. So... what do you
propose? 

Bert
> Margaret
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] Re: Notes from IESG Retreat held in May
Date: Mon, 12 Jun 2006 17:41:02 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>, "Brian Carpenter" <[email-masked]>
Cc: [email-masked]

Hi JP,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of J.P. Martin-Flatin
> Sent: Monday, June 12, 2006 5:27 PM
> To: Brian Carpenter
> Cc: [email-masked]
> Subject: [nmrg] Re: Notes from IESG Retreat held in May
> 

> 
> 1) Para 1, bullet 3: The current SNMP protocol is based on 
> "pull" not "push". See my IM 1999 paper:
> 
>     http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf

I was not aware about your paper, and still need to read it attentively.
The terminology that I am using is quite widely used (I believe) and is
looking at the management operations from the perspective of a network
operator performing configuration operations on a network device. It
seems that you were using an inverse convention in your paper. 

Dan

From: Michael Alexander <[email-masked]>
Subject: Re: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 16:37:16 +0200
To: "Margaret Wasserman" <[email-masked]>
Cc: "'J.P. Martin-Flatin'" <[email-masked]>, [email-masked]

the management protocol (may it be CORBA to XML - in alphabetical  
order) is really secondary to the data model. What matters is a good  
fine-grained, well structured model, from which basically _any  
protocol can read from/write to. In case the e.g. internal structure  
of a device is MIB/SNMP based and the underlying data model is well  
done, then agents can be written sensibly. If the data model is  
spotty then management is a pain _no matter the protocol.

On 12.06.2006, at 16:29, Margaret Wasserman wrote:

>
> Taking a quote from the URL that JP sent:
>
> "It was felt that it's time for a change of approach in the IETF, from
> a reflexive "write a MIB" to a proactive "design for manageability."
> One of the key design aspects of management is the data model,
> and the choice of data model can be crucial.
> For example, decide whether a MIB, an LDAP structure, or a
> non-IETF solution is the best way to model a particular protocol.
> The protocol to use for management will follow from this rather
> than being SNMP by definition."
>
> Do these thoughts seem problematic or short-sited to others?
>
> Given that different IETF protocols are often combined into a  
> single system,
> and I'm concerned that this approach might lead to a situation where
> multiple management protocols are required for even rudimentary
> management/monitoring of a single IETF protocol-based system.
>
> Thoughts?
>
> Margaret
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of J.P. Martin-Flatin
>> Sent: Monday, June 12, 2006 10:19 AM
>> To: [email-masked]
>> Subject: [nmrg] IESG thoughts on network management
>>
>> I suggest you read item 11 at:
>>
>>    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
>>
>> JP
>> --
>> !! This message is brought to you via the `nmrg' mailing list.
>> !! Please do not reply to this message to unsubscribe. To
>> unsubscribe or adjust !! your settings, send a mail message
>> to <[email-masked]> !! or look at
>> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
>>
>
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To  
> unsubscribe or adjust
> !! your settings, send a mail message to <[email-masked] 
> bs.de>
> !! or look at http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/ 
> listinfo/nmrg.

content-class: urn:content-classes:message
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 17:32:02 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, "J.P. Martin-Flatin" <[email-masked]>, <[email-masked]>
Cc: 

I am :-)

Thanks for the consideration. 

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret Wasserman
> Sent: Monday, June 12, 2006 5:30 PM
> To: 'Margaret Wasserman'; 'J.P. Martin-Flatin'; [email-masked]
> Subject: RE: [nmrg] IESG thoughts on network management
> 
> 
> BTW, is Dan on this list?  Or should we copy him on this discussion?
> 
> Margaret 
> 
> > -----Original Message-----
> > From: Margaret Wasserman [mailto:[email-masked]]
> > Sent: Monday, June 12, 2006 10:29 AM
> > To: 'J.P. Martin-Flatin'; [email-masked]'
> > Subject: RE: [nmrg] IESG thoughts on network management
> > 
> >  
> > Taking a quote from the URL that JP sent:
> > 
> > "It was felt that it's time for a change of approach in the 
> IETF, from 
> > a reflexive "write a MIB" to a proactive "design for manageability."
> > One of the key design aspects of management is the data 
> model, and the 
> > choice of data model can be crucial.
> > For example, decide whether a MIB, an LDAP structure, or a non-IETF 
> > solution is the best way to model a particular protocol.
> > The protocol to use for management will follow from this 
> rather than 
> > being SNMP by definition."
> > 
> > Do these thoughts seem problematic or short-sited to others?  
> > 
> > Given that different IETF protocols are often combined into 
> a single 
> > system, and I'm concerned that this approach might lead to 
> a situation 
> > where multiple management protocols are required for even 
> rudimentary 
> > management/monitoring of a single IETF protocol-based system.
> > 
> > Thoughts?
> > 
> > Margaret
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of J.P. 
> > Martin-Flatin
> > > Sent: Monday, June 12, 2006 10:19 AM
> > > To: [email-masked]
> > > Subject: [nmrg] IESG thoughts on network management
> > > 
> > > I suggest you read item 11 at:
> > > 
> > >    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> > > 
> > > JP
> > > --
> > > !! This message is brought to you via the `nmrg' mailing list.
> > > !! Please do not reply to this message to unsubscribe. To
> > unsubscribe
> > > or adjust !! your settings, send a mail message to 
> > > <[email-masked]> !! or look at 
> > > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > > 
> 
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

From: "Margaret Wasserman" <[email-masked]>
To: "'Margaret Wasserman'" <[email-masked]>, "'J.P. Martin-Flatin'" <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 10:30:26 -0400
Cc: 

BTW, is Dan on this list?  Or should we copy him on this discussion?

Margaret 

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Monday, June 12, 2006 10:29 AM
> To: 'J.P. Martin-Flatin'; [email-masked]'
> Subject: RE: [nmrg] IESG thoughts on network management
> 
>  
> Taking a quote from the URL that JP sent:
> 
> "It was felt that it's time for a change of approach in the 
> IETF, from a reflexive "write a MIB" to a proactive "design 
> for manageability."
> One of the key design aspects of management is the data 
> model, and the choice of data model can be crucial.
> For example, decide whether a MIB, an LDAP structure, or a 
> non-IETF solution is the best way to model a particular protocol.
> The protocol to use for management will follow from this 
> rather than being SNMP by definition."
> 
> Do these thoughts seem problematic or short-sited to others?  
> 
> Given that different IETF protocols are often combined into a 
> single system, and I'm concerned that this approach might 
> lead to a situation where multiple management protocols are 
> required for even rudimentary management/monitoring of a 
> single IETF protocol-based system.
> 
> Thoughts?
> 
> Margaret
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of J.P. 
> Martin-Flatin
> > Sent: Monday, June 12, 2006 10:19 AM
> > To: [email-masked]
> > Subject: [nmrg] IESG thoughts on network management
> > 
> > I suggest you read item 11 at:
> > 
> >    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> > 
> > JP
> > --
> > !! This message is brought to you via the `nmrg' mailing list.
> > !! Please do not reply to this message to unsubscribe. To 
> unsubscribe 
> > or adjust !! your settings, send a mail message to 
> > <[email-masked]> !! or look at 
> > http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> > 

From: "Margaret Wasserman" <[email-masked]>
To: "'J.P. Martin-Flatin'" <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] IESG thoughts on network management
Date: Mon, 12 Jun 2006 10:29:04 -0400
Cc: 

Taking a quote from the URL that JP sent:

"It was felt that it's time for a change of approach in the IETF, from
a reflexive "write a MIB" to a proactive "design for manageability."
One of the key design aspects of management is the data model,
and the choice of data model can be crucial.
For example, decide whether a MIB, an LDAP structure, or a
non-IETF solution is the best way to model a particular protocol.
The protocol to use for management will follow from this rather
than being SNMP by definition."

Do these thoughts seem problematic or short-sited to others?  

Given that different IETF protocols are often combined into a single system,
and I'm concerned that this approach might lead to a situation where
multiple management protocols are required for even rudimentary
management/monitoring of a single IETF protocol-based system.

Thoughts?

Margaret

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of J.P. Martin-Flatin
> Sent: Monday, June 12, 2006 10:19 AM
> To: [email-masked]
> Subject: [nmrg] IESG thoughts on network management
> 
> I suggest you read item 11 at:
> 
>    http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> 
> JP
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> http://agitator.ibr.cs.tu-bs.de/cgi-bin/mailman/listinfo/nmrg.
> 

Date: Mon, 12 Jun 2006 16:27:24 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
To: Brian Carpenter <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] Re: Notes from IESG Retreat held in May
Reply-To: "J.P. Martin-Flatin" <[email-masked]>

Brian,

Two comments on item 11 of your IESG retreat notes:

1) Para 1, bullet 3: The current SNMP protocol is based on "pull" not 
"push". See my IM 1999 paper:

    http://www.labunix.uqam.ca/%7Ejpmf/papers/im99.pdf

2) Para 4, li 3: "WEBM" -> "WBEM/CIM"

JP

On 12.06.2006 11:03, Brian Carpenter wrote:
> The notes from the recent IESG Retreat, held May 5/6, 2006, can be found at the
> following URL:
> 
> http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
> 
>    Brian Carpenter
>    IESG Chair

Date: Mon, 12 Jun 2006 16:18:59 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Subject: [nmrg] IESG thoughts on network management
Reply-To: "J.P. Martin-Flatin" <[email-masked]>

I suggest you read item 11 at:

   http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt

JP

Date: Mon, 12 Jun 2006 09:24:36 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] montreal nmrg meeting
Reply-To: [email-masked]

Hi,

the initial schedule for the IETF week is now online:

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66

The NMRG meeting has been scheduled for Monday 17:40-19:50 (but note
that the schedule can still change).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

From: Wes Hardaker <[email-masked]>
To: Aiko Pras <[email-masked]>
Organization: Sparta
Date: Tue, 06 Jun 2006 14:16:06 -0700
Cc: "[email-masked]" <[email-masked]>
Subject: [nmrg] Re: Next IRTF-NMRG meeting

>>>>> On Thu, 25 May 2006 17:50:05 +0200, Aiko Pras <[email-masked]> said:

>> I think it would be good to have someone else chair or co-chair the
>> meeting to keep us on time and so on. Any volunteers out there?

Aiko> Same holds for me. If there are no other volunteers, I can
Aiko> co-chair and remind you that time is running out. ;-)

If you don't find anyone, I can likely do it barring conflicts with
working groups I can't skip for work reasons.
-- 
Wes Hardaker
Sparta, Inc.