Re: [netmod] schematree-statement extension?

Kent Watsen <kwatsen@juniper.net> Mon, 15 October 2018 19:49 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BA3130DDA for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 12:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level:
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 ER5I9k2MgYqG for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 12:49:32 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 83FB1127332 for <netmod@ietf.org>; Mon, 15 Oct 2018 12:49:32 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9FJjDcJ002402; Mon, 15 Oct 2018 12:49:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=cHlAp/UHMLbexHa/PY7ByPeOtVzn01TgmnhYSTixLZ0=; b=Nh+QTkFKLJQomM6YZItIYugAq6RB21NfkewmFdZOlEc4mmN4a7RS3fZDrCyagVTJaQGJ bZj9YRu9qdwoNUYm1hs35hM+2JKNfMenEaRUcDc3GI0IgzIuolvYYtveikubLxjazNR+ A4Ig/WMNgkHT7OteEZFG7rSby1/d7kgLO0veTbr52t/GfofF+VFaX1IkMpwW6wWmVVtz aQ0G4ifMTisK6Fb9QzP8jLgUTLyHEpOnNLWW6eoqVFW1g7IBRvw2sRhUzPif17FiXTMt qsl8hK0Yqhbrq5jVe9bnystugnCl1MqT93VQdjhD6uu5JVFn8w0SvUEWJiqSLqMg5ydT JQ==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2n4ur98m6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Oct 2018 12:49:24 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6SPR01MB0042.namprd05.prod.outlook.com (20.178.24.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.13; Mon, 15 Oct 2018 19:49:22 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1228.020; Mon, 15 Oct 2018 19:49:22 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Robert Varga <nite@hq.sk>, Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] schematree-statement extension?
Thread-Index: AQHUZLbE4000Z90T/kKAKI2z38PgOKUgq82AgAAHZgD//8DFgA==
Date: Mon, 15 Oct 2018 19:49:22 +0000
Message-ID: <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk> <20181015.210937.2105117531520960939.mbj@tail-f.com> <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
In-Reply-To: <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6SPR01MB0042; 6:H1Xl9bbBEOfZbx2OIi8S0KNoym+RzP1CUKI3RAxwmHVJMew9LZ7JXynBHxVt3Y5EYyS1h/pLuixlbgcNRD/DOnXpbVdhe8JTNgSJ1XNvhvxOBRBYRyG9oi7jme47GXrx3W4AqcRqWHCh8eRP4LnSl9CaeWiO5HKcbMfCgXo+T5oK+gq/6uoE2oQrhOkNKKU7jyUQYFcEpRBNPdfRerszGBsSRs1XZ3o3jtL36eyA1Rm7kzrrRtQ2yvOYS2Xrx5MoSpvZlWPuDbHvmpLrvmDGBg4oz/fS2Yyx9b5tskxjfSw+Cl4UDF3V2D3mqYKo00LiH7wCNOht93qj/RjUZApA9ipu9wU8YHdEQXWlFqvmeP+6yN9AmV/OrTG2TCNKWWiOmsh7u60E4AocXFoAy50VVD5wppOwUcHMB2Nqm5eKa0gisTiXDXmY5mrr78EuV2o3wiA0N098GchW+C6yn/3WIA==; 5:CbyL1+IW4y/WKB+XWs4hQDYrIz+MSPjznEwydGgivu6D2NjhcyrLH3tv+WTIm2kPJlW1nlL4qeK7h4yYjkhMNTxsjqGQIW4OF1sGFD7+PzjD/tBkM5bzppNT7j/jT5ukTGV5LdevrpVkohLgeTrZR9FN+N/P5QYJVyvwyze1aG4=; 7:GNH0x3RwWJbMQgHFcfjZE8/I5Bn4LBG70ore8W1IVAfhnGRWopuPPKQfxOEiI1s4S6OPSEYThHZG/Pa5CNe01tX6WNdAFp8RP3O6X6MpCxGFiFA+dCQHBNS51CYRksiVexnBTdJY8sUeqASP9BECGjVDcizAv3MAJvUp73C8e3fA7by+ozGSpMMYTpGWDjRDOy+mrDuo8iy9qeMq7oZflzQ4bYMNHlphrvLHlVUGfImHoGCRtgtL2mNZOO10nNAt
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4086dc52-96f8-41a3-c2c5-08d632d74de7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6SPR01MB0042;
x-ms-traffictypediagnostic: DM6SPR01MB0042:
x-microsoft-antispam-prvs: <DM6SPR01MB0042D881365264807B430AA3A5FD0@DM6SPR01MB0042.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(278428928389397);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:DM6SPR01MB0042; BCL:0; PCL:0; RULEID:; SRVR:DM6SPR01MB0042;
x-forefront-prvs: 0826B2F01B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(366004)(346002)(13464003)(189003)(199004)(316002)(14454004)(76176011)(53546011)(6506007)(110136005)(58126008)(26005)(2906002)(966005)(478600001)(105586002)(83716004)(5660300001)(86362001)(71200400001)(71190400001)(97736004)(4326008)(81156014)(5250100002)(229853002)(99286004)(186003)(102836004)(2900100001)(8676002)(345774005)(6436002)(81166006)(25786009)(82746002)(36756003)(33656002)(6246003)(6486002)(66066001)(305945005)(7736002)(106356001)(2616005)(476003)(53936002)(68736007)(486006)(446003)(11346002)(14444005)(6512007)(6306002)(3846002)(256004)(6116002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6SPR01MB0042; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Mt96aPA7Bd9w6iDuXxcsIzthPY0DL9Vpo+LeZ5rphnSEtp291d8JMz9qDrOq7snv3fA/gZ8ay+bzfixHLP1CQ94RBPqysIVRDsVuGSenzMbfmSErP4JI8wlV3bp/nGZgTthgkTlw1Sxpt4xJfgDXToU4gdZm6lA6Ljh1hr9AcXCzH5OJNk+bNoRSHYnTVU0Mk1dy9z0voSIQ83ETvTjUthJbVyyqsj//NqACd+VGs8ODccsoR9r3xhRDDLI36IrOnlt8CB8a09C34k5iZBWEAKa0isJdIEvT5wh23039MXQ17tzvxF7UXBDlHvywQR5VFsjS19fovhKuhvkbnmkN/vHkAEuazYFIFwb2Obey2r0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F829689C0DD7B4ABE2660A2C3ACB326@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4086dc52-96f8-41a3-c2c5-08d632d74de7
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2018 19:49:22.4714 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6SPR01MB0042
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-15_10:, , 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-1807170000 definitions=main-1810150170
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8n0l2t_amL00AvqZAhjG626BfCw>
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 19:49:36 -0000

Hi Robert,

Picking up on your YANG 1.2 comment.  Please add a YANG-next issue, if this
is not being tracked already. https://github.com/netmod-wg/yang-next/issues.

Thanks,
Kent



-----Original Message-----
From: netmod <netmod-bounces@ietf.org> on behalf of Robert Varga <nite@hq.sk>
Date: Monday, October 15, 2018 at 3:36 PM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] schematree-statement extension?

