[NGO] Why NETCONF needs a data modeling language
"David Harrington" <ietfdbh@comcast.net> Fri, 30 November 2007 15:35 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 1Iy7tt-0006zE-Oy; Fri, 30 Nov 2007 10:35:33 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1Iy7ts-0006yi-Cl for ngo-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 10:35:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7ts-0006yD-0Q for ngo@ietf.org; Fri, 30 Nov 2007 10:35:32 -0500
Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy7tq-00081T-TH for ngo@ietf.org; Fri, 30 Nov 2007 10:35:31 -0500
Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id K0h81Y0091GXsuc0A0Cm00; Fri, 30 Nov 2007 15:35:34 +0000
Received: from Harrington73653 ([24.128.104.207]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id K3bU1Y00B4UVsHU0800000; Fri, 30 Nov 2007 15:35:34 +0000
X-Authority-Analysis: v=1.0 c=1 a=KSJUxJzPonUA:10 a=nKLD2Io1NIw4iaqvex4A:9 a=Tw-MUFs4hJt1eTxRKQoA:7 a=UJ77OrrZXaJLDYQLrM8z5A4y5kQA:4 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10
From: David Harrington <ietfdbh@comcast.net>
To: 'Andy Bierman' <ietf@andybierman.com>, discuss@apps.ietf.org
References: <474E0F71.2050003@andybierman.com>
Date: Fri, 30 Nov 2007 10:35:13 -0500
Message-ID: <241201c83366$9acf8070$6502a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <474E0F71.2050003@andybierman.com>
Thread-Index: AcgyI3BWX50RoOCBS32El4WAOg2IiQBOy49g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: yang@ietf.org, 'NETCONF Goes On' <ngo@ietf.org>
Subject: [NGO] 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>
Errors-To: ngo-bounces@ietf.org
> 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 ietfdbh@comcast.net _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo
- [NGO] Why NETCONF needs a data modeling language Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Juergen Schoenwaelder
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Juergen Schoenwaelder
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Andy Bierman
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Balazs Lengyel
- RE: [NGO] Re: Why NETCONF needs a data modeling l… Romascanu, Dan (Dan)
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- [NGO] Re: Why NETCONF needs a data modeling langu… Chris Cross
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] RE: [YANG] Re: Why NETCONF needs a data mod… David Harrington
- [NGO] Why NETCONF needs a data modeling language David Harrington
- [NGO] Re: Why NETCONF needs a data modeling langu… Martin Bjorklund
- [NGO] Re: Why NETCONF needs a data modeling langu… Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia