Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Mon, 20 January 2020 14:45 UTC
Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 072451200B7 for <netmod@ietfa.amsl.com>; Mon, 20 Jan 2020 06:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com
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 bFJkZ3_OHOIo for <netmod@ietfa.amsl.com>; Mon, 20 Jan 2020 06:45:34 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40080.outbound.protection.outlook.com [40.107.4.80]) (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 1F572120041 for <netmod@ietf.org>; Mon, 20 Jan 2020 06:45:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n46ZGOeZu/7pL6OIDWSQpVaq65f6RWT4SMwrrru91vJOYhKwLM2VR9jNniKy3wU1KyhI1s1QlO5ZZ78IuWp6/l530p79xjn0D6t7pj4ONKwj5OrZo68s5NUz8zqN1Ym8edEyNOQ+lbEHhfj5sC0M8nwx0B8TJJObbbH+OaKTVwc1oyCFL7OjvNWRIiq/Sxkk+oZcrscQ/s+1S47Z2JS6u4SdXsgak/+rs/sMWSnvqLyo0cFHhj/OzZ5q//SoeDalX+vRZQc2z4NRlK3ai4hVEhzrQisgzLUTgzDdL48dXPnhiak6mrTaDmvdXKJF0ii637IK3YncCE3Uz2o9bjYxqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6xVE4AZMd4ViBtDKgMDSHX/Jk+4GN9rV1qkgxj/RFU=; b=MdhrmIadau3mnV7rJHmkqHwgwFuHk6rNJeQEOq9XUkuxMDLBZY5Rq8s06h+/ZmnXZNWU974bVIQNe8dJNe1HLkkYtlmY6VDhrulgNe68yuD6z2XXIokCUT0WvTUdwqAjpyv1ZLVgsmmkK23s+QkPe+BwBnK7P+7tKP8SyG5UihVCHMlUprQDEeAy7XniHSxL4HL6+4yldasyAmun8JmTiVeHKE0NpNIaG6mLkVVWE95lHeq73bkeninCNQT3UYlsG6x6NvkqClh6c39Wqe8Ma3uB/kE8f8XfdCe1LuT0sGKTMV/RhDGYO8nN4FHNU58EexSGVUlazql2R3UPkUrTSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6xVE4AZMd4ViBtDKgMDSHX/Jk+4GN9rV1qkgxj/RFU=; b=gxVP473Rc9odBpZlpausCR7GotFWX6XhxD+nBScyKsAWfSpECEd3kSXjnPUPMvQmbkrRmj1cnay1vcODq4VWJJGpqvBSHsIVnxFs9FJKKDaCMwF2A3Th884Ob+peAJ7selrAI2TUaaDzVCfanpbF4Ruu4A7VoJuklR2B2v2MT5c=
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0117.EURP190.PROD.OUTLOOK.COM (10.172.228.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Mon, 20 Jan 2020 14:45:30 +0000
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2644.024; Mon, 20 Jan 2020 14:45:30 +0000
Received: from localhost (2001:638:709:5::7) by ZR0P278CA0002.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19 via Frontend Transport; Mon, 20 Jan 2020 14:45:29 +0000
From: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
CC: NETMOD Working Group <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
Thread-Index: AQHVxVfQ4dtefa62LU22UA5i1BqLNafztdMA
Date: Mon, 20 Jan 2020 14:45:30 +0000
Message-ID: <20200120144528.wt2z4y66xcnp7fxj@anna.jacobs.jacobs-university.de>
References: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com>
In-Reply-To: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com>
Reply-To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: ZR0P278CA0002.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::12) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:638:709:5::7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e314c24-dbb5-4c9c-dd09-08d79db76551
x-ms-traffictypediagnostic: DB6P190MB0117:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6P190MB0117E27FC5D0122A4C54DC37DE320@DB6P190MB0117.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0288CD37D9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(376002)(136003)(39850400004)(199004)(189003)(2906002)(478600001)(4326008)(6666004)(8676002)(186003)(16526019)(81166006)(81156014)(1076003)(3450700001)(52116002)(71200400001)(786003)(5660300002)(316002)(8936002)(66476007)(66556008)(64756008)(6486002)(66446008)(6496006)(66946007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0117; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XPVefVJLpoXyhN8CZu6TqHsMl/TkbRAbB03H1zkqcFtqz5BkgaPE8HMEJqBXWEb2aGAycQ4yICLgBDFngDnql+hFPEKz0wHNUCtoxqqUNJQv4IYA8KGSssOroO63427jQhwxln+mjQJnf8H/iqN3YEsuMJDIsheoEw7dMLXFihGISwqj6g0bCSl3LESKFoWIh00vx+x/JDTuXhphsQCIJT9pKkkjLOG4Q0+x9e7rakeegMX451jjqWVsgR6ilZ5LiIl+px1JDuonMiES9yoH5OX9eF+3us01Q0CHUl3HT4EXRdkszeCsZPiF1nQJlEvj6B6HNdp0HDWURyuyjcGHotekKqKDSFNNPlqpOe+Pxhj75/LWT2nrMLGSzIVpFhwaIrh4Qev9tX+zygjGSGS74m5vEZ2AFRXEamDG+uiVwH8143WVPLdT+QnGBHbBU0/JH5Qwo3l3kjK88ZzgofGn2HZTc/U4usNPFoRFGKPizK0yfqhEptFScdMFQR0DVv+0RZ4PbMXElWCs/XIuoEqEIw==
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1F6A024F87B2B343AE6A4F9EEB312583@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e314c24-dbb5-4c9c-dd09-08d79db76551
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2020 14:45:30.3762 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 42WzG1NlADBTWGf0JauT9VDifooTxiJfCH9mh4f9xxwN1Bybs+jjJaXxvHcXEkoWGU5AjA6CQZU3bCGXtPkoMWwsK2uQ3Tli4y446xBXtPs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0117
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dX_XGeRfJ94SdvAgRGdMvQAv65o>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
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, 20 Jan 2020 14:45:41 -0000
On Tue, Jan 07, 2020 at 12:41:23PM +0000, Kent Watsen wrote: > > This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmod-yang-instance-file-format-06. The WGLC ends on Jan 21. Please send your comments to the working group mailing list. > > Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time. > I have reviewed draft-ietf-netmod-yang-instance-file-format-06. I believe this is an important document but not quite ready yet. Most of the points I am raising below should, however, be easy to resolve, many concern terminology and writing consolidation and do not affect the technical solution. /js * Abstract I think we should avoid referring to some <get> operation. Here is a proposal of a rewrite: OLD running server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a <get> operation/request) and annotates it with metadata. NEW running server available. This document specifies a standard file format for YANG instance data, which follows the syntax and semantic of existing YANG models, and annotates it with metadata. * Terminology - Add missing dots (full stops) at the end of sentences - I fail to see the difference between 'content-schema' and 'content defining YANG module(s)'. The 'content-schema' is already a set of YANG modules. I suggest to remove 'Content defining YANG module(s) as it is not a necessary term. Rewrite all places where the phrase 'content defining YANG modules' is used. - Is "YANG Instance Data" a newly defined term? It's introduction does not follow the colon style. I also wonder why we need this term. Why is YANG in there? I would prefer to have this defined in RFC 7950 terms. Is 'instance data' a collection of instantiated 'data nodes'? Perhaps then we should do the following and move this up to the first definition, so we define instance data first, then instance data set, and finally instance data file. OLD YANG Instance Data, or just instance data for short, is data that could be stored in a datastore and whose syntax and semantics is defined by YANG models. NEW Instance Data: A collection of instantiated data nodes. * Introduction - It seems UC5 subsumes UC4. - One could add UCx: Storing instance data used as test cases but then this list of use cases does not need to be exhaustive (means I do not care much). - Is it necessary to describe P2 in terms of (presumably) NETCONF operations? I would prefer to have the document written in a protocol agnostic style. Perhaps simply drop "similar to the response of a <get> operation/request". - P4: What is 'many'? Or did you want to use 'multiple'? * Instance Data File Format - Replace "real data" with instance data OLD "real data" that we want to document/provide. NEW instance data that we want to document/provide. - I do not understand that text about the default attribute. Section 4.8.9 defines a query parameter, not an attribute. And I do not know how that fits into content data. - Similarly, I do not understand why implementation specific metadata may be included in the content-data. This seems to be the wrong place, no? Should metadata not go into the header? - Why MUST XML attributes be ignored, why is there no text about unknown JSON data, 'attributes' (or annotations)? What should implementations generally do about unknown elements, attributes, objects, arrays, ...)? Why are we specific about only one specific case? - References may be helpful in this sentence since <get-data> is not part of the original NETCONF specification: The content-data part will be very similar to the result returned for a NETCONF <get-data> or for a RESTCONF get operation. It is unclear what "will be very similar" really means but perhaps this is clarified later. If not, this sentence says nothing in terms of a technical specification. - Does the following sentence imply that any additional data in an instance file renders the instance file useless? The content-data part MUST conform to the content-schema. - You first write that instance data MUST conform to the schema and two paragraphs later you state that instance data MAY be partial, i.e., it MAY NOT conform to the content-schema. Perhaps I have an idea what you wanted to say but the text that is written here is a contradiction. - The introduction contains several MAYs and MUSTS that are not understandable yet and they do not seem to belong into an 'Introduction' in the first place. - Why is EXTERNAL in all caps but Inline in capitalized form? In the YANG definitions, EXTERNAL seems to be uri. I think we reduce ambiguity by being consistent with how we name things. - What is a 'real-life YANG module'? - 3.1.1 How are the details specified in the anydata? Perhaps a forward reference might help. What are 'version labels'? - 3.1.2 What is a 'list of content'? Which revision is used? What about these 'version labels' here? - 3.2 I do not understand the example. Has this been validated? As far as I can tell, the ietf-yang-library defines modules-state and not module-state. This inconsistency shows up multiple times. - I like to understand why we need several methods to specify the schema. Having N solution is always bad for interoperability and also for maintainability. Perhaps the WG failed to reach consensus on a single solution. Or there are strong technical reasons - but then they should be clearly stated. What are implementations expected to support, all methods? Or whatever the implementer prefers? How do we achieve interoperability across tools? * Data Life Cycle - I am not sure the first paragraph is needed. - In the second paragraph, I like to see some discussion of snapshot consistency. How much consistency can be expected? Are there indicators for the level of consistency? I would remove the sentence about "valid values can be retrieved at run-time" as this is obvious but then I am not sure why 'valid' values? Perhaps the authors meant 'current' values? - How do I implement the "SHOULD be described"? The default is that data can change, only in rare cases data is static. But how does a tool creating instance data know 'when and how' data changes in the future? I suggest to remove the SHOULD. The text saying that instance data is a snapshot is in my view sufficient. - This section talks about YANG instance data but it likely should talk about YANG instance data sets. * Delivery of Instance Data - Why do we need this SHOULD? I do not think we should use RFC 2119 keywords to define how organizations may use the instance data format. My proposal is to delete this entire section. * Backwards Compatibility - I do not think 'managed entity' is a YANG term. - I think this text is use case specific and the items are kind of conflicting with each other (2nd says changing the semantics of a list should lead to a change of the key while the 1st suggests that changing keys may lead to misinterpretation of something being new). - My proposal is to simply drop this entire section. If use case specific text is needed, add it to the use cases in the appendix. * YANG Model - How is the inline-content-schema feature used? Which component does indicate that inline content-schema is supported? Do all implementations have to support simplified-inline? If inline-schema is used, how do I find out which schema formats are supported? The more formats there are, the more interoperability issues will arise. * Security Considerations - "is designed as a wrapper" - what does this tell me? I suggest to rewrite the first paragraph and to remove this phrase or to explain what it means. - Why is the header part not security sensitive? Almost all data is security sensitive in certain situations. - I would prefer if the text would not use the phrase "result of a <get> operation". As stated before, I like to see things written in protocol neutral forms. - Since instance data files may require protection, is there any recommendation how to do this, e.g., by wrapping everything into a cryptographic message syntax or so? It would be important in certain use cases to be able to verify that instance data is authentic (i.e., it is signed by the original source). In other cases, it may be crucial to protect the instance data itself against occasional readers. - It may be useful to explain that data in instance data sets may have been filtered by access control rules like NACM and that data in instance data sets itself won't be filtered anymore by access control rules like NACM. In other words, if I take snapshots and stored them as instance data files, these snapshots may leak information that is otherwise protected. Hence it is important that NACM rules and file access control rules are consistent. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- [netmod] WG Last Call: draft-ietf-netmod-yang-ins… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Schönwälder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Schönwälder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Schönwälder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Benoit Claise
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Martin Björklund