IETF Logo Mail Archive

Re: Blog: YANG Really Takes Off in the Industry

Ted Lemon <Ted.Lemon@nominum.com> Tue, 02 December 2014 03:17 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CC71A006F for <ietf@ietfa.amsl.com>; Mon, 1 Dec 2014 19:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_ujTFJofA51 for <ietf@ietfa.amsl.com>; Mon, 1 Dec 2014 19:17:31 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D711A006E for <ietf@ietf.org>; Mon, 1 Dec 2014 19:17:31 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 662DBDA0121 for <ietf@ietf.org>; Tue, 2 Dec 2014 03:17:02 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1309353E072; Mon, 1 Dec 2014 19:17:01 -0800 (PST)
Received: from [192.168.0.10] (72.182.60.179) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Dec 2014 19:16:55 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Blog: YANG Really Takes Off in the Industry
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <4DD04125-EA18-499A-A060-219056E4ABE3@juniper.net>
Date: Mon, 01 Dec 2014 21:16:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-ID: <3AE8A34F-2191-4E96-9C86-ED033E8998D1@nominum.com>
References: <54770BA5.5060603@cisco.com> <809EFD2B-A845-46B7-A394-A9C9E5393CD5@piuha.net> <547874D6.1090001@cisco.com> <7890AE32-F7A9-4C32-9C3D-8251E70B1F29@lucidvision.com> <m2sigyhpxc.wl%randy@psg.com> <8BBBDF7F-00A0-44BD-AA64-DA7044D35012@lucidvision.com> <C51AC247-C16D-4452-874E-0D97BDB009EB@juniper.net> <547D0AEA.4020309@gmail.com> <0BFD0B22-EC45-473F-8E7A-7FB608B60E6F@juniper.net> <139D837E-F131-4791-A026-234699A7E617@nominum.com> <4DD04125-EA18-499A-A060-219056E4ABE3@juniper.net>
To: Dean Bogdanovic <deanb@juniper.net>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [72.182.60.179]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ImcgXKYsGgf_h5vAmFdxoeSzKQk
Cc: IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 03:17:33 -0000

On Dec 1, 2014, at 9:06 PM, Dean Bogdanovic <deanb@juniper.net> wrote:
> This is not the answer to my question.

It's certainly an answer to your question.

> I asked about adding support for another language, not how the models are architected. Vendors can (and, in my personal opinion, will) provide proprietary and standard data models. The operator can choose then which model they want to use for their purposes.

If the YANG data model is architected badly, then the vendor may not be _able_ to support that data model, and then the operator won't be able to choose that model.   If a vendor's experience of data models written in that language is that they aren't good enough, then the vendor might well decide that there's no value in supporting the language.

That said, one of the issues with YANG that has been reported back to me, but with which I do yet have specific experience of my own, is that the language is not sufficiently expressive.   E.g., it was not thought possible to express DHCP option extensions in YANG.   This would mean that certain basic functions of a DHCP server could not be supported without a non-YANG management model.

v2.23.0 | Report a Bug | By Email