Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
Balázs Lengyel <balazs.lengyel@ericsson.com> Thu, 13 February 2020 13:40 UTC
Return-Path: <balazs.lengyel@ericsson.com>
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 9BC771200FA for <netmod@ietfa.amsl.com>; Thu, 13 Feb 2020 05:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 aBdItlHmugXx for <netmod@ietfa.amsl.com>; Thu, 13 Feb 2020 05:40:18 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60069.outbound.protection.outlook.com [40.107.6.69]) (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 50B8E1200F8 for <netmod@ietf.org>; Thu, 13 Feb 2020 05:40:18 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CKunXqaw8UAhCv5H0QJLnsSjujEo2sglL6CE0XM/DaHpguKQpl3zY3CboWzWK3CQpgzzM2XyquLvny1bXFUy0deEJglcqZ3TdhUGWvAlzUCKDoijDPvCGA1CGtxwgXxnaIWTEk8a2eeMdI0wmkop5iQMLeVlEdroogaqT+sENSrbxjasg9cf+ORQeKhAeNzmzciC4l83JP5BuaixV3NCjTEGsTJ3Rms7Eivtu7gLXjRt9HGX2ySbtmrsUDlZnyWtJr1pJnhdPvw/r2+G0kHwt5lKMSk0+87IVNQCw7m+3G8ayRtKYRz6M8+cLwOIO7LLcx8t7Y3JlzXLEZhBqRd2OQ==
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=Jp4B43wLQSTAHb8MxGoCro7tjsaqFsUzm149j+L/ThM=; b=PjEnvTbPxsOgEym6CS3f2aRzHA3Cwmn/nN0sIHABhIluP8tT4R6Kd+jdO2srD6iSLJgBpB6yDAuvPMOkIxsXAjJI9b7eJsRoZS8rWmRUuNcd73nshe0D0MmfMsE/IECiReUa4VnxjGvkV26nPIDmWT/DeUGsIIYz7sNUf88+Y1kjFyU7b/+p4CFmYgjRyhmH3S3xAMjmZB9SQRCDQd0ZdvC13mutcWJoaVbFrHE+m6ekFA6x5B3L1NhFWeSGN03gNWypyNwvm23Yd777FiwCK+SsYgJFgg0ES9T0Fb1oNWiDAkgKHk1Eb/NGL/dUADQd8+n3R/TukHwQHXkClddPaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jp4B43wLQSTAHb8MxGoCro7tjsaqFsUzm149j+L/ThM=; b=ZZTH2aOiim/bZNI7XvIe4FLDvvIum9HZZ6+Ll7bq4VKSGiMLOjAEIKN8Qi0CBKjYdfcwBpx8clNIaSkdaVeQMFq28ZPSacSp3184i6FKgMXaW0fSQYWexDpd5RUAXiZGtF5MhqGP4EQ96kCh3Bge9V/qe33PE6vk7lhsV7D2EOE=
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com (52.134.97.155) by DB7PR07MB4140.eurprd07.prod.outlook.com (52.134.96.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Thu, 13 Feb 2020 13:40:14 +0000
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::b19e:4830:538a:d973]) by DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::b19e:4830:538a:d973%5]) with mapi id 15.20.2729.021; Thu, 13 Feb 2020 13:40:14 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
CC: Kent Watsen <kent+ietf@watsen.net>, NETMOD Working Group <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
Thread-Index: AQHVxVfSEJ6TUivwA0OmLdrVeJgwbqfztdUAgCEFvqCAAsFUgIAAY06g
Date: Thu, 13 Feb 2020 13:40:13 +0000
Message-ID: <DB7PR07MB4011A7798CBC8E40F49F8B88F01A0@DB7PR07MB4011.eurprd07.prod.outlook.com>
References: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com> <20200120144528.wt2z4y66xcnp7fxj@anna.jacobs.jacobs-university.de> <DB7PR07MB4011635119B75D384D11D01DF0180@DB7PR07MB4011.eurprd07.prod.outlook.com> <20200212090703.eikj365ctbsighey@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200212090703.eikj365ctbsighey@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5ed39284-407b-4251-dce7-08d7b08a411f
x-ms-traffictypediagnostic: DB7PR07MB4140:
x-microsoft-antispam-prvs: <DB7PR07MB414054ABCAB5084A0D3935F8F01A0@DB7PR07MB4140.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 031257FE13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(396003)(136003)(39860400002)(199004)(189003)(66476007)(26005)(76116006)(8936002)(66616009)(66946007)(6506007)(64756008)(86362001)(66556008)(7696005)(66446008)(53546011)(186003)(2906002)(71200400001)(478600001)(8676002)(316002)(52536014)(30864003)(54906003)(966005)(6916009)(55016002)(66574012)(4326008)(9686003)(5660300002)(81166006)(33656002)(81156014)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4140; H:DB7PR07MB4011.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OAt+488+k97MnNY4pHWqkm5jicCgg1Xqf+WAi9hv5RbnqisFMZGw6T0gDy6krCZfKiTVTJHmc3vIGTy5efUwLEiWdyvBqHdJv2NIOJrH+TT9q8wUOZRKTE7Gjg2zV5Qah4kILp5Ktfw+ZsP98yyF0Q3fIFrJ52CFTICYYCf3f/OAl7VuBCEBDOtlCL/0Er3AJSgFPbe/8S67pZlHtxCesYkXd8nRH6I1bbp5lLdeY6tie3tWdBF/X1Z/ZiIiPhKuFFWxm5egsm2vzoR/VpsLnGGJEDU0a6lp8QeoV4/+W9+mvSHWa7SAKwBVvMdiKmBKApeBgQozu7kMGG9C8thzm0jQpmNgGs+iSElGKr/n70fH2PzFt/sXJuoGw3jAHqp0aTvIE28M4C8j2FURSIP/bCyrlEE6wzHw9JffgYFVPg/eKEbVZx9nT4Rnq1Nawm4cdqeBSwblT6FeFtZZBXLQYZelxX/f+GEeMk3kqxt8AUgbre+H9KxEXbIbGdAnwjPlKe8iGTsxz5Mg6sn1814Jxw==
x-ms-exchange-antispam-messagedata: P7mW4qEc1wfdiGo2wug/8lhZ4tg5IGIFHs4Qd64BtBWQXIVcM500G9+2Taa/8SdVpKJURrb0nUOrvM5QBzeeJy8ltJ7B/B1yvmKklYrdl0tB1YyfYYyydiVQvyVuW8iS/s9DLu8+T8490NIFB58vHw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_06D4_01D5E27B.7F51F4F0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ed39284-407b-4251-dce7-08d7b08a411f
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 13:40:13.9547 (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-CrossTenant-userprincipalname: 172WZxr+p/QvU1lt8IdODK7HVGYzfrPxpnRvA8uWmWZuGwrZj/dHdYsPmkgUE2A53DLa01KwByOwxAOne+srl2UPZvPgvJS72uek0HGIwiQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4140
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/i6kCsGAPZEx_9tPkbCJ7wqnDuUM>
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: Thu, 13 Feb 2020 13:40:23 -0000
See below as BALAZS2. -----Original Message----- From: Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Sent: 2020. február 12., szerda 10:07 To: Balázs Lengyel <balazs.lengyel@ericsson.com> Cc: Kent Watsen <kent+ietf@watsen.net>; NETMOD Working Group <netmod@ietf.org> Subject: [Not Scanned] - Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 > - 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. > BALAZS: a schema is a full set of YANG modules needed to define the > structure and properties of the instance data (+features, deviations). > A "content defining YANG module" is an individual YANG module is part > of the content-schema. So the difference is a set versus one item. > I updated the description to emphasize this difference. OK. But then what is a non-content defining YANG module? Or are these schema-defining YANG modules? I still do not get why we need 'content defining YANG modules' - we did not need that in other specifications so far that define schemas. So why do we need new terms here? BALAZS2: In some paragraphs I reference individual YANG modules that are part of the content-schema. What would be a better term for the individual modules? > - 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". > BALAZS: This is a reference both to NETCONF and RESTCONF. It was > explicitly asked for by other reviewers. Well, then the correct wording would be "similar to the response of a NETCONF <get> operation or the RESTCONF response to a GET method invocation on the (unified) datastore resource". Sounds complex and I still prefer the text to be agnostic to specific operations - in particular since <get> and the unified datastore have their limitations. The format is simply reusing the already defined data model encoding formats, i.e., the format has nothing to do with the operations used to retrieve the data. So I suggest: P2 Instance data shall reuse existing encoding rules for YANG defined data. There is no need to refer to specific protocol operations. BALAZS: I will use both of your texts. That is the most common question I get: Will this use the same format as a get-reply? People like to think in terms of a specific easy-to-grasp function instead of a non-descript set of "existing" rules. Existing means you need to understand X number of RFCs, while just looking up a get-reply is easy. It is not precise, but IMHO that's how people think. > - 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. > BALAZS: https://tools.ietf.org/html/rfc8040#section-4.8.9: > " If the "with-defaults" parameter is set to "report-all-tagged", then > the server MUST adhere to the default-reporting behavior defined in > Section 3.4 of [RFC6243]. Metadata is reported by the server as > specified in Section 5.3. The XML encoding for the "default" > attribute sent by the server for default nodes is defined in > Section 6 of [RFC6243]. The JSON encoding for the "default" > attribute MUST use the same values, as defined in [RFC6243], but > encoded according to the rules in [RFC7952]. The module name > "ietf-netconf-with-defaults" MUST be used for the "default" > attribute. " > Here the usage of the default ATTRIBUTE is defined. I am still confused about terminology here, an attribute is an XML way of representing meta data, JSON does this differently. Perhaps some good examples would clear the confusion. BALAZS2: The Restconf RFC uses the exact term " the default attribute". If it is acceptable there IMHO I should be able to reuse it here. It is not my terminology it's from RFC 8040. > - 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? > BALAZS: As this might be meta-data about the individual instance data > nodes (e.g. metadata following the principles from rfc7952) it > belongs here. OK, perhaps my confusion is that it was not clear to me what kind of metadata is meant here... BALAZS2: OK., will try to update, clarify the text. > - 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? > BALAZS: Generally we want to allow users/creators to decorate the > data with additional information, that is not standardized. Like YANG > extensions these may be useful, but at least should not cause problems. > XML attributes are often used as meta-data and I was asked to list > them specifically. > I do not understand why there are specific rules for XML encodings but not equivalent JSON rules. It looks like either the XML rules are not needed or equivalent JSON rules are missing if the XML rules are needed or there should be an explanation why the different encodings lead to different results (which is operationally rather surprising). BALAZS2:XML has 2 distinct ways to encode information XML attributes and elements. JSON only has one uniform way. XML attributes are often used to carry metadata which is a useful facility and they are not used to encode "real" YANG defined data. So we want to allow the use of XML attributes and not go for a least common denominator of the 2 encodings. IMHO it is a useful facility, IMHO it belongs here, but if you insist I can remove it. If we want rules that apply to all encodings, they should be expressed in an encoding neutral way. The current text and your response leaves me puzzled what the specification really wants to say here. And do we have to say something at all? > 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. So what is the meaning of "will be very similar"? BALAZS: Similar means same structure, same data types, but there will also be differences, like the additional metadata and allowing partial data, ignoring of some constraints that are listed in the chapter. As this is not a precise term I will use it only in the introduction chapter (principles). > - 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. > BALAZS: OK, EXTERNAL should not be all caps. > Here external means that the content-schema is defined externally to > the instance data set, not even a URI is included. So if I have no case in the content-schema-spec choice, then it is external or how does this work? Perhaps define external differently? Another attempt: External method: Do not include the content-schema, the user needs to obtain the information through external documents. I removed "already known" since a tool and human producing an instance file will in general have no clue what a user of that instance file already knows. BALAZS: OK > - 3.1.1 How are the details specified in the anydata? Perhaps a > forward reference might help. What are 'version labels'? > BALAZS: Added reference to example. > Version/Revision labels are defined in > draft-verdt-netmod-yang-module-versioning; > added as a reference. I added them here (only as an example) as they > are highly relevant to specifying module versions even if they are not > agreed in Netmod yet. The name was changed from version-label to > revision-label lately. Lets use a single term then, lets say "revision labels" if that is the most recent once. Right now, both terms seem to be used. BALAZS: OK > - 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? > BALAZS: Different people in the WG wanted different solutions. > - Some (as I remember you too) asked for a full flexible solution > which can use multiple modules potentially not even the > ietf-yang-library to define the schema (Inline solution) > - some asked for a simple solution listing the content schema modules > - some wanted just to use a reference (If any this is the one, I would > remove) > - some stated that they do not want to define the content-schema at > all because it is already known So we ended up with 4 methods But reaching consensus by doing all four is not necessarily cheap. So what are compliant tools required to implement. All 4 method? Whatever the implementer prefers? Or is there a mandatory to support method (other than external ;-)? The WG needs to understand the costs of having N ways to do the same thing. BALAZS: 2 methods are mandatory: Simplified-Inline & URI. Inline is controlled by a feature, so it is optional. External is inherently optional, as whatever is outside this specification is undefined thus it may or may not be supported. > - 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? > BALAZS: OK< Changed to current. I want to keep the second sentence as > it describes the duality between the original documented values and > the current values that can be read in run-time. > Consistency is out of scope. No indicators are provided. It is very > much use-case and implementation specific. In this case, I think it helps to spell out that users cannot assume that instance data always represents consistent snapshots. BALAZS2: I would like to avoid the topic. We never stated anything about the quality of data in the instance data set. E.g. if this is a snapshot of state data and it takes time to create a snapshot, data might change even during creating the snapshot. This is not described here or in Netconf or in Restconf. Why should we describe this in more details than the protocols. > - 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. > BALAZS: We do not want to specify the how the changes should be > described, But we do want to state that this information should be made available. > Just a few ideas how this could be done. Provide > - some plain text in the description of the instance data set > - some additional metadata e.g. etags, timestamp for the individual > data nodes. > - a change indicator in the content defining yang module itself I do not know how I implement such a SHOULD. I admit that I do not understand RFC 2119 language but a lowercase should would make me feel better. The concern here is that it is entirely implementation specific how I make this information available and hence whether I have followed the SHOULD or not is rather unclear. BALAZS: OK, lowercase should > * 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. > BALAZS: I will change it to lower case may. > I was asked to and I want to state that we want to use instance data > both for offline delivery of design time information and for run-time > delivery of other data. But should this not be stated in the use cases and principles list in section 2? I think section 5 is a mixture of a use-case concern and a requirement (oops principle): PX: Instance data sets may be read from or produced by a live server [is YANG server the proper term?] or they can be the result of a specification or design effort that does not involve a live server. I think the essence of section 5 should be integrated into section 2. What it says seems misplaced in the middle of the document. (I personally prefer to talk about objectives rather than principles but that may be just me.) BALAZS: OK, I will move it into chapter 2 Introduction. This is really not something mandatory on the implementation. > (The first 3 users of this format all want to use this for early > delivery of > > server capabilities. It is for now the dominant use case for which the > 2119 SHOULD is important.). I do not think this specification should define SHOULDs for specific use cases. See my proposal for a possible PX to capture what I think is the core idea. BALAZS2: OK, SHOULD change to lower case may. > * Backwards Compatibility > > - I do not think 'managed entity' is a YANG term. > BALAZS: What term do you propose for something that is managed like an > interface or user etc. ? I was told managed entity is a generic term > that is commonly understood . Would "managed item" or "managed thing" > be better? > > - 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. > BALAZS: You don't know how many trouble reports we got in multiple > use-cases for violating these recommendations. While they may not be > important for all use-cases, the are important for many. > Actually we met the problem or had to avoid it in all but one of the > listed use-cases. This text seems specific to certain use cases or best practices and as such I suggest to integrate it into the appendix C. I do not think this advice needs to be part of the technical instance data format specification. One could even argue that some of this also concerns config changes to live servers. My issue is that I find this discussion misplaced - I like to to see the format definition separated from any guidelines how to use it. BALAZS2: I still see this as important as proved by real life situations and also as a n explicit request from the Yang versioning requirements draft. The text is specific to some use cases: In practice relevant to 90% of the use cases. > * 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. > Balazs: > - case inline { is decorated with "if-feature inline-content-schema" OK > - feature support is generally indicated as part of the > ietf-yang-library OK > - simplified-inline is mandatory to support. It is relatively simple, > so IMHO not a problem How do I know whether the feature inline-content-schema is supported in this case? BALAZS2: IMHO your question is out of scope for this draft. Just like for any feature you can read it on-line from ietf-yang-library. If the information is needed offline it can be documented in any design time document. My proposal is to use an instance data file based on ietf-yang-library using the simplified-inline schema declaration method. How much simplification is there really compared to the inline method if I only list modules in the yang library schema without derivations etc? See my earlier point about which schema formats are mandatory to implement and whether the simplification is worth the extra code and possible interoperability issues. BALAZS2: Compare: INLINE method: <content-schema> <inline-module> ietf-yang-library@2016-06-21 </inline-module> <inline-schema> <module-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <module> <name>ietf-yang-library</name> <revision>2016-06-21</revision> </module> <module> <name>ietf-netconf-monitoring</name> <revision>2010-10-04</revision> </module> </module-state> </inline-schema> <content-schema> SIMPLIFIED INLINE method: <content-schema> <module> ietf-yang-library@2020-01-14</module> <module> ietf-netconf-monitoring@2020-01-14</module> </content-schema> > - what do you mean with schema-formats? The yang schema is not > actually included anywhere. > If the "inline" case is used, instance data corresponding to the > inline-modules is included, not the schema. > anydata inline-schema { > description > "Instance data corresponding to the YANG modules > specified in the inline-module nodes defining the set > of content defining YANG modules for this > instance-data-set." My understanding is that the inline-module indicates a variant of the yang library used and the inline-schema then follows that indicated yang library variant and provides the schema. Am I entirely wrong here? BALAZS2: You are correct. Some extras: Inline-module could indicate some other module instead of the yang-library. I was asked to do this earlier by Rob Wilton. There can be multiple inline-modules so we can use yang-lib with extensions like a module adding revision-labels > - 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. > BALAZS: We do not know if the instance data set was originally > filtered by NACM or not. We don't know if the users on > Netconf/Restconf/cli are the same as the users defined in the file > system., so I fear defining what consistent means would be impossible. > It is stated that " The same kind of handling should be applied, that would > be needed for the result of a <get> operation returning the same > data." IMHO we can't really say more. Yes, I guess what I was trying to say is that a live server may apply certain access control rules while instance files may not apply the same rules. In other words, an instance file obtained from a live server by joe and passed on to lucy may reveal information that lucy will not be allowed to see on the live server. By passing around instance files, information may accidentally leak. Yes, we can't solve this, put we can point this out. BALAZS2: I agree fully, but file security is a really big topic, so highlighting some areas will not help people. I added: Care should be taken, when copying the original files or providing file access for additional users, not to reveal information unintentionally. /js -- 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