Re: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 13 January 2020 15:37 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod-ver-dt@ietfa.amsl.com
Delivered-To: netmod-ver-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AE120104 for <netmod-ver-dt@ietfa.amsl.com>; Mon, 13 Jan 2020 07:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LV+k829L; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=G4jGE57a
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 VKsu817rkEtU for <netmod-ver-dt@ietfa.amsl.com>; Mon, 13 Jan 2020 07:37:17 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9525F120033 for <netmod-ver-dt@ietf.org>; Mon, 13 Jan 2020 07:37:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=114030; q=dns/txt; s=iport; t=1578929837; x=1580139437; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jB+LiitYByTCrVtLrpYZ5YlLA1q4tQk1krewVIpYJg4=; b=LV+k829L284Q4a36J9NrbmGYq9RZLqbQ5H1cLvFpS57DnO+h8/W/ub/G ORukPo3IDyIZgxZKghuItvqGxJXI/n43signZiN+un+Beun6OXo+nzTBW zq8782mW7mSrGTlnf8nayRjkDh9JLdYAeHDwMZFVaHekF2cBc9G4Qvg9L c=;
X-Files: example_vendor_versioning_fixed_primary_configurable_secondary.xml, example_vendor_versioning_selectable_primary_no_secondary.xml, example_vendor_versioning_configurable_primary_and_secondary.xml, ietf-schema-selection-2.yang : 5550, 5069, 5871, 10741
IronPort-PHdr: 9a23:5NrmixxG8TlnFOPXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B9FgA6jhxe/4ENJK1cCh4BCxyDIC8kLAVsWCAECyoKhAKDRgOLBE6CEZgNgUKBEANUAgcBAQEJAwEBLQIBAYRAAheBYSQ4EwIDDQEBBAEBAQIBBQRthTcBC4VeAQEBAQMSEQQGEwEBMAgPAgEGAhEEAQEhAQYDAgICMBQJCAEBBBMIBhSDBYF8TgMuAQKOAJBkAoE4iGF1fzOCfgEBBYUdGIIFBwmBNoFTiQWBQRqBQT+BWIJMPoQWAQcLAQkYNIJaMoIsjVQBMgOCQ4VXJGUJiFyPLgqCN4NkgjiQLIJHiAGERItgjluadgIEAgQFAg4BAQWBaSIqPXFwFTuCbD0TGA2IAQwXg1CKU3SBKIlEgSIBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.69,429,1571702400"; d="xml'?yang'?scan'208,217";a="687146681"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jan 2020 15:37:16 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 00DFbF8W003395 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <netmod-ver-dt@ietf.org>; Mon, 13 Jan 2020 15:37:16 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 Jan 2020 09:37:15 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 Jan 2020 10:37:13 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 13 Jan 2020 10:37:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XgLXsifXTL1Hkb+mbgGUnsJ4gkqpfDe6V7BMfDbxAzysUUDidvomb5fyLHLjKnCpeqALeMl2jWN6f0kgmzAJ7fIXEEbdExZlQzS4BILBOX1Ym1A1d1dBj8l3gPoAZR/+/u+Sem2WprdevVexMrP+Si/VHw5840o7FHhoF9iaGASyd8VoMGJs6j9mBOfXBGtWP+36Twiv53HVC/b/ij7ra5RUuUbqDlN1GfCWnoXXdUEY92JamYb3MHFJNf3FeTP06MLMXhk03EROSlS7YBbX1MkjsUBFn9m9kmZUPuJ070V1CPV+Vk+MFcyiFWqOGIlabRJbrgIm4LyIn3hN5jXdkg==
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=XOR82qjZjgQFWlkNJxnl2HIiKOmaXnADMEsaptKh2rA=; b=lqsmsXlSvqPe7CPiDlvQESg/6oViaV0zJWufl9j3UBjOiffKfImS+/K6LJkWgnJaBQph58lpKSJU/G6zCwXhu4ioIfwfu74UYLvK97fLbIqmaLBzOAXo4T3Jq+96HfEHh4VvOA+T63ufpI3nF+W1X9PStuaQ8tXMRGUgv1dILRC/Xf2+U7uQDG5+oc1Dp9qAW1N8KoiR1Us0OPt2E82fOc13vNyQhCg2GSGBYZd2SuA9FH+JGPAnn3tuY5J7qwzevxc7X6FlIJaIUCpwSn5a01YNwzunOG48QPBz71o+IFizsTlVN/jxhr7QCkDbr2VLFVcb6rBCziFLtzlNLQl6gQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XOR82qjZjgQFWlkNJxnl2HIiKOmaXnADMEsaptKh2rA=; b=G4jGE57aiGpoGy8H3wI4nzoDDFxqSF9nLn1tRMoqHtwKUkgVCNx6+ZiUE0vbBtqYVoY2gDQMtUZMmQp+Q63519oEARH6dXwXuYYnyKKXjjqQCvuod+OfApbwTI4EMhSDi9N2fDFS2vSl0M2tHQ0mqQ01M38qBirtToODtE1yt6Q=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4013.namprd11.prod.outlook.com (20.179.151.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Mon, 13 Jan 2020 15:37:11 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 15:37:11 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Thread-Topic: Meeting minutes [was Today's Ver DT meeting]
Thread-Index: AdXHmld13jvhI/wQRxCV2HHooG51IgCiID5A
Date: Mon, 13 Jan 2020 15:37:11 +0000
Message-ID: <MN2PR11MB4366300C80EB69EDA594F274B5350@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <MN2PR11MB43668363A657E52D0E9C7AB2B5380@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43668363A657E52D0E9C7AB2B5380@MN2PR11MB4366.namprd11.prod.outlook.com>
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=rwilton@cisco.com;
x-originating-ip: [173.38.220.52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 29f41144-834c-408a-0828-08d7983e74ee
x-ms-traffictypediagnostic: MN2PR11MB4013:
x-microsoft-antispam-prvs: <MN2PR11MB40136F48D6AEB2A0E736DBB7B5350@MN2PR11MB4013.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 028166BF91
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(199004)(189003)(8936002)(71200400001)(5660300002)(52536014)(8676002)(81156014)(81166006)(316002)(2906002)(66576008)(6916009)(7696005)(76116006)(9326002)(9686003)(33656002)(66476007)(478600001)(86362001)(53546011)(6506007)(66556008)(66446008)(64756008)(186003)(66946007)(26005)(55016002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4013; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LdRVQVYZwex2pXt7BRYKizkvPq2ZZpRhY3JtZQKb8/8ggl0BX6PLOEU8pfZ2b/zNVuYo2rrDD0I6xHpymgvU65g57bHA8Mr3JR0WwYh0WQN1Y5TT+ByLc95VPCLQX958eQZOoJYpbvIYX3sWe05ueNXDXBVakKVPCOL3z1Kth284un8sqMu9BmhmVyYE5BZUTcFnOzlNM6AcR+vWP/Lw0WilpA/0T2py6o+bFZKMjY13AgqqYsA/0SxyUnWeFeQyGThxXmaWiwShKXhfaHgfg0QJLAxxQAglka6ZmTlfY1yqIUEsVc49O7wbgzoQlQdrwgaWj9M1SoPJJdYYH2CiUN3WckDMP707NmIVKKIUW8InIK9ygbCvxsTEGoGGRsXCJF2+yxk6veEmLFbB49IEmF3BTTE43HmxnD07BbsQ+vc9OME38o7oaszvzekI/rp7
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_007_MN2PR11MB4366300C80EB69EDA594F274B5350MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 29f41144-834c-408a-0828-08d7983e74ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 15:37:11.1266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dVkbmeMLYfEsF9p2kYQJ+LbB8RlxPMhjD/5C7wHL8e9mi43eZXhsqJbJg8myi60/3x0CWE7TOt7gesQxbbCyQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4013
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod-ver-dt/juaw-P1UO0Au6M-HARL9IH6wSXU>
Subject: Re: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]
X-BeenThere: netmod-ver-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NetMod WG YANG Model Versioning Design Team <netmod-ver-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod-ver-dt/>
List-Post: <mailto:netmod-ver-dt@ietf.org>
List-Help: <mailto:netmod-ver-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 15:37:21 -0000

Hi,

I’ve been playing around with the schema selection YANG model and examples a bit more.

3 examples attached (all for selecting from 3 different versions of the YANG schema):

  1.  3 choices of primary schema versions; no secondary schema.
  2.  3 choices of primary schema versions; secondary schema are configurable read-only views of latest versions
  3.  Primary schema fixed to latest version; older schema versions are allowed.

Comments and tree output inline below …

From: Netmod-ver-dt <netmod-ver-dt-bounces@ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: 10 January 2020 10:09
To: netmod-ver-dt@ietf.org
Subject: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

Points from the meeting what would be good for further discussion.  I think that a lot of these issues are probably still open and require further discussion:


1)     It is clear that we need to standardize supporting different versions of a schema, but do we also want to support different schema families (e.g. vendor vs IETF vs OC)?

a.       My personal view is that it would be good if the model is general enough that this can be described (and I think that it might be useful if there are some examples given in the appendix).

2)     For supporting non-native schema, there seem to be two approaches:

                                                                        i.     always translate into the native schema, reads from say OC convert back from the native schema

                                                                       ii.     store/persist configuration in the external schema (e.g. OC).  E.g. so a get-config on OC would only get back what had been written to the OC schema, not any other schema.

b.      Do we need to describe these two approaches?  For secondary schema does the model need to indicate which method is being performed, or is that purely an implementation detail?
[RW]
I think that the draft does want to describe the differences between a translated schema-sets vs filtered schema-sets that are just a subset of the primary schema-set.  At the moment, or in the examples that I have so far, I don’t think that these need to expressed in the YANG model.


3)     Can both of the approaches described in (2) above work for different versions of the schema?  Or must these always be handled by dynamic translation.
[RW]
My thinking is that schema with different module versions (relative to the primary schema) must always be translated.


