From nobody Sun Jul 1 22:42:29 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD018130DF9; Sun, 1 Jul 2018 22:42:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153051014170.27353.8312585410879472797@ietfa.amsl.com> Date: Sun, 01 Jul 2018 22:42:21 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 05:42:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Module Tags Authors : Christan Hopps Lou Berger Dean Bogdanovic Filename : draft-ietf-netmod-module-tags-02.txt Pages : 10 Date : 2018-07-01 Abstract: This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be standardized and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document provides guidance to future model writers and, as such, this document updates [I-D.ietf-netmod-rfc6087bis]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 01:07:40 2018 Return-Path: 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 36C67130E46; Mon, 2 Jul 2018 01:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PY26Eqv4S5AM; Mon, 2 Jul 2018 01:07:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 84F42130E41; Mon, 2 Jul 2018 01:07:31 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4201E5C35667B; Mon, 2 Jul 2018 09:07:24 +0100 (IST) Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 2 Jul 2018 09:07:25 +0100 Received: from DGGEMI526-MBX.china.huawei.com ([169.254.8.180]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0382.000; Mon, 2 Jul 2018 16:07:21 +0800 From: "Wubo (lana)" To: "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt Thread-Index: AdQRz+j3reyaFMCgSeK3CKn0gITfaw== Date: Mon, 2 Jul 2018 08:07:20 +0000 Message-ID: <520ECC8D9CA1724BA1CE492DF898F6A3318C07@DGGEMI526-MBX.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.189.23] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 08:07:34 -0000 RGVhciBOZXRtb2QsIE9wc2F3ZywNCg0KUGxlYXNlIHNlZSBvdXIgbmV3bHkgdXBsb2FkZWQgZHJh ZnQgb2YgVEFDQUNTKyBZQU5HIGRhdGEgbW9kZWwsIHdoaWNoIGNhbiBiZSBmb3VuZCBhdA0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoZW5nLW5ldG1vZC10YWNh Y3MteWFuZy0wMS50eHQuDQoNCg0KVGhpcyBkYXRhIG1vZGVsIGRyYWZ0IGlzIGJhc2VkIG9uIHRo ZSBUQUNBQ1MrIHdvcmtpbmcgZ3JvdXAgZHJhZnQgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vcHNhd2ctdGFjYWNzLTEwLg0KVEFDQUNTKyBwcm92aWRlcyBEZXZpY2Ug IEFkbWluaXN0cmF0aW9uIGZvciByb3V0ZXJzLCBuZXR3b3JrIGFjY2VzcyBzZXJ2ZXJzIGFuZCBv dGhlciAgbmV0d29ya2VkIGNvbXB1dGluZyBkZXZpY2VzIHZpYSBvbmUgb3IgbW9yZSANCmNlbnRy YWxpemVkIHNlcnZlcnMuICBXaXRoIHZhcmlvdXMgVEFDQUNTKyBJbXBsZW1lbnRhdGlvbiwgc2Vy dmljZSBwcm92aWRlciBtYXkgbmVlZCBkaWZmZXJlbnQgVEFDQUNTKyBZQU5HIG1vZHVsZXMNCiB0 byBtYW5pcHVsYXRlIG1hc3NpdmUgZGV2aWNlcy4NClNvIHdlIHByb3Bvc2UgdG8gZGVmaW5lIGEg IGdlbmVyaWMgVEFDQUNTKyBkYXRhIG1vZGVsICB0byBhbGxldmlhdGUgdGhpcyBpc3N1ZS4NCg0K V2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byByZWNlaXZpbmcgeW91ciByZXNwb25zZS4NCg0KQmVz dCByZWdhcmRzLg0KDQpCbw0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0Kt6LL zcqxvOQ6IDIwMTjE6jfUwjLI1SAxNDoxNQ0KytW8/sjLOiB3YW5neml0YW8gPHdhbmd6aXRhb0Bo dWF3ZWkuY29tPjsgV3VibyAobGFuYSkgPGxhbmEud3Vib0BodWF3ZWkuY29tPjsgWmhlbmdndWFu Z3lpbmcgKFdhbGtlcikgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+OyBXdWJvIChsYW5hKSA8 bGFuYS53dWJvQGh1YXdlaS5jb20+OyB3YW5neml0YW8gPHdhbmd6aXRhb0BodWF3ZWkuY29tPg0K 1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRtb2QtdGFj YWNzLXlhbmctMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoZW5nLW5l dG1vZC10YWNhY3MteWFuZy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQm8gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5nDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJWWFuZyBk YXRhIG1vZGVsIGZvciBUZXJtaW5hbCBBY2Nlc3MgQ29udHJvbGxlciBBY2Nlc3MgQ29udHJvbCBT eXN0ZW0gUGx1cw0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNy0wMQ0KR3JvdXA6CQlJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOgkJMzMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5nLTAxLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5nLTAxDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC16aGVu Zy1uZXRtb2QtdGFjYWNzLXlhbmcNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5nLTAxDQoNCkFic3Ry YWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIFRlcm1pbmFs IEFjY2VzcyBDb250cm9sbGVyDQogICBBY2Nlc3MgQ29udHJvbCBTeXN0ZW0gUGx1cyAoVEFDQUNT KykuDQoNCiAgIFRoZSBZQU5HIGRhdGEgbW9kZWwgaW4gdGhpcyBkb2N1bWVudCBjb25mb3JtcyB0 byB0aGUgTmV0d29yaw0KICAgTWFuYWdlbWVudCBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIChOTURB KSBkZWZpbmVkIGluIFtSRkM4MzQyXS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Mon Jul 2 02:04:11 2018 Return-Path: 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 A92CC130E4A; Mon, 2 Jul 2018 02:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 iWxZymDFGoO6; Mon, 2 Jul 2018 02:04:07 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0561277BB; Mon, 2 Jul 2018 02:04:07 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id z24-v6so7203175pfe.7; Mon, 02 Jul 2018 02:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2QwOjOrA/wZAzi4mKbrCFSl5nXS5kLtYrmT0186+FxM=; b=j25qiUt8E5WBJYUylYS7REUM+PNWZg9QrIngas/hTZRbtIJFgPI8ABvdXwOTI0mNa9 N6KwXUc+jkO+xSFmO84DImBI/0dgfgL0wF53gEw2NYaqKZhpBYEdt0sojJ9urv6wwB6D 3VPGXW5SKj9sEtR2/M+HhrSOMh3Qf74nlALFa+4MUbtmyEiDlhSbK18eX7IYwjt82yzB Vx8jmT6iaKh3s4J3VxR9kQ9qv1MFzNW1ox0GoBYZGqPtPL0ERRDIQj3Ry+ftSxtnl/uZ yztFs+O9R/ePQcvkJIhhC/8hQPlWnTonyTIJvqJ7Z07Wq57jrko+nJzx2Dscq8t7BxbS 8GHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2QwOjOrA/wZAzi4mKbrCFSl5nXS5kLtYrmT0186+FxM=; b=R6KVMgH01bAkWSlOa4188JVSeb0vHzNM+sCLxnxfcqUzhWL/TAz10xZ0bE9ef5KjJW gzjjxLA44gABVVzEJv+AG1OVcPCLAaPMb6b8zDA9PkNfNvgDeQlnEyajYZAkfVPE5EKx Vn48p3+0/xfXZYdvPEf01Xh4EJE0hxKjEJugxllZnqMjB4vvFo7TFYGwpL/FwYcJIfSJ T5MuF+fF4YVC6gn2mvbL/vzZVA0sYT0T3WaHt1PPHFZ0FZvod+EIDzRDCRlyOrZUBOXt HEoI/X7Floh7GqGrlLrkl34AaXEShKukacOVkSKSWlF63XBBQdZQ7ZGI0rTwShzLM40f bDZA== X-Gm-Message-State: APt69E2kVR6hIXUAjoQRbrNDu62Ht0ysMRRNHo+EMqK5mNIHiDjprikc faAQfo/DOvzwmYjRHZmq+yPFhykaMVIHNCDmUfk= X-Google-Smtp-Source: AAOMgpfrhTpa1mss03L2FMf0HAKFze3dLUPHOo+iHxp017AoLfIOM5zlSgp4qPk9fMuo+BLggdOLndFCACM4TEhe3pA= X-Received: by 2002:a65:450a:: with SMTP id n10-v6mr16053667pgq.392.1530522246910; Mon, 02 Jul 2018 02:04:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Mon, 2 Jul 2018 02:04:06 -0700 (PDT) In-Reply-To: <55D73233-1092-4553-94C6-BC0DEAD2EF84@juniper.net> References: <35F026C4-5C20-4E8B-B1F0-C6E2D7781E47@juniper.net> <87B93335-EA1A-4CE2-84F8-9A1B5558035B@juniper.net> <55D73233-1092-4553-94C6-BC0DEAD2EF84@juniper.net> From: nicola sambo Date: Mon, 2 Jul 2018 11:04:06 +0200 Message-ID: To: Kent Watsen Cc: "netmod@ietf.org" , "netmod-chairs@ietf.org" , Fioccola Giuseppe Content-Type: multipart/alternative; boundary="000000000000d919350570007ab6" Archived-At: Subject: Re: [netmod] IETF 102 presentation requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 09:04:10 -0000 --000000000000d919350570007ab6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Kent, we'd like to ask for a slot related to this draft https://datatracker.ietf.org/doc/draft-sambo-netmod-yang-fsm/?include_text= =3D1 Thanks. Best, Nicola Il gioved=C3=AC 28 giugno 2018, Kent Watsen ha scritt= o: > Per the Important Dates [1], the draft submission cutoff deadline > in this Monday, July 2nd. Please be sure sure to submit updates > for your drafts before then! > > [1] https://datatracker.ietf.org/meeting/important-dates/ > > Thanks, > Kent // co-chair > > > > > > Just a quick reminder for folks to send presentation requests. > Please have requests in no later than this Sunday (July 1st). > > K. > > =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D > > Dear WG, > > The chairs notice that the preliminary IETF 102 Agenda has been posted > [1]. NETMOD is scheduled to meet Tuesday afternoon and Friday morning, > both sessions are two hours. > > *** Yes, NETMOD is meeting on Friday, the last day of the conference! *** > > If you are interested in presenting to the WG, please send your > presentation requests to the "netmod-chairs" alias with the following > information, for each presentation request, if more than one: > > - name of the drafts (if any) > - name of presentation (usually same as the name of the draft) > - name of the presenters > - desired time request in minutes. > > [1] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ > datatracker.ietf.org_meeting_102_agenda.html&d=3DDwIGaQ&c=3D > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D > nEV2vxzatgmspqtjKXgo65Ks6s4yoUMZhzJXu_zH7lo&s=3D > uo8nf0yFGjYAZxAwBRhUZkmMjunNiNHUUgiYOEakOxA&e=3D > > Thanks! > Kent (and Lou and Joel) > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000d919350570007ab6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Kent,

we'd like to ask for a slot related to th= is draft


Thanks. Best,
Nicola

Il gioved=C3=AC 28 giugno 201= 8, Kent Watsen <kwatsen@juniper.n= et> ha scritto:
Per the Important = Dates [1], the draft submission cutoff deadline
in this Monday, July 2nd.=C2=A0 Please be sure sure to submit updates
for your drafts before then!

[1] https://datatracker.ietf.org/meeting/important-dates/=

Thanks,
Kent // co-chair





Just a quick reminder for folks to send presentation requests.
Please have requests in no later than this Sunday (July 1st).

K.

=3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D

Dear WG,

The chairs notice that the preliminary IETF 102 Agenda has been posted [1].= =C2=A0 NETMOD is scheduled to meet Tuesday afternoon and Friday morning, bo= th sessions are two hours.

*** Yes, NETMOD is meeting on Friday, the last day of the conference! ***
If you are interested in presenting to the WG, please send your presentatio= n requests to the "netmod-chairs" alias with the following inform= ation, for each presentation request, if more than one:

=C2=A0 - name of the drafts (if any)
=C2=A0 - name of presentation (usually same as the name of the draft)
=C2=A0 - name of the presenters
=C2=A0 - desired time request in minutes.

[1] https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_meeting_102_agenda.html&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Sc= bfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBY= aGTvjISlaJdcZo&m=3DnEV2vxzatgmspqtjKXgo65Ks6s4yoUMZhzJXu= _zH7lo&s=3Duo8nf0yFGjYAZxAwBRhUZkmMjunNiNHUUgiYOEakOxA&e= =3D

Thanks!
Kent (and Lou and Joel)






_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod
--000000000000d919350570007ab6-- From nobody Mon Jul 2 08:02:33 2018 Return-Path: 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 8AACF130E15 for ; Mon, 2 Jul 2018 08:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=XTTgOzk1; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lxCnEapV 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 FNhjwFowwkCh for ; Mon, 2 Jul 2018 08:02:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5C2DD130F79 for ; Mon, 2 Jul 2018 08:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530543728; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NRNvp6AuM2YXsxTfF8UheFbgCvLNTBO99G6/025MupM=; b=XTTgOzk1V2h244qY/nA3NrYC4X48ZOWuAlMhi37AT2PRH9QSGa74bo2RhOcjpHhy NhTNskdeahHRjCqD7Zi//rx9I8b7rFTjgJRg9h7ikflw1wPKKyqSCxhLvDCt5gBN Nk/f0e376OhfpdRrhXJVnWttaN/QAL/sp2sXROnEdcQ=; X-AuditID: c1b4fb30-93dff70000000a77-72-5b3a3e70c2b7 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.93.02679.07E3A3B5; Mon, 2 Jul 2018 17:02:08 +0200 (CEST) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 2 Jul 2018 17:02:08 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 2 Jul 2018 17:02:08 +0200 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 2 Jul 2018 17:02:07 +0200 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=mgYKRgo2iy2jOjWRVZY8+G2XuDXw+GyKxYvZpG83JHk=; b=lxCnEapVpej5LK+K17t7PRdPPqegxXF67Ac1flEAy6Fftpu3pegwawSysypGmbddTlyZdVWTabJhTdise9WsJL06x3URl0waqxkIm4uQp0VO62vTBGN4dXYLODIkq9eyCOkPN8spXfYbYW5dEJe+9boBu0OkFmSgAyoOzmuvBYU= Received: from [159.107.197.27] (89.135.192.225) by DB3PR07MB0489.eurprd07.prod.outlook.com (2a01:111:e400:942e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.17; Mon, 2 Jul 2018 15:02:05 +0000 References: <153054357191.16263.2004458376207699772.idtracker@ietfa.amsl.com> To: "netmod@ietf.org" From: Balazs Lengyel X-Forwarded-Message-Id: <153054357191.16263.2004458376207699772.idtracker@ietfa.amsl.com> Message-ID: <51b3788d-b4a3-0e6b-f052-ad872d979de8@ericsson.com> Date: Mon, 2 Jul 2018 17:01:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153054357191.16263.2004458376207699772.idtracker@ietfa.amsl.com> Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: VI1PR07CA0132.eurprd07.prod.outlook.com (2603:10a6:802:16::19) To DB3PR07MB0489.eurprd07.prod.outlook.com (2a01:111:e400:942e::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76ae5d7c-59e2-4681-9895-08d5e02cc6c5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DB3PR07MB0489; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0489; 3:XEellLfJgtPF4KWt/rWHG+OC0Xf3/Xxq37jhwIhRizJkwaAYj+zQkNnwYznXZ9tZlaK3h73A5hBd24/oTXz4rblnFkV6lDkx286dGKiI8R409DFSW9DhMBAPF4FRymZ0hU+EkgnJwMmXr+JnPZwPZXMVyXhXk5AIS03NbPtuXRJfm79NlDhqS5VL2c6eJKzqNW0jQl66/Fw5LFytXcgBLrX8xARcplgYraxQOM5y6BZ2vOGDtKMi2qnH/ILChhVf; 25:7yZRwJ0LHE8uJsE5fX4ozeC/5fTBIvJedlWHmjGw6IByrvSpz5gB9DswjU4tTW+1UjL4eZAwK1TUqk1QsppB9cixwQGwp+TQZOjo/0cLfnYi/Wbpqy29bf0RbBH2tM+L0ptIOqjqti+6l8GDoSNvOGMjOjzk7rCbh6fO3/63c7SoXlT7gztzyVlt4QCRz7/9ufGO3D5/zaaD9aMiCO2ysMMZ3hvOh93WCOjbYgBse8LQOnGPDyMb27Zug1ZWI6UqhcKm/Rq8I7Y8ISMoFcb7P7TAc3bKvIE6xaIDKkhecjq989I5iWv+ehdH3UhfgFzfvM5iPu5+FRfOZl00Zo/1VA==; 31:APUlKmQ00TJ26PPjzW1h4IySEUhUDsV7MpFMejvpXJJq0c89PJNJrtUzDW6+LYh5ef6Gs/iYRlP7DzkjbSLSZNxwa5t2w7iu4oSxfJfLOoA+ThvsbPXASRBAXTJ3okmPoZVcSw1R+CqBlwHPGAoale3AhkxiCxYD9AapGdpEhE5iCSPU8/HlZOWIUlEgo34hPLblrHRFfoCAMTNlziEUTGuWOFHnLxYiP/3Tgo+9oWI= X-MS-TrafficTypeDiagnostic: DB3PR07MB0489: X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0489; 20:fOtJ1zYHFh7JakJh6tVMx77MBd9cYJtj6pynIghSPYI6O02+4XKUiP6PkpGXVSuvAZrH74nTHV9vJSZtBakkaswRuFi+9LsYDym8yW5b6lmaU+eEZQk744as50ON29Rop6h73h78taHpjhFdG26re3bESd/N5nPXsfTgRCSofat1rEENDnLqanFV3wYJPwNbxozA/AiNv3k2wWsUz5UJn6HeAUGySGil//uDo1OXM/nEGr1+u7yEi1aF7zRM7wQSgSDVJqizb4RR3yjyCVDCvEML+dX8V/UVY11AOzfoF0EogmBbbmgT9FQ0oHFokDfZxatR0NE/PLZ4uq8TrpZWWhlYkqhWlgzQuS8bA/kmrVj7Uma8lyGXHpUohW84OjzwfoLxur4pvJjn8clhL8ekCawfigic1gJAYAnlRyL/UWnzJTUn4wDcZUULfYqDTvGpR/HuS4E9JSoGz3APdSxnYVwcnDTyX8R/b07HobKW7Nlr82UvgxYeHsgzvMZ+Vlfw; 4:ryugfDtdB0d3BUYXUx8P1mFAZjXafhTi15FtZz7ObUNnS3FrnZlobnxZgMYLDY7wwGEP3/8bPZ2pou2EZEt2Rssm4Ju8gFMwETY6BIDxT8RVHQqp95FwVQVYRoggz64mPrbYtGCvseeqD3g5faGVsgCTLZmPQ/fr+KTCEmzH5Eg0oPr4n52kq7N7VYpQj8EOpeLC8zmgyeD8U7grmMC4J/TBunOu/4KnkUqxi/MsqNnPUrtEKv0htDvp3Ia2MSXRgXawCTfMFHaagbKCfpe6Y+FntbygKlKo2rkm2IPW4xzTjXWaB2poJSOY3jDm0yZ5E0ocZy64QRBae7ZBXUaSpMfeB06ZxsofetzGzHxUP8Df92gIA5bMh5KuAAqG5L3hhJNsTYQvpWeC0EcomBE8Q1WmGrOlZid7VK5ORDNBFPc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(120809045254105)(95692535739014); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DB3PR07MB0489; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0489; X-Forefront-PRVS: 07215D0470 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(346002)(39860400002)(396003)(366004)(136003)(189003)(199004)(252514010)(86362001)(316002)(76176011)(31696002)(52116002)(8676002)(1730700003)(52146003)(2486003)(23676004)(81166006)(15650500001)(81156014)(8936002)(97736004)(476003)(3846002)(6116002)(486006)(44832011)(50466002)(68736007)(230700001)(6346003)(16526019)(14444005)(106356001)(478600001)(26005)(7736002)(186003)(49976009)(66066001)(65956001)(65806001)(16576012)(64126003)(386003)(105586002)(58126008)(6916009)(65826007)(966005)(5640700003)(6486002)(6306002)(236005)(54896002)(5660300001)(2906002)(606006)(23846002)(31686004)(446003)(53936002)(2351001)(956004)(2616005)(36756003)(25786009)(2501003)(6666003)(11346002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB0489; H:[159.107.197.27]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNDg5OzIzOjRrSE84ZmpDM1NPazlmMzAydDBPQWYzb0xr?= =?utf-8?B?RjRMNVdlVWZuU2pydzRTQUpzbFV5WncrUGxxdThHb1ZBUHNSNHU0c1dSb05p?= =?utf-8?B?dHFJMXFiVFFyWGlrYmRJTldsZkRiSEtjVnMzODFwd0NVOXF4dEFoZ2ZUWC9L?= =?utf-8?B?N3FzSDU0c0EybWJRTU5TelJ4REh0Zzl0Mi9NODdSY2VLTkx2ZWlLWVNQVWU3?= =?utf-8?B?dzBmTDRMVStoQlVQbzVqTEpPdGhmdDFEWktxdzFyNUhhMkFXMktIUjg2VVJU?= =?utf-8?B?YStmUXlYaVVDRGY5QVRCekpYYTNrUTlmT0EwS2xQUjA0d2FTYXRUYUZEMllN?= =?utf-8?B?OXVwbFhGVHVndzZYZWtKK0ZzdXNZcEh5ZE5mSmFxdEVSY09ab0JpekdTL1Qr?= =?utf-8?B?Nm0wMVpFN2Zpd3ErWUpCYmphMWZ3Nk8ydjJGWUV3NUtKTUpzb1hPVVlLWVFk?= =?utf-8?B?dkg0dnJvTm5Ed0JCZnJONUc0VXhJdExKbGJLQVNXcWxFSm1tOWdNYkZDRUlk?= =?utf-8?B?bXdUSWNna0E4eWxOSXkrb203Mmxra0crMWxmQkFVSFFKc1A0bWEzY0hhOUlV?= =?utf-8?B?Q1JxZlpxSklrUWxaOVQ2RUVtMTRYbHBZdmlONDZscGJNVWJpc0k5czVNYVFM?= =?utf-8?B?OGJkc0ZhM1Urc0FUSUJQbklJdElka042NzVPc1pNMEJ0a0theUVUWm5oVFpl?= =?utf-8?B?cEdkQTlHdDBtbVcyZXMrdmJBcFM3dytOcVRMc24rbW5POFJHSU1QOGNwSWVP?= =?utf-8?B?Rk5qZmJ6cEpqL1dSbkFxeEFVQWdaa0t1SDBUcTBVeXYzbHZPTjVTQmlselpy?= =?utf-8?B?bTQwSHFNRjB4M2NJL1l3NzhwRFNic0lJZ2VjRWxDdk1WaGp5Qko5bTJuQWZJ?= =?utf-8?B?ZGlWeTNpNHVuY0c4ZHZXaGV3ZU91VkpyT0tLUXFtUkxzUVZweDBMMTNBY09V?= =?utf-8?B?UGFZc1BxRjFDbi80My9wRDRIZDFQUGlYb3ovNXp3WHpJK3VUSldjZWxnOE5W?= =?utf-8?B?ckp5NElCSm0zY1pEYVErMDJta09iZ3hmLy9Ba0JYUEsyOUVRVjErUVRwd2x3?= =?utf-8?B?bTNtRC82Nkd5Rm1QWGFhYWVwbnhDY2pSdG9yR3pIMUJGanlxcm9vdG8vVjVF?= =?utf-8?B?UXNtbDNHSzBpYm80Tm9zNGhRYklBejRnZUkrQVRRRWh1dUo2MWh1OGFLR2Mv?= =?utf-8?B?ZmY5RXJuWk5WUkNEUmt1Mi9hODEvZkpNcnZwVXNSMVpQWUFsQ2VTcEp1eWc3?= =?utf-8?B?aDFSRFRPUVdSRkJERldjMUpRK2tmZzhqeEZQSFB3ODBiRHh6Z2I5T2wyMFlp?= =?utf-8?B?WTZiUVJ3SzlURHYwRklGNno5NzVKM2ZraWI1OUFiWDlyejEvWFA5OG1UUHJY?= =?utf-8?B?UXpkMi9hNW01U1FYdjhRM3lGcDFjL1ZnVWp3eXZWQW14R1hSTFpMQVlNZVdX?= =?utf-8?B?ZGdmRFJmQTZ4RzN4ck9OR2NnNGlFYmZ2NW11R283YkxYOGhyUEgwdHhBV2hG?= =?utf-8?B?WlVFMHR4aVo5WVliTndhRVVSU0FrQXUxSlVVb2k1cnRCakk0QlNRbmwrci9U?= =?utf-8?B?Zy81cmlQTU1kNkNVeG54ejdnaCticndSZ0R0MnZLZGlUNUorZ2hXT0owdkNu?= =?utf-8?B?Ni9PVUh5Tk1za29vSFlpTFlBeDV1ZUZzU0xWdGIrNzdNcTlqSndpMDdSYWxU?= =?utf-8?B?ZkFZOWVveXZhc1h5QksyZXZCWWVwQXVGNlA1V1drT1ZIUVFUcHFQdHhuNDFa?= =?utf-8?B?clRuTUdES1Y4V1JtbzZLNHFtOW50UlFhMXBLdTNZcm9BQ0JCajdhTVYvaUYz?= =?utf-8?B?Qm1zWkJqOGdXR2ZQcDJ6dXdQeHJLcjFXWkkzVmVZY29wRms5VmU5ZGRXaGxS?= =?utf-8?B?UHZ4cEYvTGZ0dnpheHR0V09EemRpOEliRTlTRU1zN2ZPc0t5VFdQRnArMkI2?= =?utf-8?B?aWYwdWh0ZWVDbGp2ZWM4OSttSzc4dXVua0xNY21lMDFGTHQyVHlVYnVXUEt6?= =?utf-8?B?MVR5L0U0UFc4RFc1VEtwVm5VQVBBWWJIcWxFL1pIWEphcDhQRHkwUUd6cE81?= =?utf-8?B?U01Zd3hyTXFXT0V3ZmE4ZXF3OElVQml4cmhWSnhjWmoyWlgwZzJiNk1oYTJl?= =?utf-8?B?SzAwT0xhay9mc2w4MDRzc2ZvWmQ5b2t3eDF3UzBVMFN1RWFWby9BZ0NnbzFB?= =?utf-8?B?ME96UlZ4Tmg5YjBjWDhLVXEybFBRPT0=?= X-Microsoft-Antispam-Message-Info: RGP5dZw0Z9wsXpT03EwzP9/8N281QhCJHIobuvKcv00WV6nkhjYlJX4m5MAYY6bl9oBMXJ5nkjGXRQJuOabM6km9YICkAJp7hokORD8f04GHMZ2mq+y73kcX04GHNxuYF5F5xRz91D0Ak56o0ZOrRIYuT+G0jxFyN3YdZztoT2FhjOSW2LCeeRtyaLePNDiEwSSCxZaBqfh9d4uYmKbFDFuwmaROrWhjwvnhz+e7RNBSR6CH+C6Kne9grbD/mcEVE/k0gVvCnzUe0On9RyYlK/UBBDFssklOmQ3yCdjlajWbpsq6lw8t+EkVCVgB6VqZDU9RTKFst/AywKasmYT9cjxc5g3NKAEQGjiwSEMGfO0= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0489; 6:+9xTpkYPcxkg1k8yjJvhkbbtPcx9mE/ncB8MfLnp+X9rzYEGIEAHkas7j/JvyumRKzieOptBjfTjGCEGEWTlu55H+GiEIMKlpC7AXi9cCwAVOWTqzVJPrjzVoudRlTicXtTXkSrl8PCqkCSeLX17t4lRGf+6aW/bR7xrKbNhojXz28oLqYx1TLzsOpM8yCob8BZ6c3A3Em93HzpjxtaG/sAhuAgh71YarJi2noceBUC0pvhCsOOCM2dJpb8skZJbZRccOfHeRm3sGPX6L9kxFmDJ9V3gdfVZdWWFMUrDURSG74M8+kwjaa8tuamAttlaICl+i71Ahs/q7jrVpIy5fw72PKl2lU2hG4lb1HhX0ZCF7TnL6Mnm9NATLj8VG10qoVSHbtcwzN863k3Uq9mFFXCYToi/+pzoAEX6tNFC5DZtcqH0gE0co8beB3JA7C1ikfbzfWdrOmXQx+z6rvhVEg==; 5:/tQaXMdF8bIteSbWKsopzX0K8WiWlW3nB0eM5+OsAEDjJfvMmMF48rYNTTbvSpH1v5MsC3G8aUUOXnH6mUSRbu6iotuTkqIZpuMdNUlveaJw6BCwX5YDu8UjZQKt4yCP3lerRd6lBZBZ9WeN+FAHyvtJbWfWyWYJ+a/PEsOwKAg=; 24:17yEp4C8dDaPuej5l8tznud9e53aieka6XjDc544iAa36SDbZoYU+22+7DMshoOF8TOXdHQaWyfMNdxxMwH/8dMfU16OrS0d3+djWxEuxzE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0489; 7:mUVga7lfP3YKrWT6GB1/GzVSl/FkXhwi4jf7Pq+hzvghpZHbUsFiDyYo1J44HrmgK56gEKAdbveP8JL85Sq9navZJOMoiFfMujJ5RAsNMvxndPko2OUy4Ta3DSuoYYoeDvphTPfVNKA1eruqjwvP/lTWxWJ1lcAMlfHig2/ICbMCM58fjW0n+vsq03VD+60qktv+G+XZHhKub6PXjGt6fHsddozjhf9+43epTqwU/kEs2FSD89i7fgIQKmEB7HgU X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2018 15:02:05.9564 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 76ae5d7c-59e2-4681-9895-08d5e02cc6c5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0489 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUyM2J7sW6BnVW0QdMDaYv5FxtZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8efuZNaCTwoVS5b9YG5gfCfZxcjJISFgInHr8lXGLkYuDiGB o4wSb1fMYoVwvjJKrHrYxo7gfD/HBuEsZpJ4M+sRE0g/i8AEZonOS2oQiTYmifW797KBJIQF wiR2r53OAmILCfhKvDjTxgxiiwioS8zcuR6shk3ASGJq/3kWiEMiJf5tvQg0lIODV8BeYsrF HIj5KhJd7YfBWkUFYiRWb7zMDmLzCghKnJz5hAWknFPAT+LbZHkQk1lATWJZqxJIBbOAuMSt J/OZIGx5ie1v5zBDLFKSuPRlGgvIxRICMxkluk6dZYO4UkPi4YW/rBBFshJHz86BusxX4v+u G+wQDRcYJRpnLGODcBrYJc71bYPq0JJY1b0Dyn7CLtG6zxnCzpbondsJFc+RuN59nBHClpM4 1XuOaQKj4Swk/8xCeGIWkidmIXliASPLKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzABHFw y2+DHYwvnzseYhTgYFTi4d3z1zJaiDWxrLgy9xCjBAezkgjvNlWraCHelMTKqtSi/Pii0pzU 4kOM0hwsSuK8Fn6bo4QE0hNLUrNTUwtSi2CyTBycUg2M+g9dQ4NiPzW9eT93bWqzdu2P6q79 CbmyJsWrxMLiDDrW1VhkTQtoOjDjtOw2Yzvjp9cnSIv9vpduWPugl6VkVpuTQfnjt99u652Z NpH1fA3359rgKYYSJqsEpEtYir2uBty/uDde8cnyzkd7zk1ycGJqNVooNV8z52we46KNt62m XCpb4denxFKckWioxVxUnAgA4fXEAQwDAAA= Archived-At: Subject: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:02:27 -0000

Updated the draft-lengyel-netmod-yang-instance-data based on comments from the last weeks discussions. Some went into the text, some added as open issues.

regards Balazs



-------- Forwarded Message --------
Subject: New Version Notification for draft-lengyel-netmod-yang-instance-data-02.txt
Date: Mon, 2 Jul 2018 07:59:31 -0700
From: internet-drafts@ietf.org
To: Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com> 


A new version of I-D, draft-lengyel-netmod-yang-instance-data-02.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name:		draft-lengyel-netmod-yang-instance-data
Revision:	02
Title:		YANG Instance Data Files and their use for Documenting Server Capabilities
Document date:	2018-07-02
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-02.txt
Status:         https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
Htmlized:       https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lengyel-netmod-yang-instance-data-02

Abstract:
   This document specifies a standard file format for YANG instance
   data, that is data that could be stored in a datastore and whose
   syntax and semantics is defined by YANG models.  Instance data files
   can be used to provide information that is defined in design time.
   There is a need to document Server capabilities (which are often
   specified in design time).  Defining server capabilities is foreseen
   as the most important use of YANG instance data files.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Jul 2 08:06:08 2018 Return-Path: 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 EFB9E1274D0 for ; Mon, 2 Jul 2018 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 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 yzELs1-Yu9Az for ; Mon, 2 Jul 2018 08:06:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1E6131106 for ; Mon, 2 Jul 2018 08:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1761; q=dns/txt; s=iport; t=1530543946; x=1531753546; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CyI2SiRh1MAHeOyC6e26DykV9b+NyYriZi/k2ROiWFY=; b=iWXBuXtWyEf+LOHcJ7rM3n7q0AHpSByVTbnnX5/Scruqu1ui61I98kC2 hA0V1YOHepefoiecOj0JZG8whOgJDD1CzPVunYhLOAehoj6QvtTZK6VnH euUNsftUVh+oxYrOU4ntJ2+angN8bEMciwM9LtsivGBKE7QZTy8YxLOw3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AwDpPjpb/5RdJa1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNJYn8og3mUQoFdKpUkgXoLJYRHAoMyITUXAQIBAQIBAQJtHAE?= =?us-ascii?q?LhTYBAwMjVBIcAwECAwImAgJNAggGDQYCAQGDHAGBfw+nZoIciEyBLoELh2K?= =?us-ascii?q?BVj+BNoJogxgBAQIBARaER4JVAogFhEk7jD0JhgaJEQaBQEODSYJGhUOHeoI?= =?us-ascii?q?5h1SBQwMzgVJNIxUagwoJiwuFWiMwARCRSgEB?= X-IronPort-AV: E=Sophos;i="5.51,299,1526342400"; d="scan'208";a="200205436" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2018 15:05:37 +0000 Received: from [10.82.252.4] (rtp-vpn6-1024.cisco.com [10.82.252.4]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w62F5bpu016600 for ; Mon, 2 Jul 2018 15:05:37 GMT References: <153054383423.16428.8893583812050203564.idtracker@ietfa.amsl.com> To: "netmod@ietf.org" From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo= Organization: Cisco X-Forwarded-Message-Id: <153054383423.16428.8893583812050203564.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 2 Jul 2018 11:05:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153054383423.16428.8893583812050203564.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-clacla-netmod-yang-model-update-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:06:07 -0000 Ahead of IETF 102, we have submitted an updated revision of our semantic version document. The primary updates are to call out where we currently address YANG model versionining design team requirements, while calling out gaps that will be addressed. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-clacla-netmod-yang-model-update-06.txt Date: Mon, 2 Jul 2018 08:03:54 -0700 From: internet-drafts@ietf.org To: Benoit Claise , Kevin D'Souza , Balazs Lengyel , Joe Clarke A new version of I-D, draft-clacla-netmod-yang-model-update-06.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Name: draft-clacla-netmod-yang-model-update Revision: 06 Title: New YANG Module Update Procedure Document date: 2018-07-02 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-clacla-netmod-yang-model-update-06.txt Status: https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/ Htmlized: https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-clacla-netmod-yang-model-update Diff: https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-yang-model-update-06 Abstract: This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 2 10:32:02 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BB131155; Mon, 2 Jul 2018 10:31:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153055270636.16350.16257613640176766753@ietfa.amsl.com> Date: Mon, 02 Jul 2018 10:31:46 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:31:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-intf-ext-yang-06.txt Pages : 33 Date : 2018-07-02 Abstract: This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-intf-ext-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 10:34:24 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2218112F1A5; Mon, 2 Jul 2018 10:34:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153055286311.16157.17518221159003026363@ietfa.amsl.com> Date: Mon, 02 Jul 2018 10:34:23 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:34:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Sub-interface VLAN YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-sub-intf-vlan-model-04.txt Pages : 31 Date : 2018-07-02 Abstract: This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orginating from an IEEE 802.1Q compliant bridge. Primarily the classification is based on VLAN identifiers in the 802.1Q VLAN tags, but the model also has support for matching on some other layer 2 frame header fields and is designed to be extensible to match on other arbitrary header fields. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 14:02:58 2018 Return-Path: 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 2E913131340 for ; Mon, 2 Jul 2018 14:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 1smqCg--aqp9 for ; Mon, 2 Jul 2018 14:02:46 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 DED121312E6 for ; Mon, 2 Jul 2018 14:02:42 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 6B31A1760E6 for ; Mon, 2 Jul 2018 15:02:42 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id a5y5fb1uF3r54a5y5fcHEu; Mon, 02 Jul 2018 15:02:41 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dx73c/qWXEGU3kpEvyoDttf6b7N57SOde3S1wdBQZFk=; b=j/Z4XkpSXFchWQ5oa1ZnYdf/wf 8ZUT7ZQmbM4pwMUNOLrlm356DnFHsObihssIboTN3+xDe+uttkWDJGi5lUfEHR70aWrcL0SZyG23k BC9bWHUu0TQZPrjaDjKnPlIhh; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42792 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fa5y5-002Z9l-Rc; Mon, 02 Jul 2018 15:02:42 -0600 To: NetMod WG Cc: NetMod WG Chairs From: Lou Berger Message-ID: Date: Mon, 2 Jul 2018 17:02:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Source-L: No X-Exim-ID: 1fa5y5-002Z9l-Rc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:42792 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] IETF 102 Draft agenda available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 21:02:56 -0000 Hi,     A draft agenda for IETF is now available, please take a look to ensure your request is included: https://datatracker.ietf.org/meeting/102/materials/agenda-102-netmod Comments/corrections should be sent to the WG chairs alias (cc'ed above). Thank you, Lou (Joel and Kent) From nobody Mon Jul 2 16:37:32 2018 Return-Path: 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 E90B01313FE; Mon, 2 Jul 2018 16:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jx9BEsshXRPj; Mon, 2 Jul 2018 16:37:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 3D68E131463; Mon, 2 Jul 2018 16:37:15 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 66DBDB4AC15C9; Tue, 3 Jul 2018 00:37:07 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 3 Jul 2018 00:37:08 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML703-CHM.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0382.000; Mon, 2 Jul 2018 16:37:02 -0700 From: Alexander Clemm To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: Smart filters for YANG-Push Thread-Index: AdQSXGYSlkIq0ljnSr2PXfacfcR+7A== Date: Mon, 2 Jul 2018 23:37:02 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.216.162] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Smart filters for YANG-Push X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:37:28 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Netmod Working Group, we have just submitted a new draft on Smart Filters for Push Updates: https= ://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-00 This draft supersedes draft-clemm-netconf-push-smart-filters-ps that recen= tly expired. The draft involves the definition of a YANG data model that = allows to define more advanced filters than the ones defined with YANG-Push= , specifically filters that can take into account values of data nodes as w= ell as state. This allows to define filters for thresholds, recent high-wa= ter marks, and more. It is also a building block for network automation, p= roviding the event portion for many types of Event-Condition-Action-based c= ontrol loops. The draft at this point contains little more than the motiva= tion and problem statement; the actual YANG data model is still to be defin= ed; however, we felt it would be good to have a placeholder posted so we ca= n have discussions in Montreal. --- Alex (on behalf of coauthors: Eric, Xiufeng, Igor, Tianran, Walker, Hen= k) --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Netmod Working Group,

 

we have just submitted a new draft on Smart Filters = for Push Updates: https://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-00<= /a> 

 

This draft supersedes  draft-clemm-netconf-push= -smart-filters-ps that recently expired.  The draft involves the defin= ition of  a YANG data model that allows to define more advanced filter= s than the ones defined with YANG-Push, specifically filters that can take into account values of data nodes as well as state.&= nbsp; This allows to define filters for thresholds, recent high-water marks= , and more.  It is also a building block for network automation, provi= ding the event portion for many types of Event-Condition-Action-based control loops.  The draft at this point contains little more than the= motivation and problem statement; the actual YANG data model is still to b= e defined; however, we felt it would be good to have a placeholder posted s= o we can have discussions in Montreal. 

 

--- Alex (on behalf of coauthors: Eric, Xiufeng, Igo= r, Tianran, Walker, Henk)

 

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03sjceml521mbxchi_-- From nobody Tue Jul 3 08:55:14 2018 Return-Path: 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 5AE52130EE5 for ; Tue, 3 Jul 2018 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y5cYHxXW; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=cOovhmIo 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 WyPErDk2ZusO for ; Tue, 3 Jul 2018 08:55:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E8078130EAC for ; Tue, 3 Jul 2018 08:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530633295; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=meFr/Jm2yR3xkITbyp+TQKo58ivy8cVTtxyBVY6HdYE=; b=Y5cYHxXW3M/C+j5s6uTO3Kt7VHv6X4YJtyRDttwaE+fKNcPot/py7v1oXNTe86Of CSgftk5Q4dRyD2/JpvHUMuhbBtJZ+fAyq5EMHCDKq1b4pHH5kIup3HfuBVuzsXOy 3dYR7Kpd5Hl8x7AsIltNjeFfNs0CwBGO7d9JoKoqm60=; X-AuditID: c1b4fb25-e23ff70000006310-33-5b3b9c4feaad Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.32.25360.F4C9B3B5; Tue, 3 Jul 2018 17:54:55 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 3 Jul 2018 17:53:52 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 3 Jul 2018 17:53:52 +0200 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=nZ+onZ54lm9zvoVsSdp0MKl6VDkluWQaXqFxmEuUHnM=; b=cOovhmIo3yWvIKLWwqxyv6kDBED2CKoH0iVnKplwHiWS/BURXE5+CrmEAdx0vS61b8wnr+ecoa/YC4EcBIC284CjqjFGWQNUeujFfEnGHCmeDRse/RdJBOdjYzFUkqjRm9jDCOeKJqHpyQh06R3Knpi5x4hMjAz3eCx9GsKpWfU= Received: from [159.107.197.27] (89.135.192.225) by DB3PR07MB0492.eurprd07.prod.outlook.com (2a01:111:e400:942f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.17; Tue, 3 Jul 2018 15:53:51 +0000 To: Alexander Clemm , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03@sjceml521-mbx.china.huawei.com> From: Balazs Lengyel Message-ID: <177d14fe-a3db-41d9-ae05-3d7bb5e109ea@ericsson.com> Date: Tue, 3 Jul 2018 17:53:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03@sjceml521-mbx.china.huawei.com> Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: AM6PR0202CA0014.eurprd02.prod.outlook.com (2603:10a6:209:15::27) To DB3PR07MB0492.eurprd07.prod.outlook.com (2a01:111:e400:942f::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 96ce2dc9-2fb7-42ad-8cf0-08d5e0fd2c37 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DB3PR07MB0492; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0492; 3:SgOeEdEptpyUXkNycGdkpzg4Sh5MrEgvveFYdP574RuvwD94DsN73rc/wMHNswHGSQG4qDvFPIctEdqIoz1TvQlW272Y8/NOg3iEQGHgwidIcnxuCqyqBvAn/CAm6tDPOifEKZbKxulunn6dgjQZD8Y9wJ8k2lYsol+G6Nr7ZE8MRzF5o5zdRvfU9kIOAOfaJZbfpjdn4vf1r51zbeKozWZ9fKuQ1qLqE/Rw/pWUAM2cnDeUwudR/kyO4qDRCL7R; 25:+2higI1GB3Fvyi8DdR2sJfazfDSXsk67LFJP3gw1/U0nnQRp4of9pwQiau8yjuKJ26KlT13MRfJsnf7o4OBaDjvOM5Gso+OXJIfG9pvilpy4kBQZz6eieLvv+95iZzaeqCnXT7Xrwx+Q5JT6S4stjL5torSJ+zF8J9nufFRz8UPVkYqtR2pglMLrlZ5+x59T+o32AETwvpmO2umr/KBIGCc1raCtIlJACSHVzUvD0jBAoiPC8Hg8PRN4k8nCsu1NB+Fw4LNCwCh56TtFAQ4EceIuGKiQu2nxQWypJMUIOeU3omHvrM2NxCBYL5Uppxf9uWY/ZWiFquf9fUZ3nVTVYQ==; 31:trlw2LWLf8gobxrcCxxOwl4tjm21jmz6oX7oYjxrKaYfduIpjrwjqb7N1g14nxq8TLktzB6DqEVkud2PjKNiVob6bCGs5l3UTtsGDq5tTFdAiZOKckHSu85LHnfKHP96RlR4iahvLdtoItaUHYY0j7RmqvYaeS3uOF6NR63lQdmf+Sz23cHfpokVpBeZGW5uhS/k6x1aytiTfenyLCnzjJmj+/booGC713ak/3K1A0k= X-MS-TrafficTypeDiagnostic: DB3PR07MB0492: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0492; 20:wGsEavfJaz0qtU+yAwd+UHQ9zBgPC+/JLQjHXN5uH5YwOuy5pApcguHZzvhd6mBpGsHhohy/Ac+KGWr5NsbcyiH7qLr2In+WpLUab/aZlb3hFg5XWSo2zMovaPOTbJuFDoOQIIC6tLaEXFkx3AHejOXWaf4EdKHMWDAgQzofN0oojunvDedcwAM7N5qL7cMJlijjMeESgFrzR5fbSoyR4+EM4ADAhs7PDkGjLqgNFGcnhlscZFtFLW8XoHSJB6Qa9mIwRxpgo3tzTwZsAQhnb1wSv2VqkGnYDY0URjthR0wiLEj7UZw2NZqEWSY0oNQ0TGWv+WNm8PYsGxgAjXfRky8owLq8kZG47mP/r5vm186XwZmP0jXhJeO4EjC/GXHNbzwXRoA458bWVgnfXZB2kqsq+65gwj1kvN5r46xxInndf9oiRpZazAa1ZdYp1X+4j2GkK1Trk3rlfg3ZEHt/cLaFcuTio36bklpawDwQlSkzcqGMgmRRjqQ2SMw+5Eph; 4:wcpFhfTES0ybUAl0O5QFFx45Fs+Z0ZwJsd0/3Kb6fAgXwXonpxuKELMElBDHKh/A8XLScix39fiSC2EvbO110pbTJed6CKHPnz7N7/VWRd/M3q646wpEsQhmAuCBz4bxZxyldi2yhJOg5aL1jTR4C34hBZ3cgcXAbYIFIgDp5/q69QzoMSH37eaYjNhH5dCR/B1Ii3sRgg8PJrbX3ogXNir+LPXb9CJRjoMh2REy9YAi7a6awnrAJOE4liIhKUbCA+hCSYZCPpI1UGy2wxsJfXbGKqd9JKWcpwoC2Egy/uB2qfZ6DInvAyqpj/h0yWJ9ID/CO4HS0qqCB7x+eZSfTLYPfeXN0DLfOlaWypMOwbc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(50582790962513); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231280)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DB3PR07MB0492; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0492; X-Forefront-PRVS: 0722981D2A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(366004)(346002)(136003)(39860400002)(396003)(189003)(199004)(252514010)(316002)(68736007)(6486002)(106356001)(58126008)(110136005)(16576012)(54896002)(6306002)(36756003)(14444005)(229853002)(6666003)(53936002)(31686004)(105586002)(2870700001)(2906002)(4326008)(65826007)(16526019)(97736004)(5660300001)(6246003)(23746002)(64126003)(50466002)(8936002)(76176011)(8676002)(7736002)(2616005)(956004)(446003)(486006)(476003)(66066001)(81166006)(6116002)(65956001)(23846002)(3846002)(31696002)(790700001)(81156014)(44832011)(52116002)(53546011)(386003)(26005)(25786009)(49976009)(236005)(186003)(606006)(65806001)(11346002)(2501003)(86362001)(478600001)(966005)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB0492; H:[159.107.197.27]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB3PR07MB0492; 23:kuU4jSS31uSqzR9OQrP0kq4o1zq4T4ytzY3ts?= =?Windows-1252?Q?Ov6CCWS+9aE6+3/k085owW1X60DqRmSLvIPze8x+LgKz4WnK6zbj8BoV?= =?Windows-1252?Q?94ooMqwBWBSLqnWbzNzx3IK9dWuVtPjuTKDiAfx9r0h32vZfkdT86UCn?= =?Windows-1252?Q?Zhdb+wBH46XcxCqHe42XWP7cUDvOw+TPh5KyK6gWSYjeGqrvSnMiFo4c?= =?Windows-1252?Q?+WTCIwpoMaQedh4X0VVMxc1zjfEIQ9HXt8ldKg/+8zSQe9nrsexnf2qS?= =?Windows-1252?Q?ioFCAX9xeSi+dSapntlZpSuM8GwLpO+NY3ZP97LNCXjNQN3gz7M+RdFi?= =?Windows-1252?Q?Sfw2MvGwjH2Iu37L6DQ2RR4ZjfPcHN90TO3dKkLdRGne93J/P8tycBMK?= =?Windows-1252?Q?w6OamkD+wDx2SKZnX0K6yuJfuZRNYADXIS7FzlBrTRufP4bzp+ZCW/Xz?= =?Windows-1252?Q?do35zK6cw+l96/64cORRxXR8X3yzalFJNB/tcczvPnOmP2oqZ0hMaxXf?= =?Windows-1252?Q?RR4upaR58IZ7OxaLOfVyLKLIp8TK+nKqONpZQXIZyG1iSqqfbC3kS5HT?= =?Windows-1252?Q?1RLusN8ZSAPF1hga4c6Y+IZ+4nfx56YTXCJDG7Bn9EpY/cIBbzOEsUT5?= =?Windows-1252?Q?5A6OO2/GMLZ8PxsJMGR1fQfXJxgwQDyS7Ma1PhNxYBXWgR4tVRVNeiwY?= =?Windows-1252?Q?b4c0Qw6IJYEPNaMA/MN5qUc5YDrXXt1SwFqoTMs6yGB11I7oT7AwkMTN?= =?Windows-1252?Q?XYqWDwCxOmUEDMmhNTT3wjI4c6xZamxy+BsMXHAfTnB7MY26bjakx3uK?= =?Windows-1252?Q?iFyFj+P3+geXor/BFAf7+zfkwO6weBaq1vm6Mu1X7rTACiBwux6LCWme?= =?Windows-1252?Q?jcfnOcZjJ0QSRf4GVEU0Mivb9m8zP52N3oIPg3EAL8xD5+wy2omOzUFl?= =?Windows-1252?Q?8OdeaLaJMHtqi1oEfGOr1Qiv0vie5guiRGZK79AzLb00HzPHjKIS1JZc?= =?Windows-1252?Q?NWUabcvloCEeH1SEIObpIDcx9Ej0+jY5+0hWkZKYLggjTJgyORGrfPDy?= =?Windows-1252?Q?js8tJDN6sJidOpXSqyhJTyid9ltDqQWxDWS6woCRnOhK8YQk8sHOB16m?= =?Windows-1252?Q?5R4XFFg2y3/ERqkb5Rjt4id3ugu8JDABS0qHFmJV7rCkg4gcpKmVtPfG?= =?Windows-1252?Q?2jRJ+W8rpQVxgIEo4O7QzoO7NLsUWhCxzxfbHJgmnrX/KyX8ooSYxtph?= =?Windows-1252?Q?FkUAu/XjjOWJxsz9IFATYqUnrUIzYAeuD7jCyoSfct3dJp6eUdzamhYe?= =?Windows-1252?Q?AhhrTBXZChT6lGlOt+kHq5DCsoehgNNQ/g21A1lM6Rapb3MSPqmRCFkb?= =?Windows-1252?Q?OWNstyIk+EXanXyHXoEDt7tn6O7sQzpVHU4iUkboOEmxa/ND6hCG3UlF?= =?Windows-1252?Q?cOMchA8MhC0c2pWfGuKZmjngXxTtep2yDxYTB8u5St3vMUxA7rSBvqqX?= =?Windows-1252?Q?FQKb+7n3XXdJ2ZXt/xnkKRta3GHMx/E+axePQMr/Ngv3DZm/dFEa4CiT?= =?Windows-1252?Q?kkKAkSTCtBzsCp2rTGdk8YiYCkqfhleIrmp+wKO7cLfrjNsHm3TDukZY?= =?Windows-1252?Q?nKUPiGEdUVLvGAUOxlarnackzuRzQbc5/MrZvJncSKrvRa2pELe9z3Rk?= =?Windows-1252?Q?YUdecN3Mg=3D=3D?= X-Microsoft-Antispam-Message-Info: jDf2AKaI4k6rIytEcDI3NHDBw7smoUzciyLueWirbI+eb3Oj51AGiBkx6Y4ACY5Aj+2pZQ/EhyZyz1qoQ8Yo/g5iVfdTUsTQs1J4tAxyZzeck608aQaJMSr7pk4BoY9PHm9cixpY+IK6iShw48mlIyIuyQeU94Sowlr3p+CcM2ZG4/07q8XCWQR2/HZmm+UpAOtyxyxL6y/KR8v0oHd+6jEwjsVE+6IJ8FZ3XV+pXFbbxKg5WNaRWxEO2YeyhGgYBTejZ3AUmLQRNyy/oTsqwwMi6ti50Kfy7Z27BgzszWmdEl0JH8nlZp++/RsVSkHHWQJwrILmb3Sifc9sdZJBbHGkr6XRrr7D7vLAdv+7ysU= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0492; 6:OXUCdymvJGEIkjUvUrt1Jz6a2VcrM7hEoVOQsGA+flJEoFekXbqA7yg8BpoiFmWpUUa+4VVbz6gTr6Q256xsfK7aYP2OKEBEnLoFHsHE2/zxnM7EOI+G4JNQpn3B7yoDpQp/JBwReqyBAFsMq1e6ryOnX8ClTfg2d70weUTS1wn/eJpbyMgWggISOzM+sTqtEN4E7X2+7TruVfqRUAaR4ypqwZBg7mZaNYYiBfcL0EBSdftxivNymNMKpLCVONH3F2OWLQy2UolNNUQr9dV9VTLrr294K459gde23dKQ74yzbAVA+TpC0fzQC5OVLbEpVAcZwa9mGGr1vJ/r0XFO2Y1z/e2ynsIopduIYgzZ3j1aNjvd0c/puAspCAEneaAOd6RK3dZ8qImX3BwEp/c8l8hcv0l/sBUF0fVxHtKu4r9UUGUTF9JtquqYpuLb3ia+VqyB31rDXcuDhdqDVMx9fw==; 5:Ose0gfm67nrOmb/oG1kpz3qSjDHvNi9kwzIXEBFdTcy5qpMh9lIOJiv+H3bCJZbN7JN1pXEVxiRnFzLznEX+YM8/PHQbxC3bTPF0KbY53VaM3175DDcPmO/C0UeX02pICn3ZqaXkaZwFuLdyjh6CPAYtFj+VKswioXWOU5t9a/A=; 24:bdyQd4YAaWbPcIhDOJyyQ29L5sQtIXdgt9o1Gy/qIuBDZX6n0C/fCxdTPnNHqc+tu4FpFwGNj+hBtjpiMP9Hg6wMIiCrramERfcEWefPOXo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB0492; 7:lBDvAGXJfyU0JB9zMxTQlQjbbN1RUXy2DWRk9dy97JOea/KcKhXy8tz9z38PQsWl2YkGOPsc3kdvJx0LoPLIasc4UqGQ3THTDxeHDsOmOTiT2v4rEaJIveBVuuFXtAP4oDyrXrzU3h5ijzU11ADRiu8ZSKbW9TJPGJKdcBQM/bmlVMzH6z7qRl9hw1Ku3q10kUN0mCfsdePaxd+THExvAKkfNAwoSs9Av9VFuxGs4R5WJb3urKT1auEgS7Bf8hV3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2018 15:53:51.3507 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 96ce2dc9-2fb7-42ad-8cf0-08d5e0fd2c37 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0492 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe8/FnQ1Hp6X4sGrSyBLBa4mi0eXbyDmTbubCWnlQcW6ysywL Q0uybQwnmOmcaW5E6UhSm/ZBwuE0DS/TQjTQBOuDOCvQUiTI7RTs2+/P+3senj+8FC4ykmKq SKNndBqVWhoiIJpy+m7FZtnSlQmrC6Gp71cdRGqn+XBqq7eKPIXLqod8pMzh2MLOYrmC4/mM uqiM0cWfuCYoHHDX4KWW6Nu93nOVyBppRHwK6GNgeNSAjEhAiWgPgqF3TpILGwjGfk8RXLBj 0OfqxvyBoC04jM62/NMeYnB/dA33L9tLJ4JrZJHwcxh9CQY8/aSfcToZOno+Y34W0RegfvI7 8nMInQSPaycDvpA+CV0Oe4AJ+hA82V4IOOH0Feh8PcPjnD0w2rQccPj0RaizmnFufyy0u17w OI6A+eVWjONIePCmGeeKSmF6vSFQB+hmBPUrBpw7KBqWpv6QnHQAPOM2guNMMK34h/0DUwhG 5rcxLlTywPvqC8ZZMWAzGQOnIjoP3jqfkZzk4IHPPbYzTu2EYni5LuH8MzC3OMfjWAJj5gnM ghKsQe2sQY2sQY2sQY3aENGBwlmGvV5SkHQ0jtEV3WBZrSZOw+i70c4PGezdjupHM6un3Yim kDRU2HU3XSkiVWVseYkbAYVLw4SuqDSlSJivKr/D6LRXdTfVDOtG+yhCGiFcSunJFdEFKj1T zDCljO7/K0bxxZXIRC4+tRICw89v0+Oz2mRyUy6O1SsOyoxrKe1mk9kiXqnIMFfUGd3N0Zk5 Rxo/1Tg/YKC2ddqZ3dk+hbfGOZgmn0Ef72n3/6h6zu/3KIS+5fN2ecsuw4KktOAXNVy95f1q VnY1xpMZsrzhCcV8du3WRtvlzd6sZEm9fEJKsIWqxBhcx6r+AsWKuYwdAwAA Archived-At: Subject: Re: [netmod] Smart filters for YANG-Push X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 15:55:13 -0000

Hello,

You should make the new filter types separate chapters, to make them more visible.

threshold crossing alert:

  • I would rather say you have a single filter with a raise and clear condition. You never really want a threshold filter without a paired clear filter
  • this should be connected to an alarm based on draft-ietf-ccamp-alarm-module. You should have the possibility of raising an alarm when the threshold is passed.
  • the term counter filter is confusing as it invokes the idea of a gauge (a filter based on counting something) instead of a reverse filter
  • mention that smart filters will obviously place a load on the server. Can they be rejected/suspended/resumed like a subscription.

regards Balazs


On 7/3/2018 1:37 AM, Alexander Clemm wrote:

Hello Netmod Working Group,

 

we have just submitted a new draft on Smart Filters for Push Updates: https://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-00 

 

This draft supersedes  draft-clemm-netconf-push-smart-filters-ps that recently expired.  The draft involves the definition of  a YANG data model that allows to define more advanced filters than the ones defined with YANG-Push, specifically filters that can take into account values of data nodes as well as state.  This allows to define filters for thresholds, recent high-water marks, and more.  It is also a building block for network automation, providing the event portion for many types of Event-Condition-Action-based control loops.  The draft at this point contains little more than the motivation and problem statement; the actual YANG data model is still to be defined; however, we felt it would be good to have a placeholder posted so we can have discussions in Montreal. 

 

--- Alex (on behalf of coauthors: Eric, Xiufeng, Igor, Tianran, Walker, Henk)

 



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Jul 3 09:01:59 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB3130F17; Tue, 3 Jul 2018 09:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361339.4893.11718983655685464051.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:13 -0700 Archived-At: Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 102 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:21 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (2:00 requested) Tuesday, 17 July 2018, Afternoon Session I 1330-1530 Room Name: Place du Canada size: 300 --------------------------------------------- netmod Session 2 (1:30 requested) Friday, 20 July 2018, Morning Session I 0930-1130 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/netmod.ics Request Information: --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf Second Priority: teas i2rs anima rtgwg Third Priority: saag People who must be present: Lou Berger Joel Jaeggli Benoit Claise Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 14:13:09 2018 Return-Path: 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 66B2D130F82; Tue, 3 Jul 2018 14:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 9q-dwO2BnHbM; Tue, 3 Jul 2018 14:12:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 9E49D13109B; Tue, 3 Jul 2018 14:12:46 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 32D5DC6458B42; Tue, 3 Jul 2018 22:12:42 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 3 Jul 2018 22:12:44 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0382.000; Tue, 3 Jul 2018 14:12:40 -0700 From: Alexander Clemm To: Balazs Lengyel , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: [netmod] Smart filters for YANG-Push Thread-Index: AdQSXGYSlkIq0ljnSr2PXfacfcR+7AAxEy0AAAPwnlA= Date: Tue, 3 Jul 2018 21:12:39 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB1D391@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB1CE03@sjceml521-mbx.china.huawei.com> <177d14fe-a3db-41d9-ae05-3d7bb5e109ea@ericsson.com> In-Reply-To: <177d14fe-a3db-41d9-ae05-3d7bb5e109ea@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.0] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1D391sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Smart filters for YANG-Push X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 21:13:06 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1D391sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, thank you for your suggestion! Brief responses inline. --- Alex From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] Sent: Tuesday, July 03, 2018 8:54 AM To: Alexander Clemm ; netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: Re: [netmod] Smart filters for YANG-Push Hello, You should make the new filter types separate chapters, to make them more v= isible. threshold crossing alert: * I would rather say you have a single filter with a raise and clear co= ndition. You never really want a threshold filter without a paired clear fi= lter Agree on TCA needing to have both threshold and hysteresis threshold= . * this should be connected to an alarm based on draft-ietf-ccamp-alarm-= module. You should have the possibility of raising an alarm when the thresh= old is passed. Need to check it out * the term counter filter is confusing as it invokes the idea of a gaug= e (a filter based on counting something) instead of a reverse filter Actually, this is a miswording. What was meant is not a filter on c= ounters, but a second filter to alternate with the first, analogous to thre= shold crossing alerts (with hysteresis, or "counter" threshold). Will need= to rephrase this to clarify. * mention that smart filters will obviously place a load on the server.= Can they be rejected/suspended/resumed like a subscription. Yes, load is a valid concern, this is also mentioned in the security= concerns. Haven't thought about whether suspend/resume makes sense; the a= bility to reject, yes certainly, and should be mentioned. Thanks! regards Balazs On 7/3/2018 1:37 AM, Alexander Clemm wrote: Hello Netmod Working Group, we have just submitted a new draft on Smart Filters for Push Updates: https= ://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-00 This draft supersedes draft-clemm-netconf-push-smart-filters-ps that recen= tly expired. The draft involves the definition of a YANG data model that = allows to define more advanced filters than the ones defined with YANG-Push= , specifically filters that can take into account values of data nodes as w= ell as state. This allows to define filters for thresholds, recent high-wa= ter marks, and more. It is also a building block for network automation, p= roviding the event portion for many types of Event-Condition-Action-based c= ontrol loops. The draft at this point contains little more than the motiva= tion and problem statement; the actual YANG data model is still to be defin= ed; however, we felt it would be good to have a placeholder posted so we ca= n have discussions in Montreal. --- Alex (on behalf of coauthors: Eric, Xiufeng, Igor, Tianran, Walker, Hen= k) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1D391sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Balazs,<= /span>

 

thank you for your sug= gestion!  Brief responses inline.

 

--- Alex

 

From:= Balazs Lengyel [mailto:balazs.lengyel@eri= csson.com]
Sent: Tuesday, July 03, 2018 8:54 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; netmod@ietf.= org
Cc: netmod-chairs@ietf.org
Subject: Re: [netmod] Smart filters for YANG-Push<= /p>

 

Hello,

You should make the new filter types separate chapters, to make them mor= e visible.

threshold crossing alert:

  • I would rather say you have a single filter with a raise and clear conditio= n. You never really want a threshold filter without a paired clear filter

<ALEX> Agree on TCA needing to= have both threshold and hysteresis threshold.  </ALEX>

  • this should be connected to an alarm based on draft-ietf-ccamp-alarm-module= . You should have the possibility of raising an alarm when the threshold is= passed.

<ALEX> Need to check it out &l= t;/ALEX>

  • the term counter filter is confusing as it invokes the idea of a gauge (a f= ilter based on counting something) instead of a reverse filter

<ALEX> Actually, this is a mis= wording.  What was meant is not a filter on counters, but a second fil= ter to alternate with the first, analogous to threshold crossing alerts (with hysteresis, or “counter” threshold).&nbs= p; Will need to rephrase this to clarify.  <ALEX>

  • mention that smart filters will obviously place a load on the server. Can t= hey be rejected/suspended/resumed like a subscription.

<ALEX> Yes, load is a valid co= ncern, this is also mentioned in the security concerns.  Haven’t= thought about whether suspend/resume makes sense; the ability to reject, yes certainly, and should be mentioned.  Thanks!

</ALEX>

 

regards Balazs

 

On 7/3/2018 1:37 AM, Alexander Clemm wrote:

Hello Netmod Working Group,

 

we have just submitted a new draft on Smart Filters = for Push Updates: https://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-00<= /a> 

 

This draft supersedes  draft-clemm-netconf-push= -smart-filters-ps that recently expired.  The draft involves the defin= ition of  a YANG data model that allows to define more advanced filter= s than the ones defined with YANG-Push, specifically filters that can take into account values of data nodes as well as state.&= nbsp; This allows to define filters for thresholds, recent high-water marks= , and more.  It is also a building block for network automation, provi= ding the event portion for many types of Event-Condition-Action-based control loops.  The draft at this point contains little more than the= motivation and problem statement; the actual YANG data model is still to b= e defined; however, we felt it would be good to have a placeholder posted s= o we can have discussions in Montreal. 

 

--- Alex (on behalf of coauthors: Eric, Xiufeng, Igo= r, Tianran, Walker, Henk)

 




_______________________________________________
netmod mailing list
netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod





-- 
Balazs Lengyel         &n=
bsp;            =
; Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909       &=
nbsp;      email: Balazs.Lengyel@ericsson.com
--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB1D391sjceml521mbxchi_-- From nobody Tue Jul 3 16:59:59 2018 Return-Path: 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 F30D51271FF; Tue, 3 Jul 2018 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 BtabOMaZdnyS; Tue, 3 Jul 2018 16:59:54 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700061.outbound.protection.outlook.com [40.107.70.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E32F130DFA; Tue, 3 Jul 2018 16:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uz42xky2pFaupPXiWryhaEe/N/VR0OnAff6AvPWDhwc=; b=XPQX4FBO56libQcl8UTowxG9b370K4PHr+4xVSH/f0ExQjndTSihKj+AnXCN8Jc9DD6J33yyn39G1AFlLKx0khHAr4fa8QsWzyPtSYn18weed61tZoOVFGeGY3kP32K0ZTmJJ2g/pKFPNSzCOfxcvKvqsmhXwRCFB7+S4NG4aAM= Received: from MWHPR08CA0047.namprd08.prod.outlook.com (2603:10b6:300:c0::21) by BLUPR08MB712.namprd08.prod.outlook.com (2a01:111:e400:88b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.25; Tue, 3 Jul 2018 23:59:51 +0000 Received: from CO1NAM03FT008.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::209) by MWHPR08CA0047.outlook.office365.com (2603:10b6:300:c0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.930.19 via Frontend Transport; Tue, 3 Jul 2018 23:59:50 +0000 Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.53 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.53; helo=mail-send.aviatnet.com; Received: from mail-send.aviatnet.com (192.147.115.53) by CO1NAM03FT008.mail.protection.outlook.com (10.152.80.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.906.15 via Frontend Transport; Tue, 3 Jul 2018 23:59:50 +0000 From: Alex Campbell To: "Wubo (lana)" , "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: EXTERNAL: Re: [netmod] New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt Thread-Index: AdQRz+j3reyaFMCgSeK3CKn0gITfawBUf1ts Date: Tue, 3 Jul 2018 23:59:49 +0000 Message-ID: <1530662388723.66460@Aviatnet.com> References: <520ECC8D9CA1724BA1CE492DF898F6A3318C07@DGGEMI526-MBX.china.huawei.com> In-Reply-To: <520ECC8D9CA1724BA1CE492DF898F6A3318C07@DGGEMI526-MBX.china.huawei.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.147.115.53; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(376002)(2980300002)(438002)(199004)(189003)(6306002)(6486002)(106002)(110136005)(6246003)(23696002)(36756003)(316002)(7596002)(14444005)(97876018)(47136003)(86362001)(36736006)(2906002)(6116002)(3846002)(2501003)(50466002)(47776003)(8676002)(246002)(2201001)(8936002)(356003)(7736002)(305945005)(7636002)(5660300001)(2616005)(476003)(478600001)(118246002)(72206003)(106466001)(436003)(6346003)(7696005)(76176011)(102836004)(26005)(336012)(186003)(53416004)(117636001)(25786009)(15650500001)(229853002)(53546011)(126002)(956004)(486006)(966005)(11346002)(48336001)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR08MB712; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT008; 1:up7XwnZmIRTt4DtqjJXktEUASxGs1GvcgrUrfbopR6nzN/zuUBOmZH2BST+CH1b6O7BdJcf/9qY5l8hmhxuh1IgZzXc6CRiChXkmF0wSrRads4Tjyp9GRVmDqFwjWVHK X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9cda84b3-161d-4f3f-09ef-08d5e141104b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BLUPR08MB712; X-Microsoft-Exchange-Diagnostics: 1; BLUPR08MB712; 3:xMEesmI6XFKJsA2irumpS++FohdRlnEEbruTZoSkxS29Kx1YgTBorCS56hoBEGy4L1XSxE5tYaw4kBz5r28NfloEbj5h1i2G68aRK5Ce2AaO1SsZf5ZAurafFyh4Xf3H4o7XCHJlFYCGdgMOF/HtwXyoAoY78EDPxq9LPmDAEVbYf13SDa2beoekQxyXIeh1dvkzOQ5w/a6SnKzNmaKl7pFXUaau2G7bjCgymAsfk7X36TEQ6FWCQYY3AQppldxaLn2EijYfL8f1+C1e8OCm0PzLPKFzbsfdfB/fJ5B4H1AJxjkWqFCNwvOp2iYVK/laozKiClr+BzcuvMG76rl2bnc3/YU3tep9Ct2nkNFWg+w=; 25:Hm5UQfYwTtXEKzBLvvmiYbpJYrmEc9OsqwcwJWQIi1h+YfP6bS+uzrIxOcf26UaD9dG9Jtam41nTNYuWrsHZx45XowrsoO/3skhbBxDYvpZt0P/W8ToJv2c7NvErJY+9059ts8VBmVADllgh7kZ0rkwDlPRZzlOrn8e+am5VgTWyTF3tL42sj2voOZQD1qaIRSfoX0q8NAHFB2YDVUBwNHydBIBraLC/f8VEMw/zWKFhya19bT8sNkJ15XwswHLe7Hj4NbB5rThPWboQm3YQH1YNF7LrbJ7+s4RSPE2iuup0oMzHpJYFzEF8EdSLVwP2gIPmwHZNb8j93/EHQA+96w== X-MS-TrafficTypeDiagnostic: BLUPR08MB712: X-Microsoft-Exchange-Diagnostics: 1; BLUPR08MB712; 31:IYJx5BYhNh/Fhbs776jOSy826hAxHjk80oFbHcLQwpKnKganI6LS2uCsAWAmwF4zwQnjmfWiJjM+iGfIOKuW55Wc4QRlvI8PLZYnT4l5wVvp8ROxg5VdnKLjo1ny3dy9ohD1k4XyoDX6fOsmoux9CnZLOCfp2nXaUoSgmyOG9+/pFMVaS0gQdc9K8H4w5SBwVj6WGcPpXEoBc7QUqNo7fJsctjxLT8N2Crnl2rfjUoE=; 20:VRP9nKNr6ziuNR/e7Bqwe0qEaewDdn5aSaUpjqzgIcsCwOmT3A4Qpt9KhnrrQ2z/mfRRciSmEbc8meCmVBi8UQoMDTBqcSnh2IRnv4E922Xk3e0vYHGMKg7CzSycQo9KJdgSeXPc+qiHrRFdBK4rCOj+z/X60K2PVpe1WMRiRO0DYIr9B9g0U6BmaMdxOLozm5mvreIbqUfAj/aK4+2RSHTLosU+9tVw+i2H3d9o/lY4G/m+l2cZiR+b0LiXebrMvMAG224IxqRN0qOqgwEfNqjv34UeYt+3CT8RUQLT7BswvtgI1FdvY4dNQ+as7P79ia3AmWhoGfQ73OBkEB12olB7s4mTGIXg0HC2BWg3BOOsAI4tNWdzfxJAf9dZIYeCoTt5G8bmi0qtyRc98JOvmjuKqskIn7KXyW4XzPd/Fck3V5cwJ38puWK5MjRxXjb1+kdOeLEvjxdj5Hu7IO4YHxPqSkkOkA65RnRaqVjpbgWLQaEDqZHrla68EUMwGU1k X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105)(50582790962513); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93004095)(3002001)(3231280)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BLUPR08MB712; BCL:0; PCL:0; RULEID:; SRVR:BLUPR08MB712; X-Microsoft-Exchange-Diagnostics: 1; BLUPR08MB712; 4:y9VaAt8spWR3LBf5ksvSyWHmzuMdQqZcyD0Zx0gSDOFK1Fnr9Yfj2mZ4zQ2Hp8fPra5CE0ajphVkZ6FSDgg8jHKSklgknGUbehiT8iuGHZtr/XQWb7Gm0kHlABQ/Cq4Dt/4E9cp5FghMYs0cxcdi4o73J+5pA/CxASwhp23sgPVqmgykm0ZogY5ifCAESFYgkR3yxT+CJGLM/T8Tro7j+TLrflHdZsoP8Aq6PmRzumTng//QTGvJJjL1OwtBWTvc/pp1kIhpt78u1/crxhbAcy+UuJRal6Y+vBxqmmEjARbpewWZcn3GWFbonQP6Otxv4k7cWv3p74o5B+RGxWW4XjgssKhkmTaeWqVWlhp/HkZMUBQxcFaIOXWaoVv64gV9 X-Forefront-PRVS: 0722981D2A X-Microsoft-Exchange-Diagnostics: =?gb2312?B?MTtCTFVQUjA4TUI3MTI7MjM6T0dUVFdwN3Z1dWlsaVVFRmV3VlpHVEVWK1RP?= =?gb2312?B?L1h0ZXpESDliTnd1THUwU3FxMW5UNlFjbkJjUThnMHR6d245a0FCS09JU1VE?= =?gb2312?B?U3NnMXUxRVBVTEVvTFNRZHNYZi85NHYzcWVFNUtnY0pDSzZNSytoYldGK09O?= =?gb2312?B?L0lQT29jS09zVjdIYmJaWmhYZjJrVDh2Sk9FT2VtYWV5OXFNQVlkYVVTNFVs?= =?gb2312?B?YW54VjdyZk9PWmFzMnhjM2JyUzNMWWJsSVdTYzdjYTQvSS9LNS9lTzZLZjBQ?= =?gb2312?B?V1kyN0h3RDMvSzFKUVJhbU0wV2ZCQ1kxV3pueU95Uy90MzVuQU9iTFM2d0N4?= =?gb2312?B?ay9zNklXOEhpUmMveEh2YXp5U0ZQa3NDV2w0MWNDQnVPRE4xcU0wWXluQ09V?= =?gb2312?B?TTBjVXk3b2tJMzdydzZtOUI0N2o3QWtzeThTQnZHclpCaXZqcEd3U2FDRG0x?= =?gb2312?B?Rzl5QkdOM0ZWbHQzQmVqdDArelZ3VEpvWm9hMkFNRDluSjhJRlFvOUEyZktt?= =?gb2312?B?UEFTanlZN1pIa0NlSXl1K3h2OU9FTEcwNGllVUo5T0svOHlhY3ZLY3h5NnZ6?= =?gb2312?B?aklxaVptVFhTN3JyQW8xMzNreTBGWSsxOXc4Q01sRXQ2dkwxcEdyZEd3c3NC?= =?gb2312?B?WDRDcWUxaFp5c3ZKcklvQWJZVE92UnFlZGtxMitud2ZvT0hWWis1ZXlaY1NB?= =?gb2312?B?VDdEa3p6cFlUSGgyUTNYRCtGeGRDZGxqOFF0SWNYM1hCL2tveXlRRlprUjBj?= =?gb2312?B?dDYxMmZlTCs4R0N3bWd6TVoyblc2WVQ3d1ZCZGlCcWJpa2hFWXgyK2JWZ1pO?= =?gb2312?B?RW8yVVYxRGxUbTkrVVFFeU44aHF6d2lqb3JIWmZKTW13b3R1SGUyVUp4ZVZy?= =?gb2312?B?aDVtMjRFc0JhZTBGQU5KSS90K1hsaWJoaGY1NkZDMWdraUIrR1ZPMW9BR1Uy?= =?gb2312?B?NGRTdloyajQxSnJ3Mm54RXJ0UEc4Y3dtK3FFTzh4azJCVWhmUHhjQWNidTRQ?= =?gb2312?B?dGkwT0I5ZHloRno3eVNPMWJzT1JQUzBrZXdSYnlvWTZXdFpDSGNiV1FNUExv?= =?gb2312?B?dDNFeXgvWFNieENLeDVnTlBTNlo3TDBvZndoQ1lpeGhXMHRrL0NaNFdwdVpj?= =?gb2312?B?Z053WVg3bDNRb1MxR3ZaZFVHemNVK29ESW91WldQYnNUODZ6NkVxNTFUV3Z5?= =?gb2312?B?UVNnZVBnYWpPZUlzYmxRMU43TEc2Y1lnUmZYQ2xSL3ZOUFFoTzNlVU9mMzVQ?= =?gb2312?B?Q0ozc0kxcWpwbkRFNFRudVRzenYxZkp2NjZwN3BVeEd5dmZHRXZFVkZDQ3Yr?= =?gb2312?B?TUtjcXhZdG9ZL05COUpWUlVxbzNwQ0pRSFAybTBINS9GeXF1TjdZS1YycDI5?= =?gb2312?B?OW13dm5uTWFLTkY4NjljeU1HRW5WdkU3bHUwbU50aldCV29WZmxxM0tYVzc5?= =?gb2312?B?ME8zcEd3M3VDM3VnSCtpYWw4K0EySFNxWjVIQi9RVENqby85Z1gxL2hJSDdX?= =?gb2312?B?RDV2WmtqcmkyVDVNR3hsTER2N29PdG1WeHRWTURVK1BLVm1KckxyYWovcGhR?= =?gb2312?B?bEpFRStQdDJ4bkVzdnpvY0JpQ3BvWU9XcWpka0ZHWE9pL0tsMkFzRWFEc0lP?= =?gb2312?B?SWhHZHlPYXlVRzBPZkQ2elFVSE90U1B3WjdLR2cvUzhjZ3FoM3pCUWViZE9I?= =?gb2312?B?Y1VrdHNna1dLdHlWR09xbGhIOGcvUDRrR3VQWGRxZUJpZHRNL0dyWGhaRXMx?= =?gb2312?B?N3pKb0txMVdVMGV3b1NPQlJCNVI0NlZHY0g1TjJlUGRTenE3RjlHQUJtT2lu?= =?gb2312?B?ZXRBaklUWVhrZjdub0dqdXlQRDZvTjVnL05mQ2w2WkkwYXNzVzlKUVZhdVZv?= =?gb2312?Q?pTNis70lB6ZKZlu26HfVwyEuzgVnzUn?= X-Microsoft-Antispam-Message-Info: g1vEnXugv/iqbzKs8nSi/9kktl090/sF1i00wwXLDC31zdo68Rsv+jzWeVFGBgksvSlg7uKzVUNBp3+yQsuu+g5C2VL5cizZDAYhRDChT4JZIyXdnB2DkZJDT1c8vav42edF7zq869nvA1v6OKy7kbI3Jm+K5pN2fPm8hCgXdgbG/XmAd7cZ6NXi5JLFoYTca1PsflrI5+Hm4ora1Tq/GyjVg5qi4eN2LjH6LgjBquALDTVP7JYjzGSx1tmnRrwTVK25W4OqeANvX7EEX4s4xiOz4vQ1pKwGD0MkqSCq9VQeeJJ1D2F0KPv74NvKWwukSf2KrzbUrlq0Pl3qSi+jN1SOpiRewK06bT+CiJq91Zs= X-Microsoft-Exchange-Diagnostics: 1; BLUPR08MB712; 6:Yhca/MB8r+hR76XO37R28JftOj2O1qfXiaQEeY5NN3UZsLFXrqMHm4/IsE20x78Ijpv5yMgIJF12hXkJce0jBegl7lHpl49qhrpVXVSJ/mji5E3lfG1dRUk9gOKLOgvsJLSakdicpTRvH/Q2frteKrBrdiv4QE3JvFXVEyGdtFRH5KpizJNi1m9X/CQSmIEj9LL7hpJfJBGUY/h/tU+BoQwaGzQ1S8uIvzBzuMm7VN/MRvMsdSvqUlWuvmAxe9OAkB6ycBaHzoceVtq2dqtPbaY3O8XanOV1BGvkizYd1QBisQ5sSqyVHYXeohKNxhIFeWbtlkMu+W2L/YOfBB3e9OVvh8hwlfk+iIS++Rka5HuREXYdUchNKNC/m2wc5V7lWbPYEyGiY6Qu6dkPl7aOrTz32PrIb6Gw63gpcZWA/2zcI1vtWVAMifKseQRlVPj05DC0axLJ9Y5zopJ7c+pM8w==; 5:V319obc7QD7+XLMGv0b26m3sk5XNshEG7s33+NUmeMfdxocleaeBrY6Kxa0xT5JGGyApopueEzL6MD5BH5YKRVl1nkzepcXQM8Pku+yNXyj6idgH7oCSWM+JISTedc45kJbHjekwzbt74OKY28cdvBpmYM5B87tcaGkEV7b2pMk=; 24:Hfp1kfpjXE10A64Kx9ERlfs09lqBt8RsvDCcOdum9nOiG16wFJ6RTXm1FJJ0mWC6L9+ggg4Zn3YS955kJPehs2svDgQI0I/1/HDyPOWPo7o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR08MB712; 7:FIeslfOPMgzyvC3u7OW1ot2/31jVh7i4FijAPPub/2bl9irhQhcpfnvgCkb6oeHQssfkq/3K5CDFmniJJIlUUjLmdcrvGKT7Z8YfS2Kc1QoGddVT+jEOZYXjJRCLxlBVSldX/H2+Zzc4cb7A+CeXj6LLGboAhclDl5t0eU9Jl5F/YEUHdBaFIgBjNbAQbRu0cK5xksV2TAbFZ/r1n2poiy91jpYN+mDAKuJU89sZxJ5JFbGyGYD4XKaBOynZUNyl X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2018 23:59:50.4020 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9cda84b3-161d-4f3f-09ef-08d5e141104b X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.53]; Helo=[mail-send.aviatnet.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR08MB712 Archived-At: Subject: Re: [netmod] EXTERNAL: Re: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 23:59:59 -0000 SGkgQm8sCgpNeSBjb21tZW50czogKGlnbm9yaW5nIHNpbXBsZSB0eXBvcyBhbmQgcGxhY2Vob2xk ZXIgdmFsdWVzIGFzIHRoaXMgaXMgYSBmaXJzdCBkcmFmdCkKCiogV2hhdCBpcyBhIFRBQ0FDUysg dGVtcGxhdGU/IFRvIG15IGtub3dsZWRnZSB0aGlzIGlzIG5vdCBhIHN0YW5kYXJkIGNvbmNlcHQu IFRoZSB3b3JkICJ0ZW1wbGF0ZSIgZG9lcyBub3QgYXBwZWFyIGluIGRyYWZ0LWlldGYtb3BzYXdn LXRhY2Fjcy0xMC4KKiBXaGF0IGlzIGEgZG9tYWluIG5hbWUsIGluIHRoZSBjb250ZXh0IG9mIHVz ZXJuYW1lcz8gImRvbWFpbiIgYWxzbyBkb2VzIG5vdCBhcHBlYXIgaW4gZHJhZnQtaWV0Zi1vcHNh d2ctdGFjYWNzLTEwLgoqIEkgZG9uJ3QgdGhpbmsgaXB2NC1hZGRyZXNzLW5vLXpvbmUgc2hvdWxk IGJlIHVzZWQgYnkgZGVmYXVsdCwgdW5sZXNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gdG8gcHJv aGliaXQgdGhlIHVzZSBvZiB6b25lcy4KICBTeXN0ZW1zIHRoYXQgZG8gbm90IGltcGxlbWVudCB6 b25lcyBjYW4gcmVqZWN0IGFkZHJlc3NlcyBjb250YWluaW5nIHpvbmVzOyBidXQgc29tZSBzeXN0 ZW1zIG1heSByZXF1aXJlIHpvbmVzLgoqIFRoaXMgbW9kdWxlIHNlZW1zIHRvIGltcGx5IGEgcGFy dGljdWxhciBzZXJ2ZXIgc2VsZWN0aW9uIGFsZ29yaXRobSAod2l0aCB0aGUgdXNlIG9mIHByaW1h cnkvc2Vjb25kYXJ5IGFuZCBjdXJyZW50IHNlcnZlcnMpLiBXaGF0IGlzIHRoZSBhbGdvcml0aG0/ CiAgT3VyIFRBQ0FDUysgY29kZSBkb2VzIG5vdCBoYXZlIGEgY29uY2VwdCBvZiBhIHByaW1hcnks IHNlY29uZGFyeSBvciBjdXJyZW50IHNlcnZlci4gSXQgaGFzIGEgcHJpb3JpdGl6ZWQgbGlzdCBv ZiBzZXJ2ZXJzLCBhbmQgdHJpZXMgZWFjaCByZXF1ZXN0IHRvd2FyZHMgZWFjaCBzZXJ2ZXIgaW4g dHVybiB1bnRpbCBpdCByZWNlaXZlcyBhIHBhc3Mgb3IgZmFpbCByZXNwb25zZSAoYXMgb3Bwb3Nl ZCB0byBhbiBlcnJvcikuIFRoZSBhc3N1bXB0aW9uIGluIHRoaXMgZGVzaWduIGlzIHRoYXQgc2Vy dmVycyBhcmUgdXAgbW9zdCBvZiB0aGUgdGltZS4KKiBNYW55IG9mIHRoZSBsZWF2ZXMgc2VlbSB1 bm5lY2Vzc2FyeSBhbmQgbm90IHRlcnJpYmx5IHVzZWZ1bC4KICBGb3IgZXhhbXBsZSwgc2VjLWF1 dGhvci1zcnYtbnVtIChUb3RhbCBudW1iZXIgb2YgY29uZmlndXJlZCBzZWNvbmRhcnkgYXV0aG9y aXphdGlvbiBzZXJ2ZXJzIGluIHRoZSB0ZW1wbGF0ZSkuCiAgSXMgdGhpcyB2YWx1ZSBuZWVkZWQg c28gZnJlcXVlbnRseSB0aGF0IGl0IG5lZWRzIHRvIGJlIGF2YWlsYWJsZSBhcyBhIHNlcGFyYXRl IHZhbHVlIC0gaW5zdGVhZCBvZiBoYXZpbmcgdGhlIG1hbmFnZW1lbnQgY2xpZW50IHNpbXBseSBy ZWFkIHRoZSB3aG9sZSBsaXN0IG9mIHNlcnZlcnMsIGFuZCBjb3VudCBob3cgbWFueSBhcmUgc2Vj b25kYXJ5IGFuZCB1c2VkIGZvciBhdXRoZW50aWNhdGlvbj8KKiBXaGF0IGlzIHRoZSBwdWJsaWMg bmV0PwoqIFdoeSBpcyB0aGVyZSBhIG1heGltdW0gb2YgMzIgc2VydmVycz8KKiBUaGVyZSBzaG91 bGQgbm90IG5lZWQgdG8gYmUgc2VwYXJhdGUgbGlzdHMgZm9yIGlwdjQgYW5kIGlwdjYgc2VydmVy cy4gSSBzZWUgdGhhdCBpcHY2IHNlcnZlcnMgZG9uJ3Qgc3VwcG9ydCBwdWJsaWMtbmV0LCBzbyBJ J2xsIHJlc2VydmUganVkZ2VtZW50IHVudGlsIEkgZmluZCBvdXQgd2hhdCBwdWJsaWMtbmV0IGRv ZXMuCiogV2hhdCBzaG91bGQgaW1wbGVtZW50YXRpb25zIGRvIGlmIHRoZXkgZG9uJ3Qgc3VwcG9y dCBpZXRmLW5ldHdvcmstaW5zdGFuY2U/CgpBcyBhIHJlbGF0ZWQgc2lkZSBub3RlLCBJJ2QgcmVh bGx5IGxpa2UgdG8gc2VlIGEgc3RhbmRhcmQgZm9yIFRBQ0FDUysgb3ZlciBUTFMuCgpSZWdhcmRz LApBbGV4Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogbmV0 bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFd1Ym8gKGxhbmEpIDxs YW5hLnd1Ym9AaHVhd2VpLmNvbT4KU2VudDogTW9uZGF5LCAyIEp1bHkgMjAxOCA4OjA3IHAubS4K VG86IG5ldG1vZEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnClN1YmplY3Q6IEVYVEVSTkFMOiBS ZTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRt b2QtdGFjYWNzLXlhbmctMDEudHh0CgpEZWFyIE5ldG1vZCwgT3BzYXdnLAoKUGxlYXNlIHNlZSBv dXIgbmV3bHkgdXBsb2FkZWQgZHJhZnQgb2YgVEFDQUNTKyBZQU5HIGRhdGEgbW9kZWwsIHdoaWNo IGNhbiBiZSBmb3VuZCBhdApodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5nLTAxLnR4dC4KCgpUaGlzIGRhdGEgbW9kZWwgZHJh ZnQgaXMgYmFzZWQgb24gdGhlIFRBQ0FDUysgd29ya2luZyBncm91cCBkcmFmdCAtIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy10YWNhY3MtMTAuClRBQ0FDUysg cHJvdmlkZXMgRGV2aWNlICBBZG1pbmlzdHJhdGlvbiBmb3Igcm91dGVycywgbmV0d29yayBhY2Nl c3Mgc2VydmVycyBhbmQgb3RoZXIgIG5ldHdvcmtlZCBjb21wdXRpbmcgZGV2aWNlcyB2aWEgb25l IG9yIG1vcmUKY2VudHJhbGl6ZWQgc2VydmVycy4gIFdpdGggdmFyaW91cyBUQUNBQ1MrIEltcGxl bWVudGF0aW9uLCBzZXJ2aWNlIHByb3ZpZGVyIG1heSBuZWVkIGRpZmZlcmVudCBUQUNBQ1MrIFlB TkcgbW9kdWxlcwogdG8gbWFuaXB1bGF0ZSBtYXNzaXZlIGRldmljZXMuClNvIHdlIHByb3Bvc2Ug dG8gZGVmaW5lIGEgIGdlbmVyaWMgVEFDQUNTKyBkYXRhIG1vZGVsICB0byBhbGxldmlhdGUgdGhp cyBpc3N1ZS4KCldlIGFyZSBsb29raW5nIGZvcndhcmQgdG8gcmVjZWl2aW5nIHlvdXIgcmVzcG9u c2UuCgpCZXN0IHJlZ2FyZHMuCgpCbwoKCi0tLS0t08q8/tStvP4tLS0tLQq3orz+yMs6IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10Kt6LL zcqxvOQ6IDIwMTjE6jfUwjLI1SAxNDoxNQrK1bz+yMs6IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1 YXdlaS5jb20+OyBXdWJvIChsYW5hKSA8bGFuYS53dWJvQGh1YXdlaS5jb20+OyBaaGVuZ2d1YW5n eWluZyAoV2Fsa2VyKSA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbT47IFd1Ym8gKGxhbmEpIDxs YW5hLnd1Ym9AaHVhd2VpLmNvbT47IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+Ctb3 zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fj cy15YW5nLTAxLnR4dAoKCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGVuZy1uZXRtb2Qt dGFjYWNzLXlhbmctMDEudHh0CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQm8g V3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LgoKTmFtZTogICAgICAgICAgIGRy YWZ0LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZwpSZXZpc2lvbjogICAgICAgMDEKVGl0bGU6ICAg ICAgICAgIFlhbmcgZGF0YSBtb2RlbCBmb3IgVGVybWluYWwgQWNjZXNzIENvbnRyb2xsZXIgQWNj ZXNzIENvbnRyb2wgU3lzdGVtIFBsdXMKRG9jdW1lbnQgZGF0ZTogIDIwMTgtMDctMDEKR3JvdXA6 ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbgpQYWdlczogICAgICAgICAgMzMKVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVu Zy1uZXRtb2QtdGFjYWNzLXlhbmctMDEudHh0ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy1uZXRtb2QtdGFjYWNzLXlhbmcvCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9k LXRhY2Fjcy15YW5nLTAxCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZwpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpoZW5nLW5ldG1vZC10 YWNhY3MteWFuZy0wMQoKQWJzdHJhY3Q6CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0 YSBtb2RlbCBvZiBUZXJtaW5hbCBBY2Nlc3MgQ29udHJvbGxlcgogICBBY2Nlc3MgQ29udHJvbCBT eXN0ZW0gUGx1cyAoVEFDQUNTKykuCgogICBUaGUgWUFORyBkYXRhIG1vZGVsIGluIHRoaXMgZG9j dW1lbnQgY29uZm9ybXMgdG8gdGhlIE5ldHdvcmsKICAgTWFuYWdlbWVudCBEYXRhc3RvcmUgQXJj aGl0ZWN0dXJlIChOTURBKSBkZWZpbmVkIGluIFtSRkM4MzQyXS4KCgoKClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4KClRoZSBJRVRGIFNlY3JldGFyaWF0CgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From nobody Wed Jul 4 03:04:13 2018 Return-Path: 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 22A12130E17; Wed, 4 Jul 2018 03:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 X1Y374hDWb4F; Wed, 4 Jul 2018 03:04:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 90D6B130DC4; Wed, 4 Jul 2018 03:04:02 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 02A45E154B61; Wed, 4 Jul 2018 11:03:59 +0100 (IST) Received: from DGGEMI421-HUB.china.huawei.com (10.1.199.150) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 4 Jul 2018 11:04:00 +0100 Received: from DGGEMI526-MBX.china.huawei.com ([169.254.8.180]) by dggemi421-hub.china.huawei.com ([10.1.199.150]) with mapi id 14.03.0382.000; Wed, 4 Jul 2018 18:03:57 +0800 From: "Wubo (lana)" To: Alex Campbell , "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: EXTERNAL: Re: [netmod] New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt Thread-Index: AdQTe7o/93VnK420SV28nIlmIEbcEA== Date: Wed, 4 Jul 2018 10:03:56 +0000 Message-ID: <520ECC8D9CA1724BA1CE492DF898F6A3319ED1@DGGEMI526-MBX.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.189.23] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] EXTERNAL: Re: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 10:04:07 -0000 SGkgQWxleCwNCg0KVGhhbmtzIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLCBwbGVhc2Ugc2Vl IG15IHJlcGx5IGlubGluZSBiZWxvdzoNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog QWxleCBDYW1wYmVsbCBbbWFpbHRvOkFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tXSANCreiy83K sbzkOiAyMDE4xOo31MI0yNUgODowMA0KytW8/sjLOiBXdWJvIChsYW5hKSA8bGFuYS53dWJvQGh1 YXdlaS5jb20+OyBuZXRtb2RAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0K1vfM4jogUmU6IEVY VEVSTkFMOiBSZTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16 aGVuZy1uZXRtb2QtdGFjYWNzLXlhbmctMDEudHh0DQoNCkhpIEJvLA0KDQpNeSBjb21tZW50czog KGlnbm9yaW5nIHNpbXBsZSB0eXBvcyBhbmQgcGxhY2Vob2xkZXIgdmFsdWVzIGFzIHRoaXMgaXMg YSBmaXJzdCBkcmFmdCkNCg0KKiBXaGF0IGlzIGEgVEFDQUNTKyB0ZW1wbGF0ZT8gVG8gbXkga25v d2xlZGdlIHRoaXMgaXMgbm90IGEgc3RhbmRhcmQgY29uY2VwdC4gVGhlIHdvcmQgInRlbXBsYXRl IiBkb2VzIG5vdCBhcHBlYXIgaW4gZHJhZnQtaWV0Zi1vcHNhd2ctdGFjYWNzLTEwLg0KW0JvXVRB Q0FDUysgdGVtcGxhdGUgaXMgdXNlZCB0byBjb25maWd1cmUgYSBzZXRzIG9mIFRBQ0FDUysgc2Vy dmVyIHdpdGggdGhlIGRlZmluZWQgZG9tYWluLg0KRWFjaCBkb21haW4gZGVmaW5lZCBtYWludGFp bnMgYSB1c2VyIGxpc3QgaW4gdGhlICJ1c2VyQGRvbWFpbiIgZm9ybWF0LiANCldoZW4gYSBUQUNB Q1MrIGNsaWVudCByZWNlaXZlcyBhIHJlcXVlc3QgZnJvbSBhIHVzZXIsIHRoZSBUQUNBQ1MrIHRl bXBsYXRlIGlzIHNlbGVjdGVkIGJhc2VkIG9uIA0KdGhlIGRvbWFpbiBjYXJyaWVkIHdpdGggdGhl IHVzZXIuDQoNCiogV2hhdCBpcyBhIGRvbWFpbiBuYW1lLCBpbiB0aGUgY29udGV4dCBvZiB1c2Vy bmFtZXM/ICJkb21haW4iIGFsc28gZG9lcyBub3QgYXBwZWFyIGluIGRyYWZ0LWlldGYtb3BzYXdn LXRhY2Fjcy0xMC4NCltCb10gRG9tYWluIGlzIHVzZWQgZm9yIG1hbmFnZW1lbnQgcHVycG9zZSBz YW1lIGFzIHRoZSBmaXJzdCBjb21tZW50Lg0KDQoqIEkgZG9uJ3QgdGhpbmsgaXB2NC1hZGRyZXNz LW5vLXpvbmUgc2hvdWxkIGJlIHVzZWQgYnkgZGVmYXVsdCwgdW5sZXNzIHRoZXJlIGlzIGEgZ29v ZCByZWFzb24gdG8gcHJvaGliaXQgdGhlIHVzZSBvZiB6b25lcy4NCiAgU3lzdGVtcyB0aGF0IGRv IG5vdCBpbXBsZW1lbnQgem9uZXMgY2FuIHJlamVjdCBhZGRyZXNzZXMgY29udGFpbmluZyB6b25l czsgYnV0IHNvbWUgc3lzdGVtcyBtYXkgcmVxdWlyZSB6b25lcy4NCltCb10gR29vZCBzdWdnZXN0 aW9uLCB3ZSB3aWxsIGNvbnNpZGVyIHRvIG1vZGlmeSB0aGlzIHR5cGUgaW4gdGhlIG5leHQgdmVy c2lvbi4NCg0KKiBUaGlzIG1vZHVsZSBzZWVtcyB0byBpbXBseSBhIHBhcnRpY3VsYXIgc2VydmVy IHNlbGVjdGlvbiBhbGdvcml0aG0gKHdpdGggdGhlIHVzZSBvZiBwcmltYXJ5L3NlY29uZGFyeSBh bmQgY3VycmVudCBzZXJ2ZXJzKS4gV2hhdCBpcyB0aGUgYWxnb3JpdGhtPw0KICBPdXIgVEFDQUNT KyBjb2RlIGRvZXMgbm90IGhhdmUgYSBjb25jZXB0IG9mIGEgcHJpbWFyeSwgc2Vjb25kYXJ5IG9y IGN1cnJlbnQgc2VydmVyLiBJdCBoYXMgYSBwcmlvcml0aXplZCBsaXN0IG9mIHNlcnZlcnMsIGFu ZCB0cmllcyBlYWNoIHJlcXVlc3QgdG93YXJkcyBlYWNoIHNlcnZlciBpbiB0dXJuIHVudGlsIGl0 IHJlY2VpdmVzIGEgcGFzcyBvciBmYWlsIHJlc3BvbnNlIChhcyBvcHBvc2VkIHRvIGFuIGVycm9y KS4gVGhlIGFzc3VtcHRpb24gaW4gdGhpcyBkZXNpZ24gaXMgdGhhdCBzZXJ2ZXJzIGFyZSB1cCBt b3N0IG9mIHRoZSB0aW1lLg0KW0JvXSBPdXIgcHJvcG9zYWwgaXMgdGhhdCBpbiBlYWNoIHRlbXBs YXRlIHRoZXJlIGFyZSBvbmx5IG9uZSBwcmltYXJ5IHNlcnZlciBhbmQgDQpzZXZlcmFsIHNlY29u ZGFyeSBzZXJ2ZXJzIHdoaWNoIGNhbiBiZSBjb25maWd1cmVkLiBUaGVyZWZvcmUsIHRoZSBwcmlt YXJ5IHNlcnZlciBpcyBzZWxlY3RlZCBmaXJzdCwgDQphbmQgdGhlbiB0aGUgc2Vjb25kYXJ5IHNl cnZlciBpcyBzZWxlY3RlZCBhY2NvcmRpbmcgdG8gdGhlIGNvbmZpZ3VyYXRpb24gb3JkZXIuDQoN ClRoZSBkaWZmZXJlbmNlIGZyb20geW91ciBpbXBsZW1lbnRhdGlvbiBpcyB0aGF0IHdlIHNwZWNp ZnkgdGhlIHByaW1hcnkgc2VydmVyLg0KV2UgdGhpbmsgc3BlY2lmeWluZyBhIHByaW1hcnkgc2Vy dmVyIGNhbiBoZWxwIGRpc3RyaWJ1dGUgdXNlciByZXF1ZXN0IHByb2Nlc3NpbmcuDQoNCiogTWFu eSBvZiB0aGUgbGVhdmVzIHNlZW0gdW5uZWNlc3NhcnkgYW5kIG5vdCB0ZXJyaWJseSB1c2VmdWwu DQogIEZvciBleGFtcGxlLCBzZWMtYXV0aG9yLXNydi1udW0gKFRvdGFsIG51bWJlciBvZiBjb25m aWd1cmVkIHNlY29uZGFyeSBhdXRob3JpemF0aW9uIHNlcnZlcnMgaW4gdGhlIHRlbXBsYXRlKS4N CiAgSXMgdGhpcyB2YWx1ZSBuZWVkZWQgc28gZnJlcXVlbnRseSB0aGF0IGl0IG5lZWRzIHRvIGJl IGF2YWlsYWJsZSBhcyBhIHNlcGFyYXRlIHZhbHVlIC0gaW5zdGVhZCBvZiBoYXZpbmcgdGhlIG1h bmFnZW1lbnQgY2xpZW50IHNpbXBseSByZWFkIHRoZSB3aG9sZSBsaXN0IG9mIHNlcnZlcnMsDQph bmQgY291bnQgaG93IG1hbnkgYXJlIHNlY29uZGFyeSBhbmQgdXNlZCBmb3IgYXV0aGVudGljYXRp b24/DQpbQm9dIEdvb2QgcG9pbnQhIEluIHRoaXMgdmVyc2lvbiwgd2UgdHJ5IHRvIHByb3ZpZGUg Y29tcGxldGUgb3BlcmF0aW9uYWwgc3RhdGlzdGljcy4gDQoNCkFuZCBJIGFncmVlIHdpdGggeW91 IHRoYXQgaXQgc2VlbXMgcmVkdW5kYW50LCBhbmQgaWYgbW9zdCBmb2xrcyBiZWxpZXZlIGl0IG5l ZWQgdG8gYmUgc2ltcGxpZmllZCB0aGF0IHdlIHdvdWxkIGxpa2UgdG8gcmVmaW5lIHRoaXMgc3Rh dGlzdGljcyBsZWF2ZXMgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KKiBXaGF0IGlzIHRoZSBwdWJs aWMgbmV0Pw0KW0JvXSBQdWJsaWMgbmV0IGlzIHVzZWQgdG8gc3BlY2lmeSB3aGV0aGVyIGEgVEFD QUNTKyBzZXJ2ZXIgaXMgdXNlZCBpbiBwdWJsaWMgSW50ZXJuZXQuDQoNCiogV2h5IGlzIHRoZXJl IGEgbWF4aW11bSBvZiAzMiBzZXJ2ZXJzPw0KW0JvXSBHb29kIGNhdGNoLCBpdCBpcyBhIGltcGxl bWVudGF0aW9uIGxpbWl0YXRpb24sIHdlIHdpbGwgcmVtb3ZlIGl0IGluIHRoZSBuZXh0IHZlcnNp b24uDQoNCiogVGhlcmUgc2hvdWxkIG5vdCBuZWVkIHRvIGJlIHNlcGFyYXRlIGxpc3RzIGZvciBp cHY0IGFuZCBpcHY2IHNlcnZlcnMuIEkgc2VlIHRoYXQgaXB2NiBzZXJ2ZXJzIGRvbid0IHN1cHBv cnQgcHVibGljLW5ldCwgc28gSSdsbCByZXNlcnZlIGp1ZGdtZW50IHVudGlsIEkgZmluZCBvdXQg d2hhdCBwdWJsaWMtbmV0IGRvZXMuDQpbQm9dIEdvb2Qgc3VnZ2VzdGlvbiwgd2Ugd2lsbCBjb25z aWRlciB0byB1c2Ugb25lIG1lcmdlZCBsaXN0IHRvIHJlcHJlc2VudCANCnR3byBhZGRyZXNzIGZh bWlsaWVzIG9mIGEgVEFDQUNTKyBzZXJ2ZXIuDQoNCiogV2hhdCBzaG91bGQgaW1wbGVtZW50YXRp b25zIGRvIGlmIHRoZXkgZG9uJ3Qgc3VwcG9ydCBpZXRmLW5ldHdvcmstaW5zdGFuY2U/DQpbQm9d R29vZCBjb21tZW50LiBUaG91Z2ggd2UgdXNlIGlldGYtbmV0d29yay1pbnN0YW5jZSBhcyBhIGtl eSB0byBjb25maWd1cmUgVEFDQUNTKyAgc2VydmVyIGFuZA0Kb3VyIGFzc3VtcHRpb24gaXMgbW9z dCBUQUNBQ1MrIGNsaWVudHMgY2FuIHN1cHBvcnQgVlBOIGZ1bmN0aW9uYWxpdHksIHRoaXMgbWF5 IGxlYWQgdG8gYW4gaXNzdWUgaW4gc29tZSBjYXNlLg0KV2Ugd2lsbCB0cnkgdG8gYWRkcmVzcyB0 aGlzIGlzc3VlIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCkFzIGEgcmVsYXRlZCBzaWRlIG5vdGUs IEknZCByZWFsbHkgbGlrZSB0byBzZWUgYSBzdGFuZGFyZCBmb3IgVEFDQUNTKyBvdmVyIFRMUy4N Cg0KDQpSZWdhcmRzLA0KQWxleA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IFd1Ym8gKGxhbmEpIDxsYW5hLnd1Ym9AaHVhd2VpLmNvbT4NClNlbnQ6IE1vbmRheSwgMiBKdWx5 IDIwMTggODowNyBwLm0uDQpUbzogbmV0bW9kQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcNClN1 YmplY3Q6IEVYVEVSTkFMOiBSZTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC16aGVuZy1uZXRtb2QtdGFjYWNzLXlhbmctMDEudHh0DQoNCkRlYXIgTmV0bW9kLCBP cHNhd2csDQoNClBsZWFzZSBzZWUgb3VyIG5ld2x5IHVwbG9hZGVkIGRyYWZ0IG9mIFRBQ0FDUysg WUFORyBkYXRhIG1vZGVsLCB3aGljaCBjYW4gYmUgZm91bmQgYXQgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZy0wMS50eHQu DQoNCg0KVGhpcyBkYXRhIG1vZGVsIGRyYWZ0IGlzIGJhc2VkIG9uIHRoZSBUQUNBQ1MrIHdvcmtp bmcgZ3JvdXAgZHJhZnQgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v cHNhd2ctdGFjYWNzLTEwLg0KVEFDQUNTKyBwcm92aWRlcyBEZXZpY2UgIEFkbWluaXN0cmF0aW9u IGZvciByb3V0ZXJzLCBuZXR3b3JrIGFjY2VzcyANClRBQ0FDUysgc2VydmVycyBhbmQgb3RoZXIg IG5ldHdvcmtlZCBjb21wdXRpbmcgZGV2aWNlcyB2aWEgb25lIG9yIG1vcmUNCmNlbnRyYWxpemVk IHNlcnZlcnMuICBXaXRoIHZhcmlvdXMgVEFDQUNTKyBJbXBsZW1lbnRhdGlvbiwgc2VydmljZSBw cm92aWRlciBtYXkgbmVlZCBkaWZmZXJlbnQgVEFDQUNTKyBZQU5HIG1vZHVsZXMgIHRvIG1hbmlw dWxhdGUgbWFzc2l2ZSBkZXZpY2VzLg0KU28gd2UgcHJvcG9zZSB0byBkZWZpbmUgYSAgZ2VuZXJp YyBUQUNBQ1MrIGRhdGEgbW9kZWwgIHRvIGFsbGV2aWF0ZSB0aGlzIGlzc3VlLg0KDQpXZSBhcmUg bG9va2luZyBmb3J3YXJkIHRvIHJlY2VpdmluZyB5b3VyIHJlc3BvbnNlLg0KDQpCZXN0IHJlZ2Fy ZHMuDQoNCkJvDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAy MDE4xOo31MIyyNUgMTQ6MTUNCsrVvP7Iyzogd2FuZ3ppdGFvIDx3YW5neml0YW9AaHVhd2VpLmNv bT47IFd1Ym8gKGxhbmEpIDxsYW5hLnd1Ym9AaHVhd2VpLmNvbT47IFpoZW5nZ3Vhbmd5aW5nIChX YWxrZXIpIDx6aGVuZ2d1YW5neWluZ0BodWF3ZWkuY29tPjsgV3VibyAobGFuYSkgPGxhbmEud3Vi b0BodWF3ZWkuY29tPjsgd2FuZ3ppdGFvIDx3YW5neml0YW9AaHVhd2VpLmNvbT4NCtb3zOI6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5n LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGVuZy1uZXRtb2QtdGFj YWNzLXlhbmctMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJvIFd1 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRy YWZ0LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZw0KUmV2aXNpb246ICAgICAgIDAxDQpUaXRsZTog ICAgICAgICAgWWFuZyBkYXRhIG1vZGVsIGZvciBUZXJtaW5hbCBBY2Nlc3MgQ29udHJvbGxlciBB Y2Nlc3MgQ29udHJvbCBTeXN0ZW0gUGx1cw0KRG9jdW1lbnQgZGF0ZTogIDIwMTgtMDctMDENCkdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAzMw0K VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC16aGVuZy1uZXRtb2QtdGFjYWNzLXlhbmctMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhlbmctbmV0bW9kLXRhY2Fjcy15YW5n Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGVu Zy1uZXRtb2QtdGFjYWNzLXlhbmctMDENCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXpoZW5nLW5ldG1vZC10YWNhY3MteWFuZw0KRGlm ZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC16aGVu Zy1uZXRtb2QtdGFjYWNzLXlhbmctMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIGRhdGEgbW9kZWwgb2YgVGVybWluYWwgQWNjZXNzIENvbnRyb2xsZXINCiAgIEFj Y2VzcyBDb250cm9sIFN5c3RlbSBQbHVzIChUQUNBQ1MrKS4NCg0KICAgVGhlIFlBTkcgZGF0YSBt b2RlbCBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm1zIHRvIHRoZSBOZXR3b3JrDQogICBNYW5hZ2Vt ZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpIGRlZmluZWQgaW4gW1JGQzgzNDJdLg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Fri Jul 6 08:03:25 2018 Return-Path: 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 C0FB8130E63 for ; Fri, 6 Jul 2018 08:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 sWOfSZjHZWut for ; Fri, 6 Jul 2018 08:03:20 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365D3130E2A for ; Fri, 6 Jul 2018 08:03:20 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i139-v6so15114509wmf.4 for ; Fri, 06 Jul 2018 08:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=kxCyEWVk4VpjxprK3GjzdcN/ENtJD7Jz1zSY0aJQnVc=; b=jEwtLmtBhcvL9j4wSreZgQNuXFWFEWtl57DT62D3GJ1QX9WCw9zNxmsP3AbX5LmENs QC9ddN3sEAPRSSPIrywRXYuwc+IXNUmoXmHifxduYexAXgT5AlQYn8T+aHwJMGeE2TAH yUC/uPnwj7UFWGKDobpbvRiaURxCbi8TCBZyCkcB5ZNEFMC4LR6ZoSDRYqQrfbzbpzIj Xjd1zMEGwFa3CVEOTPvzF3pCN+uwB/jOKrXW37zpGGmb7SUIYozfYIKuz+FdDV1GR6UB 1AbXXaROqkmbno3bo3yR3ORHqDd9QMa5Z/yWWAAlEwmn1KUoU2XlElYyhpS932fNNKZg c/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=kxCyEWVk4VpjxprK3GjzdcN/ENtJD7Jz1zSY0aJQnVc=; b=UKY/wORcuFFbzB/iOi6RtcvcajI3JnB99oXhSep4dBOpGdiEUtfUJadgpE9UtaZflH hxd4R7PdzTJit3nnkuI1vtaR9o0QOO/oonjYKxgyQhoVORf5kVVDbc89AuX1L0mWAjGp 7BQW391MB8zK+bssYko/N0XZp8A2sU6KNq8w4wCJQE2gno+xIJoYMCgF2PDoqBR2Knsg B+LbLfDAezxYdFCnowNt2IGRYDIiGlZxzJWWzIY0Ep6hn/bdgUeQt90DhNy5iMEj0wz0 wPWGAkrNNXdyJNc4ymRlEERSfHd3wEQV05tF8OP8I2f4jb4i3P7A7kcdl+2jY5IRFMPP E2zg== X-Gm-Message-State: APt69E2diKhJBFFWaOZiw9ReldTh8vhKVz3tm098VTN8E2O3TzsbefOz lLQfWYF15OfPwfuYDNRzehMDA8A4GQM= X-Google-Smtp-Source: AAOMgpcI0pt5ckJx9OfozcRy6p/yBNSPbwP3OkgKXDDOIsqZQY1oDaPXwpIMJY/SYKao1BNHa/hKTA== X-Received: by 2002:a1c:3b54:: with SMTP id i81-v6mr7041400wma.143.1530889398745; Fri, 06 Jul 2018 08:03:18 -0700 (PDT) Received: from [192.168.1.64] (204.137.207.77.rev.sfr.net. [77.207.137.204]) by smtp.gmail.com with ESMTPSA id t124-v6sm3367673wmf.37.2018.07.06.08.03.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 08:03:17 -0700 (PDT) From: Alexander Pelov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> Date: Fri, 6 Jul 2018 17:03:16 +0200 To: core@ietf.org, netmod@ietf.org, yot@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [netmod] Hackathon - open-source CoMI implementation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:03:23 -0000 Dear all, The way to use YANG for IoT - CoMI - has been stable for some time and = the missing piece as always has been.. running OPEN-SOURCE code! Montreal is the place to change that! Join us at the Hackathon in the = first structured effort to provide an open-source implementation of a = CoMI server and CoMI client. I personally will be coding in Python, but in case other folks want to = use something else - that's even better. See you on the Hackathon! Alexander PS. If people knowledgable in YDK want to join, that would be really = perfect! The description is here: https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon From nobody Fri Jul 6 10:50:03 2018 Return-Path: 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 F3D8C130E52 for ; Fri, 6 Jul 2018 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 aF2FCnA1HUzs for ; Fri, 6 Jul 2018 10:49:59 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB48129C6A for ; Fri, 6 Jul 2018 10:49:59 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id u202-v6so10434771lff.9 for ; Fri, 06 Jul 2018 10:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=e7iFyF5ddPBAgnJuEF8jRP0BGUZhVPewqwUqipZn/3o=; b=dZBXVif+3DlA04llsmvYNEJbE0OF4ojSAe8pvZzdu83IKssYzWJR3eVJc/QSym1rPb +MymbvhxZkyyx7g+cgSief0GE3EWrM3JUzo7sVSEcSvid5TWyHdeuez8DXVXNrJQg6Sk k8Sf4hrh2lu1+XctiTxMScQyJRj2PBcWFTYAu1MGVdKXZsirBlYiKOnmZvJsH2aHUYv+ EgsOZPtM2hv2JypwWExvEGOd1nAudlUfZTXt2lPwS8wVH9oXNfqZxRuyCLZiY+WVBxA2 1Xrcntu0yEqUY4iM/BF1XYn4vNZ6CO4wPkBuW7sjrWKxL0QKbqu2+QuRzsBnr/3pMU/X XpgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e7iFyF5ddPBAgnJuEF8jRP0BGUZhVPewqwUqipZn/3o=; b=rBeAaOTvS53lfcjgBkzrfEba/AB60nolaySysI8JxIS4jhn1c0hetOJTJTgjO7HdZc BoJ7CIAO9faKQImL6VUkwKmplGxhs4rivFeiV4v7lxbiGeaw1yw950H51DumHrMk/c8c KDuT4Rxp6a011is75xDdYpn7aKLSpToGV5zsblNKuJGwejhsOrCT4Ztj6D0XyL3EKT/X VapYNPrSzlxpT/D80tZ8ri+3RCbGAYxnxd/stpJZBvuBoaRHBjL5CcWZwYmG8+YCaWDm qpp0zNPSC4N4DloFtXyS3krfQjrwS11vJyLC1uh6T27ge4HPu5fyoyfkAu7v8os6qVgR GkeQ== X-Gm-Message-State: APt69E02qdHfy9tsid+B+HkMO4pxB+9bbbkDW37/7ac+gT901BuCAgzn FRJBE/bKsiddrGD3B/l0rVeHJXhZkVWHsPqCaAGIRwWl X-Google-Smtp-Source: AAOMgpcfBoqppy7tJB1zX/f93dTrcVhhlC5nAA+VzCGDt4z8Pe+appQSvX8uyOdhGEiTGx6eTT+nUPErI23KNTesXko= X-Received: by 2002:a19:b598:: with SMTP id g24-v6mr8351301lfk.129.1530899397063; Fri, 06 Jul 2018 10:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 10:49:56 -0700 (PDT) From: Andy Bierman Date: Fri, 6 Jul 2018 10:49:56 -0700 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="000000000000bfcaf20570584a76" Archived-At: Subject: [netmod] review CORE WG YANG drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 17:50:01 -0000 --000000000000bfcaf20570584a76 Content-Type: text/plain; charset="UTF-8" Hi, YANG experts: please review these 2 drafts and post comments to the CORE WG mailing list: CBOR Encoding of Data Modeled with YANGdraft-ietf-core-yang-cbor-06 https://tools.ietf.org/html/draft-ietf-core-yang-cbor-06 YANG Schema Item iDentifier (SID)draft-ietf-core-sid-04 https://tools.ietf.org/html/draft-ietf-core-sid-04 Andy --000000000000bfcaf20570584a76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

YANG experts: please review these 2= drafts and post comments to the CORE WG mailing list:

= 

CBOR Encoding of Data Modeled with YANG=



draft-ietf-core-yang-cbor-06

YANG Schema Item iDentifier (SID)


draft-ietf-core-sid-04



Andy

--000000000000bfcaf20570584a76-- From nobody Fri Jul 6 12:47:54 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E427129C6A; Fri, 6 Jul 2018 11:02:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Tom Nadeau" , "Ignas Bagdonas" , "Deborah Brungard" , "Warren Kumari" , "=?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?=" , "Martin Vigoureux" , "Alvaro Retana" Cc: Ignas Bagdonas , Deborah Brungard , nan@mef.net, The IETF Chair , Joel Jaeggli , Warren Kumari , Martin Vigoureux , Alvaro Retana , Kent Watsen , Lou Berger , Network Modeling Discussion List , Raghu Ranganathan X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153090014650.5315.16480765700997021373.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2018 11:02:26 -0700 Archived-At: X-Mailman-Approved-At: Fri, 06 Jul 2018 12:47:52 -0700 Subject: [netmod] New Liaison Statement, "MEF Starting IP Service Definition Work" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.26 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 18:02:27 -0000 Title: MEF Starting IP Service Definition Work Submission Date: 2018-07-06 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1584/ From: JASON WOLFE To: Jürgen Schönwälder , Tom Nadeau ,Alvaro Retana ,Deborah Brungard ,Martin Vigoureux ,Warren Kumari ,Ignas Bagdonas Cc: Ignas Bagdonas ,Deborah Brungard ,Kent Watsen ,Warren Kumari ,Martin Vigoureux ,Alvaro Retana ,The IETF Chair ,Joel Jaeggli ,Lou Berger ,Network Modeling Discussion List ,Raghu Ranganathan Response Contacts: nan@mef.net Technical Contacts: Purpose: For information Body: The definition of IP Services is under consideration in MEF in both the Services and Applications Committees. This follows on from the MEF IP Services Attributes specification, that was previously liaised to the IETF, and has recently been published as MEF 61. It is complementary to the MEF IP Services OAM and IP Services Activation Testing work also ongoing in MEF and previously liaised to IETF. This new project seeks to formalize the Subscriber IP Services for two main initial use cases: Internet Access IP Services Private IP-VPN Services The scope of the IP Service Definition work includes IP-VPN as well as Internet Access IP services. The project will take the IP Service Attributes already defined and place constraints on their use in delivering each of the IP Services noted. The primary purpose of the IP Services Definition project is to produce a service definition that can be used to drive functions and models in the respective Lifecycle Service Orchestration (LSO) elements within the OSS/BSS domain. These in turn would be used as a basis to create commercial offerings. The service definitions would also be the first in a series of new definitions to enable applications such as SD-WAN, 5G Mobile Backhaul, consistent pan-provider global enterprise IP-VPN services, etc. MEF values IETF’s expertise and history in architecting and specifying IP networks and invites IETF input to the development of the IP Service definitions. MEF intends to liaise interim results of the work periodically throughout the development process for IETF review and comment. MEF invites those affiliated with companies having membership in the MEF to be actively involved in the project and to help progress the work in MEF, aligned with IETF protocol and models for existing deployed networks. Please feel free to contact MEF with any questions concerning the work and its application. MEF looks forward to IETF's input and continuing our cooperative work relationship on this important topic. The forthcoming MEF meetings are: 23-26 July 2018 - Nashville, USA 1-2 November 2018 - Los Angeles, USA (co-located with MEF18) Attachments: LS00285_001_Liaison to IETF on Start of IP Service Definition Work_Wolfe https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-07-06-mef-ops-rtg-netmod-mef-starting-ip-service-definition-work-attachment-1.pdf From nobody Mon Jul 9 12:43:17 2018 Return-Path: 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 ADEDA130E8F; Mon, 9 Jul 2018 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dSYlpmDJGXqv; Mon, 9 Jul 2018 12:43:08 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6E5130E35; Mon, 9 Jul 2018 12:43:08 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id w8-v6so6491964ply.8; Mon, 09 Jul 2018 12:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c3K4x0DcYNQ+OzmxE/m/SDilAbAtBfg78XYvJ8ITMRk=; b=bl+m3irG3Uz6fEe8gFEg4etElrfCCDQqD34k8sNEbtGUmqiMH7pva6+dJCo2Z/KPez lortUvjk0nhAnvmGH1Elf3HhpRqfPgEHxhBHkiGAtOLmZ1mo370hKYqR7g/AEYa0ZRs7 0A0KxVgtfLdP72iwc3oblXdoSm+gl2vCXAKF7b6y0sHmGgy3ggEu8UGt+pO15+POI8D8 Dqap4E0Z66Pial/xeSSKyjkMPsICcw3sru76cD3VA/vz4mvUm45y8sw7MYoBymcZJ0Di xzl0Ap5RFczBu/Sobx7pnYDD+SY2vuRK5bFlDBHZlFPynPYqRunL0c0nQWi8csZ6dovn 7U4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c3K4x0DcYNQ+OzmxE/m/SDilAbAtBfg78XYvJ8ITMRk=; b=udfioG8sMHNMVffDttA8QdMrOfrtmT74C4z5/Lg1tqoBP4esK+wL4dyg7vcVAcY+bW 5Kp9mYIMIQMmrOk9JFkfhanbaQQwxG2Nu14fmuHK+apSwk1aIAsZ0awrVJgsCoq0AmAh ELnz5uvJyRUR/B39ZjCNnkF37kHvEeyXdnmKynyfV7RAPnFVKvSYD5nZ3q3+HF6HrzhB U672txe7dKslFKoLmq1Y+hvw6PMXFMjmjv24Hl2EE0NNYVzPPaKhdeFMpcXP2I+n+Zhp T8mnhzfamfrbDcxgAmtsPjSyThIOqTBnSGQTAw8SsdzAm24ubK04uXtBtfEp1gxQqJwd +txA== X-Gm-Message-State: APt69E1Tk4W9xJ5GT1yrEABmEnYClDyzP1UW9EENPQ2LF4LEp+jicbnL 1ktKLTTX9yekUcdg5UiC7Ziuqh/9vFe/6oQm0CNjsQ== X-Google-Smtp-Source: AAOMgpdTnr7C5iwQLjDh9X4OD6qKie1u/zEsqQwhO40uTzN2L06drb6Z3gy0ILCbprCqGtA1POPcOufu4EMYVSdmHoQ= X-Received: by 2002:a17:902:7202:: with SMTP id ba2-v6mr21368967plb.119.1531165387390; Mon, 09 Jul 2018 12:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Mon, 9 Jul 2018 12:43:06 -0700 (PDT) From: Allison Mankin Date: Mon, 9 Jul 2018 15:43:06 -0400 Message-ID: To: Transport Area Review Team , netmod@ietf.org Content-Type: multipart/alternative; boundary="00000000000002026905709639c1" Archived-At: Subject: [netmod] TSV-ART review of draft-ietf-netmod-acl-model-19 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 19:43:10 -0000 --00000000000002026905709639c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward this= review.. Summary: Almost Ready (but I do have a question) Technicals: I reviewed that the details about TCP, UDP, ECN, and DSCP are consistent with the specifications, and that the specifications are accurate. The model is accurate for these. Question: What is the use case for ACLs referencing TCP PSH and URG flags, and sequence numbers? These are not very predictable and I would think not very useful for the work that ACLs do, but I'm willing to be informed. --00000000000002026905709639c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've reviewed this document as part of the transpor= t area review team's=20 ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the=20 document's authors for their information and to allow them to address= =20 any issues raised. When done at the time of IETF Last Call, the authors=20 should consider this review together with any other last-call comments=20 they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward= this review..

Summary:
Almost Ready (but I do= have a question)

Technicals:
I reviewed = that the details about TCP, UDP, ECN, and DSCP are consistent with the spec= ifications, and that the specifications are accurate.=C2=A0 The model is ac= curate for these.=C2=A0


Question:
=C2=A0What is the use case for ACLs referencing TCP PSH and URG flags= , and sequence numbers?=C2=A0 These are not very predictable and I would th= ink not very useful for the work that ACLs do, but I'm willing to be in= formed.




--00000000000002026905709639c1-- From nobody Tue Jul 10 11:27:04 2018 Return-Path: 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 097FA131031; Tue, 10 Jul 2018 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uUf3ywN0AGRW; Tue, 10 Jul 2018 11:27:01 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3DC130DCE; Tue, 10 Jul 2018 11:27:01 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id g4-v6so34393iti.1; Tue, 10 Jul 2018 11:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9cpy39B9x7iNoBerSmteyPhfzkORhlDG8N+aibgnyGQ=; b=hRyxBMNhBBuOHOMxwfOsubp1Pr/HfcLDa/xndG1yniFUZpkcha7pxr6rT/700owf0V SNBF1xSugdaHB3Ixb8Gzmov9UEHO6WSWe8/452LqzrsGy+FtXrcI5nKuYDMrDch+VyIy Qr5ion/kZZZPclzrlM+iElDeSf/o68MvwBiwVuA03/UVKxcZTkithb/GzfYBID4XMo3P YSsEljUUUYnl52Il/Vb7joju6W03h1QuZmTq1e4eAscIcSL6gYwbAVTUUw/u2DHLGmLt JGHxbLkBDbTKYR2jBOUK/Pn46q8S73qw2JkBTGahMfKNZQPT8PL7uGxEHJ+Vps3T3hM6 2DDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9cpy39B9x7iNoBerSmteyPhfzkORhlDG8N+aibgnyGQ=; b=b8LCUpO8kdw944SKSTiArcy1WwsVJ5T6mYqhKc18sqEHZxoHzw7Cs9ODKs7EPIGIMs p4y0b9AiMQuUrRzRnz91nXQoCkQX9PJzvz0ifqahP4HEv484lIgYunVJZKNF1zZCcpaj j9X/c0to2u7MgUaTzZ+dJg/Uwfz1JNXmknOcYZSiqeWRPv5gDn3AFhX/5/eVPR0DSkKA 5231u0oB54OWn56dmFCDAkkfbH/IkqqZnmorAkm+rme7woFJoZ8vgQyQwfsA0p5QcjIy d6Ea7wAH/jiJvtXP8m0AdbGeHS9/xUM7/1zMaL7ihsQnWwztkh9JQIkvhizz3CS04Xyj 5oxg== X-Gm-Message-State: APt69E34rfnSNXoceDPWNBeCHqPS4x4O51g5bXA204IACO8L2B6hUgVL t4lbODlLBM4gY5mFfpva+8A7lU5NU9f3Gy4Q7vg= X-Google-Smtp-Source: AAOMgpdwqxOaqAHMyxccV9BbBr1JBvesHMb1tyAkrQ5YhlI9ZvT862v3PWISD4eXFCKJFfaap8HLBC8kFLCFiN3VZYk= X-Received: by 2002:a02:6543:: with SMTP id u64-v6mr21720457jab.71.1531247220860; Tue, 10 Jul 2018 11:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:4743:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 11:26:59 -0700 (PDT) In-Reply-To: References: From: Sonal Agarwal Date: Tue, 10 Jul 2018 11:26:59 -0700 Message-ID: To: Allison Mankin Cc: Transport Area Review Team , netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9acf90570a946f4" Archived-At: Subject: Re: [netmod] TSV-ART review of draft-ietf-netmod-acl-model-19 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:27:03 -0000 --000000000000a9acf90570a946f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Allison, Please see inline: Thanks, Sonal. On Mon, Jul 9, 2018 at 12:43 PM, Allison Mankin wrote: > I've reviewed this document as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address any > issues raised. When done at the time of IETF Last Call, the authors shoul= d > consider this review together with any other last-call comments they > receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward th= is > review.. > > Summary: > Almost Ready (but I do have a question) > > Technicals: > I reviewed that the details about TCP, UDP, ECN, and DSCP are consistent > with the specifications, and that the specifications are accurate. The > model is accurate for these. > > > Question: > What is the use case for ACLs referencing TCP PSH and URG flags, and > sequence numbers? These are not very predictable and I would think not > very useful for the work that ACLs do, but I'm willing to be informed. > > [SA] The use case for this would be for applications that use ACL's and > require high levels of security. Enumerating all the supported flags and > their bit positions makes it clear to the user. These flags and the > sequence number are all part of the TCP header. > https://en.wikipedia.org/wiki/Transmission_Control_Protocol > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --000000000000a9acf90570a946f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Allison,

Please see inline:
Thanks,
S= onal.

On Mon= , Jul 9, 2018 at 12:43 PM, Allison Mankin <allison.mankin@gmail.com= > wrote:
I&#= 39;ve reviewed this document as part of the transport area review team'= s=20 ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the=20 document's authors for their information and to allow them to address= =20 any issues raised. When done at the time of IETF Last Call, the authors=20 should consider this review together with any other last-call comments=20 they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward= this review..

Summary:
Almost Ready (but I= do have a question)

Te= chnicals:
I revi= ewed that the details about TCP, UDP, ECN, and DSCP are consistent with the= specifications, and that the specifications are accurate.=C2=A0 The model = is accurate for these.=C2=A0


Ques= tion:
=C2=A0What= is the use case for ACLs referencing TCP PSH and URG flags, and sequence n= umbers?=C2=A0 These are not very predictable and I would think not very use= ful for the work that ACLs do, but I'm willing to be informed.

[SA] The use case for this would be= for applications that use ACL's and require high levels of security. E= numerating all the supported flags and their bit positions makes it clear t= o the user. These flags and the sequence number are all part of the TCP hea= der.=C2=A0https://en.wikipedia.org/wiki/Transmission_Control_Protocol
=C2=A0



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--000000000000a9acf90570a946f4-- From nobody Tue Jul 10 12:15:56 2018 Return-Path: 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 BB5AA131056; Tue, 10 Jul 2018 12:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 IM5BHS2JR5OR; Tue, 10 Jul 2018 12:15:41 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851A9130E6E; Tue, 10 Jul 2018 12:15:41 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id c41-v6so8036465plj.10; Tue, 10 Jul 2018 12:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AdSsOOJF9eK3gWw5/3JssNhqIzSkkhE4Ugzmamtcx24=; b=iTdSe3g9N7PHJrutDBYJsDm8/NAGG81BbWHuRsWoAp7MoWh6r8+7GWah92W8ttuJhJ l+/IbXJBSecnp+5E8e0tV6hUWJ/eNM35rqGTGE4u0rsZUvrdhn4RAL1pO9FLfwVSrXGh 6BDQJCCnXHRntjoE3o0lOANztem639XToG1TYdHQxRyXXbCDWygyqzdCoEcrHrB4AGiW SxHjYGy+e+afAjsm0653Vb0Jl+FNB6AYxI+YJshcex8Nu64APLvs1WEAut27qUnbPbfK VXiwatIuCvQHOAWS7jFx1Yn5oQDPR/shP2AUsJ/zKNnJO9pJJXdojmmpWVxNW9biu/sX Tp6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AdSsOOJF9eK3gWw5/3JssNhqIzSkkhE4Ugzmamtcx24=; b=YloVrNQRmrYDHcjbaoIQ24735CQTUlYM7E36aP2Kb8WJOhOjOBEII6zYcUNXv0dQ4A Ak3VNdOA9H+Y/GrjIJky4r9mcv9gC0kuoI00SDpd/xZAnoCR2QeMiIZQr9uxqQvlnfYo QfYSWCJsIQ9H3U1RF2CNADDraUQ8FUglDtgU4JOTMQLG0Fol2Pha1Dt7AZDbDk+pUCxg If2wX8g6vm8rO3HlL0RDGyudwVEQD43xSoB/q0YS6U7mN2eUwCewLktm1ii1EBMzVfbq i3TB/BTRChSsYugYKCJlqA7iAJbDDwJvjrw/BA3apZNlEl9x9hlpnz58LxHZg1Yr56ar 4LsQ== X-Gm-Message-State: APt69E1c6C+Owx7Rh1bq5aVI2cVr28vsdIZlbl8K8ZMjRT4lW8TxTmkx sxXUe5sNjiqu9f885NhUZaQtYZV95S9Jz+NH42I= X-Google-Smtp-Source: AAOMgpe65xwpm8LgNSSkYmFkR58JCH6gJUCpB+FJibS6OQV+l5DeO5Rxfuhvi0Q6Kb0fa9dPe04+oSQ1zvpu4xxFleA= X-Received: by 2002:a17:902:7481:: with SMTP id h1-v6mr26453382pll.183.1531250141067; Tue, 10 Jul 2018 12:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Tue, 10 Jul 2018 12:15:40 -0700 (PDT) In-Reply-To: References: From: Allison Mankin Date: Tue, 10 Jul 2018 15:15:40 -0400 Message-ID: To: Sonal Agarwal Cc: Transport Area Review Team , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b87fff0570a9f4ab" Archived-At: Subject: Re: [netmod] TSV-ART review of draft-ietf-netmod-acl-model-19 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:15:46 -0000 --000000000000b87fff0570a9f4ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sonal, I=E2=80=99m very familiar with the flags and fields of TCP. My question is = what are the use cases for and ACL to match on URG, PSH, or the sequence numbers? Allison (for the Transport Area review team) On Tuesday, 10 July 2018, Sonal Agarwal wrote: > Hi Allison, > > Please see inline: > > Thanks, > Sonal. > > On Mon, Jul 9, 2018 at 12:43 PM, Allison Mankin > wrote: > >> I've reviewed this document as part of the transport area review team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's authors for their information and to allow them to address an= y >> issues raised. When done at the time of IETF Last Call, the authors shou= ld >> consider this review together with any other last-call comments they >> receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward t= his >> review.. >> >> Summary: >> Almost Ready (but I do have a question) >> >> Technicals: >> I reviewed that the details about TCP, UDP, ECN, and DSCP are consistent >> with the specifications, and that the specifications are accurate. The >> model is accurate for these. >> >> >> Question: >> What is the use case for ACLs referencing TCP PSH and URG flags, and >> sequence numbers? These are not very predictable and I would think not >> very useful for the work that ACLs do, but I'm willing to be informed. >> >> [SA] The use case for this would be for applications that use ACL's and >> require high levels of security. Enumerating all the supported flags and >> their bit positions makes it clear to the user. These flags and the >> sequence number are all part of the TCP header. https://en.wikipedia. >> org/wiki/Transmission_Control_Protocol >> > > >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > --000000000000b87fff0570a9f4ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sonal,

I=E2=80=99m very familiar with the flags and fiel= ds of TCP. My question is what are the use cases for and ACL to match on UR= G, PSH, or the sequence numbers?=C2=A0

Allison (fo= r the Transport Area review team)

On Tuesday, 10 July 2018= , Sonal Agarwal <sagarwal12@gmai= l.com> wrote:
Hi = Allison,

Please see inline:

Thanks,
Sonal.

On Mon, Jul 9, 2018 at 12:= 43 PM, Allison Mankin <allison.mankin@gmail.com> wrot= e:
I've reviewed this = document as part of the transport area review team's=20 ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the=20 document's authors for their information and to allow them to address= =20 any issues raised. When done at the time of IETF Last Call, the authors=20 should consider this review together with any other last-call comments=20 they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward= this review..

Summary:
Almost Ready (but I= do have a question)

Te= chnicals:
I revi= ewed that the details about TCP, UDP, ECN, and DSCP are consistent with the= specifications, and that the specifications are accurate.=C2=A0 The model = is accurate for these.=C2=A0


Ques= tion:
=C2=A0What= is the use case for ACLs referencing TCP PSH and URG flags, and sequence n= umbers?=C2=A0 These are not very predictable and I would think not very use= ful for the work that ACLs do, but I'm willing to be informed.

[SA] The use case for this would be= for applications that use ACL's and require high levels of security. E= numerating all the supported flags and their bit positions makes it clear t= o the user. These flags and the sequence number are all part of the TCP hea= der.=C2=A0https://en.wikipedia.org/wiki/Transmission_Co= ntrol_Protocol
=C2=A0



_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

--000000000000b87fff0570a9f4ab-- From nobody Tue Jul 10 14:01:14 2018 Return-Path: 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 001C81310C3; Tue, 10 Jul 2018 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QG6D4slZ_FET; Tue, 10 Jul 2018 14:01:05 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F60130E29; Tue, 10 Jul 2018 14:01:05 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v71-v6so622672itb.3; Tue, 10 Jul 2018 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aESgHg/lxpq9YFQfFUPISf4+wuo8IhSzxpoBTlCmSNo=; b=YLk/6c54Oj/vyjcjKMRpfwkBQdeQDpO9fGsafouK0tB1qCOfmsWTHU1b8POGCLL5S6 992Mp7C4hwvxC9d+KNm64tCGVkRmmh10pUO4LTZvqaW6QDzuBeMaVod2OacY/SWTyRje CT56ktWXArfQxXUTalu7fnDZFCjTXOvHH1BMzUEQnPmfJAQVoAZYRqChGA8noXmrQYk8 uV6t5GJCfHucmGElZ/7598A4md7tihRshSRB5npd6Upf8puS4q4u+NFuZtxAG0Q4+Flo YYsp7ize2jaMfrGZcL1dl234JU4HLxPYqbkdDfwGSdN9ksIM+nlHQUOsrpa1N0tjM+tJ ZTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aESgHg/lxpq9YFQfFUPISf4+wuo8IhSzxpoBTlCmSNo=; b=RjqVsIE0jsPNOc0CUP/lL95F02ciEfolDvXY+ehw8YQqGfE9LWBrx64Qz1x0g86mNr PzClA5nHwQHWz1fJ3JtHcRk1qn3EiPIDl2c1A13/hpvOCvBw90k+3sYJ3p+F2mANPMuG nSjiCuU41cjslCBHoVpYHbADZR3QMx/n+UCUUse4Z0Uq4Jm9jCxFCpbYYFDTcJ6Acy5s n4tvkHA0FXPyD94c9ZI95NV44KW4tHrqCsWJ9O6sXaOoMX9XhxuaovQNyu9s2OVG6TZC 7Ds1CFJU5zAA9sVbVAjb/BhkF3zm/ht35xoWgGr7yr7wRUwY+cTdMvGvTIS99KUFXCEO 6EvQ== X-Gm-Message-State: APt69E1Hy2lr16/5PCGb4aJ+yQimZLJOCUFUgx04ZaEloHjUJ/e08Ij1 sWTfoIW0ai0aZ3eGZvyfRG3k04yoixK1HmV9/Is= X-Google-Smtp-Source: AAOMgpf6od+8McMirEfqMQ9pb0I27hk9ye+DvJYkENpzvgjLi71eHa5yzMgzXCASYRK1lJKt/Deswcn96DTq1FNOUps= X-Received: by 2002:a24:28f:: with SMTP id 137-v6mr19901393itu.55.1531256463751; Tue, 10 Jul 2018 14:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:4743:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 14:01:03 -0700 (PDT) In-Reply-To: References: From: Sonal Agarwal Date: Tue, 10 Jul 2018 14:01:03 -0700 Message-ID: To: Allison Mankin Cc: Transport Area Review Team , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095013c0570ab6d83" Archived-At: Subject: Re: [netmod] TSV-ART review of draft-ietf-netmod-acl-model-19 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:01:08 -0000 --00000000000095013c0570ab6d83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 12:15 PM, Allison Mankin wrote: > Sonal, > > I=E2=80=99m very familiar with the flags and fields of TCP. My question i= s what > are the use cases for and ACL to match on URG, PSH, or the sequence > numbers? > > [SA] There were ACL examples that were published by JNPR and CSCO (and several others) that utilized these flags. Therefore, the full set of TCP flags is being supported in the model. Some such examples are: e.g. http://it-certification-network.blogspot.com/2008/12/filtering-based-on-tcp= -header-flags.html https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-f= ilter-stateless-match-conditions-bit-field-values.html The sequence number is being supported for completeness sake. Sonal. Allison (for the Transport Area review team) > > > On Tuesday, 10 July 2018, Sonal Agarwal wrote: > >> Hi Allison, >> >> Please see inline: >> >> Thanks, >> Sonal. >> >> On Mon, Jul 9, 2018 at 12:43 PM, Allison Mankin > > wrote: >> >>> I've reviewed this document as part of the transport area review team's >>> ongoing effort to review key IETF documents. These comments were writte= n >>> primarily for the transport area directors, but are copied to the >>> document's authors for their information and to allow them to address a= ny >>> issues raised. When done at the time of IETF Last Call, the authors sho= uld >>> consider this review together with any other last-call comments they >>> receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward = this >>> review.. >>> >>> Summary: >>> Almost Ready (but I do have a question) >>> >>> Technicals: >>> I reviewed that the details about TCP, UDP, ECN, and DSCP are consisten= t >>> with the specifications, and that the specifications are accurate. The >>> model is accurate for these. >>> >>> >>> Question: >>> What is the use case for ACLs referencing TCP PSH and URG flags, and >>> sequence numbers? These are not very predictable and I would think not >>> very useful for the work that ACLs do, but I'm willing to be informed. >>> >>> [SA] The use case for this would be for applications that use ACL's and >>> require high levels of security. Enumerating all the supported flags an= d >>> their bit positions makes it clear to the user. These flags and the >>> sequence number are all part of the TCP header. https://en.wikipedia.o >>> rg/wiki/Transmission_Control_Protocol >>> >> >> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >> --00000000000095013c0570ab6d83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 12:15 PM, Allison Mankin <= allison.manki= n@gmail.com> wrote:
Sonal,

I=E2=80=99m very familiar with the fl= ags and fields of TCP. My question is what are the use cases for and ACL to= match on URG, PSH, or the sequence numbers?=C2=A0

[SA] There were ACL examples that were published by JNPR and = CSCO (and several others) that utilized these flags. Therefore, the full = set of TCP flags is being supported in the model.=C2=A0Some such exam= ples are:
=C2=A0
Th= e sequence number is being supported for completeness sake.

<= /div>
Sonal.

Allison (for the Transport Area review team)


On Tuesday, 10 July 2018, Sonal= Agarwal <saga= rwal12@gmail.com> wrote:
Hi Allison,

<= /div>
Please see inline:

Thanks,
Sonal.

On Mon, Jul 9, 2018 at 12:43 PM, Allison Mankin <= allison.manki= n@gmail.com> wrote:
I've reviewed this document as part of the transport area revie= w team's=20 ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the=20 document's authors for their information and to allow them to address= =20 any issues raised. When done at the time of IETF Last Call, the authors=20 should consider this review together with any other last-call comments=20 they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward= this review..

Summary:
Almost Ready (but I= do have a question)

Te= chnicals:
I revi= ewed that the details about TCP, UDP, ECN, and DSCP are consistent with the= specifications, and that the specifications are accurate.=C2=A0 The model = is accurate for these.=C2=A0


Ques= tion:
=C2=A0What= is the use case for ACLs referencing TCP PSH and URG flags, and sequence n= umbers?=C2=A0 These are not very predictable and I would think not very use= ful for the work that ACLs do, but I'm willing to be informed.

[SA] The use case for this would be= for applications that use ACL's and require high levels of security. E= numerating all the supported flags and their bit positions makes it clear t= o the user. These flags and the sequence number are all part of the TCP hea= der.=C2=A0https://en.wikipedia.org/wiki/Transmission_Co= ntrol_Protocol
=C2=A0



_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod


--00000000000095013c0570ab6d83-- From nobody Tue Jul 10 20:05:33 2018 Return-Path: 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 BF0D7130DD3 for ; Tue, 10 Jul 2018 20:05:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 J6-NfraLvYFL for ; Tue, 10 Jul 2018 20:05:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 988B7124D68 for ; Tue, 10 Jul 2018 20:05:28 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F35AA3945D0CE for ; Wed, 11 Jul 2018 04:05:24 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 11 Jul 2018 04:05:25 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.13]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Wed, 11 Jul 2018 11:05:16 +0800 From: "Zhengguangying (Walker)" To: "netmod@ietf.org" , "Yangang (Routing Design)" , Yangshouchuan , "Qudan (Beijing-NOS)" , Qin Wu Thread-Topic: [netmod] three questions about YANG deviation statement Thread-Index: AdQYw+JeFHRcJ83VT/e5cB1803Ckag== Date: Wed, 11 Jul 2018 03:05:16 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E140C9313AA9@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.169.155] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140C9313AA9nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] three questions about YANG deviation statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 03:05:31 -0000 --_000_381D7D55085B1E4D8B581BD652E1E140C9313AA9nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, When we try to implementing, there are 3 questions want to clear on WG, = please expert help to answer the questions, thanks. [Question 1]: whether "mandatory true" node can be deviated as "not-support= ed" ? [Question 2]: Whether can deviation YANG to expand the range of type? example: target YANG node: leaf a { type uint 8 { range "1..50"; } } deviation yang: deviation "/a:a" { replace type { range "1..100"; } } [Question 3]: How to use a new type defined by "typedef" to deviate replace= the target module's type. example: module example-base { namespace "urn:example-base"; prefix base; container system { description "System group configuration."; leaf daytime { type string; } leaf date { type string; } leaf interface { type string; } leaf status { type string; config false; } } } module example-deviations { yang-version 1.1; namespace "urn:example:deviations"; prefix md; import example-base { prefix base; } import ietf-interfaces { prefix if; } // here, define a new type with typedef statement typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\+\-]\d{2}:\d{2})'; } } // try to replace the target node's type with new typedef type deviation /base:system/base:date { deviate replace { type date-and-time; } } deviation /base:system/base:interface { deviate replace { type leafref { path "/if:interfaces/if:interface/if:name"; } } } ... } problem 1: when use new type defined in deviation YANG file to replace the = target node's type, some tools give compile error, because they can not fin= d the definition of new type "date-and-time" . From the YANG language view,= this error looks reasonable, but how to replace the target node with newly= deifned type? problem 2: when try to replace the type to leafref a xpath which not import= ed in the target module, it have the compile error too, then how to replace= the target node with another module's xpath? Thanks Walker(Guangying zheng) --_000_381D7D55085B1E4D8B581BD652E1E140C9313AA9nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

   When we try to imp= lementing, there are 3 questions want to clear on WG, please expert help to= answer the questions, thanks.

 

 

[Question 1]: whether "man= datory true" node can be deviated as "not-supported" ?<= /o:p>

 

[Question 2]: Whether can devia= tion YANG to expand the range of type?

   =

   example:=

   =

 target YANG node:  <= o:p>

 leaf a {

  type uint 8 {=

    range "= 1..50";

  }

}

 

deviation yang:

 

deviation "/a:a" {

  replace type {

    range "= 1..100";

  }

}

 

[Question 3]: How to use a new = type defined by "typedef" to deviate replace the target module's = type.        

 

example:

module example-base {

      = namespace "urn:example-base";

      = prefix base;

      =

     &= nbsp;container system {

     &= nbsp;  description

     &= nbsp;   "System group configuration.";

     &= nbsp;  leaf daytime {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf date {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf interface {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf status {

     &= nbsp;     type string;

     &= nbsp;     config false;

     &= nbsp;  }

      = }

}

 

module example-deviations {

     &= nbsp; yang-version 1.1;

     &= nbsp; namespace "urn:example:deviations";

     &= nbsp; prefix md;

 

     &= nbsp; import example-base {

     &= nbsp;   prefix base;

     &= nbsp; }

     &= nbsp;

     &= nbsp; import ietf-interfaces {

     &= nbsp;   prefix if;

     &= nbsp; }

     &= nbsp;

     &= nbsp; // here, define a new type with typedef statement

     &= nbsp; typedef date-and-time {

     &= nbsp;   type string {

     &= nbsp;     pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(= \.\d+)?'

     &= nbsp;       + '(Z|[\+\-]\d{2}:\d{2})'= ;

     &= nbsp;   }

     &= nbsp;  }

 

     &= nbsp; // try to replace the target node's type with new typedef type

     &= nbsp; deviation /base:system/base:date {

     &= nbsp;   deviate replace {

     &= nbsp;      type date-and-time;   &n= bsp;    

     &= nbsp;   }

      =  }

     &= nbsp;

     &= nbsp;  deviation /base:system/base:interface {<= /p>

     &= nbsp;   deviate replace {

     &= nbsp;      type leafref {

     &= nbsp;           &nbs= p;  path "/if:interfaces/if:interface/if:name";

     &= nbsp;          }  &n= bsp;           }

     &= nbsp; }

     &= nbsp; ...

     }=

    <= /span>

 

problem 1: when use new type de= fined in deviation YANG file to replace the target node's type, some tools = give compile error, because they can not find the definition of new type &q= uot;date-and-time" . From the YANG language view, this error looks reasonable, but how to replace the target node with= newly deifned type?

 

problem 2: when try to replace = the type to leafref a xpath which not imported in the target module, it hav= e the compile error too, then how to replace the target node with another m= odule's xpath?

 

 

Thanks

Walker(Guangying zheng)

--_000_381D7D55085B1E4D8B581BD652E1E140C9313AA9nkgeml513mbxchi_-- From nobody Tue Jul 10 22:50:30 2018 Return-Path: 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 95B4F130E02 for ; Tue, 10 Jul 2018 22:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 fB2mbhDtCQ_6 for ; Tue, 10 Jul 2018 22:50:26 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0089.outbound.protection.outlook.com [104.47.33.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9929126F72 for ; Tue, 10 Jul 2018 22:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EMCt7GZkD+m489Kg6It2jquHXTFtvJUB983WWw2AwAI=; b=YM+wWojCqr7AnLaKkPxcy+7VOo52YtKVYBadYxQ/iYUwFY9IfMTEFmWpGjZ2y6AZH8PYsyzuO6m1P/upCxJmsdNf/9GC5e6Efp2WUv2ekIIOJkFtpOu3QlmadC+kvRlOJ8e0CAI6glnk0bS9eYVC4CAM55DwOgXErL7bn3AdthM= Received: from DM6PR08CA0004.namprd08.prod.outlook.com (2603:10b6:5:80::17) by BY2PR0801MB1558.namprd08.prod.outlook.com (2a01:111:e400:5336::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Wed, 11 Jul 2018 05:50:23 +0000 Received: from CO1NAM03FT057.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::203) by DM6PR08CA0004.outlook.office365.com (2603:10b6:5:80::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.952.17 via Frontend Transport; Wed, 11 Jul 2018 05:50:16 +0000 Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=bestguesspass action=none header.from=Aviatnet.com; Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.52; helo=mail-send.aviatnet.com; Received: from mail-send.aviatnet.com (192.147.115.52) by CO1NAM03FT057.mail.protection.outlook.com (10.152.81.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.16 via Frontend Transport; Wed, 11 Jul 2018 05:50:15 +0000 From: Alex Campbell To: "Zhengguangying (Walker)" CC: "Qudan (Beijing-NOS)" , Qin Wu , Yangshouchuan , "Yangang (Routing Design)" , "netmod@ietf.org" Thread-Topic: [netmod] three questions about YANG deviation statement Thread-Index: AQHUGNsKUx473YM2FUGjIsC4DWoSIQ== Date: Wed, 11 Jul 2018 05:50:14 +0000 Message-ID: <1531288214709.78469@Aviatnet.com> References: <381D7D55085B1E4D8B581BD652E1E140C9313AA9@nkgeml513-mbx.china.huawei.com> In-Reply-To: <381D7D55085B1E4D8B581BD652E1E140C9313AA9@nkgeml513-mbx.china.huawei.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: multipart/alternative; boundary="_000_153128821470978469Aviatnetcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(346002)(136003)(2980300002)(438002)(53754006)(189003)(199004)(126002)(186003)(19627405001)(54896002)(117636001)(102836004)(76176011)(336012)(26005)(246002)(97876018)(7736002)(6916009)(7696005)(6486002)(476003)(356003)(7596002)(54906003)(30436002)(5660300001)(53546011)(7636002)(106002)(14444005)(3846002)(478600001)(36756003)(72206003)(229853002)(316002)(16586007)(86362001)(486006)(106466001)(36736006)(118246002)(11346002)(53416004)(446003)(956004)(2906002)(84326002)(8676002)(4546004)(6246003)(8936002)(2616005)(25786009)(6116002)(4326008)(19627315001)(19607625011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0801MB1558; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT057; 1:jfOJ2VLl32QFUW7G/PGWqkplg2DkiToTxW5YgLC8RXHoeiRGV86nnAKGT5MVms8FJFm/ePa0FGLkFzyk5FMhIbzNuTAest5Pf68DVccO9NIMINtnmfW+4ruEJ2/WpFg3 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dce1388d-142c-418a-cb75-08d5e6f22d5d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:BY2PR0801MB1558; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0801MB1558; 3:yYs7da54wqvCfUV1QTJHoYqvS9hKI3fLhjMa3uE+m/2t1Hkk1t28Wh/b7obzKhQJ4IegYs2zt5c71FO6rDAylrfkDVJTjOPtBFBPs4fnTmj81wxGPwOCO/10Ry2gxgW2oOYZJanFOjgz3OIbhtftVNKd99idgu/SLYpFba5+gWj25j9vkSsIDchz+W18jEeANtML3kEuB8e/ZdY3WyUQlrCIEkdbFKYeSzFzF0Hwg1vuFwSaMqCZ3LLPlDLG+3ljax0S+DgFBww0TLKupbJBSJDaMEJ9sZzLAQ8yloYE0gVO+5WiE9mNpHqvhewsIzIrb9SnIjzwWOXQXy082ZPs66lhQR9keMvrT/7+yVF7Xog=; 25:N99PUmplo/KbapHGanf6bFIorhm0l1snSgMXnrAyEHzPpLEk09ujiBwqdIYh5VqsBwjSmYWp0/Xc5z6uVt6aaekFBuuvy2ijUabohj1KBsrLkMSqvnGMCcmZErnt93asMbki4yDyOmSFy3fHTo3AUGfpAg8se4CetCWaOZ7ubAYYb38uAsv4kTZAkTfJFSECxdbwJoY3K6LyBa4vhuBOOMPoNjI0A0KevWnVir9lZTMDFqraYEpf6B26F0DTBHBWEYxMRBS38jKFNE0+KgKsupFYw9dDbocSclID9b0WVTJQ24wCYxn1XJ2BdR47B/x5zzoLNbTEfCqsbG6cxwFekQ== X-MS-TrafficTypeDiagnostic: BY2PR0801MB1558: X-Microsoft-Exchange-Diagnostics: 1; BY2PR0801MB1558; 31:WLX+TdbHyYKTfgFmBa7Jk2h5vjuvzfCgBw0Cswe2Qu4q+QLTr/aiFdoNavewj0iS8QHnVthzotR52JsPAT2vYVGC2fDKLu/0qgOkr/e+w6o8eEFns/RYm3cj/Ddv6QwYCUVXqe2+RQngLTdaAs0zW8PicWDQLPuLFynY86MvJj7Ev7LTdV0DNbjPVFuk7T0J34KoUCuCaoq2RbYqD/UJETJ9Ftc1j2uLTsTX60qF9O8=; 20:xJgGnfgEvGkje/0Y08XGFmHHBv0HZRNqV6qKuca028Y0VMeshz0EZpl+QoJK7b6jDJRnNMtv4PFCbV5WjzBOsBfL2ECpCmVapTCSayXdb7awf9ec3Q6Yt/uWbCy0bVAlgTp9x7kah/Y/QrjpBnQgSmrsDZ6PtWzIardz6rZw7K0yV3NL+Qr8S31yWL+mO7Xx4sS+PVjQA6ighvwUbGOmMaCfdz9iZW7C61HTCzcxTPAl/eGm2L8NW0k3l4QX8CcAKQ1DVm9bna8ZWEZrDnjIREIHiB7yjJr8PD5BPQt+pCGb5LSgWoSXjODXKWzQcllbwCYSkYtfEpI8C0+emhGYVOmA3WvAbLy58cz4jofcGXEZJY8gFDJUYZ/+u1CvfapLxbr+qGDkyu++W0cdCqFYgaMYuBOE2vU379cVQdwTmVCMvr0WLTGmVLpZ1SHul2VDYg7zuXw69fjXORcpvFXivGHd2+tcT0ka7C/IuqfY7ro+HaGR6Ha6IdJSrBTKDekl X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(50582790962513)(788757137089); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93004095)(3002001)(3231311)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BY2PR0801MB1558; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0801MB1558; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0801MB1558; 4:sJF8r0jywN1SNENKNZ6om5y7PA6dHioqKTqSJRxwHT+yPll2ESE3Y1dQES1rOXwUT2mGVzY5FTdJStzD+Jx0GNdTeApOmaJIB2CKTO2W7fq2cqUH8cnrNVwjH1FG5WwYdYW87RNUH0mra5jR2IyMjTRWN/vDGwAYhPq4KB+1zNyfAonGSePRd5WrmonTEnE9Vr3MltYsCrpTEekBG3DVqpF5DJOGlojPXkGpXeG3uTPEVKXRfqWcCvyKcC+LuYJXVct+IAQ5jnyGR1n9byyzDNtBPh9PohUazgQaErv43Jxq9dDd/nNkr1/pp346vQ6nGpCpv8a8mTsPNAYNYMcKz6NUShzht2RtfFQiP8YZ0pg= X-Forefront-PRVS: 0730093765 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0801MB1558; 23:C++h+Hqi8dkrFwQRo+BlQEFkJ814BPf2YO47qq3?= =?us-ascii?Q?Y6hewZ8qCfYq0YGnZ6lsWbVFRUlu6CHGN7o8wu5ICRqX7BCt67ac3jgRTEHd?= =?us-ascii?Q?JSOUGHha5Y+GLD16UBk/Ju3zodhNedobNwOfeBdoNiNdnoIAdh47c7u5Z95R?= =?us-ascii?Q?934JxbKv1ffjzuIv0mLPoSQs+G2FrI6w+Fs5T0dDvPu6IaXNbh2HF5lubqj3?= =?us-ascii?Q?UGiLlsJ27K5bZevcgZz93/qSlcj4NXUFu0+Ck2dlzxPX/BPVEW6HmG6DyEoB?= =?us-ascii?Q?PQktWSwffJC4TYd+KvYgZ8vdnZPy4IY5A+6Au9SYlLLRZMW/DwS31Xw/ktMV?= =?us-ascii?Q?io5fa96lYqmEI0wm6h52l87tq+Tl3UKnrH7VfH571SIbhEIYEjJAG8+D3oO0?= =?us-ascii?Q?ogto+tSfKxooVHpb5/DU0ydAS+0N8BBcGbcyoMhrHn60a+Sjfl7nYLXIT/mJ?= =?us-ascii?Q?yV0ebUBu4ze2vUfJsSMHCm3Wx11lBgY4MGW+7rY62CGeDMfKeMi2cmhoukD1?= =?us-ascii?Q?7ejEwIXFXprelHFeYucGdFaWJuAQzoCKdQy5Y0peSbdBWwS0JjWaaW+o41nC?= =?us-ascii?Q?yYjUx7hzbpXq9dzDhjlbHINYX53QNGbvJN8ekRs3jJ2kIG8iC3x4DwJAgKQR?= =?us-ascii?Q?dfoR7GjRkOoPL2hV5bgmnDizrAyvPs4PG4WyazRySlY9oc12oqhlIewk4cl9?= =?us-ascii?Q?qhDYn+vsdcuifTf3Ve4B32sLZR5c+nyMSvQuUK2Sum6nFWTa6Lifp9aHCry9?= =?us-ascii?Q?ZyyKYJRzGucjtA1X/0GgQr9upe52MJDY3dOMWC0EHjjvYUnOn3jtTvPEG2yf?= =?us-ascii?Q?p/4B/XhMki0s6gruOCLeCvRkEHC849cTUNp4b20FXza2/UvIFrtWP8N00Qim?= =?us-ascii?Q?qreSkCuqqtX0yTUqtBNcznJfZcCum0A1dBrLJBsXUnAPE68QFwii/0Xb9NUQ?= =?us-ascii?Q?5a8HALXhPpBuuQCVK1m57/I3sEqubHj1h/3BH8TxGUQCjKJNviA6FyMJI53R?= =?us-ascii?Q?9cQU93wyI6pYZxBViYlpubcIr6FncTQ7PUTq8aiN0G+WMdx+uiHsTtI+FANw?= =?us-ascii?Q?9lTbhNh8z0KxUysotdcj9vshwaSaA0b6TnWiP/ytAo+l7S4UqHisbVawcoX7?= =?us-ascii?Q?BqpG27fCfFBtT6dlZddFMtXpH+4livBVrHQAPAnr9n7hxnmYR+J4k6yGqeqK?= =?us-ascii?Q?EA2q5t9tne2U2nuKUGtstTPGfCeQKSqGSL47hKrSUSuwPkCULRTuhmS2Ny/G?= =?us-ascii?Q?v96GVz79nkLp6lMnI3bqwe5n3MVW1e6eDTv0gBfizWXl8A7EAUaGOe5K23jo?= =?us-ascii?Q?hc8GqLWIP9YJWfORuzOdF7ONQK0iyM8fcLk2YqfPiFiuW4FzbuDcIBduYkXZ?= =?us-ascii?Q?r6KM+fng4RJh1w+1Qprnz76zRKOc=3D?= X-Microsoft-Antispam-Message-Info: Mu2bMzvMAVMHUwEeZAz0ROfbfZWM3Jm0CBP4BoDc5XPwaINGzPPgIpSmQtBiiAzKD45cz/YYvrLo8KgtPltgIW95NupLSoNllkv5xaRJsWnGRKdpsE4sMoTGPp3laeWKVvGwcVdyUopsaYTadsxTPhkVSS1ZV5vQWq4oT/HePJyfnqAmo1KrTxc524PxBOeiLviNnDAveIbAW4PdzvE993J3kKjAfDsBWTL2TzsHRkABByWrgvKa6A+inT72+lFOnexutjvBt7WUqlNR7OqHNgz8fJ73CIqMoW7wv5YoN6zV70FMHwtaoJdUTbZfDZfvgA6d8QD8YkXxl69MgusRHQY6c1ZDt41yQy4eFTsdFjo= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0801MB1558; 6:mRI1kbnUiYPXpuGv6boett4npPUdOLyfcUWIb0tds98FgTRqFpTNvcTanHPLQ+ZEC+qiZVWMpepOph3YXY0EbRqbUgcyInffNz/AId7QyhSLBjU3osQOSPU5Yp7QxHSh7lkGj84LPKhcLKasE8D0XQFRoXegB3zO/+KYJOYkk7aZib50nnc6U0Yf23xph43d+CttIgrvno2eMxEOGlaFzOrxMkbgrngUDag4RemrGBN3if3BkwVYUs78yq9/lSVh5E57xw7nqEXaPEhG7xuHgulQ2axmOOyR1JetiNKvoWpdT5qnmmgQ9csALLLFVFnXs8bZwgu9ERlNg+VROo+y4bD/gKZpixxg+NERD0LkXbEIjAXhVwDvUVbvHRSdXjKT2HRIlQr8f2m3b2D9Lx6P6AYYxSBT/Mh1yoN1EOudHKkTjQHeBqQ1PVkFAmnGH35SoTrxAX1yFexmrh3dwVd1wQ==; 5:6ivS0z/+O33mXLOecnTTcXRW5WxTDaPcn5NyC8oPBsEWo0aBjDEfigckOjdKqhvIMRC8jjcXV1rfrW91UqD+6PxlDor7Z5FIn0f7NRcQiYUgxRTfBQRI6luhKvMNZKHWq5sRCmwAKInQLj1XxcAUeouxhjuKtKKk6cHga3PilF0=; 24:liUg6eor1judR1ReUFKe2agLFUJdlOVExnGIdj5bmqK1YWjzB+lYjGr25vX2GM13eu/esE/Xl6Mt9gkZA07Bq8QtGG0f5zwq2I8FTK3OOrY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0801MB1558; 7:aFFTZUH2tUbBcmIvoPz1/msJDd6oxS0Gaep9Y/2RDX/7iK7CSy0W2jQmMDUA6QGS1LhLNIMt+ElfQfMc+i37lKED0QfQm9eOzrZyBOYxAPwAFTZNkD6yt5Av6QjJydvnIV80ohhhy6aXqq/5Nd6C02phAWxk/Ddy1cb67vrTa5Oa3EGMi+Jgw8g6MwaJI2sM6ZKAf9+yhzt84dgFPEbQZFDd+PFhc1RR6zmxpJqd2QpwQlEltG9f8RVExj9EYsiG X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2018 05:50:15.8201 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dce1388d-142c-418a-cb75-08d5e6f22d5d X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52]; Helo=[mail-send.aviatnet.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0801MB1558 Archived-At: Subject: Re: [netmod] three questions about YANG deviation statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 05:50:29 -0000 --_000_153128821470978469Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, [Note I haven't tested these answers. Also this is a source level view, wit= h no regards for compatibility] [1] If you want to make a node optional (not mandatory), the way to do that= is: deviation "/a:a" { deviate replace { mandatory false; } } [2] Deviation statements can replace types arbitrarily. Example: deviation "/a:a" { deviate replace { type uint8 { range "1..100"; } } } The whole type is replaced, there isn't a way to replace just the range. [3] Based on RFC 7950 section 5.4, it looks like your YANG is correct. If s= ome tools cannot process the module it is a bug in the tool. However as a workaround, you could always define the type inline without a = typedef. Perhaps also try 'type md:date-and-time;' (i.e. add the prefix for the devi= ation module) I think your leafref problem is related. It seems that the tool is searchin= g for prefixes imported in the target module, which is not correct accordin= g to the RFC. ________________________________ From: netmod on behalf of Zhengguangying (Walker)= Sent: Wednesday, 11 July 2018 3:05 p.m. To: netmod@ietf.org; Yangang (Routing Design); Yangshouchuan; Qudan (Beijin= g-NOS); Qin Wu Subject: [netmod] three questions about YANG deviation statement Hi all, When we try to implementing, there are 3 questions want to clear on WG, = please expert help to answer the questions, thanks. [Question 1]: whether "mandatory true" node can be deviated as "not-support= ed" ? [Question 2]: Whether can deviation YANG to expand the range of type? example: target YANG node: leaf a { type uint 8 { range "1..50"; } } deviation yang: deviation "/a:a" { replace type { range "1..100"; } } [Question 3]: How to use a new type defined by "typedef" to deviate replace= the target module's type. example: module example-base { namespace "urn:example-base"; prefix base; container system { description "System group configuration."; leaf daytime { type string; } leaf date { type string; } leaf interface { type string; } leaf status { type string; config false; } } } module example-deviations { yang-version 1.1; namespace "urn:example:deviations"; prefix md; import example-base { prefix base; } import ietf-interfaces { prefix if; } // here, define a new type with typedef statement typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\+\-]\d{2}:\d{2})'; } } // try to replace the target node's type with new typedef type deviation /base:system/base:date { deviate replace { type date-and-time; } } deviation /base:system/base:interface { deviate replace { type leafref { path "/if:interfaces/if:interface/if:name"; } } } ... } problem 1: when use new type defined in deviation YANG file to replace the = target node's type, some tools give compile error, because they can not fin= d the definition of new type "date-and-time" . From the YANG language view,= this error looks reasonable, but how to replace the target node with newly= deifned type? problem 2: when try to replace the type to leafref a xpath which not import= ed in the target module, it have the compile error too, then how to replace= the target node with another module's xpath? Thanks Walker(Guangying zheng) --_000_153128821470978469Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


[Note I haven't tested these answers. Also this is a source level view, = with no regards for compatibility]


[1] If you want to make a node optional (not mandatory), the way to do t= hat is:

  deviation "/a:a" {

    deviate replace {

      mandatory false;

    }

  }


[2] Deviation statements can replace types arbitrarily. Example:

  deviation "/a:a" {

    deviate replace {

      type uint8 {

        range "1..100";

      }

    }

  }

The whole type is replaced, there isn't a way to replace just the range.=


[3] Based on RFC 7950 section 5.4, it looks like your YANG is correct. I= f some tools cannot process the module it is a bug in the tool.

However as a workaround, you could always define the type inline without= a typedef.

Perhaps also try 'type md:date-and-time;' (i.e. add the prefix for the d= eviation module)


I think your leafref problem is related. It seems that the tool is searc= hing for prefixes imported in the target module, which is not correct accor= ding to the RFC.



From: netmod <netmod-b= ounces@ietf.org> on behalf of Zhengguangying (Walker) <zhengguangying= @huawei.com>
Sent: Wednesday, 11 July 2018 3:05 p.m.
To: netmod@ietf.org; Yangang (Routing Design); Yangshouchuan; Qudan = (Beijing-NOS); Qin Wu
Subject: [netmod] three questions about YANG deviation statement
 

Hi all,

   When we try to imp= lementing, there are 3 questions want to clear on WG, please expert help to= answer the questions, thanks.

 

 

[Question 1]: whether "man= datory true" node can be deviated as "not-supported" ?

 

[Question 2]: Whether can devia= tion YANG to expand the range of type?

  

   example:

  

 target YANG node:  <= /span>

 leaf a {

  type uint 8 {

    range "= 1..50";

  }

}

 

deviation yang:

 

deviation "/a:a" {

  replace type {

    range "= 1..100";

  }

}


 

[Question 3]: How to use a new = type defined by "typedef" to deviate replace the target module's = type.        

 

example:

module example-base {

      = namespace "urn:example-base";

      = prefix base;

      =

     &= nbsp;container system {

     &= nbsp;  description

     &= nbsp;   "System group configuration.";

     &= nbsp;  leaf daytime {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf date {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf interface {

     &= nbsp;     type string;

     &= nbsp;  }

     &= nbsp;  leaf status {

     &= nbsp;     type string;

     &= nbsp;     config false;

     &= nbsp;  }

      = }

}

 

module example-deviations {

     &= nbsp; yang-version 1.1;

     &= nbsp; namespace "urn:example:deviations";

     &= nbsp; prefix md;

 

     &= nbsp; import example-base {

     &= nbsp;   prefix base;

     &= nbsp; }

     &= nbsp;

     &= nbsp; import ietf-interfaces {

     &= nbsp;   prefix if;

     &= nbsp; }

     &= nbsp;

     &= nbsp; // here, define a new type with typedef statement

     &= nbsp; typedef date-and-time {

     &= nbsp;   type string {

     &= nbsp;     pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(= \.\d+)?'

     &= nbsp;       + '(Z|[\+\-]\d{2}:\d{2})'= ;

     &= nbsp;   }

     &= nbsp;  }

 

     &= nbsp; // try to replace the target node's type with new typedef type=

     &= nbsp; deviation /base:system/base:date {

     &= nbsp;   deviate replace {

     &= nbsp;      type date-and-time;   &n= bsp;    

     &= nbsp;   }

      =  }

     &= nbsp;

     &= nbsp;  deviation /base:system/base:interface {

     &= nbsp;   deviate replace {

     &= nbsp;      type leafref {

     &= nbsp;           &nbs= p;  path "/if:interfaces/if:interface/if:name";

     &= nbsp;          }  &n= bsp;           }

     &= nbsp; }

     &= nbsp; ...

     }

   

 

problem 1: when use new type de= fined in deviation YANG file to replace the target node's type, some tools = give compile error, because they can not find the definition of new type &q= uot;date-and-time" . From the YANG language view, this error looks reasonable, but how to replace the target node with= newly deifned type?

 

problem 2: when try to replace = the type to leafref a xpath which not imported in the target module, it hav= e the compile error too, then how to replace the target node with another m= odule's xpath?

 

 

Thanks

Walker(Guangying zheng)<= /p>

--_000_153128821470978469Aviatnetcom_-- From nobody Wed Jul 11 07:23:29 2018 Return-Path: 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 B4109130E8D for ; Wed, 11 Jul 2018 07:23:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mCJESXvO06qJ for ; Wed, 11 Jul 2018 07:23:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F1F6212DD85 for ; Wed, 11 Jul 2018 07:23:25 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 40E96F9086305 for ; Wed, 11 Jul 2018 15:23:22 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 11 Jul 2018 15:23:23 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.43]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0382.000; Wed, 11 Jul 2018 22:23:13 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: NMDA output with "when' condition Thread-Index: AdQZIp19LVusgahBSiC+KJHgNolIDA== Date: Wed, 11 Jul 2018 14:23:12 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBD305F@dggeml510-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBD305Fdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] NMDA output with "when' condition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 14:23:28 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BBD305Fdggeml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Consider the model below: ---------------------------------- list list1{ key f1; leaf f1{ type string; } leaf f2{ when "../f1=3D'hello'"; type string; } } The intention of this model is to allow configuration of leaf f2 by user, o= nly when value of f1 is 'hello'. For all other values of f1, say 'foo', the= system will internally choose some value say 'bar'. When query all fields on , using condition f1=3D'foo', if need= to output its corresponding f2 value (i.e 'bar') the when condition will g= et violated . Is there some way to keep the restriction on , but= relaxing it when showing the output ? RFC 8342 has the below section , but I think we cannot use the statements b= elow as there is no "abnormal" value here. SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possible that constraints MAY be violated under some circumstances (e.g., an abnormal value is "in use", the structure of a list is being modified, or remnant configuration (see Section 5.3.1) still exists). Any help is appreciated. With Regards, Rohit R Ranade --_000_991B70D8B4112A4699D5C00DDBBF878A6BBD305Fdggeml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Consider the model below:<= /o:p>

-------------------------------= ---

list list1{

  key f1;

  leaf f1{

    type string;=

  }

  leaf f2{

    when ".= ./f1=3D'hello'";

     &= nbsp;   type string;

  }

}

 

The intention of this model is = to allow configuration of leaf f2 by user, only when value of f1 is 'hello'= . For all other values of f1, say 'foo', the system will internally choose = some value say 'bar'.

When query all fields on <op= erational>, using condition f1=3D'foo', if need to output its correspond= ing f2 value (i.e ‘bar’) the when condition will get violated .=  Is there some way to keep the restriction on <running> , but relaxing it when showing the <operational> output ?

 

RFC 8342 has the below section = , but I think we cannot use the statements below as there is no “abno= rmal” value here.

   <operational> SHOULD confo= rm to any constraints specified in the data

   model, but given the principal a= im of returning "in use" values, it

   is possible that constraints MAY= be violated under some circumstances

   (e.g., an abnormal value is "in use", the structure of a list is

   being modified, or remnant confi= guration (see Section 5.3.1) still

   exists).

 

Any help is appreciated.

 

With Regards,=

Rohit R Ranade

 

--_000_991B70D8B4112A4699D5C00DDBBF878A6BBD305Fdggeml510mbxchi_-- From nobody Wed Jul 11 07:39:01 2018 Return-Path: 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 577FA1277CC for ; Wed, 11 Jul 2018 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 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 Qjx9is4TqYbU for ; Wed, 11 Jul 2018 07:38:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F1D126CB6 for ; Wed, 11 Jul 2018 07:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11859; q=dns/txt; s=iport; t=1531319937; x=1532529537; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=hI6gP9TykZcqEXFcIyd0fSaFIJjbmLlTv+/8zdvSiCM=; b=ImtmRxxrzQDqwTdxjbODeSzbjhPGBXW/XjWskTOxGr021n8ypewbGljw allIhxD9pvpjYa5nV2bTQDTOv5uXT86IWVUA32pOHwfIrzXfEU2iHyLuI NqzTbuZzY7xXTIn4xsbRJob4ucdE0IFH7H9Zz+Yhasx5R5nWHsFqQ/yEo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCkFUZb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTgVltEiiMXY04LJAkhwgLGAEKhANGAoJeOBQBAgEBAgEBAm0?= =?us-ascii?q?cDIU3AQEBAwEBK0EbCxguJzAGAQwGAgEBgxwBgX8PqycfhDyFJQWKVT+BECe?= =?us-ascii?q?CaoMZAQGHNgKHZIoLh2gJjyEGiBmFSIw+hVSBWCGBUjMaCBsVO4JpixWFPz4?= =?us-ascii?q?wjWIBAQ?= X-IronPort-AV: E=Sophos;i="5.51,338,1526342400"; d="scan'208,217";a="5107055" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 14:38:55 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6BEcsPi028701; Wed, 11 Jul 2018 14:38:54 GMT To: Rohit R Ranade , "netmod@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A6BBD305F@dggeml510-mbx.china.huawei.com> From: Robert Wilton Message-ID: <1ba44952-9ff7-ede1-985c-b03e08ff7daa@cisco.com> Date: Wed, 11 Jul 2018 15:38:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBD305F@dggeml510-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------72279F4B8F825AA7AF62AC8B" Content-Language: en-US Archived-At: Subject: Re: [netmod] NMDA output with "when' condition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 14:39:00 -0000 This is a multi-part message in MIME format. --------------72279F4B8F825AA7AF62AC8B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Rohit, The rule is that the operational state datastore always reports the value in use.  So, if f1="foo" and f2="bar" then that is what should be returned.  The fact that it violates a when statement is allowed, but in this scenario, not ideal. However, if leaf f2 can hold values even when f1 is not set to "hello" then I don't think the model below is as clear as it could be. Perhaps it would be better as: list list1{   key f1;   leaf f1{     type string;   }   leaf f2{     config false;     type string;   }   leaf f2-cfg-override {     when ".../f1='hello'";     type string;     description "Force f2 override"   } Or, alternatively, remove the when statements from f2, perhaps add a default value "bar", and state in the description that it is only configurable when "f1 is set to hello". Thanks, Rob On 11/07/2018 15:23, Rohit R Ranade wrote: > > Hi All, > > Consider the model below: > > ---------------------------------- > > list list1{ > >   key f1; > >   leaf f1{ > >     type string; > >   } > >   leaf f2{ > >     when ".../f1='hello'"; > >          type string; > >   } > > } > > The intention of this model is to allow configuration of leaf f2 by > user, only when value of f1 is 'hello'.. For all other values of f1, > say 'foo', the system will internally choose some value say 'bar'. > > When query all fields on , using condition f1='foo', if > need to output its corresponding f2 value (i.e ‘bar’) the when > condition will get violated .  Is there some way to keep the > restriction on , but relaxing it when showing the > output ? > > RFC 8342 has the below section , but I think we cannot use the > statements below as there is no “abnormal” value here. > >    SHOULD conform to any constraints specified in the data > >    model, but given the principal aim of returning "in use" values, it > >    is possible that constraints MAY be violated under some circumstances > >    (e.g., an *abnormal value* is "in use", the structure of a list is > >    being modified, or remnant configuration (see Section 5.3.1) still > > exists). > > Any help is appreciated. > > With Regards, > > Rohit R Ranade > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------72279F4B8F825AA7AF62AC8B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Rohit,

The rule is that the operational state datastore always reports the value in use.  So, if f1="foo" and f2="bar" then that is what should be returned.  The fact that it violates a when statement is allowed, but in this scenario, not ideal.

However, if leaf f2 can hold values even when f1 is not set to "hello" then I don't think the model below is as clear as it could be.

Perhaps it would be better as:

list list1{

  key f1;

  leaf f1{

    type string;

  }

  leaf f2{

    config false;

    type string;

  }

  leaf f2-cfg-override {

    when ".../f1='hello'";

    type string;

    description "Force f2 override"

  }

Or, alternatively, remove the when statements from f2, perhaps add a default value "bar", and state in the description that it is only configurable when "f1 is set to hello".

Thanks,
Rob
On 11/07/2018 15:23, Rohit R Ranade wrote:

Hi All,

 

Consider the model below:

----------------------------------

list list1{

  key f1;

  leaf f1{

    type string;

  }

  leaf f2{

    when ".../f1='hello'";

         type string;

  }

}

 

The intention of this model is to allow configuration of leaf f2 by user, only when value of f1 is 'hello'.. For all other values of f1, say 'foo', the system will internally choose some value say 'bar'.

When query all fields on <operational>, using condition f1='foo', if need to output its corresponding f2 value (i.e ‘bar’) the when condition will get violated .  Is there some way to keep the restriction on <running> , but relaxing it when showing the <operational> output ?

 

RFC 8342 has the below section , but I think we cannot use the statements below as there is no “abnormal” value here.

   <operational> SHOULD conform to any constraints specified in the data

   model, but given the principal aim of returning "in use" values, it

   is possible that constraints MAY be violated under some circumstances

   (e.g., an abnormal value is "in use", the structure of a list is

   being modified, or remnant configuration (see Section 5.3.1) still

   exists).

 

Any help is appreciated.

 

With Regards,

Rohit R Ranade

 



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------72279F4B8F825AA7AF62AC8B-- From nobody Wed Jul 11 10:31:05 2018 Return-Path: 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 DD713130E40 for ; Wed, 11 Jul 2018 10:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 y3lwoMX0aj6Y for ; Wed, 11 Jul 2018 10:31:01 -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 089EB130DF2 for ; Wed, 11 Jul 2018 10:31:00 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6BHT0Za020542 for ; Wed, 11 Jul 2018 10:31:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=qqsj05zM8ciGT0Nqz7rggL1WhCjAAjd0uBv/ONSfhLk=; b=uxzG5LOsfo5wEFrnx3yu1VtiRwAtwClEmsetBqdOJp1NT4ElkjOBGDg9v1BPfUv6QvR5 rp2ECz4e4Mg3FTz81vTv/3c+eQhyaDSSsp9k5D6jYdQrlhwyizJq7e83G+7SKWBcVZqi /P5Z9ifSLX/XKf+e/nLQbl8/I7VeaUC3BHdDd9ovCvAgZUWfJRc7qZx7xAIYNc07Sxrp g/j1VcKPdX37IeZaiJreMCEh6JAGdeWLWdjsTfUHrzI2uUkPlKbQSFMBkr/juZhOKlSa lbRX76jl//rwppKOUHcuyQpttTSZGlTeQTLxqg2SgTAXb6vxjNZ55BMS7TkhhiuvuHCt Pw== Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp0247.outbound.protection.outlook.com [216.32.181.247]) by mx0b-00273201.pphosted.com with ESMTP id 2k5mn5rbt7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 11 Jul 2018 10:30:59 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4552.namprd05.prod.outlook.com (52.135.203.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.14; Wed, 11 Jul 2018 17:30:58 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0952.017; Wed, 11 Jul 2018 17:30:58 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: removing a node from a grouping Thread-Index: AQHUGTztxnT5XKTefkqKIIHQ7mrEOw== Date: Wed, 11 Jul 2018 17:30:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4552; 7:vdgjL6wCC3ImiMbjTGYcxhXthL6WS7u81+46TLN/ZYeuGr7mMI2zyvpPeVNp4CSJzUs7zfe8tb3UjxC7nuF7jx7/icGPjWTyaLzjSaemhvB2Um9NZB/Rna1wCJjvfnj/M0svUrKbl8Nj9qGxMFemEbHLFvvlhpCx4mZzcifITsaoVxW1cGKRl9NFugsUwdY9dV6pUI+LEjzdY0OAnARZSEy23xWR57PgvR4oYOGJzgylUnKN2KQTBSALSczxK0Fx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f2974e0d-c3f4-4016-3412-08d5e754105f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4552; x-ms-traffictypediagnostic: BYAPR05MB4552: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4552; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4552; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(136003)(346002)(366004)(199004)(189003)(305945005)(6506007)(3846002)(36756003)(6512007)(58126008)(66066001)(26005)(316002)(8936002)(186003)(1730700003)(6916009)(8676002)(486006)(2906002)(105586002)(102836004)(81156014)(81166006)(2900100001)(6116002)(476003)(33656002)(2616005)(5660300001)(99286004)(106356001)(86362001)(2501003)(68736007)(5250100002)(82746002)(53936002)(25786009)(6436002)(256004)(7736002)(6486002)(5640700003)(2351001)(14454004)(97736004)(83716003)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4552; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: byQbvwXFsrtljlZsO+LHfhFZos5P8DNoAPpgsgZuMXVWSQTspezfOjEcTynx4B8nXYs10LBqkIUDBvDrHRvt+Nb3PI0Y3vSu91CUQT/OUukGKnXGw7LmLTAHLtindt0FYkO3nwweGO99ChI5aa2Nc1//UGUy9wNniQurD0qEVhtJ4+sDKQaBg9ovwFb7rs7J8nAiIkaOyIjgxNB9xjGzDeJbNMp19t0Pvx8bHCd2/vzKluksLJtfCWevxBIIrxRbtK4T+s/LFAENz/24lh5kyUT+EUQ3z0jxSLt1951zPF1jFzRZXFrpnQ/RUPucs1P2by5MDgDRK1zdFSrVWsGcZukMZqH/YzGm0Ppy/2gRxzY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9C95551267FD7744B7C283C8CE3FC8FA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f2974e0d-c3f4-4016-3412-08d5e754105f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 17:30:57.9305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4552 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-11_04:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=654 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807110187 Archived-At: Subject: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:31:03 -0000 DQpTYXkgdGhlcmUgaXM6DQoNCiAgZ3JvdXBpbmcgImZvby1iYXItZXRjIiB7DQogICAgY29udGFp bmVyLW9yLWxlYWYgImZvbyIgeyAuLi4gfQ0KICAgIGNvbnRhaW5lci1vci1sZWFmICJiYXIiIHsg Li4uIH0NCiAgICAuLi4gIC8vIHRoZSAiZXRjIiA7KQ0KICB9DQoNCkFuZCB0aGUgZ29hbCBpcyB0 byB1c2UgdGhlIGdyb3VwaW5nIHNhbnMgdGhlICJmb28iIG5vZGUuDQpDYW4gYSAid2hlbiIgc3Rh dGVtZW50IHRoYXQgYWx3YXlzIGV2YWx1YXRlcyB0byAiZmFsc2UiDQpkbyBpdD8NCg0KICBncm91 cGluZyAiYmFyLWV0YyIgew0KICAgIHVzZXMgImZvby1iYXItZXRjIiB7DQogICAgICByZWZpbmUg Imxpc3RlbiIgew0KICAgICAgICB3aGVuICJmYWxzZSgpIjsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KQW55IGJldHRlciBpZGVhcz8NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0K From nobody Wed Jul 11 19:17:53 2018 Return-Path: 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 A8590130FCF; Wed, 11 Jul 2018 19:17:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KJcJKzWQnmyg; Wed, 11 Jul 2018 19:17:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A20E9131001; Wed, 11 Jul 2018 19:17:35 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 92B548A924A39; Thu, 12 Jul 2018 03:17:31 +0100 (IST) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 03:17:33 +0100 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.167]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 10:17:27 +0800 From: wangzitao To: NetMod WG CC: NETMOD Working Group Thread-Topic: Please send your Netmod Slides to me Thread-Index: AdQZhjIUpTs5wqRfSNu85Io6QCKJTw== Date: Thu, 12 Jul 2018 02:17:27 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.245] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2C29B79EDGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Please send your Netmod Slides to me X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 02:17:45 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2C29B79EDGGEMM527MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, Netmod final agenda has been posted: https://tools.ietf.org/wg/netmod/agenda And presenters, Please send your slides to our chairs and CC to me. Kindly reminder- our 1st meeting is on Tuesday, so please be sure to send y= our slides no later than Monday night. Best Regards! -Michael --_000_E6BC9BBCBCACC246846FC685F9FF41EA2C29B79EDGGEMM527MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

Netmod final agenda has been posted:

= https://tools.ietf.org/wg/netmod/agenda

 

And presenters,

Please send your slides to our chairs and CC to me.<= o:p>

Kindly reminder- our 1st meeting is on Tu= esday, so please be sure to send your slides no later than Monday night.

 

Best Regards!

-Michael

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2C29B79EDGGEMM527MBXchi_-- From nobody Wed Jul 11 22:55:40 2018 Return-Path: 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 1811E130E96 for ; Wed, 11 Jul 2018 22:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 1QlSriKX_ix8 for ; Wed, 11 Jul 2018 22:55:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0053.outbound.protection.outlook.com [104.47.32.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EA4130E0F for ; Wed, 11 Jul 2018 22:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RSBIy9xn1TgBla9rHUIxYSnprQxo1pM0aXOrmz/nImA=; b=XfPy76fzPX3LI0b9ezzPHTy38MQo4JJy8KQ6aFsThzJdBEJW9dmZdfdrGRxnlLKlPvcyfSf/c3+tdktNpOeNTwUIw+TNQINkTT64UNm38tnz3CM3vM8lx7EqylKnOYk9LpoPq4fP7UFdw7vILH7g3pmJ/Wn4RY7DxKGjziZAX0s= Received: from CY4PR08CA0025.namprd08.prod.outlook.com (10.173.247.139) by CY1PR0801MB2298.namprd08.prod.outlook.com (10.174.128.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.26; Thu, 12 Jul 2018 05:55:34 +0000 Received: from DM3NAM03FT020.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::200) by CY4PR08CA0025.outlook.office365.com (2603:10b6:903:151::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.952.17 via Frontend Transport; Thu, 12 Jul 2018 05:55:34 +0000 Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.53 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.53; helo=mail-send.aviatnet.com; Received: from mail-send.aviatnet.com (192.147.115.53) by DM3NAM03FT020.mail.protection.outlook.com (10.152.82.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.952.17 via Frontend Transport; Thu, 12 Jul 2018 05:55:34 +0000 From: Hayden Brown To: "netmod@ietf.org" Thread-Topic: YANG schema mount - any early implementations? Thread-Index: AdQZpO5cY5J6A+jKS6e9MANjFdoExA== Date: Thu, 12 Jul 2018 05:55:32 +0000 Message-ID: <3081377e997e43469e2c4c443ee041bb@USP-EXCHPROD01.GNET.global.vpn> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: multipart/alternative; boundary="_000_3081377e997e43469e2c4c443ee041bbUSPEXCHPROD01GNETglobal_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.147.115.53; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39850400004)(2980300002)(438002)(199004)(53754006)(189003)(165144002)(790700001)(3846002)(126002)(6306002)(9686003)(108616005)(54896002)(24736004)(6116002)(2351001)(956004)(5640700003)(16586007)(25786009)(486006)(478600001)(72206003)(6512007)(336012)(106002)(6916009)(6486002)(260700001)(86362001)(36736006)(316002)(1730700003)(561944003)(2501003)(8676002)(8936002)(102836004)(5660300001)(356003)(118246002)(186003)(476003)(2906002)(26005)(246002)(7736002)(7636002)(7596002)(53416004)(106466001)(6346003)(84326002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0801MB2298; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT020; 1:MKchtVOahNQQig3xmT5dcUyxext6YZ+cm9Y7+fYhpAthTjq99wz+DMduB+DjdFdpfJOjgQ7+8GJ/jeKFQu+wkdLnLj3Ew6T6j/zUxnqXyxQcANTOnnc6qKpU71+Yc9OF X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8b5e28ec-1dba-4014-d0f5-08d5e7bc1573 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:CY1PR0801MB2298; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0801MB2298; 3:Sf6ObGjS6y2I6XFSzV3jD7wy2+SKUjJZmdZZxbqDbfRZOl5lagF4wvMAAm7m2ZJi1iKdlh6BF1M+rMODF6egQaq2MdW3/UyeiHjVmSjnQXZ0pRN15GLKqsdFCWMsvvhv6+F1ZW60w8jZP7TBzmAZgx0Gr1cxZh+EAWNKv6tLCOfmKXR/03ZsbmlUS0sLPbrAe9sI8G9782P6EgIJC8cpNpx1AV2a0Ajx6fXl6Y6vq0k3r7va9DOPU884vX5pURlC86LaqL18SJo2aIUWhkIoPvSApIJl4GDdAhrgQTdA9urDrMeMEmF+LFGQ/H2h3cTus7hbR0Nu46sLz/yDEUXz7W2PaCbQUQuGugnN0S3wIMg=; 25:GaJgrXpTK3Gm3QKoXOa9wxbdw7Ni2Z8NuCbSsb8o04oy8sT2PslDx3gALll3AfDWEEGfz4YlQ5PNQdFfrra402K19rPfzeSoATlTGD3w+AJmZ52lthEd+tRIh7GVRpPksW1w3qT/a+WWvv/H8ugtxEuOaquksLpoRPn9s9nsB9en9gUul0ym6Tar2YG0KuvlgRKKggOorX9yJBxyskaBcBNPFCbv/Ru/ZgbSw8h24ZwWgej9NX+snmkyghY7gl6GE+D3RSyicIT5Fclpckgcy/ivKtafLTcLSGvB3zWizYOtWa+Mrfiy8jiRyutC+iTeblLx8he5Taraul0BO4F1DQ== X-MS-TrafficTypeDiagnostic: CY1PR0801MB2298: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0801MB2298; 31:cVQTq5vMnfYRnWhromEoMSK0rJ4m2AGmTPW4EAgdgq8y/W89Bn+Lce2VKsyzCoHg6MdNo/CqQgosVwTPRtmwxWO3vZmfn/xrfDE+rWix51tOl4h2X5yJ7VA8zT0un6ma9CO8dJiVUfsdXcqyyOBqGyFePUxKVwAeupGaDxFKG3hnfTC4ngTGBxFPiP0rNvCIWB0e2U9SXKkDC0VgBoOVLz9dK9iVaJF51sGtPUuviNE=; 20:wEKWDm31t7diZeaD9+pR7WptPwwyYB9DD10eHLm8S7ZWeseH2hBNXftkEQdEgQZRgKBbfg49DKpgnLvh/MLolnAVMPw7LCphZAhY/YypII72rLKIfj0BYgaU7gdNWGGrGkd/4qkhCdHwnL/eJpWZej3aqZmZMaBRpmPMgwgsLKh2lVAEFyDFzgKn+u30FLuO4sikqZmTMeBLLiPum1+jwhWSAyowCDLpPBq/Mpovgaydjk1JgaUC437adqW5knSZUe/o1TsIzNYAmx20tg7bgXgmPO+YbvYlIBvc91GzdvIZC8chWrRZWzymDmvTYHT+dccpJgf1JPpBsMqB/TafmJtQATZafrNxczqJW9an+m9qkC8yDyHdBU8R12Se2X3eEJDYD49R4HWR4PfVW0TkX+NZUpFwD0ByCBIXSYyS3kzIhdbVcJ4E2JHqiMqpZnBCAva+JN5wqFx/rTX+MedlSYOQNJ1+R0tSI0qcTUV5Xk6y7oS8UoT29DFF2R1fWnPG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(158342451672863)(21748063052155); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93004095)(3002001)(10201501046)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:CY1PR0801MB2298; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0801MB2298; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0801MB2298; 4:3NUILv9y8DfYHIq4jFg2ieLBnbfOggeL2+jJkTIuhjs4PZMuB7YgkfvjVNxvF8+93b1X+ylPkzmUUAfNMCDxl1sLeQyzXPk/85IyjDXi5hY6bkdf3zHfaveHOe6WEysI7f6xcD5GlpAs6O3oqM4ejb7GcSt1CBCe7tzHoXST/yS+bIVRlgBhOWz3AYP5c/N7X7iA/UY1B7wAntRD4UX+bcRKpFbZ2c/k4vP3rhvXvZCfWM0N/esfi8YfadP3HYQo/YvRnCE3Yg2PASUBMbZkxvsMxcBouhLwgSZu6wd5SxOMhBrAmJI24WXu8iO/ERBgxTK69leeJIm23Pdxuf+rgbFy8zer8N5QRSTbikL1FKWB0llDnCI3nxQaudJeLFxW X-Forefront-PRVS: 0731AA2DE6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0801MB2298; 23:YVdnG9TokDTdyeRigah8NPxkwWG5C02RgaBA50V?= =?us-ascii?Q?OLHpuCYahAgmLt2KdtpPNgeu+4QpbTotO6Hi4Es+fsnXiAfKobGW6oRcySwb?= =?us-ascii?Q?9ge4I1f+jDYV+858v0H01dVg5TGGLKOqvAEB243BGFVXzHkkhArd1Om8GW/X?= =?us-ascii?Q?8ohh5xTarY4sakf8AdLQDuOWtCdf//Q3cy1e/W/J5Z4/7xhzu4Ptw1/rs20F?= =?us-ascii?Q?v8hNsNvEyQwBwsGV8woEjHYC9WPyqjVrJDa3J3iRKJggD/xDx+LTaBgfBrKK?= =?us-ascii?Q?NhMDXih4ocqKSo8OqcF2m5DZYgYg0tU7wXyFV6lspospAMk2bU/5MMu9+mef?= =?us-ascii?Q?VSDsKqXxh/w1Mao0deIonCVM6f6ODQJnlbX82eJzyFfFeuvRnC4k/syVflmt?= =?us-ascii?Q?gitr2dYtiwJTq0g60BI9qtTnAm+409HU6K5J790kbkMLtWVXyHnPzNmvqXcI?= =?us-ascii?Q?9TFzXQ2sZBaxLwxASsc3ZhDNzUC5OpZ6DY8hbU7a4lCoT7cCQYIeEJv0Xv6h?= =?us-ascii?Q?jlSHZazoOMSWcva/aQCX5+SVqUozTcx5YpCcH1gEv4sR3TXdU7oW2IT/Gd38?= =?us-ascii?Q?r+U0ewzQgV6vRPlFqzsy7ruA3yfYQWeCy1QLFKuEKFPEMiAlwV616XT/KIyo?= =?us-ascii?Q?M4hMbEhZyG65jjWiXrBTaec6sNWUHdT0npi3B8DCND41SUcc1B0xGryDXTz9?= =?us-ascii?Q?1f2jmLzIBPtMaCeQCoWVP65VO2rZqTMA3RpdgaELvgz6ApC7Q3qpdpIwyTyA?= =?us-ascii?Q?9qq3rMHF6MCjsGmvJVtOe6FpOYRbWoACHRlo1upvDrCWj18T10JG2bpMiWVg?= =?us-ascii?Q?JyXGAdXqpRi67Vh61hf+vlsZ2lG5b9SZhteXxwzwLT9F3snbla04sLq9JCfr?= =?us-ascii?Q?EoZDBeaky618mFEd8pLbKMrE+wYcMPdznxbkmQkcsJqSDXWL2psPSIL8Pd3g?= =?us-ascii?Q?HceqbFIknNfOe3Ih0s4ArEZjx4d9bC7q3e4MjccovQreCM2JtSJj0tBQW567?= =?us-ascii?Q?MzSSfgPv1aXx7UjKsVLGaYRHQJACBC8lG9VZ07ujoPpzgr0ycbD5KAaU6Ezb?= =?us-ascii?Q?LQ2VGRNd24D5LNohB3QwwyU6cYtxm1bn/HKOTBL6D8N0myaO+ExJ3qtmh+hV?= =?us-ascii?Q?40SIr55sT3+z6pGM/eB7Ej+UCSplE+kf1EqaApPc/nZSVP9g5Qb++nMUs3ZL?= =?us-ascii?Q?xIU2FcuCjKvLnDOxab9zI1HlPkhpXwJYAkEsUjKhBS+81aFXySKvtfgc9tzR?= =?us-ascii?Q?zjlFeB5TAfvi4npuvn5d3FTgjaY26HOInPf5F031J?= X-Microsoft-Antispam-Message-Info: vxAcMen7eSF2YpAgwb9X2Rb7QWLvaD9Mh6nk1yjpE/kYALnFBFGQxIb7iIEbr9C0NBRDgqtoOKOXyIKIArciFkuJKmcKnl/mMdYLL/6VxA/3x4CGwHWFrKyJ9LQbWyCFSUtG03ZEgReIe4no1vghrNr0a8yYUdvljjsNURO7SruT6mYAw4LmMJOqlMxQF5yqlGDof0ZajzcEJthowaARhabWltdNowrMGZJ8WcAhc120dFkCR/S2akGl02M+1CldygbbHOiXYbhPQDDPfnoC1uHaeBuqegqhM+or65oKYpXZZgp2WmiO3Art/3kxlGfKuwWPgaexbLl5XE+2oJ+e7uRn2DzRSghlMHTQHhlpJDU= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0801MB2298; 6:kntm+C3mRm2FBm8f/i1ZjFFaw+Z0TItjt+HSSS7VKhDapzAUGRLiA6dmTQR2HoiIMQ01poH4eISgX6JdJe/rHAGSn3GK0OuH76UJoqFPNZikR5ZafmPk5XFiB1Gt0F3xwKmJZnSI4amqjjys5WzLGK3N6gvM7JvYJ55OiXN3CA36aW1t0VytPjQPmjx+z/SOkUiXrlcf1JQOegjW7wjSSZYOejnh9ZQ176NYPRzeRJ9ZizYzkCF8GX/rKcjSG1EfVbArzAY/IBFFqkc6GTnCxSvbhCjRQbT/fxKZNCDH5/+RSSBWjnRYtULXCM3TfMwoqva9Nn7gwM3ImbnWM1YyLy2u0HcEdzn7i/+y6zd2VepHx7p8uavhLWtRdhs0ZLQ3zq/RiLv4geoSE9L9rhpMH7uFyDLdDFKAasLo3DFTVgE77FJQFmCY4nrXl0fNb0+dHe2sYiyMCx+bm7Jop357Kg==; 5:v/URGgDKDQ9UyBPG+Kb1pDER6BybYqia5ib7Op7EQneMp8DUT01ku313hlrGBcpQJQ5MhU6gSGN5DTX8tzV78RVMaQ+XC9l4HPeVN9uCXYXTMKuTn0jzuw2c7l3gMAxK4KiDmeV47ilSW/VfoyGI9+mqILht9KRKDOXzkLf5xTM=; 24:DnSlGcXJelm5p7luenXqs19lIAfHaiDCh+c9FgGEJGpAETRt+JhF3f1zVxizW/Z7M+JNFBRmr7RuMUHihPV9mBVnsLcH4+qXAosx5OYQbvc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0801MB2298; 7:bv7MC8jipXDAuNnp3eedrWiylSCkmRFuTBl1HfRqi6w29YaoqOWkc3VY+//CS6AGiBpEEtpFV6GuRjtadpkTUvNQL5QC9qRB5cu4vg1s9DabelFgk2QzABN0GX0i60ednVMlmMlnvnwl5SujRAxPVCEgFhtd6RH5vGutWg/X8XoiIkd6EmF61OK9CWD/xyKJtCKQhvPriC/r9QUmMqhdkdB0I4hB5EnKJKWjDofiiHryZXzqsHbZIPWaGmG3UB5O X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2018 05:55:34.1010 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8b5e28ec-1dba-4014-d0f5-08d5e7bc1573 X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.53]; Helo=[mail-send.aviatnet.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0801MB2298 Archived-At: Subject: [netmod] YANG schema mount - any early implementations? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 05:55:39 -0000 --_000_3081377e997e43469e2c4c443ee041bbUSPEXCHPROD01GNETglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, I have been following with interest the progress of the development of the = YANG schema mount proposed RFC. I was wondering if anybody within the working group mailing list might know= of any early implementations of the current draft schema mount mechanism? I understand that the schema mount proposal is still effectively in a state= of flux, but I am curious as to whether there are there any publicly visib= le implementations or deployments of schema mount on a NETCONF or RESTCONF = server that those interested could experiment with (e.g. to aid in client d= evelopment)? Thanks and regards, Hayden --_000_3081377e997e43469e2c4c443ee041bbUSPEXCHPROD01GNETglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

H= ello everyone,

&= nbsp;

&= nbsp;

I= have been following with interest the progress of the development of the Y= ANG schema mount proposed RFC.

&= nbsp;

I= was wondering if anybody within the working group mailing list might = know of any early implementations of the current draft schema mount mechanism?

&= nbsp;

I= understand that the schema mount proposal is still effectively in a s= tate of flux, but I am curious as to whether there are there any publicly visible implementations or deployments of schema mount on a N= ETCONF or RESTCONF server that those interested could experiment = with (e.g. to aid in client development)?

&= nbsp;

&= nbsp;

&= nbsp;

T= hanks and regards,

&= nbsp;

H= ayden

 

--_000_3081377e997e43469e2c4c443ee041bbUSPEXCHPROD01GNETglobal_-- From nobody Thu Jul 12 01:53:22 2018 Return-Path: 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 74C3C130E09 for ; Thu, 12 Jul 2018 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 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 tZGj-GmVAL9Y for ; Thu, 12 Jul 2018 01:53:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1571294D0 for ; Thu, 12 Jul 2018 01:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1263; q=dns/txt; s=iport; t=1531385598; x=1532595198; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uJo00PSRgZSKviYCf+IVw4by+KYTXp/4LQvWL+UAW0g=; b=AALTa0F5TtgbnyXl3pFJMH6EPbH01ZI3eSvawhnu+fyQKtDMtC7LozSZ 2YzwIMuwsd8dCXvh/z4PQ3OdTmYzg9cA+uaDi2hnp9uJZSAo5Vt5bkWh0 cXd25/2sXwCu2qmiZu9P8IGfi0TDmnY5+W7SPWq4KTHh+vU/1jSB2Nt+L c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQA/Fkdb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQsbRIog3qIY405JJcsCxgLhANGAoJkOBQBAgEBAgEBAm0?= =?us-ascii?q?cDIU3AQEEAQEhDwEFNhsLDgoCAiYCAicwBgEMBgIBAReDBQGBfw+pPIEuhFu?= =?us-ascii?q?FZAWBC4lKP4E3DIJegxkBAYRhglUCmVcJjyEGiBmFSIw+hVSBWCGBUjMaCBs?= =?us-ascii?q?VO4JpixWFPz4wjFgBAQ?= X-IronPort-AV: E=Sophos;i="5.51,342,1526342400"; d="scan'208";a="5123008" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 08:53:15 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6C8rFpb023191; Thu, 12 Jul 2018 08:53:15 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> Date: Thu, 12 Jul 2018 09:53:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 08:53:21 -0000 Hi Kent, I'm not sure that sec 7.13.2 of 7950 allows refine to add a when statement, although an equivalent solution would be refine it with an if-feature statement for a feature that is never enabled. Ideally, I think that the groupings would be split up, so that they build on each other. grouping "foo" { container-or-leaf "foo" { ... } } grouping "bar-etc" { container-or-leaf "bar" { ... } ... // the "etc" ;) } grouping "foo-bar-etc" { grouping "foo"; grouping "bar-etc";  } Thanks, Rob On 11/07/2018 18:30, Kent Watsen wrote: > Say there is: > > grouping "foo-bar-etc" { > container-or-leaf "foo" { ... } > container-or-leaf "bar" { ... } > ... // the "etc" ;) > } > > And the goal is to use the grouping sans the "foo" node. > Can a "when" statement that always evaluates to "false" > do it? > > grouping "bar-etc" { > uses "foo-bar-etc" { > refine "listen" { > when "false()"; > } > } > } > > Any better ideas? > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Jul 13 14:35:23 2018 Return-Path: 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 2B131130F3C for ; Fri, 13 Jul 2018 14:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 TcxDiu_Y7s9k for ; Fri, 13 Jul 2018 14:35:16 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627DB130E37 for ; Fri, 13 Jul 2018 14:35:16 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c5-v6so28373072qth.5 for ; Fri, 13 Jul 2018 14:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C1fYqtftFNsyqEXBXYW8Vc2SXAZDREMSpZiNFSgRwj8=; b=IuXCzLkufz8nKpv0hs2Y9B+m1We+BHzBiiIZ41cxmkiX03kcwrigFHP/whChbvil3j YHezUORrP7Y9+3LfGScmbhJsx593xhJEZP2V9nIThM9HQ5V0cl9zCggyCAPZx0+ZuBPK ihiyvhUixPVNnGIBHYpySli4VpqvMjE8+jHaETEUea60e9EgI1IFE9Cfms5++j8jN29w bl8bVPeNuQCOgYoFTAMl6dl0dNpmN8lshvR10A06lpWmhExM2OdWvpRN0peKfCvhlkHQ Ee3zcv82yVkZpZRIdk0gaRP/vU9eYFFVl8a5daHoRV3SBcS5QuW31z/RTmfLHly+HZoR Ejcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=C1fYqtftFNsyqEXBXYW8Vc2SXAZDREMSpZiNFSgRwj8=; b=YBEXor039Uu9f334eMZcqoBml9LVv0rQ46X0ri6ioJRGljRCPu/xpeL+nGYftz+qIo wSPVy4kXVi+Ah95sDXV5LPXpmfxMMvLZhrImK8ETJWvtanlLSZ6W/bge8nxWnGdEHdVw MK+gG25tHwhqEYp6yDxv7Nl6GRuNA6BxRbgoZ3sAtu4MXilsxQy1Fcl0RyEfqXjtzefQ eAh3xikvYgsDe8PrN/tl7LT+ipR1DeGG1570mv2qeWm3bR5GcNlUwVw0j/8gqLNg8pT4 gVilfA8hwk77dgtMHgKdljA8Mh7t1GMYjWf/Wa1B5EBYA7CfnpL8W2F1ay4KpjmflpNa qI3A== X-Gm-Message-State: AOUpUlHZVhXlmEd3hWh0f1Sy/KrPU8nTSIatcmVCiQPpn/qxjSA1Ph9E Xy99I4n9leAE2gnzB/aMJfp9DGdcj2w= X-Google-Smtp-Source: AAOMgpc9jZ9vbJVRNTmX+rYmgtih/sSARJfxzG1vwLABp45YRAhbDaSJTrA4cLEl5DjIjeHNzSPu4A== X-Received: by 2002:a0c:cd83:: with SMTP id v3-v6mr8958030qvm.232.1531517715443; Fri, 13 Jul 2018 14:35:15 -0700 (PDT) Received: from [172.20.33.141] ([207.134.103.162]) by smtp.gmail.com with ESMTPSA id d4-v6sm23952945qtd.72.2018.07.13.14.35.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 14:35:14 -0700 (PDT) From: Alexander Pelov Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 13 Jul 2018 17:35:12 -0400 In-Reply-To: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> Cc: core@ietf.org, netmod@ietf.org, yot@ietf.org, hackathon@ietf.org To: Alexander Pelov References: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [netmod] Hackathon - open-source CoMI implementation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 21:35:21 -0000 --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hell all, In anticipation of tomorrow's Hackathon on CoMI, please find the steps = of preparation and the things we will be doing tomorrow and on Sunday : https://etherpad.tools.ietf.org/p/comi = We will be combining work from F-Interop, CoAP, CBOR, and YDK, so that = one is going to be really interesting. Drop by if you have expertise and = even if you don't participate directly, if you are able to share some of = your wisdom. See you tomorrow, Alexander > On 6 Jul 2018, at 11:03, Alexander Pelov wrote: >=20 > Dear all, >=20 > The way to use YANG for IoT - CoMI - has been stable for some time and = the missing piece as always has been.. running OPEN-SOURCE code! >=20 > Montreal is the place to change that! Join us at the Hackathon in the = first structured effort to provide an open-source implementation of a = CoMI server and CoMI client. > I personally will be coding in Python, but in case other folks want to = use something else - that's even better. >=20 > See you on the Hackathon! > Alexander >=20 > PS. > If people knowledgable in YDK want to join, that would be really = perfect! >=20 >=20 > The description is here: > https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon >=20 --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hell all,

In anticipation of tomorrow's Hackathon on CoMI, please find = the steps of preparation and the things we will be doing tomorrow and on = Sunday :

https://etherpad.tools.ietf.org/p/comi

We will be combining work from = F-Interop, CoAP, CBOR, and YDK, so that one is going to be really = interesting. Drop by if you have expertise and even if you don't = participate directly, if you are able to share some of your = wisdom.

See = you tomorrow,
Alexander




On 6 Jul 2018, at 11:03, Alexander Pelov <a@ackl.io> wrote:

Dear = all,

The way to use YANG for IoT - CoMI - = has been stable for some time and the missing piece as always has been.. = running OPEN-SOURCE code!

Montreal is the = place to change that! Join us at the Hackathon in the first structured = effort to provide an open-source implementation of a CoMI server and = CoMI client.
I personally will be coding in Python, but in = case other folks want to use something else - that's even better.

See you on the Hackathon!
Alexander

PS.
If = people knowledgable in YDK want to join, that would be really = perfect!


The description is = here:
https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon

= --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F-- From nobody Fri Jul 13 15:08:35 2018 Return-Path: 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 5662A126CB6; Fri, 13 Jul 2018 15:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 W-xYaORuJ8qv; Fri, 13 Jul 2018 15:08:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C7009130F0F; Fri, 13 Jul 2018 15:08:30 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C036C19FA433D; Fri, 13 Jul 2018 17:39:50 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 13 Jul 2018 17:39:50 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.30]) by SJCEML702-CHM.china.huawei.com ([169.254.4.236]) with mapi id 14.03.0399.000; Fri, 13 Jul 2018 09:39:36 -0700 From: Igor Bryskin To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" , Xufeng Liu , Alexander Clemm , "Eric Voit (evoit)" , Henk Birkholz , Tianran Zhou Thread-Topic: IETF 102 presentation requests Thread-Index: AQHUCYGXFJ0cQU23ZUutsc2s3fO3UqRzFlgAgBplA4A= Date: Fri, 13 Jul 2018 16:39:36 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C3ED7A3@sjceml521-mbx.china.huawei.com> References: <35F026C4-5C20-4E8B-B1F0-C6E2D7781E47@juniper.net> <87B93335-EA1A-4CE2-84F8-9A1B5558035B@juniper.net> In-Reply-To: <87B93335-EA1A-4CE2-84F8-9A1B5558035B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.76] Content-Type: multipart/mixed; boundary="_002_0C72C38E7EBC34499E8A9E7DD00786391C3ED7A3sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] IETF 102 presentation requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 22:08:34 -0000 --_002_0C72C38E7EBC34499E8A9E7DD00786391C3ED7A3sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, Please, find in the attached. Igor -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, June 26, 2018 10:29 AM To: netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: Re: [netmod] IETF 102 presentation requests Just a quick reminder for folks to send presentation requests. Please have requests in no later than this Sunday (July 1st). K. =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D Dear WG, The chairs notice that the preliminary IETF 102 Agenda has been posted [1].= NETMOD is scheduled to meet Tuesday afternoon and Friday morning, both se= ssions are two hours. *** Yes, NETMOD is meeting on Friday, the last day of the conference! *** If you are interested in presenting to the WG, please send your presentatio= n requests to the "netmod-chairs" alias with the following information, for= each presentation request, if more than one: - name of the drafts (if any) - name of presentation (usually same as the name of the draft) - name of the presenters - desired time request in minutes. [1] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_meeting_102_agenda.html&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb= 3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DnEV2vxzatg= mspqtjKXgo65Ks6s4yoUMZhzJXu_zH7lo&s=3Duo8nf0yFGjYAZxAwBRhUZkmMjunNiNHUUgiYO= EakOxA&e=3D Thanks! Kent (and Lou and Joel) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_002_0C72C38E7EBC34499E8A9E7DD00786391C3ED7A3sjceml521mbxchi_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="IETF102 Presentation of Generalized Network Control Automation (GNCA) model.pptx" Content-Description: IETF102 Presentation of Generalized Network Control Automation (GNCA) model.pptx Content-Disposition: attachment; filename="IETF102 Presentation of Generalized Network Control Automation (GNCA) model.pptx"; size=83669; creation-date="Wed, 11 Jul 2018 13:02:17 GMT"; modification-date="Thu, 12 Jul 2018 16:21:03 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCRtStyigIAAPkUAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WNtymzAQfe9M/4HhtWNk0jZNMsZ56OWpl8wk/QAV1jYtSBoku/HfdxG+yAw1IkLjF2MZa3XYPWd1 xOz+uSyCDVQy5ywJ42gaBsBSnuVsmYQ/n75MbsJAKsoyWnAGSbgFGd7PX7+aPW0FyABnM5mEK6XE HSEyXUFJZcQFMLyz4FVJFQ6rJRE0/UOXQK6m02uScqaAqYmqY4Tz2Q8EUOUZBA+0Ut9piesQIRSR Bf4om8v7CCOGwcdmar16ElIhijylCrGTDcta6074YpGnkPF0XeJqkahA4lX/vSwiHfxNHZTYIbi+ HIKvdMvXapeJZvDBC5omtlVWOjDdXBAT4wrkY0OY4/d4bETH0FZJ+kalQnE1FG4Go0PSRG5iW2Ha oXk7dmoGC+rdRRDUbeCh4kKOvfohsFUVOuTjJx9ukvbTdt0w+WnEdpgU7nBA9OeVM4F0GCu27DTr p3cMQeD+0C/Zho2su6fAPusdGvXz/Hbc0w22A5OfTn6K6RMs6LpQwedndG6NWfwtYNkyZHlZezx9 A01Vx5wKCtma02PidsYxwpnauclVLuSesR0rnHeJPXbP5Kazus1g6DfNYVTSnO0fwsb9xn5qPAiC n+2pD4I2XHsbZQzc+4BZEKyPEbsP0/+EODomY6FzmPCIox0NQS050xZqhWeQTQSaJKhUDge5WTF1 6oygVZjBvjL2U4dzFWifVmM/+0QfBEV/FfCotgWM7m6N0H0oDNaeHFk91eV0o+ri6EEf6VoqXjoT tAkzVCAdO3fsRyz9GWnz1c/bBCui7Cji593BEAS3zrx4SePa5PDXy3H0ENgqBx3k9JOPfm4e1cor GF6TvWFMcXaHRIl+cTn/BwAA//8DAFBLAwQUAAYACAAAACEAR78a0BMBAAB1AwAACwAIAl9yZWxz Ly5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKzTS0vEMBAA4Lvgfwi5b9NdH4hsuhcR9iZSf8CYTNto8yCZyu6/NxR8FGoV 3GMyj3zJkO3uYHv2hjEZ7yRfFyVn6JTXxrWSP9X3qxvOEoHT0HuHkh8x8V11frZ9xB4oF6XOhMRy F5ck74jCrRBJdWghFT6gy5HGRwuUl7EVAdQrtCg2ZXkt4vcevJr0ZHstedzrC87qY8gn/6e3sEig gUAoH3EVYpZFMvkurIbYIkmuvXrI22nMKLKai3nQ5rQg6gb77MD0M5TPWPESsP0JtP47yDeNUXjn 1WDR0cwQxDTjyxQCiRAx5bJx7EsvdHVKkBoSefvLyMacJdLlKUl4IHQa9TIKQvgQiclnqd4BAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5E P2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7N clFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZx m2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwME FAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVs c4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1 rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRc ZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5By fue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBN QjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC 3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t 6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAA ACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzhI/BCsIw EETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrf abjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO 1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+ qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMS54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/ r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8ucii UDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2D eS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc4SPwQrCMBBE74L/ EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306r HQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYq zRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9z mw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3m zU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul 2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWD s3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3 AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU5LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI Uy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7B k4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZ akhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP// AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTQu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIQAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMy54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgie RD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgO zXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sG cZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsD BBQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8 hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1p xFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihr kHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAPCqnDPYAAAAzgEAACEAAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHOskcFqwzAMhu+DvYPRfXaSQxmjTi9jUNip7R7A 2EpilsjGcsfy9vUOAwcKu+ymX0KfPtD+8L3M4gsT+0AaWtmAQLLBeRo1fFzenp5BcDbkzBwINazI cOgfH/YnnE0uSzz5yKJQiDVMOccXpdhOuBiWISKVyRDSYnKJaVTR2E8zouqaZqdSzYB+wxRHpyEd XQfissZy+W92GAZv8TXY64KU75xQFDLyefYOC9WkEbMGKas2V3Urizuo+1rtf2rxj9G7WcM1b7yq PqsqdL9mavOF/gYAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMTAueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK /XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvI olA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwd g3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA LfEhHIQBAAA4CwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8ls1qwzAMgO+DvUPwfXWc/o+mvYxBD4OxdQ/gJWoa ltjB8rr17WfSkaalqBfjS0BKIn98ihUvVr91Fe3BYKlVysQgZhGoTOelKlL2sXl+mLEIrVS5rLSC lB0A2Wp5f7d4g0pa9xLuygYjV0VhynbWNo+cY7aDWuJAN6Dcna02tbQuNAVvZPYlC+BJHE+46ddg y7Oa0TpPmVnnbv3NoXEr366tt9sygyedfdeg7JUlOFZlDq6gNAXYlLUhHrPTgSNl/DqEGAaiEAmJ 4VXGvoSfV6MbPAnpUhRFKBekimmghkwoEyIJRCEEieFVRmMALz6LLkVRBHNBQYiJz44obQFfJFow pz3SSyLvBWSLEjdX/Y0xKz8reLeHyg3jbpj1kqQhnyDtAL0U1Ev+z9bjE6Qgr30jxvyYdCO8yzn1 p/+zETGFMQ5EMaIgRCgKQWN43TjEhzEnZcx9tsS601HvFNKGvL2SW2Tkk4EwMaRMeBVBQMwoCBFK hehc8LPz7vIPAAD//wMAUEsDBBQABgAIAAAAIQBwIsXNrAIAAH0OAAAUAAAAcHB0L3ByZXNlbnRh dGlvbi54bWzsl9FumzAUhu8n7R2Qb6eWmIAhKKTSNlWq1EnR0j6AC06DagyynSzp0+/YOMUJvegD cIf9+xz//nJ8Asu7Y8ODA5OqbkWB8O0MBUyUbVWL1wI9P93fZChQmoqK8lawAp2YQner79+WXd5J ppjQVENoAGmEymmBdlp3eRiqcscaqm7bjgnQtq1sqIahfA0rSf9B+oaH0WxGwobWArl4+ZX4drut S/a7LfcNbN8nkYxbH2pXd+qcrftKNv8Ul5YUPbDN/kUxfd8KrYAOWsGxFa/+UKWZfKgelb6aCeqq QBGO0zibkxjYydzMwFqMwtUy/CxctJqpq5QXc14S4rJc6IMN39JD1ZtJiOciMvHWxIecevJ8JJPY k+ORnPhHTMbywou23i/2JlBtH4DSUTTBnpyN5ciTF2N57sl4NtYTX7c/z6U5nxsegyM+OPwJOR8N HqMjPhts2fXl4f+Im/egPBZogeN4NgNa5alAJEsyO9CnDm6kKiVjIj46B7YyXNjHShN2zmELoGJb uuf6iR31Rp84Wy1pDnPrtXRPf9cy4NQ0ASZunjeGXugv4QeOO1jTUPlYIHBG+Ss0EI4CSPNEXzbv 5x2BsuZ2CaOP4qd8MxcJcutauCFE72Ar6AnrvSh1f9HsZsaFgkwYDoyCNyZNj4KuAReR5qrldXVf c24Hpt+wX1wGBwq76WN/365W2V0Dw21LS2D3oxE3XJvD0ZzRK4HRXijVlVCqAQc4tGQcD5MIHqMB TZykxvDEx0JxfOYDn74sJz4HbqA4PvHAB89TTKYCMrfKUHGAEg9QFmW2PUwdyFBxgMgAKIoyKKCp BUEFGSoOUOoBSuP51KPtH5eh4gBlAyBDB94/piZ94IaKA7TwAJEknZq0rSBDxX7ojF8x4fXW/9pa /QcAAP//AwBQSwMEFAAGAAgAAAAhAFBmIuh8BAAABxUAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54 bWzsWO1v2jgY/37S/Q9WPu0+MAghQFFhanvXblLHqsFOd/fNJA6xcOyc7VDoX3+P7QQGSzvKdcdN mlQVx/bz9nte7Mfnb1YZQ0siFRV86PmvWx4iPBIx5fOh92l63eh7SGnMY8wEJ0NvTZT3ZvTzT+f5 QLEYATVXAzz0Uq3zQbOpopRkWL0WOeGwlgiZYQ2fct6MJb4HrhlrtlutbjPDlHslvTyEXiQJjciv IioywrVjIgnDGjRXKc1VxS0/hFsuiQI2lnpHpRFYFk1YbH5VPpWEmBFf3sh8kt9Juzxe3klEY8DL QxxnAIvXLBfKbfaTwzYYNPfI5xUnPFglMhud4wHYhlZDD8Bfm/9AhAdkpVHkJqPtbJR+qNkbpb/V 7G5WAkCDjVBjlbPoS3PCypwp1Ywgf2OV24qB9FZEC4W4ADuN+c68aLysmBmbDfs8RXqdAzKRlpZb udWtW0gqEmVhrXTdgNENO0EHAAbbO2EAIbMLS6/fCvrhmYcMOO1e2w/7Z1ZGxQhkOM75QK8uRbw2 oM7g1yiIBxxC86LQIqHaGPH5ElN6oteMWDcAWHhgKSQ4nWGTF4Q3Pk08FFOprWeQyvQVIxgyqHSe Ht0QTiRm9IHEaEz0vZALdCW4loIhIxfyAgIX/XkxvkHvRUwYMkpoq4oTZwU/KtMqV6pu98++omRp 5RO81QMgCcn5FcsgkRPdmMm1WlDe4ERHgicNvLGpsQaQGq32QfZYmb0dmYdaVk9qPGltJDy+wxJ/ 3EfQkrX2JQIZeBpipooVGz4mkh9Pl26VLhNGY4LGRTYjEt0xHJFUsBjGoYlIqCdVfhyVQVBngTWU YXDP3wWWmkgPqg+UBr99RFaFgXUxBG43COFvr9y0/SDoGnRMXgXd0G9bIwAfV6yeSCvruGcnjwlz JQDBa8qY/TBnCLliEi0xG3p65XtmmhUZ5Imb64bGgU5ekZmKaLeCMW4atLUnkeFiM+ozAbAGmWw4 6pG/E6PHxEBvEwPFTNuqaX3yr31ezFzVLB39bD+7oyTo9/2g33FIVQfKmd/p2Pi3Hm71+t2+K+QH uNjA9gKVsyYH62rou7mQ6NIVGvTqbYHvCUVTEqVcMDGnRP1S4z+byI+V7AMF/1EkhM8Pq8g1LF0F G93S4mgWO3DYrDhRirzagfhYXE9pwe/fvQWCaVxdIvZiHu6Jh59zpw6qraq2KNur1RP3q5rM2rGg TLMLRlYIrl9Z9t/UiFPG8lvCFy9TU0rwLqlcwGXlAR2f50RC/wYX9ZpL8LXEBU9FQuSL5GCpM5q8 m+5W/mdlwQn8920Cf0oxl5ijv1JRHBD63y1IW/R2+6+a+vB/8u0Ptb/B1X0L6t4Rsl34ESQv1iht Qa3Q/rJDtg2heyeDYfV0FjH5HucflrbRghdBaFqhF4OpHN4AoY6brdst0HbTDBZMs6z5rYJnEHhC wkAM26a8emuLCzhpKI9JQjnVxEPwiKehIR56nMAbJrRi8JAytc9OOvsohC7bJsvJaO5Ym1EpDobQ Xo/+AQAA//8DAFBLAwQUAAYACAAAACEA9r+Q1nkCAABhBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU5 LnhtbMRVTU8bMRC9V+p/GO2pPcAClapqlQTRlPZCISLQ+2BP2G29tmVPQvLvO/ZmoaGBph9SL+uv mbfz3ow9g+Nla2BBITbODovD/YMCyCqnG3s7LK6vPu69KyAyWo3GWRoWK4rF8ejli4GvotEg3jZW OCxqZl+VZVQ1tRj3nScrZzMXWmRZhttSB7wT1NaURwcHb8sWG1us/cMu/m42axR9cGrekuUOJJBB lshj3fjYo/ld0HygKDDZeyOkkTBTU6PTGP1VIEozu/gU/NRPQj4+X0wCNFr0KsBiK7IU5fpgbZaX VsxkUj5yv+2RsFrOQjsaYCXcYDksRPxV+ooTVrRkUN2methV9cUWW1WfbrEu+x9IBPc/Taw6Rj/T OerpXDVsCA7vWXWmKK5nTn2LYJ3wTPQ7eup80YMlzgne18ArL8pwglrbdYdZj94+iqZZLF6+d3qV iN/ImDexMpGnvDKUBZGwsRJw+Yj8BlOFkt27nhZwk1Ohm8BZKYgtjw2hVPRaTB6djk9gymGueB5o INKwZGaNR1ZPMODlL2ATWawkDGHQhyvTTs+nVX3Tqzp2lqXmYGJQUe2MpgBHf6dxo6VC+jT8V3kX wuyRrNtz9WyW8nXagOkUz7I/lf1nEc+ayOBmYJxCA5Mv8XfRd6it8/TMmQ3gP4oVpEJ0kx60vROV BjAS/QbuDnLsEHC+HHO/gfwPI4ZX7GButQPMNCLMgmuBa5KXI0m1nSg0FhRGAuk0KWU/2Pc4dxgh 0FdSTBpuVtkkUpAG9voRmafu9H2xPHOb86Xunn6Z9t1AmfAZ/cUil7U0OaYwzlte2lpCE9MHk4Qh XeQ7AAAA//8DAFBLAwQUAAYACAAAACEAzvZ7PHgCAACXBgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUx MC54bWy0Vd9v2jAQfp+0/+GU9zbApGmKgIox2k3aWlTgYY/GPog1x7Zsk8J/v7OTtKJrGdqPl8Sx v/ty33eXy/BqXymo0Xlp9CjrX/YyQM2NkHo7ylbL64sPGfjAtGDKaBxlB/TZ1fjtm6EtvBJA0doX bJSVIdgizz0vsWL+0ljUdLYxrmKBHt02F449EGul8kGv9z6vmNRZG+/OiTebjeT4yfBdhTo0JA4V C5S5L6X1HZs9h8069ESToo9SGpMyvlAi3r1dOsS40vWNsws7d+n4tp47kIL8ykCzimzJ8vaghaVH TTBa5M/Ctx0TK/YbV42HrCBtsB9lZP4hXimIFbgPwJtN/rTLy7sXsLycvYDOuxdQBo8vjaoaRb/K GXRyljIohP6jqgbKKPSr4T88aEM6o/xGHr+tO7KoOdLbEsLBkjMhUrW45jD50eE9eZrMCvuPRhyi 8DXd0yYrlA+LcFCYDKG0WUHkdCH7FYsdivpitchgnUohpAvJKfBVmCpk1NGtmWE8LSkAPXipOcKX 2fK63+sPyaJAFWp5UYs5c+z+N/RRNCsoHVLSpU3LxtfX3X3XuTs1OlDvwVwxjqVRAh0M/s5rKahT unL8N5tPGjyBCjmZLH0F0oPUwRmx4yggGBC4kRphNp0A1qTdQy0ZfJ/c3sCzGrxc4JNvnq8Wn/8B jd+tPXfSpoFylFVT7VRy+i5faZJXUzyK/gN5ExrAbsfDzmE0trEyucqNSxMQYX2AUCJwJWNjRZu1 CZIGZjMe4UGGEhLcW6PjdG/rcKTzDHEnej99As3ApGU3Q7ly35i9q5Nw+jUEdNO0ZSmJyEbQJ0jk oNn7EwAA//8DAFBLAwQUAAYACAAAACEArLgnv5kDAAABCgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUx Mi54bWy8VsFy2zYQPacz/YcdntqDItmJUpdjOeMqTnpoHU1odyZHCFiKmIIABgBV6ZbfyO/1S7oA SMVyJDtNZqIDBQK7i933HpY4f7lpFazReWn0rDh5OikANTdC6tWsuL15PTorwAemBVNG46zYoi9e Xvz4w7ktvRJA3tqXbFY0IdhyPPa8wZb5p8aiprXauJYFenWrsXDsH4raqvHpZPJi3DKpi97ffYm/ qWvJ8ZXhXYs65CAOFQuUuW+k9UM0+yXRrENPYZL3XkoXVBmvlIj/3t44xDjS6zfOVnbh0vL1euFA CsKrAM1agqUY9wu9WXrVZEaD8T331RCJlZvatRfnrKTaYDMrCPxtfJITK3ETgOdJ/mmWN28P2PLm 6oD1eNiAMthtGqvKFX1ezulQzo0MCuFkV1U2ZeT6h+F/e9CG6ozl5/L49XoIFmuO4W0DYWsJmRBD 9XZ5MeEx2HvCNIEVNr8ZsY2FL+k/BmGlJvlcdsHUMkBtdKg4UxTy1wn9Usi7xsqHKmwVJvCoRFam GI6oUiyqGfXotipgmWgT0oWEKvg2zBUyUn8PfLh4hbXUpFW4ml/C1Zp04mEtGby/vH4Di9vqd6i6 pedO2iS+cwI6EM/9jqjFgjn27v7Guy0jaKykFAmJoWwaZl6Os/NsYGdOUFBOsFCMY2OUQAenEQ9S 7sDE/+RKClLaQOcRmiKk9wT7fPoLHeak2pMXk0kcJ/gH7Z49m0zPokFU8PRkMn2+Iy5HSmVnxQxI 3OX0mABOpzGo0pXl71B0PNJA+X+TLnb0HFJEhY6aJPzEAoQGoTWxB4GpAaM6gBtdy1XnUjv5udwT RKY68U2PLOxld03dtNdBnjos1geTGsEThyvpA7Vv2NvzmPYfDBcLy+VI0pejDhniGYjTDmt0DkUW v78jfghOrlYEDfO9cy1dcsvze2kdhuI1yflmk3Sz7OYNc8DpMStG/RHvMfsKgDqPPuWfzuxe2rVU CbZggFGHGQ0MIiSHhMO/Hz761AKktl0AqdNS/KZF5qk3JANlqCvB4i9/vNSvSP1BwUHG+PsJ7Qk3 VhKWggVG1wHjMF4KAs1YE8UiYLl9BGgyMzvM9iEXsMMQ6KYxSCpTN8BMTU/IeM5Hl+m4R5EQI7hB 3sXp4+g/2o/vH/jDMv3sxH5b3Ee9++5w6CuRuma+mtBwuK1w5f5k9u06qY0uYaTveZqydB5jNDL9 ZBJj0C3nPwAAAP//AwBQSwMEFAAGAAgAAAAhAKetzxUFAwAAkQcAABYAAABwcHQvc2xpZGVzL3Ns aWRlMTMueG1srFVRUxMxEH53xv+wc8/WAxwdvaEwWNEXgQ7FHxBye72MuSQmudL+e7/kelBUFEZ4 oLlk98vu9+1uDo/XnaYV+6CsmRb7r/cKYiNtrcxyWny7+jx5X1CIwtRCW8PTYsOhOD56+eLQVUHX BG8TKjEt2hhdVZZBttyJ8No6NjhrrO9ExKdflrUXN0DtdHmwt/eu7IQyxdbfP8bfNo2S/MnKvmMT BxDPWkREHlrlwojmHoPmPAfAZO97IR0hM7nQdfoN7sozp5VZffFu4eY+H5+v5p5UDb4KMqIDLUW5 Pdia5U8DMyzKX9yXI5Ko1o3vjg5FhdxoPS1A/ib9h5OoeB1JDpvyble2F3+wle3pH6zL8QJEcHtp ymrI6Pd0DsZ0rlTUTPu3WQ2mAq5frfweyFjkmdIf0pPnqxEs5ZzgXUtx48BMTFBbu+Ew8zHaB3Ca yYrrj7bepMSv8ZtARGVQPid9tI2K1FgTF1JoQH7Yw1+G3DXWIS7iRnMmDymKKmN4SKVFqmY2k2+L gq6zbLXyMbNKoYszzQLVvyU+Hp3OTuh0hfIIhMqncxsVam+oNJpZP5bdIRiOEHh7FZt6Lry4/MeN iTNRIUIQMWaN5SDLw+K8GcWZgQnERnMtJLdW1+zpINGBwh2FeKJUqkahjWo+l0oHb6ESabNw8pLr XqZGxS3/Jd4/ZTM7WpEKFFsma/SGkqYix4A9EUmBRI+NQMBkGWFyoyKqFg5SKxB8T91BsSzbQ4X1 19jOeh2VQ1MhjkDS9hie10zRq+WSPdcUVAcTYdj2QW9eEQvZkm3oplVYOJskV0IjzCUbRB4xSym5 ZNSAqYtz9AcMatU0wESJYGRPouo4lXFpPXl2jIZUK0YL7xT1s6aKzvED37t3UMchiCWDeKn7mgMh 4lpE6xVCTqxz6rg8T3PX5c9JkHhKqDfqR38/5sEwWmqEVFphkjNmhN/RbwCc3AtCPrl5b1X9S9vm 7h2eCizH10NqfybcxSqPITyKqLdZ3nKQLqHB9M4kYeDV+QkAAP//AwBQSwMEFAAGAAgAAAAhAERQ TDwMAgAAAwUAABYAAABwcHQvc2xpZGVzL3NsaWRlMTQueG1stJTbbhMxEIbvkXgHy/ftpkFCaJWk EgF6A2nEpuJ6Ys9mrfok2w3J2zP27qYCSolU9WbXh5nf838+zK4PRrM9hqicnfOrywlnaIWTyu7m /G7z5eIDZzGBlaCdxTk/YuTXi7dvZr6OWjLKtrGGOe9S8nVVRdGhgXjpPFqaa10wkKgbdpUM8JNU ja6mk8n7yoCyfMgP5+S7tlUCPznxYNCmXiSghkSVx075OKr5c9R8wEgyJfu3khbkTDRa5n/0m4CY W3Z/E3zj16FMr/brwJQkXpxZMISFV8PEEFa6lsKoUf2RvhuVoD60wSxmUJM3dphzgn/MX0qCGg+J iX5QPI6K7vaJWNF9fiK6GhegCk6LZle9o7/tTEc7G5U0squTqz4UKPWrE/eRWUc+s/3enljtR7Hs Ocv7jqWjJzIpSw1x/WThMcZHYlpgpcNHJ4/Z+Jb+ZRBqHVOTjhoLECobahKnD+HXkE8o2ou7hrNt 2QqpQiqkWDRpqRHoRA8w02KVeTYJfZwRl0TbMoihlWsI8P0/mtkp1FQDlT/WSs0e5r+RvhuRLp1N dODYWoPAzmmJgU1fBlhJOh7jHrwa22epNk4roRIzLiCTKoqHmF+SyOjFYC2i3IK4Z21whv24ORP8 acFnkBfy/eWk5nhfhQ7fwN/uyyGhZyhhWJYhTw9PVqPQx5CsQff8FwAAAP//AwBQSwMEFAAGAAgA AAAhAISLAEt6AwAAeg0AABUAAABwcHQvc2xpZGVzL3NsaWRlOC54bWy0V8Fu2zgQPW+B/QdCpxZo LDdFi0KIU6Ret5euY8RugZ4KhhxZxFIkQY5d++93SFlJlTqumjgXWabIx3nvjYajs/ebWrM1+KCs GWWvBsOMgRFWKrMcZV8WH0/eZSwgN5Jra2CUbSFk78//fnbmiqAlo9UmFHyUVYiuyPMgKqh5GFgH hp6V1tcc6a9f5tLzH4Ra6/x0OHyb11yZbLfe91lvy1IJ+MeKVQ0GGxAPmiNFHirlQovm+qA5D4Fg 0upOSOfETMy1jL/BLTxAvDPrT97N3cynx9P1zDMlSa+MGV6TLFm+e7Cblv4amkY3+Z3lyxaJF5vS 1+dnvCBubDPKSPxtvNIiXsAGmWgGxe2oqC73zBXVZM/svN2AIrjZNLJqGP1K57Sls1Cogb26YdVM 5bT0sxX/BWYs8Yz0G3pium7BIucI7yqGW0fKYITazWseJj3a+YE0TWLh5oOV20j8mn7TIC90wDlu NSRBKGxeEDhdSH7NY4aCOfkyz9h1skIqj0kpFmoca+CU0Tsx8XwyvmAXIiXLGQmD5MsODYyccc+v fgMaqfKCgqD422DptlHzfk1ft5qOrUHKODbTXEBltQTPTh+nsJKUH60JfyJuFNHQu3mxQlsqZCXF Nhdck1/v3gyHlIfazJ24ArlKktEuNJq0JA0agyJGX38OOjOdLMaX049UZshp5ryqFao1hKLjU6N9 MoAuMckokNWUitLOmGZof34c3P+vE9bZ6RFJtgRkkiN/yUAqPHkQLHgqh1RY9uSwsKZUyweh7kF7 2Y/2Qe0AxaATz5PaRBmq6Qhh3y6mn5iEUhmQ/Uj0KBBXs3HoULkvDw4Kwp7DYDnoF9Qt0AHPF5Pv i5UxoGccq7Gt3ao5tI4QKjG+UfF626i6mLBmO1ZbCfpFZ5snNZeO49h19JOuh5/GoqKOIZ3wHRYP 87WGEPgSAkPLsAImtKJq3gF+Unm4jOrkHmq7jjLBOh4mP5M8mnJhdR2EV+7Xw7LD8AGldo7cY6QR 0DpHNx397jOmh9kMVU1NbAfuscGOd9XGkt3+aOJSH3LcMGfgY5t9TDGpe/dNX82sYbOvoR/723q2 57Rp6mK5MqmhYLGUhxd3cXu2YnfPxo7T9/cGPdEPNHqp32u+Cei2/UwQ2v/L3eU6vRD09YPgx2ko ZnhEo6m3UyIGfV78DwAA//8DAFBLAwQUAAYACAAAACEAPIwicXYCAACmBgAAFgAAAHBwdC9zbGlk ZXMvc2xpZGUxMS54bWzEVc1v2jAUP2/S/oen3NtQJk1bBFSMsu6wUdSUw47GeSHWHNuyTQb//Z6d pB9rofQ0Doljv/ezfx8yo8tdLaFB64RW4+TifJAAKq4LoTbjZHX37exzAs4zVTCpFY6TPbrkcvLh /chkThZA3cplbJxU3pssTR2vsGbuXBtUtFZqWzNPn3aTFpb9IdRapsPB4FNaM6GSrt+e0q/LUnC8 0nxbo/ItiEXJPJ3cVcK4Hs2cgmYsOoKJ3U+ONCFmPJdFeDtzZxHDSDXX1uRmaePyollaEAXplYBi NcmSpN1CVxY/FZXRIP2nfdMjsWxX2noyYhlxg904IfH34UlNLMOdB95O8odZXt28UMur+QvVab8B neB+08CqZfSczrCncye8RLi4Z9WWMmr9oflvB0oTz0C/pccXTQ8WOAd4U4HfG1LGB6iurl2MevT1 jjSNYvndV13sA/E1vQMIyxTFZ7r1uhQeSq18zpkkyC8D+kXIx8XS+dzvJUbxiCLLIoYlqyQLaUZ1 tsoTWEfbCmF9VBVc7WcSGaW/E95PrrAUirIK89kU5g3lxEEjGPyaLq5hucq/Q75dO26FieEbkdCe fO52RFUsmWW3r2wcpGMZHZT06MnTsHXnsEcfe49mJAidDJaScay0LNDCMKhC+e39eKNjoqC89aa+ xayo+akGHJV+JgWRyp5I2soUtaJHG431dkH3UadhO/Wy3Ud3e3cGXKtSbLZ0HQBrvXWPvP0/51Ax eBiCB84gF+U+pNFX+PyE8QI6fMxDYTwoyxOxX+0+EuKY5fb+pGF/pXJpfzJz00Sz6J/Co53FKUMM AxqVPpQEDLqK/wIAAP//AwBQSwMEFAAGAAgAAAAhAH34PZDFAgAAvwgAABUAAABwcHQvc2xpZGVz L3NsaWRlNi54bWzUVsFu2zAMPW/A/kHwvXPbAcNgJCm6rOula4MmPeyoSEwtTJYEScmSv9+TbDdI l3ZBux12sWWJfCQfKdKDs3Wj2Yp8UNYMi5P3xwUjI6xU5n5Y3M2+Hn0qWIjcSK6toWGxoVCcjd69 HbgqaMmgbULFh0Udo6vKMoiaGh7eW0cGZwvrGx7x6e9L6flPoDa6PD0+/lg2XJmi0/eH6NvFQgn6 YsWyIRNbEE+aR3geauVCj+YOQXOeAmCy9o5LI0Qmplqmd3AzT5RWZnXp3dRNfD6+Xk08UxJ8Fczw BrQUZXfQieVPAzEsykfq9z0Sr9YL34wGvEJsbD0sQP4mPaHEK1pHJtpNsd0V9c0eWVFf7JEuewPw 4MFoiqqN6PdwTvtwZipqYicPUbWiHKpXVvwIzFjEmcJvwxPXqx4sxZzgXc3ixoGZmKA6ufYw89HL B3CayYrrz1ZuUuBzvPMmr3SI07jRlAmB27wCOB6gX/NUoWSO7qYFm+dUSOVjZoqFJo41cVR0R2Yc XYzP2cUKKQ8D8BKRlg6MjJxwz2//gJki5RV8gPu9r1i2ZD5N6Yee0rE1EdbZRHNBtdWSPDt9HcFK ojz6HPwzbresksdFRcnvYXe6nAfh1ZzPNT3id3/Gtqh70BjlRFU7SC37OQV4pCpDqSyv0ZW61LRb LzD35ojtWHpFldHaaSVQ8hsmaaEMycOgn6VjvmHfz68vWWPlUtNu/f4XrGTvJ8tQ/wUyrC8xjQ4D OqAthIb7yBZKR/IHFcGzmWKhvQcuD6UdvJ1EvaBIZ6rBlN6BxIx4onc9OPlM18rNq51vWPYjT2j/ jbubVfYQkxy0jPOWw+xOaBDdiqAVqgYHqeNHcxXQVtH6OZQhNjP9jJRLNA5l8o1QkQqG4RvB+7Aw uOkeLdJKmrXjorm1NnbzIiPBYgedVp05LPH7MfoFAAD//wMAUEsDBBQABgAIAAAAIQDbH4zMzwMA AEcKAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1srFbbbhs3EH0v0H8Y7FMCWF7HRYt0YSlwVaUv qS1YygfQ3NGKDZdkSa4s9an/0D/sl+RwLzbk2qqMWA8rLnd4OHPmcIYXH7a1pg37oKwZZ+9OzzJi I22pTDXOPi8/jt5nFKIwpdDW8Djbccg+TL7/7sIVQZeE1SYUYpytY3RFnge55lqEU+vY4NvK+lpE vPoqL724A2qt8/Ozs5/yWiiT9ev9MevtaqUk/2plU7OJHYhnLSI8D2vlwoDmjkFzngNg2tV7Lk0Q mVzoMv0Ht/TMaWQ2v3m3cHPffr7azD2pEnxlZEQNWrK8/9Cbta8GZhjkj5ZXA5IotitfTy5Egdho O85A/i49sUgUvI0ku0n5MCvX10/YyvXsCet82AAe3G+aouoi+m8450M4SxU107v7qDpTgaWfrPwS yFjEmcLvwpNXmwEsxZzg3ZrizoGZmKB6u+5jy8dgH8BpS1bc/mLLXQr8Fv/tpCh0iIu409wSArdF AXA8QL8WSaFsRp8XGd22qSiVjy1TFOo41Syg6J7MOLm+/YNlVBsOF+AlIi09GJtyLry4+R/MFKko 4APcH3zFsCPzeUp/GCidWhMhOJprIXltdcmezr+NYFVCHkMOXsJt4tDgaF420a5UpBV8W0ihka6f z388gwy1WTh5w2UDylJhwJHFdMdBl5+E8YrpmTfe2cCPcvN0tg/muaBoqRZGuQa1gclwvLP+C0kN eNLWOhIIG2UJgdFGCZLWrFTV+G7GrqgveL5Uf3FJsw3SNkL6SpWWjC5bSujNbHr5Nq2NKGSon3ue d0pp5fINksUOe6jPQR3kg/79+x8SFDgSQruaLafXVx8RIU4Vef6z4RBD7ryqER0OB73h0+qUKpiX IooTYoQ9eqEb7FHRURufOIYd2S/EewLnhKBX/YqOeSdfwyuO8u0J3a2T2HjLsmllBqXFNSMJHq2W SAWi6FVVsYfAbncpP46lWim8ctLbCaHl9jDWp1qB5D3gAQBEdoLsEGTjfSovaV1uPa1ViNYrkHR/ AtDGIxLcG8Af5QnIagPhp8zvhX+Egg/KbrZ1WknUlj3U5xR8RP02OHqVFfoovIOuFUiAid6iuOE+ Au4N36UZ9rgU4Jmn1tKIinGb8crFZMRmo7w16eZB6ffIi+d6yL0fB7pH20S6ewaGw9VDav+7cNeb tgLiRgW/pu2UgzsJDaYPJmhJOMCmSp03mk8B7Q0tWLSdWC7NcFcpG5xLZUpeKaMiZygAEIWP48xA dR6typa87Np2fWNt7Pt2i4Qde+g06rfDENfAyVcAAAD//wMAUEsDBBQABgAIAAAAIQCmtCNHvwIA AB8HAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1stFVdT9swFH2ftP9wledBgEnTFLVFW8f2wgDR 8gNc+7axcOzIdkPz73ecjyI2ypDGXhInvvf4nnM/PDnfVYYa9kE7O81Oj08yYiud0nYzze6W348+ ZxSisEoYZ3matRyy89n7d5O6CEYRvG0oxDQrY6yLPA+y5EqEY1ezxd7a+UpEfPpNrrx4AGpl8rOT k095JbTNBn//Gn+3XmvJ35zcVmxjD+LZiIjIQ6nrMKLVr0GrPQfAdN5PQpqBmVwYld6hXnrmtLLN D18v6hvfbV81N560gl4ZWVFBliwfNgaz7tPCDIv8N/fNiCSK3dpXs4kowI120wzit+kJJ1HwLpLs f8rHv7K8fsZWlhfPWOfjAYhgf2hi1TP6k87ZSGepo2E63bPqTQVcL528D2QdeCb6PT151YxgiXOC r0uKbQ1lYoIa7PrNTo/RPkDTTqy4++pUm4iv8O5+isKEuIit4U4QhC0KgOMB+Y1IFcr26G6R0apL hdI+dkpRqOLcsEBFD2LG2cX8S/hA9FCyJZQzFu0EAkXkZ0Blq26EF7d/AU+URYFgwGMMGste1cPa fhy1nTsbUXl0Y4Tk0hnFns7+TWmtUCdjMv6byC/Ke8tCpk6k6Igb8Ask3RYTYsUkfNRyi05llbZj yWQ5Pjh/T4E9hg9p5EQ1wkp+kpNe507sQ5l/MaglYrFlgt0fiLavMS80QuQQHqN963N1VXvXMAUp jFhpo2NLbr0PQ6IIvDNvfSpg13qz9UwpE9B50BexbLyoKrFCW69aEiSNTkVo3EbLw1Ecaom96i80 Q9cT/fzEchyp0vifor5uuj7GTRHZz7tfNe6GhAbTRxN0mK6wkSZKtJcB3YrRIvopvLTjDFZb3CDa Kl5rqyNnhCxHVN00s6hFj85zipf9OKpunYvDPOqQcOIAnVbDcVjiepv9AgAA//8DAFBLAwQUAAYA CAAAACEABHcaMugCAADvBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU3LnhtbLRV30/bMBB+3qT9D6c8 IHhoA0yaptAUlfLjhZVqLRM8Xh23sebYke2WVuKP39lJyrq1wNj24jj23ee77z6fO6fLQsKCGyu0 SqOj9mEEXDGdCTVLo9vxZetzBNahylBqxdNoxW102v3wvlMmVmZA3sommEa5c2USx5blvEDb1iVX tDfVpkBHv2YWZwYfCLWQ8fHh4ae4QKGi2t+8xl9Pp4Lxc83mBVeuAjFcoqPIbS5K26CVr0ErDbcE E7w3QupSZmwkM/+15dhw7mdqcWXKUTk0YXuwGBoQGfEVgcKCaInieqM2C7+KzGgS/+I+a5AwWU5N 0e1gQrnBMo2I/JUfyQkTvnTAqkX2tMrymy22LL/YYh03B1AE60N9VlVGv6dz3KQzFk5yOFpnVZki uV5r9t2C0pSnT79Kjw0WDZjP2cOXObhVScw4D1XbVZuBj8beEqeBLLc809nKJz6hb1jERFo3civJ AyEUNiYETgPRL9ErlKvW7SiCSShFJowLTIEtXF9yJEXXZLruRb8Hfa0yEfTSIW4claYG5CobosGv L+D6bDGhOCiFJl6aVoTupvVjQyud70h0MJTIeK5lxg0c/x3JIiOJNHX4b/w+y+y1ngmGEvjSXyrf SCw8CJfDfW9wBRk6pA6iDSfVZNwC9ZJYGxh+sxtFqIgN7O6q8rNR9IA11aXZnHrThPulqZjNDc8A bbL7vHCxSXnzATW5uspex2+KBFpAGVOroyu0ceTLaNxQK6SmskW/d0N0+R/CbYH5qUobYBv0r+m4 JMGOl+H2Teb9HA0wGtKoFS40FevNJCHkghs0LF+BnlKhihKNsF47JBCQtaZofSJU1eO9ncu54Xr6 itD/RSXfwT5vz9qwfwdpCvcAj4/Q25Pu5OwA9rAoT8IA+32/lp777Yu9mTu5PDjYiJCa+Y4Gs5b0 M60ldJjqIaJp8zYxab5gebMIKqUn13HTD0slKc+jkemTicegN+0HAAAA//8DAFBLAwQUAAYACAAA ACEA3C0JO8ADAABfDQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMxXUW/bNhB+XoH9B0JPCeBa adYVmxC7yLKsL11ixG6wPhU0dbaIUKRAUq797/eRklLYsx1ndYC+2BTF+3j33Xfk6eL9slRsQdZJ owfJm/5ZwkgLk0s9HySfJn+9/i1hznOdc2U0DZIVueT98OdXF1XmVM5grV3GB0nhfZWlqRMFldz1 TUUa72bGltzj0c7T3PKvQC1Ven529i4tudRJa28PsTezmRT0pxF1Sdo3IJYU9/DcFbJyHVp1CFpl yQEmWq+5NERkYqzy8O+qiSUKI734YKtxNbLx9c1iZJnMwVfCNC9BS5K2L9pl8VFjGQbphvm8Q+LZ cmbL4QXPEBtbDhKQvwq/MOIZLT0TzaT4NiuK2y1rRXG9ZXXabQAPHjcNUTUR/Tec8y6cifSK2JvH qJqlHKYfjXhwTBvEGcJvwhM3iw4sxBzgq4L5VQVmfIBq1zUvIx/degdOI1l++YfJVyHwKf7jJM+U 82O/UhQJgds8Azh+QL/iQaGkX38aJ2waU5FL6yNTzJX+ShGHolsy/XBklBQrds+t5FNF7gLseCSn hSSdj7jld08gh3h5Bk8QROcxhg2lu4n9pSP2ymgP2bGR4oIKo3Ky7Pz7aJY5RNJl4jkMByY1CvSy 9mYmPZvBt7HgCkn7/fzXM4hR6XEl7iivRSiyQYLCxXTDQZOlgPFySWIno/vTjURtF8De1DPpGNfs +uoyHGWeekz2qc84nixCqy0xb9gDUcVwKtTKO8bMjPmCog0tSdSBADCEsi9LyiVQGB5mdbSuHa15 2Ugk6mSXYvc6PLpna3i7QA6QfSjCTa3/Dwqzozk0V2bK1UHh7eWInbiCW8rZlPxXophed9o7mp/K oBSO4WaUncCF2IvqkyIIJ1/h3pBiXdw/kGxEc04dIf6DIA4Q8mOtHgS4VzobYl6jPV7xuIPqG7Q7 7WkfbrRdJbh3o59wiuCYEaYscXqEUmQn1J/3mcQtMCfbYzVG7972GHnRP13X7su5dWvXOHy5jUL8 OHhpKZ1H68c+X958QO+QE6tMoADFu1oP+mmayaJbRN+15Yr/Z8R9sRba03BbYNocPRNoj1+T6y8T Uxll5vIYZ3GqpH5w6fH88/QlQD4TcAtzGwpGD7ujq3qsmj39VGyrmv4bw64lF8r+zavbRSxJfGl4 sldxqoLAAhqWfluCJk2WeBE6Uq8/OjR8aE05jLFsorsePq+hKalzmkktPSWhDfDc+kGiCd9GaN6g 2UnTzpZ3xvi2n41I2LGFDqN2OwzxeTT8FwAA//8DAFBLAwQUAAYACAAAACEAA+C9eD4DAAAUCwAA FQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbMRW227UMBB9R+IfrDwBok0p4qLQbQXl8gJl1W65PE7t 2Y2FY1v27Hb37xk7SauUpSxlJV4Sxx6fzDkzmpmDo2VjxAJD1M6Oiie7e4VAK53SdjYqzifvd14W IhJYBcZZHBUrjMXR4f17B76KRgm+bWMFo6Im8lVZRlljA3HXebR8NnWhAeLPMCtVgEtGbUy5v7f3 vGxA26K7Hza576ZTLfGtk/MGLbUgAQ0Qex5r7WOP5jdB8wEjw+TbA5cOmZk8Myq9o58ExLSyiw/B n/lxyMcni3EQWrFehbDQsCxF2R10ZvnTshkvyhvXZz0SVMtpaA4PoGJuYjkqWPxVevIlqHBJQrab 8npX1p/X2Mr63Rrrsv8Be3D108SqZfQrnf2ezkSTQfHkilVrCnz1o5M/orCOeSb6LT15sujBEucE 72tBK8/KUILq7NrDrEdvH1nTLBYt3zi1SsQv+J03oTKRzmhlMAvCbkPF4Pxg+Q2kDEW7c35WiIsc CqUDZaVEbOjYIHBGd2LS4dcaWE8356S9QKE4mcWlplqMv8SjA1aKOFAdPFo1hgCnf/hL4g4Ve8WE eu952cr7e5Gf9iIfO0ucgmJsQGLtjMIg9v9Ncq04Yfqo/E+1A4K6oer6yN0aMzENrtkIZoMEKC+D JtwI7XanyInvr08+CAUEXBtdGIK2OZET43fpeiv+eUQlIApt/ZxKNyd+icsarZBgDFdQsRGHDRTJ LE7Hx3EAuBX/WaMZWgxAuDV3rSPNLSCX7IHHd5JZNBgjzDC+GmBthf3N6HEb3JoK07mVqeUNvL6b Aimf4mORvMMlNJ5L/l+iYuDWzU1wTb1938wN/SXcGpgH8Fjs7b549lBwSrHDcs4dH/PWIxjAbyVy 2m5Rgm9joHrg493ihMs0raQJLV71LBFwyupzqWBdLlaCatSBN6NHTo8FCu+izqMRF5J02tYs4nlm 4NFAtX9vfLn/tUMTL/s5SprwCfznRW4BPB4ShuO85bmcdSPEtQl3U93wQRojyH6M3Jl5noA8VsiJ 7QcvNefc01bhVFsu7EUiTxBoVFjkgZa7rFM4aWeQ5tQ56oaQjJRadgudVt3vkvM8+P0EAAD//wMA UEsDBBQABgAIAAAAIQDWcfqc1QAAAMABAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVz U2xpZGUxLnhtbC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vY9BDL6V7AGEriWliG8sb7dvXUBgJ FHbZSfwS+vSh7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoKBUdTDGzgygK77vlpe+SJSl2S0SdR lRLEwFhKekcUO/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKgWzHV3hnIe7cBdbqmevlvdux7b/kj 2u+ZQ3lwAmXyjiuQ8sDFgNb3jtxL2+pqC/hYpP1PkRALy4GkcF7pLPqCi/Brhqu/dzcAAAD//wMA UEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB 4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQ c9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/ VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EK wjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E 63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKa O/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ 3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0 A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+X i+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDUueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa /WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWag CVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUz cqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOEj8EKwjAQRO+C /xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9 rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1 UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNupr bvsBAAD//wMAUEsDBBQABgAIAAAAIQDcIIjxlwcAADIvAAAhAAAAcHB0L3NsaWRlTWFzdGVycy9z bGlkZU1hc3RlcjEueG1s7FpdbttGEH4v0DsQ7GOhSPynBMuBZVttACcxYucAK3IlsV6RLLlS5RQF cofeoLdo+9aj5CSdmV1SlC0lMiwDtmHAkJa7s8Pd+ebfOni9nAljwYsyydK+ab3qmAZPoyxO0knf /Hg5bIWmUUqWxkxkKe+b17w0Xx9+/91B3itF/JaVkhcG8EjLHuubUynzXrtdRlM+Y+WrLOcprI2z YsYkPBaTdlyw34D3TLTtTsdvz1iSmnp/scv+bDxOIn6SRfMZT6ViUnDBJJy/nCZ5WXHLd+GWF7wE NrR77UiHcL/oQsT4PZqozw98bCTxEqTU6Vjm4QHr0T35sSiMBRN9czSxzPbhQRu3ALEe4eYyvyw4 x1G6+KnIL/LzAh+id4vzAngCS9NI2QzkiwxoQZPRYwpkivHa9knFifWW42KGJwLxGHBCQPEaP2ET 6/GlNCI1Ga1mo+n7DbTR9HQDdbt6AVytfineSt3o9nXs6jqXiRTcOBcs4tNMxKArJCK6odoGUszP suiqNNIM7oyiUFcF4VSM8f74qnxqyOscpCSRraZTi3CytKYvSb7VoWupuF4ASkeisQPXd8J1+YS2 3fVxHaVkWa7TgQc8y4pRXpTyJ57NDBz0zYJHkhSBLc5KqUgrEkJfHSTvyeUgi68RjBF8A+ZgcbB/ mhWfTEO8Scu+2bVcF94t6YFOahpFc2W0tiLFcQYqBztYGgGfvhnJgs6SgrUdzWU2TvSJ1Cvx5aKU F/JacFILAI/1QKzwAQcSDA2ep62PF2DwM3ksOAOHoFVIHh6LJLoyZGbwOJGGtnuCAdwDsEQpSZIV seRpfM4K9uEGZy0ikk0lE0BOKdJ2dXJqdUJdbmqTjQDdV5tQQKY27fsolQXagwpG4q2sbk2rXM/2 ur7z+LUK1eJOigQWZ4gFaSRd/56KhdIjvSrXFAuUjNRWfVSvJI9xB12+4FGWxobgCy52YE86dgf2 l9Ok2J07KcMduA+zeSGnOx/eVdq4MxzDZLyRO4SRvZq0W5n0CZPrAYIEcl+TjiV4sU/gYZkYa9Mm GClMYDC5Y7zwHQ/+bpi2bTlOHTAc37Ns7/Fb9lq8IFOtogJFiIWw0JSZmID3FybOxXyMfhzFaaF7 w7kyE0k8TISgB0z3VmmQXKrsSCapVIlR4K1CaZ0zUbBo8AHbVm+iBfAleBA11mEL30WWPxYxZU2/ e+5p4B15XssKTwYt1zs+bQ1sr9ManHR9r+sFoXfi/QFBlZKGGDRNJjM+TCbzgr+fq9D97eAHxyA5 ycOgbdmQclrhymvAUfBY+zUOrzKOYZZhft2MeGTQ9zWPMeQKBOivc1bAG7SJqMCEmdSuJuJYtlvl VJttJOx6z9pGqrTr8VnJfnXSr3TyAiyfG+/ms9ENzSTnd1/NhKISWG9STlL8O/lv3/Ocryvnc3fg qiJ4fKpZO/DuwDkedIZO6wSKr5YbHg1aUIP5LfskOBoGbvf0dDisHXiJmpeCdqDHvYvf/vL57x++ fP5nD16bihVVy8Ow6hBEonjLcgPqf4iZEmp5CIF9M76C0Whi4xwUxHIJo/gKRiyKoOkAFHpQzcC6 mqlpnGoGKiC15FYzkECpGa+agaihZvxqBmx2KpL0CvIg/DKNcSZ+VhPVCBMWauWcsetsLt/EUMje mKFQa1tu4IaO73ahLO1hy6J4E+taHmy22r1GC/nSilZXaltpQVY1X50CbqUF+dS0Oh5upQXJ1bTa Q22lBZnWtP4tyazfDaRd0wbfoAUcalpqOqxJfJ1v0KDtfoMv9OZqvhYlp19hvAZc1WRpiEIDL5fU IihRCai+p0e0OJ2S6dwQ454BnuWSjS4gM6T2BeItVVeCs7N0UIDmAa7YnUv1I5BModUALcDzeRpB D0R30vJogB0z7AZF55HOG+lKkBfCnF4dzd9BG5LSsYZXg84J8L3iBbYwd01RgQmybiaydFDKFsfQ sOqbP85+aQmJIECGx24scKYWovLGQlTiwrZ0dl2q0CqE5sMtEc9YcdY3Hdfu4sWSFNweiKpVTVTZ +UPLH0Sp2hk3MBhmkNljUq3EdFQkTJhGnshoOmSzRED/zAFbiqasKDkcXNdNo/kxzNB03/zy+S8l vwaOKlo/BI7pNhzT1hYc09ZXcSRzsLFUUlgFgBX6uxorO/Sg7AGXrCupp43Vn7ewssOHsrk9YoUA adflrLCqersNsOyQipTnAdZtw7IfzEHuESxESIPlNsDSTdXnCtYGy0Kn+yDRbI9gIUIaLG8Flt3x AlK1lRt8Rpb137+3veBTwAoB0lj5Daw8yyWn9yyx2pReYDrz6A0LEdJgBQ2wuoFFAfcFrK+1nXfK 6ffoBREhDVa4Akul6WvJ4DPygk/WshAhDVa3AVYY+tQkfLGsx2RZiBAU0Wv1cd7L5JQXdbUMleO5 glTXkM0fMdQluCapuheqXHuQwqxRySpn/SQr2epXMvuvhZ6afDZXj1Wn60U+Wwo2J8AfwjxE5+Op KdDmIskK7ZByuRcN2lKZULb0okEQsrZUA4GrWqUvGrQlA4eMjvoQLwLakvX6XvDipKmJX2eazeQS Es/VP8Lwn77Vb90P/wcAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGm XkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZP Gt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5W QzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMA UEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MF wePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnD kHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKf f1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4A AAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/B CsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHe BOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68i mjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5q Wd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF 9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBv l4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE 9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQU AAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92 mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVm oAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2l M3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEANa22360EAACMEQAA IQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbKxY25LaRhB9T1X+YUp5lkFC91pw Lbe8rHcpgz9gkAaksm6RBgxOpcq/lXyOv8TdIw2gNZtlZb2AED1nprtPn27p7v0hicmeFWWUpUNF e9dXCEv9LIjS7VD5tJqrjkJKTtOAxlnKhsqRlcr70e+/3eVeGQcP9JjtOAGMtPToUAk5z71er/RD ltDyXZazFP7bZEVCOfwstr2goF8AO4l7er9v9RIapUq9vrhlfbbZRD6bZv4uYSmvQAoWUw7nL8Mo LyVafgtaXrASYMTq5pH4MQdv88hfHRQizIo93NCUEXjuL+OApDSBG4vI57uCkS8RD8mE5ngOYVPm q4IxtE73fxb5Ml8UYunjflGQKECoGkLp1X/UZuJnCmZw0Xu2fCuRqHfYFMnojnoQEXIYKpC4I37C IuqxAyd+ddM/3/XDpyu2fji7Yt2TG8AJTptCzvPKo5/d0aU7q4jHjGgnrypTCksfMv9zSdIM/ET3 K/f8x70EQ58RPg9JFX6OULVd9aeIh7QvRUzlQU+R0GxX1x3gLXhuOMCy/rOomIZjGXCTYGxMy7IH jthEIsEmFXTu8cM4C44Y0jV8Q+Zo6ocZMHWNK6gXl3zJjzHkGa73sQYnIjTeQinFwALqBWzzEW6V X4cK8B22XEvPT/aQ5CYOhJh6EAj4gKUxxUpkqfppCZWY8EnMKMDXLvHRJI78z4RnhAURJx9oyVlB ROCgbuFkiM7FHgKSpcGCFhQPdYmMuaAe7Ay+S59FGDAfLyd9IJMuy2ARU5+FWRzAIXQMERSLTHAr CkAFKlAuwGVJmHZEsDTdts0qabI6GjwwNA3JcisRXsx+QosHUY1RGoC04CWmcr17BP0Uqy44MQBS 1DvW7EFbuNSRSBWUYdpoRW7B088e1CA13uCM52qGIP9NeGhZcQPwEKTGM8542sDWsMRuOyAWwQkQ UWpA8wLQgeptB4goNaB1BgQ1gAO2OiGi1ID2BaBtiMy1cBlRakDnDIhotyelEUNEqQHdC0DLtFsm BVGua1K32mFI7VhhPV4KxwAZ8qvCgXoNggnCG9J4U2uIkCTRQ4SP2FyXwl2p+LIFXG0m5gBaRdUr zi22ISJOH1pLtYlE+p9mItTgWgd5k4ZojRrFDlTToaWGaA1NQpAar6WGaA26dqAhbscS0sDrQEEa eB0ISAOvA/1o4HUgHw28l9UDiESgiZxGF0Gr9hMOioYYcMrGhNNmijGlEk0pZw0lMrpQooD/pENa 1QRRf64KkdA/OYfJ2bMhF+KHmBQ38CyCzxN/m8bMNu9NU9Wc6Vg1zMlMHetmXx1PXct0Tdsxp+Y/ Sj1aB+AqjxI2j7bw+PK04wpW+evpgCyKrfnI7mk6PH9pzjn+cBRE6bZPWDI78yzD2fayU4iB7lc7 xYYXVYL+2tECdpDz5isD51ty1G1EbBmRZRwFjDzukvWzuFhd8Bae7wH6amhe6aNvCc2Jvu54MBn3 5wN1quuuajj3Y9W1+paqT+37uW24s9l8fqJviZ6ncLq3svb7t3//+P7tvw44Kxp79YwPl/hKQAwt cfGB5k97oW7wDgT4NBG3cnjrAXFB07MJYsi3KKMfAAAA//8DAFBLAwQUAAYACAAAACEAJl8qb/AE AAAdEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbMxY3ZLaNhi970zfQeNe E5Bt2cazkFlg6c1md6eQBxC2WNzIP5UFgXY6k9dqHydP0k+yBYaQYHb3ojdgzNHR93s+2TfvtylH GybKJM8GFn7XsxDLojxOsueB9XE+7QQWKiXNYsrzjA2sHSut98Off7opwpLH93SXryUCjqwM6cBa SVmE3W4ZrVhKy3d5wTL4b5mLlEr4KZ67saCfgTvlXbvX87opTTKrXi/arM+XyyRikzxapyyTFYlg nEqwv1wlRWnYijZshWAl0OjVxybJXQHe5ovf51sLaZjYwA1sDcHzaMZjlNEUbozzTAID+pzIFRrT QtmhMWUxF4wpdLb5VRSz4knopQ+bJ4GSWFHVFFa3/qOG6Z8ZwOCie7L82TDRcLsU6fCGhhARtB1Y kLid+oRFNGRbiaLqZnS4G60ez2Cj1d0ZdNdsABbsN4WcF5VH37pjG3fmieQM4b1XFZTC0vs8+lSi LAc/lfuVe9HDxpApnxV9sUJV+KWiqnHVnzoeBl/qmBpD95FwiQ+1pcNh+06PnMTE6fUCBzsWUpHB 2LNrRNPjirkI5XaUxzsV0QV8Q+JoFq1yKNRFFWdeypnccUgzDfmGYzAIUf4MncShCGgYs+VvcKv8 c2CBSWDTwji+x0OO4brBAxGmIcQBPmApp6oRWdb5OINGTOWYMwr0tU9yOOZJ9AnJHLE4kegDLSUT SMcN2hYsU+xS76EpWRY/UUGVUU1mlQoaws4QX+MzXFbZ/n7OIYjHXfDEacRWOY/BCPt1FZDEUL+m SNon3yE+UQlVzXAu+wRjDIgq+yQgDoZSqNyvGkq7XdWhiYTJvm6tZqrqlJ9k2lHVV1E2AHBp1/Xa rIqgiTUAwDpnsG4TawCAdc9gVbXtbTAAwJJLWAMArHcJawCA9S9hDQCwwSWsAQC2fwlbAc71EKxE wLBvllf2lNJU3VLlUU9VfaObBz7Mlrpwr2jjGYvyLEacbRhvQa976wr6+SoR7dl1Q1zBPs3XAqZf W+NdVZjX0CfLs+ww5t5UzVyjZnOV6qaU6YDA2Dej6kXDTE0QkHAYBSvKlxacAUDgdCL1UFOSoy9m uuKV+KpbP5pu2HUIrvr8MPKPxpvr9XHPe7XAoZSKe33ESLIYTjvqUpm2WD/AoVBns6Fp+Ein1ExU WOhEJW81lZnRrfiO9PREI2u+PnbVrqgV35E2nuhozYcdH3ttCfs/0FrDF9iBkvpWBh7xnehxzWfb AZj3Er4TzTZ8vqvH1vX2neh6zafIWifkyN8T7Td8HvFflo//x3yAzjanCX3AUMfc75+riFGiCZXs SIm0dr5WiWL5jQ7h6rSgnjbOChH0+MGDs+chrQL67LqEhyP1gPMXce98cktIBweTUccl47vOyCa9 zmjS90if+AGZkL+t+qwfg6sySdk0eV4L9riWWmEuH4FBU/TWcuh3sQ0PhDg4DFAwRWnP284Jz2Rn mufqtN2cFETNttfmZylFlaA/1lTADvWswBdOw9fk6G0j4puIzHgSM/SwThcncfHeIi7wwgGoz4bm why9JjT78u2PnPGoN3U6E9vud9zgdtTpez2vY0/826nv9u/uptN9+ZbK8wysU/V2TdV+/fLPL1+/ /PsGNauFpXrpAJfqHYUuRS4+0OJxo4cwvJSBehrrWwW8hoG4KOgBojjMa53hfwAAAP//AwBQSwME FAAGAAgAAAAhAEkweT+pAgAAwgYAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54 bWysVe1u2jAU/T9p72Blv9OQQPiIgKohsD9di0b7ALeJQ6I6dmYbBpsm9bW2x+mT7Noh7cY6qdP4 A87Nvcf3nHPtjM93FSNbKlUp+MTxzzoOoTwVWcnXE+f2ZuEOHaI08AyY4HTi7Klyzqdv34zrSLHs EvZiowlicBXBxCm0riPPU2lBK1BnoqYc3+VCVqDxUa69TMJnxK6YF3Q6fa+CkjuHevmaepHnZUoT kW4qynUDIikDjf2roqxVi1a/Bq2WVCGMrf69Jb2vke0dA37vEJsmtxjwnSkyT1csIxwqDMQ2wwRV fSMpNSu+fS/rVb2UNvdqu5SkzEztocbxDi8OafaRYxouvKPydYsE0S6X1XQMEUpAdhMHndqbXyyC iO40SZtg+hxNi+sXctNi/kK2126AHTxtalg1jP6kE7R0EtCULBmktBAso5L4TwSbKkCUS5HeK8IF UjZKNEzTq22La+ibneqCNNJnGgfvC5oILHdQPyTnW7JWIZNsF229QrmtjnoXi2xvNLnDfxuEiCm9 0ntGrVbICKIcHTSmfA1780F4EYauP0xitxfO5m4chB03Tkb9cBQOhmESfnPappCqLiu6KNcbSa83 GscBIokG4xjggaHcvV1h35WeMQp4oA72NM1BpKcDzw9wav3hGAXXSMK2Yi3k2RIkfDwCM0pBhD0j 3ZYbLhtf/u5Ot3VnIYRGT371JziFP7mWjUGfNiBxh9aj1tvG0P/yiJ5UkV6ryIqVGSVXm+ruSJfu KXTBWxGhX5TG6m4VOd34juLuLO4sum4SBCO3N7yI3VG/03eDZHCxGPRG8/li8TS+yjDn2N2/Tu3j w/d3jw8/TjCzdnSbixKX5iK1dyGTH6C+3uKphgi/HDhPMxuq8VtxuCueUwxG++2Z/gQAAP//AwBQ SwMEFAAGAAgAAAAhAPREAE/ZAgAAFAgAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 Ni54bWysVVtu2zAQ/C/QOxDstyJbtvwQbAeRH/1JbKNODsBIlCWEIlWSdq0WBXKt9jg5SZeUlKRp CqSofmyK3B3uzA7JyfkpZ+hIpcoEn+LuWQcjyiMRZ3w/xTfXK2eEkdKEx4QJTqe4pAqfz96/mxSB YvElKcVBI8DgKiBTnGpdBK6ropTmRJ2JgnJYS4TMiYZPuXdjSb4Ads5cr9MZuDnJOK7z5VvyRZJk EV2I6JBTrisQSRnRUL9Ks0I1aMVb0ApJFcDY7N9L0mUBbHWmGd1wVmJkQ+URJrt4BuyjHYsRJzlM XJsoZMPMiiquJaVmxI8fZbErttImrI9bibLYANSJ2K0X6jD7ySEMBu6L9H2DRIJTIvPZhASgBTpN MbSsNL+QRAJ60iiqJqOn2SjdvBIbpctXot1mA6jgcVPDqmL0Jx2voVPp0H1kVYUSSL0U0Z1CXABP Q7+iF62PDZjhbOCLFD0Tvo6rFq0eTbwCTa1Y+hSKuDTEb+HfTpKAKb3TJaNWECibBAAOPyA/I8bX lDs3O/B1rueMEvB9LZ6ezVkW3SEtEI0zja6I0lQi6wI4BQA5AXU0NKeGpDzeEkk+vUA2/EgAO0PR TYUwrCT8u5C9RsgF0RRtGYloKlgMFXhtaBproPwVjgVhCQYjgku6lriV1jTgvzRO4DwYd3/z+8uh f+H7Tne0CJ2+P186oed3nHAxHvhjfzjyF/53XDc6Bqo6y+kq2x8k3Rw0flurKgOYZgzdrgf3QHf0 1BsoxaC0251+052VEMYVz/vTa6M/iZZVgz4fiIQdmh4156WFc9CuIn6jyI5lMUXrQ377Qpd+G7rA OwPQr0pjz0XL9h2HvXnYWfWcheeNnf7oInTGg87A8RbDi9WwP14uV6tH+yrDnEN1/+rah/sfHx7u f7bgWXuxVC8ODM2zZB8VJq9IsTnamw/eYvDT3E4V8PrW9+9TiMFoXvPZLwAAAP//AwBQSwMEFAAG AAgAAAAhAFYzFQluBQAAkhsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWzs WdmO4kYUfY+Uf7CcZwZsvIEaRs2Wl57uVmA+oLCLxhlvsQsaEkWa30o+Z74k9167wGzThuZhpPAC xhwf3/X4Vvnu4yoMlCVPMz+OOqr2oaEqPHJjz49eOurnyajmqEomWOSxII54R13zTP3Y/fmnu6Sd Bd4DW8cLoQBHlLVZR50LkbTr9cyd85BlH+KER/DfLE5DJuBn+lL3UvYK3GFQ1xsNqx4yP1KL69Mq 18ezme/yQewuQh6JnCTlARNgfzb3k0yyJVXYkpRnQENX75ok1gl4K17jyWryGj9Nf1cVAqdLOK2p XfDfHQeeErEQTvTjMGGpn8UR/ZMlk5RzxETLX9NknDyndMHj8jlVfA8JigvVevFHAaOfEcDgoL53 +YtkYu3VLA27d6wN0VBWHRWStsZPuIi1+Uoobn7S3Z51509HsO58eARdlzcACzY3hXwnuUeH7ujS nYkvAq5oG69yKINLH2L3S6ZEMfiJ7ufuuY9LSYY+I30yV4rQI1WBy/+keEh8BjGlYIlVL/bW6PgU vukkaweZGIt1ACmA42WgUQJY2+Oz3/LQlk6Dt2U4OMnaYAp8QLIChn3Ao9rnMfRBKPoBZ9AnRahF tx/47hdFxAr3fKF8YpngqSIoChkacAfsAlJZUPLIe2YpAyN2mDEarA13BhelP3CYB/x02JubsGPO nwPm8nkceGCBfo0MYDxVKFeoJZmwE4nAaO2VpGHa0OBUl5rZNDWtiSZtq9NoGA3NAXHBGrWaLdsi myEMORG5n5eEjIjMsMIidx6DWkxzynL2imQrIUsfqC/8yIMGx0O8+3TxCCpGhuS1oGR/dlTdQEun 0s1SbdChDtVTEEqvKrE2DlmRCu0AM5tb1pZmkAVVWDXnkBWpClZjy6o1bc1CcCVaQu6GALkKWrNE 6+gO2XApLXIVtNaWVtcdMOEd1iJXQWuXaG2jSXV4qbXIVdA6W1rkrJ6yI7FFroK2VaK1TPtdKUMu 0pJyT5Ci4U2g6jbSRXe/XOFQcEjgsh2Fu0TFDKli/TgS0Ks7QkaqAY9a+aA481GC3T1nwayQsVxi 8LFKYcKD8vMEE3JaxnTNNhzb/I6MNVumBs2BiCo6RjJUTtTBk2qrTjllCQCHUkzKSoYttMFKAGCl RJSwpCQbrAQAVvZ9GYtVucFKAGBlM5/ESgBgZYeexEoAYGXbncRKAGBlL53ESgBg8waRkwDFl0Ry 49uP0UE0DMCHbFp6/p4xloy5G0eeEvAlD4406D499cUZ9JO5n1ZnL578lRVnFC9SMa9svJF3ZHV6 f3aUHWaTq05nptS1yf50RhZfLmr5fJxPZyhwfyxYCmNnoXEUbRqVK2ucZZgNHcyFSezUrKbZoHy3 Wa2j3mY1mJdvs1pHbf4fZzVLatqxWY1Go8tl7VDKSCcvlrJT89pWym7zGsZ8d/65zWsn9nS+u+LZ H6hu8xpuoeWrwf3Y/Kjzmi21bcAE31mEWjhhXi5s+bzmCdhA3F2Oavma6uR6lO66v/sFJ7cblvSD 1vcz2IvGneW/TGNom/emWdOcQa9mmP1hraebjVpv0LLMlmk75sD8Wy02WT1wVfghH/kvi5Q/LYSK 7G9vC8DChG4tunZd02EXXnO2ywwwBVmuO03DTmG+1T6KY9xjLe922tfIz0zABH34DNLe2Po8J0fX jUhLRmQc+B5XHhfhdC8utBPx3rqFtzxAfTQ0b2ynnBOaTfm2es1+rzFq1ga63qoZzn2v1rIaVk0f 2Pcj22gNh6PRpnwz9DwC686t2m9f//nl29d/r1CztE+dv+2BQ3wlRFIRpJ9Y8rSkRSm8CYOK7dOp BN59QVwQuoUgh3yX1v0PAAD//wMAUEsDBBQABgAIAAAAIQCppWjvFAQAAMMRAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1s7FjdcuI2FL7vTN9B4157/YNtwBPYCT/uzW6SKewD KLaI3ZUtVxIEttOZfa32cfZJeiRbhBBSoOEyN4mRP33S+c6PjnX1cV1StCJcFKwaWN4H10KkSllW VA8D68s8sXsWEhJXGaasIgNrQ4T1cfjzT1d1LGj2CW/YUiLgqESMB1YuZR07jkhzUmLxgdWkgncL xkss4Sd/cDKOH4G7pI7vupFT4qKy2vn8lPlssShSMmHpsiSVbEg4oVjC/kVe1MKw1aew1ZwIoNGz n29JbmqwVj6y2/vfLaRxfAUjnjUE09MZzVCFSxiYPzI0ZpUEGv1K1HNOiAJVq195PavvuJ5xs7rj qMgUQzvTctoXLUz/rAAGD87e9AfDhOP1gpfDKxyDEmg9sMBhG/UXJuGYrCVKm8H0aTTNbw9g03x6 AO2YBWAH20XB13Vj0UtzfGPOvJCUIG9rVQPFMPUTS78KVDGwU5nfmJferAyZslnR1zlqZVdULa55 qfUweAGaarHkesSyjTL8Hv7rQRxTIWdyQ4kWBLaNYyCHPyA/xSqqSWV/mUFUl3JMCYaob8WTwzEt 0q9IMkSyQqLPWEjCkdR2CUV5BepIcE5LSarsDnP82x6zsg/HsDJs2uwQHhsJXxeyY4RsowndUZyS nNEMNuG/TVbxDbIB04UFEQjhYXzwirZKrr0oC8Iu5KsONS9yXfWs9TUBF7idHoxbSIVdEPphP+po BxomLUDjZqPJQa+ptemKejptcJyRhZJX7d/vNYuCtjsAePQPYINdrAEAtnMA6+5iDQCwwUus92wP BgDY8BjWAAAbHcMaAGC7x7AGANjeMawBALZ/DNsAlNZtOinH6GyCmQgYtmnzxuxSEaSTSzzLriaD 9pfUgXtGQs9IyqoMUbIi9AR6nWVn0M/zgp/OrhPiDPaELbnMT9580GTkye5IisVBdjhFLlrXgv+q a1oTOE/NYXDmcbFX17T/9FGhKo1+2D0zDtW1KOi9FzY4Ed4LW/xe2LaN0HthO6FhC01hm2BJnnVr uhT//6rWNMGZhB51r2/TDnq9wJ3TFC/gC0Z9jvwZBtNueB2GttebjOwgHE/tkR+69mjSj8J+2O2F k/Avq+3MMzBVFiVJioclJ7dL9c0DR9peB/yyt4bc0v2iHHYdz4fPNq/3dB7DVhTLZY+dyHgnYUy1 8bvddKiOyrf6ZyF546A/lpjDCqa3PtJcn+OjyyrSNYrMaJERdLMs7/d0iS6hC1wLAPVBaY6cz+dI sw3f/qgzHrlJx574ft8Oetcjux+5ke1PutdJN+hPp0myDV+hLK9gd+dG7Y/vf//y4/s/F4hZXVia KwJ4VBcJOhQp/4zr25Xu3uDqBOJprIdquCwBXRT0CaI4zOXL8F8AAAD//wMAUEsDBBQABgAIAAAA IQCa4s1fiAQAALQQAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFjbbttG EH0v0H9YsM+KSIo3EZYCy7LaB8c2IucD1uTKIrK8dLlSpRQF8lvt5+RLcmZJSrLrIqptGH6RqL3M nDlzZneok/ebXLK1UHVWFiPLeWdbTBRJmWbF3cj6dDPrRRarNS9SLstCjKytqK33459/OqniWqYX fFuuNIONoo75yFpqXcX9fp0sRc7rd2UlCswtSpVzjZ/qrp8q/gds57Lv2nbQz3lWWO1+dcz+crHI EjEtk1UuCt0YUUJyDfz1Mqvqzlp1jLVKiRpmzO77kPS2QrS1SH4TPLWYWajWGHKsMWJP5jJlBc8x MBcJOWe0UCgzW1c3SghaV6x/VdW8ulZm0+X6WrEsJSPtZqvfTrTLzM8Cy/DQf7D9rrPE481C5eMT HoMNthlZSNqWPrGJx2KjWdIMJvvRZHn1yNpkef7I6n7nAAh2TpHvqono3+G4XTg3mZaCObuomqUc Wy/K5HPNihJxUvhNeMnlujNGMZP5aska6jWZatc1k4aPbn1tOO2A7pgIXXfgDAwdnmcHQ/sBKWEY uh4GGVHjDALXDn3jpLMEJ43pKtabSZluidJbfCNzvEiWJVSqaQePZa3neiuRZzyvpQNEjMs7lJGE CnicisVHDNVfRhZcwuetSXzCwQCXsnXb7kS671sE2TwGJfiAEcmpHkXR+zRHPeb6TAoOR210enwm s+Qz0yUTaabZB15roZihENULjGRdGx/GpCjSa644wTu0TFnhMTyDhS56Qwhl5r/TD76bUrgh7V1L nohlKVEMzKUgUS1dnp+kBGLfQtlA051wniQId2gHIcRhktdVyX1B+LbtRGGbmabIjhHEbWPzMUHk XF2YAs2KFCcNPVJOb1eXOE4NkgOZ4EhsputSZuksk5LWmtNUnEnF1lxCfRs6gpDOrNDNSAjYRglI 3m6xSeWBHcw1nszETnVGui5Jt0Hq+SFQgO4j4DrRK8IljBQ2kA/2cIcOyvxYuMErwiWMLVxvD9cZ hA6hOI5eiswI4BXUQCBbvP4B3siNKMlvDy+BbPEGe7yuG4Het4iXQLZ4wwO8oTc4vtxeUw8EssUb 7fES2OPr7TXxEsgW7/AAb+CHb7PeCGRzEh90EebOJ/Q45HaXuwnr6T0AXXSmBajv9QBPuee97p6f ci3u3fPmUn3uPZ9qtDZolpZcLrr7vrnWqBE2dNHD3DDXtGmmu+g6la5PM7dqdxebH4bXBTp26r3/ 9L3z0D/1/Z4TTSc9zz87701c3+5NpsPAH/ph5E/9v6y2DU0Rqs5yMcvuVkpcrbRFKvtxOgDSuNbj sO+4eE9xoj3/gEJWXrYL87vszMqSur/DPsyjBuW5+Vlo1STo9xVX8NDl6AdNmfF8ZI5elpGgY2SO bkqwy1V++4AX0/s/lxe8B8P0o9SY/hcd5EvKdzgZnE3s2aA3dd1hz4tOJ71hYAc9dxqezkJveH4+ m+3kW1PkBdD9X9V++/r3L9++/vMCmjUNdPM+jEd6cTZSlOoDr67W5nTDfwXQEzpcDFX4dwCSoaX7 JWSj+7dh/B0AAP//AwBQSwMEFAAGAAgAAAAhAPt79KJNAwAA8QoAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0Mi54bWysVlty2jAU/e9M96Bxvx2DwTw8QCY83J8mYQpZgGLL2I0suZJw oZ3OZFvtcrKSXsk2aRI6A4UfP+Sro3vPPT7S4HKTUVQQIVPOhlbzomEhwkIepWw1tO6Wgd2zkFSY RZhyRobWlkjrcvT+3SD3JY0+4S1fKwQYTPp4aCVK5b7jyDAhGZYXPCcMvsVcZFjBq1g5kcDfADuj jttodJwMp8yq5otD5vM4TkMy5eE6I0yVIIJQrCB/maS5rNHyQ9ByQSTAmNkvU1LbHKrl918sZIJE Aa9NawR1hwsaIYYzGFimihIE7KAJZwqQTIDMl4IQHcqKjyJf5HNh5t0Uc4HSSONU8y2n+lCFmVcG YfDgvJq+qpGwv4lFNhpgH8hAm6EFPdvqK0zCPtkoFJaD4fNomNzuiQ2T2Z5op14AMtgtCu3Oy4re luPW5ZR0NHdVlaEYpn7i4YNEjEOduvyyvPCmqMF0zRo+T1DJvNLMVnHlR8NHHS+BU0OW2ox5tNWF 38PdDGKfSrVQW0oMIZA29gEcLkA/xVrYhNl3CxB2piaUYBB+RZ4aTWgaPiDFEYlSha6xVEQgkwz8 BgA5AHYUNKeCJCyaY4E/v0LW9WEfVoak6wzhsaTw30S2aiIrNaE5xSFJOI0gCfc0WtMIRFEzfwZG oQGIFnRH3YkMa9kaguULhksWDZVwqZc0ZRzR1AUJOfyjlBSEHgBvmD4Cfpmk4nD0lu7jEegBXwuV HJx8+1j4NN6LDk5yVm23a21PsSIvhG0IAVut3eC//CJS8Dt/B8/HNLbAZLXYzU9tbEOby0n+EYPl a+f+4bVnXe/K8+xmbzq2295kZo9dr2GPp/2O1/e6PW/q/bQqE4ugVJVmJEhXa0Fu13p7gM6/Mou3 NlSamzaartN0YZNr9p5lC6lolPN2x6u7E3CuHe9v4zGKOrU/sRJlg76usYAV6h6d0ZHOy0inZmRB 04igm3V2/4oX7zRDLvc5OEQB9F5qjA2dWb79cWsybgQte+q6fbvduxrb/U6jY7vT7lXQbfdnsyDY yVfqyhlkd6xqnx5/fXh6/H0GzZpNszxNwaM+eZkDExXXOL8tzJ4DB03Q08QM5XC01HsvhD6HaIz6 qDr6AwAA//8DAFBLAwQUAAYACAAAACEAFk+0hDgEAABgEAAAIQAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxLnhtbMxY227jNhB9L9B/INRnrS7WzULsRXzrSzYJ1tkPYCTaFpa6lKRdu0WB /a32c/ZLOkNKlpN1sWlhFH5xKGo4OjNnhjOTm/f7kpMdE7Koq5HlvXMtwqqszotqPbI+PS3sxCJS 0SqnvK7YyDowab0f//jDTZNKnt/RQ71VBHRUMqUja6NUkzqOzDaspPJd3bAK3q1qUVIFj2Lt5IL+ CrpL7viuGzklLSqrPS/ecr5erYqMzepsW7JKGSWCcaoAv9wUjey0NW/R1ggmQY0+/RKSOjRgrSoU ZxbRYmIHG541BsuzJc9JRUvYeEIJsuRFzvQr2TwJxlCo2v0smmXzKPSJ+92jIEWOGtqTltO+aMX0 YwVisHBeHV93mmi6X4lyfENTcATZjyzg64C/cIimbK9IZjazfjfbPJyRzTbzM9JO9wFAcPwoUN0Y i741x+/MMY7wjlYZUQpH7+rssyRVDXai+ca87H7XKUObUX2zIcbrmRJaWytq3muXdEekdmuH9eiM KAkT13jE9wZu4Icv/RLHsR+gAHrHC2LXNRKnVhvVTar2kzo/oFef4a9mhaZcqqU6cKa9DT6hKSCH H+CWU8wYVtmflpAxpZpyRiGjWmbUeMqL7DNRNWF5ocgHKhUTROnokajyBkAoYL5Vyar8kQr68ZVm dB5N4cvgjg4hLA0//8zSoGNpuX023/QvQZTcPhuiILIh7Dpu306YN4i9qGVskCQR3AkvGYuALk2p ZiwOfZQ2TjCJoI038dP54yxjSBPfcQ8Ch5RU3OnMKaocsl8vKV8DWxB5kMWgYHsPt51mOWcrIAE3 ZQ1Zvig41w94xbEpF2RHOVwUe7wZgMGiUmYnDt0jVH0forBm70QPcNnph2WLD/XA0u+hBmGMniHX hxdBtngHPd6hF+g0uz68CLLFG/R4j2F4fYARZQs4PAGc+IlOi+sDjChbwFEP2PcTyNyrDGFE2QKO TwDHweBKcw5RtoCTHjCivdKkQ5Qt4OEJ4CiM9d1/fTGMKPVV3dV7RH+Bcg/18v+q+EFX8WdUMfLI acY2Nc+h5xhcovLnCpqc36DFpnwFdUlXf1OYsXPV3sPFUjsS+xPdQPU9y9ka3XdVK+ivsVn+PQzm cXgbhraXzCZ2EE7n9sQPXXsyG0bhMIyTcBb+YbV9Yw6mqqJki2K9Fexhqyzk7fvNmQGH7VfseD7M FF7Sd2MABbVcth8LO3YWdY194Ck/wSX4WUEjown6ZUsFfKHj6DstGjDwZo4u65Go84gepcj9tnx+ 5Rfdy8Ps1Q0O/2m0gJkVVJ91je6I9ZRxufAdTgbTibsY2DPfH9pBcjuxh5Eb2f4svl3EwXA+XyyO 4StxiKwA3b+N2q9f/vzp65e/LhCzups2AywscczVMyoXH2jzsNOXOMz1EE/Qy8JWA5M8NuMg2oug ju4/A+O/AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEAWxe/A2QDAAAoCwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWys Vtty2jAQfe9M/0HjPjsGB3PxAJlwcV9yYQrpu2LL2BPZciXhQjudyW+1n5Mv6Uq2SEnJDCS8GCPv Hu2e3T1S/2KdUVQSLlKWD6zmWcNCJA9ZlObLgXW3COyuhYTEeYQpy8nA2hBhXQw/fugXvqDRFd6w lUSAkQsfD6xEysJ3HBEmJMPijBUkh28x4xmW8JcvnYjj74CdUcdtNNpOhtPcqv35If4sjtOQTFi4 ykguKxBOKJYQv0jSQhi04hC0ghMBMNp7NyS5KSBbIEYu1hbSdryElaY1hNTDOY1QjjNYWKSSEgQE oa9gnIaYogVZS20migUnRDnk5WdezIsZ19435YyjNFJoNYrl1B9qM/03BzN4cV64Lw0S9tcxz4Z9 7AMraD2woHgb9QQn7EMQKKwWw+fVMLndYxsm0z3WjtkAIthuCnUvqoz+T8c16VSkNLdZVaYYXK9Y +CBQziBPlX6VXnhTGjCVs4IvElSVQCp+a7vqo+bD2AvgVJMl1yMWbVTi9/CrF7FPhZzLDSWaEAgb +wAOD6CfYtXhJLfv5tDhmRxTgmECavLkcEzT8AFJhkiUSnSNhSQc6WBgHgCyD+xIKE4NSfJohjn+ 8gJZ5Yd92BmCNhHCa0Xh60SeGyJ3egrNKA5JwmgEobinIFdRZSHGUxiCqtst6EtoGlOZYxhXMgIo BKugVXT7+IdyIVrSLdHvrIdqcl0OsVOPinNNPDzMljqpI1pgTkIGc01JSegB8LoiR8AvkpQfjn5e MXowXwFbcZkcHHzrWPg03osOunPSSWiZSZhgSXYGQBMCUmy0403qEkkY/h9wVGAam9bXEqBFRknR u9QmhmNC6fxPrzXteJeeZze7k5Hd8sZTe+R6DXs06bW9ntfpehPvl1VLXgSpyjQjQbpccXK7UofJ IaJVSaGSpY7TdOFsbHaf2xZCUSinrY5nqhMwpvTxX4HSHfXe+sSSVwX6tsIcdjA1eos+vaJIp2Wk bRiZ0zQi6GaV3b/gxTuFcMPdC6D3UqNl6MTt2xudj0eN4NyeuG7PbnUvR3av3Wjb7qRzGXRavek0 CLbtK1TmOUR3bNc+Pf7+9PT45wQ9q4/Y6u4Fr+q2pq9XlF/j4rbUGgr3U+insV4q4EaqTmowfTZR GOaGO/wLAAD//wMAUEsDBBQABgAIAAAAIQB1j6dPsgMAAAgMAAAiAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDExLnhtbLRWzZLaOBC+p2rfQeU9OzbGMuAaSA1/e0lmpgLJXbHF2BVZ8kqC QFJbldfaPE6eJC3ZYjIMqcAOezHG6v7U/X3dLV292lYMbahUpeBDr/My9BDlmchLfj/03i3nft9D ShOeEyY4HXo7qrxXoz9eXNWpYvlrshNrjQCDq5QMvULrOg0ClRW0IuqlqCmHtZWQFdHwV94HuSSf ALtiQRSGSVCRknutvzzFX6xWZUanIltXlOsGRFJGNMSvirJWDq0+Ba2WVAGM9X4ckt7VkC0Qo5el ZvSa58uth6y93MBKxxsBBdmC5YiTCj68B9MyIwxZewSMoSXdamum6qWk1DjwzV+yXtR30nrfbO4k KnOD1qJ4QbvQmtm/HMzgJThwv3dIJN2uZDW6Iimwg7ZDD0TcmSc4kRSCQFnzMXv4mhW3R2yzYnbE OnAbQAT7TUH/usnoaTqRS+eAlM4+vcaHAMZrkX1UiAtI2PDQ5JndbByqSd7sUxeo0UQbPTwkZAnK NRK1Xo2ppcl5K0u1i39PUJJEgzhsaIp6cdLtP+YqCnHPrhvGcB93cITtJg4JNmmg61RvxyLfGaY/ wC8Iaopm6FFikm9gmdILvWPU6gGskRRSggcYM2IajXL/3QIardITRgk0YqudHk1YmX1EWiCalxq9 IUpTiSwF0JYAeQXiaKiNFpLy/I5I8vYA2bBKUtgZ4nbx2hQMs7/WsftUR1NNd4xktBAsh1AikyE0 ghPsP0lqiDtQFNoCatbVw+nKxrgHg8XW/zFhk7Az6Jv1/0tYqDfENmyv4DOFNnRbndUjoRsxraLw cFtats6orQXNBIwpRjeUnQBvpT4DflmU8nT0btMqJ/M1F2upi5ODj8+FL1dH0WGeXrTFYtdiU6Lp o86yhDy3s3INU+UzHIWErby2p+xssVPSTFb78vO4tP3shoQbanZyPR1jKzj+zPn1BcezHr7G2O/0 p2M/xpOZP45w6I+ngwQPcK+Pp/gfr53gOaSqy4rOy/u1pLdrc0ieMg2h0G0cetQLOhGc/Z3+Q9lC KAblsupgp85cCDN4f558tqKeq89Ky0agv9dEwg5Oo98MvnM0uiwjiWNkwcqcopt19eGAF3tQPpcX uFsC9FFq7Bi6cPkOxt3JOJx3/WkUDfy4fz32B0mY+NG0dz3vxYPZbD7fl68ymXOI7tyq/f713z+/ f/12gZq1Z3dzp4RXcwu1hzCTb0h9u7EzFO7fUE8T+6mGGzeUjDF9MDEY7gY/+gEAAP//AwBQSwME FAAGAAgAAAAhAKXGGy5tAgAA0wUAAB8AAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTEueG1s rFTZbhoxFH2v1H+w/E6GIbTAKEPEWkVqCQrJBzgez6J6q20otOq/99rDEJrQkEp9AY/ves65vlfX W8HRhhlbKZni+KKNEZNUZZUsUvxwP2/1MbKOyIxwJVmKd8zi6+H7d1c6kcoxiyBe2oSkuHROJ1Fk ackEsRdKMwm2XBlBHHyaIsoM+Q55BY867fbHSJBK4n28eUu8yvOKsqmia8Gkq5MYxomD3m1Zadtk 02/Jpg2zkCZE/9HSELDRFc/8v9X3hjF/kptPRq/00gTzYrM0qMqAMYwkEUAMjvaGvVv4lOAGh+hZ eNFkIsk2N2J4RRLAhrYpBvp3/heCSMK2DtH6kj7d0vL2hC8tZye8o6YAdHAo6lHViF7C6TRwVrzK GLoRpGBoyQllpeIZMyg+4KyDCST7rOhXi6QC5DUh6k65/WlSElmwkdWMhquaDbrYNLU9Rb4bXSK3 00Ck5dmNKHyZQJu3hkMTYEGD2ljD+DuYywbMIkzqMYzOeRjnO31U2Q7DFIBEgZZX+9WJ244hwAvr Az0uAm/IiNHaqbxyvt6xiVu3cjvO4J4kIBjMg8yWxJA7GD0OrKaYydbDCqOsMq6ZD0gBvtBJUw2O 53jqNjzVoi/W4hGUPqbr8n/QBcJCalgnP1L8bU2MY6ZhLwz8P9IXeHlJUs6z8DB/TkfdQTya9lvt 2Xza6saDuDXo98at+Yf2vNfrjCbj2fwXPgwdjLuE7jzP5jnBVrgJZwQW5P5l1iNIEjeMY6+aC9pB 6VdkqvU9KU7QqF40cGx2D+XmC9G3mzAosFKBr0m40rBEfTZwfXLx7PkxH/4GAAD//wMAUEsDBBQA BgAIAAAAIQBpol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3Rl cjEueG1sLnJlbHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYsbz8pDBIojkLA m4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46fmDPnd9k205b 4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3v4zad/6/tqrr rsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl+ZI0568Zzg7y NkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j0tYh2T6mbP8n o7Pfb/kLAAD//wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1l Mi54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG7 7TBsK9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4P aBK2vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmI sYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5 k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd 2ynoGwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1 IPvYWMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivh GwDfqGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheS vqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829e P/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7k ZCTOt2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7n rMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g 1LHrHvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNN PFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY 8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9C tXaKcEyTy4p85oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7 L7JQf3WfYxtk0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpE OIVmu+5pIqHMSIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTO ymztWkYU1H4bZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8 cJEukhEOSOYjrfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpv T6QjS8rJyRJ01PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7 Lyjs1IFUSLWDZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69Z KeVTRcQgCo7QiE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCT x4UM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEzt gGiBe1mYhqCCi2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJla sUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9C xIpd1a43y/O9t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sf FT6zXyn0hjrkB1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKd xd/nNHbRnLnsnFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIY Ws+ByQNIfsvRLN36CwAA//8DAFBLAwQUAAYACAAAACEAdbFI/ggGAAA/HQAAIQAAAHBwdC9ub3Rl c01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbOxZ7Y7aOBT9v9K+Q5T9uaKQEEhAAxUDQ1tp2o7K9AFM YiDCcbKOoUyrlfpau4/TJ9l7/UGAmW6hna12t6gS4/jj2j4+99xr9+LpJmPOmooyzXnP9Z40XIfy OE9SPu+5b2/Htch1Skl4QljOac+9o6X7tP/zTxdFl+eSli9JKalwwAovu6TnLqQsuvV6GS9oRson eUE5tM1ykREJn2JeTwR5B9YzVvcbjXY9Iyl3zXhxzPh8NktjOsrjVUa51EYEZUTCDspFWpTWWnGM tULQEsyo0XtL6sMO4wlL8O90rn/f0JmTJhvAqdHw3P4F6ap90iETzpqwnjude269f1HHIdDZlHBw WdwKSrHE189EMSluBH7Er9Y3AmyCSdfhJAOE0YBqMN3UJ4du2vDe8Lm1RLqbmchwRQCPAyuEc7zD XxhEunQjnVhXxlVtvHj9QN94cfVA77qdALa2nRR3pXd0fzu+3c5zShIgyA0jMV3kDMsKI7VFPQ5g LK7zeFk6PIdNIxZ6r4COtYwA4FzFwpF3BcC0SAQw833P/W1FBFDQDNH9YJV8O7RUWNsN/D1Cfif0 ogaAhzgFrRAoqgxXowtRymc0zxws9FxBY6mYQNbXpcRlk67too5fz1505eYyT+7wNKbwFw4dnA7G L3Lx3nXYC1723I4XBDC1VB9qctcRuy3TvRbJhjlwzpwxK+VE3jGgGOmyNfNg0w5hc3BqptaX0Nkb qELEvGpXpqda9q4FOFegDU9uiCA4jBHUA8prbycGD+gBKNtdQVFz4fOMaFpGjIike3zw0eS38iGR rvHNk5nQjKKg7cH6Kt+wHvN/5IP4Wj7MWKKk6kMYjf2G5w9rzda4UQvGzVFtMLps1ZqNVmMQXA3D div4HYisHDWB45ZpRsfpfCXo65V2F3FAKqfM5JBRAnw1hAYCK/GS/bDu+aDzXoTOJRVXYSmPz9DA MnTC0oQ6LzIy3ydq88tEBQl7k4Nfo5znwwW4DR2UBYjEcapWsuRFNjdMVn6hpAy1TxWsHH5G0zwv aDZQvoDJ7aiFSqYwtHTWimbkrRn4HeysRcvGDyteR+kbgSRgnDKmJmHceYfiEoJNPJwyBxixFT/Q bBUmIRgszbw7veB0GVcb/Q6i6RAeg/j23Fiq2AFzGwVVm/kHBLBl6fUKE6c9BQy+TCw8pR2NxAB3 EBExruyHRC2IirUn0chQB1kUNOHfIY1aQdTGSh0lgXSGaNssoYqBR9EIFvcdThxpyCERHaxkPktN rNbBGJvuHz+GUAiQW0UCJyTdLwuX7A9ZGi8dmTs0SaVjUmSJTlhiiC4rHUO/BrCUh6gfO6VKgWC2 Y6ec0DjnicPomrIjzCtpOcH87SIVx1tXjDvB+jhfCbk4evHKW04xn84etP7YGU7bOvg4Bw/fz3lb j+HhM5CqvZxXO7jC4yQH1xEiAj/3Ie9RgmdDxH8y49mK+VRvxvoyes+/MhkOLVV0qvFqlU0PCNN+ DMJAOgGmH+KM4uNJnNnNkn9E5nx72jwaBB1vMIpqjavxqBZ4Ha/WicLL2rjVGIehPxheXo23aXOJ OSiHwzsuAlTZ8qePf/zy6eOfVRD46lxZhWX9bAFF+xgSM/GSFA48dcDVUkKeKzdQSpZQms59rIO7 v9xAKVlCicQxvK9AD1OwNdCua7Z9mrYGbmK6KbA1kJnrmpatgWRK17RtDajvgqV8CXdq/OM6s5w9 1xW2pF1KvVvduytnRFxjpN9emh24Md+S6QQuzOpiDk1CqmTAoeSaXwqYCfaMD0/cfEIXzPjhdetm xXXKj6d3ePV2llTgYxtew7F9JwW+96IE4OKqIUnY66VmVResGbyr9NxfM15jUosfJQcNlOiGuDxo iEtjW69QTbN9EVDK6WMOpKExryFnfBiCYiJLs8LHksQ+uvy4/EFQDD5BhY/XDL02XhrOACEqBqDW DkCRH6m3xzNAiIoBqF0B5PsREOjMIJBoRMUAFO4AFAZNDCpnF2OIigEoqgBCdNTDxdnFEBUDUGcH oHYrPIu0Sn0QFfXmtpsv4o2p+m/P/l8AAAD//wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAU AAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmW WFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9 xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57 kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfg NVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v6 5petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7Vm reHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwB RYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiL GR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs 3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3w qAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz +tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4 Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupw VqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pac fguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuU OO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9 cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKen NILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zw mh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2Dl dTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0s Tiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD /tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9M CrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKV b7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw 0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jk ou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXe a3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49Vm Lhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1 bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIX KD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA//8DAFBLAwQUAAYACAAAACEAtM9YGbsA AAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzhI/B CsIwEETvgv8Q9m7S9iAiTXoRoVepHxDSbRpsk5BEsX9voBcLgpeFmWXfzNbNe57IC0M0znIoaQEE rXK9sZrDvbseTkBikraXk7PIYcEIjdjv6htOMuWjOBofSabYyGFMyZ8Zi2rEWUbqPNq8GVyYZcoy aOalekiNrCqKIwvfDBAbJml7DqHtSyDd4nPyf7YbBqPw4tRzRpt+RLCUe2EGyqAxcaB0ddZZ0dwV mKjZ5jfxAQAA//8DAFBLAwQKAAAAAAAAACEABK6auwCAAAAAgAAAFwAAAGRvY1Byb3BzL3RodW1i bmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAqACoAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR CADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgED AwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRol JicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3 +Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3 AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIR AxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACivmL9q/wDac0f9lv4eaB4lbwR4q+K3xD+JHxC8LfBv4IfB zwRNotn4q+LHxe8b/b5PD3hWy1jxLqGk+GvDOjWGk6R4g8Z+OPGHiDUbfS/CHgDwr4p8SPDqlzpl ro2pUvgr8Qv2wdZ8Y3fh39pH9mT4PfC/w7c+GbrW9A+IPwH/AGp9Y/aD8OQaxpuoabaXPhDx5pfx H/Zx/ZZ8Z+HdZ1iz1T+1fCOoeDfDHxM8M3tr4e8VweL9d8C38PhG08aqk1W9t7NpxoVa1CrVm1To wxFDB0cwrYd16jhReIhg8Tha7w6m6zji8HFQc8Xh41XUTpKnz6Sq041qdNe9WlQniZ4SniPYx5qy w1TE0sRRhiHBUJ1MJjlGo/qOM9h9VUV84/Dn9sX9kb4w2HxL1X4SftT/ALOPxS0v4MWTan8YdS+H Pxw+GXjew+E+mpDrVw+ofEu88M+J9Tt/AlkkHhzxDO134ok0qBYdB1qQyBNLvmg6H4b/ALTH7OHx k8XeNvAHwg/aB+CXxV8efDUWh+I3gn4b/FbwJ458XeABfyTQ2B8beG/DGvaprPhUXstvcRWh12ys BcyQTJDvaJwompS5ItObw8MWop3k8LUhKrDE8q1+rzpwnUhWt7OUISmpOMW0TTpqTqJwUazw0nP3 VHEJ006Eua1qydaknSdpp1aacffjf22ivnH4c/ti/sjfGGw+Jeq/CT9qf9nH4paX8GLJtT+MOpfD n44fDLxvYfCfTUh1q4fUPiXeeGfE+p2/gSySDw54hna78USaVAsOg61IZAml3zQN/wCGyP2Qv+EH +JfxN/4aq/Zv/wCFbfBfxFD4Q+MXxB/4Xj8Mf+EH+E/iy5vbDTbfwv8AEvxZ/wAJR/YPgTxFPqOq 6XYQ6J4pv9K1KW91KwtUtmnvLeOQcopNuSSjRoYmTbSUcPipKGGxDfSjiJyjGhVf7urKSjTlJtIr 2c+dU+SftJYiWEjDlfPLFQgqk8Mo25niIwlGcqKXtIwak4pNM+kKK+AvjX+2nouneHP2MPH/AOzb 4y+Dvxr+GX7T/wC1x8PPgPc/ELwx4itPiP4M1DwP4m0b4lT+ItY+H/izwF4qj8P3fiHTNd8DR6VF qEl54g0iyni1exvtHuLyNTabWift2/CDwp4G+IvxC/au8f8A7O37JXhjwh+0t8WP2efDOv8AxD/a t+CeoeFvGL/D/WtRtfDep3niz+3ND0PwZ4/8ZeHdMufE2qfA/Xbp/iH8Po4LvTPEtu1zZXMiKElP 62n+6lgcXisFiI1/3Mo18HS4aq14L2nLGU78W5JTp0Yt4irUrV3Toyp4TE1KcyTi8Pa1RYrD4bE0 XRaq81LF1OIoUpNU+aUYJcLZxOrWcfYUY0aEatWFTF4anU+46K+WvGH7cv7FHw98B/Dz4qePv2wv 2WvA/wAMPi9Fdz/Cf4j+MP2gvhN4a8B/E+DTxCb+b4eeL9a8XWXh7xrFZC4gN3J4a1HU0thPD5zJ 5ibu1+LP7S/7OvwJvfAmkfGn4+/BP4Qa58VtQn0b4U6P8U/ip4G+H+p/EzXIJtJtX0bwBp/ivXtI vPGeqJea/oNrJp3huLUbxbjW9IgMQl1KyWacRUWFpVq1WM1GhOtSqRUW6n1ihT9tVwsYfFLFRpuM nh1+9tKLcUpJtR99QcWnGpQniqcr+7PC07upiYy2lh6ajJ1KyvTgoycpKzPcKK/IjQ/+Cj3xG0X/ AII7eFP+ClHiv4SeGPiN8ULz4C+EfinqXwd8FeI774X+FfE3inxRr2leH4fDegeJPE0XxLvvCeny 3erQtBeawviZoNhW5mKOZ4fRvh9/wUo8K/E/Qf8Agn3r/hX4Z6rEP23Pi58Svgh4s0DxD4mt9J8U /s5fEn4PfBr43fEP4m+DvFukW2hapF4m8T+C/HvwO8QfCjWdKjv/AAxCl3cN4ptdQurO1t9K1Ppl RqRxWMwVk8RgalCniIXsr4mti8PSlSlPlVeCrYKtCvOjzxwjnhPrbofX8D9YVRqlCU5tKEKGYYib T5vZ0cswv1zFyqKN3TksKqlbD05qNTHRw+MWBhiJYLFxo/pjRXzjpn7Y37IuteOviT8LtG/an/Zx 1b4mfBnQ/E3ib4wfDvTPjh8Mr/x18KfDfgua2t/GPiH4k+EbXxPLr/gXQ/Cdxe2cHibVvFGn6XYa DNd20WqXFq88Sv47+yN/wUu/Yr/bZ8N6TrXwM+Pvws1jXta8Y+NfA9j8NLj4qfCfUPijJrXgvV/G 9ozf8Ib4P8eeK7x7XxT4b+H/AIg+JXg0wyy3et/DGOHxkbS1sFvVssqa9rFSpfvIyw9PFxlT9+Ms LVrSw9LExcbqVCpXjOjTrJunOrCcIycoySKjVG6q/umq88K1U9xrE06XtqlCXNblrQotVJ03acIS jKSSlFv7worylfjv8D20e98Qr8ZfhS2gab8To/glqOuL8Q/CJ0fT/jNN4stPAUXwjvdTGsGytfid L451Cw8GR+AZ54/FT+LL208OrpJ1i5hs35Pwp+1p+yr47+LviP8AZ+8D/tM/s++Mvj14POsjxd8E fCnxm+HPiH4u+Fj4cngtfEI8R/DbSPEl54z0Q6Dc3Vtb6z/aei2v9lz3EEV95EksasotS5XFqSnT nVg4u/PSp0MPiqlSNr81OnhcXhcTOavGNDE4etJqnWpylU06fNzpw5KkaU+f3eSrOvWw0Kcr25ak sThsRh4wdpSr0K1JJ1KU4x+gqK/NT9qv/gop8KPAP7P/AMXfHn7MHxp/Zv8Ajd8WvhVc/AO81vwL o/xG8N/El/D/AIV+NXxZ8AeCtM8Q+LfDHw98b2fiXSdN17wz4rv9V8Gatd3mnadql1FZX1u2q6ek 1pc/e+h/Ej4d+J/FXjrwL4b8e+C/EPjf4XzaBbfEvwdofinQ9W8VfDu48V6OviLwtb+OvD1hfXGr +EpvEvh9113QItfs9Pk1nR2XU9OW5smE5mM4yhKomvZxU5uo2uR0qao89aMvhdGEq9OnKqnyRqv2 baloxpxk4NNTXInBq0oupTjVppxeqc6U4VYJr3qc4TjeMk32lFfmx8Fv2yf2lP2jT4e+L3wW/ZI8 EeI/2NvF3j6Pw34P+KmvftPDwt+0J41+HkPiaHwZqXx48Kfs8TfA3UPhlP8ADA6omq+MvDlt4h/a s8M/ETxX8INJPi/TPAi+NNZ8O/C/V/qbVP2tP2VtD+NWn/s2a1+0x+z7o/7RertZppXwC1T4zfDn T/jVqb6jpT67p66f8K7vxJD46vWvtDjk1mzW20KU3WlRvqMAe0VphpBOccO1pPFT9lQoT/d4udT2 NDEezeCqcuLpzVPEQi41KMJKtDEYdpYjC4qlRJp03XUrcuGh7StVi1OhTp87puo8RByoOCkrOcaj ilKnK/LUpuX0DRXz3N+1v+ylb/Evw98F5/2m/wBnuD4xeLdW8QaD4U+E83xo+HEfxL8Ta54S1DU9 J8VaL4e8CP4kXxTrWreGdU0TWdN8QadpulXN5o2oaRqdnqUNtcWF1HF4D8Bv+Co37Cn7RfiX46+E /h7+0l8Gm1n9n34izfD3xjb6n8Yvg8Tq8SzeBNJsviD4Ui0T4g65dX/wy1rxn8Q9C+GuieLNUttF XUfiTFf+DobL+1Y7OO9ilOFbWlOFSLwdfHqUJRlCWDwtTB0sRiITT5J06M8fg/aOMm4QrxqNezUp xVX9xf216XLiqGCkppxlDFYqGLnh6E4v3oVK8cDi1SU1HnnQnTi3UtF/oFRXzDfftt/sY6X8IbT9 oPUv2uf2YdO+AmoeJZ/Blh8b774+fCq0+EN74wtri+tbnwpafEq48WR+DLnxLb3WmalbT6FDrT6p FcaffQyWqyWk6x+YeJP2vYdR/aQ/YY8A/BzxB8LfiZ8D/wBrPwR+0Z4zm+JfhjVV8Z22q6b8KPCP gbxD4L1X4a+MvC3iaTwhfaHrVx4mvxql89n4kt9RtIbQaTdac8c09w7+8opNvnhTk0m1CdTCTx1K NRrSDrYSDr0VKzqUpQqQvCSkOScJck/cm1VahP3Zv2Ff6tXtF2b9jiE6Fay/d1oypz5ZpxPu2iii mIKKKKACiiigAooooA+Df28fgN8WvironwB+K/wCh8Na78a/2R/j/oX7Q3gb4ceNdcbwp4Q+L1nB 4J8dfC7x/wDDLUvGUOi+IJvBeteIvht8S/Fr+A/FMmk3uj6X4/svDI8TxQ+GbjV7+x/Nvxr+yp+1 r+1J8Rf2pZfBHw+/bU/Y0+Hfx2/YS/a1+DniTw7+2D+2lbfGv4e69+0v8e9b8AN8KvGfwp+EHwl/ bP8A2wfAnwn8K/DTQtH+Jel64/hbw58I7Xw/ovjTS9E8D+FfEunvf6doP9C1FYfV4OGJpylOVPFQ zqM4ScZKDz7h5cNY9wbjzuCwVPC4rD4apKpg6GaYLDZjHDOv7d1umOLrQqYStCSjWwcsqdGqk21D Jc9fEOApOEnKilTx9bHwqVqdOGKr4LM8dgquIlQeHhhv5t/h7+xx+0p4v8A/E61+Ifw2/wCChsXx g8Mf8E3/ANoX9lT4SWfx98S/8EddJ/ZuFz8SfB/gvSU+Fnw+u/2HrX4e/GDV9Pl8TeDPD0vww1b4 2eFfDHgzw14a03Wb/WbTwT4i1p9NuvU/j5/wTz+PXxC8BfsofCX4OeFvDPwesvD3/BJ/9s/9jHx9 4s07UPCOhaD8LPHvxi+GX7Mmi/DHwtdWXha9k8Q6h4YPjT4e+Kr64vPh5pHiLR9IGhXF9OQdT0qL Vv248a/FX4X/AA2v/A+lfEX4keAvAOqfE7xdZfD/AOG2m+NfGHh7wtf/ABC8eajbXV7p/gnwPZ67 qNhceLPF1/Z2N7d2XhvQY9Q1m6trO6ngspIreV072tsSnjI4+U5SSx9GpgcTOk+W05YXjaGKlF2l FYvEU/EnOcVi+ZS9rVqYCvOnyzxSx2GBqPLa+Uzw3LGWTSrYnA0aiUqap4h8OUaPPSdufD4WfBmX xwKjyxp1KWLjebhRjhf5t/h7+xx+0p4v8A/E61+Ifw2/4KGxfGDwx/wTf/aF/ZU+Eln8ffEv/BHX Sf2bhc/Enwf4L0lPhZ8Prv8AYetfh78YNX0+XxN4M8PS/DDVvjZ4V8MeDPDXhrTdZv8AWbTwT4i1 p9Nuvs343/BL9pv4f/sU/sP/AAy/Zn+Gd5o/iL4I3fwP0/4naB8DvDn7IuofH74X+EvCvwf1zwt4 gu/2VF/axnX9knRPiJaeK7zTvC2u694xmuLKP4S698SV8Dm88UX2h+b+vdFaValSrOvUc5RniMTk WLqunJw5q+Q53xHn9GTSdpLH5hxTmjzVSUljKcqaXsqksVVxONGlToUsNRhCLpYTBZ5gKFOa5o08 Pn2U5Jk1dRT2lgcJkGAeWuNo4ar7WU41qfsadH+e34KfsT/tY6F8LvgXZeNPAvii98W6V/wWO1j9 svxvdeOvF/7OT+Po/gv4r0XxxqFz8QfiC3wN034dfBu4+IL6p4ntIPHXhb4TeFfJXxbNrEnhq28W aHFH4y1nY+JHwe/bz+GP7L/7Tvwq+DHwI+J2veIf2qP+Cjf7QGteMPEXwZ+JX7Oui/Fn4ffsbfFv xLda54m+K/wsufix8b/hV4NT4neLvC2n/wDCC+BbLUvHGheKfh5rXjGP4h3+k/a/BkGiar+/VFct PD0adP2MadN4d4Ohl1TDTp054atgKOD8O8BPB1aE4Sp1MPisF4aZJhsVSceSpSzDO4RVNYnBLL93 UqOssQ6lRYiOLr4+niI1Jxr0sdVxXHeNhi6VaMlUjiMLi/EHN8RhqnM5Qq4HKJTdR0MZ9f8A5xPi N+yD+0T4Y+NPw9+NnwA+B/7avwU+But/sMeAP2RrP9mv9mC9/wCCR2q/Gj4H6b8KfiF481FvBPxN 0v8AbY1f4wfs/wCo/DD4h+FPFeh3cV3+z38ctU1i61nwlb2vxM0DXvM0XUPDfqXgf9l34ufsu+Ov Aep+Bv2OPip+1l8JPHX/AATW+CH7FGm+Efi18Tv2VI/in8Bb34V6/wCN73VvBn7T13r3xH0f4Wa3 8MfipoXxN0Kz+K2u/sxaf8bxBqXwbuYNH+FXjTR5vBw1P96a5LQ/H/gTxN4k8aeDvDfjXwl4h8X/ AA3vdG034ieFdD8SaPq3iTwFqPiPRLXxL4esPGmh2F7can4Wvde8OX1l4g0a11y1sZ9U0S8tdVsY 57C4hnfWtF4mji8NVnOrHGVs0xWKlUk62Iq0c0XEtHF0amIq+0rvDRqcZ5u4TdT26q4tRq4ipHFY 2GMiCUFaMYxisJlOEcacY0YJZK+G3l+IjCgqUKeJpf6qZKnOlGEJRw3J7NQ5I0/xTtv2Lf2jrD/g gz4F/YlX4c2X/DSPh39n/wCFXgC9+G+meL/BR02DxJ4U8f8AhXVtX03T/GF1rem+C5bKz0rS7y6t L1tYtLa4ghjgiVLyRLKs340fsD/tD6H/AMFUv2aPjV8BfD8Gofsi+OfjF8TP2lv2kJx4p8MaPc/A b9o23/Y++M/7NUfjzw14X1PWtG13xHpP7QmmfEH4cf8ACRWXg3T9cv8AQfHHwv1TxZrZs7Xxtc3t r+9dFaYp/XMdiMfXV6uLp5hRxUIynTp4jD5lTq+3w1WUJRruhHFSwuZUoRrx5cyy3LMXJzlhIpzT j7PD4nDKzhicG8JzOFPmoN0K+G+tYaEYRo0sUsNisVhlJUnSeFxWKwsqMsNiK1Kf83f7Av7DP7SP wc8S/sWfCn9orRv2/tatf2MfEXje/wDCPjnSte/4JKr+w8PEtz4D+J3ge/8AGmi6l4B0HwF/wUe1 rwb8U9E8a6nqFx4d8e+HtQ8XXXj7xJYXnxVuPEyaDdeOZO28D/sz/tZ+Ff2ONO8Cw/su+Kof2k/2 Gf24/G37T/7P9xP8TPgKngn9p3w94m/aj+MnivX9G+FHiyw+Lk2t+Cz8Qf2afih4r8FalH8fvDHw dGj+JvGFhbXVlrGl6bql3b/uIPjN8H20D4leKx8V/hqfC3wYv/EulfGHxKPHXhc6B8KNT8GaPB4h 8Yad8StZGqf2d4Fv/CmgXVrrniWz8UXOlXGhaPcwanqkdrZTRzsxvjX8Gl8VfDvwI3xb+GS+N/i/ 4d1bxf8ACbwa3j3wqPFXxQ8J6Bp9lq2u+KPh34eOqjV/G3h3RdK1LTtT1bWvDVnqem6dp9/ZXl5c w211BJIq062MjRftprExeHzGjjaEaSxUsdLEUM9wOd6U5UK2JUco+sYfnoVMur4LD15VMHXo0nKn U/ZxlUnVpwVGTq4GrQnKrDDvBRp5jlGYZL7tSE6OEry4iqYXFwo1KWNo4mvhoYfFYWtWqLEfiN8J P2Av2mfD/wAcPgN8PPFvhy1s/wBnO0svh9+298afiLZ+LfCerxxf8FBPDnwJ1v4HeJvCWj+GLjVv +EpFnqnjbU/Bv7R+meINE8MQ+Ck8XfD7VZ7jWLXVfEsWkSZ/wL/ZY/afuPhN/wAE5f2P/GH7IN98 J7r9gX41eB/iH40/bB1r4gfATW/hj8QLX4NJ4w0bXvFP7P8ApPw++LHiP9oS78cftbJ4gkvfGlr8 XvhH8GtO0Xw14++Jj+L9S1rXrDSPDPi/91dN+Lfwp1n4keJfg3o/xN+Huq/F7wZoOj+KvGHwq03x p4bvviR4U8L+IXMegeJPEvga11KXxPoWg65IrJo+sappdrp+pupWyuJ2BFY2o/H34E6R8M/Enxp1 b41fCXS/g54Nu/Emn+L/AIs6j8R/B1l8M/Ct/wCDfE194K8X2XiTx5c6zF4W0O78K+MdM1Lwl4kt tU1W1m0PxNp99oOqJa6raT2sanOjFVMRGnQw2DeYYLOXSpJUsBRxnDuNqf2NiKScnGjT4ehhsNk1 ClCpHD1cuyXLcvzenmH9nQcZlSnXpTwtWVWvWrZdWyCVaSisZPB5vgK6xuE/dQhFzzWOMx2apeyc 8PiMwxmIyhYHDVvZL8ZIv2Dvj1Yf8EPtG/Yy8MfDaLwJ+0PdXHg/Uta8L+ENa+EtjqWmeJH/AGrd D+KPivxhB4jvtQ1P4W6p4ng8OQ33jOa+1e716DWdUgFrf2etajcPpVz9w/sC/AX4o/s6fC/4ofsu fE/wrFqOi+DfGviO+8F/tR2OqeFrnxD+1l4e+JrXuv3/AMUfjNYwalN4yj/ak07ULm50P48+LPE2 gx+Hfib4jt9L+JXg3V3tvFGreBPh99X/AAT/AGjf2ev2lvD2qeLv2cvjv8Gfj/4T0TWH8O614n+C fxQ8EfFXw9pHiCOztNRk0LVNa8C65r2m2GsJp9/Y376Zd3MV6tne2l0YBBcwu+z4K+NXwb+JPiv4 ieA/h18Wvhl4+8cfCDV7LQPiz4M8FePPC3inxX8L9d1KO6m07RPiJ4d0PVb/AFfwTq9/FY3stlpv iWz0y8uo7O6eCGRbeUpFTDxlLMaFak5LM8C4YvD1FJc2Af1CEJQS5atLDQh9WpxlCSoyji6ftFUk sDKhftnyUZxq8qoZksVCvCSTlmDji4SjUlrCtWm54qVqilWhUjiJUpU3PFe0/Mj9ij/htD9kf4M/ Bv8AYd8Q/sYeL/iYnwMvNC+Dnhb9q/QfjR+zt4d/Zt8U/AnQdXtIPDvxJ8TadqfxHb9p/wANfEPS fhc50/X/AIdaP+y/4q0jVfi3og0XS/HkHw+8QH4l6D8veJ/2Tf2pdR+CH7Rn7A7fsn6r4jn+Nf7b vj/9oHQf29dR8f8AwCX4M6P4b+IH7Qum/tFeHfjD4i8P/wDC17L9qaP9oD4J+HktPhZ4O8O+H/gP Pol54y+HHgYWXxQ0T4e3lx4s0H93NC+Mnwh8UfEfxx8HfDPxV+G/iL4u/DKx0DU/iT8LNC8c+GNX +I/w+03xXZx6j4X1Dxx4H0/VLjxN4TsfEmnyxX2gXevaXYW+sWckd1p0lzA6ufSK6I16s69HMa8/ rletCcq+KrWUszjPHZRjqlWtVw3sOXnzHI1iXPL3hFHE4nFyhySw+WLLYrwjUw2Iy9x9jRlVhXhR g5c2CqyyvNMDQlS9q6k5JZZn2IjCGN+tU61GWHnVhWjOq6/4KeI/2HPjxB+y5+2B4b8JfBzRLX40 fFX/AIK1+Ef2tvBUlrq/wwtdY8TfDvwt+2h8BviVpfxPvPEc+vR6dBq2ifCTwNrt7pum+ItUtPGl rpukR+GbTR11K507RrnkPjf+yV+0/wCOfhn/AMFVP2Zj+y/rnjHw/wDtNftcfDf9ov4V/Eibxx+z /dfB74m/Dm5v/wBkK18Y/D/V9C8T/FXS/iXonjTRLD4c/EaTX9H8YfCyx8B6zo+gSRaH4116/wBb 0fR9Q/crxD8Z/hr4V+LHw1+B2veJPsHxR+L3hv4jeLvh34X/ALH1+6/4SHw98JX8HJ8QdQ/tuz0q 48O6T/wj7eP/AAkPsmuavpl9qv8Aa2dEttSFhqZsuj8f+OvCvwu8CeNPiX461X+w/BPw88J+IvHH jDWvsOo6n/ZHhfwppF5ruv6p/Zuj2eoavqH2DSrC7uvsWl2F7qN15XkWVpc3MkcL8eHlQyzAUXKt BZfg8khlUquLqRWGlgMqwvBmWVMRXq3p0o1KE/DfJ54utCVKlHE0cypVYRw8oYXDdM418bXcYUqk sXiuIsRxBhnh41HiYZnmGMzyv7HCKPNOeH5uJc1w2Gw8o1pxhiYzhN4yEcSfnv8AtXfDP4veEv2s f2Pv2r/hb8AvE37TXgv4G/Dn9on4O678E/hn4j+C/hL4heBtQ+M1l8Mr3wv8aPhzB8ePiR8GPhff jQbD4X6z8KvFOnTfErQPEdl4W+JzXPhrTNds4desU+Vf2Y/2LP2hvA/7TH7OPx28Q/CLR/hj4O1f 45f8FG/j/wCN/hhovi7wTqcX7OOn/tR+H/hRbfDzwBrR0XxDcaN4k8ceKdZ8I+I/GvxLk+EUfinw DoXxH8V+LLbT/E3iLRUsPHHif9v/AAn4p0Hxz4V8M+NvC19/anhjxh4f0bxT4c1P7LeWX9o6D4g0 621bSL77FqNvaahafa9Pu7e4+y31pa3lv5nlXVvDOjxr0FdSpVcHXnGrCpHFYehmmWNYmMo4jD4f M82hnOaYOpGSjOU6ucUaeJlUxSq4zDOjHBUK1HAqWEfG5UcZQwsqUqTw0a+CzKi8NKPsK9bC5Xi8 pwOJi4OVN045Zj69GMMP7PD1+eOKq06uK/2hlFFFQahRRRQAUUUUAFFFFABRRRQB/Nl/wUIuviv+ 1l+0j+0r4U+CX7Lfx1/aOm/Y1+CPhr4e/BHx78Kte/Zi0/wV8G/2/vEWvfD79qq28V+K7D9oL9pL 4E65qGs/DjQ/BH7LM1jq/wAMtD8dX9jonjf4leGJ7jTtSvp9G1L7H/Z4/wCCgd58b/2gvAniPUvH ei+Bf2e/H3/BLLwX+19P4U8Tp4U0Cy8F+Po/irr2gfFjWdY8VavaW+v2lv8ADbTYrLwv40s9R8QH w14Yms0vNTsrK/umvJ/1f8M+CPBfgpvEb+DvCPhjwk/jHxPqfjfxc/hnQNK0FvFPjTWorO31jxd4 jbSrS1OueJ9Wg0+wh1PX9TN1qt/FY2cd1dypbQqniHiD9i79jrxZbeAbPxV+yd+zT4mtPhT4r8Te PPhda+IPgT8LtZtvht458aeJ4vG3jHxn4Bg1HwrcxeDvFfizxnDD4u8TeIvDq6drGveJ4ote1S8u tVjS7HKqNaODw+Fp1nFRo4ypVk3P93meb5BxRgszxFL2cqTxNClnvEOAzbLY4zmxmGwnC2RZfTxt CVCjisLpiJQxEsXU5ZUp1ZYSjR9lNJRweW5hkGJwsbzjUlhq+LwPD9XAY1YVxwsa3FPEWYyw+M9o 8FjP56/2JPFnx8/aT/as/wCCdf7UHxA/a0+M+rfEL4j/APBJDx18a/EvhDwj4T/ZP0rw38QG8O/H L4CweJPANnZTfs432t2Xgv4n39zp2seLbvw74h0vxjpesLp0Xw/8beA9BuLrRr36V+C37T/7Vl38 Lv8Agm9+2Hrf7Xd78S7v9vD40eAfAfj/APYzv/hr8C7P4VeCdI+K+n+MNX8Y+G/gNqngb4XaH+0f pvjn9k638N3c/jrVPit8Zvi9ot7o3gH4mv4u0XRbm60rUvCX7LXv7J37LOop8Go9Q/Zp+AF/H+zn dfbv2e4734N/Dq6T4EXom0y5F58Gkn8OSL8MLoXGi6NP9o8EDQ5fO0nTJd++wtWij8E/sk/sqfDT 4reK/jv8Of2Zf2fPAHxw8dtr7+OPjL4J+DHw48K/Fbxk/ivVIdb8UP4r+ImheG7Dxf4ibxJrVtb6 vr7avrF4dY1S3hv9RNzdxRyr3uVPkw9GnB0qOFzPH4yjBPnjHBYrjDPeKK2WqkvZ01SzjCZzh8kx lZ808oWVPNcpUsTnGPw8cMVF16maV4SVPEZlgsPh1KnT9isNi6HDWA4dw2Ng4zqOcsrrZbDOcPSt D+0ZY2WU5jVeGyvA4qp+Cnwi+OX/AAUP+I/g7/glz46vv28/EWnXn/BQL4hfGX4KfE/QLX9nP9mq Xwz8N/Dngv4U/HP4n6D8Sfg3HN8O/wDhJNO+O8OmfA8aJc678S/E/wAUvgZdeIvFt34of9nUaFpF p4CuPc7H9sH496P8BPH3wg8VfG749+PPjxo//BSj4rfsQ/CT4gfAn4O/spXX7VPxx8P+DdEufjBo tpplt8Yrf4Z/sN/Dr4haN8O01GPx18SPH/gXTvh1qfgjwF4ij8MfDzTvid4w8MXmj/tZpXwS+DGh 2Xw403RPhF8MNH074O6nqWt/COw0rwD4U0+y+Fms6zpGveH9Y1f4cWtppMMHgjU9V0HxT4n0TUr/ AMMx6Xd32keI9e026llstX1CG45vxt+y/wDs0fErwb4v+HXxG/Z3+Bnj/wCH3xB8aP8AEjx74E8b fCTwD4q8G+N/iJI9jJJ498X+GNd8P3+ieJfGjyaZpsj+KdZsb3XGfT7FjfFrSAx8/K41Wo80sLKj GLouo1WVeGfcNY6Fanipwr1IOOT5dn2WuElUo1p5xCWJoV6dKSW1WXPOjVp8tKpBOdT93GVGpWeW cXYVueGi6dN0JY7NeGcXKhB0bRyGqqFTD1sQqz/m2+JfxF/aB/aq/Yw+Beo/FD9pP46/Drxf8I/+ C1/wz/Z2/wCEkm8P/sNj4p6rYaL+1X4R8NeAtQ+MjfDz4f8Axv8A2brv40fB+4v10u2ufghLovwt 8ReKNLA8a+B/E0Mt54ci+o/ip+0T8XP2Z9c/4KgS+C/FHhNPF3hT4xf8Ezvgy37Q3i74UfBzTvEf hm1+PHg34N/Cjx3+0p8bb74eeB/hvpnxM1r4eaR4pvfHFkvi+0m8GeGm0fTvDmk+HtE+Gdi3hOP9 jbb9n79knxp8JvFfwFs/gl+zn4s+BU+sxaB44+DFt8Nvhnrvwmm8QeEX0DyNF8V/DqLRbrwfJrPh iTw94X8rTtX0dr3RX0PQNkNs2mad5HW6X+z38A9E8MeL/BOjfA/4QaR4M+IPhLSfAPj3wjpfw08G WHhjxv4F0Hwinw/0LwV4v0C00WLSvEvhLRfAcaeCdJ8OazaXuj6d4RRPDdnZw6MoshdP93g4UUlV 9rjcszbEuDng6WbxlkHA+BzOmpUalWtllDOK3C2KxX1nAVq1V4bPKEqco1cnwVStlGN8e8TOUoKG FzPK4U3y4meX0v8AWPiTNcA/fjQp4+tltPPoYL6rjKVKhRq5Okoyo5pi8Phvww/ay/aU/bK/Y31j 9pf4K+Bf2wda/aB1nw7+z/8As5/HLwj8Ufjd8I/gHqXxH+A3jH4gftd+BfgXN4I8faV8Avhb8Bvh Z4r+G/xd8Gaj4n1rwbo+reCvDHxNt5/BfxFn0b4hXVs2jX3gv9Av2cfG/wAbPAP7cHx6/ZE+Kfx9 8b/tIeHdL/Zp+A/7THgnxl8SfBHwX8H+LvCGp/ET4l/Hf4aeN/AVtL8Dvhz8KPDer+BYj8MvC2ue Dk8QeFNX8baPcX/iS117x54ptp9JTTPqDwJ+x5+yR8Lfh74g+Efwy/Za/Zz+HPwp8Wa/p/ivxT8M fAnwR+GfhD4e+JfFOkz6RdaX4l8QeC/D/hjT/Des6/pt14f0C50/WNR0251Gzn0TSJre5jk02yaH 2SHwP4Kt/Gl/8SIPCHheH4iar4Z0vwVqfj2Hw/pMfjTUfBuh6pq2uaJ4Sv8AxSlouuXnhnR9a1/X dY0vQbi+k0rT9U1rVtQtLSG71K8mmdH9zPCKc/rEILNI46c6cKdTFU8XQzSrllOnTi508NPKMfis so/WaLjXx+BypyxLVTHYigia56WZRSdOeIq5XVy5RqSksBLC1shhmfNVtCriKea4XLs3q/V6qlRw WJzqVOgnDC08RL8LP21v2Vj4q/4KC/Cj4L6L4hj0n9nj/gpvpt54h/bg+Gri5gj8dz/sLWPg/wAW eHn8PS2CIbZvjv4X1jw18F/jxFcXNsniT4WeCtE06GVpmvorz5H/AGmvi98UvGPxT/aZ/wCCgPwt /Y/+Pnxd0T9jr9of4c6b+z1+0J4Q1f8AZlPwf8M/A79iK78ceB/21dLs/DvjT9pLwP8AtAi58d3n xF/a7+G/iCb4cfBDxTaeKrLwt8NL3RLjxUmlW8Onf1Gan4J8Ga14m8MeNdY8I+GNW8ZeCINetvBn i3U9A0q/8TeEbbxVbWln4nt/DGvXVpLqugQeI7TT7C116LSru0j1i2srSDUFuIraFUpeHvhv8O/C Pgz/AIVx4U8BeC/DHw9+z61af8IH4e8LaHovgz7J4kvNQ1HxFa/8IvptjbaH9n1/UNW1S+1qH7D5 eqXmpahdXyzz3ly8nPRjXwlPCPDOlOtlmIxeZ5dHEqc6Uc3nmOAxeAr4qpFrGVsBg8DgVkqyuniK WDWV4rE4aFKNOpUhV3m6OIdeGKjVdDMKdDAZmqFX2arZR9VxGHx2GoYWUZYGnj8bUngcXUzOph6t aWJyrCVsRTxGJjRxWG/mo+LPhnV4/wDgoP8Atvf8FJf2ctLl8b/FH9krwl+wv8QpNG8NJFc3nx5/ Y6+I/wAE/G1z+0N8KbNIts+u6hdeBLLTvjD8KNOhmeSf4sfDfwZa2cFyusXtpeeYfsSeNfhd8Q77 /glf47+ImoaD4h/ZL8cfth/8FgvGvwX8T+IZrN/hRr37Y/ij9tD4kax+yLqF5JqUh0tvHmo/DC8+ O+ofAqbUbUTt4supm8LyP4z/AOEfjT+pH4f/AAZ+D/wmiuIfhZ8Kfhr8NIbvw94N8JXUXw/8C+F/ BsVz4U+HWjSeHfh94YuI/Dml6ak3h7wJ4fll0LwbosgbTfDGjSSaZoltY2TtAeNl/Z2/Ze8L/AjW vgNP8C/gJ4d/Zkj0nXpPEXwZl+GXw80j4EJod9ql34u8Tya18O30S3+H66Tea1Nf+J9ea+0cWdxq kt3rWoF7uSa5PRz0sE8ZPDuX1TDY6vmGVU8VUp0/q8MSsb9eWLr+yrU6Uqc3gc5yqrQo+wyniWnj c8qYXMKmKlQfPClVxGCwmFrtSx1SrCOYVqNKVSji4xy3NsBhlTwjqU3UlF5viMHjKdapOrmmSfVs oWKwEMBhqp8wfsv/AB6+IHj39r/9qT4NfG/9mD4D/Bb42/Cz4Nfsy+MNV+J/wV+NWt/HRvif8N/i d4m/aJs/AXhXxJ4p8Xfsx/s3eLdNPw61bwD431PT/D9zaeLNBspviBqdxo17Z3N5q7X34p+EPij4 X/YC/ak/am/4KMeML6TQPgTrn/BQX9sb9k79r2/tNMluIodB1HwX8Mvih+zF8Q9UltpoI1vfCHxb 0LxL8HdDn1RJbUSftIS2pu9OUiST+lD4Bfs9fsy/s+eFbvTf2W/gd8Cfgh4J8aXVn4sv7D4BfDT4 f/DXwr4svbjTraCw8TXdr8O9F0XSNdup9Ijs4bPWZo7qWXTkto4blrZYgOi1L4FfBHWfD3i3wjrH wc+FWreE/H3jW3+JPjrwxqXw98I33h7xr8RbTVdD1618feLdFutIl03xH41ttc8MeGtZt/FOsW15 rkOq+HtD1GO/W80mwmt5lSnQzWGNoSlha1Lh/H5BKbpc1ejLNs34arZvXhQrzq0FWqZPlec5fS9r CdKljcfh8csLT9j7CnVWdPG0J06kYzwlfO8tziNCFZzpKllnDmcZbgIxxDg6uIVHOcbl+e0I1XL2 dLCLLfrFWnSpYif8znwZ1L4yfsX/ABe/b8/as8QeBofFP7WviX/gkH4T/bm+KfgrUBfX9vN8aPFX x3/bF8d6J8MdRFlqov73w18HPCGl+BvgraRaTqlrcXPg/wCG1p/Z81reTiQfTPxs/am/av8A2IdK +HnjrQv2tL/9v3/hcn7EX7U37REvw8+Ifw0+CGk2HhnW/gR8DLD4u+D/AIwfCC7/AGYvhR8J/E0H wA8S+LNW0r4deINE+Kep/E7V7uLxp8OovDvxO0/xFFqk3ir99Y/A3gmHxnqHxGi8HeFoviFq3hjS /BGq+O4/D+kp4z1PwZomp6vrejeEdQ8ULaDW73wxpGs+INe1fS9Aub6TSrDU9b1e/tLSK71K8lm8 l+Cn7JX7Kn7Nd34o1D9nP9mX9nz4A3/jhLGPxre/BT4MfDj4V3fi+PS5b6fTI/FFz4F8N6DN4gTT ptT1KaxTVnu1tJdQvpLcRvdzmSJU19ReBw8FhKeHy/NsDlUKdbE1KOXYfGZrxljMFgaNOdaPJh8D g+IsowlDFUnTxuFWSc2FlHEPLsZlm7qRnjo4+vCOIqVcxynH5rDkjh/7Yq4bLeC8LmFWtWp89XCv E4rhzOq/1en7aliYcRzp4qao4Wvh8f8AzsftCfFP41fsuftFfsyfHSb9rz/hvn4leCf+CUn/AAUV /ai8GeHfG3gn4I+HdSGtReA/2bvEOna5oNj+zb4O+E7Xf7PfxK1bw0reBdM8QeGNc8aWp0DxfD/w urxWk8Nr4U9UsviL/wAFAPF37L/7TWsfF7Rv2p/G37N/xO/4JnftD+OPEHxQ/agX/gmBpGj6D8Wm +FlvqngVv2arX/gn98UvFPivVfhT8TfDPibxze6lpnxu0rxlq/h2z8J/D640r4o3V3qnia31v9zf hN+yB+yX8A71NS+BX7Lv7O3wW1GK813UY7/4TfBP4a/Dm9j1DxTZ6Tp/ia/S68H+GdGnS88RWGg6 HY67dLIJ9Xs9F0m21B7iHTrNIea8B/sHfsOfCvWPGXiL4YfsZ/so/DjxB8RvC/iLwR8Qtd8B/s7f CHwhrHjvwX4vnt7nxZ4Q8Zan4e8H6de+KPC/ii5tLW48RaBrc99pOtz21vLqVpcyQxsuGZYaOOwO cYCChClmOS57l2EjVjGph8DVzjEcXYqLeFpxoxrSoy4kwNNY+nVw9VVcio42WErQxUcuweuXYl4K tkdarKdeplOaYPGYuvBPD4jNKeExGQ1oTU41Zwy+08ox1aWX0adbD1oZ1WwNXFcmHrYrMuu/ZN/5 NY/Zo/7N/wDg1/6rrw5X0BWfpOk6VoGlaZoWhaZp+i6Joun2Wk6No2k2Vtp2laTpWnW0dnp+maZp 9nHDaWGn2FpDDa2VlawxW1rbRRwQRxxRqo0K9rNMXHMMzzHHwhKnDG4/GYuFOTTlCOJxFStGEmtH KKmotrRtNrQ8bK8JLAZbl2BnONSeCwOEwkqkU1GcsNh6dGU4p6qMnBySeqTs9QooorgO4KKKKACi iigAooooAKKKKACvkn9tT4UfF74yfBf/AIRD4MamIvEKeMPDWsa54YP7Qvxm/ZNHxB8JadJdDVPB x/aT/Z48OeLfjT8IQ15PpniU614C8Oane+IR4b/4QLWY7fwv4u128tvraisMTh6eKouhWu6cp0py Sdub2NWFaMZXTThKVNRqRatODlB6SZpSqypSco7yp1qT1lGSjXozoTlTqU5Qq0asYVJSo16M6deh VUK1CpTq04Tj+C/iX/gnD+2vZ/DP9lzSPhj+0p468H+PPhJ8Wfgf4l+INv4R/bf/AGjvh58OtR8A /CD4b+BvB9j4Oi8Lan8I/i/4N8f/AA1fUNI8Zz+M/gOnw1+DFp8apNZ8NeIfFfxm8KX3h6/0jXes /Zw/4JSeJf2btf8A2ho/hb8RfGHwh0r4+yR/ETxj4y8HftH/ABH+LWreP/ijqHjj4k6v428KeO/h F+1F8M/jP8NdI8I/ETQfEXhS48YfGP4dan4Y+Oc19b6z4e8PX3hm1RvE+vft5RWuNjHMFiFiVd4u liKGKnCU6dXE4fFZZluWYihXrQkq1ajiY5TgcXjKdSpKOPxlKU8wWKoVJ4dzhZywlSnUpPWliKeL pQlGHsKWLpZnmOaU8TSw0Yxw9GtRqZrj8NhZ0qUHgMJX5Mv+q1oU68PxE+Ff7Gf7VfwO+CPivWPE nj/4gQeIvg58J/iLqnwG+F3w6/bV/bM/aYtYfiBoXhXwHJ4Qg1/UfijY+A/EHxp0Xxhr3gXxDqaf DDx34Z8S6H8PIfiBc/DX4bwXOiW1vq7p8Rv2Ff25viF44jv7b4+nS/C7/Bj4C6fe+JNa/aX+P+pa 7c/Gf4eeM9N8a+PdS8FfBjTvA+k/DP4JaR49OoeN/DfiP4naJ4n8ffHuTRLvwbZ/Cnxr8ALXwbFa aj+3lFbVKtWticFjKtT2mJy/F4bH4arOnRm1i8Li80xsa1SEqTp1FUxOac1ShKDw6o4DLcHSo08F hnh6nNTw9Kjh8RhaKlTo4vC1MFiYwnOLqYaWDynL6UIzjJTpzo4XKmvrEJLE4ivj8bjcVWr414fE 0PzL8a/slftMeOPG+meMoP2h/Hvw1m8OeM7DX/B1t4B/aC+LM+n+GtH1nxb8M7bxtputeDPEfhy+ +FHxgew+F2mfEzTPBGnfGn4c+OvC1l411fQPEn9gaRfz3+raZ8wftP8A/BOb9uL4g+EfHem/CL9u X9oq18ReOZILHxf4hT9sr4gfs+eNfGmg+E9e+Et14Afwl4o+H/7O3xV+EP7Kni65tNK+K2pfEzxD +zt+y5pGmePl1XR/BGr+GbnRdcOveAf3TorCFOFOng6UU3HA06tOi6spYicvaxwUHUr1MQ6s69aN LAUaCq1ZSnUoSq0q7qwklHoTfta9WXvSxGLji6iSVGCnHDYnDRpUoYdUY0MPTeKqYrD0qCprCY1Q xeEdCtFyf4dP+wP+2F4ZTVbfwN49vr0a38abT4mavq/iX/goz+2d4e1vW9Z1b4TeDfD3/C0PEifD /wCFWi6JqV38JvH+jeJ7w/sxaBpPg/8AZ2/aj0zxFZeIfiTH8KLvw34e8HaVZ8Lf8E/P2u9R8C6b Y+Mfjf478C6zpGpPPofgvw3/AMFE/wBuf416HpWneIda+G2gfEqx8T/Fv4iad4G8dfF+18ZfDrSP irrfhfT/AIh+EbiD4K+N/iBpelfCufQh4S0Xx/Z/t5RSrUaddv2kVKm8LgsEqF2qCw2X5XQyjCU3 SvyVPZ4TDUnKdZValatToVa06jweBWFdKcqMKUYPWniq2MlOXvVK1fE5u86xUqsne8cRjXKLhBQh Rw1bG4bCrD0czzSON/ArR/8Aglb+1L8F/FX7HPh79mz9rf4u+E/gB8Avh9408F6x8Lrj9pHUvAnw 78E2vi/wRdeHLjw9YfB3wJ+zLO37VHh7RtZvJPEfwy8V/HD4zeAfjR8LvFMmreLdT+J/xUbUfDXh vwF2U37Gv7fnjTxV4v8AjB491r4faB8WfFXwk8bfC2y0n4ff8FBf20NP8EeDdHTwx8D9M0XSvDc+ gfBL4c29ve/F3VfBPxUvfEnxOtfAmmfEL9m/W/Hum/EH4bz/ABd8XaYVi/cOit5VJzr4nEzaqV8T /bF6lWEKzo/25Qx2Gx3sVWjUjFSo5ljoxU4zU6mJrYjEKviatWtPGNKEVh4rnUMNRyvDxhGpUpxq UcpxWW47CwmqU6bTeMyjLcROpSdKrGWFjSoToYerXo1fxLm/4J3ftUeJPCOiy67+0d8XPCPjLSfD 3iDSNF8PeEf+Cg/7dGr+GPC1hd+GfjPr3gnwzq3jh9T8G+JPjRf+APi9q/wFiufjJ8RvCdt8RviT 8O/APivS/G1tNoHibWfhr4m4n4L/APBO39t3wd4vTxb8Vvjj4o+LWoaJ+1J8W/ir4Hn8X/8ABQT9 qHXl8EeCfir8LdW8JXt14TstJ+BPgJLbwjofim08KX/gb9j34gXfxY8BeAdHuPE7wftEeJdVurtv EH71UVhiaUcVHEQm506eJhiIThRqVIODxeOwWYYmtRq8zr0sXWrYCip4yNVYt61lWWLjRxNLahJ0 Hh5xUJ1MPVVWM506b9pyYXE4SjRrUoxjQqYPD08VW+r4B0lgaMZyw8MOsHVrYar+M2n/ALC/7X3i bx94uT4mfHPxhYeAPE1v4M0vxN4n+HH7d/7aWh+LPH+gWN34Bubix8P/AA00i38G+FP2W9e+H+m+ GPEfhqLxv8CvH83iH9ol/Ft74w+Kr+EdS83Rpe8t/wBnb9sjQvEXwY8Haj+1Z8YfiDc+J/gz4+1D 4y+IPE9xYWngPwl8QPAXw+8K+Gfhr4W8AeI/g78Pfgxrdr4c1P4qeP8AxH481O/8fX2sfGH4l+HP Csuna54zvtM8L2GlaN+rtFaVf3tLEUpWSxNR1J1Ixhz05rC4jDU3h4TjPD0PY/WJ16LhQvQxblja DpY2csSTQ/cVaVWPv+xo0qEadX34Tp08TPFSjVbtUqRrVZRjVpyqez+r4fB4SnCnhMDg6FD8AvAv 7Cf7ePwq/ZX8MWvjr9p746eLviz8A9H+IviPwndQ/ttftH/tAeN/FVtrHxL0/wAVavoHj7xZo/wW /Z5i/ab165+Er+PPCPw6sfiB8Cmu/BfiPVvBejeCfsV94c0zx5a8T+zt+xz8dvjT+wh8J9K8V3/x t/aF/wCEM+IHiW58bfslf8FUPi58Q/H3wn/ajig8X67d6f4w+LnxS/aL/wCCcHw4/bC0geDU1jSb j4aeFvEv7MXhr4Tx6l8NtHlT4O+Kbi/0L9oO8/ozopSjGpRxNCtGNWnXeGqKTV6/1qhivrM8Tia8 +epjpVeWlGMMS5QpVaccalLHUcHiMJKio8jg5qXtca60nUm3Uw2Ny2OWzwlCUJU6mCjCHtKsK2Eq U66nXrxhUhCvWVT8uv2Jv2Sfi7+z/wDHX4r+NviL8Lf2WdI0vxJ8HfgV8MdI+M3wV8U69b/GT4tT fCPwL4b8P32vftF+EdR/Z98Hv4t8Z6n4hPiyXRfiDrHx6+IB8NfD3TPAHgTw74H0LU2+I3jbxx+o tFFdFfEVMR7N1Gm6cJQTScU+atVrzk4J+zhKdWtUnU9lCnGpUlOtUjKvVrVakxpqM61S95V50pzf LTj/AAcLh8HTX7uEHLloYWlFSqOc0oqKn7OMIQKKKKwNAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigD4I1zw9+2xcfFPxVovhnxLfaV8MrbwRoknhXXLjXvhNYabe+Mjq8 EuvW661rnwx+LvxCtW/su5Btpdb8BahpEradq+lW50z7foev6f6v8TPhh8Z/GHwu8V+GbD4lawPF +s+LtL1TSNR0Dxs/wgk0bw1pt3p7NomkeM/B/wAN/EOv6SmoRWc91qialovi65u5b6+0qLWLPTpr STTvqCvDfEvxC8b+GfG+s27+E9T1v4f6ZoEWprqWh+CfFmp6vJqscukHVdEtW0ebWbrWZ9O0W6uv ElnPpHhW4h8QT7/BOlk+KNIvBeQoxjCNNyek51fbVGnJOliXmSc6k/3dKNN0XQpO1PmoOODTqSqU 4StuU6ntIqz5Y01TpJpS58Msv0hD35ymqjrzau44hvFe77Pmh554i8H/ALVf2PVLTwv8TdMj1PWN G8QXdjcXEfhW28P+Dtb06zsdM8JaPpOoan8NfFfiW70zWbjVL7xF4gn8T6P431Hf4Uh0y117S111 nE+m/DD4+2N/4skh+IPhzS7fX7vUNQ0m80q20y41Hwzc65eWs2ry2EOv/D3V7W51Rmjvr/8AtO+k n0a8a40jR38HWUWgXWreJM7Vvi78XdF1qLxdZeBvEPiTwd4utfCun6B4IvfCHxD0K+8JyC21LUNV 1bULjw78JPHfi241/wARfa7K0Fj420v4e+DfCqaMtlruuaPq148t/Hp37T3ia3+Nvwj+BnjX4a6B 4W8TfEzQPGevXlxb/EXVNTTQ4fC0N/c2UGl2Gp/DTw1feIjrltZl4p7qPw3DbS2utwwNqJ0qNtQ1 hepVqUlF+2lRq4KalzQqKNJ1MwqpVZOLdd0aMKlSpGpKrKlSoQqS9s5RljU5adGnUlL9xTrxxsJw 5Z05SnCGGhejBOKoUnWnh6VOVGFNVJ1qlJSjNVpek+JvAfj/AFnw/wCCtJk8U6ldeJtJsNes5/H1 pNoOnappOu3emmwsPHCwQ6DaaFJq66S2r6V9msvBs+kfbvEMnm6Cuii5SPgb3wX+1jpHhXxd4W8I /EPwnq2qT2PjW78GfErx1rUVx4mt9c1rW7l/DVtr/hnS/g7/AMIwLDRNMm/tNr3THNhFqBj8M2fg 0aBZW14er/4Xfq1lZ3+qX3w7+JF7aaL5una4NP8Aht8Sklj1iHU9askXw/4bj8B6l4m8U2UzQaIr a/4cfWvDz2WqNqsM8dhpt/dGt8RviT8QvDPiXSb/AMP6TNq+nad4DtfEus/DSz0W51fxT4ri1jxB Z6Nq9zoD2MJ1i31f4eTSaDNLAlnNp2oaV4l1qHUNPOox6JfaRi/36Sj7Tlxbq0eal7jT+q42vGVN xtOkuShOrGth1GnSj9WxWLlTy9OvDZ/uG1LkbwioYlKbU1U5q+Cw6pTlNunUlKrjaOHqUcTJSUni OVRnCc1g2Xgz9rddE+yan8V/CdzqsfhW2ga+02DQ9Mur7xZbaVZSXE8d5efCHWtL0e01bW9a8S2h 1GTwrr8Oj6b4L+H2qReE9Uudf8b6K+9rfws+J3i74LS+Dtd8aXukfEWTVrDVIfFPhPxx4g8KzwMm p2kt+NQ8S/DTw58Kp9cmuNLfVorrZ4Q0TStX1Ca3vJNG01o7Y6f5ZL8bf2j9V8ReI/BMPwqfw/qP gLXNBsLnxxpnhj4pa14Z8aG78K+KZ7y6Gi+KPhl4V8ODw3ea7p+lajZx/Cr41fFS90zTbm18P+M/ FfgnxTeQaZe43wg/ab/aC+Lvhn45aZ/woXxR8PPFfwx0T4e2Xw9+JHxF+FXxb8IeD/jP4n8V6E03 iPxFo3wc8Y2HhPxxoXhnwjr8M0N74Xj+I3iPWl0+S3W+8S6fcOs0ujtiaeMnC3LSw0Jc1OPJJ4d1 qdenjMJGykqsquIoRpXjDFzpwpzoUZYelOqocvq1TCQnJ3liVUcp88oxxHJUwf1bFxSvGn7GNSrO EIfVUq0pTmq05QXV2Xwi/aU16DTNO8dfEqVLLSn03UbC/sPiB4Z1nWLHVtNk1NFlF1o/7Lnwuur2 +ube5hgm1qTUbayOlzS6W3hKTWbVvGeqdv4j8EftLSad4ln8O/FqN9X1W9sJdH0ySbwL4e07w/ZW dxNHNbaNrt18AvH1zbnUbSSG81ZvE3h3xxJcXFo+m6LP4aivf7VsvD/E/wC07+0np/h/SLa3+BFx 4Z8Ta5B8VJ73WdT+Gv7Q3xLg8HyeAfFniPTbGxt/Afwm+HGtaZ46l1HQNEtNQ0+71z42/BuD4gRa 1puqfCSPxzJdReHTteIP2svjbpWgeJNVsP2TvGNzceHJrCEtqo+Msdjqy3Wpt4aludL03wB+zr8U PiBqUf8AwlGgeOI4YtA8BeIHt/CEfwz+IWuSaL4S+Jh1HwoXXNdXksTWrV/d55U51JV1QnBON1Tn KeHjhaEVKFWtCkoYV1LSkDg+Z0nFwnhoyw8k+WHs6eHnOcIqpdRqwlOpWqQVOdVJymqig6tONT0X VvAn7Q2hXb3vg7xfYvpjf8LB1zWNJ0u88L2d1rOvapb6nd6C0Oj+KvhnrKajfXuoSafDBFH8TPhz onhq5he81VvGunTSaZDwXw68Mftpah8MPBd5418UwaJ8SptVe48eWM+tfCXw3qlxaw+baR+frPhv 4EfGHwlfWgS3il0/SdL0vTdVl067she+MtNvNNvNP1DmPH/7Tv7T3gnxJ4t1m2/Zc8Sa94M0rwjr 8/hzRdMuviB4gu9e8QeGo9Ru4bC5/wCEC+AvjTxLpPijxtdQyaT4bt7HT/FPw8h0fSYta1nxpo+u +JPD3hvVvr74U+KvEXiuLxvLr9tLbwaX40Sx8P8A2m3W1vRo+o+CvBniifT7+Jbeyb7X4a8ReIte 8ISGexs78L4eRNVhOqpezSuEHUpTpxdl9TwuNdpQU6OGwuPq5fQhTcLqn9bco82Hp6fU6GHnUhh6 jSrROcY1lK7lL61iaTklJU8RXxGDo4zE1J86iqn1eWIjGNSylUxk8RLDfWqOHxNXD5/wk8N/EjRI 5Lr4l6pY6t4kvPBfgLT/ABHqGlTW0mlaz420VfEcXiXxFZR2mj+G4lXUrG78OWLyf8Iz4fMg0dIo tOjtLe2J9noopzlzzlO0Y80pS5YJRjHmbdoxWkYq9opaJWQ4x5YxjeUuWKjzSd5SsrXk+snu31d2 FFFFSUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5Zc/Gf4dWVxfJf6/Dpen6PfeKtO 17X9dU+G/D2g3Xg2LTJdbbUtW8RnSbc2EY1W2jttZsftui3MyXMSagJLaVVvr8WvhrceHNS8W6T4 10DxPoOlWVhf3V34LvV8cTvb6tdTWGjiw0zwgNb1TVrnWr+3n0/RLHSrK9vdZ1CKSx0y3u7tTCOc h/Z6+Ddk+rTaT4HsvD11rtvJHrF/4W1HW/Cmp6jeTTtdS+ILrVPDep6XqEnjGS7KXb+ODc/8Jg13 BaXR1z7RZ2kkO5ZfCLwJYaHr3h+Gx1uSx8TxaeuvXd9408ban4g1K80pFj0vXJvFeo+IrvxSvirT oYNPgsfF8OsR+KbW30Xw5bwawkPhrQE02ff5J/D7T6vS9no+T61y/vlPW/1fm1pOP7xRVppt3VLl 5o35uT29Tntbm+q/8uuXp7dbVL/u3a8bXss5Pjn8L4Qja/4osvAsd1e6Rpulj4lMvw4vdZ1LW9Lg 1ez0yw0Txs2heIU1YWs6C40fUNJsdVhlDKbJk2yMy1/aF+AV9pGreILL44fB+80HQZtOt9d1u1+J fgu40jRZ9YkuItIg1bUodaez06bVJbS6j06O8mhe+ktrhLZZWhkC0j8HfhTqwl0RbnxLfX+gXFku sPB8XfiZL4ofz9KtorfTPGWtQeNj4l13TNU0iOxkutC8W3+o6Vrdtb2F1fWN79mtZY9W7+FnwrhW 9a+0m0t1gtLm/v2uNf1eBbexlGrm5vbkvqyC3tMajq5a5cxwxh5SHX7NF5Lk7Sq2sqfPejKT95Ul yuXtVbl5+VVNYyUVeMndRlGSirwp7urypVlFe57SUlCPs3fm5ZSlCCUlzOTSTbmktcfFDwPd+GNK 8Z+Htf03xn4Z1vU4dL0vWvBWo6b4m0y9f7bPaaldW2oaZeTWNzZ6BFZapf629tczT2tppGpRw29z fwx2UtXwd8Y/hT8QbC/1XwT8RPB/ijS9MvYNOvdS0bXtPvNPivbiwt9Tit1vY5zbTv8AZLhfM+zy yrBdQ3thO0d/p9/bW0kPg3wPf6YdA0WdIbSw1u38Q3UGk6sLy4S71K3aeWO6luZdQntrTX9JvZ4J Vja2ll0u/kk02e1Z4blMC/8Agz8J/EOvXt/NZ38msWsa2mtWek+PvGul2swuvC9p4dsk8R+H9F8T 2el6jNb+HLe3GhPrenXM+lPJNrOivZ6le3N/O5XXt0lrzxVBTbjKCVKi6iq2jJTiq3tadNxVOprK pUioxhSnMWpKm7rWlUlNx9+MqjxLVBU3eNoPB2nVk+e1dKFNShN1KfQ6b8XvhNrNjb6po/xQ+Heq 6bdpcy2uo6b418NX1jcx2d3pFhdyW93a6nLbzJa32v6DZ3LxyMsF3rekW8pWbUrNJqi/GX4a3Hg3 XfiHpHivTvFfgrw7C1zqHiDwA7fEm3NtEQt1cWll8PV8T6tdpYuJlvlh09pbSO1vLuaNbG1muk4b wf8As1fs+eF7PT9D8I+DrGGz8EqNDt9Nj8U+J9WXR2ltPEGonTtShv8AxDfvLcz2XxC1DUZY9X8+ 5uIb3w5fS+Yvh/wlNpXo2h/C3wb4f8Pa74Ys7fXr/S/E1pcWOvyeJfGnjXxjrOq2l1Zy6dLDd+Jf FviHW/EjhbCZ7O3Yasr2lssMNo0MdvAsbny2q+zb1lfDSnFWlRk5SpzqqMn70qbpO1OTjdylGTi4 odO3NQ9qvc519adN+8oWXPGgpK3PGXMlKo0pK14Rd0cEv7UvwCuPDq+JNM+KHhHV42inm/sKz1vT bfxjEthJYrrUN54N1W603xNp1/4ch1C3vPEmk6lplpq2h2xJ1CxgmKQv2LfGv4PRmRbj4p/D2xmg 8MR+NLq01Lxj4f0y/sfCMvlBfEuo6fqGoW19puiB5oopdSvre3tIZpFgmljm+Sue0/4H/CjTtX8i 1fxU9/DAl9/YF58XvilqWnRaWb4SadB/wiWo+OLvRk8N6TqFrIfDGk/2SNB8NXJvl8OWemvdXom0 9R+HvwnkvT4VvFt7HW/EtlqGpWmmWnjLXNF8UXdrpSaZZX2taBJp2vWXiCzk0R7jR/8AieaDLbXO h38+m3cN5Z38ttM0yu4x9nb2kqc7RlrF1YRxN+WUbSnTjy0pTagpRjRxMWvfjOiqfNe1ayUZU+d0 73UJrDSfuytyyfNWVO8mpKrhqmnLOFWeH43/AAokmt0n8feD9Ps9U1DQdL8L6xqPirw3aaN42vvE ul2ur6PbeC9QfVjF4kmvLS8g8iHTxJNcSOPssc8bJKzP+F8fBT7Dq2sH4ufDAaDoV3FpmteIT8Q/ Bf8AYmk6xLcfZV0XU78a6U0/VfOMSfZL1YHd54oozJMWiRrfA/4bmLSYl0zXYjpF1p13FPb+OvHl veam+m21paJB4ovoPE0d54y0/UEsLObxDpXi6fW9L8U3tvHqPiWz1bUAbk+Y/D/9lL4U/DnSNb8K w+IPH+s3XizxTrXjddTv/Ht94U8X2N5e30d/qsXhnWPhiPh/qel6VHf6hcSXYsT9peLXb3TNQvbj Sr9NPFKzrSTuqCdSSlvVcOfCxpU+Ve77VwljZ1JOUaceTDqPM5VIs19jrZ1mqCaWkFK9eWImm7tU 7Rw9OnFxlN+0rN8vLCcfctA+IvgzxXf2ln4X8QaV4kg1DTdW1PTtY8P6np2t6Hfx+HtXttC8RWtt qmlXd3bm/wBB1O+0611S1kMbQS38MSGWaG9jtO2rzrwf8K/B/gS5juPDdvqsJi/4SqRRquv634lu Gu/G2u2PiPxTfTat4mv9X124udX1bTbG5mSfVJLSE26raWtuHkL+i0l/Do3/AIrhJ10vgVT2tSyp vdwVL2VpStKT5pOMG+SIubmqXty8/wC75b2dNRiot31U5ayqRd4xqOcacp0ownIooooGFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRXG/ESx8Ual4G8V2ngnWdS0DxfJoeoSeGdU0mLw3Nfw65 bwPcabDHH4u0rWvDhivruKKwujqmnSwpaXM7pNZzrFeW6k+WLkouVk3yxtzO3RXaV+12i4Q55whz QhzzjDnqPlhDmaXNOVnywje8nZ2Sbsb2uab/AGzousaP5xtv7V0vUNN+0CMym3+3Wk1r5wiEkRkM Xm7/ACxLEX27RImdw/P2L9gvWtE1tf8AhCv2iPip4f8ABl/cNN4g0S++Jn7Ueq+LJxL4K8J+D7uT RvHVh+1P4fIv72Pw5cPDqHjzw78R5fCWm3el6d8M08BX2hLreoeoa1q/7YGg+IPBvhTwX4R8M+J/ DEtt4th8X/E/x5Poeoaxb3sVwIfB2qzeHvD/AI+8AwXL3qLJqWvaX4f0LS9MdJYrDSovDARkjd4y 8Uftp6RdeEY/B/w/+GPi62u9Y0HTvGE0lomif2dpUWmXEnibxNp/9ofGZJBHfapLZW+iaAlvrF7p FvZXzX2oa79ttZrRJRpP28UpPF06WGnaLk5UpVcVh1CvRmr06UJVqs5uvTppUcRSxMlyQlOhClKu vYy5oxoLEzgptU+VVvqdSo6dVNJ1qsMHQS9lUnKDo1cPTqfv3DE7Xw//AGa9V8CeMvEfiST4seKv Fel+IPhzb+ARoHiqfxJrsunz6faaVp1j4rk17WPGmpaj4m8SXem6f9g8Ra143XxP4gv7e00gaHrv hdpPGreOuc8Efsl3ng34Y2XwstPiTPpPhmyjnji0nwFpvjLwVoyJNfaxqUyLE/xR8QeJbtNQ1DU4 7vXk1vxbrK62sE+k3W3w1Pa6Fp3ceLZv2gB8KrNFTWLv4mjxbpkV9e/BbSfhhoUj+GPtwmv7uHQv jl4w8XeG0gTSjLZT2p8VPrF3qqWl1YzaZYzXUdvgaXJ+1H4X0fwnpsdlp3iyW68VWia5faxpOh6r qWj+GL5oWms9QvH+MPg/ZDpKi6W+8X6fH481xZmt/wCzvh1r9vKy6fTppymm7+1qQoVJOcpKbnXj jlVlduTjCvm2JqyxDjenKGNo86dJUmlUajBxi1yRq1oRjTUZU3QpQwlo2SUZzpZZhadGnFp1ISoV YLkq1agzSv2YNS0bTNc+xfFTX28Watocnh//AIS6STxpZ31xYRCFrFtZGgfEfQtQe6kmt45dXvPC WseCrnZJLY+EJfBWmW2i2Oj9Z4d+Cfivw/qvgnUx8Try+Og6npuo+Ko7qHx68vjBNP8ABMnhMWFx eS/FWe5vLQXco1q1b4gt8S7uGW005bu61HVre51692H1v4la/wCC/GsfiLwfr3gq9sp7LSLSTSbr SbrW9b0xZbWPxP4i8IHwh4o8W39tDdWcl83hNb5dF8WwTJFJd6NZ3awk8jY6r+074d8Q3J1vRNJ+ Inh3WhpNpo0fhrRvCvhe58FS3PiPxALu98Vz678VIpPEttpvhxdJbWtU8N2tvcXc0ulJ4f8AA5uI /EDvTnKdTnbSlWnRr81oxh7WNZ16SlBJRpP2uKrVakZxhSi3WWJ5WlByoQp0nGMfcowq0eRXc3Sq Qhh63K2+aqlToUoRcZTqOnGMsOpK7LHiL9nDRvF/iibxjq19c6T4m0qfxdbeDfEvhvWfFOja/pOl +Or7S7vxRO9/4f1rw1NDqmoaZbXHhW2mjlurrSNLt9O1DStUtrxXtoub8Dfs+/GfwfDrVlqH7TOv +L7DxD4m8Ua7fSeINA8W3et6TYapbTr4c8P+D9XuPi1dJ4e0/wAP3dzLNeifT9Yj1i2hsbWytvD0 1q17PB4W8aftnX41JvFHwk+H2h+b428QWOjRRajYXT2ngaK8stL8N6zq72nxOv0vNTuBr0XijUYb AWsjaL4C8WaMml2Ou+KPCRj9K+Hd58bdfuvGdp8StLTwfCYr/TfDeu6Fpnh/TbmDM80Vpf6RZN8U /jHpWsLawyi9sPEHiTw54RvdUkSOLWvAGmW8AsJ8qcYyo4Xli1TjgKlKlTm+RxpQdHGyoVqVRxVP EVK9Tnh7WMF7f6zSoTjHnpy1qSaqYyUmpTq42lVrTjHmjUr1an1SVajKEZS9jTpU4yq+wi4SpRoV ZxlH99DBs/2cksb7TNTh+InjOfU9D0i/0bRNZ1XxD4z8QeIbC31WfU59QabX/EPjTVdU1V2bUmWx /ti4vjpMcSwac1vblYY+af8AZk8RP4YsLc/FCVvH1jZS6UPHTr8YDeyaLP4kk16bw+Nfj+PsXxpX w+5NtI2lP8b5oX1izt7qZpfD8cfhSPjPD13+2lY6U/hbxJYXniVrgyWtx4xu/Cfwntdajg1TS72X /RfEHhP9oLwJaL/Zt5Lb2j+ILf4Q6ZqHh24tre3sfCvxIhubjxXZet6Wf2m9Lh0KwkfwTrlvpWlX set6hrGgsmr+J9SlS+XSWs73TviRa2nh6LTJEsG1NrrRPEc2s27ukNxp955t5V05tSjOKalT9jVp Nxs+avSqV5r30lGdOVaVKtGX/L+tWTvFVJuakbc6fvKcqlOq4y5rrDToxpSXI3KUaigpUpxSfs6F Na+7CNTxZ+zi/ifR/hZYTeLre91f4ceLNR8WN4v8YaV4p8c+J57vWPtEerReG73W/iKLbw9Hf2N7 e6UttrVp400nR9PktG8NaToep6PoupafveGfgB4Y8H+N08aaBpnhjT9UvvFUPifxBqul+HNP0PWt W+y/DS88CDTtQvbKCW41mK91fUtS8XXEt7eQ+Rqd3MRDeXM099L582sftXr4bPimPwnZN4zl0qz0 9vDr6D4YNqnl+Jta827XwD/w0ynhqDWX0ptLa4uk+O91B/ZDm/je41eH/hCoub8O/FX9qnxJ41+N +i/8Ky0+xsPh7cLp/wAPtSuPAXi/R7PxUbmzhkuLvTrzxj8SvBPhf4ilL611GxsU0/U/CemBrawu LvxPolh4gjv4CD9nDEcmknCpiqtOOs5xoOhgoqlezfPSnh0qMHFOEbzhalzkzScsPGSbhSnTwtGp K/s4fWuXFS9rLWKUa8aj9pVcpKrGfs5e1r+zn9z0V8z/AA91r4+6zrejy/Ejw0PDcNp4smtUNnpW laLBrPgq6+Gkt7fXWs6NoPxY+M2k6fqlh8S0sdP06STxVFdNpsci2MdxbXGo3N19MVUo8rSvGV4w neLulzwjPleialHm5ZxavGalF6oIy5k3aUfelG0lZ+7Jxvb+WVuaL6xafUKKKKkoKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKrXt3Dp9nd39wtw0FlbT3c62lpd6hdNDbRPNKttYWEFzfXtwURhDaWVtcXdzJtht oJZnSNrNVryztNRtLrT9Qtba+sL62ns72yvIIrm0vLS5iaC5tbq2nV4bi2uIXeGeCZHilido5FZG IMVPaezqexcFV5J+ydRSdNVOV8jqKLjJwUrc6jJScbpNOzKhyc8Pac3s+aPPyW5+S65uTm93m5b8 t9L2voRaZqNnrGm6fq+nytNYapY2mo2Mzwz2zy2d9BHc20r291FDc27SQyo7Q3EMU8RJjmijkVkF 6qGlaVpmh6Zp2iaJp1ho+jaPYWelaRpGlWdvp+maXpmn28dpYadp1haRw2tjYWNrDFbWdnbRRW9t bxRwwxpGiqL9bVPZ+0qeyU1S55eyVRxdRU+Z8iqOKUXNRtzOKUXK7SSsjOHPyQ9py+05Y8/Jfk57 Lm5Ob3uXmvy31ta+p//Z////xgDPHt7/////////+gHoHt3/////////QwDSAPH/////////xgDB AOf/////////QQD/AMP/////////xgBPAd7//////////AG0Huf/////////+gFoAd3///////// /AEHAef/////////AAHWHuT/////////AgHWHuT/////////wQBZAFn/////////wAAYIFv///// ////+gGAHrD//////////AHhHt7/////////xgAbAd7/////////xAAYIFv/////////+gE0ARwA AAD/////DAHWHvH/////////QQAbAsH///9bBwAAQgAbAuz//////////AGtHuX/////////QQDS HuT///+ZBwAA/AEAAef///9KBwAA+gHaHuT/////////xgB1Adj/////////QQBSAeT///+uBwAA /AEB+8n//////////AGmHuf/////////AAEsABkAAAD/////AgEsABkAAAD//////AFaAez///// ////BAEsABkAAAD/////wQBuAd3/////////BgEsAPn/////////CAEsAPn/////////QQAeAef/ ////////xgANAef/////////AAFZAFn/////////AgFZAFn/////////AAEYIFv/////////BAFZ AFn/////////AgEYIFv/////////wQDZAN3/////////BAH1HsP/////////xADZAN3///////// /AFTAd7/////////xgCzHuX/////////+gHMHuT/////////QQBVAN3/////////wADSAOT///// ////+gH5HsP///9NBwAA/AH5Hsv/////////xgBxAOL/////////+gFMAeT///9SBwAA/AFMAd3/ /////////AHrAN7/////////xgBgAez//////////AHFHt7//////////AF5Afb/////////BAHZ AN3/////////wAAbAsH/////////xgAA+8n/////////wQAbAsH//////////AHkAOX///////// wgAbAsH/////////xgAbAuL/////////QQBHAOf/////////AAEGAej/////////QwBHAPH///// ////AgEGAej/////////+gFyAd3/////////BAEGAej/////////QQCCHrD/////////QQDVAOT/ ////////QQB0AMH/////////QgB0AOz/////////QwDVAPH/////////BgHSAPH/////////AAH/ AMP/////////AgH/AMP/////////BAH/AMP////DBwAA+gEKAej//////////AEKAeL///////// +gHkHt3///+tBwAA/AGDHtj/////////wQD4Hln/////////AAEbAsH/////////AgEbAsH///// ////xgDqAN7/////////BAEbAsH///+/BwAA+gFkAWD///+4BwAA/AEDAeX////kBwAA/AFBAOf/ //8LCAAAAAHSHuT/////////AgHSHuT/////////wQBVAN3/////////QQDHAOj///+eBwAAwgBV AN3/////////wwBVAN3/////////xABVAN3//////////AHdHt7/////////xgAXAd7///////// xQBVAN3/////////CAHSHvH/////////DAHSHvH//////////AEE+8n/////////AAFSAeT///// /////AGpHuX///9aBwAAAgFSAeT/////////BAFSAeT/////////QQDOHuT/////////BgFSAfH/ ////////xgC9Ht7/////////+gHWHuT/////////wQDcAN3/////////QQBOAeT/////////xQDc AN3//////////AGiHuf//////////AEYAuz//////////AH1AN7/////////wQBqAd3///////// xABqAd3/////////wQBHAOf////JBwAAxQBqAd3////GBwAAxgAJAef/////////AgF4AVn///+q BwAAAAFVAN3/////////wACCHrD/////////BAF4AVn/////////wQCCHrD////VBwAA+gEiAef/ ////////AgFVAN3/////////wgCCHrD///8fCAAAQQD0Hln/////////wwCCHrD//////////AEi AeL/////////BAFVAN3////pBwAAxACCHrD///8hCAAA/AHBAOf///+oBwAAxQCCHrD///////// wQDVAOT/////////wQB0AMH/////////xADVAOT/////////xAB0AMH/////////xgDVAN3///// ////xQB0AMH/////////xgB0AOL///+9BwAAxgCvHuX///9PBwAAxgACAef/////////QwBRAPH/ /////////AEbAd7///8ICAAA+gEYIFv/////////+gH1HsP/////////BAHcAN3/////////xgAD +8n/////////xgCoHuf///81CAAAQQAMAej/////////QQBKABwAAAD/////QwBKAA8AAAAPCAAA /AF1Adj/////////BAFHAOf/////////BgFHAPH/////////AAGCHrD///9DCAAACAFHAPH///// ////AgGCHrD///9FCAAA+gHuHt3/////////BAGCHrD///8oCAAAxgBmAMn///8ECAAABAHVAOT/ ////////BAF0AMH//////////AHgAOX/////////BgHVAPH/////////xgChHuX/////////QQBD AOj/////////+gFuAd3/////////wgDOHuT/////////xADOHuT//////////AENAef///8mCAAA AAHcHuT/////////xgDOHt3///+MBwAAAgHcHuT/////////CAHcHvH/////////+gHZAN3///// BwAAwwCvAd3/////////xgBOAd3///+YBwAA+gEGAej/////////QQDYHuT//////////AEGAeL/ //9vBwAAxgDHHt7/////////+gHgHuT///8CCAAA/AHgHt3/////////wAD0Hln/////////wQD0 Hln/////////AgHHAOj/////////wgD0Hln/////////BAHHAOj//////////AHSAN3///+KBwAA /AFxAOL////WBwAAQQAaAmD/////////xgDmAOX///+lBwAA+gH/AMP//////////AFgAez///// ////AAHOHuT/////////wQB0AbD/////////AgHOHuT/////////wQBRAOT/////////wgBRAOT/ ////////wAAQIOf///9uCAAAwwBRAOT/////////xABRAOT/////////xgATAd7/////////wgAQ IOf///9wCAAAxQBRAOT/////////CAHOHvH/////////xgBRAN3/////////xAAQIOf///////// xQAQIOf/////////xgAQINj/////////AAGvAd3/////////xgChAd7///+pBwAAAAFOAeT///// ////QQAuAA8AAACHBwAAAgGvAd3//////////AGlHuX///+WBwAAAgFOAeT///8uCAAA+gEbAsH/ ////////BgFOAfH//////////AH4AN7/////////xgC5Ht7///9sBwAAwAAMAej/////////wQAM Aej///+zBwAAwgAMAej/////////wQBKABwAAAD/////wwAMAej/////////wgBKABwAAAD///// +gHSHuT/////////wwBKABwAAAD/////xQAMAej/////////xABKABwAAAD/////xQBKABwAAAD/ ////wgDmHt3/////////QQD3HsP///+XCAAAwwDmHt3/////////xADmHt3//////////AHEAOf/ //95BwAAAAH0Hln///9gBwAA/AFjAOf/////////xgCFHtj/////////AgH0Hln///+ABwAAxgD7 AeX///8JCAAAxgB3ANj/////////+gFSAeT///++BwAA/AFSAd3/////////xgCyHuf///////// QQB3AcP///9xCAAAwQBDAOj///8gCAAAwgBDAOj/////////wwBDAOj/////////AAF0AbD///// ////QQBUAGD///9eCAAAxABDAOj/////////QwBUAAoAAABjCAAAAgF0AbD/////////xgBDAOL/ ////////AAFRAOT/////////BAF0AbD/////////+gEeAef////wBwAAAgFRAOT////4BwAAAAEQ IOf///88CAAAQQDwHt3///+vBwAABAFRAOT////6BwAA/AEeAeL////9BwAAxgDfHt7///////// BgFRAPH////8BwAA+gH4Hln///+0BwAADAFRAPH/////////xgCrHuX///99BwAAQQBwAd3///// ////AAEMAej/////////AgEMAej/////////+gF4AVn///+5BwAAAgFKABwAAAADCAAAwgDYHuT/ ////////BAFKABwAAABcCAAA/AEXAd7///9yCAAAxADYHuT/////////BgFKAA8AAAAFCAAAxgDY Ht3/////////AgHmHt3/////////QQDbAN3///8aCAAAwAAaAmD/////////wQAaAmD///////// /AHjAOX/////////wgAaAmD///9rCAAAxgCkHuf///++CAAAwwAaAmD///8ACAAAxAAaAmD///// /////AG9Ht7///+yBwAAQQDiHuT/////////QwDiHvH/////////+gHqHt3/////////QwDUAPH/ ////////xgDDAOf//////////AH/Ad7/////////+gHcAN3///+TBwAAwQAuAA8AAAD/////QQA/ AKz/////////xgBRAd7/////////xAAuAA8AAAD/////+gFqAd3/////////+gFHAOf///9zBwAA /AEJAef///+gCAAAAAHYHuT///93CAAA/AFHAOL///90BwAAAgHYHuT/////////+gGCHrD///+6 CAAA/AHjHt7/////////wAD3HsP/////////CAHYHvH///9kBwAAwQD3HsP/////////wgD3HsP/ ////////QgAC++z/////////DAHYHvH///9oBwAA/AF0AOL/////////AAEaAmD////2CAAAAgEa AmD///8sCAAAxgDpAN7/////////QQDUHuT/////////CAEaAgoAAAD//////AECAef////OBwAA QwDUHvH/////////xgDDHt7/////////DAEaAgoAAAD/////xAB3AcP/////////+gHcHuT////j BwAAxgB3Acv////sBwAAxABUAGD/////////QwDGABQAAAD//////AHcHt3///9IBwAAxQBUAGD/ ////////wADwHt3/////////wgDwHt3///+XBwAAxADwHt3///+aBwAA/AED+8n///+nCAAA/AGo Huf/////////AAEuAA8AAACfCAAAAgEuAA8AAACjCAAA/AFcAez/////////BAEuAA8AAAD///// wABwAd3/////////wQBwAd3///9qCAAAwgBwAd3/////////wwBwAd3/////////QQAgAef///// ////xABwAd3/////////xQBwAd3//////////AHHAOL/////////AAH3HsP///+UBwAA/AFmAMn/ //+sBwAAwQDbAN3/////////BAH3HsP/////////xADbAN3///+3CAAA/AH0AN7/////////xgC1 HuX///+QCAAAxAAIAej/////////+gHOHuT/////////QQBXALD/////////wADiHuT///////// BAF3AcP///+8BwAAwgDiHuT///93BwAAAgFUAGD/////////QQDzHsP////2BwAAxADiHuT///9t BwAABAFUAGD///8SCAAAxQDiHuT//////////AHAAOf///+QBwAABgFUAAoAAAATCAAAxgCBHtj/ ////////CAFUAAoAAAD/////AgHwHt3////BBwAABAHwHt3/////////DAFUAAoAAAAcCAAAxgDU AN3/////////+gGvAd3/////////+gFOAeT///8tCQAA/AFOAd3///8vCQAAxgCuHuf///////// wQA/AKz///+UCAAAwgA/AKz/////////AAFwAd3/////////wwA/AKz//////////AHHHt7///// ////AgFwAd3/////////BAFwAd3////LBwAAxgDbHt7/////////QQCgAeT///+bBwAA+gH0Hln/ //8GCQAAQwCgAfH/////////BAHbAN3/////////xgCnHuX///8lCQAAQQBsAd3///+jBwAAAgEI Aej/////////wADUHuT/////////+gF0AbD/////////wQDUHuT/////////+gFRAOT///+RBwAA /AETAd7///8DCQAAxADUHuT////FBwAAQQCEHrD////KCAAA/AFRAN3///+ECAAABAHiHuT///// ////QQB2AM7/////////CAHiHvH/////////BAHUAOT//////////AGhAd7///+LBwAABgHUAPH/ //+ZCAAAxgCgHuf///8+CQAACAHUAPH/////////QQBlAcH///8gCQAAxgDzAN7/////////+gEM Aej///94CAAA/AEMAeL/////////+gFKABwAAAD/////DAGgAfH/////////DAHaHvH///9ACAAA DAHcHvH///8YCQAADAHeHvH/////////DAHgHvH/////////DAHiHvH/////////CgE0AQ8AAAD/ ////CgFMAfH/////////CgFQAfH/////////CgFSAfH/////////CgFUAAoAAAD/////CgFkAQoA AACeCAAACgEaAgoAAAD/////CgHOHvH/////////CgHQHvH/////////CgHSHvH////zBwAACgHU HvH/////////CgHWHvH/////////CgHYHvH///9mBwAACgHaHvH///87CAAACgHcHvH///8VCQAA CgHeHvH/////////CgHgHvH/////////CgHiHvH/////////xwBKAA8AAAD/////xwBRAPH///// ////xwBUAAoAAAD/////xwAaAgoAAAD/////xwAYIA8AAAA4CAAAxwAZID4AAAAJCQAAxwAcIA8A AADbBwAAxwAdID4AAAB0CAAAxwCgAfH/////////xwDcHvH/////////xwDeHvH/////////xwDg HvH/////////xwDiHvH/////////RADBAND/////////RADCAND/////////RADDAND///////// RADEAND/////////RAD6AdD/////////RADGANj/////////RABKAOj/////////RAA0Aej///// ////RAAaAuP/////////RABWAOL/////////RACAHuz/////////RADyHsn/////////RADdAMn/ //+ACQAARAB9Aef/////////RAAsANP/////////RAAuANP/////////RAAYIPP/////////RAAc IPP////1BwAARAAdIAoAAABQCQAARACwHtD/////////RAC0HtD/////////RAC2HtD///////// RAD4Hsn/////////RAD2Hsn/////////DgHAAND///8MCQAADgHBAND///8eCAAADgHCAND///// ////DgHDAND/////////DgHEAND/////////DgHFAND/////////DgH6AdD/////////DgHGANj/ ////////DgFUAOP///9rCQAADgEaAuP/////////DgFWAOL///9sCQAADgF0Aez/////////DgFY AM3///9tCQAADgF2Acn/////////DgF4Acn/////////DgFaAOf///9uCQAADgF5Aef///////// DgF9Aef/////////DgF7Aef/////////DgEcIPP/////////DgEdIAoAAAD/////DgGgHtD///// ////DgGoHtD/////////DgGqHtD/////////DgGsHtD/////////DgGuHtD/////////DgGyHtD/ ////////DgG0HtD/////////DgG2HtD/////////EAHAAND///+PCQAAEAHBAND///+mCQAAEAHC AND///+QCQAAEAHDAND///+nCQAAEAHEAND///+pCQAAEAHFAND/////////EAH6AdD////IBwAA EAHGANj///+rCQAAEAFUAOP///8dCAAAEAEaAuP/////////EAFWAOL///9fBwAAEAFXAOz///// ////EAFYAM3///8wCAAAEAHdAMn/////////EAFaAOf////3CAAAEAF5Aef/////////EAF9Aef/ ////////EAF7Aef/////////EAEZIAoAAABxBwAAEAEcIPP/////////EAEdIAoAAADrCAAAEAGo HtD/////////EAGqHtD/////////EAGsHtD/////////EAGuHtD/////////EAGyHtD////mBwAA EAG0HtD/////////EAG2HtD/////////EAH0Hsn/////////EAH4Hsn/////////0ADCAND///// ////0ADDAND/////////0ADEAND/////////0AACAdD/////////0ADFAND///91CQAA0AD6AdD/ ////////0AAEAdD/////////0ADGANj/////////0ABKAOj/////////0ABWAOL/////////0ACC Huz/////////0AB0Aez/////////0ACEHuz/////////0ABYAM3/////////0ADdAMn///+aCQAA 0ABaAOf/////////0AB5Aef/////////0AB9Aef/////////0AB7Aef/////////0AAsANP///// ////0AAZIAoAAACVCQAA0AAdIAoAAABjBwAA0ACgHtD/////////0ACkHtD///+kCQAA0ACmHtD/ //+3CQAA0ACoHtD///+5CQAA0ACqHtD///+7CQAA0ACyHtD/////////0AC0HtD/////////0AC2 HtD/////////0AD0Hsn/////////0AD4Hsn/////////RQDBAOf/////////RQAAAef///////// RQACAef/////////RQDFAOf////eBwAARQD6Aef////9CAAARQAMAeL/////////RQAKAeL///// ////RQDHAOL/////////RQBHAOL/////////RQBTAOz/////////RQBaAez/////////RQAYAuz/ //91CAAARQBaAPb///9vCAAARQB7Afb/////////RQBhAOX/////////RQDgAOX/////////RQDh AOX/////////RQDjAOX/////////RQDkAOX/////////RQABAeX/////////RQADAeX///////// RQDlAOX////kCAAARQD7AeX/////////RQDmAOX/////////RQBjAOf/////////RQAHAef///// ////RQAJAef/////////RQANAef///9BCAAARQALAef/////CAAARQDnAOf/////////RQBkAOL/ ///fCAAARQDpAN7///9mCQAARQAbAd7/////////RQDrAN7///9CCQAARQATAd7///8cCQAARQAV Ad7///+PBwAARQAXAd7/////////RQAZAd7////gCAAARQBmAMn////mCAAARQAA+8n///////// RQAB+8n/////////RQAD+8n/////////RQDzAN7/////////RQD1AN7/////////RQB0AOL///8q CAAARQBlAeL/////////RQAbAuL////0CAAARQB2AMv///86CAAARQB3ANj///84CQAARQB5AMv/ //+mCAAARQD/AMv/////////RQCmHuf/////////RQCoHuf/////////RQCsHuf/////////RQCu Huf///+KCAAARQCwHuf///+cBwAARQCyHuf///8yCQAARQC0Huf///9dBwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABQSwMEFAAGAAgAAAAhAFibkMKqAAAAHwEAABEAAABwcHQvcHJlc1Byb3BzLnhtbIyPOw7CMAxA dyTuEGWnKQwIVf0siJkBDhClbhspcSI7/G5PxEeCraNlvefnurt7J65AbAM2cl2UUgCa0FscG3k+ HVY7KThp7LULCI18AMuuXS7qWEUCBkw6ZfRIIouQK93IKaVYKcVmAq+5CBEw74ZAXqc80qh60rd8 wDu1Kcut8tqi/PA0hw/DYA3sg7n4HPCWELhXCU828tcW59h+//hLUu0TAAD//wMAUEsDBBQABgAI AAAAIQC0dMhPhAEAAEcDAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyMUrluwjAY3iv1HSzvkEMlhYjA UnViqATtbjlOsOTYlm1C4On7OyEkHAOb/+u7kuW6qQSqmbFcyQxH0xAjJqnKuSwz/Lv7nswxso7I nAglWYZPzOL16v1tqdOas+OPQQAgbUoyvHdOp0Fg6Z5VxE6VZhJmhTIVcVCaMsgNOQJwJYI4DJOg Ilziy7155V4VBafsS9FDxaTrQAwTxIF4u+fa9mj6FTRtmAWY9vpG0grMSS9b/LUWfQ27ThmWb1jh kD1DVLMkDnEwnu2UbkeLjyRpR8EjjhU8ZwMs3Yp8VHVPVBOzpURA3BH2BNYXqyVJbYPgKyUxRjnM wpYEuqfHLlBfrnSqDC+5RE2GJ4togdEJHrPIa4ctOtCXB9C2sc5Ttm8El5AQhKnMGSOtbIbjqPPW r3TN+bw3PIB48JE9r+jWvFSO2R1r3CBhpObOtHf7xPVd25N0YY1twyV47hVeOWD5iYTS8HyrCYUf FVHI7HMexmAPMCiAXKsuvbr7Qf4BAAD//wMAUEsDBBQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAA cHB0L3RhYmxlU3R5bGVzLnhtbAzMSQ6CMBhA4b2Jd2j+fS1DUSQUwiArd+oBKpQh6UBooxLj3WX5 8pIvzT9KopdY7GQ0A//gARK6Nd2kBwaPe4NjQNZx3XFptGCwCgt5tt+lPHFPeXOrFFfr0KZom3AG o3NzQohtR6G4PZhZ6O31ZlHcbbkMpFv4e9OVJIHnHYnikwbUiZ7BN6qCIKK0wKfL5YhpSANcejTG cVTW1bmp/SosfkCyPwAAAP//AwBQSwMEFAAGAAgAAAAhAHGE71SMAQAAyAIAABEACAFkb2NQcm9w cy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSQU8bMRCF75X6 Hyyf2sPG9iYlwdosoqngUlClpgJxs+whWHjtlT2wpL8e74ZsF7VSj/a8+fzmjauzl8aRZ4jJBr+m YsYpAa+DsX63pr+2F8WKkoTKG+WChzXdQ6Jn9ccPlW6lDhF+xNBCRAuJZJJPUrdr+oDYSsaSfoBG pVlW+Fy8D7FRmI9xx1qlH9UOWMn5CWsAlVGoWA8s2pFI35BGj8j2KboBYDQDBw14TEzMBPujRYhN +mfDUJkoG4v7Ns/0ZnfKNvpQHNUvyY7Crutm3Xywkf0Ldnv1/ecwamF9n5UGWldGS7TooL4ED1E5 +xsMuQbsQnwkm+AxBkfOnzDkTHL25NPl9eb8M2mCAVexsbvn6AgKQ6wt58svp+VyMdSPt/0mnEp4 lZd2b8F83U+Ffxd7fYRn22+8XqwqNj3n54aUDm9mx3lueUjpWLmZb75tL2hdcrEqeFmI+ZYLKZZy sbjrjb3r73M4XOTBBnv/JS4LUW7FiSyF5PMJ8QioB8fv/179CgAA//8DAFBLAwQUAAYACAAAACEA SGOaqAgDAAD8BgAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACsVW1v2jAQ/j5p/+GUT5tUCHSs6yqTCtEXJrUFiZRqH018IV6NHdkGyn79Lgmk 0NJKm5ZPd77Lc+fnXszOn+YKlmidNLobtJutAFAnRkg96wb38VXjNADnuRZcGY3dYI0uOI8+fmAj a3K0XqIDgtCuG2Te52dh6JIM59w1yazJkho7555UOwtNmsoEL0yymKP24XGrdRLik0ctUDTyGjCo EM+W/l9BhUmK/NwkXueUcMRi47mK5Ryj45NTFj6r7MFY4aLOSZuFlch6ea5kwj0xEt3KxBpnUg/D MncYmRXakZHas3DXkfhAR5cqf7sq7xwNdcMlFlHDODMr+NQ5+/KZhQcc2YhbPrM8z1z07Tu5PKts rKRAF7U7LNyI7M744oSFlcAGUgjUG2uLhXs6u73tK5m7iAxbkY0TrrBPDEUpVw4Juj5gA+RF9Udc WhexpT9bYuKNBSd/U/07AUy5w4LXbrDkVnLtid/CrVJKWeXO2yimRiBsslV6Ke667cqyU9yIfEl4 17HCKm8LsfQK3d+EIBoPxSgOq3tS8H0GqhjDlIriDxDS/rrLSJlcxUeV56ZtXlFRk3KNGi1XRK6A O/QrYx+hb7S3RkFv4Q0NDzUi/OzdXcOtEagAhOWpb0zt2j1K3dDoE6PTBq+dG2uuZ43WMewSUwcc Tn9RQeVyn7fafNnvuSOAVUZtS2NPwvogzMjQkKxhUlR9+qIINdhDxj0kZqEETBEEbRBYSZ/BaOLO D6JSdLhc0hztFbXGK8xEjpAFJ2+79Oh+79nH3i4Sv7B7zVkH6WdEH601J3WC8OMyvmq3qtbctHHt eYGp1DQr8Jw2LCWvijW6Hw9gvJjSCpD52/n8D4yd8EXJaC1IWrRl4zjiy1pUpXKQ8jvawDD2mO/x uTcQL0agb+Y51+tosOArlBBjkmmjzKx4C/qmeXTjRZOFWy92I/Wju89jc8E9bhfO/iEbZ9yioJdh a38+YAPaNVYVIFVlxNbntaHY3ZPqMYvax80WfeWa3p4V23f7bEV/AAAA//8DAFBLAwQUAAYACAAA ACEAjgqpaR8BAADKAgAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC0kr1OwzAURnck3sHy7tpxG2iiJBVN2pmhsCLLcdJI/olsNxAh3h1H pREMLKButu7VOd+9drZ5UxIMwrrO6BxGCwKB0NzUnW5z+HTYozUEzjNdM2m0yOEoHNwUtzfZozW9 sL4TDgSEdjk8et+nGDt+FIq5RSjrUGmMVcyHq22xaZqOi8rwkxLaY0rIHeYn541C/YyDZ146+L8i a8OndO75MPYhbpF9wUfQKN/VOXyv4rKqYhIjuktKFJFoi5Jlco/ImhC6peU+edh9QNBPzRQCzVQY /cUKVhstx0AcfCr7V+dtkeHv54vpn87l7ORHpltxfeNqNjYnKRE32lsjr++NL17XSNb+8EXxMlpF lNLVbzvG0zOfP2HxCQAA//8DAFBLAQItABQABgAIAAAAIQCRtStyigIAAPkUAAATAAAAAAAAAAAA AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAEe/GtATAQAAdQMAAAsA AAAAAAAAAAAAAAAAwwQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAA AAAAAAAAAAAAAAAABwgAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAABAkAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAAQoA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAA NwEAACAAAAAAAAAAAAAAAAAA/goAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA+wsAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAA AAAA+AwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA9w0AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA9A4AAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAA AAAAAAAAAAAA8Q8AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU5LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAEv1Pey/AAAANwEAACEAAAAAAAAAAAAAAAAA7hAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUx NC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAAAOwRAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlMTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3 AQAAIQAAAAAAAAAAAAAAAADqEgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhAPCqnDPYAAAAzgEAACEAAAAAAAAAAAAAAAAA6BMAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGUxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAA AAAAAP8UAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA LfEhHIQBAAA4CwAAHwAAAAAAAAAAAAAAAAD9FQAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwu cmVsc1BLAQItABQABgAIAAAAIQBwIsXNrAIAAH0OAAAUAAAAAAAAAAAAAAAAAMYYAABwcHQvcHJl c2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQBQZiLofAQAAAcVAAAVAAAAAAAAAAAAAAAAAKQb AABwcHQvc2xpZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEA9r+Q1nkCAABhBwAAFQAAAAAA AAAAAAAAAABTIAAAcHB0L3NsaWRlcy9zbGlkZTkueG1sUEsBAi0AFAAGAAgAAAAhAM72ezx4AgAA lwYAABYAAAAAAAAAAAAAAAAA/yIAAHBwdC9zbGlkZXMvc2xpZGUxMC54bWxQSwECLQAUAAYACAAA ACEArLgnv5kDAAABCgAAFgAAAAAAAAAAAAAAAACrJQAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbFBL AQItABQABgAIAAAAIQCnrc8VBQMAAJEHAAAWAAAAAAAAAAAAAAAAAHgpAABwcHQvc2xpZGVzL3Ns aWRlMTMueG1sUEsBAi0AFAAGAAgAAAAhAERQTDwMAgAAAwUAABYAAAAAAAAAAAAAAAAAsSwAAHBw dC9zbGlkZXMvc2xpZGUxNC54bWxQSwECLQAUAAYACAAAACEAhIsAS3oDAAB6DQAAFQAAAAAAAAAA AAAAAADxLgAAcHB0L3NsaWRlcy9zbGlkZTgueG1sUEsBAi0AFAAGAAgAAAAhADyMInF2AgAApgYA ABYAAAAAAAAAAAAAAAAAnjIAAHBwdC9zbGlkZXMvc2xpZGUxMS54bWxQSwECLQAUAAYACAAAACEA ffg9kMUCAAC/CAAAFQAAAAAAAAAAAAAAAABINQAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0A FAAGAAgAAAAhANsfjMzPAwAARwoAABUAAAAAAAAAAAAAAAAAQDgAAHBwdC9zbGlkZXMvc2xpZGUy LnhtbFBLAQItABQABgAIAAAAIQCmtCNHvwIAAB8HAAAVAAAAAAAAAAAAAAAAAEI8AABwcHQvc2xp ZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEABHcaMugCAADvBwAAFQAAAAAAAAAAAAAAAAA0 PwAAcHB0L3NsaWRlcy9zbGlkZTcueG1sUEsBAi0AFAAGAAgAAAAhANwtCTvAAwAAXw0AABUAAAAA AAAAAAAAAAAAT0IAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQAD4L14PgMA ABQLAAAVAAAAAAAAAAAAAAAAAEJGAABwcHQvc2xpZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAA ACEA1nH6nNUAAADAAQAAKgAAAAAAAAAAAAAAAACzSQAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25v dGVzU2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAA AAAA0EoAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA2EsAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AAAAAAAAAAAAAAAA4EwAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA6E0AAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAAAAAAAAAAAAAAAA8E4AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQ5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANwgiPGXBwAAMi8AACEAAAAAAAAAAAAAAAAA+E8A AHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAtAAAAAAAAAAAAAAAAAM5XAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAADXWAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA4FkAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAA6FoAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA8FsAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADWttt+tBAAAjBEA ACEAAAAAAAAAAAAAAAAA+FwAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBLAQIt ABQABgAIAAAAIQAmXypv8AQAAB0SAAAhAAAAAAAAAAAAAAAAAORhAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEASTB5P6kCAADCBgAAIQAAAAAAAAAAAAAA AAATZwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAPRE AE/ZAgAAFAgAACEAAAAAAAAAAAAAAAAA+2kAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2 LnhtbFBLAQItABQABgAIAAAAIQBWMxUJbgUAAJIbAAAhAAAAAAAAAAAAAAAAABNtAABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAAACEAqaVo7xQEAADDEQAAIQAA AAAAAAAAAAAAAADAcgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAG AAgAAAAhAJrizV+IBAAAtBAAACEAAAAAAAAAAAAAAAAAE3cAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQzLnhtbFBLAQItABQABgAIAAAAIQD7e/SiTQMAAPEKAAAhAAAAAAAAAAAAAAAAANp7 AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAFk+0hDgE AABgEAAAIQAAAAAAAAAAAAAAAABmfwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1s UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA3YMAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAFsXvwNkAwAA KAsAACIAAAAAAAAAAAAAAAAA5YQAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQ SwECLQAUAAYACAAAACEAdY+nT7IDAAAIDAAAIgAAAAAAAAAAAAAAAACJiAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQItABQABgAIAAAAIQClxhsubQIAANMFAAAfAAAAAAAA AAAAAAAAAHuMAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAh AGmiXyEeAQAAxwcAACwAAAAAAAAAAAAAAAAAJY8AAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xp ZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPnPCTmDBgAAXBsAABQAAAAAAAAAAAAA AAAAjZAAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0AFAAGAAgAAAAhAHWxSP4IBgAAPx0AACEA AAAAAAAAAAAAAAAAQpcAAHBwdC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbFBLAQItABQA BgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAAAAAAAAAAAAAAImdAABwcHQvdGhlbWUvdGhlbWUxLnht bFBLAQItABQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAAAAAAAAAAAAAAD6kAABwcHQvbm90ZXNN YXN0ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BLAQItAAoAAAAAAAAAIQAErpq7AIAA AACAAAAXAAAAAAAAAAAAAAAAAEOlAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ1BLAQItABQABgAI AAAAIQBYm5DCqgAAAB8BAAARAAAAAAAAAAAAAAAAAHglAQBwcHQvcHJlc1Byb3BzLnhtbFBLAQIt ABQABgAIAAAAIQC0dMhPhAEAAEcDAAARAAAAAAAAAAAAAAAAAFEmAQBwcHQvdmlld1Byb3BzLnht bFBLAQItABQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAAAAAAAAAAAAAAAAQoAQBwcHQvdGFibGVT dHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAHGE71SMAQAAyAIAABEAAAAAAAAAAAAAAAAA4SgBAGRv Y1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAEhjmqgIAwAA/AYAABAAAAAAAAAAAAAAAAAA pCsBAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAjgqpaR8BAADKAgAAEwAAAAAAAAAA AAAAAADiLwEAZG9jUHJvcHMvY3VzdG9tLnhtbFBLBQYAAAAARQBFAIUUAAA6MgEAAAA= --_002_0C72C38E7EBC34499E8A9E7DD00786391C3ED7A3sjceml521mbxchi_-- From nobody Sat Jul 14 15:46:44 2018 Return-Path: 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 AAF93130F16 for ; Sat, 14 Jul 2018 15:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Pjv3cJ2De0r9 for ; Sat, 14 Jul 2018 15:46:40 -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 0490C124C04 for ; Sat, 14 Jul 2018 15:46:39 -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 w6EMjF73004785; Sat, 14 Jul 2018 15:46:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=F4gVqiSLoXvEf0FKtmZp6KfLPXgVxrgFWC7xAiMPhec=; b=u3eGnP5WKkMhhkOB+oWSk3hM81RVBXOT/KMS9rdn78DwZnDJqZj97d6wMfIaMvz6Qxx6 OifhIzGipD32hfhx3xyP+M0L/s9EuSsG32ruEnezyyM+9uh7ZzKXSXgnhgLu/ePrO+Pa t8cZGLsPsMokGceGckKpoptgOjeuL3abw6qiVbVNDRk/vEsNh+Hb17qFBNzJABCmNUQF B+X7424kVwx9EYJZY4UzStKt2FK95bYJMwfmhPzbHtR3iFt/geDjQ+ZFqqScB7kryw2+ ZaYx4TmrU90XDWmPIQT3TGKiVb1SzMZeVH/5aBQVeNTXnmHDrAURwpXBRpi/81Wy15ug Cw== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) by mx0b-00273201.pphosted.com with ESMTP id 2k7g9x8pux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 15:46:37 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4293.namprd05.prod.outlook.com (52.135.202.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.10; Sat, 14 Jul 2018 22:46:34 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0952.021; Sat, 14 Jul 2018 22:46:34 +0000 From: Kent Watsen To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] removing a node from a grouping Thread-Index: AQHUGTztxnT5XKTefkqKIIHQ7mrEO6SLSRCAgAPKboA= Date: Sat, 14 Jul 2018 22:46:33 +0000 Message-ID: References: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> In-Reply-To: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4293; 7:8LsX/KaxyBwg3koTprPh+Cgzzn12OlVefaMsk3r+tXA3/5mmHWJn3IifyTcwa05DCgoQJ2Am1Y0mivw1I7ZER/amgEqDNFSvvIPj5LZ93ef/XIQVuKrxgciQNWQzcDY0/hLREWXOiQFGKyMNkycjeAKFUi0oAE2plMLquzPBiedvs78VMBtWotsyDre/2KO9ibOtbJr9a8ALVTvegaPk8/a2N5qAGdaIrdHSCug9boOSfcba0NBiOVBmHMXoz2M1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fe19e93a-518c-4b73-1be5-08d5e9dba675 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4293; x-ms-traffictypediagnostic: BYAPR05MB4293: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4293; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4293; x-forefront-prvs: 07334CBCCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(366004)(346002)(136003)(51444003)(199004)(189003)(478600001)(6246003)(8936002)(53936002)(106356001)(25786009)(3846002)(86362001)(476003)(575784001)(36756003)(7736002)(33656002)(81166006)(83716003)(76176011)(53546011)(305945005)(81156014)(229853002)(102836004)(66066001)(6506007)(6116002)(105586002)(2906002)(2616005)(316002)(14454004)(486006)(99286004)(6306002)(8676002)(256004)(110136005)(966005)(446003)(11346002)(82746002)(58126008)(186003)(68736007)(6512007)(2501003)(6436002)(5250100002)(6486002)(5660300001)(26005)(97736004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4293; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: /vK2XBpOVTUMLyrsC6VuEXPRr1+VeoWaBQ/Vqjiw/ft1ps1Sfo7IGAb4mt7KBu2HeoJ04A8QvblqiKBrY5e6VFREGYhWAGZmt+mg93dbu0uoK0h+5wg/QwUwGGOXfPttiFhZ+orIpoF1OCdP29vZ6ueX5Q/GGTHNVEJJv7oZBu6/HAYXuwtQYxjP0CXcQq+ql6hdKFAEHO7nY5AVboNSsqOfWxDXRi5m5CiW6cTk6eeWGtCexBJHO6Qkg2H/gJTwFN7fVVfHuwjIBour5C0wJvCJpoVm/dl7o/lKW96NsZrozmfQ/aaEekvcVgj5AnO/FAE+1gEyWQn8EJpshIR3NYLtkHWbEZFj0maQwBAKNY0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: fe19e93a-518c-4b73-1be5-08d5e9dba675 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2018 22:46:33.7111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4293 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140275 Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 22:46:43 -0000 DQpIaSBSb2IsDQoNClJpZ2h0IHlvdSBhcmUsICJyZWZpbmUiIGRvZXNuJ3QgaGF2ZSBhICJ3aGVu IiBzdWJzdGF0ZW1lbnQsIGJ1dCAiYXVnbWVudCIgZG9lcy4NCg0KICAgIGdyb3VwaW5nICJiYXIt ZXRjIiB7DQogICAgICB1c2VzICJmb28tYmFyLWV0YyIgew0KICAgICAgICBhdWdtZW50ICJmb28i IHsNCiAgICAgICAgICB3aGVuICJmYWxzZSgpIjsNCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIH0N Cg0KDQpUaGUgcHJvYmxlbSB3aXRoIHNwbGl0dGluZyB1cCBncm91cGluZ3MgaXMgdGhhdCAxKSBp dCBuZWVkcyB0byBiZSBkb25lIA0KYmVmb3JlaGFuZCBhbmQgMikgaXQgbWF5IHByb2R1Y2UgInVu bmF0dXJhbCIgZ3JvdXBpbmdzIHRoYXQgd291bGRuJ3QgYmUNCnRoZXJlIG90aGVyd2lzZS4NCg0K S2VudA0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KSGkgS2VudCwNCg0KSSdt IG5vdCBzdXJlIHRoYXQgc2VjIDcuMTMuMiBvZiA3OTUwIGFsbG93cyByZWZpbmUgdG8gYWRkIGEg d2hlbiANCnN0YXRlbWVudCwgYWx0aG91Z2ggYW4gZXF1aXZhbGVudCBzb2x1dGlvbiB3b3VsZCBi ZSByZWZpbmUgaXQgd2l0aCBhbiANCmlmLWZlYXR1cmUgc3RhdGVtZW50IGZvciBhIGZlYXR1cmUg dGhhdCBpcyBuZXZlciBlbmFibGVkLg0KDQpJZGVhbGx5LCBJIHRoaW5rIHRoYXQgdGhlIGdyb3Vw aW5ncyB3b3VsZCBiZSBzcGxpdCB1cCwgc28gdGhhdCB0aGV5IA0KYnVpbGQgb24gZWFjaCBvdGhl ci4NCg0KICAgZ3JvdXBpbmcgImZvbyIgew0KICAgICBjb250YWluZXItb3ItbGVhZiAiZm9vIiB7 IC4uLiB9DQogICB9DQoNCiAgIGdyb3VwaW5nICJiYXItZXRjIiB7DQogICAgIGNvbnRhaW5lci1v ci1sZWFmICJiYXIiIHsgLi4uIH0NCiAgICAgLi4uICAvLyB0aGUgImV0YyIgOykNCiAgIH0NCg0K ICAgZ3JvdXBpbmcgImZvby1iYXItZXRjIiB7DQogICAgIGdyb3VwaW5nICJmb28iOw0KICAgICBn cm91cGluZyAiYmFyLWV0YyI7DQogICB9DQoNClRoYW5rcywNClJvYg0KDQpPbiAxMS8wNy8yMDE4 IDE4OjMwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gU2F5IHRoZXJlIGlzOg0KPg0KPiAgICBncm91 cGluZyAiZm9vLWJhci1ldGMiIHsNCj4gICAgICBjb250YWluZXItb3ItbGVhZiAiZm9vIiB7IC4u LiB9DQo+ICAgICAgY29udGFpbmVyLW9yLWxlYWYgImJhciIgeyAuLi4gfQ0KPiAgICAgIC4uLiAg Ly8gdGhlICJldGMiIDspDQo+ICAgIH0NCj4NCj4gQW5kIHRoZSBnb2FsIGlzIHRvIHVzZSB0aGUg Z3JvdXBpbmcgc2FucyB0aGUgImZvbyIgbm9kZS4NCj4gQ2FuIGEgIndoZW4iIHN0YXRlbWVudCB0 aGF0IGFsd2F5cyBldmFsdWF0ZXMgdG8gImZhbHNlIg0KPiBkbyBpdD8NCj4NCj4gICAgZ3JvdXBp bmcgImJhci1ldGMiIHsNCj4gICAgICB1c2VzICJmb28tYmFyLWV0YyIgew0KPiAgICAgICAgcmVm aW5lICJmb28iIHsNCj4gICAgICAgICAgd2hlbiAiZmFsc2UoKSI7DQo+ICAgICAgICB9DQo+ICAg ICAgfQ0KPiAgICB9DQo+DQo+IEFueSBiZXR0ZXIgaWRlYXM/DQo+DQo+IFRoYW5rcywNCj4gS2Vu dA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgw VWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFH VHZqSVNsYUpkY1pvJm09bjhBVVI4Z3RGMzMwZDk2ZHFja3Z4NTNoQ2R5VW01dHNUekpzbTZEVTgz VSZzPWhENTBwMFJ6TFZ6elRuUTYybnhnczI1NndGZjdVbUljelRKTWY5eW1fbjgmZT0NCj4gLg0K Pg0KDQoNCg0K From nobody Sun Jul 15 04:11:27 2018 Return-Path: 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 F17E9130F65 for ; Sun, 15 Jul 2018 04:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 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 7iG0LUk2kgb2 for ; Sun, 15 Jul 2018 04:11:23 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B38130E79 for ; Sun, 15 Jul 2018 04:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2771; q=dns/txt; s=iport; t=1531653083; x=1532862683; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QQkfa3RARVWUhPPGC24x4yZo53ZscRIo3ua4woQfKU4=; b=m/txWwESotNAp2hLlUOKb6fU7hIVRqE58o421WP904N/Kq2ufcPJllxq ocqvMzK+GrBq5jpaSzmWx+579XDgWPRfq70OxdzAcNwYhwZ/S7GwalH8O rpjrgcta7Qg55F0T6ZlJgd+BGpaErB7Dx3OLMEpdE52JW3J00U3pukRkc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQDnKktb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQsbRIog3uIY41CJJczCyOESQKCcDgUAQIBAQIBAQJtHAy?= =?us-ascii?q?FNwEFIw8BBTYbCw4KAgImAgJXBgEMBgIBARYBgwUBgX8PqHKBLoRbhWOBC4l?= =?us-ascii?q?OP4E4DIJegxkCgWCDAYJVAoxXjQUJhgqJFwaCBoYWhUmKOYIGhVWBWCGBUjM?= =?us-ascii?q?aCBsVO4JpCYV4im4jMIxjAQE?= X-IronPort-AV: E=Sophos;i="5.51,356,1526342400"; d="scan'208";a="5127606" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 11:11:21 +0000 Received: from [10.61.227.226] ([10.61.227.226]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6FBBKY0012785; Sun, 15 Jul 2018 11:11:20 GMT To: Kent Watsen , "netmod@ietf.org" References: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> From: Robert Wilton Message-ID: Date: Sun, 15 Jul 2018 07:11:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 11:11:26 -0000 Hi Kent, I don't think that this is a valid use of augment - I thought that augment can only add news data nodes, not add extra sub statements to existing ones. Also, YANG allows grouping to be changed so that it is constructed from sub groupings, at long as the original grouping name is preserved and is only updated in a backwards compatible way.  But as you say, this can still lead to unnatural groupings. I still think that groupings are probably being overused.  Perhaps Andy's clone statement might be a better alternative in some cases (https://github.com/netmod-wg/yang-next/issues/31). Thanks, Rob On 14/07/2018 18:46, Kent Watsen wrote: > Hi Rob, > > Right you are, "refine" doesn't have a "when" substatement, but "augment" does. > > grouping "bar-etc" { > uses "foo-bar-etc" { > augment "foo" { > when "false()"; > } > } > } > > > The problem with splitting up groupings is that 1) it needs to be done > beforehand and 2) it may produce "unnatural" groupings that wouldn't be > there otherwise. > > Kent > > > ===== original message ===== > > Hi Kent, > > I'm not sure that sec 7.13.2 of 7950 allows refine to add a when > statement, although an equivalent solution would be refine it with an > if-feature statement for a feature that is never enabled. > > Ideally, I think that the groupings would be split up, so that they > build on each other. > > grouping "foo" { > container-or-leaf "foo" { ... } > } > > grouping "bar-etc" { > container-or-leaf "bar" { ... } > ... // the "etc" ;) > } > > grouping "foo-bar-etc" { > grouping "foo"; > grouping "bar-etc"; > } > > Thanks, > Rob > > On 11/07/2018 18:30, Kent Watsen wrote: >> Say there is: >> >> grouping "foo-bar-etc" { >> container-or-leaf "foo" { ... } >> container-or-leaf "bar" { ... } >> ... // the "etc" ;) >> } >> >> And the goal is to use the grouping sans the "foo" node. >> Can a "when" statement that always evaluates to "false" >> do it? >> >> grouping "bar-etc" { >> uses "foo-bar-etc" { >> refine "foo" { >> when "false()"; >> } >> } >> } >> >> Any better ideas? >> >> Thanks, >> Kent >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n8AUR8gtF330d96dqckvx53hCdyUm5tsTzJsm6DU83U&s=hD50p0RzLVzzTnQ62nxgs256wFf7UmIczTJMf9ym_n8&e= >> . >> > > From nobody Sun Jul 15 23:31:49 2018 Return-Path: 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 325F2130F53 for ; Sun, 15 Jul 2018 23:31:46 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 b1Gy7USeq_72 for ; Sun, 15 Jul 2018 23:31:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B18F312E039 for ; Sun, 15 Jul 2018 23:31:43 -0700 (PDT) Received: from pluto.hedeland.org (81-228-153-183-no289.tbcn.telia.com [81.228.153.183]) by mail.tail-f.com (Postfix) with ESMTPSA id DDB6D1AE02AC; Mon, 16 Jul 2018 08:31:40 +0200 (CEST) To: Robert Wilton References: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> From: Per Hedeland Cc: Kent Watsen , "netmod@ietf.org" Message-ID: <8995a833-21cb-8126-5a40-2972ba1a4e1a@tail-f.com> Date: Mon, 16 Jul 2018 08:31:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 06:31:46 -0000 On 2018-07-15 13:11, Robert Wilton wrote: > Hi Kent, > > I don't think that this is a valid use of augment - I thought that augment can only add news data nodes, not add extra sub statements to existing ones. Well, it is valid (though not if "foo" is a leaf), but you are right, and it doesn't do what Kent expects. The 'when' statement, as always, "makes its parent data definition statement conditional". I.e. it applies to the 'augment' statement, not the 'foo' statement, and thus with an always-false 'when', no 'augment' will happen. --Per > Also, YANG allows grouping to be changed so that it is constructed from sub groupings, at long as the original grouping name is preserved and is only updated in a backwards compatible way. But as you > say, this can still lead to unnatural groupings. > > I still think that groupings are probably being overused. Perhaps Andy's clone statement might be a better alternative in some cases (https://github.com/netmod-wg/yang-next/issues/31). > > Thanks, > Rob > > > On 14/07/2018 18:46, Kent Watsen wrote: >> Hi Rob, >> >> Right you are, "refine" doesn't have a "when" substatement, but "augment" does. >> >> grouping "bar-etc" { >> uses "foo-bar-etc" { >> augment "foo" { >> when "false()"; >> } >> } >> } >> >> >> The problem with splitting up groupings is that 1) it needs to be done >> beforehand and 2) it may produce "unnatural" groupings that wouldn't be >> there otherwise. >> >> Kent >> >> >> ===== original message ===== >> >> Hi Kent, >> >> I'm not sure that sec 7.13.2 of 7950 allows refine to add a when >> statement, although an equivalent solution would be refine it with an >> if-feature statement for a feature that is never enabled. >> >> Ideally, I think that the groupings would be split up, so that they >> build on each other. >> >> grouping "foo" { >> container-or-leaf "foo" { ... } >> } >> >> grouping "bar-etc" { >> container-or-leaf "bar" { ... } >> ... // the "etc" ;) >> } >> >> grouping "foo-bar-etc" { >> grouping "foo"; >> grouping "bar-etc"; >> } >> >> Thanks, >> Rob >> >> On 11/07/2018 18:30, Kent Watsen wrote: >>> Say there is: >>> >>> grouping "foo-bar-etc" { >>> container-or-leaf "foo" { ... } >>> container-or-leaf "bar" { ... } >>> ... // the "etc" ;) >>> } >>> >>> And the goal is to use the grouping sans the "foo" node. >>> Can a "when" statement that always evaluates to "false" >>> do it? >>> >>> grouping "bar-etc" { >>> uses "foo-bar-etc" { >>> refine "foo" { >>> when "false()"; >>> } >>> } >>> } >>> >>> Any better ideas? >>> >>> Thanks, >>> Kent >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n8AUR8gtF330d96dqckvx53hCdyUm5tsTzJsm6DU83U&s=hD50p0RzLVzzTnQ62nxgs256wFf7UmIczTJMf9ym_n8&e= >>> >>> . >>> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 16 05:36:02 2018 Return-Path: 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 4214F13102E for ; Mon, 16 Jul 2018 05:36:01 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 FV5rOhpfAhRU for ; Mon, 16 Jul 2018 05:36:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id ED82D131025 for ; Mon, 16 Jul 2018 05:35:59 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 78E231820CC2; Mon, 16 Jul 2018 14:42:16 +0200 (CEST) Received: from localhost (unknown [89.24.60.123]) by trail.lhotka.name (Postfix) with ESMTPSA id E54C618202E0; Mon, 16 Jul 2018 14:42:14 +0200 (CEST) From: Ladislav Lhotka To: Robert Wilton , Kent Watsen , "netmod\@ietf.org" In-Reply-To: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> References: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod\@ietf.org" Date: Mon, 16 Jul 2018 14:35:56 +0200 Message-ID: <878t6bcq8j.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:36:01 -0000 Robert Wilton writes: > Hi Kent, > > I'm not sure that sec 7.13.2 of 7950 allows refine to add a when=20 > statement, although an equivalent solution would be refine it with an=20 > if-feature statement for a feature that is never enabled. Neither "when" nor "if-feature" is permitted as a substatement of "refine". Lada > > Ideally, I think that the groupings would be split up, so that they=20 > build on each other. > > grouping "foo" { > container-or-leaf "foo" { ... } > } > > grouping "bar-etc" { > container-or-leaf "bar" { ... } > ... // the "etc" ;) > } > > grouping "foo-bar-etc" { > grouping "foo"; > grouping "bar-etc"; > =C2=A0} > > Thanks, > Rob > > On 11/07/2018 18:30, Kent Watsen wrote: >> Say there is: >> >> grouping "foo-bar-etc" { >> container-or-leaf "foo" { ... } >> container-or-leaf "bar" { ... } >> ... // the "etc" ;) >> } >> >> And the goal is to use the grouping sans the "foo" node. >> Can a "when" statement that always evaluates to "false" >> do it? >> >> grouping "bar-etc" { >> uses "foo-bar-etc" { >> refine "listen" { >> when "false()"; >> } >> } >> } >> >> Any better ideas? >> >> Thanks, >> Kent >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jul 16 06:34:01 2018 Return-Path: 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 4FAAD12F1A6 for ; Mon, 16 Jul 2018 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 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 4xo1eGUTADGb for ; Mon, 16 Jul 2018 06:33:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DEE1294D0 for ; Mon, 16 Jul 2018 06:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6065; q=dns/txt; s=iport; t=1531748037; x=1532957637; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=OQyygb6Q2d6JC2nuu5jl7od0OH+d95Ik6QRxDm7MHKw=; b=FxYE+ui3k8p1zeP6yhkT7Mie8eG/G/5ww1LG7jSOuN2Ue2K2ZZ6va/Ta 8BAp0AWNjLlDsXSj2PTR8kN1sFx7vjC7SW34TyQV7OKZ5JKpUfUxrf9fK gpMRREpvEWab2ZNG5aSpptptayNV75TNuW7VDXR2T2W73C356H0qib1KD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAQAunkxb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTgVltEiiDfIhjjWeQKocJCxgBCoQDRgKDATcVAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNgEBAQMBAQEhSxsLDgoqAgInMAYBDAYCAQEXgwUBgXcID6h/gS4fhDy?= =?us-ascii?q?FXwWKWT+BOIJqgxkBAQKEX4JVAplcCY8hBogchUmMP4VVgVcigVIzGggbFTu?= =?us-ascii?q?CaYsVhVojMAGOGwEB?= X-IronPort-AV: E=Sophos;i="5.51,361,1526342400"; d="scan'208,217";a="5205406" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 13:33:55 +0000 Received: from [10.61.227.226] ([10.61.227.226]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6GDXsv8016878; Mon, 16 Jul 2018 13:33:54 GMT To: Kent Watsen , "netmod@ietf.org" References: <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> <878t6bcq8j.fsf@nic.cz> From: Robert Wilton Message-ID: Date: Mon, 16 Jul 2018 09:33:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <878t6bcq8j.fsf@nic.cz> Content-Type: multipart/alternative; boundary="------------E685620384410FE98F04A4C3" Content-Language: en-US Archived-At: Subject: Re: [netmod] removing a node from a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 13:34:00 -0000 This is a multi-part message in MIME format. --------------E685620384410FE98F04A4C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Lada, On 16/07/2018 08:35, Ladislav Lhotka wrote: > Robert Wilton writes: > >> Hi Kent, >> >> I'm not sure that sec 7.13.2 of 7950 allows refine to add a when >> statement, although an equivalent solution would be refine it with an >> if-feature statement for a feature that is never enabled. > Neither "when" nor "if-feature" is permitted as a substatement of > "refine". My reading of 7950, is that you are allowed to refine a node to add an "if-feature". RFC 7950, section 7.13.2: The following refinements can be done: ... o A leaf, leaf-list, list, container, choice, case, anydata, or anyxml node may get additional "if-feature" expressions. Thanks, Rob > > Lada > >> Ideally, I think that the groupings would be split up, so that they >> build on each other. >> >> grouping "foo" { >> container-or-leaf "foo" { ... } >> } >> >> grouping "bar-etc" { >> container-or-leaf "bar" { ... } >> ... // the "etc" ;) >> } >> >> grouping "foo-bar-etc" { >> grouping "foo"; >> grouping "bar-etc"; >>  } >> >> Thanks, >> Rob >> >> On 11/07/2018 18:30, Kent Watsen wrote: >>> Say there is: >>> >>> grouping "foo-bar-etc" { >>> container-or-leaf "foo" { ... } >>> container-or-leaf "bar" { ... } >>> ... // the "etc" ;) >>> } >>> >>> And the goal is to use the grouping sans the "foo" node. >>> Can a "when" statement that always evaluates to "false" >>> do it? >>> >>> grouping "bar-etc" { >>> uses "foo-bar-etc" { >>> refine "listen" { >>> when "false()"; >>> } >>> } >>> } >>> >>> Any better ideas? >>> >>> Thanks, >>> Kent >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --------------E685620384410FE98F04A4C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Lada,


On 16/07/2018 08:35, Ladislav Lhotka wrote:
Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> writes:


Hi Kent,

I'm not sure that sec 7.13.2 of 7950 allows refine to add a when 
statement, although an equivalent solution would be refine it with an 
if-feature statement for a feature that is never enabled.

Neither "when" nor "if-feature" is permitted as a substatement of
"refine".
My reading of 7950, is that you are allowed to refine a node to add an "if-feature".

RFC 7950, section 7.13.2:

The following refinements can be done:

...

   o  A leaf, leaf-list, list, container, choice, case, anydata, or
      anyxml node may get additional "if-feature" expressions.

Thanks,
Rob


Lada


Ideally, I think that the groupings would be split up, so that they 
build on each other.

   grouping "foo" {
     container-or-leaf "foo" { ... }
   }

   grouping "bar-etc" {
     container-or-leaf "bar" { ... }
     ...  // the "etc" ;)
   }

   grouping "foo-bar-etc" {
     grouping "foo";
     grouping "bar-etc";
   }

Thanks,
Rob

On 11/07/2018 18:30, Kent Watsen wrote:

Say there is:

   grouping "foo-bar-etc" {
     container-or-leaf "foo" { ... }
     container-or-leaf "bar" { ... }
     ...  // the "etc" ;)
   }

And the goal is to use the grouping sans the "foo" node.
Can a "when" statement that always evaluates to "false"
do it?

   grouping "bar-etc" {
     uses "foo-bar-etc" {
       refine "listen" {
         when "false()";
       }
     }
   }

Any better ideas?

Thanks,
Kent



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    

  


--------------E685620384410FE98F04A4C3--


From nobody Mon Jul 16 07:59:31 2018
Return-Path: 
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 CFF2713108B for ; Mon, 16 Jul 2018 07:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.586
X-Spam-Level: 
X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hG7Ear71; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OXmHzNq9
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 q0xxA1otNjcl for ; Mon, 16 Jul 2018 07:59:28 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 11697131089 for ; Mon, 16 Jul 2018 07:59:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531753166; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=i9mbP9mscRYudhTL4nBlSKHXvVPT+aH6kvEdmRgBh94=; b=hG7Ear71CaG6S8q7VNqgIZymispWIbUFZbQodGzcQm56gd8t0Sv5jlnc9Y8FbRYP 6niXqBCfqtezM6iQAQIKo9EtUeMzCz09CSp8rTEMi8prEOkTtKX4L6fkm/7xvB1o thYuv9IDPJUMQfg3vSLmD1bMJKHJr5sJxfbSnO/I7XU=;
X-AuditID: c1b4fb30-d12a19c000000a77-bd-5b4cb2ced590
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B9.22.02679.EC2BC4B5; Mon, 16 Jul 2018 16:59:26 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 16 Jul 2018 16:59:08 +0200
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 16 Jul 2018 16:59:08 +0200
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=w4H8H79l9GZKdu7sNOVteKrBwDPE6v8weyY2StBBluc=; b=OXmHzNq9rmu+Leg7CypgqkkxzrvWzklXqXqTg9IjZLZ7KR01qb1MsBPtvt9UTtnxueFUDsmDoqVKqy9biI9hedKMZ95/2IGEcNQcXP8aepW9ZYE+mJ1sBIKN7Coj9LNrPWNJBtSpwnHD7yUmfOsp3pPSGfMeyJ+blpMtpyrPmLo=
Received: from [IPv6:2001:67c:1232:144:359a:6cee:c6ec:9271] (2001:67c:1232:144:359a:6cee:c6ec:9271) by AM3PR07MB0488.eurprd07.prod.outlook.com (2a01:111:e400:8830::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.7; Mon, 16 Jul 2018 14:59:00 +0000
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References:  <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> <878t6bcq8j.fsf@nic.cz> 
From: Balazs Lengyel 
Message-ID: <5edff99f-7b51-25ff-24df-fac384f12b25@ericsson.com>
Date: Mon, 16 Jul 2018 10:58:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2001:67c:1232:144:359a:6cee:c6ec:9271]
X-ClientProxiedBy: DM5PR13CA0051.namprd13.prod.outlook.com (2603:10b6:3:117::13) To AM3PR07MB0488.eurprd07.prod.outlook.com (2a01:111:e400:8830::18)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8b01c507-5ffe-407d-6ca3-08d5eb2caa5c
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM3PR07MB0488; 
X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0488; 3:MLIQfY3wy1wRh6Kjxjmu1iwwLKE+h1oVw9y9aNxRLba/YL1wFQTJV3SdFSjyJcDbFeatJNPcvLYx5XWd93t9GTn88si/WGcXil+8UkFwSfdLbrPvgcXIGxI8OsgHvmp3Tkq6vEtSSu9RDfsHbRxQaQ4rdyDD3fdk52i+mgFmbr+qRQW4riEr6u11SxqltW1y6LHoQLq6zVfIFjENLxokfBUgdI8gqEudsfpKmwN7LvNqDlL9zMQDTzn1zMou30NF; 25:Cp3aQ9rtH5JMmJE6RDOo7ajOWjv3EoGIfDHhQBjHc3PV3VVDvdzL/+jioBKFQH1KxS+E38EyfreQJW6pg4187kK8CkKY/AA/7luYOqxf1HLDnzM3xwaYjJ1f/2/sbhFdR38g5KUTVdUYhauYGwBRapQdLcjmn/qXb7er3SUYBybzPl1dLvPH6BKrCBkDRJ1M0ynJ5hKEvgBGcfK2i3r+UrbH+BYDZV1uXu7l5ZG+cYwPwdvmBzU3qEIQVDi9zyS2IBWFG4Nr/eza4yuwNbzO+9/ztM5ipe4g42DPx3o2UlOzw+F9sFkgJeHgn03fYBP5eM75myEyfL99VEUJABubFg==; 31:+uD7VgEKbNUREO+qC5Ww3oyqwQyGAls2C3ajmRGiIzRpWKQE/VSvdr/QUQyFdeCaUXQFCxWs8XD+wfR4zjSkWL4KqqMvkCUv4xOLKATmRbBK1Cl/D7Ho1XKkLrn3khF7yvbszWw3f5KS0Fm3MUIZFyU3RiEMAu3Pg1LJpMlNWpXpob5INDga250C4yHYN39xQx+aVTcNnmlUT9kRwKCKLEgy2++uPED08+RGzSiHJSU=
X-MS-TrafficTypeDiagnostic: AM3PR07MB0488:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0488; 20:/dA931+SH7f6KZpWIH2O5O2xMYf+dkerID2oZmuEJVWhjDbJveZ2jIMPbEU7hzNnTdt1ZoyiG1WEHTSHKjRxyWXeRRWq0Z7m6AX3apxohD/3nMWVbrwVqY4rTQF1dzbvYYLM3X8okQ0N5FUDLi2byanxirToMcoqTPcEuRVLGozAkmbtWVoxlN02GJ2z0NIzYSZXyFwzoHVmqTKwSRj2/nUn4J7R0bIgj61LGtBDTd8WBWKMXlkw3HS63j6ZHJkJjAeIHab3McXMznjMApC443MOi4NK0oepuZvnBclBzi/AuHgLHDFduQPIM8aTqmPhgSuoKhPunWO4m7Nl7rkwHZaDDNdy79UHqyd4Mmsq41chYk5Z7VbNdUFO1UkE6K6MW/9jNOK24O7LA6Me491GFyC0ZQtDibMgmQYCtBDRphBaotFaKsy1JS2lRZoOYBHvBCiTBn9for9J/pytAFqqCmG+FvR8bzIr008LWuPfx7SGbhJKtr8zlSpgLvp7RPbS; 4:K6SeASFeqiuwgoATnNScxjF0Rfps43yUbwH/3fEcks07Fbs1hJNSQ45AlJd6fgltBshMfeO7YqxzUJaF2AMXAKabfhDo6o9KHiY3drclhn4/aQGJtCfr/yHPnMNzgw5gKHWr1ytNICC8Cd6fGdw/jI/xdXtSUUwBiFhC7qD4teoXf6eb4wmWiMMmYLIzEki2RNMl6SUidQK8QvXmqXCQyEELyIGdcb1o1uqNbtUE9peboCPA6FYa3CIzaVfHBiMkArxD7F9aedJJKxMxO4V98kh1Ct5kZuxnuaxqDlM6yjK9LZdsKe4dVn+N1VZ/BJecKQrSposypZZCiHSafT6NDIewJuqY/KKzbSR4q+9LbyM=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(95692535739014);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(2018427008)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM3PR07MB0488; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0488; 
X-Forefront-PRVS: 073515755F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(376002)(39860400002)(366004)(252514010)(51444003)(199004)(189003)(54896002)(476003)(236005)(6666003)(106356001)(11346002)(23676004)(105586002)(44832011)(2501003)(25786009)(53936002)(52146003)(2616005)(1706002)(65806001)(6306002)(486006)(65826007)(6486002)(5660300001)(386003)(46003)(6246003)(446003)(186003)(52116002)(31686004)(6116002)(53546011)(76176011)(16526019)(52396003)(2870700001)(23846002)(64126003)(81156014)(36756003)(68736007)(81166006)(8936002)(7736002)(86362001)(31696002)(93886005)(97736004)(966005)(8676002)(2906002)(229853002)(110136005)(606006)(58126008)(50466002)(316002)(65956001)(1941001)(478600001)(2486003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0488; H:[IPv6:2001:67c:1232:144:359a:6cee:c6ec:9271]; 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-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjA3TUIwNDg4OzIzOnBlSE1sczVHd2IyenFjRmZkSGQ0dzA4dTZw?= =?utf-8?B?K2NkVkxXaXcyMWQvRzAzVG9QQzNPTjJIRW5RVDZLVVFHL2ZIZ2Z4QmI5b1NX?= =?utf-8?B?TUQwK0dPdzF5Tjg2QldmaE84ek0vWTI0RUF6S2F3dXZBQm1sbUVWbkd3ZVRC?= =?utf-8?B?OTBBUW5ITG4wOCtseEVQVEVoa293a25BMENtQm5IdXRxMzM5T3c3RzlGc2hX?= =?utf-8?B?WnlnVSs2NGdQMlJYNlJOTUZVbkcwakFGd3hoRXUwWS8xYXdNcVZrR2hSd0xs?= =?utf-8?B?UEhhYkxHMmhxdXJWVVJQT2tJemJiRGJwdGdIYnhVVUFwdndsRzRpMHk3eVFG?= =?utf-8?B?eFJ4dnI0ZVBJYWppeWtoNzRXcEhkSWptODZuUzY3MW9kVmNUQ2VUWWp5YVow?= =?utf-8?B?a05EQnZYMGlHNk1WdHdHaXNMUlU4QTZMMnRRM0I3OGFlOW5DQTJYclhzekV0?= =?utf-8?B?RUhPZnFwTnkrK3RaNG1ZSW5BcmIxRWpuVnAydExjVWdBZDFnNGJ3UDdQTjBS?= =?utf-8?B?ZzZvcFRNVFBQQ3BTZlFCMUxldXdTUWJSK0lScG1RbGU1ZGRhcS9tTTBFMXBS?= =?utf-8?B?WXFDbGZNeW5scWtaMUxna3lRZzJqKzBqaGViVzVQNDVCOXh0M0lwdUdkcW54?= =?utf-8?B?MTM5M2NxdXI0Z2dXZkxSNVEyWVZwN2dPUzc5VHNYU3BiM1dTZ05tcmFzSXNo?= =?utf-8?B?SWVSMnhORWc1bTZ3TDJHTndRczB3VHEwMjhka0N3S3lxYTVjYXJ6c0dZVjlY?= =?utf-8?B?aXJEWjNGVDFzVEJyY0Z6M2J6ckJha2xMOGVTOHBvTHNQelNLbEZPR3pQampw?= =?utf-8?B?dkIybnFrSWt4ZVlJN3gyTXUweUxIeTBXTTdaQllUb3A2ZE9saGlkM2hoYURk?= =?utf-8?B?ai9xSU9BSE0vS3NPK2lvbEM1T3FmenFFWlEvV24zZzNqZmwxeUk5dm1Rckhj?= =?utf-8?B?L2FHZEUyVy96ZU9WWWtOU2tRMmd6cjZHRkhoTVdGdUlmQnpWQy9xb053N1d0?= =?utf-8?B?dzZpTG5LUEZQMXdreGlUQVhRMUQvRkxJNU1Eb0piYVl5azhncG1MVmRONjN6?= =?utf-8?B?OHpjVEc3VjVGeEI2SzNudHJDWFpraEorVy9WU1RZVjh4M0RtWVN2TW8zVCs5?= =?utf-8?B?bmszbitUNXkvNmtiNG9KUjR2L1pFWmV2MmtBVWptNFhEWld5KzRzRVlaNzFr?= =?utf-8?B?QUgrVHh5MHN3eStFUmo1SHVQMlBxejNaVVloVVRkbmNydnRpRVVtc0xZQXFp?= =?utf-8?B?WHVvUnJac2U2QVRmbGovYWZuM2dWSmNKS2pLKzArZjlaaXVJZ1NrYkJBcW9k?= =?utf-8?B?bjV3bklKNVgva2lPWFltMUkvTmkvVVhVNVR3NDgvekl4SER1VGl4SkE2bW1N?= =?utf-8?B?UDM2M0NjV2k5TXNxaG1EeVl4aHg0OU1KalRJOVJJbGdBZ1FDWTNvWUxOSVEv?= =?utf-8?B?M2ovT3pCSlRNT294eFhzVWdSWVBON295dFFyU0V6cnBvM2d3WkhlM1B4MEhV?= =?utf-8?B?czBrcEJ1NkpVL0FPUmw0YWVQUVZHbHRoSHJjVkdnbnFIb2JmSit2L0VLTHRu?= =?utf-8?B?c3BhaHc4Um9lRHExTUJYNkMzKzNHNWdOb0thNmNDOGpkQWdwS1l0Z2JsMlJw?= =?utf-8?B?NVM4NHhzb292SitDbFAzQVIzZXlaV3d0dGNtcnJockVBcjcweVI2OUlTVDRa?= =?utf-8?B?eUtLWkp6T2Y2OTVOSXRBR09Ca3Y2d3gyUzN3M2F6alpsTE4wK1VKTXJNMFl0?= =?utf-8?B?emxuaDdQTHFVOFZmR3JzZ1dwbittZDVCWEVoSWt2TmwvbUYrZVhGVTNhQ1RW?= =?utf-8?B?L1BTRERITy9NL3Z2MUJIN2lKeE5WNTdtbmxMQ3lWUk5tSjJFMEo4MTVkVXl2?= =?utf-8?B?Z2NJUm5hNjRmM2NMOEg5bFVVWjJrWlBYa09mMzF5V0dRQmNqRDBYbTQrRmE2?= =?utf-8?B?ZWs1NjhBdWRWRXp2VVB6ZnB3d1FkRDU1V1Z0b0kySXFjV1pOUU15czA5Mnpo?= =?utf-8?B?Qytod3JNbGFaVU5TTG1VTUQrclBkVHQ2NnNwTmJ2YzFld3BWZlk0NUhrY1Bl?= =?utf-8?Q?ft74=3D?=
X-Microsoft-Antispam-Message-Info: 0DdcxzlhbAN6UcRgvk0zyjbfRol6qQglzF+qOqF9d5b6x1nFclZoBj/H937ghxpzN2N0z5DXu2FwKB/KXPeSSepGOA+RBoSP234DimRwqaJymMGVaGknwps+9pvVHKALo6Ld/d36djjbuWekdxtmMZVAXQAnxoDtxnPQJTajBH5uATw9GUOPtxcznhg+ISkkEijn570hy6dneNrSGuOCD/DAgzGldn9M2St1y6tHGGzuafbnZbShVXVNG9OaufDDI6VKMdfhtFH3XLW0DgkOjE0+JjbR6AsIN3UcC7e3upXQ06wI0eTX7vGXWNtzG0x9Rjpea9y3MLOdDetrHl/MrsMM+9UQ6XkS0PXtJkZBYdc=
X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0488; 6:Ia+XzzmrZr+rGS33YyiaIavU61Xiuj8eG7xvoMoVxpc/44pVB2vYAzkMNfhk1AsyIvGRQzLvW0E+r2xRdHEpeNz9xJVodrfJxN7uOUFLwmJu+e2FwI8p1NpsX/w0/51l4ubuQLtgbjuA0x8s9oQ+r6b8GeLNHcfMaW8wraLFtju8BqQQckYCRpOlc6OjQbwn49MpasseTazI6vtEE6Nj+lHdvoHsbJtykUZ/1ZlCPlnSPI3BothKOFsbng6OEkdQEivYNiTzOBeOY427U7XAAyzW+qoDVkljPS/tS9TJH/hLtPRZHBtuMqwylaEhhrYRTiYm/3zeWO84pS2VqhTYEWHV02mQGx8WoadNegS3kk3Aq2LIymZbbt+4xYq3I2howbCSeISoY5QWSTE2T+4aKMQBm5A6OG3PYcPOLRBBSgMCIA66SgaM4Al51tgJNeZpQWiE56gu8axZtuYA4JQCbg==; 5:atyTk4miTegojVGRZrkXpJ4YUsGroG1wj9/dsFSsm0M4H76Xfmv1NADfbHcRsUfb2bqsvH8kMW318q7OnGjgPELLvUlGdqEZZSpkjHnsf2sDbyV+EtJG+lh6l311u9CIvzsxskjGexP4C3DqqGelcrsUzhKAF1NswCrvsBSebPQ=; 24:TzKzsjvf3ovG6hL3aGEfPxyjAeaiCAmDElXczMamYo3p6E7b87sUGiCM0jmww76hLQGusTeVJbTucy5CyURVyrMn1HvH1jlMte6JeCbHuX4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0488; 7:1rumVGrbpeRfjslkSK3/sgmkNx40N0r5ZXzq9F8aGsxjk3My8Lh/0wYJtVP3ADLo9FAQbYz7wZx3iUnmlbce0kUFGktRxKjsKpJV+4mGeqqdgNxtQvAgypi696ptDvNMzLRiQYSu8Ri7IpZ73BX2hxKm97Paq6HJS+G4lK5JhC3547VbRe4CPpLvLUiUJykO77PxSVS5dNV19kBP5OuoHVAC0TSZ9RjM/pFOvhsxeWdGKg/uEvcu6j2Dxzi+kSem
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2018 14:59:00.0976 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b01c507-5ffe-407d-6ca3-08d5eb2caa5c
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0488
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbG9XPfcJp9og+e9TBYH5rBbzL/YyGrR v07UgdnjxLIrrB5Llvxk8rjedJU9gDmKyyYlNSezLLVI3y6BK2Plhy2MBdvUK+6/OMrcwHhM rouRk0NCwERiwfdPzF2MXBxCAkcZJRY/fs4GkhAS+MYosXKpCERiCZPEnIknmUESLAITmCU2 3xGESOxmkri65w8jSEJYwFTi+P+VTCAJEYEGRonZl9dBzd3DKHGxay/YXDYBI4mp/edZQGxe AXuJTbsvsUCMVZX4emAuO4gtKhAjcXRyCxtEjaDEyZlPwGo4BWwllv+fBRTn4GAWUJNY1qoE EmYWEJe49WQ+E4QtL9G8dTYzSImEgKXEv8XGICdICMxglNh+upUV4jUNiYcX/rJC/C8rcfTs HBYI21eip6edDaLhAqNE07ptzBBOA7vE+p19LBBTtSQm3NYBaWAUiJPYuWYhK0TNEnaJSZPe skFMypboeLOFHcL2kmg7vowZwpaTONV7jgmi4RSzxKfnS5gnMOrPQvLoLITnZiF5bhaS5xYw sqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECEwkB7f8NtjB+PK54yFGAQ5GJR5etvU+0UKs iWXFlbmHGCU4mJVEeKdUA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzWvhtjhISSE8sSc1OTS1I LYLJMnFwSjUwuuYsMVp5+tKMZrdTCsKXOGx5dnHKL+Sz7NE23N+7ef7sg1sNu9apeaq1aEgl bzz/kdn+cue7JvH1X4zjZl7sXPLG59Nd9v+yxUeWfllUlXj6YWBSwUnduQqxN26Kh3W9i3tX +67w8PwDLsba2fG/Q8uckldv1i9ateqWhf3ePpsT556G+yx4rMRSnJFoqMVcVJwIAFJ96Ksg AwAA
Archived-At: 
Subject: Re: [netmod] removing a node from a grouping
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Jul 2018 14:59:31 -0000


  
    
  
  
    
So it seems that 

    

    
   grouping "bar-etc" {
     uses "foo-bar-etc" {
       refine "foo" {
         if-feature never-supported-feature ;
       }
     }
   }

would work. It seems rather similar to a deviation.
regards Balazs 


    

    
On 7/16/2018 9:33 AM, Robert Wilton
      wrote:

    

    

      
      
Hi Lada,

      

      

      
On 16/07/2018 08:35, Ladislav Lhotka
        wrote:

      

      

        
Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> writes:



        

          
Hi Kent,

I'm not sure that sec 7.13.2 of 7950 allows refine to add a when 
statement, although an equivalent solution would be refine it with an 
if-feature statement for a feature that is never enabled.


        

        
Neither "when" nor "if-feature" is permitted as a substatement of
"refine".

      

      My reading of 7950, is that you are allowed to refine a node to
      add an "if-feature".

      

      RFC 7950, section 7.13.2:

      

      
The following refinements can be done:

....

   o  A leaf, leaf-list, list, container, choice, case, anydata, or
      anyxml node may get additional "if-feature" expressions.

      

      Thanks,

      Rob

      

      

        
Lada



        

          
Ideally, I think that the groupings would be split up, so that they 
build on each other.

   grouping "foo" {
     container-or-leaf "foo" { ... }
   }

   grouping "bar-etc" {
     container-or-leaf "bar" { ... }
     ...  // the "etc" ;)
   }

   grouping "foo-bar-etc" {
     grouping "foo";
     grouping "bar-etc";
   }

Thanks,
Rob

On 11/07/2018 18:30, Kent Watsen wrote:


          

            
Say there is:

   grouping "foo-bar-etc" {
     container-or-leaf "foo" { ... }
     container-or-leaf "bar" { ... }
     ...  // the "etc" ;)
   }

And the goal is to use the grouping sans the "foo" node.
Can a "when" statement that always evaluates to "false"
do it?

   grouping "bar-etc" {
     uses "foo-bar-etc" {
       refine "listen" {
         when "false()";
       }
     }
   }

Any better ideas?

Thanks,
Kent



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
..



          

          
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


        

      

      

      

      

      

      
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Mon Jul 16 13:24:35 2018
Return-Path: 
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 90FAA131175 for ; Mon, 16 Jul 2018 13:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 3dB9V4lfKY7p for ; Mon, 16 Jul 2018 13:24:28 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 754CD130FC8 for ; Mon, 16 Jul 2018 13:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531772667; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2lumyVjhluUCWN3R6LMlixgUzUTUWbh6xH0ua0NIwWs=; b=GpwgZTyqIxE4ZNJvQGirr5iw3h01OVf9zztrQ1JoMhgNrNsEhwyI23Aeo9N/NtqJ ZrRxgDGoRsBr5By2R3ILeczDXkAs2IsAFS8QwOI7g0LGSCPkkYcYRQl6X4W9s2+Q O7eeqEWermpq4rQULPzCtgea9uR3CGFFdIrYqQbjlaM=;
X-AuditID: c618062d-bc3ff70000004941-ad-5b4cfefb5fcf
Received: from EUSASMB501.ericsson.se (Unknown_Domain [147.117.188.219]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id A5.73.18753.BFEFC4B5; Mon, 16 Jul 2018 22:24:27 +0200 (CEST)
Received: from EUSASMB505.ericsson.se (147.117.188.223) by EUSASMB501.ericsson.se (147.117.188.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 16 Jul 2018 16:24:27 -0400
Received: from EUSASMB505.ericsson.se ([147.117.188.241]) by EUSASMB505.ericsson.se ([147.117.188.241]) with mapi id 15.01.1466.003; Mon, 16 Jul 2018 16:24:26 -0400
From: David Sinicrope 
To: "netmod@ietf.org" 
Thread-Topic: Broadband Forum Liaison re YANG Data Model for ANCP
Thread-Index: AQHUHUDb43ZHBu0a2kOl8qB25UkSjKSSS3kA
Date: Mon, 16 Jul 2018 20:24:26 +0000
Message-ID: 
References: <9CEBC23D-CD0F-4DF2-8123-7787A17611B2@ericsson.com>
In-Reply-To: <9CEBC23D-CD0F-4DF2-8123-7787A17611B2@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [147.117.188.8]
Content-Type: multipart/alternative; boundary="_000_E5D734704B3D47DDBC116A83BC3663B1ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXTPbd3f/3yiDT5vsraYf7GR1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGWee7WQpuG1fsfbRBOYGxk+2XYycHBICJhKbuvpZuxi5OIQE jjFKfP3yhhnC+cEocfrwXGaQKiGBFYwSV067g9hsQB3rNu5hAbFFBNQlZu5cz9bFyMEhLOAg 8epQFETYUeLh+hlQJUYS825PZwKxWQRUJc48+8IKYvMK2EscO7KZBWK8vcTm5VdZQcZwAo3p my4BEmYUEJP4fmoNWCuzgLjErSfzmSBuFpBYsuc8M4QtKvHy8T+wkaICehJTZz+CqlGU+Hz6 BjvISGaBZInF73ghtgpKnJz5hGUCo+gsJFNnIVTNQlIFEdaUWL9LH6JaUWJK90N2CFtDonXO XHaIEmuJtr9CyEoWMHKsYuQoLS7IyU03MtjECIynYxJsujsY70/3PMQowMGoxMO74rtPtBBr YllxZe4hRgkOZiUR3inVQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Zzx5o4QE0hNLUrNTUwtS i2CyTBycUg2MkdvWMFreiQkKeDKFZ6/22ewp/Ho9kYcbvkUu2aJ5ie3u8rY1S969nzllAqPL qpMb3OeLumflFrFHHrBLWHFry9/JWxw/6X/4sUCE42RQm8A8Gx+W5Mj6ugz3r68dovcs+ffR qKTm9jILe2lOy5uPP+w+v7v7xE+Ruwoua3U9l5eujxXlD3wlo8RSnJFoqMVcVJwIAJ1oWTej AgAA
Archived-At: 
Subject: [netmod] FW: Broadband Forum Liaison re YANG Data Model for ANCP
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Jul 2018 20:24:31 -0000

--_000_E5D734704B3D47DDBC116A83BC3663B1ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBsaWFpc29uIHdhcyBzZW50IHRvIE5ldG1vZCB3aGVuIGl0IHdhcyBmaXJzdCByZWNlaXZl
ZCBieSBTdGF0ZW1lbnRzIGJhY2sgaW4gQXByaWwuDQpQbGVhc2UgY29uc2lkZXIgdGhpcyBhIHJl
ZnJlc2ggY29ycmVzcG9uZGluZyB0byB0aGUgaXRlbSBvbiB0aGUgTmV0bW9kIENoYWly4oCZcyBz
bGlkZXMgZm9yIE1vbnRyZWFsLg0KUmVnYXJkcywNCkRhdmUgU2luaWNyb3BlDQpJRVRGIExpYWlz
b24gTWFuYWdlciB0byBCQkYNCg0KRnJvbTogRGF2aWQgU2luaWNyb3BlIDxkYXZpZC5zaW5pY3Jv
cGVAZXJpY3Nzb24uY29tPg0KRGF0ZTogTW9uZGF5LCBKdWx5IDE2LCAyMDE4IGF0IDQ6MDkgUE0N
ClRvOiAiSW50LWFyZWFAaWV0Zi5vcmciIDxJbnQtYXJlYUBpZXRmLm9yZz4NClN1YmplY3Q6IEJy
b2FkYmFuZCBGb3J1bSBMaWFpc29uIHJlIFlBTkcgRGF0YSBNb2RlbCBmb3IgQU5DUA0KDQpQZXIg
bXkgY29tbWVudHMgYXQgdGhlIG1pYyB0b2RheSBkdXJpbmcgdGhlIHN0YXJ0IG9mIHRoZSBJbnRB
cmVhIFdHIHNlc3Npb24gYW5kIHRoZSByZXF1ZXN0IG9mIHRoZSBDaGFpcnMsIHBsZWFzZSBzZWUg
dGhlIGxpYWlzb24gcmVmZXJlbmNlZCBiZWxvdy4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvbGlhaXNvbi8xNTY4Lw0KDQpUaGUgbGlhaXNvbiBtYWtlcyBub3RlIG9mIFlBTkcgbW9kZWxp
bmcgd29yayBzdGFydGluZyBpbiB0aGUgQnJvYWRiYW5kIEZvcnVtIGZvciBBTkNQLg0KSXQgYWxz
byBub3RlcyB3b3JrIG5lZWRlZCwgYW5kIGFuIGFudGljaXBhdGVkIGRyYWZ0IHRvIGVuaGFuY2Ug
QU5DUCB0byBjb3ZlciBEU0wgZW5oYW5jZW1lbnRzIGFuZCBuZXcgdGVjaG5vbG9naWVzIHN1Y2gg
YXMgRy5mYXN0Lg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9u
cyBhYm91dCB0aGUgbGlhaXNvbi4NClJlZ2FyZHMsDQpEYXZlIFNpbmljcm9wZQ0KSUVURiBMaWFp
c29uIE1hbmFnZXIgdG8gQkJGDQoNCg0KDQoNCg0K

--_000_E5D734704B3D47DDBC116A83BC3663B1ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <416D8EF22E9D954DADCB69394F19240D@ericsson.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw
Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u
YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6
MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm
b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw
YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs
aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBsaWFpc29uIHdhcyBz
ZW50IHRvIE5ldG1vZCB3aGVuIGl0IHdhcyBmaXJzdCByZWNlaXZlZCBieSBTdGF0ZW1lbnRzIGJh
Y2sgaW4gQXByaWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBjb25zaWRlciB0aGlzIGEgcmVm
cmVzaCBjb3JyZXNwb25kaW5nIHRvIHRoZSBpdGVtIG9uIHRoZSBOZXRtb2QgQ2hhaXLigJlzIHNs
aWRlcyBmb3IgTW9udHJlYWwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+RGF2ZSBTaW5pY3JvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SUVURiBMaWFpc29uIE1h
bmFnZXIgdG8gQkJGPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPkRhdmlkIFNpbmljcm9wZSAmbHQ7ZGF2aWQuc2luaWNyb3BlQGVyaWNzc29uLmNv
bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdWx5IDE2LCAyMDE4IGF0IDQ6MDkgUE08
YnI+DQo8Yj5UbzogPC9iPiZxdW90O0ludC1hcmVhQGlldGYub3JnJnF1b3Q7ICZsdDtJbnQtYXJl
YUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+QnJvYWRiYW5kIEZvcnVtIExpYWlz
b24gcmUgWUFORyBEYXRhIE1vZGVsIGZvciBBTkNQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBlciBteSBjb21tZW50cyBh
dCB0aGUgbWljIHRvZGF5IGR1cmluZyB0aGUgc3RhcnQgb2YgdGhlIEludEFyZWEgV0cgc2Vzc2lv
biBhbmQgdGhlIHJlcXVlc3Qgb2YgdGhlIENoYWlycywgcGxlYXNlIHNlZSB0aGUgbGlhaXNvbiBy
ZWZlcmVuY2VkIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTU2OC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvbGlhaXNvbi8xNTY4LzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPlRoZSBsaWFpc29uIG1ha2VzIG5vdGUgb2YgWUFORyBtb2RlbGluZyB3b3JrIHN0YXJ0
aW5nIGluIHRoZSBCcm9hZGJhbmQgRm9ydW0gZm9yIEFOQ1AuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkl0
IGFsc28gbm90ZXMgd29yayBuZWVkZWQsIGFuZCBhbiBhbnRpY2lwYXRlZCBkcmFmdCB0byBlbmhh
bmNlIEFOQ1AgdG8gY292ZXIgRFNMIGVuaGFuY2VtZW50cyBhbmQgbmV3IHRlY2hub2xvZ2llcyBz
dWNoIGFzIEcuZmFzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PlBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGFib3V0IHRoZSBs
aWFpc29uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EYXZl
IFNpbmljcm9wZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JRVRGIExpYWlzb24gTWFuYWdlciB0byBCQkY8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_E5D734704B3D47DDBC116A83BC3663B1ericssoncom_--


From nobody Mon Jul 16 18:52:39 2018
Return-Path: 
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 68A9E130EBD for ; Mon, 16 Jul 2018 18:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 eTUAHEyHoQxn for ; Mon, 16 Jul 2018 18:52:34 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 0E8D2130ECA for ; Mon, 16 Jul 2018 18:52:32 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 558B360121 for ; Tue, 17 Jul 2018 03:52:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1531792349; bh=wfI5O0xroF0B3Gr/4XTVZOss2Gr9LI9dMlZA6t+qzbk=; h=From:To:Date; b=UKCj/AtVqzVBHTaZsOaTRqAsruBY7a4pbhqTcMvXdVo5XsurmpCkMo2VK8DMDeAbQ E+aUYuOtUTb1hxACuMX9IMp9ZCKNimuDUtHizXNi5rDo1lzGH5El779lQxphlHFacF SSLVbgP1DEqIFr0pISYrQaosZf15Nx8bpP+/nWPo=
Message-ID: 
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 17 Jul 2018 03:52:28 +0200
In-Reply-To: 
References:  <80f2c076-1937-9b09-fdec-a4d4c9a16aa5@cisco.com> <878t6bcq8j.fsf@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] removing a node from a grouping
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jul 2018 01:52:38 -0000

On Mon, 2018-07-16 at 09:33 -0400, Robert Wilton wrote:
> Hi Lada,
> 
> On 16/07/2018 08:35, Ladislav Lhotka wrote:
> > Robert Wilton  writes:
> > 
> > > Hi Kent,
> > > 
> > > I'm not sure that sec 7.13.2 of 7950 allows refine to add a when 
> > > statement, although an equivalent solution would be refine it with an 
> > > if-feature statement for a feature that is never enabled.
> > 
> > Neither "when" nor "if-feature" is permitted as a substatement of
> > "refine".
>  My reading of 7950, is that you are allowed to refine a node to add an "if-
> feature".
> 
> RFC 7950, section 7.13.2:
> 
> The following refinements can be done:
> 
> ....
> 
>    o  A leaf, leaf-list, list, container, choice, case, anydata, or
>       anyxml node may get additional "if-feature" expressions.

Oh yes, you are right, I looked into the ABNF and failed to see

*if-feature-stmt

Sorry, Lada

> 
> Thanks,
> Rob
> 
> > Lada
> > 
> > > Ideally, I think that the groupings would be split up, so that they 
> > > build on each other.
> > > 
> > >    grouping "foo" {
> > >      container-or-leaf "foo" { ... }
> > >    }
> > > 
> > >    grouping "bar-etc" {
> > >      container-or-leaf "bar" { ... }
> > >      ...  // the "etc" ;)
> > >    }
> > > 
> > >    grouping "foo-bar-etc" {
> > >      grouping "foo";
> > >      grouping "bar-etc";
> > >    }
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > On 11/07/2018 18:30, Kent Watsen wrote:
> > > > Say there is:
> > > > 
> > > >    grouping "foo-bar-etc" {
> > > >      container-or-leaf "foo" { ... }
> > > >      container-or-leaf "bar" { ... }
> > > >      ...  // the "etc" ;)
> > > >    }
> > > > 
> > > > And the goal is to use the grouping sans the "foo" node.
> > > > Can a "when" statement that always evaluates to "false"
> > > > do it?
> > > > 
> > > >    grouping "bar-etc" {
> > > >      uses "foo-bar-etc" {
> > > >        refine "listen" {
> > > >          when "false()";
> > > >        }
> > > >      }
> > > >    }
> > > > 
> > > > Any better ideas?
> > > > 
> > > > Thanks,
> > > > Kent
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > ..
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
>  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jul 17 07:26:44 2018
Return-Path: 
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 B7E2B130EBB; Tue, 17 Jul 2018 07:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8SxIQHRs6HxN; Tue, 17 Jul 2018 07:26:40 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87F9130E1B; Tue, 17 Jul 2018 07:26:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A009B14C37E8; Tue, 17 Jul 2018 16:26:37 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YMfUdbJyKSYk; Tue, 17 Jul 2018 16:26:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 75E6514C37EC; Tue, 17 Jul 2018 16:26:37 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JPlriVjuR3Hs; Tue, 17 Jul 2018 16:26:37 +0200 (CEST)
Received: from [192.168.42.78] (dhcp-9285.meeting.ietf.org [31.133.146.133]) by mail.transpacket.com (Postfix) with ESMTPSA id E873D14C37E8; Tue, 17 Jul 2018 16:26:36 +0200 (CEST)
References: <153163104655.12797.4549822574205791661.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" , detnet@ietf.org
From: Vladimir Vassilev 
X-Forwarded-Message-Id: <153163104655.12797.4549822574205791661.idtracker@ietfa.amsl.com>
Message-ID: <1671ad91-5627-fedf-ef1c-9a2a790accd4@transpacket.com>
Date: Tue, 17 Jul 2018 16:26:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <153163104655.12797.4549822574205791661.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jul 2018 14:26:43 -0000

Hi,

I have submitted a draft=20
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/=20
that proposes a model for network bridge management based on the concept=20
of flows. The model has 2 components 1. Forwarding based on flows. 2.=20
Scheduling/QoS based on gate controller topologies that provide a new=20
and very generic way of modeling and managing the actual scheduler=20
design and map the flows to scheduler topology inputs.

There is similar work on the flow based forwarding in detnet however I=20
am not sure detnet is the right workgroup to be defining the flow=20
model.=C2=A0 I think the flow concept is important and general. It is as=20
significant as the concept of interfaces and is not only relevant to=20
detnet. Let me know what is your opinion of the draft and the proposed=20
network bridge concept.

Vladimir

-------- Forwarded Message --------
Subject: 	New Version Notification for=20
draft-vassilev-netmod-network-bridge-00.txt
Date: 	Sat, 14 Jul 2018 22:04:06 -0700
From: 	internet-drafts@ietf.org
To: 	Vladimir Vassilev 



A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt
has been successfully submitted by Vladimir Vassilev and posted to the
IETF repository.

Name:		draft-vassilev-netmod-network-bridge
Revision:	00
Title:		A YANG Data Model for Network Bridge Management
Document date:	2018-07-14
Group:		Individual Submission
Pages:		44
URL:            https://www.ietf.org/internet-drafts/draft-vassilev-netmo=
d-network-bridge-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vassilev-netmod-ne=
twork-bridge/
Htmlized:       https://tools.ietf.org/html/draft-vassilev-netmod-network=
-bridge-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vassilev-netm=
od-network-bridge


Abstract:
    This document introduces new YANG model of a network bridge.

                                                                         =
         =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From hayden@thebrowns.net.nz  Tue Jul 10 14:43:44 2018
Return-Path: 
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 8CF2A1310FD for ; Tue, 10 Jul 2018 14:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 3LC7e90rAVaD for ; Tue, 10 Jul 2018 14:43:42 -0700 (PDT)
Received: from esmtp06.digiweb.net.nz (esmtp06.digiweb.net.nz [202.174.114.135]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5450912872C for ; Tue, 10 Jul 2018 14:43:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by esmtp06.digiweb.net.nz (Postfix) with ESMTP id 2EF24C0722 for ; Wed, 11 Jul 2018 09:43:39 +1200 (NZST)
Received: from esmtp06.digiweb.net.nz ([202.174.114.135]) by localhost (dwl-chc-mscan02.digiweb.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVPk9HOrEI2m for ; Wed, 11 Jul 2018 09:43:38 +1200 (NZST)
Received: from email.discountdomains.co.nz (dd-chc-smail01.digiweb.net.nz [202.174.115.190]) by esmtp06.digiweb.net.nz (Postfix) with ESMTP id BA921BFF52 for ; Wed, 11 Jul 2018 09:43:38 +1200 (NZST)
Received: by email.discountdomains.co.nz via HTTP; Wed, 11 Jul 2018 09:43:32 +1200
From: "hayden" 
To: 
Date: Wed, 11 Jul 2018 09:43:32 +1200
Reply-To: hayden@thebrowns.net.nz
Message-ID: <368eeb2b0f1b419892dc303806f27a94@thebrowns.net.nz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=5023e32b28b7470e8fcb30e61d2d0ac4
X-Originating-IP: [124.157.115.222]
Archived-At: 
X-Mailman-Approved-At: Thu, 19 Jul 2018 07:00:11 -0700
Subject: [netmod] YANG schema mount - any early implementations?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jul 2018 21:47:35 -0000

This is a multipart message in MIME format.

--5023e32b28b7470e8fcb30e61d2d0ac4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello everyone,
  
  
 I have been following with interest the progress of the development of the 
YANG schema mount proposed RFC.
  
 I was wondering if anybody within the working group mailing list might 
know of any early implementations of the current draft schema mount 
mechanism?
  
 I understand that the schema mount proposal is still effectively in a 
state of flux, but are there any publicly visible implementations or 
deployments of a NETCONF or RESTCONF server that those interested could 
experiment with (e.g. to aid in client development)?
  
  
  
 Thanks and regards,
  
 Hayden
  


--5023e32b28b7470e8fcb30e61d2d0ac4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=

Hello everyone,



 



 



I have been following with interest the progress of the development of=
 the YANG schema mount proposed RFC.



 



I was wondering if anybody within the working group mailing list =
might know of any early implementations of the current draft schema mount m=
echanism?



 



I understand that the schema mount proposal is still effectively in a&=
nbsp;state of flux, but are there any publicly visible implementations or d=
eployments of a NETCONF or RESTCONF server that those interested =
could experiment with (e.g. to aid in client development)?



 



 



 



Thanks and regards,



 



Hayden



 


--5023e32b28b7470e8fcb30e61d2d0ac4--


From nobody Fri Jul 20 01:09:35 2018
Return-Path: 
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 A42CB13107E for ; Fri, 20 Jul 2018 01:09:33 -0700 (PDT)
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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 InR32R-MTqkO for ; Fri, 20 Jul 2018 01:09:31 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 39447131071 for ; Fri, 20 Jul 2018 01:09:30 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 1C7C8235F8D4; Fri, 20 Jul 2018 10:09:27 +0200 (CEST)
Date: Fri, 20 Jul 2018 10:09:27 +0200
From: Juergen Schoenwaelder 
To: hayden 
Cc: netmod@ietf.org
Message-ID: <20180720080927.uwfu7ns2nitlv6g4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: hayden , netmod@ietf.org
References: <368eeb2b0f1b419892dc303806f27a94@thebrowns.net.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <368eeb2b0f1b419892dc303806f27a94@thebrowns.net.nz>
User-Agent: NeoMutt/20180622
Archived-At: 
Subject: Re: [netmod] YANG schema mount - any early implementations?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 08:09:34 -0000

On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote:
>   
> I understand that the schema mount proposal is still effectively in a 
> state of flux, but are there any publicly visible implementations or 
> deployments of a NETCONF or RESTCONF server that those interested could 
> experiment with (e.g. to aid in client development)?
>

State of flux? It is past WG last call and IETF last call.

https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Jul 20 06:46:06 2018
Return-Path: 
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 D8A18130F97 for ; Fri, 20 Jul 2018 06:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 DrkuU0em8MZK for ; Fri, 20 Jul 2018 06:46:02 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20112.outbound.protection.outlook.com [40.107.2.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F02130E2D for ; Fri, 20 Jul 2018 06:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B+BEVVsZm6h8wWh3lAvqaBXowYEke+RjuFOitITjZ1w=; b=eudX5HXMsO8jlXhmHAaVrh4rsRlz0T9xNUvF3Onhnxo0vaGGtFiSLoOYRy1tTwXg6225UvH3o8tuWxznoyFB9aLn9riX8PEJ3ehY+dVCMS/wOM19utV6l/PDIl/GrxXQhnSJH0zYpm3zJmAb6GZ5YHGe1uTYIT+Yt4+y3/Gl4es=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; 
Received: from [IPv6:2001:67c:370:128:f8e7:3760:85fc:b89a] (2001:67c:370:128:f8e7:3760:85fc:b89a) by HE1PR0701MB2507.eurprd07.prod.outlook.com (2603:10a6:3:72::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Fri, 20 Jul 2018 13:45:58 +0000
From: Martin Vigoureux 
To: netmod@ietf.org
Cc: Alissa Cooper , Martin Vigoureux 
Message-ID: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
Date: Fri, 20 Jul 2018 15:45:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Originating-IP: [2001:67c:370:128:f8e7:3760:85fc:b89a]
X-ClientProxiedBy: YQBPR0101CA0065.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:1::42) To HE1PR0701MB2507.eurprd07.prod.outlook.com (2603:10a6:3:72::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9eda735e-e299-42c3-3b6b-08d5ee472023
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(2017052603328)(7193020); SRVR:HE1PR0701MB2507; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2507; 3:mSkuz0ccx871xyoKvGWYs2W5fD8uum94FBmFsSd3oBrY/bBJwmGiPUXfCztCEy/KOdZn0Z27x+aGdyeD7BVqHl8yVNZjIYLHdn287kWpLg+9wrN2VH16R3ZJufIOaUh3WgTshBROYOFDXsoMdfUMU0zzc6ECxhxlCdjEYjnfLQYTRMmB9SeGf9o5tNJXp+2vfzdzDMFeJYytK4ZV9xclTNavN4snoXpS55DYjHPg43IKJWHO16vbfQBnWXKY5O+b; 25:vF0bjChb6p6SQh0VfWhEwYVnI/oXKO5vst7E/GRHTYQ8VTlQNbgkM7PvLQRuS3mxozUtiNtwxym5ObwxcfcJ2Bc6C2c2B9RIdMjPDq2msAwYiIgTtaJRRz/IQfwYSyXjIy54yo3A4G6X3CR3dMupItRYFrPKAjmfrnyEoNyzYlFABKlukXSYoVyVM+nzogyzIixUoLdSgLy6O2QCeD5hxGz61foB60h2I6IfQdgzUKgodOycSpeIGG8izaYphVJW9WCxNH+3q7T/axAjTOb3gkivIfJhqECqLJUoOOF4etFmVvKw0g+h4LgnCzlg4G1iQ2lAbfwb3NbUCDK86NXZvA==; 31:9iogNtCkerCW26kVwfMqxaNVwqtr29zCWu4OkGXDoyC+6oCrUugCJ4cusqgDZy+ik1YAnoy3vgT5C3JuXRaVWvKE84ysxPeH+lqQoK4hzHJ4Vu+iv3rWMmsRXMgEJr8wJt5pjvygoGGeni7Ke/dR+eqM9qV+UT3Zwp4N268id3smPA++iTXnfOMK73PyENRDn0nvDk/rDK3W2pdPEFl1qseuHuPGmjGKjyJdXjXjhmQ=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB2507:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2507; 20:rsvFRyitnOCExho8TfdscJxkDd7qfOmrUtntO7MPdzpmPMpgKwlV/XBGtKJdb+6YMq2apckrYKsRTQuVdJME6f3QK/lhSN8rnAF1nwpscqBvzRNEpHeXD2boEfzLLjizSaTeWCujMEvPwpb6T0nOl2xWdp0uFVZyRbRyqUtLZEL2pVcqWFdvGQa2KsKvNUu2dG32biLTsYPS5Mi65tJwyQLXl1LU84rzw41zso1OZAbauzqHj1lDr01XbLdDuPjOMH4pH4UFM0K0545R4m7v2Eqa0xjVJb0zLokZcIsp/U+iqCn8CDGJDuqH/Ld+IHs49jCum4/ktItdx6b3oh2v3SpsCWgHZfnq2e8c0IE7vtKIMTQpunYRiYweMXUu+Q91x3uBdMN0rGSnvPylPWtU+ygG6sdwzdmZsnGwPN6a9fXsJnDARttVi4/8VSdV/Vj5doI1Cja+ph3oMJp+Wg8leNfqPmd/yf9j7kiIiqug5YXC7BflQTiikjPeXrWgtd7l; 4:gXmfh55kokb+DwcMfdqMHNjCdR6ZqyGST5Tm1V8342zGB0WKUzSNSf9ISjOfFMMYQ/uDTeHMLT90vKKHTMujL6V+WRksxUKYGAaqCd8gaycOd8dZ/xszEemT1jl17uaFW2SdyfPBHzORQFR5pXqdMe3V3wdvy1dOoIVCz9DSJ4nhUX9c8EEVn4kSywa95HR79A1M3/hbIItCGOM0y9DZbbP7t34RsefjsXD9IJ9Ow9+NvuvU+DnOcMFreLjbKA9odjQEkN0/ROeGMeuA1LIHxA==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2507; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2507; 
X-Forefront-PRVS: 073966E86B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(136003)(396003)(39860400002)(85644002)(189003)(199004)(106356001)(68736007)(1706002)(107886003)(53936002)(3260700006)(67846002)(25786009)(2616005)(476003)(54906003)(31686004)(58126008)(36756003)(86362001)(486006)(65826007)(64126003)(2361001)(4326008)(230700001)(478600001)(6116002)(5660300001)(6666003)(31696002)(52116002)(16526019)(2486003)(23676004)(6916009)(52146003)(52396003)(50466002)(46003)(2351001)(65956001)(47776003)(65806001)(316002)(2906002)(6486002)(305945005)(81166006)(81156014)(97736004)(44832011)(7736002)(386003)(8936002)(105586002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2507; H:[IPv6:2001:67c:370:128:f8e7:3760:85fc:b89a]; 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-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjI1MDc7MjM6aCswSVBtQTFNOWhYR0p5RGM5QXI5OTVL?= =?utf-8?B?YkR4NncxRlY2SGk0RTM1MmxyME5vR1BWUTlrUElRRWVoVDNZSzZ4TWoxQ000?= =?utf-8?B?bGlCRzhkaDJPSDkxMlpBcldFbW4rY3JHY1JXNU92SndTNnRRWDB3WThpVUlr?= =?utf-8?B?RFRjZU9RY0lYNy9UeHYvZHRLMktEaU9kZ3M3dS9mVVZxYllFZU5GM0FKNW9t?= =?utf-8?B?dWtSdTZ3cC85VTY2NGpoOW1Jcnh2NE82YzFoSU1GQWYwVzN5K1J4Z1llTmc4?= =?utf-8?B?OVdIZi84SERSZWdRbFN0Qk1EVEtZaVBIZFpRSksxeFNxOUJUc1pMR2h4cVda?= =?utf-8?B?Zk5KWFRVdnh4L21pcWgzR0pQY2gyd1BONEE2bTdOUUVJeGc4cmxHbmd3UGll?= =?utf-8?B?QnFKZElxNSs2VVBBUU95eFZyaEllMTZRbjBTN1gwK3loUDRlTDljVTBCZXQ4?= =?utf-8?B?SGtDVnV2YmQ0VFVFQXhkcldYNWR2bFV1RXF4NkFOUHZiYkhLNnk4UzJtWlRp?= =?utf-8?B?TGM2Q0hNMzVhMnE1SzhVN01pT2pFUWdRc3pReUFTd3B1VlRWT2liYnFvRHZF?= =?utf-8?B?dVA4SXU5Wmdmek9xaGJBVHpHSDl2YTNBU0xGVTBTL1BJZDVLNTlObEpYVUVy?= =?utf-8?B?alEvOHh1WEp6QkpMaGp0K2dKSXc4cjJuSGZKV2lYbzF6WTRkY1lsekM5YXNI?= =?utf-8?B?T0pFeEI2Q2JyejNPYXFBTGlmVFJ2MlBUTzBMOUVvZkQxRGV3K05LdDM2aDBx?= =?utf-8?B?RmlSQjdiNTBzOFRpUGJmdzJQU1VVcGdNSjJUZE5HOWh0bDhuaG1wTHlPd0JI?= =?utf-8?B?dEdVL2hyaktzRnlZSExHU0VGT0FNYlN6M1dDRitLZnVsWE5sOEQwMW1mRkU0?= =?utf-8?B?T3BzRTdPMk1pNy9RRU1pb2JUN2xpSFY1a3h5Uno4Sm1WWkhQN2lRZGVJcG8x?= =?utf-8?B?djJRT1R1ZjNVbVdjZU11NTlOSEI0ZUhENGUvT3NodkZtTVJXSitoTDBFRFR5?= =?utf-8?B?U3F5Nm1ZMjhCUXkvVWl6VVJtVllSTVNBeGNKWXpHR0xvQ2pCN29TOEpjbGFN?= =?utf-8?B?ZUJ6V2RvNnRSTHZ5ckZQQk5ob0RRWVI2amxJdFpRdkQ5bjhPUXFwbmRhUGRq?= =?utf-8?B?cmUyZWExNk81THR1Q0xpUHl2ZnFwdHZNb29iMk9yeVRPQUxuaHNGTUlqS1V2?= =?utf-8?B?TVpXWlZlNE9zNklEbGI3bEJ6MU1rd3NySUFoZTM1VCt4UDlHNWc3Y3Y5cnZ5?= =?utf-8?B?VE1zdk9aR0VnZVNRTktsWlFxSGtaZVJKcHM5dURCQzg2RTYxelZHMWhENU0y?= =?utf-8?B?dEFWUjk5ZTJ1TUQyQ3AvenBlWVk3UXRZcUZkRmdFT2RRVVB5YTJjcnF1QjY3?= =?utf-8?B?RDEyNXFUZ0RZeGh5MU52T2hBdGFJNzFBc201a3hUNFVPRm5PeExVRlcxc2xH?= =?utf-8?B?Y2I3SzNWZzNNMFhhNXgwOHNydFhXSGRNWFpVYng4YVFwOTNjM3kvTitvOTVD?= =?utf-8?B?L2pYYmNZUUF0dXg1a2tXMWpXWnlOMWpORzl0L254MTIveitZWVQyZFVCQVJP?= =?utf-8?B?Z2ptb0RkL2doY2hsbm1sRGk3aE8vVlcwMEtEMFdqcUdZREd4cnZvR2VMc3Nt?= =?utf-8?B?SVdYemttSENwcVg1ejYvM2N2TXVnSnZIM2REcXpPZVNBelV3RjZtZW5kR01r?= =?utf-8?B?ZHhRVzBZTjhPSTBZVWtBYmtSNjZMOURtcXNLR3cyTEJ0NWZEVVhqRFZnNGIw?= =?utf-8?B?SzFCejFiNlQrNDVlMk1SalpUY3dPdU8vejZTMUlXcHNxUldwdWVmZnYwMG9Z?= =?utf-8?B?TUkzSUllTHpLclFHTkV2aVZVbWRGbW5BZGU0aFBsbzY5UVVUUT09?=
X-Microsoft-Antispam-Message-Info: P3dcKmbrEuiHwQDleLYDy46k+hVlxvBZLj62TrG0/KqG3mHvhMwwXBkZ7hy+PLhGjM53QOtlXETi5OyvE018YPjQFdg+KGSYyUM0vEvh1SuR5g89dor+Vuj1GtwDoigDCiG60dYuK3Is7xKoAQmqyl0YNBIp8E+9bxY8SLQXPpVwZJqXLyQA4dIkrcfA1UbUY2RKObwLi/q1EgsghoqfpWP5NIg/Ix+D7QPZP7l4Qu+JprhPcB5gCzPUk13xvJgT8UeWQ4/XYn2pRK8wJtwgRmlDCGLDQ3sjZTfv4yf3QkbeYiZWv3mvLSIjn64rImOJJvouBoeyMIi0e2JgmR7wLSnxx/PXi61W7kIEHCAksIhbLp7hrogEZEcMw43dZg4uudYzSRXiExLUhscvqyr/pw==
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2507; 6:6lf0e4eRchd3tKRtZADlWdWn7CKHadhj9bPjxw3agAhV1d6a1KN09BZfsuRxozDRYBNCZed4thdpkTgjFuW28M+5LO89INIznZUJgm9DzNFfS15TOra+TDlSXDzA1kjaSQkop7zmNAXgzZiqbPEZun1Lx2rBDom9sXFvJVtA/AEOTNdP3YS6UB1Vtw4ChnL67XY2n3ijD8b1E9R6ZpaWeC0nguxbZlYkusELW05teUtLCWnXHgcbqISGANxuEJ5JNYodFz/OV2FG3wJ11Y4kjQGux7yjTBZ6xmoJ95vz4rq3eFFV0VPqW1DVAY95KO1La7w+1dNWDHWSL+UVfT538ObgylX5M9zJ1cSUCIfUjt0d4ueLfXU52cAkn1Pu5VlUu8M5qULsoGU6c6JZRAXNpT6PwLLp8PWkPAFATDuN4ifUyAOqKeHs+kL8qrxMVL9lBRMp4hdCST8s3887eS+/sQ==; 5:S5I0l+ahBLWMSQA+s8WKAT1Euvgw8IIiUjB67ELl4cY0FuI33sHsADcDnPQ+T0JaWhiqyZpBgRa/d9B/zTGk0aZ819x43nW3OJsSmsiOr7GPzBLVCWzlMgTXVKc6daNaypIw/oPxhtvrYWBL/DDzp3t8FFr15MbBt9dnMSXid+I=; 7:5Ltp/urv2nCLQK3us76HaP03FFIO94KVarTPmjfpwbqjWEAfOWOzKO7zRa270WOC7AaN1R6TL4ocLa5utn44ipqeWiuSE3D6gULLBElbT/0vhkLtpHswDTsitu4PaViZEc6Te2//YfDyCEPZYRhhTdBKhYYPWux2ToVbuIYmDyU/4AOIWL1PXxdcsmccbOPDwuEZGDTvBMhCXTX1isRYlV3V9YATP9X0GGBx4CD0/U1j3PEQo04T3E4wTug+mOqF
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2018 13:45:58.4874 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9eda735e-e299-42c3-3b6b-08d5ee472023
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2507
Archived-At: 
Subject: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 13:46:04 -0000

Hello

As part of a recent IESG review (of draft-bfd-yang) a point came up on 
the use of "iana" in yang modules' name/namespace/prefix.
This is typically used in the case where the module refers to an IANA 
maintained registry. However, the point raised was that the name of the 
registry operator might not always be IANA, and that using that name 
might not put modules on the most stable deployment footing under all 
possible circumstances.

On top of that, as far as I can tell, the use of "iana" is an 
undocumented convention.

So, I wanted to collect views:
on whether a convention should be documented,
and, with regards to the point raised in IESG, on whether that keyword 
should be changed going forward. In that context, what about "reg" (for 
registry) or "regop" (for registry operator)? Other proposals are welcome.

Thanks
-m


From nobody Fri Jul 20 06:52:28 2018
Return-Path: 
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 175E8130E2D for ; Fri, 20 Jul 2018 06:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 DQByYDz5CG5a for ; Fri, 20 Jul 2018 06:52:23 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2221B131168 for ; Fri, 20 Jul 2018 06:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=414; q=dns/txt; s=iport; t=1532094743; x=1533304343; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=tcscPFhgc54HCkx4BymxI2v2zZDH/TzjNOFcPzgsB8k=; b=IZA3bN97gAAJNMUviUhv3PKkynha4dsVSiLDJAOggH1/FUNcvJyKEDN2 ELrLJ5REDshH9n/RkEmek0FrImM3j8CIfMB6Iydi9SJz2Rm8It7TEMZQt sFvh4lf/3dvJ8qDNEfNgiSdNQrLCnoPPHSmv2wWfkcp2bGrhR6BIEc8uh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAwBK6FFb/4oNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNNgWKEJpQzgWCXYguHeiE3FQECAQECAQECbR0LhWCBCwImAl8?= =?us-ascii?q?NCAEBgxyCAKo0gS6KUIELh3eBVz+BOIpmglUCjRmMUwmBQI1qBoE3AYZohVK?= =?us-ascii?q?SIYFXIoFSTSMVgyWQbiONdAEB?=
X-IronPort-AV: E=Sophos;i="5.51,379,1526342400"; d="scan'208";a="424566638"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2018 13:52:22 +0000
Received: from [10.82.171.247] ([10.82.171.247]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id w6KDqLX7026387 for ; Fri, 20 Jul 2018 13:52:22 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: 
Date: Fri, 20 Jul 2018 09:52:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.82.171.247, [10.82.171.247]
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: 
Subject: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 13:52:26 -0000

I just had a chance to finish reading this.  The in-person meeting group
seems to strongly support this work, and I agree.

Coming from a serviceability standpoint, I find this might serve as a
precursor to a VCS-like "blame log".  Would it be reasonable to include
identifiers as to who (or what) made the change and when?  Sorry if this
was raised at the mic today.  I came to the room a bit late.

Joe


From nobody Fri Jul 20 06:52:51 2018
Return-Path: 
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 8456913118D for ; Fri, 20 Jul 2018 06:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 zvk8vmpgi58H for ; Fri, 20 Jul 2018 06:52:43 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70125.outbound.protection.outlook.com [40.107.7.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCC1131179 for ; Fri, 20 Jul 2018 06:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7iG8IeNwjphXBcdBnv18Ipkvk07D+zmw6pP7tGSCtBw=; b=qrvG+BfiIPLw88RFU6k5R4czAkn3a9XgKTkg2riZZPv2u5MOsXRC/mZ+QMWBBQZE4w0FWS/OsjQQ6ETxSnzwZkPksDgdZgncczL4EIZqkHV0W5DXk9Nk3QMQY9J1hlPYVzEVIzYPU84cmz+go7PDaXSKZJmZNpN7A9iIWw1TKXc=
Received: from VI1PR0701MB1885.eurprd07.prod.outlook.com (10.167.197.21) by VI1PR0701MB2240.eurprd07.prod.outlook.com (10.169.137.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Fri, 20 Jul 2018 13:52:38 +0000
Received: from VI1PR0701MB1885.eurprd07.prod.outlook.com ([fe80::38e8:ff94:c728:7391]) by VI1PR0701MB1885.eurprd07.prod.outlook.com ([fe80::38e8:ff94:c728:7391%7]) with mapi id 15.20.0995.008; Fri, 20 Jul 2018 13:52:38 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: clarifications for draft-clemm-netmod-nmda-diff
Thread-Index: AdQgMEEzMOKLHJFGTYmNWeW9m6nT3g==
Date: Fri, 20 Jul 2018 13:52:38 +0000
Message-ID: 
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: [135.245.20.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2240; 6:EfZ97tAyBcbViB4Bf9ocwUfGlZXaFk4kdvjTgnBj9xOgFvhIfo60JdYG8L4nS7+aW/phtqYtVXU7RHlFqRKPE/YN7uOfu10NgIq1eZgX21r21y8LXGEcBlFW1jlZGyhGT4D7nYRs4LNwbeXOdU6fQPgvK8C1hIf7jC6MIRxB6WMt45Gmu9ivfyZCEPMq/FzOFaO6Yxd6GNPbuPXa9oXlLHKlMMklHXV/2MqmxMk+qL0Zo2plIBiiefYn8tIIKtjyp1mqR+ThCJ4gKgHbBbds7Ytcfb9PWZ2AIWAiSBeElHL/EPbfznDUx2UUHKu3UQLQ4di+PKJZ81Gp+4vdOeA2ZAYGBOWqhNEjLK3mO6QSUgsAxjOw3kYKY6AZMqDARmurtdyCP8MRtR3F0nb8WRUXAsMCC/ePtEj4Ngs8xpwUEZsrRAmfkwr6dW/Qq0/IPw6jufDDfjwKIO3crFu+b80S3Q==; 5:bPByxwr0g3Y9vswwsaEVjokCw3HcEnh18dzNDHL02sPamGrFlS6B5hO9IQMLDMF8OBvs4ehTPb7bAIY+eWy5OQwOv+oARwfIZdEiREcwts9JHWM0acFa7bP+OQsZu9WW3L4ozQiuHLayIoVtzGwi1cqC0sCYAq/TMfS7wgL8N2M=; 7:5iWY0wG1RZwsFNQp448ZMmxJuw/yXh3Yf2buBr00yxi9V16XW0s/l2X83Smyx0doiw03WJnaxnbBOqCLgguAtcJ0x+8lzEZWvvYuV8a7K8AAetHU8AihW7hrewHN03sLKzikPj4lHJ+5wLd13oUsXlnl9LpR2vdlsw1dqhkTGMpRkZJA3gH3LDTZveKqenoEzsjPDETKmO7Jl0zCLXxCBMlyZuFqzFCbl9fHagyWp/M9b1FtqmUTwjer86vzLjZV
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 08b5806a-bad8-497b-ba13-08d5ee480e1c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR0701MB2240; 
x-ms-traffictypediagnostic: VI1PR0701MB2240:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2240; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2240; 
x-forefront-prvs: 073966E86B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(366004)(346002)(376002)(53754006)(189003)(199004)(5640700003)(6436002)(25786009)(476003)(2906002)(6306002)(54896002)(55016002)(5660300001)(14454004)(7736002)(2501003)(5250100002)(9686003)(6116002)(316002)(66066001)(790700001)(2900100001)(6916009)(486006)(99286004)(3846002)(81156014)(97736004)(105586002)(8936002)(478600001)(5630700001)(1730700003)(106356001)(26005)(33656002)(8676002)(6506007)(186003)(68736007)(7696005)(53936002)(86362001)(74316002)(81166006)(256004)(102836004)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2240; H:VI1PR0701MB1885.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-microsoft-antispam-message-info: YWVJUJ6P2BClxs5t9XweoRyinyhAPT9iAr74Io4menL6R9HXBznO6AOgefFMsnduTMOZC7jk9XpjMgOwe7oZutI56Puz7lGlnZXn3/58zlcxs+mpYx4XYf8+lG8vjCkzRCjy+dFmnftvtRx0dAGg1S85A/hHQAfZcPmYS6Gf08D0euF95/X3HSBFmQuKu0omcyyx+/XjniCUdtNUe0brt3MKa/KEshGi1+PYDd4cMHoFWz3injOtYUCE9LXawoerAcfDhNocgV/QHg6bQMX+ws6KyHTCdQOO/qbMqg0LKgdw1yvyfv/Wi7rlyl8E0k8j+iWbNYJFP2hsPSjXdLwmYdOavWkaHVCq1kfC4UU83oVaaChDc96/nH3hr4mQetD9ASC6iV6mEEx8lTO6X0LUEQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB1885FC9EA773BDF2DB66F5D99B510VI1PR0701MB1885_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 08b5806a-bad8-497b-ba13-08d5ee480e1c
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 13:52:38.3231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2240
Archived-At: 
Subject: [netmod] clarifications for draft-clemm-netmod-nmda-diff
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 13:52:48 -0000

--_000_VI1PR0701MB1885FC9EA773BDF2DB66F5D99B510VI1PR0701MB1885_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

One thing that we should probably clarify in the diff draft is that a compa=
rison to the operational datastore is not expected to be an atomic snapshot=
.   As the diff function walks through the nodes, some of the operational n=
odes may change value while the diff is underway.

I believe the primary use case for the draft is related to comparison of co=
nfig=3Dtrue data.  Most of the draft seems focused on that case.  Are there=
 use cases that compare config=3Dfalse data ?  Maybe we should give some ex=
ample or explanation of that case.

Regards,
Jason



--_000_VI1PR0701MB1885FC9EA773BDF2DB66F5D99B510VI1PR0701MB1885_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


One thing that we should probab=
ly clarify in the diff draft is that a comparison to the operational datast=
ore is not expected to be an atomic snapshot.   As the diff funct=
ion walks through the nodes, some of the operational
 nodes may change value while the diff is underway.


 


I believe the primary use case =
for the draft is related to comparison of config=3Dtrue data.  Most of=
 the draft seems focused on that case.  Are there use cases that compa=
re config=3Dfalse data ?  Maybe we should give some
 example or explanation of that case.


 


Regards,


Jason


 


 






--_000_VI1PR0701MB1885FC9EA773BDF2DB66F5D99B510VI1PR0701MB1885_--


From nobody Fri Jul 20 07:01:11 2018
Return-Path: 
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 D0F16130E2D for ; Fri, 20 Jul 2018 07:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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
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 l5uozjqu4L1X for ; Fri, 20 Jul 2018 07:01:08 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8B5130DE7 for ; Fri, 20 Jul 2018 07:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1532095268; x=1533304868; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RIXkfy7PTY45zHdYs/8aGpgm4c3bNOj9oCSGLehAHjU=; b=BCFlhHFfPu9zv2XXoTfdm51Gb1vG2YHaOJmaZ6xpjoQYTzMlaqFLYtuS dbcrEMnjRp2TTz+bYPBhPeHO5lCayHwHBC/jOO5ERLVXNK2OBB4IOj0Pd fgm6V9ZRmst0Yrp0DFvCb0YuYJ1aOV326FS+Zd4HeNwY23UPj43gReNem A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwA76lFb/4MNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNNY38oCoN0iASML4Fog1ySBIF6CxgLhANGAheCdSE0GAECAQE?= =?us-ascii?q?CAQECbRwMhTcCBAEBIRE6GwIBCBoCJgICAiULFRACBAESgyABgX8PqiyBLoR?= =?us-ascii?q?dhW4FgQuHd4IWgREnDIJegxkBAYFggwExgiQCjFyNEAkCjy6NcpF6AhEUgSQ?= =?us-ascii?q?dOIFScBU7KgGCPosVhT5vjCmBGwEB?=
X-IronPort-AV: E=Sophos;i="5.51,379,1526342400"; d="scan'208";a="145352676"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2018 14:01:07 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w6KE170p011163 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2018 14:01:07 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Jul 2018 10:01:06 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 20 Jul 2018 10:01:06 -0400
From: "Acee Lindem (acee)" 
To: Martin Vigoureux , "netmod@ietf.org" 
Thread-Topic: [netmod] "iana" in yang modules' name/namespace/prefix
Thread-Index: AQHUIDAKdENQS5PIXkGtPzyGTnThaaSYI9EA
Date: Fri, 20 Jul 2018 14:01:05 +0000
Message-ID: <11F13D75-4941-41B7-9B6E-A9B3E62CD3AC@cisco.com>
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
In-Reply-To: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.114.11]
Content-Type: text/plain; charset="utf-8"
Content-ID: <91B1B2CB5DFEB74F87BECC643ACA3EE6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 14:01:10 -0000

SGkgTWFydGluLCANCkkgd291bGQgcHJlZmVyIG5vdCB1c2luZyAicmVnIiBzaW5jZSBpdCB3aWxs
IGFsd2F5cyBiZSBhbiBhYmJyZXZpYXRpb24gZm9yIGEgbWFjaGluZSBsYW5ndWFnZSByZWdpc3Rl
ciB0byBtZS4gSSdkIGZhdm9yIHVzaW5nICJyZWdpc3RyeSIgaW4gdGhlIG1vZHVsZSBuYW1lIGFu
ZCB0aGUgbW9yZSBjcnlwdGljICJyZWciIGluIHRoZSBtb2R1bGUgcHJlZml4LiANClRoYW5rcywN
CkFjZWUgDQoNCu+7v09uIDcvMjAvMTgsIDk6NDYgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1h
cnRpbiBWaWdvdXJldXgiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWFy
dGluLnZpZ291cmV1eEBub2tpYS5jb20+IHdyb3RlOg0KDQogICAgSGVsbG8NCiAgICANCiAgICBB
cyBwYXJ0IG9mIGEgcmVjZW50IElFU0cgcmV2aWV3IChvZiBkcmFmdC1iZmQteWFuZykgYSBwb2lu
dCBjYW1lIHVwIG9uIA0KICAgIHRoZSB1c2Ugb2YgImlhbmEiIGluIHlhbmcgbW9kdWxlcycgbmFt
ZS9uYW1lc3BhY2UvcHJlZml4Lg0KICAgIFRoaXMgaXMgdHlwaWNhbGx5IHVzZWQgaW4gdGhlIGNh
c2Ugd2hlcmUgdGhlIG1vZHVsZSByZWZlcnMgdG8gYW4gSUFOQSANCiAgICBtYWludGFpbmVkIHJl
Z2lzdHJ5LiBIb3dldmVyLCB0aGUgcG9pbnQgcmFpc2VkIHdhcyB0aGF0IHRoZSBuYW1lIG9mIHRo
ZSANCiAgICByZWdpc3RyeSBvcGVyYXRvciBtaWdodCBub3QgYWx3YXlzIGJlIElBTkEsIGFuZCB0
aGF0IHVzaW5nIHRoYXQgbmFtZSANCiAgICBtaWdodCBub3QgcHV0IG1vZHVsZXMgb24gdGhlIG1v
c3Qgc3RhYmxlIGRlcGxveW1lbnQgZm9vdGluZyB1bmRlciBhbGwgDQogICAgcG9zc2libGUgY2ly
Y3Vtc3RhbmNlcy4NCiAgICANCiAgICBPbiB0b3Agb2YgdGhhdCwgYXMgZmFyIGFzIEkgY2FuIHRl
bGwsIHRoZSB1c2Ugb2YgImlhbmEiIGlzIGFuIA0KICAgIHVuZG9jdW1lbnRlZCBjb252ZW50aW9u
Lg0KICAgIA0KICAgIFNvLCBJIHdhbnRlZCB0byBjb2xsZWN0IHZpZXdzOg0KICAgIG9uIHdoZXRo
ZXIgYSBjb252ZW50aW9uIHNob3VsZCBiZSBkb2N1bWVudGVkLA0KICAgIGFuZCwgd2l0aCByZWdh
cmRzIHRvIHRoZSBwb2ludCByYWlzZWQgaW4gSUVTRywgb24gd2hldGhlciB0aGF0IGtleXdvcmQg
DQogICAgc2hvdWxkIGJlIGNoYW5nZWQgZ29pbmcgZm9yd2FyZC4gSW4gdGhhdCBjb250ZXh0LCB3
aGF0IGFib3V0ICJyZWciIChmb3IgDQogICAgcmVnaXN0cnkpIG9yICJyZWdvcCIgKGZvciByZWdp
c3RyeSBvcGVyYXRvcik/IE90aGVyIHByb3Bvc2FscyBhcmUgd2VsY29tZS4NCiAgICANCiAgICBU
aGFua3MNCiAgICAtbQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRm
Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQog
ICAgDQoNCg==


From nobody Fri Jul 20 07:40:12 2018
Return-Path: 
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 76B1F130EB4 for ; Fri, 20 Jul 2018 07:40:10 -0700 (PDT)
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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 g8UEs9SlcgNZ for ; Fri, 20 Jul 2018 07:40:08 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id BA03A130E0F for ; Fri, 20 Jul 2018 07:40:07 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id E813C2360ADC; Fri, 20 Jul 2018 16:40:06 +0200 (CEST)
Date: Fri, 20 Jul 2018 16:40:06 +0200
From: Juergen Schoenwaelder 
To: Martin Vigoureux 
Cc: netmod@ietf.org
Message-ID: <20180720144006.ybautxifiwwh2xth@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Vigoureux , netmod@ietf.org
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
User-Agent: NeoMutt/20180622
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 14:40:11 -0000

On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
 
> As part of a recent IESG review (of draft-bfd-yang) a point came up on the
> use of "iana" in yang modules' name/namespace/prefix.
> This is typically used in the case where the module refers to an IANA
> maintained registry. However, the point raised was that the name of the
> registry operator might not always be IANA, and that using that name might
> not put modules on the most stable deployment footing under all possible
> circumstances.
> 
> On top of that, as far as I can tell, the use of "iana" is an undocumented
> convention.
> 
> So, I wanted to collect views:
> on whether a convention should be documented,
> and, with regards to the point raised in IESG, on whether that keyword
> should be changed going forward. In that context, what about "reg" (for
> registry) or "regop" (for registry operator)? Other proposals are welcome.

iana- has the advantage that everybody knows which registry is meant.
Using registry- is perhaps more flexible in case IANA registry gets
renamed but it leaves is much more open where the module is
maintained. The first part of a module name is supposed to identify an
organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
says:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules.

Concerning documentation, perhaps we could change the above to this:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
   begin with the prefix "iana-".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Jul 20 08:26:46 2018
Return-Path: 
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 7AE661311D8 for ; Fri, 20 Jul 2018 08:26:37 -0700 (PDT)
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4JIebsJXqag7 for ; Fri, 20 Jul 2018 08:26:35 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 44C7D1310AC for ; Fri, 20 Jul 2018 08:26:33 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A6FE0A0286620 for ; Fri, 20 Jul 2018 16:26:29 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 20 Jul 2018 16:26:30 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Fri, 20 Jul 2018 23:26:25 +0800
From: Qin Wu 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
Thread-Index: AdQgO9aPf9MFKlVCS3ix012Wcdg4yQ==
Date: Fri, 20 Jul 2018 15:26:24 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.124.182.175]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 15:26:43 -0000

QWRkIHR3byBhZGRpdGlvbmFsIHRob3VnaHRzLA0KKDEpIEkgaG9wZSBOTURBIGRhdGFzdG9yZSBj
YW4gYmUgdXNlZCB0byBjb21wYXJlIG9uZSBkYXRhc3RvcmUgYXQgdHdvIGRpZmZlcmVudCB0aW1l
cG9pbnRzLCBzbyBJIGFtIG5vdCBzdXJlIHNvdXJjZSBhbmQgdGFyZ2V0IGRlZmluZWQgaW4gdGhl
IG1vZGVsIGFyZSBlbm91Z2ggdG8gc3VwcG9ydCB0aGlzIGNhc2UuDQooMikgTk1EQSBCYXNlIGV2
ZW50cyBkZWZpbmVkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0
Y29uZi1iYXNlLW5vdGlmaWNhdGlvbi1ubWRhLTAxIGNhbiBsZXZlcmFnZSBOTURBIGRpZmYgdG8g
cGVyZm9ybSBOTURBIGRhdGEgdmFsaWRhdGlvbiwgcmlnaHQgbm93IGl0IGlzIHVwIHRvIHRoZSBz
ZXJ2ZXIgdG8gZGV0ZWN0IHZhbGlkYXRpb24gZXZlbnQsIGJ1dCBub3cgd2UgbWlnaHQgcmVseSBv
biBOTURBIGRpZmYgdG8gZGVjaWRlIHdoaWNoIG9iamVjdCBpcyBtaXNzaW5nLCB3aGF0IGZhaWxl
ZCBvYmplY3RzIGFyZS4gTk1EQSBkaWZmIGJlY29tZXMgYSBnb29kIHRvb2wuDQpPbiB0aGUgb3Ro
ZXIgaGFuZCwgdXNlciBtaWdodCB3YW50IHRvIGtub3cgd2hlbiBhcHBsaWVkIGNvbmZpZ3VyYXRp
b24gc3RhcnQsIHdoZW4gYXBwbGllZCBjb25maWd1cmF0aW9uIGNvbXBsZXRlLCBiYXNlZCBvbiB0
aGlzIHRvIHNlZSB3aGVuIHRvIHBlcmZvcm0gTk1EQSBkaWZmLiBUbyBhZGRyZXNzIHRoaXMsIHdl
IG1pZ2h0IGNvbnNpZGVyIHR3byBvciB0aHJlZSBuZXcgbm90aWZpY2F0aW9ucw0KSW4gdGhlIGRy
YWZ0LXd1LW5ldGNvbmYtYmFzZS1ub3RpZmljYXRpb24tbm1kYS0wMSB0byBoZWxwIHRvIGRlY2lk
ZSB3aGVuIHRvIHVzZSBORE1BIGRpZmYNCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tKQ0Kt6K8
/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKb2UgQ2xh
cmtlDQq3osvNyrG85DogMjAxOMTqN9TCMjDI1SAyMTo1Mg0KytW8/sjLOiBuZXRtb2RAaWV0Zi5v
cmcNCtb3zOI6IFtuZXRtb2RdIFRob3VnaHRzIG9uIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRp
ZmYNCg0KSSBqdXN0IGhhZCBhIGNoYW5jZSB0byBmaW5pc2ggcmVhZGluZyB0aGlzLiAgVGhlIGlu
LXBlcnNvbiBtZWV0aW5nIGdyb3VwIHNlZW1zIHRvIHN0cm9uZ2x5IHN1cHBvcnQgdGhpcyB3b3Jr
LCBhbmQgSSBhZ3JlZS4NCg0KQ29taW5nIGZyb20gYSBzZXJ2aWNlYWJpbGl0eSBzdGFuZHBvaW50
LCBJIGZpbmQgdGhpcyBtaWdodCBzZXJ2ZSBhcyBhIHByZWN1cnNvciB0byBhIFZDUy1saWtlICJi
bGFtZSBsb2ciLiAgV291bGQgaXQgYmUgcmVhc29uYWJsZSB0byBpbmNsdWRlIGlkZW50aWZpZXJz
IGFzIHRvIHdobyAob3Igd2hhdCkgbWFkZSB0aGUgY2hhbmdlIGFuZCB3aGVuPyAgU29ycnkgaWYg
dGhpcyB3YXMgcmFpc2VkIGF0IHRoZSBtaWMgdG9kYXkuICBJIGNhbWUgdG8gdGhlIHJvb20gYSBi
aXQgbGF0ZS4NCg0KSm9lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Fri Jul 20 12:52:44 2018
Return-Path: 
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 A538F131227 for ; Fri, 20 Jul 2018 12:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 eTJ6ly-9q4WS for ; Fri, 20 Jul 2018 12:52:35 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E110213110F for ; Fri, 20 Jul 2018 12:52:34 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id k12-v6so23322166oiw.8 for ; Fri, 20 Jul 2018 12:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O4TkPm+yEc5TIlyZ1WcVupKi0MRAvJuz9q7x9CCS/GM=; b=WPt9eU8GxralkJQH2RSvCZsWKMFinXnJBEiZI2gL44PDIzfscZ4iinEZsm4oy8MC8S wJH6JNrC0k33S2F8qOFrWzKZVZ05jSco0kv6IdRHeyWRgCcdNvBPUhXt/Wm6fcH7dmw5 meor7k6GQDV6jrJuQhWMUgzmhC2U7jzInQUIMq1l/ta+SO4GWAag+jio4GGwO9zOArGR I4N3AspsZY7NLviVeNIMQUq87VD0G76umNxGWmr/9g9u9DKHAKiEQchZEbqKeQABOJjj Hrb5+Iiej0a+cfvv9hKWiS/82omRpYEN32+p43PrKwnhHRLJfttcH5EkesagKW7TtojW 0P3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O4TkPm+yEc5TIlyZ1WcVupKi0MRAvJuz9q7x9CCS/GM=; b=rYn/PEc3kV23lQ+0y/6GOPfSHcyE4Phx5YGbJn5uCrYroqO5bKIwmW5JSAXimfTcXU i+b98k/BAvq+VJKpDH3sFhhdB+pMf5Le0S4hdlOYlhEoiPM6f5+9BS845Gf4ve92+bWh tcvYJ8c92kdNwmDfK73y8uJx1rV56oAte1mfYUsqOP4ICIfpbTCZhSdu8kvViS5TH2LO N2hVbhYQhi4u5luEM5np77dRWh64RSmR5mk9vrNgnslVGz9Nacq3srdRxQOtfOzrmRlV vsmziQ9mWd/048Ql0R8olO6Ox6Z4iyn34f4Zv4GoDM7bXzP8YClR38jNDWDMPbsGfgYa dyWw==
X-Gm-Message-State: AOUpUlGsYtAc6QY3h67M0/IEX0APy65jxZp70+97U27ZtVyYNHROPayD 0yPKr8UKVd807oeu2PObR7GWGrUlZ/A=
X-Google-Smtp-Source: AAOMgpehtu9WYPVa/bvz8SFL9Oe/ofNxrDJK38lwsXhd2gUKTB08k3JbJyHdbV/a9K8eBElGlnO2Bg==
X-Received: by 2002:aca:ef44:: with SMTP id n65-v6mr97436oih.120.1532116354231;  Fri, 20 Jul 2018 12:52:34 -0700 (PDT)
Received: from [100.170.238.171] (md55636d0.tmodns.net. [208.54.86.213]) by smtp.gmail.com with ESMTPSA id r81-v6sm4750365oih.28.2018.07.20.12.52.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 12:52:32 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Mahesh Jethanandani 
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <20180720144006.ybautxifiwwh2xth@anna.jacobs.jacobs-university.de>
Date: Fri, 20 Jul 2018 15:52:31 -0400
Cc: Martin Vigoureux , netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com> <20180720144006.ybautxifiwwh2xth@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder 
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 19:52:43 -0000

Sent from my iPhone

> On Jul 20, 2018, at 10:40 AM, Juergen Schoenwaelder  wrote:
>=20
>> On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
>>=20
>> As part of a recent IESG review (of draft-bfd-yang) a point came up on th=
e
>> use of "iana" in yang modules' name/namespace/prefix.
>> This is typically used in the case where the module refers to an IANA
>> maintained registry. However, the point raised was that the name of the
>> registry operator might not always be IANA, and that using that name migh=
t
>> not put modules on the most stable deployment footing under all possible
>> circumstances.
>>=20
>> On top of that, as far as I can tell, the use of "iana" is an undocumente=
d
>> convention.
>>=20
>> So, I wanted to collect views:
>> on whether a convention should be documented,
>> and, with regards to the point raised in IESG, on whether that keyword
>> should be changed going forward. In that context, what about "reg" (for
>> registry) or "regop" (for registry operator)? Other proposals are welcome=
.
>=20
> iana- has the advantage that everybody knows which registry is meant.
> Using registry- is perhaps more flexible in case IANA registry gets
> renamed but it leaves is much more open where the module is
> maintained. The first part of a module name is supposed to identify an
> organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
> says:
>=20
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules.
>=20
> Concerning documentation, perhaps we could change the above to this:
>=20
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
>   begin with the prefix "iana-".

+1

I agree that the prefix suggests the organization responsible for maintainin=
g the model, something reg- or registry- does not. Two more examples that al=
ready exist are mef- and etsi-. I understand there is the possibility that t=
hat prefix changes, but we then pick a new prefix, if we know what it might b=
e.=20

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jul 20 14:41:40 2018
Return-Path: 
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 28266130E30 for ; Fri, 20 Jul 2018 14:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 msiCF0DoDztq for ; Fri, 20 Jul 2018 14:41:37 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32E712F1A5 for ; Fri, 20 Jul 2018 14:41:36 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id y17-v6so12216533ljy.8 for ; Fri, 20 Jul 2018 14:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wwBZSBOrxx3yv2eTplpZ9QeOBOESCc8RCCw33uQPs9Y=; b=O0EzIn4SRBY1j5eGvPFqR4hIXviw3VgKvNIPJmJn1btJsmplk1GL+TwZy4Wy7vr/0/ VGhgq91c+ciEqZUarP2KCOJyTtM4vnYdBFlY/hm2ZqCrI0fqVyVM/sdXAkd/4Rlw7uF7 C0YRIPG705OoYbST+yyQ+QbUS4CyAyploM9VdeFJyh5EbvmJPu7IFalOQ5ZF1ZMIvXYd k6pBu7ofQfduT4jeAaTr/9lJUyjfOtqB9xdpnXH0b388P0mChgQeogoRPICjm0FRxPZ9 1kMfjp8wHXS3mYBh43ohSlGLx5KDJ0DJbXgzQizu2qeAv9WoaB52Ba30OjesG+pqprZo 7Fvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wwBZSBOrxx3yv2eTplpZ9QeOBOESCc8RCCw33uQPs9Y=; b=RDYawyaWMZb43X7MOCKqAZnVw/kPYGK+0oNZgp6zE7Exdo3QvQj0YIMXBGYxza8KRa 2RWxU6fz5SwxGCVtIKM3K1vEHxOh/YV5LpLY4s5sjR5TM9aEMlqeLbBalK8MKupSHYWo HeQuILlGpEyHHpkFnVFfD5UiM1Rw+oQsv456Ho4z0x0utdzWlduIthpKrLtY3aqXhHpl Q5pALnwhhkqVP3ist7sNvPrMkieWFzw3rswPZ9fkTFYgcBI5fyjdFH+EI0Tm33zMlQ6C 7BjPDb3sTH6B2dIjuh66OlceudRI98B6CW85J7aRhv5i2iN/qC/1vJFQMMZiD//NGcNT F9lg==
X-Gm-Message-State: AOUpUlHBG+8uj7onPgV6ARLmt9QLb5wjS8T6Or5B9YFaT7YzSZBVk6gR bRGNFou/mmdkogoh8FBkdakkJHowUGkzqFOVPK4chBX7S4E=
X-Google-Smtp-Source: AAOMgpfgoi+nzrChQIbODJ23LDcBhaWN54NGkhP+DtndHHwYIUDjWQH8EPZijTIZD4KHd/CysrfmBuWbuTb8V7IKMkQ=
X-Received: by 2002:a2e:97c8:: with SMTP id m8-v6mr2907831ljj.52.1532122894606;  Fri, 20 Jul 2018 14:41:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 14:41:33 -0700 (PDT)
From: Andy Bierman 
Date: Fri, 20 Jul 2018 14:41:33 -0700
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000e2b79e0571752881"
Archived-At: 
Subject: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jul 2018 21:41:39 -0000

--000000000000e2b79e0571752881
Content-Type: text/plain; charset="UTF-8"

Hi,

I strongly object to requirement 3.1:


    3.1  The solution MUST provide a mechanism to allow servers to
            support existing clients in a backward compatible way.



This is not what servers do today at all.
They provide only one version of an implemented module, as specified in RFC
7950.

It is a vendor and operator decision when to upgrade a server such that
non-backward compatible changes are made. They must decide if/when it is ok
based on the client applications in use.

This requirement says you cannot make backward-incompatible changes
which completely contradicts requirements 1.1 and 1.2.

IMO requirement 3.1 should be removed, or change MUST to MAY


Andy

--000000000000e2b79e0571752881
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I strongly object to requirement 3.=
1:


    3.1  The solution MUST provide a mechanism to allow s=
ervers to
            support existing clients in a backward compatible way.


This is not =
what servers do today at all.
They provide only one version of an implem=
ented module, as specified in RFC 7950.

It i=
s a vendor and operator decision when to upgrade a server such that
non-backward compatible changes are made. They must decide if/when it is=
 ok
based on the client applications in use.

=

This requirement says you cannot make backward-incompatible changes
which completely contradicts requirements 1.1 and 1.2.
IMO requirement 3.1 should be removed, or change MUST to MAY


Andy



--000000000000e2b79e0571752881--


From nobody Fri Jul 20 22:46:03 2018
Return-Path: 
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 AB9FF130EE2 for ; Fri, 20 Jul 2018 22:46:01 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 8VMBgzNCTrUy for ; Fri, 20 Jul 2018 22:45:59 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id 19C4D130E37 for ; Fri, 20 Jul 2018 22:45:58 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id BCA052362462; Sat, 21 Jul 2018 07:45:56 +0200 (CEST)
Date: Sat, 21 Jul 2018 07:45:56 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: NetMod WG 
Message-ID: <20180721054556.jvso3jnrqu6ah6eg@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180622
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 05:46:02 -0000

My understanding is that the MUST puts a requirement on the solution
and the rest is an "allow servers", i.e., something that servers may
want to do. (I was against using RFC 2119 keywords in the first place
for this document.)

/js

On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote:
> Hi,
> 
> I strongly object to requirement 3.1:
> 
> 
>     3.1  The solution MUST provide a mechanism to allow servers to
>             support existing clients in a backward compatible way.
> 
> 
> 
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.
> 
> It is a vendor and operator decision when to upgrade a server such that
> non-backward compatible changes are made. They must decide if/when it is ok
> based on the client applications in use.
> 
> This requirement says you cannot make backward-incompatible changes
> which completely contradicts requirements 1.1 and 1.2.
> 
> IMO requirement 3.1 should be removed, or change MUST to MAY
> 
> 
> Andy

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Jul 20 22:49:41 2018
Return-Path: 
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 419E4130E1E for ; Fri, 20 Jul 2018 22:49:39 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 58znHJngKW_U for ; Fri, 20 Jul 2018 22:49:37 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7AD12D949 for ; Fri, 20 Jul 2018 22:49:37 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 795DB2362544; Sat, 21 Jul 2018 07:49:35 +0200 (CEST)
Date: Sat, 21 Jul 2018 07:49:35 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: NetMod WG 
Message-ID: <20180721054935.cgsgpxvnkmnpro6n@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180622
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 05:49:39 -0000

On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote:
> Hi,
> 
> I strongly object to requirement 3.1:
> 
> 
>     3.1  The solution MUST provide a mechanism to allow servers to
>             support existing clients in a backward compatible way.
> 
> 
> 
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.

But today a backwards incompatible change leads to a new module and
you can very well implement two modules if that is reasonable to do in
order to allow clients a transition period.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sat Jul 21 01:48:43 2018
Return-Path: 
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 3FE36130E9B for ; Sat, 21 Jul 2018 01:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 R0VbnOKc-m5v for ; Sat, 21 Jul 2018 01:48:40 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC56130E93 for ; Sat, 21 Jul 2018 01:48:39 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id n96-v6so3293133lfi.1 for ; Sat, 21 Jul 2018 01:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cZPsP6IKCqSlMmIVp4XR80zxPq2p10phDAHON7W08vU=; b=F2WKmELmfwnyQrfp2ewFqEg5jQ0a2Asx8an01NMTb5iGThyVHhJLJCDv2nv+0lF6Td LIM6A/OPK5yfqd/Mkg+j+cJsLoVCTS0RZ3U0paorEkaqXz3JYJq3bZsNjzItiiu47KCN YZJ6Q6u7RfNBvHhbI1vjMKHu+bNjTZ3K9rYx6AqapNtUgN0bKwHXwX6kkJbrRCX+pIsh 0Dag4L0NfUTt9oRb3Enz6it9IeBixyj2gXUOCNyjlgANdsQ+UbD3O1gsACsEdUc85mpr zpGdlZQt+znIMuDO7iK7grwKpRjIdrIDUeYT4bRxz6tDv8LmTNZHe0kOsaH0IOMlf++F rlMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cZPsP6IKCqSlMmIVp4XR80zxPq2p10phDAHON7W08vU=; b=rSe/5m71+mfKcFrYKktKYSI8zApLnJH9zbbzF3PbtWPAq8mWs8K4iYsIIyAvU9+Bco K17W2qlUcBxWV40CkfZv3dWltMW5gwqPIq83mYQoqC8Rj02UcVnd3f8kthxMklK2VHoJ 7AJ3rLV6zis3ZWkYCAn8m7Impt0cCyV4EBXcLW5M2txQ5YEp7V/SYupbbyov+uMY7Vj9 mMTVFMX+XcXRQpkuGfyHET6OAaaRC1jJ3pOOCXdjqMLc2er89MQu6Kkub0nczGQTOKG/ ZP3qTn3tDdm3YneDsXyaQGdOIDAM9W0sysB0nE92+pKi5hlCoZFha8VO4+l3QgKc1AmU cvow==
X-Gm-Message-State: AOUpUlGUVPZYkqUkrEVMS+iK6SV7mTKcyxFibMl+EEoYB3oW3fIpFaRu nZqCHG6SqHqM5xF9V1g/5IQsoNseikYpeSj69VzA6w==
X-Google-Smtp-Source: AAOMgpdAJX6V6SLHtmDCp3h1RiHOGJAmC+kVG6shLZJdaDpkQnQAe2ueuPysmeikAY9i+wilP9uBz9z7GPGJfRJv2HY=
X-Received: by 2002:a19:b598:: with SMTP id g24-v6mr3270355lfk.129.1532162918053;  Sat, 21 Jul 2018 01:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 01:48:37 -0700 (PDT)
In-Reply-To: <20180721054935.cgsgpxvnkmnpro6n@anna.jacobs.jacobs-university.de>
References:  <20180721054935.cgsgpxvnkmnpro6n@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Sat, 21 Jul 2018 01:48:37 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000780a0b05717e7ae6"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 08:48:42 -0000

--000000000000780a0b05717e7ae6
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 20, 2018 at 10:49 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > I strongly object to requirement 3.1:
> >
> >
> >     3.1  The solution MUST provide a mechanism to allow servers to
> >             support existing clients in a backward compatible way.
> >
> >
> >
> > This is not what servers do today at all.
> > They provide only one version of an implemented module, as specified in
> RFC
> > 7950.
>
> But today a backwards incompatible change leads to a new module and
> you can very well implement two modules if that is reasonable to do in
> order to allow clients a transition period.
>


But you can tell the 2 subtrees apart this way.
If I change /foo from a container to a list, then how do you support both
implementations
of container /foo and list /foo at the same time?



>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--000000000000780a0b05717e7ae6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Jul 20, 2018 at 10:49 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bier=
man wrote:

> Hi,

> 

> I strongly object to requirement 3.1:

> 

> 

>=C2=A0 =C2=A0 =C2=A03.1=C2=A0 The solution MUST provide a mechanism to =
allow servers to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support existing client=
s in a backward compatible way.

> 

> 

> 

> This is not what servers do today at all.

> They provide only one version of an implemented module, as specified i=
n RFC

> 7950.



But today a backwards incompatible change leads to a new module and

you can very well implement two modules if that is reasonable to do in

order to allow clients a transition period.

=


But you can tell the 2 subtrees apart this way.
If I change /foo from a container to a list, then how do you support bot=
h implementations
of container /foo and list /foo at the same tim=
e?

=C2=A0



/js

Andy
=C2=A0=




-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--000000000000780a0b05717e7ae6--


From nobody Sat Jul 21 03:12:29 2018
Return-Path: 
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 74670130EA9 for ; Sat, 21 Jul 2018 03:12:27 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 tlo44G-a50Ga for ; Sat, 21 Jul 2018 03:12:25 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 54B25130DDF for ; Sat, 21 Jul 2018 03:12:25 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 7C5D42362EB9; Sat, 21 Jul 2018 12:12:24 +0200 (CEST)
Date: Sat, 21 Jul 2018 12:12:23 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: NetMod WG 
Message-ID: <20180721101223.vg2hipa6ocfhmemy@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References:  <20180721054935.cgsgpxvnkmnpro6n@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180622
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 10:12:28 -0000

On Sat, Jul 21, 2018 at 01:48:37AM -0700, Andy Bierman wrote:
> 
> But you can tell the 2 subtrees apart this way.
> If I change /foo from a container to a list, then how do you support both
> implementations
> of container /foo and list /foo at the same time?
>

Well, all of this is the consequence of moving from the current naming
system (module, path) to (module,path,version). Once we allow
non-backwards compatible changes, then we may have to find ways to
support different versions of a module (i.e, during session
establishment the client selects a version context to work with).

To be clear about my involvement in the versioning design team: I am
personally not convinced that a different versioning scheme is going
to be simpler; certain things that are simple and robust today will
become more complex and fragile. I decided to get involved in order to
point out that moving to a (module,path,version) naming scheme has
many implications since everywhere where we currently use
(module,path) we need to think about now required version context is
coming from. This goes far beyond YANG imports, this impacts likely
protocols, the proposed instance document storage format, NACM rules
may need to be interpreted in a version context etc.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sat Jul 21 03:44:18 2018
Return-Path: 
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 7262A130E6E for ; Sat, 21 Jul 2018 03:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 bLmT213_OZAq for ; Sat, 21 Jul 2018 03:44:14 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0FD130DE8 for ; Sat, 21 Jul 2018 03:44:14 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id v9-v6so13110004ljk.4 for ; Sat, 21 Jul 2018 03:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZJiVvZkuDFZ8uhZcCaa98NssLYoCETfVdRfTfb16vP4=; b=Sv4W9uxT1ihuUr0DJrmcGibNYmKYWqb2QQDhYDEoXb1qgt0dKISA1TMIZshTN2TqeB F4cx2aelzk51gNPZvc+dUQBta4F7K2uv+ivFuULK75onwm2DnvBU2Ka4BbSN3jEs0vKO 8OZ+++hu6eqa2D5cxrWp2ndMt/XsD0qL4hSXKFtekC+CaSbYcWkxDVAEo189PgTNGbF+ uvkX+cB0gQNcgMnHNXxnJkV26q73fmyHorOPVzYk0zfxV7VC+N6MTnFoIj2/sehFmkqg UNoW3tj9BcbEeQtVAUGeW6GG4VOLuGL6VJq/nHW+KFB3Q7rr4tC4NUaOcpKjqeIoJEhT VCGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZJiVvZkuDFZ8uhZcCaa98NssLYoCETfVdRfTfb16vP4=; b=rcRE/9xpFoelx+Ao2/77yH3TU7bmQFhlyI2tI5Y56EeonHd44Eoxhtu3PE7F50iBMa yQn+UicjoGnqo9cwQj7d+STkdfANZz9ZHsuf8YpzfhRsuSiT8jV6dPughTUmhbC+u6Md q8c6/lSfRd0QvSqAd7QTFY+2A7+FEs97v4nlKR9aiZo9+3ggYMf5hmLvXondPQ5aUoi1 FqWfe4VzvM4rDwPsU+Lzg8rXCrb6B+D5opkL3XGHwrWdTanjzZsuij8agnDhoG7TqYp+ 2jZSo/2SCU3Hcff7INs3zRvbHEdKGDENWNLTU82oPDU6x6lQA87dR4fcKzGGasa8Gmjs ZR8A==
X-Gm-Message-State: AOUpUlHb1odF8fUYr4ADl9oP7zkkYzLN82TY4WrPxyEBds2FSNK4f8rZ FSv5Ua+dad8GrfyWCXauL0JiIksG66GVzx5U0qSzJQ==
X-Google-Smtp-Source: AAOMgpeZ+HHYWzLE7VV1wj32Ug9R2Nsn2NPqJ+QBh4wmgwgoUNV9+LMN4uWeG8rKIZunDzXaeik40VibJt9IPNuRrvQ=
X-Received: by 2002:a2e:1dc8:: with SMTP id w69-v6mr4227768lje.110.1532169852641;  Sat, 21 Jul 2018 03:44:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 03:44:11 -0700 (PDT)
In-Reply-To: <20180721101223.vg2hipa6ocfhmemy@anna.jacobs.jacobs-university.de>
References:  <20180721054935.cgsgpxvnkmnpro6n@anna.jacobs.jacobs-university.de>  <20180721101223.vg2hipa6ocfhmemy@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Sat, 21 Jul 2018 03:44:11 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000cd755a057180171b"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 10:44:18 -0000

--000000000000cd755a057180171b
Content-Type: text/plain; charset="UTF-8"

On Sat, Jul 21, 2018 at 3:12 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Jul 21, 2018 at 01:48:37AM -0700, Andy Bierman wrote:
> >
> > But you can tell the 2 subtrees apart this way.
> > If I change /foo from a container to a list, then how do you support both
> > implementations
> > of container /foo and list /foo at the same time?
> >
>
> Well, all of this is the consequence of moving from the current naming
> system (module, path) to (module,path,version). Once we allow
> non-backwards compatible changes, then we may have to find ways to
> support different versions of a module (i.e, during session
> establishment the client selects a version context to work with).
>
> To be clear about my involvement in the versioning design team: I am
> personally not convinced that a different versioning scheme is going
> to be simpler; certain things that are simple and robust today will
> become more complex and fragile. I decided to get involved in order to
> point out that moving to a (module,path,version) naming scheme has
> many implications since everywhere where we currently use
> (module,path) we need to think about now required version context is
> coming from. This goes far beyond YANG imports, this impacts likely
> protocols, the proposed instance document storage format, NACM rules
> may need to be interpreted in a version context etc.
>
>

Supporting multiple concurrent conflicting configuration management models
 is too complicated
and I would expect those interested in tractable solutions will look
elsewhere.


/js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--000000000000cd755a057180171b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Jul 21, 2018 at 3:12 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 21, 2018 at 01:48:37AM -0700, Andy Bierm=
an wrote:

> 

> But you can tell the 2 subtrees apart this way.

> If I change /foo from a container to a list, then how do you support b=
oth

> implementations

> of container /foo and list /foo at the same time?

>



Well, all of this is the consequence of moving from the current naming

system (module, path) to (module,path,version). Once we allow

non-backwards compatible changes, then we may have to find ways to

support different versions of a module (i.e, during session

establishment the client selects a version context to work with).



To be clear about my involvement in the versioning design team: I am

personally not convinced that a different versioning scheme is going

to be simpler; certain things that are simple and robust today will

become more complex and fragile. I decided to get involved in order to

point out that moving to a (module,path,version) naming scheme has

many implications since everywhere where we currently use

(module,path) we need to think about now required version context is

coming from. This goes far beyond YANG imports, this impacts likely

protocols, the proposed instance document storage format, NACM rules

may need to be interpreted in a version context etc.




Supporting multiple concurrent confli=
cting configuration management models =C2=A0is too complicated
an=
d I would expect those interested in tractable solutions will look elsewher=
e.



/js

Andy
=C2=A0=




-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--000000000000cd755a057180171b--


From nobody Sat Jul 21 09:00:21 2018
Return-Path: 
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 7174D130E6B for ; Sat, 21 Jul 2018 09:00:19 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 6gCx-dR-nw50 for ; Sat, 21 Jul 2018 09:00:17 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D8130DD3 for ; Sat, 21 Jul 2018 09:00:17 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id BCA18633EB; Sat, 21 Jul 2018 16:00:16 +0000 (UTC)
References: 
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Andy Bierman 
Cc: NetMod WG 
In-reply-to: 
Date: Sat, 21 Jul 2018 12:00:15 -0400
Message-ID: <87va981svk.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 16:00:20 -0000

As I pointed out at the mic @102 this requirement derives directly from the 1.x requirement of not changing the name of the module/namespace. If you allow for changing the namespace/module name for "major" (i.e., incompatible) changes (i.e., like today) then this 3.1 requirement goes away.

I think the plan is to reword some of these to get closer to the intention which I believe is to allow for smoother transition from one module to the next while making incompatible but mostly non-impacting changes.

Thanks,
Chris.

Andy Bierman  writes:

> Hi,
>
> I strongly object to requirement 3.1:
>
>
>     3.1  The solution MUST provide a mechanism to allow servers to
>             support existing clients in a backward compatible way.
>
>
>
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.
>
> It is a vendor and operator decision when to upgrade a server such that
> non-backward compatible changes are made. They must decide if/when it is ok
> based on the client applications in use.
>
> This requirement says you cannot make backward-incompatible changes
> which completely contradicts requirements 1.1 and 1.2.
>
> IMO requirement 3.1 should be removed, or change MUST to MAY
>
>
> Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Sat Jul 21 09:25:27 2018
Return-Path: 
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 CACE4130DE3 for ; Sat, 21 Jul 2018 09:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 pDo66tZJgyYH for ; Sat, 21 Jul 2018 09:25:23 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD50130DE9 for ; Sat, 21 Jul 2018 09:25:22 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id f1-v6so11877380ljc.9 for ; Sat, 21 Jul 2018 09:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7c+tN8yXZl5rDOjMO9Ek+i2lBs08ZO+yjVXb2ivfv8s=; b=JRUj5rtbJ1kKulsW2FSpvm4OjASWw4R51OCCPLgEMK+qbcXC3xoykCtiOZrQ6eeC1/ ifNYqjCti+6v0Ph2bra1FJ2p2hT7BEmtWf/zT6eoRn29yrxrxP0NEoHA56Az1vqVOiQp SV5mfyn81qEyn5DUaniencEtkPnMw1g3OjGzqaLRtdrGoZhIT6hxv5Gsv3SqwlZRRkyF V8VQZto5wdv5usfm3SVV97ZCuNQPR/kuEDc3dLGut/kATC9mvPj9WVk6n/KXYOuO4LNw X1pRqGt6DyElPgluzVYFlhYiDG7s5In5WuDkJ3948YwEgCQfaCUPhOi8xTa9FzlcGP37 YOEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7c+tN8yXZl5rDOjMO9Ek+i2lBs08ZO+yjVXb2ivfv8s=; b=HJdYmuYz+WisqU74xszsGs8E+zcc2AbpRN2qnB/AsmHTYPTk6pL2DbrwOSkUgjIQ4O 54V0ZIhf4psZr76u215zt86HdWmXBoeK4nvN5tvbYwhruPXIJolb+Y8bAJtBHypYFiqd e3NP46RyghxuYEg73pB4LhIlH28euN0ILInw/bTGuysPDNkdFC5j1QUkiwGFkDkSEEzU YQQRZpKkjMe6lY1fC3dpvZS858t07R8tFT/kAYeoQ4rC8YEwVvklhUqeMOIF4vFNJUVN yLfkDOBWfvDxR+0JE5aZavX5Yx4Cjs5Iuyi245/X5K2Ogwm5MlwDlD+qgH885HuW6Z0G sDYg==
X-Gm-Message-State: AOUpUlFwJL6uTwk5nv2RoQOcWYg/yE5qkv64qfbKdPpsKv1agtJYUSqU rnAArufiwDgBvbjtJ1NH7d/ZUatpgOOwTyCDvG5Jzw==
X-Google-Smtp-Source: AAOMgpdosyfMJUua5Sy/aAvUGpH3S33ZqZb16ZVm4rTvcd9Rq+lUuGCRb3ykLi5VkmNPbuw/RIVji8WnbAlm3dCIweo=
X-Received: by 2002:a2e:4401:: with SMTP id r1-v6mr4821326lja.21.1532190320330;  Sat, 21 Jul 2018 09:25:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 09:25:19 -0700 (PDT)
In-Reply-To: <87va981svk.fsf@chopps.org>
References:  <87va981svk.fsf@chopps.org>
From: Andy Bierman 
Date: Sat, 21 Jul 2018 09:25:19 -0700
Message-ID: 
To: Christian Hopps 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000c59ea1057184db68"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 16:25:26 -0000

--000000000000c59ea1057184db68
Content-Type: text/plain; charset="UTF-8"

On Sat, Jul 21, 2018 at 9:00 AM, Christian Hopps  wrote:

> As I pointed out at the mic @102 this requirement derives directly from
> the 1.x requirement of not changing the name of the module/namespace. If
> you allow for changing the namespace/module name for "major" (i.e.,
> incompatible) changes (i.e., like today) then this 3.1 requirement goes
> away.
>
> I think the plan is to reword some of these to get closer to the intention
> which I believe is to allow for smoother transition from one module to the
> next while making incompatible but mostly non-impacting changes.
>
>
You may find that reality interferes with your requirement.
The term "incompatible" should be a clue.  If the change is genuinely
incompatible
then the underlying system change may be incompatible as well.
Passive operations like  are not a problem, but configuration
datastores
are a problem.  There are good reasons that RFC 7950 says only 1 revision
of a module can be advertised by a server.

There is already a practical solution that is available today.
A vendor can implement the server in a way that allows their customer to
select the appropriate revision for their use-cases and tools environment.

So how does YANG validation work?
There is only 1 instance of .
E.g., i there are 3 versions of module A and 2 versions of module B,
then which versions does module C use for XPath validation that reference
modules A and B?  Is a new version of XPath needed for YANG?

It is possible to make a standard so complicated that nobody implements it.


Thanks,
> Chris.
>
>
Andy


> Andy Bierman  writes:
>
> Hi,
>>
>> I strongly object to requirement 3.1:
>>
>>
>>     3.1  The solution MUST provide a mechanism to allow servers to
>>             support existing clients in a backward compatible way.
>>
>>
>>
>> This is not what servers do today at all.
>> They provide only one version of an implemented module, as specified in
>> RFC
>> 7950.
>>
>> It is a vendor and operator decision when to upgrade a server such that
>> non-backward compatible changes are made. They must decide if/when it is
>> ok
>> based on the client applications in use.
>>
>> This requirement says you cannot make backward-incompatible changes
>> which completely contradicts requirements 1.1 and 1.2.
>>
>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>

--000000000000c59ea1057184db68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Jul 21, 2018 at 9:00 AM, Christian Hopps <=
chopps@chopps.org> wrote:
As I pointed out at t=
he mic @102 this requirement derives directly from the 1.x requirement of n=
ot changing the name of the module/namespace. If you allow for changing the=
 namespace/module name for "major" (i.e., incompatible) changes (=
i.e., like today) then this 3.1 requirement goes away.



I think the plan is to reword some of these to get closer to the intention =
which I believe is to allow for smoother transition from one module to the =
next while making incompatible but mostly non-impacting changes.



You may find that reality interferes w=
ith your requirement.
The term "incompatible" should be=
 a clue.=C2=A0 If the change is genuinely incompatible
then the u=
nderlying system change may be incompatible as well.
Passive oper=
ations like <get> are not a problem, but configuration datastores
are a problem.=C2=A0 There are good reasons that RFC 7950 says only =
1 revision
of a module can be advertised by a server.
<=
br>
There is already a practical solution that is available today=
.
A vendor can implement the server in a way that allows their cu=
stomer to
select the appropriate revision for their use-cases and=
 tools environment.

So how does YANG validation wo=
rk?
There is only 1 instance of <intended>.
E.g.,=
 i there are 3 versions of module A and 2 versions of module B,
t=
hen which versions does module C use for XPath validation that reference
modules A and B?=C2=A0 Is a new version of XPath needed for YANG?

It is possible to make a standard so complicated th=
at nobody implements it.



Thanks,

Chris.



Andy
=C2=A0

Andy Bierman <an=
dy@yumaworks.com> writes:





Hi,



I strongly object to requirement 3.1:





=C2=A0 =C2=A0 3.1=C2=A0 The solution MUST provide a mechanism to allow serv=
ers to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 support existing clients in a bac=
kward compatible way.







This is not what servers do today at all.

They provide only one version of an implemented module, as specified in RFC=


7950.



It is a vendor and operator decision when to upgrade a server such that

non-backward compatible changes are made. They must decide if/when it is ok=


based on the client applications in use.



This requirement says you cannot make backward-incompatible changes

which completely contradicts requirements 1.1 and 1.2.



IMO requirement 3.1 should be removed, or change MUST to MAY





Andy

_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod








--000000000000c59ea1057184db68--


From nobody Sat Jul 21 14:47:51 2018
Return-Path: 
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 F35FD12F1A5 for ; Sat, 21 Jul 2018 14:47:49 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 WtLE_2YHSddL for ; Sat, 21 Jul 2018 14:47:47 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9612426A for ; Sat, 21 Jul 2018 14:47:46 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1F0C7633FD; Sat, 21 Jul 2018 21:47:46 +0000 (UTC)
References:  <87va981svk.fsf@chopps.org> 
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Andy Bierman 
Cc: Christian Hopps , NetMod WG 
In-reply-to: 
Date: Sat, 21 Jul 2018 17:47:45 -0400
Message-ID: <87tvos1cse.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jul 2018 21:47:50 -0000

Perhaps you are mistaking my intention here? I want a simple solution. I advocated for *not* introducing a new major version component. I don't want models changing all the time. I don't believe there is a large need for incompatible changes.

There are actual instances where small perhaps non-disruptive but incompatible changes are required. The example given to me for this type of change was when the original specification had an obvious bug (e.g., a range was incorrectly specified). I think for these there are non-standard solutions (e.g., a server could be configured to map a set (or all) clients to new module name/namespace if the operator/user decides its safe to do so). Naming conventions (e.g., a version suffix) can identify lineage to earlier "major" versions of a module as well.

Joe Clark mentioned one thing to me that I do think is missing and needed in YANG and that is some form of a "import after" so that module designers/users have the ability to select a version of the module that includes additions that have shown up in later revisions. I believe this can utilize the current revision (date) semantics.

It seems one place seeing a lot of "major" changes is with vendor models. I think internal development processes are driving these, and the vendors need to fix these processes, and not just make it easier to push these changes out to the operators/users. I expressed this multiple times to the design team this last week.

Thanks,
Chris.

Andy Bierman  writes:

> On Sat, Jul 21, 2018 at 9:00 AM, Christian Hopps  wrote:
>
>> As I pointed out at the mic @102 this requirement derives directly from
>> the 1.x requirement of not changing the name of the module/namespace. If
>> you allow for changing the namespace/module name for "major" (i.e.,
>> incompatible) changes (i.e., like today) then this 3.1 requirement goes
>> away.
>>
>> I think the plan is to reword some of these to get closer to the intention
>> which I believe is to allow for smoother transition from one module to the
>> next while making incompatible but mostly non-impacting changes.
>>
>>
> You may find that reality interferes with your requirement.
> The term "incompatible" should be a clue.  If the change is genuinely
> incompatible
> then the underlying system change may be incompatible as well.
> Passive operations like  are not a problem, but configuration
> datastores
> are a problem.  There are good reasons that RFC 7950 says only 1 revision
> of a module can be advertised by a server.
>
> There is already a practical solution that is available today.
> A vendor can implement the server in a way that allows their customer to
> select the appropriate revision for their use-cases and tools environment.
>
> So how does YANG validation work?
> There is only 1 instance of .
> E.g., i there are 3 versions of module A and 2 versions of module B,
> then which versions does module C use for XPath validation that reference
> modules A and B?  Is a new version of XPath needed for YANG?
>
> It is possible to make a standard so complicated that nobody implements it.
>
>
> Thanks,
>> Chris.
>>
>>
> Andy
>
>
>> Andy Bierman  writes:
>>
>> Hi,
>>>
>>> I strongly object to requirement 3.1:
>>>
>>>
>>>     3.1  The solution MUST provide a mechanism to allow servers to
>>>             support existing clients in a backward compatible way.
>>>
>>>
>>>
>>> This is not what servers do today at all.
>>> They provide only one version of an implemented module, as specified in
>>> RFC
>>> 7950.
>>>
>>> It is a vendor and operator decision when to upgrade a server such that
>>> non-backward compatible changes are made. They must decide if/when it is
>>> ok
>>> based on the client applications in use.
>>>
>>> This requirement says you cannot make backward-incompatible changes
>>> which completely contradicts requirements 1.1 and 1.2.
>>>
>>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>>
>>>
>>> Andy
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>


From nobody Sun Jul 22 06:54:24 2018
Return-Path: 
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 D04A5130F29 for ; Sun, 22 Jul 2018 06:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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
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 0PIqUSbA2HXu for ; Sun, 22 Jul 2018 06:54:22 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA17130E1D for ; Sun, 22 Jul 2018 06:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1522; q=dns/txt; s=iport; t=1532267661; x=1533477261; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=O/4g06ghRRj4rM6EHRW6Ql3wmDDeuFAY9FnqQjgqqu8=; b=gtioXSVcKKBEBPFNulYLetmw718dXyTYze+h2H9C9DYXI7GRGV6OAYUb OrN0wuz0/C8OFK2fngThRJ2V9QHVDPDHL4axEIt5x4v7a62lFQ6oz1cQ7 PTRSM2y3AA0Y8OwNIBCFYXFaEd4JXCOOqXC9uW1TJkNZX9th5wS9lsoPY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9BAAvi1Rb/5RdJa1cGwEBAQEDAQE?= =?us-ascii?q?BCQEBAYNNY38og36UNoFglWmBegsYC4QDRgKDDCE1FwECAQECAQECbRwMhTc?= =?us-ascii?q?CAQMBASEPAQU2GwsaAiYCAicwBgEMBgIBAYMcAYF/D65vgS6EXYVsBYELh3e?= =?us-ascii?q?BVz+BESeCaoMbAQGEYYJVAoxcjRAJjyoGiCCFUoxMhVWBQwE1gVIzGggbFTu?= =?us-ascii?q?CaYsVhVojMAGPEwEB?=
X-IronPort-AV: E=Sophos;i="5.51,389,1526342400"; d="scan'208";a="146588548"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2018 13:54:21 +0000
Received: from [10.86.252.240] ([10.86.252.240]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id w6MDsKPq027365; Sun, 22 Jul 2018 13:54:20 GMT
To: Martin Vigoureux , netmod@ietf.org
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
From: Benoit Claise 
Message-ID: <0a82c50c-5cec-362d-208e-67d2c136a4bb@cisco.com>
Date: Sun, 22 Jul 2018 09:54:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.86.252.240, [10.86.252.240]
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Jul 2018 13:54:24 -0000

Martin,

I'm wonder whether this is really an important optimization, worth 
changing now, in the hypothetical case that IANA is not called IANA any 
longer in the future?
Right now, "iana" n the YANG module name correctly states what this is about
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
     => "maintained by IANA"
I agree with Jürgen that documenting this in 6087bis is the right way 
forward.

Regards, Benoit.
> Hello
>
> As part of a recent IESG review (of draft-bfd-yang) a point came up on 
> the use of "iana" in yang modules' name/namespace/prefix.
> This is typically used in the case where the module refers to an IANA 
> maintained registry. However, the point raised was that the name of 
> the registry operator might not always be IANA, and that using that 
> name might not put modules on the most stable deployment footing under 
> all possible circumstances.
>
> On top of that, as far as I can tell, the use of "iana" is an 
> undocumented convention.
>
> So, I wanted to collect views:
> on whether a convention should be documented,
> and, with regards to the point raised in IESG, on whether that keyword 
> should be changed going forward. In that context, what about "reg" 
> (for registry) or "regop" (for registry operator)? Other proposals are 
> welcome.
>
> Thanks
> -m
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Sun Jul 22 07:20:20 2018
Return-Path: 
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 DD5D3130F4F for ; Sun, 22 Jul 2018 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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
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 9KQoxO66p_pw for ; Sun, 22 Jul 2018 07:20:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A895130F46 for ; Sun, 22 Jul 2018 07:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3022; q=dns/txt; s=iport; t=1532269216; x=1533478816; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7vpVUh0kK746EuavK8y45W0MokJjKhpwFuZRtS7qQDI=; b=U2i+2J2s+IyRHI0Hjh4+ASSmyIqkina4eC3SEQDBR0EfK8UJ+oApdopg WrnJIv9Upwd769AtJJ1vBwchzy6WPGHrVoZkQqpXRj1q5lwxx6I9mpApS inHT2HCSaZFh4mmEU7Ixx1Opv0rTnIplToryvDGvdJA60OmTEM9/i63+W o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAgCXkVRb/4wNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNNY38oCoN0iASMMoFog12SBIF6CxgLhANGAheCdSE0GAECAQE?= =?us-ascii?q?CAQECbRwMhTcCAQMBASEROhsCAQgaAiYCAgIlCxUQAgQBEoMgAYF/D65qgS6?= =?us-ascii?q?KSQWBC4d3ghaBEScMgl6DGwEBAoRfMYIkAoxcjRAJAo8ujXKRegIRFIEkHTi?= =?us-ascii?q?BUnAVOyoBgj6LFYU+bwGNeIEbAQE?=
X-IronPort-AV: E=Sophos;i="5.51,389,1526342400"; d="scan'208";a="427340616"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2018 14:20:15 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w6MEKEEF007396 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Jul 2018 14:20:15 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 22 Jul 2018 10:20:14 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Sun, 22 Jul 2018 10:20:14 -0400
From: "Acee Lindem (acee)" 
To: Benoit Claise , Martin Vigoureux , "netmod@ietf.org" 
Thread-Topic: [netmod] "iana" in yang modules' name/namespace/prefix
Thread-Index: AQHUIDAKdENQS5PIXkGtPzyGTnThaaSbiagA///ELYA=
Date: Sun, 22 Jul 2018 14:20:14 +0000
Message-ID: <02902781-A915-46CE-9EFB-F1DDCD6B1E3C@cisco.com>
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com> <0a82c50c-5cec-362d-208e-67d2c136a4bb@cisco.com>
In-Reply-To: <0a82c50c-5cec-362d-208e-67d2c136a4bb@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Jul 2018 14:20:18 -0000

SGkgQmVub2l0LCBldCBhbCwgDQpJIGNvdWxkbid0IGFncmVlIG1vcmUuIFRoZSBJRVRGIGhhcyBt
dWNoIG1vcmUgZXhpZ2VudCBpc3N1ZXMgd2l0aCByZXNwZWN0IHRvIFlBTkcgbW9kZWxzIGFuZCB0
aGUgYXR0ZW5kYW50IHByb3RvY29sIGluZnJhc3RydWN0dXJlIHRoYW4gd2hldGhlciBJQU5BIG1p
Z2h0IGdvIGF3YXkgaW4gdGhlIGZ1dHVyZS4gDQpUaGFua3MsDQpBY2VlIA0KDQrvu79PbiA3LzIy
LzE4LCA5OjU0IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlIiA8bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJjbGFpc2U9NDBjaXNjby5jb21AZG1hcmMu
aWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgTWFydGluLA0KICAgIA0KICAgIEknbSB3b25kZXIgd2hl
dGhlciB0aGlzIGlzIHJlYWxseSBhbiBpbXBvcnRhbnQgb3B0aW1pemF0aW9uLCB3b3J0aCANCiAg
ICBjaGFuZ2luZyBub3csIGluIHRoZSBoeXBvdGhldGljYWwgY2FzZSB0aGF0IElBTkEgaXMgbm90
IGNhbGxlZCBJQU5BIGFueSANCiAgICBsb25nZXIgaW4gdGhlIGZ1dHVyZT8NCiAgICBSaWdodCBu
b3csICJpYW5hIiBuIHRoZSBZQU5HIG1vZHVsZSBuYW1lIGNvcnJlY3RseSBzdGF0ZXMgd2hhdCB0
aGlzIGlzIGFib3V0DQogICAgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveWFuZy1w
YXJhbWV0ZXJzL3lhbmctcGFyYW1ldGVycy54aHRtbA0KICAgICAgICAgPT4gIm1haW50YWluZWQg
YnkgSUFOQSINCiAgICBJIGFncmVlIHdpdGggSsO8cmdlbiB0aGF0IGRvY3VtZW50aW5nIHRoaXMg
aW4gNjA4N2JpcyBpcyB0aGUgcmlnaHQgd2F5IA0KICAgIGZvcndhcmQuDQogICAgDQogICAgUmVn
YXJkcywgQmVub2l0Lg0KICAgID4gSGVsbG8NCiAgICA+DQogICAgPiBBcyBwYXJ0IG9mIGEgcmVj
ZW50IElFU0cgcmV2aWV3IChvZiBkcmFmdC1iZmQteWFuZykgYSBwb2ludCBjYW1lIHVwIG9uIA0K
ICAgID4gdGhlIHVzZSBvZiAiaWFuYSIgaW4geWFuZyBtb2R1bGVzJyBuYW1lL25hbWVzcGFjZS9w
cmVmaXguDQogICAgPiBUaGlzIGlzIHR5cGljYWxseSB1c2VkIGluIHRoZSBjYXNlIHdoZXJlIHRo
ZSBtb2R1bGUgcmVmZXJzIHRvIGFuIElBTkEgDQogICAgPiBtYWludGFpbmVkIHJlZ2lzdHJ5LiBI
b3dldmVyLCB0aGUgcG9pbnQgcmFpc2VkIHdhcyB0aGF0IHRoZSBuYW1lIG9mIA0KICAgID4gdGhl
IHJlZ2lzdHJ5IG9wZXJhdG9yIG1pZ2h0IG5vdCBhbHdheXMgYmUgSUFOQSwgYW5kIHRoYXQgdXNp
bmcgdGhhdCANCiAgICA+IG5hbWUgbWlnaHQgbm90IHB1dCBtb2R1bGVzIG9uIHRoZSBtb3N0IHN0
YWJsZSBkZXBsb3ltZW50IGZvb3RpbmcgdW5kZXIgDQogICAgPiBhbGwgcG9zc2libGUgY2lyY3Vt
c3RhbmNlcy4NCiAgICA+DQogICAgPiBPbiB0b3Agb2YgdGhhdCwgYXMgZmFyIGFzIEkgY2FuIHRl
bGwsIHRoZSB1c2Ugb2YgImlhbmEiIGlzIGFuIA0KICAgID4gdW5kb2N1bWVudGVkIGNvbnZlbnRp
b24uDQogICAgPg0KICAgID4gU28sIEkgd2FudGVkIHRvIGNvbGxlY3Qgdmlld3M6DQogICAgPiBv
biB3aGV0aGVyIGEgY29udmVudGlvbiBzaG91bGQgYmUgZG9jdW1lbnRlZCwNCiAgICA+IGFuZCwg
d2l0aCByZWdhcmRzIHRvIHRoZSBwb2ludCByYWlzZWQgaW4gSUVTRywgb24gd2hldGhlciB0aGF0
IGtleXdvcmQgDQogICAgPiBzaG91bGQgYmUgY2hhbmdlZCBnb2luZyBmb3J3YXJkLiBJbiB0aGF0
IGNvbnRleHQsIHdoYXQgYWJvdXQgInJlZyIgDQogICAgPiAoZm9yIHJlZ2lzdHJ5KSBvciAicmVn
b3AiIChmb3IgcmVnaXN0cnkgb3BlcmF0b3IpPyBPdGhlciBwcm9wb3NhbHMgYXJlIA0KICAgID4g
d2VsY29tZS4NCiAgICA+DQogICAgPiBUaGFua3MNCiAgICA+IC1tDQogICAgPg0KICAgID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCiAgICA+IG5ldG1vZEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+IC4NCiAgICA+DQogICAgDQog
ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBu
ZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K


From nobody Sun Jul 22 08:39:01 2018
Return-Path: 
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 DB48A130DD8 for ; Sun, 22 Jul 2018 08:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 VTSIG8m8yRba for ; Sun, 22 Jul 2018 08:38:56 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26E5126F72 for ; Sun, 22 Jul 2018 08:38:55 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id l15-v6so14829849lji.6 for ; Sun, 22 Jul 2018 08:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bwB4c01VfLbn261XYa827rRUjcRohwA0wvTwSI11N8Q=; b=LtB0gpPTVFBa6S97ON6qyl0GBqxTmayOSQThM//rRMep6vkODf3PmnFUmfn/Mqn8R9 Ln3vO/ceBNHn0GEIdM7RcZ0BCO7PDl+HW8LyYRP24jR3zCKYfxxjo8v7f24QyQZgDuGz mdD5PlGoCNUVAnyIQ8AA3NaGK3CeyXcQhPnxB5/WE9UnREMLssqY1c0a8ic3X47xzf98 U77W8axeqZCWSdIM60M9sB3MBFqnin53oIPTi1tFuPbyRKs+mXaOk9y9bA2MMCJnOjnY B6XaTfX3abCTMmHOdz3+BpBxWnb1PFnYr3tHaM59UfQ13+msNw/tY6kXotrDu1KJTPjm XvpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bwB4c01VfLbn261XYa827rRUjcRohwA0wvTwSI11N8Q=; b=cDJr4aCdrADAJn4DKqDO7OTxmoKqjXD9izKZvbP19XgEZElIY4J+yvANQZaOhCGweE PKKU9io2rbO/IFoSandvx3LjCC29lUsPJ6YtfPvt1LLxhV9J8I8BCbCOoaHQ2wH9+TNx /2EiQb5bHOJdIFa5qzZKRpUBXccoROO7G9I5cvvAhRO/+fUgwAX6jI+HsawaRt68Wnfc AcTDafV/ov4fy/K01uuSOpfbWCTpln2ft9cexYbDndXslZV7LelagdnVFW5sjSnX940A g/AWQAY31khxAtqWK7ezoGa41PRCb889jLh0uaBiJ3KUEbeLxhlkDDuShgs6eHFrAaKK 0yzQ==
X-Gm-Message-State: AOUpUlFfaQ8H7+oqKFni4p6Tqg5zdjsmJh/b4EX/6xEJfR4qKeDa//et VnrNDwkztHb4QiGxkClo3maZW3EQfZIr1I1BSC65Sw==
X-Google-Smtp-Source: AAOMgpcnKSsmmUqr3qE+lLbB1QWBxhGNX4LQGt6UifE94tKAQO0NxRvKyyxKSJSOgj6VQXvdGX5tZNXbvjnj+vjUhn8=
X-Received: by 2002:a2e:97c8:: with SMTP id m8-v6mr7167721ljj.52.1532273933743;  Sun, 22 Jul 2018 08:38:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 08:38:52 -0700 (PDT)
In-Reply-To: <02902781-A915-46CE-9EFB-F1DDCD6B1E3C@cisco.com>
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com> <0a82c50c-5cec-362d-208e-67d2c136a4bb@cisco.com> <02902781-A915-46CE-9EFB-F1DDCD6B1E3C@cisco.com>
From: Andy Bierman 
Date: Sun, 22 Jul 2018 08:38:52 -0700
Message-ID: 
To: "Acee Lindem (acee)" 
Cc: Benoit Claise ,  Martin Vigoureux , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000085078a0571985326"
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Jul 2018 15:38:59 -0000

--00000000000085078a0571985326
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

A bit ironic...
We should change the name of an acronym that has been in place since 1988
in order to guard against instability.


Andy


On Sun, Jul 22, 2018 at 7:20 AM, Acee Lindem (acee) <
acee=3D40cisco.com@dmarc.ietf.org> wrote:

> Hi Benoit, et al,
> I couldn't agree more. The IETF has much more exigent issues with respect
> to YANG models and the attendant protocol infrastructure than whether IAN=
A
> might go away in the future.
> Thanks,
> Acee
>
> =EF=BB=BFOn 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" <
> netmod-bounces@ietf.org on behalf of bclaise=3D40cisco.com@dmarc.ietf.org=
>
> wrote:
>
>     Martin,
>
>     I'm wonder whether this is really an important optimization, worth
>     changing now, in the hypothetical case that IANA is not called IANA
> any
>     longer in the future?
>     Right now, "iana" n the YANG module name correctly states what this i=
s
> about
>     https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtm=
l
>          =3D> "maintained by IANA"
>     I agree with J=C3=BCrgen that documenting this in 6087bis is the righ=
t way
>     forward.
>
>     Regards, Benoit.
>     > Hello
>     >
>     > As part of a recent IESG review (of draft-bfd-yang) a point came up
> on
>     > the use of "iana" in yang modules' name/namespace/prefix.
>     > This is typically used in the case where the module refers to an
> IANA
>     > maintained registry. However, the point raised was that the name of
>     > the registry operator might not always be IANA, and that using that
>     > name might not put modules on the most stable deployment footing
> under
>     > all possible circumstances.
>     >
>     > On top of that, as far as I can tell, the use of "iana" is an
>     > undocumented convention.
>     >
>     > So, I wanted to collect views:
>     > on whether a convention should be documented,
>     > and, with regards to the point raised in IESG, on whether that
> keyword
>     > should be changed going forward. In that context, what about "reg"
>     > (for registry) or "regop" (for registry operator)? Other proposals
> are
>     > welcome.
>     >
>     > Thanks
>     > -m
>     >
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org
>     > https://www.ietf.org/mailman/listinfo/netmod
>     > .
>     >
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--00000000000085078a0571985326
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

A bit ironic...
We should=
 change the name of an acronym that has been in place since 1988
=
in order to guard against instability.


<=
div>Andy


On Sun, Jul 22, 2018 at 7:20 AM, Acee Lindem (acee) <acee=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Benoit, et al, 

I couldn't agree more. The IETF has much more exigent issues with respe=
ct to YANG models and the attendant protocol infrastructure than whether IA=
NA might go away in the future. 

Thanks,

Acee 



=EF=BB=BFOn 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise"=
 <netmod-bounces@ietf.org=
 on behalf of bclaise=3D40cis=
co.com@dmarc.ietf.org> wrote:



=C2=A0 =C2=A0 Martin,



=C2=A0 =C2=A0 I'm wonder whether this is really an important optimizati=
on, worth 

=C2=A0 =C2=A0 changing now, in the hypothetical case that IANA is not calle=
d IANA any 

=C2=A0 =C2=A0 longer in the future?

=C2=A0 =C2=A0 Right now, "iana" n the YANG module name correctly =
states what this is about

=C2=A0 =C2=A0 https://www.iana=
.org/assignments/yang-parameters/yang-parameters.xhtml

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> "maintained by IANA"
=C2=A0 =C2=A0 I agree with J=C3=BCrgen that documenting this in 6087bis is =
the right way 

=C2=A0 =C2=A0 forward.



=C2=A0 =C2=A0 Regards, Benoit.

=C2=A0 =C2=A0 > Hello

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > As part of a recent IESG review (of draft-bfd-yang) a po=
int came up on 

=C2=A0 =C2=A0 > the use of "iana" in yang modules' name/na=
mespace/prefix.

=C2=A0 =C2=A0 > This is typically used in the case where the module refe=
rs to an IANA 

=C2=A0 =C2=A0 > maintained registry. However, the point raised was that =
the name of 

=C2=A0 =C2=A0 > the registry operator might not always be IANA, and that=
 using that 

=C2=A0 =C2=A0 > name might not put modules on the most stable deployment=
 footing under 

=C2=A0 =C2=A0 > all possible circumstances.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > On top of that, as far as I can tell, the use of "i=
ana" is an 

=C2=A0 =C2=A0 > undocumented convention.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > So, I wanted to collect views:

=C2=A0 =C2=A0 > on whether a convention should be documented,

=C2=A0 =C2=A0 > and, with regards to the point raised in IESG, on whethe=
r that keyword 

=C2=A0 =C2=A0 > should be changed going forward. In that context, what a=
bout "reg" 

=C2=A0 =C2=A0 > (for registry) or "regop" (for registry operat=
or)? Other proposals are 

=C2=A0 =C2=A0 > welcome.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Thanks

=C2=A0 =C2=A0 > -m

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > _______________________________________________

=C2=A0 =C2=A0 > netmod mailing list

=C2=A0 =C2=A0 > netmod@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/lis=
tinfo/netmod

=C2=A0 =C2=A0 > .

=C2=A0 =C2=A0 >



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 netmod mailing list

=C2=A0 =C2=A0 netmod@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/netmod





_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--00000000000085078a0571985326--


From nobody Sun Jul 22 11:50:46 2018
Return-Path: 
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 ABCC5130FD4 for ; Sun, 22 Jul 2018 11:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JBG6IGj7nJcs for ; Sun, 22 Jul 2018 11:50:41 -0700 (PDT)
Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68B0130FC8 for ; Sun, 22 Jul 2018 11:50:41 -0700 (PDT)
Received: by mail-pl0-x22a.google.com with SMTP id f6-v6so7278160plo.1 for ; Sun, 22 Jul 2018 11:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fxROjRc9+PpefYC9I3rOaehY67V4fJDVf1vE8yAIIoQ=; b=UUyPkDku1dmo/t7vOOYMGEiLWr1SgrVmr8b7bzYvS3Jaz2IyQp4M3poXhgcjrsGQ+7 3cFCNxcSwBMFbiUWd09jvpuwHa2LvXTat9SQ294aQf5UerVThj98seZBvv8QABdYm7LN 6HbAFNM8Z9WkYgU6iNFk2RqyvO2LCndl1fJ42FSlkMlsBB1rdUpEUVxdGkj2fxBs18na JcZwyQVl4qdXQqGe9wX3ZJL7PVcLU752Wk9TRMgTB7YK1beLrke6zf+45vNwvyH/+Z/e bkqqf1TfvvIIkqV5Uds2mGfQhZkrB4Dvv+1GzD1NFKvyYBk+T+fVLoQOQMUR4e2MXEKT s6DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fxROjRc9+PpefYC9I3rOaehY67V4fJDVf1vE8yAIIoQ=; b=AiKDDDSixe9CKzcFPngHQc2nRTr8NWR6NbEGNakppOVtY19QLDWsWrA2sqotagSTZi WxTaTUm+kw+zYC/Svfpngb2+vBrKo0NQcXfj2UJGziY+8g2Rx0XQOsI4buffBSq/nZfN VdI8gzVdvyT7eue3u3rwSq+xT5Y73y+gKARKu3uVPs63Zi1SW9zkv20irwV34HEhcwOh CPDrPKOSR8yl56VyXtsnAyVyzh0ZVKPB1UqnR/E44MpYmiIVxI4BGfENedyJxfq88zqv v9xKjQMpYu3xWQgkMFnWZudaD/KI7UcukwfJ2JNzDWNs11pZ38Q8+DZ/g4qgi6b2n94Y 9viw==
X-Gm-Message-State: AOUpUlFqZAr9BnNyuMsjAXZVHiUGLCChzk2YL3aFL13Lx4R809YEOuwX tv6UAszwmrPpG9YPgVqWy5B82HsG
X-Google-Smtp-Source: AAOMgpcWYv8WtYswiJAX8HFFdYXWZr7X6SnvaMFkWRW1xDp+dFC184VoVMHTv8g75F86ucyi1ovbng==
X-Received: by 2002:a17:902:5381:: with SMTP id c1-v6mr9853880pli.137.1532285440925;  Sun, 22 Jul 2018 11:50:40 -0700 (PDT)
Received: from ?IPv6:2601:640:10e:4512:6966:675f:655d:ba2c? ([2601:640:10e:4512:6966:675f:655d:ba2c]) by smtp.gmail.com with ESMTPSA id c68-v6sm17107368pfj.51.2018.07.22.11.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 11:50:39 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <02902781-A915-46CE-9EFB-F1DDCD6B1E3C@cisco.com>
Date: Sun, 22 Jul 2018 11:50:38 -0700
Cc: Benoit Claise , Martin Vigoureux , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A8E6E7C-6118-403A-8DE8-8182CF11E852@gmail.com>
References: <98a58631-0c57-7ed8-5277-5dcb3ee9dd86@nokia.com> <0a82c50c-5cec-362d-208e-67d2c136a4bb@cisco.com> <02902781-A915-46CE-9EFB-F1DDCD6B1E3C@cisco.com>
To: "Acee Lindem (acee)" 
Archived-At: 
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Jul 2018 18:50:45 -0000

Same here, let=E2=80=99s focus on immediate problems, there are plenty of th=
ose...

Regards,
Jeff

> On Jul 22, 2018, at 07:20, Acee Lindem (acee)  wrote:
>=20
> Hi Benoit, et al,=20
> I couldn't agree more. The IETF has much more exigent issues with respect t=
o YANG models and the attendant protocol infrastructure than whether IANA mi=
ght go away in the future.=20
> Thanks,
> Acee=20
>=20
> =EF=BB=BFOn 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise"  wrote:
>=20
>    Martin,
>=20
>    I'm wonder whether this is really an important optimization, worth=20
>    changing now, in the hypothetical case that IANA is not called IANA any=
=20
>    longer in the future?
>    Right now, "iana" n the YANG module name correctly states what this is a=
bout
>    https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
>         =3D> "maintained by IANA"
>    I agree with J=C3=BCrgen that documenting this in 6087bis is the right w=
ay=20
>    forward.
>=20
>    Regards, Benoit.
>> Hello
>>=20
>> As part of a recent IESG review (of draft-bfd-yang) a point came up on=20=

>> the use of "iana" in yang modules' name/namespace/prefix.
>> This is typically used in the case where the module refers to an IANA=20
>> maintained registry. However, the point raised was that the name of=20
>> the registry operator might not always be IANA, and that using that=20
>> name might not put modules on the most stable deployment footing under=20=

>> all possible circumstances.
>>=20
>> On top of that, as far as I can tell, the use of "iana" is an=20
>> undocumented convention.
>>=20
>> So, I wanted to collect views:
>> on whether a convention should be documented,
>> and, with regards to the point raised in IESG, on whether that keyword=20=

>> should be changed going forward. In that context, what about "reg"=20
>> (for registry) or "regop" (for registry operator)? Other proposals are=20=

>> welcome.
>>=20
>> Thanks
>> -m
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>=20
>=20
>    _______________________________________________
>    netmod mailing list
>    netmod@ietf.org
>    https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jul 23 02:50:34 2018
Return-Path: 
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 5BF04130DEB for ; Mon, 23 Jul 2018 02:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 CgX_2vGaJy5r for ; Mon, 23 Jul 2018 02:50:29 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E39C130DE8 for ; Mon, 23 Jul 2018 02:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1532339429; x=1533549029; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=iPKwsXD49xhUGsmcUkyfboiy6fv5a+zBrb9e0WlmY6I=; b=ZlLawL+UBsE1gBFIn0jJs8yKdehhB1CuulVAQcZ3W35KZD+pwMhvh/MY eODblrMA56Sj1rC6d4fJzUyVXS3pxsrOKxmr89GQK6k/G0iq/0trofibu GXf7HEsc62NUHwNeJ4XlEFihGhHxYvda1KSRPaXVmxI1ThEyNpCHyhjyO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAQDxo1Vb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfgRFtEiiDfohjjV+VUYFmCxgLhANGAoM8OBQBAgEBAgEBAm0?= =?us-ascii?q?cDIU2AQEBAQIBAQEhDwEFNhsJAg4KAgImAgInMAYBDAYCAQEXgwUBgXcID5J?= =?us-ascii?q?Zm0eBLoRdhWoFgQuJTj+BESeCaoMbAQGBSAKDF4JVAogRhEuNEAmPKgaIIIV?= =?us-ascii?q?SjEyFVYFYIYFSMxoIGxU7gmmCTYhIhT8+MI8CAQE?=
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400";  d="scan'208";a="5346238"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 09:50:27 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6N9oQc9022106; Mon, 23 Jul 2018 09:50:27 GMT
To: Christian Hopps , Andy Bierman , NetMod WG 
References:  <87va981svk.fsf@chopps.org>
From: Robert Wilton 
Message-ID: 
Date: Mon, 23 Jul 2018 10:50:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87va981svk.fsf@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 09:50:32 -0000

Hi Chris, Andy,


On 21/07/2018 17:00, Christian Hopps wrote:
> As I pointed out at the mic @102 this requirement derives directly 
> from the 1.x requirement of not changing the name of the 
> module/namespace. If you allow for changing the namespace/module name 
> for "major" (i.e., incompatible) changes (i.e., like today) then this 
> 3.1 requirement goes away.
Not sure that I agree.

I think that you have made an assumption here that the server will 
continue to support both old and new major revision (with different 
name) of the module at the same time.  However, these is nothing in the 
existing YANG upgrade rules that requires that.

Ultimately, there is a choice whether supporting older module versions 
is the servers problem or the clients problem, or perhaps a combination 
of the two.

The aim of requirement 3.1 is to ensure that there is a standard 
mechanism available so that server implementations that want the 
flexibility of supporting older client versions have a standard way of 
doing so.  My intention is that this part of the solution would be 
optional to implement and hence decided by the market, which is why the 
text in the requirement is "to allow servers" rather than "to require 
servers".

Thanks,
Rob


>
> I think the plan is to reword some of these to get closer to the 
> intention which I believe is to allow for smoother transition from one 
> module to the next while making incompatible but mostly non-impacting 
> changes.
>
> Thanks,
> Chris.
>
> Andy Bierman  writes:
>
>> Hi,
>>
>> I strongly object to requirement 3.1:
>>
>>
>>     3.1  The solution MUST provide a mechanism to allow servers to
>>             support existing clients in a backward compatible way.
>>
>>
>>
>> This is not what servers do today at all.
>> They provide only one version of an implemented module, as specified 
>> in RFC
>> 7950.
>>
>> It is a vendor and operator decision when to upgrade a server such that
>> non-backward compatible changes are made. They must decide if/when it 
>> is ok
>> based on the client applications in use.
>>
>> This requirement says you cannot make backward-incompatible changes
>> which completely contradicts requirements 1.1 and 1.2.
>>
>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Mon Jul 23 04:54:49 2018
Return-Path: 
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 659B1130E06 for ; Mon, 23 Jul 2018 04:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jnogvOcIO6-L for ; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C6F130DD4 for ; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id y200-v6so254271lfd.7 for ; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bqvGc9kcnh1Yexbkj3+lufi+gmhi/+xFzVrTUo4708M=; b=z0O118ozCnfJas3njWhI6bvKVa4qW/S5ZuR8HZDW6htI3Mi0wankFmVqwvcBPwJxAd IvTLdq9OO44ZpqmvjgG0tRXdAfM2dLsouyp6KC7QcWscDBnC7fxsgK+/ROwgjM3N4swR fzir/1xHsKhRUSrVqvBmzYZIMpCYeHeJdjnhaYjcbeK12erN1hrETJABWGmmuGUjoarz DFIv3n8zGAf1rk6OquBf6rRQRGcl1KXMIyfpHXqRm4MolQ84hAoJEy/zJLlSINa+aWCZ e0GQOClgNRTHLvw6MUQzqAeergSKIQy8c51SMvbAV/HdsFW6hqoI1e4FdWDebZC8V30g N33g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bqvGc9kcnh1Yexbkj3+lufi+gmhi/+xFzVrTUo4708M=; b=n5UOmfS/t/l2LOWw42XpoIUgXld/kQJzxum1xuzahsnljQQ/jT32WnKV19/CgxuBRR iOtIVTjkKKgb3/0nHOAc/YPLpnF4IyhSDP4EDsEBE+aSY5dhwBnrRd7jOO2NptWxqewU TSVEjf08qe5Jr5Bmc8uvuJY+QAZBVXxmMgRuzatrOaIK1C9JB5uS8mg3HswLwdTgyqxw owfjfYFH93WUEPMxxlRKhb7jkQxEnBmJAImH/D6hHtVW9c0Vts67NL5VoE/slzte4Pvq Q2AU018uVAMxL5Pxh0DYupdHHpaGKiPqszrrb/PRZTgmyA3ooRE31Xt7/UsjuklDqZSs ccIg==
X-Gm-Message-State: AOUpUlEV/LCbt1+qWFquf9diTxZ417Oi61SvGm6tNbRS+UGDn8ROt9g8 F9VsgozuSpAd6Cr7cPuG4+q1pVB9L5PCMjfmOPyoyg==
X-Google-Smtp-Source: AAOMgpdVZNbw3NZ2+rmMkB0k8CH+rFHUcr3zfx4EzblygMih72WQyKZ5BYBQorQuy2O6ooU9y3JsmsR6H6HZqZleygA=
X-Received: by 2002:a19:2043:: with SMTP id g64-v6mr4631386lfg.66.1532346882238;  Mon, 23 Jul 2018 04:54:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 04:54:41 -0700 (PDT)
In-Reply-To: 
References:  <87va981svk.fsf@chopps.org> 
From: Andy Bierman 
Date: Mon, 23 Jul 2018 04:54:41 -0700
Message-ID: 
To: Robert Wilton 
Cc: Christian Hopps , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000096c0540571a94f96"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 11:54:48 -0000

--00000000000096c0540571a94f96
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton  wrote:

> Hi Chris, Andy,
>
>
> On 21/07/2018 17:00, Christian Hopps wrote:
>
>> As I pointed out at the mic @102 this requirement derives directly from
>> the 1.x requirement of not changing the name of the module/namespace. If
>> you allow for changing the namespace/module name for "major" (i.e.,
>> incompatible) changes (i.e., like today) then this 3.1 requirement goes
>> away.
>>
> Not sure that I agree.
>
> I think that you have made an assumption here that the server will
> continue to support both old and new major revision (with different name)
> of the module at the same time.  However, these is nothing in the existing
> YANG upgrade rules that requires that.
>
> Ultimately, there is a choice whether supporting older module versions is
> the servers problem or the clients problem, or perhaps a combination of the
> two.
>
> The aim of requirement 3.1 is to ensure that there is a standard mechanism
> available so that server implementations that want the flexibility of
> supporting older client versions have a standard way of doing so.  My
> intention is that this part of the solution would be optional to implement
> and hence decided by the market, which is why the text in the requirement
> is "to allow servers" rather than "to require servers".
>
>

API versioning is usually done on the message exchanges.
Trying to do the same for datastore contents is not going to work.
You can write the word MUST in all caps as many times as you want,
but that will not change anything.



> Thanks,
> Rob
>

Andy


>
>
>
>> I think the plan is to reword some of these to get closer to the
>> intention which I believe is to allow for smoother transition from one
>> module to the next while making incompatible but mostly non-impacting
>> changes.
>>
>> Thanks,
>> Chris.
>>
>> Andy Bierman  writes:
>>
>> Hi,
>>>
>>> I strongly object to requirement 3.1:
>>>
>>>
>>>     3.1  The solution MUST provide a mechanism to allow servers to
>>>             support existing clients in a backward compatible way.
>>>
>>>
>>>
>>> This is not what servers do today at all.
>>> They provide only one version of an implemented module, as specified in
>>> RFC
>>> 7950.
>>>
>>> It is a vendor and operator decision when to upgrade a server such that
>>> non-backward compatible changes are made. They must decide if/when it is
>>> ok
>>> based on the client applications in use.
>>>
>>> This requirement says you cannot make backward-incompatible changes
>>> which completely contradicts requirements 1.1 and 1.2.
>>>
>>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>>
>>>
>>> Andy
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>>
>

--00000000000096c0540571a94f96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:
Hi Chris, Andy,





On 21/07/2018 17:00, Christian Hopps wrote:



As I pointed out at the mic @102 this requirement derives directly from the=
 1.x requirement of not changing the name of the module/namespace. If you a=
llow for changing the namespace/module name for "major" (i.e., in=
compatible) changes (i.e., like today) then this 3.1 requirement goes away.=




Not sure that I agree.



I think that you have made an assumption here that the server will continue=
 to support both old and new major revision (with different name) of the mo=
dule at the same time.=C2=A0 However, these is nothing in the existing YANG=
 upgrade rules that requires that.



Ultimately, there is a choice whether supporting older module versions is t=
he servers problem or the clients problem, or perhaps a combination of the =
two.



The aim of requirement 3.1 is to ensure that there is a standard mechanism =
available so that server implementations that want the flexibility of suppo=
rting older client versions have a standard way of doing so.=C2=A0 My inten=
tion is that this part of the solution would be optional to implement and h=
ence decided by the market, which is why the text in the requirement is &qu=
ot;to allow servers" rather than "to require servers".




API versioning is usual=
ly done on the message exchanges.
Trying to do the same for datas=
tore contents is not going to work.
You can write the word MUST i=
n all caps as many times as you want,
but that will not change an=
ything.

=C2=A0

Thanks,

Rob

Andy
=C2=A0









I think the plan is to reword some of these to get closer to the intention =
which I believe is to allow for smoother transition from one module to the =
next while making incompatible but mostly non-impacting changes.



Thanks,

Chris.



Andy Bierman <an=
dy@yumaworks.com> writes:





Hi,



I strongly object to requirement 3.1:





=C2=A0=C2=A0=C2=A0 3.1=C2=A0 The solution MUST provide a mechanism to allow=
 servers to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 support =
existing clients in a backward compatible way.







This is not what servers do today at all.

They provide only one version of an implemented module, as specified in RFC=


7950.



It is a vendor and operator decision when to upgrade a server such that

non-backward compatible changes are made. They must decide if/when it is ok=


based on the client applications in use.



This requirement says you cannot make backward-incompatible changes

which completely contradicts requirements 1.1 and 1.2.



IMO requirement 3.1 should be removed, or change MUST to MAY





Andy

_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.











--00000000000096c0540571a94f96--


From nobody Mon Jul 23 06:25:05 2018
Return-Path: 
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 2A90C130DF3 for ; Mon, 23 Jul 2018 06:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 RiCxMv82vyNE for ; Mon, 23 Jul 2018 06:25:01 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C09B130DD0 for ; Mon, 23 Jul 2018 06:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13323; q=dns/txt; s=iport; t=1532352301; x=1533561901; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6G3UnWlimXBI3GsTh0tGt1dJSSt+BsWeAQD2SSyV5bc=; b=OCOPZclePjsO2inAndwqxfr4IqhPDKxeiBkE8Usl+yv8e6CY5AghyFSo sgfkrX1RINTbIqfCE0gjuRKkWG/DEK071ahXv2iTJUrt8Gpk4Hbgn1fVE TZvmA7Sj/dMnhyAPbddA8n5hFTNEQNoulDOGAsYLaeY9zzq78+/yJzreP w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBx1lVb/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfgRFtEiiDfohjjTQskC2FJIFmCxgBCoQDRgKDPjgUAQIBAQI?= =?us-ascii?q?BAQJtHAyFNgEBAQECAQEBIUsLBQsJAhgnAwICJx8RBg0GAgEBF4MFAYF3CA+?= =?us-ascii?q?SbptHgS4fhD6FbAWKWT+BESeCaoMbAQGBSAKDF4JVAogRhEuFHId0CY8qBog?= =?us-ascii?q?ghVKMTIVVgVghJoEsMxoIGxU7gmmBdViISIU/PjCORwEB?=
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400"; d="scan'208,217";a="5352791"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 13:24:58 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6NDOvET016168; Mon, 23 Jul 2018 13:24:57 GMT
To: Andy Bierman 
Cc: Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  
From: Robert Wilton 
Message-ID: 
Date: Mon, 23 Jul 2018 14:24:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9FF4C864440748C42D689175"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 13:25:04 -0000

This is a multi-part message in MIME format.
--------------9FF4C864440748C42D689175
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 23/07/2018 12:54, Andy Bierman wrote:
>
>
> On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton  > wrote:
>
>     Hi Chris, Andy,
>
>
>     On 21/07/2018 17:00, Christian Hopps wrote:
>
>         As I pointed out at the mic @102 this requirement derives
>         directly from the 1.x requirement of not changing the name of
>         the module/namespace. If you allow for changing the
>         namespace/module name for "major" (i.e., incompatible) changes
>         (i.e., like today) then this 3.1 requirement goes away.
>
>     Not sure that I agree.
>
>     I think that you have made an assumption here that the server will
>     continue to support both old and new major revision (with
>     different name) of the module at the same time.  However, these is
>     nothing in the existing YANG upgrade rules that requires that.
>
>     Ultimately, there is a choice whether supporting older module
>     versions is the servers problem or the clients problem, or perhaps
>     a combination of the two.
>
>     The aim of requirement 3.1 is to ensure that there is a standard
>     mechanism available so that server implementations that want the
>     flexibility of supporting older client versions have a standard
>     way of doing so.  My intention is that this part of the solution
>     would be optional to implement and hence decided by the market,
>     which is why the text in the requirement is "to allow servers"
>     rather than "to require servers".
>
>
>
> API versioning is usually done on the message exchanges.
> Trying to do the same for datastore contents is not going to work.
A YANG schema can be considered an API.  Particularly looking at say the 
OpenConfig YANG schema.  I doubt all implementations will store all 
their configuration and operational state in a central place.

> You can write the word MUST in all caps as many times as you want,
> but that will not change anything.

I disagree.  Marking a requirement as a MUST means that requirement has 
to be met for a solution to be considered viable.

I previously had some text in the draft explaining how RFC 2119 text 
translates to evaluating the requirements, but was asked to take it out 
because it is obvious.  Perhaps it should go back in ...

Thanks,
Rob

>     Thanks,
>     Rob
>
>
> Andy
>
>
>
>
>         I think the plan is to reword some of these to get closer to
>         the intention which I believe is to allow for smoother
>         transition from one module to the next while making
>         incompatible but mostly non-impacting changes.
>
>         Thanks,
>         Chris.
>
>         Andy Bierman >
>         writes:
>
>             Hi,
>
>             I strongly object to requirement 3.1:
>
>
>                 3.1  The solution MUST provide a mechanism to allow
>             servers to
>                         support existing clients in a backward
>             compatible way.
>
>
>
>             This is not what servers do today at all.
>             They provide only one version of an implemented module, as
>             specified in RFC
>             7950.
>
>             It is a vendor and operator decision when to upgrade a
>             server such that
>             non-backward compatible changes are made. They must decide
>             if/when it is ok
>             based on the client applications in use.
>
>             This requirement says you cannot make
>             backward-incompatible changes
>             which completely contradicts requirements 1.1 and 1.2.
>
>             IMO requirement 3.1 should be removed, or change MUST to MAY
>
>
>             Andy
>             _______________________________________________
>             netmod mailing list
>             netmod@ietf.org 
>             https://www.ietf.org/mailman/listinfo/netmod
>             
>
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>         
>         .
>
>
>


--------------9FF4C864440748C42D689175
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 23/07/2018 12:54, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Jul 23, 2018 at 2:50 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            
Hi
              Chris, Andy,

              

              

              On 21/07/2018 17:00, Christian Hopps wrote:

              

                As I pointed out at the mic @102 this requirement
                derives directly from the 1.x requirement of not
                changing the name of the module/namespace. If you allow
                for changing the namespace/module name for "major"
                (i.e., incompatible) changes (i.e., like today) then
                this 3.1 requirement goes away.

              

              Not sure that I agree.

              

              I think that you have made an assumption here that the
              server will continue to support both old and new major
              revision (with different name) of the module at the same
              time.  However, these is nothing in the existing YANG
              upgrade rules that requires that.

              

              Ultimately, there is a choice whether supporting older
              module versions is the servers problem or the clients
              problem, or perhaps a combination of the two.

              

              The aim of requirement 3.1 is to ensure that there is a
              standard mechanism available so that server
              implementations that want the flexibility of supporting
              older client versions have a standard way of doing so.  My
              intention is that this part of the solution would be
              optional to implement and hence decided by the market,
              which is why the text in the requirement is "to allow
              servers" rather than "to require servers".

              

            

            


            

            


            

            
API versioning is usually done on the message
              exchanges.

            
Trying to do the same for datastore contents is not
              going to work.

          

        

      

    

    A YANG schema can be considered an API.  Particularly looking at say
    the OpenConfig YANG schema.  I doubt all implementations will store
    all their configuration and operational state in a central place.

    

    

      

        

          

            
You can write the word MUST in all caps as many times
              as you want,

            
but that will not change anything.

          

        

      

    

    

    I disagree.  Marking a requirement as a MUST means that requirement
    has to be met for a solution to be considered viable.

    

    I previously had some text in the draft explaining how RFC 2119 text
    translates to evaluating the requirements, but was asked to take it
    out because it is obvious.  Perhaps it should go back in ...

    

    Thanks,

    Rob

    

    

      

        

          

            
 

            

              Thanks,

              Rob

            

            


            

            
Andy

            
 

            

              

              

              

                

                I think the plan is to reword some of these to get
                closer to the intention which I believe is to allow for
                smoother transition from one module to the next while
                making incompatible but mostly non-impacting changes.

                

                Thanks,

                Chris.

                

                Andy Bierman <andy@yumaworks.com>
                writes:

                

                

                  Hi,

                  

                  I strongly object to requirement 3.1:

                  

                  

                      3.1  The solution MUST provide a mechanism to
                  allow servers to

                              support existing clients in a backward
                  compatible way.

                  

                  

                  

                  This is not what servers do today at all.

                  They provide only one version of an implemented
                  module, as specified in RFC

                  7950.

                  

                  It is a vendor and operator decision when to upgrade a
                  server such that

                  non-backward compatible changes are made. They must
                  decide if/when it is ok

                  based on the client applications in use.

                  

                  This requirement says you cannot make
                  backward-incompatible changes

                  which completely contradicts requirements 1.1 and 1.2.

                  

                  IMO requirement 3.1 should be removed, or change MUST
                  to MAY

                  

                  

                  Andy

                  _______________________________________________

                  netmod mailing list

                  netmod@ietf.org

                  https://www.ietf.org/mailman/listinfo/netmod

                

                

                _______________________________________________

                netmod mailing list

                netmod@ietf.org

                https://www.ietf.org/mailman/listinfo/netmod

                .

                

              

              

            

          

          

        

      

    

    

  


--------------9FF4C864440748C42D689175--


From nobody Mon Jul 23 07:08:11 2018
Return-Path: 
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 88D3712F1AC for ; Mon, 23 Jul 2018 07:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 BlTwXtfEsm-W for ; Mon, 23 Jul 2018 07:08:07 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A572127148 for ; Mon, 23 Jul 2018 07:08:06 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id j19-v6so665356ljc.7 for ; Mon, 23 Jul 2018 07:08:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n9UGgaYu2Kfcph8I7x/9ELK3QUeA58Zq+riJEiw8zuQ=; b=lIVLhxmQvIy/LMmLKh1KIy3SPE+YCcBHA6OgUObF4La+3vsvzwXgLR8oBX14vUupn8 CJHFLVMgERkCkN+443HCQvFl9vZvwKXVZ6XtVe6rR9DZBPBMkXReje3rKd57PIcaBj2v zqx04GjsExwcPtkF2gtlfNjj2o5XSMU29VnBGwMRlI0yY3qnZvt5/SKmGVaTI+l9zN+R oICwMWorNilks4PpBmgQIvrzCW14ee9j/MZWYgYLVRpvoKN2JG8IPExoHR2lNRmrKGFc kkEfaaFMN8iM88BBPOQr0qjqd5DuUApMX2TQM3USLnCmlAlBVJOEOU+gGrEfOKqq/aYD wzpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n9UGgaYu2Kfcph8I7x/9ELK3QUeA58Zq+riJEiw8zuQ=; b=RwOSzilM//UTVD4xpjml5Uequt4+5aKStQXaU+nv4NQwwvYq5HyX5xhk6VV77Mb86q +ZbqgVZ1opNMyVhR7K4UNGojFfABmnKzlsdnr+ZkYroAYdvjjYDvjcyai7Bb8y1J9XsG pvwby2CUuDt7LUkEZQ5Z8ZRur1MecGXVZZC9NwGB41IoXjD51q2ffUWaCyVvpDctLqVi EIAJetCi//17HuJaDkBpI4bgBPgWp/UlQwblBeJpxW51e5UspJuxpKsBvSxuTmUcCG2V NFY3cd9kVU8kBteeGheJR4uzdiNiHh32DRPAy+m51bYECkFBKq/MJNDt35m7ob83G4+/ d3pg==
X-Gm-Message-State: AOUpUlEqYPdylZREMYuGcbzca/FF5A0UP77sWr4BgtB/5W4qlA/EiaNH fzFZox2Pv10icN2aXuKWZja9SFDOjb78LRdTGBbE0vJf
X-Google-Smtp-Source: AAOMgpewQhH/YG4ui4+ooIJ6W4gK0GqHSg6BJy2EsVGyJEs+rQWBtL62k20Y93xdbuU58ifuKdsgVRNC2lWT6PkWPbc=
X-Received: by 2002:a2e:2ac3:: with SMTP id q186-v6mr8769211ljq.123.1532354884555;  Mon, 23 Jul 2018 07:08:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 07:08:03 -0700 (PDT)
In-Reply-To: 
References:  <87va981svk.fsf@chopps.org>   
From: Andy Bierman 
Date: Mon, 23 Jul 2018 07:08:03 -0700
Message-ID: 
To: Robert Wilton 
Cc: Christian Hopps , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000907a1a0571ab2cfe"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 14:08:09 -0000

--000000000000907a1a0571ab2cfe
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton  wrote:

>
>
> On 23/07/2018 12:54, Andy Bierman wrote:
>
>
>
> On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton  wrote:
>
>> Hi Chris, Andy,
>>
>>
>> On 21/07/2018 17:00, Christian Hopps wrote:
>>
>>> As I pointed out at the mic @102 this requirement derives directly from
>>> the 1.x requirement of not changing the name of the module/namespace. If
>>> you allow for changing the namespace/module name for "major" (i.e.,
>>> incompatible) changes (i.e., like today) then this 3.1 requirement goes
>>> away.
>>>
>> Not sure that I agree.
>>
>> I think that you have made an assumption here that the server will
>> continue to support both old and new major revision (with different name)
>> of the module at the same time.  However, these is nothing in the existing
>> YANG upgrade rules that requires that.
>>
>> Ultimately, there is a choice whether supporting older module versions is
>> the servers problem or the clients problem, or perhaps a combination of the
>> two.
>>
>> The aim of requirement 3.1 is to ensure that there is a standard
>> mechanism available so that server implementations that want the
>> flexibility of supporting older client versions have a standard way of
>> doing so.  My intention is that this part of the solution would be optional
>> to implement and hence decided by the market, which is why the text in the
>> requirement is "to allow servers" rather than "to require servers".
>>
>>
>
> API versioning is usually done on the message exchanges.
> Trying to do the same for datastore contents is not going to work.
>
> A YANG schema can be considered an API.  Particularly looking at say the
> OpenConfig YANG schema.  I doubt all implementations will store all their
> configuration and operational state in a central place.
>
> You can write the word MUST in all caps as many times as you want,
> but that will not change anything.
>
>
> I disagree.  Marking a requirement as a MUST means that requirement has to
> be met for a solution to be considered viable.
>
> I previously had some text in the draft explaining how RFC 2119 text
> translates to evaluating the requirements, but was asked to take it out
> because it is obvious.  Perhaps it should go back in ...
>
>
So you can answer the question how YANG validation works when multiple
revisions of a
module are implemented?  I do not doubt that you can find a leaf somewhere
that can
be changed.  Not at all convinced the validation rules can be rewritten to
account
for actual incompatible changes, like changing the type of data node or
replacing nodes
with completely different configuration.  Even less convinced that this
complexity is
worth the cost.



Thanks,
> Rob
>
>
Andy


>
>
>> Thanks,
>> Rob
>>
>
> Andy
>
>
>>
>>
>>
>>> I think the plan is to reword some of these to get closer to the
>>> intention which I believe is to allow for smoother transition from one
>>> module to the next while making incompatible but mostly non-impacting
>>> changes.
>>>
>>> Thanks,
>>> Chris.
>>>
>>> Andy Bierman  writes:
>>>
>>> Hi,
>>>>
>>>> I strongly object to requirement 3.1:
>>>>
>>>>
>>>>     3.1  The solution MUST provide a mechanism to allow servers to
>>>>             support existing clients in a backward compatible way.
>>>>
>>>>
>>>>
>>>> This is not what servers do today at all.
>>>> They provide only one version of an implemented module, as specified in
>>>> RFC
>>>> 7950.
>>>>
>>>> It is a vendor and operator decision when to upgrade a server such that
>>>> non-backward compatible changes are made. They must decide if/when it
>>>> is ok
>>>> based on the client applications in use.
>>>>
>>>> This requirement says you cannot make backward-incompatible changes
>>>> which completely contradicts requirements 1.1 and 1.2.
>>>>
>>>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>>>
>>>>
>>>> Andy
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>>>
>>
>
>

--000000000000907a1a0571ab2cfe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 23/07/2018 12:54=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Jul 23, 2018 at 2:50 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            
Hi
              Chris, Andy,

              

              

              On 21/07/2018 17:00, Christian Hopps wrote:

              

                As I pointed out at the mic @102 this requirement
                derives directly from the 1.x requirement of not
                changing the name of the module/namespace. If you allow
                for changing the namespace/module name for "major"=
;
                (i.e., incompatible) changes (i.e., like today) then
                this 3.1 requirement goes away.

              

              Not sure that I agree.

              

              I think that you have made an assumption here that the
              server will continue to support both old and new major
              revision (with different name) of the module at the same
              time.=C2=A0 However, these is nothing in the existing YANG
              upgrade rules that requires that.

              

              Ultimately, there is a choice whether supporting older
              module versions is the servers problem or the clients
              problem, or perhaps a combination of the two.

              

              The aim of requirement 3.1 is to ensure that there is a
              standard mechanism available so that server
              implementations that want the flexibility of supporting
              older client versions have a standard way of doing so.=C2=A0 =
My
              intention is that this part of the solution would be
              optional to implement and hence decided by the market,
              which is why the text in the requirement is "to allow
              servers" rather than "to require servers".

              

            

            


            

            


            

            
API versioning is usually done on the message
              exchanges.

            
Trying to do the same for datastore contents is not
              going to work.

          

        

      

    

    A YANG schema can be considered an API.=C2=A0 Particularly looking at s=
ay
    the OpenConfig YANG schema.=C2=A0 I doubt all implementations will stor=
e
    all their configuration and operational state in a central place.

    

    

      

        

          

            
You can write the word MUST in all caps as many times
              as you want,

            
but that will not change anything.

          

        

      

    

    

    I disagree.=C2=A0 Marking a requirement as a MUST means that requiremen=
t
    has to be met for a solution to be considered viable.

    

    I previously had some text in the draft explaining how RFC 2119 text
    translates to evaluating the requirements, but was asked to take it
    out because it is obvious.=C2=A0 Perhaps it should go back in ...

    

So you can answer the questi=
on how YANG validation works when multiple revisions of a
module =
are implemented?=C2=A0 I do not doubt that you can find a leaf somewhere th=
at can
be changed.=C2=A0 Not at all convinced the validation rule=
s can be rewritten to account
for actual incompatible changes, li=
ke changing the type of data node or replacing nodes
with complet=
ely different configuration.=C2=A0 Even less convinced that this complexity=
 is
worth the cost.



<=
/div>

    Thanks,

    Rob

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

      

        

          

            
=C2=A0

            

              Thanks,

              Rob

            

            


            

            
Andy

            
=C2=A0

            

              

              

              

                

                I think the plan is to reword some of these to get
                closer to the intention which I believe is to allow for
                smoother transition from one module to the next while
                making incompatible but mostly non-impacting changes.

                

                Thanks,

                Chris.

                

                Andy Bierman <andy@yumaworks.com>
                writes:

                

                

                  Hi,

                  

                  I strongly object to requirement 3.1:

                  

                  

                  =C2=A0=C2=A0=C2=A0 3.1=C2=A0 The solution MUST provide a =
mechanism to
                  allow servers to

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 support existing clients in a backward
                  compatible way.

                  

                  

                  

                  This is not what servers do today at all.

                  They provide only one version of an implemented
                  module, as specified in RFC

                  7950.

                  

                  It is a vendor and operator decision when to upgrade a
                  server such that

                  non-backward compatible changes are made. They must
                  decide if/when it is ok

                  based on the client applications in use.

                  

                  This requirement says you cannot make
                  backward-incompatible changes

                  which completely contradicts requirements 1.1 and 1.2.
                  

                  IMO requirement 3.1 should be removed, or change MUST
                  to MAY

                  

                  

                  Andy

                  _______________________________________________

                  netmod mailing list

                  netm=
od@ietf.org

                  https://www.ietf.org/mailman/list=
info/netmod

                

                

                _______________________________________________

                netmod mailing list

                netmod=
@ietf.org

                https://www.ietf.org/mailman/listin=
fo/netmod

                .

                

              

              

            

          

          

        

      

    

    

  






--000000000000907a1a0571ab2cfe--


From nobody Mon Jul 23 07:32:27 2018
Return-Path: 
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 8C4B9130DC0 for ; Mon, 23 Jul 2018 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 mbLdalSAo8ub for ; Mon, 23 Jul 2018 07:32:22 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B89130E95 for ; Mon, 23 Jul 2018 07:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24075; q=dns/txt; s=iport; t=1532356341; x=1533565941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=d73BfDYH80go9Atj1Gm8bfTZe1fJdytL8loP7Q4L8Qw=; b=HwH4dpRcnOA0lspast54jIzhAHueY0w93ZtR+rpAQYEjHfD/cyXF14cm MEijk/loMM/1h58OeX3dD9vzHJ059clLL9A+dsYNbjWvVAHhM1BCM+HGM 4UZU/YD24H9/iRptK8m+um56aYHOuBVB9/aJScck9RkJ4WdAuEverCRJ0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAgBU5lVb/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfgRFtEiiDfohjjTQIJJVRgWYLGAEKgVSCL0YCgz44FAECAQE?= =?us-ascii?q?CAQECbRwMhTcBAQEDAQEhSwsQCQIYFQsHAwICJx8RBg0GAgEBF4MFAYF/D5J?= =?us-ascii?q?Hm0eBLh+EPoVsBYpZP4ERJwyBYH6DGwEBgRstAlWCQoJVAogRhEuFHId0CY8?= =?us-ascii?q?qBogghVKMTIVVgVghJoEsMxoIGxU7gmmBdViISIU/PjCLfSuCHAEB?=
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400"; d="scan'208,217";a="5295943"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 14:32:18 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6NEWIHX029051; Mon, 23 Jul 2018 14:32:18 GMT
To: Andy Bierman 
Cc: Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>    
From: Robert Wilton 
Message-ID: <44703b8f-ec6b-4853-1ccf-46e1b1f5482c@cisco.com>
Date: Mon, 23 Jul 2018 15:32:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1314DB25D5C13CD6B342F34B"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 14:32:26 -0000

This is a multi-part message in MIME format.
--------------1314DB25D5C13CD6B342F34B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 23/07/2018 15:08, Andy Bierman wrote:
>
>
> On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton  > wrote:
>
>
>
>     On 23/07/2018 12:54, Andy Bierman wrote:
>>
>>
>>     On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton >     > wrote:
>>
>>         Hi Chris, Andy,
>>
>>
>>         On 21/07/2018 17:00, Christian Hopps wrote:
>>
>>             As I pointed out at the mic @102 this requirement derives
>>             directly from the 1.x requirement of not changing the
>>             name of the module/namespace. If you allow for changing
>>             the namespace/module name for "major" (i.e.,
>>             incompatible) changes (i.e., like today) then this 3.1
>>             requirement goes away.
>>
>>         Not sure that I agree.
>>
>>         I think that you have made an assumption here that the server
>>         will continue to support both old and new major revision
>>         (with different name) of the module at the same time.
>>         However, these is nothing in the existing YANG upgrade rules
>>         that requires that.
>>
>>         Ultimately, there is a choice whether supporting older module
>>         versions is the servers problem or the clients problem, or
>>         perhaps a combination of the two.
>>
>>         The aim of requirement 3.1 is to ensure that there is a
>>         standard mechanism available so that server implementations
>>         that want the flexibility of supporting older client versions
>>         have a standard way of doing so.  My intention is that this
>>         part of the solution would be optional to implement and hence
>>         decided by the market, which is why the text in the
>>         requirement is "to allow servers" rather than "to require
>>         servers".
>>
>>
>>
>>     API versioning is usually done on the message exchanges.
>>     Trying to do the same for datastore contents is not going to work.
>     A YANG schema can be considered an API.  Particularly looking at
>     say the OpenConfig YANG schema.  I doubt all implementations will
>     store all their configuration and operational state in a central
>     place.
>
>>     You can write the word MUST in all caps as many times as you want,
>>     but that will not change anything.
>
>     I disagree.  Marking a requirement as a MUST means that
>     requirement has to be met for a solution to be considered viable.
>
>     I previously had some text in the draft explaining how RFC 2119
>     text translates to evaluating the requirements, but was asked to
>     take it out because it is obvious. Perhaps it should go back in ...
>
>
> So you can answer the question how YANG validation works when multiple 
> revisions of a
> module are implemented?

Ok, so the scheme that I was considering is:
  - The device implements only one version of the schema (i.e. probably 
all of the latest modules revisions/versions).

However, the protocols are extended to allow clients to select to use an 
older version set of the modules for that session.  YANG library for 
that session would report the chosen set of modules as "implemented" by 
the server for that session.

The server chooses how many different sets of modules are supported, and 
exactly what module revisions, features are included in each of those 
module sets.  Normally I would expect exact module sets to align with a 
previous software release.  The different module-sets can be exposed via 
YANG library bis.  New RPCs or protocol extensions are required to 
choose which version is being used for the session.

The server then has code to map from the older module set paths to the 
latest version that is "implemented" by the device.  The vast majority 
of the mappings would be trivial mappings of the same value on the same 
path.

This mapping is exactly the same as would have to be done on a client if 
it has to support servers running different revisions.

Not all changes can be mapped, some would have to just fail (perhaps 
could be covered by deviations).

>   I do not doubt that you can find a leaf somewhere that can
> be changed.  Not at all convinced the validation rules can be 
> rewritten to account
> for actual incompatible changes, like changing the type of data node 
> or replacing nodes
> with completely different configuration.
The mapping above will not be perfect in all cases, particularly if keys 
are changes, or support for software is removed, etc.  But they might 
still help.

>   Even less convinced that this complexity is
> worth the cost.

Well the complexity ends up going in the client or the server.  I think 
that this is generally a complex problem to solve.  Operators will 
likely argue that it is better that the complexity goes in the server to 
keep the client simple.  Server vendors will likely argue for the reverse.

Note, that I'm still somewhat open to what the right solution should be 
here.

Thanks,
Rob

>
>
>
>     Thanks,
>     Rob
>
>
> Andy
>
>>         Thanks,
>>         Rob
>>
>>
>>     Andy
>>
>>
>>
>>
>>             I think the plan is to reword some of these to get closer
>>             to the intention which I believe is to allow for smoother
>>             transition from one module to the next while making
>>             incompatible but mostly non-impacting changes.
>>
>>             Thanks,
>>             Chris.
>>
>>             Andy Bierman >             > writes:
>>
>>                 Hi,
>>
>>                 I strongly object to requirement 3.1:
>>
>>
>>                     3.1  The solution MUST provide a mechanism to
>>                 allow servers to
>>                             support existing clients in a backward
>>                 compatible way.
>>
>>
>>
>>                 This is not what servers do today at all.
>>                 They provide only one version of an implemented
>>                 module, as specified in RFC
>>                 7950.
>>
>>                 It is a vendor and operator decision when to upgrade
>>                 a server such that
>>                 non-backward compatible changes are made. They must
>>                 decide if/when it is ok
>>                 based on the client applications in use.
>>
>>                 This requirement says you cannot make
>>                 backward-incompatible changes
>>                 which completely contradicts requirements 1.1 and 1.2.
>>
>>                 IMO requirement 3.1 should be removed, or change MUST
>>                 to MAY
>>
>>
>>                 Andy
>>                 _______________________________________________
>>                 netmod mailing list
>>                 netmod@ietf.org 
>>                 https://www.ietf.org/mailman/listinfo/netmod
>>                 
>>
>>
>>             _______________________________________________
>>             netmod mailing list
>>             netmod@ietf.org 
>>             https://www.ietf.org/mailman/listinfo/netmod
>>             
>>             .
>>
>>
>>
>
>


--------------1314DB25D5C13CD6B342F34B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 23/07/2018 15:08, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Jul 23, 2018 at 6:24 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                

                
On
                  23/07/2018 12:54, Andy Bierman wrote:

                

                

                  


                    


                      
On Mon, Jul 23, 2018 at
                        2:50 AM, Robert Wilton <rwilton@cisco.com>
                        wrote:

                        
Hi Chris, Andy,

                          

                          

                          On 21/07/2018 17:00, Christian Hopps wrote:

                          
 As I pointed
                            out at the mic @102 this requirement derives
                            directly from the 1.x requirement of not
                            changing the name of the module/namespace.
                            If you allow for changing the
                            namespace/module name for "major" (i.e.,
                            incompatible) changes (i.e., like today)
                            then this 3.1 requirement goes away.

                          

                          Not sure that I agree.

                          

                          I think that you have made an assumption here
                          that the server will continue to support both
                          old and new major revision (with different
                          name) of the module at the same time. 
                          However, these is nothing in the existing YANG
                          upgrade rules that requires that.

                          

                          Ultimately, there is a choice whether
                          supporting older module versions is the
                          servers problem or the clients problem, or
                          perhaps a combination of the two.

                          

                          The aim of requirement 3.1 is to ensure that
                          there is a standard mechanism available so
                          that server implementations that want the
                          flexibility of supporting older client
                          versions have a standard way of doing so.  My
                          intention is that this part of the solution
                          would be optional to implement and hence
                          decided by the market, which is why the text
                          in the requirement is "to allow servers"
                          rather than "to require servers".

                          

                        

                        


                        

                        


                        

                        
API versioning is usually done on the
                          message exchanges.

                        
Trying to do the same for datastore
                          contents is not going to work.

                      

                    

                  

                

                A YANG schema can be considered an API.  Particularly
                looking at say the OpenConfig YANG schema.  I doubt all
                implementations will store all their configuration and
                operational state in a central place.

                

                

                  

                    

                      

                        
You can write the word MUST in all caps as
                          many times as you want,

                        
but that will not change anything.

                      

                    

                  

                

                

                I disagree.  Marking a requirement as a MUST means that
                requirement has to be met for a solution to be
                considered viable.

                

                I previously had some text in the draft explaining how
                RFC 2119 text translates to evaluating the requirements,
                but was asked to take it out because it is obvious. 
                Perhaps it should go back in ...

                

              

            

            


            

            
So you can answer the question how YANG validation
              works when multiple revisions of a

            
module are implemented?

          

        

      

    

    

    Ok, so the scheme that I was considering is:

     - The device implements only one version of the schema (i.e.
    probably all of the latest modules revisions/versions).

    

    However, the protocols are extended to allow clients to select to
    use an older version set of the modules for that session.  YANG
    library for that session would report the chosen set of modules as
    "implemented" by the server for that session.

    

    The server chooses how many different sets of modules are supported,
    and exactly what module revisions, features are included in each of
    those module sets.  Normally I would expect exact module sets to
    align with a previous software release.  The different module-sets
    can be exposed via YANG library bis.  New RPCs or protocol
    extensions are required to choose which version is being used for
    the session.

    

    The server then has code to map from the older module set paths to
    the latest version that is "implemented" by the device.  The vast
    majority of the mappings would be trivial mappings of the same value
    on the same path.

    

    This mapping is exactly the same as would have to be done on a
    client if it has to support servers running different revisions.

    

    Not all changes can be mapped, some would have to just fail (perhaps
    could be covered by deviations).

    

    

      

        

          

            
  I do not doubt that you can find a leaf somewhere
              that can

            
be changed.  Not at all convinced the validation rules
              can be rewritten to account

            
for actual incompatible changes, like changing the type
              of data node or replacing nodes

            
with completely different configuration.

          

        

      

    

    The mapping above will not be perfect in all cases, particularly if
    keys are changes, or support for software is removed, etc.  But they
    might still help.

    

    

      

        

          

            
  Even less convinced that this complexity is

            
worth the cost.

          

        

      

    

    

    Well the complexity ends up going in the client or the server.  I
    think that this is generally a complex problem to solve.  Operators
    will likely argue that it is better that the complexity goes in the
    server to keep the client simple.  Server vendors will likely argue
    for the reverse.

    

    Note, that I'm still somewhat open to what the right solution should
    be here.

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            


            

            


            

            

              
 Thanks,

                Rob

                

              

            

            


            

            
Andy

            
 

            

              

                

                  

                    

                      

                        
 

                        
 Thanks,

                          Rob

                        

                        


                        

                        
Andy

                        
 

                        
 

                          

                          
 

                            I think the plan is to reword some of these
                            to get closer to the intention which I
                            believe is to allow for smoother transition
                            from one module to the next while making
                            incompatible but mostly non-impacting
                            changes.

                            

                            Thanks,

                            Chris.

                            

                            Andy Bierman <andy@yumaworks.com>
                            writes:

                            

                            
 Hi,

                              

                              I strongly object to requirement 3.1:

                              

                              

                                  3.1  The solution MUST provide a
                              mechanism to allow servers to

                                          support existing clients in a
                              backward compatible way.

                              

                              

                              

                              This is not what servers do today at all.

                              They provide only one version of an
                              implemented module, as specified in RFC

                              7950.

                              

                              It is a vendor and operator decision when
                              to upgrade a server such that

                              non-backward compatible changes are made.
                              They must decide if/when it is ok

                              based on the client applications in use.

                              

                              This requirement says you cannot make
                              backward-incompatible changes

                              which completely contradicts requirements
                              1.1 and 1.2.

                              

                              IMO requirement 3.1 should be removed, or
                              change MUST to MAY

                              

                              

                              Andy

                              _______________________________________________

                              netmod mailing list

                              netmod@ietf.org

                              https://www.ietf.org/mailman/listinfo/netmod

                            

                            

                            _______________________________________________

                            netmod mailing list

                            netmod@ietf.org

                            https://www.ietf.org/mailman/listinfo/netmod

                            .

                            

                          

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------1314DB25D5C13CD6B342F34B--


From nobody Mon Jul 23 11:46:39 2018
Return-Path: 
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 C882D130E0D for ; Mon, 23 Jul 2018 11:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 TCo7uzsOcVLE for ; Mon, 23 Jul 2018 11:46:35 -0700 (PDT)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A1C130DD9 for ; Mon, 23 Jul 2018 11:46:34 -0700 (PDT)
Received: by mail-lf1-x143.google.com with SMTP id g6-v6so1196393lfb.11 for ; Mon, 23 Jul 2018 11:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7B+QmjLHzxtfZcBRF0P4pGPOaRlfspP9wkKW7shxahA=; b=f8T92TLBkW004mZXud8tU9sdVi+hHlFrA3Jvc3LL4YVnLXGCO+G2W/+3r4PulCgO7F nHRyT4/9v9Jllg5NdK1bKe4Mfu4k09W/Z4Dmem86mB3W28GkiiaB2bgwsu/UdJ0li7bw zP7xtxZDCyJsBoKmlTkoionBYfoI1fuDtdfdzjiPCyJ/3AntgB22wIPuosBmMjeRJjgs R23H+um2UXSkFU30yrKRgLQiG+IZlLXwCxIcRd0E5mpkvp2lbZWiKx7X8bwpT+iDJF2H eb/T8igAAENnDTdw6ndg+lkRaMlCNMnv6UFXvRw4dRk/9GzgJ+K1kUKlqFMbVxFY8GbH 6+wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7B+QmjLHzxtfZcBRF0P4pGPOaRlfspP9wkKW7shxahA=; b=NiEP1GS2/ZdAvyJpwovhIUqxcy7A0MmCnXsJK7yP2zJGgWyGunerXfEVqJuiaVnsW+ n/rCjD5IorrWf5auCx4JfPOQS29X9495YV9zBRBVIs3faAVlrLOFymq+lrC38KazWz3I UBB3KRBBOJCPlU3K1tyNkZfcVyaNAkzQMwlZJWfkMzrchbaLQbz/fUlb2JVJE1wRvZtr 6AUCi6VprnvuLyEUyrgG+eYIJuT38ZUDHUM/Vp8devk+ltZ6sjtBSIUrgvHrGCG8N2CE OTegOYBvPF3sPQr5ikcJkiqnJR/NxHTIAx/l58PzR1DS2dtre6iNWG4qw9uEwdIqFFZ0 iv9A==
X-Gm-Message-State: AOUpUlEWifKTdneTVlqchqj7CeOMRG94Cr6D4XRwoJ1sXtciKIBtUswD qaxuQmytKFxxSQAzzk9OeXjFM6887W2uBZ17Q5cd5g==
X-Google-Smtp-Source: AAOMgpdXLzW9BRLNvc4i0W/j/LI3cyoQCb6U7k5jm6jPrLMBs1PAeWdvf5+8C1JXVmtD7b8xlWAvgIMgf/pDAGuPJ/s=
X-Received: by 2002:a19:1460:: with SMTP id k93-v6mr7835573lfi.15.1532371592618;  Mon, 23 Jul 2018 11:46:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 11:46:31 -0700 (PDT)
In-Reply-To: <44703b8f-ec6b-4853-1ccf-46e1b1f5482c@cisco.com>
References:  <87va981svk.fsf@chopps.org>     <44703b8f-ec6b-4853-1ccf-46e1b1f5482c@cisco.com>
From: Andy Bierman 
Date: Mon, 23 Jul 2018 11:46:31 -0700
Message-ID: 
To: Robert Wilton 
Cc: Christian Hopps , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000713a7e0571af10e3"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jul 2018 18:46:38 -0000

--000000000000713a7e0571af10e3
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 23, 2018 at 7:32 AM, Robert Wilton  wrote:

>
>
> On 23/07/2018 15:08, Andy Bierman wrote:
>
>
>
> On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton  wrote:
>
>>
>>
>> On 23/07/2018 12:54, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton  wrote:
>>
>>> Hi Chris, Andy,
>>>
>>>
>>> On 21/07/2018 17:00, Christian Hopps wrote:
>>>
>>>> As I pointed out at the mic @102 this requirement derives directly from
>>>> the 1.x requirement of not changing the name of the module/namespace. If
>>>> you allow for changing the namespace/module name for "major" (i.e.,
>>>> incompatible) changes (i.e., like today) then this 3.1 requirement goes
>>>> away.
>>>>
>>> Not sure that I agree.
>>>
>>> I think that you have made an assumption here that the server will
>>> continue to support both old and new major revision (with different name)
>>> of the module at the same time.  However, these is nothing in the existing
>>> YANG upgrade rules that requires that.
>>>
>>> Ultimately, there is a choice whether supporting older module versions
>>> is the servers problem or the clients problem, or perhaps a combination of
>>> the two.
>>>
>>> The aim of requirement 3.1 is to ensure that there is a standard
>>> mechanism available so that server implementations that want the
>>> flexibility of supporting older client versions have a standard way of
>>> doing so.  My intention is that this part of the solution would be optional
>>> to implement and hence decided by the market, which is why the text in the
>>> requirement is "to allow servers" rather than "to require servers".
>>>
>>>
>>
>> API versioning is usually done on the message exchanges.
>> Trying to do the same for datastore contents is not going to work.
>>
>> A YANG schema can be considered an API.  Particularly looking at say the
>> OpenConfig YANG schema.  I doubt all implementations will store all their
>> configuration and operational state in a central place.
>>
>> You can write the word MUST in all caps as many times as you want,
>> but that will not change anything.
>>
>>
>> I disagree.  Marking a requirement as a MUST means that requirement has
>> to be met for a solution to be considered viable.
>>
>> I previously had some text in the draft explaining how RFC 2119 text
>> translates to evaluating the requirements, but was asked to take it out
>> because it is obvious.  Perhaps it should go back in ...
>>
>>
> So you can answer the question how YANG validation works when multiple
> revisions of a
> module are implemented?
>
>
> Ok, so the scheme that I was considering is:
>  - The device implements only one version of the schema (i.e. probably all
> of the latest modules revisions/versions).
>
> However, the protocols are extended to allow clients to select to use an
> older version set of the modules for that session.  YANG library for that
> session would report the chosen set of modules as "implemented" by the
> server for that session.
>
> The server chooses how many different sets of modules are supported, and
> exactly what module revisions, features are included in each of those
> module sets.  Normally I would expect exact module sets to align with a
> previous software release.  The different module-sets can be exposed via
> YANG library bis.  New RPCs or protocol extensions are required to choose
> which version is being used for the session.
>
> The server then has code to map from the older module set paths to the
> latest version that is "implemented" by the device.  The vast majority of
> the mappings would be trivial mappings of the same value on the same path.
>
> This mapping is exactly the same as would have to be done on a client if
> it has to support servers running different revisions.
>
> Not all changes can be mapped, some would have to just fail (perhaps could
> be covered by deviations).
>
>   I do not doubt that you can find a leaf somewhere that can
> be changed.  Not at all convinced the validation rules can be rewritten to
> account
> for actual incompatible changes, like changing the type of data node or
> replacing nodes
> with completely different configuration.
>
> The mapping above will not be perfect in all cases, particularly if keys
> are changes, or support for software is removed, etc.  But they might still
> help.
>
>   Even less convinced that this complexity is
> worth the cost.
>
>
> Well the complexity ends up going in the client or the server.  I think
> that this is generally a complex problem to solve.  Operators will likely
> argue that it is better that the complexity goes in the server to keep the
> client simple.  Server vendors will likely argue for the reverse.
>
> Note, that I'm still somewhat open to what the right solution should be
> here.
>

Sounds very complicated to implement in the server, but at least you avoid
multiple variants of a datastore.
Instead the server is providing various transformations between data models.

This will make the standards much more complicated and heavyweight to
implement.
If it was so easy and so important, vendors would already support it in
their proprietary APIs.
Instead vendors decide when to end-of-life products and features.



> Thanks,
> Rob
>

Andy


>
>
>
>
> Thanks,
>> Rob
>>
>>
> Andy
>
>
>>
>>
>>> Thanks,
>>> Rob
>>>
>>
>> Andy
>>
>>
>>>
>>>
>>>
>>>> I think the plan is to reword some of these to get closer to the
>>>> intention which I believe is to allow for smoother transition from one
>>>> module to the next while making incompatible but mostly non-impacting
>>>> changes.
>>>>
>>>> Thanks,
>>>> Chris.
>>>>
>>>> Andy Bierman  writes:
>>>>
>>>> Hi,
>>>>>
>>>>> I strongly object to requirement 3.1:
>>>>>
>>>>>
>>>>>     3.1  The solution MUST provide a mechanism to allow servers to
>>>>>             support existing clients in a backward compatible way.
>>>>>
>>>>>
>>>>>
>>>>> This is not what servers do today at all.
>>>>> They provide only one version of an implemented module, as specified
>>>>> in RFC
>>>>> 7950.
>>>>>
>>>>> It is a vendor and operator decision when to upgrade a server such that
>>>>> non-backward compatible changes are made. They must decide if/when it
>>>>> is ok
>>>>> based on the client applications in use.
>>>>>
>>>>> This requirement says you cannot make backward-incompatible changes
>>>>> which completely contradicts requirements 1.1 and 1.2.
>>>>>
>>>>> IMO requirement 3.1 should be removed, or change MUST to MAY
>>>>>
>>>>>
>>>>> Andy
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> .
>>>>
>>>>
>>>
>>
>>
>
>

--000000000000713a7e0571af10e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Jul 23, 2018 at 7:32 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 23/07/2018 15:08=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Jul 23, 2018 at 6:24 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                

                
On
                  23/07/2018 12:54, Andy Bierman wrote:

                

                

                  


                    


                      
On Mon, Jul 23, 2018 at
                        2:50 AM, Robert Wilton <rwilton@cisco.com><=
/span>
                        wrote:

                        
Hi Chris, Andy,

                          

                          

                          On 21/07/2018 17:00, Christian Hopps wrote:

                          
 As I pointed
                            out at the mic @102 this requirement derives
                            directly from the 1.x requirement of not
                            changing the name of the module/namespace.
                            If you allow for changing the
                            namespace/module name for "major" (i.=
e.,
                            incompatible) changes (i.e., like today)
                            then this 3.1 requirement goes away.

                          

                          Not sure that I agree.

                          

                          I think that you have made an assumption here
                          that the server will continue to support both
                          old and new major revision (with different
                          name) of the module at the same time.=C2=A0
                          However, these is nothing in the existing YANG
                          upgrade rules that requires that.

                          

                          Ultimately, there is a choice whether
                          supporting older module versions is the
                          servers problem or the clients problem, or
                          perhaps a combination of the two.

                          

                          The aim of requirement 3.1 is to ensure that
                          there is a standard mechanism available so
                          that server implementations that want the
                          flexibility of supporting older client
                          versions have a standard way of doing so.=C2=A0 M=
y
                          intention is that this part of the solution
                          would be optional to implement and hence
                          decided by the market, which is why the text
                          in the requirement is "to allow servers"=
;
                          rather than "to require servers".

                          

                        

                        


                        

                        


                        

                        
API versioning is usually done on the
                          message exchanges.

                        
Trying to do the same for datastore
                          contents is not going to work.

                      

                    

                  

                

                A YANG schema can be considered an API.=C2=A0 Particularly
                looking at say the OpenConfig YANG schema.=C2=A0 I doubt al=
l
                implementations will store all their configuration and
                operational state in a central place.

                

                

                  

                    

                      

                        
You can write the word MUST in all caps as
                          many times as you want,

                        
but that will not change anything.

                      

                    

                  

                

                

                I disagree.=C2=A0 Marking a requirement as a MUST means tha=
t
                requirement has to be met for a solution to be
                considered viable.

                

                I previously had some text in the draft explaining how
                RFC 2119 text translates to evaluating the requirements,
                but was asked to take it out because it is obvious.=C2=A0
                Perhaps it should go back in ...

                

              

            

            


            

            
So you can answer the question how YANG validation
              works when multiple revisions of a

            
module are implemented?

          

        

      

    

    

    Ok, so the scheme that I was considering is:

    =C2=A0- The device implements only one version of the schema (i.e.
    probably all of the latest modules revisions/versions).

    

    However, the protocols are extended to allow clients to select to
    use an older version set of the modules for that session.=C2=A0 YANG
    library for that session would report the chosen set of modules as
    "implemented" by the server for that session.

    

    The server chooses how many different sets of modules are supported,
    and exactly what module revisions, features are included in each of
    those module sets.=C2=A0 Normally I would expect exact module sets to
    align with a previous software release.=C2=A0 The different module-sets
    can be exposed via YANG library bis.=C2=A0 New RPCs or protocol
    extensions are required to choose which version is being used for
    the session.

    

    The server then has code to map from the older module set paths to
    the latest version that is "implemented" by the device.=C2=A0=
 The vast
    majority of the mappings would be trivial mappings of the same value
    on the same path.

    

    This mapping is exactly the same as would have to be done on a
    client if it has to support servers running different revisions.

    

    Not all changes can be mapped, some would have to just fail (perhaps
    could be covered by deviations).

    

    

      

        

          

            
=C2=A0 I do not doubt that you can find a leaf somewhere
              that can

            
be changed.=C2=A0 Not at all convinced the validation rule=
s
              can be rewritten to account

            
for actual incompatible changes, like changing the type
              of data node or replacing nodes

            
with completely different configuration.

          

        

      

    

    The mapping above will not be perfect in all cases, particularly if
    keys are changes, or support for software is removed, etc.=C2=A0 But th=
ey
    might still help.

    

    

      

        

          

            
=C2=A0 Even less convinced that this complexity is

            
worth the cost.

          

        

      

    

    

    Well the complexity ends up going in the client or the server.=C2=A0 I
    think that this is generally a complex problem to solve.=C2=A0 Operator=
s
    will likely argue that it is better that the complexity goes in the
    server to keep the client simple.=C2=A0 Server vendors will likely argu=
e
    for the reverse.

    

    Note, that I'm still somewhat open to what the right solution shoul=
d
    be here.

Sounds very complica=
ted to implement in the server, but at least you avoid multiple variants of=
 a datastore.
Instead the server is providing various transformat=
ions between data models.

This will make the stand=
ards much more complicated and heavyweight to implement.
If it wa=
s so easy and so important, vendors would already support it in their propr=
ietary APIs.
Instead vendors decide when to end-of-life products =
and features.



    

    Thanks,

    Rob

Andy
=C2=A0

    

    

      

        

          

            


            

            


            

            


            

            

              
 Thanks,

                Rob

                

              

            

            


            

            
Andy

            
=C2=A0

            

              

                

                  

                    

                      

                        
=C2=A0

                        
 Thanks,

                          Rob

                        

                        


                        

                        
Andy

                        
=C2=A0

                        
 

                          

                          
 

                            I think the plan is to reword some of these
                            to get closer to the intention which I
                            believe is to allow for smoother transition
                            from one module to the next while making
                            incompatible but mostly non-impacting
                            changes.

                            

                            Thanks,

                            Chris.

                            

                            Andy Bierman <andy@yumaworks.com>
                            writes:

                            

                            
 Hi,

                              

                              I strongly object to requirement 3.1:

                              

                              

                              =C2=A0=C2=A0=C2=A0 3.1=C2=A0 The solution MUS=
T provide a
                              mechanism to allow servers to

                              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 support existing clients in a
                              backward compatible way.

                              

                              

                              

                              This is not what servers do today at all.

                              They provide only one version of an
                              implemented module, as specified in RFC

                              7950.

                              

                              It is a vendor and operator decision when
                              to upgrade a server such that

                              non-backward compatible changes are made.
                              They must decide if/when it is ok

                              based on the client applications in use.

                              

                              This requirement says you cannot make
                              backward-incompatible changes

                              which completely contradicts requirements
                              1.1 and 1.2.

                              

                              IMO requirement 3.1 should be removed, or
                              change MUST to MAY

                              

                              

                              Andy

                              ________________________________________=
_______

                              netmod mailing list

                              netmod@ietf.org

                              https://www.ietf.org/mailm=
an/listinfo/netmod

                            

                            

                            __________________________________________=
_____

                            netmod mailing list

                            netmod@ietf.org

                            https://www.ietf.org/mailman=
/listinfo/netmod

                            .

                            

                          

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  






--000000000000713a7e0571af10e3--


From nobody Mon Jul 23 17:25:50 2018
Return-Path: 
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 76582130E3C for ; Mon, 23 Jul 2018 17:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level: 
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 DV9xa-tcv383 for ; Mon, 23 Jul 2018 17:25:44 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 AE7B412F18C for ; Mon, 23 Jul 2018 17:25:44 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6O0O691023207; Mon, 23 Jul 2018 17:25:42 -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 : mime-version; s=PPS1017; bh=pYCHNdOD7cP0YsyVL1WGg/PyMUMESubCsrPdupEQ2tU=; b=1/n/nvx/DMKFhOprkDMuilB+XkTXuplhRDAXMrPVVoxAeE/ZH1na5SNmPZORQ7jzwmWE g0A5pZU76J4FRZ8gBjcThe32aRqasDmOlTmSjUFrMuJI4QNlW6ekB6f0U4k4E4Qj1ifM 9QBcdqS6z3QzZ1fczY9SktT1Rwfyg+TGEfcrtXukPwDQPBX2kHbGLnvf8gBV3colSLbz u7c3l62w4vZyQlP9nGSYuA8KPcYixwzJtco/iwkbyQy+77sohlGxttKHdWU+8WBR+VsY U+LxesQqP3FrlUsysgBP4CEtgONF9jvG6kKFXRu2Nj3pf1lr/lt0/BkcnPkPwNJe//wd 7Q== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) by mx0a-00273201.pphosted.com with ESMTP id 2kda571mhy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Jul 2018 17:25:42 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB3975.namprd05.prod.outlook.com (52.135.196.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.9; Tue, 24 Jul 2018 00:25:38 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416%2]) with mapi id 15.20.0995.014; Tue, 24 Jul 2018 00:25:38 +0000
From: Kent Watsen 
To: Andy Bierman , Robert Wilton 
CC: NetMod WG 
Thread-Topic: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
Thread-Index: AQHUIHJ31DW+ryPtaESmByU8ep0YbaSZ1u6AgAK9VgCAACK3gIAAGTmAgAAMCoCAAAbHAIAARweAgAAbsIA=
Date: Tue, 24 Jul 2018 00:25:38 +0000
Message-ID: <23F07D1B-2816-457A-89DD-BD457F77889E@juniper.net>
References:  <87va981svk.fsf@chopps.org>     <44703b8f-ec6b-4853-1ccf-46e1b1f5482c@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB3975; 6:r/roWcZ5CulRbrRj9kfxQhWIXWgV8Z8myGytwa2s4qbAKx+KvHobBLOaPmC75TbfapefLPMF4wNWuXWYxuBHqeJwFdWz6O27iuqoYM6svs24mmUImKcnSWWMYJEjyaBpyTkDTV/RBnRtLIc00KjSgUKHER0rZmqzFwqu7jOMuWBfJjWUrVFwe3fAYWSU4qAEgfW43ZdIzW7R1Ff9ja8Rndcs5QeObcqHONrUiLD9Q/Fze09+5GfpUuA21PnWp82madMFzdXPklQReXHE3kjypP/llLJWCpweu0GdQQOCTGxiWNVFA2rswcJZqJaBKNUjiobhD4I+LpFRHvC7nrMgyQFjEOVsgDa+B0ojScmPtxowZkRwNn0OnLIuZ5s1dZ8BZUTDouyK0EoLVo8+u3c/Gjc/cgPnSwQFWmVuw8CFNJnMHZ4TZQIyUVAw8Nv6redWPlrIDRnn24waVbYg4HdoQg==; 5:7Ii3oJrNrDXJ6OqNWsoX60bGeG87pqM5iFkF3s2o5GgrL9XZMf1b3aPfIrQmVF6/0MWx20MCArDusqnGFkTJtr7vPzwlW9JWxqmLmNWm6QHU057nm7lmDXv+sfaDfzMCzC3UEGeKgtBEDQF+OkDRte+jcMqBNcib3ezNKNHWjAo=; 7:JQozoMaPZokPjDXwZCde9dqzdlySM9v34AM/OrYtXGFlL0mPanASczk0rtxf8QpoD/RJ4NV8SpujDdYWMPEYTJFebNXDThtG25I4yzOtitNJEH9rGAQgkcJPDPstDcbqu0GVvCQs5Ga/kHRTJMsB6ORHtcvhnC8zL0j8NHHeXy9UPnO4xDKUf6eQ5zdD9v3a+xucDtCt/YsYvIm00utMRc8UdUbnn+lUgEHkxvGJEgpJOq6CiGojPndc3Ix6w/lB
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 771319db-a44d-4ba8-5bcd-08d5f0fbfb60
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3975; 
x-ms-traffictypediagnostic: BYAPR05MB3975:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(95692535739014)(21748063052155)(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB3975; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3975; 
x-forefront-prvs: 0743E8D0A6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(396003)(366004)(39860400002)(51444003)(189003)(199004)(6512007)(99286004)(54896002)(5250100002)(6486002)(68736007)(7736002)(6246003)(236005)(6306002)(2906002)(2900100001)(476003)(26005)(606006)(53936002)(102836004)(82746002)(2616005)(53546011)(25786009)(6436002)(3846002)(6116002)(229853002)(316002)(4326008)(110136005)(5660300001)(11346002)(186003)(76176011)(97736004)(14454004)(106356001)(93886005)(8676002)(105586002)(66066001)(446003)(966005)(86362001)(8936002)(81166006)(256004)(36756003)(33656002)(6506007)(486006)(83716003)(478600001)(58126008)(14444005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3975; H:BYAPR05MB4230.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: 4N0n4QW0ZfWRcx/WKtdGfVsdQxhHCYtevFf1RH80TAQ8ShpQYvnk7zOAZTfbKyN3om9FbNZIPu4LI4uZVNPYzlQ1leTgKNehVp/rj1hIKoCXMNmdVYb6nOzc1bG7jwh0LEHp6cwk9GpAZuFthNGIwbXBo7zMUP3EIdI5l7fCJpwoYDnYoPAHmtGwUl8uAW80YEnMSNandUxnjaVgy8CAwetHRZRAQwJmbh6anF0BkeGh0f8ibUZ/9avRT6tGMUmoDT0MeQcD+tGDYAnT/feVJ3JKbDFilCCVPXRyWln9zyHJjSbNGQ2+ph6ph8s3VxvfbfSt+G7GjuTAyJhnXlQjXjrW61GEkvNZe54XdbRFFOM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_23F07D1B2816457A89DDBD457F77889Ejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 771319db-a44d-4ba8-5bcd-08d5f0fbfb60
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 00:25:38.6396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3975
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-23_07:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807240003
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 00:25:49 -0000

--_000_23F07D1B2816457A89DDBD457F77889Ejunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpCZWZvcmUgUkVTVENPTkYsIEkgaW1wbGVtZW50ZWQgYSB2ZXJzaW9uZWQgUkVTVCBBUEkgdGhh
dCBtYWludGFpbmVkIGNvbnN0YW50IG9iamVjdCBVUklzLCB3aGlsZSBhbGxvd2luZyB0aGUgb2Jq
ZWN0cyB0aGVtc2VsdmVzIHRvIGJlIHZlcnNpb25lZCwgYnkgdXNpbmcgdGhlIENvbnRlbnQtVHlw
ZSBhbmQgQWNjZXB0IGhlYWRlcnMgKHllcywgd2UgY3JlYXRlZCBhIG1lZGlhIHR5cGUgZm9yIGV2
ZXJ5ICJvYmplY3QiIGluIHRoZSBzeXN0ZW0pLiAgVGhlIHNlcnZlciBhbHdheXMgbmF0aXZlbHkg
dW5kZXJzdG9vZCB0aGUgImxhdGVzdCIsIHdoaWxlIGJlaW5nIGFibGUgdG8gdHJhbnNsYXRlIHRv
L2Zyb20gdGhlIGxhc3QgZmV3IHZlcnNpb25zIG9mIHRoZSBwcm9kdWN0LiAgSXQgd2FzIGVmZm9y
dCB0byB1cGRhdGUgdGhlIHRyYW5zbGF0b3JzIGVhY2ggcmVsZWFzZSBidXQsIHRoYW5rZnVsbHks
IHRoZXJlIHdlcmUgb25seSBhIGZldyBvZiB0aGVtIGVhY2ggdGltZSwgYW5kIHRoZSB1bml0LXRl
c3RzIGZyb20gdGhlIHByZXZpb3VzIHJlbGVhc2VzIGNvdWxkIGJlIHVzZWQgdG8gdGVzdCBjb3Jy
ZWN0bmVzcyBvZiB0aGUgdHJhbnNsYXRvcnMuDQoNCldoYXQncyBiZWluZyBkaXNjdXNzZWQgbm93
IHNvdW5kcyBzaW1pbGFyLCB3aXRoIHNpbWlsYXIgYXNzb2NpYXRlZCBjb3N0cy4gIFdoZXRoZXIg
b3Igbm90IHdlIHVzZSBhIG5ldyBtb2R1bGUtbmFtZSBwZXIgIm1ham9yIiB2ZXJzaW9uIChlc3Nl
bnRpYWxseSB3aGF0IHdlIGhhdmUgdG9kYXksIGJ1dCBmdXJ0aGVyIHJlZmluZWQgYnkgQ2hyaXMn
cyBpZGVhKSB3b24ndCBhZmZlY3QgdGhpcyBjb3N0IG11Y2guICBUaGUgcHJpbWFyeSBhZHZhbnRh
Z2UgdG8gdXNpbmcgdGhlIHNhbWUgbW9kdWxlIG5hbWUgYWNyb3NzIG1ham9yIHZlcnNpb25zIGlz
IHRoYXQgaXMgZ2l2ZXMgdG8gY2xpZW50IG1vcmUgY2x1ZSBiZWhpbmQgd2hhdCBpcyBnb2luZyBv
bi4gIFBlcmhhcHMgc2ltaWxhciBjbHVlIGNhbiBiZSBhY2hpZXZlZCB2aWEgYW4gZXh0ZW5zaW9u
IHN0YXRlbWVudDoNCg0KICBtb2R1bGUgZm9vLTMgew0KICAgIOKApg0KICAgIHJlcGxhY2VzLW1v
ZHVsZSBmb28tMjsNCiAgICDigKYNCiAgfQ0KDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQpP
biA3LzIzLzE4LCAyOjQ2IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4iIDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9u
IGJlaGFsZiBvZiBhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+
IHdyb3RlOg0KDQoNCg0KT24gTW9uLCBKdWwgMjMsIDIwMTggYXQgNzozMiBBTSwgUm9iZXJ0IFdp
bHRvbiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6
DQoNCg0KDQpPbiAyMy8wNy8yMDE4IDE1OjA4LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQoNCg0KT24g
TW9uLCBKdWwgMjMsIDIwMTggYXQgNjoyNCBBTSwgUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNj
by5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiAyMy8wNy8y
MDE4IDEyOjU0LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQoNCg0KT24gTW9uLCBKdWwgMjMsIDIwMTgg
YXQgMjo1MCBBTSwgUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0
b25AY2lzY28uY29tPj4gd3JvdGU6DQpIaSBDaHJpcywgQW5keSwNCg0KDQpPbiAyMS8wNy8yMDE4
IDE3OjAwLCBDaHJpc3RpYW4gSG9wcHMgd3JvdGU6DQpBcyBJIHBvaW50ZWQgb3V0IGF0IHRoZSBt
aWMgQDEwMiB0aGlzIHJlcXVpcmVtZW50IGRlcml2ZXMgZGlyZWN0bHkgZnJvbSB0aGUgMS54IHJl
cXVpcmVtZW50IG9mIG5vdCBjaGFuZ2luZyB0aGUgbmFtZSBvZiB0aGUgbW9kdWxlL25hbWVzcGFj
ZS4gSWYgeW91IGFsbG93IGZvciBjaGFuZ2luZyB0aGUgbmFtZXNwYWNlL21vZHVsZSBuYW1lIGZv
ciAibWFqb3IiIChpLmUuLCBpbmNvbXBhdGlibGUpIGNoYW5nZXMgKGkuZS4sIGxpa2UgdG9kYXkp
IHRoZW4gdGhpcyAzLjEgcmVxdWlyZW1lbnQgZ29lcyBhd2F5Lg0KTm90IHN1cmUgdGhhdCBJIGFn
cmVlLg0KDQpJIHRoaW5rIHRoYXQgeW91IGhhdmUgbWFkZSBhbiBhc3N1bXB0aW9uIGhlcmUgdGhh
dCB0aGUgc2VydmVyIHdpbGwgY29udGludWUgdG8gc3VwcG9ydCBib3RoIG9sZCBhbmQgbmV3IG1h
am9yIHJldmlzaW9uICh3aXRoIGRpZmZlcmVudCBuYW1lKSBvZiB0aGUgbW9kdWxlIGF0IHRoZSBz
YW1lIHRpbWUuICBIb3dldmVyLCB0aGVzZSBpcyBub3RoaW5nIGluIHRoZSBleGlzdGluZyBZQU5H
IHVwZ3JhZGUgcnVsZXMgdGhhdCByZXF1aXJlcyB0aGF0Lg0KDQpVbHRpbWF0ZWx5LCB0aGVyZSBp
cyBhIGNob2ljZSB3aGV0aGVyIHN1cHBvcnRpbmcgb2xkZXIgbW9kdWxlIHZlcnNpb25zIGlzIHRo
ZSBzZXJ2ZXJzIHByb2JsZW0gb3IgdGhlIGNsaWVudHMgcHJvYmxlbSwgb3IgcGVyaGFwcyBhIGNv
bWJpbmF0aW9uIG9mIHRoZSB0d28uDQoNClRoZSBhaW0gb2YgcmVxdWlyZW1lbnQgMy4xIGlzIHRv
IGVuc3VyZSB0aGF0IHRoZXJlIGlzIGEgc3RhbmRhcmQgbWVjaGFuaXNtIGF2YWlsYWJsZSBzbyB0
aGF0IHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3YW50IHRoZSBmbGV4aWJpbGl0eSBvZiBz
dXBwb3J0aW5nIG9sZGVyIGNsaWVudCB2ZXJzaW9ucyBoYXZlIGEgc3RhbmRhcmQgd2F5IG9mIGRv
aW5nIHNvLiAgTXkgaW50ZW50aW9uIGlzIHRoYXQgdGhpcyBwYXJ0IG9mIHRoZSBzb2x1dGlvbiB3
b3VsZCBiZSBvcHRpb25hbCB0byBpbXBsZW1lbnQgYW5kIGhlbmNlIGRlY2lkZWQgYnkgdGhlIG1h
cmtldCwgd2hpY2ggaXMgd2h5IHRoZSB0ZXh0IGluIHRoZSByZXF1aXJlbWVudCBpcyAidG8gYWxs
b3cgc2VydmVycyIgcmF0aGVyIHRoYW4gInRvIHJlcXVpcmUgc2VydmVycyIuDQoNCg0KQVBJIHZl
cnNpb25pbmcgaXMgdXN1YWxseSBkb25lIG9uIHRoZSBtZXNzYWdlIGV4Y2hhbmdlcy4NClRyeWlu
ZyB0byBkbyB0aGUgc2FtZSBmb3IgZGF0YXN0b3JlIGNvbnRlbnRzIGlzIG5vdCBnb2luZyB0byB3
b3JrLg0KQSBZQU5HIHNjaGVtYSBjYW4gYmUgY29uc2lkZXJlZCBhbiBBUEkuICBQYXJ0aWN1bGFy
bHkgbG9va2luZyBhdCBzYXkgdGhlIE9wZW5Db25maWcgWUFORyBzY2hlbWEuICBJIGRvdWJ0IGFs
bCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzdG9yZSBhbGwgdGhlaXIgY29uZmlndXJhdGlvbiBhbmQg
b3BlcmF0aW9uYWwgc3RhdGUgaW4gYSBjZW50cmFsIHBsYWNlLg0KDQoNCllvdSBjYW4gd3JpdGUg
dGhlIHdvcmQgTVVTVCBpbiBhbGwgY2FwcyBhcyBtYW55IHRpbWVzIGFzIHlvdSB3YW50LA0KYnV0
IHRoYXQgd2lsbCBub3QgY2hhbmdlIGFueXRoaW5nLg0KDQpJIGRpc2FncmVlLiAgTWFya2luZyBh
IHJlcXVpcmVtZW50IGFzIGEgTVVTVCBtZWFucyB0aGF0IHJlcXVpcmVtZW50IGhhcyB0byBiZSBt
ZXQgZm9yIGEgc29sdXRpb24gdG8gYmUgY29uc2lkZXJlZCB2aWFibGUuDQoNCkkgcHJldmlvdXNs
eSBoYWQgc29tZSB0ZXh0IGluIHRoZSBkcmFmdCBleHBsYWluaW5nIGhvdyBSRkMgMjExOSB0ZXh0
IHRyYW5zbGF0ZXMgdG8gZXZhbHVhdGluZyB0aGUgcmVxdWlyZW1lbnRzLCBidXQgd2FzIGFza2Vk
IHRvIHRha2UgaXQgb3V0IGJlY2F1c2UgaXQgaXMgb2J2aW91cy4gIFBlcmhhcHMgaXQgc2hvdWxk
IGdvIGJhY2sgaW4gLi4uDQoNClNvIHlvdSBjYW4gYW5zd2VyIHRoZSBxdWVzdGlvbiBob3cgWUFO
RyB2YWxpZGF0aW9uIHdvcmtzIHdoZW4gbXVsdGlwbGUgcmV2aXNpb25zIG9mIGENCm1vZHVsZSBh
cmUgaW1wbGVtZW50ZWQ/DQoNCk9rLCBzbyB0aGUgc2NoZW1lIHRoYXQgSSB3YXMgY29uc2lkZXJp
bmcgaXM6DQogLSBUaGUgZGV2aWNlIGltcGxlbWVudHMgb25seSBvbmUgdmVyc2lvbiBvZiB0aGUg
c2NoZW1hIChpLmUuIHByb2JhYmx5IGFsbCBvZiB0aGUgbGF0ZXN0IG1vZHVsZXMgcmV2aXNpb25z
L3ZlcnNpb25zKS4NCg0KSG93ZXZlciwgdGhlIHByb3RvY29scyBhcmUgZXh0ZW5kZWQgdG8gYWxs
b3cgY2xpZW50cyB0byBzZWxlY3QgdG8gdXNlIGFuIG9sZGVyIHZlcnNpb24gc2V0IG9mIHRoZSBt
b2R1bGVzIGZvciB0aGF0IHNlc3Npb24uICBZQU5HIGxpYnJhcnkgZm9yIHRoYXQgc2Vzc2lvbiB3
b3VsZCByZXBvcnQgdGhlIGNob3NlbiBzZXQgb2YgbW9kdWxlcyBhcyAiaW1wbGVtZW50ZWQiIGJ5
IHRoZSBzZXJ2ZXIgZm9yIHRoYXQgc2Vzc2lvbi4NCg0KVGhlIHNlcnZlciBjaG9vc2VzIGhvdyBt
YW55IGRpZmZlcmVudCBzZXRzIG9mIG1vZHVsZXMgYXJlIHN1cHBvcnRlZCwgYW5kIGV4YWN0bHkg
d2hhdCBtb2R1bGUgcmV2aXNpb25zLCBmZWF0dXJlcyBhcmUgaW5jbHVkZWQgaW4gZWFjaCBvZiB0
aG9zZSBtb2R1bGUgc2V0cy4gIE5vcm1hbGx5IEkgd291bGQgZXhwZWN0IGV4YWN0IG1vZHVsZSBz
ZXRzIHRvIGFsaWduIHdpdGggYSBwcmV2aW91cyBzb2Z0d2FyZSByZWxlYXNlLiAgVGhlIGRpZmZl
cmVudCBtb2R1bGUtc2V0cyBjYW4gYmUgZXhwb3NlZCB2aWEgWUFORyBsaWJyYXJ5IGJpcy4gIE5l
dyBSUENzIG9yIHByb3RvY29sIGV4dGVuc2lvbnMgYXJlIHJlcXVpcmVkIHRvIGNob29zZSB3aGlj
aCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQgZm9yIHRoZSBzZXNzaW9uLg0KDQpUaGUgc2VydmVyIHRo
ZW4gaGFzIGNvZGUgdG8gbWFwIGZyb20gdGhlIG9sZGVyIG1vZHVsZSBzZXQgcGF0aHMgdG8gdGhl
IGxhdGVzdCB2ZXJzaW9uIHRoYXQgaXMgImltcGxlbWVudGVkIiBieSB0aGUgZGV2aWNlLiAgVGhl
IHZhc3QgbWFqb3JpdHkgb2YgdGhlIG1hcHBpbmdzIHdvdWxkIGJlIHRyaXZpYWwgbWFwcGluZ3Mg
b2YgdGhlIHNhbWUgdmFsdWUgb24gdGhlIHNhbWUgcGF0aC4NCg0KVGhpcyBtYXBwaW5nIGlzIGV4
YWN0bHkgdGhlIHNhbWUgYXMgd291bGQgaGF2ZSB0byBiZSBkb25lIG9uIGEgY2xpZW50IGlmIGl0
IGhhcyB0byBzdXBwb3J0IHNlcnZlcnMgcnVubmluZyBkaWZmZXJlbnQgcmV2aXNpb25zLg0KDQpO
b3QgYWxsIGNoYW5nZXMgY2FuIGJlIG1hcHBlZCwgc29tZSB3b3VsZCBoYXZlIHRvIGp1c3QgZmFp
bCAocGVyaGFwcyBjb3VsZCBiZSBjb3ZlcmVkIGJ5IGRldmlhdGlvbnMpLg0KDQoNCiAgSSBkbyBu
b3QgZG91YnQgdGhhdCB5b3UgY2FuIGZpbmQgYSBsZWFmIHNvbWV3aGVyZSB0aGF0IGNhbg0KYmUg
Y2hhbmdlZC4gIE5vdCBhdCBhbGwgY29udmluY2VkIHRoZSB2YWxpZGF0aW9uIHJ1bGVzIGNhbiBi
ZSByZXdyaXR0ZW4gdG8gYWNjb3VudA0KZm9yIGFjdHVhbCBpbmNvbXBhdGlibGUgY2hhbmdlcywg
bGlrZSBjaGFuZ2luZyB0aGUgdHlwZSBvZiBkYXRhIG5vZGUgb3IgcmVwbGFjaW5nIG5vZGVzDQp3
aXRoIGNvbXBsZXRlbHkgZGlmZmVyZW50IGNvbmZpZ3VyYXRpb24uDQpUaGUgbWFwcGluZyBhYm92
ZSB3aWxsIG5vdCBiZSBwZXJmZWN0IGluIGFsbCBjYXNlcywgcGFydGljdWxhcmx5IGlmIGtleXMg
YXJlIGNoYW5nZXMsIG9yIHN1cHBvcnQgZm9yIHNvZnR3YXJlIGlzIHJlbW92ZWQsIGV0Yy4gIEJ1
dCB0aGV5IG1pZ2h0IHN0aWxsIGhlbHAuDQoNCg0KICBFdmVuIGxlc3MgY29udmluY2VkIHRoYXQg
dGhpcyBjb21wbGV4aXR5IGlzDQp3b3J0aCB0aGUgY29zdC4NCg0KV2VsbCB0aGUgY29tcGxleGl0
eSBlbmRzIHVwIGdvaW5nIGluIHRoZSBjbGllbnQgb3IgdGhlIHNlcnZlci4gIEkgdGhpbmsgdGhh
dCB0aGlzIGlzIGdlbmVyYWxseSBhIGNvbXBsZXggcHJvYmxlbSB0byBzb2x2ZS4gIE9wZXJhdG9y
cyB3aWxsIGxpa2VseSBhcmd1ZSB0aGF0IGl0IGlzIGJldHRlciB0aGF0IHRoZSBjb21wbGV4aXR5
IGdvZXMgaW4gdGhlIHNlcnZlciB0byBrZWVwIHRoZSBjbGllbnQgc2ltcGxlLiAgU2VydmVyIHZl
bmRvcnMgd2lsbCBsaWtlbHkgYXJndWUgZm9yIHRoZSByZXZlcnNlLg0KDQpOb3RlLCB0aGF0IEkn
bSBzdGlsbCBzb21ld2hhdCBvcGVuIHRvIHdoYXQgdGhlIHJpZ2h0IHNvbHV0aW9uIHNob3VsZCBi
ZSBoZXJlLg0KDQpTb3VuZHMgdmVyeSBjb21wbGljYXRlZCB0byBpbXBsZW1lbnQgaW4gdGhlIHNl
cnZlciwgYnV0IGF0IGxlYXN0IHlvdSBhdm9pZCBtdWx0aXBsZSB2YXJpYW50cyBvZiBhIGRhdGFz
dG9yZS4NCkluc3RlYWQgdGhlIHNlcnZlciBpcyBwcm92aWRpbmcgdmFyaW91cyB0cmFuc2Zvcm1h
dGlvbnMgYmV0d2VlbiBkYXRhIG1vZGVscy4NCg0KVGhpcyB3aWxsIG1ha2UgdGhlIHN0YW5kYXJk
cyBtdWNoIG1vcmUgY29tcGxpY2F0ZWQgYW5kIGhlYXZ5d2VpZ2h0IHRvIGltcGxlbWVudC4NCklm
IGl0IHdhcyBzbyBlYXN5IGFuZCBzbyBpbXBvcnRhbnQsIHZlbmRvcnMgd291bGQgYWxyZWFkeSBz
dXBwb3J0IGl0IGluIHRoZWlyIHByb3ByaWV0YXJ5IEFQSXMuDQpJbnN0ZWFkIHZlbmRvcnMgZGVj
aWRlIHdoZW4gdG8gZW5kLW9mLWxpZmUgcHJvZHVjdHMgYW5kIGZlYXR1cmVzLg0KDQoNCg0KVGhh
bmtzLA0KUm9iDQoNCkFuZHkNCg0KDQoNCg0KDQoNClRoYW5rcywNClJvYg0KDQpBbmR5DQoNCg0K
VGhhbmtzLA0KUm9iDQoNCkFuZHkNCg0KDQoNCkkgdGhpbmsgdGhlIHBsYW4gaXMgdG8gcmV3b3Jk
IHNvbWUgb2YgdGhlc2UgdG8gZ2V0IGNsb3NlciB0byB0aGUgaW50ZW50aW9uIHdoaWNoIEkgYmVs
aWV2ZSBpcyB0byBhbGxvdyBmb3Igc21vb3RoZXIgdHJhbnNpdGlvbiBmcm9tIG9uZSBtb2R1bGUg
dG8gdGhlIG5leHQgd2hpbGUgbWFraW5nIGluY29tcGF0aWJsZSBidXQgbW9zdGx5IG5vbi1pbXBh
Y3RpbmcgY2hhbmdlcy4NCg0KVGhhbmtzLA0KQ2hyaXMuDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5
dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cml0ZXM6DQpIaSwNCg0K
SSBzdHJvbmdseSBvYmplY3QgdG8gcmVxdWlyZW1lbnQgMy4xOg0KDQoNCiAgICAzLjEgIFRoZSBz
b2x1dGlvbiBNVVNUIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gYWxsb3cgc2VydmVycyB0bw0KICAg
ICAgICAgICAgc3VwcG9ydCBleGlzdGluZyBjbGllbnRzIGluIGEgYmFja3dhcmQgY29tcGF0aWJs
ZSB3YXkuDQoNCg0KDQpUaGlzIGlzIG5vdCB3aGF0IHNlcnZlcnMgZG8gdG9kYXkgYXQgYWxsLg0K
VGhleSBwcm92aWRlIG9ubHkgb25lIHZlcnNpb24gb2YgYW4gaW1wbGVtZW50ZWQgbW9kdWxlLCBh
cyBzcGVjaWZpZWQgaW4gUkZDDQo3OTUwLg0KDQpJdCBpcyBhIHZlbmRvciBhbmQgb3BlcmF0b3Ig
ZGVjaXNpb24gd2hlbiB0byB1cGdyYWRlIGEgc2VydmVyIHN1Y2ggdGhhdA0Kbm9uLWJhY2t3YXJk
IGNvbXBhdGlibGUgY2hhbmdlcyBhcmUgbWFkZS4gVGhleSBtdXN0IGRlY2lkZSBpZi93aGVuIGl0
IGlzIG9rDQpiYXNlZCBvbiB0aGUgY2xpZW50IGFwcGxpY2F0aW9ucyBpbiB1c2UuDQoNClRoaXMg
cmVxdWlyZW1lbnQgc2F5cyB5b3UgY2Fubm90IG1ha2UgYmFja3dhcmQtaW5jb21wYXRpYmxlIGNo
YW5nZXMNCndoaWNoIGNvbXBsZXRlbHkgY29udHJhZGljdHMgcmVxdWlyZW1lbnRzIDEuMSBhbmQg
MS4yLg0KDQpJTU8gcmVxdWlyZW1lbnQgMy4xIHNob3VsZCBiZSByZW1vdmVkLCBvciBjaGFuZ2Ug
TVVTVCB0byBNQVkNCg0KDQpBbmR5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0
bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3TUZhUSZjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09TkxLekIzUlJ2R2tBZEJkU3FzYlBmOXZiSTNP
QmN5ZzZuejJQYjBTalpFYyZzPVVodjMxTTFmdnpoeXlzLTR0Q2dpSEdreHZrLXctZEtiQWFlaFBV
ZVFfaFkmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll
dGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdNRmFRJmM9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mbT1OTEt6QjNSUnZHa0FkQmRTcXNiUGY5dmJJM09CY3lnNm56MlBi
MFNqWkVjJnM9VWh2MzFNMWZ2emh5eXMtNHRDZ2lIR2t4dmstdy1kS2JBYWVoUFVlUV9oWSZlPT4N
Ci4NCg0KDQoNCg0KDQoNCg==

--_000_23F07D1B2816457A89DDBD457F77889Ejunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <935791AC9EC050449A4CB3EE4CB86D63@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0
YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRl
Y29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNv
SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkJlZm9yZSBSRVNUQ09ORiwgSSBpbXBsZW1lbnRl
ZCBhIHZlcnNpb25lZCBSRVNUIEFQSSB0aGF0IG1haW50YWluZWQgY29uc3RhbnQgb2JqZWN0IFVS
SXMsIHdoaWxlIGFsbG93aW5nIHRoZSBvYmplY3RzIHRoZW1zZWx2ZXMgdG8gYmUgdmVyc2lvbmVk
LCBieSB1c2luZyB0aGUgQ29udGVudC1UeXBlIGFuZCBBY2NlcHQgaGVhZGVycyAoeWVzLCB3ZSBj
cmVhdGVkDQogYSBtZWRpYSB0eXBlIGZvciBldmVyeSAmcXVvdDtvYmplY3QmcXVvdDsgaW4gdGhl
IHN5c3RlbSkuJm5ic3A7IFRoZSBzZXJ2ZXIgYWx3YXlzIG5hdGl2ZWx5IHVuZGVyc3Rvb2QgdGhl
ICZxdW90O2xhdGVzdCZxdW90Oywgd2hpbGUgYmVpbmcgYWJsZSB0byB0cmFuc2xhdGUgdG8vZnJv
bSB0aGUgbGFzdCBmZXcgdmVyc2lvbnMgb2YgdGhlIHByb2R1Y3QuJm5ic3A7IEl0IHdhcyBlZmZv
cnQgdG8gdXBkYXRlIHRoZSB0cmFuc2xhdG9ycyBlYWNoIHJlbGVhc2UgYnV0LCB0aGFua2Z1bGx5
LCB0aGVyZSB3ZXJlDQogb25seSBhIGZldyBvZiB0aGVtIGVhY2ggdGltZSwgYW5kIHRoZSB1bml0
LXRlc3RzIGZyb20gdGhlIHByZXZpb3VzIHJlbGVhc2VzIGNvdWxkIGJlIHVzZWQgdG8gdGVzdCBj
b3JyZWN0bmVzcyBvZiB0aGUgdHJhbnNsYXRvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj5XaGF0J3MgYmVpbmcgZGlzY3Vzc2VkIG5vdyBzb3VuZHMg
c2ltaWxhciwgd2l0aCBzaW1pbGFyIGFzc29jaWF0ZWQgY29zdHMuJm5ic3A7IFdoZXRoZXIgb3Ig
bm90IHdlIHVzZSBhIG5ldyBtb2R1bGUtbmFtZSBwZXIgJnF1b3Q7bWFqb3ImcXVvdDsgdmVyc2lv
biAoZXNzZW50aWFsbHkgd2hhdCB3ZSBoYXZlIHRvZGF5LCBidXQgZnVydGhlciByZWZpbmVkIGJ5
IENocmlzJ3MgaWRlYSkNCiB3b24ndCBhZmZlY3QgdGhpcyBjb3N0IG11Y2guJm5ic3A7IFRoZSBw
cmltYXJ5IGFkdmFudGFnZSB0byB1c2luZyB0aGUgc2FtZSBtb2R1bGUgbmFtZSBhY3Jvc3MgbWFq
b3IgdmVyc2lvbnMgaXMgdGhhdCBpcyBnaXZlcyB0byBjbGllbnQgbW9yZSBjbHVlIGJlaGluZCB3
aGF0IGlzIGdvaW5nIG9uLiZuYnNwOyBQZXJoYXBzIHNpbWlsYXIgY2x1ZSBjYW4gYmUgYWNoaWV2
ZWQgdmlhIGFuIGV4dGVuc2lvbiBzdGF0ZW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgbW9kdWxlIGZvby0zIHs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDsmbmJzcDsmbmJzcDsgcmVwbGFjZXMtbW9kdWxlIGZvby0yOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij4mbmJzcDsmbmJzcDsmbmJzcDsg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyB9PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6Q2FsaWJyaSI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzIzLzE4LCAyOjQ2IFBN
LCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmIG9mIEFuZHkgQmllcm1hbiZxdW90OyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9y
ZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5h
bmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyMywgMjAxOCBhdCA3OjMyIEFN
LCBSb2JlcnQgV2lsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iIHRh
cmdldD0iX2JsYW5rIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIDIzLzA3LzIwMTggMTU6MDgsIEFuZHkgQmllcm1hbiB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdWwgMjMsIDIwMTgg
YXQgNjoyNCBBTSwgUm9iZXJ0IFdpbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lz
Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMy8wNy8yMDE4IDEyOjU0LCBBbmR5IEJpZXJtYW4gd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVs
IDIzLCAyMDE4IGF0IDI6NTAgQU0sIFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpy
d2lsdG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SGkgQ2hyaXMsIEFuZHksPGJyPg0KPGJyPg0KPGJyPg0KT24gMjEvMDcvMjAxOCAxNzowMCwg
Q2hyaXN0aWFuIEhvcHBzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFzIEkgcG9pbnRlZCBvdXQgYXQgdGhlIG1pYyBAMTAyIHRoaXMgcmVx
dWlyZW1lbnQgZGVyaXZlcyBkaXJlY3RseSBmcm9tIHRoZSAxLnggcmVxdWlyZW1lbnQgb2Ygbm90
IGNoYW5naW5nIHRoZSBuYW1lIG9mIHRoZSBtb2R1bGUvbmFtZXNwYWNlLiBJZiB5b3UgYWxsb3cg
Zm9yIGNoYW5naW5nIHRoZSBuYW1lc3BhY2UvbW9kdWxlIG5hbWUgZm9yICZxdW90O21ham9yJnF1
b3Q7IChpLmUuLCBpbmNvbXBhdGlibGUpIGNoYW5nZXMgKGkuZS4sDQogbGlrZSB0b2RheSkgdGhl
biB0aGlzIDMuMSByZXF1aXJlbWVudCBnb2VzIGF3YXkuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pk5vdCBzdXJlIHRoYXQgSSBhZ3JlZS48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgeW91IGhhdmUg
bWFkZSBhbiBhc3N1bXB0aW9uIGhlcmUgdGhhdCB0aGUgc2VydmVyIHdpbGwgY29udGludWUgdG8g
c3VwcG9ydCBib3RoIG9sZCBhbmQgbmV3IG1ham9yIHJldmlzaW9uICh3aXRoIGRpZmZlcmVudCBu
YW1lKSBvZiB0aGUgbW9kdWxlIGF0IHRoZSBzYW1lIHRpbWUuJm5ic3A7IEhvd2V2ZXIsIHRoZXNl
IGlzIG5vdGhpbmcgaW4gdGhlIGV4aXN0aW5nIFlBTkcgdXBncmFkZSBydWxlcyB0aGF0IHJlcXVp
cmVzIHRoYXQuPGJyPg0KPGJyPg0KVWx0aW1hdGVseSwgdGhlcmUgaXMgYSBjaG9pY2Ugd2hldGhl
ciBzdXBwb3J0aW5nIG9sZGVyIG1vZHVsZSB2ZXJzaW9ucyBpcyB0aGUgc2VydmVycyBwcm9ibGVt
IG9yIHRoZSBjbGllbnRzIHByb2JsZW0sIG9yIHBlcmhhcHMgYSBjb21iaW5hdGlvbiBvZiB0aGUg
dHdvLjxicj4NCjxicj4NClRoZSBhaW0gb2YgcmVxdWlyZW1lbnQgMy4xIGlzIHRvIGVuc3VyZSB0
aGF0IHRoZXJlIGlzIGEgc3RhbmRhcmQgbWVjaGFuaXNtIGF2YWlsYWJsZSBzbyB0aGF0IHNlcnZl
ciBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3YW50IHRoZSBmbGV4aWJpbGl0eSBvZiBzdXBwb3J0aW5n
IG9sZGVyIGNsaWVudCB2ZXJzaW9ucyBoYXZlIGEgc3RhbmRhcmQgd2F5IG9mIGRvaW5nIHNvLiZu
YnNwOyBNeSBpbnRlbnRpb24gaXMgdGhhdCB0aGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uDQogd291
bGQgYmUgb3B0aW9uYWwgdG8gaW1wbGVtZW50IGFuZCBoZW5jZSBkZWNpZGVkIGJ5IHRoZSBtYXJr
ZXQsIHdoaWNoIGlzIHdoeSB0aGUgdGV4dCBpbiB0aGUgcmVxdWlyZW1lbnQgaXMgJnF1b3Q7dG8g
YWxsb3cgc2VydmVycyZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDt0byByZXF1aXJlIHNlcnZlcnMm
cXVvdDsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkFQSSB2ZXJzaW9uaW5nIGlzIHVzdWFsbHkgZG9uZSBvbiB0aGUgbWVzc2Fn
ZSBleGNoYW5nZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UcnlpbmcgdG8gZG8gdGhlIHNhbWUgZm9yIGRhdGFzdG9yZSBjb250ZW50cyBpcyBu
b3QgZ29pbmcgdG8gd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBZQU5HIHNjaGVt
YSBjYW4gYmUgY29uc2lkZXJlZCBhbiBBUEkuJm5ic3A7IFBhcnRpY3VsYXJseSBsb29raW5nIGF0
IHNheSB0aGUgT3BlbkNvbmZpZyBZQU5HIHNjaGVtYS4mbmJzcDsgSSBkb3VidCBhbGwgaW1wbGVt
ZW50YXRpb25zIHdpbGwgc3RvcmUgYWxsIHRoZWlyIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlv
bmFsIHN0YXRlIGluIGEgY2VudHJhbCBwbGFjZS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PllvdSBjYW4gd3JpdGUgdGhlIHdvcmQgTVVTVCBpbiBhbGwgY2FwcyBhcyBtYW55IHRpbWVzIGFz
IHlvdSB3YW50LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YnV0IHRoYXQgd2lsbCBub3QgY2hhbmdlIGFueXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkkgZGlzYWdyZWUu
Jm5ic3A7IE1hcmtpbmcgYSByZXF1aXJlbWVudCBhcyBhIE1VU1QgbWVhbnMgdGhhdCByZXF1aXJl
bWVudCBoYXMgdG8gYmUgbWV0IGZvciBhIHNvbHV0aW9uIHRvIGJlIGNvbnNpZGVyZWQgdmlhYmxl
Ljxicj4NCjxicj4NCkkgcHJldmlvdXNseSBoYWQgc29tZSB0ZXh0IGluIHRoZSBkcmFmdCBleHBs
YWluaW5nIGhvdyBSRkMgMjExOSB0ZXh0IHRyYW5zbGF0ZXMgdG8gZXZhbHVhdGluZyB0aGUgcmVx
dWlyZW1lbnRzLCBidXQgd2FzIGFza2VkIHRvIHRha2UgaXQgb3V0IGJlY2F1c2UgaXQgaXMgb2J2
aW91cy4mbmJzcDsgUGVyaGFwcyBpdCBzaG91bGQgZ28gYmFjayBpbiAuLi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
U28geW91IGNhbiBhbnN3ZXIgdGhlIHF1ZXN0aW9uIGhvdyBZQU5HIHZhbGlkYXRpb24gd29ya3Mg
d2hlbiBtdWx0aXBsZSByZXZpc2lvbnMgb2YgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bW9kdWxlIGFyZSBpbXBsZW1lbnRlZD88bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT2ssIHNvIHRoZSBzY2hlbWUgdGhhdCBJIHdhcyBjb25z
aWRlcmluZyBpczo8YnI+DQombmJzcDstIFRoZSBkZXZpY2UgaW1wbGVtZW50cyBvbmx5IG9uZSB2
ZXJzaW9uIG9mIHRoZSBzY2hlbWEgKGkuZS4gcHJvYmFibHkgYWxsIG9mIHRoZSBsYXRlc3QgbW9k
dWxlcyByZXZpc2lvbnMvdmVyc2lvbnMpLjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBwcm90b2Nv
bHMgYXJlIGV4dGVuZGVkIHRvIGFsbG93IGNsaWVudHMgdG8gc2VsZWN0IHRvIHVzZSBhbiBvbGRl
ciB2ZXJzaW9uIHNldCBvZiB0aGUgbW9kdWxlcyBmb3IgdGhhdCBzZXNzaW9uLiZuYnNwOyBZQU5H
IGxpYnJhcnkgZm9yIHRoYXQgc2Vzc2lvbiB3b3VsZCByZXBvcnQgdGhlIGNob3NlbiBzZXQgb2Yg
bW9kdWxlcyBhcyAmcXVvdDtpbXBsZW1lbnRlZCZxdW90OyBieSB0aGUgc2VydmVyIGZvciB0aGF0
IHNlc3Npb24uPGJyPg0KPGJyPg0KVGhlIHNlcnZlciBjaG9vc2VzIGhvdyBtYW55IGRpZmZlcmVu
dCBzZXRzIG9mIG1vZHVsZXMgYXJlIHN1cHBvcnRlZCwgYW5kIGV4YWN0bHkgd2hhdCBtb2R1bGUg
cmV2aXNpb25zLCBmZWF0dXJlcyBhcmUgaW5jbHVkZWQgaW4gZWFjaCBvZiB0aG9zZSBtb2R1bGUg
c2V0cy4mbmJzcDsgTm9ybWFsbHkgSSB3b3VsZCBleHBlY3QgZXhhY3QgbW9kdWxlIHNldHMgdG8g
YWxpZ24gd2l0aCBhIHByZXZpb3VzIHNvZnR3YXJlIHJlbGVhc2UuJm5ic3A7IFRoZSBkaWZmZXJl
bnQNCiBtb2R1bGUtc2V0cyBjYW4gYmUgZXhwb3NlZCB2aWEgWUFORyBsaWJyYXJ5IGJpcy4mbmJz
cDsgTmV3IFJQQ3Mgb3IgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhcmUgcmVxdWlyZWQgdG8gY2hvb3Nl
IHdoaWNoIHZlcnNpb24gaXMgYmVpbmcgdXNlZCBmb3IgdGhlIHNlc3Npb24uPGJyPg0KPGJyPg0K
VGhlIHNlcnZlciB0aGVuIGhhcyBjb2RlIHRvIG1hcCBmcm9tIHRoZSBvbGRlciBtb2R1bGUgc2V0
IHBhdGhzIHRvIHRoZSBsYXRlc3QgdmVyc2lvbiB0aGF0IGlzICZxdW90O2ltcGxlbWVudGVkJnF1
b3Q7IGJ5IHRoZSBkZXZpY2UuJm5ic3A7IFRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBtYXBwaW5n
cyB3b3VsZCBiZSB0cml2aWFsIG1hcHBpbmdzIG9mIHRoZSBzYW1lIHZhbHVlIG9uIHRoZSBzYW1l
IHBhdGguPGJyPg0KPGJyPg0KVGhpcyBtYXBwaW5nIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgd291
bGQgaGF2ZSB0byBiZSBkb25lIG9uIGEgY2xpZW50IGlmIGl0IGhhcyB0byBzdXBwb3J0IHNlcnZl
cnMgcnVubmluZyBkaWZmZXJlbnQgcmV2aXNpb25zLjxicj4NCjxicj4NCk5vdCBhbGwgY2hhbmdl
cyBjYW4gYmUgbWFwcGVkLCBzb21lIHdvdWxkIGhhdmUgdG8ganVzdCBmYWlsIChwZXJoYXBzIGNv
dWxkIGJlIGNvdmVyZWQgYnkgZGV2aWF0aW9ucykuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDsgSSBkbyBub3QgZG91YnQgdGhhdCB5b3UgY2FuIGZpbmQgYSBsZWFmIHNvbWV3aGVy
ZSB0aGF0IGNhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YmUgY2hhbmdlZC4mbmJzcDsgTm90IGF0IGFsbCBjb252aW5jZWQgdGhlIHZhbGlkYXRp
b24gcnVsZXMgY2FuIGJlIHJld3JpdHRlbiB0byBhY2NvdW50PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgYWN0dWFsIGluY29tcGF0aWJsZSBj
aGFuZ2VzLCBsaWtlIGNoYW5naW5nIHRoZSB0eXBlIG9mIGRhdGEgbm9kZSBvciByZXBsYWNpbmcg
bm9kZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PndpdGggY29tcGxldGVseSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIG1hcHBpbmcgYWJvdmUgd2lsbCBub3QgYmUgcGVyZmVjdCBpbiBhbGwg
Y2FzZXMsIHBhcnRpY3VsYXJseSBpZiBrZXlzIGFyZSBjaGFuZ2VzLCBvciBzdXBwb3J0IGZvciBz
b2Z0d2FyZSBpcyByZW1vdmVkLCBldGMuJm5ic3A7IEJ1dCB0aGV5IG1pZ2h0IHN0aWxsIGhlbHAu
PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgRXZlbiBsZXNzIGNvbnZpbmNlZCB0
aGF0IHRoaXMgY29tcGxleGl0eSBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+d29ydGggdGhlIGNvc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCldlbGwgdGhlIGNvbXBsZXhpdHkgZW5kcyB1cCBnb2luZyBpbiB0aGUgY2xpZW50
IG9yIHRoZSBzZXJ2ZXIuJm5ic3A7IEkgdGhpbmsgdGhhdCB0aGlzIGlzIGdlbmVyYWxseSBhIGNv
bXBsZXggcHJvYmxlbSB0byBzb2x2ZS4mbmJzcDsgT3BlcmF0b3JzIHdpbGwgbGlrZWx5IGFyZ3Vl
IHRoYXQgaXQgaXMgYmV0dGVyIHRoYXQgdGhlIGNvbXBsZXhpdHkgZ29lcyBpbiB0aGUgc2VydmVy
IHRvIGtlZXAgdGhlIGNsaWVudCBzaW1wbGUuJm5ic3A7IFNlcnZlciB2ZW5kb3JzIHdpbGwNCiBs
aWtlbHkgYXJndWUgZm9yIHRoZSByZXZlcnNlLjxicj4NCjxicj4NCk5vdGUsIHRoYXQgSSdtIHN0
aWxsIHNvbWV3aGF0IG9wZW4gdG8gd2hhdCB0aGUgcmlnaHQgc29sdXRpb24gc2hvdWxkIGJlIGhl
cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlNvdW5kcyB2ZXJ5IGNvbXBsaWNhdGVkIHRvIGltcGxlbWVudCBpbiB0
aGUgc2VydmVyLCBidXQgYXQgbGVhc3QgeW91IGF2b2lkIG11bHRpcGxlIHZhcmlhbnRzIG9mIGEg
ZGF0YXN0b3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SW5zdGVhZCB0aGUgc2VydmVyIGlzIHByb3ZpZGluZyB2YXJpb3VzIHRyYW5zZm9ybWF0
aW9ucyBiZXR3ZWVuIGRhdGEgbW9kZWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdpbGwgbWFrZSB0aGUgc3RhbmRhcmRzIG11Y2gg
bW9yZSBjb21wbGljYXRlZCBhbmQgaGVhdnl3ZWlnaHQgdG8gaW1wbGVtZW50LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgd2FzIHNvIGVh
c3kgYW5kIHNvIGltcG9ydGFudCwgdmVuZG9ycyB3b3VsZCBhbHJlYWR5IHN1cHBvcnQgaXQgaW4g
dGhlaXIgcHJvcHJpZXRhcnkgQVBJcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkluc3RlYWQgdmVuZG9ycyBkZWNpZGUgd2hlbiB0byBlbmQtb2Yt
bGlmZSBwcm9kdWN0cyBhbmQgZmVhdHVyZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYW5rcyw8YnI+
DQpSb2I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MsPGJy
Pg0KUm9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSSB0aGlu
ayB0aGUgcGxhbiBpcyB0byByZXdvcmQgc29tZSBvZiB0aGVzZSB0byBnZXQgY2xvc2VyIHRvIHRo
ZSBpbnRlbnRpb24gd2hpY2ggSSBiZWxpZXZlIGlzIHRvIGFsbG93IGZvciBzbW9vdGhlciB0cmFu
c2l0aW9uIGZyb20gb25lIG1vZHVsZSB0byB0aGUgbmV4dCB3aGlsZSBtYWtpbmcgaW5jb21wYXRp
YmxlIGJ1dCBtb3N0bHkgbm9uLWltcGFjdGluZyBjaGFuZ2VzLjxicj4NCjxicj4NClRoYW5rcyw8
YnI+DQpDaHJpcy48YnI+DQo8YnI+DQpBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+
Jmd0OyB3cml0ZXM6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGksPGJyPg0KPGJyPg0KSSBzdHJvbmdseSBvYmplY3QgdG8gcmVxdWlyZW1lbnQgMy4x
Ojxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAzLjEmbmJzcDsgVGhlIHNvbHV0
aW9uIE1VU1QgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBhbGxvdyBzZXJ2ZXJzIHRvPGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHN1cHBvcnQgZXhpc3RpbmcgY2xpZW50cyBpbiBhIGJhY2t3YXJkIGNvbXBhdGlibGUg
d2F5Ljxicj4NCjxicj4NCjxicj4NCjxicj4NClRoaXMgaXMgbm90IHdoYXQgc2VydmVycyBkbyB0
b2RheSBhdCBhbGwuPGJyPg0KVGhleSBwcm92aWRlIG9ubHkgb25lIHZlcnNpb24gb2YgYW4gaW1w
bGVtZW50ZWQgbW9kdWxlLCBhcyBzcGVjaWZpZWQgaW4gUkZDPGJyPg0KNzk1MC48YnI+DQo8YnI+
DQpJdCBpcyBhIHZlbmRvciBhbmQgb3BlcmF0b3IgZGVjaXNpb24gd2hlbiB0byB1cGdyYWRlIGEg
c2VydmVyIHN1Y2ggdGhhdDxicj4NCm5vbi1iYWNrd2FyZCBjb21wYXRpYmxlIGNoYW5nZXMgYXJl
IG1hZGUuIFRoZXkgbXVzdCBkZWNpZGUgaWYvd2hlbiBpdCBpcyBvazxicj4NCmJhc2VkIG9uIHRo
ZSBjbGllbnQgYXBwbGljYXRpb25zIGluIHVzZS48YnI+DQo8YnI+DQpUaGlzIHJlcXVpcmVtZW50
IHNheXMgeW91IGNhbm5vdCBtYWtlIGJhY2t3YXJkLWluY29tcGF0aWJsZSBjaGFuZ2VzPGJyPg0K
d2hpY2ggY29tcGxldGVseSBjb250cmFkaWN0cyByZXF1aXJlbWVudHMgMS4xIGFuZCAxLjIuPGJy
Pg0KPGJyPg0KSU1PIHJlcXVpcmVtZW50IDMuMSBzaG91bGQgYmUgcmVtb3ZlZCwgb3IgY2hhbmdl
IE1VU1QgdG8gTUFZPGJyPg0KPGJyPg0KPGJyPg0KQW5keTxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u
ZXRtb2QmYW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZhbXA7bT1OTEt6QjNSUnZHa0FkQmRTcXNiUGY5dmJJM09CY3lnNm56MlBiMFNqWkVjJmFt
cDtzPVVodjMxTTFmdnpoeXlzLTR0Q2dpSEdreHZrLXctZEtiQWFlaFBVZVFfaFkmYW1wO2U9IiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRt
b2QmYW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa
byZhbXA7bT1OTEt6QjNSUnZHa0FkQmRTcXNiUGY5dmJJM09CY3lnNm56MlBiMFNqWkVjJmFtcDtz
PVVodjMxTTFmdnpoeXlzLTR0Q2dpSEdreHZrLXctZEtiQWFlaFBVZVFfaFkmYW1wO2U9IiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8
L2E+PGJyPg0KLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_23F07D1B2816457A89DDBD457F77889Ejunipernet_--


From nobody Tue Jul 24 02:29:13 2018
Return-Path: 
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 A6A11130E40 for ; Tue, 24 Jul 2018 02:29:11 -0700 (PDT)
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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FraxoeQcXuZ8 for ; Tue, 24 Jul 2018 02:29:09 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7912872C for ; Tue, 24 Jul 2018 02:29:09 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 97BE4237D13C; Tue, 24 Jul 2018 11:29:08 +0200 (CEST)
Date: Tue, 24 Jul 2018 11:29:08 +0200
From: Juergen Schoenwaelder 
To: Christian Hopps 
Cc: Andy Bierman , NetMod WG 
Message-ID: <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , Andy Bierman , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87tvos1cse.fsf@chopps.org>
User-Agent: NeoMutt/20180716
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 09:29:12 -0000

On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:

> There are actual instances where small perhaps non-disruptive but
> incompatible changes are required. The example given to me for this
> type of change was when the original specification had an obvious
> bug (e.g., a range was incorrectly specified).

I strongly believe that fixing bugs is not a reason to change the
current versioning rules. Bugs come essentially in three flavors:

- A definition is messed up (i.e., a range, a pattern, a must
  expression) but the original intention of the definition is clear
  from the context (description clauses, references, ...). In this
  case, implementors will likely have done the right thing (or when
  they observed the problem they will likely have done the right
  thing).

- A definition is messed up but it is not clear from the context what
  the original intention of the definition was. In this case, there is
  a true ambiguity and implementors can rightfully have come to
  different conclusions how to deal with the conflict in the
  definition.

In the first case, I believe there is no issue with simply fixing the
messed up definition. I believe this kind of bug fixes is not
constrained by the YANG update rules.

In the second case, there is true ambiguity what implementations may
do and hence the safest approach is to deprecate the messed up
definition and to create a replacement.

Of course, in reality, things are often not so clear cut and hence it
takes some informed judgement what is the reasonable way to deal with
things. (A type two bug caught very early may be different from a type
two bug caught after several months of implementation and deployment.)

Sometimes we also have situations where a definition that was
originally OK turs out over time to be problematic as technology has
evolved. So after some time, the original definition starts to look
like a bug but it actually is not. The safe path forward is again to
create new definitions and to deprecate the old ones.

Now, for those in favour of moving from (module, path) to (module,
path, version), you loose the deprecated definition. So if you wan't
to allow for a transition period, there is a need to allow an old
client to work with the old definition and a new client to work with
the new definition. In the current naming scheme, this is not a
problem, with a (module, path, version) naming scheme this requires
some extra complexity.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Jul 24 08:12:04 2018
Return-Path: 
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 9ED95131125 for ; Tue, 24 Jul 2018 08:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 EzVxwhQ-gnH9 for ; Tue, 24 Jul 2018 08:11:58 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60E5131117 for ; Tue, 24 Jul 2018 08:11:57 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id q5-v6so3896672ljh.12 for ; Tue, 24 Jul 2018 08:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KMy+N9o/jcFO4a8JLGtpDNts/A6obcleAyOHXUyPbLw=; b=o//ztf5QIkkq3jPRd/nGwOgoWgrj0TZd9iQPgBfCg6GwvYD6yM/YV9eBBHpUMOGOSK GDiiWyezhVV3Vpw67XVNbfOLUzAG+hMPDynsjZHj3Tuf/OACBq0LQ84ugMn3L+jtv2nT SJiVwOzKQIpmwZZc6aotRW44y+zvR7Ncgi3PGYOVij3olnx0u3dR9L3miQlYwcIkejls w0TV47u9eO9QEiuUqajl27c/vk2O2JyoEtXl3UJfuO5T+NDnLoEYR+kQeDCXmn4Hk+M9 sZ2A0NaPBn5xFhjUqJ/jCm44XQ/cHCv+/za6iyhilkzDy4C8lhmLp/y9CYMsiqFShqFS JcyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KMy+N9o/jcFO4a8JLGtpDNts/A6obcleAyOHXUyPbLw=; b=Ygk1ghKsbfwYYhMAgNBaGLieH50vDUXpkdIY8SIAEJrNLs2zzqZ/WC+LOPNX0+kDJk TiGRPva30D7FRj+eOL/41mxruhbxSKEkoL2Z2TZbjvnc+O1AHj4+EZeAn9naiMVs4LKh unuyFdZ7bJG/IrMDFt7Nk1olWD/gUPkPFH+XPh+lcFK7YD4Z0X+6M5xPHmBzSbKAPzKA 7xeXn3jUv5lD19K6tXjHAimIpwWXIik5f1WEG37m3LAG5OY51bDU8RmTKIBKR9dEZrWu cy9N2uuBDWh+p2rcvL+/9mJXqbxZ/cB+YqzLkOa0gKScFyHE5RQVAyRu5+ymqDe7be6d P5YA==
X-Gm-Message-State: AOUpUlFqt0JrBASWFlWXOlceqHmzPqv9LdQe6HzTCVM52CfXe+PpCgjT GAyQYK0gawz+8CpTukLCWfIp/hOhtGPVsNIUkg9eZuKo
X-Google-Smtp-Source: AAOMgpdiiCvKEwAe8zQcKFupBNZdLhLKq52s3Au9RIsz5/z41dHQrKFp6OPNhwq7uFh7/LgJnWMYmlP9gUgf2yRymF0=
X-Received: by 2002:a2e:97c8:: with SMTP id m8-v6mr13427231ljj.52.1532445116111;  Tue, 24 Jul 2018 08:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 08:11:54 -0700 (PDT)
In-Reply-To: <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Tue, 24 Jul 2018 08:11:54 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  Christian Hopps , Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000c8a9650571c02e10"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 15:12:02 -0000

--000000000000c8a9650571c02e10
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:
>
> > There are actual instances where small perhaps non-disruptive but
> > incompatible changes are required. The example given to me for this
> > type of change was when the original specification had an obvious
> > bug (e.g., a range was incorrectly specified).
>
> I strongly believe that fixing bugs is not a reason to change the
> current versioning rules. Bugs come essentially in three flavors:
>
> - A definition is messed up (i.e., a range, a pattern, a must
>   expression) but the original intention of the definition is clear
>   from the context (description clauses, references, ...). In this
>   case, implementors will likely have done the right thing (or when
>   they observed the problem they will likely have done the right
>   thing).
>
> - A definition is messed up but it is not clear from the context what
>   the original intention of the definition was. In this case, there is
>   a true ambiguity and implementors can rightfully have come to
>   different conclusions how to deal with the conflict in the
>   definition.
>
> In the first case, I believe there is no issue with simply fixing the
> messed up definition. I believe this kind of bug fixes is not
> constrained by the YANG update rules.
>
> In the second case, there is true ambiguity what implementations may
> do and hence the safest approach is to deprecate the messed up
> definition and to create a replacement.
>
> Of course, in reality, things are often not so clear cut and hence it
> takes some informed judgement what is the reasonable way to deal with
> things. (A type two bug caught very early may be different from a type
> two bug caught after several months of implementation and deployment.)
>
> Sometimes we also have situations where a definition that was
> originally OK turs out over time to be problematic as technology has
> evolved. So after some time, the original definition starts to look
> like a bug but it actually is not. The safe path forward is again to
> create new definitions and to deprecate the old ones.
>
> Now, for those in favour of moving from (module, path) to (module,
> path, version), you loose the deprecated definition. So if you wan't
> to allow for a transition period, there is a need to allow an old
> client to work with the old definition and a new client to work with
> the new definition. In the current naming scheme, this is not a
> problem, with a (module, path, version) naming scheme this requires
> some extra complexity.
>
>

The problem with versioning the "YANG API" is that it is not possible to
isolate
individual modules and say "I pick version 1.0.3 of module foo and version
2.1.1
of module bar". And every client can pick a different arbitrary subset of
mix-and-match YANG modules.

Well YANG does not work that way.  There is no concept of a YANG package.
There is no concept of a group of modules/versions/features that are
not divisible within a server implementation.

The other problem is what you are pointing out.
It would be far easier to just fix the clients and the servers, not just
the servers.
Why is it OK for the client developer to decide "we are sticking with the
defective version of the module and not going to upgrade to
the fixed version like the server developers have done."


/js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--000000000000c8a9650571c02e10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian =
Hopps wrote:



> There are actual instances where small perhaps non-disruptive but

> incompatible changes are required. The example given to me for this
> type of change was when the original specification had an obvious

> bug (e.g., a range was incorrectly specified).



I strongly believe that fixing bugs is not a reason to change the

current versioning rules. Bugs come essentially in three flavors:



- A definition is messed up (i.e., a range, a pattern, a must

=C2=A0 expression) but the original intention of the definition is clear
=C2=A0 from the context (description clauses, references, ...). In this

=C2=A0 case, implementors will likely have done the right thing (or when
=C2=A0 they observed the problem they will likely have done the right

=C2=A0 thing).



- A definition is messed up but it is not clear from the context what

=C2=A0 the original intention of the definition was. In this case, there is=


=C2=A0 a true ambiguity and implementors can rightfully have come to

=C2=A0 different conclusions how to deal with the conflict in the

=C2=A0 definition.



In the first case, I believe there is no issue with simply fixing the

messed up definition. I believe this kind of bug fixes is not

constrained by the YANG update rules.



In the second case, there is true ambiguity what implementations may

do and hence the safest approach is to deprecate the messed up

definition and to create a replacement.



Of course, in reality, things are often not so clear cut and hence it

takes some informed judgement what is the reasonable way to deal with

things. (A type two bug caught very early may be different from a type

two bug caught after several months of implementation and deployment.)



Sometimes we also have situations where a definition that was

originally OK turs out over time to be problematic as technology has

evolved. So after some time, the original definition starts to look

like a bug but it actually is not. The safe path forward is again to

create new definitions and to deprecate the old ones.



Now, for those in favour of moving from (module, path) to (module,

path, version), you loose the deprecated definition. So if you wan't
to allow for a transition period, there is a need to allow an old

client to work with the old definition and a new client to work with

the new definition. In the current naming scheme, this is not a

problem, with a (module, path, version) naming scheme this requires

some extra complexity.




The problem with versioning the "=
;YANG API" is that it is not possible to isolate
individual =
modules and say "I pick version 1.0.3 of module foo and version 2.1.1<=
/div>
of module bar". And every client can pick a different arbitr=
ary subset of
mix-and-match YANG modules.=C2=A0

Well YANG does not work that way.=C2=A0 There is no concept of a YA=
NG package.
There is no concept of a group of modules/versions/fe=
atures that are
not divisible within a server implementation.=C2=
=A0

The other problem is what you are pointing out=
.
It would be far easier to just fix the clients and the servers,=
 not just the servers.
Why is it OK for the client developer to d=
ecide "we are sticking with the
defective version of the mod=
ule and not going to upgrade to
the fixed version like the server=
 developers have done."



/js

Andy
=C2=A0=




-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--000000000000c8a9650571c02e10--


From nobody Tue Jul 24 08:32:14 2018
Return-Path: 
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 A7983131140 for ; Tue, 24 Jul 2018 08:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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
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 1NRTevnJSG6L for ; Tue, 24 Jul 2018 08:32:09 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668F1131145 for ; Tue, 24 Jul 2018 08:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15740; q=dns/txt; s=iport; t=1532446328; x=1533655928; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3nQvLEssuffWdF1OPRwjiqY81FgO5tiBaJyORQrOz/8=; b=TvzGJYGF2GGG9sFvHWcMwpykRucdhkY4bzaEzuIXg8y9i8/LFlro//mu 7EJ2w/eLEUsJ2UwHdzJzAuc3yq3GjwyxElt5F1zT+W5nGH1JUQ97KVAKH Typ4iYVCMHMhA/BqJckVUWjxq6XWti3ga9dlef2tlW72cgzeGRFTpr34e o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQByRVdb/xbLJq1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDH4ERbRIog36IY41okDOHDAsYAQqDEnFGAoJuOBQBAgE?= =?us-ascii?q?BAgEBAm0cDIU2AQEBAQIBAQEhSxAJAgkCEAgnAwICGwwfEQYBDAYCAQGDHAG?= =?us-ascii?q?BdwgPkyibR4EuH4Q+hXUFBYpUP4E4gmqDGwEBgUoJLiaCOoJVAogShEuNEwm?= =?us-ascii?q?PLQaBRYZchVOIBIRKhVWBWCGBUjMaCBsVO4JpgXVYg2eEYYU/PjCLd4JHAQE?=
X-IronPort-AV: E=Sophos;i="5.51,398,1526342400"; d="scan'208,217";a="5377130"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 15:32:06 +0000
Received: from [10.63.23.138] (dhcp-ensft1-uk-vla370-10-63-23-138.cisco.com [10.63.23.138]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6OFW5XM014185; Tue, 24 Jul 2018 15:32:05 GMT
To: Andy Bierman , Juergen Schoenwaelder , Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 24 Jul 2018 16:32:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9ABCDA2589A3F4B42D316707"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.138, dhcp-ensft1-uk-vla370-10-63-23-138.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 15:32:12 -0000

This is a multi-part message in MIME format.
--------------9ABCDA2589A3F4B42D316707
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 24/07/2018 16:11, Andy Bierman wrote:
>
>
> On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:
>
>     > There are actual instances where small perhaps non-disruptive but
>     > incompatible changes are required. The example given to me for this
>     > type of change was when the original specification had an obvious
>     > bug (e.g., a range was incorrectly specified).
>
>     I strongly believe that fixing bugs is not a reason to change the
>     current versioning rules. Bugs come essentially in three flavors:
>
>     - A definition is messed up (i.e., a range, a pattern, a must
>       expression) but the original intention of the definition is clear
>       from the context (description clauses, references, ...). In this
>       case, implementors will likely have done the right thing (or when
>       they observed the problem they will likely have done the right
>       thing).
>
>     - A definition is messed up but it is not clear from the context what
>       the original intention of the definition was. In this case, there is
>       a true ambiguity and implementors can rightfully have come to
>       different conclusions how to deal with the conflict in the
>       definition.
>
>     In the first case, I believe there is no issue with simply fixing the
>     messed up definition. I believe this kind of bug fixes is not
>     constrained by the YANG update rules.
>
>     In the second case, there is true ambiguity what implementations may
>     do and hence the safest approach is to deprecate the messed up
>     definition and to create a replacement.
>
>     Of course, in reality, things are often not so clear cut and hence it
>     takes some informed judgement what is the reasonable way to deal with
>     things. (A type two bug caught very early may be different from a type
>     two bug caught after several months of implementation and deployment.)
>
>     Sometimes we also have situations where a definition that was
>     originally OK turs out over time to be problematic as technology has
>     evolved. So after some time, the original definition starts to look
>     like a bug but it actually is not. The safe path forward is again to
>     create new definitions and to deprecate the old ones.
>
>     Now, for those in favour of moving from (module, path) to (module,
>     path, version), you loose the deprecated definition. So if you wan't
>     to allow for a transition period, there is a need to allow an old
>     client to work with the old definition and a new client to work with
>     the new definition. In the current naming scheme, this is not a
>     problem, with a (module, path, version) naming scheme this requires
>     some extra complexity.
>
>
>
> The problem with versioning the "YANG API" is that it is not possible 
> to isolate
> individual modules and say "I pick version 1.0.3 of module foo and 
> version 2.1.1
> of module bar". And every client can pick a different arbitrary subset of
> mix-and-match YANG modules.
>
> Well YANG does not work that way.  There is no concept of a YANG package.
> There is no concept of a group of modules/versions/features that are
> not divisible within a server implementation.
>
> The other problem is what you are pointing out..
> It would be far easier to just fix the clients and the servers, not 
> just the servers.
> Why is it OK for the client developer to decide "we are sticking with the
> defective version of the module and not going to upgrade to
> the fixed version like the server developers have done."

One of the aims of the YANG versioning work is to give more information 
to the client about whether they are likely to be impacted by upgrading 
to a new set of modules.  For me, I think that the most useful thing is 
if this is done by comparing the full schema between old and new 
releases (including module versions, enabled features, and deviations), 
and then identifying the data nodes that have been changed in a 
backwards compatible way, and those that have been changed in a non 
backwards compatible way (if that is allowed).

E.g. even it is a change is an obvious bugfix, it still makes sense to 
flag that change so that client implementations can be checked to ensure 
that they don't break.

But if fixing a definition requires a whole new module name then I think 
that causes lots of problems (e.g. consider needing to change 
ief-interfaces to ietf-interfaces-v2 because of changing one random 
leaf).  The YANG 1.1 way is to define a new definition and then 
deprecate the broken one.  But this has negative consequences as well, 
e.g. does writing to the old leaf automatically also write to the new 
leaf at the same time?  Are both returned in a get request? What if a 
different client only writes to the new leaf?

Thanks,
Rob


>
>
>     /js
>
>
> Andy
>
>
>     -- 
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------9ABCDA2589A3F4B42D316707
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 24/07/2018 16:11, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Jul 24, 2018 at 2:29 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Sat,
              Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:

              

              > There are actual instances where small perhaps
              non-disruptive but

              > incompatible changes are required. The example given
              to me for this

              > type of change was when the original specification
              had an obvious

              > bug (e.g., a range was incorrectly specified).

              

              I strongly believe that fixing bugs is not a reason to
              change the

              current versioning rules. Bugs come essentially in three
              flavors:

              

              - A definition is messed up (i.e., a range, a pattern, a
              must

                expression) but the original intention of the definition
              is clear

                from the context (description clauses, references, ...).
              In this

                case, implementors will likely have done the right thing
              (or when

                they observed the problem they will likely have done the
              right

                thing).

              

              - A definition is messed up but it is not clear from the
              context what

                the original intention of the definition was. In this
              case, there is

                a true ambiguity and implementors can rightfully have
              come to

                different conclusions how to deal with the conflict in
              the

                definition.

              

              In the first case, I believe there is no issue with simply
              fixing the

              messed up definition. I believe this kind of bug fixes is
              not

              constrained by the YANG update rules.

              

              In the second case, there is true ambiguity what
              implementations may

              do and hence the safest approach is to deprecate the
              messed up

              definition and to create a replacement.

              

              Of course, in reality, things are often not so clear cut
              and hence it

              takes some informed judgement what is the reasonable way
              to deal with

              things. (A type two bug caught very early may be different
              from a type

              two bug caught after several months of implementation and
              deployment.)

              

              Sometimes we also have situations where a definition that
              was

              originally OK turs out over time to be problematic as
              technology has

              evolved. So after some time, the original definition
              starts to look

              like a bug but it actually is not. The safe path forward
              is again to

              create new definitions and to deprecate the old ones.

              

              Now, for those in favour of moving from (module, path) to
              (module,

              path, version), you loose the deprecated definition. So if
              you wan't

              to allow for a transition period, there is a need to allow
              an old

              client to work with the old definition and a new client to
              work with

              the new definition. In the current naming scheme, this is
              not a

              problem, with a (module, path, version) naming scheme this
              requires

              some extra complexity.

              

                

            


            

            


            

            
The problem with versioning the "YANG API" is that it
              is not possible to isolate

            
individual modules and say "I pick version 1.0.3 of
              module foo and version 2.1.1

            
of module bar". And every client can pick a different
              arbitrary subset of

            
mix-and-match YANG modules. 

            


            

            
Well YANG does not work that way.  There is no concept
              of a YANG package.

            
There is no concept of a group of
              modules/versions/features that are

            
not divisible within a server implementation. 

            


            

            
The other problem is what you are pointing out..

            
It would be far easier to just fix the clients and the
              servers, not just the servers.

            
Why is it OK for the client developer to decide "we are
              sticking with the

            
defective version of the module and not going to
              upgrade to

            
the fixed version like the server developers have
              done."

          

        

      

    

    

    One of the aims of the YANG versioning work is to give more
    information to the client about whether they are likely to be
    impacted by upgrading to a new set of modules.  For me, I think that
    the most useful thing is if this is done by comparing the full
    schema between old and new releases (including module versions,
    enabled features, and deviations), and then identifying the data
    nodes that have been changed in a backwards compatible way, and
    those that have been changed in a non backwards compatible way (if
    that is allowed).

    

    E.g. even it is a change is an obvious bugfix, it still makes sense
    to flag that change so that client implementations can be checked to
    ensure that they don't break.

    

    But if fixing a definition requires a whole new module name then I
    think that causes lots of problems (e.g. consider needing to change
    ief-interfaces to ietf-interfaces-v2 because of changing one random
    leaf).  The YANG 1.1 way is to define a new definition and then
    deprecate the broken one.  But this has negative consequences as
    well, e.g. does writing to the old leaf automatically also write to
    the new leaf at the same time?  Are both returned in a get request? 
    What if a different client only writes to the new leaf?

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            

                  /js

                

            


            

            
Andy

            
 

            

                  

                  -- 

                  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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    

  


--------------9ABCDA2589A3F4B42D316707--


From nobody Tue Jul 24 09:07:20 2018
Return-Path: 
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 7874E131162 for ; Tue, 24 Jul 2018 09:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 rzUiwONpiz2H for ; Tue, 24 Jul 2018 09:07:15 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7A5131156 for ; Tue, 24 Jul 2018 09:07:14 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id l16-v6so3347112lfc.13 for ; Tue, 24 Jul 2018 09:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=catevl4XRe6ZQx5GlTAL/EMDpu1kfBnz/bUINOfmXCw=; b=rNfbmw4mm88jXEOrIajw7CwjD5OwS8q4qkvdW6Fn/6vewPPTpBYiBgjxXEdO5r/Cs9 EXLfXRozTL2q5ZQLwXOEHcQaw4l5/SaBL9h2aVBr8ZR/0WGKDxVXU6NsEdgHV7PvOTGw E4fRGob17lAoJ2hdoQHiF1p+RzwiSzSpcNyf2hfknm3jWyVxQWFqVCF0A+9rdYwHxkF8 2aNCmjzTyCxz/fOwJi2ujmiOc9RI4DrxoUIz6r4oRumBBwg6lXwBtSOPNSEWOrEsmcsA kLrHx2v3WZvIdvoZdh/RFsHH7hLTfODMNsrFEJNAPWCyhln3nwRtU9l5EWCTLhCzXMz2 giJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=catevl4XRe6ZQx5GlTAL/EMDpu1kfBnz/bUINOfmXCw=; b=qDO6iuj+yp3yctOzg9JZnrvhum40nrnCNuPBhsA9EkaoxrqMsOk4ZpjDYxZAOR/Rrk JhuCTbBg0vbhPL2gjng2hWXOrQioZRJiMSw7js5KQcRrdNH7HphB9OM+xsyf9xHsVNwf PeDxBepRdgEoSeuXwlQfh9jSv00mkrwwEtzvF2E0n9fAesXVyVbIaU7nkMUWI1lN66kG Glpuag6PKUDOYUo2byf4Rgv+jv7UueHCc08wE4ai50n0bg+QRpP1xKF7NuLLJzK9fTwd REdPTjWuQ6sHpbZdhPBQRAtXGReGY7TYa/8bzZGMqn2QW4geFTUvwdaoPRToQdGhnD5J 2iqQ==
X-Gm-Message-State: AOUpUlE4A/9ukRWRD3Ztsz9co/iUSdqKIaDEEfcGVSItsHqAn85txFEl 28F/r1ymEc9JQw2PCcJdCs782ULDyqbeoY5OYSYs4A==
X-Google-Smtp-Source: AAOMgpdYjvx+IteEiFeN7I3eXS+D2qzQZEERokLn+/JOZJuV4W5lAENE+SQFxbKaYX7dFFnQwj17FmmK4lWv02tmzCQ=
X-Received: by 2002:a19:1460:: with SMTP id k93-v6mr10149425lfi.15.1532448432365;  Tue, 24 Jul 2018 09:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:07:11 -0700 (PDT)
In-Reply-To: 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>  
From: Andy Bierman 
Date: Tue, 24 Jul 2018 09:07:11 -0700
Message-ID: 
To: Robert Wilton 
Cc: Juergen Schoenwaelder ,  Christian Hopps , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000072b72b0571c0f4ee"
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 16:07:19 -0000

--00000000000072b72b0571c0f4ee
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton  wrote:

>
>
> On 24/07/2018 16:11, Andy Bierman wrote:
>
>
>
> On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:
>>
>> > There are actual instances where small perhaps non-disruptive but
>> > incompatible changes are required. The example given to me for this
>> > type of change was when the original specification had an obvious
>> > bug (e.g., a range was incorrectly specified).
>>
>> I strongly believe that fixing bugs is not a reason to change the
>> current versioning rules. Bugs come essentially in three flavors:
>>
>> - A definition is messed up (i.e., a range, a pattern, a must
>>   expression) but the original intention of the definition is clear
>>   from the context (description clauses, references, ...). In this
>>   case, implementors will likely have done the right thing (or when
>>   they observed the problem they will likely have done the right
>>   thing).
>>
>> - A definition is messed up but it is not clear from the context what
>>   the original intention of the definition was. In this case, there is
>>   a true ambiguity and implementors can rightfully have come to
>>   different conclusions how to deal with the conflict in the
>>   definition.
>>
>> In the first case, I believe there is no issue with simply fixing the
>> messed up definition. I believe this kind of bug fixes is not
>> constrained by the YANG update rules.
>>
>> In the second case, there is true ambiguity what implementations may
>> do and hence the safest approach is to deprecate the messed up
>> definition and to create a replacement.
>>
>> Of course, in reality, things are often not so clear cut and hence it
>> takes some informed judgement what is the reasonable way to deal with
>> things. (A type two bug caught very early may be different from a type
>> two bug caught after several months of implementation and deployment.)
>>
>> Sometimes we also have situations where a definition that was
>> originally OK turs out over time to be problematic as technology has
>> evolved. So after some time, the original definition starts to look
>> like a bug but it actually is not. The safe path forward is again to
>> create new definitions and to deprecate the old ones.
>>
>> Now, for those in favour of moving from (module, path) to (module,
>> path, version), you loose the deprecated definition. So if you wan't
>> to allow for a transition period, there is a need to allow an old
>> client to work with the old definition and a new client to work with
>> the new definition. In the current naming scheme, this is not a
>> problem, with a (module, path, version) naming scheme this requires
>> some extra complexity.
>>
>>
>
> The problem with versioning the "YANG API" is that it is not possible to
> isolate
> individual modules and say "I pick version 1.0.3 of module foo and version
> 2.1.1
> of module bar". And every client can pick a different arbitrary subset of
> mix-and-match YANG modules.
>
> Well YANG does not work that way.  There is no concept of a YANG package.
> There is no concept of a group of modules/versions/features that are
> not divisible within a server implementation.
>
> The other problem is what you are pointing out..
> It would be far easier to just fix the clients and the servers, not just
> the servers.
> Why is it OK for the client developer to decide "we are sticking with the
> defective version of the module and not going to upgrade to
> the fixed version like the server developers have done."
>
>
> One of the aims of the YANG versioning work is to give more information to
> the client about whether they are likely to be impacted by upgrading to a
> new set of modules.  For me, I think that the most useful thing is if this
> is done by comparing the full schema between old and new releases
> (including module versions, enabled features, and deviations), and then
> identifying the data nodes that have been changed in a backwards compatible
> way, and those that have been changed in a non backwards compatible way (if
> that is allowed).
>
> E.g. even it is a change is an obvious bugfix, it still makes sense to
> flag that change so that client implementations can be checked to ensure
> that they don't break.
>
> But if fixing a definition requires a whole new module name then I think
> that causes lots of problems (e.g. consider needing to change
> ief-interfaces to ietf-interfaces-v2 because of changing one random leaf).
> The YANG 1.1 way is to define a new definition and then deprecate the
> broken one.  But this has negative consequences as well, e.g. does writing
> to the old leaf automatically also write to the new leaf at the same time?
> Are both returned in a get request?  What if a different client only writes
> to the new leaf?
>
>
I agree a new module is not required.
I like SEMVER. It is still better to follow the YANG update rules, but I am
OK
with using the major version to indicate a non-backward-compatible change.
IMO it should not be fine-grained (e.g., SEMVER per object).
The scope of the standard should just be to identify versions with SEMVER
and fix import-stmt.

I think a server could version the API (all modules, not client-picked).
Not convinced this is a high priority at all, or that it would be easy to
standardize.

Thanks,
> Rob
>
>
Andy


>
>
>
> /js
>>
>
> Andy
>
>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>

--00000000000072b72b0571c0f4ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 24/07/2018 16:1=
1, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Tue, Jul 24, 2018 at 2:29 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jaco=
bs-university.de>
            wrote:

            
On Sat,
              Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:

              

              > There are actual instances where small perhaps
              non-disruptive but

              > incompatible changes are required. The example given
              to me for this

              > type of change was when the original specification
              had an obvious

              > bug (e.g., a range was incorrectly specified).

              

              I strongly believe that fixing bugs is not a reason to
              change the

              current versioning rules. Bugs come essentially in three
              flavors:

              

              - A definition is messed up (i.e., a range, a pattern, a
              must

              =C2=A0 expression) but the original intention of the definiti=
on
              is clear

              =C2=A0 from the context (description clauses, references, ...=
).
              In this

              =C2=A0 case, implementors will likely have done the right thi=
ng
              (or when

              =C2=A0 they observed the problem they will likely have done t=
he
              right

              =C2=A0 thing).

              

              - A definition is messed up but it is not clear from the
              context what

              =C2=A0 the original intention of the definition was. In this
              case, there is

              =C2=A0 a true ambiguity and implementors can rightfully have
              come to

              =C2=A0 different conclusions how to deal with the conflict in
              the

              =C2=A0 definition.

              

              In the first case, I believe there is no issue with simply
              fixing the

              messed up definition. I believe this kind of bug fixes is
              not

              constrained by the YANG update rules.

              

              In the second case, there is true ambiguity what
              implementations may

              do and hence the safest approach is to deprecate the
              messed up

              definition and to create a replacement.

              

              Of course, in reality, things are often not so clear cut
              and hence it

              takes some informed judgement what is the reasonable way
              to deal with

              things. (A type two bug caught very early may be different
              from a type

              two bug caught after several months of implementation and
              deployment.)

              

              Sometimes we also have situations where a definition that
              was

              originally OK turs out over time to be problematic as
              technology has

              evolved. So after some time, the original definition
              starts to look

              like a bug but it actually is not. The safe path forward
              is again to

              create new definitions and to deprecate the old ones.

              

              Now, for those in favour of moving from (module, path) to
              (module,

              path, version), you loose the deprecated definition. So if
              you wan't

              to allow for a transition period, there is a need to allow
              an old

              client to work with the old definition and a new client to
              work with

              the new definition. In the current naming scheme, this is
              not a

              problem, with a (module, path, version) naming scheme this
              requires

              some extra complexity.

              

                

            


            

            


            

            
The problem with versioning the "YANG API" is th=
at it
              is not possible to isolate

            
individual modules and say "I pick version 1.0.3 of
              module foo and version 2.1.1

            
of module bar". And every client can pick a different
              arbitrary subset of

            
mix-and-match YANG modules.=C2=A0

            


            

            
Well YANG does not work that way.=C2=A0 There is no concep=
t
              of a YANG package.

            
There is no concept of a group of
              modules/versions/features that are

            
not divisible within a server implementation.=C2=A0

            


            

            
The other problem is what you are pointing out..

            
It would be far easier to just fix the clients and the
              servers, not just the servers.

            
Why is it OK for the client developer to decide "we a=
re
              sticking with the

            
defective version of the module and not going to
              upgrade to

            
the fixed version like the server developers have
              done."

          

        

      

    

    

    One of the aims of the YANG versioning work is to give more
    information to the client about whether they are likely to be
    impacted by upgrading to a new set of modules.=C2=A0 For me, I think th=
at
    the most useful thing is if this is done by comparing the full
    schema between old and new releases (including module versions,
    enabled features, and deviations), and then identifying the data
    nodes that have been changed in a backwards compatible way, and
    those that have been changed in a non backwards compatible way (if
    that is allowed).

    

    E.g. even it is a change is an obvious bugfix, it still makes sense
    to flag that change so that client implementations can be checked to
    ensure that they don't break.

    

    But if fixing a definition requires a whole new module name then I
    think that causes lots of problems (e.g. consider needing to change
    ief-interfaces to ietf-interfaces-v2 because of changing one random
    leaf).=C2=A0 The YANG 1.1 way is to define a new definition and then
    deprecate the broken one.=C2=A0 But this has negative consequences as
    well, e.g. does writing to the old leaf automatically also write to
    the new leaf at the same time?=C2=A0 Are both returned in a get request=
?=C2=A0
    What if a different client only writes to the new leaf?

    

I agree a new module is not =
required.
I like SEMVER. It is still better to follow the YANG up=
date rules, but I am OK
with using the major version to indicate =
a non-backward-compatible change.=C2=A0
IMO it should not be fine=
-grained (e.g., SEMVER per object).
The scope of the standard sho=
uld just be to identify versions with SEMVER and fix import-stmt.

I think a server could version the API (all modules, not cl=
ient-picked).
Not convinced this is a high priority at all, or th=
at it would be easy to standardize.


    Thanks,

    Rob

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

    

      

        

          

            


            

            


            

            

                  /js

                

            


            

            
Andy

            
=C2=A0

            

                  

                  -- 

                  Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<https://www.jacobs-university.de/>

                

          

          

        

      

      

      

      

      
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/=
mailman/listinfo/netmod


    

    

  






--00000000000072b72b0571c0f4ee--


From nobody Wed Jul 25 04:03:14 2018
Return-Path: 
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 E44FE130E41 for ; Wed, 25 Jul 2018 04:03:12 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 Atb2MrbQMTLn for ; Wed, 25 Jul 2018 04:03:10 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 29A86127598 for ; Wed, 25 Jul 2018 04:03:10 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id CFB70237FDE0; Wed, 25 Jul 2018 13:03:08 +0200 (CEST)
Date: Wed, 25 Jul 2018 13:03:08 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Christian Hopps , NetMod WG 
Message-ID: <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jul 2018 11:03:13 -0000

On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote:
> 
> But if fixing a definition requires a whole new module name then I think
> that causes lots of problems (e.g. consider needing to change ief-interfaces
> to ietf-interfaces-v2 because of changing one random leaf).

I assume this depends a lot on how clients are written but chances are
that a significant portion of clients are written such in such a way
that dealing with multiple namespaces is difficult. (But yeah, dealing
with multiple versions in the same namespace likely is also difficult
for them.)

What really chances here is the adaptation process: Today, a client
will not bother to use a new namespace (a new version) unless it was
programmed to do so (opt-in). The proposed new versioning scheme
effectively means that client will automatically use new versions
until the client got told to be careful where necessary (and I assume
that in most cases this means until the client failed and then got
fixed, an opt-out process).

I can understand why some people believe a conservative opt-in
approach is desirable for them and I can understand why some other
people believe an optimistic approach opt-out approach is desirable
for them. There are likely good arguments for both and this makes it
difficult to pick one.

At the end, code that needs to support multiple versions is always
going to be to some extend ugly. Whether the uglyness is in namespace
bindings or version checks is likely more a question of taste. I
believe code uglyness is not really driving this but the desire to be
more agile and "lets release and then fix clients when they break" may
be more dynamic than "lets release and then wait for clients to get
updated".

> The YANG 1.1 way is to define a new definition and then deprecate
> the broken one. But this has negative consequences as well,
> e.g. does writing to the old leaf automatically also write to the
> new leaf at the same time? Are both returned in a get request? What
> if a different client only writes to the new leaf?

Sure, duplicate or overlapping config objects is something we usually
try to avoid. In general, I assume a server would try to keep such
overlapping leafs in sync. But then, this is an issue that appears in
any scheme that allows access to multiple versions of a leaf (or
overlapping leafs in general, i.e. a standard object and a vendor
version of it).

The point I was trying to make was a different one, namely that today
we have a way to expose multiple versions of a leaf by using a new
(module, path) name while with a (module, path, version) naming
system, our protocols need extensions to expose multiple versions of a
leaf (or we declare that servers will never expose multiple versions
and that clients must always adapt to the version currently offered by
a server).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jul 25 09:25:58 2018
Return-Path: 
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 C2C4C130DD4 for ; Wed, 25 Jul 2018 09:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 a4wcor9ZEmOp for ; Wed, 25 Jul 2018 09:25:54 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310EB126BED for ; Wed, 25 Jul 2018 09:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7618; q=dns/txt; s=iport; t=1532535954; x=1533745554; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=MCF/p8eUQkaJJ1Pk0FCGqWRmMeVHXD2ZYMHJ00AWaNk=; b=ZwcEhZjbZwg7liuZRaJM0256sYrcfrSb+F96a9wWkUCVoakhwcd794Tu fACJsQ2ArxkGYM812XQlxjWJljBEkoSwu0lsxbFddu85GbfKRfHT90vyM /UZXSwsYF4G99DWcp2V+pqF0aO86gNUMBJr4oGlGdsqliYN9+pZfHtF8/ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQA6pFhb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMfghCEJmKIA408LJVdgWYLhGwCgwc4FAECAQECAQECbSi?= =?us-ascii?q?FNgEBAQMBIw8BBTQSCwsYAgIRFQICVwYBDAgBAYMcgXgIsDOBLoRdhXyBC4d?= =?us-ascii?q?oJoFBP4E4gjY1hDgvVYJCglUCh00ZhHuBLYtnCY8vBogqhVWMVoVXgVghgVI?= =?us-ascii?q?zGggbFYMlgkyOBz6PIQEB?=
X-IronPort-AV: E=Sophos;i="5.51,401,1526342400";  d="scan'208";a="5404237"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 16:25:33 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6PGPWJC005420; Wed, 25 Jul 2018 16:25:32 GMT
To: Andy Bierman , Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com>
Date: Wed, 25 Jul 2018 17:25:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jul 2018 16:25:57 -0000

On 25/07/2018 12:03, Juergen Schoenwaelder wrote:
> On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote:
>> But if fixing a definition requires a whole new module name then I think
>> that causes lots of problems (e.g. consider needing to change ief-interfaces
>> to ietf-interfaces-v2 because of changing one random leaf).
> I assume this depends a lot on how clients are written but chances are
> that a significant portion of clients are written such in such a way
> that dealing with multiple namespaces is difficult. (But yeah, dealing
> with multiple versions in the same namespace likely is also difficult
> for them.)
Yes, I think that this comes down to client implementation.

If clients are looking for a universally unique identifier for a given 
datanode then I think that they already have to consider the triple 
(module, path, X), where X potentially covers:
(i) per device/vendor/release deviations,
(ii) possibly which revision a data node was first introduced in, or 
obsoleted in,
(iii) different YANG features enabled on different devices,
(iv) semantic versioning - at least in the case of the OpenConfig YANG 
modules,
(v) non backwards compatible changes (both bug fixes, and more 
significant refactoring).

Hence, I'm still not really convinced that adding a semantic version 
number is introducing something that robust clients don't have to 
already have handle today (even if they didn't have to cope with (iv) or 
(v), they still may have to cope with (i) and (ii) and (iii) regardless.

One alternative way to build a robust client would be to have an 
internally defined schema by the client (perhaps based on open models, 
or perhaps a particular version of vendor models, possibly with some 
deviations, or their own model) which they can then map onto one or more 
per device schema.  So within a particular schema (internal or device 
specific) then (module name, path) uniquely resolves to a data node with 
particular properties; but between different schema (e.g. for each 
different device) then the same (module name, path) pair is allowed to 
resolve to a different uniquely defined property.

A layer of mapping is performed between the internal schema and the 
device schema for whichever devices/sw-versions it needs to interoperate 
with.  The more closely the two schema align, the easier the mapping is 
to achieve.  This is also why, ultimately, that determining whether 
changes are backwards compatible or not needs to be done at the schema 
level (which takes into account deviations and features), and also the 
per data node level.

It is also worth pointing out that the version selection scheme that I 
described is really just a way to potentially move the mapping layer 
from the client code to the server.  Fundamentally it is doing the same 
job and serving the same purpose.


>
> What really chances here is the adaptation process: Today, a client
> will not bother to use a new namespace (a new version) unless it was
> programmed to do so (opt-in). The proposed new versioning scheme
> effectively means that client will automatically use new versions
> until the client got told to be careful where necessary (and I assume
> that in most cases this means until the client failed and then got
> fixed, an opt-out process).
My main concern with using module name for major version changes is that 
it forces a name change for each data node in that module, regardless of 
whether that node has actually changed.  This inherently feels like the 
wrong this to do.  If a data node hasn't changed then ideally you want 
it to remain unchanged on the same path.  So the alternative way that 
RFC 7950 supports today is to keep the module name the same but 
introduce new names for all identifiers that have been changed in a non 
backwards compatible way, making use of status deprecated/obsolete.

However, it isn't clear to me that handling the old and new values 
within the same schema is always a good thing to do.  I generally prefer 
the idea of doing version selection (if anyone chooses to support this) 
so that a given value is only reported once.

> I can understand why some people believe a conservative opt-in
> approach is desirable for them and I can understand why some other
> people believe an optimistic approach opt-out approach is desirable
> for them. There are likely good arguments for both and this makes it
> difficult to pick one.
My feeling (and I don't have hard evidence to back this up) is that 
clients are generally less impacted by keeping the name the same rather 
than changing the module name for every major version change.

>
> At the end, code that needs to support multiple versions is always
> going to be to some extend ugly. Whether the uglyness is in namespace
> bindings or version checks is likely more a question of taste. I
> believe code uglyness is not really driving this but the desire to be
> more agile and "lets release and then fix clients when they break" may
> be more dynamic than "lets release and then wait for clients to get
> updated".
With version selection, servers would still have the opportunity of not 
breaking clients, although it doesn't seem that likely to me that 
vendors will spend the effort to implement this.  But I still see that 
allowing the option to do this is a good idea (perhaps as a separate 
experimental draft).

>
>> The YANG 1.1 way is to define a new definition and then deprecate
>> the broken one. But this has negative consequences as well,
>> e.g. does writing to the old leaf automatically also write to the
>> new leaf at the same time? Are both returned in a get request? What
>> if a different client only writes to the new leaf?
> Sure, duplicate or overlapping config objects is something we usually
> try to avoid. In general, I assume a server would try to keep such
> overlapping leafs in sync. But then, this is an issue that appears in
> any scheme that allows access to multiple versions of a leaf (or
> overlapping leafs in general, i.e. a standard object and a vendor
> version of it).
I still think that clients may struggle to process configuration in a 
get request that they had not configured, and hence were not expecting.

>
> The point I was trying to make was a different one, namely that today
> we have a way to expose multiple versions of a leaf by using a new
> (module, path) name while with a (module, path, version) naming
> system, our protocols need extensions to expose multiple versions of a
> leaf (or we declare that servers will never expose multiple versions
> and that clients must always adapt to the version currently offered by
> a server).
So, I think that constraint should be that for a given schema (i.e. set 
of implemented modules) there can be only a single definition for a 
(module, path) pairing.  I see the version information, much like 
deviations, as just a mechanism to help clients (and readers) to spot 
where the definition may deviate from what they were previously 
anticipating.

In all cases, I think that minimizing backwards incompatible changes is 
the right thing to do, and I suspect that as YANG gains more traction, 
more of the latent bugs will get fixed, models will harden, and churn 
will decrease.  But I think that vendors will always want an easy way to 
fix bugs, and to change the model in the case that the implementation 
has radically changed, or when the schema is being cleaned up.

Thanks,
Rob


>
> /js
>


From nobody Wed Jul 25 09:59:56 2018
Return-Path: 
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 A72E6130E1B for ; Wed, 25 Jul 2018 09:59:54 -0700 (PDT)
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] autolearn=unavailable autolearn_force=no
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 3UtItp1BX2Ex for ; Wed, 25 Jul 2018 09:59:52 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id A950F130E78 for ; Wed, 25 Jul 2018 09:59:49 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 8EA6F2380925; Wed, 25 Jul 2018 18:59:46 +0200 (CEST)
Date: Wed, 25 Jul 2018 18:59:46 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Christian Hopps , NetMod WG 
Message-ID: <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com>
User-Agent: NeoMutt/20180716
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jul 2018 16:59:55 -0000

On Wed, Jul 25, 2018 at 05:25:32PM +0100, Robert Wilton wrote:
> 
> 
> One alternative way to build a robust client would be to have an internally
> defined schema by the client (perhaps based on open models, or perhaps a
> particular version of vendor models, possibly with some deviations, or their
> own model) which they can then map onto one or more per device schema.  So
> within a particular schema (internal or device specific) then (module name,
> path) uniquely resolves to a data node with particular properties; but
> between different schema (e.g. for each different device) then the same
> (module name, path) pair is allowed to resolve to a different uniquely
> defined property.
> 
> A layer of mapping is performed between the internal schema and the device
> schema for whichever devices/sw-versions it needs to interoperate with.  The
> more closely the two schema align, the easier the mapping is to achieve. 
> This is also why, ultimately, that determining whether changes are backwards
> compatible or not needs to be done at the schema level (which takes into
> account deviations and features), and also the per data node level.
>

This is what NMSes used to do and well still nasty work. But I assume
people think about much simpler clients, the scripts that often clue
the things together.

> > What really chances here is the adaptation process: Today, a client
> > will not bother to use a new namespace (a new version) unless it was
> > programmed to do so (opt-in). The proposed new versioning scheme
> > effectively means that client will automatically use new versions
> > until the client got told to be careful where necessary (and I assume
> > that in most cases this means until the client failed and then got
> > fixed, an opt-out process).
> My main concern with using module name for major version changes is that it
> forces a name change for each data node in that module, regardless of
> whether that node has actually changed.  This inherently feels like the
> wrong this to do.  If a data node hasn't changed then ideally you want it to
> remain unchanged on the same path.  So the alternative way that RFC 7950
> supports today is to keep the module name the same but introduce new names
> for all identifiers that have been changed in a non backwards compatible
> way, making use of status deprecated/obsolete.

Yes, you can decide between the two options today. If only leaf foo
needs an non-backwards compatible update, you create a new leaf
bar. If the majority of leafs in a module need a non-backwards
compatible update, you create a new module.

> However, it isn't clear to me that handling the old and new values within
> the same schema is always a good thing to do.  I generally prefer the idea
> of doing version selection (if anyone chooses to support this) so that a
> given value is only reported once.

I wonder how this will ever work with vendor modules, ietf modules,
ieee modules, openconfig modules, etc. all overlapping, sometimes more
and sometimes less. You would have to create distinct views onto the
same instrumentation if you do not want to have overlapping values.

> > I can understand why some people believe a conservative opt-in
> > approach is desirable for them and I can understand why some other
> > people believe an optimistic approach opt-out approach is desirable
> > for them. There are likely good arguments for both and this makes it
> > difficult to pick one.
> My feeling (and I don't have hard evidence to back this up) is that clients
> are generally less impacted by keeping the name the same rather than
> changing the module name for every major version change.

Not sure I parse this correctly...

> > > The YANG 1.1 way is to define a new definition and then deprecate
> > > the broken one. But this has negative consequences as well,
> > > e.g. does writing to the old leaf automatically also write to the
> > > new leaf at the same time? Are both returned in a get request? What
> > > if a different client only writes to the new leaf?
> > Sure, duplicate or overlapping config objects is something we usually
> > try to avoid. In general, I assume a server would try to keep such
> > overlapping leafs in sync. But then, this is an issue that appears in
> > any scheme that allows access to multiple versions of a leaf (or
> > overlapping leafs in general, i.e. a standard object and a vendor
> > version of it).
> I still think that clients may struggle to process configuration in a get
> request that they had not configured, and hence were not expecting.

Maybe, maybe not. Perhaps things get simpler if the relationship of
foo replacing bar is machine readable.

> > The point I was trying to make was a different one, namely that today
> > we have a way to expose multiple versions of a leaf by using a new
> > (module, path) name while with a (module, path, version) naming
> > system, our protocols need extensions to expose multiple versions of a
> > leaf (or we declare that servers will never expose multiple versions
> > and that clients must always adapt to the version currently offered by
> > a server).
> So, I think that constraint should be that for a given schema (i.e. set of
> implemented modules) there can be only a single definition for a (module,
> path) pairing.  I see the version information, much like deviations, as just
> a mechanism to help clients (and readers) to spot where the definition may
> deviate from what they were previously anticipating.
> 
> In all cases, I think that minimizing backwards incompatible changes is the
> right thing to do, and I suspect that as YANG gains more traction, more of
> the latent bugs will get fixed, models will harden, and churn will
> decrease.  But I think that vendors will always want an easy way to fix
> bugs, and to change the model in the case that the implementation has
> radically changed, or when the schema is being cleaned up.

Well, part of the story line is that it is necessary to produce half
baked modules faster and then to fix them iteratively. And there is
likely some truth to it since implementation of models helps to
understand how to do them better. But once you are in production, you
hate moving APIs and stability is suddenly a big value.

Perhaps all we need is a marker that says "this module is still
experimental and hence it does not provide any backwards compatibility
promises". Clients using these modules then know that newer revisions
can break things.

 module ietf-foo {
    stability alpha;
 }

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Jul 26 03:19:14 2018
Return-Path: 
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 6FABF1310BB for ; Thu, 26 Jul 2018 03:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 jgYW5TPyB5Fn for ; Thu, 26 Jul 2018 03:19:10 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7741310B9 for ; Thu, 26 Jul 2018 03:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9432; q=dns/txt; s=iport; t=1532600350; x=1533809950; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/s4NqXouo4AP9+LlrFuFaQYCVugnuC3zupqk7BGugXs=; b=TJzigZFSKit/LcJB2uMVC524fJ+n6bODYRWulsWT34AOrKHSTLnAf2LH GI9xk9JiiTDJHKS1XEvCEKV+7XxT3DExDzrizDYEFYPMjxdAzVBVkquoL 48/jCZYAQtQtT9jdvrF+mV637aZpFSjkyzwDQNDUi6xbGMx+7prN9Jn/f o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCen1lb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMggX4ShCaIZY08LJVigWYLhGwCgxE4FAECAQECAQECbSi?= =?us-ascii?q?FNgEBAQECASMPAQU0BhcLGAICERUCAlcGAQwIAQEXgwWBeAixZoEuhF6FbYE?= =?us-ascii?q?Lh2gmgUE/gTiBbUk1hDgvVYJCglUCh04ZhHuBLYtsCY8vBoFHhmWFV4gLhFC?= =?us-ascii?q?FWIFYIYFSMxoIGxU7gmqCTI4HPo8lAQE?=
X-IronPort-AV: E=Sophos;i="5.51,404,1526342400";  d="scan'208";a="5415112"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 10:19:08 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6QAJ7KA020968; Thu, 26 Jul 2018 10:19:07 GMT
To: Andy Bierman , Christian Hopps , NetMod WG 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com> <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com>
Date: Thu, 26 Jul 2018 11:19:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jul 2018 10:19:14 -0000

On 25/07/2018 17:59, Juergen Schoenwaelder wrote:
> On Wed, Jul 25, 2018 at 05:25:32PM +0100, Robert Wilton wrote:
>>
>> One alternative way to build a robust client would be to have an internally
>> defined schema by the client (perhaps based on open models, or perhaps a
>> particular version of vendor models, possibly with some deviations, or their
>> own model) which they can then map onto one or more per device schema.  So
>> within a particular schema (internal or device specific) then (module name,
>> path) uniquely resolves to a data node with particular properties; but
>> between different schema (e.g. for each different device) then the same
>> (module name, path) pair is allowed to resolve to a different uniquely
>> defined property.
>>
>> A layer of mapping is performed between the internal schema and the device
>> schema for whichever devices/sw-versions it needs to interoperate with.  The
>> more closely the two schema align, the easier the mapping is to achieve.
>> This is also why, ultimately, that determining whether changes are backwards
>> compatible or not needs to be done at the schema level (which takes into
>> account deviations and features), and also the per data node level.
>>
> This is what NMSes used to do and well still nasty work. But I assume
> people think about much simpler clients, the scripts that often clue
> the things together.
>
>>> What really chances here is the adaptation process: Today, a client
>>> will not bother to use a new namespace (a new version) unless it was
>>> programmed to do so (opt-in). The proposed new versioning scheme
>>> effectively means that client will automatically use new versions
>>> until the client got told to be careful where necessary (and I assume
>>> that in most cases this means until the client failed and then got
>>> fixed, an opt-out process).
>> My main concern with using module name for major version changes is that it
>> forces a name change for each data node in that module, regardless of
>> whether that node has actually changed.  This inherently feels like the
>> wrong this to do.  If a data node hasn't changed then ideally you want it to
>> remain unchanged on the same path.  So the alternative way that RFC 7950
>> supports today is to keep the module name the same but introduce new names
>> for all identifiers that have been changed in a non backwards compatible
>> way, making use of status deprecated/obsolete.
> Yes, you can decide between the two options today. If only leaf foo
> needs an non-backwards compatible update, you create a new leaf
> bar. If the majority of leafs in a module need a non-backwards
> compatible update, you create a new module.
But my main objection is that changing the name of the module forces a 
name change for all data nodes in the module, even for those that have 
not changed.  I'm just not convinced that this is a good thing to do.

I think that there is an assumption here that if the module is published 
with a new name then servers can implement both old and new modules at 
the same time.  But I'm not sure that vendors will actually do this, nor 
will this necessary work that well in practice.

E.g. if we consider a non backwards compatible change to ietf-interfaces 
that it is decided needs a new module name.  Not only do we need 
ietf-interfaces-v2, but we also need v2 versions of all 70 modules that 
augment from ietf-interfaces, either directly or indirectly.  Now if 
someone makes a get request without a sufficient filter then will twice 
as much data.

>> However, it isn't clear to me that handling the old and new values within
>> the same schema is always a good thing to do.  I generally prefer the idea
>> of doing version selection (if anyone chooses to support this) so that a
>> given value is only reported once.
> I wonder how this will ever work with vendor modules, ietf modules,
> ieee modules, openconfig modules, etc. all overlapping, sometimes more
> and sometimes less. You would have to create distinct views onto the
> same instrumentation if you do not want to have overlapping values.
Yes, I think that they have to be kept as discrete views.  Or perhaps 
the server is configured as to which external management model it should 
use.  Even with discrete views there are problems due to different 
hierarchies or list keys.  There is no perfect technical solution here, 
although over time I think that things will get better as management 
models slowly converge.

But representing multiple models in one combined view doesn't really 
seem to be a good idea.

I think that some aspects of versioning are the same problem.  E.g. I 
think that there is a difference between a major release where more 
backwards compatible changes could be expected, vs maintenance releases 
where one would expect backwards compatibility should likely be preserved.
>
>>> I can understand why some people believe a conservative opt-in
>>> approach is desirable for them and I can understand why some other
>>> people believe an optimistic approach opt-out approach is desirable
>>> for them. There are likely good arguments for both and this makes it
>>> difficult to pick one.
>> My feeling (and I don't have hard evidence to back this up) is that clients
>> are generally less impacted by keeping the name the same rather than
>> changing the module name for every major version change.
> Not sure I parse this correctly...
This was similar to a comment above.  I don't like the (module, path) of 
a data node having to change (due to a module name change for a major 
version) if its definition hasn't changed at all.

>
>>>> The YANG 1.1 way is to define a new definition and then deprecate
>>>> the broken one. But this has negative consequences as well,
>>>> e.g. does writing to the old leaf automatically also write to the
>>>> new leaf at the same time? Are both returned in a get request? What
>>>> if a different client only writes to the new leaf?
>>> Sure, duplicate or overlapping config objects is something we usually
>>> try to avoid. In general, I assume a server would try to keep such
>>> overlapping leafs in sync. But then, this is an issue that appears in
>>> any scheme that allows access to multiple versions of a leaf (or
>>> overlapping leafs in general, i.e. a standard object and a vendor
>>> version of it).
>> I still think that clients may struggle to process configuration in a get
>> request that they had not configured, and hence were not expecting.
> Maybe, maybe not. Perhaps things get simpler if the relationship of
> foo replacing bar is machine readable.
Yes, potentially that would help.

>
>>> The point I was trying to make was a different one, namely that today
>>> we have a way to expose multiple versions of a leaf by using a new
>>> (module, path) name while with a (module, path, version) naming
>>> system, our protocols need extensions to expose multiple versions of a
>>> leaf (or we declare that servers will never expose multiple versions
>>> and that clients must always adapt to the version currently offered by
>>> a server).
>> So, I think that constraint should be that for a given schema (i.e. set of
>> implemented modules) there can be only a single definition for a (module,
>> path) pairing.  I see the version information, much like deviations, as just
>> a mechanism to help clients (and readers) to spot where the definition may
>> deviate from what they were previously anticipating.
>>
>> In all cases, I think that minimizing backwards incompatible changes is the
>> right thing to do, and I suspect that as YANG gains more traction, more of
>> the latent bugs will get fixed, models will harden, and churn will
>> decrease.  But I think that vendors will always want an easy way to fix
>> bugs, and to change the model in the case that the implementation has
>> radically changed, or when the schema is being cleaned up.
> Well, part of the story line is that it is necessary to produce half
> baked modules faster and then to fix them iteratively. And there is
> likely some truth to it since implementation of models helps to
> understand how to do them better. But once you are in production, you
> hate moving APIs and stability is suddenly a big value.
Yes, both of these are right.  And partly it is a chicken and egg 
problem.  We would like clients to migrate from CLI to YANG, but that 
requires stable models, but don't want to invest heavily in creating 
stable models in YANG if customers are not using it. Having two separate 
sets of standard models (e.g. IETF and OpenConfig) doesn't help either.


>
> Perhaps all we need is a marker that says "this module is still
> experimental and hence it does not provide any backwards compatibility
> promises". Clients using these modules then know that newer revisions
> can break things.
>
>   module ietf-foo {
>      stability alpha;
>   }
Possibly.  In SemVer, version numbers less than 1.0 would generally be 
regarded as experimental.

I think that regardless of what IETF decides to standardize for YANG 
versioning, I can't see OpenConfig changing their direction for their 
own models, so some part of the industry at least will likely have to 
accept semver as part of the solution.

Thanks,
Rob


>
> /js
>


From nobody Thu Jul 26 07:16:21 2018
Return-Path: 
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 DC747131001 for ; Thu, 26 Jul 2018 07:16:19 -0700 (PDT)
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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dPUAOtAOZjf6 for ; Thu, 26 Jul 2018 07:16:17 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id B4BDB130E58 for ; Thu, 26 Jul 2018 07:16:17 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id DC572238535E; Thu, 26 Jul 2018 16:16:16 +0200 (CEST)
Date: Thu, 26 Jul 2018 16:16:16 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Christian Hopps , NetMod WG 
Message-ID: <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Christian Hopps , NetMod WG 
References: <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com> <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de> <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com>
User-Agent: NeoMutt/20180716
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jul 2018 14:16:20 -0000

On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote:
> 
> I think that some aspects of versioning are the same problem.  E.g. I think
> that there is a difference between a major release where more backwards
> compatible changes could be expected, vs maintenance releases where one
> would expect backwards compatibility should likely be preserved.
>

Well 'could be expected' and 'would expect backwards compatibility
should likely be preserved' is kind of hand-waving. There are often
situations where people are reluctant to bump major version numbers
just because a tiny bit of an API has changed in a non-backwards
compatible way - for the same reason that you brought up. Most of the
definitions did not change, so people do not want to bump the major
version.

> This was similar to a comment above.  I don't like the (module, path) of a
> data node having to change (due to a module name change for a major version)
> if its definition hasn't changed at all.

Fine. Then you deprecate the broken foo and create foo'. You do not
like that because you do not want foo and foo' at the same time. But
others want deprecated objects to stay to allow a transition period.

> Yes, both of these are right.  And partly it is a chicken and egg problem. 
> We would like clients to migrate from CLI to YANG, but that requires stable
> models, but don't want to invest heavily in creating stable models in YANG
> if customers are not using it. Having two separate sets of standard models
> (e.g. IETF and OpenConfig) doesn't help either.

So do we hit a requirement (which is independent of versioning) that a
mechanism is needed to select different module sets (or views), given
that the reality gives us overlapping and competing models? And then
as a side effect, such a mechanism may also be used to select between
different versions?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Jul 26 08:24:55 2018
Return-Path: 
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 33AD31311B0 for ; Thu, 26 Jul 2018 08:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 I72r6KrtCxLt for ; Thu, 26 Jul 2018 08:24:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A741311AF for ; Thu, 26 Jul 2018 08:24:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3827; q=dns/txt; s=iport; t=1532618688; x=1533828288; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=E+mtFhh0Kqs/bjNzzPm6yFljjGBymHCDcEZow7xmCBI=; b=cJaXICKH2uteYTympluGYaZasNy1O7oLryEeuD3MA5ZnYW/k/C7L2LV6 IqjNXuRBLg2oeGjYyfevQacKPO9KkrVb78PjEi0gEfuFkgbKtgkN8dQAQ yYwaCDyrNB+KTrp4fGmBCzNPR+MiSaV0vBx5us7CmfhK7aaMUGRbOkB3H 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQAx51lb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUeEoQmiGWNOyyXSAuEbAKDGTgUAQIBAQIBAQJtKIU2AQE?= =?us-ascii?q?BAQIBIw8BBTQKEwsYAgImAgJXBgEMCAEBgxyBeAixS4EuhF6Fa4ELiA6BQT+?= =?us-ascii?q?BOII2NYd+glUCjGKNGQmPLwaILIVXjFuFWIFYIYFSMxoIGxU7gmqCJBcRjgc?= =?us-ascii?q?+j04BAQ?=
X-IronPort-AV: E=Sophos;i="5.51,405,1526342400";  d="scan'208";a="5421295"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 15:24:46 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6QFOjxA021684; Thu, 26 Jul 2018 15:24:46 GMT
To: Robert Wilton , Andy Bierman , Christian Hopps , NetMod WG 
References: <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com> <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de> <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com> <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: <32fdeca8-f809-d278-fb39-2f775bf03e95@cisco.com>
Date: Thu, 26 Jul 2018 16:24:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jul 2018 15:24:53 -0000

On 26/07/2018 15:16, Juergen Schoenwaelder wrote:
> On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote:
>> I think that some aspects of versioning are the same problem.  E.g. I think
>> that there is a difference between a major release where more backwards
>> compatible changes could be expected, vs maintenance releases where one
>> would expect backwards compatibility should likely be preserved.
>>
> Well 'could be expected' and 'would expect backwards compatibility
> should likely be preserved' is kind of hand-waving. There are often
> situations where people are reluctant to bump major version numbers
> just because a tiny bit of an API has changed in a non-backwards
> compatible way - for the same reason that you brought up. Most of the
> definitions did not change, so people do not want to bump the major
> version.
Yes, exactly.

I think that there will always be a reluctance to change the model name 
(e.g. to "module-v2") unless it can truly be made low impact to clients, 
importing modules, etc.  And if we get to something that is low impact, 
then it may well be that we end up with something that is logically 
equivalent to semver anyway.

There may be less reluctance to bump the semver major version number - 
although I agree with you that non backwards compatible bugfixes may be 
a grey area.

E.g. one common non backwards compatible change that I see recently 
between Native YANG models was changing from int32 to uint32 for list 
indexes (mostly in config false nodes).  I don't have the history as to 
why the change was made, but for all intents and purposes the effective 
value set is the same (but not specified in the model), but the encoding 
could differ, and hence it is regarded as a non backwards compatible 
change.  As an aside, part of me wonders whether classifying this as a 
non backwards compatible change is right, although I can see why it is 
specified that way.




>
>> This was similar to a comment above.  I don't like the (module, path) of a
>> data node having to change (due to a module name change for a major version)
>> if its definition hasn't changed at all.
> Fine. Then you deprecate the broken foo and create foo'. You do not
> like that because you do not want foo and foo' at the same time. But
> others want deprecated objects to stay to allow a transition period.
Basically yes.

I also think that perhaps there is a level of pragmatism here:
  - if a particular node is widely used, but needs to be changed, then I 
think that we are far more likely to create foo', and continue to 
support foo.
  - but if the node (or nodes) were effectively broken for some reason, 
then even if it is being used by some customers, I think that there is a 
preference to just fix in place.

I think that it just goes back to stability.  The models start off 
somewhat unstable, and then gain stability over time.  We want to be to 
modify/fix them when they are new, but once there are older, we would 
expect a much greater level of stability in them.

>
>> Yes, both of these are right.  And partly it is a chicken and egg problem.
>> We would like clients to migrate from CLI to YANG, but that requires stable
>> models, but don't want to invest heavily in creating stable models in YANG
>> if customers are not using it. Having two separate sets of standard models
>> (e.g. IETF and OpenConfig) doesn't help either.
> So do we hit a requirement (which is independent of versioning) that a
> mechanism is needed to select different module sets (or views), given
> that the reality gives us overlapping and competing models? And then
> as a side effect, such a mechanism may also be used to select between
> different versions?
Yes.

Thanks,
Rob

>
> /js
>


From nobody Sat Jul 28 22:07:22 2018
Return-Path: 
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 4CDA0130DCC for ; Sat, 28 Jul 2018 22:07:21 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 3HbyvuomRMFG for ; Sat, 28 Jul 2018 22:07:19 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C58A01274D0 for ; Sat, 28 Jul 2018 22:07:19 -0700 (PDT)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 00BB4635D3; Sun, 29 Jul 2018 05:07:18 +0000 (UTC)
From: Christian Hopps 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_D058B0C7-EAFB-4E75-84E7-ACC0DD8393F1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 29 Jul 2018 01:07:17 -0400
In-Reply-To: 
Cc: Christian Hopps , Juergen Schoenwaelder , NetMod WG 
To: Andy Bierman 
References:  <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jul 2018 05:07:21 -0000

--Apple-Mail=_D058B0C7-EAFB-4E75-84E7-ACC0DD8393F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

One answer to a slightly more general version of this question (why is =
OK for the clients to do nothing while the servers do the work) is that =
the client developers are often the server developers customers, they =
pay the bills.

Also in general there is a one to many mapping from a server to it's =
clients, the overall cost of updating a server and of it supporting =
multiple versions or transforming or whatever is much less than the =
overall cost of all the users of that server updating their client =
software.

I'm not advocating for clients never updating, but I think it's =
unreasonable to think that clients will be updating as fast as servers, =
or to design a versioning scheme that assumes anything like that.

Thanks,
Chris.

> On Jul 24, 2018, at 11:11 AM, Andy Bierman  wrote:
>=20
> Why is it OK for the client developer to decide "we are sticking with =
the
> defective version of the module and not going to upgrade to
> the fixed version like the server developers have done."
>=20


--Apple-Mail=_D058B0C7-EAFB-4E75-84E7-ACC0DD8393F1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAltdS4UACgkQLh2DDte4
MCXcyA//Y8eHThPeYGhK3vIxO2Penf9Txg4m7YZIi8xUdRbc+lRiXJQ7OWjqBCKq
lrXEaynWD3Z9al8h9+eET9EznHlAVzTgS8uG8yvl0agA/B0ifjbHaQc1aOJK+Rw2
oIDGJ2G/0P46y5R1FhWu8tpqH/warZr5CY8eCazmnbIb+OWcH2cDTrRo5vExU033
jmuQOZBzuKKT+E7TSDoqqsxdqO/Tx6eJ2CtNft8/MljgCsoAvbCwYFBKKXGAB3nH
PK6jiuctirWPYUGNu0qgH/1Lh1uW6TC1ypzU29f0sGZ6XxKtKQg3WE+Lr9L2eetB
yEGYsuPFj59gjbjtDxg1Y6OUS4elBqNsRahjBAEX5p8iIadQ7sJ4cCooDD6apTbk
S9lIaYd/yrR1Abva82xtz8dQykiYqWtKxv95e0rp/S/Bb1cD6WREK7r7zrpiZZJO
mkfU3aDOMmeZZw25OHV631WHjU7TOuJzqDOJtiGTkYWxf6CiK5s98O+eHDd0IV6Z
VoojXjF7qhcUzg5a7xV3epBfBmhmYKn5xW/T5l+8B9enmnaEBHWTGzB7WvVQqudN
2S/UUCj9UvokT029a6X2c+C6d1/aodSaFG6Z6WTJRPfXKVWB8KCsOOC57xEh1BNG
I8j/3hJbMRJzAx/2FUkzPa0TH7HqZesP1zTmYiyotrN8XcX82Wo=
=xO0/
-----END PGP SIGNATURE-----

--Apple-Mail=_D058B0C7-EAFB-4E75-84E7-ACC0DD8393F1--


From nobody Mon Jul 30 16:27:51 2018
Return-Path: 
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 A5E0613114F for ; Mon, 30 Jul 2018 16:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 TV29lUD5cIjX for ; Mon, 30 Jul 2018 16:27:35 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700075.outbound.protection.outlook.com [40.107.70.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E786E1311C4 for ; Mon, 30 Jul 2018 16:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9LCZWuLEiJIAlktZNa7P+C+yn64qYX2LJtKZToUbPvA=; b=Fk31VtAKh9d1CQ8tTwZlGPRfTyWEPiNOGhtbrQc0vVuo54YcK/GGAn/hyqGdCWVaUrNueeA5qEz9ceRC23iR3axbRQlZZy+MkoosngNaFDF8Ix1aQv1fVbhl4+PpDVqmEq3KJ2BeBlEeS0GIEXnq6R1W+MaZND+hl6WFrbwQapc=
Received: from DM5PR08CA0037.namprd08.prod.outlook.com (2603:10b6:4:60::26) by BN1PR08MB155.namprd08.prod.outlook.com (2a01:111:e400:40d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.995.19; Mon, 30 Jul 2018 23:27:29 +0000
Received: from DM3NAM03FT030.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by DM5PR08CA0037.outlook.office365.com (2603:10b6:4:60::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.995.17 via Frontend Transport; Mon, 30 Jul 2018 23:27:29 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT030.mail.protection.outlook.com (10.152.82.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1038.3 via Frontend Transport; Mon, 30 Jul 2018 23:27:28 +0000
From: Hayden Brown 
To: "netmod@ietf.org" 
Thread-Topic: Fwd: Re: [netmod] YANG schema mount - any early implementations?
Thread-Index: AdQoXL4JL5BXFoDLT6iNrQ7jsBoYyA==
Date: Mon, 30 Jul 2018 23:27:26 +0000
Message-ID: <5df7eb40589d4631a33c704358bc8f8e@USP-EXCHPROD01.GNET.global.vpn>
Accept-Language: en-NZ, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_5df7eb40589d4631a33c704358bc8f8eUSPEXCHPROD01GNETglobal_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(346002)(39850400004)(136003)(396003)(2980300002)(438002)(53754006)(199004)(189003)(5660300001)(2906002)(5024004)(6306002)(9686003)(2473003)(6512007)(229853002)(336012)(260700001)(24736004)(36736006)(102836004)(108616005)(316002)(106002)(186003)(26005)(606006)(6916009)(53546011)(16586007)(6116002)(54896002)(118246002)(126002)(84326002)(86362001)(790700001)(236005)(2351001)(561944003)(7636002)(246002)(7596002)(8676002)(7736002)(356003)(53416004)(966005)(478600001)(72206003)(476003)(3846002)(956004)(5640700003)(6486002)(486006)(2501003)(25786009)(8936002)(1730700003)(106466001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR08MB155; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT030; 1:DswMjwPFdTRQkYGSRrvwN78owRPEjBgHC5zeXEgSWBuNVcSz08PP/NRPhDXI+d69bccMXx6j+kNMFmsx/svIGhle9SnymxxFwPbADrAlvjDgQ1HkMZYRTG7WA6IN4gjZ
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5ac2d3e5-8478-43af-c750-08d5f6740431
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:BN1PR08MB155; 
X-Microsoft-Exchange-Diagnostics: 1; BN1PR08MB155; 3:aeXWLM4OFESghuuyozDFiDpNkLLuCphnU5efSkHYphYBx9y5nZKCo4JxBa2vMwWzV8ALBiTymGG1zO+wxouSqPrt+ib09Zlp75d4uC4liNXPEv+N6mN2kCxx0W6g2oj7gzwaG/+pF+ZHW057DYxKNQqhVoAKVITLwRMzdQ9jbFNNVRzY0LTeMZRm/oomS8cdYgEZOabpT0JkGIT6BcO2DvDYFzRKICldwO6xNAMEaAuf+36YbeJu1PMN0dpPZKGiATc2iDjhI2eoSwL5ZCz74A5YVxzIS4gYkRiXoFWr0jOgfMGstwfEh8tIuXFUXJppHAnHxO0mnmF7zMqHYdJzIpIr+8KRqNz6RHq/i83YL9g=; 25:i9M32Roj1D1XIcKOnaH0tCoLeUz5OGaTpLRjLKvztKgezGCu2o77HFgVMV1yQBYdn8OX4gYOyAEAAsttb52v301hGvjLvRI9pONCNERIcmt2TgkiOcluSc2CiHp9hmuWvOJk+TeDR0B/ExOqdnCXhXheDG2r7Zlgo/evF7C+i0OVQUeY1phiXP380nUlPmurd2Tv6wqUcpOya8tNP3b2sJqX7x9X91Z/Mb3iKyrqk3t6qabyoY4stXWV7V+41iz5lME5WPpP0prJl//PM7TiM0Kizvnw3W85DT1OD43Nc+KWy7L7VoPUM5JKzsxOXOa2ZuA91BTPdj8mMjeST3LeKQ==
X-MS-TrafficTypeDiagnostic: BN1PR08MB155:
X-Microsoft-Exchange-Diagnostics: 1; BN1PR08MB155; 31:aL8lwwqYbI5BDwygqGWn61zsDSLYTvefW5VykVYpE6oMQPv2Q23QQDLXD6FhF+VibFuj+wGEqrDnq/tLXQy6WUDmhh9hX0ARfrTDqcU0+FYPfqINmauB84LET/cNkyc4SIelRLRFNpiSG5MO8tXm9q6knUunZc90a6YQCEaH/A+Zo+h7t6K8i1+pcGzPiKaWOoP44IPJww+RL1PjYwStGU0Y0PkynU2ws+UD+Wxu9kE=; 20:hAr3WS1cZsXFjTABEhQ0IQpk1Vr74CribTGEF2Li2CjiM/alWny+JkRAAradezFgxaISWloFzS2020d2l1Og1KyrRwqD8dqy6J1s9pmBIZ4M7bwIrv+mUCxSetxzEoIcYl48RI1LGJ2k8JTsEai2TFBJhEIldbWFAWBuZ6uR7LmTQEOESFGZtU5HYfVwOd8XHdcDk/hEldVUiTBo2w/n63C8UG06MaXS+hPdekdvVVlP7yixrBw/H+bot4h3QptnuMj/A+I43aPkMjAvD/f2R//IF4mNI24Y4iMRDgHfuTxLgwKjq6758XHqQ9omLtWcNoAruUoCV4D+9ohdrDbO6XzDru7LSiDw7+Q1wtVETGfpscyfdjOHIosOg5UWfGXAMnoqvdsJtCoAT0ML1SQnzr8unnNaqHWYqOxtpgnYxWb6jBZAdqiJTi31BCWpESWIE7OXKfNsWhmUqqzjvPX1krnQgxHQrfdyKoi8kFN/8a+6qiKia/glFHmTBlJGIGLr
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(158342451672863)(120809045254105)(21748063052155); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93004095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN1PR08MB155; BCL:0; PCL:0; RULEID:; SRVR:BN1PR08MB155; 
X-Microsoft-Exchange-Diagnostics: 1; BN1PR08MB155; 4:uOUmBMoeSoAYmT1dmvEHEetrIh/DYB/ZqQaZAz2p3efE1/omtitxnU8Gb+aA7AT8smuWfyzzAtT/fRBswkZO2it811OrF9M/nJVkZhx//U1AojENdniUehM2b9Y1cmIIyU2kzYkpNp5PQ4iq9Z5c2Rcf/FGiz/ICn0PmFaDKtt90rZw5CuefTLKG8Y0NlBiTzuLqn0X+zJCHltEEI0k+odM67HzSbvgIgH0+cVFKXEUYyAMZJWerpsi01JpGjLQBr23GjBmEKDlcRDDUj4TG8zRvFrDNT9Wm5q816kd7ZAmX6QcYfvYvpTFBuNKi0caUBwC/LiL9SoTuGCoJDg9Y7HRnEIMyYUo8EN1SnRyIPx7aephNIUku5KIk70zXPSmx23aEV5mLn1drcjVISZ/A6QueZRhFXUGsXaWvpZt+eCY=
X-Forefront-PRVS: 0749DC2CE6
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR08MB155; 23:TlQnOgscmbHL61cmp8p5qd148MitSOctWC1+YF947C?= =?us-ascii?Q?X8l5mpOobaE6KT4V8SeWxf8AgiJkMc1tR0T9XfIhlL79t8DDjKesHzfC1bUw?= =?us-ascii?Q?z3BvBJYKn5BDNFOrWaC+L7zrVr1iIK0J/CyXYtwp12oLu8M6VVVMcRyKWAe5?= =?us-ascii?Q?GNmQVpHgifgjVo1NuQBrSvZPGSrf3mTxNdQWCSIfgOdayUP/O4hE+SOH5Cjq?= =?us-ascii?Q?T2/YkA0kdxjGxPKQwpPvObeYDMmIBCegrzN5WcGDDtsp42V4xVz9BX3eha1I?= =?us-ascii?Q?1nVbA9lthy9eoCgTk35K9XQ9RqLexTa7n9afCY3yEahyX4UIsmstEuRURWad?= =?us-ascii?Q?M7vp+aiP1R3Obr5Ki0qnXMXfcHmsF1TfjgAvbE0zEawcewVmcZiy5FwgbhjM?= =?us-ascii?Q?+WAC8xqxLYq8zveYgXqtqY94LhiBo4pM+3/tMASTGIJRHcYscQME5bCfVUnV?= =?us-ascii?Q?C+rtNf3JqVXV34ColQUMt3lGZliaxynB5UdXJKFD2OaDd7AWNEw79jX7AiUk?= =?us-ascii?Q?bor08NGlw58i6kX3SnlyOWH26+11glpFzbGJXx+cSSrfdiVsqs+Am31wlSPf?= =?us-ascii?Q?iEmm9gkaJ0tyy8MWN8G6BUSyYiMes9WlS8H74PhQSEzJhe7nrhDMPFv5TqFW?= =?us-ascii?Q?5GcMyHwwUvoPcMl5Ih7WY9RAyNttwlyum02Bf2CGY6aE6aV++W0ns5BL3bbE?= =?us-ascii?Q?2E4yfM37XAzVOh6ej5+b6Ln4lfRoq5A8L296esVzIMYBcJDc3nhltI5zuGYD?= =?us-ascii?Q?6XunZGEQG/BZKaQL91Dv8dfJeemt8RrpSn3r7EH4A+fGSjXBUFEtDexGwblD?= =?us-ascii?Q?mHC4RzoWZSCg8gzsFLjDZK6l5Qz5NeEu5YkaPMLAyfOdTWKh0FLjBWpJWSdc?= =?us-ascii?Q?2Vb16TjkY+i3mvfXUvxxzcWeis91D17JoU6MFfD+Qv/K4n4WLltjsTopbuRL?= =?us-ascii?Q?3nLJOLrS2KFl4WnxZf4EwhgBAxdGxqjvw3jsCAnkeC/9A+cTeekhUVI+SMIn?= =?us-ascii?Q?QvbpTvlAVR0CWhPmlYLLqreAk4P+i8hLNsioS/uu1D5hMsoav5wUVOGs6TWa?= =?us-ascii?Q?axwmCRPoYxUAgJqTeNnR+AXKtnpkxaDtQ/SW6mDoyzLOg4WvgZSoj/4Wzn8W?= =?us-ascii?Q?AcEOgVsEgjCsnvTyYlHF8GGR8B+7TKY7/XQhiEEYALQZ+cxspqalkvn2BT2F?= =?us-ascii?Q?QPGlRw0/0tKn6VFrLPNJdghTyXgEmTu2GBsAsW1lsXCf1G+eKoBN45rnlTqU?= =?us-ascii?Q?RFS1Hvqe3uVE0qU76fUjhjecc//+Te70F9GmuWXHVIlTbXeuQ8eAoe18Wkrp?= =?us-ascii?Q?pYAJsjh5HBRSBOWkVs1A4dPPJfFJo4/TbdKxFsUc42+aoUPXpybyNAo7KCEA?= =?us-ascii?Q?k9qQ=3D=3D?=
X-Microsoft-Antispam-Message-Info: bODlYnpIRn3APTTo793Yv7olB0y8LWNn8my5UWkTLAZt08JvLoOOP+OR7kz5c6ojDzfewQNoldNtG3zeWrgqzG1XAAfDSRNHv8mWmO4G1J6jALVsSdocZ7Dj9B7mvWihHdaCo/cclOZiI3NqmK+GexCJTSzXis0ZYxPBfMEHi3ycdOziP/4YKCy2zT4LdGL+iGfXvth7BwZM+YL04Ns76xD9AXlxYaWSRHXIaCiXVcGCtJKNwgYi7SQXu+zqqHEPYsmh4wGm2JMntO0zomUz6pjncQop35OOHZmCVzQxQLfdhcTpfreCaMacVr73HywSAXnLR/ELvpqsxXc/6ce+f0tVe7kYhsnJ/6DnCeYx7/k=
X-Microsoft-Exchange-Diagnostics: 1; BN1PR08MB155; 6:tPEXmAGK9XFsPoONUIwm2jcEKdDJVAjHynbiyxTgLfICwQtDxsMZf2hoA9BNJWexbmwlkAKfOhTv1WnDmd7dewM9D1zckrf6FqFvvIGJaHi++ZIdp/AHnAvVOGtpV+Qbm96MMrsCU0xAYCI21TqCaM7izgpEJpwZ/9u+0/M0Q5JlCnDbblEDYIk9JVsFHhiR0EUZOXR52i7+XU6ajsFl6VNHz7q23VUeMUxBcb/kIY6r9p2beziehiVg8dKllAf6iiUyn2gaeyVtl8Xo9omn2kBszL84QvzRfLPUelynJhfPA9rxVeAUHIr1IVM5RgSR89bDHZPH3fPQZVmbVMKNsCM+r52EmcrgFxzZJT+nrwxielht7nbdvgbTktAIRRlsBxyB/lLzXD4/1G56g6h5YWSoH18k8c8enh46L3SLNbEliVy6ijPbul9i5KuBS1UEkXmf9e6qnMdEOgj0tg8R6w==; 5:6bfxflRya+WJEvbshoM9nYKj5ZmqUWbKSr5g/aSMfhkGftoYiTQPjxXxu0I8NiXwmyj3x3/zqApQPk/lAjXWVoTKDe6zP+yzgrGTlRdIaAUIaSBRbuR5FuLPVygHc0I1mPKB9ULB+GEkmF7ZkrE/f+wgPxMZbkMRNv5FXeKrONE=; 7:D/BwEmlLLuReWtkXAIA7ehK3BYPgDvSLIj4Q2PLqEKCjadjC6NndH2XW2tdij2KjdeSAfSjm364kkcM14hoyz2progZBC3VIh4f9YIzOADJzBFIATS5wQNyLouxIB1N0Pdazps83y/Id+++xJFCvcFBRDKvWOonEChMq5riGlvGM9kiabOOZHgYSGiiawkGbR+pbIT5HLNDBQrwe3Gio8niJxFwBnHxdrXCzQZv+bufGjnule4eRxeV6IOpRQCsO
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2018 23:27:28.5272 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ac2d3e5-8478-43af-c750-08d5f6740431
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR08MB155
Archived-At: 
Subject: [netmod] Fwd: Re:  YANG schema mount - any early implementations?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jul 2018 23:27:49 -0000

--_000_5df7eb40589d4631a33c704358bc8f8eUSPEXCHPROD01GNETglobal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I just wanted to ask if it would be possible to clarify the intentions arou=
nd some of the wording of the draft schema mount standard (Rev-10). In part=
icular, regarding entries of the /schema-mounts/mount-points list.

My interpretation is that the intended use of the /schema-mounts/mount-poin=
ts list entries are to specify the parent modules that contain a mount poin=
t. Following on from this, the client should use the YANG library instance =
to determine which schema options can be mounted at the root of a mount poi=
nt. This seems consistent with the examples of Appendix A of the draft stan=
dard.

In this email I wanted to highlight the following sections of the draft RFC=
 below. In my view they seem to me to be somewhat ambiguous, in implying th=
at the mount-point list entries specify the *child* module (sub-schema):


>From https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/?inclu=
de_text=3D1
Section 3.3 - Page 7
> The "/schema-mounts" container has the "mount-point" list as one of its c=
hildren. Every entry of this list refers through its key to a mount point a=
nd specifies the mounted schema.

Section 3.3 - Page 8
> An entry of the "mount-point" list can specify the mounted schema in two =
different ways, "inline" or "shared-schema".


Section 9 - Page 13
> A mount point defines a place in the node hierarchy where other data mode=
ls may be attached. A server that implements a module with a mount point po=
pulates the /schema-mounts/mount-point list with detailed information on wh=
ich data models are mounted at each mount point.

Section 9 - Page 14
list mount-point {
    key "module label";
    description
    "Each entry of this list specifies a schema for a particular mount poin=
t.


The wording makes me wonder if these passages might actually just be "left-=
over" context from earlier revisions of the draft standard (Revision 8 and =
prior) -- effectively referring back to the schema-mount 'use-schema' list.


I do of course acknowledge that it is entirely possible that I've misinterp=
reted the wording of the passages above, however if that is the case, I sus=
pect I may not be the only one in future.
Many thanks for your time on this matter.

Best regards,
Hayden







On 20/07/2018 8:09 PM, Juergen Schoenwaelder wrote:

On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote:



I understand that the schema mount proposal is still effectively in a

state of flux, but are there any publicly visible implementations or

deployments of a NETCONF or RESTCONF server that those interested could

experiment with (e.g. to aid in client development)?



State of flux? It is past WG last call and IETF last call.



https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/



/js





--_000_5df7eb40589d4631a33c704358bc8f8eUSPEXCHPROD01GNETglobal_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











H=
i everyone,



I just wanted to ask if it would be possible to clarify the intentions arou=
nd some of the wording of the draft schema mount standard (Rev-10). In part=
icular, regarding entries of the /schema-mounts/mount-points list.


M=
y interpretation is that the intended use of the /schema-mounts/mount-point=
s list entries are to specify the
parent modules that contain a mount point. Following on from this, t=
he client should use the YANG library instance to determine which schema op=
tions can be mounted at the root of a mount point. This seems consistent wi=
th the examples of Appendix A of
 the draft standard.


In this email I wanted to highlight the follo=
wing sections of the draft RFC below. In my view they seem to me to be some=
what ambiguous, in implying that the mount-point list entries
 specify the *child* module (sub-schema):





>From 
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/?include_te=
xt=3D1


Section 3.3 R=
11; Page 7

> The "/schema-mounts" container has the "mount-point&qu=
ot; list as one of its children. Every entry of this list refers through it=
s key to a mount point and
specifies the mounted schema.



Section 3.3 - Page 8<=
span style=3D"font-size:12.0pt">

> An entry of the "mount-point" list can specify
the mounted schema in two different ways, =
"inline" or "shared-schema".





Section 9 - Page 13

> A mount point defines a place in the node hierarchy where other data =
models may be attached. A server that implements a module with a mount poin=
t populates the /schema-mounts/mount-point list
 with detailed information on which data models a=
re mounted at each mount point.



Section 9 - Page 14

list mount-point {

    key "module label";

    description

    "Each entry of this list =
specifies a schema for a particular mount point.


 




The wording makes me wonder if thes=
e passages might actually just be "left-over" context from earlie=
r revisions of the draft standard (Revision 8 and prior) -- effectively ref=
erring back to the schema-mount 'use-schema'
 list.








I do of course acknowledge that it is entirely possible that I've misinterp=
reted the wording of the passages above, however if that is the case, I sus=
pect I may not be the only one in future.

Many thanks for your time on this matter.



Best regards,

Hayden


 


 


 


 


 


 


 


On 20/07/2018 8:09 PM, Juergen Schoenwaelder wrote:<=
o:p>


On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote:=



  


I understand that the schema mount proposal is still effectively in a =



state of flux, but are there any publicly visible implementations or <=
o:p>


deployments of a NETCONF or RESTCONF server that those interested coul=
d 


experiment with (e.g. to aid in client development)?


 


State of flux? It is past WG last call and IETF last call.<=
/pre>

 


https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mo=
unt/history/


 


/js


 


 


 






--_000_5df7eb40589d4631a33c704358bc8f8eUSPEXCHPROD01GNETglobal_--


From nobody Mon Jul 30 17:41:32 2018
Return-Path: 
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 720CD130DFB for ; Mon, 30 Jul 2018 17:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 g1Rk_VeYqAyY for ; Mon, 30 Jul 2018 17:41:27 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 47E93130E11 for ; Mon, 30 Jul 2018 17:41:27 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6V0eWDM025378; Mon, 30 Jul 2018 17:41:26 -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=e5G9f7gn/GFjaLKgRq9pgor+Y0G+cWvppGTudthQGqk=; b=JqukRlHex3/SKUEvOoDWjbwinexHuNmqthHcKSgY3FywP7+yeHWZKrxQnUpqBYu/7LGS cazalLST2xnruY0t7rbuF0CnR5P/c8XlwUfZmM9jRfhrXZfsUrpoDmlUwN12FRYkMbGk RoBwcZrfagJoXUxGMGN47Yq7nYQHpVdfAaohNs7NOWcF5yoxSOtfnu+GVP30Np6JqSkq ZCKIfzkqzsjHXJOGWUsZklj2BzRlLWtLLLpM+YTXNyQBs1NfMYh9vzy1a0DfyYjwQrBU OT7tjmDzVjDdaP2zTmr/BgDuoJvJ0gW6SqnBc2J+EBi8aM/gsmxsQ42o1U5yEAflNcet RA== 
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0116.outbound.protection.outlook.com [216.32.180.116]) by mx0a-00273201.pphosted.com with ESMTP id 2kjbh1866e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Jul 2018 17:41:26 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4582.namprd05.prod.outlook.com (52.135.204.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.13; Tue, 31 Jul 2018 00:41:23 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416%2]) with mapi id 15.20.1017.010; Tue, 31 Jul 2018 00:41:23 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , Robert Wilton 
CC: NetMod WG 
Thread-Topic: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
Thread-Index: AQHUIHJ31DW+ryPtaESmByU8ep0YbaSZ1u6AgAAHAYCAAFoWgIAD6KEAgABfxACAAAWkgIABRzAAgABaFACAAAmQAIABImSAgABCQwCABrTrAA==
Date: Tue, 31 Jul 2018 00:41:23 +0000
Message-ID: 
References: <87va981svk.fsf@chopps.org>  <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>   <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com> <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de> <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com> <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4582; 6:5sAO30HSODctnMCSyO/+Y4SibqmYdf0Z7qG5KrPDWtza1lFum2tKDoRzG0vLPE+UPqfr12B+fhzFzo8b4ptCePYXWqhQMU/Wu5aEqExK7ARvmNUUkPzMNB5FmSc1hSLYZsPhw3SvOOoy7RfsT49ZNRO68Kz9mEKHipuXQiIFTgSbrNGi77E12C/9TBb95JzK/+EBRMoX1xkzXh3mDNjQKWoQwDlLPg7oAcsrVWTDYCiZ6RJqYnCG2UYvwdg/lslTRPd5ni228SATtRZ8yrg6a/9E/k0zg5/+bTq05ukMMpdGRe8KCsnW+j6t4AFw/D6TGQAeDhOBkEWU93qXvFw7U+rbGhtNetd5TPZrdf6qEMYAYi/YPj+TWTCAgaFKkWKoeDF9zNe1yYIIzZvBsGSzlRGuTOxFETr9xZfFW2usbQbs1tKK3JejQJRz82zDD+LyiDFKXJCQ900L+TrnF62fNg==; 5:7J/xICPXtYsHBLqOvm02LyYlHs/HgrdcFZoECEZnURiA+KXyuIt5pJY2FUMC81Yvb34ld5Eev2rj+7rj6+ogHQQxKJ1SuNX4++fBvDinrAIJVzwTQEB/lsC8x1Hv1DUrstgPOLylS6rCe6GOLnc3f5o/5SUxiGpJlM891CKbkF4=; 7:1Ngvru/MEsZQ1+Sbt37+9ZCipDCt1D4pmDoCViCN7tKM0idmOKW90JtgUs6S4+CDcntLpDg+z1zFFfMXS6EUatpw4kz7nx8mJqp/I5rOn6FECwcN3TJy6YTR3OeqxRdbOntqii4LugVcgMQ1CA0hCjX7J1Rh4Fy0zvNTtUbycoP4kd7JHdqLIaTWzlBv/mFCteWpjylYGWbjoZl5WA8eA/XoQ1GXAK6x2ifIIxVYI6NPm720S8+947NYH4AcrhTx
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f2492638-3dfb-466c-5cfb-08d5f67e5795
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4582; 
x-ms-traffictypediagnostic: BYAPR05MB4582:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4582; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4582; 
x-forefront-prvs: 0750463DC9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(39860400002)(366004)(396003)(189003)(199004)(5660300001)(82746002)(2906002)(33656002)(6436002)(3846002)(486006)(86362001)(6116002)(8676002)(106356001)(102836004)(6512007)(105586002)(476003)(7736002)(93886005)(5250100002)(2616005)(83716003)(14454004)(68736007)(97736004)(4326008)(446003)(6506007)(76176011)(2900100001)(305945005)(110136005)(53936002)(11346002)(66066001)(58126008)(99286004)(8936002)(229853002)(186003)(81156014)(478600001)(6486002)(256004)(6246003)(36756003)(26005)(316002)(81166006)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4582; H:BYAPR05MB4230.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: dIkSOlKPFbXtwI+Xugat8IXti5mw02WvIT0ebe/Pm+c2r3tywgnMD5yOzWdMd5nrmFyRLlRmuUxv1Xg4U7FJRDc1a50cDYBa/JUlIAPx8RIit/9q3iTu18xxAzRY3Dc8EmdyjxAwIyRv4N94uhvsy6q5iF8eQAUP69STtIgH/+xEUUJGZjP+PqYhu9vxP7xGL7SN162Ma5bzN04lAtIcjSmyuWq/cRJWO4c6ofWsDdn+zuJasz4WmC3E21RO13o+3aRoPiJc/EjVLfhJmt5Vx40jOW4Eec1w48CUmcx9LKgGFLe/ChToTr7RfRWgDAwQ3Okz6z6Fjnj21YKF4PaeyQuxp1ZB6VZKfN+ijJ3y+b4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1CF25B259E7B174B9317B40968B11D77@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f2492638-3dfb-466c-5cfb-08d5f67e5795
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2018 00:41:23.6670 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4582
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-30_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=666 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310006
Archived-At: 
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 00:41:31 -0000

DQoNCj4gU28gZG8gd2UgaGl0IGEgcmVxdWlyZW1lbnQgKHdoaWNoIGlzIGluZGVwZW5kZW50IG9m
IHZlcnNpb25pbmcpIHRoYXQgYQ0KPiBtZWNoYW5pc20gaXMgbmVlZGVkIHRvIHNlbGVjdCBkaWZm
ZXJlbnQgbW9kdWxlIHNldHMgKG9yIHZpZXdzKSwgZ2l2ZW4NCj4gdGhhdCB0aGUgcmVhbGl0eSBn
aXZlcyB1cyBvdmVybGFwcGluZyBhbmQgY29tcGV0aW5nIG1vZGVscz8gQW5kIHRoZW4NCj4gYXMg
YSBzaWRlIGVmZmVjdCwgc3VjaCBhIG1lY2hhbmlzbSBtYXkgYWxzbyBiZSB1c2VkIHRvIHNlbGVj
dCBiZXR3ZWVuDQo+IGRpZmZlcmVudCB2ZXJzaW9ucz8NCg0KU291bmRzIGNvbXBlbGxpbmcuICBS
ZW1pbmRzIG1lIG9mIEFuZHkncyBwYWNrYWdlcyBpZGVhLiAgSSdkIGxpa2UgdG8gc2VlDQp0aGUg
bmV4dCBsZXZlbCBvZiBhbmFseXNpcyBvbiB0aGlzIGlkZWEuDQoNCktlbnQgLy8gY29udHJpYnV0
b3INCg0KDQo=