Subject: [nmrg] mailing list configuration changed
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Date: Tue, 22 Apr 2003 16:24:13 +0200
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

As discussed before, I have now changed the mailing list so that all
people can subscribe/unsubscribe. However, the right to post without
approval is limited to the people who have been on this list before
this opening up of the list. Posts from other addresses will go to the
mailing list administrator (right now me) for approval (as it was
before).

/js

-- 
Juergen Schoenwaelder		International University Bremen
Phone: +49 421 200 3587		P.O. Box 750 561, 28725 Bremen, Germany
Fax:   +49 421 200 3103		<http://www.iu-bremen.de/>

Date: Mon, 14 Apr 2003 11:20:50 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: IRTF Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] mailing list policy
Sender: [email-masked]

I like Frank's proposal.

JP

Frank Strauss wrote:
> Hi!
> 
> How do you think about...
> 
> - opening subscription to all people,
> - restricting the list of allowed posters to the current subscribers,
> - adding a text to the mailman message footer that is appended to every
>   posting, which explains that this list is read-only to anybody, but
>   posting privileges require to contact the list owner first.
> 
> This would solve the problem of interested people that process the
> list archive in a less elegant way. And the workload for the list
> owner should at least not be increased, while David's concern is also
> addressed.
> 
> Juergen, if you think, I could help to reduce your workload as the list
> owner, feel free to add me as a co-list owner, no matter what the result
> of this discussion will be.
> 
> Just my thoughts,
> 
>  -frank

From: "Andrea Westerinen" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] Terminology help
Date: Wed, 9 Apr 2003 16:13:32 -0700
Importance: Normal
Sender: [email-masked]

Jumping in...

CIM distinguishes Settings - which are desired/configuration values -
from current info - which is stored in the properties of a class.  You
can have multiple Settings (ie, default, current, defined but not used
right now).  You can apply the Settings to an instance.  The instance
may diverge from those Settings due to the environment, a change by the
operator, etc.

This is at a small, rather granular, property level.  At a broader
level, there have been discussions of using namespaces to store a
complete boot config, running config, etc. and then reference/apply
these entire namespaces.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 09, 2003 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] Terminology help

>>>>> Harrington, David writes:

Dave> The point is that there is a new distinction being made, and it 
Dave> probably will need a new mechanism. In SNMP-land this would 
Dave> probably be a new field in an object definition, or a new clause 
Dave> similar to a conformance or group statement.

I continue to disagree since I believe the fact that a certain setting
of a MIB variable belongs to one or more configurations is a dynamic
property of the setting and not a static one.

Dave> Two different issues

Dave> 1) whether objects should be considered configuration data is 
Dave> something that can be recommended/standardized, although issues 
Dave> such as DHCP will mean implementors may have to make exceptions. 
Dave> Identifying objects as configuration data can be done in the mib 
Dave> module.

Dave> 2) which set of configuration data the objects belong to cannot be

Dave> specified in a mib module because that is a runtime decision, and 
Dave> it varies with time.

I believe 2) is the interesting issue where SNMP completely fails. From
reading MIB data, I can not determine what is configuration or not. Nor
am I able to modify SNMP objects while at the same time conveying to the
device that this is in fact a change for a certain named configuration.

Dave> We discussed time-related configuration contexts in SNMPv2 around 
Dave> 1994.  I don't know if it would be possible to locate any archives

Dave> of those discussions.

Dave> It was eventually dropped because of the complexity. We did keep 
Dave> the notion of contexts for mib-instancing, and physical and 
Dave> logical separation of data subsets. Configuration contexts of some

Dave> sort could be developed, I agree, but I believe using the existing

Dave> context mechanism will not work.

I believe that time-related configuration contexts (give me the value of
ifInOctets.X from three days ago) are much harder than contexts which
distinguish between different configurations. I continue to believe that
contexts could be used to distinguish between different configuration
contexts but I agree that this is a mood discussion at this point in
time where SNMP is essentially a dead horse.

Dave> A configuration context, such as startup, might need to contain 
Dave> objects for multiple objects of the same object definition. For 
Dave> example, a vendor might have multiple cards in a chassis or 
Dave> multiple devices in a stack that are managed through a common SNMP

Dave> agent. Each card or stack may implement the same mib module. The 
Dave> instances of the mib module are differentiated by context, so 
Dave> blade#1's rptrPortAdminStatus would be in a different context than

Dave> blade#2's rptrPortAdminStatus.

Dave> How would you represent both these objects in the startup config 
Dave> context, since you would need the blade1 context and the blade2 
Dave> context to uniquely identify these instances?

This is why I used the example "board3@startup" in my previsous message.
Yes, there would be a need to structure the context string. I do not
consider this problematic.

Anyway, I am not trying to advocate an SNMP solution (which I have done
back in 1998). The whole point I was trying to make is that we do not
really discover new territory here since many of the issues are well
know for some time.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>
-- 
!! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Wed, 9 Apr 2003 20:41:04 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> David T Perkins writes:

David> The big picture question is "What is the configuration of the
David> device, so that it can be captured, and then restored later?"
David> Well there is some configuration that is "static" with the
David> device, some that is "static", but provided at runtime (maybe
David> limited to startup (such as that retrieved from a DHCP
David> server)), and there is some that is dynamic that is "learned
David> from operation". Now if I snapshot config info, and then later
David> restore it, there are some parts of the config info that will
David> become stale (or rotten) over time, and should not be used in a
David> restore. Figuring this out, I believe, is a research problem.

In my world view, everything that controls the behaviour of a device
and which has been learned during the operation of the device does not
belong to the configuration of the device. I believe this is what
devices already implement in their CLIs when you do a dump/restore.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Wed, 09 Apr 2003 11:23:40 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

HI,

First, I deliberately posed the question to this group, and not the
NETCONF mailing list because of the diversity of background this
group has with different management protocols. I appreciate the
time that responders have taken responding to the question.

The last few interactions have brought up a very interesting issue
that I have not seen being addressed in a general way. That is
the issue of "life time" of configuration information. (Please note
that I have spoken privately (and maybe there was a message on this
list) about a more general question of "life time" of management
information and by understanding the life time of a value (and instance)
a management application could optimize it's retrieval operations
so that the "poll cycle" matched the expected life time of the
information. Part of characterizing the life time of information
is relating the stimuli that caused values to change, and instances
to be created and deleted. (I believe that is research stuff.)

Back to the configuration info.... 
The big picture question is "What is the configuration of the
device, so that it can be captured, and then restored later?"
Well there is some configuration that is "static" with the
device, some that is "static", but provided at runtime (maybe
limited to startup (such as that retrieved from a DHCP server)),
and there is some that is dynamic that is "learned from
operation". Now if I snapshot config info, and then later
restore it, there are some parts of the config info that
will become stale (or rotten) over time, and should not
be used in a restore. Figuring this out, I believe, is
a research problem.

Comments.

Regards,
/david t. perkins

Date: Wed, 9 Apr 2003 19:52:13 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> Harrington, David writes:

Dave> The point is that there is a new distinction being made, and it
Dave> probably will need a new mechanism. In SNMP-land this would
Dave> probably be a new field in an object definition, or a new clause
Dave> similar to a conformance or group statement.

I continue to disagree since I believe the fact that a certain setting
of a MIB variable belongs to one or more configurations is a dynamic
property of the setting and not a static one.

Dave> Two different issues

Dave> 1) whether objects should be considered configuration data is
Dave> something that can be recommended/standardized, although issues
Dave> such as DHCP will mean implementors may have to make
Dave> exceptions. Identifying objects as configuration data can be
Dave> done in the mib module.

