>>>>> Harrington, David =
writes:
Dave>=20
In SNMP land, some people might have used contexts to =
separate,
Dave>=20
for example, configuration from statistics, or to separate, =
for
Dave>=20
example, the running config from the startup config, but =
others
Dave>=20
would not because they used contexts to separate physical =
or
Dave>=20
logical instantiations of mibs based on other criteria, such =
as
Dave>=20
different boards in a chassis.
Since context are identified by =
strings,=20
it would even be possible to
structure them (e.g. =
"board3@startup"). But=20
since we never managed to
produce a document on how to use =
contexts, this=20
is all more theory
than established practice.
I would say it is more established practice than =
theory=20
;-)
Vendors already use contexts in shipping=20
products.
The use of contexts has not yet been standardized, and =
theories=20
of best current practice have not been=20
published.
Dave> The point is that there is a =
new=20
distinction being made, and it
Dave> probably will need a new =
mechanism.=20
In SNMP-land this would
Dave> probably be a new field in an =
object=20
definition, or a new
Dave> clause similar to a conformance or =
group=20
statement.
I do not thing that this works since the distinction =
which=20
controls
belong to a certain configuration (yes, I assume a box can =
have
multiple configurations) is a runtime decision and not a SMI=20
design
time decision.
Two different issues
1) whether objects should be considered =
configuration data=20
is something that can be recommended/standardized, although issues =
such as=20
DHCP will mean implementors may have to make exceptions. Identifying =
objects=20
as configuration data can be done in the mib =
module.
2) which set of configuration data the =
objects belong=20
to cannot be specified in a mib module because that is a runtime =
decision, and=20
it varies with time.
Dave> I do not think it =
will be=20
easy to separate configuration data
Dave> from other types of =
data; the=20
same data typically is used in
Dave> multiple scenarios. =
Duplicate sets=20
of data, or a mechanisms that
Dave> allows data to be marked for =
multiple uses will probably be
Dave> needed.
Correct. And =
this is=20
what contexts do. I recall discussions around
this usage of =
contexts from=20
the first NMRG meeting where I proposed to
define get-config and =
set-config=20
operations for SNMP...
I wasn't at the first NMRG =
meeting.
We discussed time-related configuration=20
contexts in SNMPv2 =
around=20
1994. I don't know if it would be possible to locate any =
archives of=20
those discussions.
It was eventually dropped because of the complexity. =
We did keep=20
the notion of contexts for mib-instancing, and physical and logical =
separation=20
of data subsets. Configuration contexts of some sort could be =
developed, I=20
agree, but I believe using the existing context mechanism will not=20
work.
From=20
RFC3411:
Typically, =
there are many=20
instances of each managed object type
within a =
management=20
domain. For simplicity, the method for
identifying =
instances=20
specified by the MIB module does not allow each
=
instance to be=20
distinguished amongst the set of all instances within
=
a=20
management domain; rather, it allows each instance to be=20
identified
only within some scope or "context", where =
there=20
are multiple such
contexts within the management =
domain. =20
Often, a context is a
physical device, or perhaps, a =
logical=20
device, although a context can
also encompass multiple =
devices, or a subset of a single device, or
even a =
subset of=20
multiple devices, but a context is always defined as
a =
subset=20
of a single SNMP entity. Thus, in order to identify =
an
=20
individual item of management information within the=20
management
domain, its contextName and contextEngineID =
must be=20
identified in
addition to its object type and its=20
instance.
A=20
configuration context, such as startup, might need to contain objects =
for=20
multiple objects of the same object definition. For example, a vendor =
might=20
have multiple cards in a chassis or multiple devices in a stack that =
are=20
managed through a common SNMP agent. Each card or stack may implement =
the same=20
mib module. The instances of the mib module are differentiated by =
context, so=20
blade#1's rptrPortAdminStatus would be in a different context than =
blade#2's=20
rptrPortAdminStatus.
How=20
would you represent both these objects in the startup config context, =
since=20
you would need the blade1 context and the blade2 context to uniquely =
identify=20
these instances?
I=20
believe another mechanism would be needed to different configuration =
data sets=20
because context is already used to differentiate mib=20
instances.
Dave> Even=20
then, there is some data that will be hard to categorize
Dave> =
cleanly,=20
such as DHCP-assigned addresses. In SNMP land, I =
think
Dave>=20
having an independent clause, like a conformance clause, =
would
Dave> be=20
preferable to a new field in an object definition because =
it
Dave> would=20
be easy to apply to existing mibs, and, like conformance
Dave> =
clauses,=20
it could identify conditions when it was valid to not
Dave> =
consider the=20
data to be configuration data, such as when an IP
Dave> address =
is=20
assigned by DHCP.
Again, such a distinction is not static and =
thus more=20
SMI mechanisms
won't help. Trying to write down all the various =
ways to=20
dynamically
assign IP addresses alone would be a task without an =
end.
But it would be possible to write a clause that read =
"IP=20
addresses that are established statically by the system should be =
included in=20
configuration data"
Using configuration contexts in any sort of =
interoperable=20
manner would seem to require being able to identify what is included =
in the=20
context.
/js
--
Juergen=20
Schoenwaelder <http://www.iu-bremen.de/>
------_=_NextPart_001_01C2FEB0.ADECBFC0--
is the serialization/deserialization of XML documents. The code for DOM,
which is often used for this purpose, may be 10 times bigger than that
needed to store the XML document. Therefore, never keep a DOM tree if
you want to be scalable, use SAX or a streaming API (adaptive DOM).
The attendees ask whether there are comparison studies between BER and
XML encoding. We feel that there is a lack of studies in this area.
2H) Ease of implementation
--------------------------
Bert tells that one of the main issues with SNMP is the complexity of
implementing MIBs in the devices. SNMP MIBs are not implemented
immediately when new features are implemented in products, CLI is
implemented instead. MIBs are then implemented very slowly, as vendors
have no incentive to implement them promptly. How will WS relate to
this?
Aiko reports on some experiments to implement a Get method in WSDL.
After a learning curve of one to two weeks, things are relatively
simple to implement (both manager and agent). Only need a few lines of
code in the server and client; everything else is libraries, etc.
The question was raised whether developers can be brain washed so that
the first thought when they have a new feature is to write an WSDL
interface for it? Aiko thinks there are better development tools
available for Web-Services, compared to SNMP tools (especially at the
manager side).
2I) Security
------------
Randy mentions that we should not forget security and asks whether
Web-Services helps to address these problems. Does XML digital
signature address the requirements? what about XML encryption? It was
noted that the signature and encryption header is used to identify
identities that send messages.
3) XML
------
At the second day XML was discussed. We primarily discussed
experiences of attendees in this area.
3A) Juniper
-----------
Phil explained the Juniper approach. Their internal management daemon
(mgd) is completely based on XML. The CLI talks XML to the management
daemon, using a rendering engine. It is interesting that the CLI use
many pieces of the XML code. The communication is based on an XML RPC
mechanism, where the whole session maps on a single XML document.
Juniper provides DTDs, but only because they were once needed, XML
schema is the way to go. The management daemon may pass calls to other
daemons via XML. There is an SNMP agent, which does not share any code
with the XML daemon. Phil shows some examples and explains the internal
workings of Junoscript.
Juniper had originally a CLI which was not based on XML. Internally
everything is based on meta-data, which drives the rendering and other
things. Adding parsers is therefore doable, without having to touch
all parts of the system.
Juniper uses a self-written pull-based parser, which implements a
subset of XML. Margaret thinks that it is a good idea to use a
restricted set of XML in order to put parsers into memory constraint
systems. Margaret wants to investigate what element of XML make
parsers too memory hungry.
3B) Lucent
----------
Larry Menton (researcher at Lucent) sent some slides, and presented
them via speaker phone. Larry has worked at Lucent Tech for 22 years,
involved in NW management, agents and other data networking products.
[See slides for details of presentation.]
4) How should the IETF proceed?
-------------------------------
Discussion of what type of work makes sense in this space for the IETF
to do. Bert: There are a lot of things that aren't standardizable. So,
is there anything left here that makes sense for the IETF to
standardize?
Randy proposed to differentiate between trying to standardize the CLI
(in XML, text, etc.) and trying to standardize some mechanisms by
which you configure the universe. How do we download the configuration
in XML? What is our transport? There are syntax primitives and
transport for configuring, and then there is the syntax/semantics for
the actual configuration information. Randy believes that it is
important to get agreement on the first part, not on the second.
There seems to be a feeling in multiple groups that we should
standardize the transport & the operations, but not the structure of
the data (i.e. schema). The following picture appeared:
+------------+
| Content | -----> Should remain vendor-specific???
+------------+ --+
| Operations | |
+------------+ |
| RPC Mech | +--> Interesting parts to standardize.
+------------+ | (We also understand how to do this?)
| Transport | |
+------------+ --+
For instance, we could use (from bottom up) HTTP, SOAP and WSDL. In
that case we might have to standardize a set of WSDL operations. Aiko
proposed to standardize operations like:
get/set/create/delete/dump/restore. Phil proposed:
create/delete/update/delete + rollback/lock/unlock (update has
replace/merge modifiers).
5) What will the IRTF do with the results of this meeting?
----------------------------------------------------------
A key issue will be to create prototypes and make these
available to each other. Some people (Olivier, Aiko) volunteered to
proceed in this area.
J.P. and Mario noted that it might be useful to write a requirements
document and send it to the W3C. Such document should detail what the
requirements are for the WS architecture to be used for network
management. J.P. is willing to co-author, but can't write it alone.
Bert would like to see someone work on defining high-level operations
that we need. Aiko proposed that the NMRG holds a meeting to determine
what higher-level semantics you need to manage a network (as opposed
to a particular device), discuss transactions, etc.
6) Closing
----------
The meeting was closed at 16:30
--------------060303020804080402080206--