4)     What is the schema that the configuration is persisted in?  Should this automatically be tied to the default schema, or should this a separate data node, that could potentially be configurable?

a.      Related to this, how does the system handle changing the default schema?  Can that be done as part of a config request?  Does the connection have to be closed and re-opened?  Or should it be an RPC outside of configuration?
[RW]
I still think that it makes sense to tie this to the primary schema.  I’ve introduced a RPC to change the primary schema rather than allowing this to be done via regular configuration.  I’m hoping that this solves the issue that we were discussing in the last meeting.


5)     We need a concise way of describing the relationship between schema and datastores.  The current approach in the model is somewhat verbose, if every datastore needs to be described separately (but is somewhat aligned to YANG library style).

a.      Should we allow schema to only support some datastores (e.g. only operational, or only conventional configuration)?
[RW]
Adding a common schema definition, so that it just becomes a list of supported datastores makes this more concise.  I think that we want the flexibility to allow different schema to express support for different datastores.


6)     Do we need secondary schema to have the ability to be defined or described as only being read-only?

a.      E.g. I can see a requirement to allow a client a configure a device using an older version of the schema.  I can also see a requirement of allowing a client to see what the instance data against a older version of a schema would look like in a more current version.  But I’m less convinced of the need to be able to convert a current configuration back into an older format.
[RW]
I think that this is useful, and have added this to the latest version.

