Re: [netmod] YANG next

Balázs Lengyel <> Wed, 24 July 2019 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 297251202C1 for <>; Wed, 24 Jul 2019 07:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SROds4f-4Ws3 for <>; Wed, 24 Jul 2019 07:28:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7949012032F for <>; Wed, 24 Jul 2019 07:28:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=DtXtSIl5qp80ruQev1mW/lzXh4Nlkwl+/IAt51I6m8znsQzT+0WklnN4tum8+F3YlIaUr+r8vlekLYjle7jPC224vl0NY5rAa1tp/E/xd4OMQ/QCvFVhqigqjntzUjI4cYoEG3l0hEFmYvVM44yy7c81hMRGyk0mFBfKBNgqJaLG5GXzcAHdY2HuY0ORDKiiMRpvzuYh0VXPXW2AVpuYAM0ljF86o1KFbKJOoHJqLhoLdJ/8l+UyWQPSypgt9RIBbkVcBvMb4AGB8yM8PhoZpIjBi/mQvkm/Mr7F6etM9uy2TTf4F0jqB6fZMe2CWF9Nse3KIKZask8OXEZM2C2WeQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7bvJv81lr9Q03X1lmpWIdZdNFR+TdMHWMsiGn9GQMBQ=; b=iprJ3FwNj20G3roOU+zEGhzTn9YPq6rlc4FSkUlJLo7MNPGQFNC2+iYM7YIF53ZSK/w7nStqK3gFuN96C/Mms+WyM5Uv7pyOOZ3SUBVPrnlRYT1vqN/SL0pF9JDvaAaFSxeB84g0rwu6CTchYka0FJiD4cN3x2Wh41iChutFmkcRfWXN0F88mUN6u4ablKxTlDQCFDzS2at3zXw/U3tlOpZ94tzPYdbb69T6mwKNzMAN57andGt216l7q3FCGX9ceoUF4hwWvxvTWoOeZhFjR3g4Qz2SzvCo48ynuuDwD9wYOKvPlqzkb/RDfv5YXZe1ClXSk4KgqQ8pUC4BIqQbxg==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7bvJv81lr9Q03X1lmpWIdZdNFR+TdMHWMsiGn9GQMBQ=; b=RrPs8nTIF03ZPB6ikeMdKEyXjpmz+WO5wmBJH7U+1H8GSgRrF4V2yvowwQ3Otml4AGcUkbUGm/llCTgXPgtXy9GUfwX2BPvjN3nAGB36zxEoKcEddRUnrXuzGQpsn/87YJSb5yRLJSd9B+r3wvSNLdxxzhyadrsiBV9RtbVxIc8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 14:28:35 +0000
Received: from ([fe80::5556:4c20:cd8d:686a]) by ([fe80::5556:4c20:cd8d:686a%11]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 14:28:35 +0000
From: Balázs Lengyel <>
To: Andy Bierman <>, Juergen Schoenwaelder <>, NETMOD WG <>
Thread-Topic: [netmod] YANG next
Date: Wed, 24 Jul 2019 14:28:34 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:67c:1232:144:1816:c5a7:7b6a:280f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: df00bef7-5daf-4677-1988-08d710433609
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2637;
x-ms-traffictypediagnostic: VI1PR0701MB2637:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(199004)(189003)(76116006)(229853002)(6506007)(186003)(486006)(6116002)(7696005)(790700001)(102836004)(46003)(53546011)(52536014)(85182001)(66616009)(478600001)(76176011)(66476007)(66446008)(64756008)(66556008)(110136005)(86362001)(2906002)(66946007)(6306002)(5660300002)(81156014)(33656002)(55016002)(53936002)(25786009)(316002)(236005)(66574012)(14444005)(99936001)(256004)(81166006)(14454004)(74316002)(6436002)(476003)(11346002)(446003)(606006)(9686003)(68736007)(71200400001)(71190400001)(85202003)(6246003)(99286004)(8936002)(54896002)(8676002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2637;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Oqxr4k5UMfCEwQR3PcLePktt21ic8y6gSsB9QRZ0pD4dGNu82/OT8ta3l5IaIrrO6ktzJMZPp4QniUh4gAnQfyCu7hyiDdP2z0RWAHWo973Jp/YUhPdMkYcX41qWYtsssRPL9aPHvWCQX2aN87VAFKepkl9PL5c4kGt8ISboToY8yd+7CaN3ywSXinLlgz03FKesJ/HkgLIOu+rrUEi2q37LG+fL+btRRJebBeQkP6B7cO4rUEmPLMbC5S7Cr9IRf7KW8kvoKzCKiSv6dHr2bw1kqeDWfmLyoXRUwlPeL54GlF5K4Ik/OpTyI586IVZWN8BEH/dgYzK+KPaO7uXa0sx4MabruG4ILAaIAPEB+zgqtkihXjM12pFIayCufQBGELKXWyH5acCqNdFJvFt4EaaVx8vD/lTXmCsBGLs9mhY=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_046C_01D5420A.8B2658F0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: df00bef7-5daf-4677-1988-08d710433609
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 14:28:35.0144 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2637
Archived-At: <>
Subject: Re: [netmod] YANG next
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 14:28:59 -0000

We already have some RFCs and drafts that propose extensions that would/could go into YANG 1.2.  I would like to have an “official” agreement/document/wiki that lists what is planned to go into 1.2 whenever it happens. That would help us to have a platform that contains a well defined set of additions beyond YANG 1.1.

Regards Balazs


From: netmod <> On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 10:10
To: Juergen Schoenwaelder <>; Andy Bierman <>; NETMOD WG <>
Subject: Re: [netmod] YANG next




On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka < <> > wrote:

Juergen Schoenwaelder < <> > writes:

> On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
>> This problem is actually not limited to YANG itself - people are reporting
>> problems with the transition to NMDA. 
> The YANG update from 1 to 1.1 mostly affected compiler writers - and
> to a much lesser extend module authors and module implementors. NMDA,
> affects client and server implementors much more directly, additional
> instrumentation on the server side needs to be written, application
> logic on the client side needs to be adjusted. NMDA is an evolution of
> architectural principles and this already indicates that there is a
> certain investment to make.

But both updates induced some changes in YANG modules that affect users and integrators. Take ietf-ospf module as an example: it is of course a great addition to the YANG module collection, but in order to use it, all tools have to support

- YANG 1.1, e.g. because of the special XPath functions, and

- NMDA, because otherwise state data are missing.

Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may get frustrated if lazy authors (including myself) don't update their tools in a timely manner.

> If we discuss YANG next, we should compare it to the YANG 1 to 1.1
> transition and not to the NMDA transition. When we started YANG 1.1

Both types of changes may have similar effects on YANG users. 

> work, there were people who said that nobody would implement it. But
> then implementations were adopted relatively fast when we finalized
> YANG 1.1.

When we started YANG 1.1, there were only a few YANG modules around with little practical use, so nobody really cared. The situation is now very different.


Not that different.

The IETF does not value stability that much.

Maybe customer expectations are different, but some of us have to follow 2 simple rules:


   - Whatever works SHALL continue to work 

   - If you changed how it works, you broke it (even if you fixed it)


Some customers even think they should be able to upgrade from any existing version to any new version,

and these rules still hold. Therefore every change in server behavior must be "opt-in" by the vendor and

maybe the client as well. Instead of automatically upgrading because of course you want the spiffy

new features, vendors want the behavior to stay exactly the same (unless they choose to change it).


There is no real need for YANG 1.2 unless and until NBC changes need to be made,

and we try to avoid doing that.








> While a collection of patches (updates) of YANG 1.1 may sound simpler,
> I am not sure this is really true. We will loose a common baseline and
> instead get complexity since we will get systems that all support
> different sets of patches (updates) of YANG 1.1. I believe we are all
> much better off if we have a common baseline language and tools that
> support the common baseline language. Again, if done right, YANG next
> will mostly affect compiler writers and tool makers and not so much
> module authors and implementors.
> /js
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>

Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67