Dave> 2) which set of configuration data the objects belong to cannot
Dave> be specified in a mib module because that is a runtime decision,
Dave> and it varies with time.

I believe 2) is the interesting issue where SNMP completely fails.
>From reading MIB data, I can not determine what is configuration or
not. Nor am I able to modify SNMP objects while at the same time
conveying to the device that this is in fact a change for a certain
named configuration.

Dave> We discussed time-related configuration contexts in SNMPv2
Dave> around 1994.  I don't know if it would be possible to locate
Dave> any archives of those discussions.

Dave> It was eventually dropped because of the complexity. We did keep
Dave> the notion of contexts for mib-instancing, and physical and
Dave> logical separation of data subsets. Configuration contexts of
Dave> some sort could be developed, I agree, but I believe using the
Dave> existing context mechanism will not work.

I believe that time-related configuration contexts (give me the value
of ifInOctets.X from three days ago) are much harder than contexts
which distinguish between different configurations. I continue to
believe that contexts could be used to distinguish between different
configuration contexts but I agree that this is a mood discussion at
this point in time where SNMP is essentially a dead horse.

Dave> A configuration context, such as startup, might need to contain
Dave> objects for multiple objects of the same object definition. For
Dave> example, a vendor might have multiple cards in a chassis or
Dave> multiple devices in a stack that are managed through a common
Dave> SNMP agent. Each card or stack may implement the same mib
Dave> module. The instances of the mib module are differentiated by
Dave> context, so blade#1's rptrPortAdminStatus would be in a
Dave> different context than blade#2's rptrPortAdminStatus.

Dave> How would you represent both these objects in the startup config
Dave> context, since you would need the blade1 context and the blade2
Dave> context to uniquely identify these instances?

This is why I used the example "board3@startup" in my previsous
message. Yes, there would be a need to structure the context string. I
do not consider this problematic.

Anyway, I am not trying to advocate an SNMP solution (which I have
done back in 1998). The whole point I was trying to make is that we do
not really discover new territory here since many of the issues are
well know for some time.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

content-class: urn:content-classes:message
Subject: RE: [nmrg] Terminology help
Date: Wed, 9 Apr 2003 11:57:10 -0400
From: "Harrington, David" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2FEB0.ADECBFC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Juergen,
=20
comments inline.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, April 08, 2003 4:37 PM
To: Harrington, David
Cc: [email-masked]
Subject: Re: [nmrg] Terminology help

>>>>> Harrington, David writes:

Dave> In SNMP land, some people might have used contexts to separate,
Dave> for example, configuration from statistics, or to separate, for
Dave> example, the running config from the startup config, but others
Dave> would not because they used contexts to separate physical or
Dave> logical instantiations of mibs based on other criteria, such as
Dave> different boards in a chassis.

Since context are identified by strings, it would even be possible to
structure them (e.g. "board3@startup"). But since we never managed to
produce a document on how to use contexts, this is all more theory
than established practice.=20

I would say it is more established practice than theory ;-)

Vendors already use contexts in shipping products.

The use of contexts has not yet been standardized, and theories of best =
current practice have not been published.

Dave> The point is that there is a new distinction being made, and it
Dave> probably will need a new mechanism. In SNMP-land this would
Dave> probably be a new field in an object definition, or a new
Dave> clause similar to a conformance or group statement.

I do not thing that this works since the distinction which controls
belong to a certain configuration (yes, I assume a box can have
multiple configurations) is a runtime decision and not a SMI design
time decision.=20

Two different issues=20

1) whether objects should be considered configuration data is something =
that can be recommended/standardized, although issues such as DHCP will =
mean implementors may have to make exceptions. Identifying objects as =
configuration data can be done in the mib module.

2) which set of configuration data the objects belong to cannot be =
specified in a mib module because that is a runtime decision, and it =
varies with time.

Dave> I do not think it will be easy to separate configuration data
Dave> from other types of data; the same data typically is used in
Dave> multiple scenarios. Duplicate sets of data, or a mechanisms that
Dave> allows data to be marked for multiple uses will probably be
Dave> needed.

Correct. And this is what contexts do. I recall discussions around
this usage of contexts from the first NMRG meeting where I proposed to
define get-config and set-config operations for SNMP...=20

I wasn't at the first NMRG meeting.

We discussed time-related configuration contexts in SNMPv2 around 1994.  =
I don't know if it would be possible to locate any archives of those =
discussions.

It was eventually dropped because of the complexity. We did keep the =
notion of contexts for mib-instancing, and physical and logical =
separation of data subsets. Configuration contexts of some sort could be =
developed, I agree, but I believe using the existing context mechanism =
will not work.

Date: Tue, 8 Apr 2003 22:36:45 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> Harrington, David writes:

Dave> In SNMP land, some people might have used contexts to separate,
Dave> for example, configuration from statistics, or to separate, for
Dave> example, the running config from the startup config, but others
Dave> would not because they used contexts to separate physical or
Dave> logical instantiations of mibs based on other criteria, such as
Dave> different boards in a chassis.

Since context are identified by strings, it would even be possible to
structure them (e.g. "board3@startup"). But since we never managed to
produce a document on how to use contexts, this is all more theory
than established practice.

Dave> The point is that there is a new distinction being made, and it
Dave> probably will need a new mechanism. In SNMP-land this would
Dave> probably be a new field in an object definition, or a new
Dave> clause similar to a conformance or group statement. 

I do not thing that this works since the distinction which controls
belong to a certain configuration (yes, I assume a box can have
multiple configurations) is a runtime decision and not a SMI design
time decision.

Dave> I do not think it will be easy to separate configuration data
Dave> from other types of data; the same data typically is used in
Dave> multiple scenarios. Duplicate sets of data, or a mechanisms that
Dave> allows data to be marked for multiple uses will probably be
Dave> needed.

Correct. And this is what contexts do. I recall discussions around
this usage of contexts from the first NMRG meeting where I proposed to
define get-config and set-config operations for SNMP...

Dave> Even then, there is some data that will be hard to categorize
Dave> cleanly, such as DHCP-assigned addresses.  In SNMP land, I think
Dave> having an independent clause, like a conformance clause, would
Dave> be preferable to a new field in an object definition because it
Dave> would be easy to apply to existing mibs, and, like conformance
Dave> clauses, it could identify conditions when it was valid to not
Dave> consider the data to be configuration data, such as when an IP
Dave> address is assigned by DHCP.

Again, such a distinction is not static and thus more SMI mechanisms
won't help. Trying to write down all the various ways to dynamically
assign IP addresses alone would be a task without an end.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