Approximate changes to the schema:

  *   Primary schema is now only changeable via RPC, it can’t be chosen via config (secondary schema are still configured, or a server can support them automatically)
  *   Renamed stuff from “schema” to “schema-set” since that seems more correct
  *   Added a list of “common packages” that apply to all datatstores, in addition to per datastore packages (the datastore schema is defined as the union of the common and per-datastore packages).
  *   Added a flag to indicate that a datastore is read-only, for datastores that would normally be writable.  Actually, it might be cleaner to reverse the sense and change this to writable.
  *   Renamed some of the containers/flags/etc.

Tree output:

module: ietf-schema-selection-2
  +--rw schema-set-selection
     +--ro primary?      -> /schema-set-selection/schema-set/name
     +--rw secondary*    -> /schema-set-selection/schema-set/name {secondary-schema-set}?
     +--rw custom* [name] {custom-schema-set}?
     |  +--rw name               string
     |  +--rw description?       string
     |  +--rw included-schema*   -> /schema-set-selection/schema-set/name
     +--ro schema-set* [name]
        +--ro name                    string
        +--ro common-package* [name version]
        |  +--ro name        -> /yanglib:yang-library/yl-pkg:package/name
        |  +--ro version     -> /yanglib:yang-library/yl-pkg:package[yl-pkg:name = current()/../name]/version
        |  +--ro checksum?   -> /yanglib:yang-library/yl-pkg:package[yl-pkg:name = current()/../name][yl-pkg:version = current()/../version] /yl-pkg:checksum
        +--ro datastore* [name]
        |  +--ro name                  ds:datastore-ref
        |  +--ro read-only?            empty
        |  +--ro additional-package* [name version]
        |     +--ro name        -> /yanglib:yang-library/yl-pkg:package/name
        |     +--ro version     -> /yanglib:yang-library/yl-pkg:package[yl-pkg:name = current()/../name]/version
        |     +--ro checksum?   -> /yanglib:yang-library/yl-pkg:package[yl-pkg:name = current()/../name][yl-pkg:version = current()/../version] /yl-pkg:checksum
        +--ro primary-selectable?     empty {primary-schema-set}?
        +--ro secondary-selectable! {secondary-schema-set}?
        |  +--ro compatible-with
        |     +--ro primary*     -> /schema-set-selection/schema-set/name
        |     +--ro secondary*   -> /schema-set-selection/schema-set/name
        +--ro custom-selectable! {custom-schema-set}?
           +--ro combinable*   -> /schema-set-selection/schema-set/name

  rpcs:
    +---x change-primary {primary-schema-set}?
       +---w input
          +---w primary?                    -> /schema-set-selection/schema-set/name
          +---w (config)
             +--:(translate)
             |  +---w translate?            empty
             +--:(replacement-config)
                +---w replacement-config?   <anydata>

