Re: Why NETCONF needs a data modeling language

Jon Saperia <> Sun, 02 December 2007 22:43 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IyxXb-00061c-Cb; Sun, 02 Dec 2007 17:43:59 -0500
Received: from discuss by with local (Exim 4.43) id 1IyxXZ-00060u-C7 for; Sun, 02 Dec 2007 17:43:57 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IyxXZ-00060i-2N for; Sun, 02 Dec 2007 17:43:57 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IyxXW-00031q-TZ for; Sun, 02 Dec 2007 17:43:57 -0500
Received: from [] ( []) (authenticated bits=0) by (8.13.1/8.13.7) with ESMTP id lB2Mho91028679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Dec 2007 16:43:51 -0600
In-Reply-To: <>
References: <> <241201c83366$9acf8070$> <> <> <>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--715098613
Message-Id: <>
From: Jon Saperia <>
Subject: Re: Why NETCONF needs a data modeling language
Date: Sun, 2 Dec 2007 17:43:53 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6
Cc:,, 'NETCONF Goes On' <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Wrong order - people will push (not just the vendors for convenience)  
when there is something that makes a real difference.
On Dec 2, 2007, at 3:19 PM, Balazs Lengyel wrote:

> Hello,
> Naturally our aim is to develop standard NETCONF configuration  
> models, and the more people use NETCONF the easier that will be.
> Balazs
> Jon Saperia wrote:
>> Thanks
>> /jon
>> ----------------------
>> Jon Saperia
>> (mobil) 617-201-2655
>> (office) 978-461-0249
>> <>
>> On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote:
>>> 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.
>> Yes, but does that mean that we will begin to develop a standard  
>> configuration objects for say, BGP or DiffServ that would work  
>> from one vendor to the next?  It would be nice to think so, that  
>> would really help interoperability and should be the target of  
>> 'our' collective efforts.
>> /jon
>>> 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
>>>> <>
>>>> <>

Jon Saperia
(mobil)	617-201-2655
(office)	978-461-0249