content-class: urn:content-classes:message
Subject: RE: [nmrg] Terminology help
Date: Tue, 8 Apr 2003 15:03:14 -0400
From: "Harrington, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2FE01.81DD0AB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
In SNMP land, some people might have used contexts to separate, for =
example, configuration from statistics, or to separate, for example, the =
running config from the startup config, but others would not because =
they used contexts to separate physical or logical instantiations of =
mibs based on other criteria, such as different boards in a chassis.
=20
The point is that there is a new distinction being made, and it probably =
will need a new mechanism. In SNMP-land this would probably be a new =
field in an object definition, or a new clause similar to a conformance =
or group statement. I do not think it will be easy to separate =
configuration data from other types of data; the same data typically is =
used in multiple scenarios. Duplicate sets of data, or a mechanisms that =
allows data to be marked for multiple uses will probably be needed. Even =
then, there is some data that will be hard to categorize cleanly, such =
as DHCP-assigned addresses.
=20
In SNMP land, I think having an independent clause, like a conformance =
clause, would be preferable to a new field in an object definition =
because it would be easy to apply to existing mibs, and, like =
conformance clauses, it could identify conditions when it was valid to =
not consider the data to be configuration data, such as when an IP =
address is assigned by DHCP.
=20
dbh

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, April 08, 2003 3:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nmrg] Terminology help

>>>>> Margaret Wasserman writes:

Margaret> Perhaps it would help if I explained why we want a clear
Margaret> distinction between configuration information and
Margaret> non-configuration information (what I've called "operational
Margaret> state" in the past)?

[...]

Margaret> Does that make sense?

I think I very well understand the issue. My point here is that the
question whether a given piece of control information is configuration
or not is just an attribute of that particular information. For
example, the IP address assigned to an interface can be configuration
or not. What matters is whether the IP address has been marked as a
configuration that will be reestablished when this particular
configuration is reloaded.

If we agree on this, then everyting boils down to having a mechanism
to associate control information to configuration(s). There are
different ways to do this - the netconf approach is to use different
operations. In SNMP land, one would have used different contexts (or
special configuration columns which name the configurations a given
row is part of).

>> Do you think the general model where configuration data is
>> considered a subset of control data does not work?

Margaret> I don't know if this would work or not.  Is configuration
Margaret> data a well-enough defined subset of control data that it
Margaret> would be possible to make a binary determination between
Margaret> configuration data and everything else using this model?

See above. The function f(o, c) that determins whether a given control
o is part of a specific configuration c needs to be established as
part of the configuration process on the device.

/js

--
Juergen Schoenwaelder    < http://www.iu-bremen.de/>

--
!! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C2FE01.81DD0AB0
Content-Type: text/html;
	charset="iso-8859-1"
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">
<TITLE>Re: [nmrg] Terminology help</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
SNMP land, some people might have used contexts to separate, for=20
example,&nbsp;configuration from statistics, or to separate, for=20
example,&nbsp;the running config from the startup config, but others =
would not=20
because they used contexts to separate physical or logical =
instantiations of=20
mibs based on other criteria, such as different boards in a=20
chassis.</FONT></SPAN></DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
point is that there is a new distinction being made, and it probably =
will need a=20
new mechanism. In SNMP-land this would probably be a new field in an =
object=20
definition, or a new clause similar to a conformance or group statement. =
I do=20
not think it will be easy to separate configuration data from other =
types of=20
data; the same data typically is used in multiple scenarios. Duplicate =
sets of=20
data, or a mechanisms that allows data to be marked for multiple uses =
will=20
probably be needed. Even then, there is some data that will be hard to=20
categorize cleanly, such as DHCP-assigned addresses.</FONT></SPAN></DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
SNMP land, I think having an independent clause, like a conformance =
clause,=20
would be preferable to a new field in an object definition because it =
would be=20
easy to apply to existing mibs, and, like conformance clauses, it could =
identify=20
conditions when it was valid to not consider the data to be =
configuration data,=20
such as when an IP address is assigned by DHCP.</FONT></SPAN></DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D853364618-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Juergen =
Schoenwaelder=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, April 08, =
2003 3:49=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> =
[email-masked];=20
  [email-masked]<BR><B>Subject:</B> Re: [nmrg] Terminology=20
  help<BR><BR></FONT></DIV><!-- Converted from text/plain format --><BR>
  <P><FONT size=3D2>&gt;&gt;&gt;&gt;&gt; Margaret Wasserman=20
  writes:<BR><BR>Margaret&gt; Perhaps it would help if I explained why =
we want a=20
  clear<BR>Margaret&gt; distinction between configuration information=20
  and<BR>Margaret&gt; non-configuration information (what I've called=20
  "operational<BR>Margaret&gt; state" in the=20
  past)?<BR><BR>[...]<BR><BR>Margaret&gt; Does that make sense?<BR><BR>I =
think I=20
  very well understand the issue. My point here is that the<BR>question =
whether=20
  a given piece of control information is configuration<BR>or not is =
just an=20
  attribute of that particular information. For<BR>example, the IP =
address=20
  assigned to an interface can be configuration<BR>or not. What matters =
is=20
  whether the IP address has been marked as a<BR>configuration that will =
be=20
  reestablished when this particular<BR>configuration is =
reloaded.<BR><BR>If we=20
  agree on this, then everyting boils down to having a mechanism<BR>to =
associate=20
  control information to configuration(s). There are<BR>different ways =
to do=20
  this - the netconf approach is to use different<BR>operations. In SNMP =
land,=20
  one would have used different contexts (or<BR>special configuration =
columns=20
  which name the configurations a given<BR>row is part =
of).<BR><BR>&gt;&gt; Do=20
  you think the general model where configuration data is<BR>&gt;&gt; =
considered=20
  a subset of control data does not work?<BR><BR>Margaret&gt; I don't =
know if=20
  this would work or not.&nbsp; Is configuration<BR>Margaret&gt; data a=20
  well-enough defined subset of control data that it<BR>Margaret&gt; =
would be=20
  possible to make a binary determination between<BR>Margaret&gt; =
configuration=20
  data and everything else using this model?<BR><BR>See above. The =
function f(o,=20
  c) that determins whether a given control<BR>o is part of a specific=20
  configuration c needs to be established as<BR>part of the =
configuration=20
  process on the device.<BR><BR>/js<BR><BR>--<BR>Juergen=20
  Schoenwaelder&nbsp;&nbsp;&nbsp; &lt;<A=20
  =
href=3D"http://www.iu-bremen.de/">http://www.iu-bremen.de/</A>&gt;<BR><BR=
><BR>--<BR>!!=20
  This message is brought to you via the `nmrg' mailing list.<BR>!! =
Please do=20
  not reply to this message to unsubscribe. To unsubscribe or =
adjust<BR>!! your=20
  settings, send a mail message to =
&lt;[email-masked]&gt;<BR>!! or=20
  look at <A=20
  =
href=3D"https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg">https://www.ib=
r.cs.tu-bs.de/mailman/listinfo/nmrg</A>.<BR></FONT></P></BLOCKQUOTE></BOD=
Y></HTML>

------_=_NextPart_001_01C2FE01.81DD0AB0--

content-class: urn:content-classes:message
Subject: RE: [nmrg] mailing list policy
Date: Tue, 8 Apr 2003 14:44:33 -0400
From: "Harrington, David" <[email-masked]>
To: "Olivier Festor" <[email-masked]>, "Frank Strauss" <[email-masked]>
Cc: "NMRG (E-mail)" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2FDFE.E5A121F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am also fine with that solution.
=20
dbh

-----Original Message-----
From: Olivier Festor [mailto:[email-masked]]
Sent: Tuesday, April 08, 2003 10:27 AM
To: Frank Strauss
Cc: NMRG (E-mail)
Subject: Re: [nmrg] mailing list policy

I agree with Frank's proposal.

Olivier

Frank Strauss wrote:

>Hi!
>
>How do you think about...
>
>- opening subscription to all people,
>- restricting the list of allowed posters to the current subscribers,
>- adding a text to the mailman message footer that is appended to every
>  posting, which explains that this list is read-only to anybody, but
>  posting privileges require to contact the list owner first.
>
>This would solve the problem of interested people that process the
>list archive in a less elegant way. And the workload for the list
>owner should at least not be increased, while David's concern is also
>addressed.
>
>Juergen, if you think, I could help to reduce your workload as the list
>owner, feel free to add me as a co-list owner, no matter what the =
result
>of this discussion will be.
>
>Just my thoughts,
>
> -frank
>=20
>

--
!! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C2FDFE.E5A121F0
Content-Type: text/html;
	charset="iso-8859-1"
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">
<TITLE>Re: [nmrg] mailing list policy</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D186174318-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>I am=20
also fine with that solution.</FONT></SPAN></DIV>
<DIV><SPAN class=3D186174318-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D186174318-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Olivier Festor=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, April 08, =
2003 10:27=20
  AM<BR><B>To:</B> Frank Strauss<BR><B>Cc:</B> NMRG =
(E-mail)<BR><B>Subject:</B>=20
  Re: [nmrg] mailing list policy<BR><BR></FONT></DIV><!-- Converted from =
text/plain format -->
  <P><FONT size=3D2>I agree with Frank's =
proposal.<BR><BR>Olivier<BR><BR>Frank=20
  Strauss wrote:<BR><BR>&gt;Hi!<BR>&gt;<BR>&gt;How do you think=20
  about...<BR>&gt;<BR>&gt;- opening subscription to all people,<BR>&gt;- =

  restricting the list of allowed posters to the current =
subscribers,<BR>&gt;-=20
  adding a text to the mailman message footer that is appended to=20
  every<BR>&gt;&nbsp; posting, which explains that this list is =
read-only to=20
  anybody, but<BR>&gt;&nbsp; posting privileges require to contact the =
list=20
  owner first.<BR>&gt;<BR>&gt;This would solve the problem of interested =
people=20
  that process the<BR>&gt;list archive in a less elegant way. And the =
workload=20
  for the list<BR>&gt;owner should at least not be increased, while =
David's=20
  concern is also<BR>&gt;addressed.<BR>&gt;<BR>&gt;Juergen, if you =
think, I=20
  could help to reduce your workload as the list<BR>&gt;owner, feel free =
to add=20
  me as a co-list owner, no matter what the result<BR>&gt;of this =
discussion=20
  will be.<BR>&gt;<BR>&gt;Just my thoughts,<BR>&gt;<BR>&gt;=20
  -frank<BR>&gt;&nbsp;<BR>&gt;<BR><BR><BR>--<BR>!! This message is =
brought to=20
  you via the `nmrg' mailing list.<BR>!! Please do not reply to this =
message to=20
  unsubscribe. To unsubscribe or adjust<BR>!! your settings, send a mail =
message=20
  to &lt;[email-masked]&gt;<BR>!! or look at <A=20
  =
href=3D"https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg">https://www.ib=
r.cs.tu-bs.de/mailman/listinfo/nmrg</A>.<BR></FONT></P></BLOCKQUOTE></BOD=
Y></HTML>

------_=_NextPart_001_01C2FDFE.E5A121F0--

From: John Strassner <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [nmrg] Terminology help
Date: Tue, 8 Apr 2003 08:33:56 -0600 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2FDDB.E2F3D150
Content-Type: text/plain

FWIW, I agree with Juergen here.

regards,
John
 
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO  80903  USA
phone: +1.719.785.0648
  FAX: +1.719.785.0644
email: [email-masked] 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2003 1:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nmrg] Terminology help

