Re: [Teas] [yang-doctors] Feedback on options for issue #1 in TE tunnel YANG

Ladislav Lhotka <> Mon, 25 July 2016 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F8D312D0E0; Mon, 25 Jul 2016 06:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3CpXrbatsAop; Mon, 25 Jul 2016 06:38:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75AD512D833; Mon, 25 Jul 2016 06:38:29 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id F1FD31CC0281; Mon, 25 Jul 2016 15:38:33 +0200 (CEST)
From: Ladislav Lhotka <>
To: "Tarek Saad (tsaad)" <>, "" <>
In-Reply-To: <>
References: <>
User-Agent: Notmuch/0.22.1 ( Emacs/ (x86_64-apple-darwin14.0.0)
Date: Mon, 25 Jul 2016 15:38:39 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [Teas] [yang-doctors] Feedback on options for issue #1 in TE tunnel YANG
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jul 2016 13:38:31 -0000

Hi Tarek,

your analysis of available solutions seems correct and exhaustive. Maybe
I don't fully understand option #3 but I think you could achieve a
reasonable level of "object-orientedness" and separation of
technology-specific data by defining appropriate hierarchy of identities
(possibly with multiple inheritance, which is now possible in YANG 1.1),
and then using conditional augments.

As for option #2, the design of schema mount could perhaps include some
means for refering to data nodes and/or definitions in the parent
schema. This would however make the subschema usable only in a specific


"Tarek Saad (tsaad)" <> writes:

> Hi YANG doctors,
> We have a requirement to reuse generic data across multiple technology model instantiations for model we’re driving in draft-ietf-teas-yang-te. For this, we've identified a number of proposals and tried to summarize them in slides 7-10 in the deck @
> We are seeking your expert advice on the best way of the options to proceed with and whether there’s a precedence in other IETF models that have solved similar issues.
> Regards,
> Tarek (and co-authors)
> _______________________________________________
> yang-doctors mailing list

Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C