Re: Why NETCONF needs a data modeling language

[Balazs Lengyel <[e-mail]>]

Hello,
 >>    Q1) Why does NETCONF need a DML at all?

If we have an IETF standard DML for NETCONF, device vendors (like my company) will be much 
more comfortable, much more willing to adapt NETCONF itself. With a standard DML we would 
see a better chance at having available 3rd party or even freeware toolkits for NETCONF.

The above would be important even for a company which would not care about interoperability.

Balazs

David Harrington wrote:
>  
>> 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
> [e-mail]
> [e-mail]
> 
> 
> 
> 
> 
>