[Taps] Potential alternatives to YANG

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 29 March 2019 11:53 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4600120316 for <taps@ietfa.amsl.com>; Fri, 29 Mar 2019 04:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 By_vRtVTGBbh for <taps@ietfa.amsl.com>; Fri, 29 Mar 2019 04:53:01 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1097D12039F for <taps@ietf.org>; Fri, 29 Mar 2019 04:53:01 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 4CC5125A1F for <taps@ietf.org>; Fri, 29 Mar 2019 12:52:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553860379; bh=vP2IHONX7jN4/hNS0EptBcvU+5XGLwzIDqSOoZsElyc=; h=From:To:Subject:Date:From; b=V9nCMmbocRJXo4rt1Q1mx9QtOUAhOVuUox5eHc9ZUyU9+wQnT4pne2SS+S0/AhQri MuR5ASLlKghP/tgAKsFamCojjWs7+AQMbSYdK8aEQHKfnNqKpXCHyiW6LrGOdafgDH UZiXTCm1YhW6XsYoDCvh4a8vQjWkxTHlxsKeHOsg=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z7hxPSQJCG4 for <taps@ietf.org>; Fri, 29 Mar 2019 12:52:57 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for <taps@ietf.org>; Fri, 29 Mar 2019 12:52:57 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 12:52:57 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "taps@ietf.org" <taps@ietf.org>
Thread-Topic: Potential alternatives to YANG
Thread-Index: AdTmJJkFb6Zp0XvTRsiCqia1FVlvnQ==
Date: Fri, 29 Mar 2019 11:52:56 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28CC16@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.29.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/dZaLoGkjUDv2sit9xrtxeWrb95g>
Subject: [Taps] Potential alternatives to YANG
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 11:53:16 -0000

As mentioned on the mic: There are quite a number of solutions to "rigorously" specify APIs. Some of these general-purpose techniques are IMHO also used for configuration/provisioning tasks in the networking industry, i.e., as alternative to YANG.

In a former life, I had quite some discussions on the role of YANG as compared to, for instance:

* swagger.io (https://swagger.io/)

* gRPC, gNMI and protocol buffers (see e.g. draft-openconfig-rtgwg-gnmi-spec-01 in the IETF)

In both cases there is are tooling eco-system that are IMHO widely used by app developers (and often preferred over YANG). The YANG tooling that exists in industry, e.g., for code auto-generation, is quite specific to network management, as far as I can tell.

To me, whether to develop models in YANG or in other data modeling languages depends a lot on the use case and the target software developer community. Of course, in the RTG and OPS area YANG is the default data modeling language.

Michael 
(as somebody who attends RTG and OPS working groups)