[NGO] Re: Why NETCONF needs a data modeling language

Jon Saperia <saperia@jdscons.com> Sun, 02 December 2007 22:46 UTC

Return-path: <ngo-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxZc-0006nG-IY; Sun, 02 Dec 2007 17:46:04 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1IyxXl-00065d-Gv for ngo-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:44:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyxXk-00064b-Oz; Sun, 02 Dec 2007 17:44:08 -0500
Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyxXi-0003Di-Ox; Sun, 02 Dec 2007 17:44:08 -0500
Received: from [192.168.20.199] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (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: <47531335.9050800@ericsson.com>
References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com> <47531335.9050800@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <1319D660-EA6A-4C07-AE39-3F179C45B29A@jdscons.com>
From: Jon Saperia <saperia@jdscons.com>
Date: Sun, 02 Dec 2007 17:43:53 -0500
To: balazs.lengyel@ericsson.com
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6
X-Mailman-Approved-At: Sun, 02 Dec 2007 17:46:03 -0500
Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' <ngo@ietf.org>
Subject: [NGO] Re: Why NETCONF needs a data modeling language
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1889729603=="
Errors-To: ngo-bounces@ietf.org

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
>> TSP NM
>> (mobil) 617-201-2655
>> (office) 978-461-0249
>> saperia@jdscons.com <mailto:saperia@jdscons.com>
>> 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
>>>> dbharrington@comcast.net <mailto:dbharrington@comcast.net>
>>>> ietfdbh@comcast.net <mailto:ietfdbh@comcast.net>
>>>
>>>
>

Thanks,
/jon
----
Jon Saperia
saperia@jdscons.com
(mobil)	617-201-2655
(office)	978-461-0249



_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo