Re: [Netmod-ver-dt] [meeting minutes] RE: YANG package updates

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Fri, 20 December 2019 14:14 UTC

Return-Path: <jason.sterne@nokia.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 0B9941200EF for <netmod-ver-dt@ietfa.amsl.com>; Fri, 20 Dec 2019 06:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 zjrRMhs2fcLz for <netmod-ver-dt@ietfa.amsl.com>; Fri, 20 Dec 2019 06:14:53 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130113.outbound.protection.outlook.com [40.107.13.113]) (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 3C2F2120025 for <netmod-ver-dt@ietf.org>; Fri, 20 Dec 2019 06:14:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MoyrrVFPVaeDSWjq+bcPvCwtwZB4xRWA628CV7tjzFnDKC8BLxrX785MAcGFvRE7cWjRvpAYWgzAVYsMFfzg/4rfs6Tg1dAXj80VDYHb8UhmQx8rWU0zploy0KYg+rH+lF79KHL8FTkhge9a/dKlzQXeFcQC5WSGnTK59RFbXSF5/I18Oheni0EZmkVwkbDHqHgjqojPhN+eY/MQTahszVfoebfG5hWEhs5gWY+9iim+fxsJMU9cRP/4kHpCpusA5aljiE/0B4xMR28eWgebNQF5306i8SQYSolDluEB6sR8bSRjX9nTv2QagzlAgjmxApr8aO+VvJMadoJJwrKLdA==
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=brQcMKintvvuQ05xgmvlGNgRLfKWft1xiVOP185rliE=; b=QIjRa2cKELBqJMgXq48oPQwoPEGo/wLB39BQ0r2uvXRmJG6jY/qwvqnI8zs0O6+ta54hVC6oby8YqGiOEsMdRDQDMZYfgZMp7PQrBVnc0Ft//6igSrjieFTPspPj5BgO2orjTMPmvbYIK5TB76nTdneDPizY1z/LRLO5Eflp+p55PZAvRU+/70VmoFdN10yeNMmTyGLpLm3huM2OJHJFWHJDDJEGr0b0cUcX4rCGl1CrrDqPh99xLnrEg8qqVqhBaL7Q0AQhimzuU3qTGdcKV49dOAZJPm5LCkhq+7PYhgPLYU5cUNwIgtSaWszYRqXbV8Wyp57TmxhBtSG4ikUG1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=brQcMKintvvuQ05xgmvlGNgRLfKWft1xiVOP185rliE=; b=ZhXUOEbDF47EBQGWjR7F6UDGrGk/drmtd7oUlH2OSLamRiob0EVrXFLhhn4IU9hp8laOY899Spx9VHLv7riD3FF3M016IjRpim1RxdjVUwf9i3591c1QiXy6LUwTHGMs56XPO0v2MshVXs8mO6ezWRn4d1gkXpLQRfCdC5iI5Qk=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.29.24) by VI1PR07MB5536.eurprd07.prod.outlook.com (20.178.13.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.4; Fri, 20 Dec 2019 14:14:49 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::f4ac:1bfd:a5a1:aadf]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::f4ac:1bfd:a5a1:aadf%6]) with mapi id 15.20.2559.012; Fri, 20 Dec 2019 14:14:49 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Thread-Topic: [meeting minutes] RE: YANG package updates
Thread-Index: AdW3Iz/Ytf/SKNW2RTSzRdJ2KaA2fQAHCzQQ
Date: Fri, 20 Dec 2019 14:14:49 +0000
Message-ID: <VI1PR07MB398139B8ABAE972A35CFEF409B2D0@VI1PR07MB3981.eurprd07.prod.outlook.com>
References: <MN2PR11MB4366271C7B488D904E61539AB52D0@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366271C7B488D904E61539AB52D0@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com;
x-originating-ip: [45.72.135.40]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ce9dcc6b-d4b6-406a-d2a2-08d78556f97a
x-ms-traffictypediagnostic: VI1PR07MB5536:
x-microsoft-antispam-prvs: <VI1PR07MB5536F1E27BCEAE22F1B7EF4C9B2D0@VI1PR07MB5536.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 025796F161
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(136003)(39860400002)(346002)(51444003)(189003)(199004)(186003)(9326002)(26005)(8936002)(66946007)(76116006)(71200400001)(478600001)(33656002)(66476007)(66446008)(64756008)(66556008)(316002)(52536014)(110136005)(7696005)(2906002)(81156014)(15650500001)(5660300002)(81166006)(8676002)(86362001)(55016002)(30864003)(9686003)(6506007)(53546011)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5536; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /Av0nZw3s0bYj0KvBrUeAbhlf3fiC5wSN38u6bEsbkLYPmZkbgHL/BW22lvDq4IvUFOiK8xjZeRULC1BPXCgzSG1cuwUJ7dFwVg+x7xKi8FkdxRVO3e8DY8zpZVjTpGJDQFpyRmUFPlihznWKKuAVLcvi46pQ5ZTzTlrLevxrsaYDYVpyOn7UYQpiRJD2dGTxZwBoRjo23tfidaVdBXU7haMLx1XbNf0CR1i8nKq6mOVja9N0zXCJ8sR0FMNPT/rcyLNVcTt7Khdq6KaFtuVhOu8uXvLaSqyX/IXmH47tzPHSewbHXErzAX7aJVb+XVYGAvQT3JStznP73ILl1nMMMhOBqOvQmqq40EDvwM8ogekVVgLw8+uANC+nTKUw5fztIru8oduHlPK+tIP5ZalIEXmQJl48p+hvv1z8eDHbGNJm8JNc7uQcPbcoDgosV2JOwt8lUdPYJ8ICPzuEYWqkauWf5PkjGABaNPyiI6sCnPLzOdBuNZXnG+q8e5eNVpc
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB398139B8ABAE972A35CFEF409B2D0VI1PR07MB3981eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce9dcc6b-d4b6-406a-d2a2-08d78556f97a
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 14:14:49.4612 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3nfcOf08UOvICLsyKJs7zhmZ/GAxvzmjfdLl83xrnB0crOWdSQauQNbviFmdHfdi832GADqGuqB0xhjQUI0ttQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5536
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod-ver-dt/7n1qw6I7lX2kuwGn_0HGFNZRFTw>
Subject: Re: [Netmod-ver-dt] [meeting minutes] RE: YANG package updates
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: Fri, 20 Dec 2019 14:14:56 -0000

Hi Rob,

About this:  " An implication of this is that if the file is not available somewhere then the device cannot provide a checksum."

We're you thinking that in order for a server to populate that checksum field, it would actually go out via the URI and find a file and run a checksum over it (and then report that checksum in this tree)?

That isn't how I was thinking of this. I was thinking that a server would have a-priori knowledge of the expected checksums of any packages that it advertises.  So the availability of the file wouldn't affect whether the server can return the checksum or not.

Jason

From: Netmod-ver-dt <netmod-ver-dt-bounces@ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, December 20, 2019 5:56 AM
To: netmod-ver-dt@ietf.org
Subject: [Netmod-ver-dt] [meeting minutes] RE: YANG package updates

Minutes from yesterday's short meeting (only Jason, Reshad and I) :


  *   We agreed that we preferred the packages structure below, and that this is a much better way of explaining the relationship between the instance data package files and the on the device packages.
  *   We seemed to reach agreement that the checksum/location is on the right track, but the document should clarify the SHA-256 is *only* based on the instance file contents, not what is in YANG library.  An implication of this is that if the file is not available somewhere then the device cannot provide a checksum.
  *   There wasn't much time spent discussion the version selection, but a couple of points were discussed:

     *   I don't think that we have figured out whether it is right for a schema to be limited to a single package per datastore, or whether it should be a simple union of packages (which might be better for custom schema implementations because then the device doesn't need to "create" packages to represent the union).  I think that I'm now thinking that union might be better.
     *   There was some discussion on whether the name of the schema should match the "name@version" of the packages.  I think that the leaning was towards this being a SHOULD rather than a MUST.

  *   We agreed that having some concrete examples would probably greatly help determine whether we are on the right track with the models, and will probably be very helpful in the version selection draft.

There will be no meeting for the next two weeks.  Hence the next meeting will be 9th Jan.

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: 17 December 2019 15:44
To: netmod-ver-dt@ietf.org<mailto:netmod-ver-dt@ietf.org>
Subject: [Netmod-ver-dt] YANG package updates

[Mostly] based on the discussions last Thursday, I have had another ago at updating the packages.  Files pushed to github (as per attached).  Tree output at the end of this email.


1)      I've currently ditched the idea of using "<pkg-name>@<version>" as the identifier for a package and just gone back to separate name and version fields.  This makes the references slightly more verbose/ugly but has the benefit of consistency between the instance data file and the on the device data.

2)      I've renamed the file ietf-yang-package.yang to ietf-yang-package-instance.yang

3)      The structure between the YANG instance data package definition (ignoring the standard fields for all instance data documents) and the package list entry are the same, except that the package list entry also contains the location and checksum.  It doesn't make sense to put these into the instance data document because either they can't be known (checksum) or they are self-referential (location).

module: ietf-yang-package-instance
  structure package:
    +-- name                  pkg-name
    +-- version               pkg-version
     ... this is exactly the same as everything in the package list entry below ...

module: ietf-yl-packages
  augment /yanglib:yang-library:
    +--ro package* [name version]
       +--ro name                  pkg-name
       +--ro version               pkg-versionmodule: ietf-yl-packages
       |  ... matches above, plus the following two fields ...
       +--ro location*     inet:uri
       +--ro checksum?     pkg-types:sha-256-hash


4)      I've removed the "supported-optional-feature" leaf-list from the YANG-library augmentation (to /yanglib:yang-library/yanglib:schema).  I think that it is more consistent to define a separate package for this use case, which can define the features used by the package, and also allows the schema to be available off the device.

I've had another bash at the schema-version-selection YANG module:

5)      The "default-schema" is now also the schema that persistent configuration is restored from.  I.e. I'm thinking that generally the default schema is what the secondary schema are either selected subsets of or are converted into.

6)      Custom-schema are now just a named union of selectable schema.  I.e. it no longer defines a package instance to sit alongside the custom schema, clients have to manage this themselves (which seems reasonable).

7)      I've separated the naming of schema vs the naming of packages defining those schema.  If we follow this path we need to decide whether the names can contain "@" and whether they should match "<name>@<version>".

8)      Schema's now no longer explicitly identify a package to represent the pan-datastore schema.  It still logically exists, but isn't explicitly reported (which keeps the definition closely to RFC8525).

9)      Each schema defines whether it is selectable as a default schema, secondary schema, or as part of a custom schema.  The schema compatibility details are also split out depending on how it is being used.  I.e. to give implementations more control of what types of

Thoughts/comments welcome.

Tree output for the updates.

Version selection:

module: ietf-schema-selection
  +--rw schema-selection
     +--rw default-schema?     -> /schema-selection/schema/name {default-schema}?
     +--rw secondary-schema*   -> /schema-selection/schema/name {secondary-schema}?
     +--rw custom-schema* [name] {custom-schema}?
     |  +--rw name               string
     |  +--rw description?       string
     |  +--rw included-schema*   -> /schema-selection/schema/name
     +--ro schema* [name]
        +--ro name                           string
        +--ro datastores* [datastore]
        |  +--ro datastore    ds:datastore-ref
        |  +--ro package
        |     +--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 default-schema-selectable! {default-schema}?
        |  +--ro compatible-secondary-schema*   -> /schema-selection/schema/name
        +--ro secondary-schema-selectable! {secondary-schema}?
        |  +--ro compatible-default-schema*     -> /schema-selection/schema/name
        |  +--ro compatible-secondary-schema*   -> /schema-selection/schema/name
        +--ro custom-schema-selectable! {custom-schema}?
           +--ro combinable-schema*   -> /schema-selection/schema/name


YANG instance data definition:

