The above would be important even for a company which would not care about interoperability.
Hi,
There are a few questions that the IESG and others have asked,
which I will try to address:
Q1) Why does NETCONF need a DML at all?
Q2) Why is NETCONF special?
Q3) Why won't lots of other WGs want to define their own
protocol-specific DMLs?
Q4) Why isn't XSD or RelaxNG good enough?
I'll take a whack at answering the same questions.
A1) Why does NETCONF need a DML at all?
to promote vendor-neutral interoperable management. It is much easier to develop standards when everybody uses the same
basic language to communicate; this "common language for shared
communication" is also reflected in the IETF decision to use English
text and ASCII documents.
This is not just about being able to standardize **device
management**; it is a basic step to permit the standardization of
**network management** and possibly **services management". The DML is
a basic building block.
A2) Why is NETCONF special?
It is and it isn't. Netconf is only one protocol used for network
management. It has some unique requirements, such as using a document-based
approach and differentiating the data for config versus state and for
dealing with different time-defined contexts such as running and
startup configs. This differs from other network management protocols,
such as SNMP and syslog and ipfix, which use their own data formats,
and usually deal only with the currently-running config. Netconf is a
tool designed to meet the special requirements of configuration, and
the DML needs to support special features not found in other NM-DMLs. Netconf is not special, in that any language used for network
management is likely to have certain common requirements. NM data
models are commonly used directly by humans, in their raw form, such
as when they troubleshoot problems using network sniffers. NM data
models are also commonly used by NMS applications that can handle the
translations into a more human-readable format. Designers of NM tools
(e.g., protocols and data models) thus need to pay close attention to
who will use the information, and to assume that the data will be used
both directly by humans and by applications. Operators have complained
strongly that OIDs are very hard to work with in raw form, yet
operators frequently need to deal with the raw form of the data. A3) Why won't lots of other WGs want to define their own
protocol-specific DMLs?
To paraphrase a wise man from the SNMP community, when you fill a room
with protocol designers and ask for a solution to a problem, is it a
surprise when they recommend designing a new protocol?
The decision about whether to use an existing protocol/DML or develop
a new protocol/DML should be made after a careful analysis of the
requirements of the solution. SNMP was designed when CMIP was found to
not quite address the needs. The SMI was designed when ASN.1 was found
to not quite address the needs. XML was designed when other DMLs were
found to not quite address the needs.
The decision to explore an XML-based DML and to explore a C-like DML
follows years and years and years of debate over the requiremnts of
network management, and configuration in particular. If every WG spends as much time analyzing the requirements that the
OPS area has spent considering this decision, it might be good for
ensuring no new protoocls are designed that are not really needed, but
the IETF would also grind to a halt, much as the OPS community has
done over our many years of debate. And the delay caused by our
debates has made IETF network management largely irrelevant to the
operator community (our customers).
As always, we need to be vigilant and determine whether enough thought
has been given to reuse of existing protocols. We also need to
consider the tradeoffs between new protocols and reusing existing
protocols in ways they were not designed to be used.
A4) Why isn't XSD or RelaxNG good enough?
As mentioned in A2, NM data models need to be both machine- and
human-readable. XSD is machine-readable, but it is a tough language
for humans. RelaxNG seems better. As discussed further in a different email, Netconf will almost
certainly need a DML suited to its requirements, and if RelaxNG is
found to be human-friendly-enough, we would almost certainly still
need to select a subset and adapt it to meet configuration
requirements. So the benefit of using RelaxNG over a domain-specific
DML may be lost by using an adapted-subset of RelaxNG.
Most operators already understand languages like Perl and C and
Javascript, because they already need to write lots of scripts to
manage their networks. Most implementers of NM support in
internetworking devices work in C or a variant of C. It makes a lot of
sense to use a language with a C-like syntax for these people, rather
than forcing them to learn yet another language that was designed for
some other purpose.
[soap]
somebody commented that the designers of XSD and RelaxNG really
understand how to design DMLs, implying that the OPS community does
not. Many of the people involved in the ongoing DML discussions over
the years, and now, are MIB Doctors and operators and protocol
designers, and have had years of experience designing and working with
SMI and network management. They understand the requirements of a DML
for NM far more than the designers of XSD or RelaxNG, who were not
designing their DMLs for NM purposes.
[end soap]
David Harrington
or typedefs. What if a standard data model
defines an item, say a hello timer, with such a default, but an
implementation wants to use another value for the default? Should it
come up with another schema?
Lada
RSS Feed