On 15/10/2018 21:09, Martin Bjorklund wrote:
> Hi,
> 
> Robert Varga <nite@hq.sk> wrote:
>> It is wide-spread practice to use tailf:action and target statements
>> within it with augment/deviate statements -- which I think is a failure
>> to follow RFC7950 section 6.3.1:
>>
>>    Care must be taken when defining extensions so that modules that use
>>    the extensions are meaningful also for applications that do not
>>    support the extensions.
> 
> Yes, but note that 7950 means a 1.1 module, and tailf:action should be
> replaced with 'action' in a 1.1 module.

I think the argument applies (and proposed extension would be
applicable) to RFC6020 as well.

I am not complaining about tailf:action specifically, I will just map it
YANG 1.1 action even in YANG 1.0 mode and I'm done :)

> One reason we added the quoted paragraph to 7950 was because of the
> problem you describe with tailf:action.

I suspected as much, thank you for that :)

>> I think the proper way of fixing this would be to define a YANG
>> extension, which, when used within another extension, would indicate
>> that the extension being defined is part of the schema tree, for example:
>>
>>    extension schematree-statement;
>>
>>    extension foo {
>>        argument bar;
>>
>>        sts:schematree-statement;
>>    }
> 
> Unfortunately, this doesn't solve the problem, since a parser that
> doesn't understand sts:schematree-statement still wouldn't know that
> foo defined a schema node, and thus it will still complain if it sees
> an augment of a node introduced with "ex:foo".
> 
> In order for this to work, "schematree-statement" would have to be a
> builtin statement.
> 
> (... and if we had this statement, we could have used it in yang-ext
> as well, and avoid augement-yang-data)

Understood and agreed, parsers not supporting schematree-statement would
be left unfixed, but also no worse off.

My skin in the game is to future-proof my parser (based on supporting
widely-available specifications) until this is fixed for everyone with
YANG 1.2. Adding support for a language extension is much simpler than
to bump YANG language support by 0.1, at least in my experience.

This could even help augment-yang-data in that the semantics of what it
does would be kept with the extension (yang-data) as opposed to a
different, related (as understandable by humans), language extension. An
an implementor,

Such extension would also address a piece of RFC7950 section 7.19's:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section 7.20.3.2), but the mechanism for how this is defined is
   outside the scope of this specification.

by defining how an extension can declare that it _does_allow_ refinement
and deviations without getting into the business of how that
refinement/deviations are done. This could even be separate extensions:

   extension augmentable-statement;
   extension deviable-statement;

Such a language extension can be picked up by parsers across all YANG
versions, making adoption much easier and faster.

>> Using that knowledge, the parser can correctly interpret
>> augment/deviation arguments as validly pointing to a particular use of
>> foo (or its descendants) and correctly ignore their effects.
>>
>> Is this something the WG feels is a real problem and would be interested
>> in solving?
> 
> The current advice is of course to NEVER add nodes to the schema tree
> with an extension.  I think it is probably best to stick to this
> advice...

That advice I missed. Is there a link I can quote? :)

Thanks,
Robert