module: ietf-yang-package-instance

  structure package:
    +-- name                  pkg-name
    +-- version               pkg-version
    +-- timestamp?            yang:date-and-time
    +-- organization?         string
    +-- contact?              string
    +-- description?          string
    +-- reference?            string
    +-- complete?             boolean
    +-- local?                boolean
    +-- previous-version?     pkg-version
    +-- nbc-changes?          boolean
    +-- tag*                  tags:tag
    +-- mandatory-feature*    scoped-feature
    +-- included-package* [name version]
    |  +-- name                pkg-name
    |  +-- version             pkg-version
    |  +-- replaces-version*   pkg-version
    |  +-- nbc-modified?       boolean
    |  +-- location*           inet:uri
    |  +-- checksum?           pkg-types:sha-256-hash
    +-- module* [name]
    |  +-- name                 yang:yang-identifier
    |  +-- revision?            rev:revision-date-or-label
    |  +-- replaces-revision*   rev:revision-date-or-label
    |  +-- namespace?           inet:uri
    |  +-- location*            inet:uri
    |  +-- checksum?            pkg-types:sha-256-hash
   |  +-- submodule* [name]
    |     +-- name        yang:yang-identifier
    |     +-- revision    yang:revision-identifier
    |     +-- location*   inet:uri
    |     +-- checksum?   pkg-types:sha-256-hash
    +-- import-only-module* [name revision]
       +-- name                 yang:yang-identifier
       +-- revision             rev:revision-date-or-label
       +-- replaces-revision*   rev:revision-date-or-label
       +-- namespace?           inet:uri
       +-- location*            inet:uri
       +-- checksum?            pkg-types:sha-256-hash
       +-- submodule* [name]
          +-- name        yang:yang-identifier
          +-- revision    yang:revision-identifier
          +-- location*   inet:uri
          +-- checksum?   pkg-types:sha-256-hash

YANG library augmentations:

module: ietf-yl-packages
  augment /yanglib:yang-library:
    +--ro package* [name version]
       +--ro name                  pkg-name
       +--ro version               pkg-version
       +--ro timestamp?            yang:date-and-time
       +--ro organization?         string
       +--ro contact?              string
       +--ro description?          string
       +--ro reference?            string
       +--ro complete?             boolean
       +--ro local?                boolean
       +--ro previous-version?     pkg-version
       +--ro nbc-changes?          boolean
       +--ro tag*                  tags:tag
       +--ro mandatory-feature*    scoped-feature
       +--ro included-package* [name version]
       |  +--ro name                pkg-name
       |  +--ro version             pkg-version
       |  +--ro replaces-version*   pkg-version
       |  +--ro nbc-modified?       boolean
       |  +--ro location*           inet:uri
       |  +--ro checksum?           pkg-types:sha-256-hash
       +--ro module* [name]
       |  +--ro name                 yang:yang-identifier
       |  +--ro revision?            rev:revision-date-or-label
       |  +--ro replaces-revision*   rev:revision-date-or-label
       |  +--ro namespace?           inet:uri
       |  +--ro location*            inet:uri
       |  +--ro checksum?            pkg-types:sha-256-hash
       |  +--ro submodule* [name]
       |     +--ro name        yang:yang-identifier
       |     +--ro revision    yang:revision-identifier
       |     +--ro location*   inet:uri
       |     +--ro checksum?   pkg-types:sha-256-hash
       +--ro import-only-module* [name revision]
       |  +--ro name                 yang:yang-identifier
       |  +--ro revision             rev:revision-date-or-label
       |  +--ro replaces-revision*   rev:revision-date-or-label
       |  +--ro namespace?           inet:uri
       |  +--ro location*            inet:uri
       |  +--ro checksum?            pkg-types:sha-256-hash
       |  +--ro submodule* [name]
       |     +--ro name        yang:yang-identifier
       |     +--ro revision    yang:revision-identifier
       |     +--ro location*   inet:uri
       |     +--ro checksum?   pkg-types:sha-256-hash
       +--ro location*             inet:uri
       +--ro checksum?             pkg-types:sha-256-hash
  augment /yanglib:yang-library/yanglib:schema:
    +--ro package
       +--ro name?       -> /yanglib:yang-library/package/name
       +--ro version?    -> /yanglib:yang-library/package[name = current()/../name]/version
       +--ro checksum?   -> /yanglib:yang-library/package[name = current()/../name][version = current()/../version]/checksum

Thanks,
Rob