Re: [netmod] yang-data-ext issues

Kent Watsen <> Mon, 30 April 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F7F2124239 for <>; Mon, 30 Apr 2018 10:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Lv-MBFJaerE for <>; Mon, 30 Apr 2018 10:57:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E2851201F2 for <>; Mon, 30 Apr 2018 10:57:38 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w3UHsdmW014031; Mon, 30 Apr 2018 10:57:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=KhyF6yTlD9Xd96gRmEspRvtyrUbQCQJoEUvPlQTr264=; b=jof5ID2BDg02hLfz/ZNyVNhTyepxbatozlZIWb9aV18GyxgF6w66Llx0XAj5oKYm8DFA x0vdYxlkCGGHWIT87922U/HvGfSLEWdmnIXTE46127EmmI5Ko/PLs4xs05Q1bkvN+d9x 46HeufT0tGUpepc9et5Z6UiCdMOuDL3oBMbCr7hHzoQVf/dJoBVZk90EIaxjRWOn3Kb+ loHvk2gG7dcQ7RrQ9dG4yJecrA4imflG16BpyEVz4anmpj49ZttdGSUW/IFwuDkQ8x7n 21Gb2pm4tOjtCDRvPDOSeNUCIAUaRktB6Em9NkLxMXB7DzKz1M/EPVGvtk4mk4lTycBh Bw==
Received: from ( []) by with ESMTP id 2hp293rp7c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 10:57:37 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.11; Mon, 30 Apr 2018 17:57:34 +0000
Received: from ([fe80::44ac:d4a9:49d0:101e]) by ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0715.014; Mon, 30 Apr 2018 17:57:34 +0000
From: Kent Watsen <>
To: Ladislav Lhotka <>, Andy Bierman <>
CC: NetMod WG <>
Thread-Topic: [netmod] yang-data-ext issues
Date: Mon, 30 Apr 2018 17:57:34 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <20180427144708.6ekknrajexvz5yvf@elstar.local> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4152; 7:A6y4yqJ7dlIR0gfXyNi2FuD8jvl5/CsTU5Jhi0ST2pBYk8K1TWFIFwwYRlo/a9wPasdybK8SvjQVJ/VJZaot3LgJ9W9rrNCzCr9H1+sk2ikOHfWoIhIUhUmJkHdB2A8EkhXvThqKrx7mw1ZtL7ZDXAmtWR0A68hKhOdzVQ+bhn+SmvEruxCe7VE4CAThWs6aiczf2jAiWGtI2TjpBl24yNRgYJUXytqaxA0QGfXo7wOju/NefDV04D40heEUGDCS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4152;
x-ms-traffictypediagnostic: BYAPR05MB4152:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BYAPR05MB4152; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4152;
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(39860400002)(39380400002)(199004)(189003)(99286004)(110136005)(93886005)(305945005)(478600001)(2906002)(316002)(5660300001)(6486002)(14454004)(102836004)(3660700001)(6506007)(6346003)(486006)(2900100001)(186003)(68736007)(476003)(446003)(6246003)(86362001)(11346002)(2616005)(26005)(3280700002)(4326008)(58126008)(25786009)(83716003)(82746002)(97736004)(33656002)(36756003)(8936002)(229853002)(66066001)(81156014)(7736002)(5250100002)(6436002)(76176011)(6116002)(6512007)(59450400001)(53936002)(105586002)(3846002)(106356001)(8676002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4152;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: JrBPpTD1TaBh9Jx5X2ss5kD8Gnl4qoydsduTZ6EHzvKdqEPkYeHY4N5t/FHBbwgqfZ7rJc9BT5gOzsOlUXFTU70s0SAYisZBiC8gVhkIjox3ke1iKT+6lUmDhgZcPWKDqGqTYd0i6zDu7UWCBBE0uLlTdlW1s3dwjvS73+PBz3NsDV9ixmq731m6oWhyq6g7
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 90db90e5-e8cf-47e7-5ccb-08d5aec3da17
X-MS-Exchange-CrossTenant-Network-Message-Id: 90db90e5-e8cf-47e7-5ccb-08d5aec3da17
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 17:57:34.2312 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4152
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300173
Archived-At: <>
Subject: Re: [netmod] yang-data-ext issues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Apr 2018 17:57:40 -0000

Lada writes:
> Andy writes:
>>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
>>is sufficient for that purpose, which is a YANG representation of
>>an instance document (such as a protocol message or file).
> The same is basically true even without the extension. For example, I
> fail to see any benefit from using yang-data in a module like
> ietf-zerotouch-information.

I don't understand this, how else would you propose to define the
JSON-or-XML encoded payload of the CMS structure?

>> I am in favor if keeping the yang-data in RFC 8040 and not
>> creating a new version of it that is unconstrained.
>> There does not seem to be consensus on how to do this,
>> or even consensus that it is a good idea.
> If the extension is deemed necessary, I would also prefer this 
> approach to making the extension a Proposed Standard.

I don't understand talk about abandoning this draft.  There is no question
that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
'choice' between two containers and 2) it requires drafts to reference 
RFC 8040, even though the drafts may have nothing to do with RESTCONF.

Sure, maybe we have convinced ourselves that yang-data is not needed
to model error-info, but that doesn't negate the other use case.

We need a way to indicate that some data-model represents a stand-alone
data structure.  It is not configuration, operational state, an RPC, or
a notification.  It can only appear as a descendent of the 'module'
statement.  All 'action', 'notification', 'config', and 'if-feature'
descendent statements are ignored.  For the purpose of 'must' and '
when' statements, the yang-data structure is its own context root.  It
has a namespace and a unique local name (unique only to other yang-data
defined within the same module; it's okay if an RPC, notification, or
top-level data node has the same name).  Anything else?

Kent // contributor