>>>>> Margaret Wasserman writes:

Margaret> Perhaps it would help if I explained why we want a clear 
Margaret> distinction between configuration information and 
Margaret> non-configuration information (what I've called "operational 
Margaret> state" in the past)?

[...]

Margaret> Does that make sense?

I think I very well understand the issue. My point here is that the question
whether a given piece of control information is configuration or not is just
an attribute of that particular information. For example, the IP address
assigned to an interface can be configuration or not. What matters is
whether the IP address has been marked as a configuration that will be
reestablished when this particular configuration is reloaded.

If we agree on this, then everyting boils down to having a mechanism to
associate control information to configuration(s). There are different ways
to do this - the netconf approach is to use different operations. In SNMP
land, one would have used different contexts (or special configuration
columns which name the configurations a given row is part of).

>> Do you think the general model where configuration data is considered 
>> a subset of control data does not work?

Margaret> I don't know if this would work or not.  Is configuration data 
Margaret> a well-enough defined subset of control data that it would be 
Margaret> possible to make a binary determination between configuration 
Margaret> data and everything else using this model?

See above. The function f(o, c) that determins whether a given control o is
part of a specific configuration c needs to be established as part of the
configuration process on the device.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

-- 
!! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C2FDDB.E2F3D150
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [nmrg] Terminology help</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>FWIW, I agree with Juergen here.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>John</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>John Strassner</FONT>
<BR><FONT SIZE=3D2>Chief Strategy Officer</FONT>
<BR><FONT SIZE=3D2>Intelliden Corporation</FONT>
<BR><FONT SIZE=3D2>90 South Cascade Avenue</FONT>
<BR><FONT SIZE=3D2>Colorado Springs, CO&nbsp; 80903&nbsp; USA</FONT>
<BR><FONT SIZE=3D2>phone: +1.719.785.0648</FONT>
<BR><FONT SIZE=3D2>&nbsp; FAX: +1.719.785.0644</FONT>
<BR><FONT SIZE=3D2>email: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Juergen Schoenwaelder [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 08, 2003 1:49 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [nmrg] Terminology help</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt; Margaret Wasserman =
writes:</FONT>
</P>

<P><FONT SIZE=3D2>Margaret&gt; Perhaps it would help if I explained why =
we want a clear </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; distinction between configuration =
information and </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; non-configuration information (what =
I've called &quot;operational </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; state&quot; in the past)?</FONT>
</P>

<P><FONT SIZE=3D2>[...]</FONT>
</P>

<P><FONT SIZE=3D2>Margaret&gt; Does that make sense?</FONT>
</P>

<P><FONT SIZE=3D2>I think I very well understand the issue. My point =
here is that the question whether a given piece of control information =
is configuration or not is just an attribute of that particular =
information. For example, the IP address assigned to an interface can =
be configuration or not. What matters is whether the IP address has =
been marked as a configuration that will be reestablished when this =
particular configuration is reloaded.</FONT></P>

<P><FONT SIZE=3D2>If we agree on this, then everyting boils down to =
having a mechanism to associate control information to =
configuration(s). There are different ways to do this - the netconf =
approach is to use different operations. In SNMP land, one would have =
used different contexts (or special configuration columns which name =
the configurations a given row is part of).</FONT></P>

<P><FONT SIZE=3D2>&gt;&gt; Do you think the general model where =
configuration data is considered </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a subset of control data does not =
work?</FONT>
</P>

<P><FONT SIZE=3D2>Margaret&gt; I don't know if this would work or =
not.&nbsp; Is configuration data </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; a well-enough defined subset of control =
data that it would be </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; possible to make a binary determination =
between configuration </FONT>
<BR><FONT SIZE=3D2>Margaret&gt; data and everything else using this =
model?</FONT>
</P>

<P><FONT SIZE=3D2>See above. The function f(o, c) that determins =
whether a given control o is part of a specific configuration c needs =
to be established as part of the configuration process on the =
device.</FONT></P>

<P><FONT SIZE=3D2>/js</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Juergen Schoenwaelder&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.iu-bremen.de/" =
TARGET=3D"_blank">http://www.iu-bremen.de/</A>&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>!! 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 =
&lt;[email-masked]&gt; !! or look at <A =
HREF=3D"https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg" =
TARGET=3D"_blank">https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg</A>.=
</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C2FDDB.E2F3D150--

Date: Tue, 08 Apr 2003 16:26:55 +0200
From: Olivier Festor <[email-masked]>
Organization: The MADYNES Research Team
To: Frank Strauss <[email-masked]>
Cc: "NMRG (E-mail)" <[email-masked]>
Subject: Re: [nmrg] mailing list policy
Sender: [email-masked]

I agree with Frank's proposal.

Olivier

Frank Strauss wrote:

>Hi!
>
>How do you think about...
>
>- opening subscription to all people,
>- restricting the list of allowed posters to the current subscribers,
>- adding a text to the mailman message footer that is appended to every
>  posting, which explains that this list is read-only to anybody, but
>  posting privileges require to contact the list owner first.
>
>This would solve the problem of interested people that process the
>list archive in a less elegant way. And the workload for the list
>owner should at least not be increased, while David's concern is also
>addressed.
>
>Juergen, if you think, I could help to reduce your workload as the list
>owner, feel free to add me as a co-list owner, no matter what the result
>of this discussion will be.
>
>Just my thoughts,
>
> -frank
>  
>

From: Frank Strauss <[email-masked]>
To: "NMRG (E-mail)" <[email-masked]>
Subject: Re: [nmrg] mailing list policy
Date: 08 Apr 2003 16:20:18 +0200
Lines: 22
Sender: [email-masked]

Hi!

How do you think about...

- opening subscription to all people,
- restricting the list of allowed posters to the current subscribers,
- adding a text to the mailman message footer that is appended to every
  posting, which explains that this list is read-only to anybody, but
  posting privileges require to contact the list owner first.

This would solve the problem of interested people that process the
list archive in a less elegant way. And the workload for the list
owner should at least not be increased, while David's concern is also
addressed.

Juergen, if you think, I could help to reduce your workload as the list
owner, feel free to add me as a co-list owner, no matter what the result
of this discussion will be.

Just my thoughts,

 -frank

content-class: urn:content-classes:message
Subject: RE: [nmrg] mailing list policy
Date: Tue, 8 Apr 2003 09:57:27 -0400
From: "Harrington, David" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, "NMRG (E-mail)" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2FDD6.C9D4F910
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I don't know why the original decision was made to maintain a closed =
list, but I suspect it was because the open IETF lists were so =
unproductive.=20
=20
I am concerned that some people really like to talk and they can =
seriously monopolize a mailinglist. I have already unsubscribed from =
some IETF lists that interest me because the signal-to-noise ratio got =
too low as the result of incessant talkers. One problem is that mailing =
lists can turn into philosophical forums, with endless debates rather =
than real down-to-earth research. The IETF suffers greatly from this =
malady, with many lists being dominated by a few verbose people; the =
number of new ideas is low compared to the number of emails.
=20
I would not like to see that happen to the NMRG list because I find the =
NMRG list has been well-focused. We tend to select a topic area for =
research and focus efforts on that topic, including reports about =
ongoing prototypes and so on. A strong benefit of the NMRG is they work =
on validating their research with prototypes, and measurements, or by =
publishing papers that work to finalize the debates. They don't go on =
and on like IETF debates do.
=20
I have expressed concern in the past that projects that are being =
actively engineered in the IETF should not be addressed by the NMRG. I =
think we should avoid cross-contamination; we are not part of the IETF. =
We should work on research of not-well-understood problems that are not =
already being addressed by the IETF. We don't want to be a subset of the =
IETF or a competitor to the IETF. We should focus on topics not being =
addressed by the IETF.=20
=20
The latest discussion on the NMRG list is about the ambiguous =
terminology being used in an emerging IETF effort - netconf. The IETF =
has been working on configuration for over two years, is obviously about =
to officially take on the problem of defining a "configuration" protocol =
solution, and it is now in their court to determine just what =
"configuration data" means. They need to define their own scope; we =
should stay out of it. I think this discussion belongs on the netconf =
mailing list, not the NMRG mailing list. If there was no netconf list, =
then I might agree that it is a difficult problem that could use some =
serious research, but the IETF has decided to take on engineering a =
solution to this problem, there is a netconf list, and the discussion =
about appropriate terminology belongs there, as part of defining the =
information model for the netconf effort, not in the NMRG.
=20
I have serious concerns that opening up this list will make NMRG yet =
another IETF-oriented gabfest rather than a focused forum that produces =
real results.
=20
dbh

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, April 08, 2003 6:51 AM
To: Network Management Research Group
Subject: [nmrg] mailing list policy

I would like to start a discussion about our current mailing list
policy. Right now, the NMRG mailing list is a more or less closed list
with a public archive. When the NMRG started, there was a decision to
operate the list this way in order to stay focussed.

There is an increasing number of people who like to follow what is
going on in the NMRG. Some of them managed to build scripts that scan
the archive and feed the result back into local lists. Others try to
get on the list which increases my workload (and in fact, many of
these requests actually stay in some queues for quite some time, which
is unfortunate).

Since the list is now operated by mailman, which allows quite some
control over the various rights people have, I like to propose to open
up the list so that interested people can just subscribe. This is
basically a move from a pessimistic approach (keep the list closed so
it won't suffer from distracting discussions) towards an optimistic
approach (keep the list open but be prepared to react in case
something unpleasant happens). The direct benefit of running the NMRG
list as an open list is that the maintainer does not have to handle
subscribe requests on an individual basis and that people do not have
to deploy mail archive scanning scripts to follow the list.

Please think about this. If you agree with opening up the list, just
do nothing. If you disagree, please send a note explaining why you
think this is a bad idea and try to propose a mechanism which allows
the list maintainer to better handle subscribe requests. The deadline
for such emails is Friday 18th (10 days).

/js

--
Juergen Schoenwaelder    < http://www.iu-bremen.de/>
--
!! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C2FDD6.C9D4F910
Content-Type: text/html;
	charset="iso-8859-1"
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">
<TITLE>[nmrg] mailing list policy</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't know why the original decision was made to maintain a closed list, =
but I=20
suspect it was because the open IETF lists were so unproductive.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>I am=20
concerned that some people really like to talk and they can seriously =
monopolize=20
a mailinglist. </FONT></SPAN><SPAN class=3D366365612-08042003><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I have already unsubscribed from some IETF =
lists that=20
interest me because the signal-to-noise ratio got too low as the result =
of=20
incessant talkers. One problem is that mailing lists can turn into =
philosophical=20
forums, with endless debates rather than real down-to-earth research. =
The IETF=20
suffers greatly from this malady, with many lists being dominated by a =
few=20
verbose people; the number of new ideas is low compared to the number of =

emails.</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
would not like to see that happen to the NMRG list because I find the =
NMRG list=20
has been well-focused. We tend to select a topic area for research and =
focus=20
efforts on that topic, including reports about ongoing prototypes and so =
on. A=20
strong benefit of the NMRG is they work on validating their research =
with=20
prototypes, and measurements, or by publishing papers that work to =
finalize the=20
debates. They don't go on and on like IETF debates =
do.</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>I have=20
expressed concern in the past that&nbsp;projects that are being actively =

engineered in the IETF should not be addressed by the NMRG.&nbsp;I think =
we=20
should avoid cross-contamination; we are not part of the IETF. We should =
work on=20
research of not-well-understood problems that are not already being =
addressed by=20
the IETF. We don't want to be a subset of the IETF or a competitor to =
the IETF.=20
We should focus on topics not being addressed by the IETF. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
latest discussion on the NMRG list&nbsp;is about the ambiguous =
terminology being=20
used in an emerging IETF effort - netconf. The IETF has been working on=20
configuration for over two years, is obviously about to officially take =
on the=20
problem of defining a "configuration" protocol solution, and it is now =
in their=20
court to determine just what "configuration data" means. They need to =
define=20
their own scope; we should stay out of it. I think this discussion =
belongs on=20
the netconf mailing list, not the NMRG mailing list. If there was no =
netconf=20
list,&nbsp;then I might agree that it is a difficult problem that could =
use some=20
serious research, but&nbsp;the IETF has decided to take on engineering a =

solution to this problem, there is a netconf list, and the discussion =
about=20
appropriate terminology belongs there, as part of defining the =
information model=20
for the netconf effort, not in the NMRG.</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003></SPAN><SPAN =
class=3D366365612-08042003><FONT=20
face=3DArial color=3D#0000ff size=3D2>I have serious concerns that =
opening up this=20
list will make NMRG yet another IETF-oriented gabfest rather than a =
focused=20
forum that produces real results.</FONT></SPAN></DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D366365612-08042003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Juergen =
Schoenwaelder=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, April 08, =
2003 6:51=20
  AM<BR><B>To:</B> Network Management Research Group<BR><B>Subject:</B> =
[nmrg]=20
  mailing list policy<BR><BR></FONT></DIV><!-- Converted from text/plain =
format --><BR>
  <P><FONT size=3D2>I would like to start a discussion about our current =
mailing=20
  list<BR>policy. Right now, the NMRG mailing list is a more or less =
closed=20
  list<BR>with a public archive. When the NMRG started, there was a =
decision=20
  to<BR>operate the list this way in order to stay =
focussed.<BR><BR>There is an=20
  increasing number of people who like to follow what is<BR>going on in =
the=20
  NMRG. Some of them managed to build scripts that scan<BR>the archive =
and feed=20
  the result back into local lists. Others try to<BR>get on the list =
which=20
  increases my workload (and in fact, many of<BR>these requests actually =
stay in=20
  some queues for quite some time, which<BR>is =
unfortunate).<BR><BR>Since the=20
  list is now operated by mailman, which allows quite some<BR>control =
over the=20
  various rights people have, I like to propose to open<BR>up the list =
so that=20
  interested people can just subscribe. This is<BR>basically a move from =
a=20
  pessimistic approach (keep the list closed so<BR>it won't suffer from=20
  distracting discussions) towards an optimistic<BR>approach (keep the =
list open=20
  but be prepared to react in case<BR>something unpleasant happens). The =
direct=20
  benefit of running the NMRG<BR>list as an open list is that the =
maintainer=20
  does not have to handle<BR>subscribe requests on an individual basis =
and that=20
  people do not have<BR>to deploy mail archive scanning scripts to =
follow the=20
  list.<BR><BR>Please think about this. If you agree with opening up the =
list,=20
  just<BR>do nothing. If you disagree, please send a note explaining why =

  you<BR>think this is a bad idea and try to propose a mechanism which=20
  allows<BR>the list maintainer to better handle subscribe requests. The =

  deadline<BR>for such emails is Friday 18th (10=20
  days).<BR><BR>/js<BR><BR>--<BR>Juergen Schoenwaelder&nbsp;&nbsp;&nbsp; =
&lt;<A=20
  =
href=3D"http://www.iu-bremen.de/">http://www.iu-bremen.de/</A>&gt;<BR>--<=
BR>!!=20
  This message is brought to you via the `nmrg' mailing list.<BR>!! =
Please do=20
  not reply to this message to unsubscribe. To unsubscribe or =
adjust<BR>!! your=20
  settings, send a mail message to =
&lt;[email-masked]&gt;<BR>!! or=20
  look at <A=20
  =
href=3D"https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg">https://www.ib=
r.cs.tu-bs.de/mailman/listinfo/nmrg</A>.<BR></FONT></P></BLOCKQUOTE></BOD=
Y></HTML>

------_=_NextPart_001_01C2FDD6.C9D4F910--

Date: Tue, 8 Apr 2003 12:50:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] mailing list policy
Sender: [email-masked]

I would like to start a discussion about our current mailing list
policy. Right now, the NMRG mailing list is a more or less closed list
with a public archive. When the NMRG started, there was a decision to
operate the list this way in order to stay focussed.

There is an increasing number of people who like to follow what is
going on in the NMRG. Some of them managed to build scripts that scan
the archive and feed the result back into local lists. Others try to
get on the list which increases my workload (and in fact, many of
these requests actually stay in some queues for quite some time, which
is unfortunate).

Since the list is now operated by mailman, which allows quite some
control over the various rights people have, I like to propose to open
up the list so that interested people can just subscribe. This is
basically a move from a pessimistic approach (keep the list closed so
it won't suffer from distracting discussions) towards an optimistic
approach (keep the list open but be prepared to react in case
something unpleasant happens). The direct benefit of running the NMRG
list as an open list is that the maintainer does not have to handle
subscribe requests on an individual basis and that people do not have
to deploy mail archive scanning scripts to follow the list.

Please think about this. If you agree with opening up the list, just
do nothing. If you disagree, please send a note explaining why you
think this is a bad idea and try to propose a mechanism which allows
the list maintainer to better handle subscribe requests. The deadline
for such emails is Friday 18th (10 days).

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Tue, 8 Apr 2003 10:22:39 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> Frank Strauss writes:

Frank> This is a good example which shows that our terminology and
Frank> classification according to this terminology is not generally
Frank> valid, but just valid for the NETCONF efforts: Generally
Frank> speaking the IP address is of course a configured value and
Frank> DHCP - the dynamic host _configuration protocol_ might be the
Frank> way to configure it and the reason why just _we_ don't regard
Frank> it as a piece of configuration data.

s/configuration data/provisioned configuration data/g

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

From: Frank Strauss <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nmrg] Terminology help
Date: 08 Apr 2003 10:20:02 +0200
Lines: 16
Sender: [email-masked]

Hi!

Juergen> [... one] can view "configuration data" as a subset of
Juergen> "control data". Note that you can't decide by the type of
Juergen> information whether it is configuration data or
Juergen> non-configuration data (e.g. an IP address might be
Juergen> configured or learned dynamically via DHCP).

This is a good example which shows that our terminology and
classification according to this terminology is not generally valid,
but just valid for the NETCONF efforts: Generally speaking the IP
address is of course a configured value and DHCP - the dynamic host
_configuration protocol_ might be the way to configure it and the
reason why just _we_ don't regard it as a piece of configuration data.

 -frank

Date: Tue, 8 Apr 2003 09:49:29 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> Margaret Wasserman writes:

Margaret> Perhaps it would help if I explained why we want a clear
Margaret> distinction between configuration information and
Margaret> non-configuration information (what I've called "operational
Margaret> state" in the past)?

[...]

Margaret> Does that make sense?

I think I very well understand the issue. My point here is that the
question whether a given piece of control information is configuration
or not is just an attribute of that particular information. For
example, the IP address assigned to an interface can be configuration
or not. What matters is whether the IP address has been marked as a
configuration that will be reestablished when this particular
configuration is reloaded.

If we agree on this, then everyting boils down to having a mechanism
to associate control information to configuration(s). There are
different ways to do this - the netconf approach is to use different
operations. In SNMP land, one would have used different contexts (or
special configuration columns which name the configurations a given
row is part of).

>> Do you think the general model where configuration data is
>> considered a subset of control data does not work?

Margaret> I don't know if this would work or not.  Is configuration
Margaret> data a well-enough defined subset of control data that it
Margaret> would be possible to make a binary determination between
Margaret> configuration data and everything else using this model?

See above. The function f(o, c) that determins whether a given control
o is part of a specific configuration c needs to be established as
part of the configuration process on the device.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Tue, 08 Apr 2003 00:52:44 -0400
To: Juergen Schoenwaelder <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: [nmrg] Terminology help
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hi Juergen,

At 07:40 PM 4/7/2003 +0200, Juergen Schoenwaelder wrote:
>I agree that there is a difference betwen control and configuration
>_operations_. But the data being manipulated is probably not very
>different - what differs is the persistence of the modification.

I'm not sure what you mean by the data being "not very different".

Perhaps it would help if I explained why we want a clear distinction
between configuration information and non-configuration information
(what I've called "operational state" in the past)?

Operators want to be able to dump the running configuration of a
box, compare it to a stored configuration, restore a complete
configuration from a dump, etc.  In order for this work, they
need a way to access the configuration information on a box
without seeing any of the dynamic state.

For example, the static routes configured in the routing table
at initialization would be considered configuration data, but all
of the routes placed there at runtime by routing protocols would
not be configuration data.  So, when an operator dumps the box
configuration, he wants to get the static routes, but not the
dynamic routes.

It isn't only a difference between static and dynamic, though.
For instance, the ethernet address of an interface would be
static, but it wouldn't be part of the configuration data
(unless, of course, it was set by the software at initialization).

Does that make sense?

>Do you think the general model where configuration data is considered
>a subset of control data does not work?

I don't know if this would work or not.  Is configuration data a
well-enough defined subset of control data that it would be possible
to make a binary determination between configuration data and
everything else using this model?

Margaret

Date: Mon, 7 Apr 2003 19:40:12 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> David T Perkins writes:

David> In the terminology below, in the past, SNMP was described by
David> others as providing operations to monitor and control devices,
David> and for devices to send unsolicited event reports. In my
David> descriptions of SNMP, I changed the description to say,
David> configure, control, and monitor, plus unsolicited event
David> reporting. That is, to me "control" is very different from
David> "configuration". An example of "control" would be to "reset" a
David> sub-component. This operation does not change the configuration
David> of the sub-component.

I agree that there is a difference betwen control and configuration
_operations_. But the data being manipulated is probably not very
different - what differs is the persistence of the modification.

Do you think the general model where configuration data is considered
a subset of control data does not work?

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Mon, 07 Apr 2003 10:13:38 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

HI,

Thanks for the info below, and the reference in the follow up
message. Hopefully, I'll be able to access a copy of the reference.

If you are following the NETCONF mailing list, there is continued
conflict about separating out configuration information from
non-configuration info, and determining the need for separate
operations for modifying (and retrieving) configuration of a
managed device.

I do think that a short definitions paper from the NMRG would
be much appreciated and helpful to the work of the to be created
NETCONF group.

In the terminology below, in the past, SNMP was described by others
as providing operations to monitor and control devices, and for 
devices to send unsolicited event reports. In my descriptions of
SNMP, I changed the description to say, configure, control, and
monitor, plus unsolicited event reporting. That is, to me "control"
is very different from "configuration". An example of "control"
would be to "reset" a sub-component. This operation does not change
the configuration of the sub-component.

Here is another example. Consider driving a car. Turning the
steering wheel and pressing the brake or accelerator are all,
to me, control operations. On the other hand, setting the
"cruise control" to a speed in configuration. Engaging or
disengaging the cruise control could be argued to be a control,
or a configuration operation.

In general, it seems like "high level" control operations can
result in one or more specific configuration operations (which
are internal to the managed device).

At 06:06 PM 4/7/2003 +0200, Juergen Schoenwaelder wrote:
>>>>>> David T Perkins writes:
>David> In the NETCONF design group, many of the members use the terms
>David> "configuration information" and "state information". With the
>David> term "state information" meaning all non-configuration
>David> information.  The term "state" really bothers me because to me,
>David> "state information" is a subset of non-configuration
>David> information. That is, to me, non-configuration information
>David> includes: 1) statistics - "the integration of measurements over
>David> time" 2) state - the current condition of components and
>David> sub-components 3) attributes - properties of components and
>David> sub-components (for example, the SNMP object type sysContact is
>David> an attribute of the system) 4) linkage - specifies the
>David> relationships between components
>
>I agree that having a good agreed terminology here would be valuable.
>Here is another proposal. I distinguish data on a system into the
>following categories:
>
>control data    - parameters that influence the behaviour of the system
>                  (changes through explicit configuration or through
>                   protocols that control parts of a system)
>
>statistical data - metrics obtained through the operation of the system
>                  (changes permanently during the operation of the system)
>
>structural data - data that describes the structure of the system
>                  (changes slowly, usually only through hardward or
>                   software reconfigurations)
>
>With this terminology in place, on can view "configuration data" as a
>subset of "control data". Note that you can't decide by the type of
>information whether it is configuration data or non-configuration data
>(e.g. an IP address might be configured or learned dynamically via
>DHCP).
>
>Note that RFC 1404 further subdivides the category of statistical
>data into the following four major categories:
>
>    - Utilization metrics
>    - Performance metrics
>    - Availability metrics
>    - Stability metrics
>
>I think this is reasonable. Note, I think there has been some previous
>work which suggested the groupings I have used above which was
>basically driven by the need to design database schemas for network
>management data and it turned out that the three categories listed
>above make a big differences because of the update frequencies.
>Unfortunately, the details have been swapped out of my brain.
>
>Comments? Shall we try to write a short document which focusses on
>these terms and tries to explain them?
>
>/js
Regards,
/david t. perkins 

Date: Mon, 7 Apr 2003 18:10:23 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> Juergen Schoenwaelder writes:

Juergen> Note, I think there has been some previous work which
Juergen> suggested the groupings I have used above which was basically
Juergen> driven by the need to design database schemas for network
Juergen> management data and it turned out that the three categories
Juergen> listed above make a big differences because of the update
Juergen> frequencies.  Unfortunately, the details have been swapped
Juergen> out of my brain.

I just found the reference:

@InProceedings{HBRBD93,
  author =       "J. Haritsa and M. Ball and N. Roussopoulos and J.
                 Baras and A. Datta",
  title =        "{Design of the MANDATE MIB}",
  booktitle =    "Proc. International Symposium on Integrated Network
                 Management",
  pages =        "85--96",
  month =        apr,
  year =         "1993",
}

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Mon, 7 Apr 2003 18:06:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

>>>>> David T Perkins writes:

David> In the NETCONF design group, many of the members use the terms
David> "configuration information" and "state information". With the
David> term "state information" meaning all non-configuration
David> information.  The term "state" really bothers me because to me,
David> "state information" is a subset of non-configuration
David> information. That is, to me, non-configuration information
David> includes: 1) statistics - "the integration of measurements over
David> time" 2) state - the current condition of components and
David> sub-components 3) attributes - properties of components and
David> sub-components (for example, the SNMP object type sysContact is
David> an attribute of the system) 4) linkage - specifies the
David> relationships between components

I agree that having a good agreed terminology here would be valuable.
Here is another proposal. I distinguish data on a system into the
following categories:

control	data	- parameters that influence the behaviour of the system
		  (changes through explicit configuration or through
		   protocols that control parts of a system)

statistical data - metrics obtained through the operation of the system
		  (changes permanently during the operation of the system)

structural data	- data that describes the structure of the system
		  (changes slowly, usually only through hardward or
		   software reconfigurations)

With this terminology in place, on can view "configuration data" as a
subset of "control data". Note that you can't decide by the type of
information whether it is configuration data or non-configuration data
(e.g. an IP address might be configured or learned dynamically via
DHCP).

Note that RFC 1404 further subdivides the category of statistical
data into the following four major categories:

    - Utilization metrics
    - Performance metrics
    - Availability metrics
    - Stability metrics

I think this is reasonable. Note, I think there has been some previous
work which suggested the groupings I have used above which was
basically driven by the need to design database schemas for network
management data and it turned out that the three categories listed
above make a big differences because of the update frequencies.
Unfortunately, the details have been swapped out of my brain.

Comments? Shall we try to write a short document which focusses on
these terms and tries to explain them?

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

Date: Fri, 04 Apr 2003 17:07:59 -0500
From: "Dave Sidor" <[email-masked]>
Organization: Nortel Networks
To: "David T. Perkins" <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] Terminology help
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------E722015B1BCB5273047D0B62
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

The telecom industry standards bodies (SG 4, 3GPP, etc) view state
functionality as a subset of configuration functionality (see section
7.5 in attached excerpt from M.3400 FCAPS summary) and generally follow
the state attribute semantics of X.731.

Dave

"David T. Perkins" wrote:
> 
> HI,
> 
> In the NETCONF design group, many of the members use the terms
> "configuration information" and "state information". With the term
> "state information" meaning all non-configuration information.
> The term "state" really bothers me because to me, "state information"
> is a subset of non-configuration information. That is, to me,
> non-configuration information includes:
>   1) statistics - "the integration of measurements over time"
>   2) state - the current condition of components and sub-components
>   3) attributes - properties of components and sub-components
>      (for example, the SNMP object type sysContact is an
>       attribute of the system)
>   4) linkage - specifies the relationships between components
> 
> Do any of you guys have better terms?
> 
> Thanks,
> /david t. perkins
> 
> --
> !! 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 https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
--------------E722015B1BCB5273047D0B62
Content-Type: application/msword;
 name="M.3400 T of C.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="M.3400 T of C.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAswAAAAAA
AAAAEAAAtQAAAAEAAAD+////AAAAALEAAACyAAAA////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------E722015B1BCB5273047D0B62--

From: Frank Strauss <[email-masked]>
To: "David T. Perkins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] Terminology help
Date: 04 Apr 2003 10:46:49 +0200
Lines: 44
Sender: [email-masked]

Hi!

David T Perkins writes:

David> In the NETCONF design group, many of the members use the terms
David> "configuration information" and "state information". With the term
David> "state information" meaning all non-configuration information.
David> The term "state" really bothers me because to me, "state information"
David> is a subset of non-configuration information. That is, to me,
David> non-configuration information includes:
David>   1) statistics - "the integration of measurements over time"
David>   2) state - the current condition of components and sub-components
David>   3) attributes - properties of components and sub-components
David>      (for example, the SNMP object type sysContact is an
David>       attribute of the system)
David>   4) linkage - specifies the relationships between components

David> Do any of you guys have better terms?

I agree that we need a precisely defined terminolgy and I like your
observation and proposal in general. However, the terms "attributes"
and "linkage" above are not 100% non-configuration terms, in my
opinion.  sysContact is a good example for a property that is
configured.

As far as I am aware of the XMLCONF draft, we do not really need a
sub-classification there as given by your list (1)-(4) above. I think
it would be a simple (i.e., easy to understand) approach to simply
talk about "configuration data" and "non-configuration data", with the
term "non-configuration data" just explained at one place somewhere in
document's intro.

How about this classification:

configuration data - data that is required to bring a system to the
  intended operational state at any point in time. The nature of
  configuration data is static.

non-configuration data - data that can be derived, composed, or
  computed at any point in time from the ongoing operation of the
  system, such as counters, statistics, accounting data, and state
  information. The nature of non-configuration data is dynamic.

 -frank

Date: Thu, 03 Apr 2003 10:50:52 -0800
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Terminology help
Sender: [email-masked]

HI,

In the NETCONF design group, many of the members use the terms
"configuration information" and "state information". With the term
"state information" meaning all non-configuration information.
The term "state" really bothers me because to me, "state information"
is a subset of non-configuration information. That is, to me,
non-configuration information includes:
  1) statistics - "the integration of measurements over time"
  2) state - the current condition of components and sub-components
  3) attributes - properties of components and sub-components
     (for example, the SNMP object type sysContact is an
      attribute of the system)
  4) linkage - specifies the relationships between components

Do any of you guys have better terms?

Thanks,
/david t. perkins