YANG file, and examples are attached.

Please let me know your thoughts/comments.

Thanks,
Rob



Perhaps we can discuss some of these over email, and try and reach consensus, or otherwise we will pick up discussion in next week’s meeting.

Was there anything else that I missed?

Thanks,
Rob


From: Netmod-ver-dt <netmod-ver-dt-bounces@ietf.org<mailto:netmod-ver-dt-bounces@ietf.org>> On Behalf Of Rob Wilton (rwilton)
Sent: 09 January 2020 14:11
To: netmod-ver-dt@ietf.org<mailto:netmod-ver-dt@ietf.org>
Subject: [Netmod-ver-dt] Today's Ver DT meeting

Happy New Year!

From the last meeting I did say that I would work on producing some concrete examples of version selection 😊

I’ve started working on this, but more work is required.  I have attached one example that we can discuss in the meeting, more may be forthcoming before the meeting.

As part of that work, I’ve been thinking more about the default/secondary schema.

As a recap, I think that this is roughly where I am at:


(1)   The default schema:

o   is the schema that is used if a client doesn’t specify a secondary schema during their connection (i.e. NETCONF capabilities negotiation, or RESTCONF path).

o   is also the schema used for the persistent configuration (and the <startup> datastore). [I think that this is probably right, but might need further thought/discussion]


(2)   Secondary schema:

o   are additional schema that clients can choose to use, and are specified during their session (i.e. NETCONF capabilities negotiation, or RESTCONF path).

o   can probably take several forms:

§  A filtered view on the default schema (e.g. if the default schema supported vendor native + IETF + OC schema) then a filtered schema view might just be the OC subset.  This should be simple to support since it broadly equivalent to a subtree filter on any get operations.

§  A translated view on the default schema (e.g. perhaps a different version of a schema),  All reads/writes to a translated schema are converted to/from the default schema.  The configuration is persisted in the “default schema”.

o   It might be useful if some of the secondary schema could be labelled as read-only views on the data.  E.g. it might be reasonable to see the configuration using a secondary schema non native version, but not allow it to be modified.

Attached example:

Example 1, a simple example of a server supporting two schema versions, and the client can choose between which version is used for the primary schema.

-        One question related to this example is what happens to the current configuration if a client changes the default schema to a different version.  Does that configuration also automatically get translated as well?  What happens if that translation fails?

-        Do we need a simpler way to reporting the per datastore schema?  E.g. should we have a special value to identify all datastores, or all conventional datastores?

Thanks,
Rob