From nobody Mon Jan 1 04:15: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 C52EA127011; Mon, 1 Jan 2018 04:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 iJlIt3xRe6hX; Mon, 1 Jan 2018 04:15:14 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0123.outbound.protection.outlook.com [104.47.1.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3CE1201F8; Mon, 1 Jan 2018 04:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4n+I6T1godMzUuBPfG2owPwoHd9UITlpUP3v1FZXGak=; b=gxOylPRuUuhmMjjDWxujwsyNpUl/120lqBzQcS8saseUuZXHT2CxawCfIjihnPGpRegjVsW3PZXrnE2ed+CzuUow1wYVoccT7e4F0La1zSgyRnHW+j4LSd+IhNBXPzJmj5H57BSKA1EVnzfKQ+MJe0jIkPS5e3r1diiRTc2+nZ4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.169.153.236) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Mon, 1 Jan 2018 12:15:10 +0000 Message-ID: <008c01d382f9$8e291140$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Acee Lindem \(acee\)" , "Benoit Claise \(bclaise\)" , "NetMod WG" , References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com> Date: Mon, 1 Jan 2018 12:09:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: DB3PR0102CA0011.eurprd01.prod.exchangelabs.com (2603:10a6:8::24) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 30d21b56-ee97-4dbc-df0b-08d551114dcf X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:vT1UC9vZXeTya/OS4/Bg9UumBTGk688p25hkV5LCqVn3wFBsevhaP+plSnLl/LrYDch/rH60T4AZvXly4Vu1GfRB98lQp36lNzNn+ufiOQZLEZByQDQhgXfWKUcvlHFOupFmcOHdH9V21TiD+Mux7E1KTEDUeddOrKbnoV4TmkJoGgUBgHJF/MAsLdWikmwYCrumOeRWzRtmNjC0MgYwApl2OgKeVjc41SJX4nP5wPLU4ebuj8+MIkoVgo/Hy+h6; 25:q/HE4+YtTXlweTjSEhdQZDh+LMWtoi1coyAELbYUaPRkdsF5m1vJxNymnTuoz8TTBRzjxYjH3xf7sNvlVtPGuB/hb0/wXCb+tF5zDG4icwEDSgCEsySbI1Ef/bGjHPEsMUXWXR2WBPAGvWCsiCm/NRltIShR29HO3nkCiqwj2vQ34wIAzwL/NNI4FIytJJjnS3FPP3WyacCjN0CpWJr6yq8sb8xnNNH2nmIiyp8sNH6sL/ifBdVZNCCB7pEicgqUa3UVBW9yaFx8zoHYRJhf2RtxG78Rv6ChY3q+wQsUiOLwmMqVHQCQhDfQFYdObUqyJXAzJw10wOx6ZUV5/qcHyQ==; 31:+N7vZu0k7/v+YP5kqrxEyPwfo80Ge9WoMC6ZEqVvwhisudou8wo6ICYpXpllW924/M7/4VQXXbLE10AMiGAwQWYmmiq6fmJHGHrhDzbOe/RnPgoi7/bZqdOFuE/JH2LQMolXWGw0iZLVqjrCejQ0DtfaEXOE69sDAMq0LZobWY4hT4iLwILGTW5lr5qGDi2wIFuZM6SBr+8DVHl0dzeg7bZDqtI338AYmT7nFGm/ckc= X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 4:+uL4vyJcsHHZOSDBHvTBETINVWXWoB+WFKdkjiu45+CaG081g5byz/68/fvffgU5OvDc6G/fBZr4xuGSRTQWvE0l3+HKyGzOehJb2yWpUY58q8kovCBCtyvLFHoTeHp/DHVIZlHzDExYmgbFiB6jUbaOyQU+gJfnYkjqiUUyPsM8TaPA5E05+P7znqInHYcqpF52c0tIbc3xmyqK6U8LO3CtMOIXHqX4sifCJmklJqWMh9LSVnokfSSIXcfijjGve5mv9Or+gWEkdt2xmCdpzD1bMNTZn6zPR+vqkThVacpq70rSpXY8s9BdQKk0a9mBhpzTIuzYww3WDqspnxf17kd00JEHbut0NaIn3dmaE38= X-Forefront-PRVS: 0539EEBD11 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(376002)(346002)(366004)(377424004)(13464003)(24454002)(199004)(189003)(1456003)(23676004)(6116002)(3846002)(6246003)(229853002)(44736005)(6486002)(50466002)(7736002)(9686003)(14496001)(6306002)(305945005)(84392002)(25786009)(2906002)(53936002)(47776003)(316002)(5820100001)(386003)(81686011)(53546011)(2870700001)(16526018)(110136005)(93886005)(81816011)(52116002)(6496006)(76176011)(62236002)(44716002)(66066001)(33896004)(105586002)(68736007)(106356001)(8936002)(8676002)(4720700003)(5660300001)(1556002)(478600001)(50226002)(81156014)(6666003)(81166006)(966005)(86362001)(116806002)(230783001)(61296003)(97736004)(4001150100001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7MjM6U0ZEbnBxcU10aGhnaWo5a05KWmt3VDZv?= =?utf-8?B?SzJZc01LUkg2MHJUMEJCMVpvWjBsR3YwNTJQdm9aY0tpa1cza3RsMmpxVlZR?= =?utf-8?B?UTFaQllvdlFiemZlQit5RWl0eENEZUVueHJtNGJDRXVVbXdJWGdHc3BRd1h0?= =?utf-8?B?MktJU1N2WHVBQVFzZUxYalVnS2Q4b1AxTmRraVU2OTdaNlFuQkFUcVFUMXEr?= =?utf-8?B?aXh4NERLTFdwcXBKZzhueTZTLzFYMDBnN3AzcnVUZmVvSjVSSDlOUm4xTzVH?= =?utf-8?B?NlpPbUVzb3p6dUZTMENGU3lIb0hlRnJKUFAxQUNMSzUwUkRHTGJZaWlKL1RO?= =?utf-8?B?RWtTeXMwYllyU1c3aGRUR0h0U09TNDNFcTFSbUhzLzBPbHNnVmhxQURyZWl1?= =?utf-8?B?KzFnZjJ1bWtsR21MWkJaY1NJbjhMOFg4T2dHOWxyNTcrN3BPSnlyT0dUYVFp?= =?utf-8?B?Y2xnUmpubWxLcTFZd1NLNUlQd0U1cjNOS1NRZmpzRENGLzFGODB2a0RUbGJB?= =?utf-8?B?R1kxc3FCUTN1V0JxeCtBUThLVG5zYk9ORU9UUkI0T0pYblcvak43WkpwektD?= =?utf-8?B?dGUvWUVhMDBpM0FKUjFMQ251QzdNR3JXZmRNdkRiSmp0N1ExOHE0SWl4V0lI?= =?utf-8?B?aDN2MXBrakFyRCt5c2ZueWkwL0x6aGloTUFRekJCVjlJRWpoWGJQbllINmtE?= =?utf-8?B?d2MzWjliVGJ0UEhsTWlMelVBb2N0WnlSZTZNV0xETGxNL3ZuWEJScGhnZ3do?= =?utf-8?B?d21yaUtPOXR1ZjhBVmlvWU9HRGpBUkJ4Q0kraTVRY2RuTE5CQ05vZzBLdVZx?= =?utf-8?B?MGMzcnRCdjdoYkxNbWJSN25PVXdBaHhZMnFXVmtwdnpFaWlmMzlYb1ZmbDNq?= =?utf-8?B?NGFWZlJNSUZ6aVJvcXcrR0FuQVFoYnBZOU9KdU9OVWN0eWdVK3hKK3M5RDRU?= =?utf-8?B?d0NvVDRNZjFyWDNjTmFIc2ZITVRrNW9BbXVZZzBGQTBvdVNoeEMyeWU1VjVG?= =?utf-8?B?VFpuSmoveXBJeUFNTW10eHNrcDFqQlNPVUZzTG0zUUE4THhGZlZ4RDMra0F4?= =?utf-8?B?NGk3K2JVdC9Odk1EM3pFZStSNDRNNWZQVko5V3RBSHRaSW8yTUh5cFFIZWxy?= =?utf-8?B?aTg1Z05Gc1hVUU11ZEFIRm1hdEVBMkRHZ2FnN0N0UXA0Z25MWm5lSlQ3MkdO?= =?utf-8?B?U1kraUZ5YVp0SEhXSW1IUmYxYyt6OWdsZmllYXpNYXdlV1JEclY2dElQVW45?= =?utf-8?B?SWhmdkxYVVdlK250M3B3Nkh6cDdmZytRTlhtMTZqcy8yYmxDT2tTK2RKb0hx?= =?utf-8?B?TnpTdGZrczRqU1ZhcWpOVTJWVytTS1NsM0NvbzhobFllWW9yZnEwSUcyZGdY?= =?utf-8?B?azZJQzRGZW9pU1lrb0VJU2dkdWVoYTA0U1dsWkZXRXVMVXdrOGh0cTFqZXUy?= =?utf-8?B?bEJ6Z3FNWCtURk5Lb0trTERVYkVqcUNBbE1KYmN3YXlhdUk4T1Bua1JnKzhq?= =?utf-8?B?T0lGT3YxeWhmVXQrVDQ1WGYvUTcvR2pVdFc3bUFCMmFyR0JDK2RQL2VJaU56?= =?utf-8?B?TEE0YUJvQkxnYlBkNm5EY01Oa3VNUFhRVGdPb3ZidVpqWnRKSWh5WTNtV2pQ?= =?utf-8?B?T3ozTm5yN0FQaGdHKzdBcy9KVm1YQVFFOS91QmY5clByNGRLMTJLQk1BUHo2?= =?utf-8?B?ODBQc0EyTWxILyswdk1ucCtIb1orVzMvaDRBT25iWEpsZ0RLcjlHSVhLbjNG?= =?utf-8?B?N1ZaYSs4YTRNdVN1cStHWWEraTBZWkwrcjhaa0xjdnVISDZwNlZ2ZjZFS2Vp?= =?utf-8?B?dHNIRlJvb2RXR08xeXlabSt0MGlRalVaZ2lqRTdmUlcyQkNORjExVFhPZHBB?= =?utf-8?B?OTdUREtsTUl5T2IySnZjYjJFUGJRUzMrMTc2Unl3aXpxemFORXErK29hd1Z5?= =?utf-8?B?Qk5MZEtDb3VrWDdidEZpUnlUWlEvUnNlTEZ0TmJiZ1F2b1FBOEVMRWdKM3p6?= =?utf-8?B?d2lFVlNGVWxvR2hWbTVicUhqT1VCMGFNOHhWcWF3ajRuZEtPblpzcFQ1NkdO?= =?utf-8?B?ODBKaWxNdGlidUZwZ1M5Y0VzZ2FlS003VEI2ZElCOGVVdm9rdkFDbE8zZDMw?= =?utf-8?Q?D6qBmgoGVn+ZO3FJJFKoyb77Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:U+JjswcqIeJZilkCjqQM3SC1Oo9UrIDPoXc43rxU34afZZF/83Tbk/SyM/c33DfP11F4sLlMkzwHdtRfftHndYNjLKjJFEoIMlzckSlUBRpWi1zdfGbmn1ag4ZmRR8w8/8QrAdTsE7N12iXzLMS1Gjm9O7RQpfgvc6AqHrPgWRWjn0lQf68p53IME0eHZmXqhpRmPlX39EVAU3sqnpTv+Nuk9JTr6Mxl+cREtN7UkkVMgC9Ml8uIyFgsqggMnBlFze3SuEdh0r6Vf9usvKiWXQYYC8ZhKCtE1vIHOM4UEnv14HWkO1WrIiX8eexSI79znGgSgH1Bgm0huRsJ9fU3dG0LaZtp/QoHhFSp/xx3fr4=; 5:9IKmV47L+g3LmSX5BPGyLCYgQYmhG149ZjpCZyLVNnQAmUb+HCvKWJ73i2rACKOFIFt961OUaiZy0MM5W8t2Lb55yBXwfiAuVFBrlWsmcWE5Zk/2KlcpM0XgIz0nkrReSjrFlxIGnEtQ4UGLOC9tqdxfQ5T3VzEZSRZFI74vAdM=; 24:ekiU26Q1gsGk47sGrYOfBA0tsY2YiJzZBrFwLVd9W7rNS37lRZqQ/ZHtip1LjGqYH7ITg/sMy0yXvdYADyo0Eam/ljeOUOVRXmVOMqUyOp8=; 7:l23J9MPIbK07gRl9zauX2e/oQAQP1VM3CHKdTpMzI+uO1nqbxYWVzHYPAv1vhiLHFvj+HUAeNTz30GdzOegyGq6zNmmF3e5VC6NaT6DML3xrR+iilnb+5jkQzSPXA9ewA3bpSO5QOS1RvoDGhKq2p0ZjJUToXWKswKOKDRKcrdJ92p8/7rdBglmtrg41ttPgS5v0cbMlPcpWN1h56b3geS4F6RRDIsBCZlfZb4dT65LZakHEj2gV3sxD8/21nFCr SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jan 2018 12:15:10.0024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 30d21b56-ee97-4dbc-df0b-08d551114dcf X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Subject: Re: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 12:15:19 -0000 ----- Original Message ----- From: "Acee Lindem (acee)" Sent: Wednesday, December 27, 2017 5:25 PM > Hi Benoit, > > On 12/27/17, 6:18 AM, "Benoit Claise (bclaise)" wrote: > > >Thanks Acee, > > > >Minor question for the working group and the draft-ietf-rtgwg-yang-rip > >authors. > > > >The appendix is about adding a new control-plane protocol. It takes as > >an example RIP. > >However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG > >telechat on Jan 11th). > >Does it make sense to keep the RIP example? If so, is the example > >consistent with draft-ietf-rtgwg-yang-rip? > >Or should we just point to draft-ietf-rtgwg-yang-rip as the example? > > It is probably better just to reference the RIP module draft. Does anyone > disagree? Disagree; strongly. You are then holding up as an example to the rest of the world of how to do it a YANG module produced by a WG over which we have no control and little influence and who may produce a less than satisfactory module. I have already commented that IMHO the rip module is not fit to advance and even if the issues are addressed we have no certainty that the module will be fit to hold up to the world as an examplar. So no, referencing yang-rip is a bad idea. Tom Petch > > Thanks, > Acee > > > >Not strong views on my side. > > > >Regards, Benoit > >> This version includes Martin’s YANG doctor comments and some updates to > >> the examples (e.g., YANG Library data) from Lada. > >> > >> Thanks, > >> Acee > >> > >> On 12/22/17, 1:28 PM, "netmod on behalf of internet-drafts@ietf.org" > >> wrote: > >> > >>> 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 : A YANG Data Model for Routing Management > >>>(NDMA > >>> Version) > >>> Authors : Ladislav Lhotka > >>> Acee Lindem > >>> Yingzhen Qu > >>> Filename : draft-ietf-netmod-rfc8022bis-06.txt > >>> Pages : 77 > >>> Date : 2017-12-22 > >>> > >>> Abstract: > >>> This document contains a specification of three YANG modules and one > >>> submodule. Together they form the core routing data model that > >>> serves as a framework for configuring and managing a routing > >>> subsystem. It is expected that these modules will be augmented by > >>> additional YANG modules defining data models for control-plane > >>> protocols, route filters, and other functions. The core routing > >>>data > >>> model provides common building blocks for such extensions -- routes, > >>> Routing Information Bases (RIBs), and control-plane protocols. > >>> > >>> The YANG modules in this document conform to the Network Management > >>> Datastore Architecture (NMDA). This document obsoletes RFC 8022. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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/ > >>> > >>> _______________________________________________ > >>> 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 > From nobody Mon Jan 1 14:01: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 89408120721; Mon, 1 Jan 2018 14:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 cT9_Ntl4woue; Mon, 1 Jan 2018 14:01:52 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 E19BE1200C5; Mon, 1 Jan 2018 14:01:52 -0800 (PST) Received: from mb.local ([IPv6:2601:1c0:cb00:da11:b1ad:65f7:63fb:2247]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w01M1pLo056300 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 1 Jan 2018 22:01:52 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:da11:b1ad:65f7:63fb:2247] claimed to be mb.local To: NETMOD Working Group Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org From: joel jaeggli Message-ID: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> Date: Mon, 1 Jan 2018 14:01:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vgRvtWdBGGds4uLwtw8UN67kPJwyjVmfp" Archived-At: Subject: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 22:01:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vgRvtWdBGGds4uLwtw8UN67kPJwyjVmfp Content-Type: multipart/mixed; boundary="5SgWtuy420WhNcQzeJrpjmmWOzkg6Jabc"; protected-headers="v1" From: joel jaeggli To: NETMOD Working Group Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org Message-ID: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> Subject: WGLC - draft-ietf-netmod-yang-tree-diagrams --5SgWtuy420WhNcQzeJrpjmmWOzkg6Jabc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Greetings, We hope the new year is a time to make great progess on outstanding documents before preparation for the London IETF begins in earnest. This starts a two-week working group last call on: YANG Tree Diagrams draft-ietf-netmod-yang-tree-diagrams https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ Please send email to the list indicating your support or concerns. We are particularly interested in statements of the form: * I have reviewed this draft and found no issues. * I have reviewed this draft and found the following issues: ... Thank you, NETMOD WG Chairs --5SgWtuy420WhNcQzeJrpjmmWOzkg6Jabc-- --vgRvtWdBGGds4uLwtw8UN67kPJwyjVmfp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWkqvygAKCRDwADWrtn9W sulGAJ92RQa0T4G4JdJWxFptaLN/dH0vPwCfZV/ygWBJt9BWoebFCuk1aUwB500= =+7JZ -----END PGP SIGNATURE----- --vgRvtWdBGGds4uLwtw8UN67kPJwyjVmfp-- From nobody Mon Jan 1 16:27:55 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 48F10124234; Mon, 1 Jan 2018 16:27:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk CC: netmod-chairs@ietf.org, Joel Jaeggli , netmod@ietf.org, joelja@bogus.com, bclaise@cisco.com, draft-ietf-netmod-rfc8022bis@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151485287429.22351.10456211675888099250.idtracker@ietfa.amsl.com> Date: Mon, 01 Jan 2018 16:27:54 -0800 Archived-At: Subject: [netmod] Last Call: (A YANG Data Model for Routing Management (NDMA Version)) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 00:27:54 -0000 The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for Routing Management (NDMA Version)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-01-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 2 02:42: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 D6CB0126FDC; Tue, 2 Jan 2018 02:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 Kd9WCcXkrqjD; Tue, 2 Jan 2018 02:42:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 ACA95126BF7; Tue, 2 Jan 2018 02:42:37 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 661886265F; Tue, 2 Jan 2018 11:42:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1514889755; bh=Q1eNNOy7Y5TSV69V7sTkGTsIFy8tuonKRkSUYnKa+Eg=; h=From:To:Date; b=H72o7JbnPTMhlYX2zWDqy1R6KdwizkcxLMJUbq1oT3a7Mpgy+a+BGnHN9kjPFfB9M lU7m2PidS7SYO6d+XGAsD55GcO9R+oCwD8/Bzim/vkjehwbMJmeyAL64lMRWLhEp6x XkF/UfgcWx+ueyUqaa3/5IMVCLDsGciwzDDe9rD8= Message-ID: <1514889755.4068.17.camel@nic.cz> From: Ladislav Lhotka To: "Acee Lindem (acee)" , "Benoit Claise (bclaise)" , NetMod WG , "draft-ietf-rtgwg-yang-rip@ietf.org" Date: Tue, 02 Jan 2018 11:42:35 +0100 In-Reply-To: References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 10:42:42 -0000 On Wed, 2017-12-27 at 17:25 +0000, Acee Lindem (acee) wrote: > Hi Benoit, > > On 12/27/17, 6:18 AM, "Benoit Claise (bclaise)" wrote: > > > Thanks Acee, > > > > Minor question for the working group and the draft-ietf-rtgwg-yang-rip > > authors. > > > > The appendix is about adding a new control-plane protocol. It takes as > > an example RIP. > > However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG > > telechat on Jan 11th). > > Does it make sense to keep the RIP example? If so, is the example > > consistent with draft-ietf-rtgwg-yang-rip? > > Or should we just point to draft-ietf-rtgwg-yang-rip as the example? > > It is probably better just to reference the RIP module draft. Does anyone > disagree? I tend to disagree. For this document, we need a simple example to illustrate the steps that need to be done. Any production module, be it ietf-rip or anything else, necessarily involves some complexity that defeats the purpose of the example. In my view, the present RIP example is fine. Perhaps we can extend the disclaimer saying that it is not intended as a production module and also provide a non-normative reference to the "real" RIP module. Lada > > Thanks, > Acee > > > > Not strong views on my side. > > > > Regards, Benoit > > > This version includes Martin’s YANG doctor comments and some updates to > > > the examples (e.g., YANG Library data) from Lada. > > > > > > Thanks, > > > Acee > > > > > > On 12/22/17, 1:28 PM, "netmod on behalf of internet-drafts@ietf.org" > > > wrote: > > > > > > > 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 : A YANG Data Model for Routing Management > > > > (NDMA > > > > Version) > > > > Authors : Ladislav Lhotka > > > > Acee Lindem > > > > Yingzhen Qu > > > > Filename : draft-ietf-netmod-rfc8022bis-06.txt > > > > Pages : 77 > > > > Date : 2017-12-22 > > > > > > > > Abstract: > > > > This document contains a specification of three YANG modules and one > > > > submodule. Together they form the core routing data model that > > > > serves as a framework for configuring and managing a routing > > > > subsystem. It is expected that these modules will be augmented by > > > > additional YANG modules defining data models for control-plane > > > > protocols, route filters, and other functions. The core routing > > > > data > > > > model provides common building blocks for such extensions -- routes, > > > > Routing Information Bases (RIBs), and control-plane protocols. > > > > > > > > The YANG modules in this document conform to the Network Management > > > > Datastore Architecture (NMDA). This document obsoletes RFC 8022. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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/ > > > > > > > > _______________________________________________ > > > > 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 Jan 2 03:59: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 C27461274D2; Tue, 2 Jan 2018 03:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WKFd2e67zwUn; Tue, 2 Jan 2018 03:59:06 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED28126D05; Tue, 2 Jan 2018 03:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6570; q=dns/txt; s=iport; t=1514894346; x=1516103946; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=h7VdK0Ivuhx1KpM4lrBryIsD0CjNc8pxTazFKMnKKo0=; b=cldue2+q64Fcp4nEQPunxXRrh/3gKeg7miba//Dj+q39kbBS7W+tcOGG hBwtIqxyqO/d88v7gPAObI3bfkyL7fu7AEpCRm+Ke/gKlo/Xgd32fpM+t g/AzRjv+udjNxEkC0FgWSRRJZkC0YDT++9IMXzmu/mqiCwAGNpzxlTdi/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAAD9ckta/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4QAiiSPGIIBlyqCFQoYC4RJTwIahBY/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQEDAQEhETobAgEIEgYCAiYCAgIlCxUCDgIEARKKLhCyBYInhBcBh?= =?us-ascii?q?hkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+CfYE1XYM/gy6DLwEBF4RtgmUFo0w?= =?us-ascii?q?CiAGNMoIXZYUxi1CNJIkyAhEZAYE7AR85gU9vFRkkgikJhBMBOniHaYEWAQEB?= X-IronPort-AV: E=Sophos;i="5.45,496,1508803200"; d="scan'208";a="51286647" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jan 2018 11:59:05 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w02Bx5ui017417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Jan 2018 11:59:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 2 Jan 2018 06:59:04 -0500 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; Tue, 2 Jan 2018 06:59:04 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "Benoit Claise (bclaise)" , NetMod WG , "draft-ietf-rtgwg-yang-rip@ietf.org" , Tom Petch Thread-Topic: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt Thread-Index: AQHTfwRmtyMCVakw5E6pebB4gVVRlKNXcWeAgAlRLoD//8F0gA== Date: Tue, 2 Jan 2018 11:59:04 +0000 Message-ID: References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com> <1514889755.4068.17.camel@nic.cz> In-Reply-To: <1514889755.4068.17.camel@nic.cz> 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.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 11:59:10 -0000 SGkgTGFkYSwgVG9tLA0KDQpPa2F5IC0gbm8gc2Vuc2UgaW4gZGVyYWlsaW5nIHRoaXMgZHJhZnQg YmFzZWQgb24gYW4gZXhhbXBsZSBpZiB0aGVyZSBpc27igJl0DQpjb25zZW5zdXMuIA0KDQpUaGFu a3MsDQpBY2VlIA0KDQpPbiAxLzIvMTgsIDU6NDIgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90 a2FAbmljLmN6PiB3cm90ZToNCg0KPk9uIFdlZCwgMjAxNy0xMi0yNyBhdCAxNzoyNSArMDAwMCwg QWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4gSGkgQmVub2l0LCANCj4+IA0KPj4gT24gMTIv MjcvMTcsIDY6MTggQU0sICJCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSIgPGJjbGFpc2VAY2lzY28u Y29tPg0KPj53cm90ZToNCj4+IA0KPj4gPiBUaGFua3MgQWNlZSwNCj4+ID4gDQo+PiA+IE1pbm9y IHF1ZXN0aW9uIGZvciB0aGUgd29ya2luZyBncm91cCBhbmQgdGhlIGRyYWZ0LWlldGYtcnRnd2ct eWFuZy1yaXANCj4+ID4gYXV0aG9ycy4NCj4+ID4gDQo+PiA+IFRoZSBhcHBlbmRpeCBpcyBhYm91 dCBhZGRpbmcgYSBuZXcgY29udHJvbC1wbGFuZSBwcm90b2NvbC4gSXQgdGFrZXMgYXMNCj4+ID4g YW4gZXhhbXBsZSBSSVAuDQo+PiA+IEhvd2V2ZXIsIGRyYWZ0LWlldGYtcnRnd2cteWFuZy1yaXAg aXMgYmVpbmcgZmluYWxpemVkIChvbiB0aGUgSUVTRw0KPj4gPiB0ZWxlY2hhdCBvbiBKYW4gMTF0 aCkuDQo+PiA+IERvZXMgaXQgbWFrZSBzZW5zZSB0byBrZWVwIHRoZSBSSVAgZXhhbXBsZT8gSWYg c28sIGlzIHRoZSBleGFtcGxlDQo+PiA+IGNvbnNpc3RlbnQgd2l0aCBkcmFmdC1pZXRmLXJ0Z3dn LXlhbmctcmlwPw0KPj4gPiBPciBzaG91bGQgd2UganVzdCBwb2ludCB0byBkcmFmdC1pZXRmLXJ0 Z3dnLXlhbmctcmlwIGFzIHRoZSBleGFtcGxlPw0KPj4gDQo+PiBJdCBpcyBwcm9iYWJseSBiZXR0 ZXIganVzdCB0byByZWZlcmVuY2UgdGhlIFJJUCBtb2R1bGUgZHJhZnQuIERvZXMNCj4+YW55b25l DQo+PiBkaXNhZ3JlZT8NCj4NCj5JIHRlbmQgdG8gZGlzYWdyZWUuIEZvciB0aGlzIGRvY3VtZW50 LCB3ZSBuZWVkIGEgc2ltcGxlIGV4YW1wbGUgdG8NCj5pbGx1c3RyYXRlDQo+dGhlIHN0ZXBzIHRo YXQgbmVlZCB0byBiZSBkb25lLiBBbnkgcHJvZHVjdGlvbiBtb2R1bGUsIGJlIGl0IGlldGYtcmlw IG9yDQo+YW55dGhpbmcgZWxzZSwgbmVjZXNzYXJpbHkgaW52b2x2ZXMgc29tZSBjb21wbGV4aXR5 IHRoYXQgZGVmZWF0cyB0aGUNCj5wdXJwb3NlIG9mDQo+dGhlIGV4YW1wbGUuDQo+DQo+SW4gbXkg dmlldywgdGhlIHByZXNlbnQgUklQIGV4YW1wbGUgaXMgZmluZS4gUGVyaGFwcyB3ZSBjYW4gZXh0 ZW5kIHRoZQ0KPmRpc2NsYWltZXIgc2F5aW5nIHRoYXQgaXQgaXMgbm90IGludGVuZGVkIGFzIGEg cHJvZHVjdGlvbiBtb2R1bGUgYW5kIGFsc28NCj5wcm92aWRlIGEgbm9uLW5vcm1hdGl2ZSByZWZl cmVuY2UgdG8gdGhlICJyZWFsIiBSSVAgbW9kdWxlLg0KPg0KPkxhZGENCj4NCj4+IA0KPj4gVGhh bmtzLA0KPj4gQWNlZSANCj4+ID4gDQo+PiA+IE5vdCBzdHJvbmcgdmlld3Mgb24gbXkgc2lkZS4N Cj4+ID4gDQo+PiA+IFJlZ2FyZHMsIEJlbm9pdA0KPj4gPiA+IFRoaXMgdmVyc2lvbiBpbmNsdWRl cyBNYXJ0aW7igJlzIFlBTkcgZG9jdG9yIGNvbW1lbnRzIGFuZCBzb21lDQo+PnVwZGF0ZXMgdG8N Cj4+ID4gPiB0aGUgZXhhbXBsZXMgKGUuZy4sIFlBTkcgTGlicmFyeSBkYXRhKSBmcm9tIExhZGEu DQo+PiA+ID4gDQo+PiA+ID4gVGhhbmtzLA0KPj4gPiA+IEFjZWUNCj4+ID4gPiANCj4+ID4gPiBP biAxMi8yMi8xNywgMToyOCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIg0KPj4gPiA+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPj53cm90ZToNCj4+ID4gPiANCj4+ID4gPiA+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPj4gPiA+ID4gZGlyZWN0b3JpZXMuDQo+PiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPj4gPiA+ ID4gDQo+PiA+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVs IGZvciBSb3V0aW5nIE1hbmFnZW1lbnQNCj4+ID4gPiA+IChORE1BDQo+PiA+ID4gPiBWZXJzaW9u KQ0KPj4gPiA+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCj4+ ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQWNlZSBMaW5kZW0NCj4+ID4gPiA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUNCj4+ID4gPiA+IAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA2LnR4dA0KPj4gPiA+ID4gCVBh Z2VzICAgICAgICAgICA6IDc3DQo+PiA+ID4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0y Mg0KPj4gPiA+ID4gDQo+PiA+ID4gPiBBYnN0cmFjdDoNCj4+ID4gPiA+ICAgIFRoaXMgZG9jdW1l bnQgY29udGFpbnMgYSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcw0KPj5hbmQg b25lDQo+PiA+ID4gPiAgICBzdWJtb2R1bGUuICBUb2dldGhlciB0aGV5IGZvcm0gdGhlIGNvcmUg cm91dGluZyBkYXRhIG1vZGVsIHRoYXQNCj4+ID4gPiA+ICAgIHNlcnZlcyBhcyBhIGZyYW1ld29y ayBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZw0KPj4gPiA+ID4gICAgc3Vi c3lzdGVtLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwgYmUNCj4+YXVn bWVudGVkIGJ5DQo+PiA+ID4gPiAgICBhZGRpdGlvbmFsIFlBTkcgbW9kdWxlcyBkZWZpbmluZyBk YXRhIG1vZGVscyBmb3IgY29udHJvbC1wbGFuZQ0KPj4gPiA+ID4gICAgcHJvdG9jb2xzLCByb3V0 ZSBmaWx0ZXJzLCBhbmQgb3RoZXIgZnVuY3Rpb25zLiAgVGhlIGNvcmUNCj4+cm91dGluZw0KPj4g PiA+ID4gZGF0YQ0KPj4gPiA+ID4gICAgbW9kZWwgcHJvdmlkZXMgY29tbW9uIGJ1aWxkaW5nIGJs b2NrcyBmb3Igc3VjaCBleHRlbnNpb25zIC0tDQo+PnJvdXRlcywNCj4+ID4gPiA+ICAgIFJvdXRp bmcgSW5mb3JtYXRpb24gQmFzZXMgKFJJQnMpLCBhbmQgY29udHJvbC1wbGFuZSBwcm90b2NvbHMu DQo+PiA+ID4gPiANCj4+ID4gPiA+ICAgIFRoZSBZQU5HIG1vZHVsZXMgaW4gdGhpcyBkb2N1bWVu dCBjb25mb3JtIHRvIHRoZSBOZXR3b3JrDQo+Pk1hbmFnZW1lbnQNCj4+ID4gPiA+ICAgIERhdGFz dG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDDQo+ PjgwMjIuDQo+PiA+ID4gPiANCj4+ID4gPiA+IA0KPj4gPiA+ID4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiA+ID4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLw0KPj4gPiA+ ID4gDQo+PiA+ID4gPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQo+PiA+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2QtcmZjODAyMmJpcy0wNg0KPj4gPiA+ID4gDQo+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wNg0KPj4gPiA+ID4gDQo+ PiA+ID4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+PiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1u ZXRtb2QtcmZjODAyMmJpcy0wNg0KPj4gPiA+ID4gDQo+PiA+ID4gPiANCj4+ID4gPiA+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+PiA+ID4gPiBzdWJtaXNzaW9uDQo+PiA+ID4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+PnRvb2xzLmlldGYub3JnLg0KPj4gPiA+ ID4gDQo+PiA+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQo+PiA+ID4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPj4gPiA+ID4gDQo+PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gPiA+ID4gbmV0 bW9kQGlldGYub3JnDQo+PiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KPj4gPiA+IA0KPj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gPiA+IG5l dG1vZEBpZXRmLm9yZw0KPj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+LS0gDQo+TGFk aXNsYXYgTGhvdGthDQo+SGVhZCwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiAweEI4RjkyQjA4 QTlGNzZDNjcNCg0K From nobody Tue Jan 2 14:03:23 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 BC8CC12D850; Tue, 2 Jan 2018 14:03:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mahesh Jethanandani To: Cc: draft-ietf-netmod-rfc7277bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151493059670.30939.8241436286877635051@ietfa.amsl.com> Date: Tue, 02 Jan 2018 14:03:16 -0800 Archived-At: Subject: [netmod] Yangdoctors early review of draft-ietf-netmod-rfc7277bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 22:03:17 -0000 Reviewer: Mahesh Jethanandani Review result: Ready Document reviewed: draft-ietf-netmod-rfc7277bis-01 Status: Ready This review is looking at the draft from a YANG perspective. Summary: This document updates the ietf-ip YANG data model to comply with the NMDA requirements. Comments: I believe the document is ready. The YANG compilation page shows the model passing all compilations. From nobody Wed Jan 3 11:52:39 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 96CDB126C83; Wed, 3 Jan 2018 11:52:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Andy Bierman To: Cc: draft-ietf-netmod-rfc7223bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151500915856.30927.2802442728843365900@ietfa.amsl.com> Date: Wed, 03 Jan 2018 11:52:38 -0800 Archived-At: Subject: [netmod] Yangdoctors early review of draft-ietf-netmod-rfc7223bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 19:52:38 -0000 Reviewer: Andy Bierman Review result: Ready This module appears to follow all NMDA transition guidelines. There are no YANG compiler errors or warnings. From nobody Thu Jan 4 04:41: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 712D412751F; Thu, 4 Jan 2018 04:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 rNg88jUhEqMT; Thu, 4 Jan 2018 04:41:46 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0113.outbound.protection.outlook.com [104.47.0.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB1F1271DF; Thu, 4 Jan 2018 04:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vLp8F08aQq1qZUfuXyb35woD25sX/TaxzlcAXBIDL/8=; b=SusRFXvVEoHGPg+geSDPgYv08nn2Gjk2eyM7XjSEd3G+edokpZh7uizllIBbE1uOIjEAjn1/PsxbuDsQotawTbQFLZ34s9kvJE3i7haFQVhhNDotKIM+9zjoc1j3n4XzHb5bjEgUlnsY6UbrOhPF2LV+1PTh5WxCHkO/uI7+zRA= Received: from pc6 (86.169.153.236) by AM4PR07MB1555.eurprd07.prod.outlook.com (2a01:111:e400:7a79::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Thu, 4 Jan 2018 12:41:42 +0000 Message-ID: <04bb01d38558$bf88b4a0$4001a8c0@gateway.2wire.net> From: "tom p." To: Cc: , , , References: <151389497762.28118.16231694341929195271.idtracker@ietfa.amsl.com> Date: Thu, 4 Jan 2018 12:37:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: LNXP265CA0048.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::36) To AM4PR07MB1555.eurprd07.prod.outlook.com (2a01:111:e400:7a79::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09d1eb4e-89ff-4bb5-2271-08d55370824b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(8989060)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307); SRVR:AM4PR07MB1555; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1555; 3:nBUG2xV4tbJBgxPHDs2rzdlKVi+lII3QBLICSylIZmfSrkRXuDnidJYjLM0wnM80z28j0Bu+8k1JCZr7z7ZlHXzvawC/QtwrIbIxggENt02gUq+dKtUsy3LJBvqTmbro7KKiTVhWOw2epbGjyk5Vr//ND1hImS4dEcJm7QBokhocM32gvf8v45cCY4itgzBKGx4jQ/yYkhC5ddJomgpXrmDbcY8OAEjQv+lWSsUDPsSXcxbCqLhVzejZvBff+IBl; 25:mH8/oz1tNsDdMDpvulnPGEt5sFCNv9C7nNYReIYC/D6F313okX/jCwT17V/7lX66zJwZlvoeABmFxOVt7zlI6QC4xhK0ZzOHPhK+DWWqQIDPT5yz3lLOKs2R60eaOtga2QuGG0LdjAJNFxkm6DX96Hqu4vOZszfYZyYm39hECyhinzH2qCn3AOGCuXJSmug482pgBkrNJ3L5xBatEOPstH/E0V14T2kdguSluvbS7VoFG4l7W+WsC2beSnqD/Bd0c0ENxoSvT1mMZsIbVaX5z7tjmkUMSrfLOAbpAsPl1kqphrmpu1esLLBsGzNZReZhZJwY47HXQcla+CS2WE8msA==; 31:P3sXfyu5xdi5QegwT3R4laVjl5j1zMJSmy1kyGRPXKC6j6RIButbKW1QxSN2vQ17WKBmNjfaGNEfs4rGjtDVNyn63tYT7YiyoiVecQdizhwRVioE4xdnQA/GqpCh0Rcdzudeqqe3Ti690Ha0coUP9zYo50M3r0G7Vdvdnp8LPdulkNcSYathRMYy8Jgg76xcci7qadpLBdO6XFjrdCKuxZtcAQ589r2thGcguNGkGlQ= X-MS-TrafficTypeDiagnostic: AM4PR07MB1555: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(20161123222025)(3231023)(944501075)(10201501046)(6055026)(61426038)(61427038)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB1555; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB1555; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1555; 4:i2B+nWc9SYhXNuBgy43BI2pdeG609eeW4QmoMWPtz6nAfsgfGxeiRZjh2U9rPZYUx+kKQRSIOsg40ttxRekjT6z5EfZZq3RDA5wgsFk8qMoU3Q+lfTYzq5Kojrcgt+5U0fN8tC3NVDIXx9DsNir+Ego08Ri4wEfvGwF0NE7nNOoWaSFeQkcfYhQJl3G9T6KS1RRPiyI1NMmJfM2ETS2FPFYo5/4OZh7PGWI3OOefOS0CQcHY7ompWvRwvso4pCiEJzXtWeLgygeWGOEmm9GHTAjEj5g07e25LT2TXQ463P4nhY/pHqi0YNS4C6U6lvxr X-Forefront-PRVS: 054231DC40 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39380400002)(39860400002)(376002)(396003)(189003)(199004)(13464003)(40224003)(1456003)(230700001)(229853002)(6496006)(1556002)(44736005)(386003)(33896004)(54906003)(116806002)(230783001)(2906002)(316002)(478600001)(6486002)(5660300001)(6116002)(6666003)(4720700003)(84392002)(25786009)(53936002)(9686003)(3846002)(86362001)(6916009)(97736004)(305945005)(7736002)(966005)(2351001)(16526018)(106356001)(62236002)(105586002)(76176011)(81686011)(6306002)(44716002)(50466002)(52116002)(81816011)(2486003)(23676004)(68736007)(66066001)(47776003)(6246003)(4326008)(50226002)(59450400001)(8936002)(81156014)(61296003)(8676002)(14496001)(81166006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1555; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIxNTU1OzIzOkRiSlRIQUE2RVBYNHE3aFphdk93ZUhOblMx?= =?utf-8?B?RFk3UjIwbG4wN211TE85UUhPUVZVWkRSWncrODZUTzBCTWpMbzlaU1pjTTRV?= =?utf-8?B?MVp0MGZ2SUE1cGVDazZBeVV3T2VheUZMdGtRU1NXZk1WVEc3R1drRE9HVXZh?= =?utf-8?B?UXNMYnNMWXdqSkdaZ1E5dG10M3IxdnhOUTlXMmVseStiOFRzdXdZSUhpSEhH?= =?utf-8?B?QzF1bUZNK3BtOVZINXdsamx3ejBHUmRFb29ZZkxEUmF2ZW5xRkZKN1VLdFow?= =?utf-8?B?cGxSdFlGZTB3eHdQcFFEYUhrR0J1VWlrL3BwN0UwOTBYM0cwMEw2Rmo3a2la?= =?utf-8?B?KzZEYjYzM1Y4Vy92UmRaeFVpcWtpMDNuS0g1MVI0UnVrNlUxNkdFV0tEUjRz?= =?utf-8?B?cWdrbGtCU1BjZEgwZGpqL04wQTRPcmYvVVVCN3dGeENYNUxmak9XVlQ2ZWV5?= =?utf-8?B?TnBnK3MyWXBCUEtCUndNazdZa3o5RzFWWVlrbXpEU2cvck5MYWJPZTMvS3Nj?= =?utf-8?B?NHl3QUt2OGRkTjJqNTVSNHdPdEZTSDBzbnJ2cmc2SVFuT2ZwTENMdkRqR2ll?= =?utf-8?B?d00xS3J2cHBuRkdvSDl4RGxHZ1VPZElqL1laOEx6OEZ2Z1N5MzNmTERGeCtN?= =?utf-8?B?VFJzQkltQm9jU3NaR2ozb0VjY2FPalU2ZURwb2RIbVVESC9hQU84MHlVMEpF?= =?utf-8?B?VG1LWmRFcmNyaXlEeGxrMGlrMGFBZ3p2ZXE0TjVnMnNxWjBhMDQ5ZWxOKzlW?= =?utf-8?B?VWNveHRkMXFqQjRTeFJNdzl1MkFzME0reFZZUEVuYm43dGp4MVV4TnlBUjY4?= =?utf-8?B?dVgwMnZJRjhYN05kYWVQUU1QNnFQSEtLWXo1Z1hnL1dDMEhtd1UyOTVSSzFS?= =?utf-8?B?Qld0emVxUDV4RHhUWGcxczlqSmw1TzZ2YW9LL1ZIQjRWaXFvYm5KN2pJMVZG?= =?utf-8?B?ajdiL3p1WWk0U0ZZWmZlWVdYY2x0bXNwQ1dUZnBySk1HOFVBMkNvZUJjb3Ax?= =?utf-8?B?TjZkdUtLc1VodnEwZStYaFVqUTRxQTg4SERWWThYaWExQ3ZSZ1ZkVkZEVStx?= =?utf-8?B?cHkxYXRVcStweHJGVFM0Q0dsM05XSlJLOGtNR21KcndnMkhpeDdWK1pza1JM?= =?utf-8?B?aE15K2ZFZy9KNUQxWTFjTWZ2aXlNTlJyUisydnJtRStoYysvRm0xaEJXNS8x?= =?utf-8?B?ZU83OG5LaHE2dHhMUHIzeXo5b2ZhU3BZYWxnajkveEZlQlQ5Y3JEQkQyQVk3?= =?utf-8?B?WnpVOVU4QkE2c2hhb0YyVDNwUVRFUW0wNUQvZHJOVnppaC9YMGZwQ1BvdFYz?= =?utf-8?B?K1RtMEE3eXdxWUtGM3BhL1lsazIzSWNoU3c4Qm11YmhjeUw0NE9JVEM1UXd5?= =?utf-8?B?RXFYYXE5dDVUZlBCQ3B2RVFlbzJKcjcwMUhXRmx0dzRmWlFkdmo2NkMvVnMw?= =?utf-8?B?UFlWWUp4QmFDbldzQVQvVk9yamRNZ0tOZ241NGFXTVN0WjFyWE1ZWkx3Qjc5?= =?utf-8?B?N3BXTjBtUTM0Y1BTMXoydUJacTREbTJaZXZlYjh4UlFWbmdYUUxiNlRzWCtV?= =?utf-8?B?L1kzdWROWXBjR29CL1N3WmNEdG1VK05mMnQxZWwzYU04SVVjQjhzaHp4OWdP?= =?utf-8?B?bUxSa0xQT0o4QVVKMnNKTEs5aGcrYUxFQVFBSmhPYm9tY0tNZVNTdlpKRWZS?= =?utf-8?B?SFFhVFVXUTNvOHFjS2VjdTNnaWpRWWNqTThCTFlucVlVWnJ1VDNJUlpmdW84?= =?utf-8?B?NVo2ZXppOHY2ZDBRY1BmUFdVVTNIL3Y3YVhYSFJvZy9OVllBbnk2UStLS0hD?= =?utf-8?B?cC90UTV0MlYzcE5FaE5GUWk1aURjN1hRcTNUckovSURYbW4yVVQwTG9CYmgr?= =?utf-8?B?cXNIS3JUTEJZNG5RSnRLdVEzL0I5Z1pEc3RCdUpPZzBmMEJSUEJnUjZyVHhO?= =?utf-8?B?bDJrVEg5K3VZdnFBRzN4T01LOENFOFF5Y3krMlRNLzZNWHBRUjVkZllzcHA5?= =?utf-8?B?Z0M5WFNiMzZYSVVpRXo0cnRrdXo0cTZmUDRvUkhheVVpK3IvU0RBNTVZVEo0?= =?utf-8?B?VFAxYzkvSnAxNEloeGNna1dNTWxuQWxmc3JRY282aFR6Z3lNY3BOZDNLTjRQ?= =?utf-8?B?YUE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1555; 6:C05ndCymRK3ruxVM43jjSyCzJf+4k/Ps5pzcS7adff5tet1W2lRaKYIEc//XP8haeGl7FLWPUPV3IpZMlr0ok+cnS6i0AWNUh7Mzkdv3NXPBUYjYNhhkoK0LFJc/gG7II53YdjpO+9j7QPGZj7JMD1R2qGWnPtguMH85uNs8GJDnqLs4yXGvY53s3taNH17RPnZDWahnzG56nk06Wt2pKRKBHQOEOzXIm/umZ5TzQ1vQzj2TgQLFJEu4YpSJoSgqvtb9z1A/t/cGKf9imKVZ/M0QMnW8kooDaiFO3oCRVuLbLXR6i2aW5n481CA2TqljMXCnDfPNsVi5j+bTSaeKdrZffs5NsJ/uQs24u6RFTBA=; 5:384DnGMCFBKfkSi7euoiJJed3pJzw51F9ZnV0WaXM+rZZJyuB4MMJIhzUP5GXomaoNt6csKhhG/JotZknJ8ENl1OR3/Cj2o7HeHoieoN0UHxfwzXZijDuxTVoJ/24AoQo5UiyUaVZF+I3OTQdZr/XS56rhNpmM67G630XEiDv54=; 24:6PBWmPKNckhYNVkAEIU8Uxh7cMvAq9eChYh/SzmQo8EgZKHRLw951xWMHU1OS3262IJEQL56GvYr3uZd5U2gbtvzSTDNeJnXgHjTmLcx7gM=; 7:PbuycRjHS2PxQHMexIiKYNmcu/gu67z4H3SpSqU3LyFcfFMw5fLjBx4J1CwLHgP+2CBAvPlxdIZcglDYswlMxT7kB9ZGZPLFL4ne+EoCGrIsqvGxacSXOOtfVoM+eZHNKMywEA2OyCkzypNxiu9LATHGAkyWYPpYF31On8JSyal6WtmVIuwckh5upLumsPAwoHL5ZipzMEdoeFYptu5yxRbOHJJg//pQn8miiFDxp8rXKShVpowOhMPMPjd8SX5D SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2018 12:41:42.5353 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 09d1eb4e-89ff-4bb5-2271-08d55370824b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1555 Archived-At: Subject: Re: [netmod] Last Call: (A YANG Data Model for Hardware Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 12:41:49 -0000 This I-D illlustrates a problem that the netmod WG has been wrestling with for a decade or more and (IMHO) has yet fully to solve. This I-D is in Last Call at the same time as netmod-revised-datastores, which proposes the most recent solution. The problem is that an 'object' can take more than one value and the question is how to represent that. Previously it was by having twin trees in the schema; now it is by having one common schema and multiple datastores, for the user-supplied values, for those actually in use, the latter including values learnt from the hardware or protocols or some other means. In this model the situation arises with 'serial-num' which may take a value from the hardware or may be written as part of configuration (the idea of configuring serial numbers may seem unusual but has been inherited from the Entity MIB [RFC6933] with the endorsement of the netmod WG). So if there is an accessible hardware value and the user writes a value, who wins? There is no way of specifying this, neither in YANG nor in 'revised-datastores'; in this case, the 'description' specifies that the value determined from the component should be used so a user can configure a value, see it in the datastore but not in the datastore and cannot tell why, unless they are familiar with the minutiae of description clauses. In this case, the model is clear as to which value, configured or learnt, wins; here, it is learnt. In other cases, it may be that configured wins or that may be something a user wants to influence as part of policy. Is that still one schema or is it now two slightly different schemas based on the description clause coupled with the datastore that the schema is being applied to? Is the description clause an adequate way of expressing policy? In passing, routing protocols addressed this dilemma a long time ago, with concepts such as 'Admin Distance'. (Whether or not this particular value should be configurable is a different and irrelevant discussion; the MIB WG decided it should be, the YANG WG likewise - and there are plenty of other objects which illustrate this dilemma, how to specify who wins). Tom Petch ----- Original Message ----- From: "The IESG" Sent: Thursday, December 21, 2017 10:22 PM > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'A YANG Data Model for Hardware Management' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > This document defines a YANG data model for the management of > hardware on a single server. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ballot/ > > No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 4 04:46: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 DA49C12711A; Thu, 4 Jan 2018 04:46:12 -0800 (PST) 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_RP_MATCHES_RCVD=-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 rp-8KN7fzeW9; Thu, 4 Jan 2018 04:46:11 -0800 (PST) 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 40F8F127369; Thu, 4 Jan 2018 04:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6316; q=dns/txt; s=iport; t=1515069970; x=1516279570; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4Nl3GQ5dH8cIZd5HrhMdBAdbHgWMkGQ9oMHOrOlPjFY=; b=QicdmK/+v9ZJegOnH+NxueoiGiASwovLBT88cdHq9ZKGdlf76ogxzDfg OWEBbu3K87wwhBCk/djBnlXHvdSrNdpHXvtVvuJTYWeUgXxz0GgFPd/2A SoMNy9TEQBow/j9ybF1RCqkcFseoF5HF9/IeaYdxjjs55IprZWzIsG2KA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgCzIU5a/xbLJq1dGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdCeEB4sYj2MLkgCFUYIVChgBCoUYAoRxFgEBAQEBAQEBAWsohSQ?= =?us-ascii?q?CAQMBASFLCxALEjACAiciDhMGAgEBBYolELIagicmihgBAQEBAQEBAwEBAQEBA?= =?us-ascii?q?QEBIIQTg2iBaSkMgnmDJAsBAReEbYJlBaNWiAaNNYIXZYUzg22HaY0xgQBaiAW?= =?us-ascii?q?BPCYGLCWBKjIaCBsVGSSCKgmET0A3AYkMAQEB?= X-IronPort-AV: E=Sophos;i="5.45,507,1508803200"; d="scan'208,217";a="1206742" 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; 04 Jan 2018 12:46:05 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w04Ck5Jh023997; Thu, 4 Jan 2018 12:46:05 GMT To: i-d-announce@ietf.org Cc: netmod@ietf.org References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> From: Benoit Claise Message-ID: <4592d575-2523-bed7-9949-caa51b119cfe@cisco.com> Date: Thu, 4 Jan 2018 13:46:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <151396733267.27997.4142470279197260306@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------81080A6931C2F5739DF51A83" Content-Language: en-US Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 12:46:13 -0000 This is a multi-part message in MIME format. --------------81080A6931C2F5739DF51A83 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, While the abstract mentions: "This document obsoletes RFC 8022 .", you forgot the obsolete tag in the header. Regards, Benoit. > 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 : A YANG Data Model for Routing Management (NDMA Version) > Authors : Ladislav Lhotka > Acee Lindem > Yingzhen Qu > Filename : draft-ietf-netmod-rfc8022bis-06.txt > Pages : 77 > Date : 2017-12-22 > > Abstract: > This document contains a specification of three YANG modules and one > submodule. Together they form the core routing data model that > serves as a framework for configuring and managing a routing > subsystem. It is expected that these modules will be augmented by > additional YANG modules defining data models for control-plane > protocols, route filters, and other functions. The core routing data > model provides common building blocks for such extensions -- routes, > Routing Information Bases (RIBs), and control-plane protocols. > > The YANG modules in this document conform to the Network Management > Datastore Architecture (NMDA). This document obsoletes RFC 8022. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . > --------------81080A6931C2F5739DF51A83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi,

While the abstract mentions: "This document obsoletes RFC 8022.", you forgot the obsolete tag in the header.

Regards, Benoit.
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           : A YANG Data Model for Routing Management (NDMA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-06.txt
	Pages           : 77
	Date            : 2017-12-22

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
.

--------------81080A6931C2F5739DF51A83-- From nobody Thu Jan 4 04:46: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 6CC5E127369; Thu, 4 Jan 2018 04:46:27 -0800 (PST) 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_RP_MATCHES_RCVD=-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 lBZAKhA6SFGR; Thu, 4 Jan 2018 04:46:26 -0800 (PST) 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 B328512711A; Thu, 4 Jan 2018 04:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1515069984; x=1516279584; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Shl7kyTHRFc1P2eC2mBelCnopcZKLkmwG0zBYsCiM6g=; b=m2tXx0GuRqYTbZ5LrHWheotpzePlcLl6MaurrxJP+r07vtypwFhYPj7j w+0KfWOslD8ciXCymw3X7m/+3/fgnQq9ez2AqFSpr3iAYdaYRH3oHSZdE eEr1GG7e1cDG0cscXvWqckwRTK9bvfYEe6Pu9SRfngmUepm03X0xqdgdO M=; X-IronPort-AV: E=Sophos;i="5.45,507,1508803200"; d="scan'208";a="1253886" 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; 04 Jan 2018 12:46:22 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w04CkLZK024135; Thu, 4 Jan 2018 12:46:21 GMT To: "Acee Lindem (acee)" , Ladislav Lhotka , NetMod WG , "draft-ietf-rtgwg-yang-rip@ietf.org" , Tom Petch References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com> <1514889755.4068.17.camel@nic.cz> From: Benoit Claise Message-ID: Date: Thu, 4 Jan 2018 13:46:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 12:46:27 -0000 On 1/2/2018 12:59 PM, Acee Lindem (acee) wrote: > Hi Lada, Tom, > > Okay - no sense in derailing this draft based on an example if there isn’t > consensus. Fine with me. Regards, B. > > Thanks, > Acee > > On 1/2/18, 5:42 AM, "Ladislav Lhotka" wrote: > >> On Wed, 2017-12-27 at 17:25 +0000, Acee Lindem (acee) wrote: >>> Hi Benoit, >>> >>> On 12/27/17, 6:18 AM, "Benoit Claise (bclaise)" >>> wrote: >>> >>>> Thanks Acee, >>>> >>>> Minor question for the working group and the draft-ietf-rtgwg-yang-rip >>>> authors. >>>> >>>> The appendix is about adding a new control-plane protocol. It takes as >>>> an example RIP. >>>> However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG >>>> telechat on Jan 11th). >>>> Does it make sense to keep the RIP example? If so, is the example >>>> consistent with draft-ietf-rtgwg-yang-rip? >>>> Or should we just point to draft-ietf-rtgwg-yang-rip as the example? >>> It is probably better just to reference the RIP module draft. Does >>> anyone >>> disagree? >> I tend to disagree. For this document, we need a simple example to >> illustrate >> the steps that need to be done. Any production module, be it ietf-rip or >> anything else, necessarily involves some complexity that defeats the >> purpose of >> the example. >> >> In my view, the present RIP example is fine. Perhaps we can extend the >> disclaimer saying that it is not intended as a production module and also >> provide a non-normative reference to the "real" RIP module. >> >> Lada >> >>> Thanks, >>> Acee >>>> Not strong views on my side. >>>> >>>> Regards, Benoit >>>>> This version includes Martin’s YANG doctor comments and some >>> updates to >>>>> the examples (e.g., YANG Library data) from Lada. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> On 12/22/17, 1:28 PM, "netmod on behalf of internet-drafts@ietf.org" >>>>> >>> wrote: >>>>>> 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 : A YANG Data Model for Routing Management >>>>>> (NDMA >>>>>> Version) >>>>>> Authors : Ladislav Lhotka >>>>>> Acee Lindem >>>>>> Yingzhen Qu >>>>>> Filename : draft-ietf-netmod-rfc8022bis-06.txt >>>>>> Pages : 77 >>>>>> Date : 2017-12-22 >>>>>> >>>>>> Abstract: >>>>>> This document contains a specification of three YANG modules >>> and one >>>>>> submodule. Together they form the core routing data model that >>>>>> serves as a framework for configuring and managing a routing >>>>>> subsystem. It is expected that these modules will be >>> augmented by >>>>>> additional YANG modules defining data models for control-plane >>>>>> protocols, route filters, and other functions. The core >>> routing >>>>>> data >>>>>> model provides common building blocks for such extensions -- >>> routes, >>>>>> Routing Information Bases (RIBs), and control-plane protocols. >>>>>> >>>>>> The YANG modules in this document conform to the Network >>> Management >>>>>> Datastore Architecture (NMDA). This document obsoletes RFC >>> 8022. >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ >>>>>> >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06 >>>>>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06 >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Thu Jan 4 05:21:09 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 B31FA126FDC; Thu, 4 Jan 2018 05:21:02 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151507206270.23804.5681435201873245182@ietfa.amsl.com> Date: Thu, 04 Jan 2018 05:21:02 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:21:03 -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 : A YANG Data Model for Routing Management (NDMA Version) Authors : Ladislav Lhotka Acee Lindem Yingzhen Qu Filename : draft-ietf-netmod-rfc8022bis-07.txt Pages : 77 Date : 2018-01-04 Abstract: This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-07 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 Thu Jan 4 05:21:54 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 7AB1A129C56; Thu, 4 Jan 2018 05:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0YI5QmHbO0Os; Thu, 4 Jan 2018 05:21:50 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E36E126CD6; Thu, 4 Jan 2018 05:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11353; q=dns/txt; s=iport; t=1515072110; x=1516281710; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5JNK5FbOdhe8CYLvtAjiHWRaU6CwJomgG6bTRwlGB+A=; b=ipIra5QZ8daY8kpjJJMRpmZEeIp2A03ZPw8sgPJVpCZxAgOYR6dgDQRq lMlwWCIFQ3KcDwD1uPPm9w6nHUbLPa9/s6ez+LQeGFZIz7uHX7ua3Lh5d AxllcVWfQdG+7+ZTiqAZBnHan7KNieYoTR16pe0c5SibLniq9fX7ZFKIv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AACCKU5a/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweEAIokjwiCAZFZhVGCFQoYAQ6FFAIahBY/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSMBAQEBAwEBIUsLEAIBCBEBAgECKAMCAgIlCxQDBggCBAENBQmJQ?= =?us-ascii?q?WQQsgGCJyaKGAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EE4ISgz+DLoMkCwEBF4F?= =?us-ascii?q?2HoJZgmUFo1YCiASNNYIXZYUzi1aNMYEAiDICERkBgTsBHzklgSpvFRkkgioJh?= =?us-ascii?q?E54AQGHdYEWAQEB?= X-IronPort-AV: E=Sophos; i="5.45,507,1508803200"; d="scan'208,217"; a="52206866" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2018 13:21:49 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w04DLmj3011544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jan 2018 13:21:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 4 Jan 2018 08:21:48 -0500 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; Thu, 4 Jan 2018 08:21:48 -0500 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" , "i-d-announce@ietf.org" CC: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.txt Thread-Index: AQHThVpio6C5fsVs/0Gx7PW+in8tDqNjszEA Date: Thu, 4 Jan 2018 13:21:47 +0000 Message-ID: References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> <4592d575-2523-bed7-9949-caa51b119cfe@cisco.com> In-Reply-To: <4592d575-2523-bed7-9949-caa51b119cfe@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.198] Content-Type: multipart/alternative; boundary="_000_D6739473E8526aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:21:52 -0000 --_000_D6739473E8526aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KR29vZCBjYXRjaCAtIEkgaGF2ZSBmaXhlZCBpbiB0aGUg4oCTMDcgdmVyc2lv bi4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkJlbm9pdCBD bGFpc2UgKGJjbGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28u Y29tPj4NCkRhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDQsIDIwMTggYXQgNzo0NiBBTQ0KVG86ICJp LWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4iIDxpLWQt YW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogIm5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxt YWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA2LnR4dA0KDQpIaSwNCg0KV2hpbGUgdGhl IGFic3RyYWN0IG1lbnRpb25zOiAiVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDgwMjI8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgwMjI+LiIsIHlvdSBmb3Jnb3QgdGhlIG9ic29s ZXRlIHRhZyBpbiB0aGUgaGVhZGVyLg0KDQpSZWdhcmRzLCBCZW5vaXQuDQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgTW9k ZWxpbmcgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5H IERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFuYWdlbWVudCAoTkRNQSBWZXJzaW9uKQ0KICAgICAg ICBBdXRob3JzICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgQWNlZSBMaW5kZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUN CiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0w Ni50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogNzcNCiAgICAgICAgRGF0ZSAgICAgICAg ICAgIDogMjAxNy0xMi0yMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgY29udGFpbnMg YSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcyBhbmQgb25lDQogICBzdWJtb2R1 bGUuICBUb2dldGhlciB0aGV5IGZvcm0gdGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsIHRoYXQN CiAgIHNlcnZlcyBhcyBhIGZyYW1ld29yayBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIGEg cm91dGluZw0KICAgc3Vic3lzdGVtLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVz IHdpbGwgYmUgYXVnbWVudGVkIGJ5DQogICBhZGRpdGlvbmFsIFlBTkcgbW9kdWxlcyBkZWZpbmlu ZyBkYXRhIG1vZGVscyBmb3IgY29udHJvbC1wbGFuZQ0KICAgcHJvdG9jb2xzLCByb3V0ZSBmaWx0 ZXJzLCBhbmQgb3RoZXIgZnVuY3Rpb25zLiAgVGhlIGNvcmUgcm91dGluZyBkYXRhDQogICBtb2Rl bCBwcm92aWRlcyBjb21tb24gYnVpbGRpbmcgYmxvY2tzIGZvciBzdWNoIGV4dGVuc2lvbnMgLS0g cm91dGVzLA0KICAgUm91dGluZyBJbmZvcm1hdGlvbiBCYXNlcyAoUklCcyksIGFuZCBjb250cm9s LXBsYW5lIHByb3RvY29scy4NCg0KICAgVGhlIFlBTkcgbW9kdWxlcyBpbiB0aGlzIGRvY3VtZW50 IGNvbmZvcm0gdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudA0KICAgRGF0YXN0b3JlIEFyY2hpdGVj dHVyZSAoTk1EQSkuICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODAyMi4NCg0KDQpUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMvDQoN ClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA2aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIy YmlzLTA2DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1y ZmM4MDIyYmlzLTA2DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkkt RC1Bbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFm dCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0Kb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCi4NCg0KDQoNCg== --_000_D6739473E8526aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBCZW5vaXQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pkdvb2QgY2F0Y2ggLSBJIGhhdmUgZml4ZWQgaW4gdGhlIOKAkzA3 IHZlcnNpb24uJm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2QgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7QmVub2l0IENsYWlzZSAoYmNsYWlzZSkmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+YmNsYWlzZUBjaXNjby5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1 cnNkYXksIEphbnVhcnkgNCwgMjAxOCBhdCA3OjQ2IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ UmU6IFtuZXRtb2RdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDYu dHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRk ZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRp diB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1vei1jaXRl LXByZWZpeCI+SGksPGJyPg0KPGJyPg0KV2hpbGUgdGhlIGFic3RyYWN0IG1lbnRpb25zOiAmcXVv dDtUaGlzIGRvY3VtZW50IG9ic29sZXRlcyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjODAyMiI+DQpSRkMgODAyMjwvYT4uJnF1b3Q7LCB5b3UgZm9yZ290IHRoZSBvYnNv bGV0ZSB0YWcgaW4gdGhlIGhlYWRlci48YnI+DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQuPGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MTUxMzk2NzMzMjY3LjI3 OTk3LjQxNDI0NzAyNzkxOTcyNjAzMDZAaWV0ZmEuYW1zbC5jb20iPg0KPHByZSB3cmFwPSIiPkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5l dHdvcmsgTW9kZWxpbmcgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAg IDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFuYWdlbWVudCAoTkRNQSBWZXJzaW9u KQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgQWNlZSBMaW5kZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgWWlu Z3poZW4gUXUNCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlz LTA2LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDc3DQoJRGF0ZSAgICAgICAgICAgIDogMjAxNy0x Mi0yMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgYSBzcGVjaWZpY2F0 aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcyBhbmQgb25lDQogICBzdWJtb2R1bGUuICBUb2dldGhl ciB0aGV5IGZvcm0gdGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsIHRoYXQNCiAgIHNlcnZlcyBh cyBhIGZyYW1ld29yayBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZw0KICAg c3Vic3lzdGVtLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwgYmUgYXVn bWVudGVkIGJ5DQogICBhZGRpdGlvbmFsIFlBTkcgbW9kdWxlcyBkZWZpbmluZyBkYXRhIG1vZGVs cyBmb3IgY29udHJvbC1wbGFuZQ0KICAgcHJvdG9jb2xzLCByb3V0ZSBmaWx0ZXJzLCBhbmQgb3Ro ZXIgZnVuY3Rpb25zLiAgVGhlIGNvcmUgcm91dGluZyBkYXRhDQogICBtb2RlbCBwcm92aWRlcyBj b21tb24gYnVpbGRpbmcgYmxvY2tzIGZvciBzdWNoIGV4dGVuc2lvbnMgLS0gcm91dGVzLA0KICAg Um91dGluZyBJbmZvcm1hdGlvbiBCYXNlcyAoUklCcyksIGFuZCBjb250cm9sLXBsYW5lIHByb3Rv Y29scy4NCg0KICAgVGhlIFlBTkcgbW9kdWxlcyBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm0gdG8g dGhlIE5ldHdvcmsgTWFuYWdlbWVudA0KICAgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSAoTk1EQSku ICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODAyMi4NCg0KDQpUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCjxhIGNsYXNzPSJtb3otdHh0LWxp bmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLzwvYT4NCg0KVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9k LXJmYzgwMjJiaXMtMDYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dG1vZC1yZmM4MDIyYmlzLTA2PC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2QtcmZjODAyMmJpcy0wNiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA2PC9hPg0KDQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy ZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1uZXRtb2QtcmZjODAyMmJpcy0wNiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDY8L2E+DQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvPC9hPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1v ei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9y ZyI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRl eHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91 bmNlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwv YT4NCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy ZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIj5odHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPg0Kb3IgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiPmZ0 cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9hPg0KLg0KDQo8L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6739473E8526aceeciscocom_-- From nobody Thu Jan 4 05:33: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 B6E5D12D832; Thu, 4 Jan 2018 05:33:11 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 146htIJUtzrg; Thu, 4 Jan 2018 05:33:09 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFEF126CD6; Thu, 4 Jan 2018 05:33:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4AF4A3D; Thu, 4 Jan 2018 14:33:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Mixov6DwfW-M; Thu, 4 Jan 2018 14:33:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Jan 2018 14:33:08 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 370A420136; Thu, 4 Jan 2018 14:33:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W294e799sm9D; Thu, 4 Jan 2018 14:33:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E00420134; Thu, 4 Jan 2018 14:33:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 748234203D9C; Thu, 4 Jan 2018 14:33:07 +0100 (CET) Date: Thu, 4 Jan 2018 14:33:07 +0100 From: Juergen Schoenwaelder To: "tom p." Cc: netmod@ietf.org, draft-ietf-netmod-entity@ietf.org Message-ID: <20180104133307.mihhlwavxqdc3qok@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "tom p." , netmod@ietf.org, draft-ietf-netmod-entity@ietf.org References: <151389497762.28118.16231694341929195271.idtracker@ietfa.amsl.com> <04bb01d38558$bf88b4a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04bb01d38558$bf88b4a0$4001a8c0@gateway.2wire.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Last Call: (A YANG Data Model for Hardware Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:33:12 -0000 On Thu, Jan 04, 2018 at 12:37:02PM -0000, tom p. wrote: > This I-D illlustrates a problem that the netmod WG has been wrestling > with for a decade or more and (IMHO) has yet fully to solve. This I-D > is in Last Call at the same time as netmod-revised-datastores, which > proposes the most recent solution. > > The problem is that an 'object' can take more than one value and the > question is how to represent that. Previously it was by having twin > trees in the schema; now it is by having one common schema and multiple > datastores, for the user-supplied values, for > those actually in use, the latter including values learnt from the > hardware or protocols or some other means. > > In this model the situation arises with 'serial-num' which may take a > value from the hardware or may be written as part of configuration (the > idea of configuring serial numbers may seem unusual but has been > inherited from the Entity MIB [RFC6933] with the endorsement of the > netmod WG). > > So if there is an accessible hardware value and the user writes a value, > who wins? There is no way of specifying this, neither in YANG nor in > 'revised-datastores'; in this case, the 'description' specifies that the > value determined from the component should be used so a user can > configure a value, see it in the datastore but not in the > datastore and cannot tell why, unless they are familiar > with the minutiae of description clauses. The origin attribute will at least tell you where the operationally used value is originating from. > In this case, the model is clear as to which value, configured or > learnt, wins; here, it is learnt. In other cases, it may be that > configured wins or that may be something a user wants to influence as > part of policy. > > Is that still one schema or is it now two slightly different schemas > based on the description clause coupled with the datastore that the > schema is being applied to? > > Is the description clause an adequate way of expressing policy? > > In passing, routing protocols addressed this dilemma a long time ago, > with concepts such as 'Admin Distance'. > > (Whether or not this particular value should be configurable is a > different and irrelevant discussion; the MIB WG decided it should be, > the YANG WG likewise - and there are plenty of other objects which > illustrate this dilemma, how to specify who wins). > > Tom Petch > > ----- Original Message ----- > From: "The IESG" > Sent: Thursday, December 21, 2017 10:22 PM > > > The IESG has received a request from the Network Modeling WG (netmod) > to > > consider the following document: - 'A YANG Data Model for Hardware > Management' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > This document defines a YANG data model for the management of > > hardware on a single server. > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ballot/ > > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > 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 Thu Jan 4 06:10:27 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 832B512D86B; Thu, 4 Jan 2018 06:10:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= To: Cc: draft-ietf-netmod-entity.all@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151507502144.23798.1644071576333370968@ietfa.amsl.com> Date: Thu, 04 Jan 2018 06:10:21 -0800 Archived-At: Subject: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:10:22 -0000 Reviewer: Radek Krejčí Review result: Ready with Issues The document itself and normative parts seem fine to me, the only issue I see is with the ietf-hardware-state module in non-normative appendix A. It seems to me that this temporary non-NMDA module does not conform to its purpose as described in RFC6087bis. According to guidelines, such a module is intended to provide state (config false) data in case the server does not implement NMDA (to bridge the time period until NMDA is implemented). So such a server is IMHO intended to implement both modules, foo and foo-state. The foo-state contains "the top-level config-false data nodes that would have been defined in a legacy YANG module" - so it's only the ro mirror of data nodes. But ietf-hardware-state contains notifications, which are not the data nodes as defined in RFC7950. I understand why the notifications were placed also into the ietf-hardware-state - the module's description states that "If a server that implements this module but doesn't support NMDA also supports configuration of hardware components, it SHOULD also implement the module 'ietf-hardware' ...", so it allows its standalone usage in case the server does not support hw configuration. But in such a case, the server can implement ietf-hardware with deviations on the config=true nodes. The same way it had to implement the legacy YANG module (before NMDA). So I think that the notifications should be removed from ietf-hardware-state and the module's description should change this way: OLD If a server that implements this module but doesn't support NMDA also supports configuration of hardware components, it SHOULD also implement the module 'ietf-hardware' in the configuration datastores. The corresponding state data is found in the '/hw-state:hardware' subtree. NEW If a server that implements this module but doesn't support NMDA, it MUST also implement the module 'ietf-hardware' in the configuration datastores. The corresponding state data is found in the '/hw-state:hardware' subtree. From nobody Thu Jan 4 19:47: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 260CD127333 for ; Thu, 4 Jan 2018 19:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=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 RI1sfejcifzz for ; Thu, 4 Jan 2018 19:47:25 -0800 (PST) Received: from mx0b-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 A10BB127137 for ; Thu, 4 Jan 2018 19:47:25 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w053jPt2009501 for ; Thu, 4 Jan 2018 19:47:25 -0800 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=oUaXXQSG3/kkhsiPHfion8WEqenHFLAxjFHH7M2EGdM=; b=Mwyxu/iqcyMNpZq4fSXWhbsmdp9/ttDky3r+Vv5A5q+chyVbdogx39n1eKeLeV7obmnu /oUXiEdQZJ0usU3PGNAYv0a4hA6wshYYEPv4bcTrODH1PeDGtTMFDomVuhWqA16QWbp0 /BKu28Mm53zBgyvj9gX2Je2Odn5904xwrW2wqJwn78psp0VAq//EBm+sewpJqarGsowG cmfw3HrH6gjElMGCl4eUyYqePQM8HI9oVpNe7QugSioEL0wjnWqS8UouO8/+EGZDlhP8 bWqJ1XxLcibLaUoPzeLrV3/NT/ltmaheIV8134F9+vzQNmZBwyFnnGnmd0qmo1/qaJFM Ag== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0085.outbound.protection.outlook.com [207.46.163.85]) by mx0a-00273201.pphosted.com with ESMTP id 2fa1bhr11e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 04 Jan 2018 19:47:25 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2793.namprd05.prod.outlook.com (10.168.175.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Fri, 5 Jan 2018 03:47:23 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0407.000; Fri, 5 Jan 2018 03:47:23 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: syslog-model-18 shepherd writeup issues Thread-Index: AQHThdfle+mgMO3MmESdKCsZf/n8Dw== Date: Fri, 5 Jan 2018 03:47:23 +0000 Message-ID: <4F31BAEF-AAC8-43F5-93E8-13EFE1EBEF18@juniper.net> 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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB2793; 7:MDX1emxIX1KPuWuk7Ia7S7uvFXqitWOzzCjd5yPz7EARJkU/sAmHrmH5jq5jAlnvKvZs90pwPpxUA23wXUigataOlwA0p4b8ypVrNXqqnfjqs18uKLOVi9voPellvcya0i546XSSpY/wGlmumSiRkibN0VB8+jnyhKrAGvWPFnzEDdz2a0167Vi/kuFyLXmX8lsXxEsEMltX7MM3e5OLJ4LHYDHqXlPILiL6M70oCfNGsAvMlz61B9WoCsu91fRe x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 17078e7c-08bb-4909-fb27-08d553ef079e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR05MB2793; x-ms-traffictypediagnostic: DM5PR05MB2793: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041268)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB2793; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB2793; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(39380400002)(396003)(366004)(346002)(199004)(189003)(105586002)(6506007)(53376002)(2501003)(81166006)(81156014)(8676002)(6306002)(6512007)(6116002)(3846002)(59450400001)(1730700003)(5640700003)(478600001)(8936002)(33656002)(3660700001)(305945005)(36756003)(25786009)(7736002)(66066001)(6916009)(83506002)(106356001)(102836004)(53936002)(3280700002)(68736007)(2906002)(4001150100001)(5660300001)(6486002)(99286004)(2900100001)(2351001)(316002)(58126008)(97736004)(6436002)(966005)(86362001)(82746002)(77096006)(83716003)(14454004)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2793; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7wwxU1FJJusXnVPmjRFx3x2YNJWBMU3pZgVU+3hAdlCqVyDlQu1b4EXF2ufUdZ8NV2Q2bpyitB0tKZxeX3PeIw== 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: 17078e7c-08bb-4909-fb27-08d553ef079e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 03:47:23.2629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2793 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-05_02:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801050047 Archived-At: Subject: [netmod] syslog-model-18 shepherd writeup issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 03:47:28 -0000 W1dlbGNvbWUgdG8gMjAxOCFdDQoNCg0KSGkgQ2x5ZGUsDQoNCkluIHJldmlld2luZyB0aGUgLTE4 IGRyYWZ0IGZvciBTaGVwaGVyZCB3cml0ZS11cCwgSSBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3Vl cyB0aGF0IEkgdGhpbmsgbmVlZCB0byBiZSBhZGRyZXNzZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBj YW4gYmUgc2VudCB0byBCZW5vaXQgZm9yIEFEIHJldmlldzoNCg0KDQoxLiBJIGJlbGlldmUgdGhh dCB0aGVyZSBpcyBhIHBlbmRpbmcgcmVxdWVzdCBmcm9tIFRvbSBvbiB0aGF0IGhhcyB5ZXQgdG8g YmUgYWRkcmVzc2VkOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1v ZC9Ga0V6UWVMSjMxRmlpakZrLVMtb2p5YWZNZHcNCg0KMi4gSWRuaXRzIGZvdW5kIHRoZSBmb2xs b3dpbmcuICAgTm90ZSwgSSdtIGF3YXJlIHRoYXQgaWRuaXRzLCB3aGVuIHJ1biB2aWEgdGhlIGRy YWZ0IHN1Ym1pc3Npb24gdG9vbCwgZG9lc24ndCBzaG93IGFueSBpc3N1ZXMsIHdoaWNoIGlzIHBy b2JhYmx5IHdoeSB5b3UgZGlkbid0IGZpeCB0aGVzZSBiZWZvcmUuIEZXSVcsIEknbSB1c2luZyB0 aGUgdG9vbCBsb2NhdGVkIGF0IGh0dHBzOi8vd3d3LmlldGYub3JnL3Rvb2xzL2lkbml0cyBhbmQg ZG8gTk9UIHNlbGVjdCB0aGUgIm9ubHkgZG8gc3VibWlzc2lvbiBjaGVja3MiIGJveC4NCg0KICBD aGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZC1pbmZvL2No ZWNrbGlzdCA6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAqKiBUaGVyZSBpcyAxIGluc3Rh bmNlIG9mIHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qgb25lDQog ICAgIGJlaW5nIDEgY2hhcmFjdGVyIGluIGV4Y2VzcyBvZiA3Mi4NCg0KDQogIENoZWNraW5nIHJl ZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQNCiAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQogICAgIChTZWUgUkZDcyAzOTY3IGFuZCA0ODk3IGZvciBpbmZvcm1h dGlvbiBhYm91dCB1c2luZyBub3JtYXRpdmUgcmVmZXJlbmNlcw0KICAgICB0byBsb3dlci1tYXR1 cml0eSBkb2N1bWVudHMgaW4gUkZDcykNCg0KICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQzYw MjEnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDM3NCwgYnV0IG5vdCBkZWZpbmVkDQoNCiAgKiogT2Jz b2xldGUgdW5kZWZpbmVkIHJlZmVyZW5jZTogUkZDIDYwMjEgKE9ic29sZXRlZCBieSBSRkMgNjk5 MSkNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNjY5MScgaXMgZGVmaW5lZCBvbiBsaW5l IDE0NDYsIGJ1dCBubyBleHBsaWNpdA0KICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0 ZXh0DQoNCiAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzc4OTUnIGlzIGRlZmluZWQgb24gbGlu ZSAxNDU0LCBidXQgbm8gZXhwbGljaXQNCiAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUg dGV4dA0KDQogICoqIERvd25yZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gSGlzdG9yaWMg UkZDOiBSRkMgNjU4Nw0KDQogICoqIERvd25yZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4g SW5mb3JtYXRpb25hbCBSRkM6IFJGQyA2NjkxDQoNCjMuIEluIFNlY3Rpb24gNC4xLCBbUkZDIHh4 eHhdIG5lZWRzIHRvIGJlIFtJLUQuaWV0Zi1uZXRjb25mLWtleXN0b3JlXSBhbmQNCiAgIFtSRkMg eXl5eV0gbmVlZHMgdG8gYmUgW0ktRC5pZXRmLW5ldGNvbmYtdGxzLWNsaWVudC1zZXJ2ZXJdLg0K DQo0LiBBbHNvIGluIFNlY3Rpb24gNC4xLCB0aGUgcmVmZXJlbmNlIHN0YXRlbWVudHMgZm9yIHRo ZSBpZXRmLWtleXN0b3JlDQogICBhbmQgaWV0Zi10bHMtY2xpZW50IG1vZHVsZXMgYXJlIHJldmVy c2VkLg0KDQo1LiBUaGlzIGlzIG1vcmUgb2YgYSBuaXQsIGJ1dCBwbGVhc2UgZml4IHRoZSBJQU5B IENvbnNpZGVyYXRpb25zIHNlY3Rpb24NCiAgIHNvIGl0IGhhcyB0d28gc2VjdGlvbnMgKGkuZS4s IDcuMSBhbmQgNy4yKSwgb25lIGZvciBlYWNoIHJlZ2lzdHJ5IHRoYXQNCiAgIGlzIHVwZGF0ZWQu DQoNCjYuIFRoaXMgaXMgZGVmaW5pdGVseSBhIG5pdCwgYnV0IGluIDcuMSwgInRoZSB0aGUiIC0t PiAidGhlIi4gIGFsc28sIHNvbWV0aGluZw0KICAgaXMgd3Jvbmcgd2l0aCB5b3VyIHJlZmVyZW5j ZXMgaW4gdGhpcyBzZWN0aW9uLCBhcyB0aGV5J3JlIGJlaW5nIHJlbmRlcmVkDQogICB3aXRoIFhN TCBibGVlZGluZyB0aHJ1IChlLmcuLCAiXVw+IikuICBbUFM6IHRoaXMgaXMgbGlrZWx5IHRoZSBy b290IGNhdXNlDQogICBmb3IgdGhlIFJGQzc4OTUgaXNzdWUgbWVudGlvbmVkIGFib3ZlXS4NCg0K Ny4gSW4gU2VjdGlvbiA3LCB0aGUgUmVnaXN0cmFudCBDb250YWN0IHNob3VsZCBwcm9iYWJseSBi ZSAiVGhlIElFU0ciIChub3QgDQogICAiVGhlIE5FVENPTkYgV0cgb2YgdGhlIElFVEYiKSwgcGVy IFJGQyAzNjg4LCBTZWN0aW9uIDQuDQoNCjguIGByZmNzdHJpcGAgZXh0cmFjdGVkICJpZXRmLXN5 c2xvZy55YW5nQDIwMTctMTItMTIueWFuZyIsIHdoaWNoIGhhcyBhDQogICBzdXBlcmZsdW91cyAi LnlhbmciIGluIGl0LiAgW2NoZWNrIHlvdXIgPENPREUgQkVHSU5TPiBsaW5lXQ0KDQo5LiBUaGUg ZXhhbXBsZXMgaW4gU2VjdGlvbiA1IGRvIG5vdCBuZWVkIHRvIGRlZmluZSB0aGUgInhtbG5zOnN5 c2xvZyIgcHJlZml4LA0KICAgYXMgdGhlIHByZWZpeCBpc24ndCB1c2VkIGFueXdoZXJlIGluIHRo ZSBleGFtcGxlcy4NCg0KMTAuIEluIFNlY3Rpb24gNiwgcGxlYXNlIHJlbW92ZSB0aGUgbGluZS1y ZXR1cm4gYWZ0ZXIgZWFjaCBuYW1lLiAgRS5nLiwgdGhlIGVudGlyZQ0KICAgc2VjdGlvbiBjb3Vs ZCBiZSBvbmUgcGFyYWdyYXBoLi4uDQoNCjExLiBJbiBTZWN0aW9uIDkuMSwgW2RyYWZ0LWlldGYt bmV0Y29uZi1rZXlzdG9yZS0wNC50eHRdIG5lZWRzIHRvIGJlDQogICAgW0ktRC5pZXRmLW5ldGNv bmYta2V5c3RvcmVdIGFuZCBbZHJhZnQtaWV0Zi1uZXRjb25mLXRscy1jbGllbnQtc2VydmVyLTA1 LnR4dF0NCiAgICBuZWVkcyB0byBiZSBbSS1ELmlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZl cl0uICAgQlRXLCBhbGwgdGhpcyBpcyBhdXRvbWF0aWMNCiAgICBpZiwgaW4geW91ciBYTUwsIHlv dSBwdXQgZS5nLiA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuSS1ELmlldGYtbmV0Y29uZi1rZXlz dG9yZSI/Pg0KDQoxMi4gSW4gQXBwZW5kaXggQS4xLCB0aGUgbW9kdWxlIG5hbWUgc2hvdWxkIGJl Z2luIHdpdGggImV4YW1wbGUtIiwgcGVyIHJmYzYwODdiaXMNCiAgIFNlY3Rpb24gMy4yLjEuDQoN CjEzLiBBbHNvIGluIEFwcGVuZGl4IEEuMSwgdGhlIG5hbWVzcGFjZSBzaG91bGQgZm9sbG93IG9u ZSBvZiB0aGUgY29udmVudGlvbnMNCiAgICBkZWZpbmVkIGluIHJmYzYwODdiaXMgU2VjdGlvbiA0 LjkgKGUuZy4sIGh0dHA6Ly9leGFtcGxlLmNvbS9ucy9zeXNsb2ctdHlwZXMpDQoNCg0KDQpSZXZp ZXdpbmcgbXkgY29tbWVudHMgZnJvbSAtMTcgKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvbmV0bW9kL2ZhaWw3Q3pjUkNzSUlZLUN4aFQzeFhqa0N2YykNCg0KMS4gbW9zdGx5 IGZpeGVkLCBleGNlcHQgdGhlIGRvd25yZWYgdG8gUkZDIDY1ODcgKHNlZSAjMSBhYm92ZSkNCjIu IEkgc2VlIHlvdSBtYWRlIGEgY2hhbmdlLCBidXQgaXQncyBzdGlsbCBub3QgcmlnaHQgKHNlZSAj NiBhYm92ZSkNCjMuIGZpeGVkDQo0LiBmaXhlZA0KNS4gZml4ZWQNCjYuIG5vdCBmaXhlZCAoc2Vl ICMxIGFib3ZlKQ0KNy4gbm90IGZpeGVkLCBidXQgdGhpcyBtYXkgYmUgb2theSAod2hhdCB0aGUg dHJlZSBkaWFncmFtcyBkcmFmdCBzYXk/KQ0KOC4gZml4ZWQNCjkuIG5vdCBmaXhlZCAoc2VlICMx IGFib3ZlKQ0KMTAuIGZpeGVkDQoxMS4gbm90IGZpeGVkICh0aGVyZSBNVVNUIGJlIG5vcm1hdGl2 ZSByZWZlcmVuY2VzIGluIFNlY3Rpb24gDQoxMi4gbm90IGZpeGVkIChzZWUgIzUgYWJvdmUpDQoN Cg0KUmV2aWV3aW5nIG15IGNvbW1lbnRzIGZyb20gLTE1IChodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL25ldG1vZC8xMGxvNDFVZDRBM1pOMTFzLTBnT2ZDZThOU0UpDQoNCjEu IG9rDQoyLiBiZXR0ZXINCjMuIGZpeGVkDQo0LiBiZXR0ZXINCjUuIG5vdCBmaXhlZCAoYnV0IEkg Y2FuIGxpdmUgd2l0aCBpdCkNCjYuIG5vdCBmaXhlZC4gZnJvbSA4MTc0LCB5b3Ugc2hvdWxkIGFk ZCB0aGUgcGFydCAid2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0 YWxzLCBhcyBzaG93biBoZXJlLiINCjcuIGZpeGVkDQo4LiBmaXhlZA0KOS4gZml4ZWQNCjEwLiBu b3QgZml4ZWQNCjExLiBiZXR0ZXINCjEyLiBiZXR0ZXINCjEzLiBmaXhlZA0KMTQuIGZpeGVkDQox NS4gZml4ZWQNCjE2LiBmaXhlZA0KMTcuIGZpbmUNCjE4LiBub3QgZml4ZWQNCjE5LiBmaXhlZA0K MjAuIGZpeGVkDQoyMS4gZml4ZWQNCjIyLiBmaW5lDQoNCg0KVGhhbmtzLA0KS2VudCAvLyBTaGVw aGVyZA0KDQoNCg0K From nobody Sat Jan 6 12:30:47 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 9B2A812AF84; Sat, 6 Jan 2018 12:30:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: draft-ietf-netmod-rfc8022bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151527064556.32311.7928092264244016989@ietfa.amsl.com> Date: Sat, 06 Jan 2018 12:30:45 -0800 Archived-At: Subject: [netmod] Opsdir telechat review of draft-ietf-netmod-rfc8022bis-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 20:30:45 -0000 Reviewer: Joe Clarke Review result: Ready I am completing this review as a representative of the ops directorate. This document describes an NMDA-compliant version of the ietf-routing family of YANG modules that obsoletes the revisions in RFC8022. Overall, I feel this document is ready, with some very minor spelling nits. The only substantive comment I have is in the comments ahead of the now-obsolete state branches. Currently, these comments just state "Obsolete State Data". I wonder if it would make sense to add a bit more text here to reference why these branches are now obsolete. Perhaps a reference to the NMDA document would be beneficial. Spelling-wise, search for Managment. There are four instances in the YANG modules themselves. Obviously, these should be "Management". Another minor nit I noticed (and this is likely an issue with pyang) is that when using a grouping, the YANG tree lists nodes like routing-state -> router-id with a '+' instead of a 'o' (i.e., indicating obsolete). Not a big deal since the parent container is obsolete. One comment I have is that the imports clauses here definitely point out a need to be able to import by some kind of version that will allow to set a minimum requirement (e.g., import by semantic version). Having comments such as are in the modules now are not machine-consumable, and will likely cause operational challenges for those that do not pay attention. From nobody Sat Jan 6 15:27: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 9FE04126E01; Sat, 6 Jan 2018 15:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 OnY8GJnoSk5g; Sat, 6 Jan 2018 15:27:27 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88636126C3D; Sat, 6 Jan 2018 15:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1515281247; x=1516490847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6UT6JAyGdkKytPWoWiZkqbVRMODVi8CbKLHaULfU+VU=; b=gKu+V9dmmH45WM4/SuFv5nIaqX5Rk64TdKy72rKfMKwq7+svH+OVxxlY sjvl5vZ78BY9UNvrFviaCEgIMDOAOgvLI1j1FuX2vNIw7arKMc5Oun6np zf2nO1RM8j+iNlGe3tCRNPolxSiVSq/7rh2Qe4HAvBECqEt/YDAYuEAgc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AgANW1Fa/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM/gVonB4QAmHyZLIIVCoU7AhqEGEAXAQEBAQEBAQEBayiFJAY?= =?us-ascii?q?jBA1FEAIBCBIIAiYCAgIwFQIOAgQBDQWKMa9DgW06ii8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR6BD4MRghWDP4MugzCBboMXgmUBBId3m2cCj2mFU5QJlmoCERkBgTs?= =?us-ascii?q?BIAE3gVBvFT2CKoRXeIhdgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.46,323,1511827200"; d="scan'208";a="338180664" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2018 23:27:26 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w06NRQWS023760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 6 Jan 2018 23:27:26 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 6 Jan 2018 18:27:25 -0500 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; Sat, 6 Jan 2018 18:27:25 -0500 From: "Acee Lindem (acee)" To: "Joe Clarke (jclarke)" , "ops-dir@ietf.org" CC: "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" Thread-Topic: Opsdir telechat review of draft-ietf-netmod-rfc8022bis-07 Thread-Index: AQHThy08rP1/r175G0SqJDaeknQSXKNnfV+A Date: Sat, 6 Jan 2018 23:27:24 +0000 Message-ID: References: <151527064556.32311.7928092264244016989@ietfa.amsl.com> In-Reply-To: <151527064556.32311.7928092264244016989@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <3232414B27CE34488A24416178D5B92D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Opsdir telechat review of draft-ietf-netmod-rfc8022bis-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 23:27:29 -0000 SGV5IEpvZSwgDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gU2VlIHJlcGxpZXMgaW5saW5lLg0K DQpPbiAxLzYvMTgsIDM6MzAgUE0sICJKb2UgQ2xhcmtlIChqY2xhcmtlKSIgPGpjbGFya2VAY2lz Y28uY29tPiB3cm90ZToNCg0KPlJldmlld2VyOiBKb2UgQ2xhcmtlDQo+UmV2aWV3IHJlc3VsdDog UmVhZHkNCj4NCj5JIGFtIGNvbXBsZXRpbmcgdGhpcyByZXZpZXcgYXMgYSByZXByZXNlbnRhdGl2 ZSBvZiB0aGUgb3BzIGRpcmVjdG9yYXRlLg0KPlRoaXMNCj5kb2N1bWVudCBkZXNjcmliZXMgYW4g Tk1EQS1jb21wbGlhbnQgdmVyc2lvbiBvZiB0aGUgaWV0Zi1yb3V0aW5nIGZhbWlseQ0KPm9mIFlB TkcNCj5tb2R1bGVzIHRoYXQgb2Jzb2xldGVzIHRoZSByZXZpc2lvbnMgaW4gUkZDODAyMi4gIE92 ZXJhbGwsIEkgZmVlbCB0aGlzDQo+ZG9jdW1lbnQNCj5pcyByZWFkeSwgd2l0aCBzb21lIHZlcnkg bWlub3Igc3BlbGxpbmcgbml0cy4NCj4NCj5UaGUgb25seSBzdWJzdGFudGl2ZSBjb21tZW50IEkg aGF2ZSBpcyBpbiB0aGUgY29tbWVudHMgYWhlYWQgb2YgdGhlDQo+bm93LW9ic29sZXRlIHN0YXRl IGJyYW5jaGVzLiAgQ3VycmVudGx5LCB0aGVzZSBjb21tZW50cyBqdXN0IHN0YXRlDQo+Ik9ic29s ZXRlDQo+U3RhdGUgRGF0YSIuICBJIHdvbmRlciBpZiBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGFk ZCBhIGJpdCBtb3JlIHRleHQgaGVyZQ0KPnRvDQo+cmVmZXJlbmNlIHdoeSB0aGVzZSBicmFuY2hl cyBhcmUgbm93IG9ic29sZXRlLiAgUGVyaGFwcyBhIHJlZmVyZW5jZSB0bw0KPnRoZSBOTURBDQo+ ZG9jdW1lbnQgd291bGQgYmUgYmVuZWZpY2lhbC4NCg0KSG93IGFib3V0IHNvbWV0aGluZyBsaWtl Og0KDQogIFRoZSBzdWJzZXF1ZW50IGRhdGEgbm9kZXMgYXJlIG9idmlhdGVkIGFuZCBvYnNvbGV0 ZWQgYnkgdGhlIOKAnE5ldHdvcmsNCiAgTWFuYWdlbWVudCBBcmNoaXRlY3R1cmXigJ0gYXMgZGVz Y3JpYmVkIGluDQpkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMu4oCdDQoNCj4N Cj5TcGVsbGluZy13aXNlLCBzZWFyY2ggZm9yIE1hbmFnbWVudC4gIFRoZXJlIGFyZSBmb3VyIGlu c3RhbmNlcyBpbiB0aGUgWUFORw0KPm1vZHVsZXMgdGhlbXNlbHZlcy4gIE9idmlvdXNseSwgdGhl c2Ugc2hvdWxkIGJlICJNYW5hZ2VtZW50Ii4NCg0KU2lnaCAtIHRoYW5rcywgSeKAmXZlIGZpeGVk Lg0KPg0KPkFub3RoZXIgbWlub3Igbml0IEkgbm90aWNlZCAoYW5kIHRoaXMgaXMgbGlrZWx5IGFu IGlzc3VlIHdpdGggcHlhbmcpIGlzDQo+dGhhdA0KPndoZW4gdXNpbmcgYSBncm91cGluZywgdGhl IFlBTkcgdHJlZSBsaXN0cyBub2RlcyBsaWtlIHJvdXRpbmctc3RhdGUgLT4NCj5yb3V0ZXItaWQg d2l0aCBhICcrJyBpbnN0ZWFkIG9mIGEgJ28nIChpLmUuLCBpbmRpY2F0aW5nIG9ic29sZXRlKS4g IE5vdCBhDQo+YmlnDQo+ZGVhbCBzaW5jZSB0aGUgcGFyZW50IGNvbnRhaW5lciBpcyBvYnNvbGV0 ZS4NCg0KR29vZCBjYXRjaC4gRHVlIHRvIHNvbWUgc3Vic2V0dGluZyBhbmQgZm9ybWF0dGluZywg dGhlc2Ugd2VyZSBub3QNCnJlZ2VuZXJhdGVkLiBJDQp3aWxsIGZpeC4gDQo+DQo+T25lIGNvbW1l bnQgSSBoYXZlIGlzIHRoYXQgdGhlIGltcG9ydHMgY2xhdXNlcyBoZXJlIGRlZmluaXRlbHkgcG9p bnQgb3V0DQo+YSBuZWVkDQo+dG8gYmUgYWJsZSB0byBpbXBvcnQgYnkgc29tZSBraW5kIG9mIHZl cnNpb24gdGhhdCB3aWxsIGFsbG93IHRvIHNldCBhDQo+bWluaW11bQ0KPnJlcXVpcmVtZW50IChl LmcuLCBpbXBvcnQgYnkgc2VtYW50aWMgdmVyc2lvbikuICBIYXZpbmcgY29tbWVudHMgc3VjaCBh cw0KPmFyZSBpbg0KPnRoZSBtb2R1bGVzIG5vdyBhcmUgbm90IG1hY2hpbmUtY29uc3VtYWJsZSwg YW5kIHdpbGwgbGlrZWx5IGNhdXNlDQo+b3BlcmF0aW9uYWwNCj5jaGFsbGVuZ2VzIGZvciB0aG9z ZSB0aGF0IGRvIG5vdCBwYXkgYXR0ZW50aW9uLg0KDQpXZSBkaXNjdXNzZWQgdGhpcyBvbiB0aGUg TkVUTU9EIGxpc3QgYW5kIGl0IGlzIGFsc28gdW5kZXNpcmFibGUgdG8gaGFyZA0KY29kZSBhIA0K dmVyc2lvbi4gSXQgd291bGQgYmUgZ29vZCB0byBoYXZlIOKAnGdyZWF0ZXIgdGhhbiBvciBlcXVh bCB0b+KAnSBzZW1hbnRpY3MuDQoNCg0KVGhhbmtzLA0KQWNlZSANCg0KPg0KDQo= From nobody Sun Jan 7 07:03: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 B47AA12422F; Sun, 7 Jan 2018 07:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8FG3Xs-XD5HS; Sun, 7 Jan 2018 07:03:32 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11CEA126579; Sun, 7 Jan 2018 07:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1962; q=dns/txt; s=iport; t=1515337412; x=1516547012; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jI6QtjQFnysCxu+t9scQaRJBUYfPuCvPg/o4DFF21Js=; b=b3ViSjZJwB8EuDgEzb5pxrIsLELRUhcSB4JebhIkmbxEOTH1CHFrZWvZ SQjlYlMH3q8tDCYvl1DxmsKf4VBhf2X9QgMgB1OtngTzqyGNwxRnxE0w4 XTXwjash2sw72gXtWw7l2E6ICaJtxILjrzgGVpfxkv/z/2fFf2sFITYip M=; X-IronPort-AV: E=Sophos;i="5.46,326,1511827200"; d="scan'208";a="52803039" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2018 15:03:31 +0000 Received: from [10.118.87.84] (rtp-jclarke-nitro3.cisco.com [10.118.87.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w07F3Uqj024843; Sun, 7 Jan 2018 15:03:31 GMT To: "Acee Lindem (acee)" , "ops-dir@ietf.org" Cc: "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" References: <151527064556.32311.7928092264244016989@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Message-ID: <5d2859cb-e43a-3eda-5b20-172177a6fe6c@cisco.com> Date: Sun, 7 Jan 2018 10:03:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Opsdir telechat review of draft-ietf-netmod-rfc8022bis-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 15:03:34 -0000 On 1/6/18 18:27, Acee Lindem (acee) wrote: >>The only substantive comment I have is in the comments ahead of the >>now-obsolete state branches.  Currently, these comments just state >>"Obsolete >>State Data".  I wonder if it would make sense to add a bit more text here >>to >>reference why these branches are now obsolete.  Perhaps a reference to >>the NMDA >>document would be beneficial. > > How about something like: > >   The subsequent data nodes are obviated and obsoleted by the “Network >   Management Architecture” as described in > draft-ietf-netmod-revised-datastores.” Works for me. >>Another minor nit I noticed (and this is likely an issue with pyang) is >>that >>when using a grouping, the YANG tree lists nodes like routing-state -> >>router-id with a '+' instead of a 'o' (i.e., indicating obsolete).  Not a >>big >>deal since the parent container is obsolete. > > Good catch. Due to some subsetting and formatting, these were not > regenerated. I > will fix. Cool. I wasn't in a place to validate with pyang yesterday. I had assumed an issue there, but if it just takes a regen to fix, that would be great and clearer. >> >>One comment I have is that the imports clauses here definitely point out >>a need >>to be able to import by some kind of version that will allow to set a >>minimum >>requirement (e.g., import by semantic version).  Having comments such as >>are in >>the modules now are not machine-consumable, and will likely cause >>operational >>challenges for those that do not pay attention. > > We discussed this on the NETMOD list and it is also undesirable to hard > code a > version. It would be good to have “greater than or equal to” semantics. Yes, I have seen and been part of the semver discussion. This was more to get keep beating the drum as this will pose an operational issue for those not as familiar with NMDA. Thanks, Acee. Joe From nobody Sun Jan 7 14:26:28 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 08E0D124239; Sun, 7 Jan 2018 14:26:23 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151536398298.11305.11587070488437904384@ietfa.amsl.com> Date: Sun, 07 Jan 2018 14:26:23 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 22:26: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 : A YANG Data Model for Routing Management (NDMA Version) Authors : Ladislav Lhotka Acee Lindem Yingzhen Qu Filename : draft-ietf-netmod-rfc8022bis-08.txt Pages : 77 Date : 2018-01-07 Abstract: This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-08 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 Sun Jan 7 14:29:37 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 D8A1F124B17 for ; Sun, 7 Jan 2018 14:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.51 X-Spam-Level: X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZyD6_tGTiEvu for ; Sun, 7 Jan 2018 14:29:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD136124239 for ; Sun, 7 Jan 2018 14:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3108; q=dns/txt; s=iport; t=1515364173; x=1516573773; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7Z9f5my1Ni1ZaQ+1rDS/ILp++k2z2y3O3h69BTtfUCA=; b=Slo95Umn/ffC2XXz0Fq04cRps4lnCt2W2o8HS7fvci4Fh9Xe8yPGm+P+ X5PNNC29LxLw0tRxNC32DjbsgKG/leWSEblF7kee2mqM8Y8PTChTaxWJz RgK52W4CJfLiW+GYlDAqiE+DMhytjAD9q1Ou1EK5WGshGHRv/HXOR3bwS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQBynlJa/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM/ZnQYDweEAIokjliBSpdighUKGAuESU8CGgyEDD8YAQEBAQE?= =?us-ascii?q?BAQEBayiFGwkCAQMBASEROgsQAgEIEggCJgICAiULFQIOAhIFhXOEPhCxYoIni?= =?us-ascii?q?jABAQEBAQEBAwEBAQEBAQEBIIEPgxGCFYM/gy6DLwEBF4FWgxcUglEFo14CiAW?= =?us-ascii?q?NN4IXZYU0i1mNM4k3AhEZAYE7AR85gVBvFRkkgQQIgR4JhE54iQ2BFwEBBQ?= X-IronPort-AV: E=Sophos;i="5.46,327,1511827200"; d="scan'208";a="334057272" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2018 22:29:32 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w07MTWdm007143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 7 Jan 2018 22:29:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 7 Jan 2018 17:29:31 -0500 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, 7 Jan 2018 17:29:31 -0500 From: "Acee Lindem (acee)" CC: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-08.txt Thread-Index: AQHTiAahlvCUNA5cKU67in1lJiHpNKNo/eAA Date: Sun, 7 Jan 2018 22:29:31 +0000 Message-ID: References: <151536398298.11305.11587070488437904384@ietfa.amsl.com> In-Reply-To: <151536398298.11305.11587070488437904384@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <2D1940FDC684A347ACDD192FC7F7068E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 22:29:36 -0000 VGhpcyB2ZXJzaW9uIGluY29ycG9yYXRlcyBKb2UgQ2xhcmtl4oCZcyBPUFMgZGlyZWN0b3JhdGUg Y29tbWVudHMuDQpUaGFua3MsDQpBY2VlDQoNCk9uIDEvNy8xOCwgNToyNiBQTSwgIm5ldG1vZCBv biBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPG5ldG1vZC1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+ DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgTmV0d29yayBNb2RlbGluZyBXRyBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxl ICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIE1hbmFnZW1lbnQgKE5E TUENCj5WZXJzaW9uKQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTGFkaXNsYXYgTGhvdGth DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBY2VlIExpbmRlbQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgWWluZ3poZW4gUXUNCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1u ZXRtb2QtcmZjODAyMmJpcy0wOC50eHQNCj4JUGFnZXMgICAgICAgICAgIDogNzcNCj4JRGF0ZSAg ICAgICAgICAgIDogMjAxOC0wMS0wNw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQg Y29udGFpbnMgYSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcyBhbmQgb25lDQo+ ICAgc3VibW9kdWxlLiAgVG9nZXRoZXIgdGhleSBmb3JtIHRoZSBjb3JlIHJvdXRpbmcgZGF0YSBt b2RlbCB0aGF0DQo+ICAgc2VydmVzIGFzIGEgZnJhbWV3b3JrIGZvciBjb25maWd1cmluZyBhbmQg bWFuYWdpbmcgYSByb3V0aW5nDQo+ICAgc3Vic3lzdGVtLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB0 aGVzZSBtb2R1bGVzIHdpbGwgYmUgYXVnbWVudGVkIGJ5DQo+ICAgYWRkaXRpb25hbCBZQU5HIG1v ZHVsZXMgZGVmaW5pbmcgZGF0YSBtb2RlbHMgZm9yIGNvbnRyb2wtcGxhbmUNCj4gICBwcm90b2Nv bHMsIHJvdXRlIGZpbHRlcnMsIGFuZCBvdGhlciBmdW5jdGlvbnMuICBUaGUgY29yZSByb3V0aW5n IGRhdGENCj4gICBtb2RlbCBwcm92aWRlcyBjb21tb24gYnVpbGRpbmcgYmxvY2tzIGZvciBzdWNo IGV4dGVuc2lvbnMgLS0gcm91dGVzLA0KPiAgIFJvdXRpbmcgSW5mb3JtYXRpb24gQmFzZXMgKFJJ QnMpLCBhbmQgY29udHJvbC1wbGFuZSBwcm90b2NvbHMuDQo+DQo+ICAgVGhlIFlBTkcgbW9kdWxl cyBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm0gdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudA0KPiAg IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMg UkZDIDgwMjIuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1uZXRtb2QtcmZjODAyMmJpcy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0bW9kLXJmYzgwMjJiaXMtMDgNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDgNCj4NCj5BIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDgNCj4NCj4NCj5QbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Mon Jan 8 02:53:57 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 95B78127342 for ; Mon, 8 Jan 2018 02:53:56 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 4ireS8H2yOxF for ; Mon, 8 Jan 2018 02:53:54 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 7F8C11273E2 for ; Mon, 8 Jan 2018 02:53:54 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eYV3x-0005P4-0D for ietf-supjps-netmod@ietf.org; Mon, 08 Jan 2018 10:53:53 +0000 From: "Jon Shallow" To: Date: Mon, 8 Jan 2018 10:53:53 -0000 Message-ID: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0124_01D3886E.F96F7E10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOIbvlU0QBjg+SHRESC+Oh6XUPoRw== Content-Language: en-gb Archived-At: Subject: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 10:53:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0124_01D3886E.F96F7E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi There, I appreciate that this is late to the table, but is it possible to set up "access-lists" as a "grouping" in the YANG data model so that "access-lists" can be included by "uses" in a higher level YANG data model? I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues Regards Jon ------=_NextPart_000_0124_01D3886E.F96F7E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = There,

 

I appreciate that this is late to the table, but is it = possible to set up “access-lists” as a = “grouping” in the YANG data model so that = “access-lists” can be included by “uses” in a = higher level YANG data model?

 

I have = raised this as issue #22 at https://github.com= /netmod-wg/acl-model/issues

 

Regards

 

Jon

------=_NextPart_000_0124_01D3886E.F96F7E10-- From nobody Mon Jan 8 05:05:11 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 269251242F5; Mon, 8 Jan 2018 05:05:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151541670915.11305.11069854448917067732.idtracker@ietfa.amsl.com> Date: Mon, 08 Jan 2018 05:05:09 -0800 Archived-At: Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 13:05:09 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- protocol interactions with other systems and that is neither conventional nor dynamic configuration. Could you provide an example of this? datastore that holds the complete current configuration on the device. It MAY include configuration that requires further transformation before it can be applied, e.g., inactive If I am reading the text, this doesn't seem to be true because "system configuration" is not included. From nobody Mon Jan 8 05:55: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 DC3D1126C25 for ; Mon, 8 Jan 2018 05:55:29 -0800 (PST) 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_RP_MATCHES_RCVD=-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 WNbOAkxQXoZU for ; Mon, 8 Jan 2018 05:55:27 -0800 (PST) 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 35F9A126C23 for ; Mon, 8 Jan 2018 05:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29437; q=dns/txt; s=iport; t=1515419726; x=1516629326; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=osF2WQI3OdS9QAYdgSPcVsp6n15zh+L7g78meQmDuWo=; b=BhnqQ+BBtL7r7oFm4nut20N+DKBiK6rhfKxM8niKA5jb2dILt1jO28/C 9/PRLcwW7Ag6khEFbcWMDGdqe18nz5kNVAp6wBdBbvdIAu611qSZGvRlK IYuL7KZSeHdd6jss67sSKZJI0l6iqZOX0ky4Rr9nGSboUHAqtQI7uSBya k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAQAidVNa/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSoFbdCeEB4sYjz8nlz6CAQoYAQqDOoEPTwKEdRQBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQIBAQEhSxkCCQIQCCAHAwICGwwfEQYBDAYCAQEXig4IEJM+n?= =?us-ascii?q?W6CJyaKCQEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FhBt9gm6BaSkMgWuBDoMvAYF?= =?us-ascii?q?HDwI3JoJQgmUFmViKBpU+jB+BYIYKjxCIB4E8NiIlgSsyGggbFT2CKgmCEjkcg?= =?us-ascii?q?WdBN4gdAiUHgh0BAQE?= X-IronPort-AV: E=Sophos;i="5.46,330,1511827200"; d="scan'208,217";a="1280889" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 13:55:23 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w08DtNL7022957; Mon, 8 Jan 2018 13:55:23 GMT To: Andy Bierman , NETMOD Working Group References: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com> <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com> <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.com> <20171221132030.7zebh2xkhddmql3c@elstar.local> <20171221222742.izrmwpbiwgoc7col@elstar.local> From: Robert Wilton Message-ID: Date: Mon, 8 Jan 2018 13:55:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F91B683334AB18728E793FBA" Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 13:55:30 -0000 This is a multi-part message in MIME format. --------------F91B683334AB18728E793FBA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, Regarding your comment below, this intent is captured by this text describing the operational datastore in section 5.3: 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 due to remnant configuration (see Section 5.3.1). Note, that deviations SHOULD be used when it is known in advance that a device does not fully conform to the schema. Only semantic constraints MAY be violated, these are the YANG "when", "must", "mandatory", "unique", "min-elements", and "max-elements" statements; and the uniqueness of key values. Syntactic constraints MUST NOT be violated, including hierarchical organization, identifiers, and type-based constraints. If a node in does not meet the syntactic constraints then it MUST NOT be returned, and some other mechanism should be used to flag the error. Do you agree that this is sufficient? Thanks, Rob On 21/12/2017 22:49, Andy Bierman wrote: > Hi, > > It should be clear somehow that server requirements to provide > config=false data > that is valid according to the YANG definitions is not affected by NMDA. > That is not being taken away.  The ability to validate operational values > of configuration data has never been provided, and therefore is not > being taken away either. > > A constraint on config=true nodes only applies to configuration > datastores. > These are the only constraints that should be ignored in . > Constraints on config=false nodes still apply in . > > > Andy > > > > On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder > > wrote: > > On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote: > > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: > > > > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote: > > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: > > > > > > > > > Hi Vladimir, > > > > > > > > > > First point of clarification is that this is not about > running/intended > > > > > at all.  The contents of running/intended do not change in > anyway > > > > > depending on whether hardware is present or absent. > > > > > > > > > > The section is only concerned with how the configuration > is applied in > > > > > operational, and basically says that you cannot apply > configuration for > > > > > resources that are missing (which seems reasonable).  E.g. > I cannot > > > > > configure an IP address on a physical interface that isn't > there.  Or if > > > > > the physical interface gets removed then the configuration > associated > > > > > with that interface is also removed from operational. > > > > > > > > > > Operational isn't validated and data model constraints are > allowed to be > > > > > broken (ideally transiently). > > > > I want to focus on this. IMO giving up schema validitiy for > any datastore is > > > > unacceptable price. Pre-NMDA devices had full model support > in operational > > > > data (all YANG constrains part of the model without > discrimination were > > > > enforced). > > > There was a long debate about the value of returning the true > > > operational state. What do you do if the operational state is > invalid? > > > A server can reject configuration changes if they lead to invalid > > > state, a server can not reject reality. > > IMO if the model can represent reality then data conforming to > the model > > can. If not a better model is needed not a hack that breaks the > datastore > > conformance to the YANG model. I do not see how > > /interfaces/interface/oper-status=not-present was not > representing the > > reality of a system with removed line card that is configured > and ready to > > resume operation as soon as the line card is reconnected. > > I assume this is all system and implementation specific. If your > system knows about interfaces that are not present (i.e., there is > operational state about them), you can report these interfaces.  But > 'is configured' is confusing here. I am not sure a line card that does > not exist should be considered configured. But yes, this may be system > specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has > oper-status 'not-present' - so this seems to be a mood point. > > > > > If this is about to change it will compromise interoperability > > > > and a significant portion of the client implementation > workload that can be > > > > automated will need to be coded in hand and tested. > Unresolved leafrefs, > > > > undefined behaviour of different implementations removing > different > > > > configuration nodes in violation of YANG semantic > constraints (which I do > > > > not think can be so clearly separated from the syntactic > constraints when > > > > one considers types like leafref, instance-identifier etc.) > and the > > > > corresponding side effects based on the server > implementators own creativity > > > > is eventually going to create more problems. > > > > > > > > 1. IMO the only acceptable solution is to have YANG valid > operational > > > > datastore at all times. operational like any other datastore > MUST be valid > > > > YANG data tree and it has to be a system implementation task > to consider all > > > > complications resulting from the removal of the resources > leading to any > > > > data transformations. If this is difficult or impossible > other mechanisms to > > > > flag missing resources should be used (e.g. > > > > /interfaces/interface/oper-status=not-present) This sounds > like a useful > > > > contract providing the value of a standard the alternative > does not. > > > As said above, it is impossible to report valid operational > state if > > > the operational state is not valid according to the models. > > > > > > > 2. Even with the change in 1. I do not see the removal of > intended > > > > configuration nodes from operational as a solution worth > implementing on our > > > > servers. I do not see a real world plug-and-play scenario > that can be > > > > automatically solved without specific additions to the > models e.g. > > > > /interfaces/interface/oper-status=not-present is > oversimplified solution but > > > > it needs to be extended exactly as much as the solution > provided by the > > > > removal of config true; nodes without the sacrifice of YANG > validity of > > > > operational. > > > Your thinking is likely wrong. reports the > operational > > > state. It may have little in common with . Trying to > derive > > > operational from intended is likely a not well working approach. > > The proposal for this solution ("derive operational from > intended" e.g. > > merge /interfaces-state in /interfaces) comes from the revised > datastores > > draft not me. > > > > By definition config true; data represents intent. Reusing the > model of a > > config true; data to represent state absent of intent (e.g. > > /interfaces/interface with origin="or:system") is a hack. The > hack works > > fine without compromising the conformance of operational to the > YANG model > > as long as certain conditions are met. I am pointing out that > one of the > > conditions is to keep all of the intended configuration data > present in > > 'operational' and handle missing resources with conventional > means e.g. > > /interfaces/interface/oper-status=not-present instead of adding > the straw > > that breaks the camel's back. > > I fail to see why you believe all objects that appear in intended > configuration needs to exist in applied configuration. In fact, > operators told us very clearly that they care about the distinction > between intended and applied config. > > > > > 3. Solutions like /interfaces/interface/admin-state stop > working. With the > > > > interface removed you can no longer figure if the if-mib has > or does not > > > > have the interface enabled so an operator has to use SNMP or > wait for a > > > > replacement line card to be connected to figure this bit of > information. > > > At least on my boxes, if I remove a line card, the interface also > > > disappears in SNMP tables. Stuff that is operationally not > present is > > > simply operationally not present. > > > > > > > My > > > > interpretation of the MAY as requirement level in sec. 5.3. > The Operational > > > > State Datastore () is that plug-and-play > solutions can be > > > > implemented without this limited approach that has the same > problem as the > > > > pre-NMDA only now we have to have /interfaces-state to keep > config false; > > > > data relevant to hardware that is configured but not present: > > > > > > > >     configuration data nodes supported in a configuration > datastore > > > >     MAY be omitted from if a server is not able to > > > >     accurately report them. > > > > > > > > I realize this discussion comes late. I have stated my > objections to this > > > > particular part of the NMDA draft earlier. > > > I believe there is a conceptual misunderstanding. I think > there never > > > was a requirement that a server reports the state of hardware > that is > > > not present. > > "Data relevant to hardware that is configured but not present" > is different > > from "state of hardware that is not present". For example > information > > indicating when the line card became unavailable, what was the > reason, or > > other information like how many packets that had this interface > as egress > > destination are being dropped as a result of the removal. > > I think that systems handle non-existing interfaces differently. It > seems that ietf-interfaces is flexible enough to accomodate the > differnet styles. > > /js > > -- > 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 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------F91B683334AB18728E793FBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

Regarding your comment below, this intent is captured by this text describing the operational datastore in section 5.3:

   <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 due to remnant configuration (see
   Section 5.3.1).  Note, that deviations SHOULD be used when it is
   known in advance that a device does not fully conform to the
   <operational> schema.

   Only semantic constraints MAY be violated, these are the YANG "when",
   "must", "mandatory", "unique", "min-elements", and "max-elements"
   statements; and the uniqueness of key values.

   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
   <operational> does not meet the syntactic constraints then it MUST
   NOT be returned, and some other mechanism should be used to flag the
   error.

Do you agree that this is sufficient?

Thanks,
Rob


On 21/12/2017 22:49, Andy Bierman wrote:
Hi,

It should be clear somehow that server requirements to provide config=false data
that is valid according to the YANG definitions is not affected by NMDA.
That is not being taken away.  The ability to validate operational values
of configuration data has never been provided, and therefore is not being taken away either.

A constraint on config=true nodes only applies to configuration datastores.
These are the only constraints that should be ignored in <operational>.
Constraints on config=false nodes still apply in <operational>.


Andy



On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
> On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>
> > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
> > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > First point of clarification is that this is not about running/intended
> > > > at all.  The contents of running/intended do not change in anyway
> > > > depending on whether hardware is present or absent.
> > > >
> > > > The section is only concerned with how the configuration is applied in
> > > > operational, and basically says that you cannot apply configuration for
> > > > resources that are missing (which seems reasonable).  E.g. I cannot
> > > > configure an IP address on a physical interface that isn't there.  Or if
> > > > the physical interface gets removed then the configuration associated
> > > > with that interface is also removed from operational.
> > > >
> > > > Operational isn't validated and data model constraints are allowed to be
> > > > broken (ideally transiently).
> > > I want to focus on this. IMO giving up schema validitiy for any datastore is
> > > unacceptable price. Pre-NMDA devices had full model support in operational
> > > data (all YANG constrains part of the model without discrimination were
> > > enforced).
> > There was a long debate about the value of returning the true
> > operational state. What do you do if the operational state is invalid?
> > A server can reject configuration changes if they lead to invalid
> > state, a server can not reject reality.
> IMO if the model can represent reality then data conforming to the model
> can. If not a better model is needed not a hack that breaks the datastore
> conformance to the YANG model. I do not see how
> /interfaces/interface/oper-status=not-present was not representing the
> reality of a system with removed line card that is configured and ready to
> resume operation as soon as the line card is reconnected.

I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e., there is
operational state about them), you can report these interfaces.  But
'is configured' is confusing here. I am not sure a line card that does
not exist should be considered configured. But yes, this may be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.

> > > If this is about to change it will compromise interoperability
> > > and a significant portion of the client implementation workload that can be
> > > automated will need to be coded in hand and tested. Unresolved leafrefs,
> > > undefined behaviour of different implementations removing different
> > > configuration nodes in violation of YANG semantic constraints (which I do
> > > not think can be so clearly separated from the syntactic constraints when
> > > one considers types like leafref, instance-identifier etc.) and the
> > > corresponding side effects based on the server implementators own creativity
> > > is eventually going to create more problems.
> > >
> > > 1. IMO the only acceptable solution is to have YANG valid operational
> > > datastore at all times. operational like any other datastore MUST be valid
> > > YANG data tree and it has to be a system implementation task to consider all
> > > complications resulting from the removal of the resources leading to any
> > > data transformations. If this is difficult or impossible other mechanisms to
> > > flag missing resources should be used (e.g.
> > > /interfaces/interface/oper-status=not-present) This sounds like a useful
> > > contract providing the value of a standard the alternative does not.
> > As said above, it is impossible to report valid operational state if
> > the operational state is not valid according to the models.
> >
> > > 2. Even with the change in 1. I do not see the removal of intended
> > > configuration nodes from operational as a solution worth implementing on our
> > > servers. I do not see a real world plug-and-play scenario that can be
> > > automatically solved without specific additions to the models e.g.
> > > /interfaces/interface/oper-status=not-present is oversimplified solution but
> > > it needs to be extended exactly as much as the solution provided by the
> > > removal of config true; nodes without the sacrifice of YANG validity of
> > > operational.
> > Your thinking is likely wrong. <operational> reports the operational
> > state. It may have little in common with <intended>. Trying to derive
> > operational from intended is likely a not well working approach.
> The proposal for this solution ("derive operational from intended" e.g.
> merge /interfaces-state in /interfaces) comes from the revised datastores
> draft not me.
>
> By definition config true; data represents intent. Reusing the model of a
> config true; data to represent state absent of intent (e.g.
> /interfaces/interface with origin="or:system") is a hack. The hack works
> fine without compromising the conformance of operational to the YANG model
> as long as certain conditions are met. I am pointing out that one of the
> conditions is to keep all of the intended configuration data present in
> 'operational' and handle missing resources with conventional means e.g.
> /interfaces/interface/oper-status=not-present instead of adding the straw
> that breaks the camel's back.

I fail to see why you believe all objects that appear in intended
configuration needs to exist in applied configuration. In fact,
operators told us very clearly that they care about the distinction
between intended and applied config.

> > > 3. Solutions like /interfaces/interface/admin-state stop working. With the
> > > interface removed you can no longer figure if the if-mib has or does not
> > > have the interface enabled so an operator has to use SNMP or wait for a
> > > replacement line card to be connected to figure this bit of information.
> > At least on my boxes, if I remove a line card, the interface also
> > disappears in SNMP tables. Stuff that is operationally not present is
> > simply operationally not present.
> >
> > > My
> > > interpretation of the MAY as requirement level in sec. 5.3. The Operational
> > > State Datastore (<operational>) is that plug-and-play solutions can be
> > > implemented without this limited approach that has the same problem as the
> > > pre-NMDA only now we have to have /interfaces-state to keep config false;
> > > data relevant to hardware that is configured but not present:
> > >
> > >     configuration data nodes supported in a configuration datastore
> > >     MAY be omitted from <operational> if a server is not able to
> > >     accurately report them.
> > >
> > > I realize this discussion comes late. I have stated my objections to this
> > > particular part of the NMDA draft earlier.
> > I believe there is a conceptual misunderstanding. I think there never
> > was a requirement that a server reports the state of hardware that is
> > not present.
> "Data relevant to hardware that is configured but not present" is different
> from "state of hardware that is not present". For example information
> indicating when the line card became unavailable, what was the reason, or
> other information like how many packets that had this interface as egress
> destination are being dropped as a result of the removal.

I think that systems handle non-existing interfaces differently. It
seems that ietf-interfaces is flexible enough to accomodate the
differnet styles.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
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

--------------F91B683334AB18728E793FBA-- From nobody Mon Jan 8 07:03: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 581EE129C53 for ; Mon, 8 Jan 2018 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Q86GStKgzXo0 for ; Mon, 8 Jan 2018 07:02:59 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF1712706D for ; Mon, 8 Jan 2018 07:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15520; q=dns/txt; s=iport; t=1515423779; x=1516633379; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bu5PFg2e5e+9Khu/yvlE+2YljIvCrFdxOmWKmjkJGtE=; b=UFD/0bWrt9mcjsrtvWkg6GsgbmkW8l7+wvHBM9EVM3z+3b6FAy4T1Pbg ltem7s5VwsM36vdBqL3YlRK0rHJ7VzTGxoEo91y4D8zdgVOx7UOGOfXRz kmNbQ8eIPYwDd0GODbfrnAC8yQHeiprqleU0LdbNR0eKO1Fhr/9cZJGB3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAQDGh1Na/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdWZ0JweEAIokjliTW4VRghUKGAEKhANGTwIahBw/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSQCAQMBASFLCxACAQgOMQMCAgIlCxQRAQEEAQ0FiU1kELELgieKL?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhCCCFYNogwWDLwGBbYMYMYI0BaNeAog?= =?us-ascii?q?FjTeUCY0zhh+DGAIRGQGBOwEfOYFQbxU9KgGBfz+EGHiJUYEXAQEB?= X-IronPort-AV: E=Sophos; i="5.46,330,1511827200"; d="scan'208,217"; a="53165277" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 15:02:55 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w08F2sRk017189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jan 2018 15:02:55 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 8 Jan 2018 10:02:53 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Mon, 8 Jan 2018 10:02:53 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Jon Shallow , Mahesh Jethanandani CC: "netmod@ietf.org" Thread-Topic: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" Thread-Index: AdOIbvlU0QBjg+SHRESC+Oh6XUPoRwATLimA Date: Mon, 8 Jan 2018 15:02:53 +0000 Message-ID: References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> In-Reply-To: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.106.4] Content-Type: multipart/alternative; boundary="_000_B0576B62CB6145EA99EFE5B67545B85Cciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:03:01 -0000 --_000_B0576B62CB6145EA99EFE5B67545B85Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhpcyBpcyBhIDctbGluZSBjaGFuZ2UsIEkgc2VlIG5vIGhhcm0gaW4gaXQgaWYgbm8t b25lIG9iamVjdHM/IE1haGVzaCBoYXMgdGhlIHRva2VuIGZvciByb2xsaW5nIGluIHVwZGF0ZXMg ZGlzY3Vzc2VkIGp1c3QgcHJpb3IgdG8gdGhlIGVuZCBvZiAyMDE3Lg0KDQpIZXJl4oCZcyBhIHBv c3NpYmxlIGRpZmY6DQoNCiQgZ2l0IGRpZmYgLWINCmRpZmYgLS1naXQgYS9zcmMveWFuZy9pZXRm LWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZyBiL3NyYy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wt bGlzdC55YW5nDQppbmRleCA0ZDY5OGM5Li5iMWExNzNmIDEwMDY0NA0KLS0tIGEvc3JjL3lhbmcv aWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCisrKyBiL3NyYy95YW5nL2lldGYtYWNjZXNz LWNvbnRyb2wtbGlzdC55YW5nDQpAQCAtNDAyLDYgKzQwMiwxMCBAQCBtb2R1bGUgaWV0Zi1hY2Nl c3MtY29udHJvbC1saXN0IHsNCiAgIC8qDQogICAgKiBDb25maWd1cmF0aW9uIGRhdGEgbm9kZXMN CiAgICAqLw0KKyAgZ3JvdXBpbmcgYWNjZXNzLWxpc3RzLXRvcCB7DQorICAgIGRlc2NyaXB0aW9u DQorICAgICAgIkdyb3VwaW5nIHRvIGFsbG93IHJldXNlIG9mIGFjY2VzcyBsaXN0cyBjb250YWlu ZXIgZWxzZXdoZXJlLiI7DQorDQogICAgIGNvbnRhaW5lciBhY2Nlc3MtbGlzdHMgew0KICAgICAg IGRlc2NyaXB0aW9uDQogICAgICAgICAiVGhpcyBpcyBhIHRvcCBsZXZlbCBjb250YWluZXIgZm9y IEFjY2VzcyBDb250cm9sIExpc3RzLg0KQEAgLTU3Niw2ICs1ODAsOSBAQCBtb2R1bGUgaWV0Zi1h Y2Nlc3MtY29udHJvbC1saXN0IHsNCiAgICAgICAgIH0NCiAgICAgICB9DQogICAgIH0NCisgIH0N CisgIHVzZXMgYWNjZXNzLWxpc3RzLXRvcDsNCisNCiAgIGF1Z21lbnQgIi9pZjppbnRlcmZhY2Vz L2lmOmludGVyZmFjZSIgew0KICAgICBkZXNjcmlwdGlvbg0KICAgICAgICJBdWdtZW50IGludGVy ZmFjZXMgdG8gYWxsb3cgQUNMcyB0byBiZSBhc3NvY2lhdGVkIGluIGVpdGhlciB0aGUNCg0KQ2hl ZXJzLA0KDQpFaW5hcg0KDQoNCk9uIDggSmFuIDIwMTgsIGF0IDEwOjUzLCBKb24gU2hhbGxvdyA8 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bT4+IHdyb3RlOg0KDQpIaSBUaGVyZSwNCg0KSSBhcHByZWNpYXRlIHRoYXQgdGhpcyBpcyBsYXRl IHRvIHRoZSB0YWJsZSwgYnV0IGlzIGl0IHBvc3NpYmxlIHRvIHNldCB1cCDigJxhY2Nlc3MtbGlz dHPigJ0gYXMgYSDigJxncm91cGluZ+KAnSBpbiB0aGUgWUFORyBkYXRhIG1vZGVsIHNvIHRoYXQg 4oCcYWNjZXNzLWxpc3Rz4oCdIGNhbiBiZSBpbmNsdWRlZCBieSDigJx1c2Vz4oCdIGluIGEgaGln aGVyIGxldmVsIFlBTkcgZGF0YSBtb2RlbD8NCg0KSSBoYXZlIHJhaXNlZCB0aGlzIGFzIGlzc3Vl ICMyMiBhdCBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9pc3N1ZXMNCg0K UmVnYXJkcw0KDQpKb24NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v ZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQoNCg== --_000_B0576B62CB6145EA99EFE5B67545B85Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClNpbmNlIHRoaXMgaXMgYSA3LWxpbmUgY2hhbmdl LCBJIHNlZSBubyBoYXJtIGluIGl0IGlmIG5vLW9uZSBvYmplY3RzPyBNYWhlc2ggaGFzIHRoZSB0 b2tlbiBmb3Igcm9sbGluZyBpbiB1cGRhdGVzIGRpc2N1c3NlZCBqdXN0IHByaW9yIHRvIHRoZSBl bmQgb2YgMjAxNy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkhlcmXigJlzIGEgcG9zc2libGUgZGlmZjoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+ JCBnaXQgZGlmZiAtYjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZh Y2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFz cz0iIj5kaWZmIC0tZ2l0IGEvc3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmcg Yi9zcmMveWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj5pbmRleCA0ZDY5OGM5Li5iMWExNzNmIDEw MDY0NDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4tLS0g YS9zcmMveWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mIzQzOyYjNDM7JiM0MzsgYi9zcmMveWFu Zy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHg7IiBjbGFzcz0iIj5AQCAtNDAyLDYgJiM0Mzs0MDIsMTAgQEAgbW9kdWxlIGll dGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsvKjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICogQ29uZmlndXJhdGlvbiBkYXRh IG5vZGVzPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgKi88L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xh c3M9IiI+JiM0MzsgJm5ic3A7Z3JvdXBpbmcgYWNjZXNzLWxpc3RzLXRvcCB7PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiYjNDM7ICZuYnNwOyAmbmJzcDtk ZXNjcmlwdGlvbjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9 IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0i Ij4mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0dyb3VwaW5nIHRvIGFsbG93IHJldXNl IG9mIGFjY2VzcyBsaXN0cyBjb250YWluZXIgZWxzZXdoZXJlLiZxdW90Ozs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+JiM0Mzs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb250 YWluZXIgYWNjZXNzLWxpc3RzIHs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4 OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1RoaXMgaXMgYSB0b3AgbGV2ZWwgY29udGFpbmVyIGZv ciBBY2Nlc3MgQ29udHJvbCBMaXN0cy48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB4OyIgY2xhc3M9IiI+QEAgLTU3Niw2ICYjNDM7NTgwLDkgQEAgbW9kdWxlIGlldGYtYWNjZXNz LWNvbnRyb2wtbGlzdCB7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg ZmFjZT0iQ291cmllciIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO308L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3Vy aWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsi IGNsYXNzPSIiPiYjNDM7ICZuYnNwO308L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB4OyIgY2xhc3M9IiI+JiM0MzsgJm5ic3A7dXNlcyBhY2Nlc3MtbGlzdHMtdG9wOzwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mIzQzOzwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YXVnbWVu dCAmcXVvdDsvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UmcXVvdDsgezwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2Rl c2NyaXB0aW9uPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0i Q291cmllciIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0F1Z21lbnQgaW50ZXJmYWNlcyB0byBh bGxvdyBBQ0xzIHRvIGJlIGFzc29jaWF0ZWQgaW4gZWl0aGVyIHRoZTwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D aGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA4IEphbiAyMDE4LCBhdCAxMDo1MywgSm9u IFNoYWxsb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIiBj bGFzcz0iIj5zdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQpIaSBUaGVyZSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQpJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIGlzIGxhdGUgdG8gdGhlIHRhYmxlLCBidXQg aXMgaXQgcG9zc2libGUgdG8gc2V0IHVwIOKAnGFjY2Vzcy1saXN0c+KAnSBhcyBhIOKAnGdyb3Vw aW5n4oCdIGluIHRoZSBZQU5HIGRhdGEgbW9kZWwgc28gdGhhdCDigJxhY2Nlc3MtbGlzdHPigJ0g Y2FuIGJlIGluY2x1ZGVkIGJ5IOKAnHVzZXPigJ0gaW4gYSBoaWdoZXIgbGV2ZWwgWUFORyBkYXRh IG1vZGVsPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkkgaGF2ZSByYWlzZWQg dGhpcyBhcyBpc3N1ZSAjMjIgYXQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9k ZWwvaXNzdWVzIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9pc3N1 ZXM8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KUmVnYXJkczxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkpvbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5uZXRtb2QNCiBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B0576B62CB6145EA99EFE5B67545B85Cciscocom_-- From nobody Mon Jan 8 07:23: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 3BC64129C53; Mon, 8 Jan 2018 07:23:39 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HBQgomRIrLpJ; Mon, 8 Jan 2018 07:23:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32912706D; Mon, 8 Jan 2018 07:23:37 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CCE1C1AE0332; Mon, 8 Jan 2018 16:23:35 +0100 (CET) Date: Mon, 08 Jan 2018 16:21:53 +0100 (CET) Message-Id: <20180108.162153.18427707995478583.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: yang-doctors@ietf.org, draft-ietf-netmod-entity.all@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151507502144.23798.1644071576333370968@ietfa.amsl.com> References: <151507502144.23798.1644071576333370968@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:23:39 -0000 SGksDQoNClJhZGVrIEtyZWrEjcOtIDxya3JlamNpQGNlc25ldC5jej4gd3JvdGU6DQo+IFJldmll d2VyOiBSYWRlayBLcmVqxI3DrQ0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0K PiANCj4gVGhlIGRvY3VtZW50IGl0c2VsZiBhbmQgbm9ybWF0aXZlIHBhcnRzIHNlZW0gZmluZSB0 byBtZSwgdGhlIG9ubHkgaXNzdWUgSSBzZWUNCj4gaXMgd2l0aCB0aGUgaWV0Zi1oYXJkd2FyZS1z dGF0ZSBtb2R1bGUgaW4gbm9uLW5vcm1hdGl2ZSBhcHBlbmRpeCBBLiBJdCBzZWVtcyB0bw0KPiBt ZSB0aGF0IHRoaXMgdGVtcG9yYXJ5IG5vbi1OTURBIG1vZHVsZSBkb2VzIG5vdCBjb25mb3JtIHRv IGl0cyBwdXJwb3NlIGFzDQo+IGRlc2NyaWJlZCBpbiBSRkM2MDg3YmlzLiBBY2NvcmRpbmcgdG8g Z3VpZGVsaW5lcywgc3VjaCBhIG1vZHVsZSBpcyBpbnRlbmRlZCB0bw0KPiBwcm92aWRlIHN0YXRl IChjb25maWcgZmFsc2UpIGRhdGEgaW4gY2FzZSB0aGUgc2VydmVyIGRvZXMgbm90IGltcGxlbWVu dCBOTURBDQo+ICh0byBicmlkZ2UgdGhlIHRpbWUgcGVyaW9kIHVudGlsIE5NREEgaXMgaW1wbGVt ZW50ZWQpLiBTbyBzdWNoIGEgc2VydmVyIGlzIElNSE8NCj4gaW50ZW5kZWQgdG8gaW1wbGVtZW50 IGJvdGggbW9kdWxlcywgZm9vIGFuZCBmb28tc3RhdGUuIFRoZSBmb28tc3RhdGUgY29udGFpbnMN Cj4gInRoZSB0b3AtbGV2ZWwgY29uZmlnLWZhbHNlIGRhdGEgbm9kZXMgdGhhdCB3b3VsZCBoYXZl IGJlZW4gZGVmaW5lZCBpbiBhIGxlZ2FjeQ0KPiBZQU5HIG1vZHVsZSIgLSBzbyBpdCdzIG9ubHkg dGhlIHJvIG1pcnJvciBvZiBkYXRhIG5vZGVzLiBCdXQNCj4gaWV0Zi1oYXJkd2FyZS1zdGF0ZSBj b250YWlucyBub3RpZmljYXRpb25zLCB3aGljaCBhcmUgbm90IHRoZSBkYXRhIG5vZGVzIGFzDQo+ IGRlZmluZWQgaW4gUkZDNzk1MC4gSSB1bmRlcnN0YW5kIHdoeSB0aGUgbm90aWZpY2F0aW9ucyB3 ZXJlIHBsYWNlZCBhbHNvIGludG8NCj4gdGhlIGlldGYtaGFyZHdhcmUtc3RhdGUgLSB0aGUgbW9k dWxlJ3MgZGVzY3JpcHRpb24gc3RhdGVzIHRoYXQgIklmIGEgc2VydmVyDQo+IHRoYXQgaW1wbGVt ZW50cyB0aGlzIG1vZHVsZSBidXQgZG9lc24ndCBzdXBwb3J0IE5NREEgYWxzbyBzdXBwb3J0cw0K PiBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlIGNvbXBvbmVudHMsIGl0IFNIT1VMRCBhbHNvIGlt cGxlbWVudCB0aGUgbW9kdWxlDQo+ICdpZXRmLWhhcmR3YXJlJyAuLi4iLCBzbyBpdCBhbGxvd3Mg aXRzIHN0YW5kYWxvbmUgdXNhZ2UgaW4gY2FzZSB0aGUgc2VydmVyIGRvZXMNCj4gbm90IHN1cHBv cnQgaHcgY29uZmlndXJhdGlvbi4gQnV0IGluIHN1Y2ggYSBjYXNlLCB0aGUgc2VydmVyIGNhbiBp bXBsZW1lbnQNCj4gaWV0Zi1oYXJkd2FyZSB3aXRoIGRldmlhdGlvbnMgb24gdGhlIGNvbmZpZz10 cnVlIG5vZGVzLg0KDQpUaGUgcHJvYmxlbSB3aXRoIHVzZWluZyB0aGUgbm90aWZjYXRpb25zIGRl ZmluZWQgaW4gaWV0Zi1oYXJkd2FyZSBpbg0KdGhpcyBjYXNlIGlzIHRoYXQgYWxsIGxlYWZyZWZz IHdvdWxkIGJlIHdyb25nOyB0aGV5J2QgcG9pbnQgaW50byBhDQpzY2hlbWEgdGhhdCBpcyBub3Qg aW1wbGVtZW50ZWQuDQoNCj4gVGhlIHNhbWUgd2F5IGl0IGhhZCB0bw0KPiBpbXBsZW1lbnQgdGhl IGxlZ2FjeSBZQU5HIG1vZHVsZSAoYmVmb3JlIE5NREEpLg0KDQpCZWZvcmUgTk1EQSB0aGUgbGVh ZnJlZnMgaW4gdGhlIG5vdGlmY2F0aW9ucyBwb2ludGVkIHRvDQovaGFyZHdhcmUtc3RhdGUsIGFu ZCBhbGwgY29uZmlnIHdhcyBkZWZpbmVkIHdpdGggYW4gaWYtZmVhdHVyZSwgc28gYQ0Kc2VydmVy IGRpZCBub3QgaGF2ZSB0byB1c2UgYW55IGRldmlhdGlvbnMgaW4gdGhpcyBjYXNlLg0KDQoNCg0K L21hcnRpbg0KDQoNCg0KPiANCj4gU28gSSB0aGluayB0aGF0IHRoZSBub3RpZmljYXRpb25zIHNo b3VsZCBiZSByZW1vdmVkIGZyb20gaWV0Zi1oYXJkd2FyZS1zdGF0ZQ0KPiBhbmQgdGhlIG1vZHVs ZSdzIGRlc2NyaXB0aW9uIHNob3VsZCBjaGFuZ2UgdGhpcyB3YXk6DQo+IA0KPiBPTEQNCj4gDQo+ ICAgSWYgYSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHRoaXMgbW9kdWxlIGJ1dCBkb2Vzbid0IHN1 cHBvcnQgTk1EQQ0KPiAgIGFsc28gc3VwcG9ydHMgY29uZmlndXJhdGlvbiBvZiBoYXJkd2FyZSBj b21wb25lbnRzLCBpdCBTSE9VTEQNCj4gICBhbHNvIGltcGxlbWVudCB0aGUgbW9kdWxlICdpZXRm LWhhcmR3YXJlJyBpbiB0aGUgY29uZmlndXJhdGlvbg0KPiAgIGRhdGFzdG9yZXMuIFRoZSBjb3Jy ZXNwb25kaW5nIHN0YXRlIGRhdGEgaXMgZm91bmQgaW4gdGhlDQo+ICAgJy9ody1zdGF0ZTpoYXJk d2FyZScgc3VidHJlZS4NCj4gDQo+IE5FVw0KPiANCj4gICBJZiBhIHNlcnZlciB0aGF0IGltcGxl bWVudHMgdGhpcyBtb2R1bGUgYnV0IGRvZXNuJ3Qgc3VwcG9ydCBOTURBLA0KPiAgIGl0IE1VU1Qg YWxzbyBpbXBsZW1lbnQgdGhlIG1vZHVsZSAnaWV0Zi1oYXJkd2FyZScgaW4gdGhlDQo+ICAgY29u ZmlndXJhdGlvbiBkYXRhc3RvcmVzLiBUaGUgY29ycmVzcG9uZGluZyBzdGF0ZSBkYXRhIGlzIGZv dW5kDQo+ICAgaW4gdGhlICcvaHctc3RhdGU6aGFyZHdhcmUnIHN1YnRyZWUuDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Mon Jan 8 07:31: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 3956A126C25 for ; Mon, 8 Jan 2018 07:31:31 -0800 (PST) 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_RP_MATCHES_RCVD=-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 dUf_GuJ-btDR for ; Mon, 8 Jan 2018 07:31:29 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84AD1200C5 for ; Mon, 8 Jan 2018 07:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17550; q=dns/txt; s=iport; t=1515425489; x=1516635089; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=qA0B9xc+sv9cPtqqKG0F+lIM9dhksXQuuybd1KUoPeg=; b=GoQj5bTxkYDgis4tC9Uwx4gbp4OSjxRs+aV7kToCwYKyUqH3NWL8JXEp SMU49dWJ49AJ5+XtHRehY0fibzRT7hXjXIbw/fWnbk+Lc9fRTDEdbLDr/ mYtdE/ivdHh2guQmCAKq2bdGTfd0EYSMtvS7Ixsv4WUmcCz4ZQhtd9i5F E=; X-IronPort-AV: E=Sophos;i="5.46,330,1511827200"; d="scan'208,217";a="1278099" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 15:31:27 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w08FVQSc021801; Mon, 8 Jan 2018 15:31:26 GMT To: "Einar Nilsen-Nygaard (einarnn)" , Jon Shallow , Mahesh Jethanandani Cc: "netmod@ietf.org" References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> From: Robert Wilton Message-ID: <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> Date: Mon, 8 Jan 2018 15:31:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------66C4978BB07FF18388AA8688" Content-Language: en-US Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:31:31 -0000 This is a multi-part message in MIME format. --------------66C4978BB07FF18388AA8688 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Einar, Jon, Mahesh, My gut instinct is that making this a grouping might not be a good idea: 1) If somebody updates the core ACL model, will then need to check that anyone using it should be similarly updated (unless they use import-by-revision). 2) Does it make sense to define ACLs in separate places.  Would like be more simple if ACLs were defined in a central place and then just referenced by other protocols as required. 3) I think that groupings are probably overused and I think that they can detract from the readability of the model.  (I regard the OpenConfig YANG models as an extreme example of this, where it is necessary to compile the modules together to figure out where everything fits together). Having said that, I don't think that this issue is important enough to have a long discussion about ... Thanks, Rob On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote: > Since this is a 7-line change, I see no harm in it if no-one objects? > Mahesh has the token for rolling in updates discussed just prior to > the end of 2017. > > Here’s a possible diff: > > $ git diff -b > diff --git a/src/yang/ietf-access-control-list.yang > b/src/yang/ietf-access-control-list.yang > index 4d698c9..b1a173f 100644 > --- a/src/yang/ietf-access-control-list.yang > +++ b/src/yang/ietf-access-control-list.yang > @@ -402,6 +402,10 @@ module ietf-access-control-list { >    /* >     * Configuration data nodes >     */ > +  grouping access-lists-top { > +    description > +      "Grouping to allow reuse of access lists container elsewhere."; > + >      container access-lists { >        description >          "This is a top level container for Access Control Lists. > @@ -576,6 +580,9 @@ module ietf-access-control-list { >          } >        } >      } > +  } > +  uses access-lists-top; > + >    augment "/if:interfaces/if:interface" { >      description >        "Augment interfaces to allow ACLs to be associated in either the > > Cheers, > > Einar > > >> On 8 Jan 2018, at 10:53, Jon Shallow > > wrote: >> >> Hi There, >> I appreciate that this is late to the table, but is it possible to >> set up “access-lists” as a “grouping” in the YANG data model so that >> “access-lists” can be included by “uses” in a higher level YANG data >> model? >> I have raised this as issue #22 >> athttps://github.com/netmod-wg/acl-model/issues >> Regards >> Jon >> _______________________________________________ >> 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 --------------66C4978BB07FF18388AA8688 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that anyone using it should be similarly updated (unless they use import-by-revision).

2) Does it make sense to define ACLs in separate places.  Would like be more simple if ACLs were defined in a central place and then just referenced by other protocols as required.

3) I think that groupings are probably overused and I think that they can detract from the readability of the model.  (I regard the OpenConfig YANG models as an extreme example of this, where it is necessary to compile the modules together to figure out where everything fits together).

Having said that, I don't think that this issue is important enough to have a long discussion about ...

Thanks,
Rob


On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh has the token for rolling in updates discussed just prior to the end of 2017.

Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang b/src/yang/ietf-access-control-list.yang
index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
    * Configuration data nodes
    */
+  grouping access-lists-top {
+    description
+      "Grouping to allow reuse of access lists container elsewhere.";
+
     container access-lists {
       description
         "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
         }
       }
     }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
     description
       "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar


On 8 Jan 2018, at 10:53, Jon Shallow <supjps-ietf@jpshallow.com> wrote:

Hi There,
 
I appreciate that this is late to the table, but is it possible to set up “access-lists” as a “grouping” in the YANG data model so that “access-lists” can be included by “uses” in a higher level YANG data model?
 
I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues
 
Regards
 
Jon
_______________________________________________
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

--------------66C4978BB07FF18388AA8688-- From nobody Mon Jan 8 07:46:57 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 3D3AB129C53 for ; Mon, 8 Jan 2018 07:46:57 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 EBCLug-dTpOY for ; Mon, 8 Jan 2018 07:46:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2832B129966 for ; Mon, 8 Jan 2018 07:46:55 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id C77151AE0332; Mon, 8 Jan 2018 16:46:52 +0100 (CET) Date: Mon, 08 Jan 2018 16:45:09 +0100 (CET) Message-Id: <20180108.164509.2179320293753239869.mbj@tail-f.com> To: rwilton@cisco.com Cc: einarnn@cisco.com, supjps-ietf@jpshallow.com, mjethanandani@gmail.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:46:57 -0000 SGksDQoNClJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gSGkgRWlu YXIsIEpvbiwgTWFoZXNoLA0KPiANCj4gTXkgZ3V0IGluc3RpbmN0IGlzIHRoYXQgbWFraW5nIHRo aXMgYSBncm91cGluZyBtaWdodCBub3QgYmUgYSBnb29kDQo+IGlkZWE6DQo+IA0KPiAxKSBJZiBz b21lYm9keSB1cGRhdGVzIHRoZSBjb3JlIEFDTCBtb2RlbCwgd2lsbCB0aGVuIG5lZWQgdG8gY2hl Y2sNCj4gdGhhdCBhbnlvbmUgdXNpbmcgaXQgc2hvdWxkIGJlIHNpbWlsYXJseSB1cGRhdGVkICh1 bmxlc3MgdGhleSB1c2UNCj4gaW1wb3J0LWJ5LXJldmlzaW9uKS4NCj4gDQo+IDIpIERvZXMgaXQg bWFrZSBzZW5zZSB0byBkZWZpbmUgQUNMcyBpbiBzZXBhcmF0ZSBwbGFjZXMuwqAgV291bGQgbGlr ZQ0KPiBiZSBtb3JlIHNpbXBsZSBpZiBBQ0xzIHdlcmUgZGVmaW5lZCBpbiBhIGNlbnRyYWwgcGxh Y2UgYW5kIHRoZW4ganVzdA0KPiByZWZlcmVuY2VkIGJ5IG90aGVyIHByb3RvY29scyBhcyByZXF1 aXJlZC4NCj4gDQo+IDMpIEkgdGhpbmsgdGhhdCBncm91cGluZ3MgYXJlIHByb2JhYmx5IG92ZXJ1 c2VkIGFuZCBJIHRoaW5rIHRoYXQgdGhleQ0KPiBjYW4gZGV0cmFjdCBmcm9tIHRoZSByZWFkYWJp bGl0eSBvZiB0aGUgbW9kZWwuwqAgKEkgcmVnYXJkIHRoZQ0KPiBPcGVuQ29uZmlnIFlBTkcgbW9k ZWxzIGFzIGFuIGV4dHJlbWUgZXhhbXBsZSBvZiB0aGlzLCB3aGVyZSBpdCBpcw0KPiBuZWNlc3Nh cnkgdG8gY29tcGlsZSB0aGUgbW9kdWxlcyB0b2dldGhlciB0byBmaWd1cmUgb3V0IHdoZXJlDQo+ IGV2ZXJ5dGhpbmcgZml0cyB0b2dldGhlcikuDQoNCkkgYWdyZWUgd2l0aCBhbGwgdGhyZWUgc3Rh dGVtZW50cy4gIFRoZSBjdXJyZW50IGFjbCBkYXRhIG1vZGVsIGhhcyBhDQp0b3AtbGV2ZWwgZ3Jv dXBpbmcgImludGVyZmFjZS1hY2wiIHdoaWNoIHByb2JhYmx5IGlzIG5vdCBpbnRlbmRlZCB0bw0K YmUgImV4cG9ydGVkIi4gIEkgdGhpbmsgb3Qgc2hvdWxkIGJlIG1vdmVkIGludG8gdGhlDQoiYXR0 YWNobWVudC1wb2ludHMiIGNvbnRhaW5lciwgaW4gb3JkZXIgdG8gbWFrZSBpdCBsb2NhbC4NCg0K SWYgdGhlIGVudGlyZSBhY2Nlc3MtbGlzdCBjb250YWluZXIgaXMgZGVmaW5lZCBhcyBhIGdvcnVw aW5nLCBhbmQgaXMNCnVzZWQgaW4gbXVsdGlwbGUgcGxhY2VzLCBob3cgYXJlIHRoZSBtdWx0aXBs ZSBpbnRlcmZhY2UNCmF0dGFjaG1lbnQtcG9pbnRzIGhhbmRsZWQ/DQoNCg0KL21hcnRpbg0KDQoN Cg0KPiANCj4gSGF2aW5nIHNhaWQgdGhhdCwgSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXNzdWUg aXMgaW1wb3J0YW50IGVub3VnaCB0bw0KPiBoYXZlIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IC4u Lg0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4gDQo+IA0KPiBPbiAwOC8wMS8yMDE4IDE1OjAyLCBF aW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6DQo+ID4gU2luY2UgdGhpcyBpcyBh IDctbGluZSBjaGFuZ2UsIEkgc2VlIG5vIGhhcm0gaW4gaXQgaWYgbm8tb25lIG9iamVjdHM/DQo+ ID4gTWFoZXNoIGhhcyB0aGUgdG9rZW4gZm9yIHJvbGxpbmcgaW4gdXBkYXRlcyBkaXNjdXNzZWQg anVzdCBwcmlvciB0bw0KPiA+IHRoZSBlbmQgb2YgMjAxNy4NCj4gPg0KPiA+IEhlcmXigJlzIGEg cG9zc2libGUgZGlmZjoNCj4gPg0KPiA+ICQgZ2l0IGRpZmYgLWINCj4gPiBkaWZmIC0tZ2l0IGEv c3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCj4gPiBiL3NyYy95YW5nL2ll dGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nDQo+ID4gaW5kZXggNGQ2OThjOS4uYjFhMTczZiAx MDA2NDQNCj4gPiAtLS0gYS9zcmMveWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZw0K PiA+ICsrKyBiL3NyYy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nDQo+ID4gQEAg LTQwMiw2ICs0MDIsMTAgQEAgbW9kdWxlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7DQo+ID4g wqAgwqAvKg0KPiA+IMKgIMKgICogQ29uZmlndXJhdGlvbiBkYXRhIG5vZGVzDQo+ID4gwqAgwqAg Ki8NCj4gPiArIMKgZ3JvdXBpbmcgYWNjZXNzLWxpc3RzLXRvcCB7DQo+ID4gKyDCoCDCoGRlc2Ny aXB0aW9uDQo+ID4gKyDCoCDCoCDCoCJHcm91cGluZyB0byBhbGxvdyByZXVzZSBvZiBhY2Nlc3Mg bGlzdHMgY29udGFpbmVyIGVsc2V3aGVyZS4iOw0KPiA+ICsNCj4gPiDCoCDCoCDCoGNvbnRhaW5l ciBhY2Nlc3MtbGlzdHMgew0KPiA+IMKgIMKgIMKgIMKgZGVzY3JpcHRpb24NCj4gPiDCoCDCoCDC oCDCoCDCoCJUaGlzIGlzIGEgdG9wIGxldmVsIGNvbnRhaW5lciBmb3IgQWNjZXNzIENvbnRyb2wg TGlzdHMuDQo+ID4gQEAgLTU3Niw2ICs1ODAsOSBAQCBtb2R1bGUgaWV0Zi1hY2Nlc3MtY29udHJv bC1saXN0IHsNCj4gPiDCoCDCoCDCoCDCoCDCoH0NCj4gPiDCoCDCoCDCoCDCoH0NCj4gPiDCoCDC oCDCoH0NCj4gPiArIMKgfQ0KPiA+ICsgwqB1c2VzIGFjY2Vzcy1saXN0cy10b3A7DQo+ID4gKw0K PiA+IMKgIMKgYXVnbWVudCAiL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlIiB7DQo+ID4gwqAg wqAgwqBkZXNjcmlwdGlvbg0KPiA+IMKgIMKgIMKgIMKgIkF1Z21lbnQgaW50ZXJmYWNlcyB0byBh bGxvdyBBQ0xzIHRvIGJlIGFzc29jaWF0ZWQgaW4gZWl0aGVyDQo+ID4gdGhlDQo+ID4NCj4gPiBD aGVlcnMsDQo+ID4NCj4gPiBFaW5hcg0KPiA+DQo+ID4NCj4gPj4gT24gOCBKYW4gMjAxOCwgYXQg MTA6NTMsIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tDQo+ID4+IDxtYWls dG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+IHdyb3RlOg0KPiA+Pg0KPiA+PiBIaSBUaGVy ZSwNCj4gPj4gSSBhcHByZWNpYXRlIHRoYXQgdGhpcyBpcyBsYXRlIHRvIHRoZSB0YWJsZSwgYnV0 IGlzIGl0IHBvc3NpYmxlIHRvIHNldA0KPiA+PiB1cCDigJxhY2Nlc3MtbGlzdHPigJ0gYXMgYSDi gJxncm91cGluZ+KAnSBpbiB0aGUgWUFORyBkYXRhIG1vZGVsIHNvIHRoYXQNCj4gPj4g4oCcYWNj ZXNzLWxpc3Rz4oCdIGNhbiBiZSBpbmNsdWRlZCBieSDigJx1c2Vz4oCdIGluIGEgaGlnaGVyIGxl dmVsIFlBTkcgZGF0YQ0KPiA+PiBtb2RlbD8NCj4gPj4gSSBoYXZlIHJhaXNlZCB0aGlzIGFzIGlz c3VlICMyMg0KPiA+PiBhdGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL2lz c3Vlcw0KPiA+PiBSZWdhcmRzDQo+ID4+IEpvbg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+ IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+DQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCg== From nobody Mon Jan 8 07:47: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 64D90129966 for ; Mon, 8 Jan 2018 07:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 vJU44eU9Z9Vr for ; Mon, 8 Jan 2018 07:47:17 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 7E9A3126579 for ; Mon, 8 Jan 2018 07:47:17 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eYZdn-0005df-61; Mon, 08 Jan 2018 15:47:11 +0000 From: "Jon Shallow" To: "'Robert Wilton'" , , "'Einar Nilsen-Nygaard \(einarnn\)'" , "'Mahesh Jethanandani'" References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> In-Reply-To: <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> Date: Mon, 8 Jan 2018 15:47:11 -0000 Message-ID: <022401d38897$f2aa1b70$d7fe5250$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0225_01D38897.F2ABA210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQyRuXL6dM12jnz185RKPboCEftgLUfB8AAmARq32hxfarIA== Content-Language: en-gb Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:47:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0225_01D38897.F2ABA210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 A good set of points. =20 My particular use case (hence raising the question) is defining a YANG = model where there are multiple appliances and where ACLs are defined for = each appliance, but there is the likelihood of the different appliances = using the same =E2=80=9Cacl-name=E2=80=9D, but the contents of = =E2=80=9Cacl-name=E2=80=9D are different. Having a grouping (using = import-by-revision) would help me considerably here. =20 Regards =20 Jon =20 From: Robert Wilton [mailto: rwilton@cisco.com]=20 Sent: 08 January 2018 15:31 To: Einar Nilsen-Nygaard (einarnn); Jon Shallow; Mahesh Jethanandani Cc: netmod@ietf.org Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a = "grouping" =20 Hi Einar, Jon, Mahesh, My gut instinct is that making this a grouping might not be a good idea: 1) If somebody updates the core ACL model, will then need to check that = anyone using it should be similarly updated (unless they use = import-by-revision). 2) Does it make sense to define ACLs in separate places. Would like be = more simple if ACLs were defined in a central place and then just = referenced by other protocols as required. 3) I think that groupings are probably overused and I think that they = can detract from the readability of the model. (I regard the OpenConfig = YANG models as an extreme example of this, where it is necessary to = compile the modules together to figure out where everything fits = together). Having said that, I don't think that this issue is important enough to = have a long discussion about ... Thanks, Rob On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote: Since this is a 7-line change, I see no harm in it if no-one objects? = Mahesh has the token for rolling in updates discussed just prior to the = end of 2017.=20 =20 Here=E2=80=99s a possible diff:=20 =20 $ git diff -b diff --git a/src/yang/ietf-access-control-list.yang = b/src/yang/ietf-access-control-list.yang index 4d698c9..b1a173f 100644 --- a/src/yang/ietf-access-control-list.yang +++ b/src/yang/ietf-access-control-list.yang @@ -402,6 +402,10 @@ module ietf-access-control-list { /* * Configuration data nodes */ + grouping access-lists-top { + description + "Grouping to allow reuse of access lists container elsewhere."; + container access-lists { description "This is a top level container for Access Control Lists. @@ -576,6 +580,9 @@ module ietf-access-control-list { } } } + } + uses access-lists-top; + augment "/if:interfaces/if:interface" { description "Augment interfaces to allow ACLs to be associated in either the =20 Cheers, =20 Einar =20 On 8 Jan 2018, at 10:53, Jon Shallow wrote: =20 Hi There, =20 I appreciate that this is late to the table, but is it possible to set = up =E2=80=9Caccess-lists=E2=80=9D as a =E2=80=9Cgrouping=E2=80=9D in the = YANG data model so that =E2=80=9Caccess-lists=E2=80=9D can be included = by =E2=80=9Cuses=E2=80=9D in a higher level YANG data model? =20 I have raised this as issue #22 at = = https://github.com/netmod-wg/acl-model/issues =20 Regards =20 Jon _______________________________________________ netmod mailing list netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod =20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_000_0225_01D38897.F2ABA210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

A good set of points.

 

My particular use case (hence raising the question) is defining a = YANG model where there are multiple appliances and where ACLs are = defined for each appliance, but there is the likelihood of the different = appliances using the same =E2=80=9Cacl-name=E2=80=9D, but the contents = of =E2=80=9Cacl-name=E2=80=9D are different.=C2=A0 Having a grouping = (using import-by-revision) would help me considerably = here.

 

Regards

 

Jon

 

From: Robert Wilton [mailto: rwilton@cisco.com]
Sent: 08 = January 2018 15:31
To: Einar Nilsen-Nygaard (einarnn); Jon = Shallow; Mahesh Jethanandani
Cc: = netmod@ietf.org
Subject: Re: [netmod] Netmod ACL - Can = "access-lists" be set up as a = "grouping"

 

Hi Einar, Jon, = Mahesh,

My gut instinct is that making this a grouping = might not be a good idea:

1) If somebody updates the = core ACL model, will then need to check that anyone using it should be = similarly updated (unless they use = import-by-revision).

2) Does it make sense to define = ACLs in separate places.  Would like be more simple if ACLs were = defined in a central place and then just referenced by other protocols = as required.

3) I think that groupings are probably = overused and I think that they can detract from the readability of the = model.  (I regard the OpenConfig YANG models as an extreme example = of this, where it is necessary to compile the modules together to figure = out where everything fits together).

Having said that, I don't = think that this issue is important enough to have a long discussion = about ...

Thanks,
Rob

On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) = wrote:

Since this is a 7-line change, I see no harm in it if = no-one objects? Mahesh has the token for rolling in updates discussed = just prior to the end of 2017.

 

Here=E2=80=99s a possible diff:

 

$ = git diff -b

diff --git = a/src/yang/ietf-access-control-list.yang = b/src/yang/ietf-access-control-list.yang

=

index 4d698c9..b1a173f = 100644

--- = a/src/yang/ietf-access-control-list.yang

=

+++ = b/src/yang/ietf-access-control-list.yang

=

@@ -402,6 +402,10 @@ = module ietf-access-control-list {

  =  /*

    * = Configuration data nodes

    = */

+  grouping = access-lists-top {

+ =    description

+ =      "Grouping to allow reuse of access lists = container elsewhere.";

+

    =  container access-lists {

      =  description

      =    "This is a top level container for Access Control = Lists.

@@ -576,6 +580,9 @@ module = ietf-access-control-list {

      =    }

      =  }

    =  }

+ =  }

+  uses = access-lists-top;

+

   augment = "/if:interfaces/if:interface" = {

    =  description

      =  "Augment interfaces to allow ACLs to be associated in either = the

 

Cheers,

 

Einar

 



On 8 = Jan 2018, at 10:53, Jon Shallow <supjps-ietf@jpshallow.com&g= t; wrote:

 

Hi = There,

 =

I = appreciate that this is late to the table, but is it possible to set up = =E2=80=9Caccess-lists=E2=80=9D as a =E2=80=9Cgrouping=E2=80=9D in the = YANG data model so that =E2=80=9Caccess-lists=E2=80=9D can be included = by =E2=80=9Cuses=E2=80=9D in a higher level YANG data = model?

 =

I have = raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues

 =

Regards

 =

Jon

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

=

 




_______________________=
________________________
netmod mailing =
list
netmod@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/netmod

 

------=_NextPart_000_0225_01D38897.F2ABA210-- From nobody Mon Jan 8 07:52: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 694A3129C6E for ; Mon, 8 Jan 2018 07:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 3DtLb3A0qNKg for ; Mon, 8 Jan 2018 07:52:01 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D04126579 for ; Mon, 8 Jan 2018 07:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27508; q=dns/txt; s=iport; t=1515426719; x=1516636319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=U3uo7w8Bmmus0yIyb6vk+qkDaWHfa7hnpPVltmvEfvs=; b=GpfcTHKKHnnRPpSkIxfIrhQ4x74kbMRtOQ9jLMszKVK+VA9eiBuajtpM WRHrvtcJRvTVn/YkvWMEWm1PtFCSzUyBEdPL+SQ2h955EnaEKzkdQOeSu BCTIOMxD6fl8J3E9zmENyOOOz+H9ZO188udmwrTHISwUGWIBD76iGFiGk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArBQCmklNa/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdWZ0JweEAJh9mSyCFQoYAQqEA0ZPAhqEHEAXAQEBAQEBAQE?= =?us-ascii?q?BayiFJAIBAwEBIUsLEAIBCDgHAwICAiULFBEBAQQBDQWJTWQQsF6CJyaKCwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFhCCCFYNogwWDLwGBRyYYgwAxgjQFo14CiAW?= =?us-ascii?q?NN4IXkXKKYIJThh+DGAIRGQGBOwEhATaBUG8VPSoBgX8/ghUcgWd4iCSBNIEXA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos; i="5.46,330,1511827200"; d="scan'208,217"; a="53763170" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 15:51:58 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w08Fpw1Z008235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jan 2018 15:51:58 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 8 Jan 2018 10:51:57 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Mon, 8 Jan 2018 10:51:56 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Jon Shallow , "Mahesh Jethanandani" CC: "netmod@ietf.org" Thread-Topic: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" Thread-Index: AdOIbvlU0QBjg+SHRESC+Oh6XUPoRwATLimAAAD9eAAAALiggA== Date: Mon, 8 Jan 2018 15:51:56 +0000 Message-ID: References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> In-Reply-To: <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.106.4] Content-Type: multipart/alternative; boundary="_000_A6455D8AE85C411A8B115B15EA0D9AB9ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:52:03 -0000 --_000_A6455D8AE85C411A8B115B15EA0D9AB9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIDggSmFuIDIwMTgsIGF0IDE1OjMxLCBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0g RU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRv bkBjaXNjby5jb20+PiB3cm90ZToNCg0KDQpIaSBFaW5hciwgSm9uLCBNYWhlc2gsDQoNCk15IGd1 dCBpbnN0aW5jdCBpcyB0aGF0IG1ha2luZyB0aGlzIGEgZ3JvdXBpbmcgbWlnaHQgbm90IGJlIGEg Z29vZCBpZGVhOg0KDQoxKSBJZiBzb21lYm9keSB1cGRhdGVzIHRoZSBjb3JlIEFDTCBtb2RlbCwg d2lsbCB0aGVuIG5lZWQgdG8gY2hlY2sgdGhhdCBhbnlvbmUgdXNpbmcgaXQgc2hvdWxkIGJlIHNp bWlsYXJseSB1cGRhdGVkICh1bmxlc3MgdGhleSB1c2UgaW1wb3J0LWJ5LXJldmlzaW9uKS4NCg0K R3JvdXBpbmdzIGFuZCB0eXBlZGVmcyBhcmUgc3ViamVjdCB0byB0aGUgc2FtZSBiYWNrd2FyZHMt Y29tcGF0aWJpbGl0eSBjb25zdHJhaW50cyBhcyBhbnkgb3RoZXIgZGF0YS4gVGh1cyB1cGRhdGVz IHRvIHRoZSBtb2RlbCBzaG91bGQgYWx3YXlzIGJlIHRyb3VibGUtZnJlZSBpZiB0aGUgdXBkYXRl cyBjb25mb3JtIHRvIFJGQyA2MDIwLzc5NTAgYmFja3dhcmRzLWNvbXBhdGliaWxpdHkgcnVsZXMg Zm9yIG1vZGVsIHVwZGF0ZXMuDQoNCg0KMikgRG9lcyBpdCBtYWtlIHNlbnNlIHRvIGRlZmluZSBB Q0xzIGluIHNlcGFyYXRlIHBsYWNlcy4gIFdvdWxkIGxpa2UgYmUgbW9yZSBzaW1wbGUgaWYgQUNM cyB3ZXJlIGRlZmluZWQgaW4gYSBjZW50cmFsIHBsYWNlIGFuZCB0aGVuIGp1c3QgcmVmZXJlbmNl ZCBieSBvdGhlciBwcm90b2NvbHMgYXMgcmVxdWlyZWQuDQoNCkpvbiBjbGVhcmx5IGhhcyBhIGNh c2UgaGUgaXMgdGhpbmtpbmcgYWJvdXQsIGFuZCBtYWtpbmcgYW4gYWNjZXNzIGxpc3QgY29udGFp bmVyIHJldXNhYmxlIGRvZXNu4oCZdCBzZWVtIGxpa2UgYW4gaW50cmluc2ljYWxseSBiYWQgaWRl YSB0byBtZS4gV2hhdCBtYXkgYmUgYW4gaXJyaXRhdGluZyB0aGluZyBpcyBpZiB0aGVyZSBhcmUg PjEgdXNlIGNhc2UgZm9yIHRoaXMgYW5kIGVhY2ggdXNlIGNhc2UgaXMgaW4gZWZmZWN0IHJlcXVp cmVkIHRvIGRlZmluZSBpdOKAmXMgb3duIGlkZWEgb2YgYSBsaXN0IG9mIGFjY2VzcyBsaXN0IGRl ZmluaXRpb25zLg0KDQoNCjMpIEkgdGhpbmsgdGhhdCBncm91cGluZ3MgYXJlIHByb2JhYmx5IG92 ZXJ1c2VkIGFuZCBJIHRoaW5rIHRoYXQgdGhleSBjYW4gZGV0cmFjdCBmcm9tIHRoZSByZWFkYWJp bGl0eSBvZiB0aGUgbW9kZWwuICAoSSByZWdhcmQgdGhlIE9wZW5Db25maWcgWUFORyBtb2RlbHMg YXMgYW4gZXh0cmVtZSBleGFtcGxlIG9mIHRoaXMsIHdoZXJlIGl0IGlzIG5lY2Vzc2FyeSB0byBj b21waWxlIHRoZSBtb2R1bGVzIHRvZ2V0aGVyIHRvIGZpZ3VyZSBvdXQgd2hlcmUgZXZlcnl0aGlu ZyBmaXRzIHRvZ2V0aGVyKS4NCg0KSeKAmW0gbm90IGdvaW5nIHRvIGRpc2FncmVlIHdpdGggeW91 ciBjb21tZW50cyBvbiB0aGUgb3ZlcnVzZSBvZiBncm91cGluZ3MuIFdlIGNvdWxkIGFsc28gcmVm ZXIgdG8gQ2lzY28gSU9TLVhSIG5hdGl2ZSBtb2RlbHMsIHdoZXJlIHdlIGhhdmUgc29tZSBtb2Rl bHMgd2l0aCA4IGxldmVscyAocGVyaGFwcyBtb3JlPykgb2YgbmVzdGVkIGdyb3VwaW5ncyA7LSkN Cg0KSGF2aW5nIHNhaWQgdGhhdCwgSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXNzdWUgaXMgaW1w b3J0YW50IGVub3VnaCB0byBoYXZlIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IC4uLg0KDQpMaWtl d2lzZS4gSSBoYXZlIG5vIG9iamVjdGlvbiB0byB0aGlzIGNoYW5nZSwgYnV0IG5vIHN0cm9uZyB2 ZXN0ZWQgaW50ZXJlc3QgZWl0aGVyLiBXaGF0IEnigJltIG1vc3QgaW50ZXJlc3RlZCBpbiBpcyBn ZXR0aW5nIHRvIGFuIGFncmVlZCBtb2RlbCBhdCB0aGlzIHBvaW50LCBhbmQgdGhpcyBjaGFuZ2Ug d291bGRu4oCZdCBpbXBhY3QgdGhhdCBhcyBpdCBkb2VzbuKAmXQgY2hhbmdlIHRoZSBhY3R1YWwg bW9kZWwuDQoNCkpvbiDigJQgY291bGQgeW91IHBlcmhhcHMgYXJ0aWN1bGF0ZSB5b3VyIHVzZSBj YXNlKHMpPyBBbmQgcGVyaGFwcyB1cGRhdGUgaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9h Y2wtbW9kZWwvaXNzdWVzIHdpdGggdGhlbT8NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNClRoYW5r cywNClJvYg0KDQoNCk9uIDA4LzAxLzIwMTggMTU6MDIsIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChl aW5hcm5uKSB3cm90ZToNClNpbmNlIHRoaXMgaXMgYSA3LWxpbmUgY2hhbmdlLCBJIHNlZSBubyBo YXJtIGluIGl0IGlmIG5vLW9uZSBvYmplY3RzPyBNYWhlc2ggaGFzIHRoZSB0b2tlbiBmb3Igcm9s bGluZyBpbiB1cGRhdGVzIGRpc2N1c3NlZCBqdXN0IHByaW9yIHRvIHRoZSBlbmQgb2YgMjAxNy4N Cg0KSGVyZeKAmXMgYSBwb3NzaWJsZSBkaWZmOg0KDQokIGdpdCBkaWZmIC1iDQpkaWZmIC0tZ2l0 IGEvc3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcgYi9zcmMveWFuZy9pZXRm LWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZw0KaW5kZXggNGQ2OThjOS4uYjFhMTczZiAxMDA2NDQN Ci0tLSBhL3NyYy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nDQorKysgYi9zcmMv eWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZw0KQEAgLTQwMiw2ICs0MDIsMTAgQEAg bW9kdWxlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7DQogICAvKg0KICAgICogQ29uZmlndXJh dGlvbiBkYXRhIG5vZGVzDQogICAgKi8NCisgIGdyb3VwaW5nIGFjY2Vzcy1saXN0cy10b3Agew0K KyAgICBkZXNjcmlwdGlvbg0KKyAgICAgICJHcm91cGluZyB0byBhbGxvdyByZXVzZSBvZiBhY2Nl c3MgbGlzdHMgY29udGFpbmVyIGVsc2V3aGVyZS4iOw0KKw0KICAgICBjb250YWluZXIgYWNjZXNz LWxpc3RzIHsNCiAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgIlRoaXMgaXMgYSB0b3AgbGV2 ZWwgY29udGFpbmVyIGZvciBBY2Nlc3MgQ29udHJvbCBMaXN0cy4NCkBAIC01NzYsNiArNTgwLDkg QEAgbW9kdWxlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7DQogICAgICAgICB9DQogICAgICAg fQ0KICAgICB9DQorICB9DQorICB1c2VzIGFjY2Vzcy1saXN0cy10b3A7DQorDQogICBhdWdtZW50 ICIvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UiIHsNCiAgICAgZGVzY3JpcHRpb24NCiAgICAg ICAiQXVnbWVudCBpbnRlcmZhY2VzIHRvIGFsbG93IEFDTHMgdG8gYmUgYXNzb2NpYXRlZCBpbiBl aXRoZXIgdGhlDQoNCkNoZWVycywNCg0KRWluYXINCg0KDQpPbiA4IEphbiAyMDE4LCBhdCAxMDo1 MywgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb20+PiB3cm90ZToNCg0KSGkgVGhlcmUsDQoNCkkgYXBwcmVjaWF0ZSB0 aGF0IHRoaXMgaXMgbGF0ZSB0byB0aGUgdGFibGUsIGJ1dCBpcyBpdCBwb3NzaWJsZSB0byBzZXQg dXAg4oCcYWNjZXNzLWxpc3Rz4oCdIGFzIGEg4oCcZ3JvdXBpbmfigJ0gaW4gdGhlIFlBTkcgZGF0 YSBtb2RlbCBzbyB0aGF0IOKAnGFjY2Vzcy1saXN0c+KAnSBjYW4gYmUgaW5jbHVkZWQgYnkg4oCc dXNlc+KAnSBpbiBhIGhpZ2hlciBsZXZlbCBZQU5HIGRhdGEgbW9kZWw/DQoNCkkgaGF2ZSByYWlz ZWQgdGhpcyBhcyBpc3N1ZSAjMjIgYXQgaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wt bW9kZWwvaXNzdWVzDQoNClJlZ2FyZHMNCg0KSm9uDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KDQoNCg0K --_000_A6455D8AE85C411A8B115B15EA0D9AB9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BD2B440A0B80846B605FD677EDC723D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IDggSmFuIDIwMTgsIGF0IDE1OjMxLCBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZU IExJTUlURUQgYXQgQ2lzY28pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20i IGNsYXNzPSIiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgdGV4 dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iIj5IaSBF aW5hciwgSm9uLCBNYWhlc2gsPGJyIGNsYXNzPSIiPg0KPC9wPg0KPHAgY2xhc3M9IiI+TXkgZ3V0 IGluc3RpbmN0IGlzIHRoYXQgbWFraW5nIHRoaXMgYSBncm91cGluZyBtaWdodCBub3QgYmUgYSBn b29kIGlkZWE6PC9wPg0KPHAgY2xhc3M9IiI+MSkgSWYgc29tZWJvZHkgdXBkYXRlcyB0aGUgY29y ZSBBQ0wgbW9kZWwsIHdpbGwgdGhlbiBuZWVkIHRvIGNoZWNrIHRoYXQgYW55b25lIHVzaW5nIGl0 IHNob3VsZCBiZSBzaW1pbGFybHkgdXBkYXRlZCAodW5sZXNzIHRoZXkgdXNlIGltcG9ydC1ieS1y ZXZpc2lvbikuPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R3JvdXBpbmdz IGFuZCB0eXBlZGVmcyBhcmUgc3ViamVjdCB0byB0aGUgc2FtZSZuYnNwO2JhY2t3YXJkcy1jb21w YXRpYmlsaXR5IGNvbnN0cmFpbnRzIGFzIGFueSBvdGhlciBkYXRhLiBUaHVzIHVwZGF0ZXMgdG8g dGhlIG1vZGVsIHNob3VsZCBhbHdheXMgYmUgdHJvdWJsZS1mcmVlIGlmIHRoZSB1cGRhdGVzIGNv bmZvcm0gdG8gUkZDIDYwMjAvNzk1MCZuYnNwO2JhY2t3YXJkcy1jb21wYXRpYmlsaXR5IHJ1bGVz IGZvciBtb2RlbCB1cGRhdGVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiIGNs YXNzPSIiPg0KPHAgY2xhc3M9IiI+MikgRG9lcyBpdCBtYWtlIHNlbnNlIHRvIGRlZmluZSBBQ0xz IGluIHNlcGFyYXRlIHBsYWNlcy4mbmJzcDsgV291bGQgbGlrZSBiZSBtb3JlIHNpbXBsZSBpZiBB Q0xzIHdlcmUgZGVmaW5lZCBpbiBhIGNlbnRyYWwgcGxhY2UgYW5kIHRoZW4ganVzdCByZWZlcmVu Y2VkIGJ5IG90aGVyIHByb3RvY29scyBhcyByZXF1aXJlZC48YnIgY2xhc3M9IiI+DQo8L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Sm9uIGNsZWFybHkgaGFzIGEgY2FzZSBoZSBpcyB0aGlua2luZyBhYm91dCwgYW5kIG1h a2luZyBhbiBhY2Nlc3MgbGlzdCBjb250YWluZXIgcmV1c2FibGUgZG9lc27igJl0IHNlZW0gbGlr ZSBhbiBpbnRyaW5zaWNhbGx5IGJhZCBpZGVhIHRvIG1lLiBXaGF0IG1heSBiZSBhbiBpcnJpdGF0 aW5nIHRoaW5nIGlzIGlmIHRoZXJlIGFyZSAmZ3Q7MSB1c2UgY2FzZSBmb3IgdGhpcyBhbmQgZWFj aCB1c2UgY2FzZSBpcyBpbiBlZmZlY3QgcmVxdWlyZWQgdG8NCiBkZWZpbmUgaXTigJlzIG93biBp ZGVhIG9mIGEgbGlzdCBvZiBhY2Nlc3MgbGlzdCBkZWZpbml0aW9ucy48L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+DQo8cCBjbGFz cz0iIj48L3A+DQozKSBJIHRoaW5rIHRoYXQgZ3JvdXBpbmdzIGFyZSBwcm9iYWJseSBvdmVydXNl ZCBhbmQgSSB0aGluayB0aGF0IHRoZXkgY2FuIGRldHJhY3QgZnJvbSB0aGUgcmVhZGFiaWxpdHkg b2YgdGhlIG1vZGVsLiZuYnNwOyAoSSByZWdhcmQgdGhlIE9wZW5Db25maWcgWUFORyBtb2RlbHMg YXMgYW4gZXh0cmVtZSBleGFtcGxlIG9mIHRoaXMsIHdoZXJlIGl0IGlzIG5lY2Vzc2FyeSB0byBj b21waWxlIHRoZSBtb2R1bGVzIHRvZ2V0aGVyIHRvIGZpZ3VyZSBvdXQgd2hlcmUNCiBldmVyeXRo aW5nIGZpdHMgdG9nZXRoZXIpLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZG RkZGIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiB0ZXh0PSIj MDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj5J4oCZbSBub3QgZ29pbmcgdG8gZGlz YWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzIG9uIHRoZSBvdmVydXNlIG9mIGdyb3VwaW5ncy4gV2Ug Y291bGQgYWxzbyByZWZlciB0byBDaXNjbyBJT1MtWFIgbmF0aXZlIG1vZGVscywgd2hlcmUgd2Ug aGF2ZSBzb21lIG1vZGVscyB3aXRoIDggbGV2ZWxzIChwZXJoYXBzIG1vcmU/KSBvZiBuZXN0ZWQg Z3JvdXBpbmdzIDstKTwvZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZG IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0i I0ZGRkZGRiIgY2xhc3M9IiI+SGF2aW5nIHNhaWQgdGhhdCwgSSBkb24ndCB0aGluayB0aGF0IHRo aXMgaXNzdWUgaXMgaW1wb3J0YW50IGVub3VnaCB0byBoYXZlIGEgbG9uZyBkaXNjdXNzaW9uIGFi b3V0IC4uLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2Nv bG9yPSIjRkZGRkZGIiBjbGFzcz0iIj5MaWtld2lzZS4gSSBoYXZlIG5vIG9iamVjdGlvbiB0byB0 aGlzIGNoYW5nZSwgYnV0IG5vIHN0cm9uZyB2ZXN0ZWQgaW50ZXJlc3QgZWl0aGVyLiBXaGF0IEni gJltIG1vc3QgaW50ZXJlc3RlZCBpbiBpcyBnZXR0aW5nIHRvIGFuIGFncmVlZCBtb2RlbCBhdCB0 aGlzIHBvaW50LCBhbmQgdGhpcyBjaGFuZ2Ugd291bGRu4oCZdCBpbXBhY3QgdGhhdCBhcyBpdCBk b2VzbuKAmXQgY2hhbmdlDQogdGhlIGFjdHVhbCBtb2RlbC48L2Rpdj4NCjxkaXYgdGV4dD0iIzAw MDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPkpvbiDigJQgY291 bGQgeW91IHBlcmhhcHMgYXJ0aWN1bGF0ZSB5b3VyIHVzZSBjYXNlKHMpPyBBbmQgcGVyaGFwcyB1 cGRhdGUmbmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2Rl bC9pc3N1ZXMiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVs L2lzc3VlczwvYT4gd2l0aCB0aGVtPzwvZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9y PSIjRkZGRkZGIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgdGV4dD0iIzAw MDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJn Y29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgdGV4dD0iIzAwMDAw MCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHRleHQ9IiMw MDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0 ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj5UaGFua3MsPGJyIGNsYXNz PSIiPg0KUm9iPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAwOC8wMS8yMDE4IDE1OjAyLCBFaW5hciBOaWxz ZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6QjA1NzZCNjItQ0I2MS00NUVBLTk5RUYtRTVCNjc1 NDVCODVDQGNpc2NvLmNvbSIgY2xhc3M9IiI+DQpTaW5jZSB0aGlzIGlzIGEgNy1saW5lIGNoYW5n ZSwgSSBzZWUgbm8gaGFybSBpbiBpdCBpZiBuby1vbmUgb2JqZWN0cz8gTWFoZXNoIGhhcyB0aGUg dG9rZW4gZm9yIHJvbGxpbmcgaW4gdXBkYXRlcyBkaXNjdXNzZWQganVzdCBwcmlvciB0byB0aGUg ZW5kIG9mIDIwMTcuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5IZXJl4oCZcyBhIHBvc3NpYmxlIGRpZmY6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIi PiQgZ2l0IGRpZmYgLWI8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xh c3M9IiI+ZGlmZiAtLWdpdCBhL3NyYy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5n IGIvc3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+aW5kZXggNGQ2OThjOS4uYjFhMTczZiAx MDA2NDQ8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+LS0t IGEvc3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+JiM0MzsmIzQzOyYjNDM7IGIvc3JjL3lh bmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+QEAgLTQwMiw2ICYjNDM7NDAyLDEwIEBAIG1vZHVsZSBp ZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Qgezwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7Lyo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAqIENvbmZpZ3VyYXRpb24gZGF0 YSBub2Rlczwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICovPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNs YXNzPSIiPiYjNDM7ICZuYnNwO2dyb3VwaW5nIGFjY2Vzcy1saXN0cy10b3Agezwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mIzQzOyAmbmJzcDsgJm5ic3A7 ZGVzY3JpcHRpb248L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9 IiI+JiM0MzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtHcm91cGluZyB0byBhbGxvdyByZXVz ZSBvZiBhY2Nlc3MgbGlzdHMgY29udGFpbmVyIGVsc2V3aGVyZS4mcXVvdDs7PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiYjNDM7PC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y29u dGFpbmVyIGFjY2Vzcy1saXN0cyB7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw eDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9uPC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtUaGlzIGlzIGEgdG9wIGxldmVsIGNvbnRhaW5lciBm b3IgQWNjZXNzIENvbnRyb2wgTGlzdHMuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFweDsiIGNsYXNzPSIiPkBAIC01NzYsNiAmIzQzOzU4MCw5IEBAIG1vZHVsZSBpZXRmLWFjY2Vz cy1jb250cm9sLWxpc3Qgezwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBj bGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt9PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIg ZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7 IiBjbGFzcz0iIj4mIzQzOyAmbmJzcDt9PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFweDsiIGNsYXNzPSIiPiYjNDM7ICZuYnNwO3VzZXMgYWNjZXNzLWxpc3RzLXRvcDs8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+JiM0Mzs8L3NwYW4+PC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2F1Z21l bnQgJnF1b3Q7L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlJnF1b3Q7IHs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtk ZXNjcmlwdGlvbjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtBdWdtZW50IGludGVyZmFjZXMgdG8g YWxsb3cgQUNMcyB0byBiZSBhc3NvY2lhdGVkIGluIGVpdGhlciB0aGU8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gOCBKYW4gMjAxOCwgYXQg MTA6NTMsIEpvbiBTaGFsbG93ICZsdDs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFs bG93LmNvbSIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5zdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIg c3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsNCiAgICAgICAgICAgICAgICAgICAgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOg0KICAgICAgICAgICAg ICAgICAgICBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0Og0K ICAgICAgICAgICAgICAgICAgICBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0Ow0KICAgICAgICAgICAgICAgICAgICB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6DQogICAgICAgICAgICAgICAgICAgIG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgICAgICAgIC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6DQogICAgICAgICAgICAgICAgICAgICAgMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkhpIFRoZXJlLDxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZToNCiAgICAgICAgICAgICAgICAgICAgICAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgICAg ICAgICAgICAgICAgIDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQpJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIGlzIGxhdGUgdG8gdGhlIHRhYmxlLCBidXQg aXMgaXQgcG9zc2libGUgdG8gc2V0IHVwIOKAnGFjY2Vzcy1saXN0c+KAnSBhcyBhIOKAnGdyb3Vw aW5n4oCdIGluIHRoZSBZQU5HIGRhdGEgbW9kZWwgc28gdGhhdCDigJxhY2Nlc3MtbGlzdHPigJ0g Y2FuIGJlIGluY2x1ZGVkIGJ5IOKAnHVzZXPigJ0gaW4gYSBoaWdoZXIgbGV2ZWwgWUFORyBkYXRh IG1vZGVsPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgICAgICAgICAgICAgICAgICAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAgICAgIDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJIGhhdmUgcmFpc2VkIHRoaXMgYXMgaXNz dWUgIzIyIGF0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL2lzc3VlcyIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjoNCiAgICAgICAgICAgICAgICAg ICAgICAgIHVuZGVybGluZTsiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6 Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvaXNzdWVzPC9hPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZToNCiAgICAgICAgICAgICAgICAgICAgICAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAg ICAgICAgICAgICAgICAgIDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpSZWdhcmRzPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAg ICAgIDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICAgICAgICAgICAgICAgICAgMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkpvbjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7DQogICAgICAgICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsNCiAgICAgICAgICAgICAg ICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt Og0KICAgICAgICAgICAgICAgICAgICBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDogbm9uZTsNCiAgICAgICAgICAgICAgICAgICAgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsNCiAgICAgICAgICAgICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06DQogICAg ICAgICAgICAgICAgICAgIG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4Ow0KICAgICAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7DQogICAgICAgICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOg0KICAgICAgICAg ICAgICAgICAgICBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsN CiAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsNCiAgICAgICAgICAgICAgICAgICAgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5uZXRtb2QNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOw0KICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7DQogICAgICAgICAgICAgICAgICAg IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZToNCiAg ICAgICAgICAgICAgICAgICAgbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAg ICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBo cmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsNCiAgICAg ICAgICAgICAgICAgICAgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7DQogICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOg0KICAgICAgICAgICAgICAgICAg ICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICAg ICAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOg0KICAgICAgICAgICAgICAgICAgICAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsNCiAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7DQogICAgICAg ICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsNCiAgICAgICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOg0KICAgICAgICAgICAgICAgICAgICBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAg ICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOw0KICAgICAgICAgICAgICAgICAg ICBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6DQog ICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6DQogICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOg0KICAgICAgICAgICAgICAgICAg ICBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87DQogICAgICAgICAgICAg ICAgICAgIHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 DQogICAgICAgICAgICAgICAgICAgIC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxmaWVsZHNl dCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+IDxiciBjbGFzcz0iIj4N CjxwcmUgd3JhcD0iIiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGlu ay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYu b3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A6455D8AE85C411A8B115B15EA0D9AB9ciscocom_-- From nobody Mon Jan 8 07:59:52 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 D4018129966 for ; Mon, 8 Jan 2018 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 3v_fkW7Jqf4a for ; Mon, 8 Jan 2018 07:59:48 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFABD126579 for ; Mon, 8 Jan 2018 07:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29089; q=dns/txt; s=iport; t=1515427187; x=1516636787; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3+/aH2H1jBIN7oC8XmJ4iP2pnYoh23w7cL9NwP5I3i0=; b=jqyekcYgFV4orAyDqBE79uTXpLapg6lxHusAq2tIa7xJuKDqaknMkE8N 9tZW1pzGWvUedjITT0gOGtFGpd8fZ355hz3acBRZDrk+I9EpRctCjczGd ZfSRvlqFBcs0X+EVvO2RiNIwpItpp+Cyo5cQNtwUwdm0IE5u3+hRTgX6R 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvBQAalFNa/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdWZ0JweEAJh9ggKJCI4ighUKGAEKhANGTwIahBxBFgEBAQE?= =?us-ascii?q?BAQEBAWsohSMBAQEBAwEBIQpBGwIBCA4DAwEBASEHAwICAh8GCxQJCAEBBAESi?= =?us-ascii?q?U1MAxUQsF+CJyaDcQGDGw2CcAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhjWGbYJ?= =?us-ascii?q?rRAGBRz4JFoJhgmUFkiWHSokyPQKIBYg3hQCUCY0zP4h4AhEZAYE7ASYBMYFQb?= =?us-ascii?q?xU9giqCVByBLAE6eAGII4E0gRcBAQE?= X-IronPort-AV: E=Sophos; i="5.46,330,1511827200"; d="scan'208,217"; a="53239822" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 15:59:47 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w08Fxkss019255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jan 2018 15:59:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 8 Jan 2018 10:59:45 -0500 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; Mon, 8 Jan 2018 10:59:45 -0500 From: "Acee Lindem (acee)" To: Jon Shallow , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" , "Einar Nilsen-Nygaard (einarnn)" , "'Mahesh Jethanandani'" Thread-Topic: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" Thread-Index: AdOIbvlU0QBjg+SHRESC+Oh6XUPoRwATLimAAAD9eAAAAIzRgP//r6qA Date: Mon, 8 Jan 2018 15:59:45 +0000 Message-ID: References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> <022401d38897$f2aa1b70$d7fe5250$@jpshallow.com> In-Reply-To: <022401d38897$f2aa1b70$d7fe5250$@jpshallow.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.198] Content-Type: multipart/alternative; boundary="_000_D678FF01E8C2Aaceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:59:51 -0000 --_000_D678FF01E8C2Aaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKb24gU2hhbGxvdyA8c3VwanBz LWlldGZAanBzaGFsbG93LmNvbTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+DQpE YXRlOiBNb25kYXksIEphbnVhcnkgOCwgMjAxOCBhdCAxMDo0NyBBTQ0KVG86ICJSb2JlcnQgV2ls dG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIiA8cndpbHRvbkBjaXNj by5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4sICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4+LCAiRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIiA8ZWluYXJubkBjaXNjby5jb208 bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4sICdNYWhlc2ggSmV0aGFuYW5kYW5pJyA8bWpldGhh bmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4NClN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBOZXRtb2QgQUNMIC0gQ2FuICJhY2Nlc3MtbGlzdHMiIGJlIHNldCB1 cCBhcyBhICJncm91cGluZyINCg0KSGkgUm9iZXJ0LA0KDQpBIGdvb2Qgc2V0IG9mIHBvaW50cy4N Cg0KTXkgcGFydGljdWxhciB1c2UgY2FzZSAoaGVuY2UgcmFpc2luZyB0aGUgcXVlc3Rpb24pIGlz IGRlZmluaW5nIGEgWUFORyBtb2RlbCB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgYXBwbGlhbmNl cyBhbmQgd2hlcmUgQUNMcyBhcmUgZGVmaW5lZCBmb3IgZWFjaCBhcHBsaWFuY2UsIGJ1dCB0aGVy ZSBpcyB0aGUgbGlrZWxpaG9vZCBvZiB0aGUgZGlmZmVyZW50IGFwcGxpYW5jZXMgdXNpbmcgdGhl IHNhbWUg4oCcYWNsLW5hbWXigJ0sIGJ1dCB0aGUgY29udGVudHMgb2Yg4oCcYWNsLW5hbWXigJ0g YXJlIGRpZmZlcmVudC4gIEhhdmluZyBhIGdyb3VwaW5nICh1c2luZyBpbXBvcnQtYnktcmV2aXNp b24pIHdvdWxkIGhlbHAgbWUgY29uc2lkZXJhYmx5IGhlcmUuDQoNCkkgZ3Vlc3MgSSBkb27igJl0 IHNlZSB0aGUgdXNlIGNhc2UuIFdvdWxkbuKAmXQgeW91IGhhdmUgbXVsdGlwbGUgbmV0d29yayBk ZXZpY2VzIGZvciBtdWx0aXBsZSBuZXR3b3JrIGRldmljZXM/IE9yIGF0IGxlYXN0IHNlcGFyYXRl IExORXM/ICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXJ0Z3dnLWxuZS1tb2Rl bC0wNS50eHQNCg0KVGhhbmtzLA0KQWNlZQ0KDQpSZWdhcmRzDQoNCkpvbg0KDQpGcm9tOiBSb2Jl cnQgV2lsdG9uIFttYWlsdG86IHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2Nv LmNvbT5dDQpTZW50OiAwOCBKYW51YXJ5IDIwMTggMTU6MzENClRvOiBFaW5hciBOaWxzZW4tTnln YWFyZCAoZWluYXJubik7IEpvbiBTaGFsbG93OyBNYWhlc2ggSmV0aGFuYW5kYW5pDQpDYzogbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1v ZF0gTmV0bW9kIEFDTCAtIENhbiAiYWNjZXNzLWxpc3RzIiBiZSBzZXQgdXAgYXMgYSAiZ3JvdXBp bmciDQoNCg0KSGkgRWluYXIsIEpvbiwgTWFoZXNoLA0KDQpNeSBndXQgaW5zdGluY3QgaXMgdGhh dCBtYWtpbmcgdGhpcyBhIGdyb3VwaW5nIG1pZ2h0IG5vdCBiZSBhIGdvb2QgaWRlYToNCg0KMSkg SWYgc29tZWJvZHkgdXBkYXRlcyB0aGUgY29yZSBBQ0wgbW9kZWwsIHdpbGwgdGhlbiBuZWVkIHRv IGNoZWNrIHRoYXQgYW55b25lIHVzaW5nIGl0IHNob3VsZCBiZSBzaW1pbGFybHkgdXBkYXRlZCAo dW5sZXNzIHRoZXkgdXNlIGltcG9ydC1ieS1yZXZpc2lvbikuDQoNCjIpIERvZXMgaXQgbWFrZSBz ZW5zZSB0byBkZWZpbmUgQUNMcyBpbiBzZXBhcmF0ZSBwbGFjZXMuICBXb3VsZCBsaWtlIGJlIG1v cmUgc2ltcGxlIGlmIEFDTHMgd2VyZSBkZWZpbmVkIGluIGEgY2VudHJhbCBwbGFjZSBhbmQgdGhl biBqdXN0IHJlZmVyZW5jZWQgYnkgb3RoZXIgcHJvdG9jb2xzIGFzIHJlcXVpcmVkLg0KMykgSSB0 aGluayB0aGF0IGdyb3VwaW5ncyBhcmUgcHJvYmFibHkgb3ZlcnVzZWQgYW5kIEkgdGhpbmsgdGhh dCB0aGV5IGNhbiBkZXRyYWN0IGZyb20gdGhlIHJlYWRhYmlsaXR5IG9mIHRoZSBtb2RlbC4gIChJ IHJlZ2FyZCB0aGUgT3BlbkNvbmZpZyBZQU5HIG1vZGVscyBhcyBhbiBleHRyZW1lIGV4YW1wbGUg b2YgdGhpcywgd2hlcmUgaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbXBpbGUgdGhlIG1vZHVsZXMgdG9n ZXRoZXIgdG8gZmlndXJlIG91dCB3aGVyZSBldmVyeXRoaW5nIGZpdHMgdG9nZXRoZXIpLg0KDQpI YXZpbmcgc2FpZCB0aGF0LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpc3N1ZSBpcyBpbXBvcnRh bnQgZW5vdWdoIHRvIGhhdmUgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgLi4uDQoNClRoYW5rcywN ClJvYg0KDQpPbiAwOC8wMS8yMDE4IDE1OjAyLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJu bikgd3JvdGU6DQpTaW5jZSB0aGlzIGlzIGEgNy1saW5lIGNoYW5nZSwgSSBzZWUgbm8gaGFybSBp biBpdCBpZiBuby1vbmUgb2JqZWN0cz8gTWFoZXNoIGhhcyB0aGUgdG9rZW4gZm9yIHJvbGxpbmcg aW4gdXBkYXRlcyBkaXNjdXNzZWQganVzdCBwcmlvciB0byB0aGUgZW5kIG9mIDIwMTcuDQoNCkhl cmXigJlzIGEgcG9zc2libGUgZGlmZjoNCg0KJCBnaXQgZGlmZiAtYg0KZGlmZiAtLWdpdCBhL3Ny Yy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nIGIvc3JjL3lhbmcvaWV0Zi1hY2Nl c3MtY29udHJvbC1saXN0LnlhbmcNCmluZGV4IDRkNjk4YzkuLmIxYTE3M2YgMTAwNjQ0DQotLS0g YS9zcmMveWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZw0KKysrIGIvc3JjL3lhbmcv aWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCkBAIC00MDIsNiArNDAyLDEwIEBAIG1vZHVs ZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Qgew0KICAgLyoNCiAgICAqIENvbmZpZ3VyYXRpb24g ZGF0YSBub2Rlcw0KICAgICovDQorICBncm91cGluZyBhY2Nlc3MtbGlzdHMtdG9wIHsNCisgICAg ZGVzY3JpcHRpb24NCisgICAgICAiR3JvdXBpbmcgdG8gYWxsb3cgcmV1c2Ugb2YgYWNjZXNzIGxp c3RzIGNvbnRhaW5lciBlbHNld2hlcmUuIjsNCisNCiAgICAgY29udGFpbmVyIGFjY2Vzcy1saXN0 cyB7DQogICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICJUaGlzIGlzIGEgdG9wIGxldmVsIGNv bnRhaW5lciBmb3IgQWNjZXNzIENvbnRyb2wgTGlzdHMuDQpAQCAtNTc2LDYgKzU4MCw5IEBAIG1v ZHVsZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Qgew0KICAgICAgICAgfQ0KICAgICAgIH0NCiAg ICAgfQ0KKyAgfQ0KKyAgdXNlcyBhY2Nlc3MtbGlzdHMtdG9wOw0KKw0KICAgYXVnbWVudCAiL2lm OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlIiB7DQogICAgIGRlc2NyaXB0aW9uDQogICAgICAgIkF1 Z21lbnQgaW50ZXJmYWNlcyB0byBhbGxvdyBBQ0xzIHRvIGJlIGFzc29jaWF0ZWQgaW4gZWl0aGVy IHRoZQ0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KDQpPbiA4IEphbiAyMDE4LCBhdCAxMDo1Mywg Sm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20+PiB3cm90ZToNCg0KSGkgVGhlcmUsDQoNCkkgYXBwcmVjaWF0ZSB0aGF0 IHRoaXMgaXMgbGF0ZSB0byB0aGUgdGFibGUsIGJ1dCBpcyBpdCBwb3NzaWJsZSB0byBzZXQgdXAg 4oCcYWNjZXNzLWxpc3Rz4oCdIGFzIGEg4oCcZ3JvdXBpbmfigJ0gaW4gdGhlIFlBTkcgZGF0YSBt b2RlbCBzbyB0aGF0IOKAnGFjY2Vzcy1saXN0c+KAnSBjYW4gYmUgaW5jbHVkZWQgYnkg4oCcdXNl c+KAnSBpbiBhIGhpZ2hlciBsZXZlbCBZQU5HIGRhdGEgbW9kZWw/DQoNCkkgaGF2ZSByYWlzZWQg dGhpcyBhcyBpc3N1ZSAjMjIgYXQgaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9k ZWwvaXNzdWVzDQoNClJlZ2FyZHMNCg0KSm9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQoNCg== --_000_D678FF01E8C2Aaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBKb24sJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBK YW51YXJ5IDgsIDIwMTggYXQgMTA6NDcgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZU IExJTUlURUQgYXQgQ2lzY28pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj by5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90O0Vp bmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVp bmFybm5AY2lzY28uY29tIj5laW5hcm5uQGNpc2NvLmNvbTwvYT4mZ3Q7LCAnTWFoZXNoIEpldGhh bmFuZGFuaScgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpl dGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIE5ldG1vZCBBQ0wgLSBDYW4gJnF1 b3Q7YWNjZXNzLWxpc3RzJnF1b3Q7IGJlIHNldCB1cCBhcyBhICZxdW90O2dyb3VwaW5nJnF1b3Q7 PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1 IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2Zm aWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAi Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmls dGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0x OjIgNyA0IDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglj b2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5IaSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+QSBnb29kIHNldCBvZiBwb2ludHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+TXkgcGFydGljdWxhciB1c2UgY2FzZSAoaGVuY2UgcmFpc2lu ZyB0aGUgcXVlc3Rpb24pIGlzIGRlZmluaW5nIGEgWUFORyBtb2RlbCB3aGVyZSB0aGVyZSBhcmUg bXVsdGlwbGUgYXBwbGlhbmNlcyBhbmQgd2hlcmUgQUNMcyBhcmUgZGVmaW5lZCBmb3IgZWFjaA0K IGFwcGxpYW5jZSwgYnV0IHRoZXJlIGlzIHRoZSBsaWtlbGlob29kIG9mIHRoZSBkaWZmZXJlbnQg YXBwbGlhbmNlcyB1c2luZyB0aGUgc2FtZSDigJxhY2wtbmFtZeKAnSwgYnV0IHRoZSBjb250ZW50 cyBvZiDigJxhY2wtbmFtZeKAnSBhcmUgZGlmZmVyZW50LiZuYnNwOyBIYXZpbmcgYSBncm91cGlu ZyAodXNpbmcgaW1wb3J0LWJ5LXJldmlzaW9uKSB3b3VsZCBoZWxwIG1lIGNvbnNpZGVyYWJseSBo ZXJlLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGd1ZXNzIEkgZG9u4oCZdCBzZWUgdGhl IHVzZSBjYXNlLiBXb3VsZG7igJl0IHlvdSBoYXZlIG11bHRpcGxlIG5ldHdvcmsgZGV2aWNlcyBm b3IgbXVsdGlwbGUgbmV0d29yayBkZXZpY2VzPyBPciBhdCBsZWFzdCBzZXBhcmF0ZSBMTkVzPyAm bmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXJ0Z3dnLWxuZS1tb2RlbC0w NS50eHQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+ QWNlZSZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1h cy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3Lncz Lm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5SZWdhcmRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Sm9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlm OyBjb2xvcjogd2luZG93dGV4dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsg Y29sb3I6IHdpbmRvd3RleHQ7Ij4gUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOg0KPGEgaHJlZj0ibWFp bHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT5dIDxicj4NCjxiPlNl bnQ6PC9iPiAwOCBKYW51YXJ5IDIwMTggMTU6MzE8YnI+DQo8Yj5Ubzo8L2I+IEVpbmFyIE5pbHNl bi1OeWdhYXJkIChlaW5hcm5uKTsgSm9uIFNoYWxsb3c7IE1haGVzaCBKZXRoYW5hbmRhbmk8YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIE5ldG1vZCBBQ0wgLSBD YW4gJnF1b3Q7YWNjZXNzLWxpc3RzJnF1b3Q7IGJlIHNldCB1cCBhcyBhICZxdW90O2dyb3VwaW5n JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgRWluYXIsIEpvbiwgTWFoZXNo LDxvOnA+PC9vOnA+PC9wPg0KPHA+TXkgZ3V0IGluc3RpbmN0IGlzIHRoYXQgbWFraW5nIHRoaXMg YSBncm91cGluZyBtaWdodCBub3QgYmUgYSBnb29kIGlkZWE6PG86cD48L286cD48L3A+DQo8cD4x KSBJZiBzb21lYm9keSB1cGRhdGVzIHRoZSBjb3JlIEFDTCBtb2RlbCwgd2lsbCB0aGVuIG5lZWQg dG8gY2hlY2sgdGhhdCBhbnlvbmUgdXNpbmcgaXQgc2hvdWxkIGJlIHNpbWlsYXJseSB1cGRhdGVk ICh1bmxlc3MgdGhleSB1c2UgaW1wb3J0LWJ5LXJldmlzaW9uKS48bzpwPjwvbzpwPjwvcD4NCjxw PjIpIERvZXMgaXQgbWFrZSBzZW5zZSB0byBkZWZpbmUgQUNMcyBpbiBzZXBhcmF0ZSBwbGFjZXMu Jm5ic3A7IFdvdWxkIGxpa2UgYmUgbW9yZSBzaW1wbGUgaWYgQUNMcyB3ZXJlIGRlZmluZWQgaW4g YSBjZW50cmFsIHBsYWNlIGFuZCB0aGVuIGp1c3QgcmVmZXJlbmNlZCBieSBvdGhlciBwcm90b2Nv bHMgYXMgcmVxdWlyZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjMpIEkgdGhpbmsgdGhhdCBncm91cGluZ3MgYXJlIHBy b2JhYmx5IG92ZXJ1c2VkIGFuZCBJIHRoaW5rIHRoYXQgdGhleSBjYW4gZGV0cmFjdCBmcm9tIHRo ZSByZWFkYWJpbGl0eSBvZiB0aGUgbW9kZWwuJm5ic3A7IChJIHJlZ2FyZCB0aGUgT3BlbkNvbmZp ZyBZQU5HIG1vZGVscyBhcyBhbiBleHRyZW1lIGV4YW1wbGUgb2YgdGhpcywgd2hlcmUgaXQgaXMg bmVjZXNzYXJ5DQogdG8gY29tcGlsZSB0aGUgbW9kdWxlcyB0b2dldGhlciB0byBmaWd1cmUgb3V0 IHdoZXJlIGV2ZXJ5dGhpbmcgZml0cyB0b2dldGhlcikuPGJyPg0KPGJyPg0KSGF2aW5nIHNhaWQg dGhhdCwgSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXNzdWUgaXMgaW1wb3J0YW50IGVub3VnaCB0 byBoYXZlIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IC4uLjxicj4NCjxicj4NClRoYW5rcyw8YnI+ DQpSb2I8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAwOC8wMS8yMDE4IDE1OjAyLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2lu Y2UgdGhpcyBpcyBhIDctbGluZSBjaGFuZ2UsIEkgc2VlIG5vIGhhcm0gaW4gaXQgaWYgbm8tb25l IG9iamVjdHM/IE1haGVzaCBoYXMgdGhlIHRva2VuIGZvciByb2xsaW5nIGluIHVwZGF0ZXMgZGlz Y3Vzc2VkIGp1c3QgcHJpb3IgdG8gdGhlIGVuZCBvZiAyMDE3Lg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJl4oCZcyBhIHBvc3NpYmxlIGRpZmY6IDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+JCBnaXQgZGlmZiAt Yjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+ZGlm ZiAtLWdpdCBhL3NyYy95YW5nL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nIGIvc3JjL3lh bmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmluZGV4IDRkNjk4YzkuLmIxYTE3M2YgMTAwNjQ0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb3VyaWVyIj4tLS0g YS9zcmMveWFuZy9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+JiM0MzsmIzQzOyYjNDM7IGIvc3Jj L3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkBAIC00MDIsNiAmIzQzOzQwMiwxMCBAQCBt b2R1bGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsvKjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAqIENv bmZpZ3VyYXRpb24gZGF0YSBub2Rlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAqLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+JiM0MzsgJm5ic3A7Z3JvdXBpbmcgYWNjZXNz LWxpc3RzLXRvcCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpD b3VyaWVyIj4mIzQzOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiYjNDM7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JnF1b3Q7R3JvdXBpbmcgdG8gYWxsb3cgcmV1c2Ugb2YgYWNjZXNzIGxpc3RzIGNvbnRhaW5l ciBlbHNld2hlcmUuJnF1b3Q7Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6Q291cmllciI+JiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udGFpbmVyIGFjY2Vzcy1saXN0 cyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZxdW90O1RoaXMgaXMgYSB0b3AgbGV2ZWwgY29udGFpbmVyIGZvciBBY2Nlc3Mg Q29udHJvbCBMaXN0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXIiPkBAIC01NzYsNiAmIzQzOzU4MCw5IEBAIG1vZHVsZSBpZXRmLWFjY2Vzcy1jb250 cm9sLWxpc3Qgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291 cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6Q291cmllciI+JiM0MzsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+JiM0MzsgJm5ic3A7dXNlcyBhY2Nlc3MtbGlz dHMtdG9wOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q291cmll ciI+JiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDthdWdtZW50ICZxdW90Oy9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFj ZSZxdW90OyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmcXVvdDtBdWdtZW50IGludGVyZmFjZXMgdG8gYWxsb3cgQUNMcyB0byBiZSBhc3NvY2lhdGVk IGluIGVpdGhlciB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVpbmFyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDggSmFuIDIwMTgsIGF0IDEwOjUz LCBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SGkgVGhlcmUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPkkgYXBwcmVjaWF0ZSB0aGF0IHRoaXMgaXMgbGF0ZSB0byB0 aGUgdGFibGUsIGJ1dCBpcyBpdCBwb3NzaWJsZSB0byBzZXQgdXAg4oCcYWNjZXNzLWxpc3Rz4oCd IGFzIGEg4oCcZ3JvdXBpbmfigJ0gaW4gdGhlIFlBTkcgZGF0YSBtb2RlbCBzbyB0aGF0IOKAnGFj Y2Vzcy1saXN0c+KAnSBjYW4gYmUgaW5jbHVkZWQgYnkg4oCcdXNlc+KAnQ0KIGluIGEgaGlnaGVy IGxldmVsIFlBTkcgZGF0YSBtb2RlbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SSBoYXZl IHJhaXNlZCB0aGlzIGFzIGlzc3VlICMyMiBhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdn L2FjbC1tb2RlbC9pc3N1ZXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZ2l0 aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL2lzc3Vlczwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Sm9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5l dG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBjb2xvcjogcHVycGxlOyI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6IHB1cnBsZTsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5ldG1vZCBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bmV0bW9kQGll dGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D678FF01E8C2Aaceeciscocom_-- From nobody Mon Jan 8 08:46: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 4B900124217 for ; Mon, 8 Jan 2018 08:46:25 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JvUa9sKGSyey for ; Mon, 8 Jan 2018 08:46:23 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEB771241F5 for ; Mon, 8 Jan 2018 08:46:22 -0800 (PST) Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id A7CE91AE0332; Mon, 8 Jan 2018 17:46:21 +0100 (CET) Date: Mon, 08 Jan 2018 17:46:21 +0100 (CET) Message-Id: <20180108.174621.261235771307695730.mbj@tail-f.com> To: acee@cisco.com Cc: supjps-ietf@jpshallow.com, rwilton@cisco.com, netmod@ietf.org, einarnn@cisco.com, mjethanandani@gmail.com From: Martin Bjorklund In-Reply-To: References: <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> <022401d38897$f2aa1b70$d7fe5250$@jpshallow.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:46:25 -0000 IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gSGkgSm9uLA0K PiANCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiBvbiBiZWhhbGYgb2YgSm9uIFNoYWxsb3cNCj4gPHN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+Pg0K PiBEYXRlOiBNb25kYXksIEphbnVhcnkgOCwgMjAxOCBhdCAxMDo0NyBBTQ0KPiBUbzogIlJvYmVy dCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykiDQo+IDxyd2ls dG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiwNCj4gIm5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiINCj4gPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPj4sICJFaW5hciBOaWxzZW4tTnlnYWFyZA0KPiAoZWluYXJubikiIDxl aW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+PiwgJ01haGVzaA0KPiBK ZXRoYW5hbmRhbmknDQo+IDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20+Pg0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gTmV0bW9kIEFDTCAtIENh biAiYWNjZXNzLWxpc3RzIiBiZSBzZXQgdXAgYXMgYQ0KPiAiZ3JvdXBpbmciDQo+IA0KPiBIaSBS b2JlcnQsDQo+IA0KPiBBIGdvb2Qgc2V0IG9mIHBvaW50cy4NCj4gDQo+IE15IHBhcnRpY3VsYXIg dXNlIGNhc2UgKGhlbmNlIHJhaXNpbmcgdGhlIHF1ZXN0aW9uKSBpcyBkZWZpbmluZyBhIFlBTkcN Cj4gbW9kZWwgd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIGFwcGxpYW5jZXMgYW5kIHdoZXJlIEFD THMgYXJlIGRlZmluZWQNCj4gZm9yIGVhY2ggYXBwbGlhbmNlLCBidXQgdGhlcmUgaXMgdGhlIGxp a2VsaWhvb2Qgb2YgdGhlIGRpZmZlcmVudA0KPiBhcHBsaWFuY2VzIHVzaW5nIHRoZSBzYW1lIOKA nGFjbC1uYW1l4oCdLCBidXQgdGhlIGNvbnRlbnRzIG9mIOKAnGFjbC1uYW1l4oCdDQo+IGFyZSBk aWZmZXJlbnQuICBIYXZpbmcgYSBncm91cGluZyAodXNpbmcgaW1wb3J0LWJ5LXJldmlzaW9uKSB3 b3VsZA0KPiBoZWxwIG1lIGNvbnNpZGVyYWJseSBoZXJlLg0KPiANCj4gSSBndWVzcyBJIGRvbuKA mXQgc2VlIHRoZSB1c2UgY2FzZS4gV291bGRu4oCZdCB5b3UgaGF2ZSBtdWx0aXBsZSBuZXR3b3Jr DQo+IGRldmljZXMgZm9yIG11bHRpcGxlIG5ldHdvcmsgZGV2aWNlcz8gT3IgYXQgbGVhc3Qgc2Vw YXJhdGUgTE5Fcz8NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1ydGd3Zy1s bmUtbW9kZWwtMDUudHh0DQoNClJpZ2h0LiAgSWYgYSBncm91cGluZyBpcyByZXF1aXJlZCBmb3Ig YWNscyBmb3IgdGhpcyB1c2UgY2FzZSwgd291bGRuJ3QNCnRoZSBzYW1lIGJlIHRydWUgZm9yIGlu dGVyZmFjZXMgYW5kIHRoZSBvdGhlciBtb2RlbHM/ICBJIHRoaW5rIExORSBvcg0Kc2NoZW1hIG1v dW50IGluIGdlbmVyYWwgc29sdmVzIHRoaXMgaXNzdWUuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+ IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gUmVnYXJkcw0KPiANCj4gSm9uDQo+IA0KPiBGcm9tOiBS b2JlcnQgV2lsdG9uIFttYWlsdG86DQo+IHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9u QGNpc2NvLmNvbT5dDQo+IFNlbnQ6IDA4IEphbnVhcnkgMjAxOCAxNTozMQ0KPiBUbzogRWluYXIg Tmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pOyBKb24gU2hhbGxvdzsgTWFoZXNoIEpldGhhbmFuZGFu aQ0KPiBDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBOZXRtb2QgQUNMIC0gQ2FuICJhY2Nlc3MtbGlzdHMiIGJlIHNldCB1 cCBhcyBhDQo+ICJncm91cGluZyINCj4gDQo+IA0KPiBIaSBFaW5hciwgSm9uLCBNYWhlc2gsDQo+ IA0KPiBNeSBndXQgaW5zdGluY3QgaXMgdGhhdCBtYWtpbmcgdGhpcyBhIGdyb3VwaW5nIG1pZ2h0 IG5vdCBiZSBhIGdvb2QNCj4gaWRlYToNCj4gDQo+IDEpIElmIHNvbWVib2R5IHVwZGF0ZXMgdGhl IGNvcmUgQUNMIG1vZGVsLCB3aWxsIHRoZW4gbmVlZCB0byBjaGVjaw0KPiB0aGF0IGFueW9uZSB1 c2luZyBpdCBzaG91bGQgYmUgc2ltaWxhcmx5IHVwZGF0ZWQgKHVubGVzcyB0aGV5IHVzZQ0KPiBp bXBvcnQtYnktcmV2aXNpb24pLg0KPiANCj4gMikgRG9lcyBpdCBtYWtlIHNlbnNlIHRvIGRlZmlu ZSBBQ0xzIGluIHNlcGFyYXRlIHBsYWNlcy4gIFdvdWxkIGxpa2UNCj4gYmUgbW9yZSBzaW1wbGUg aWYgQUNMcyB3ZXJlIGRlZmluZWQgaW4gYSBjZW50cmFsIHBsYWNlIGFuZCB0aGVuIGp1c3QNCj4g cmVmZXJlbmNlZCBieSBvdGhlciBwcm90b2NvbHMgYXMgcmVxdWlyZWQuDQo+IDMpIEkgdGhpbmsg dGhhdCBncm91cGluZ3MgYXJlIHByb2JhYmx5IG92ZXJ1c2VkIGFuZCBJIHRoaW5rIHRoYXQgdGhl eQ0KPiBjYW4gZGV0cmFjdCBmcm9tIHRoZSByZWFkYWJpbGl0eSBvZiB0aGUgbW9kZWwuICAoSSBy ZWdhcmQgdGhlDQo+IE9wZW5Db25maWcgWUFORyBtb2RlbHMgYXMgYW4gZXh0cmVtZSBleGFtcGxl IG9mIHRoaXMsIHdoZXJlIGl0IGlzDQo+IG5lY2Vzc2FyeSB0byBjb21waWxlIHRoZSBtb2R1bGVz IHRvZ2V0aGVyIHRvIGZpZ3VyZSBvdXQgd2hlcmUNCj4gZXZlcnl0aGluZyBmaXRzIHRvZ2V0aGVy KS4NCj4gDQo+IEhhdmluZyBzYWlkIHRoYXQsIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzc3Vl IGlzIGltcG9ydGFudCBlbm91Z2ggdG8NCj4gaGF2ZSBhIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCAu Li4NCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiBPbiAwOC8wMS8yMDE4IDE1OjAyLCBFaW5h ciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6DQo+IFNpbmNlIHRoaXMgaXMgYSA3LWxp bmUgY2hhbmdlLCBJIHNlZSBubyBoYXJtIGluIGl0IGlmIG5vLW9uZSBvYmplY3RzPw0KPiBNYWhl c2ggaGFzIHRoZSB0b2tlbiBmb3Igcm9sbGluZyBpbiB1cGRhdGVzIGRpc2N1c3NlZCBqdXN0IHBy aW9yIHRvDQo+IHRoZSBlbmQgb2YgMjAxNy4NCj4gDQo+IEhlcmXigJlzIGEgcG9zc2libGUgZGlm ZjoNCj4gDQo+ICQgZ2l0IGRpZmYgLWINCj4gZGlmZiAtLWdpdCBhL3NyYy95YW5nL2lldGYtYWNj ZXNzLWNvbnRyb2wtbGlzdC55YW5nDQo+IGIvc3JjL3lhbmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1s aXN0LnlhbmcNCj4gaW5kZXggNGQ2OThjOS4uYjFhMTczZiAxMDA2NDQNCj4gLS0tIGEvc3JjL3lh bmcvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCj4gKysrIGIvc3JjL3lhbmcvaWV0Zi1h Y2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCj4gQEAgLTQwMiw2ICs0MDIsMTAgQEAgbW9kdWxlIGll dGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7DQo+ICAgIC8qDQo+ICAgICAqIENvbmZpZ3VyYXRpb24g ZGF0YSBub2Rlcw0KPiAgICAgKi8NCj4gKyAgZ3JvdXBpbmcgYWNjZXNzLWxpc3RzLXRvcCB7DQo+ ICsgICAgZGVzY3JpcHRpb24NCj4gKyAgICAgICJHcm91cGluZyB0byBhbGxvdyByZXVzZSBvZiBh Y2Nlc3MgbGlzdHMgY29udGFpbmVyIGVsc2V3aGVyZS4iOw0KPiArDQo+ICAgICAgY29udGFpbmVy IGFjY2Vzcy1saXN0cyB7DQo+ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAiVGhpcyBp cyBhIHRvcCBsZXZlbCBjb250YWluZXIgZm9yIEFjY2VzcyBDb250cm9sIExpc3RzLg0KPiBAQCAt NTc2LDYgKzU4MCw5IEBAIG1vZHVsZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Qgew0KPiAgICAg ICAgICB9DQo+ICAgICAgICB9DQo+ICAgICAgfQ0KPiArICB9DQo+ICsgIHVzZXMgYWNjZXNzLWxp c3RzLXRvcDsNCj4gKw0KPiAgICBhdWdtZW50ICIvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2Ui IHsNCj4gICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgIkF1Z21lbnQgaW50ZXJmYWNlcyB0byBh bGxvdyBBQ0xzIHRvIGJlIGFzc29jaWF0ZWQgaW4gZWl0aGVyIHRoZQ0KPiANCj4gQ2hlZXJzLA0K PiANCj4gRWluYXINCj4gDQo+IA0KPiANCj4gT24gOCBKYW4gMjAxOCwgYXQgMTA6NTMsIEpvbiBT aGFsbG93DQo+IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPj4gd3JvdGU6DQo+IA0KPiBIaSBUaGVyZSwNCj4gDQo+IEkgYXBwcmVjaWF0 ZSB0aGF0IHRoaXMgaXMgbGF0ZSB0byB0aGUgdGFibGUsIGJ1dCBpcyBpdCBwb3NzaWJsZSB0byBz ZXQNCj4gdXAg4oCcYWNjZXNzLWxpc3Rz4oCdIGFzIGEg4oCcZ3JvdXBpbmfigJ0gaW4gdGhlIFlB TkcgZGF0YSBtb2RlbCBzbyB0aGF0DQo+IOKAnGFjY2Vzcy1saXN0c+KAnSBjYW4gYmUgaW5jbHVk ZWQgYnkg4oCcdXNlc+KAnSBpbiBhIGhpZ2hlciBsZXZlbCBZQU5HIGRhdGENCj4gbW9kZWw/DQo+ IA0KPiBJIGhhdmUgcmFpc2VkIHRoaXMgYXMgaXNzdWUgIzIyIGF0DQo+IGh0dHBzOi8vZ2l0aHVi LmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL2lzc3Vlcw0KPiANCj4gUmVnYXJkcw0KPiANCj4gSm9u DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gDQo+IG5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo= From nobody Mon Jan 8 11:45:52 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 C9040126D46 for ; Mon, 8 Jan 2018 11:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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=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 WduaGd4VInOc for ; Mon, 8 Jan 2018 11:45:47 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 77A5612426E for ; Mon, 8 Jan 2018 11:45:46 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id c19so13350414lfg.3 for ; Mon, 08 Jan 2018 11:45:46 -0800 (PST) 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=s6yQWm/QFChnT+MdlxNsy7NFczdyM+xUsBL820ap3dM=; b=LU+bF+KoGPZ5hgZbmXtX1MRnweyFc78NmGvXEhaTbSwcUidrmfK+UKaEShrGSgzHv6 VZmTLTRnkFy0Naw2NbgBmhHTbzj4ev2z/a4JrnlYwZHghUZNe3h72GzApLnehGzOgLDl rIvi2qjIaxMNqokYzzZZDbSBFVfhC0BP6Jb1sRK50cYbWs7weg71zVMmjNeklsmw6uSo NUuNgwbb3k7DwACU2gjArj4TjCY/kQ7E+0w/QqXB6hVhm7gsvwQoM+0TzbCD0KrIWW4+ YwT0gwl68nFcXHaq3PZcK7X/QSmAyGw0JKMsecZzSn0xXhCVdUAUZdI/q8ZoRygKRavx lEHQ== 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=s6yQWm/QFChnT+MdlxNsy7NFczdyM+xUsBL820ap3dM=; b=YKchRjcV9OyTfJP2R4nzVCpeBM2cfHL7/Ip4XCzHTUcgb+ohEn9JgGSx68bgx7pNar NFu7q/2YDOpWPsB5DDwW0Ma/KKjwI2C2N/pBJHnd4LcpEGaEQVNd2ZaNzVU5JuxARpFW pyJwYR4Cobc6ndlfBWaodriI6ZKX8Lps7vnGON2s3UGkzKz0woA8+bno5lNBBjVGZo2n LHleZOm+2vJ+Tv+L9Wt1siBXG2AbiusCscoMcjySxx2B1rfwYSeXiJvdhUE/twz6kvPV XiP5I37T3bzjsa+5YSSdAccFuVWqKYLdKMypEQfBTRVkr/fJT386YsxL3TJRPEWvLhrW 3+FA== X-Gm-Message-State: AKGB3mIs6EwED0JtgDcyGrq2gfkzESVR0hn5mD2f6MW2nag9xaSkrKsh mFy5UkNfahndgsyqt1Ac/n5zG365g4x8LsW6yMfBJw== X-Google-Smtp-Source: ACJfBosum5Mqaubv8cQ4w02JBnXABnycK2dvUoCUhDzg1QiMOxnV76RmwlMtD4hCsN9i8+/X34V3ILG90WVZT4r/toM= X-Received: by 10.46.60.23 with SMTP id j23mr7139991lja.107.1515440744595; Mon, 08 Jan 2018 11:45:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.95.22 with HTTP; Mon, 8 Jan 2018 11:45:43 -0800 (PST) In-Reply-To: References: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com> <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com> <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.com> <20171221132030.7zebh2xkhddmql3c@elstar.local> <20171221222742.izrmwpbiwgoc7col@elstar.local> From: Andy Bierman Date: Mon, 8 Jan 2018 11:45:43 -0800 Message-ID: To: Robert Wilton Cc: NETMOD Working Group Content-Type: multipart/alternative; boundary="f4f5e807b0044298560562490ba7" Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:45:51 -0000 --f4f5e807b0044298560562490ba7 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton wrote: > Hi Andy, > > Regarding your comment below, this intent is captured by this text > describing the operational datastore in section 5.3: > > 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 due to remnant configuration (see > Section 5.3.1). Note, that deviations SHOULD be used when it is > known in advance that a device does not fully conform to the > schema. > > Only semantic constraints MAY be violated, these are the YANG "when", > "must", "mandatory", "unique", "min-elements", and "max-elements" > statements; and the uniqueness of key values. > > Syntactic constraints MUST NOT be violated, including hierarchical > organization, identifiers, and type-based constraints. If a node in > does not meet the syntactic constraints then it MUST > NOT be returned, and some other mechanism should be used to flag the > error. > > > Do you agree that this is sufficient? > Not really. It does not address my concern, which is that NMDA is removing the YANG constraints on config=false data nodes for no apparent reason. The server implementation requirements expressed in YANG constraints are applicable to any data node, not just config=true data nodes. The requirement to implement the ancestor nodes (with keys) does not change. The requirement to conform to the YANG constraints defined within config=false data nodes does not change. To do otherwise does not make sense. E.g. "when" conditions that add ethernet counters only when the interface type is ethernetCsmacd. Why would it be OK for the server to ignore that when-stmt and add ethernet counters to every interface? IMO the text above can only apply to the operational values of config=true nodes. > Thanks, > Rob > Andy > > > On 21/12/2017 22:49, Andy Bierman wrote: > > Hi, > > It should be clear somehow that server requirements to provide > config=false data > that is valid according to the YANG definitions is not affected by NMDA. > That is not being taken away. The ability to validate operational values > of configuration data has never been provided, and therefore is not being > taken away either. > > A constraint on config=true nodes only applies to configuration datastores. > These are the only constraints that should be ignored in . > Constraints on config=false nodes still apply in . > > > Andy > > > > On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote: >> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: >> > >> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote: >> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: >> > > > >> > > > > Hi Vladimir, >> > > > > >> > > > > First point of clarification is that this is not about >> running/intended >> > > > > at all. The contents of running/intended do not change in anyway >> > > > > depending on whether hardware is present or absent. >> > > > > >> > > > > The section is only concerned with how the configuration is >> applied in >> > > > > operational, and basically says that you cannot apply >> configuration for >> > > > > resources that are missing (which seems reasonable). E.g. I >> cannot >> > > > > configure an IP address on a physical interface that isn't >> there. Or if >> > > > > the physical interface gets removed then the configuration >> associated >> > > > > with that interface is also removed from operational. >> > > > > >> > > > > Operational isn't validated and data model constraints are >> allowed to be >> > > > > broken (ideally transiently). >> > > > I want to focus on this. IMO giving up schema validitiy for any >> datastore is >> > > > unacceptable price. Pre-NMDA devices had full model support in >> operational >> > > > data (all YANG constrains part of the model without discrimination >> were >> > > > enforced). >> > > There was a long debate about the value of returning the true >> > > operational state. What do you do if the operational state is invalid? >> > > A server can reject configuration changes if they lead to invalid >> > > state, a server can not reject reality. >> > IMO if the model can represent reality then data conforming to the model >> > can. If not a better model is needed not a hack that breaks the >> datastore >> > conformance to the YANG model. I do not see how >> > /interfaces/interface/oper-status=not-present was not representing the >> > reality of a system with removed line card that is configured and ready >> to >> > resume operation as soon as the line card is reconnected. >> >> I assume this is all system and implementation specific. If your >> system knows about interfaces that are not present (i.e., there is >> operational state about them), you can report these interfaces. But >> 'is configured' is confusing here. I am not sure a line card that does >> not exist should be considered configured. But yes, this may be system >> specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has >> oper-status 'not-present' - so this seems to be a mood point. >> >> > > > If this is about to change it will compromise interoperability >> > > > and a significant portion of the client implementation workload >> that can be >> > > > automated will need to be coded in hand and tested. Unresolved >> leafrefs, >> > > > undefined behaviour of different implementations removing different >> > > > configuration nodes in violation of YANG semantic constraints >> (which I do >> > > > not think can be so clearly separated from the syntactic >> constraints when >> > > > one considers types like leafref, instance-identifier etc.) and the >> > > > corresponding side effects based on the server implementators own >> creativity >> > > > is eventually going to create more problems. >> > > > >> > > > 1. IMO the only acceptable solution is to have YANG valid >> operational >> > > > datastore at all times. operational like any other datastore MUST >> be valid >> > > > YANG data tree and it has to be a system implementation task to >> consider all >> > > > complications resulting from the removal of the resources leading >> to any >> > > > data transformations. If this is difficult or impossible other >> mechanisms to >> > > > flag missing resources should be used (e.g. >> > > > /interfaces/interface/oper-status=not-present) This sounds like a >> useful >> > > > contract providing the value of a standard the alternative does not. >> > > As said above, it is impossible to report valid operational state if >> > > the operational state is not valid according to the models. >> > > >> > > > 2. Even with the change in 1. I do not see the removal of intended >> > > > configuration nodes from operational as a solution worth >> implementing on our >> > > > servers. I do not see a real world plug-and-play scenario that can >> be >> > > > automatically solved without specific additions to the models e.g. >> > > > /interfaces/interface/oper-status=not-present is oversimplified >> solution but >> > > > it needs to be extended exactly as much as the solution provided by >> the >> > > > removal of config true; nodes without the sacrifice of YANG >> validity of >> > > > operational. >> > > Your thinking is likely wrong. reports the operational >> > > state. It may have little in common with . Trying to derive >> > > operational from intended is likely a not well working approach. >> > The proposal for this solution ("derive operational from intended" e.g. >> > merge /interfaces-state in /interfaces) comes from the revised >> datastores >> > draft not me. >> > >> > By definition config true; data represents intent. Reusing the model of >> a >> > config true; data to represent state absent of intent (e.g. >> > /interfaces/interface with origin="or:system") is a hack. The hack works >> > fine without compromising the conformance of operational to the YANG >> model >> > as long as certain conditions are met. I am pointing out that one of the >> > conditions is to keep all of the intended configuration data present in >> > 'operational' and handle missing resources with conventional means e.g. >> > /interfaces/interface/oper-status=not-present instead of adding the >> straw >> > that breaks the camel's back. >> >> I fail to see why you believe all objects that appear in intended >> configuration needs to exist in applied configuration. In fact, >> operators told us very clearly that they care about the distinction >> between intended and applied config. >> >> > > > 3. Solutions like /interfaces/interface/admin-state stop working. >> With the >> > > > interface removed you can no longer figure if the if-mib has or >> does not >> > > > have the interface enabled so an operator has to use SNMP or wait >> for a >> > > > replacement line card to be connected to figure this bit of >> information. >> > > At least on my boxes, if I remove a line card, the interface also >> > > disappears in SNMP tables. Stuff that is operationally not present is >> > > simply operationally not present. >> > > >> > > > My >> > > > interpretation of the MAY as requirement level in sec. 5.3. The >> Operational >> > > > State Datastore () is that plug-and-play solutions can >> be >> > > > implemented without this limited approach that has the same problem >> as the >> > > > pre-NMDA only now we have to have /interfaces-state to keep config >> false; >> > > > data relevant to hardware that is configured but not present: >> > > > >> > > > configuration data nodes supported in a configuration datastore >> > > > MAY be omitted from if a server is not able to >> > > > accurately report them. >> > > > >> > > > I realize this discussion comes late. I have stated my objections >> to this >> > > > particular part of the NMDA draft earlier. >> > > I believe there is a conceptual misunderstanding. I think there never >> > > was a requirement that a server reports the state of hardware that is >> > > not present. >> > "Data relevant to hardware that is configured but not present" is >> different >> > from "state of hardware that is not present". For example information >> > indicating when the line card became unavailable, what was the reason, >> or >> > other information like how many packets that had this interface as >> egress >> > destination are being dropped as a result of the removal. >> >> I think that systems handle non-existing interfaces differently. It >> seems that ietf-interfaces is flexible enough to accomodate the >> differnet styles. >> >> /js >> >> -- >> 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 >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --f4f5e807b0044298560562490ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20

Hi Andy,

Regarding your comment below, this intent is captured by this text describing the operational datastore in section 5.3:

   <operational> SHOUL=
D conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" value=
s, it
   is possible that constraints MAY be violated under some
   circumstances, e.g., an abnormal value is "in use", the struct=
ure of
   a list is being modified, or due to remnant configuration (see
   Section 5.3.1).  Note, that deviations SHOULD be used when it is
   known in advance that a device does not fully conform to the
   <operational> schema.

   Only semantic constraints MAY be violated, these are the YANG "when=
",
   "must", "mandatory", "unique", "min-e=
lements", and "max-elements"
   statements; and the uniqueness of key values.

   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
   <operational> does not meet the syntactic constraints then it MUST
   NOT be returned, and some other mechanism should be used to flag the
   error.

Do you agree that this is sufficient?


Not really.
It does not address my concer= n, which is that NMDA is
removing the YANG constraints on config= =3Dfalse data nodes
for no apparent reason.

<= div>The server implementation requirements expressed in YANG constraints
are applicable to any data node, not just config=3Dtrue data nodes.=
The requirement to implement the ancestor nodes (with keys) does= not change.
The requirement to conform to the YANG constraints d= efined within config=3Dfalse
data nodes does not change.

To do otherwise does not make sense.=C2=A0 E.g. "when= " conditions that add ethernet
counters only when the interf= ace type is ethernetCsmacd. Why would it be OK for
the server to = ignore that when-stmt and add ethernet counters to every interface?

IMO the text above can only apply to the operational valu= es of config=3Dtrue nodes.


Thanks,
Rob


Andy
=
=C2=A0


On 21/12/2017 22:49= , Andy Bierman wrote:
=20
Hi,

It should be clear somehow that server requirements to provide config=3Dfalse data
that is valid according to the YANG definitions is not affected by NMDA.
That is not being taken away.=C2=A0 The ability to validate operational values
of configuration data has never been provided, and therefore is not being taken away either.

A constraint on config=3Dtrue nodes only applies to configuration datastores.
These are the only constraints that should be ignored in <operational>.
Constraints on config=3Dfalse nodes still apply in <operational>.


Andy



On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs= -university.de> wrote:
On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
> On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>
> > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
> > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > First point of clarification is that this is not about running/intended
> > > > at all.=C2=A0 The contents of running/intended do not change in anyway
> > > > depending on whether hardware is present or absent.
> > > >
> > > > The section is only concerned with how the configuration is applied in
> > > > operational, and basically says that you cannot apply configuration for
> > > > resources that are missing (which seems reasonable).=C2=A0 E.g. I cannot
> > > > configure an IP address on a physical interface that isn't there.=C2=A0 Or if
> > > > the physical interface gets removed then the configuration associated
> > > > with that interface is also removed from operational.
> > > >
> > > > Operational isn't validated and data model constraints are allowed to be
> > > > broken (ideally transiently).
> > > I want to focus on this. IMO giving up schema validitiy for any datastore is
> > > unacceptable price. Pre-NMDA devices had full model support in operational
> > > data (all YANG constrains part of the model without discrimination were
> > > enforced).
> > There was a long debate about the value of returning the true
> > operational state. What do you do if the operational state is invalid?
> > A server can reject configuration changes if they lead to invalid
> > state, a server can not reject reality.
> IMO if the model can represent reality then data conforming to the model
> can. If not a better model is needed not a hack that breaks the datastore
> conformance to the YANG model. I do not see how
> /interfaces/interface/oper-status=3Dnot-present was not representing the
> reality of a system with removed line card that is configured and ready to
> resume operation as soon as the line card is reconnected.

I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e., there is
operational state about them), you can report these interfaces.=C2=A0 But
'is configured' is confusing here. I am not sure a line= card that does
not exist should be considered configured. But yes, this may be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.

> > > If this is about to change it will compromise interoperability
> > > and a significant portion of the client implementation workload that can be
> > > automated will need to be coded in hand and tested. Unresolved leafrefs,
> > > undefined behaviour of different implementations removing different
> > > configuration nodes in violation of YANG semantic constraints (which I do
> > > not think can be so clearly separated from the syntactic constraints when
> > > one considers types like leafref, instance-identifier etc.) and the
> > > corresponding side effects based on the server implementators own creativity
> > > is eventually going to create more problems.
> > >
> > > 1. IMO the only acceptable solution is to have YANG valid operational
> > > datastore at all times. operational like any other datastore MUST be valid
> > > YANG data tree and it has to be a system implementation task to consider all
> > > complications resulting from the removal of the resources leading to any
> > > data transformations. If this is difficult or impossible other mechanisms to
> > > flag missing resources should be used (e.g.
> > > /interfaces/interface/oper-status=3Dnot-pre= sent) This sounds like a useful
> > > contract providing the value of a standard the alternative does not.
> > As said above, it is impossible to report valid operational state if
> > the operational state is not valid according to the models.
> >
> > > 2. Even with the change in 1. I do not see the removal of intended
> > > configuration nodes from operational as a solution worth implementing on our
> > > servers. I do not see a real world plug-and-play scenario that can be
> > > automatically solved without specific additions to the models e.g.
> > > /interfaces/interface/oper-status=3Dnot-pre= sent is oversimplified solution but
> > > it needs to be extended exactly as much as the solution provided by the
> > > removal of config true; nodes without the sacrifice of YANG validity of
> > > operational.
> > Your thinking is likely wrong. <operational> reports the operational
> > state. It may have little in common with <intended>. Trying to derive
> > operational from intended is likely a not well working approach.
> The proposal for this solution ("derive operational from intended" e.g.
> merge /interfaces-state in /interfaces) comes from the revised datastores
> draft not me.
>
> By definition config true; data represents intent. Reusing the model of a
> config true; data to represent state absent of intent (e.g.
> /interfaces/interface with origin=3D"or:system")= is a hack. The hack works
> fine without compromising the conformance of operational to the YANG model
> as long as certain conditions are met. I am pointing out that one of the
> conditions is to keep all of the intended configuration data present in
> 'operational' and handle missing resources with conventional means e.g.
> /interfaces/interface/oper-status=3Dnot-present instead of adding the straw
> that breaks the camel's back.

I fail to see why you believe all objects that appear in intended
configuration needs to exist in applied configuration. In fact,
operators told us very clearly that they care about the distinction
between intended and applied config.

> > > 3. Solutions like /interfaces/interface/admin-state stop working. With the
> > > interface removed you can no longer figure if the if-mib has or does not
> > > have the interface enabled so an operator has to use SNMP or wait for a
> > > replacement line card to be connected to figure this bit of information.
> > At least on my boxes, if I remove a line card, the interface also
> > disappears in SNMP tables. Stuff that is operationally not present is
> > simply operationally not present.
> >
> > > My
> > > interpretation of the MAY as requirement level in sec. 5.3. The Operational
> > > State Datastore (<operational>) is that plug-and-play solutions can be
> > > implemented without this limited approach that has the same problem as the
> > > pre-NMDA only now we have to have /interfaces-state to keep config false;
> > > data relevant to hardware that is configured but not present:
> > >
> > >=C2=A0 =C2=A0=C2=A0 configuration data nodes supp= orted in a configuration datastore
> > >=C2=A0 =C2=A0=C2=A0 MAY be omitted from <opera= tional> if a server is not able to
> > >=C2=A0 =C2=A0=C2=A0 accurately report them.
> > >
> > > I realize this discussion comes late. I have stated my objections to this
> > > particular part of the NMDA draft earlier.
> > I believe there is a conceptual misunderstanding. I think there never
> > was a requirement that a server reports the state of hardware that is
> > not present.
> "Data relevant to hardware that is configured but not present" is different
> from "state of hardware that is not present". Fo= r example information
> indicating when the line card became unavailable, what was the reason, or
> other information like how many packets that had this interface as egress
> destination are being dropped as a result of the removal.

I think that systems handle non-existing interfaces differently. It
seems that ietf-interfaces is flexible enough to accomodate the
differnet styles.

/js

--
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=A0Ca= mpus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>

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



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


--f4f5e807b0044298560562490ba7-- From nobody Mon Jan 8 13:33: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 C487412D831; Mon, 8 Jan 2018 13:33:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: Cc: draft-ietf-netmod-rfc7223bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151544720277.11278.6563847217163379153@ietfa.amsl.com> Date: Mon, 08 Jan 2018 13:33:22 -0800 Archived-At: Subject: [netmod] Opsdir telechat review of draft-ietf-netmod-rfc7223bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:33:23 -0000 Reviewer: Jouni Korhonen Review result: Ready I did a shallow review on the document and to me it looked ok. The YANG passes online validators (obviously the examples in Appendixes create bogus warnings). Similarly IDnits warning concerning abstract and "obsoletes" is bogus. From nobody Mon Jan 8 13:48:14 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 6851512D82C; Mon, 8 Jan 2018 13:48:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-rfc7223bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151544808841.11217.4534109694790942374.idtracker@ietfa.amsl.com> Date: Mon, 08 Jan 2018 13:48:08 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7223bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:48:08 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-rfc7223bis-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hello, Thanks for your work on this draft. It appears an older version of the Security Considerations template was used. Could you please update to the current version that adds in transport security and other considerations? I believe this is the latest version, but Benoit can confirm. https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 From nobody Mon Jan 8 13:53:10 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 0624F12D847; Mon, 8 Jan 2018 13:53:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-rfc7277bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> Date: Mon, 08 Jan 2018 13:53:05 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:53:05 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-rfc7277bis-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hello, I'm a little confused on the Security Consideration section as it doesn't use the latest template, but does specify SSH for NETCONF, so I'm good with that part. Will RESTCONF also be used as a transport or is there some reason it won't be used for this YANG module? Here's what I think is the latest template and please let me know if sections of it do not apply to this draft and I'll drop the discuss for correcting the security considerations section. https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 Thanks in advance! From nobody Mon Jan 8 13:59: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 9F2F812D848; Mon, 8 Jan 2018 13:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 hiAYHL9Ie_An; Mon, 8 Jan 2018 13:59:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 7A3A912D835; Mon, 8 Jan 2018 13:59:48 -0800 (PST) Received: from MBP.local ([IPv6:2620:11a:c081:20:109c:f7e3:ded:4120]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w08LxjbQ033690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 8 Jan 2018 21:59:46 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:109c:f7e3:ded:4120] claimed to be MBP.local To: Kathleen Moriarty , The IESG Cc: draft-ietf-netmod-rfc7277bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org References: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <11d17779-1b0b-490a-a245-00712cc35b6d@bogus.com> Date: Mon, 8 Jan 2018 13:59:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------8773D0B3836302296625BF53" Content-Language: en-US Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:59:52 -0000 This is a multi-part message in MIME format. --------------8773D0B3836302296625BF53 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 1/8/18 1:53 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-netmod-rfc7277bis-01: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hello, > > I'm a little confused on the Security Consideration section as it doesn't use > the latest template, but does specify SSH for NETCONF, so I'm good with that > part. Will RESTCONF also be used as a transport or is there some reason it > won't be used for this YANG module? > > Here's what I think is the latest template and please let me know if sections > of it do not apply to this draft and I'll drop the discuss for correcting the > security considerations section. the security consideration section of 7277bis is the same as for rfc 7277 the ssh recommendation came from you at the time. *Comment* (2014-03-21 for -13) Add a RECOMMEND use of SSH in addition to the MTI to prevent MITM or monitoring attacks (pervasive or otherwise). > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 > > Thanks in advance! > > > > --------------8773D0B3836302296625BF53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 1/8/18 1:53 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-netmod-rfc7277bis-01: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hello,

I'm a little confused on the Security Consideration section as it doesn't use
the latest template, but does specify SSH for NETCONF, so I'm good with that
part.  Will RESTCONF also be used as a transport or is there some reason it
won't be used for this YANG module?

Here's what I think is the latest template and please let me know if sections
of it do not apply to this draft and I'll drop the discuss for correcting the
security considerations section.

the security consideration section of 7277bis is the same as for rfc 7277

the ssh recommendation came from you at the time.
Comment (2014-03-21 for -13)
Add a RECOMMEND use of SSH in addition to the MTI to prevent MITM or monitoring attacks (pervasive or otherwise).
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

Thanks in advance!

--------------8773D0B3836302296625BF53-- From nobody Mon Jan 8 19:54:42 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 C422F12711A; Mon, 8 Jan 2018 19:54:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Victor Kuarsingh To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-revised-datastores.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151547007476.9572.16433487564668974701@ietfa.amsl.com> Date: Mon, 08 Jan 2018 19:54:34 -0800 Archived-At: Subject: [netmod] Opsdir telechat review of draft-ietf-netmod-revised-datastores-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 03:54:35 -0000 Reviewer: Victor Kuarsingh Review result: Ready Dear Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - Network Management Datastore Architecture Link to Document - https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-09 Summary: This document specifies and architectural framework for datastores as it pertains to YANG (RFC7960)and NETCONF(RFC6241)/RESTCONF(RFC8040). A significant amount of input was gathered from real world experience to help evolve the the the datamodels user/proposed. The document outlines a revised architecture model for datastores with the addition of “Intended” and “operational” to the conceptual model. General Comments and Feedback: In general, this document seems well written and reviewed by the working group. N specific NITs or edits are recommended by this review. The document describes operational impacts os the change since Implications to YANG in section 6 and YANG model examples in section 7 which are highly useful the for the operationalization of this updated specification. I fee the document is ready for publishing baed on the current (ver -09) draft. From nobody Mon Jan 8 23:16:52 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 D348912D7F7; Mon, 8 Jan 2018 23:16:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang To: Cc: draft-ietf-netmod-rfc7277bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org, ops-ad@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151548219984.9488.4656273701638000972@ietfa.amsl.com> Date: Mon, 08 Jan 2018 23:16:39 -0800 Archived-At: Subject: [netmod] Opsdir telechat review of draft-ietf-netmod-rfc7277bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:16:40 -0000 Reviewer: Sheng Jiang Review result: Ready Hi, OPS-DIR, Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This Standards Track document defines a YANG data model for management of IP implementations. It includes configuration and system state. This document obsoletes RFC 7277. As a Bis document, this document is well written. It is ready with minor issues. Major issue: no. Minor issue: no. Regards, Sheng From nobody Mon Jan 8 23:28: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 113B412D7F7; Mon, 8 Jan 2018 23:28:22 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bZPW4zGzpExI; Mon, 8 Jan 2018 23:28:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 598A5126B7F; Mon, 8 Jan 2018 23:28:20 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id C18951AE0144; Tue, 9 Jan 2018 08:28:18 +0100 (CET) Date: Tue, 09 Jan 2018 08:26:36 +0100 (CET) Message-Id: <20180109.082636.1242827908143886439.mbj@tail-f.com> To: Kathleen.Moriarty.ietf@gmail.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-rfc7223bis@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151544808841.11217.4534109694790942374.idtracker@ietfa.amsl.com> References: <151544808841.11217.4534109694790942374.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7223bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:28:22 -0000 Hi, Kathleen Moriarty wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hello, > > Thanks for your work on this draft. It appears an older version of the > Security Considerations template was used. Could you please update to the > current version that adds in transport security and other considerations? I > believe this is the latest version, but Benoit can confirm. > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 I have updated to the latest version in my local copy. /martin From nobody Mon Jan 8 23:28:57 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 29AE812D7F7; Mon, 8 Jan 2018 23:28:56 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VSBoDXRPm3dB; Mon, 8 Jan 2018 23:28:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66525127909; Mon, 8 Jan 2018 23:28:54 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 5CE911AE0144; Tue, 9 Jan 2018 08:28:53 +0100 (CET) Date: Tue, 09 Jan 2018 08:27:11 +0100 (CET) Message-Id: <20180109.082711.971204319569734613.mbj@tail-f.com> To: Kathleen.Moriarty.ietf@gmail.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> References: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:28:56 -0000 Hi, Kathleen Moriarty wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hello, > > I'm a little confused on the Security Consideration section as it doesn't use > the latest template, but does specify SSH for NETCONF, so I'm good with that > part. Will RESTCONF also be used as a transport or is there some reason it > won't be used for this YANG module? > > Here's what I think is the latest template and please let me know if sections > of it do not apply to this draft and I'll drop the discuss for correcting the > security considerations section. > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 I have updated to the latest version in my local copy. /martin From nobody Mon Jan 8 23:40: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 3BA5D12D80E; Mon, 8 Jan 2018 23:40:13 -0800 (PST) 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_RP_MATCHES_RCVD=-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 TFCWuhNqkDfL; Mon, 8 Jan 2018 23:40:11 -0800 (PST) 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 B8192126B7F; Mon, 8 Jan 2018 23:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1050; q=dns/txt; s=iport; t=1515483611; x=1516693211; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9xqS2fKffLr6PXA0DmY0mrwKsnDSRUJQSSd2GR5CHaU=; b=V4acYbYylnch4dG7H7G1ZDVQn0gIoDXR42kz/SFVfvOsY6JEZR9cePZT VCgsxKQtG3LN6trXwzqKGD1QDAuGcC6ThR8JRsDvbZ28Zj9FNrRmkuNmO 249R8FYngRun9TBLoyuv6cVz9FEzGsdyprICNhO7570ZAZjC5Yuf307z6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQCpcFRa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQmdCeEB4sYj2qJCJA4CiOFGAKEeRQBAQEBAQEBAQFrKIUkAQU?= =?us-ascii?q?jFUEQCw4KAgImAgIhNgYBDAYCAQGKFAMVEK8CgieHRg2CcAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgQ+DEYNsghKDBYJrRAGFBYJlBYpTmE49iAqIN4UAgheGGYN?= =?us-ascii?q?vh2qNND+BHogHgTw2IoFQMhoIGxWCZ4MJgU9ANwGKWAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,334,1511827200"; d="scan'208";a="1343367" 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; 09 Jan 2018 07:40:08 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w097e8xv020697; Tue, 9 Jan 2018 07:40:08 GMT To: Martin Bjorklund , Kathleen.Moriarty.ietf@gmail.com Cc: netmod-chairs@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, iesg@ietf.org, netmod@ietf.org References: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> <20180109.082711.971204319569734613.mbj@tail-f.com> From: Benoit Claise Message-ID: <4000af84-77c5-1b57-a0da-23aa735ce38d@cisco.com> Date: Tue, 9 Jan 2018 08:40:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109.082711.971204319569734613.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:40:13 -0000 On 1/9/2018 8:27 AM, Martin Bjorklund wrote: > Hi, > > Kathleen Moriarty wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Hello, >> >> I'm a little confused on the Security Consideration section as it doesn't use >> the latest template, but does specify SSH for NETCONF, so I'm good with that >> part. Will RESTCONF also be used as a transport or is there some reason it >> won't be used for this YANG module? >> >> Here's what I think is the latest template and please let me know if sections >> of it do not apply to this draft and I'll drop the discuss for correcting the >> security considerations section. >> >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 > I have updated to the latest version in my local copy. Thanks Martin. The IETF LC finishes today. So please post a new version tomorrow. Regards, B. > > > /martin > > . > From nobody Tue Jan 9 00:53:36 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 438B0120454; Tue, 9 Jan 2018 00:53:35 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151548801523.9604.6358368567681323750@ietfa.amsl.com> Date: Tue, 09 Jan 2018 00:53:35 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 08:53:35 -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 : A YANG Data Model for Interface Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7223bis-02.txt Pages : 48 Date : 2018-01-09 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). This document obsoletes RFC 7223. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-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 Tue Jan 9 00:54:31 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 83B2B120454; Tue, 9 Jan 2018 00:54:26 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151548806650.9560.4097258872322227892@ietfa.amsl.com> Date: Tue, 09 Jan 2018 00:54:26 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7277bis-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 08:54:27 -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 : A YANG Data Model for IP Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7277bis-02.txt Pages : 32 Date : 2018-01-09 Abstract: This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7277bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-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 Tue Jan 9 02:50:15 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 BDCA5126C83; Tue, 9 Jan 2018 02:50:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151549500977.9608.14570663429463756513.idtracker@ietfa.amsl.com> Date: Tue, 09 Jan 2018 02:50:09 -0800 Archived-At: Subject: [netmod] Alexey Melnikov's Yes on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 10:50:10 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Appendix C.1: example hostnames "foo" and "bar" are used. Should these be fully qualified? From nobody Tue Jan 9 03:18: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 270E5126D3F for ; Tue, 9 Jan 2018 03:18:31 -0800 (PST) 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_RP_MATCHES_RCVD=-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 Y0X3jU7yIksC for ; Tue, 9 Jan 2018 03:18:27 -0800 (PST) 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 7BBD4126C83 for ; Tue, 9 Jan 2018 03:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49412; q=dns/txt; s=iport; t=1515496706; x=1516706306; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=SEhHR7A1aBZpr7LHFM6AjBImqjr60wzYunfdFRi+ncw=; b=N7gw8IgOjaPSKjYBZkNv0Vo8slWYMzBlEL6uu0sDldX/7LoA+tbM5ZIJ IHaKj/xVeBMwOyoeBLlMLX5KP+iusd6R/h5gOLkp7U9NUqHr+xr90ozKo ZYgUW+0M9Q5ONiji9oOpMfrLbupeVVCZPfFgyDlYUGJaJSyIQoNaw23EE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQB2pFRa/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkaBFnQnhAeLGI9ql0KCAQoYAQqDOoEPTwKEehQBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQIBAQEYAQhLCwUJAgkCEAIGIAEGAwICGwwfAw4GDQYCAQEXi?= =?us-ascii?q?g4IEJEsnW6CJyaKHQEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FhBt9gm+BaSmBd4E?= =?us-ascii?q?Ogy8BgUcPAjcmglCCZQWZWReJb5VBgheKCCaBOoYKimGEMYgHgTw2IiWBKzIaC?= =?us-ascii?q?BsVPYIqCYISORyBZ0E3iDMCJQeCHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,335,1511827200"; d="scan'208,217";a="1348454" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 11:18:23 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w09BIN0x028739; Tue, 9 Jan 2018 11:18:23 GMT To: Andy Bierman Cc: NETMOD Working Group References: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com> <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com> <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.com> <20171221132030.7zebh2xkhddmql3c@elstar.local> <20171221222742.izrmwpbiwgoc7col@elstar.local> From: Robert Wilton Message-ID: Date: Tue, 9 Jan 2018 11:18:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5028F0DD6D1EF7E68FF0ED6D" Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 11:18:31 -0000 This is a multi-part message in MIME format. --------------5028F0DD6D1EF7E68FF0ED6D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On 08/01/2018 19:45, Andy Bierman wrote: > > > On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton > wrote: > > Hi Andy, > > Regarding your comment below, this intent is captured by this text > describing the operational datastore in section 5.3: > > 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 due to remnant configuration (see > Section 5.3.1). Note, that deviations SHOULD be used when it is > known in advance that a device does not fully conform to the > schema. > > Only semantic constraints MAY be violated, these are the YANG "when", > "must", "mandatory", "unique", "min-elements", and "max-elements" > statements; and the uniqueness of key values. > > Syntactic constraints MUST NOT be violated, including hierarchical > organization, identifiers, and type-based constraints. If a node in > does not meet the syntactic constraints then it MUST > NOT be returned, and some other mechanism should be used to flag the > error. > > > Do you agree that this is sufficient? > > > > Not really. > It does not address my concern, which is that NMDA is > removing the YANG constraints on config=false data nodes > for no apparent reason. There is a reason. I don't think that the constraints on config=false is really being removed, because I don't think that they truly existed in the first place (despite what RFC 7950 might indicate!). I think that we all agree on the expected behavior for configuration: If a client sends configuration to a server that would cause to become invalid then the server should reject that change, to ensure that always holds a consistent configuration.  Having a consistent configuration is the most important property here.  I.e. the server has the right to reject an invalid configuration request from a client. However, the flow of operational state data in opposite direction cannot hold to the same rules.  If during the processing of a get request (or YANG push) a server sends operational state data back to a client then a client has to choose how to process the message:  - if the message is garbled or not sane then it makes sense to discard it.  - however, what should the client do if the message is well formed but either (i) contains some values outside the permitted schema range (but can be represented by the schema datatype), or (ii) by applying the values would cause the clients copy of to become invalid? If the client discards the message because of one bad value, then that doesn't seem to be helpful, since it allows for a very fragile model of system management.  I.e. if one small thing is bad then the whole house of cards collapses. So I think that the only sensible behaviour here is that the client has to process the operational state update in a best effort fashion, keep all the good data and probably flag any values that are outside the value constraints.  Similarly any reference constraint failures (i.e. when/must) can similarly be flagged up, but throwing away an update message that would cause the operational state to become inconsistent doesn't seem to be helpful.  I.e. it is much better if the client gets to see the true state of the server, even if that state isn't good (or consistent). Similar questions arise on the server itself:  - what if the real value in use (e.g. that is read from the hardware) is outside the permitted range (because of a logic defect)?  Is it really better to suppress that value entirely or return a value that server knows to be wrong?  - can a server even know that its operational view is consistent? For complex systems where the real operational state is split across multiple underlying linecards, or remote devices, I think that this is very hard (if not impossible) to do. So what the NMDA architecture states is:  (i) if a server knows that it won't conform to the operational schema then it must use deviations,  (ii) a server in a normal steady state should conform to the operational schema (and be valid),  (iii) but, if the system is churning (e.g. configuration, route update, etc) then the operational state of the server might be transiently inconsistent and this is OK,  (iv) if, the server is in a bad state, then it is better to return the actual state than to lie or not report a particular value (as long as it can be encoded).  (v) a server does not need to explicitly validate that its view of operational is valid. It is unclear what it would/could do if it detected that the operational state is invalid, nor is it clear that servers would generally be able to always perform this operation. > > The server implementation requirements expressed in YANG constraints > are applicable to any data node, not just config=true data nodes. > The requirement to implement the ancestor nodes (with keys) does not > change. The draft does not allow this to be violated.  I.e. the following statement prevents this: "Syntactic constraints MUST NOT be violated, including hierarchical organization". > The requirement to conform to the YANG constraints defined within > config=false > data nodes does not change. > > To do otherwise does not make sense.  E.g. "when" conditions that add > ethernet > counters only when the interface type is ethernetCsmacd. Why would it > be OK for > the server to ignore that when-stmt and add ethernet counters to every > interface? It is not OK for a server to ignore that and add Ethernet counters to every interface (without using a deviation).  The draft is not trying to allow that. But if an interface could change type (e.g. between Ethernet and ATM via a different optics module being inserted) then it would be allowed for a server to transiently report the ethernet counters on the interface whilst it is in the process of changing the interface type from ethernet to ATM (e.g. if the counters are maintained by a separate daemon that is updated asynchronously with respect to the config or optics change).  Once the change had completed, the the system reaches steady state then the Ethernet counter must no longer be reported. Thanks, Rob > > IMO the text above can only apply to the operational values of > config=true nodes. > > > Thanks, > Rob > > > > Andy > > > > On 21/12/2017 22:49, Andy Bierman wrote: >> Hi, >> >> It should be clear somehow that server requirements to provide >> config=false data >> that is valid according to the YANG definitions is not affected >> by NMDA. >> That is not being taken away.  The ability to validate >> operational values >> of configuration data has never been provided, and therefore is >> not being taken away either. >> >> A constraint on config=true nodes only applies to configuration >> datastores. >> These are the only constraints that should be ignored in >> . >> Constraints on config=false nodes still apply in . >> >> >> Andy >> >> >> >> On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder >> > > wrote: >> >> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev >> wrote: >> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: >> > >> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir >> Vassilev wrote: >> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: >> > > > >> > > > > Hi Vladimir, >> > > > > >> > > > > First point of clarification is that this is not >> about running/intended >> > > > > at all.  The contents of running/intended do not >> change in anyway >> > > > > depending on whether hardware is present or absent. >> > > > > >> > > > > The section is only concerned with how the >> configuration is applied in >> > > > > operational, and basically says that you cannot apply >> configuration for >> > > > > resources that are missing (which seems reasonable).  >> E.g. I cannot >> > > > > configure an IP address on a physical interface that >> isn't there.  Or if >> > > > > the physical interface gets removed then the >> configuration associated >> > > > > with that interface is also removed from operational. >> > > > > >> > > > > Operational isn't validated and data model >> constraints are allowed to be >> > > > > broken (ideally transiently). >> > > > I want to focus on this. IMO giving up schema validitiy >> for any datastore is >> > > > unacceptable price. Pre-NMDA devices had full model >> support in operational >> > > > data (all YANG constrains part of the model without >> discrimination were >> > > > enforced). >> > > There was a long debate about the value of returning the true >> > > operational state. What do you do if the operational >> state is invalid? >> > > A server can reject configuration changes if they lead to >> invalid >> > > state, a server can not reject reality. >> > IMO if the model can represent reality then data conforming >> to the model >> > can. If not a better model is needed not a hack that breaks >> the datastore >> > conformance to the YANG model. I do not see how >> > /interfaces/interface/oper-status=not-present was not >> representing the >> > reality of a system with removed line card that is >> configured and ready to >> > resume operation as soon as the line card is reconnected. >> >> I assume this is all system and implementation specific. If your >> system knows about interfaces that are not present (i.e., >> there is >> operational state about them), you can report these >> interfaces.  But >> 'is configured' is confusing here. I am not sure a line card >> that does >> not exist should be considered configured. But yes, this may >> be system >> specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has >> oper-status 'not-present' - so this seems to be a mood point. >> >> > > > If this is about to change it will compromise >> interoperability >> > > > and a significant portion of the client implementation >> workload that can be >> > > > automated will need to be coded in hand and tested. >> Unresolved leafrefs, >> > > > undefined behaviour of different implementations >> removing different >> > > > configuration nodes in violation of YANG semantic >> constraints (which I do >> > > > not think can be so clearly separated from the >> syntactic constraints when >> > > > one considers types like leafref, instance-identifier >> etc.) and the >> > > > corresponding side effects based on the server >> implementators own creativity >> > > > is eventually going to create more problems. >> > > > >> > > > 1. IMO the only acceptable solution is to have YANG >> valid operational >> > > > datastore at all times. operational like any other >> datastore MUST be valid >> > > > YANG data tree and it has to be a system implementation >> task to consider all >> > > > complications resulting from the removal of the >> resources leading to any >> > > > data transformations. If this is difficult or >> impossible other mechanisms to >> > > > flag missing resources should be used (e.g. >> > > > /interfaces/interface/oper-status=not-present) This >> sounds like a useful >> > > > contract providing the value of a standard the >> alternative does not. >> > > As said above, it is impossible to report valid >> operational state if >> > > the operational state is not valid according to the models. >> > > >> > > > 2. Even with the change in 1. I do not see the removal >> of intended >> > > > configuration nodes from operational as a solution >> worth implementing on our >> > > > servers. I do not see a real world plug-and-play >> scenario that can be >> > > > automatically solved without specific additions to the >> models e.g. >> > > > /interfaces/interface/oper-status=not-present is >> oversimplified solution but >> > > > it needs to be extended exactly as much as the solution >> provided by the >> > > > removal of config true; nodes without the sacrifice of >> YANG validity of >> > > > operational. >> > > Your thinking is likely wrong. reports the >> operational >> > > state. It may have little in common with . >> Trying to derive >> > > operational from intended is likely a not well working >> approach. >> > The proposal for this solution ("derive operational from >> intended" e.g. >> > merge /interfaces-state in /interfaces) comes from the >> revised datastores >> > draft not me. >> > >> > By definition config true; data represents intent. Reusing >> the model of a >> > config true; data to represent state absent of intent (e.g. >> > /interfaces/interface with origin="or:system") is a hack. >> The hack works >> > fine without compromising the conformance of operational to >> the YANG model >> > as long as certain conditions are met. I am pointing out >> that one of the >> > conditions is to keep all of the intended configuration >> data present in >> > 'operational' and handle missing resources with >> conventional means e.g. >> > /interfaces/interface/oper-status=not-present instead of >> adding the straw >> > that breaks the camel's back. >> >> I fail to see why you believe all objects that appear in intended >> configuration needs to exist in applied configuration. In fact, >> operators told us very clearly that they care about the >> distinction >> between intended and applied config. >> >> > > > 3. Solutions like /interfaces/interface/admin-state >> stop working. With the >> > > > interface removed you can no longer figure if the >> if-mib has or does not >> > > > have the interface enabled so an operator has to use >> SNMP or wait for a >> > > > replacement line card to be connected to figure this >> bit of information. >> > > At least on my boxes, if I remove a line card, the >> interface also >> > > disappears in SNMP tables. Stuff that is operationally >> not present is >> > > simply operationally not present. >> > > >> > > > My >> > > > interpretation of the MAY as requirement level in sec. >> 5.3. The Operational >> > > > State Datastore () is that plug-and-play >> solutions can be >> > > > implemented without this limited approach that has the >> same problem as the >> > > > pre-NMDA only now we have to have /interfaces-state to >> keep config false; >> > > > data relevant to hardware that is configured but not >> present: >> > > > >> > > >     configuration data nodes supported in a >> configuration datastore >> > > >     MAY be omitted from if a server is >> not able to >> > > >     accurately report them. >> > > > >> > > > I realize this discussion comes late. I have stated my >> objections to this >> > > > particular part of the NMDA draft earlier. >> > > I believe there is a conceptual misunderstanding. I think >> there never >> > > was a requirement that a server reports the state of >> hardware that is >> > > not present. >> > "Data relevant to hardware that is configured but not >> present" is different >> > from "state of hardware that is not present". For example >> information >> > indicating when the line card became unavailable, what was >> the reason, or >> > other information like how many packets that had this >> interface as egress >> > destination are being dropped as a result of the removal. >> >> I think that systems handle non-existing interfaces >> differently. It >> seems that ietf-interfaces is flexible enough to accomodate the >> differnet styles. >> >> /js >> >> -- >> 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 >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --------------5028F0DD6D1EF7E68FF0ED6D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 08/01/2018 19:45, Andy Bierman wrote:


On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Regarding your comment below, this intent is captured by this text describing the operational datastore in section 5.3:

   <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 due to remnant configuration (see
   Section 5.3.1).  Note, that deviations SHOULD be used when it is
   known in advance that a device does not fully conform to the
   <operational> schema.

   Only semantic constraints MAY be violated, these are the YANG "when",
   "must", "mandatory", "unique", "min-elements", and "max-elements"
   statements; and the uniqueness of key values.

   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
   <operational> does not meet the syntactic constraints then it MUST
   NOT be returned, and some other mechanism should be used to flag the
   error.

Do you agree that this is sufficient?


Not really.
It does not address my concern, which is that NMDA is
removing the YANG constraints on config=false data nodes
for no apparent reason.

There is a reason. I don't think that the constraints on config=false is really being removed, because I don't think that they truly existed in the first place (despite what RFC 7950 might indicate!).

I think that we all agree on the expected behavior for configuration: If a client sends configuration to a server that would cause <running> to become invalid then the server should reject that change, to ensure that <running> always holds a consistent configuration.  Having a consistent configuration is the most important property here.  I.e. the server has the right to reject an invalid configuration request from a client.

However, the flow of operational state data in opposite direction cannot hold to the same rules.  If during the processing of a get request (or YANG push) a server sends operational state data back to a client then a client has to choose how to process the message:
 - if the message is garbled or not sane then it makes sense to discard it.
 - however, what should the client do if the message is well formed but either (i) contains some values outside the permitted schema range (but can be represented by the schema datatype), or (ii) by applying the values would cause the clients copy of <operational> to become invalid?

If the client discards the message because of one bad value, then that doesn't seem to be helpful, since it allows for a very fragile model of system management.  I.e. if one small thing is bad then the whole house of cards collapses.

So I think that the only sensible behaviour here is that the client has to process the operational state update in a best effort fashion, keep all the good data and probably flag any values that are outside the value constraints.  Similarly any reference constraint failures (i.e. when/must) can similarly be flagged up, but throwing away an update message that would cause the operational state to become inconsistent doesn't seem to be helpful.  I.e. it is much better if the client gets to see the true state of the server, even if that state isn't good (or consistent).

Similar questions arise on the server itself:
 - what if the real value in use (e.g. that is read from the hardware) is outside the permitted range (because of a logic defect)?  Is it really better to suppress that value entirely or return a value that server knows to be wrong?
 - can a server even know that its operational view is consistent?  For complex systems where the real operational state is split across multiple underlying linecards, or remote devices, I think that this is very hard (if not impossible) to do.

So what the NMDA architecture states is:
 (i) if a server knows that it won't conform to the operational schema then it must use deviations,
 (ii) a server in a normal steady state should conform to the operational schema (and be valid),
 (iii) but, if the system is churning (e.g. configuration, route update, etc) then the operational state of the server might be transiently inconsistent and this is OK,
 (iv) if, the server is in a bad state, then it is better to return the actual state than to lie or not report a particular value (as long as it can be encoded).
 (v) a server does not need to explicitly validate that its view of operational is valid. It is unclear what it would/could do if it detected that the operational state is invalid, nor is it clear that servers would generally be able to always perform this operation.


The server implementation requirements expressed in YANG constraints
are applicable to any data node, not just config=true data nodes.
The requirement to implement the ancestor nodes (with keys) does not change.

The draft does not allow this to be violated.  I.e. the following statement prevents this: "Syntactic constraints MUST NOT be violated, including hierarchical organization".


The requirement to conform to the YANG constraints defined within config=false
data nodes does not change.

To do otherwise does not make sense.  E.g. "when" conditions that add ethernet
counters only when the interface type is ethernetCsmacd. Why would it be OK for
the server to ignore that when-stmt and add ethernet counters to every interface?

It is not OK for a server to ignore that and add Ethernet counters to every interface (without using a deviation).  The draft is not trying to allow that.

But if an interface could change type (e.g. between Ethernet and ATM via a different optics module being inserted) then it would be allowed for a server to transiently report the ethernet counters on the interface whilst it is in the process of changing the interface type from ethernet to ATM (e.g. if the counters are maintained by a separate daemon that is updated asynchronously with respect to the config or optics change).  Once the change had completed, the the system reaches steady state then the Ethernet counter must no longer be reported.

Thanks,
Rob



IMO the text above can only apply to the operational values of config=true nodes.


Thanks,
Rob


Andy
 


On 21/12/2017 22:49, Andy Bierman wrote:
Hi,

It should be clear somehow that server requirements to provide config=false data
that is valid according to the YANG definitions is not affected by NMDA.
That is not being taken away.  The ability to validate operational values
of configuration data has never been provided, and therefore is not being taken away either.

A constraint on config=true nodes only applies to configuration datastores.
These are the only constraints that should be ignored in <operational>.
Constraints on config=false nodes still apply in <operational>.


Andy



On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
> On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>
> > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
> > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > First point of clarification is that this is not about running/intended
> > > > at all.  The contents of running/intended do not change in anyway
> > > > depending on whether hardware is present or absent.
> > > >
> > > > The section is only concerned with how the configuration is applied in
> > > > operational, and basically says that you cannot apply configuration for
> > > > resources that are missing (which seems reasonable).  E.g. I cannot
> > > > configure an IP address on a physical interface that isn't there.  Or if
> > > > the physical interface gets removed then the configuration associated
> > > > with that interface is also removed from operational.
> > > >
> > > > Operational isn't validated and data model constraints are allowed to be
> > > > broken (ideally transiently).
> > > I want to focus on this. IMO giving up schema validitiy for any datastore is
> > > unacceptable price. Pre-NMDA devices had full model support in operational
> > > data (all YANG constrains part of the model without discrimination were
> > > enforced).
> > There was a long debate about the value of returning the true
> > operational state. What do you do if the operational state is invalid?
> > A server can reject configuration changes if they lead to invalid
> > state, a server can not reject reality.
> IMO if the model can represent reality then data conforming to the model
> can. If not a better model is needed not a hack that breaks the datastore
> conformance to the YANG model. I do not see how
> /interfaces/interface/oper-status=not-present was not representing the
> reality of a system with removed line card that is configured and ready to
> resume operation as soon as the line card is reconnected.

I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e., there is
operational state about them), you can report these interfaces.  But
'is configured' is confusing here. I am not sure a line card that does
not exist should be considered configured. But yes, this may be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.

> > > If this is about to change it will compromise interoperability
> > > and a significant portion of the client implementation workload that can be
> > > automated will need to be coded in hand and tested. Unresolved leafrefs,
> > > undefined behaviour of different implementations removing different
> > > configuration nodes in violation of YANG semantic constraints (which I do
> > > not think can be so clearly separated from the syntactic constraints when
> > > one considers types like leafref, instance-identifier etc.) and the
> > > corresponding side effects based on the server implementators own creativity
> > > is eventually going to create more problems.
> > >
> > > 1. IMO the only acceptable solution is to have YANG valid operational
> > > datastore at all times. operational like any other datastore MUST be valid
> > > YANG data tree and it has to be a system implementation task to consider all
> > > complications resulting from the removal of the resources leading to any
> > > data transformations. If this is difficult or impossible other mechanisms to
> > > flag missing resources should be used (e.g.
> > > /interfaces/interface/oper-status=not-present) This sounds like a useful
> > > contract providing the value of a standard the alternative does not.
> > As said above, it is impossible to report valid operational state if
> > the operational state is not valid according to the models.
> >
> > > 2. Even with the change in 1. I do not see the removal of intended
> > > configuration nodes from operational as a solution worth implementing on our
> > > servers. I do not see a real world plug-and-play scenario that can be
> > > automatically solved without specific additions to the models e.g.
> > > /interfaces/interface/oper-status=not-present is oversimplified solution but
> > > it needs to be extended exactly as much as the solution provided by the
> > > removal of config true; nodes without the sacrifice of YANG validity of
> > > operational.
> > Your thinking is likely wrong. <operational> reports the operational
> > state. It may have little in common with <intended>. Trying to derive
> > operational from intended is likely a not well working approach.
> The proposal for this solution ("derive operational from intended" e.g.
> merge /interfaces-state in /interfaces) comes from the revised datastores
> draft not me.
>
> By definition config true; data represents intent. Reusing the model of a
> config true; data to represent state absent of intent (e.g.
> /interfaces/interface with origin="or:system") is a hack. The hack works
> fine without compromising the conformance of operational to the YANG model
> as long as certain conditions are met. I am pointing out that one of the
> conditions is to keep all of the intended configuration data present in
> 'operational' and handle missing resources with conventional means e.g.
> /interfaces/interface/oper-status=not-present instead of adding the straw
> that breaks the camel's back.

I fail to see why you believe all objects that appear in intended
configuration needs to exist in applied configuration. In fact,
operators told us very clearly that they care about the distinction
between intended and applied config.

> > > 3. Solutions like /interfaces/interface/admin-state stop working. With the
> > > interface removed you can no longer figure if the if-mib has or does not
> > > have the interface enabled so an operator has to use SNMP or wait for a
> > > replacement line card to be connected to figure this bit of information.
> > At least on my boxes, if I remove a line card, the interface also
> > disappears in SNMP tables. Stuff that is operationally not present is
> > simply operationally not present.
> >
> > > My
> > > interpretation of the MAY as requirement level in sec. 5.3. The Operational
> > > State Datastore (<operational>) is that plug-and-play solutions can be
> > > implemented without this limited approach that has the same problem as the
> > > pre-NMDA only now we have to have /interfaces-state to keep config false;
> > > data relevant to hardware that is configured but not present:
> > >
> > >     configuration data nodes supported in a configuration datastore
> > >     MAY be omitted from <operational> if a server is not able to
> > >     accurately report them.
> > >
> > > I realize this discussion comes late. I have stated my objections to this
> > > particular part of the NMDA draft earlier.
> > I believe there is a conceptual misunderstanding. I think there never
> > was a requirement that a server reports the state of hardware that is
> > not present.
> "Data relevant to hardware that is configured but not present" is different
> from "state of hardware that is not present". For example information
> indicating when the line card became unavailable, what was the reason, or
> other information like how many packets that had this interface as egress
> destination are being dropped as a result of the removal.

I think that systems handle non-existing interfaces differently. It
seems that ietf-interfaces is flexible enough to accomodate the
differnet styles.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
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



--------------5028F0DD6D1EF7E68FF0ED6D-- From nobody Tue Jan 9 03:29: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 237101200FC for ; Tue, 9 Jan 2018 03:29:55 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NoBXlCWFQxqB for ; Tue, 9 Jan 2018 03:29:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 53E96126DEE for ; Tue, 9 Jan 2018 03:29:51 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id E03671AE0144; Tue, 9 Jan 2018 12:29:49 +0100 (CET) Date: Tue, 09 Jan 2018 12:28:07 +0100 (CET) Message-Id: <20180109.122807.1121028038684414186.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 11:29:55 -0000 Robert Wilton wrote: > Hi Andy, > = > = > On 08/01/2018 19:45, Andy Bierman wrote: > > > > > > On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton > > wrote: > > > > Hi Andy, > > > > Regarding your comment below, this intent is captured by this t= ext > > describing the operational datastore in section 5.3: > > > > SHOULD conform to any constraints specified i= n the > > data > > model, but given the principal aim of returning "in use" va= lues, it > > is possible that constraints MAY be violated under some > > circumstances, e.g., an abnormal value is "in use", the str= ucture of > > a list is being modified, or due to remnant configuration (= see > > Section 5.3.1). Note, that deviations SHOULD be used when = it is > > known in advance that a device does not fully conform to th= e > > schema. > > > > Only semantic constraints MAY be violated, these are the YA= NG > > "when", > > "must", "mandatory", "unique", "min-elements", and "max-ele= ments" > > statements; and the uniqueness of key values. > > > > Syntactic constraints MUST NOT be violated, including hiera= rchical > > organization, identifiers, and type-based constraints. If = a node in > > does not meet the syntactic constraints then = it MUST > > NOT be returned, and some other mechanism should be used to= flag the > > error. > > > > > > Do you agree that this is sufficient? > > > > > > > > Not really. > > It does not address my concern, which is that NMDA is > > removing the YANG constraints on config=3Dfalse data nodes > > for no apparent reason. > = > There is a reason. I don't think that the constraints on config=3Dfal= se > is really being removed, because I don't think that they truly existe= d > in the first place (despite what RFC 7950 might indicate!). I agree. But note that RFC 7950 says: o If the constraint is defined on state data, it MUST be true in a valid state data tree. It is not defined anywhere that must return a "valid state data tree". In reality, I suspect that all implementations of call various instrumentation call back functions in some order, possibly in parallell, which means that data will be collected at different times from the backend systems. I don't think it is feasible to freeze the operational state of a device, collect all data, and unfreeze, in order to get a consistent snapshot of the operational state. /martin > I think that we all agree on the expected behavior for configuration:= > If a client sends configuration to a server that would cause > to become invalid then the server should reject that change, to ensur= e > that always holds a consistent configuration.=A0 Having a > consistent configuration is the most important property here.=A0 > I.e. the server has the right to reject an invalid configuration > request from a client. > = > However, the flow of operational state data in opposite direction > cannot hold to the same rules.=A0 If during the processing of a get > request (or YANG push) a server sends operational state data back to = a > client then a client has to choose how to process the message: > =A0- if the message is garbled or not sane then it makes sense to > discard it. > =A0- however, what should the client do if the message is well formed= > but either (i) contains some values outside the permitted schema rang= e > (but can be represented by the schema datatype), or (ii) by applying > the values would cause the clients copy of to become > invalid? > = > If the client discards the message because of one bad value, then tha= t > doesn't seem to be helpful, since it allows for a very fragile model > of system management.=A0 I.e. if one small thing is bad then the whol= e > house of cards collapses. > = > So I think that the only sensible behaviour here is that the client > has to process the operational state update in a best effort fashion,= > keep all the good data and probably flag any values that are outside > the value constraints.=A0 Similarly any reference constraint failures= > (i.e. when/must) can similarly be flagged up, but throwing away an > update message that would cause the operational state to become > inconsistent doesn't seem to be helpful.=A0 I.e. it is much better if= > the client gets to see the true state of the server, even if that > state isn't good (or consistent). > = > Similar questions arise on the server itself: > =A0- what if the real value in use (e.g. that is read from the hardwa= re) > is outside the permitted range (because of a logic defect)?=A0 Is it > really better to suppress that value entirely or return a value that > server knows to be wrong? > =A0- can a server even know that its operational view is consistent? = For > complex systems where the real operational state is split across > multiple underlying linecards, or remote devices, I think that this i= s > very hard (if not impossible) to do. > = > So what the NMDA architecture states is: > =A0(i) if a server knows that it won't conform to the operational sch= ema > then it must use deviations, > =A0(ii) a server in a normal steady state should conform to the > operational schema (and be valid), > =A0(iii) but, if the system is churning (e.g. configuration, route > update, etc) then the operational state of the server might be > transiently inconsistent and this is OK, > =A0(iv) if, the server is in a bad state, then it is better to return= > the actual state than to lie or not report a particular value (as lon= g > as it can be encoded). > =A0(v) a server does not need to explicitly validate that its view of= > operational is valid. It is unclear what it would/could do if it > detected that the operational state is invalid, nor is it clear that > servers would generally be able to always perform this operation. > = > > > > The server implementation requirements expressed in YANG constraint= s > > are applicable to any data node, not just config=3Dtrue data nodes.= > > The requirement to implement the ancestor nodes (with keys) does no= t > > change. > = > The draft does not allow this to be violated.=A0 I.e. the following > statement prevents this: "Syntactic constraints MUST NOT be violated,= > including hierarchical organization". > = > = > > The requirement to conform to the YANG constraints defined within > > config=3Dfalse > > data nodes does not change. > > > > To do otherwise does not make sense.=A0 E.g. "when" conditions that= add > > ethernet > > counters only when the interface type is ethernetCsmacd. Why would = it > > be OK for > > the server to ignore that when-stmt and add ethernet counters to ev= ery > > interface? > = > It is not OK for a server to ignore that and add Ethernet counters to= > every interface (without using a deviation).=A0 The draft is not tryi= ng > to allow that. > = > But if an interface could change type (e.g. between Ethernet and ATM > via a different optics module being inserted) then it would be allowe= d > for a server to transiently report the ethernet counters on the > interface whilst it is in the process of changing the interface type > from ethernet to ATM (e.g. if the counters are maintained by a > separate daemon that is updated asynchronously with respect to the > config or optics change).=A0 Once the change had completed, the the > system reaches steady state then the Ethernet counter must no longer > be reported. > = > Thanks, > Rob > = > = > > > > IMO the text above can only apply to the operational values of > > config=3Dtrue nodes. > > > > > > Thanks, > > Rob > > > > > > > > Andy > > > > > > > > On 21/12/2017 22:49, Andy Bierman wrote: > >> Hi, > >> > >> It should be clear somehow that server requirements to provide= > >> config=3Dfalse data > >> that is valid according to the YANG definitions is not affecte= d > >> by NMDA. > >> That is not being taken away.=A0 The ability to validate > >> operational values > >> of configuration data has never been provided, and therefore i= s > >> not being taken away either. > >> > >> A constraint on config=3Dtrue nodes only applies to configurat= ion > >> datastores. > >> These are the only constraints that should be ignored in > >> . > >> Constraints on config=3Dfalse nodes still apply in . > >> > >> > >> Andy > >> > >> > >> > >> On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder > >> >> > wrote: > >> > >> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassile= v > >> wrote: > >> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: > >> > > >> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir > >> Vassilev wrote: > >> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: > >> > > > > >> > > > > Hi Vladimir, > >> > > > > > >> > > > > First point of clarification is that this is not > >> about running/intended > >> > > > > at all.=A0 The contents of running/intended do not= > >> change in anyway > >> > > > > depending on whether hardware is present or absent= .= > >> > > > > > >> > > > > The section is only concerned with how the > >> configuration is applied in > >> > > > > operational, and basically says that you cannot ap= ply > >> configuration for > >> > > > > resources that are missing (which seems reasonable= ).=A0 > >> E.g. I cannot > >> > > > > configure an IP address on a physical interface th= at > >> isn't there.=A0 Or if > >> > > > > the physical interface gets removed then the > >> configuration associated > >> > > > > with that interface is also removed from operation= al. > >> > > > > > >> > > > > Operational isn't validated and data model > >> constraints are allowed to be > >> > > > > broken (ideally transiently). > >> > > > I want to focus on this. IMO giving up schema validi= tiy > >> for any datastore is > >> > > > unacceptable price. Pre-NMDA devices had full model > >> support in operational > >> > > > data (all YANG constrains part of the model without > >> discrimination were > >> > > > enforced). > >> > > There was a long debate about the value of returning t= he true > >> > > operational state. What do you do if the operational > >> state is invalid? > >> > > A server can reject configuration changes if they lead= to > >> invalid > >> > > state, a server can not reject reality. > >> > IMO if the model can represent reality then data conform= ing > >> to the model > >> > can. If not a better model is needed not a hack that bre= aks > >> the datastore > >> > conformance to the YANG model. I do not see how > >> > /interfaces/interface/oper-status=3Dnot-present was not > >> representing the > >> > reality of a system with removed line card that is > >> configured and ready to > >> > resume operation as soon as the line card is reconnected= .= > >> > >> I assume this is all system and implementation specific. I= f your > >> system knows about interfaces that are not present (i.e., > >> there is > >> operational state about them), you can report these > >> interfaces.=A0 But > >> 'is configured' is confusing here. I am not sure a line ca= rd > >> that does > >> not exist should be considered configured. But yes, this m= ay > >> be system > >> specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt stil= l has > >> oper-status 'not-present' - so this seems to be a mood poi= nt. > >> > >> > > > If this is about to change it will compromise > >> interoperability > >> > > > and a significant portion of the client implementati= on > >> workload that can be > >> > > > automated will need to be coded in hand and tested. > >> Unresolved leafrefs, > >> > > > undefined behaviour of different implementations > >> removing different > >> > > > configuration nodes in violation of YANG semantic > >> constraints (which I do > >> > > > not think can be so clearly separated from the > >> syntactic constraints when > >> > > > one considers types like leafref, instance-identifie= r > >> etc.) and the > >> > > > corresponding side effects based on the server > >> implementators own creativity > >> > > > is eventually going to create more problems. > >> > > > > >> > > > 1. IMO the only acceptable solution is to have YANG > >> valid operational > >> > > > datastore at all times. operational like any other > >> datastore MUST be valid > >> > > > YANG data tree and it has to be a system implementat= ion > >> task to consider all > >> > > > complications resulting from the removal of the > >> resources leading to any > >> > > > data transformations. If this is difficult or > >> impossible other mechanisms to > >> > > > flag missing resources should be used (e.g. > >> > > > /interfaces/interface/oper-status=3Dnot-present) Thi= s > >> sounds like a useful > >> > > > contract providing the value of a standard the > >> alternative does not. > >> > > As said above, it is impossible to report valid > >> operational state if > >> > > the operational state is not valid according to the mo= dels. > >> > > > >> > > > 2. Even with the change in 1. I do not see the remov= al > >> of intended > >> > > > configuration nodes from operational as a solution > >> worth implementing on our > >> > > > servers. I do not see a real world plug-and-play > >> scenario that can be > >> > > > automatically solved without specific additions to t= he > >> models e.g. > >> > > > /interfaces/interface/oper-status=3Dnot-present is > >> oversimplified solution but > >> > > > it needs to be extended exactly as much as the solut= ion > >> provided by the > >> > > > removal of config true; nodes without the sacrifice = of > >> YANG validity of > >> > > > operational. > >> > > Your thinking is likely wrong. reports t= he > >> operational > >> > > state. It may have little in common with . > >> Trying to derive > >> > > operational from intended is likely a not well working= > >> approach. > >> > The proposal for this solution ("derive operational from= > >> intended" e.g. > >> > merge /interfaces-state in /interfaces) comes from the > >> revised datastores > >> > draft not me. > >> > > >> > By definition config true; data represents intent. Reusi= ng > >> the model of a > >> > config true; data to represent state absent of intent (e= .g. > >> > /interfaces/interface with origin=3D"or:system") is a ha= ck. > >> The hack works > >> > fine without compromising the conformance of operational= to > >> the YANG model > >> > as long as certain conditions are met. I am pointing out= > >> that one of the > >> > conditions is to keep all of the intended configuration > >> data present in > >> > 'operational' and handle missing resources with > >> conventional means e.g. > >> > /interfaces/interface/oper-status=3Dnot-present instead = of > >> adding the straw > >> > that breaks the camel's back. > >> > >> I fail to see why you believe all objects that appear in i= ntended > >> configuration needs to exist in applied configuration. In = fact, > >> operators told us very clearly that they care about the > >> distinction > >> between intended and applied config. > >> > >> > > > 3. Solutions like /interfaces/interface/admin-state > >> stop working. With the > >> > > > interface removed you can no longer figure if the > >> if-mib has or does not > >> > > > have the interface enabled so an operator has to use= > >> SNMP or wait for a > >> > > > replacement line card to be connected to figure this= > >> bit of information. > >> > > At least on my boxes, if I remove a line card, the > >> interface also > >> > > disappears in SNMP tables. Stuff that is operationally= > >> not present is > >> > > simply operationally not present. > >> > > > >> > > > My > >> > > > interpretation of the MAY as requirement level in se= c. > >> 5.3. The Operational > >> > > > State Datastore () is that plug-and-pla= y > >> solutions can be > >> > > > implemented without this limited approach that has t= he > >> same problem as the > >> > > > pre-NMDA only now we have to have /interfaces-state = to > >> keep config false; > >> > > > data relevant to hardware that is configured but not= > >> present: > >> > > > > >> > > >=A0 =A0=A0 configuration data nodes supported in a > >> configuration datastore > >> > > >=A0 =A0=A0 MAY be omitted from if a ser= ver is > >> not able to > >> > > >=A0 =A0=A0 accurately report them. > >> > > > > >> > > > I realize this discussion comes late. I have stated = my > >> objections to this > >> > > > particular part of the NMDA draft earlier. > >> > > I believe there is a conceptual misunderstanding. I th= ink > >> there never > >> > > was a requirement that a server reports the state of > >> hardware that is > >> > > not present. > >> > "Data relevant to hardware that is configured but not > >> present" is different > >> > from "state of hardware that is not present". For exampl= e > >> information > >> > indicating when the line card became unavailable, what w= as > >> the reason, or > >> > other information like how many packets that had this > >> interface as egress > >> > destination are being dropped as a result of the removal= .= > >> > >> I think that systems handle non-existing interfaces > >> differently. It > >> seems that ietf-interfaces is flexible enough to accomodat= e the > >> differnet styles. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs Univers= ity Bremen gGmbH > >> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1 | = 28759 Bremen > >> | Germany > >> Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 > >> =A0 >> > > >> > >> _______________________________________________ > >> 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 Tue Jan 9 04:09: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 AC23A127342; Tue, 9 Jan 2018 04:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 YklwmbVs62Iz; Tue, 9 Jan 2018 04:09:06 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 B826C126DEE; Tue, 9 Jan 2018 04:09:06 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id d21so7203534qkj.3; Tue, 09 Jan 2018 04:09:06 -0800 (PST) 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=xMi5a9GRMeki/0Vy7Acui3h/SwdOG0DFOvxNw5Pg9C8=; b=bvpKFvaCSQUVHGE+7JLN9L/nPbzejJJO5MvA+GCROBmDagMnw3MBssjZCnPAlzXfSi ez37jU+fpKfVBHB6TqrNGk24XGW4N3oOIYTqBNZ2KJ0zcQPBbnFWdKrLXEB4yrzUbDRD w25834HXYLbqXHIuwfB8hX0pMfPqbQxmeIHlc5/0jkS+EPBt4VOfDETts4wrkBf+0XG6 y90wnX1rco9G6t6GzXyptmBeIVAJEN7ktOwXncVhgjhycz8n58m6KPP6G2Qz2hIYRpSq JefzOJeCRAXrZxnBjq1TLpWMC7o9o2Z9hmBQyg8ob672tk7AGiqXQfa1DHoWzc+W/SPL i1gw== 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=xMi5a9GRMeki/0Vy7Acui3h/SwdOG0DFOvxNw5Pg9C8=; b=WC0W0lR+1okBFAwz2RGakQSQORLqLH3Iuydc4ryb4vLqguNZzVF8JeNR89NpzO4CFK qyj/d/I2SgpRJdERk8/6t/cvmQEB2afqWAnryjYne1kLdEIEsnwCtMX6Toc0FdzB/0Vt a5vR+JyCcG4Lm56WI6NVZTq8arUxptPwpyaVheFs8gzOQu1gEAzefn50jkvTGGZFh4IG cd8ujjN31cppd1443gT3V+s4JplCae12udaHwquD+Ph06KCszsjhQBkFR03VWfaoBSHm Yx4xBvlhJlLL8D8LPLdos1yImp/e1UkOC+3phtmCRxAqT3aDN1XD56x9bpX4Tx3CA5IS 6M2g== X-Gm-Message-State: AKwxytebbk5vy3//TNd7dsqmKvj234fOQ90mCjIdJGvFQ4ipCdIsOoMc rswmK4bzAoRZmPbUbdbzQSbG8+Cl X-Google-Smtp-Source: ACJfBotbzdjrdbwpOYUMSWq0n81kDZkWZ8ZExMqCf2/IUvjjj8LFt5l2F/kl31KsScxwVdwbwAsacg== X-Received: by 10.55.220.2 with SMTP id v2mr628149qki.16.1515499745565; Tue, 09 Jan 2018 04:09:05 -0800 (PST) Received: from [10.111.222.219] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id j4sm8965317qtk.15.2018.01.09.04.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 04:09:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15C153) In-Reply-To: <4000af84-77c5-1b57-a0da-23aa735ce38d@cisco.com> Date: Tue, 9 Jan 2018 07:09:03 -0500 Cc: Martin Bjorklund , netmod-chairs@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, iesg@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151544838502.11225.12200905325785852409.idtracker@ietfa.amsl.com> <20180109.082711.971204319569734613.mbj@tail-f.com> <4000af84-77c5-1b57-a0da-23aa735ce38d@cisco.com> To: Benoit Claise Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 12:09:09 -0000 Sent from my mobile device > On Jan 9, 2018, at 2:40 AM, Benoit Claise wrote: >=20 >> On 1/9/2018 8:27 AM, Martin Bjorklund wrote: >> Hi, >>=20 >> Kathleen Moriarty wrote: >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> Hello, >>>=20 >>> I'm a little confused on the Security Consideration section as it doesn'= t use >>> the latest template, but does specify SSH for NETCONF, so I'm good with t= hat >>> part. Will RESTCONF also be used as a transport or is there some reason= it >>> won't be used for this YANG module? >>>=20 >>> Here's what I think is the latest template and please let me know if sec= tions >>> of it do not apply to this draft and I'll drop the discuss for correctin= g the >>> security considerations section. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 >> I have updated to the latest version in my local copy. > Thanks Martin. > The IETF LC finishes today. So please post a new version tomorrow. Thank you, all. I=E2=80=99ll clear once posted. Best regards, Kathleen=20 >=20 > Regards, B. >>=20 >>=20 >> /martin >>=20 >> . >>=20 >=20 From nobody Tue Jan 9 04:12: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 EB7F6127342; Tue, 9 Jan 2018 04:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 zSvqzsp9TfDG; Tue, 9 Jan 2018 04:12:14 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 EC3EC126DEE; Tue, 9 Jan 2018 04:12:13 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id o126so18182777qke.12; Tue, 09 Jan 2018 04:12:13 -0800 (PST) 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=6DtpuKbD+0eaHF9F+214eMFtATcg8iZDz9FjrPJ2EaA=; b=oB1vQXXxIF8eEUNQSo4rff0qCe4ePFnRCKy7DPXiFRXga1CYb2lpMtCdz1yq7RHNHG Yylohl7HKmgqOT3YpFBY9ZBVPl1QTBsA4K4rmIyG/vnsMz6XB4MD1+EmRN4LhAwvzfN9 5Z+igCvWWpY2ARjalllFHzpaMP+wmXmXXqJOS0/k6C/wj4Uv6TnTsrhPAqU6rIgnHw3a ywfBTl045LevXQcuczBtQgqv78AOjGmDurOqG7LC0LYrcRoboO9OjkLI8zuo4aDa+tN3 /qRQw7B3dBImjyZ062D/NHoDONQkDJLSMcY4I7rpzQEWfiKySM0sqPehwJdEJ75s3tTn qyjw== 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=6DtpuKbD+0eaHF9F+214eMFtATcg8iZDz9FjrPJ2EaA=; b=mb35GLPhUcbF31fK4XqtwumHcqoJ/MZJRnBpQ7y5Lu2Yw3aB3VcwPmy6XDUWw84NxT 0QiQ6n+WbJs8NqH1wJJ5zEiwQpdOyQT8PqHbFlWCCtEMd3JkHmmEiWHviUCSGbtNMXFH ukr9Rk6BVjBkIsfSHBk3k5Y6LGUEgi6bHbqhrHDxS6zoUi/aR39LE8g8CjEWRbVXZoxC m5cebnZEwrNuPaHxdPqyJ4riAklgX9dDIDNCXOgJhhx1VSmD45yTvZsiBqwd7i26XI+A xHWwfVuIf9OSwNoZAJsr3lBPUPUjGW82CwdnikCfzJX21jw+q8yo2fmp+kAbL7H9J7Te Q4Ag== X-Gm-Message-State: AKwxytdGIQREF42QFKBvjcnlIrXsrQsuKs9HWhTHavYRXi9yn8z9Kdde sU5IR+nAgLrHPruYcQdz65RW5UJa X-Google-Smtp-Source: ACJfBouugsUcZNZNQUKNdfnLIQuybA2MLsEXhzZ9ktYDBzNAGeqk+I0ShRx8l9v2cY2uQCepw2ziFA== X-Received: by 10.55.43.99 with SMTP id r96mr22008831qkh.169.1515499932483; Tue, 09 Jan 2018 04:12:12 -0800 (PST) Received: from [10.111.222.219] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id f34sm8771299qtb.63.2018.01.09.04.12.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 04:12:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15C153) In-Reply-To: <20180109.082636.1242827908143886439.mbj@tail-f.com> Date: Tue, 9 Jan 2018 07:12:11 -0500 Cc: iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-rfc7223bis@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151544808841.11217.4534109694790942374.idtracker@ietfa.amsl.com> <20180109.082636.1242827908143886439.mbj@tail-f.com> To: Martin Bjorklund Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7223bis-01: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 12:12:16 -0000 Sent from my mobile device > On Jan 9, 2018, at 2:26 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Kathleen Moriarty wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Hello, >>=20 >> Thanks for your work on this draft. It appears an older version of the >> Security Considerations template was used. Could you please update to th= e >> current version that adds in transport security and other considerations?= I >> believe this is the latest version, but Benoit can confirm. >>=20 >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52 >=20 > I have updated to the latest version in my local copy. >=20 Thank you, Martin. I=E2=80=99ll clear once it is posted. Best regards, Kathleen=20 >=20 > /martin >=20 From nobody Tue Jan 9 06:39: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 050A612D86E for ; Tue, 9 Jan 2018 06:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwpDcMymaNvY for ; Tue, 9 Jan 2018 06:39:01 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0096.outbound.protection.outlook.com [104.47.1.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C1712D86A for ; Tue, 9 Jan 2018 06:39:01 -0800 (PST) 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; bh=EymY31/jumfGgsDvRVrMaP3KFZNx6yh0KMJEQeJ8bdQ=; b=PL+qZtTGn1ZMbLIlW9haMz4PtV0U6f/bey7KuNv/PFh8Vd46Fja3FIM3sN+j9fiG0xnfjOXAeglhkQivXSsHYLfA4XkGCvA3N8ECZDNqd42VUOjCPCfIvUW/VYPsvXY6p+4fcjcmG3YccMNooegJyiyvBo5v1442XVRi6RDqf9E= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB3457.eurprd07.prod.outlook.com (10.171.190.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.1; Tue, 9 Jan 2018 14:38:58 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0%14]) with mapi id 15.20.0407.005; Tue, 9 Jan 2018 14:38:58 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Robert Wilton , Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-entity-06 Thread-Index: AQHTeZsGj/By4wgWGkSTA5QT6Ag4U6NN6XKHgBw2jXA= Date: Tue, 9 Jan 2018 14:38:57 +0000 Message-ID: References: <20171220.160020.956270997417344353.mbj@tail-f.com> <20171221.123746.382540578845045602.mbj@tail-f.com> <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com> In-Reply-To: <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3457; 7:EnNXQ/kYONiTC6fkWiLq506TCdsKNPx1qk0/UCuaej7sD3LqOQsCjwBx2Ec2wyUvNj8yuYo3T3zg4sy7tX8RKSSmb4+n1qgr0J6hPnctQQZ+dCp/qDd0Ukkhpoqb8F56+GRr9y0kBxJ98jd3iRCSvXSXSLTHpLjED7sdsvR+uFTY5I/TU9BC83tImzphC8wPy4JNYXCmUqxFzjGT8YvUcHRX3d7EoajrSGLSwwj95i0L96DN2jjoAJNZfMxm+kmD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 37c899da-2b11-475c-df28-08d5576eb790 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB3457; x-ms-traffictypediagnostic: AM4PR07MB3457: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(11241501184)(806099)(944501075)(10201501046)(6055026)(6041268)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB3457; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3457; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(39860400002)(396003)(346002)(51444003)(13464003)(199004)(189003)(40224003)(24454002)(106356001)(102836004)(3846002)(9686003)(25786009)(5660300001)(68736007)(59450400001)(6116002)(7696005)(53546011)(55016002)(97736004)(105586002)(6306002)(6246003)(86362001)(93886005)(305945005)(81156014)(81166006)(76176011)(6506007)(14454004)(99286004)(2906002)(53936002)(66066001)(8936002)(3280700002)(6436002)(7736002)(230783001)(74316002)(966005)(2501003)(5250100002)(2900100001)(2950100002)(8676002)(3660700001)(33656002)(110136005)(229853002)(478600001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3457; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pDwWtYgtzS1gxDA0BWOkpTxu5nq8VSmvbg/q40N3TF5caaGRdTjj2XH7sQhYVGupeUIQOk50A+wm1OU7nEGs5js9tRULo3GWYbnTZxgijVnqNbMOh5GCWQ3YONfa9xPP spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37c899da-2b11-475c-df28-08d5576eb790 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 14:38:57.9755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3457 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 14:39:04 -0000 SGkgTWFydGluLA0KDQpXZSBoYWQgYSBkaXNjdXNzaW9uIG9uIHRoaXMgYW5kIHdlIGhhdmUgc29t ZSBjb25jZXJucyBhYm91dCBiZWxvdyBzdGF0ZW1lbnQgKGJlaGF2aW9yIGluIHRoZSBkZXNjcmlw dGlvbiBzdGF0ZW1lbnQpOg0KDQo+ICAgIFRoaXMgbGVhZiBjYW4gYmUgY29uZmlndXJlZC4gIFRo ZSBjb25maWd1cmVkIHZhbHVlIGlzIHVzZWQgb25seSBpZg0KPiAgICB0aGUgc2VydmVyIGNhbm5v dCBkZXRlcm1pbmUgdGhlIHZlbmRvci1zcGVjaWZpYyBzZXJpYWwgbnVtYmVyIGZyb20NCj4gICAg dGhlIGNvbXBvbmVudCBpdHNlbGYuDQoNCkZvciB0aGUgYWJvdmUgc2VudGVuY2Ug4oCcc2VydmVy IGNhbm5vdCBkZXRlcm1pbmXigJ0gd2UgaGF2ZSAyIGNhc2VzOg0KMS4JSXQgY2Fu4oCZdCBiZSBk ZXRlcm1pbmVkIGJlY2F1c2UgdGhlcmUgaXMgbm90aGluZyBkZXRlY3RlZC4gIEFjY29yZGluZyB0 byB0aGUgTk1EQS1kcmFmdCBpdCBpcyBjbGVhciB0aGF0IGluIHRoaXMgY2FzZSB0aGVyZSBpcyBu byByb3cgZm9yIHRoZSBhc3NvY2lhdGVkIGNvbXBvbmVudCBhbmQgaGVuY2Ugbm8gZGF0YS4gIEkg dGhpbmsgdGhpcyBjYXNlIGlzIGNvdmVyZWQgYnkgdGhlIHNlbnRlbmNlIGluIHRoZSBsYXRlc3Qg ZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGZvciB0aGUgbGlzdCDigJxjb21wb25lbnTigJ0gd2hl cmUgaXQgaXMgc3RhdGVkOiDigJxXaGVuIHRoZSBzZXJ2ZXIgZGV0ZWN0cyBhIG5ldyBoYXJkd2Fy ZSBjb21wb25lbnQsIGl0IGluaXRpYWxpemVzIGEgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9u YWwgc3RhdGUu4oCdLCBzbyB0aGUgYWJvdmUgc2VudGVuY2Ugb25seSBhcHBsaWVzIGZvciB0aGUg c2Vjb25kIGNhc2UgYmVsb3cuDQoyLglUaGUgc2Vjb25kIGNhc2UgaXMgdGhhdCBzb21ldGhpbmcg aXMgZGV0ZWN0ZWQgYnV0IGl0IGNhbuKAmXQgYmUgcmVhZC4gIFdlIGRvIG5vdCBzZWUgYSByZWFz b24gdG8gdXNlIHRoZSB2YWx1ZSBjb25maWd1cmVkIGZvciB0aGUgbGVhZnMg4oCYc2VyaWFsLW51 beKAmSwg4oCYbWZnLW5hbWXigJkgYW5kIOKAmG1vZGVsLW5hbWXigJkgb2YgYSBtYXRjaGluZyBl bnRyeSBpbiB0aGUgY29uZmlndXJhdGlvbiBkYXRhLiAgVGhlc2UgbGVhZnMgYXJlIGRlZmluZWQg YXMgb3B0aW9uYWwgc28gd2h5IHdvdWxkIHdlIHJlcG9ydCBzb21ldGhpbmcgZW50ZXJlZCBieSBh biBvcGVyYXRvciBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byBy ZXBvcnQgb24gd2hhdCBpcyBkZXRlY3RlZD8gIElzIGl0IG5vdCBiZXR0ZXIgdG8gbm90IHJlcG9y dCB0aGVtIGF0IGFsbD8gIEluIGFuIE5NREEgY29udGV4dCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0 byBoYXZlIGEgZGlmZmVyZW50IHZhbHVlIChvciBubyB2YWx1ZSBhdCBhbGwpIGZvciBjZXJ0YWlu IGxlYWZzIHdoaWxlIHRoZXJlIGlzIHNvbWV0aGluZyBpbiB0aGUgcnVubmluZy9pbnRlbmRlZCBk YXRhc3RvcmUuDQoNCkJlc3QgcmVnYXJkcywgQmFydA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSb2JlcnQgV2lsdG9uDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjEsIDIwMTcg NDoxNCBQTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsgbmV0bW9kQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0 bW9kLWVudGl0eS0wNg0KDQpIaSBNYXJ0aW4sDQoNCg0KT24gMjEvMTIvMjAxNyAxMTozNywgTWFy dGluIEJqb3JrbHVuZCB3cm90ZToNCj4gSGksDQo+DQo+IEkgbmVlZCBXRyBpbnB1dCBvbiB0aGlz IGlzc3VlLiAgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBoYW5kbGUgDQo+ICdzZXJpYWwtbnVtJywg J21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJy4gIEkgdGhpbmsgdGhleSBzaG91bGQgYWxsIA0K PiBiZSB0cmVhdGVkIHRoZSBzYW1lLiAgQmFzZWQgb24gcHJldmlvdXMgV0cgZGlzY3Vzc2lvbiAo c2VlIGUuZy4gdGhlIA0KPiBtYWlsIHRocmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlz c3VlICMxMyIpLCBJIHRoaW5rIHRoZXkgc2hvdWxkIA0KPiBhbGwgYmUgY29uZmlndXJhYmxlLCBi dXQgdGhlIGNvbmZpZ3VyZWQgdmFsdWUgaXMgb25seSB1c2VkIGluIA0KPiBvcGVyYXRpb25hbCBz dGF0ZSBpZiB0aGUgc3lzdGVtIGNhbm5vdCByZWFkIGl0IGZyb20gdGhlIGhhcmR3YXJlLg0KSSB0 aGluayB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgcHJvYmFibHkgT0s6DQogwqAtIFRoZSBjbGllbnQg Y2FuIGFsd2F5cyBzZWUgdGhlIHJlYWwgdmFsdWUgaWYgaXQgaXMgYXZhaWxhYmxlLg0KIMKgLSBJ ZiBpdCBpcyBub3QgYXZhaWxhYmxlIHRoZW4gdGhleSBjYW4gYXNzaWduIGEgdmFsdWUgdmlhIGNv bmZpZ3VyYXRpb24uDQoNCkkgd2FzIGFsc28gY29uc2lkZXJpbmcgYW4gYWx0ZXJuYXRpdmUgYXBw cm9hY2ggb2YgaGF2aW5nIGEgc2VwYXJhdGUgc2V0IG9mIGNvbmZpZyBmYWxzZSBsZWF2ZXMgZm9y IHRoZSAiYnVybnQgaW4gdmFsdWVzIi7CoCBBbmQgdGhlbiBoYXZpbmcgdGhlIGNvbmZpZ3VyYWJs ZSBsZWF2ZXMgYWx3YXlzIG92ZXJyaWRlIHRoZSBkZWZhdWx0IG9wZXJhdGlvbmFsIHZhbHVlcy4g RS5nLiBzaW1pbGFyIHRvIGhvdyBhbiBpbnRlcmZhY2UgTUFDIGFkZHJlc3Mgd291bGQgZXhwZWN0 IHRvIGJlIGhhbmRsZWQuDQoNCkJ1dCBvbmUgc2V0IG9mIGxlYXZlcyBpcyBwcm9iYWJseSBzdWZm aWNpZW50Lg0KDQpUaGFua3MsDQpSb2INCg0KDQo+DQo+IFNvIEkgc3VnZ2VzdCB0aGUgZm9sbG93 aW5nIGNoYW5nZXM6DQo+DQo+IE9MRDoNCj4NCj4gICAgICAgIGxlYWYgc2VyaWFsLW51bSB7DQo+ ICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiAgICAgICAgICBjb25maWcgZmFsc2U7DQo+ICAgICAg ICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgIlRoZSB2ZW5kb3Itc3BlY2lmaWMgc2VyaWFs IG51bWJlciBzdHJpbmcgZm9yIHRoZQ0KPiAgICAgICAgICAgICBjb21wb25lbnQuICBUaGUgcHJl ZmVycmVkIHZhbHVlIGlzIHRoZSBzZXJpYWwgbnVtYmVyDQo+ICAgICAgICAgICAgIHN0cmluZyBh Y3R1YWxseSBwcmludGVkIG9uIHRoZSBjb21wb25lbnQgaXRzZWxmIChpZg0KPiAgICAgICAgICAg ICBwcmVzZW50KS4iOw0KPiAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzOiBlbnRQaHlzaWNh bFNlcmlhbE51bSI7DQo+ICAgICAgICB9DQo+DQo+IE5FVzoNCj4NCj4gICAgICAgIGxlYWYgc2Vy aWFsLW51bSB7DQo+ICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiAgICAgICAgICBkZXNjcmlwdGlv bg0KPiAgICAgICAgICAgICJUaGUgdmVuZG9yLXNwZWNpZmljIHNlcmlhbCBudW1iZXIgc3RyaW5n IGZvciB0aGUNCj4gICAgICAgICAgICAgY29tcG9uZW50LiAgVGhlIHByZWZlcnJlZCB2YWx1ZSBp cyB0aGUgc2VyaWFsIG51bWJlcg0KPiAgICAgICAgICAgICBzdHJpbmcgYWN0dWFsbHkgcHJpbnRl ZCBvbiB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4gICAgICAgICAgICAgcHJlc2VudCkuDQo+ DQo+ICAgICAgICAgICAgIFRoaXMgbGVhZiBjYW4gYmUgY29uZmlndXJlZC4gIFRoZXJlIGFyZSB0 d28gdXNlIGNhc2VzIGZvcg0KPiAgICAgICAgICAgICB0aGlzOyBhcyBhICdwb3N0LWl0JyBub3Rl IGlmIHRoZSBzZXJ2ZXIgY2Fubm90IGRldGVybWluZQ0KPiAgICAgICAgICAgICB0aGlzIHZhbHVl IGZyb20gdGhlIGNvbXBvbmVudCwgb3Igd2hlbiBwcmUtcHJvdmlzaW9uaW5nIGENCj4gICAgICAg ICAgICAgY29tcG9uZW50Lg0KPg0KPiAgICAgICAgICAgICBJZiB0aGUgc2VydmVyIGNhbiBkZXRl cm1pbmUgdGhlIHNlcmlhbCBudW1iZXIgZnJvbSB0aGUNCj4gICAgICAgICAgICAgY29tcG9uZW50 LCB0aGVuIHRoYXQgdmFsdWUgaXMgYWx3YXlzIHVzZWQgaW4gb3BlcmF0aW9uYWwNCj4gICAgICAg ICAgICAgc3RhdGUsIGV2ZW4gaWYgYW5vdGhlciB2YWx1ZSBoYXMgYmVlbiBjb25maWd1cmVkLiI7 DQo+ICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6IGVudFBoeXNpY2FsU2VyaWFsTnVtIjsN Cj4gICAgICAgIH0NCj4NCj4gQW5kIGNvcnJlc3BvbmRpbmcgdGV4dCBmb3IgJ21mZy1uYW1lJyBh bmQgJ21vZGVsLW5hbWUnLg0KPg0KPiBBbmQgYWxzbzoNCj4NCj4gT0xEOg0KPg0KPiAgICAgICAg ICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9uZW50LCBpdA0K PiAgICAgICAgICAgaW5pdGlhbGl6ZXMgYSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBz dGF0ZS4NCj4NCj4gICAgICAgICAgIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBjb25m aWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ICAgICAgICAgICBjb21wb25lbnRzLCBsaXN0IGVudHJp ZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGFyZQ0KPiAgICAgICAgICAgaW5pdGlhbGl6ZWQg d2l0aCB2YWx1ZXMgZm9yIGFsbCBub2RlcyBhcyBkZXRlY3RlZCBieSB0aGUNCj4gICAgICAgICAg IGltcGxlbWVudGF0aW9uLg0KPg0KPiAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5n IHByb2NlZHVyZSBpcyBmb2xsb3dlZDoNCj4NCj4gICAgICAgICAgICAgMS4gSWYgdGhlcmUgaXMg YW4gZW50cnkgaW4gdGhlIC9oYXJkd2FyZS9jb21wb25lbnQgbGlzdCBpbg0KPiAgICAgICAgICAg ICAgICB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiB3aXRoIHZhbHVlcyBmb3IgdGhlIG5vZGVz DQo+ICAgICAgICAgICAgICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRo YXQgYXJlIGVxdWFsIHRvDQo+ICAgICAgICAgICAgICAgIHRoZSBkZXRlY3RlZCB2YWx1ZXMsIHRo ZW46DQo+DQo+ICAgICAgICAgICAgIDFhLiBJZiB0aGUgY29uZmlndXJlZCBlbnRyeSBoYXMgYSB2 YWx1ZSBmb3IgJ21mZy1uYW1lJw0KPiAgICAgICAgICAgICAgICAgdGhhdCBpcyBlcXVhbCB0byB0 aGUgZGV0ZWN0ZWQgdmFsdWUsIG9yIGlmIHRoZQ0KPiAgICAgICAgICAgICAgICAgJ21mZy1uYW1l JyB2YWx1ZSBjYW5ub3QgYmUgZGV0ZWN0ZWQsIHRoZW4gdGhlIGxpc3QNCj4gICAgICAgICAgICAg ICAgIGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcyBpbml0aWFsaXplZCB3aXRoIHRo ZQ0KPiAgICAgICAgICAgICAgICAgY29uZmlndXJlZCB2YWx1ZXMgZm9yIGFsbCBjb25maWd1cmVk IG5vZGVzLCBpbmNsdWRpbmcNCj4gICAgICAgICAgICAgICAgIHRoZSAnbmFtZScuDQo+DQo+ICAg ICAgICAgICAgICAgICBPdGhlcndpc2UsIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25h bCBzdGF0ZSBpcw0KPiAgICAgICAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9y IGFsbCBub2RlcyBhcyBkZXRlY3RlZCBieQ0KPiAgICAgICAgICAgICAgICAgdGhlIGltcGxlbWVu dGF0aW9uLiAgVGhlIGltcGxlbWVudGF0aW9uIG1heSByYWlzZSBhbg0KPiAgICAgICAgICAgICAg ICAgYWxhcm0gdGhhdCBpbmZvcm1zIGFib3V0IHRoZSAnbWZnLW5hbWUnIG1pc21hdGNoDQo+ICAg ICAgICAgICAgICAgICBjb25kaXRpb24uICBIb3cgdGhpcyBpcyBkb25lIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mDQo+ICAgICAgICAgICAgICAgICB0aGlzIGRvY3VtZW50Lg0KPg0KPiAgICAgICAg ICAgICAxYi4gT3RoZXJ3aXNlIChpLmUuLCB0aGVyZSBpcyBubyBtYXRjaGluZyBjb25maWd1cmF0 aW9uDQo+ICAgICAgICAgICAgICAgICBlbnRyeSksIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVy YXRpb25hbCBzdGF0ZSBpcw0KPiAgICAgICAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1 ZXMgZm9yIGFsbCBub2RlcyBhcyBkZXRlY3RlZCBieQ0KPiAgICAgICAgICAgICAgICAgdGhlIGlt cGxlbWVudGF0aW9uLg0KPg0KPiAgICAgICAgICAgSWYgdGhlIC9oYXJkd2FyZS9jb21wb25lbnQg bGlzdCBpbiB0aGUgaW50ZW5kZWQNCj4gICAgICAgICAgIGNvbmZpZ3VyYXRpb24gaXMgbW9kaWZp ZWQsIHRoZW4gdGhlIHN5c3RlbSBNVVNUIGJlaGF2ZSBhcyBpZg0KPiAgICAgICAgICAgaXQgcmUt aW5pdGlhbGl6ZXMgaXRzZWxmLCBhbmQgZm9sbG93IHRoZSBwcm9jZWR1cmUgaW4gKDEpLiI7DQo+ DQo+IE5FVzoNCj4NCj4gICAgICAgICAgIFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGEgbmV3IGhh cmR3YXJlIGNvbXBvbmVudCwgaXQNCj4gICAgICAgICAgIGluaXRpYWxpemVzIGEgbGlzdCBlbnRy eSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUuDQo+DQo+ICAgICAgICAgICBJZiB0aGUgc2VydmVy IGRvZXMgbm90IHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBoYXJkd2FyZQ0KPiAgICAgICAgICAg Y29tcG9uZW50cywgbGlzdCBlbnRyaWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBhcmUNCj4g ICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0 ZWQgYnkgdGhlDQo+ICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi4NCj4NCj4gICAgICAgICAgIE90 aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9sbG93ZWQ6DQo+DQo+ICAgICAg ICAgICAgIDEuIElmIHRoZXJlIGlzIGFuIGVudHJ5IGluIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50 IGxpc3QgaW4NCj4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gd2l0 aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiAgICAgICAgICAgICAgICAnY2xhc3MnLCAncGFyZW50 JywgJ3BhcmVudC1yZWwtcG9zJyB0aGF0IGFyZSBlcXVhbCB0bw0KPiAgICAgICAgICAgICAgICB0 aGUgZGV0ZWN0ZWQgdmFsdWVzLCB0aGVuIHRoZSBsaXN0IGVudHJ5IGluIG9wZXJhdGlvbmFsDQo+ ICAgICAgICAgICAgICAgIHN0YXRlIGlzIGluaXRpYWxpemVkIHdpdGggdGhlIGNvbmZpZ3VyZWQg dmFsdWVzLA0KPiAgICAgICAgICAgICAgICBpbmNsdWRpbmcgdGhlICduYW1lJy4gIFRoZSBsZWFm cyAnc2VyaWFsLW51bScsDQo+ICAgICAgICAgICAgICAgICdtZmctbmFtZScsIGFuZCAnbW9kZWwt bmFtZScgYXJlIHRyZWF0ZWQgc3BlY2lhbGx5OyBzZWUNCj4gICAgICAgICAgICAgICAgdGhlaXIg ZGVzY3JpcHRpb25zIGZvciBkZXRhaWxzLg0KPg0KPiAgICAgICAgICAgICAyLiBPdGhlcndpc2Ug KGkuZS4sIHRoZXJlIGlzIG5vIG1hdGNoaW5nIGNvbmZpZ3VyYXRpb24NCj4gICAgICAgICAgICAg ICAgZW50cnkpLCB0aGUgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4g ICAgICAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBub2RlcyBhcyBk ZXRlY3RlZCBieQ0KPiAgICAgICAgICAgICAgICB0aGUgaW1wbGVtZW50YXRpb24uDQo+DQo+ICAg ICAgICAgICBJZiB0aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluIHRoZSBpbnRlbmRlZA0K PiAgICAgICAgICAgY29uZmlndXJhdGlvbiBpcyBtb2RpZmllZCwgdGhlbiB0aGUgc3lzdGVtIE1V U1QgYmVoYXZlIGFzIGlmDQo+ICAgICAgICAgICBpdCByZS1pbml0aWFsaXplcyBpdHNlbGYsIGFu ZCBmb2xsb3cgdGhlIHByb2NlZHVyZSBpbiAoMSkuIjsNCj4NCj4NCj4NCj4gL21hcnRpbg0KPg0K Pg0KPg0KPg0KPiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBP biAxMi8yMC8yMDE3IDQ6MDAgUE0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+Pj4gQmVub2l0 IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPj4+PiBIaSBNYXJ0aW4sDQo+Pj4+ DQo+Pj4+IFRoYW5rcy4NCj4+Pj4gT25seSBrZXB0IHRoZSByZWxldmFudCBleGNlcnB0cy4NCj4+ Pj4+PiAtIFNvbWUgb2JqZWN0cyBhcmUgcmVhZC13cml0ZSBpbiBSRkM2OTMzOg0KPj4+Pj4+ICAg ICAgICAgIGVudFBoeXNpY2FsU2VyaWFsTnVtDQo+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxB bGlhcw0KPj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsQXNzZXRJRA0KPj4+Pj4+ICAgICAgICAg IGVudFBoeXNpY2FsVXJpcw0KPj4+Pj4+DQo+Pj4+Pj4gRm9yIGV4YW1wbGUsIGVudFBoeXNpY2Fs U2VyaWFsTnVtIGJlaW5nIHJlYWQtd3JpdGUgYWx3YXlzIGJvdGhlcmVkIG1lLg0KPj4+Pj4+IHNl cmlhbC1udW0gaXMgbm93ICJjb25maWcgZmFsc2UiLCB3aGljaCBpcyBhIGdvb2QgbmV3cyBJTU8u DQo+Pj4+PiBBY3R1YWxseSwgdGhpcyB3YXMgbm90IHRoZSBpbnRlbnRpb24uICBJbiANCj4+Pj4+ IGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wMyB0aGlzIGlzIGNvbmZpZ3VyYWJsZS4gIEkgbWlz c2VkIHRoaXMgaW4gdGhlIGNvbnZlcnNpb24gdG8gTk1EQS4NCj4+Pj4gQWguIFNvIG5vIGdvb2Qg bmV3cyBpbiB0aGlzIGNhc2UuLi4NCj4+Pj4+PiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGVu dFBoeXNpY2FsTWZnTmFtZSBpcyByZWFkLW9ubHkgaW4gDQo+Pj4+Pj4gUkZDNjkzMywgd2hpbGUg aXQncyAiY29uZmlnIHRydWUiIGluIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eQ0KPj4+Pj4gWWVz LCB0aGlzIHdhcyBhZGRlZCBwZXIgcmVxdWVzdCBmcm9tIHRoZSBXRy4gIFNlZSBlLmcuIHRoZSB0 aHJlYWQgDQo+Pj4+PiAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlzc3VlICMxMyIuDQo+Pj4+ IFN1cmUuIEl0IHdhcyBtYWlubHkgYW4gb2JzZXJ2YXRpb24uDQo+Pj4+PiBIb3dldmVyLCBJIHRo aW5rIHRoYXQgd2hhdCB3ZSBoYXZlIG5vdyBpcyBwcm9iYWJseSBub3QgY29ycmVjdC4gIEkgDQo+ Pj4+PiB0aGluayB0aGF0IGFsbCBub2RlcyAnc2VyaWFsLW51bScsICdtZmctbmFtZScsIGFuZCAn bW9kZWwtbmFtZScgDQo+Pj4+PiBzaG91bGQgYmUgY29uZmlnIHRydWUsIGFuZCB0aGUgZGVzY3Jp cHRpb24gb2YgbGlzdCAnY29tcG9uZW50JyANCj4+Pj4+IHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGF0 IGFsbCB0aGVzZSB0cmVlIGxlYWZzIGFyZSBoYW5kbGVkIHRoZSBzYW1lIHdheS4NCj4+Pj4+DQo+ Pj4+PiBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aGF0IHRoZSBXRyB0aGlua3MgYWJvdXQgdGhpcy4N Cj4+Pj4gVGFsa2luZyBhcyBhIGNvbnRyaWJ1dG9yIHRoaXMgdGltZS4NCj4+Pj4gSXQgc2VlbXMg dGhhdCBpbnZlbnRvcnkgbWFuYWdlbWVudCBpcyBraW5kIG9mIGJyb2tlbiB3aGVuIHNvbWVvbmUg DQo+Pj4+IGNhbiBjaGFuZ2UgJ3NlcmlhbC1udW0nLCAnbWZnLW5hbWUnLCBhbmQgJ21vZGVsLW5h bWUuDQo+Pj4gVGhleSBjYW4ndCByZWFsbHkgY2hhbmdlIHRoZW0uICBUaGUgY29uZmlndXJlZCB2 YWx1ZXMgYXJlIG9ubHkgdXNlZCANCj4+PiAoaS5lLiB2aXNpYmxlIGluIHRoZSBvcGVyYXRpb25h bCBzdGF0ZSkgaWYgdGhlIGRldmljZSBjYW5ub3QgZGV0ZWN0IA0KPj4+IHRoZW0gYXV0b21hdGlj YWxseS4gIEkuZS4sIHRoZXkgd29yayBhcyAicG9zdC1pdCIgbm90ZXMgb25seS4NCj4+IElmIEkg bG9vayBhdCwgZm9yIGV4YW1wbGUsIHRoZSBtZmctbmFtZSwgZGVzY3JpcHRpb24sIHRoaXMgaXMg bm90IA0KPj4gd2hhdCBpdCBzYXlzLg0KPj4NCj4+ICAgICBsZWFmIG1mZy1uYW1lIHsNCj4+ICAg ICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPj4gICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4+ICAg ICAgICAgICAgICAgIlRoZSBuYW1lIG9mIHRoZSBtYW51ZmFjdHVyZXIgb2YgdGhpcyBwaHlzaWNh bCBjb21wb25lbnQuDQo+PiAgICAgICAgICAgICAgICBUaGUgcHJlZmVycmVkIHZhbHVlIGlzIHRo ZSBtYW51ZmFjdHVyZXIgbmFtZSBzdHJpbmcNCj4+ICAgICAgICAgICAgICAgIGFjdHVhbGx5IHBy aW50ZWQgb24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmIHByZXNlbnQpLg0KPj4NCj4+ICAgICAg ICAgICAgICAgIE5vdGUgdGhhdCBjb21wYXJpc29ucyBiZXR3ZWVuIGluc3RhbmNlcyBvZiB0aGUg bW9kZWwtbmFtZSwNCj4+ICAgICAgICAgICAgICAgIGZpcm13YXJlLXJldiwgc29mdHdhcmUtcmV2 LCBhbmQgdGhlIHNlcmlhbC1udW0gbm9kZXMgYXJlDQo+PiAgICAgICAgICAgICAgICBvbmx5IG1l YW5pbmdmdWwgYW1vbmdzdCBjb21wb25lbnQgd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZg0KPj4gICAg ICAgICAgICAgICAgbWZnLW5hbWUuDQo+Pg0KPj4gICAgICAgICAgICAgICAgSWYgdGhlIG1hbnVm YWN0dXJlciBuYW1lIHN0cmluZyBhc3NvY2lhdGVkIHdpdGggdGhlDQo+PiAgICAgICAgICAgICAg ICBwaHlzaWNhbCBjb21wb25lbnQgaXMgdW5rbm93biB0byB0aGUgc2VydmVyLCB0aGVuIHRoaXMN Cj4+ICAgICAgICAgICAgICAgIG5vZGUgaXMgbm90IGluc3RhbnRpYXRlZC4iOw0KPj4gICAgICAg ICAgICAgcmVmZXJlbmNlICJSRkMgNjkzMyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY5MzM+Og0KPj4gICAgICAgICAgICAgZW50UGh5c2ljYWxNZmdOYW1lIjsNCj4+DQo+PiBSZWdh cmRzLCBCZW5vaXQNCj4+DQo+Pj4NCj4+PiAvbWFydGluDQo+Pj4gLg0KPj4+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo+IC4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Tue Jan 9 07:02: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 B300012D86C; Tue, 9 Jan 2018 07:02:00 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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=cesnet.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 PPDYUnsAjhig; Tue, 9 Jan 2018 07:01:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 F2EC3126C0F; Tue, 9 Jan 2018 07:01:57 -0800 (PST) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 5C3CE400065; Tue, 9 Jan 2018 16:01:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1515510114; bh=naClBdZvux3jD73SoAsAQEt7sy8R1v8aE0K+cZSeAJE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=K+EcsZglGf3Tb/9GaZdOb4r8ptpDWnoah5e7JUBxQaF5wrRAJvm1K/apZibEHEvv7 3kOp49l2Zc975d2//0viBpA20d9EGRiX+14wHoNGT4Wtrj6wH01493oGXVg/eDuAym EG7eB6FEvDeemCgKS8zUSy146CRZN3M7Wn7dvSSg= To: Martin Bjorklund Cc: yang-doctors@ietf.org, draft-ietf-netmod-entity.all@ietf.org, netmod@ietf.org References: <151507502144.23798.1644071576333370968@ietfa.amsl.com> <20180108.162153.18427707995478583.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: <08db428e-f9af-022d-0dc9-c14dbddcd745@cesnet.cz> Date: Tue, 9 Jan 2018 16:01:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180108.162153.18427707995478583.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-entity-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 15:02:00 -0000 Hi Martin, you are right, now I see it. So, to me, the document is Ready. Andy, text in RFC6087bis (Temporary non-NMDA Modules) should be changed s= ince it seems to limit the temporary module to contain data nodes only. OLD =C2=A0=C2=A0=C2=A0 It contains the top-level config=3Dfalse data nodes th= at would have been defined in a legacy YANG module (before NMDA). NEW =C2=A0=C2=A0=C2=A0 It contains the top-level config=3Dfalse data nodes th= at would have been defined in a legacy YANG module (before NMDA) as well = as the notifications, RPCs and actions that would refer such nodes. Regards, Radek Dne 8.1.2018 v 16:21 Martin Bjorklund napsal(a): > Hi, > > Radek Krej=C4=8D=C3=AD wrote: >> Reviewer: Radek Krej=C4=8D=C3=AD >> Review result: Ready with Issues >> >> The document itself and normative parts seem fine to me, the only issu= e I see >> is with the ietf-hardware-state module in non-normative appendix A. It= seems to >> me that this temporary non-NMDA module does not conform to its purpose= as >> described in RFC6087bis. According to guidelines, such a module is int= ended to >> provide state (config false) data in case the server does not implemen= t NMDA >> (to bridge the time period until NMDA is implemented). So such a serve= r is IMHO >> intended to implement both modules, foo and foo-state. The foo-state c= ontains >> "the top-level config-false data nodes that would have been defined in= a legacy >> YANG module" - so it's only the ro mirror of data nodes. But >> ietf-hardware-state contains notifications, which are not the data nod= es as >> defined in RFC7950. I understand why the notifications were placed als= o into >> the ietf-hardware-state - the module's description states that "If a s= erver >> that implements this module but doesn't support NMDA also supports >> configuration of hardware components, it SHOULD also implement the mod= ule >> 'ietf-hardware' ...", so it allows its standalone usage in case the se= rver does >> not support hw configuration. But in such a case, the server can imple= ment >> ietf-hardware with deviations on the config=3Dtrue nodes. > The problem with useing the notifcations defined in ietf-hardware in > this case is that all leafrefs would be wrong; they'd point into a > schema that is not implemented. > >> The same way it had to >> implement the legacy YANG module (before NMDA). > Before NMDA the leafrefs in the notifcations pointed to > /hardware-state, and all config was defined with an if-feature, so a > server did not have to use any deviations in this case. > > > > /martin > > > >> So I think that the notifications should be removed from ietf-hardware= -state >> and the module's description should change this way: >> >> OLD >> >> If a server that implements this module but doesn't support NMDA >> also supports configuration of hardware components, it SHOULD >> also implement the module 'ietf-hardware' in the configuration >> datastores. The corresponding state data is found in the >> '/hw-state:hardware' subtree. >> >> NEW >> >> If a server that implements this module but doesn't support NMDA, >> it MUST also implement the module 'ietf-hardware' in the >> configuration datastores. The corresponding state data is found >> in the '/hw-state:hardware' subtree. >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 9 07:34: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 3525112D868 for ; Tue, 9 Jan 2018 07:34:01 -0800 (PST) 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_RP_MATCHES_RCVD=-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 jITbINMxUo7x for ; Tue, 9 Jan 2018 07:33:59 -0800 (PST) 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 39B531205F0 for ; Tue, 9 Jan 2018 07:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21421; q=dns/txt; s=iport; t=1515512038; x=1516721638; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7v0tywUFa3Rf7WKlteIXlOzEVG/nxjvOjsQ8YzqPi6s=; b=HQtYAjHDpejEerKx/vi8I6yF17oIqeW4XM08ZPlsPj7VZL1sVvbXRpRZ zkpBKuVDgHSoo43NJFovcsUvURs6vk85KJ0BtcQ+oi88UblaKXCoPfu/a E4HKqdPUriQdlMm+Af1Eyr8HENw9o/16oLqSdXES6pfA5Y3JeMa3v9ere s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQCX4FRa/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJnQnhAeLGI9ql0KCAQoYC4RJTwKEfRQBAQEBAQEBAQFrKIU?= =?us-ascii?q?kAQEEAQEhDwEFNgsOAgkCDgICBgICIwMCAhsMHwMOBg0GAgEBF4oWEJEmnW6CJ?= =?us-ascii?q?4pBAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoMRfYJvgWkpgXeBDoMvAYFHDwI?= =?us-ascii?q?3JoJQgmUFmVmKBot/iUKCF4oIJoE6hgqKYYQxiAeBPDYigVAyGggbFT2CKgmCS?= =?us-ascii?q?xyBZ0E3iF8CJQeCHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,336,1511827200"; d="scan'208";a="1310142" 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; 09 Jan 2018 15:33:35 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w09FXZj6017667; Tue, 9 Jan 2018 15:33:35 GMT To: Martin Bjorklund Cc: andy@yumaworks.com, netmod@ietf.org References: <20180109.122807.1121028038684414186.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Tue, 9 Jan 2018 15:33:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180109.122807.1121028038684414186.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 15:34:01 -0000 On 09/01/2018 11:28, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi Andy, >> >> >> On 08/01/2018 19:45, Andy Bierman wrote: >>> >>> On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton >> > wrote: >>> >>> Hi Andy, >>> >>> Regarding your comment below, this intent is captured by this text >>> describing the operational datastore in section 5.3: >>> >>> 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 due to remnant configuration (see >>> Section 5.3.1). Note, that deviations SHOULD be used when it is >>> known in advance that a device does not fully conform to the >>> schema. >>> >>> Only semantic constraints MAY be violated, these are the YANG >>> "when", >>> "must", "mandatory", "unique", "min-elements", and "max-elements" >>> statements; and the uniqueness of key values. >>> >>> Syntactic constraints MUST NOT be violated, including hierarchical >>> organization, identifiers, and type-based constraints. If a node in >>> does not meet the syntactic constraints then it MUST >>> NOT be returned, and some other mechanism should be used to flag the >>> error. >>> >>> >>> Do you agree that this is sufficient? >>> >>> >>> >>> Not really. >>> It does not address my concern, which is that NMDA is >>> removing the YANG constraints on config=false data nodes >>> for no apparent reason. >> There is a reason. I don't think that the constraints on config=false >> is really being removed, because I don't think that they truly existed >> in the first place (despite what RFC 7950 might indicate!). > I agree. But note that RFC 7950 says: > > o If the constraint is defined on state data, it MUST be true in a > valid state data tree. > > It is not defined anywhere that must return a "valid state data > tree". > > In reality, I suspect that all implementations of call various > instrumentation call back functions in some order, possibly in > parallell, which means that data will be collected at different times > from the backend systems. I don't think it is feasible to freeze the > operational state of a device, collect all data, and unfreeze, in > order to get a consistent snapshot of the operational state. I agree. It is not even just that the management agent may be reading the data from the backend systems at different times, the operational state in those backend systems may not have converged at the point that it is being read (e.g. a route that has been installed in the FIB on some linecards, but not all). I think that the operational state is probably best considered as being eventually consistent.  I.e. if the device stops receiving further updates (in config or state), and if no abnormal conditions have occurred, then the operational state of the system must end up conforming to the schema for , and would be a valid data state data tree. Thanks, Rob > > > /martin > >> I think that we all agree on the expected behavior for configuration: >> If a client sends configuration to a server that would cause >> to become invalid then the server should reject that change, to ensure >> that always holds a consistent configuration.  Having a >> consistent configuration is the most important property here. >> I.e. the server has the right to reject an invalid configuration >> request from a client. >> >> However, the flow of operational state data in opposite direction >> cannot hold to the same rules.  If during the processing of a get >> request (or YANG push) a server sends operational state data back to a >> client then a client has to choose how to process the message: >>  - if the message is garbled or not sane then it makes sense to >> discard it. >>  - however, what should the client do if the message is well formed >> but either (i) contains some values outside the permitted schema range >> (but can be represented by the schema datatype), or (ii) by applying >> the values would cause the clients copy of to become >> invalid? >> >> If the client discards the message because of one bad value, then that >> doesn't seem to be helpful, since it allows for a very fragile model >> of system management.  I.e. if one small thing is bad then the whole >> house of cards collapses. >> >> So I think that the only sensible behaviour here is that the client >> has to process the operational state update in a best effort fashion, >> keep all the good data and probably flag any values that are outside >> the value constraints.  Similarly any reference constraint failures >> (i.e. when/must) can similarly be flagged up, but throwing away an >> update message that would cause the operational state to become >> inconsistent doesn't seem to be helpful.  I.e. it is much better if >> the client gets to see the true state of the server, even if that >> state isn't good (or consistent). >> >> Similar questions arise on the server itself: >>  - what if the real value in use (e.g. that is read from the hardware) >> is outside the permitted range (because of a logic defect)?  Is it >> really better to suppress that value entirely or return a value that >> server knows to be wrong? >>  - can a server even know that its operational view is consistent? For >> complex systems where the real operational state is split across >> multiple underlying linecards, or remote devices, I think that this is >> very hard (if not impossible) to do. >> >> So what the NMDA architecture states is: >>  (i) if a server knows that it won't conform to the operational schema >> then it must use deviations, >>  (ii) a server in a normal steady state should conform to the >> operational schema (and be valid), >>  (iii) but, if the system is churning (e.g. configuration, route >> update, etc) then the operational state of the server might be >> transiently inconsistent and this is OK, >>  (iv) if, the server is in a bad state, then it is better to return >> the actual state than to lie or not report a particular value (as long >> as it can be encoded). >>  (v) a server does not need to explicitly validate that its view of >> operational is valid. It is unclear what it would/could do if it >> detected that the operational state is invalid, nor is it clear that >> servers would generally be able to always perform this operation. >> >>> The server implementation requirements expressed in YANG constraints >>> are applicable to any data node, not just config=true data nodes. >>> The requirement to implement the ancestor nodes (with keys) does not >>> change. >> The draft does not allow this to be violated.  I.e. the following >> statement prevents this: "Syntactic constraints MUST NOT be violated, >> including hierarchical organization". >> >> >>> The requirement to conform to the YANG constraints defined within >>> config=false >>> data nodes does not change. >>> >>> To do otherwise does not make sense.  E.g. "when" conditions that add >>> ethernet >>> counters only when the interface type is ethernetCsmacd. Why would it >>> be OK for >>> the server to ignore that when-stmt and add ethernet counters to every >>> interface? >> It is not OK for a server to ignore that and add Ethernet counters to >> every interface (without using a deviation).  The draft is not trying >> to allow that. >> >> But if an interface could change type (e.g. between Ethernet and ATM >> via a different optics module being inserted) then it would be allowed >> for a server to transiently report the ethernet counters on the >> interface whilst it is in the process of changing the interface type >> from ethernet to ATM (e.g. if the counters are maintained by a >> separate daemon that is updated asynchronously with respect to the >> config or optics change).  Once the change had completed, the the >> system reaches steady state then the Ethernet counter must no longer >> be reported. >> >> Thanks, >> Rob >> >> >>> IMO the text above can only apply to the operational values of >>> config=true nodes. >>> >>> >>> Thanks, >>> Rob >>> >>> >>> >>> Andy >>> >>> >>> >>> On 21/12/2017 22:49, Andy Bierman wrote: >>>> Hi, >>>> >>>> It should be clear somehow that server requirements to provide >>>> config=false data >>>> that is valid according to the YANG definitions is not affected >>>> by NMDA. >>>> That is not being taken away.  The ability to validate >>>> operational values >>>> of configuration data has never been provided, and therefore is >>>> not being taken away either. >>>> >>>> A constraint on config=true nodes only applies to configuration >>>> datastores. >>>> These are the only constraints that should be ignored in >>>> . >>>> Constraints on config=false nodes still apply in . >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder >>>> >>> > wrote: >>>> >>>> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev >>>> wrote: >>>> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: >>>> > >>>> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir >>>> Vassilev wrote: >>>> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: >>>> > > > >>>> > > > > Hi Vladimir, >>>> > > > > >>>> > > > > First point of clarification is that this is not >>>> about running/intended >>>> > > > > at all.  The contents of running/intended do not >>>> change in anyway >>>> > > > > depending on whether hardware is present or absent. >>>> > > > > >>>> > > > > The section is only concerned with how the >>>> configuration is applied in >>>> > > > > operational, and basically says that you cannot apply >>>> configuration for >>>> > > > > resources that are missing (which seems reasonable). >>>> E.g. I cannot >>>> > > > > configure an IP address on a physical interface that >>>> isn't there.  Or if >>>> > > > > the physical interface gets removed then the >>>> configuration associated >>>> > > > > with that interface is also removed from operational. >>>> > > > > >>>> > > > > Operational isn't validated and data model >>>> constraints are allowed to be >>>> > > > > broken (ideally transiently). >>>> > > > I want to focus on this. IMO giving up schema validitiy >>>> for any datastore is >>>> > > > unacceptable price. Pre-NMDA devices had full model >>>> support in operational >>>> > > > data (all YANG constrains part of the model without >>>> discrimination were >>>> > > > enforced). >>>> > > There was a long debate about the value of returning the true >>>> > > operational state. What do you do if the operational >>>> state is invalid? >>>> > > A server can reject configuration changes if they lead to >>>> invalid >>>> > > state, a server can not reject reality. >>>> > IMO if the model can represent reality then data conforming >>>> to the model >>>> > can. If not a better model is needed not a hack that breaks >>>> the datastore >>>> > conformance to the YANG model. I do not see how >>>> > /interfaces/interface/oper-status=not-present was not >>>> representing the >>>> > reality of a system with removed line card that is >>>> configured and ready to >>>> > resume operation as soon as the line card is reconnected. >>>> >>>> I assume this is all system and implementation specific. If your >>>> system knows about interfaces that are not present (i.e., >>>> there is >>>> operational state about them), you can report these >>>> interfaces.  But >>>> 'is configured' is confusing here. I am not sure a line card >>>> that does >>>> not exist should be considered configured. But yes, this may >>>> be system >>>> specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has >>>> oper-status 'not-present' - so this seems to be a mood point. >>>> >>>> > > > If this is about to change it will compromise >>>> interoperability >>>> > > > and a significant portion of the client implementation >>>> workload that can be >>>> > > > automated will need to be coded in hand and tested. >>>> Unresolved leafrefs, >>>> > > > undefined behaviour of different implementations >>>> removing different >>>> > > > configuration nodes in violation of YANG semantic >>>> constraints (which I do >>>> > > > not think can be so clearly separated from the >>>> syntactic constraints when >>>> > > > one considers types like leafref, instance-identifier >>>> etc.) and the >>>> > > > corresponding side effects based on the server >>>> implementators own creativity >>>> > > > is eventually going to create more problems. >>>> > > > >>>> > > > 1. IMO the only acceptable solution is to have YANG >>>> valid operational >>>> > > > datastore at all times. operational like any other >>>> datastore MUST be valid >>>> > > > YANG data tree and it has to be a system implementation >>>> task to consider all >>>> > > > complications resulting from the removal of the >>>> resources leading to any >>>> > > > data transformations. If this is difficult or >>>> impossible other mechanisms to >>>> > > > flag missing resources should be used (e.g. >>>> > > > /interfaces/interface/oper-status=not-present) This >>>> sounds like a useful >>>> > > > contract providing the value of a standard the >>>> alternative does not. >>>> > > As said above, it is impossible to report valid >>>> operational state if >>>> > > the operational state is not valid according to the models. >>>> > > >>>> > > > 2. Even with the change in 1. I do not see the removal >>>> of intended >>>> > > > configuration nodes from operational as a solution >>>> worth implementing on our >>>> > > > servers. I do not see a real world plug-and-play >>>> scenario that can be >>>> > > > automatically solved without specific additions to the >>>> models e.g. >>>> > > > /interfaces/interface/oper-status=not-present is >>>> oversimplified solution but >>>> > > > it needs to be extended exactly as much as the solution >>>> provided by the >>>> > > > removal of config true; nodes without the sacrifice of >>>> YANG validity of >>>> > > > operational. >>>> > > Your thinking is likely wrong. reports the >>>> operational >>>> > > state. It may have little in common with . >>>> Trying to derive >>>> > > operational from intended is likely a not well working >>>> approach. >>>> > The proposal for this solution ("derive operational from >>>> intended" e.g. >>>> > merge /interfaces-state in /interfaces) comes from the >>>> revised datastores >>>> > draft not me. >>>> > >>>> > By definition config true; data represents intent. Reusing >>>> the model of a >>>> > config true; data to represent state absent of intent (e.g. >>>> > /interfaces/interface with origin="or:system") is a hack. >>>> The hack works >>>> > fine without compromising the conformance of operational to >>>> the YANG model >>>> > as long as certain conditions are met. I am pointing out >>>> that one of the >>>> > conditions is to keep all of the intended configuration >>>> data present in >>>> > 'operational' and handle missing resources with >>>> conventional means e.g. >>>> > /interfaces/interface/oper-status=not-present instead of >>>> adding the straw >>>> > that breaks the camel's back. >>>> >>>> I fail to see why you believe all objects that appear in intended >>>> configuration needs to exist in applied configuration. In fact, >>>> operators told us very clearly that they care about the >>>> distinction >>>> between intended and applied config. >>>> >>>> > > > 3. Solutions like /interfaces/interface/admin-state >>>> stop working. With the >>>> > > > interface removed you can no longer figure if the >>>> if-mib has or does not >>>> > > > have the interface enabled so an operator has to use >>>> SNMP or wait for a >>>> > > > replacement line card to be connected to figure this >>>> bit of information. >>>> > > At least on my boxes, if I remove a line card, the >>>> interface also >>>> > > disappears in SNMP tables. Stuff that is operationally >>>> not present is >>>> > > simply operationally not present. >>>> > > >>>> > > > My >>>> > > > interpretation of the MAY as requirement level in sec. >>>> 5.3. The Operational >>>> > > > State Datastore () is that plug-and-play >>>> solutions can be >>>> > > > implemented without this limited approach that has the >>>> same problem as the >>>> > > > pre-NMDA only now we have to have /interfaces-state to >>>> keep config false; >>>> > > > data relevant to hardware that is configured but not >>>> present: >>>> > > > >>>> > > >     configuration data nodes supported in a >>>> configuration datastore >>>> > > >     MAY be omitted from if a server is >>>> not able to >>>> > > >     accurately report them. >>>> > > > >>>> > > > I realize this discussion comes late. I have stated my >>>> objections to this >>>> > > > particular part of the NMDA draft earlier. >>>> > > I believe there is a conceptual misunderstanding. I think >>>> there never >>>> > > was a requirement that a server reports the state of >>>> hardware that is >>>> > > not present. >>>> > "Data relevant to hardware that is configured but not >>>> present" is different >>>> > from "state of hardware that is not present". For example >>>> information >>>> > indicating when the line card became unavailable, what was >>>> the reason, or >>>> > other information like how many packets that had this >>>> interface as egress >>>> > destination are being dropped as a result of the removal. >>>> >>>> I think that systems handle non-existing interfaces >>>> differently. It >>>> seems that ietf-interfaces is flexible enough to accomodate the >>>> differnet styles. >>>> >>>> /js >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> > . > From nobody Tue Jan 9 07:41: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 79BC1128959 for ; Tue, 9 Jan 2018 07:41:19 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vZd1rSFojpZ7 for ; Tue, 9 Jan 2018 07:41:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 72EE3126D0C for ; Tue, 9 Jan 2018 07:41:16 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 76DA81AE0144; Tue, 9 Jan 2018 16:41:15 +0100 (CET) Date: Tue, 09 Jan 2018 16:39:33 +0100 (CET) Message-Id: <20180109.163933.49682684192910889.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20171221.123746.382540578845045602.mbj@tail-f.com> <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 15:41:19 -0000 SGksDQoNCiJCb2dhZXJ0LCBCYXJ0IChOb2tpYSAtIEJFL0FudHdlcnApIiA8YmFydC5ib2dhZXJ0 QG5va2lhLmNvbT4gd3JvdGU6DQo+IEhpIE1hcnRpbiwNCj4gDQo+IFdlIGhhZCBhIGRpc2N1c3Np b24gb24gdGhpcyBhbmQgd2UgaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0IGJlbG93DQo+IHN0YXRl bWVudCAoYmVoYXZpb3IgaW4gdGhlIGRlc2NyaXB0aW9uIHN0YXRlbWVudCk6DQo+IA0KPiA+ICAg IFRoaXMgbGVhZiBjYW4gYmUgY29uZmlndXJlZC4gIFRoZSBjb25maWd1cmVkIHZhbHVlIGlzIHVz ZWQgb25seSBpZg0KPiA+ICAgIHRoZSBzZXJ2ZXIgY2Fubm90IGRldGVybWluZSB0aGUgdmVuZG9y LXNwZWNpZmljIHNlcmlhbCBudW1iZXIgZnJvbQ0KPiA+ICAgIHRoZSBjb21wb25lbnQgaXRzZWxm Lg0KPiANCj4gRm9yIHRoZSBhYm92ZSBzZW50ZW5jZSDigJxzZXJ2ZXIgY2Fubm90IGRldGVybWlu ZeKAnSB3ZSBoYXZlIDIgY2FzZXM6DQo+IDEuIEl0IGNhbuKAmXQgYmUgZGV0ZXJtaW5lZCBiZWNh dXNlIHRoZXJlIGlzIG5vdGhpbmcgZGV0ZWN0ZWQuDQo+IEFjY29yZGluZyB0byB0aGUgTk1EQS1k cmFmdCBpdCBpcyBjbGVhciB0aGF0IGluIHRoaXMgY2FzZSB0aGVyZSBpcyBubw0KPiByb3cgZm9y IHRoZSBhc3NvY2lhdGVkIGNvbXBvbmVudCBhbmQgaGVuY2Ugbm8gZGF0YS4gSSB0aGluayB0aGlz IGNhc2UNCj4gaXMgY292ZXJlZCBieSB0aGUgc2VudGVuY2UgaW4gdGhlIGxhdGVzdCBkcmFmdC1p ZXRmLW5ldG1vZC1lbnRpdHkgZm9yDQo+IHRoZSBsaXN0IOKAnGNvbXBvbmVudOKAnSB3aGVyZSBp dCBpcyBzdGF0ZWQ6IOKAnFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGENCj4gbmV3IGhhcmR3YXJl IGNvbXBvbmVudCwgaXQgaW5pdGlhbGl6ZXMgYSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25h bA0KPiBzdGF0ZS7igJ0sIHNvIHRoZSBhYm92ZSBzZW50ZW5jZSBvbmx5IGFwcGxpZXMgZm9yIHRo ZSBzZWNvbmQgY2FzZSBiZWxvdy4NCg0KT2suDQoNCj4gMi4gVGhlIHNlY29uZCBjYXNlIGlzIHRo YXQgc29tZXRoaW5nIGlzIGRldGVjdGVkIGJ1dCBpdCBjYW7igJl0IGJlIHJlYWQuDQo+IFdlIGRv IG5vdCBzZWUgYSByZWFzb24gdG8gdXNlIHRoZSB2YWx1ZSBjb25maWd1cmVkIGZvciB0aGUgbGVh ZnMNCj4g4oCYc2VyaWFsLW51beKAmSwg4oCYbWZnLW5hbWXigJkgYW5kIOKAmG1vZGVsLW5hbWXi gJkgb2YgYSBtYXRjaGluZyBlbnRyeSBpbiB0aGUNCj4gY29uZmlndXJhdGlvbiBkYXRhLiAgVGhl c2UgbGVhZnMgYXJlIGRlZmluZWQgYXMgb3B0aW9uYWwgc28gd2h5IHdvdWxkDQo+IHdlIHJlcG9y dCBzb21ldGhpbmcgZW50ZXJlZCBieSBhbiBvcGVyYXRvciBpbiB0aGUgb3BlcmF0aW9uYWwNCj4g ZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byByZXBvcnQgb24gd2hhdCBpcyBkZXRlY3RlZD8gIElz IGl0IG5vdA0KPiBiZXR0ZXIgdG8gbm90IHJlcG9ydCB0aGVtIGF0IGFsbD8gIEluIGFuIE5NREEg Y29udGV4dCBpdCB3b3VsZCBiZQ0KPiBwb3NzaWJsZSB0byBoYXZlIGEgZGlmZmVyZW50IHZhbHVl IChvciBubyB2YWx1ZSBhdCBhbGwpIGZvciBjZXJ0YWluDQo+IGxlYWZzIHdoaWxlIHRoZXJlIGlz IHNvbWV0aGluZyBpbiB0aGUgcnVubmluZy9pbnRlbmRlZCBkYXRhc3RvcmUuDQoNClRoZSBub3Jt YWwgTk1EQSBwcm9jZWR1cmUgZm9yIGEgY29uZmlndXJhdGlvbiBsZWFmIGlzIHRvIHJlcGVhdCBp dCBpbg0Kb3BlcmF0aW9uYWwgc3RhdGUuICBUaGlzIGlzIHRoZW4gdGhlICJhcHBsaWVkIGNvbmZp Z3VyYXRpb24iLiAgDQpJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc3BlY2lhbCBydWxl IGZvciB0aGVzZSBsZWFmcy4NCg0KVGhpcyBhbHNvIG1lYW5zIHRoYXQgYSBjbGllbnQgdGhhdCBq dXN0IHdhbnRzIHRvIHJlYWQgYWxsIHRoZSBzZXJpYWwNCm51bWJlcnMgY2FuIGRvIHNvIGZyb20g b25lIHBsYWNlLCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUsIHJlZ2FyZGxlc3Mgb2YNCmhvdyB0aGV5 IGNhbWUgaW50byBleGlzdGFuY2UuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IEJlc3QgcmVnYXJk cywgQmFydA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4g V2lsdG9uDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMSwgMjAxNyA0OjE0IFBNDQo+IFRv OiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW25ldG1vZF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0 eS0wNg0KPiANCj4gSGkgTWFydGluLA0KPiANCj4gDQo+IE9uIDIxLzEyLzIwMTcgMTE6MzcsIE1h cnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBJIG5lZWQgV0cgaW5wdXQg b24gdGhpcyBpc3N1ZS4gIFRoZSBxdWVzdGlvbiBpcyBob3cgdG8gaGFuZGxlIA0KPiA+ICdzZXJp YWwtbnVtJywgJ21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJy4gIEkgdGhpbmsgdGhleSBzaG91 bGQgYWxsIA0KPiA+IGJlIHRyZWF0ZWQgdGhlIHNhbWUuICBCYXNlZCBvbiBwcmV2aW91cyBXRyBk aXNjdXNzaW9uIChzZWUgZS5nLiB0aGUgDQo+ID4gbWFpbCB0aHJlYWQgImRyYWZ0LWlldGYtbmV0 bW9kLWVudGl0eSBpc3N1ZSAjMTMiKSwgSSB0aGluayB0aGV5IHNob3VsZA0KPiA+IGFsbCBiZSBj b25maWd1cmFibGUsIGJ1dCB0aGUgY29uZmlndXJlZCB2YWx1ZSBpcyBvbmx5IHVzZWQgaW4gDQo+ ID4gb3BlcmF0aW9uYWwgc3RhdGUgaWYgdGhlIHN5c3RlbSBjYW5ub3QgcmVhZCBpdCBmcm9tIHRo ZSBoYXJkd2FyZS4NCj4gSSB0aGluayB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgcHJvYmFibHkgT0s6 DQo+ICDCoC0gVGhlIGNsaWVudCBjYW4gYWx3YXlzIHNlZSB0aGUgcmVhbCB2YWx1ZSBpZiBpdCBp cyBhdmFpbGFibGUuDQo+ICDCoC0gSWYgaXQgaXMgbm90IGF2YWlsYWJsZSB0aGVuIHRoZXkgY2Fu IGFzc2lnbiBhIHZhbHVlIHZpYQ0KPiAgY29uZmlndXJhdGlvbi4NCj4gDQo+IEkgd2FzIGFsc28g Y29uc2lkZXJpbmcgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggb2YgaGF2aW5nIGEgc2VwYXJhdGUN Cj4gc2V0IG9mIGNvbmZpZyBmYWxzZSBsZWF2ZXMgZm9yIHRoZSAiYnVybnQgaW4gdmFsdWVzIi7C oCBBbmQgdGhlbiBoYXZpbmcNCj4gdGhlIGNvbmZpZ3VyYWJsZSBsZWF2ZXMgYWx3YXlzIG92ZXJy aWRlIHRoZSBkZWZhdWx0IG9wZXJhdGlvbmFsDQo+IHZhbHVlcy4gRS5nLiBzaW1pbGFyIHRvIGhv dyBhbiBpbnRlcmZhY2UgTUFDIGFkZHJlc3Mgd291bGQgZXhwZWN0IHRvDQo+IGJlIGhhbmRsZWQu DQo+IA0KPiBCdXQgb25lIHNldCBvZiBsZWF2ZXMgaXMgcHJvYmFibHkgc3VmZmljaWVudC4NCj4g DQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4gPg0KPiA+IFNvIEkgc3VnZ2VzdCB0aGUgZm9s bG93aW5nIGNoYW5nZXM6DQo+ID4NCj4gPiBPTEQ6DQo+ID4NCj4gPiAgICAgICAgbGVhZiBzZXJp YWwtbnVtIHsNCj4gPiAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiAgICAgICAgICBjb25maWcg ZmFsc2U7DQo+ID4gICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICJUaGUgdmVu ZG9yLXNwZWNpZmljIHNlcmlhbCBudW1iZXIgc3RyaW5nIGZvciB0aGUNCj4gPiAgICAgICAgICAg ICBjb21wb25lbnQuICBUaGUgcHJlZmVycmVkIHZhbHVlIGlzIHRoZSBzZXJpYWwgbnVtYmVyDQo+ ID4gICAgICAgICAgICAgc3RyaW5nIGFjdHVhbGx5IHByaW50ZWQgb24gdGhlIGNvbXBvbmVudCBp dHNlbGYgKGlmDQo+ID4gICAgICAgICAgICAgcHJlc2VudCkuIjsNCj4gPiAgICAgICAgICByZWZl cmVuY2UgIlJGQyA2OTMzOiBlbnRQaHlzaWNhbFNlcmlhbE51bSI7DQo+ID4gICAgICAgIH0NCj4g Pg0KPiA+IE5FVzoNCj4gPg0KPiA+ICAgICAgICBsZWFmIHNlcmlhbC1udW0gew0KPiA+ICAgICAg ICAgIHR5cGUgc3RyaW5nOw0KPiA+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gICAgICAgICAg ICAiVGhlIHZlbmRvci1zcGVjaWZpYyBzZXJpYWwgbnVtYmVyIHN0cmluZyBmb3IgdGhlDQo+ID4g ICAgICAgICAgICAgY29tcG9uZW50LiAgVGhlIHByZWZlcnJlZCB2YWx1ZSBpcyB0aGUgc2VyaWFs IG51bWJlcg0KPiA+ICAgICAgICAgICAgIHN0cmluZyBhY3R1YWxseSBwcmludGVkIG9uIHRoZSBj b21wb25lbnQgaXRzZWxmIChpZg0KPiA+ICAgICAgICAgICAgIHByZXNlbnQpLg0KPiA+DQo+ID4g ICAgICAgICAgICAgVGhpcyBsZWFmIGNhbiBiZSBjb25maWd1cmVkLiAgVGhlcmUgYXJlIHR3byB1 c2UgY2FzZXMgZm9yDQo+ID4gICAgICAgICAgICAgdGhpczsgYXMgYSAncG9zdC1pdCcgbm90ZSBp ZiB0aGUgc2VydmVyIGNhbm5vdCBkZXRlcm1pbmUNCj4gPiAgICAgICAgICAgICB0aGlzIHZhbHVl IGZyb20gdGhlIGNvbXBvbmVudCwgb3Igd2hlbiBwcmUtcHJvdmlzaW9uaW5nIGENCj4gPiAgICAg ICAgICAgICBjb21wb25lbnQuDQo+ID4NCj4gPiAgICAgICAgICAgICBJZiB0aGUgc2VydmVyIGNh biBkZXRlcm1pbmUgdGhlIHNlcmlhbCBudW1iZXIgZnJvbSB0aGUNCj4gPiAgICAgICAgICAgICBj b21wb25lbnQsIHRoZW4gdGhhdCB2YWx1ZSBpcyBhbHdheXMgdXNlZCBpbiBvcGVyYXRpb25hbA0K PiA+ICAgICAgICAgICAgIHN0YXRlLCBldmVuIGlmIGFub3RoZXIgdmFsdWUgaGFzIGJlZW4gY29u ZmlndXJlZC4iOw0KPiA+ICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6IGVudFBoeXNpY2Fs U2VyaWFsTnVtIjsNCj4gPiAgICAgICAgfQ0KPiA+DQo+ID4gQW5kIGNvcnJlc3BvbmRpbmcgdGV4 dCBmb3IgJ21mZy1uYW1lJyBhbmQgJ21vZGVsLW5hbWUnLg0KPiA+DQo+ID4gQW5kIGFsc286DQo+ ID4NCj4gPiBPTEQ6DQo+ID4NCj4gPiAgICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMg YSBuZXcgaGFyZHdhcmUgY29tcG9uZW50LCBpdA0KPiA+ICAgICAgICAgICBpbml0aWFsaXplcyBh IGxpc3QgZW50cnkgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlLg0KPiA+DQo+ID4gICAgICAgICAg IElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJl DQo+ID4gICAgICAgICAgIGNvbXBvbmVudHMsIGxpc3QgZW50cmllcyBpbiB0aGUgb3BlcmF0aW9u YWwgc3RhdGUgYXJlDQo+ID4gICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBh bGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkgdGhlDQo+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9u Lg0KPiA+DQo+ID4gICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUg aXMgZm9sbG93ZWQ6DQo+ID4NCj4gPiAgICAgICAgICAgICAxLiBJZiB0aGVyZSBpcyBhbiBlbnRy eSBpbiB0aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluDQo+ID4gICAgICAgICAgICAgICAg dGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gd2l0aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiA+ ICAgICAgICAgICAgICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQg YXJlIGVxdWFsIHRvDQo+ID4gICAgICAgICAgICAgICAgdGhlIGRldGVjdGVkIHZhbHVlcywgdGhl bjoNCj4gPg0KPiA+ICAgICAgICAgICAgIDFhLiBJZiB0aGUgY29uZmlndXJlZCBlbnRyeSBoYXMg YSB2YWx1ZSBmb3IgJ21mZy1uYW1lJw0KPiA+ICAgICAgICAgICAgICAgICB0aGF0IGlzIGVxdWFs IHRvIHRoZSBkZXRlY3RlZCB2YWx1ZSwgb3IgaWYgdGhlDQo+ID4gICAgICAgICAgICAgICAgICdt ZmctbmFtZScgdmFsdWUgY2Fubm90IGJlIGRldGVjdGVkLCB0aGVuIHRoZSBsaXN0DQo+ID4gICAg ICAgICAgICAgICAgIGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcyBpbml0aWFsaXpl ZCB3aXRoIHRoZQ0KPiA+ICAgICAgICAgICAgICAgICBjb25maWd1cmVkIHZhbHVlcyBmb3IgYWxs IGNvbmZpZ3VyZWQgbm9kZXMsIGluY2x1ZGluZw0KPiA+ICAgICAgICAgICAgICAgICB0aGUgJ25h bWUnLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGxpc3QgZW50cnkg aW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGlzDQo+ID4gICAgICAgICAgICAgICAgIGluaXRpYWxp emVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4gPiAgICAgICAg ICAgICAgICAgdGhlIGltcGxlbWVudGF0aW9uLiAgVGhlIGltcGxlbWVudGF0aW9uIG1heSByYWlz ZSBhbg0KPiA+ICAgICAgICAgICAgICAgICBhbGFybSB0aGF0IGluZm9ybXMgYWJvdXQgdGhlICdt ZmctbmFtZScgbWlzbWF0Y2gNCj4gPiAgICAgICAgICAgICAgICAgY29uZGl0aW9uLiAgSG93IHRo aXMgaXMgZG9uZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZg0KPiA+ICAgICAgICAgICAgICAgICB0 aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gICAgICAgICAgICAgMWIuIE90aGVyd2lzZSAoaS5lLiwg dGhlcmUgaXMgbm8gbWF0Y2hpbmcgY29uZmlndXJhdGlvbg0KPiA+ICAgICAgICAgICAgICAgICBl bnRyeSksIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcw0KPiA+ICAg ICAgICAgICAgICAgICBpbml0aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRl dGVjdGVkIGJ5DQo+ID4gICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4gPg0K PiA+ICAgICAgICAgICBJZiB0aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluIHRoZSBpbnRl bmRlZA0KPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1vZGlmaWVkLCB0aGVuIHRoZSBz eXN0ZW0gTVVTVCBiZWhhdmUgYXMgaWYNCj4gPiAgICAgICAgICAgaXQgcmUtaW5pdGlhbGl6ZXMg aXRzZWxmLCBhbmQgZm9sbG93IHRoZSBwcm9jZWR1cmUgaW4gKDEpLiI7DQo+ID4NCj4gPiBORVc6 DQo+ID4NCj4gPiAgICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdh cmUgY29tcG9uZW50LCBpdA0KPiA+ICAgICAgICAgICBpbml0aWFsaXplcyBhIGxpc3QgZW50cnkg aW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlLg0KPiA+DQo+ID4gICAgICAgICAgIElmIHRoZSBzZXJ2 ZXIgZG9lcyBub3Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gICAgICAg ICAgIGNvbXBvbmVudHMsIGxpc3QgZW50cmllcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgYXJl DQo+ID4gICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMg ZGV0ZWN0ZWQgYnkgdGhlDQo+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4g ICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9sbG93ZWQ6 DQo+ID4NCj4gPiAgICAgICAgICAgICAxLiBJZiB0aGVyZSBpcyBhbiBlbnRyeSBpbiB0aGUgL2hh cmR3YXJlL2NvbXBvbmVudCBsaXN0IGluDQo+ID4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVk IGNvbmZpZ3VyYXRpb24gd2l0aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiA+ICAgICAgICAgICAg ICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRv DQo+ID4gICAgICAgICAgICAgICAgdGhlIGRldGVjdGVkIHZhbHVlcywgdGhlbiB0aGUgbGlzdCBl bnRyeSBpbiBvcGVyYXRpb25hbA0KPiA+ICAgICAgICAgICAgICAgIHN0YXRlIGlzIGluaXRpYWxp emVkIHdpdGggdGhlIGNvbmZpZ3VyZWQgdmFsdWVzLA0KPiA+ICAgICAgICAgICAgICAgIGluY2x1 ZGluZyB0aGUgJ25hbWUnLiAgVGhlIGxlYWZzICdzZXJpYWwtbnVtJywNCj4gPiAgICAgICAgICAg ICAgICAnbWZnLW5hbWUnLCBhbmQgJ21vZGVsLW5hbWUnIGFyZSB0cmVhdGVkIHNwZWNpYWxseTsg c2VlDQo+ID4gICAgICAgICAgICAgICAgdGhlaXIgZGVzY3JpcHRpb25zIGZvciBkZXRhaWxzLg0K PiA+DQo+ID4gICAgICAgICAgICAgMi4gT3RoZXJ3aXNlIChpLmUuLCB0aGVyZSBpcyBubyBtYXRj aGluZyBjb25maWd1cmF0aW9uDQo+ID4gICAgICAgICAgICAgICAgZW50cnkpLCB0aGUgbGlzdCBl bnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiAgICAgICAgICAgICAgICBpbml0 aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5DQo+ID4gICAg ICAgICAgICAgICAgdGhlIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gICAgICAgICAgIElmIHRo ZSAvaGFyZHdhcmUvY29tcG9uZW50IGxpc3QgaW4gdGhlIGludGVuZGVkDQo+ID4gICAgICAgICAg IGNvbmZpZ3VyYXRpb24gaXMgbW9kaWZpZWQsIHRoZW4gdGhlIHN5c3RlbSBNVVNUIGJlaGF2ZSBh cyBpZg0KPiA+ICAgICAgICAgICBpdCByZS1pbml0aWFsaXplcyBpdHNlbGYsIGFuZCBmb2xsb3cg dGhlIHByb2NlZHVyZSBpbiAoMSkuIjsNCj4gPg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3Jv dGU6DQo+ID4+IE9uIDEyLzIwLzIwMTcgNDowMCBQTSwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN Cj4gPj4+IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+PiBI aSBNYXJ0aW4sDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MuDQo+ID4+Pj4gT25seSBrZXB0IHRoZSBy ZWxldmFudCBleGNlcnB0cy4NCj4gPj4+Pj4+IC0gU29tZSBvYmplY3RzIGFyZSByZWFkLXdyaXRl IGluIFJGQzY5MzM6DQo+ID4+Pj4+PiAgICAgICAgICBlbnRQaHlzaWNhbFNlcmlhbE51bQ0KPiA+ Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxBbGlhcw0KPiA+Pj4+Pj4gICAgICAgICAgZW50UGh5 c2ljYWxBc3NldElEDQo+ID4+Pj4+PiAgICAgICAgICBlbnRQaHlzaWNhbFVyaXMNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBGb3IgZXhhbXBsZSwgZW50UGh5c2ljYWxTZXJpYWxOdW0gYmVpbmcgcmVhZC13 cml0ZSBhbHdheXMgYm90aGVyZWQgbWUuDQo+ID4+Pj4+PiBzZXJpYWwtbnVtIGlzIG5vdyAiY29u ZmlnIGZhbHNlIiwgd2hpY2ggaXMgYSBnb29kIG5ld3MgSU1PLg0KPiA+Pj4+PiBBY3R1YWxseSwg dGhpcyB3YXMgbm90IHRoZSBpbnRlbnRpb24uICBJbiANCj4gPj4+Pj4gZHJhZnQtaWV0Zi1uZXRt b2QtZW50aXR5LTAzIHRoaXMgaXMgY29uZmlndXJhYmxlLiAgSSBtaXNzZWQgdGhpcyBpbg0KPiA+ Pj4+PiB0aGUgY29udmVyc2lvbiB0byBOTURBLg0KPiA+Pj4+IEFoLiBTbyBubyBnb29kIG5ld3Mg aW4gdGhpcyBjYXNlLi4uDQo+ID4+Pj4+PiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGVudFBo eXNpY2FsTWZnTmFtZSBpcyByZWFkLW9ubHkgaW4gDQo+ID4+Pj4+PiBSRkM2OTMzLCB3aGlsZSBp dCdzICJjb25maWcgdHJ1ZSIgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5DQo+ID4+Pj4+IFll cywgdGhpcyB3YXMgYWRkZWQgcGVyIHJlcXVlc3QgZnJvbSB0aGUgV0cuICBTZWUgZS5nLiB0aGUg dGhyZWFkIA0KPiA+Pj4+PiAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlzc3VlICMxMyIuDQo+ ID4+Pj4gU3VyZS4gSXQgd2FzIG1haW5seSBhbiBvYnNlcnZhdGlvbi4NCj4gPj4+Pj4gSG93ZXZl ciwgSSB0aGluayB0aGF0IHdoYXQgd2UgaGF2ZSBub3cgaXMgcHJvYmFibHkgbm90IGNvcnJlY3Qu ICBJIA0KPiA+Pj4+PiB0aGluayB0aGF0IGFsbCBub2RlcyAnc2VyaWFsLW51bScsICdtZmctbmFt ZScsIGFuZCAnbW9kZWwtbmFtZScgDQo+ID4+Pj4+IHNob3VsZCBiZSBjb25maWcgdHJ1ZSwgYW5k IHRoZSBkZXNjcmlwdGlvbiBvZiBsaXN0ICdjb21wb25lbnQnIA0KPiA+Pj4+PiB1cGRhdGVkIHRv IHJlZmxlY3QgdGhhdCBhbGwgdGhlc2UgdHJlZSBsZWFmcyBhcmUgaGFuZGxlZCB0aGUgc2FtZSB3 YXkuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgd291bGQgbGlrZSB0byBrbm93IHdoYXQgdGhlIFdHIHRo aW5rcyBhYm91dCB0aGlzLg0KPiA+Pj4+IFRhbGtpbmcgYXMgYSBjb250cmlidXRvciB0aGlzIHRp bWUuDQo+ID4+Pj4gSXQgc2VlbXMgdGhhdCBpbnZlbnRvcnkgbWFuYWdlbWVudCBpcyBraW5kIG9m IGJyb2tlbiB3aGVuIHNvbWVvbmUgDQo+ID4+Pj4gY2FuIGNoYW5nZSAnc2VyaWFsLW51bScsICdt ZmctbmFtZScsIGFuZCAnbW9kZWwtbmFtZS4NCj4gPj4+IFRoZXkgY2FuJ3QgcmVhbGx5IGNoYW5n ZSB0aGVtLiAgVGhlIGNvbmZpZ3VyZWQgdmFsdWVzIGFyZSBvbmx5IHVzZWQgDQo+ID4+PiAoaS5l LiB2aXNpYmxlIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSkgaWYgdGhlIGRldmljZSBjYW5ub3Qg ZGV0ZWN0IA0KPiA+Pj4gdGhlbSBhdXRvbWF0aWNhbGx5LiAgSS5lLiwgdGhleSB3b3JrIGFzICJw b3N0LWl0IiBub3RlcyBvbmx5Lg0KPiA+PiBJZiBJIGxvb2sgYXQsIGZvciBleGFtcGxlLCB0aGUg bWZnLW5hbWUsIGRlc2NyaXB0aW9uLCB0aGlzIGlzIG5vdCANCj4gPj4gd2hhdCBpdCBzYXlzLg0K PiA+Pg0KPiA+PiAgICAgbGVhZiBtZmctbmFtZSB7DQo+ID4+ICAgICAgICAgICAgIHR5cGUgc3Ry aW5nOw0KPiA+PiAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+PiAgICAgICAgICAgICAgICJU aGUgbmFtZSBvZiB0aGUgbWFudWZhY3R1cmVyIG9mIHRoaXMgcGh5c2ljYWwgY29tcG9uZW50Lg0K PiA+PiAgICAgICAgICAgICAgICBUaGUgcHJlZmVycmVkIHZhbHVlIGlzIHRoZSBtYW51ZmFjdHVy ZXIgbmFtZSBzdHJpbmcNCj4gPj4gICAgICAgICAgICAgICAgYWN0dWFsbHkgcHJpbnRlZCBvbiB0 aGUgY29tcG9uZW50IGl0c2VsZiAoaWYgcHJlc2VudCkuDQo+ID4+DQo+ID4+ICAgICAgICAgICAg ICAgIE5vdGUgdGhhdCBjb21wYXJpc29ucyBiZXR3ZWVuIGluc3RhbmNlcyBvZiB0aGUgbW9kZWwt bmFtZSwNCj4gPj4gICAgICAgICAgICAgICAgZmlybXdhcmUtcmV2LCBzb2Z0d2FyZS1yZXYsIGFu ZCB0aGUgc2VyaWFsLW51bSBub2RlcyBhcmUNCj4gPj4gICAgICAgICAgICAgICAgb25seSBtZWFu aW5nZnVsIGFtb25nc3QgY29tcG9uZW50IHdpdGggdGhlIHNhbWUgdmFsdWUgb2YNCj4gPj4gICAg ICAgICAgICAgICAgbWZnLW5hbWUuDQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgIElmIHRoZSBt YW51ZmFjdHVyZXIgbmFtZSBzdHJpbmcgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiA+PiAgICAgICAg ICAgICAgICBwaHlzaWNhbCBjb21wb25lbnQgaXMgdW5rbm93biB0byB0aGUgc2VydmVyLCB0aGVu IHRoaXMNCj4gPj4gICAgICAgICAgICAgICAgbm9kZSBpcyBub3QgaW5zdGFudGlhdGVkLiI7DQo+ ID4+ICAgICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzMgPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2OTMzPjoNCj4gPj4gICAgICAgICAgICAgZW50UGh5c2ljYWxNZmdOYW1lIjsN Cj4gPj4NCj4gPj4gUmVnYXJkcywgQmVub2l0DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gL21hcnRpbg0K PiA+Pj4gLg0KPiA+Pj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+IC4N Cj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Tue Jan 9 07:43:37 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 C820B12D879; Tue, 9 Jan 2018 07:43:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Jan Lindblad To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-revised-datastores.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151551261178.1806.130953175040927039@ietfa.amsl.com> Date: Tue, 09 Jan 2018 07:43:31 -0800 Archived-At: Subject: [netmod] Yangdoctors early review of draft-ietf-netmod-revised-datastores-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 15:43:32 -0000 Reviewer: Jan Lindblad Review result: Ready Finally the NMDA datastores draft has reached WGLC, and I have been assigned as YD reviewer; quite an honor ;-) Because of the pretty fundamental importance of this document, I performed what I consider myself a pretty thorough review. Since this work has been going on for a very long time and with high intensity at times, I have not even tried to keep up to date with all the discussions. So in order not to resurrect all the beaten zombies that this spec has seen, I decided to let the document shepherd and principal author Martin Björklund review my review. The end result of which is that I withdraw every one of my comments and proclaim review result Ready. For full transparency (and to show that I wasn't lazy after all), I have enclosed my initial review findings below. Note that I now feel that they are either discussed enough already, addressed in a different document (e.g. YANG library), or misunderstandings/proposals on my part that do not necessarily merit further discussion or clarification. Finally I will add that no blackmail or bribery ;-) was involved in me reaching this conclusion; merely a good discussion. /jan Topic #1: Loss of operational stringency According to RFC 6020 tradition, config false data returned from operations MUST adhere to the constraints declared in the YANG modules; max-elements, must statements, unique keys, etc. This is obviously a high standard to live up to for server implementors. With NMDA, the situation reverses so that operations will return data from where no semantic guarantees apply. This moves the burden of managing flux and inconsistency from the servers to the clients. Now each client has to be able to deal with potentially duplicate keys, violated constraints and generally that any YANG model semantic guarantee is a mere recommendation. Personally I find this rather shocking. One of the core values in NETCONF/YANG has always been that it sides with the "operator" or "client" view of the world. Decades ago we had SNMP (Simple ...) -- which in practice meant simple to *implement*, not simple to use. NC/Y is supposed to be the other way around. Hard to implement, but easy to use. If we feel strict adherence to the YANG declaration is a bar too high for operational data, maybe we could find some middle ground? Just giving up and saying that anything anywhere may be violated anytime is to make it too easy for implementors and too hard for clients, IMHO. If I'm beating on a dead horse here, I apologize ;-) I just want to ensure that if this is what we want, it should be an informed decision. Topic #2: Actions live in NMDA says actions are always invoked in context of the data store. In many cases I agree this makes good sense. But there are a couple of catches here. The first catch relates to timing. As the server is not obliged to make an element committed in immediately available in , a client that creates a bit of configuration and is interested to execute an action on it will not know when to fire the action. Should it poll for the object creation? Keep retrying? I sense the creation of Heisenbugs and interop issues. The second catch relates to structure translation between and . If the configuration committed to by the client has no direct counterpart in and , there is nothing to invoke the action on. Say I used a templating feature in to define a bit of configuration, and now I want to execute a check-sync action on that piece of config to see that the config has propagated properly. There is no context to invoke the action on in . Similarly, for actions that update (e.g. config wizards), executing in would make sense. Maybe an ability to specify the context datastore in the rpc would be enough to fix this. Or better perhaps, the target datastore should be formally declared by the action/rpc? Such a declaration would solve another issue that exists today. A client needs to parse English to know if an action changes . Any configuration data cached by the client would need to be invalidated iff so. With a formal mechanism to declare which datastores are (not) affected, clients could be a lot more efficient. This is a real issue. Topic #3: Datastore specific deviations How would I express a deviation that applies to one datastore but not another? Say, for example, that I have a deviate not-implemented on an object in but I support it in . Topic #4: NMDA compliance declaration How would a client know that a server works according to NMDA principles? I suppose the intent is that there is no need to know because things are "backwards compatible", and that for a given server the answer may vary depending on which data model we're talking about. But as discussed in topic #1, #2, #3 above (and more below), significant semantic differences are introduced by NMDA. As client implementor, I would want to know what to expect from a server. Topic #5: Origin of unset values When the operational view is constructed, the draft describes situations where the operational value may be taken in some cases from or:intended and in other from or:learned. While it would be valuable for clients to understand what the precedence rule is, this may be a bit too complex to declare formally, since it is quite possible that the mechanics of which value shows up isn't always simple and may depend on other leaf values. In the example with a DHCP learned address trumping an intended address, it could be that the DHCP server specifies only an IPv6 address. In which case the device policy might be to override the IPv4 address in intended with no value. In this situation, there is no way for the server to communicate why there is no IPv4 address (it was or:learned), since the origin attribute cannot live on a non-existent XML element. So the origin mechanism does not work well for optional elements. Topic #6: Datastore and origin identity trees Why are there two trees with identities, one for datastores and one with origins? Most values seems to be the same, with the origins being a superset of the datastores. By organizing them into a single tree with all the datastores as one branch of the origins tree, we could get something simpler. moduel ietf-origin { identity origin; identity unknown { base origin; } identity system { base origin; } identity learned { base origin; } identity default { base origin; } identity datastore { base origin; } identity conventional { base datastore; } identity running { base conventional; } identity candidate { base conventional; } identity startup { base conventional; } identity intended { base conventional; } identity dynamic { base datastore; } identity operational { base datastore; } /* * Type definitions */ typedef origin-ref { type identityref { base origin; } } typedef datastore-ref { type identityref { base datastore; } } Topic #7: Editorial Below are a few details about the wording: On pages 3 and 4, it is said that "These datastores share a common datastore schema" and """datastore schema: The combined set of schema nodes for all modules supported by a particular datastore, taking into consideration any deviations and enabled features for that datastore.""" If we have a device that support macros/templates/services in , which expands into concrete configuration in , I don't suppose the macro/template/service instances would be part of ? If so, I guess the schemas are not exactly the same? Maybe we can say that is a subset of the schemas (plus all the config false data)? p15: Maybe we could point out that learned values etc MUST NOT update / to make this entirely clear. p24: Juergen Schoenwaelder's funding is mentioned, but not his participation p27: what's ? p28: ds-ephemeral and or-ephemeral are not great names. Will be referred to as ds:ds-ephemeral and or:or-ephemeral. Would prefer ds:ephemeral and or:ephemeral. /jan From nobody Tue Jan 9 09:01:10 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 4FCCE12D885; Tue, 9 Jan 2018 09:01:02 -0800 (PST) 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 (1024-bit key) header.d=btconnect.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 TjdsX22olbSY; Tue, 9 Jan 2018 09:00:59 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0103.outbound.protection.outlook.com [104.47.0.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2234127871; Tue, 9 Jan 2018 09:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EWybgMtZRLoOPKf1mYNJNleHCclfzvqbgfGM6Upi+Ig=; b=LjvNr80mltC3ETX24ZGCIwBiLqkgnPImFeiXstlwKk82aGGaruv+tDkcpXsEA/FSvgA+0li/MWziqHv4OTNln0j9fWQZz4XpxwX/MWA/XfkaMFsObhl4E/xPcYwuxBDKbn96ppkQZL99mydej4QCpggMpaa65DSb+uKLmYRlFOc= Received: from pc6 (86.169.153.236) by HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Tue, 9 Jan 2018 17:00:55 +0000 Message-ID: <002501d3896b$4c17a3c0$4001a8c0@gateway.2wire.net> From: "tom p." To: "ietf" Cc: , , , References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> Date: Tue, 9 Jan 2018 16:38:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: HE1PR0701CA0056.eurprd07.prod.outlook.com (2603:10a6:3:9e::24) To HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f731702-b3e6-4070-4f50-08d557828cde X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020040)(4652020)(8989060)(4534070)(4602075)(4627166)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 3:BnwOBhHRKjqCJa7/JAcvjZP5IpweS35+8J27Yj5RK4TittxW3NlvvhykRU6EutMRSH2a7GtB0rVPquDFel5+P25BBkuwUyUeLSxTafwu2UACUSsfM1yT6IoEnCtX+h5GfaWVi+dosGbgauUyL+jBe4vNq3jFPSJe9ALntZ8I/RkjA5/hMl3vWmFX5hoHgRwXvaWJtpCFsCl4V7/vjAsiC3pcTIUC2hFXExrmcnzmhXTxaSjJLHUXToZ/wggG1GSt; 25:ye6a+9/8PrxCUFbt/Alw16PzIivqFT/mkoK9YqdRvOfiu4m3O18AGt8eC/b+e6JII3INTKQxQ8iw4Yh1EFjR3ZqRLn/ro1WVviH8GrnKXzEcXGr9las33Z+H0Fiqr3AHshVG/RdaoJwVlOxD9h/WIjKCyB4pZF2ut9OvQqHB5+TLIW2FzaJBwxzwg5vUNfLwaaWx2sGDnI1QP4cDW2jE/Eo6hpG9206A2CL1kdO3B5/cchePnHjjT2zDNX7O0aNYZEggwEc60GZCW5ES0+KFice52Nv3Mx31yT/xUDmtfMde04Y6Z8+ZkblsjTT/ITP6zu3cZqmt5nXugcDPwT76Vw==; 31:E9oQ8oVhfNbJTN3FgO/DEuUJM5+GUY7UzyPIWGyWfvTmXhwVyK7+YYJ2ovuSKCr8U2FGGDTPqJgf1a4nDvdTOJtd21ULg417SQcxozrAM/H2u6QQmd88tQeGjdn02ZUvpOshJLhw8XY2+znV756GkPSV6nW1nrm/jeFdULmCU2xa0M7o9AegBUahzlfzjq1FwaX6jwXEoyqqMSd2EEmCQwCA+3DLNBeFqSxeMGf3Pwo= X-MS-TrafficTypeDiagnostic: HE1PR07MB1563: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(944501110)(6055026)(61426038)(61427038)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR07MB1563; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 4:bMJzkoM6MGFatRon6LrtkAq4mMR74vLtpPhW/PEk9f2uVsRS1lKv6gdejL/6oLA89BA/+oE0EBRHPytYddNtV3ha/UnU+wIb6WRhGozUZm5lkjDOfjozxH91h3VDi20FtWJnte1yjyOqcNIkNg/xFII1WvsK8HCAQhKiTRuLMhyuTzz7MGoZEi2Eg/c5U9ikZCNrEb++WWkB6gFEWd7W7O7VWdu/CTTzdpwlsphQCpAcMVhGTFSl0FYaewEGdczQrSacLvq+QSdKGA3DBxjSBqhpTLyh/onzFSdczW/Xw2+G+9k0X4fJADm1lbwzbNe8 X-Forefront-PRVS: 0547116B72 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(39860400002)(39380400002)(189003)(199004)(13464003)(305945005)(16526018)(68736007)(106356001)(47776003)(7736002)(6496006)(54906003)(62236002)(1456003)(44716002)(66066001)(86362001)(25786009)(23676004)(1556002)(50466002)(6346003)(61296003)(105586002)(52116002)(229853002)(386003)(5660300001)(14496001)(81686011)(8936002)(59450400001)(6246003)(478600001)(6306002)(230700001)(230783001)(81816011)(50226002)(76176011)(53936002)(966005)(84392002)(33896004)(5820100001)(116806002)(44736005)(6666003)(4326008)(4720700003)(2906002)(316002)(8676002)(6116002)(81156014)(3846002)(97736004)(6916009)(9686003)(81166006)(6486002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1563; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNTYzOzIzOnZ5QWVTclVRb2JvQm9hNjl2UWUwdm1vbzlw?= =?utf-8?B?cURuUUpZa0FwVDRWTmZ1djhyMXBaaHpxNkw2aFVVUExEWC9sTVJwdGMvSVNT?= =?utf-8?B?NXVQci9JeHBlb3JVRzNWUjFOME5wRnI2a0I1UDRFNmtHQ3Z2ZmlJWGJ3dlNs?= =?utf-8?B?dXpEenpYajNxQmM2K2t2cmNxeEtwemJ6N2RsVGJEL2JOUTVYb1hud1JraWUy?= =?utf-8?B?L2JKUnAvUU9OTmVBTW5pbnRhdGRJRzY1cktXYTFpSFM1U2loZStTK002QlVV?= =?utf-8?B?Tks4VlRmTFA5OWRpeXI1dm9EdTdyS0Z3clBtallBcEp0VFU4NGVqNDR4RG1m?= =?utf-8?B?bjVwaHF6Um53c3BoUzVsK1lZMzg0Q3JPN1Uwbk1maDJKVEtmWFArQlZmb2tI?= =?utf-8?B?MHdMZjNVOWMxTEtUeUttU0FMdVJXM2pmb1RMZUZVaVVCcllrVGFFUWpQcE1G?= =?utf-8?B?cjJuVjQydTloWWNvQWgrWU5IM0Q1R09HUjhyK0wyNDJDb1hYSzArbGticzFU?= =?utf-8?B?VEcxYi9uU29zR0pTR2dwL2I1TWtLZlZyUDhOVjRhTExON1NES3RkUUJiR1Rr?= =?utf-8?B?dzE2QSt2S0ppazRpQlVSdmltbnZ0S1VFRTlYemMwSmp3aXN3dndhdUNEK3Rw?= =?utf-8?B?dnFNQ1JwdXpDUXFYS2N6YkMraEZQTjlYdjRBR1ZvMEd2M0U2OWZZcVd4U2VP?= =?utf-8?B?c3FwRkowcHd1WmE5ZEkyUUFlK1hOVEFBUVVCU016ZlNxdTZYdlJ4akVPWUg1?= =?utf-8?B?dEtleG44cUNzLzN6cHdUdU1iWktrT09BQzVtbXlZN0ZreWlhVVFiblBCRW9G?= =?utf-8?B?dXBGNjloaWNxU3JvQ0xjSlpqakdiTllNZkdaSlNTUnh4UDlEQjFtTlVPYzdW?= =?utf-8?B?MWxIeXhUaTExcWs5bEpOY1U2dHllbWk1cmFsWDhmMmx5RGgrRnhTQzJTc2s3?= =?utf-8?B?cUY4QUMrMzRTUjZ3Y2lNNVJrQWIxdkJUTzBja0p0OG5OZ0VZUEczNVRxUDdN?= =?utf-8?B?cWRteGM3UTl4ZkdYamppM0NJaFAxc1U2V1EwcGVMczVxRUIzMnB6N2tKK0dG?= =?utf-8?B?T0tGakRTZlFscm4xS20xbHg0dUJUdVZ1dzl3NDl4QWhnTFhqaERWMXlmUVU3?= =?utf-8?B?d1VoeUJjNmNZaWkvNUtBUGxFTVh5QkgvNTh2WTRBT3FCUE0rQzN3T21neHFv?= =?utf-8?B?UDRRaEZ1L1phZDFKV1p0SlhrTUluZUFvcE5jUVYySkRXOUZNbHdqWDhFZTJ1?= =?utf-8?B?U3Q0OWZteFNpT1UvWkorL0ZJWHZRc1N0MVhTeUY5SXQySTg5S3hnY3VkUUxn?= =?utf-8?B?OTBQL0NQRmx1TzRQU2wzUmI0Q3dnVzFlQ2RjOUNKL2dmVFkrQzFtVVlPOWkv?= =?utf-8?B?aDErVjkzQzRRWUxWakxDTjFLdXQ3ZEJ4anhRempVZE5wTWYzeTNkVTM1Vmwx?= =?utf-8?B?bzBrZ1NzcE1aVEpnOVdEbG5tYWdEK3JlNXRzRVhtcWlDNGo2dEVPUDFlMXBX?= =?utf-8?B?a1lGRlJLUDhlejJicUlPcWF5c0xoTDlwOGFjdS9sYmFEaW80OUtqTTBpanZZ?= =?utf-8?B?U05RUjBuTERSZTRVdHhoWGZzcXRkNnljY2JQTXZVYlpJcVV4aG1HVzlsSER4?= =?utf-8?B?Sm03RkZOVlMrSDdOb3FIbUxPU2RLeU9Oanc2anQ5cGlWTTlwVW8rMjBNMFp5?= =?utf-8?B?bXlLYWZKMXdWc05YTVQ3K0NSVEM1UVhkZzQ3Y1VzSnRUS3VsSmpncHNiNklz?= =?utf-8?B?enlDanBMY0hWMTdlam5Cd1lRWS9VSThBdnEzWEhtS21UdE9RcnBUR05FZ2I2?= =?utf-8?B?RTVFdnJXc2Y3UXVqaWRieS9WRGhjdGtiWDAzOWpGZ1VsZlU0YnpRQnZ4bVY4?= =?utf-8?B?VU9uUXp1ZXl2a2VwN2JtRnZoc0ZUSWhOa3JsU3EyQmlSNzdSdlZ3UWdBd1Jw?= =?utf-8?B?ZElCTXZaaE5FNGhIMFlrNGEwdUlHZzdYRDlCcU13dHBOMTFURW1VM20zaEE5?= =?utf-8?B?WFliaEIxd1RnaUVQYXNIZkhZcFdJUzI4OXZzK254U3F2NVJla2JQMlBxYytz?= =?utf-8?Q?EJr2OxwPflsa1vYSwDhNRmc3S?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 6:8/im+oG6j+GFjEmnT3DzR7Q5bzraKfFL3SFYSgJ1B7laskmYkwOPNBMhGBG971RB8YwWYZnEWIUq3TWhBNOre3oeO0Hz84MWtIPsvmSkle+01seF+juToJyNntxBB14rNvjTYUBqqiOKtkeUfZFHDoFzjOd4HcYZT6+9LOOzFsZLotePzxOqFYASKnkd8Xlnkxd7j5MgeTABhB4dQ8+/HA7hlMmzmGkwNb7zSq619V9AqA8A7J9VdG99B60c5y5WHrvnJAJ1dSWzLnVaCQQPK3nTgMN8lPVBFB3REc8HUPM7n8BwWWEYSFMxXH481vjk5JeQbhBVK3tgfz566IbXm7r/kHOZp/w02FY6dOZVE+4=; 5:XCSGD6ewG0kpstlTG27NRbxpppKCXccJlDjB4RUgQVS7MEgTKvDpSDJswxhywYh3O94kEcey/+rQ6dn3ddU5Y2XpkeXwuU0xDgmkNGHhzcuEU1e8EsT+hVpHrDH59tdiDkVKoTedIU4oYyKA9P6/5WGHU1t7JTOCa/3LoeRHAHQ=; 24:aYa7gdPO2a6C6tIpmsjojhYcu65+zI4p+pizBhAX23VuN7noP4J1ewNher0KoSaSX5tXqCNAVR96YOcRAtwDsI5sj1Egn23H4QuVjgxT7s0=; 7:kmCZoAxCXmaABkhUk7DBuLPE4zCnP9nlWJyXL0qn8W8Bl0yyii/dYNbisXkzEA4UDYTLJ7aZ9V2QOTbibEddBkb2ewgH05vvy4LBWl51zRyVGEW2iY5CyzYk+l0ig+oVzdoBoRP2Tnt2wCv2XDH+hFyrLwl1fDAo2+0SBIgXBO/ABbu98lG+fUbJRILhI6gFqH1nShrCTTfELYZFfRQ7vxmDnK9UBbTGmjRGjrgBd2ZQSJMEfNESET/7Dn1Zctg7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2018 17:00:55.7287 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f731702-b3e6-4070-4f50-08d557828cde X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1563 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard configuration X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:01:02 -0000 This I-D re-arranges the tectonic plates which underly the IETF's management technology and is likely to affect all such work for some years to come. As such, I want it to be clear and unambiguous but do not find it so. I find it unclear as to the meaning of the word 'configuration'. Netconf (and latterly YANG) were instigated to facilitate configuration, which was narrowly defined as the values that a user might want to change to get a box from its initial state to its desired state. What might have been thought as configuration historically - values learnt from hardware or the interactions of protocols - was not configuration but state, latterly referred to as operational state. This narrow definition of configuration is reflected in this I-D. However, working through the 24 definitions that appear under 'Terminology', while the early ones use this narrow definition, by the time we get to "learned configuration: Configuration that has been learned via protocol interactions " or "system configuration: Configuration that is supplied by the device itself." the meaning has clearly changed to encompass all the different ways in which a device can learn a value i.e 'learned configuration' and 'system configuration' are not configuration as has been understood up until now in this work. I think it hard to follow this I-D when this key term seems to have a variable meaning. I am uncertain what meaning to attribute the word when it appears in the later text. Tom Petch ----- Original Message ----- From: "The IESG" Sent: Thursday, December 21, 2017 7:23 PM > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'Network Management Datastore Architecture' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > Datastores are a fundamental concept binding the data models written > in the YANG data modeling language to network management protocols > such as NETCONF and RESTCONF. This document defines an architectural > framework for datastores based on the experience gained with the > initial simpler model, addressing requirements that were not well > supported in the initial model. This document updates RFC 7950. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba llot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > From nobody Tue Jan 9 09:16:15 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 7A59E126DD9; Tue, 9 Jan 2018 09:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 o98dXQO24Xif; Tue, 9 Jan 2018 09:16:06 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60099.outbound.protection.outlook.com [40.107.6.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E54127871; Tue, 9 Jan 2018 09:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vNoN9fGS5Kw7a0xnwo5IvkGA9xLLQ1txFWzSJlrLGPU=; b=PZhMIlt0Uat5VFJDan3ybtFV4VYxV2B/4fSbxAX6z4RvM6xuGNjPnkQnVfgQqE3fyqyrwEzH/Qyby6C+AfSw4PJwN17LaLJQPUTlcgviixu2DtC+AwqrQMp8lNSvEy6y4gOK9vGfqQ4RzaiVNbj+fD2uyPaJKE3a8lmRlL9KrKc= Received: from pc6 (86.169.153.236) by DB5PR07MB1560.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Tue, 9 Jan 2018 17:16:02 +0000 Message-ID: <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> From: "tom p." To: "ietf" Cc: , , , References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> Date: Tue, 9 Jan 2018 17:14:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: HE1PR0701CA0052.eurprd07.prod.outlook.com (2603:10a6:3:9e::20) To DB5PR07MB1560.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0657620a-a16f-4cfb-fcf3-08d55784a979 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020040)(4652020)(8989060)(5600026)(4604075)(4534070)(4602075)(4627166)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:DB5PR07MB1560; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1560; 3:/HS2nfuXktdyATpNqYV2CV2wuC7hT/oFszR+7+zDJ+4CRfDaful6kxygg8xOd/U1v+DcSNRDMg10XfwkMK/1XFeHmEzTYCC5UfV6084ZnddpZ/xSZftJfmpg63ZSAnGIBYp1Il6MckcQZMLjB5Pi3vw1uKIid8oeJG+2A1jfphJEGkQ8eTI7fX8mUutoYFmB7WcFK+TFNL5kDi+a3IjtXZJOCrCfoM7Z1GW6i1e+3eW+RkUSwpcstchq1oT0Lb5X; 25:WrCby7Pynyna7Etx2bQB4P30faJSAddSzQcvqxzhNm7oh1fo1FI27qjv9AWLUcIVIPmP1LPYG6xyG+q2qn7T2yOtcJ6V7mZimGoy7zA/MlMsV+7HifDv6vE7geEaNErY5p5rgXwamMOgjJeadufKiteZWDVTB/OlDcpnAe7jFFdHAFPTbxHSOGbP1GkVdUggESXA4GZf95xAO2zXbycAG3Z5xSjQ32t5RbGQyXlE7SueBs7jqj0TnVqhNZJEYFTiKgtQdRGBIXtucHkArbUqBy7bdZdYnI1FAtO4JoWcT27s/QZhpoKJWRvJQWtni733Ta9AZarOduvG91ldloymug==; 31:JEdwxfKTRPPxaeeKYXoCXF6bHdovsvxOKmX0KJGkCRaDeblfAWWRH5wVLkXiIN2lIFd9a2433+7qxKKGJ1UyVfM0Ht78mi3YKp+kBcUpyEG3jlilFcuah6NYH1VbbTWTr6bn5LWblau3mVPf7w/nPPj4TqbmeT9afHA4DxUbniqEDS0+UynaufR1Wau7Imq/DafB85ETfjb8oG7VVcZAn2776aiEk+Vgf9qh0CPMiQo= X-MS-TrafficTypeDiagnostic: DB5PR07MB1560: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501110)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DB5PR07MB1560; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB5PR07MB1560; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1560; 4:QFSoc6CYd8mINMpk5ZPtatMTIlWLb+yDpjHe+9ZeQkP6qLlX/q799G1irvMz4scAkeQd+nv1YSksy9yOlk+a+gcsgXrt8EyfM7nvkE5KYLTpJIdO7pjHmPl41jgQqydDsjcxmW6wNYQ0ju3hpHmiEw3fx59+hZqifbDLqufqeNQjs0L4v94r4QBU9iSC4nHppQBCgBKR0Id/p7AU2F7Di3E4l3VqS0gL7JaEKUVifNQs2hUwa0VAxz2HGpoVhT7RLWdVMbsF+pyLQyzDl6xVq3VN8HMuht9ttpCOCnkiEbJ6nf1XWarA5tbWSGCQ/T9FayxZLRuhAGa7FWhoTC4VBXjfwMOm+2C8bde9p+wd35c= X-Forefront-PRVS: 0547116B72 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(396003)(376002)(39860400002)(366004)(13464003)(199004)(189003)(1556002)(84392002)(2906002)(9686003)(53936002)(62236002)(229853002)(76176011)(44716002)(14496001)(5660300001)(50226002)(66066001)(47776003)(68736007)(6496006)(6486002)(97736004)(6306002)(230700001)(7736002)(386003)(50466002)(316002)(305945005)(81816011)(23676004)(86362001)(52116002)(44736005)(59450400001)(33896004)(81686011)(8936002)(61296003)(116806002)(6246003)(106356001)(105586002)(5820100001)(8676002)(54906003)(478600001)(230783001)(6916009)(6666003)(6116002)(4720700003)(966005)(25786009)(4326008)(3846002)(16526018)(1456003)(81156014)(81166006)(6346003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1560; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNTYwOzIzOlRxb0tpa2ZnOHJqdWt6NkFvL0tSdkF1T29H?= =?utf-8?B?NHRJOVZ6K2pTUC92VzRFYXZ1RnNKUWk3S0l0cGtqelRyRTZqM2d1WFZHaWY5?= =?utf-8?B?NTdGeTRrNHNsZ1ozY2hmMm9uYm9Jb1ZMVUQ2VjBRN0dOalpSelEwUlZRbzF3?= =?utf-8?B?TzY5VFNDTjF1WnR4M0lKRUFVQVVteE05NStna0w4eDZmaGNSclAwbTRocCtT?= =?utf-8?B?M1RTOVZoKzdSRytLZnNVbkQ5U083S3FsSVJqbzFkeGdGR1JUQXhkclR4TmNN?= =?utf-8?B?Y1Y5ekNwTDN0Vi9kSFdsdlNvNlhhdHAyVTZqMHN3ZERnN3Fqam9NWXFRQTc4?= =?utf-8?B?ek9VNEhFQXdaaWRMam9aTThmRndETW5UMURaMjZwVjBoYjF1Z0phQjBZSVVt?= =?utf-8?B?RERxZGYydncxeXVpVWkrV3BOYnEyZ25KLzdscmNVSEJhS0dEVkxwbzNXQmd0?= =?utf-8?B?UzRNWllaN3JoUmozUjdJbno5aTByT29kOG5Ca0dVVE4vdXdKYW1QSDU4SmVM?= =?utf-8?B?c25WOHhPSkxha3JzUGNWVnNTU3NwN3BDRGEzZU1yN0FnQmU4MU9Jc2hFajhI?= =?utf-8?B?S1UrQnpod0dzL1BSY1hsdTJiL0Q1YUxFdFJ0VlJiVEM5S3AyRTN3RlZ2OGhw?= =?utf-8?B?MUkvdVVNank0dk93ZU1DZHBlVVU0N2ZJQ3VjMldXZUxvdTg1c0ZsSVV1Tk5J?= =?utf-8?B?L3c0K1AxL0dBWjJBS05yYzRkdjRSNGtQV2k4VHh2N08wamthd25iRXhuejZh?= =?utf-8?B?WkplVGhLQ0ZuZStENkNCUUtlZUp5U0IrVjhrUzlicE0vYTlCOG11QkwvWkFx?= =?utf-8?B?VU1pSGpZOWsyRjVuZlFHZzk5ZUhGTExFdHZxZXpEQUxoNDc0NFQ2Y0FSVzFn?= =?utf-8?B?bHhXdU1RUW02RUlwdzN3ZVA1czllZUVCOGhxekdOQ2hLbFBQejhFc3NNZzJF?= =?utf-8?B?YWRQZkhFVisxaFJHS3NwUThEQWFydWdNek9rVERoNU1xYzVUZm5IUmRraldM?= =?utf-8?B?bkNwSUtpWERPV1B6eGpGZTVVWUM4amRDZVVGS2tFNmRBeEJkdm9aTDgxOFFD?= =?utf-8?B?akV0a01qVUZKUzJscUFJOWt6enJ6Y3FrWEJsaUpsUW1IWnZpVnRDMVZKSXYz?= =?utf-8?B?L2h0MUZwT29FbEhocUdhU2VBV1A1NUovL0JvZGpnK0pBKzlvaGR0QWZaVnFI?= =?utf-8?B?S3lRWm5peVdwRE83T3lORXpGc2lobDlqSVo3T1Q0VnN5SWZVTzVMWUUvaDNr?= =?utf-8?B?UEUvY2ZmaDAyelFqM29wajEyRkRVN1VDU0xHZUVBWi9zUGdwUlZLM1VXUGVO?= =?utf-8?B?T0tzR0U4UTRmeWlIWG5FN3ZyVkJBaVZzY05RQXgyMGc3b1JIL3Q2TzB4N3Ex?= =?utf-8?B?ZFo3U0J1ajlpZzd0b2U1a1V5SUpScVFBcEkwRm93NUlsV2dkd1k5WXpPelNl?= =?utf-8?B?ckZvWDBDRkZSTVQ3UW1WV2lETkppMHViaFhFTkZ3enpFY3JpTVZVWC9wQW1a?= =?utf-8?B?KzI0U1R3V081ZndzemV2QmxUZ2taaytMTWxIUUpjaXN1UVBnTExkSU0ySlpm?= =?utf-8?B?LzQ2UXlNaENNM3VnTUlsZHBOWlV0ZEUzUGJUM2hyTDVUa0hoeU9lZ2N6S0t3?= =?utf-8?B?R0c5bjVjbjhIdTk0czYweXVEQkxmM2R6WUpGajFnK3J3bmNzcXZ0NFc5ckFZ?= =?utf-8?B?TGhoRTYvdkl1eVBjN2xSNjFpRnNlbE95Q0FlZ25Qb01LNG5YdE9YK1pNQllG?= =?utf-8?B?bkJqNFZIWTI0VkNMS2ZSQjNSZkRHWlNhS1k2a2FOaUMyUHdGZ1VVL2QvMGd5?= =?utf-8?B?c3kvSWhPK0hrbWVmK2FyQWhtV1ZZcTFpM1E4OW1NcTA2TmYxZjZJSWtQYi9W?= =?utf-8?B?Ujd6Y0lWTC9yS055NEt2RCtRS0JwUGllVlU5ZEtlTGpYVWUyQUtyYmUwK3V5?= =?utf-8?B?Y2FYeDlXSVZOSjNWZTdWNmx0VXArSlRrUXVXalEwVktXVFJMVUMyRS83ZTNT?= =?utf-8?B?NEoxeEozUXdiNlN5dnUxcFZMOUVyNUV5T3VoOHE4clNSV3dsejRFU3BLSjBF?= =?utf-8?Q?IoZ/KW6vP5Kn8sEu6XrOvIr6m?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1560; 6:3qXLj//1CVUvg0N1t4MHIOjswWaNJVV0edpNoboZbeRRrWQeNkU1r/iOIq1zRfm6Y6si8VEYI4GOZcRVlIae0bKMLaxg6qlTmEnlsorJEj1vWsZoDmzbQ23K9AkJ5EhyIucQ1QYU8DKH1WxcwBPM5P/YeHed4rA53CEou25QHqw5Vv2X0sk1/GNlloqKHRdSkjMYLR/CjuuTIOkPqpBm5k/P7ZCe2+g6oYHw6cCRhTbX3YpVzOn4PBLVvMy43IsVcBYkkH+gsRvG5Ye2Ll92vaNwxhibrQ4l3UbGXXynVCZ+0j3ud+JJsJIt5NDuJE3UQW/K/VyTBjoxZ/gw3jOf1kYo2Z58sv7KlXAt+RgeWJc=; 5:8IpRloPbPZlyN1/RmCn6YMO3D88ok0iJDMQRPGKTvH9dqAW+iYesIiBNupkfXQtk+X3FoP+1Oj1Dz8zYtCvGtVYiuh8RL42MOirzsKmOivRoXXP6AMNAcxhAAZExhGji3s81uvQeZRtvCkTfex+AeoBWQtQtLuJgTjAQQkPZA+s=; 24:bLxRsp/r3WH0Bxq9kj3/a26H4zcJPWu4kcCn+JxGIHUYTlGXms073fB6HFqfFLUkZdJ2KfpdbuWa79A4IXPtiHdsIfO6cng3TonBv8dgwP0=; 7:sDdjcV73UNNPuk87YAOB8oRmTWObn4/vhtNHQQUgEdp3RIzRQ7ILD7ZEWy4YaPHmaJadlEDrk0qQXGNxmnHag4W/IZyFXQa+w289wBGWNWs8nY5FdzFuQR8355BCVYyVtely6f+y06rm+50e1C1KTHb3nHExlv1xjlqOFm3fsiaJQZWtf03GqDCD1JsWcK7o710Y6zgzIYpVDG/jIFYz68q6xFi9yqyhM+HgyZOkFY1tRUqZQ8ckFKAlbAdJhhdO SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2018 17:16:02.3905 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0657620a-a16f-4cfb-fcf3-08d55784a979 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1560 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:16:09 -0000 Much of this I-D is about the idea that network management data objects can often take two different values. The I-D always refers to this as being two values but is that a limit that this architecture imposes; or can it be more? The later diagrams show three datastores, , and . Since " MAY also be updated independently of ", can there be three values? And since the architecture says that other conventional configuration datastores may be defined in future, can there be any number more values? I think this is a significant issue when set against the objectives, of exposing to the user what values there are in a server; the I-D is clear that there is one schema, but I am less certain about its insistence on two values. In a sense, there is a datastore, perhaps more than one, missing. The focus has been on configuration-related datastores and is now widening to put other object values into datastores. Yet the values learnt from hardware, protocols and such like will only be in a datastore if that value is used and so is in . If a user-configured value is the one put into , then values learnt by other means will not appear AFAICT. For completeness, there should be a datastore for values learnt from the hardware, from protocols and so on. (In fact, doing the sort of thing that routing protocols, which learn different routes to the same destination via different means, have been doing for years:-) Tom Petch ----- Original Message ----- From: "The IESG" Sent: Thursday, December 21, 2017 7:23 PM > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'Network Management Datastore Architecture' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > Datastores are a fundamental concept binding the data models written > in the YANG data modeling language to network management protocols > such as NETCONF and RESTCONF. This document defines an architectural > framework for datastores based on the experience gained with the > initial simpler model, addressing requirements that were not well > supported in the initial model. This document updates RFC 7950. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba llot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > From nobody Tue Jan 9 09:26: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 B2701129516; Tue, 9 Jan 2018 09:26:05 -0800 (PST) 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_RP_MATCHES_RCVD=-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 2owArww3v49w; Tue, 9 Jan 2018 09:26:03 -0800 (PST) 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 3704C127522; Tue, 9 Jan 2018 09:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12176; q=dns/txt; s=iport; t=1515518762; x=1516728362; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rmMx1fcxKvg111FB9aFT8bvYBy/zUfdVe1I1r2z2h6A=; b=IbZB94rIzrUHzFE4Tqw8QInEBP5yhkP0fo4c6gcwAIGqTlpb+Bv4atq2 AQCS5qMOZf7Dn3AAEwChKmKNeNfiS7Ex8pSIR7N+ZO/qgJYE+7xemkxGJ sLflMLjq6voKn2TUkAgJyU6rurUByfOV3Un2i92gss7HrkBat902b/9AT o=; X-IronPort-AV: E=Sophos;i="5.46,336,1511827200"; d="scan'208,217";a="1312080" 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; 09 Jan 2018 17:26:00 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w09HQ0ro026867; Tue, 9 Jan 2018 17:26:00 GMT To: "tom p." , ietf Cc: netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <002501d3896b$4c17a3c0$4001a8c0@gateway.2wire.net> From: Robert Wilton Message-ID: Date: Tue, 9 Jan 2018 17:26:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <002501d3896b$4c17a3c0$4001a8c0@gateway.2wire.net> Content-Type: multipart/alternative; boundary="------------4EB7A8894C3059BBFAE51E41" Content-Language: en-US Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard configuration X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:26:06 -0000 This is a multi-part message in MIME format. --------------4EB7A8894C3059BBFAE51E41 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tom, The draft uses this definition for configuration: o configuration: Data that is required to get a device from its initial default state into a desired operational state. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources. The last sentence means that it encompasses configuration that comes from other sources such as protocol interactions.  I.e. by different sources it means that configuration may come via DHCP, or be learned from a peer protocol (e.g. hello timer values, Ethernet auto-negotiation settings). The other sentence that is key is 'This data is modeled in YANG using "config true" nodes.'.  This statement applies both ways.  If you want to model configuration in YANG then it must be labelled "config true".  Hence all nodes in the schema marked as "config true" are by definition, configuration.  Conversely, all nodes in the schema not marked as "config true" are by definition, not configuration. So, I don't think that the definition for "configuration" changes through the definitions at all, it has the same meaning through out, i.e. the broader definition that encompasses data learned from other sources such as DHCP, peer protocols, etc, as well as conventional configuration received via NETCONF/RESTCONF or similar "regular" configuration protocols. I think that the intent of "conventional configuration" probably matches your narrower definition of "configuration" that you describe below: Thanks, Rob On 09/01/2018 16:38, tom p. wrote: > This I-D re-arranges the tectonic plates which underly the IETF's > management technology and is likely to affect all such work for some > years to come. As such, I want it to be clear and unambiguous but do > not find it so. I find it unclear as to the meaning of the word > 'configuration'. > > Netconf (and latterly YANG) were instigated to facilitate configuration, > which was narrowly defined as the values that a user might want to > change to get a box from its initial state to its desired state. What > might have been thought as configuration historically - values learnt > from hardware or the interactions of protocols - was not configuration > but state, latterly referred to as operational state. This narrow > definition of configuration is reflected in this I-D. > > However, working through the 24 definitions that appear under > 'Terminology', while the early ones use this narrow definition, by the > time > we get to > > "learned configuration: Configuration that has been learned via protocol > interactions " > or > > "system configuration: Configuration that is supplied by the device > itself." > the meaning has clearly changed to encompass all the different ways in > which a device can learn a value i.e 'learned configuration' and 'system > configuration' are not configuration as has been understood up until now > in this work. > > I think it hard to follow this I-D when this key term seems to have a > variable meaning. I am uncertain what meaning to attribute the word when > it appears in the later text. > > Tom Petch > > ----- Original Message ----- > From: "The IESG" > Sent: Thursday, December 21, 2017 7:23 PM > >> The IESG has received a request from the Network Modeling WG (netmod) > to >> consider the following document: - 'Network Management Datastore > Architecture' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may > be >> sent to iesg@ietf.org instead. In either case, please retain the > beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> Datastores are a fundamental concept binding the data models > written >> in the YANG data modeling language to network management protocols >> such as NETCONF and RESTCONF. This document defines an > architectural >> framework for datastores based on the experience gained with the >> initial simpler model, addressing requirements that were not well >> supported in the initial model. This document updates RFC 7950. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ >> >> IESG discussion can be tracked via >> > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba > llot/ >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> > . > --------------4EB7A8894C3059BBFAE51E41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Tom,

The draft uses this definition for configuration:

   o  configuration: Data that is required to get a device from its
      initial default state into a desired operational state.  This data
      is modeled in YANG using "config true" nodes.  Configuration can
      originate from different sources.

The last sentence means that it encompasses configuration that comes from other sources such as protocol interactions.  I.e. by different sources it means that configuration may come via DHCP, or be learned from a peer protocol (e.g. hello timer values, Ethernet auto-negotiation settings).

The other sentence that is key is 'This data is modeled in YANG using "config true" nodes.'.  This statement applies both ways.  If you want to model configuration in YANG then it must be labelled "config true".  Hence all nodes in the schema marked as "config true" are by definition, configuration.  Conversely, all nodes in the schema not marked as "config true" are by definition, not configuration.

So, I don't think that the definition for "configuration" changes through the definitions at all, it has the same meaning through out, i.e. the broader definition that encompasses data learned from other sources such as DHCP, peer protocols, etc, as well as conventional configuration received via NETCONF/RESTCONF or similar "regular" configuration protocols.

I think that the intent of "conventional configuration" probably matches your narrower definition of "configuration" that you describe below:

Thanks,
Rob


On 09/01/2018 16:38, tom p. wrote:
This I-D re-arranges the tectonic plates which underly the IETF's
management technology and is likely to affect all such work for some
years to come.  As such, I want it to be clear and unambiguous but do
not find it so.  I find it unclear as to the meaning of the word
'configuration'.

Netconf (and latterly YANG) were instigated to facilitate configuration,
which was narrowly defined as the values that a user might want to
change to get a box from its initial state to its desired state.  What
might have been thought as configuration historically - values learnt
from hardware or the interactions of protocols - was not configuration
but state, latterly referred to as operational state.  This narrow
definition of configuration is reflected in this I-D.

However, working through the 24 definitions that appear under
'Terminology', while the early ones use this narrow definition, by the
time
we get to

"learned configuration: Configuration that has been learned via protocol
interactions "
or

"system configuration: Configuration that is supplied by the device
itself."
the meaning has clearly changed to encompass all the different ways in
which a device can learn a value i.e 'learned configuration' and 'system
configuration' are not configuration as has been understood up until now
in this work.

I think it hard to follow this I-D when this key term seems to have a
variable meaning. I am uncertain what meaning to attribute the word when
it appears in the later text.

Tom Petch

----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
Sent: Thursday, December 21, 2017 7:23 PM


The IESG has received a request from the Network Modeling WG (netmod)

to

consider the following document: - 'Network Management Datastore

Architecture'

  <draft-ietf-netmod-revised-datastores-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits

final

comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may

be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of

the Subject line to allow automated sorting.

Abstract


   Datastores are a fundamental concept binding the data models

written

   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document defines an

architectural

   framework for datastores based on the experience gained with the
   initial simpler model, addressing requirements that were not well
   supported in the initial model.  This document updates RFC 7950.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

IESG discussion can be tracked via


https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba
llot/


No IPR declarations have been submitted directly on this I-D.





.

--------------4EB7A8894C3059BBFAE51E41-- From nobody Tue Jan 9 09:33: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 7BD57127522 for ; Tue, 9 Jan 2018 09:33:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 M3piTdMc7NtE for ; Tue, 9 Jan 2018 09:32:56 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 61A29124207 for ; Tue, 9 Jan 2018 09:32:55 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id h137so16800024lfe.8 for ; Tue, 09 Jan 2018 09:32:55 -0800 (PST) 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=PP3hHq1r4F5Vq0QZFmr5JoCrL+FJB2YfB8RHgN9lpqI=; b=pLN7qKHHv/JsrhKZMkf+AUbcL0IZ5vHfyPinvhxxL8304x+NqWZYX5iailMmiaUXar HA/U0+yfAiunRj0hLUQtThldeKJOGBENYt4XCs3LLF9e3S1H4mOQpuOi0yNA/zJNDhNS H/UiIKcM6RNMoBJ9+Ug2IdAhCzrAVIBzTCJ9TkZDUt3V6RYYMXILa9ArQwzzw81BKx7J nmG6jmUQYMG9tDgnx1OSLV01b0KJ/ShxZJmRlRVCM1VkaF+gXmIiipDanGp3bucSR5ot z5IdJXWBRwqiVV2qA88ndZje7jwFm4OTNCz5Y+Fv3oI5AgcqlRzu7dHqro4PKm4ZCOOH B+bg== 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=PP3hHq1r4F5Vq0QZFmr5JoCrL+FJB2YfB8RHgN9lpqI=; b=mQrbAFbPZVuOc49qPkuz8i6KBcjjbfadbH0nqDs42im34SaR7lQ/tsyRwTSsjhzUOp VMPihFOnmp88yVbX745MCxgHG/s0NpMSqPjOSpbJPp63Yl/1Zbtr2f8ecqco1CfuGUTj nrpt21gF+3aenzvEd2lY27K+DYjOwBNtkVc0zZXsJTFQd0d0j31Mfu4KTHSVJU1TNJH2 AvGqYvi/+iJjYTGycQyTZFwUUab+Eu2qS240uE6DgO3pjLBxlwb2n0nbi03W0ZI9NLeq Q3caDDVGMjz31l2TjmjInD7S2CyF4XtcPN3+uyNuMQ9Vv9lHaV//knKExOePFIXETTQT r3ew== X-Gm-Message-State: AKwxyteeu2BJbOxp4lG4e78Ode+wOzh9yeR+y4Uf0IceEFHFWMEIdBY4 qLOu6vdDfkzCGXX7lKbErXqFIIRnz0zIU5JtQvWkWA== X-Google-Smtp-Source: ACJfBoveAQanwIix2981jLWXXykFA+UX469covc5wLXOnZisO8+XgMIgQ7C8t3JBm3otHkm72pmEObP5wE53LoH3JQw= X-Received: by 10.25.202.91 with SMTP id h27mr2623085lfj.62.1515519173284; Tue, 09 Jan 2018 09:32:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.95.22 with HTTP; Tue, 9 Jan 2018 09:32:52 -0800 (PST) In-Reply-To: <20180109.122807.1121028038684414186.mbj@tail-f.com> References: <20180109.122807.1121028038684414186.mbj@tail-f.com> From: Andy Bierman Date: Tue, 9 Jan 2018 09:32:52 -0800 Message-ID: To: Martin Bjorklund Cc: Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="f403045e9f64f9c15005625b4d05" Archived-At: Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:33:01 -0000 --f403045e9f64f9c15005625b4d05 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 9, 2018 at 3:28 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > Hi Andy, > > > > > > On 08/01/2018 19:45, Andy Bierman wrote: > > > > > > > > > On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton > > > wrote: > > > > > > Hi Andy, > > > > > > Regarding your comment below, this intent is captured by this text > > > describing the operational datastore in section 5.3: > > > > > > 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 due to remnant configuration (see > > > Section 5.3.1). Note, that deviations SHOULD be used when it > is > > > known in advance that a device does not fully conform to the > > > schema. > > > > > > Only semantic constraints MAY be violated, these are the YANG > > > "when", > > > "must", "mandatory", "unique", "min-elements", and > "max-elements" > > > statements; and the uniqueness of key values. > > > > > > Syntactic constraints MUST NOT be violated, including > hierarchical > > > organization, identifiers, and type-based constraints. If a > node in > > > does not meet the syntactic constraints then it > MUST > > > NOT be returned, and some other mechanism should be used to > flag the > > > error. > > > > > > > > > Do you agree that this is sufficient? > > > > > > > > > > > > Not really. > > > It does not address my concern, which is that NMDA is > > > removing the YANG constraints on config=false data nodes > > > for no apparent reason. > > > > There is a reason. I don't think that the constraints on config=false > > is really being removed, because I don't think that they truly existed > > in the first place (despite what RFC 7950 might indicate!). > > I agree. But note that RFC 7950 says: > > o If the constraint is defined on state data, it MUST be true in a > valid state data tree. > > It is not defined anywhere that must return a "valid state data > tree". > This is yet another where the protocol definitions placed in the YANG RFC are incomplete. The term "state data tree" is not defined, and only used in this instance, so this sentence is fairly meaningless. Andy > > In reality, I suspect that all implementations of call various > instrumentation call back functions in some order, possibly in > parallell, which means that data will be collected at different times > from the backend systems. I don't think it is feasible to freeze the > operational state of a device, collect all data, and unfreeze, in > order to get a consistent snapshot of the operational state. > > > /martin > > > I think that we all agree on the expected behavior for configuration: > > If a client sends configuration to a server that would cause > > to become invalid then the server should reject that change, to ensure > > that always holds a consistent configuration. Having a > > consistent configuration is the most important property here. > > I.e. the server has the right to reject an invalid configuration > > request from a client. > > > > However, the flow of operational state data in opposite direction > > cannot hold to the same rules. If during the processing of a get > > request (or YANG push) a server sends operational state data back to a > > client then a client has to choose how to process the message: > > - if the message is garbled or not sane then it makes sense to > > discard it. > > - however, what should the client do if the message is well formed > > but either (i) contains some values outside the permitted schema range > > (but can be represented by the schema datatype), or (ii) by applying > > the values would cause the clients copy of to become > > invalid? > > > > If the client discards the message because of one bad value, then that > > doesn't seem to be helpful, since it allows for a very fragile model > > of system management. I.e. if one small thing is bad then the whole > > house of cards collapses. > > > > So I think that the only sensible behaviour here is that the client > > has to process the operational state update in a best effort fashion, > > keep all the good data and probably flag any values that are outside > > the value constraints. Similarly any reference constraint failures > > (i.e. when/must) can similarly be flagged up, but throwing away an > > update message that would cause the operational state to become > > inconsistent doesn't seem to be helpful. I.e. it is much better if > > the client gets to see the true state of the server, even if that > > state isn't good (or consistent). > > > > Similar questions arise on the server itself: > > - what if the real value in use (e.g. that is read from the hardware) > > is outside the permitted range (because of a logic defect)? Is it > > really better to suppress that value entirely or return a value that > > server knows to be wrong? > > - can a server even know that its operational view is consistent? For > > complex systems where the real operational state is split across > > multiple underlying linecards, or remote devices, I think that this is > > very hard (if not impossible) to do. > > > > So what the NMDA architecture states is: > > (i) if a server knows that it won't conform to the operational schema > > then it must use deviations, > > (ii) a server in a normal steady state should conform to the > > operational schema (and be valid), > > (iii) but, if the system is churning (e.g. configuration, route > > update, etc) then the operational state of the server might be > > transiently inconsistent and this is OK, > > (iv) if, the server is in a bad state, then it is better to return > > the actual state than to lie or not report a particular value (as long > > as it can be encoded). > > (v) a server does not need to explicitly validate that its view of > > operational is valid. It is unclear what it would/could do if it > > detected that the operational state is invalid, nor is it clear that > > servers would generally be able to always perform this operation. > > > > > > > > The server implementation requirements expressed in YANG constraints > > > are applicable to any data node, not just config=true data nodes. > > > The requirement to implement the ancestor nodes (with keys) does not > > > change. > > > > The draft does not allow this to be violated. I.e. the following > > statement prevents this: "Syntactic constraints MUST NOT be violated, > > including hierarchical organization". > > > > > > > The requirement to conform to the YANG constraints defined within > > > config=false > > > data nodes does not change. > > > > > > To do otherwise does not make sense. E.g. "when" conditions that add > > > ethernet > > > counters only when the interface type is ethernetCsmacd. Why would it > > > be OK for > > > the server to ignore that when-stmt and add ethernet counters to every > > > interface? > > > > It is not OK for a server to ignore that and add Ethernet counters to > > every interface (without using a deviation). The draft is not trying > > to allow that. > > > > But if an interface could change type (e.g. between Ethernet and ATM > > via a different optics module being inserted) then it would be allowed > > for a server to transiently report the ethernet counters on the > > interface whilst it is in the process of changing the interface type > > from ethernet to ATM (e.g. if the counters are maintained by a > > separate daemon that is updated asynchronously with respect to the > > config or optics change). Once the change had completed, the the > > system reaches steady state then the Ethernet counter must no longer > > be reported. > > > > Thanks, > > Rob > > > > > > > > > > IMO the text above can only apply to the operational values of > > > config=true nodes. > > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > Andy > > > > > > > > > > > > On 21/12/2017 22:49, Andy Bierman wrote: > > >> Hi, > > >> > > >> It should be clear somehow that server requirements to provide > > >> config=false data > > >> that is valid according to the YANG definitions is not affected > > >> by NMDA. > > >> That is not being taken away. The ability to validate > > >> operational values > > >> of configuration data has never been provided, and therefore is > > >> not being taken away either. > > >> > > >> A constraint on config=true nodes only applies to configuration > > >> datastores. > > >> These are the only constraints that should be ignored in > > >> . > > >> Constraints on config=false nodes still apply in . > > >> > > >> > > >> Andy > > >> > > >> > > >> > > >> On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder > > >> > >> > wrote: > > >> > > >> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev > > >> wrote: > > >> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote: > > >> > > > >> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir > > >> Vassilev wrote: > > >> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote: > > >> > > > > > >> > > > > Hi Vladimir, > > >> > > > > > > >> > > > > First point of clarification is that this is not > > >> about running/intended > > >> > > > > at all. The contents of running/intended do not > > >> change in anyway > > >> > > > > depending on whether hardware is present or absent. > > >> > > > > > > >> > > > > The section is only concerned with how the > > >> configuration is applied in > > >> > > > > operational, and basically says that you cannot apply > > >> configuration for > > >> > > > > resources that are missing (which seems reasonable). > > >> E.g. I cannot > > >> > > > > configure an IP address on a physical interface that > > >> isn't there. Or if > > >> > > > > the physical interface gets removed then the > > >> configuration associated > > >> > > > > with that interface is also removed from operational. > > >> > > > > > > >> > > > > Operational isn't validated and data model > > >> constraints are allowed to be > > >> > > > > broken (ideally transiently). > > >> > > > I want to focus on this. IMO giving up schema validitiy > > >> for any datastore is > > >> > > > unacceptable price. Pre-NMDA devices had full model > > >> support in operational > > >> > > > data (all YANG constrains part of the model without > > >> discrimination were > > >> > > > enforced). > > >> > > There was a long debate about the value of returning the > true > > >> > > operational state. What do you do if the operational > > >> state is invalid? > > >> > > A server can reject configuration changes if they lead to > > >> invalid > > >> > > state, a server can not reject reality. > > >> > IMO if the model can represent reality then data conforming > > >> to the model > > >> > can. If not a better model is needed not a hack that breaks > > >> the datastore > > >> > conformance to the YANG model. I do not see how > > >> > /interfaces/interface/oper-status=not-present was not > > >> representing the > > >> > reality of a system with removed line card that is > > >> configured and ready to > > >> > resume operation as soon as the line card is reconnected. > > >> > > >> I assume this is all system and implementation specific. If > your > > >> system knows about interfaces that are not present (i.e., > > >> there is > > >> operational state about them), you can report these > > >> interfaces. But > > >> 'is configured' is confusing here. I am not sure a line card > > >> that does > > >> not exist should be considered configured. But yes, this may > > >> be system > > >> specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still > has > > >> oper-status 'not-present' - so this seems to be a mood point. > > >> > > >> > > > If this is about to change it will compromise > > >> interoperability > > >> > > > and a significant portion of the client implementation > > >> workload that can be > > >> > > > automated will need to be coded in hand and tested. > > >> Unresolved leafrefs, > > >> > > > undefined behaviour of different implementations > > >> removing different > > >> > > > configuration nodes in violation of YANG semantic > > >> constraints (which I do > > >> > > > not think can be so clearly separated from the > > >> syntactic constraints when > > >> > > > one considers types like leafref, instance-identifier > > >> etc.) and the > > >> > > > corresponding side effects based on the server > > >> implementators own creativity > > >> > > > is eventually going to create more problems. > > >> > > > > > >> > > > 1. IMO the only acceptable solution is to have YANG > > >> valid operational > > >> > > > datastore at all times. operational like any other > > >> datastore MUST be valid > > >> > > > YANG data tree and it has to be a system implementation > > >> task to consider all > > >> > > > complications resulting from the removal of the > > >> resources leading to any > > >> > > > data transformations. If this is difficult or > > >> impossible other mechanisms to > > >> > > > flag missing resources should be used (e.g. > > >> > > > /interfaces/interface/oper-status=not-present) This > > >> sounds like a useful > > >> > > > contract providing the value of a standard the > > >> alternative does not. > > >> > > As said above, it is impossible to report valid > > >> operational state if > > >> > > the operational state is not valid according to the > models. > > >> > > > > >> > > > 2. Even with the change in 1. I do not see the removal > > >> of intended > > >> > > > configuration nodes from operational as a solution > > >> worth implementing on our > > >> > > > servers. I do not see a real world plug-and-play > > >> scenario that can be > > >> > > > automatically solved without specific additions to the > > >> models e.g. > > >> > > > /interfaces/interface/oper-status=not-present is > > >> oversimplified solution but > > >> > > > it needs to be extended exactly as much as the solution > > >> provided by the > > >> > > > removal of config true; nodes without the sacrifice of > > >> YANG validity of > > >> > > > operational. > > >> > > Your thinking is likely wrong. reports the > > >> operational > > >> > > state. It may have little in common with . > > >> Trying to derive > > >> > > operational from intended is likely a not well working > > >> approach. > > >> > The proposal for this solution ("derive operational from > > >> intended" e.g. > > >> > merge /interfaces-state in /interfaces) comes from the > > >> revised datastores > > >> > draft not me. > > >> > > > >> > By definition config true; data represents intent. Reusing > > >> the model of a > > >> > config true; data to represent state absent of intent (e.g. > > >> > /interfaces/interface with origin="or:system") is a hack. > > >> The hack works > > >> > fine without compromising the conformance of operational to > > >> the YANG model > > >> > as long as certain conditions are met. I am pointing out > > >> that one of the > > >> > conditions is to keep all of the intended configuration > > >> data present in > > >> > 'operational' and handle missing resources with > > >> conventional means e.g. > > >> > /interfaces/interface/oper-status=not-present instead of > > >> adding the straw > > >> > that breaks the camel's back. > > >> > > >> I fail to see why you believe all objects that appear in > intended > > >> configuration needs to exist in applied configuration. In > fact, > > >> operators told us very clearly that they care about the > > >> distinction > > >> between intended and applied config. > > >> > > >> > > > 3. Solutions like /interfaces/interface/admin-state > > >> stop working. With the > > >> > > > interface removed you can no longer figure if the > > >> if-mib has or does not > > >> > > > have the interface enabled so an operator has to use > > >> SNMP or wait for a > > >> > > > replacement line card to be connected to figure this > > >> bit of information. > > >> > > At least on my boxes, if I remove a line card, the > > >> interface also > > >> > > disappears in SNMP tables. Stuff that is operationally > > >> not present is > > >> > > simply operationally not present. > > >> > > > > >> > > > My > > >> > > > interpretation of the MAY as requirement level in sec. > > >> 5.3. The Operational > > >> > > > State Datastore () is that plug-and-play > > >> solutions can be > > >> > > > implemented without this limited approach that has the > > >> same problem as the > > >> > > > pre-NMDA only now we have to have /interfaces-state to > > >> keep config false; > > >> > > > data relevant to hardware that is configured but not > > >> present: > > >> > > > > > >> > > > configuration data nodes supported in a > > >> configuration datastore > > >> > > > MAY be omitted from if a server is > > >> not able to > > >> > > > accurately report them. > > >> > > > > > >> > > > I realize this discussion comes late. I have stated my > > >> objections to this > > >> > > > particular part of the NMDA draft earlier. > > >> > > I believe there is a conceptual misunderstanding. I think > > >> there never > > >> > > was a requirement that a server reports the state of > > >> hardware that is > > >> > > not present. > > >> > "Data relevant to hardware that is configured but not > > >> present" is different > > >> > from "state of hardware that is not present". For example > > >> information > > >> > indicating when the line card became unavailable, what was > > >> the reason, or > > >> > other information like how many packets that had this > > >> interface as egress > > >> > destination are being dropped as a result of the removal. > > >> > > >> I think that systems handle non-existing interfaces > > >> differently. It > > >> seems that ietf-interfaces is flexible enough to accomodate > the > > >> differnet styles. > > >> > > >> /js > > >> > > >> -- > > >> 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 > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > > > > > > > > --f403045e9f64f9c15005625b4d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 9, 2018 at 3:28 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Robert Wilton <rwilton@cisco.com> wrote:
> Hi Andy,
>
>
> On 08/01/2018 19:45, Andy Bierman wrote:
> >
> >
> > On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton <rwilton@cisco.com
> > <mailto:rwilton@cisco.com= >> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0Hi Andy,
> >
> >=C2=A0 =C2=A0 =C2=A0Regarding your comment below, this intent is c= aptured by this text
> >=C2=A0 =C2=A0 =C2=A0describing the operational datastore in sectio= n 5.3:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<operational> SHOULD confo= rm to any constraints specified in the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model, but given the principal a= im of returning "in use" values, it
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is possible that constraints MAY= be violated under some
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0circumstances, e.g., an abnormal= value is "in use", the structure of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a list is being modified, or due= to remnant configuration (see
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.3.1).=C2=A0 Note, that= deviations SHOULD be used when it is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0known in advance that a device d= oes not fully conform to the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<operational> schema.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Only semantic constraints MAY be= violated, these are the YANG
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"when",
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"must", "mandator= y", "unique", "min-elements", and "max-elemen= ts"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statements; and the uniqueness o= f key values.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Syntactic constraints MUST NOT b= e violated, including hierarchical
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0organization, identifiers, and t= ype-based constraints.=C2=A0 If a node in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<operational> does not mee= t the syntactic constraints then it MUST
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NOT be returned, and some other = mechanism should be used to flag the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0Do you agree that this is sufficient?
> >
> >
> >
> > Not really.
> > It does not address my concern, which is that NMDA is
> > removing the YANG constraints on config=3Dfalse data nodes
> > for no apparent reason.
>
> There is a reason. I don't think that the constraints on config=3D= false
> is really being removed, because I don't think that they truly exi= sted
> in the first place (despite what RFC 7950 might indicate!).

I agree.=C2=A0 But note that RFC 7950 says:

=C2=A0 =C2=A0o=C2=A0 If the constraint is defined on state data, it MUST be= true in a
=C2=A0 =C2=A0 =C2=A0 valid state data tree.

It is not defined anywhere that <get> must return a "valid state= data
tree".


This is yet = another where the protocol definitions placed in the
YANG RFC are= incomplete. The term "state data tree" is not defined,
and only used in this instance, so this sentence is fairly meaningless.


Andy


=C2=A0

In reality, I suspect that all implementations of <get> call various<= br> instrumentation call back functions in some order, possibly in
parallell, which means that data will be collected at different times
from the backend systems.=C2=A0 I don't think it is feasible to freeze = the
operational state of a device, collect all data, and unfreeze, in
order to get a consistent snapshot of the operational state.


/martin

> I think that we all agree on the expected behavior for configuration:<= br> > If a client sends configuration to a server that would cause <runni= ng>
> to become invalid then the server should reject that change, to ensure=
> that <running> always holds a consistent configuration.=C2=A0 Ha= ving a
> consistent configuration is the most important property here.=C2=A0 > I.e. the server has the right to reject an invalid configuration
> request from a client.
>
> However, the flow of operational state data in opposite direction
> cannot hold to the same rules.=C2=A0 If during the processing of a get=
> request (or YANG push) a server sends operational state data back to a=
> client then a client has to choose how to process the message:
> =C2=A0- if the message is garbled or not sane then it makes sense to > discard it.
> =C2=A0- however, what should the client do if the message is well form= ed
> but either (i) contains some values outside the permitted schema range=
> (but can be represented by the schema datatype), or (ii) by applying > the values would cause the clients copy of <operational> to beco= me
> invalid?
>
> If the client discards the message because of one bad value, then that=
> doesn't seem to be helpful, since it allows for a very fragile mod= el
> of system management.=C2=A0 I.e. if one small thing is bad then the wh= ole
> house of cards collapses.
>
> So I think that the only sensible behaviour here is that the client > has to process the operational state update in a best effort fashion,<= br> > keep all the good data and probably flag any values that are outside > the value constraints.=C2=A0 Similarly any reference constraint failur= es
> (i.e. when/must) can similarly be flagged up, but throwing away an
> update message that would cause the operational state to become
> inconsistent doesn't seem to be helpful.=C2=A0 I.e. it is much bet= ter if
> the client gets to see the true state of the server, even if that
> state isn't good (or consistent).
>
> Similar questions arise on the server itself:
> =C2=A0- what if the real value in use (e.g. that is read from the hard= ware)
> is outside the permitted range (because of a logic defect)?=C2=A0 Is i= t
> really better to suppress that value entirely or return a value that > server knows to be wrong?
> =C2=A0- can a server even know that its operational view is consistent= ? For
> complex systems where the real operational state is split across
> multiple underlying linecards, or remote devices, I think that this is=
> very hard (if not impossible) to do.
>
> So what the NMDA architecture states is:
> =C2=A0(i) if a server knows that it won't conform to the operation= al schema
> then it must use deviations,
> =C2=A0(ii) a server in a normal steady state should conform to the
> operational schema (and be valid),
> =C2=A0(iii) but, if the system is churning (e.g. configuration, route<= br> > update, etc) then the operational state of the server might be
> transiently inconsistent and this is OK,
> =C2=A0(iv) if, the server is in a bad state, then it is better to retu= rn
> the actual state than to lie or not report a particular value (as long=
> as it can be encoded).
> =C2=A0(v) a server does not need to explicitly validate that its view = of
> operational is valid. It is unclear what it would/could do if it
> detected that the operational state is invalid, nor is it clear that > servers would generally be able to always perform this operation.
>
> >
> > The server implementation requirements expressed in YANG constrai= nts
> > are applicable to any data node, not just config=3Dtrue data node= s.
> > The requirement to implement the ancestor nodes (with keys) does = not
> > change.
>
> The draft does not allow this to be violated.=C2=A0 I.e. the following=
> statement prevents this: "Syntactic constraints MUST NOT be viola= ted,
> including hierarchical organization".
>
>
> > The requirement to conform to the YANG constraints defined within=
> > config=3Dfalse
> > data nodes does not change.
> >
> > To do otherwise does not make sense.=C2=A0 E.g. "when" = conditions that add
> > ethernet
> > counters only when the interface type is ethernetCsmacd. Why woul= d it
> > be OK for
> > the server to ignore that when-stmt and add ethernet counters to = every
> > interface?
>
> It is not OK for a server to ignore that and add Ethernet counters to<= br> > every interface (without using a deviation).=C2=A0 The draft is not tr= ying
> to allow that.
>
> But if an interface could change type (e.g. between Ethernet and ATM > via a different optics module being inserted) then it would be allowed=
> for a server to transiently report the ethernet counters on the
> interface whilst it is in the process of changing the interface type > from ethernet to ATM (e.g. if the counters are maintained by a
> separate daemon that is updated asynchronously with respect to the
> config or optics change).=C2=A0 Once the change had completed, the the=
> system reaches steady state then the Ethernet counter must no longer > be reported.
>
> Thanks,
> Rob
>
>
> >
> > IMO the text above can only apply to the operational values of > > config=3Dtrue nodes.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0Thanks,
> >=C2=A0 =C2=A0 =C2=A0Rob
> >
> >
> >
> > Andy
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0On 21/12/2017 22:49, Andy Bierman wrote:
> >>=C2=A0 =C2=A0 =C2=A0Hi,
> >>
> >>=C2=A0 =C2=A0 =C2=A0It should be clear somehow that server req= uirements to provide
> >>=C2=A0 =C2=A0 =C2=A0config=3Dfalse data
> >>=C2=A0 =C2=A0 =C2=A0that is valid according to the YANG defini= tions is not affected
> >>=C2=A0 =C2=A0 =C2=A0by NMDA.
> >>=C2=A0 =C2=A0 =C2=A0That is not being taken away.=C2=A0 The ab= ility to validate
> >>=C2=A0 =C2=A0 =C2=A0operational values
> >>=C2=A0 =C2=A0 =C2=A0of configuration data has never been provi= ded, and therefore is
> >>=C2=A0 =C2=A0 =C2=A0not being taken away either.
> >>
> >>=C2=A0 =C2=A0 =C2=A0A constraint on config=3Dtrue nodes only a= pplies to configuration
> >>=C2=A0 =C2=A0 =C2=A0datastores.
> >>=C2=A0 =C2=A0 =C2=A0These are the only constraints that should= be ignored in
> >>=C2=A0 =C2=A0 =C2=A0<operational>.
> >>=C2=A0 =C2=A0 =C2=A0Constraints on config=3Dfalse nodes still = apply in <operational>.
> >>
> >>
> >>=C2=A0 =C2=A0 =C2=A0Andy
> >>
> >>
> >>
> >>=C2=A0 =C2=A0 =C2=A0On Thu, Dec 21, 2017 at 2:27 PM, Juergen S= choenwaelder
> >>=C2=A0 =C2=A0 =C2=A0<j.schoenwaelder@jacobs-university.de
> >>=C2=A0 =C2=A0 =C2=A0<mailto:j.schoenwaelder@jacobs-university.de>&= gt; wrote:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Dec 21, 2017 at 07:5= 2:54PM +0100, Vladimir Vassilev
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 12/21/2017 02:20 PM,= Juergen Schoenwaelder wrote:
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > On Thu, Dec 21, 20= 17 at 02:03:45PM +0100, Vladimir
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vassilev wrote:
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > On 12/21/2017= 11:34 AM, Robert Wilton wrote:
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Hi Vladi= mir,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > First po= int of clarification is that this is not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about running/intended
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > at all.= =C2=A0 The contents of running/intended do not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change in anyway
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > dependin= g on whether hardware is present or absent.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > The sect= ion is only concerned with how the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration is applied in<= br> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > operatio= nal, and basically says that you cannot apply
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration for
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > resource= s that are missing (which seems reasonable).=C2=A0
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E.g. I cannot
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > configur= e an IP address on a physical interface that
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't there.=C2=A0 Or if=
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the phys= ical interface gets removed then the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration associated
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > with tha= t interface is also removed from operational.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Operatio= nal isn't validated and data model
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0constraints are allowed to b= e
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > broken (= ideally transiently).
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I want to foc= us on this. IMO giving up schema validitiy
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for any datastore is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > unacceptable = price. Pre-NMDA devices had full model
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support in operational
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > data (all YAN= G constrains part of the model without
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discrimination were
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > enforced). > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > There was a long d= ebate about the value of returning the true
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > operational state.= What do you do if the operational
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state is invalid?
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > A server can rejec= t configuration changes if they lead to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0invalid
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > state, a server ca= n not reject reality.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> IMO if the model can re= present reality then data conforming
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the model
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> can. If not a better mo= del is needed not a hack that breaks
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the datastore
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> conformance to the YANG= model. I do not see how
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> /interfaces/interface/o= per-status=3Dnot-present was not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0representing the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> reality of a system wit= h removed line card that is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured and ready to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> resume operation as soo= n as the line card is reconnected.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I assume this is all system = and implementation specific. If your
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0system knows about interface= s that are not present (i.e.,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operational state about them= ), you can report these
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interfaces.=C2=A0 But
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'is configured' is c= onfusing here. I am not sure a line card
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that does
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not exist should be consider= ed configured. But yes, this may
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be system
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specific. Anyway, draft-ietf= -netmod-rfc7223bis-01.txt still has
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oper-status 'not-present= ' - so this seems to be a mood point.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > If this is ab= out to change it will compromise
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interoperability
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > and a signifi= cant portion of the client implementation
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0workload that can be
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > automated wil= l need to be coded in hand and tested.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unresolved leafrefs,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > undefined beh= aviour of different implementations
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0removing different
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > configuration= nodes in violation of YANG semantic
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0constraints (which I do
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > not think can= be so clearly separated from the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syntactic constraints when > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > one considers= types like leafref, instance-identifier
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0etc.) and the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > corresponding= side effects based on the server
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementators own creativit= y
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > is eventually= going to create more problems.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > 1. IMO the on= ly acceptable solution is to have YANG
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0valid operational
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > datastore at = all times. operational like any other
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore MUST be valid
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > YANG data tre= e and it has to be a system implementation
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0task to consider all
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > complications= resulting from the removal of the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resources leading to any
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > data transfor= mations. If this is difficult or
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0impossible other mechanisms = to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > flag missing = resources should be used (e.g.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > /interfaces/i= nterface/oper-status=3Dnot-present) This
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sounds like a useful
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > contract prov= iding the value of a standard the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alternative does not.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > As said above, it = is impossible to report valid
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operational state if
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > the operational st= ate is not valid according to the models.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > 2. Even with = the change in 1. I do not see the removal
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of intended
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > configuration= nodes from operational as a solution
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0worth implementing on our > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > servers. I do= not see a real world plug-and-play
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenario that can be
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > automatically= solved without specific additions to the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0models e.g.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > /interfaces/i= nterface/oper-status=3Dnot-present is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oversimplified solution but<= br> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > it needs to b= e extended exactly as much as the solution
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provided by the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > removal of co= nfig true; nodes without the sacrifice of
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0YANG validity of
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > operational.<= br> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Your thinking is l= ikely wrong. <operational> reports the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operational
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > state. It may have= little in common with <intended>.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Trying to derive
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > operational from i= ntended is likely a not well working
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approach.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The proposal for this s= olution ("derive operational from
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended" e.g.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> merge /interfaces-state= in /interfaces) comes from the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0revised datastores
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> draft not me.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition config tr= ue; data represents intent. Reusing
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the model of a
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> config true; data to re= present state absent of intent (e.g.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> /interfaces/interface w= ith origin=3D"or:system") is a hack.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The hack works
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> fine without compromisi= ng the conformance of operational to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the YANG model
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> as long as certain cond= itions are met. I am pointing out
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that one of the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> conditions is to keep a= ll of the intended configuration
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data present in
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 'operational' a= nd handle missing resources with
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0conventional means e.g.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> /interfaces/interface/o= per-status=3Dnot-present instead of
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adding the straw
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> that breaks the camel&#= 39;s back.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I fail to see why you believ= e all objects that appear in intended
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration needs to exist= in applied configuration. In fact,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operators told us very clear= ly that they care about the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0distinction
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between intended and applied= config.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > 3. Solutions = like /interfaces/interface/admin-state
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stop working. With the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > interface rem= oved you can no longer figure if the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-mib has or does not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > have the inte= rface enabled so an operator has to use
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SNMP or wait for a
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > replacement l= ine card to be connected to figure this
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit of information.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > At least on my box= es, if I remove a line card, the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface also
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > disappears in SNMP= tables. Stuff that is operationally
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not present is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > simply operational= ly not present.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > My
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > interpretatio= n of the MAY as requirement level in sec.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05.3. The Operational
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > State Datasto= re (<operational>) is that plug-and-play
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solutions can be
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > implemented w= ithout this limited approach that has the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same problem as the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > pre-NMDA only= now we have to have /interfaces-state to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep config false;
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > data relevant= to hardware that is configured but not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present:
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0= =C2=A0 configuration data nodes supported in a
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration datastore
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0= =C2=A0 MAY be omitted from <operational> if a server is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not able to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0= =C2=A0 accurately report them.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I realize thi= s discussion comes late. I have stated my
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0objections to this
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > particular pa= rt of the NMDA draft earlier.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > I believe there is= a conceptual misunderstanding. I think
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there never
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > was a requirement = that a server reports the state of
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hardware that is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > not present.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "Data relevant to = hardware that is configured but not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present" is different > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> from "state of har= dware that is not present". For example
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> indicating when the lin= e card became unavailable, what was
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the reason, or
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> other information like = how many packets that had this
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface as egress
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> destination are being d= ropped as a result of the removal.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think that systems handle = non-existing interfaces
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0differently. It
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0seems that ietf-interfaces i= s flexible enough to accomodate the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0differnet styles.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/js
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Juergen Schoenwaelder=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Phone: +49 421 200 3587=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Germany
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fax:=C2=A0 =C2=A0+49 421 200= 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0<http://www.= jacobs-university.de/
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs= -university.de/>>
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________= ___________________
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod mailing list
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod@ietf.org <mailto:ne= tmod@ietf.org>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://w= ww.ietf.org/mailman/listinfo/netmod
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https= ://www.ietf.org/mailman/listinfo/netmod>
> >>
> >>
> >>
> >>
> >>=C2=A0 =C2=A0 =C2=A0_____________________________________= __________
> >>=C2=A0 =C2=A0 =C2=A0netmod mailing list
> >>=C2=A0 =C2=A0 =C2=A0netmod@= ietf.org <mailto:netmod@ietf.org<= /a>>
> >>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/ma= ilman/listinfo/netmod
> >>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.or= g/mailman/listinfo/netmod>
> >
> >
>

--f403045e9f64f9c15005625b4d05-- From nobody Tue Jan 9 12:08: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 A90BC120725; Tue, 9 Jan 2018 12:08:37 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VvIUGjv_brh3; Tue, 9 Jan 2018 12:08:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF5C3120721; Tue, 9 Jan 2018 12:08:26 -0800 (PST) Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 890401AE0144; Tue, 9 Jan 2018 21:08:24 +0100 (CET) Date: Tue, 09 Jan 2018 21:08:24 +0100 (CET) Message-Id: <20180109.210824.760424986407969599.mbj@tail-f.com> To: daedulus@btconnect.com Cc: ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 20:08:38 -0000 Hi Tom, "tom p." wrote: > Much of this I-D is about the idea that network management data objects > can often take two different values. The I-D always refers to this as > being two values but is that a limit that this architecture imposes; or > can it be more? The I-D talks about two instantiations in the Objectives section, when the original "config vs oper values" problem is explained, and how NMDA solves the problem. But the archtecture allows for any number of instantiations; it all depends on which datastores a particular server implements. For example, a config node might have one value in , a different in and yet a different value in . This is not new to this document. > The later diagrams show three datastores, , > and . Since " MAY also be updated > independently of ", can there be three values? And since the > architecture says that other conventional configuration datastores may > be defined in future, can there be any number more values? I think this > is a significant issue when set against the objectives, of exposing to > the user > what values there are in a server; the I-D is clear that there is one > schema, but I > am less certain about its insistence on two values. > > In a sense, there is a datastore, perhaps more than one, missing. The > focus has been on configuration-related datastores and is now widening > to put other object values into datastores. Yet the values learnt > from hardware, protocols and such like will only be in a datastore if > that value is used and so is in . If a user-configured > value is the one put into , then values learnt by other > means will not > appear AFAICT. For completeness, there should be a datastore for values > learnt from the hardware, from protocols and so on. (In fact, doing the > sort of > thing that routing protocols, which learn different routes to the same > destination via different means, have been doing for years:-) The architecture defined in this I-D defines a set of datastores, but it also allows for new datastores defined in the future. If a datastore with "unused" values is needed, such a datastore can be defined later. /martin > > Tom Petch > > ----- Original Message ----- > From: "The IESG" > Sent: Thursday, December 21, 2017 7:23 PM > > > The IESG has received a request from the Network Modeling WG (netmod) > to > > consider the following document: - 'Network Management Datastore > Architecture' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > > > Datastores are a fundamental concept binding the data models > written > > in the YANG data modeling language to network management protocols > > such as NETCONF and RESTCONF. This document defines an > architectural > > framework for datastores based on the experience gained with the > > initial simpler model, addressing requirements that were not well > > supported in the initial model. This document updates RFC 7950. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba > llot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > From nobody Tue Jan 9 16:41:26 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 38FB712422F for ; Tue, 9 Jan 2018 16:41:25 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=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 4DKUC7wffWUQ for ; Tue, 9 Jan 2018 16:41:22 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 2E281120454 for ; Tue, 9 Jan 2018 16:41:22 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id j129so2482083oib.12 for ; Tue, 09 Jan 2018 16:41:22 -0800 (PST) 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=NpD3nsjfCM2dEu9e7JLqK3UGUlLEtBlHOQXTNcbSwCw=; b=iLXfVYIjYtAq8H5wo/oAA52dGefbiv6ymQmtKD3n/YZF+fdG3AVw1i0+1wvdOtlIjB uhHmUfRucdy5OJSuo5YCwj+DfTkOgIm8Kf9ecOrLvx9To8pbbFLnU5zqYYYyD0iwo32A 7UUAR3hcIOL9g8kw2V6KszHAmZ9nr/IvzsFJmx6IZvSt2DwZdqJbmXN16hUAgsaedqoS S3lNccvaPX4lsx74Yx2WnBprmOYbhSg1qYTtgq1HAfgtlvqfhLsUzNAd5peFN/Fgxaci u+9h8mze5ewdFIqrcyv8PZIFqQ4iNuRQv2SPyY1GfsYtalEp/6rjX51U7dkWfN6JgvpR skiQ== 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=NpD3nsjfCM2dEu9e7JLqK3UGUlLEtBlHOQXTNcbSwCw=; b=MVWo2Uga4zq/7gCCwmTYcGYgWBL4yc1jhl07j8YlJdvc3zzG+FN5I54tiRXB5jLi0A E7q6BgQTc1YpVUxiKst6GACKzOFY5cOZoHGtsh8Wbepx34ABZxr9coGnYipXgHbDcxSn 3KaTOtm1ioqDYDINVasrSMUYf3pZgXka4Pv3WAG/LeqiRTeECYvOWvyOpF0CTYAu8sG4 XGE4lBLRap21Z3eQsPZVU5ESku5hrpLTfmElZLp9v9hLz5y2K4CwlPRslSsiMC6pSSrz xvQKE0tOzpiwZRDFwG5R06aqGCk21OHg8dqAbwPPNdNtqJ/xLXifkrslyogLP6I/+sKR 3j4A== X-Gm-Message-State: AKwxytfk8QYuXRbAFz0df0NBGaEC3K5IXX7XwBgtBNMf/31ScGpTJcun vEWlmmJjb/bwK+dTH7eCGlQ= X-Google-Smtp-Source: ACJfBotmBdFr+mCoQHYHBhk50XkyjZJiVYtnm/ET1iCY745x51IrB7yK+za76Ne8ZSYf2Ji7NpJ5Kw== X-Received: by 10.202.85.145 with SMTP id j139mr4359498oib.99.1515544881368; Tue, 09 Jan 2018 16:41:21 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:648a:d03c:6bd4:2fce]) by smtp.gmail.com with ESMTPSA id w21sm2050715otd.14.2018.01.09.16.41.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 16:41:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mahesh Jethanandani In-Reply-To: <20180108.164509.2179320293753239869.mbj@tail-f.com> Date: Tue, 9 Jan 2018 16:41:17 -0800 Cc: Robert Wilton , "Einar Nilsen-Nygaard (einarnn)" , supjps-ietf@jpshallow.com, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <68BA264A-9036-4C7C-BBCC-7C2B7B05BDD2@gmail.com> References: <012301d3886e$f96f08e0$ec4d1aa0$@jpshallow.com> <041cd24f-858c-5e94-6bea-6d25f62b4acc@cisco.com> <20180108.164509.2179320293753239869.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 00:41:25 -0000 Hi, > On Jan 8, 2018, at 7:45 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Robert Wilton wrote: >> Hi Einar, Jon, Mahesh, >>=20 >> My gut instinct is that making this a grouping might not be a good >> idea: >>=20 >> 1) If somebody updates the core ACL model, will then need to check >> that anyone using it should be similarly updated (unless they use >> import-by-revision). >>=20 >> 2) Does it make sense to define ACLs in separate places. Would like >> be more simple if ACLs were defined in a central place and then just >> referenced by other protocols as required. >>=20 >> 3) I think that groupings are probably overused and I think that they >> can detract from the readability of the model. (I regard the >> OpenConfig YANG models as an extreme example of this, where it is >> necessary to compile the modules together to figure out where >> everything fits together). >=20 > I agree with all three statements. The current acl data model has a > top-level grouping "interface-acl" which probably is not intended to > be "exported". I think ot should be moved into the > "attachment-points" container, in order to make it local. Have moved =E2=80=9Cinterface-acl=E2=80=9D under the = =E2=80=9Cattachment-point=E2=80=9D container and made it local. Thanks. >=20 > If the entire access-list container is defined as a goruping, and is > used in multiple places, how are the multiple interface > attachment-points handled? >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Having said that, I don't think that this issue is important enough = to >> have a long discussion about ... >>=20 >> Thanks, >> Rob >>=20 >>=20 >> On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote: >>> Since this is a 7-line change, I see no harm in it if no-one = objects? >>> Mahesh has the token for rolling in updates discussed just prior to >>> the end of 2017. >>>=20 >>> Here=E2=80=99s a possible diff: >>>=20 >>> $ git diff -b >>> diff --git a/src/yang/ietf-access-control-list.yang >>> b/src/yang/ietf-access-control-list.yang >>> index 4d698c9..b1a173f 100644 >>> --- a/src/yang/ietf-access-control-list.yang >>> +++ b/src/yang/ietf-access-control-list.yang >>> @@ -402,6 +402,10 @@ module ietf-access-control-list { >>> /* >>> * Configuration data nodes >>> */ >>> + grouping access-lists-top { >>> + description >>> + "Grouping to allow reuse of access lists container = elsewhere."; >>> + >>> container access-lists { >>> description >>> "This is a top level container for Access Control Lists. >>> @@ -576,6 +580,9 @@ module ietf-access-control-list { >>> } >>> } >>> } >>> + } >>> + uses access-lists-top; >>> + >>> augment "/if:interfaces/if:interface" { >>> description >>> "Augment interfaces to allow ACLs to be associated in either >>> the >>>=20 >>> Cheers, >>>=20 >>> Einar >>>=20 >>>=20 >>>> On 8 Jan 2018, at 10:53, Jon Shallow >>> > wrote: >>>>=20 >>>> Hi There, >>>> I appreciate that this is late to the table, but is it possible to = set >>>> up =E2=80=9Caccess-lists=E2=80=9D as a =E2=80=9Cgrouping=E2=80=9D = in the YANG data model so that >>>> =E2=80=9Caccess-lists=E2=80=9D can be included by =E2=80=9Cuses=E2=80= =9D in a higher level YANG data >>>> model? >>>> I have raised this as issue #22 >>>> athttps://github.com/netmod-wg/acl-model/issues >>>> Regards >>>> Jon >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Jan 9 19:08: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 4C154126D05 for ; Tue, 9 Jan 2018 19:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 SORjDREa--5P for ; Tue, 9 Jan 2018 19:08:10 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 62A191242F7 for ; Tue, 9 Jan 2018 19:08:10 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id a70so5605040oib.1 for ; Tue, 09 Jan 2018 19:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=TMHX0k0pdhOnHI8XyDLwgldnY34z9BCR5ADf/h7z9hw=; b=h42kfxAbJRUDlIThWLn2qNJTlq/C3ho7mDZSCkGvNKC3yB+zdWQ1Nou25uhVu9BJFS IUucxuP9mdX8uD2HCwCFzEHerFVaBG98MHtn8eDiewT9tf33i0VRWQjb+P2okQrysPPs Ic5INn8/Ewcf9o+kX64n/Atf+7ueMpuE5vMtwJk3yQgp/NwQi5ZQkcUgjqOUVq3CMy/+ +8T/+3z1i2BIrzN5DZ4/TIpffNHhYGddswcKRscvudGM7HOocSmqnClclJ70k2tZEx5a t9XGhLPjKqkqkicbqKVj4RenRjdWkLP3qFJcaRRvmvPIlLW/12YJvhf66SKaIy/rhnxp e99w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=TMHX0k0pdhOnHI8XyDLwgldnY34z9BCR5ADf/h7z9hw=; b=fFTx+lvLNOt/gU7DO7WlTknnMvOGqsVbyiIaaYyCZd3skchXi+gzFwgcg5Pg1FsTPr 5BTvNKFn/HMP/IaJESRsVTFncFpm3PHH7pce0cRrrLtUNp6GITyGVWAKLtjcESHkPWpN 4pNPk/DlaANaWng3P7S6QYqlb4JFcKOQHLgzqCPkf7N/4t6sWvdaF42a3BgY0NzeD/5k 3LnpBqfoVzzcGe6TvVcvp8d/ceEWdijDL4+KEAe77CSnLu5oN/ldyGqTyRU2MvGNbkxO 05O80faxdG+aEvUzo8ggibRNns+NfZIJAKEvK00JpCS3jOQZtVVOtRsKfinRGW9vue9c lQGA== X-Gm-Message-State: AKGB3mKqWqV3pSfgHwSpOf/KvwSGuAa9A2mXLAGRhKsThnoxKbfjkONa ctfhB5ZdN71vJxZv2UnFfSRC7x90 X-Google-Smtp-Source: ACJfBovO1yPolh1I8dnTT/RWWYdFYFwMzObkDt0CrHbf85ARqxPlYDJsOZ4vzpzocED7mfffp+O4Mw== X-Received: by 10.202.117.85 with SMTP id q82mr9622311oic.34.1515553689185; Tue, 09 Jan 2018 19:08:09 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:648a:d03c:6bd4:2fce]) by smtp.gmail.com with ESMTPSA id i67sm7019708oih.36.2018.01.09.19.08.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 19:08:07 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE20AB9-89E7-4B8C-A14D-F8AA8F05783C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 9 Jan 2018 19:08:05 -0800 References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> To: "netmod@ietf.org" In-Reply-To: <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> Message-Id: <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 03:08:13 -0000 --Apple-Mail=_6AE20AB9-89E7-4B8C-A14D-F8AA8F05783C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have pulled in the changes as they relate to: - moving =E2=80=9Cinterface-acl=E2=80=9D under the container = =E2=80=9Cattachment-points=E2=80=9D making it local to that container. - reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ctype=E2=80=9D - removed =E2=80=9Cinterface-all-aggregate=E2=80=9D feature - simplified source port and destination port definition The pull request for the changes can be found here. https://github.com/netmod-wg/acl-model/pull/20 = After discussing with some of the original contributors, decided not to = include the change as it relates to augmenting ietf-interfaces. We did = not find that the change had a particular advantage over the current = implementation. Even if we do not completely understand how ACLs might = be attached =E2=80=9Cglobally=E2=80=9D or on something that is not an = interface, having the flexibility to attach them to other attachment = points is important. Keeping it as interface-ref gives us that = flexibility. Cheers. > On Dec 18, 2017, at 4:31 AM, Eliot Lear wrote: >=20 > So long as nobody expects an interface construct in a MUD file, I'm = happy. >=20 > On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: >> Eliot, >>=20 >> Nothing can force an implementation to have to implement either the = ietf-interfaces model or the augmentation in the = ietf-access-control-list model. I appreciate your desire for modularity = and cohesiveness, but I would resist #1, because I feel that the = majority of users will be targeting interface-based attachment over = time. I=E2=80=99ve adde back in use of the =E2=80=9Cinterface-attachment=E2= =80=9D feature (which I took out as part of refactoring interface = attachment). Part of: >>=20 >> https://github.com/netmod-wg/acl-model/pull/21 = >>=20 >> The augments part of the tree now looks like: >>=20 >> augment /if:interfaces/if:interface: >> +--rw acls {interface-attachment}? >> +--rw ingress >> | +--rw acl-sets >> | +--rw acl-set* [name] >> | +--rw name -> /access-lists/acl/name >> | +--rw type? -> /access-lists/acl/type >> | +--ro ace-statistics* [name] {interface-stats}? >> | +--ro name -> = /access-lists/acl/aces/ace/name >> | +--ro matched-packets? yang:counter64 >> | +--ro matched-octets? yang:counter64 >> +--rw egress >> +--rw acl-sets >> +--rw acl-set* [name] >> +--rw name -> /access-lists/acl/name >> +--rw type? -> /access-lists/acl/type >> +--ro ace-statistics* [name] {interface-stats}? >> +--ro name -> = /access-lists/acl/aces/ace/name >> +--ro matched-packets? yang:counter64 >> +--ro matched-octets? yang:counter64 >>=20 >> Cheers, >>=20 >> Einar >>=20 >>=20 >>> On 17 Dec 2017, at 11:29, Eliot Lear > wrote: >>>=20 >>> Einar, >>>=20 >>> I think this change is fine, with one exception. I would rather the = augment to the interface not be required for implementations that don't = actually have interfaces. I understand that there may be two ways to go = about this: >>>=20 >>> Separate out the augment into a separate module (same doc is fine); = or >>> Somehow "feature-ize" the augment. >>> I don't know how to do (2) but if you do, that's okay by me. >>>=20 >>> Eliot >>>=20 >>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote: >>>> All, >>>>=20 >>>> After a series of discussions on- and off-list, I have a candidate = PR that includes the changes in the PR Mahesh sent out plus some more = edits. Please see consolidated PR here: >>>>=20 >>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>=20 >>>> Main changes in addition to Mahesh=E2=80=99s PR are: >>>>=20 >>>> Moved interface attachment to be via an interface augmentation. >>>> Restructured port matches slightly under both IPv4 and IPv6 = containers. >>>> Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. >>>> Removed action =E2=80=98icmp-off=E2=80=99, can be augmented later. >>>>=20 >>>> For reference, here is the current YANG tree plus =E2=80=9C--ietf=E2=80= =9D logs: >>>>=20 >>>> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang >>>> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" = (should be date) >>>> module: ietf-access-control-list >>>> +--rw access-lists >>>> +--rw acl* [name] >>>> +--rw name string >>>> +--rw type? acl-type >>>> +--rw aces >>>> +--rw ace* [name] >>>> +--rw name string >>>> +--rw matches >>>> | +--rw (l2)? >>>> | | +--:(eth) >>>> | | +--rw eth {match-on-eth}? >>>> | | +--rw destination-mac-address? = yang:mac-address >>>> | | +--rw destination-mac-address-mask? = yang:mac-address >>>> | | +--rw source-mac-address? = yang:mac-address >>>> | | +--rw source-mac-address-mask? = yang:mac-address >>>> | | +--rw ethertype? = eth:ethertype >>>> | +--rw (l3)? >>>> | | +--:(ipv4) >>>> | | | +--rw ipv4 {match-on-ipv4}? >>>> | | | +--rw dscp? = inet:dscp >>>> | | | +--rw ecn? uint8 >>>> | | | +--rw length? = uint16 >>>> | | | +--rw ttl? uint8 >>>> | | | +--rw protocol? uint8 >>>> | | | +--rw (source-port-range-or-operator)? >>>> | | | | +--:(range) >>>> | | | | | +--rw source-port-lower = inet:port-number >>>> | | | | | +--rw source-port-upper = inet:port-number >>>> | | | | +--:(operator) >>>> | | | | +--rw source-operator = operator >>>> | | | | +--rw source-port = inet:port-number >>>> | | | +--rw = (destination-port-range-or-operator)? >>>> | | | | +--:(range) >>>> | | | | | +--rw destination-port-lower = inet:port-number >>>> | | | | | +--rw destination-port-upper = inet:port-number >>>> | | | | +--:(operator) >>>> | | | | +--rw destination-operator = operator >>>> | | | | +--rw destination-port = inet:port-number >>>> | | | +--rw ihl? uint8 >>>> | | | +--rw flags? bits >>>> | | | +--rw offset? = uint16 >>>> | | | +--rw identification? = uint16 >>>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>>> | | +--:(ipv6) >>>> | | +--rw ipv6 {match-on-ipv6}? >>>> | | +--rw dscp? = inet:dscp >>>> | | +--rw ecn? uint8 >>>> | | +--rw length? = uint16 >>>> | | +--rw ttl? uint8 >>>> | | +--rw protocol? uint8 >>>> | | +--rw (source-port-range-or-operator)? >>>> | | | +--:(range) >>>> | | | | +--rw source-port-lower = inet:port-number >>>> | | | | +--rw source-port-upper = inet:port-number >>>> | | | +--:(operator) >>>> | | | +--rw source-operator = operator >>>> | | | +--rw source-port = inet:port-number >>>> | | +--rw = (destination-port-range-or-operator)? >>>> | | | +--:(range) >>>> | | | | +--rw destination-port-lower = inet:port-number >>>> | | | | +--rw destination-port-upper = inet:port-number >>>> | | | +--:(operator) >>>> | | | +--rw destination-operator = operator >>>> | | | +--rw destination-port = inet:port-number >>>> | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>>> | | +--rw source-ipv6-network? = inet:ipv6-prefix >>>> | | +--rw flow-label? = inet:ipv6-flow-label >>>> | +--rw (l4)? >>>> | | +--:(tcp) >>>> | | | +--rw tcp {match-on-tcp}? >>>> | | | +--rw sequence-number? uint32 >>>> | | | +--rw acknowledgement-number? uint32 >>>> | | | +--rw data-offset? uint8 >>>> | | | +--rw reserved? uint8 >>>> | | | +--rw flags? bits >>>> | | | +--rw window-size? uint16 >>>> | | | +--rw urgent-pointer? uint16 >>>> | | | +--rw options? uint32 >>>> | | +--:(udp) >>>> | | | +--rw udp {match-on-udp}? >>>> | | | +--rw length? uint16 >>>> | | +--:(icmp) >>>> | | +--rw icmp {match-on-icmp}? >>>> | | +--rw type? uint8 >>>> | | +--rw code? uint8 >>>> | | +--rw rest-of-header? uint32 >>>> | +--rw egress-interface? if:interface-ref >>>> | +--rw ingress-interface? if:interface-ref >>>> +--rw actions >>>> | +--rw forwarding identityref >>>> | +--rw logging? identityref >>>> +--ro statistics {acl-aggregate-stats}? >>>> +--ro matched-packets? yang:counter64 >>>> +--ro matched-octets? yang:counter64 >>>>=20 >>>> augment /if:interfaces/if:interface: >>>> +--rw acls >>>> +--rw ingress >>>> | +--rw acl-sets >>>> | +--rw acl-set* [name] >>>> | +--rw name -> /access-lists/acl/name >>>> | +--rw type? -> /access-lists/acl/type >>>> | +--ro ace-statistics* [name] {interface-stats}? >>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>> | +--ro matched-packets? yang:counter64 >>>> | +--ro matched-octets? yang:counter64 >>>> +--rw egress >>>> +--rw acl-sets >>>> +--rw acl-set* [name] >>>> +--rw name -> /access-lists/acl/name >>>> +--rw type? -> /access-lists/acl/type >>>> +--ro ace-statistics* [name] {interface-stats}? >>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>> +--ro matched-packets? yang:counter64 >>>> +--ro matched-octets? yang:counter64 >>>>=20 >>>> Comments welcome! >>>>=20 >>>> Cheers, >>>>=20 >>>> Einar >>>>=20 >>>>=20 >>>>=20 >>>>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal > wrote: >>>>>>=20 >>>>>> Hi Einar, >>>>>>=20 >>>>>> You had 3 questions for me on all the several e-mail threads.=20 >>>>>> 1. Global attachment point >>>>>> 2. icmp-off >>>>>> 3. acl-aggregate-interface stats. >>>>>>=20 >>>>>> For (1), my first preference is to have the model define = attachment point for interfaces only. >>>>>=20 >>>>> einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s PR = to netmod-wg/acl-model that do this. Nearly like the augmentation I have = below. Feel free to take a look at: >>>>>=20 >>>>> https://github.com/mjethanandani/acl-model/pull/3 = >>>>>=20 >>>>>> However, Kristian wants the global attachment point as well so = that he can add the ACL to the linux tables. >>>>>=20 >>>>> einarnn> I think Kristian doesn=E2=80=99t feel a global attachment = point needs to be in this first revision. But he can confirm. >>>>>=20 >>>>>> If an ACL is attached globally, does this mean it is per = direction or does it mean it is across directions? >>>>>=20 >>>>> einarnn> I don=E2=80=99t know right now :-) >>>>>=20 >>>>>> This global ACL may not be applicable to any of Cisco's service = provider routers as I don't see any platform actually replicating the = ACL to all line cards and attaching it in ingress and egress directions = across all interfaces. >>>>>=20 >>>>> einarnn> Per other emails, I don=E2=80=99t think we understand = this enough yet to specify it, so I suggest we just leave it out for = now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80= =9D being added later once we understand what it really means. >>>>>=20 >>>>>> For (2), I am ok with removing icmp-off. >>>>>=20 >>>>> einarnn> Done in my PR above. >>>>>=20 >>>>>> For (3), this would have to be a combination of ACL stats across = all interfaces for all ACL's. Something like this is possible on an XR = box where ACES have counter names associated with it. Let's chat about = this offline tomorrow. >>>>>=20 >>>>> einarnn> I=E2=80=99ll ping you to clarify, and we can bring any = conclusion back to the list. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Einar >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Sonal. >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani = > wrote: >>>>>> We want to support =E2=80=9Cglobal=E2=80=9D attachment point down = the line, and that =E2=80=9Cglobal=E2=80=9D attachment point will be one = of the choices (the other being the interface), what would this augment = look like. Note, as far as I know, you cannot augment inside a choice = node. >>>>>>=20 >>>>>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>=20 >>>>>>> Perhaps like this, as an augmentation to the interface: >>>>>>>=20 >>>>>>> augment /if:interfaces/if:interface: >>>>>>> +--rw ingress-acls >>>>>>> | +--rw acl-sets >>>>>>> | +--rw acl-set* [name] >>>>>>> | +--rw name -> /access-lists/acl/name >>>>>>> | +--rw type? -> /access-lists/acl/type >>>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>> | +--ro matched-packets? yang:counter64 >>>>>>> | +--ro matched-octets? yang:counter64 >>>>>>> +--rw egress-acls >>>>>>> +--rw acl-sets >>>>>>> +--rw acl-set* [name] >>>>>>> +--rw name -> /access-lists/acl/name >>>>>>> +--rw type? -> /access-lists/acl/type >>>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>> +--ro matched-packets? yang:counter64 >>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>=20 >>>>>>> Could also put an =E2=80=9Caces=E2=80=9D container above both = these & rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. = to give a single root for the augmentation if preferred. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Einar >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 6 Dec 2017, at 19:43, Eliot Lear > wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote: >>>>>>>>> How does one move the interface attachment point, currently an >>>>>>>>> 'interface-ref', to an augmentation of the = if:interfaces/interface, >>>>>>>>> inside of the =E2=80=98acl=E2=80=99 container? Down the line = we might need to have an >>>>>>>>> container for "attachment points" to accommodate the = possibility of >>>>>>>>> attaching an ACL either to an interface or =E2=80=9Cglobally=E2=80= =9D. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Keeping in mind that one use is that an ACL doesn't attach to = an >>>>>>>> interface at all. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>=20 >>>>>>=20 >>>>>> Mahesh Jethanandani >>>>>> mjethanandani@gmail.com >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod = >>>=20 >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6AE20AB9-89E7-4B8C-A14D-F8AA8F05783C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have pulled in the changes as they relate to:

- moving =E2=80=9Cinterface-acl=E2=80=9D = under the container =E2=80=9Cattachment-points=E2=80=9D making it local = to that container.
- reverting =E2=80=9Cacl-type=E2=80= =9D to =E2=80=9Ctype=E2=80=9D
- removed = =E2=80=9Cinterface-all-aggregate=E2=80=9D feature
- = simplified source port and destination port definition

The pull request for the = changes can be found here.

https://github.com/netmod-wg/acl-model/pull/20

After discussing with = some of the original contributors, decided not to include the change as = it relates to augmenting ietf-interfaces. We did not find that the = change had a particular advantage over the current implementation. Even = if we do not completely understand how ACLs might be attached = =E2=80=9Cglobally=E2=80=9D or on something that is not an interface, = having the flexibility to attach them to other attachment points is = important. Keeping it as interface-ref gives us that = flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, = Eliot Lear <lear@cisco.com> wrote:

=20 =20

So = long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar = Nilsen-Nygaard (einarnn) wrote:
Eliot,

Nothing can force an implementation to have to implement either the ietf-interfaces model or the = augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment over time. I=E2=80=99ve adde back in = use of the =E2=80=9Cinterface-attachment=E2=80=9D feature (which I took = out as part of refactoring interface attachment). Part of:

https://github.com/netmod-wg/acl-model/pull/21

The augments part of the tree now looks = like:

  augment /if:interfaces/if:interface:
    = +--rw acls {interface-attachment}?
    =    +--rw ingress
    =    |  +--rw acl-sets
    =    |     +--rw acl-set* [name]
    =    |        +--rw name             =  -> /access-lists/acl/name
    =    |        +--rw type?             = -> /access-lists/acl/type
    =    |        +--ro ace-statistics* [name] = {interface-stats}?
    =    |           +--ro name               = -> /access-lists/acl/aces/ace/name
    =    |           +--ro matched-packets?   yang:counter64
    =    |           +--ro matched-octets?   =  yang:counter64
    =    +--rw egress
    =       +--rw acl-sets
    =          +--rw acl-set* [name]
    =             +--rw name             =  -> /access-lists/acl/name
    =             +--rw type?             -> = /access-lists/acl/type
    =             +--ro ace-statistics* [name] {interface-stats}?
    =                +--ro name             =   -> /access-lists/acl/aces/ace/name
    =                +--ro matched-packets?   = yang:counter64
    =                +--ro matched-octets?   =  yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:

Einar,

I think this change is fine, with one exception.  I would rather the augment to the interface not be required for implementations that don't actually have interfaces.  I understand = that there may be two ways to go about this:

  1. Separate out the augment into a = separate module (same doc is fine); or
  2. Somehow "feature-ize" the augment. =

I don't know how to do (2) but if you = do, that's okay by me.

Eliot
=


On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
All,

After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR here:

https://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to = Mahesh=E2=80=99s PR are:

  • Moved interface attachment to be via an interface augmentation.
  • Restructured port matches = slightly under both IPv4 and IPv6 containers.
  • Removed unnecessary identity 'interface-acl-aggregate=E2=80=99.
  • Removed action =E2=80=98icmp-off=E2= =80=99, can be augmented later.

For reference, here is the current YANG tree plus =E2=80=9C--ietf=E2=80=9D = logs:

13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" (should be = date)
module: ietf-access-control-list
    +--rw access-lists
       +--rw acl* [name]
          +--rw name   =  string
          +--rw type?   = acl-type
          +--rw aces
             +--rw ace* = [name]
                +--rw name =          string
                +--rw = matches
                | =  +--rw (l2)?
                |  | =  +--:(eth)
                |  | =     +--rw eth {match-on-eth}?
                |  | =        +--rw destination-mac-address?        yang:mac-address
                |  | =        +--rw destination-mac-address-mask?   yang:mac-address
                |  | =        +--rw source-mac-address?       =       yang:mac-address
                |  | =        +--rw source-mac-address-mask?        yang:mac-address
                |  | =        +--rw ethertype?                     =  eth:ethertype
                | =  +--rw (l3)?
                |  | =  +--:(ipv4)
                |  | =  |  +--rw ipv4 {match-on-ipv4}?
                |  | =  |     +--rw dscp?           =             = inet:dscp
                |  | =  |     +--rw ecn?           =             =  uint8
                |  | =  |     +--rw length?                     = uint16
                |  | =  |     +--rw ttl?           =             =  uint8
                |  | =  |     +--rw protocol?                   = uint8
                |  | =  |     +--rw (source-port-range-or-operator)?
                |  | =  |     |  +--:(range)
                |  | =  |     |  |  +--rw source-port-lower         =   inet:port-number
                |  | =  |     |  |  +--rw source-port-upper         =   inet:port-number
                |  | =  |     |  +--:(operator)
                |  | =  |     |     +--rw source-operator         =     operator
                |  | =  |     |     +--rw source-port             =     inet:port-number
                |  | =  |     +--rw = (destination-port-range-or-operator)?
                |  | =  |     |  +--:(range)
                |  | =  |     |  |  +--rw destination-port-lower     =  inet:port-number
                |  | =  |     |  |  +--rw destination-port-upper     =  inet:port-number
                |  | =  |     |  +--:(operator)
                |  | =  |     |     +--rw destination-operator       =  operator
                |  | =  |     |     +--rw destination-port         =    inet:port-number
                |  | =  |     +--rw ihl?           =             =  uint8
                |  | =  |     +--rw flags?           =           =  bits
                |  | =  |     +--rw offset?                     = uint16
                |  | =  |     +--rw identification?             = uint16
                |  | =  |     +--rw destination-ipv4-network?   = inet:ipv4-prefix
                |  | =  |     +--rw source-ipv4-network?       =  inet:ipv4-prefix
                |  | =  +--:(ipv6)
                |  | =     +--rw ipv6 {match-on-ipv6}?
                |  | =        +--rw dscp?         =               = inet:dscp
                |  | =        +--rw ecn?           =             =  uint8
                |  | =        +--rw length?         =             = uint16
                |  | =        +--rw ttl?           =             =  uint8
                |  | =        +--rw protocol?                   = uint8
                |  | =        +--rw (source-port-range-or-operator)?
                |  | =        |  +--:(range)
                |  | =        |  |  +--rw source-port-lower         =   inet:port-number
                |  | =        |  |  +--rw source-port-upper         =   inet:port-number
                |  | =        |  +--:(operator)
                |  | =        |     +--rw source-operator         =     operator
                |  | =        |     +--rw source-port             =     inet:port-number
                |  | =        +--rw = (destination-port-range-or-operator)?
                |  | =        |  +--:(range)
                |  | =        |  |  +--rw destination-port-lower     =  inet:port-number
                |  | =        |  |  +--rw destination-port-upper     =  inet:port-number
                |  | =        |  +--:(operator)
                |  | =        |     +--rw destination-operator       =  operator
                |  | =        |     +--rw destination-port         =    inet:port-number
                |  | =        +--rw destination-ipv6-network?   = inet:ipv6-prefix
                |  | =        +--rw source-ipv6-network?       =  inet:ipv6-prefix
                |  | =        +--rw flow-label?                 = inet:ipv6-flow-label
                | =  +--rw (l4)?
                |  | =  +--:(tcp)
                |  | =  |  +--rw tcp {match-on-tcp}?
                |  | =  |     +--rw sequence-number?          uint32
                |  | =  |     +--rw acknowledgement-number?   = uint32
                |  | =  |     +--rw data-offset?              uint8
                |  | =  |     +--rw reserved?                 uint8
                |  | =  |     +--rw flags?           =          bits
                |  | =  |     +--rw window-size?              uint16
                |  | =  |     +--rw urgent-pointer?           = uint16
                |  | =  |     +--rw options?                  uint32
                |  | =  +--:(udp)
                |  | =  |  +--rw udp {match-on-udp}?
                |  | =  |     +--rw length?   uint16
                |  | =  +--:(icmp)
                |  | =     +--rw icmp {match-on-icmp}?
                |  | =        +--rw type?         =     uint8
                |  | =        +--rw code?         =     uint8
                |  | =        +--rw rest-of-header?   uint32
                | =  +--rw egress-interface?    if:interface-ref
                | =  +--rw ingress-interface?   if:interface-ref
                +--rw = actions
                | =  +--rw forwarding    identityref
                | =  +--rw logging?      identityref
                +--ro = statistics {acl-aggregate-stats}?
                  =  +--ro matched-packets?   yang:counter64
                  =  +--ro matched-octets?    yang:counter64

  augment = /if:interfaces/if:interface:
    +--rw acls
       +--rw ingress
       |  +--rw acl-sets
       |     +--rw acl-set* = [name]
       |        +--rw name =              -> /access-lists/acl/name
       |        +--rw type? =             -> /access-lists/acl/type
       |        +--ro = ace-statistics* [name] {interface-stats}?
       |           = +--ro name               -> /access-lists/acl/aces/ace/name
       |           = +--ro matched-packets?   yang:counter64
       |           = +--ro matched-octets?    yang:counter64
       +--rw egress
          +--rw acl-sets
             +--rw acl-set* = [name]
                +--rw name =              -> /access-lists/acl/name
                +--rw type? =             -> /access-lists/acl/type
                +--ro = ace-statistics* [name] {interface-stats}?
                  =  +--ro name               -> /access-lists/acl/aces/ace/name
                  =  +--ro matched-packets?   yang:counter64
                  =  +--ro matched-octets?    yang:counter64

Comments welcome!

Cheers,

Einar



On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:



On 14 Dec 2017, at = 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Einar,

You had 3 questions for me on all the several e-mail threads. 
1. Global attachment point
2. icmp-off
3. acl-aggregate-interface = stats.

For (1), my first preference is to have the model define attachment point for interfaces only.

einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to netmod-wg/acl-model that do this. Nearly like the augmentation I have below. Feel free to take a look at:

https://github.com/mjethanandani/acl-model/pull/3=

However, Kristian wants the global attachment point as well so that he can add the ACL to the linux tables.

einarnn> I think = Kristian doesn=E2=80=99t feel a global attachment = point needs to be in this first revision. But he can confirm.

If an ACL is = attached globally, does this mean it is per direction or does it mean it is across directions?

einarnn> I don=E2=80=99t = know right now :-)

This global ACL may not be applicable to any of Cisco's service provider routers as I don't see any platform actually replicating the ACL to all line cards and attaching it in ingress and egress directions across all interfaces.

einarnn> Per other emails, I don=E2=80=99t think we = understand this enough yet to specify it, so I suggest we just leave it out for now. Nothing in the model prevents a =E2=80=9Cglobal = attachment point=E2=80=9D being added later once we understand what it really means.

For (2), I am ok = with removing icmp-off.

einarnn> Done in my PR above.

For (3), this would have to be a combination of ACL stats across all interfaces for all ACL's. Something like this is possible on an XR box where ACES have counter names associated with it. Let's chat about this offline tomorrow.

einarnn> I=E2=80=99ll = ping you to clarify, and we can bring any conclusion back to the list.

Cheers,

Einar



Sonal.


On Wed, = Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal=E2=80=9D = attachment point down the line, and that = =E2=80=9Cglobal=E2=80=9D attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.

On = Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:

Perhaps like this, as an augmentation to the interface:

=
  augment = /if:interfaces/if:interface:
=
    +--rw = ingress-acls
=
    | =  +--rw = acl-sets
=
    | =     +--rw acl-set* = [name]
=
    | =        +--rw = name       =        -> = /access-lists/acl/name
=
    | =        +--rw = type?       =       -> = /access-lists/acl/type
=
    | =        +--ro = ace-statistics* [name] = {interface-stats}?
=
    | =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
    | =           +--ro = matched-packets?   = yang:counter64
=
    | =           +--ro = matched-octets?   =  yang:counter64
=
    +--rw = egress-acls
=
      =  +--rw = acl-sets
=
      =     +--rw acl-set* = [name]
=
      =        +--rw = name       =        -> = /access-lists/acl/name
=
      =        +--rw = type?       =       -> = /access-lists/acl/type
=
      =        +--ro = ace-statistics* [name] = {interface-stats}?
=
      =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
      =           +--ro = matched-packets?   = yang:counter64
=
      =           +--ro = matched-octets?   =  yang:counter64

Could also put an =E2=80=9Caces=E2= =80=9D container above both these & rename = =E2=80=9Cingress-acls" to = =E2=80=9Cingress=E2=80=9D, etc. to give a single root for the augmentation if = preferred.

Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com> wrote:

=


On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently = an
'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2=80= =99 =  container? Down the line we might need to have an
container for "attachment points" to accommodate the possibility = of
attaching an ACL either to an interface or = =E2=80=9Cglobally=E2=80=9D.


Keeping in mind that one use is that an ACL doesn't attach to = an
interface at all.

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


Mahesh Jethanandani
mjethanandani@gmail.com


= _______________________________________________
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<= br class=3D""> 



_______________________________________________
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

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_6AE20AB9-89E7-4B8C-A14D-F8AA8F05783C-- From nobody Tue Jan 9 19:10: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 359AC1242F7; Tue, 9 Jan 2018 19:10:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151555382321.21465.10788231800400955949.idtracker@ietfa.amsl.com> Date: Tue, 09 Jan 2018 19:10:23 -0800 Archived-At: Subject: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 03:10:23 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Please add a sentence to the Introduction explaining how this document updates rfc7950. I know that a couple of sections explicitly indicate what part of rfc7950 they update, but having a short summary at the beginning would be nice. (2) Section 3 says: “It is expected that the revised definitions provided in this section will replace the definitions in [RFC6241] and [RFC7950] when these documents are revised.” Why not formally Update those documents here? [See my note above about the Update to rfc7950.] (3) s/Section 4.4 of this document/Section 4.4 of rfc6244 From nobody Tue Jan 9 23:35: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 8F734124319 for ; Tue, 9 Jan 2018 23:35:56 -0800 (PST) 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_RP_MATCHES_RCVD=-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 0K4Um0Np2X0T for ; Tue, 9 Jan 2018 23:35:52 -0800 (PST) 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 3D67F12025C for ; Tue, 9 Jan 2018 23:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139283; q=dns/txt; s=iport; t=1515569751; x=1516779351; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5oPcs3JjdXobwTh9icbvA60ufqEhiB1EPg6Ivjh1UHk=; b=NxDsA1oA9J/UB2elhsgJRNJGTRUQlvNgDov2xLPh601vdabe3DhQOvXv jnu9hbMJsgmBgvZa5nMRFhguF73rAON6/OiknBNtpQhy7OPcMWzb6Jold MgJk0cjmXFgOPGz8euIvTzn1RS7v80ZEeow0OrJbZQwn+LfvOqHbq3vnI g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAQAGwVVa/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEYEWdCeEB4sYj0UniQuOJBSBfwMHAxgBCoRJTwIahGIWAQE?= =?us-ascii?q?BAQEBAQEBayiFJAEBAQMBARgBCARHGwkCDgogAQYDAgICHwYfEQYBDAYCAQGKF?= =?us-ascii?q?wMVEJE1nW6BbTomhxgNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWEIIVUASk?= =?us-ascii?q?MgnmCa0QBgUQSLx+CYYJlBZInh0qJMz2EVoIvgQWIOIUBgheGGINvh2qNNkCJJ?= =?us-ascii?q?YE8JQEygVAyGggbFT2CKoIbORyBaEA3i2ABAQE?= X-IronPort-AV: E=Sophos;i="5.46,339,1511827200"; d="asc'?scan'208,217";a="1370125" 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; 10 Jan 2018 07:35:48 +0000 Received: from [10.61.225.122] ([10.61.225.122]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0A7ZlHt007125; Wed, 10 Jan 2018 07:35:48 GMT To: Mahesh Jethanandani , "netmod@ietf.org" References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> From: Eliot Lear Message-ID: Date: Wed, 10 Jan 2018 08:35:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6Pr28Ab55iRndvQuU15frpObkLGriIb57" Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 07:35:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6Pr28Ab55iRndvQuU15frpObkLGriIb57 Content-Type: multipart/mixed; boundary="xdKR59NewOib3acUeBvD5xKRQfAMBevku"; protected-headers="v1" From: Eliot Lear To: Mahesh Jethanandani , "netmod@ietf.org" Message-ID: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> In-Reply-To: <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> --xdKR59NewOib3acUeBvD5xKRQfAMBevku Content-Type: multipart/alternative; boundary="------------BBBB20A3D0CC9698AB192736" Content-Language: en-US This is a multi-part message in MIME format. --------------BBBB20A3D0CC9698AB192736 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgTWFoZXNoLAoKVGhhbmtzIGZvciB0aGlzIHdvcmsuwqAgSSB0aGluayB0aGlzIGlzIG9r YXkuwqAgSW4gdGhlIGNhc2Ugb2YgTVVEIHdlCnNpbXBseSB3b24ndCBoYXZlIHRoZSBvdGhl ciBjb250YWluZXIuwqAgQ2FuIEkgcGxlYXNlIGFzayB0aGF0IHlvdSBnZXQKdGhlIGRyYWZ0 IG91dCBxdWlja2x5IGFzIGRyYWZ0LWlldGYtb3BzYXdnLW11ZCBoYXMgYmVlbiB3YWl0aW5n IHF1aXRlCnNvbWUgdGltZSBmb3IgdGhpcyB3b3JrIHRvIGNvbXBsZXRlLgoKRWxpb3QKCgpP biAxMC4wMS4xOCAwNDowOCwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPiBJIGhhdmUg cHVsbGVkIGluIHRoZSBjaGFuZ2VzIGFzIHRoZXkgcmVsYXRlIHRvOgo+Cj4gLSBtb3Zpbmcg 4oCcaW50ZXJmYWNlLWFjbOKAnSB1bmRlciB0aGUgY29udGFpbmVyIOKAnGF0dGFjaG1lbnQt cG9pbnRz4oCdCj4gbWFraW5nIGl0IGxvY2FsIHRvIHRoYXQgY29udGFpbmVyLgo+IC0gcmV2 ZXJ0aW5nIOKAnGFjbC10eXBl4oCdIHRvIOKAnHR5cGXigJ0KPiAtIHJlbW92ZWQg4oCcaW50 ZXJmYWNlLWFsbC1hZ2dyZWdhdGXigJ0gZmVhdHVyZQo+IC0gc2ltcGxpZmllZCBzb3VyY2Ug cG9ydCBhbmQgZGVzdGluYXRpb24gcG9ydCBkZWZpbml0aW9uCj4KPiBUaGUgcHVsbCByZXF1 ZXN0IGZvciB0aGUgY2hhbmdlcyBjYW4gYmUgZm91bmQgaGVyZS4KPgo+IGh0dHBzOi8vZ2l0 aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjAKPgo+IEFmdGVyIGRpc2N1c3Np bmcgd2l0aCBzb21lIG9mIHRoZSBvcmlnaW5hbCBjb250cmlidXRvcnMsIGRlY2lkZWQgbm90 Cj4gdG8gaW5jbHVkZSB0aGUgY2hhbmdlIGFzIGl0IHJlbGF0ZXMgdG8gYXVnbWVudGluZyBp ZXRmLWludGVyZmFjZXMuIFdlCj4gZGlkIG5vdCBmaW5kIHRoYXQgdGhlIGNoYW5nZSBoYWQg YSBwYXJ0aWN1bGFyIGFkdmFudGFnZSBvdmVyIHRoZQo+IGN1cnJlbnQgaW1wbGVtZW50YXRp b24uIEV2ZW4gaWYgd2UgZG8gbm90IGNvbXBsZXRlbHkgdW5kZXJzdGFuZCBob3cKPiBBQ0xz IG1pZ2h0IGJlIGF0dGFjaGVkIOKAnGdsb2JhbGx54oCdIG9yIG9uIHNvbWV0aGluZyB0aGF0 IGlzIG5vdCBhbgo+IGludGVyZmFjZSwgaGF2aW5nIHRoZSBmbGV4aWJpbGl0eSB0byBhdHRh Y2ggdGhlbSB0byBvdGhlciBhdHRhY2htZW50Cj4gcG9pbnRzIGlzIGltcG9ydGFudC4gS2Vl cGluZyBpdCBhcyBpbnRlcmZhY2UtcmVmIGdpdmVzIHVzIHRoYXQKPiBmbGV4aWJpbGl0eS4K Pgo+IENoZWVycy4KPgo+PiBPbiBEZWMgMTgsIDIwMTcsIGF0IDQ6MzEgQU0sIEVsaW90IExl YXIgPGxlYXJAY2lzY28uY29tCj4+IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToK Pj4KPj4gU28gbG9uZyBhcyBub2JvZHkgZXhwZWN0cyBhbiBpbnRlcmZhY2UgY29uc3RydWN0 IGluIGEgTVVEIGZpbGUsIEknbQo+PiBoYXBweS4KPj4KPj4KPj4gT24gMTcuMTIuMTcgMTU6 MzQsIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSB3cm90ZToKPj4+IEVsaW90LAo+ Pj4KPj4+IE5vdGhpbmcgY2FuIGZvcmNlIGFuIGltcGxlbWVudGF0aW9uIHRvIGhhdmUgdG8g aW1wbGVtZW50IGVpdGhlcgo+Pj4gdGhlwqBpZXRmLWludGVyZmFjZXMgbW9kZWwgb3IgdGhl IGF1Z21lbnRhdGlvbiBpbiB0aGUKPj4+IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBtb2Rl bC4gSSBhcHByZWNpYXRlIHlvdXIgZGVzaXJlIGZvcgo+Pj4gbW9kdWxhcml0eSBhbmQgY29o ZXNpdmVuZXNzLCBidXQgSSB3b3VsZCByZXNpc3QgIzEsIGJlY2F1c2UgSSBmZWVsCj4+PiB0 aGF0IHRoZSBtYWpvcml0eSBvZiB1c2VycyB3aWxsIGJlIHRhcmdldGluZyBpbnRlcmZhY2Ut YmFzZWQKPj4+IGF0dGFjaG1lbnQgb3ZlciB0aW1lLiBJ4oCZdmUgYWRkZSBiYWNrIGluIHVz ZSBvZiB0aGUKPj4+IOKAnGludGVyZmFjZS1hdHRhY2htZW504oCdIGZlYXR1cmUgKHdoaWNo IEkgdG9vayBvdXQgYXMgcGFydCBvZgo+Pj4gcmVmYWN0b3JpbmcgaW50ZXJmYWNlIGF0dGFj aG1lbnQpLiBQYXJ0IG9mOgo+Pj4KPj4+ICAgICBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9k LXdnL2FjbC1tb2RlbC9wdWxsLzIxCj4+Pgo+Pj4KPj4+IFRoZSBhdWdtZW50cyBwYXJ0IG9m IHRoZSB0cmVlIG5vdyBsb29rcyBsaWtlOgo+Pj4KPj4+IMKgIGF1Z21lbnQgL2lmOmludGVy ZmFjZXMvaWY6aW50ZXJmYWNlOgo+Pj4gwqAgwqAgKy0tcncgYWNscyAqe2ludGVyZmFjZS1h dHRhY2htZW50fSo/Cj4+PiDCoCDCoCDCoCDCoCstLXJ3IGluZ3Jlc3MKPj4+IMKgIMKgIMKg IMKgfCDCoCstLXJ3IGFjbC1zZXRzCj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgKy0tcncgYWNs LXNldCogW25hbWVdCj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ydyBuYW1lIMKg IMKgIMKgIMKgIMKgIMKgIMKgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4gwqAgwqAg wqAgwqB8IMKgIMKgIMKgIMKgKy0tcncgdHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4gL2Fj Y2Vzcy1saXN0cy9hY2wvdHlwZQo+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgKy0tcm8g YWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+IMKgIMKgIMKg IMKgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0+ Cj4+PiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+PiDCoCDCoCDCoCDCoHwg wqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2 NAo+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtb2N0ZXRz PyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+PiDCoCDCoCDCoCDCoCstLXJ3IGVncmVzcwo+Pj4g wqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldHMKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg Ky0tcncgYWNsLXNldCogW25hbWVdCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1y dyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgdHlwZT8gwqAgwqAgwqAgwqAgwqAg wqAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDC oCDCoCDCoCAtPgo+Pj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlh bmc6Y291bnRlcjY0Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG1h dGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pgo+Pj4gQ2hlZXJzLAo+Pj4K Pj4+IEVpbmFyCj4+Pgo+Pj4KPj4+PiBPbiAxNyBEZWMgMjAxNywgYXQgMTE6MjksIEVsaW90 IExlYXIgPGxlYXJAY2lzY28uY29tCj4+Pj4gPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdy b3RlOgo+Pj4+Cj4+Pj4gRWluYXIsCj4+Pj4KPj4+PiBJIHRoaW5rIHRoaXMgY2hhbmdlIGlz IGZpbmUsIHdpdGggb25lIGV4Y2VwdGlvbi7CoCBJIHdvdWxkIHJhdGhlcgo+Pj4+IHRoZSBh dWdtZW50IHRvIHRoZSBpbnRlcmZhY2Ugbm90IGJlIHJlcXVpcmVkIGZvciBpbXBsZW1lbnRh dGlvbnMKPj4+PiB0aGF0IGRvbid0IGFjdHVhbGx5IGhhdmUgaW50ZXJmYWNlcy7CoCBJIHVu ZGVyc3RhbmQgdGhhdCB0aGVyZSBtYXkKPj4+PiBiZSB0d28gd2F5cyB0byBnbyBhYm91dCB0 aGlzOgo+Pj4+Cj4+Pj4gIDEuIFNlcGFyYXRlIG91dCB0aGUgYXVnbWVudCBpbnRvIGEgc2Vw YXJhdGUgbW9kdWxlIChzYW1lIGRvYyBpcwo+Pj4+ICAgICBmaW5lKTsgb3IKPj4+PiAgMi4g U29tZWhvdyAiZmVhdHVyZS1pemUiIHRoZSBhdWdtZW50Lgo+Pj4+Cj4+Pj4gSSBkb24ndCBr bm93IGhvdyB0byBkbyAoMikgYnV0IGlmIHlvdSBkbywgdGhhdCdzIG9rYXkgYnkgbWUuCj4+ Pj4KPj4+PiBFbGlvdAo+Pj4+Cj4+Pj4KPj4+PiBPbiAxNi4xMi4xNyAxNDoxOSwgRWluYXIg Tmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOgo+Pj4+PiBBbGwsCj4+Pj4+Cj4+Pj4+ IEFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25zIG9uLSBhbmQgb2ZmLWxpc3QsIEkgaGF2 ZSBhIGNhbmRpZGF0ZQo+Pj4+PiBQUiB0aGF0IGluY2x1ZGVzIHRoZSBjaGFuZ2VzIGluIHRo ZSBQUiBNYWhlc2ggc2VudCBvdXQgcGx1cyBzb21lCj4+Pj4+IG1vcmUgZWRpdHMuIFBsZWFz ZSBzZWUgY29uc29saWRhdGVkIFBSIGhlcmU6Cj4+Pj4+Cj4+Pj4+ICAgICBodHRwczovL2dp dGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIxCj4+Pj4+Cj4+Pj4+Cj4+Pj4+ IE1haW4gY2hhbmdlcyBpbiBhZGRpdGlvbiB0byBNYWhlc2jigJlzIFBSIGFyZToKPj4+Pj4K Pj4+Pj4gICAqIE1vdmVkIGludGVyZmFjZSBhdHRhY2htZW50IHRvIGJlIHZpYSBhbiBpbnRl cmZhY2UgYXVnbWVudGF0aW9uLgo+Pj4+PiAgICogUmVzdHJ1Y3R1cmVkIHBvcnQgbWF0Y2hl cyBzbGlnaHRseSB1bmRlciBib3RoIElQdjQgYW5kIElQdjYKPj4+Pj4gICAgIGNvbnRhaW5l cnMuCj4+Pj4+ICAgKiBSZW1vdmVkIHVubmVjZXNzYXJ5IGlkZW50aXR5ICdpbnRlcmZhY2Ut YWNsLWFnZ3JlZ2F0ZeKAmS4KPj4+Pj4gICAqIFJlbW92ZWQgYWN0aW9uIOKAmGljbXAtb2Zm 4oCZLCBjYW4gYmUgYXVnbWVudGVkIGxhdGVyLgo+Pj4+Pgo+Pj4+Pgo+Pj4+PiBGb3IgcmVm ZXJlbmNlLCBoZXJlIGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKAnC0taWV0ZuKA nSBsb2dzOgo+Pj4+Pgo+Pj4+PiAxMzoxMiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJl ZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZwo+Pj4+PiBpZXRmLWFjY2Vzcy1jb250 cm9sLWxpc3QueWFuZzo1MTogZXJyb3I6IGJhZCB2YWx1ZSAiWVlZWS1NTS1ERCIKPj4+Pj4g KHNob3VsZCBiZSBkYXRlKQo+Pj4+PiBtb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlz dAo+Pj4+PiDCoCDCoCArLS1ydyBhY2Nlc3MtbGlzdHMKPj4+Pj4gwqAgwqAgwqAgwqArLS1y dyBhY2wqIFtuYW1lXQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCArLS1ydyBuYW1lIMKgIMKgc3Ry aW5nCj4+Pj4+IMKgIMKgIMKgIMKgIMKgICstLXJ3IHR5cGU/IMKgIGFjbC10eXBlCj4+Pj4+ IMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjZXMKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAr LS1ydyBhY2UqIFtuYW1lXQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBu YW1lIMKgIMKgIMKgIMKgIMKgc3RyaW5nCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICstLXJ3IG1hdGNoZXMKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCstLXJ3 IChsMik/Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgKy0tOihldGgp Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgICstLXJ3IGV0aCB7 bWF0Y2gtb24tZXRofT8KPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAg wqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcz8gwqAgwqAgwqAKPj4+Pj4g wqB5YW5nOm1hYy1hZGRyZXNzCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgIMKgIMKgIMKgKy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3MtbWFzaz8gwqAKPj4+ Pj4geWFuZzptYWMtYWRkcmVzcwo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoCDCoCDCoCDCoCstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcz8gwqAgwqAgwqAgwqAgwqAg wqAKPj4+Pj4geWFuZzptYWMtYWRkcmVzcwo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNrPyDCoCDC oCDCoAo+Pj4+PiDCoHlhbmc6bWFjLWFkZHJlc3MKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBldGhlcnR5cGU/IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgCj4+Pj4+IMKgZXRoOmV0aGVydHlwZQo+Pj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgKGwzKT8KPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqArLS06KGlwdjQpCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgfCDCoCstLXJ3IGlwdjQge21hdGNoLW9uLWlwdjR9Pwo+Pj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgZHNjcD8gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAKPj4+Pj4gaW5ldDpkc2NwCj4+Pj4+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBlY24/IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdWludDgKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGxlbmd0aD8gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgdWludDE2Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgfCDCoCDCoCArLS1ydyB0dGw/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgdWludDgKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg ICstLXJ3IHByb3RvY29sPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+Pj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgKHNvdXJj ZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06KHJhbmdlKQo+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwgwqArLS1ydyBzb3VyY2UtcG9ydC1s b3dlciDCoCDCoCDCoCDCoAo+Pj4+PiDCoCBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgfCDCoCstLXJ3IHNvdXJj ZS1wb3J0LXVwcGVyIMKgIMKgIMKgIMKgCj4+Pj4+IMKgIGluZXQ6cG9ydC1udW1iZXIKPj4+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06KG9w ZXJhdG9yKQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAg fCDCoCDCoCArLS1ydyBzb3VyY2Utb3BlcmF0b3IgwqAgwqAgwqAgwqAgwqAKPj4+Pj4gwqAg b3BlcmF0b3IKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg IHwgwqAgwqAgKy0tcncgc291cmNlLXBvcnQgwqAgwqAgwqAgwqAgwqAgwqAgwqAKPj4+Pj4g wqAgaW5ldDpwb3J0LW51bWJlcgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoHwgwqAgwqAgKy0tcncKPj4+Pj4gKGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3Bl cmF0b3IpPwo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAg fCDCoCstLToocmFuZ2UpCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg fCDCoCDCoCB8IMKgfCDCoCstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgwqAgwqAKPj4+ Pj4gwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgfCDCoCDCoCB8IMKgfCDCoCstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgwqAg wqAKPj4+Pj4gwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgKy0tOihvcGVyYXRvcikKPj4+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqAgwqAgKy0tcncgZGVzdGluYXRp b24tb3BlcmF0b3IgwqAgwqAgwqAKPj4+Pj4gwqBvcGVyYXRvcgo+Pj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCDCoCArLS1ydyBkZXN0aW5hdGlv bi1wb3J0IMKgIMKgIMKgIMKgIMKgCj4+Pj4+IMKgaW5ldDpwb3J0LW51bWJlcgo+Pj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgaWhsPyDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+Pj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBmbGFncz8gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBiaXRzCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgfCDCoCDCoCArLS1ydyBvZmZzZXQ/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHVpbnQxNgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwg wqAgwqAgKy0tcncgaWRlbnRpZmljYXRpb24/IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+ Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgZGVz dGluYXRpb24taXB2NC1uZXR3b3JrPyDCoAo+Pj4+PiBpbmV0OmlwdjQtcHJlZml4Cj4+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBzb3VyY2Ut aXB2NC1uZXR3b3JrPyDCoCDCoCDCoAo+Pj4+PiDCoGluZXQ6aXB2NC1wcmVmaXgKPj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06KGlwdjYpCj4+Pj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgICstLXJ3IGlwdjYge21hdGNoLW9uLWlw djZ9Pwo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCst LXJ3IGRzY3A/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgCj4+Pj4+IGluZXQ6 ZHNjcAo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCst LXJ3IGVjbj8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+Pj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGxlbmd0 aD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDE2Cj4+Pj4+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgdHRsPyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgcHJvdG9jb2w/IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHVpbnQ4Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgIMKgIMKgIMKgKy0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgKy0tOihy YW5nZSkKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8 IMKgfCDCoCstLXJ3IHNvdXJjZS1wb3J0LWxvd2VyIMKgIMKgIMKgIMKgCj4+Pj4+IMKgIGlu ZXQ6cG9ydC1udW1iZXIKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAg wqAgwqAgwqB8IMKgfCDCoCstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyIMKgIMKgIMKgIMKgCj4+ Pj4+IMKgIGluZXQ6cG9ydC1udW1iZXIKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqAgwqAgwqAgwqB8IMKgKy0tOihvcGVyYXRvcikKPj4+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgIMKgICstLXJ3IHNvdXJjZS1vcGVy YXRvciDCoCDCoCDCoCDCoCDCoAo+Pj4+PiDCoCBvcGVyYXRvcgo+Pj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqAgwqAgKy0tcncgc291cmNlLXBv cnQgwqAgwqAgwqAgwqAgwqAgwqAgwqAKPj4+Pj4gwqAgaW5ldDpwb3J0LW51bWJlcgo+Pj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3Cj4+Pj4+ IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgKy0tOihyYW5nZSkKPj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDCoCstLXJ3 IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgwqAgwqAKPj4+Pj4gwqBpbmV0OnBvcnQtbnVtYmVy Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoHwg wqArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LXVwcGVyIMKgIMKgCj4+Pj4+IMKgaW5ldDpwb3J0 LW51bWJlcgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oHwgwqArLS06KG9wZXJhdG9yKQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoCDCoCDCoCDCoHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tb3BlcmF0b3IgwqAgwqAg wqAKPj4+Pj4gwqBvcGVyYXRvcgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoCDCoCDCoCDCoHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tcG9ydCDCoCDCoCDCoCDC oCDCoAo+Pj4+PiDCoGluZXQ6cG9ydC1udW1iZXIKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1pcHY2LW5ldHdvcms/ IMKgCj4+Pj4+IGluZXQ6aXB2Ni1wcmVmaXgKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBzb3VyY2UtaXB2Ni1uZXR3b3JrPyDCoCDCoCDC oAo+Pj4+PiDCoGluZXQ6aXB2Ni1wcmVmaXgKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBmbG93LWxhYmVsPyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoAo+Pj4+PiBpbmV0OmlwdjYtZmxvdy1sYWJlbAo+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgKy0tcncgKGw0KT8KPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqArLS06KHRjcCkKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqB8IMKgKy0tcncgdGNwIHttYXRjaC1vbi10Y3B9Pwo+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgc2VxdWVuY2UtbnVtYmVyPyDCoCDC oCDCoCDCoCDCoHVpbnQzMgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgKy0tcncgYWNrbm93bGVkZ2VtZW50LW51bWJlcj8gwqAgdWludDMyCj4+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBkYXRhLW9m ZnNldD8gwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgcmVzZXJ2ZWQ/IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHVpbnQ4Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg fCDCoCDCoCArLS1ydyBmbGFncz8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiaXRz Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyB3 aW5kb3ctc2l6ZT8gwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50MTYKPj4+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IHVyZ2VudC1wb2ludGVyPyDC oCDCoCDCoCDCoCDCoCB1aW50MTYKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqB8IMKgIMKgICstLXJ3IG9wdGlvbnM/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dWludDMyCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgKy0tOih1ZHAp Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IHVkcCB7 bWF0Y2gtb24tdWRwfT8KPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8 IMKgIMKgICstLXJ3IGxlbmd0aD8gwqAgdWludDE2Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgKy0tOihpY21wKQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8IMKgfCDCoCDCoCArLS1ydyBpY21wIHttYXRjaC1vbi1pY21wfT8KPj4+Pj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyB0eXBlPyDCoCDCoCDC oCDCoCDCoCDCoCB1aW50OAo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oCDCoCDCoCDCoCstLXJ3IGNvZGU/IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4+Pj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgcmVzdC1vZi1o ZWFkZXI/IMKgIHVpbnQzMgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0t cncgZWdyZXNzLWludGVyZmFjZT8gwqAgwqBpZjppbnRlcmZhY2UtcmVmCj4+Pj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBpbmdyZXNzLWludGVyZmFjZT8gwqAgaWY6 aW50ZXJmYWNlLXJlZgo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY3Rp b25zCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBmb3J3YXJkaW5n IMKgIMKgaWRlbnRpdHlyZWYKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCst LXJ3IGxvZ2dpbmc/IMKgIMKgIMKgaWRlbnRpdHlyZWYKPj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgKy0tcm8gc3RhdGlzdGljcyB7YWNsLWFnZ3JlZ2F0ZS1zdGF0c30/Cj4+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDC oCB5YW5nOmNvdW50ZXI2NAo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCst LXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4+Cj4+Pj4+IMKg IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOgo+Pj4+PiDCoCDCoCArLS1y dyBhY2xzCj4+Pj4+IMKgIMKgIMKgIMKgKy0tcncgaW5ncmVzcwo+Pj4+PiDCoCDCoCDCoCDC oHwgwqArLS1ydyBhY2wtc2V0cwo+Pj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgKy0tcncgYWNs LXNldCogW25hbWVdCj4+Pj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUg wqAgwqAgwqAgwqAgwqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lCj4+Pj4+IMKg IMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+ IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKg Ky0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+Pj4g wqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLT4KPj4+Pj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+Pj4+PiDC oCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5 YW5nOmNvdW50ZXI2NAo+Pj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8g bWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+Pj4gwqAgwqAgwqAgwqAr LS1ydyBlZ3Jlc3MKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldHMKPj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyBhY2wtc2V0KiBbbmFtZV0KPj4+Pj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9h Y2Nlc3MtbGlzdHMvYWNsL25hbWUKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0t cncgdHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQo+ Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBhY2Utc3RhdGlzdGljcyogW25h bWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCstLXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+Pj4gL2FjY2Vzcy1s aXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPj4+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5 YW5nOmNvdW50ZXI2NAo+Pj4+Pgo+Pj4+PiBDb21tZW50cyB3ZWxjb21lIQo+Pj4+Pgo+Pj4+ PiBDaGVlcnMsCj4+Pj4+Cj4+Pj4+IEVpbmFyCj4+Pj4+Cj4+Pj4+Cj4+Pj4+Cj4+Pj4+PiBP biAxNCBEZWMgMjAxNywgYXQgMTg6NTAsIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5u KQo+Pj4+Pj4gPGVpbmFybm5AY2lzY28uY29tIDxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+ PiB3cm90ZToKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+PiBPbiAxNCBEZWMgMjAxNywg YXQgMDg6MjEsIFNvbmFsIEFnYXJ3YWwgPHNhZ2Fyd2FsMTJAZ21haWwuY29tCj4+Pj4+Pj4g PG1haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbT4+IHdyb3RlOgo+Pj4+Pj4+Cj4+Pj4+Pj4g SGkgRWluYXIsCj4+Pj4+Pj4KPj4+Pj4+PiBZb3UgaGFkIDMgcXVlc3Rpb25zIGZvciBtZSBv biBhbGwgdGhlIHNldmVyYWwgZS1tYWlsIHRocmVhZHMuwqAKPj4+Pj4+PiAxLiBHbG9iYWwg YXR0YWNobWVudCBwb2ludAo+Pj4+Pj4+IDIuIGljbXAtb2ZmCj4+Pj4+Pj4gMy4gYWNsLWFn Z3JlZ2F0ZS1pbnRlcmZhY2Ugc3RhdHMuCj4+Pj4+Pj4KPj4+Pj4+PiBGb3IgKDEpLCBteSBm aXJzdCBwcmVmZXJlbmNlIGlzIHRvIGhhdmUgdGhlIG1vZGVsIGRlZmluZQo+Pj4+Pj4+IGF0 dGFjaG1lbnQgcG9pbnQgZm9yIGludGVyZmFjZXMgb25seS4KPj4+Pj4+Cj4+Pj4+PiBlaW5h cm5uPiBJIGhhdmUgc29tZSBkaWZmcywgbGF5ZXJlZCBvbiB0b3Agb2YgTWFoZXNo4oCZcyBQ UiB0bwo+Pj4+Pj4gbmV0bW9kLXdnL2FjbC1tb2RlbCB0aGF0IGRvIHRoaXMuIE5lYXJseSBs aWtlIHRoZSBhdWdtZW50YXRpb24gSQo+Pj4+Pj4gaGF2ZSBiZWxvdy4gRmVlbCBmcmVlIHRv IHRha2UgYSBsb29rIGF0Ogo+Pj4+Pj4KPj4+Pj4+ICAgICBodHRwczovL2dpdGh1Yi5jb20v bWpldGhhbmFuZGFuaS9hY2wtbW9kZWwvcHVsbC8zCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+PiBI b3dldmVyLCBLcmlzdGlhbiB3YW50cyB0aGUgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQgYXMg d2VsbCBzbwo+Pj4+Pj4+IHRoYXQgaGUgY2FuIGFkZCB0aGUgQUNMIHRvIHRoZSBsaW51eCB0 YWJsZXMuCj4+Pj4+Pgo+Pj4+Pj4gZWluYXJubj4gSSB0aGluayBLcmlzdGlhbiBkb2VzbuKA mXQgZmVlbCBhIGdsb2JhbCBhdHRhY2htZW50IHBvaW50Cj4+Pj4+PiBuZWVkcyB0byBiZSBp biB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQgaGUgY2FuIGNvbmZpcm0uCj4+Pj4+Pgo+Pj4+ Pj4+IElmIGFuIEFDTCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9lcyB0aGlzIG1lYW4gaXQg aXMgcGVyCj4+Pj4+Pj4gZGlyZWN0aW9uIG9yIGRvZXMgaXQgbWVhbiBpdCBpcyBhY3Jvc3Mg ZGlyZWN0aW9ucz8KPj4+Pj4+Cj4+Pj4+PiBlaW5hcm5uPiBJIGRvbuKAmXQga25vdyByaWdo dCBub3cgOi0pCj4+Pj4+Pgo+Pj4+Pj4+IFRoaXMgZ2xvYmFsIEFDTCBtYXkgbm90IGJlIGFw cGxpY2FibGUgdG8gYW55IG9mIENpc2NvJ3Mgc2VydmljZQo+Pj4+Pj4+IHByb3ZpZGVyIHJv dXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFjdHVhbGx5Cj4+Pj4+Pj4gcmVw bGljYXRpbmcgdGhlIEFDTCB0byBhbGwgbGluZSBjYXJkcyBhbmQgYXR0YWNoaW5nIGl0IGlu Cj4+Pj4+Pj4gaW5ncmVzcyBhbmQgZWdyZXNzIGRpcmVjdGlvbnMgYWNyb3NzIGFsbCBpbnRl cmZhY2VzLgo+Pj4+Pj4KPj4+Pj4+IGVpbmFybm4+IFBlciBvdGhlciBlbWFpbHMsIEkgZG9u 4oCZdCB0aGluayB3ZSB1bmRlcnN0YW5kIHRoaXMKPj4+Pj4+IGVub3VnaCB5ZXQgdG8gc3Bl Y2lmeSBpdCwgc28gSSBzdWdnZXN0IHdlIGp1c3QgbGVhdmUgaXQgb3V0IGZvcgo+Pj4+Pj4g bm93LiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50cyBhIOKAnGdsb2JhbCBhdHRhY2ht ZW50IHBvaW504oCdCj4+Pj4+PiBiZWluZyBhZGRlZCBsYXRlciBvbmNlIHdlIHVuZGVyc3Rh bmQgd2hhdCBpdCByZWFsbHkgbWVhbnMuCj4+Pj4+Pgo+Pj4+Pj4+IEZvciAoMiksIEkgYW0g b2sgd2l0aCByZW1vdmluZyBpY21wLW9mZi4KPj4+Pj4+Cj4+Pj4+PiBlaW5hcm5uPiBEb25l IGluIG15IFBSIGFib3ZlLgo+Pj4+Pj4KPj4+Pj4+PiBGb3IgKDMpLCB0aGlzIHdvdWxkIGhh dmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wgc3RhdHMgYWNyb3NzCj4+Pj4+Pj4gYWxs IGludGVyZmFjZXMgZm9yIGFsbCBBQ0wncy4gU29tZXRoaW5nIGxpa2UgdGhpcyBpcyBwb3Nz aWJsZSBvbgo+Pj4+Pj4+IGFuIFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1l cyBhc3NvY2lhdGVkIHdpdGggaXQuCj4+Pj4+Pj4gTGV0J3MgY2hhdCBhYm91dCB0aGlzIG9m ZmxpbmUgdG9tb3Jyb3cuCj4+Pj4+Pgo+Pj4+Pj4gZWluYXJubj4gSeKAmWxsIHBpbmcgeW91 IHRvIGNsYXJpZnksIGFuZCB3ZSBjYW4gYnJpbmcgYW55Cj4+Pj4+PiBjb25jbHVzaW9uIGJh Y2sgdG8gdGhlIGxpc3QuCj4+Pj4+Pgo+Pj4+Pj4gQ2hlZXJzLAo+Pj4+Pj4KPj4+Pj4+IEVp bmFyCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pj4gU29uYWwuCj4+Pj4+Pj4KPj4+Pj4+ Pgo+Pj4+Pj4+IE9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhlc2ggSmV0 aGFuYW5kYW5pCj4+Pj4+Pj4gPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToKPj4+Pj4+Pgo+Pj4+Pj4+ICAgICBXZSB3 YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUg bGluZSwKPj4+Pj4+PiAgICAgYW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9p bnQgd2lsbCBiZSBvbmUgb2YgdGhlCj4+Pj4+Pj4gICAgIGNob2ljZXMgKHRoZSBvdGhlciBi ZWluZyB0aGUgaW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzCj4+Pj4+Pj4gICAgIGF1Z21l bnQgbG9vayBsaWtlLiBOb3RlLCBhcyBmYXIgYXMgSSBrbm93LCB5b3UgY2Fubm90Cj4+Pj4+ Pj4gICAgIGF1Z21lbnQgaW5zaWRlIGEgY2hvaWNlIG5vZGUuCj4+Pj4+Pj4KPj4+Pj4+Pj4g ICAgIE9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQg KGVpbmFybm4pCj4+Pj4+Pj4+ICAgICA8ZWluYXJubkBjaXNjby5jb20gPG1haWx0bzplaW5h cm5uQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAgICAgUGVyaGFwcyBs aWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOgo+Pj4+Pj4+ Pgo+Pj4+Pj4+PiAgICAgICAgIMKgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJm YWNlOgo+Pj4+Pj4+PiAgICAgICAgIMKgIMKgICstLXJ3IGluZ3Jlc3MtYWNscwo+Pj4+Pj4+ PiAgICAgICAgIMKgIMKgIHwgwqArLS1ydyBhY2wtc2V0cwo+Pj4+Pj4+PiAgICAgICAgIMKg IMKgIHwgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4+Pj4+Pj4+ICAgICAgICAgwqAg wqAgfCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAtPgo+Pj4+ Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPj4+Pj4+Pj4gICAgICAgICDC oCDCoCB8IMKgIMKgIMKgIMKgKy0tcncgdHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+ Pj4+Pj4gICAgICAgICAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+Pj4+Pj4+ICAgICAgICAg wqAgwqAgfCDCoCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0KPj4+Pj4+ Pj4gICAgICAgICB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+Pj4+Pj4gICAgICAgICDCoCDCoCB8 IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+ Pj4+Pj4gICAgICAgICAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+Pj4+Pj4+ ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/ IMKgIHlhbmc6Y291bnRlcjY0Cj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDC oCDCoCArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+ PiAgICAgICAgIMKgIMKgICstLXJ3IGVncmVzcy1hY2xzCj4+Pj4+Pj4+ICAgICAgICAgwqAg wqAgwqAgwqArLS1ydyBhY2wtc2V0cwo+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKg ICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKg IMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+Cj4+Pj4+Pj4+ICAgICAg ICAgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKg IMKgIMKgIMKgKy0tcncgdHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+Pj4+Pj4gICAg ICAgICAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAg wqAgwqAgwqAgwqArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdCj4+Pj4+Pj4+ICAgICAg ICAge2ludGVyZmFjZS1zdGF0c30/Cj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+Pj4+PiAg ICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUKPj4+Pj4+Pj4gICAgICAg ICDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlh bmc6Y291bnRlcjY0Cj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Ky0tcm8gbWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+Pj4+Pj4KPj4+ Pj4+Pj4KPj4+Pj4+Pj4gICAgIENvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFp bmVyIGFib3ZlIGJvdGggdGhlc2UgJgo+Pj4+Pj4+PiAgICAgcmVuYW1lIOKAnGluZ3Jlc3Mt YWNscyIgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlCj4+Pj4+Pj4+ ICAgICByb290IGZvciB0aGUgYXVnbWVudGF0aW9uIGlmIHByZWZlcnJlZC4KPj4+Pj4+Pj4K Pj4+Pj4+Pj4gICAgIENoZWVycywKPj4+Pj4+Pj4KPj4+Pj4+Pj4gICAgIEVpbmFyCj4+Pj4+ Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiAgICAgT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVs aW90IExlYXIgPGxlYXJAY2lzY28uY29tCj4+Pj4+Pj4+PiAgICAgPG1haWx0bzpsZWFyQGNp c2NvLmNvbT4+IHdyb3RlOgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4gICAgIE9uIDEyLzYvMTcgNzoyMyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToK Pj4+Pj4+Pj4+PiAgICAgSG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2ht ZW50IHBvaW50LAo+Pj4+Pj4+Pj4+ICAgICBjdXJyZW50bHkgYW4KPj4+Pj4+Pj4+PiAgICAg J2ludGVyZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlCj4+Pj4+Pj4+Pj4g ICAgIGlmOmludGVyZmFjZXMvaW50ZXJmYWNlLAo+Pj4+Pj4+Pj4+ICAgICBpbnNpZGUgb2Yg dGhlIOKAmGFjbOKAmSDCoGNvbnRhaW5lcj8gRG93biB0aGUgbGluZSB3ZSBtaWdodAo+Pj4+ Pj4+Pj4+ICAgICBuZWVkIHRvIGhhdmUgYW4KPj4+Pj4+Pj4+PiAgICAgY29udGFpbmVyIGZv ciAiYXR0YWNobWVudCBwb2ludHMiIHRvIGFjY29tbW9kYXRlIHRoZQo+Pj4+Pj4+Pj4+ICAg ICBwb3NzaWJpbGl0eSBvZgo+Pj4+Pj4+Pj4+ICAgICBhdHRhY2hpbmcgYW4gQUNMIGVpdGhl ciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uCj4+Pj4+Pj4+Pj4KPj4+Pj4+ Pj4+Cj4+Pj4+Pj4+PiAgICAgS2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0 IGFuIEFDTCBkb2Vzbid0IGF0dGFjaAo+Pj4+Pj4+Pj4gICAgIHRvIGFuCj4+Pj4+Pj4+PiAg ICAgaW50ZXJmYWNlIGF0IGFsbC4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+Pj4+ICAgICBu ZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+PiAgICAgbmV0bW9kQGlldGYub3JnIDxtYWls dG86bmV0bW9kQGlldGYub3JnPgo+Pj4+Pj4+Pj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCj4+Pj4+Pj4+PiAgICAgPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPgo+Pj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+ Pj4gICAgIE1haGVzaCBKZXRoYW5hbmRhbmkKPj4+Pj4+PiAgICAgbWpldGhhbmFuZGFuaUBn bWFpbC5jb20gPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4KPj4+Pj4+Pgo+Pj4+ Pj4+Cj4+Pj4+Pj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4+Pj4+Pj4gICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4+Pj4+PiAgICAg bmV0bW9kQGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+Pj4+Pj4+ICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Pj4+ICAg ICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+Cj4+Pj4+ Pj4KPj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+PiBu ZXRtb2RAaWV0Zi5vcmcgPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Cj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Pgo+Pj4+Pgo+Pj4+ Pgo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+IG5ldG1vZEBpZXRmLm9yZwo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Cj4+ Pgo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QKPgo+IE1haGVzaCBKZXRoYW5hbmRhbmkKPiBtamV0aGFuYW5kYW5pQGdtYWls LmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPgo+Cj4KPgo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxp bmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCgo= --------------BBBB20A3D0CC9698AB192736 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

Thanks for this work.=C2=A0 I think this is okay.=C2=A0 In the cas= e of MUD we simply won't have the other container.=C2=A0 Can I please ask th= at you get the draft out quickly as draft-ietf-opsawg-mud has been waiting quite some time for this work to complete.

Eliot


On 10.01.18 04:08, Mahesh Jethanandani= wrote:
I have pulled in the changes as they relate to:

- moving =E2=80=9Cinterface-acl=E2=80=9D under the = container =E2=80=9Cattachment-points=E2=80=9D making it local to that conta= iner.
- reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9C= type=E2=80=9D
- removed =E2=80=9Cinterface-all-aggregate=E2=80=9D= feature
- simplified source port and destination port definition

The pull request for the changes can be found here.=

https://github.com/netmod-wg/acl-model= /pull/20

After discussing with some of the original contributors, decided not to include the change as it relates to augmenting ietf-interfaces. We did not find that the change had a particular advantage over the current implementation. Even if we do not completely understand how ACLs might be attached =E2=80=9Cglobally=E2=80=9D or on something that is not an interfa= ce, having the flexibility to attach them to other attachment points is important. Keeping it as interface-ref gives us that flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, Eliot Lear <<= a href=3D"mailto:lear@cisco.com" class=3D"" moz-do-not-send=3D"true">lear@cisco.com> wrote:

So long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
Eliot,

Nothing can force an implementation to have to implement either the=C2=A0ietf-interfaces mod= el or the augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment over time. I=E2=80=99ve ad= de back in use of the =E2=80=9Cinterface-attachment=E2=80=9D = feature (which I took out as part of refactoring interface attachment). Part of:

https://githu= b.com/netmod-wg/acl-model/pull/21

The augments part of the tree now looks= like:

=C2= =A0 augment /if:interfaces/if:interface:
=
=C2= =A0 =C2=A0 +--rw acls {interface-attachment}?
=C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw ingress
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--rw acl-sets
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw acl-set* [name]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/acl/name
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/type
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics* = [name] {interface-stats}?
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-= packets? =C2=A0 yang:counter64
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-= octets? =C2=A0 =C2=A0yang:counter64
=C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw egress
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw acl-sets
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw acl-set* [name]<= /div>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/acl/name
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/type
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro ace-statistics*= [name] {interface-stats}?
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro na= me =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro ma= tched-packets? =C2=A0 yang:counter64
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro ma= tched-octets? =C2=A0 =C2=A0yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisc= o.com> wrote:

Einar,

I think this change is fine, with one exception.=C2=A0 I would rather th= e augment to the interface not be required for implementations that don't actually have interfaces.=C2=A0 I understand that th= ere may be two ways to go about this:

  1. Separate out the augment int= o a separate module (same doc is fine); or
  2. Somehow "feature-ize" the augment.

I don't know how to do (2) but if you do, that's okay by me.

Eliot


On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
All,

After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR here:

h= ttps://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to Mahesh=E2=80=99s PR are:

  • Moved interface attachment to be via an interface augmentation.
  • Restructured port matches slightly under both IPv4 and IPv6 containers.
  • Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. =
  • Removed action =E2=80=98icmp-off=E2=80=99, can be = augmented later.

For reference, here is th= e current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs:

13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
ietf-access-contro= l-list.yang:51: error: bad value "YYYY-MM-DD" (should be date)
module: ietf-access-control-list
=C2=A0 =C2=A0 +--r= w access-lists
=C2=A0 =C2=A0 =C2=A0= =C2=A0+--rw acl* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--rw name =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--rw type? =C2=A0 acl-type
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--rw aces
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ace* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw matches
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw (l2)?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(eth)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw eth {ma= tch-on-eth}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw destination-mac-address? =C2=A0 =C2= =A0 =C2=A0 =C2=A0yang:mac-address
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw destination-mac-address-mask? =C2=A0= yang:mac-address
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw source-mac-address? =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 yang:mac-address
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw source-mac-address-mask? =C2=A0 =C2= =A0 =C2=A0 =C2=A0yang:mac-address
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw ethertype? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0eth:ethertype
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw (l3)?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(ipv4)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0+--rw ipv4 {m= atch-on-ipv4}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= dscp? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = inet:dscp
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= ecn? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= length? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= ttl? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= protocol? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= (source-port-range-or-operator)?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0+--:(range)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0| =C2=A0+--rw source-port-lower =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0| =C2=A0+--rw source-port-upper =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0+--:(operator)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 +--rw source-operator =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 operator
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 +--rw source-port =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= (destination-port-range-or-operator= )?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0+--:(range)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0| =C2=A0+--rw destination-port-lower =C2=A0 =C2=A0= =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0| =C2=A0+--rw destination-port-upper =C2=A0 =C2=A0= =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0+--:(operator)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 +--rw destination-operator =C2=A0 =C2=A0 = =C2=A0 =C2=A0operator
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 +--rw destination-port =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= ihl? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= flags? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b= its
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= offset? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= identification? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= destination-ipv4-network? =C2=A0 inet:ipv4-prefix
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= source-ipv4-network? =C2=A0 =C2=A0 = =C2=A0 =C2=A0inet:ipv4-prefix
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(ipv6)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw ipv6 {m= atch-on-ipv6}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw dscp? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = inet:dscp
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw ecn? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw length? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw ttl? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw protocol? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw (source-port-range-or-operator)?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0+--:(range)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0| =C2=A0+--rw source-port-lower =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0| =C2=A0+--rw source-port-upper =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0+--:(operator)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 +--rw source-operator =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 operator
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 +--rw source-port =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw (destination-port-range-or-operator= )?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0+--:(range)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0| =C2=A0+--rw destination-port-lower =C2=A0 =C2=A0= =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0| =C2=A0+--rw destination-port-upper =C2=A0 =C2=A0= =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0+--:(operator)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 +--rw destination-operator =C2=A0 =C2=A0 = =C2=A0 =C2=A0operator
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 +--rw destination-port =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0inet:port-number
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw destination-ipv6-network? =C2=A0 inet:ipv6-prefix
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw source-ipv6-network? =C2=A0 =C2=A0 = =C2=A0 =C2=A0inet:ipv6-prefix
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw flow-label? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = inet:ipv6-flow-label
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw (l4)?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(tcp)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0+--rw tcp {ma= tch-on-tcp}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= sequence-number? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= acknowledgement-number? =C2=A0 uint= 32
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= data-offset? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= reserved? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= flags? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bits
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= window-size? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= urgent-pointer? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16<= /font>
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= options? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(udp)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0+--rw udp {ma= tch-on-udp}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw= length? =C2=A0 uint16
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--:(icmp)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw icmp {m= atch-on-icmp}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw code? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw rest-of-header? =C2=A0 uint32
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw egress-interface? =C2=A0= =C2=A0if:interface-ref
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw ingress-interface? =C2=A0= if:interface-ref
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw actions
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw forwarding =C2=A0 =C2=A0= identityref
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw logging? =C2=A0 =C2=A0 = =C2=A0identityref
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics {acl-aggregate-stats}?
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-packets? =C2=A0= yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-octets? =C2=A0 =C2=A0yang:counter64

=C2=A0 augment /if:interfaces/if:interface:=
=C2=A0 =C2=A0 +--r= w acls
=C2=A0 =C2=A0 =C2=A0= =C2=A0+--rw ingress
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0+--rw acl-sets
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/acl/name
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type? =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/type
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics* [name] {interface-stats}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets? =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets? =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0+--rw egress
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--rw acl-sets
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/acl/name
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/acl/type
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro ace-statistics* [name] {interface-stats}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-packets? =C2=A0= yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-octets? =C2=A0 =C2=A0yang:counter64

Comments welcome!

Cheers,

Einar



On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:



On 14 Dec 2017, at 08:21, Sonal Agarwal <= sagarwal12@gmail.com> wrote:

Hi Einar,

You had 3= questions for me on all the several e-mail threads.=C2=A0
1. Global= attachment point
2. icmp-off
3. acl-aggregate-interface= stats.

For (1), my first preference is to have the model define attachment point for interfaces only.

=
einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s PR to= netmod-wg/acl-model that do this. Nearly like the augmentation I have below. Feel free to take a look at:<= /div>

=
https://github.com/mjethanandani/acl-model/pull/3

However, Kristian wants the global attachment point as well so that he can add the ACL to the linux tables.
=

=
einarnn> I think Kristian doesn=E2=80=99= t feel a global attachment point needs to be in this first revision. But he can confirm.

If an ACL= is attached globally, does this mean it is per direction or does it mean it is across directions?

=
einarnn> I don=E2=80=99t know right now = :-)

This global ACL may not be applicable to any of Cisco's service provider routers as I don't see any platform actually replicating the ACL to all line cards and attaching it in ingress and egress directions across all interfaces.

=
einarnn> Per= other emails, I don=E2=80=99t= think we understand this enough yet to specify it, so I suggest we just leave it out for now. Nothing in the model prevents a =E2=80=9Cglo= bal attachment point=E2=80=9D bei= ng added later once we understand what it really means.

For (2), = I am ok with removing icmp-off.

=
einarnn> Don= e in my PR above.

For (3), this would have to be a combination of ACL stats across all interfaces for all ACL's. Something like this is possible on an XR box where ACES have counter names associated with it. Let's chat about this offline tomorrow.
=

=
einarnn> I=E2= =80=99ll ping you to clarify, and we can bring any conclusion back to the list.

=
Cheers,
=

Einar



Sonal.

=
On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal=E2=80= =9D attachment point down the line, and that =E2=80=9Cgloba= l=E2=80=9D attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.
On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <<= a href=3D"mailto:einarnn@cisco.com" target=3D"_blank" class=3D"" moz-do-not-send= =3D"true">einarnn@cisco.com> wrote:

Perh= aps like this, as an augmentation to the interface:

=C2=A0 augment /if:interfaces/= if:interface:
=C2=A0 =C2=A0 +--rw ingress-acls
=C2=A0 =C2=A0 | =C2=A0= +--rw acl-sets=
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw nam= e =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/a= cl/name
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw typ= e? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/type
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics*= [name] {interface-stat= s}?
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/aces/ace/name=
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets= ? =C2=A0 yang:counter64<= /font>
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets?= =C2=A0 =C2=A0yang:coun= ter64
=C2=A0 =C2=A0 +--rw egress-acls
=C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw acl-sets=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw nam= e =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/a= cl/name
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw typ= e? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/type
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics*= [name] {interface-stat= s}?
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/aces/ace/name=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets= ? =C2=A0 yang:counter64<= /font>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets?= =C2=A0 =C2=A0yang:coun= ter64

Could also put an =E2=80=9Caces=E2= =80=9D container above both these & rename =E2=80=9Cingres= s-acls" to =E2=80=9Cing= ress=E2=80=9D, etc. to give a single root for the augmentation if preferred.

Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com&= gt; wrote:



= On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently an 'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2= =80=99 =C2=A0container= ? Down the line we might need to have an
container for "attachment points" to accommodate the possibility of<= br class=3D""> attaching an ACL either to an interface or =E2=80=9Cglo= bally=E2=80=9D.

=

= Keeping in mind that one use is that an ACL doesn't attach to an interface at all.

= _______________________________________________
netmod mailing list
netmod@ietf.org=
https://www.ietf.or= g/mailman/list= info/netmod

=

=
Mahesh Jethanandani
mjethanandani@gmail.com

= <= /div>

_______________________________________________
netmod mailing list netmod@ietf.org
https://www.ietf.org/mailman/listin= fo/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/lis=
tinfo/netmod



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

Mahesh Jethanandani
mjethanandani@gmail.com= 



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

--------------BBBB20A3D0CC9698AB192736-- --xdKR59NewOib3acUeBvD5xKRQfAMBevku-- --6Pr28Ab55iRndvQuU15frpObkLGriIb57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpVwlMACgkQh7ZrRtnS ejMPIQf9EoW4Mo/z6t7aoL+tXm7qxO1az/+mPO8QdZqAY92hQCj/KIKi1gntB8t+ qYTRz3rocWN+F+bimg68sLRuynzc48WjaAnP+uk8g2Kuz2azhGHT3SdKfyaizZN7 WhZUNzmdtDi3ucJ5wRdoCRO47s5N5hNT/WPSsU55ZW7x5yjkLhYnMBrGd4J0eFSC PcsDGuoxF3DpOA6ZEMLbxFr57kLWq0UEO7PfEXHqHNBPLv+0ojawQcE+GXMXqEit bXDD0PsIr65cxG4rXor9nXDu4XVhJdXBH/4vW9BqJS+Fr3fq5i0g03rbU5py5gSP 1ILZ/r/hUIBANyKAcsb/7kpnD8AMuQ== =IdhR -----END PGP SIGNATURE----- --6Pr28Ab55iRndvQuU15frpObkLGriIb57-- From nobody Wed Jan 10 00:58:16 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 E2B63126CB6 for ; Wed, 10 Jan 2018 00:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fllVkfPmWnRA for ; Wed, 10 Jan 2018 00:58:11 -0800 (PST) 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 9381D124E15 for ; Wed, 10 Jan 2018 00:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90592; q=dns/txt; s=iport; t=1515574691; x=1516784291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dIHBInAky2t5+e+SN9mhQuY7tKJ0r6QK8s8ca58R6ss=; b=AnkpiIhvLJtVfhTBXJZHE9Q5v0UAYnhYztB5lCSs+/rDRTUAP4T5Xyz+ n8DWJ7XLCDTNW6jYkvxTDn2XRoQEfxRLjXG/L36GJS+uLpOB1MK4iayd8 aORJKYw8K74gAxaWqRfPxowBMAXXKTl6yT5+JK4OA6y8kZtLbfNnj+gGi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQDW1FVa/5pdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDETBmdCcHhACKJI5egVuJMY4kFIICChgBCoE5AYMPTwIahCM?= =?us-ascii?q?/GAEBAQEBAQEBAWsohSQCAQMBARgJBEcLEAIBCA4qAQYDAgICHwYLFBECBA4Fi?= =?us-ascii?q?U9MAxUQryuBbTomhxcNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYQgghWDPwE?= =?us-ascii?q?pDIJ5gmtEAQECgUUSFxgfgmExgjQFkieHS4k1PQKICYg5hQEMggyGHItajTtAh?= =?us-ascii?q?WCDGQIRGQGBOwEfOYFQbxU9KgGBfz+BXDkcgWd4ikmBFwEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,339,1511827200"; d="scan'208,217"; a="54647771" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 08:58:10 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0A8w9uX017724 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Jan 2018 08:58:09 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 10 Jan 2018 03:58:08 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 10 Jan 2018 03:58:08 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani CC: "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpICAAshNAIABc5kAgAAzf4CAAXAVAIAjiDCAgABhzIA= Date: Wed, 10 Jan 2018 08:58:08 +0000 Message-ID: References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> In-Reply-To: <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.240.141] Content-Type: multipart/alternative; boundary="_000_E2A33B749D0B49648280FF931CA1D330ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 08:58:15 -0000 --_000_E2A33B749D0B49648280FF931CA1D330ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFoZXNoLA0KDQpUd28gdGhpbmdzOg0KDQpGaXJzdCwgSSBzZWUgdGhhdCB5b3UgaGF2ZSBzdGls bCBsZWZ0IGluIHRoZSDigJxpY21wLW9mZuKAnSBhY3Rpb24uIFRoaXMgd2FzIHNvbWV0aGluZyBi b3RoIEtyaXN0aWFuIGFuZCBJIHJlY29tbWVuZGVkIHJlbW92aW5nLCBhbmQgSSBhbHNvIGRpc2N1 c3NlZCB0aGlzIHdpdGggU29uYWwgYXQgdGhlIGVuZCBvZiBsYXN0IHllYXIgYW5kIHNoZSBhZ3Jl ZWQgdGhhdCBpdCBzaG91bGQgcHJvYmFibHkgYmUgcmVtb3ZlZCBzaW5jZSBpdCBzZWVtcyBhdCB0 aGlzIHBvaW50IChhYnNlbnQgYW55b25lIHBvaW50aW5nIG91dCBvdGhlciBpbXBsZW1lbnRhdGlv bnMpIHRvIGJlIGEgQ2lzY28gSU9TLVhSLXNwZWNpZmljIGZlYXR1cmUgdGhhdCBzaG91bGQgcHJv YmFibHkgYmUgZGVhbHQgd2l0aCB2aWEgYSB2ZW5kb3IgYXVnbWVudGF0aW9uIGluaXRpYWxseS4g Q2FuIHdlIHJlbW92ZSB0aGlzPw0KDQpTZWNvbmQsIEkgd291bGQgcmVhbGx5IGxpa2UgdGhlIGNv bnRyaWJ1dG9ycyB3aG8gd2lzaCB0byBtYWludGFpbiB0aGUgc2VwYXJhdGUgQUNMIGF0dGFjaG1l bnQgaW50ZXJmYWNlIGxpc3Qgd2l0aCBpbnRlcmZhY2UgcmVmZXJlbmNlcyB0byBsYXkgb3V0IGhv dyBkaXJlY3QgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcHJldmVudHMgQUNMcyBiZWluZyB1c2VkIHdp dGggb3RoZXIgYXR0YWNobWVudCBwb2ludHMuIEFzIEkgcG9pbnRlZCBvdXQsIGRpcmVjdCBpbnRl cmZhY2UgYXR0YWNobWVudCBkb2VzIG5vdCByZW1vdmUgYW55IGZsZXhpYmlsaXR5IGF0IGFsbCBm b3Igb3RoZXIgZnV0dXJlIGF0dGFjaG1lbnQgcG9pbnRzLiBXaGlsZSBJ4oCZbSBub3QgaW50cmlu c2ljYWxseSBvcHBvc2VkIHRvIGEgc2VwYXJhdGUgbGlzdCB3aXRoIGludGVyZmFjZSByZWZzLCBJ IGp1c3Qgd2FudCB0byB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgYXMgdGhlIG1ham9yaXR5IG9m IHN3aXRjaGVzIGFuZCByb3V0ZXJzLCBhcyBmYXIgYXMgSSBhbSBhd2FyZSwgdHlwaWNhbGx5IGF0 dGFjaCBBQ0xzIGRpcmVjdGx5IHRvIGludGVyZmFjZXMsIG1lYW5pbmcgdGhhdCB0aGUgcGF0dGVy biBpcyB3ZWxsLXVuZGVyc3Rvb2QgYnkgdHlwaWNhbCB1c2VycyBvZiB0aGlzIG1vZGVsLg0KDQpD aGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gMTAgSmFuIDIwMTgsIGF0IDAzOjA4LCBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+PiB3cm90ZToNCg0KSSBoYXZlIHB1bGxlZCBpbiB0aGUgY2hhbmdlcyBhcyB0aGV5 IHJlbGF0ZSB0bzoNCg0KLSBtb3Zpbmcg4oCcaW50ZXJmYWNlLWFjbOKAnSB1bmRlciB0aGUgY29u dGFpbmVyIOKAnGF0dGFjaG1lbnQtcG9pbnRz4oCdIG1ha2luZyBpdCBsb2NhbCB0byB0aGF0IGNv bnRhaW5lci4NCi0gcmV2ZXJ0aW5nIOKAnGFjbC10eXBl4oCdIHRvIOKAnHR5cGXigJ0NCi0gcmVt b3ZlZCDigJxpbnRlcmZhY2UtYWxsLWFnZ3JlZ2F0ZeKAnSBmZWF0dXJlDQotIHNpbXBsaWZpZWQg c291cmNlIHBvcnQgYW5kIGRlc3RpbmF0aW9uIHBvcnQgZGVmaW5pdGlvbg0KDQpUaGUgcHVsbCBy ZXF1ZXN0IGZvciB0aGUgY2hhbmdlcyBjYW4gYmUgZm91bmQgaGVyZS4NCg0KaHR0cHM6Ly9naXRo dWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMA0KDQpBZnRlciBkaXNjdXNzaW5nIHdp dGggc29tZSBvZiB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzLCBkZWNpZGVkIG5vdCB0byBpbmNs dWRlIHRoZSBjaGFuZ2UgYXMgaXQgcmVsYXRlcyB0byBhdWdtZW50aW5nIGlldGYtaW50ZXJmYWNl cy4gV2UgZGlkIG5vdCBmaW5kIHRoYXQgdGhlIGNoYW5nZSBoYWQgYSBwYXJ0aWN1bGFyIGFkdmFu dGFnZSBvdmVyIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uLiBFdmVuIGlmIHdlIGRvIG5vdCBj b21wbGV0ZWx5IHVuZGVyc3RhbmQgaG93IEFDTHMgbWlnaHQgYmUgYXR0YWNoZWQg4oCcZ2xvYmFs bHnigJ0gb3Igb24gc29tZXRoaW5nIHRoYXQgaXMgbm90IGFuIGludGVyZmFjZSwgaGF2aW5nIHRo ZSBmbGV4aWJpbGl0eSB0byBhdHRhY2ggdGhlbSB0byBvdGhlciBhdHRhY2htZW50IHBvaW50cyBp cyBpbXBvcnRhbnQuIEtlZXBpbmcgaXQgYXMgaW50ZXJmYWNlLXJlZiBnaXZlcyB1cyB0aGF0IGZs ZXhpYmlsaXR5Lg0KDQpDaGVlcnMuDQoNCk9uIERlYyAxOCwgMjAxNywgYXQgNDozMSBBTSwgRWxp b3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQoN Cg0KU28gbG9uZyBhcyBub2JvZHkgZXhwZWN0cyBhbiBpbnRlcmZhY2UgY29uc3RydWN0IGluIGEg TVVEIGZpbGUsIEknbSBoYXBweS4NCg0KT24gMTcuMTIuMTcgMTU6MzQsIEVpbmFyIE5pbHNlbi1O eWdhYXJkIChlaW5hcm5uKSB3cm90ZToNCkVsaW90LA0KDQpOb3RoaW5nIGNhbiBmb3JjZSBhbiBp bXBsZW1lbnRhdGlvbiB0byBoYXZlIHRvIGltcGxlbWVudCBlaXRoZXIgdGhlIGlldGYtaW50ZXJm YWNlcyBtb2RlbCBvciB0aGUgYXVnbWVudGF0aW9uIGluIHRoZSBpZXRmLWFjY2Vzcy1jb250cm9s LWxpc3QgbW9kZWwuIEkgYXBwcmVjaWF0ZSB5b3VyIGRlc2lyZSBmb3IgbW9kdWxhcml0eSBhbmQg Y29oZXNpdmVuZXNzLCBidXQgSSB3b3VsZCByZXNpc3QgIzEsIGJlY2F1c2UgSSBmZWVsIHRoYXQg dGhlIG1ham9yaXR5IG9mIHVzZXJzIHdpbGwgYmUgdGFyZ2V0aW5nIGludGVyZmFjZS1iYXNlZCBh dHRhY2htZW50IG92ZXIgdGltZS4gSeKAmXZlIGFkZGUgYmFjayBpbiB1c2Ugb2YgdGhlIOKAnGlu dGVyZmFjZS1hdHRhY2htZW504oCdIGZlYXR1cmUgKHdoaWNoIEkgdG9vayBvdXQgYXMgcGFydCBv ZiByZWZhY3RvcmluZyBpbnRlcmZhY2UgYXR0YWNobWVudCkuIFBhcnQgb2Y6DQoNCmh0dHBzOi8v Z2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjENCg0KVGhlIGF1Z21lbnRzIHBh cnQgb2YgdGhlIHRyZWUgbm93IGxvb2tzIGxpa2U6DQoNCiAgYXVnbWVudCAvaWY6aW50ZXJmYWNl cy9pZjppbnRlcmZhY2U6DQogICAgKy0tcncgYWNscyB7aW50ZXJmYWNlLWF0dGFjaG1lbnR9Pw0K ICAgICAgICstLXJ3IGluZ3Jlc3MNCiAgICAgICB8ICArLS1ydyBhY2wtc2V0cw0KICAgICAgIHwg ICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgIHwgICAgICAgICstLXJ3IG5hbWUgICAg ICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICB8ICAgICAgICArLS1y dyB0eXBlPyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgfCAg ICAgICAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAg ICAgICB8ICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0 cy9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFj a2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNoZWQt b2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICstLXJ3IGVncmVzcw0KICAgICAgICAg ICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAg ICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wv bmFtZQ0KICAgICAgICAgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3Mt bGlzdHMvYWNsL3R5cGUNCiAgICAgICAgICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25h bWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgICAgICAgICAgICAgICstLXJvIG5hbWUgICAg ICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgICAgICAg ICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAg ICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQoNCkNo ZWVycywNCg0KRWluYXINCg0KDQpPbiAxNyBEZWMgMjAxNywgYXQgMTE6MjksIEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCkVpbmFy LA0KDQpJIHRoaW5rIHRoaXMgY2hhbmdlIGlzIGZpbmUsIHdpdGggb25lIGV4Y2VwdGlvbi4gIEkg d291bGQgcmF0aGVyIHRoZSBhdWdtZW50IHRvIHRoZSBpbnRlcmZhY2Ugbm90IGJlIHJlcXVpcmVk IGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCBhY3R1YWxseSBoYXZlIGludGVyZmFjZXMu ICBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtYXkgYmUgdHdvIHdheXMgdG8gZ28gYWJvdXQgdGhp czoNCg0KICAxLiAgU2VwYXJhdGUgb3V0IHRoZSBhdWdtZW50IGludG8gYSBzZXBhcmF0ZSBtb2R1 bGUgKHNhbWUgZG9jIGlzIGZpbmUpOyBvcg0KICAyLiAgU29tZWhvdyAiZmVhdHVyZS1pemUiIHRo ZSBhdWdtZW50Lg0KDQpJIGRvbid0IGtub3cgaG93IHRvIGRvICgyKSBidXQgaWYgeW91IGRvLCB0 aGF0J3Mgb2theSBieSBtZS4NCg0KRWxpb3QNCg0KT24gMTYuMTIuMTcgMTQ6MTksIEVpbmFyIE5p bHNlbi1OeWdhYXJkIChlaW5hcm5uKSB3cm90ZToNCkFsbCwNCg0KQWZ0ZXIgYSBzZXJpZXMgb2Yg ZGlzY3Vzc2lvbnMgb24tIGFuZCBvZmYtbGlzdCwgSSBoYXZlIGEgY2FuZGlkYXRlIFBSIHRoYXQg aW5jbHVkZXMgdGhlIGNoYW5nZXMgaW4gdGhlIFBSIE1haGVzaCBzZW50IG91dCBwbHVzIHNvbWUg bW9yZSBlZGl0cy4gUGxlYXNlIHNlZSBjb25zb2xpZGF0ZWQgUFIgaGVyZToNCg0KaHR0cHM6Ly9n aXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMQ0KDQpNYWluIGNoYW5nZXMgaW4g YWRkaXRpb24gdG8gTWFoZXNo4oCZcyBQUiBhcmU6DQoNCg0KICAqICAgTW92ZWQgaW50ZXJmYWNl IGF0dGFjaG1lbnQgdG8gYmUgdmlhIGFuIGludGVyZmFjZSBhdWdtZW50YXRpb24uDQogICogICBS ZXN0cnVjdHVyZWQgcG9ydCBtYXRjaGVzIHNsaWdodGx5IHVuZGVyIGJvdGggSVB2NCBhbmQgSVB2 NiBjb250YWluZXJzLg0KICAqICAgUmVtb3ZlZCB1bm5lY2Vzc2FyeSBpZGVudGl0eSAnaW50ZXJm YWNlLWFjbC1hZ2dyZWdhdGXigJkuDQogICogICBSZW1vdmVkIGFjdGlvbiDigJhpY21wLW9mZuKA mSwgY2FuIGJlIGF1Z21lbnRlZCBsYXRlci4NCg0KRm9yIHJlZmVyZW5jZSwgaGVyZSBpcyB0aGUg Y3VycmVudCBZQU5HIHRyZWUgcGx1cyDigJwtLWlldGbigJ0gbG9nczoNCg0KMTM6MTIgJCBweWFu ZyAtLWlldGYgLS1saW50IC1mIHRyZWUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LnlhbmcNCmll dGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nOjUxOiBlcnJvcjogYmFkIHZhbHVlICJZWVlZLU1N LUREIiAoc2hvdWxkIGJlIGRhdGUpDQptb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdA0K ICAgICstLXJ3IGFjY2Vzcy1saXN0cw0KICAgICAgICstLXJ3IGFjbCogW25hbWVdDQogICAgICAg ICAgKy0tcncgbmFtZSAgICBzdHJpbmcNCiAgICAgICAgICArLS1ydyB0eXBlPyAgIGFjbC10eXBl DQogICAgICAgICAgKy0tcncgYWNlcw0KICAgICAgICAgICAgICstLXJ3IGFjZSogW25hbWVdDQog ICAgICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAg ICArLS1ydyBtYXRjaGVzDQogICAgICAgICAgICAgICAgfCAgKy0tcncgKGwyKT8NCiAgICAgICAg ICAgICAgICB8ICB8ICArLS06KGV0aCkNCiAgICAgICAgICAgICAgICB8ICB8ICAgICArLS1ydyBl dGgge21hdGNoLW9uLWV0aH0/DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZGVz dGluYXRpb24tbWFjLWFkZHJlc3M/ICAgICAgICB5YW5nOm1hYy1hZGRyZXNzDQogICAgICAgICAg ICAgICAgfCAgfCAgICAgICAgKy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3MtbWFzaz8gICB5 YW5nOm1hYy1hZGRyZXNzDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgc291cmNl LW1hYy1hZGRyZXNzPyAgICAgICAgICAgICB5YW5nOm1hYy1hZGRyZXNzDQogICAgICAgICAgICAg ICAgfCAgfCAgICAgICAgKy0tcncgc291cmNlLW1hYy1hZGRyZXNzLW1hc2s/ICAgICAgICB5YW5n Om1hYy1hZGRyZXNzDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZXRoZXJ0eXBl PyAgICAgICAgICAgICAgICAgICAgICBldGg6ZXRoZXJ0eXBlDQogICAgICAgICAgICAgICAgfCAg Ky0tcncgKGwzKT8NCiAgICAgICAgICAgICAgICB8ICB8ICArLS06KGlwdjQpDQogICAgICAgICAg ICAgICAgfCAgfCAgfCAgKy0tcncgaXB2NCB7bWF0Y2gtb24taXB2NH0/DQogICAgICAgICAgICAg ICAgfCAgfCAgfCAgICAgKy0tcncgZHNjcD8gICAgICAgICAgICAgICAgICAgICAgIGluZXQ6ZHNj cA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGVjbj8gICAgICAgICAgICAgICAg ICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGxlbmd0aD8g ICAgICAgICAgICAgICAgICAgICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICAr LS1ydyB0dGw/ICAgICAgICAgICAgICAgICAgICAgICAgdWludDgNCiAgICAgICAgICAgICAgICB8 ICB8ICB8ICAgICArLS1ydyBwcm90b2NvbD8gICAgICAgICAgICAgICAgICAgdWludDgNCiAgICAg ICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0 b3IpPw0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICstLToocmFuZ2UpDQogICAgICAg ICAgICAgICAgfCAgfCAgfCAgICAgfCAgfCAgKy0tcncgc291cmNlLXBvcnQtbG93ZXIgICAgICAg ICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICB8ICAr LS1ydyBzb3VyY2UtcG9ydC11cHBlciAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAg ICAgICAgICAgIHwgIHwgIHwgICAgIHwgICstLToob3BlcmF0b3IpDQogICAgICAgICAgICAgICAg fCAgfCAgfCAgICAgfCAgICAgKy0tcncgc291cmNlLW9wZXJhdG9yICAgICAgICAgICAgIG9wZXJh dG9yDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgKy0tcncgc291cmNlLXBvcnQg ICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8 ICAgICArLS1ydyAoZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/DQogICAgICAg ICAgICAgICAgfCAgfCAgfCAgICAgfCAgKy0tOihyYW5nZSkNCiAgICAgICAgICAgICAgICB8ICB8 ICB8ICAgICB8ICB8ICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyICAgICAgaW5ldDpwb3J0 LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IGRlc3RpbmF0 aW9uLXBvcnQtdXBwZXIgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAg fCAgfCAgICAgfCAgKy0tOihvcGVyYXRvcikNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8 ICAgICArLS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciAgICAgICAgb3BlcmF0b3INCiAgICAgICAg ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0ICAgICAgICAg ICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGlo bD8gICAgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwg ICAgICstLXJ3IGZsYWdzPyAgICAgICAgICAgICAgICAgICAgICBiaXRzDQogICAgICAgICAgICAg ICAgfCAgfCAgfCAgICAgKy0tcncgb2Zmc2V0PyAgICAgICAgICAgICAgICAgICAgIHVpbnQxNg0K ICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGlkZW50aWZpY2F0aW9uPyAgICAgICAg ICAgICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBkZXN0aW5hdGlv bi1pcHY0LW5ldHdvcms/ICAgaW5ldDppcHY0LXByZWZpeA0KICAgICAgICAgICAgICAgIHwgIHwg IHwgICAgICstLXJ3IHNvdXJjZS1pcHY0LW5ldHdvcms/ICAgICAgICBpbmV0OmlwdjQtcHJlZml4 DQogICAgICAgICAgICAgICAgfCAgfCAgKy0tOihpcHY2KQ0KICAgICAgICAgICAgICAgIHwgIHwg ICAgICstLXJ3IGlwdjYge21hdGNoLW9uLWlwdjZ9Pw0KICAgICAgICAgICAgICAgIHwgIHwgICAg ICAgICstLXJ3IGRzY3A/ICAgICAgICAgICAgICAgICAgICAgICBpbmV0OmRzY3ANCiAgICAgICAg ICAgICAgICB8ICB8ICAgICAgICArLS1ydyBlY24/ICAgICAgICAgICAgICAgICAgICAgICAgdWlu dDgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBsZW5ndGg/ICAgICAgICAgICAg ICAgICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgdHRsPyAg ICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAg Ky0tcncgcHJvdG9jb2w/ICAgICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAg fCAgfCAgICAgICAgKy0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8NCiAgICAg ICAgICAgICAgICB8ICB8ICAgICAgICB8ICArLS06KHJhbmdlKQ0KICAgICAgICAgICAgICAgIHwg IHwgICAgICAgIHwgIHwgICstLXJ3IHNvdXJjZS1wb3J0LWxvd2VyICAgICAgICAgICBpbmV0OnBv cnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgKy0tcncgc291cmNl LXBvcnQtdXBwZXIgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8 ICB8ICAgICAgICB8ICArLS06KG9wZXJhdG9yKQ0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAg IHwgICAgICstLXJ3IHNvdXJjZS1vcGVyYXRvciAgICAgICAgICAgICBvcGVyYXRvcg0KICAgICAg ICAgICAgICAgIHwgIHwgICAgICAgIHwgICAgICstLXJ3IHNvdXJjZS1wb3J0ICAgICAgICAgICAg ICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncg KGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPw0KICAgICAgICAgICAgICAgIHwg IHwgICAgICAgIHwgICstLToocmFuZ2UpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAg fCAgKy0tcncgZGVzdGluYXRpb24tcG9ydC1sb3dlciAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICB8ICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LXVw cGVyICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwg ICstLToob3BlcmF0b3IpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICAgKy0tcncg ZGVzdGluYXRpb24tb3BlcmF0b3IgICAgICAgIG9wZXJhdG9yDQogICAgICAgICAgICAgICAgfCAg fCAgICAgICAgfCAgICAgKy0tcncgZGVzdGluYXRpb24tcG9ydCAgICAgICAgICAgIGluZXQ6cG9y dC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBkZXN0aW5hdGlvbi1p cHY2LW5ldHdvcms/ICAgaW5ldDppcHY2LXByZWZpeA0KICAgICAgICAgICAgICAgIHwgIHwgICAg ICAgICstLXJ3IHNvdXJjZS1pcHY2LW5ldHdvcms/ICAgICAgICBpbmV0OmlwdjYtcHJlZml4DQog ICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZmxvdy1sYWJlbD8gICAgICAgICAgICAg ICAgIGluZXQ6aXB2Ni1mbG93LWxhYmVsDQogICAgICAgICAgICAgICAgfCAgKy0tcncgKGw0KT8N CiAgICAgICAgICAgICAgICB8ICB8ICArLS06KHRjcCkNCiAgICAgICAgICAgICAgICB8ICB8ICB8 ICArLS1ydyB0Y3Age21hdGNoLW9uLXRjcH0/DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAg Ky0tcncgc2VxdWVuY2UtbnVtYmVyPyAgICAgICAgICB1aW50MzINCiAgICAgICAgICAgICAgICB8 ICB8ICB8ICAgICArLS1ydyBhY2tub3dsZWRnZW1lbnQtbnVtYmVyPyAgIHVpbnQzMg0KICAgICAg ICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGRhdGEtb2Zmc2V0PyAgICAgICAgICAgICAgdWlu dDgNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyByZXNlcnZlZD8gICAgICAgICAg ICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgZmxhZ3M/ICAg ICAgICAgICAgICAgICAgICBiaXRzDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncg d2luZG93LXNpemU/ICAgICAgICAgICAgICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICB8 ICAgICArLS1ydyB1cmdlbnQtcG9pbnRlcj8gICAgICAgICAgIHVpbnQxNg0KICAgICAgICAgICAg ICAgIHwgIHwgIHwgICAgICstLXJ3IG9wdGlvbnM/ICAgICAgICAgICAgICAgICAgdWludDMyDQog ICAgICAgICAgICAgICAgfCAgfCAgKy0tOih1ZHApDQogICAgICAgICAgICAgICAgfCAgfCAgfCAg Ky0tcncgdWRwIHttYXRjaC1vbi11ZHB9Pw0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICst LXJ3IGxlbmd0aD8gICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICArLS06KGljbXApDQog ICAgICAgICAgICAgICAgfCAgfCAgICAgKy0tcncgaWNtcCB7bWF0Y2gtb24taWNtcH0/DQogICAg ICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICAgdWludDgNCiAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBjb2RlPyAgICAgICAgICAgICB1aW50OA0K ICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IHJlc3Qtb2YtaGVhZGVyPyAgIHVpbnQz Mg0KICAgICAgICAgICAgICAgIHwgICstLXJ3IGVncmVzcy1pbnRlcmZhY2U/ICAgIGlmOmludGVy ZmFjZS1yZWYNCiAgICAgICAgICAgICAgICB8ICArLS1ydyBpbmdyZXNzLWludGVyZmFjZT8gICBp ZjppbnRlcmZhY2UtcmVmDQogICAgICAgICAgICAgICAgKy0tcncgYWN0aW9ucw0KICAgICAgICAg ICAgICAgIHwgICstLXJ3IGZvcndhcmRpbmcgICAgaWRlbnRpdHlyZWYNCiAgICAgICAgICAgICAg ICB8ICArLS1ydyBsb2dnaW5nPyAgICAgIGlkZW50aXR5cmVmDQogICAgICAgICAgICAgICAgKy0t cm8gc3RhdGlzdGljcyB7YWNsLWFnZ3JlZ2F0ZS1zdGF0c30/DQogICAgICAgICAgICAgICAgICAg Ky0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgICAgICAgICAg ICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQoNCiAgYXVnbWVudCAv aWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6DQogICAgKy0tcncgYWNscw0KICAgICAgICstLXJ3 IGluZ3Jlc3MNCiAgICAgICB8ICArLS1ydyBhY2wtc2V0cw0KICAgICAgIHwgICAgICstLXJ3IGFj bC1zZXQqIFtuYW1lXQ0KICAgICAgIHwgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+ IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICB8ICAgICAgICArLS1ydyB0eXBlPyAgICAg ICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgfCAgICAgICAgKy0tcm8g YWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICB8ICAgICAg ICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9h Y2UvbmFtZQ0KICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5n OmNvdW50ZXI2NA0KICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5 YW5nOmNvdW50ZXI2NA0KICAgICAgICstLXJ3IGVncmVzcw0KICAgICAgICAgICstLXJ3IGFjbC1z ZXRzDQogICAgICAgICAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgICAg Ky0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAg ICAgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5 cGUNCiAgICAgICAgICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZh Y2Utc3RhdHN9Pw0KICAgICAgICAgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAt PiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgICAgICAgICAgICAgICAgKy0t cm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgICAgICAgICAgICAg Ky0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQoNCkNvbW1lbnRzIHdlbGNv bWUhDQoNCkNoZWVycywNCg0KRWluYXINCg0KDQoNCk9uIDE0IERlYyAyMDE3LCBhdCAxODo1MCwg RWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86 ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToNCg0KDQoNCk9uIDE0IERlYyAyMDE3LCBhdCAwODoy MSwgU29uYWwgQWdhcndhbCA8c2FnYXJ3YWwxMkBnbWFpbC5jb208bWFpbHRvOnNhZ2Fyd2FsMTJA Z21haWwuY29tPj4gd3JvdGU6DQoNCkhpIEVpbmFyLA0KDQpZb3UgaGFkIDMgcXVlc3Rpb25zIGZv ciBtZSBvbiBhbGwgdGhlIHNldmVyYWwgZS1tYWlsIHRocmVhZHMuDQoxLiBHbG9iYWwgYXR0YWNo bWVudCBwb2ludA0KMi4gaWNtcC1vZmYNCjMuIGFjbC1hZ2dyZWdhdGUtaW50ZXJmYWNlIHN0YXRz Lg0KDQpGb3IgKDEpLCBteSBmaXJzdCBwcmVmZXJlbmNlIGlzIHRvIGhhdmUgdGhlIG1vZGVsIGRl ZmluZSBhdHRhY2htZW50IHBvaW50IGZvciBpbnRlcmZhY2VzIG9ubHkuDQoNCmVpbmFybm4+IEkg aGF2ZSBzb21lIGRpZmZzLCBsYXllcmVkIG9uIHRvcCBvZiBNYWhlc2jigJlzIFBSIHRvIG5ldG1v ZC13Zy9hY2wtbW9kZWwgdGhhdCBkbyB0aGlzLiBOZWFybHkgbGlrZSB0aGUgYXVnbWVudGF0aW9u IEkgaGF2ZSBiZWxvdy4gRmVlbCBmcmVlIHRvIHRha2UgYSBsb29rIGF0Og0KDQpodHRwczovL2dp dGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9kZWwvcHVsbC8zDQoNCkhvd2V2ZXIsIEtyaXN0 aWFuIHdhbnRzIHRoZSBnbG9iYWwgYXR0YWNobWVudCBwb2ludCBhcyB3ZWxsIHNvIHRoYXQgaGUg Y2FuIGFkZCB0aGUgQUNMIHRvIHRoZSBsaW51eCB0YWJsZXMuDQoNCmVpbmFybm4+IEkgdGhpbmsg S3Jpc3RpYW4gZG9lc27igJl0IGZlZWwgYSBnbG9iYWwgYXR0YWNobWVudCBwb2ludCBuZWVkcyB0 byBiZSBpbiB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQgaGUgY2FuIGNvbmZpcm0uDQoNCklmIGFu IEFDTCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9lcyB0aGlzIG1lYW4gaXQgaXMgcGVyIGRpcmVj dGlvbiBvciBkb2VzIGl0IG1lYW4gaXQgaXMgYWNyb3NzIGRpcmVjdGlvbnM/DQoNCmVpbmFybm4+ IEkgZG9u4oCZdCBrbm93IHJpZ2h0IG5vdyA6LSkNCg0KVGhpcyBnbG9iYWwgQUNMIG1heSBub3Qg YmUgYXBwbGljYWJsZSB0byBhbnkgb2YgQ2lzY28ncyBzZXJ2aWNlIHByb3ZpZGVyIHJvdXRlcnMg YXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFjdHVhbGx5IHJlcGxpY2F0aW5nIHRoZSBBQ0wg dG8gYWxsIGxpbmUgY2FyZHMgYW5kIGF0dGFjaGluZyBpdCBpbiBpbmdyZXNzIGFuZCBlZ3Jlc3Mg ZGlyZWN0aW9ucyBhY3Jvc3MgYWxsIGludGVyZmFjZXMuDQoNCmVpbmFybm4+IFBlciBvdGhlciBl bWFpbHMsIEkgZG9u4oCZdCB0aGluayB3ZSB1bmRlcnN0YW5kIHRoaXMgZW5vdWdoIHlldCB0byBz cGVjaWZ5IGl0LCBzbyBJIHN1Z2dlc3Qgd2UganVzdCBsZWF2ZSBpdCBvdXQgZm9yIG5vdy4gTm90 aGluZyBpbiB0aGUgbW9kZWwgcHJldmVudHMgYSDigJxnbG9iYWwgYXR0YWNobWVudCBwb2ludOKA nSBiZWluZyBhZGRlZCBsYXRlciBvbmNlIHdlIHVuZGVyc3RhbmQgd2hhdCBpdCByZWFsbHkgbWVh bnMuDQoNCkZvciAoMiksIEkgYW0gb2sgd2l0aCByZW1vdmluZyBpY21wLW9mZi4NCg0KZWluYXJu bj4gRG9uZSBpbiBteSBQUiBhYm92ZS4NCg0KRm9yICgzKSwgdGhpcyB3b3VsZCBoYXZlIHRvIGJl IGEgY29tYmluYXRpb24gb2YgQUNMIHN0YXRzIGFjcm9zcyBhbGwgaW50ZXJmYWNlcyBmb3IgYWxs IEFDTCdzLiBTb21ldGhpbmcgbGlrZSB0aGlzIGlzIHBvc3NpYmxlIG9uIGFuIFhSIGJveCB3aGVy ZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3NvY2lhdGVkIHdpdGggaXQuIExldCdzIGNoYXQg YWJvdXQgdGhpcyBvZmZsaW5lIHRvbW9ycm93Lg0KDQplaW5hcm5uPiBJ4oCZbGwgcGluZyB5b3Ug dG8gY2xhcmlmeSwgYW5kIHdlIGNhbiBicmluZyBhbnkgY29uY2x1c2lvbiBiYWNrIHRvIHRoZSBs aXN0Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KDQpTb25hbC4NCg0KDQpPbiBXZWQsIERlYyAx MywgMjAxNyBhdCAxMjoxMCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBn bWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQpXZSB3YW50 IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwg YW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhl IGNob2ljZXMgKHRoZSBvdGhlciBiZWluZyB0aGUgaW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlz IGF1Z21lbnQgbG9vayBsaWtlLiBOb3RlLCBhcyBmYXIgYXMgSSBrbm93LCB5b3UgY2Fubm90IGF1 Z21lbnQgaW5zaWRlIGEgY2hvaWNlIG5vZGUuDQoNCk9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBB TSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWls dG86ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToNCg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFu IGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOg0KDQogIGF1Z21lbnQgL2lmOmludGVyZmFj ZXMvaWY6aW50ZXJmYWNlOg0KICAgICstLXJ3IGluZ3Jlc3MtYWNscw0KICAgIHwgICstLXJ3IGFj bC1zZXRzDQogICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgfCAgICAgICAgKy0t cncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgIHwgICAg ICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAg ICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9 Pw0KICAgIHwgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxp c3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNr ZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3Rl dHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgKy0tcncgZWdyZXNzLWFjbHMNCiAgICAgICArLS1y dyBhY2wtc2V0cw0KICAgICAgICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAg ICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAg ICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBl DQogICAgICAgICAgICAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0 YXRzfT8NCiAgICAgICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vz cy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQt cGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQt b2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KDQpDb3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCd IGNvbnRhaW5lciBhYm92ZSBib3RoIHRoZXNlICYgcmVuYW1lIOKAnGluZ3Jlc3MtYWNscyIgdG8g 4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50 YXRpb24gaWYgcHJlZmVycmVkLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gNiBEZWMgMjAx NywgYXQgMTk6NDMsIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2Nv LmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5k YW5pIHdyb3RlOg0KSG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBv aW50LCBjdXJyZW50bHkgYW4NCidpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9m IHRoZSBpZjppbnRlcmZhY2VzL2ludGVyZmFjZSwNCmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICBj b250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZlIGFuDQpjb250YWlu ZXIgZm9yICJhdHRhY2htZW50IHBvaW50cyIgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5 IG9mDQphdHRhY2hpbmcgYW4gQUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFs bHnigJ0uDQoNCg0KS2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBk b2Vzbid0IGF0dGFjaCB0byBhbg0KaW50ZXJmYWNlIGF0IGFsbC4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBs aXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpu ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxp c3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K --_000_E2A33B749D0B49648280FF931CA1D330ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <40DAC99086A0184EB1B005A9140FFF54@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KTWFoZXNoLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VHdvIHRoaW5nczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZpcnN0LCBJIHNlZSB0aGF0IHlvdSBo YXZlIHN0aWxsIGxlZnQgaW4gdGhlIOKAnGljbXAtb2Zm4oCdIGFjdGlvbi4gVGhpcyB3YXMgc29t ZXRoaW5nIGJvdGggS3Jpc3RpYW4gYW5kIEkgcmVjb21tZW5kZWQgcmVtb3ZpbmcsIGFuZCBJIGFs c28gZGlzY3Vzc2VkIHRoaXMgd2l0aCBTb25hbCBhdCB0aGUgZW5kIG9mIGxhc3QgeWVhciBhbmQg c2hlIGFncmVlZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJseSBiZSByZW1vdmVkIHNpbmNlIGl0DQog c2VlbXMgYXQgdGhpcyBwb2ludCAoYWJzZW50IGFueW9uZSBwb2ludGluZyBvdXQgb3RoZXIgaW1w bGVtZW50YXRpb25zKSB0byBiZSBhIENpc2NvIElPUy1YUi1zcGVjaWZpYyBmZWF0dXJlIHRoYXQg c2hvdWxkIHByb2JhYmx5IGJlIGRlYWx0IHdpdGggdmlhIGEgdmVuZG9yIGF1Z21lbnRhdGlvbiBp bml0aWFsbHkuIENhbiB3ZSByZW1vdmUgdGhpcz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNlY29uZCwgSSB3b3VsZCByZWFsbHkgbGlr ZSB0aGUgY29udHJpYnV0b3JzIHdobyB3aXNoIHRvIG1haW50YWluIHRoZSBzZXBhcmF0ZSBBQ0wg YXR0YWNobWVudCBpbnRlcmZhY2UgbGlzdCB3aXRoIGludGVyZmFjZSByZWZlcmVuY2VzIHRvIGxh eSBvdXQgaG93IGRpcmVjdCBpbnRlcmZhY2UgYXR0YWNobWVudCBwcmV2ZW50cyBBQ0xzIGJlaW5n IHVzZWQgd2l0aCBvdGhlciBhdHRhY2htZW50IHBvaW50cy4gQXMgSSBwb2ludGVkDQogb3V0LCBk aXJlY3QgaW50ZXJmYWNlIGF0dGFjaG1lbnQgZG9lcyBub3QgcmVtb3ZlIGFueSBmbGV4aWJpbGl0 eSBhdCBhbGwgZm9yIG90aGVyIGZ1dHVyZSBhdHRhY2htZW50IHBvaW50cy4gV2hpbGUgSeKAmW0g bm90IGludHJpbnNpY2FsbHkgb3Bwb3NlZCB0byBhIHNlcGFyYXRlIGxpc3Qgd2l0aCBpbnRlcmZh Y2UgcmVmcywgSSBqdXN0IHdhbnQgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGFzIHRoZSBt YWpvcml0eSBvZiBzd2l0Y2hlcyBhbmQNCiByb3V0ZXJzLCBhcyBmYXIgYXMgSSBhbSBhd2FyZSwg dHlwaWNhbGx5IGF0dGFjaCBBQ0xzIGRpcmVjdGx5IHRvIGludGVyZmFjZXMsIG1lYW5pbmcgdGhh dCB0aGUgcGF0dGVybiBpcyB3ZWxsLXVuZGVyc3Rvb2QgYnkgdHlwaWNhbCB1c2VycyBvZiB0aGlz IG1vZGVsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTAgSmFu IDIwMTgsIGF0IDAzOjA4LCBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIGNsYXNzPSIiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KSSBoYXZlIHB1bGxlZCBpbiB0aGUgY2hhbmdlcyBhcyB0aGV5IHJlbGF0ZSB0 bzoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0g bW92aW5nIOKAnGludGVyZmFjZS1hY2zigJ0gdW5kZXIgdGhlIGNvbnRhaW5lciDigJxhdHRhY2ht ZW50LXBvaW50c+KAnSBtYWtpbmcgaXQgbG9jYWwgdG8gdGhhdCBjb250YWluZXIuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi0gcmV2ZXJ0aW5nIOKAnGFjbC10eXBl4oCdIHRvIOKAnHR5cGXigJ08L2Rp dj4NCjxkaXYgY2xhc3M9IiI+LSByZW1vdmVkIOKAnGludGVyZmFjZS1hbGwtYWdncmVnYXRl4oCd IGZlYXR1cmU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBzaW1wbGlmaWVkIHNvdXJjZSBwb3J0IGFu ZCBkZXN0aW5hdGlvbiBwb3J0IGRlZmluaXRpb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBwdWxsIHJlcXVlc3QgZm9yIHRoZSBj aGFuZ2VzIGNhbiBiZSBmb3VuZCBoZXJlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25l dG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMCIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL25l dG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFmdGVyIGRpc2N1c3Npbmcgd2l0aCBzb21l IG9mIHRoZSBvcmlnaW5hbCBjb250cmlidXRvcnMsIGRlY2lkZWQgbm90IHRvIGluY2x1ZGUgdGhl IGNoYW5nZSBhcyBpdCByZWxhdGVzIHRvIGF1Z21lbnRpbmcgaWV0Zi1pbnRlcmZhY2VzLiBXZSBk aWQgbm90IGZpbmQgdGhhdCB0aGUgY2hhbmdlIGhhZCBhIHBhcnRpY3VsYXIgYWR2YW50YWdlIG92 ZXIgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24uIEV2ZW4gaWYgd2UgZG8gbm90DQogY29tcGxl dGVseSB1bmRlcnN0YW5kIGhvdyBBQ0xzIG1pZ2h0IGJlIGF0dGFjaGVkIOKAnGdsb2JhbGx54oCd IG9yIG9uIHNvbWV0aGluZyB0aGF0IGlzIG5vdCBhbiBpbnRlcmZhY2UsIGhhdmluZyB0aGUgZmxl eGliaWxpdHkgdG8gYXR0YWNoIHRoZW0gdG8gb3RoZXIgYXR0YWNobWVudCBwb2ludHMgaXMgaW1w b3J0YW50LiBLZWVwaW5nIGl0IGFzIGludGVyZmFjZS1yZWYgZ2l2ZXMgdXMgdGhhdCBmbGV4aWJp bGl0eS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkNoZWVycy48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMg MTgsIDIwMTcsIGF0IDQ6MzEgQU0sIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFy QGNpc2NvLmNvbSIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4NCjxwIGNsYXNz PSIiPlNvIGxvbmcgYXMgbm9ib2R5IGV4cGVjdHMgYW4gaW50ZXJmYWNlIGNvbnN0cnVjdCBpbiBh IE1VRCBmaWxlLCBJJ20gaGFwcHkuPGJyIGNsYXNzPSIiPg0KPC9wPg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNy4xMi4xNyAxNTozNCwgRWluYXIgTmls c2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjUyOTlFMzMzLUYxRjMtNDc4MS1CNDY3LTBCRkIy NzFBNDkxNUBjaXNjby5jb20iIGNsYXNzPSIiPg0KRWxpb3QsDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ob3RoaW5nIGNhbiBmb3JjZSBhbiBpbXBs ZW1lbnRhdGlvbiB0byBoYXZlIHRvIGltcGxlbWVudCBlaXRoZXIgdGhlJm5ic3A7aWV0Zi1pbnRl cmZhY2VzIG1vZGVsIG9yIHRoZSBhdWdtZW50YXRpb24gaW4gdGhlIGlldGYtYWNjZXNzLWNvbnRy b2wtbGlzdCBtb2RlbC4gSSBhcHByZWNpYXRlIHlvdXIgZGVzaXJlIGZvciBtb2R1bGFyaXR5IGFu ZCBjb2hlc2l2ZW5lc3MsIGJ1dCBJIHdvdWxkIHJlc2lzdCAjMSwgYmVjYXVzZSBJIGZlZWwNCiB0 aGF0IHRoZSBtYWpvcml0eSBvZiB1c2VycyB3aWxsIGJlIHRhcmdldGluZyBpbnRlcmZhY2UtYmFz ZWQgYXR0YWNobWVudCBvdmVyIHRpbWUuIEnigJl2ZSBhZGRlIGJhY2sgaW4gdXNlIG9mIHRoZSDi gJxpbnRlcmZhY2UtYXR0YWNobWVudOKAnSBmZWF0dXJlICh3aGljaCBJIHRvb2sgb3V0IGFzIHBh cnQgb2YgcmVmYWN0b3JpbmcgaW50ZXJmYWNlIGF0dGFjaG1lbnQpLiBQYXJ0IG9mOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzoNCiAgICAgICAgMHB4OyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRt b2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjEiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ aHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMTwvYT48L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlRoZSBhdWdtZW50cyBwYXJ0IG9mIHRoZSB0cmVlIG5vdyBsb29rcyBsaWtlOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyBhdWdt ZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZTo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3 IGFjbHMgPGIgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgY29sb3I9IiNmZjI2MDAiPntpbnRlcmZh Y2UtYXR0YWNobWVudH08L2ZvbnQ+PC9iPj88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyBpbmdyZXNzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7 LS1ydyBhY2wtc2V0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIg ZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wv bmFtZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291 cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvdHlwZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlLXN0YXRpc3Rp Y3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbmFtZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vz cy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tl dHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0 cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgZWdyZXNzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyBhY2wtc2V0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxp c3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBhY2Ut c3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7 LS1ybyBtYXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE3 IERlYyAyMDE3LCBhdCAxMToyOSwgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJA Y2lzY28uY29tIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmxlYXJAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZG RiIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iIj5FaW5hciw8L3A+DQo8cCBjbGFzcz0iIj5JIHRoaW5r IHRoaXMgY2hhbmdlIGlzIGZpbmUsIHdpdGggb25lIGV4Y2VwdGlvbi4mbmJzcDsgSSB3b3VsZCBy YXRoZXIgdGhlIGF1Z21lbnQgdG8gdGhlIGludGVyZmFjZSBub3QgYmUgcmVxdWlyZWQgZm9yIGlt cGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IGFjdHVhbGx5IGhhdmUgaW50ZXJmYWNlcy4mbmJzcDsg SSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgbWF5IGJlIHR3byB3YXlzIHRvIGdvIGFib3V0IHRoaXM6 PC9wPg0KPG9sIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPlNlcGFyYXRlIG91dCB0aGUgYXVnbWVu dCBpbnRvIGEgc2VwYXJhdGUgbW9kdWxlIChzYW1lIGRvYyBpcyBmaW5lKTsgb3INCjwvbGk+PGxp IGNsYXNzPSIiPlNvbWVob3cgJnF1b3Q7ZmVhdHVyZS1pemUmcXVvdDsgdGhlIGF1Z21lbnQuIDwv bGk+PC9vbD4NCjxwIGNsYXNzPSIiPkkgZG9uJ3Qga25vdyBob3cgdG8gZG8gKDIpIGJ1dCBpZiB5 b3UgZG8sIHRoYXQncyBva2F5IGJ5IG1lLjwvcD4NCjxwIGNsYXNzPSIiPkVsaW90PGJyIGNsYXNz PSIiPg0KPC9wPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5P biAxNi4xMi4xNyAxNDoxOSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjBG NDNDREU5LTIxRDItNEVENy1BRTdDLTlBMkI5Rjg1NDEwMUBjaXNjby5jb20iIGNsYXNzPSIiPg0K QWxsLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QWZ0ZXIgYSBzZXJpZXMgb2YgZGlzY3Vzc2lvbnMgb24tIGFuZCBvZmYtbGlzdCwgSSBoYXZlIGEg Y2FuZGlkYXRlIFBSIHRoYXQgaW5jbHVkZXMgdGhlIGNoYW5nZXMgaW4gdGhlIFBSIE1haGVzaCBz ZW50IG91dCBwbHVzIHNvbWUgbW9yZSBlZGl0cy4gUGxlYXNlIHNlZSBjb25zb2xpZGF0ZWQgUFIg aGVyZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7DQogICAgICAgICAg ICAgICAgICAgIHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIxIiBjbGFzcz0i IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNs LW1vZGVsL3B1bGwvMjE8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TWFpbiBj aGFuZ2VzIGluIGFkZGl0aW9uIHRvIE1haGVzaOKAmXMgUFIgYXJlOjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1h aWxPdXRsaW5lIj4NCjxsaSBjbGFzcz0iIj5Nb3ZlZCBpbnRlcmZhY2UgYXR0YWNobWVudCB0byBi ZSB2aWEgYW4gaW50ZXJmYWNlIGF1Z21lbnRhdGlvbi4gPC9saT48bGkgY2xhc3M9IiI+UmVzdHJ1 Y3R1cmVkIHBvcnQgbWF0Y2hlcyBzbGlnaHRseSB1bmRlciBib3RoIElQdjQgYW5kIElQdjYgY29u dGFpbmVycy4NCjwvbGk+PGxpIGNsYXNzPSIiPlJlbW92ZWQgdW5uZWNlc3NhcnkgaWRlbnRpdHkg J2ludGVyZmFjZS1hY2wtYWdncmVnYXRl4oCZLiA8L2xpPjxsaSBjbGFzcz0iIj5SZW1vdmVkIGFj dGlvbiDigJhpY21wLW9mZuKAmSwgY2FuIGJlIGF1Z21lbnRlZCBsYXRlci4gPC9saT48L3VsPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Gb3IgcmVmZXJlbmNlLCBoZXJlIGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKAnC0t aWV0ZuKAnSBsb2dzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPjEzOjEyICQgcHlhbmcgLS1pZXRmIC0tbGludCAtZiB0cmVlIGlldGYtYWNjZXNzLWNvbnRy b2wtbGlzdC55YW5nPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj5pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzo1MTogZXJyb3I6IGJh ZCB2YWx1ZSAmcXVvdDtZWVlZLU1NLUREJnF1b3Q7IChzaG91bGQgYmUgZGF0ZSk8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPm1vZHVsZTog aWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3Mt bGlzdHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wqIFtuYW1lXTwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsg Jm5ic3A7c3RyaW5nPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyB0eXBlPyAmbmJzcDsgYWNsLXR5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzstLXJ3IGFjZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ydyBhY2UqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3RyaW5nPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBtYXRjaGVzPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 JiM0MzstLXJ3IChsMik/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihldGgpPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBldGgge21hdGNoLW9uLWV0aH0/PC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3M/ ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3lhbmc6bWFjLWFkZHJlc3M8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVz cy1tYXNrPyAmbmJzcDsgeWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcz8gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNr PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt5YW5nOm1hYy1hZGRyZXNzPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZXRoZXJ0eXBlPyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZXRoOmV0aGVydHlwZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyAobDMpPzwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7JiM0MzstLTooaXB2NCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGlw djQge21hdGNoLW9uLWlwdjR9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBkc2NwPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6ZHNjcDwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7 fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBlY24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdWludDE2PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0Mzst LXJ3IHR0bD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7 fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9w ZXJhdG9yKT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06 KHJhbmdlKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsm IzQzOy0tcncgc291cmNlLXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwOyYjNDM7LS1ydyBzb3VyY2UtcG9ydC11cHBlciAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgc291cmNlLW9wZXJhdG9yICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9yPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2Ut cG9ydCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGluZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgKGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPzwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1w b3J0LWxvd2VyICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRp b24tcG9ydC11cHBlciAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVz dGluYXRpb24tb3BlcmF0b3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0b3I8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRl c3RpbmF0aW9uLXBvcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtp bmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3 IGlobD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBmbGFncz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgb2Zmc2V0PyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgdWludDE2PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGlkZW50 aWZpY2F0aW9uPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50 MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzdGluYXRpb24t aXB2NC1uZXR3b3JrPyAmbmJzcDsgaW5ldDppcHY0LXByZWZpeDwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2UtaXB2NC1uZXR3b3JrPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtpbmV0OmlwdjQtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihp cHY2KTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291 cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaXB2NiB7bWF0Y2gtb24taXB2 Nn0/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZHNjcD8g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OmRzY3A8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ydyBlY24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBsZW5ndGg/ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyB0dGw/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyAoc291cmNlLXBv cnQtcmFuZ2Utb3Itb3BlcmF0b3IpPzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fCAmbmJzcDsmIzQzOy0tOihyYW5nZSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgc291cmNlLXBvcnQtbG93ZXIgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IHNvdXJj ZS1wb3J0LXVwcGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0 LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQz Oy0tOihvcGVyYXRvcik8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgc291cmNlLW9wZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9yPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHNvdXJjZS1wb3J0ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0 LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IChk ZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGRlc3RpbmF0aW9u LXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQtbnVtYmVyPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGRl c3RpbmF0aW9uLXBvcnQtdXBwZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQtbnVtYmVy PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVy Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KG9w ZXJhdG9yKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICYjNDM7LS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtvcGVyYXRvcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIg ZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBkZXN0aW5hdGlvbi1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gJm5i c3A7IGluZXQ6aXB2Ni1wcmVmaXg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyBzb3VyY2UtaXB2Ni1uZXR3b3JrPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbmV0OmlwdjYtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm IzQzOy0tcncgZmxvdy1sYWJlbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OmlwdjYtZmxvdy1sYWJlbDwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1y dyAobDQpPzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7JiM0MzstLToodGNwKTwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsmIzQzOy0tcncgdGNwIHttYXRjaC1vbi10Y3B9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBzZXF1ZW5jZS1udW1iZXI/ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt1aW50MzI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgYWNrbm93bGVkZ2VtZW50LW51bWJlcj8gJm5ic3A7IHVpbnQzMjwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkYXRhLW9mZnNldD8gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgcmVzZXJ2ZWQ/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZmxhZ3M/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgd2luZG93LXNpemU/ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VpbnQxNjwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyB1cmdlbnQtcG9pbnRlcj8gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmIzQzOy0tcncgb3B0aW9ucz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50MzI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7 LS06KHVkcCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IHVkcCB7bWF0Y2gtb24t dWRwfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAm bmJzcDsgdWludDE2PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihpY21wKTwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgaWNtcCB7bWF0Y2gtb24taWNtcH0/PC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ydyBjb2RlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IHJlc3Qtb2YtaGVhZGVyPyAmbmJzcDsgdWludDMyPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGVn cmVzcy1pbnRlcmZhY2U/ICZuYnNwOyAmbmJzcDtpZjppbnRlcmZhY2UtcmVmPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0 MzstLXJ3IGluZ3Jlc3MtaW50ZXJmYWNlPyAmbmJzcDsgaWY6aW50ZXJmYWNlLXJlZjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cncgYWN0aW9uczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyBmb3J3YXJkaW5nICZuYnNwOyAmbmJzcDtpZGVu dGl0eXJlZjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyBsb2dnaW5nPyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lk ZW50aXR5cmVmPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ybyBzdGF0aXN0aWNzIHthY2wtYWdncmVnYXRlLXN0YXRzfT88L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ybyBtYXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2 NDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFu Zzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZh Y2U9IkNvdXJpZXIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFj ZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsczwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGluZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg bmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0 OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0 MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0 MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBlZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNs L3R5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/ PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVy Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFt ZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291 bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJD b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJz cDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q29tbWVudHMgd2VsY29tZSE8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE0IERlYyAyMDE3LCBhdCAxODo1MCwgRWluYXIgTmls c2VuLU55Z2FhcmQgKGVpbmFybm4pICZsdDs8YSBocmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5j b20iIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZWluYXJubkBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1i cmVhazoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTQgRGVjIDIw MTcsIGF0IDA4OjIxLCBTb25hbCBBZ2Fyd2FsICZsdDs8YSBocmVmPSJtYWlsdG86c2FnYXJ3YWwx MkBnbWFpbC5jb20iIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+c2FnYXJ3YWwxMkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkg RWluYXIsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Zb3UgaGFkIDMgcXVlc3Rpb25zIGZvciBtZSBvbiBhbGwgdGhlIHNldmVyYWwgZS1tYWlsIHRo cmVhZHMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuIEdsb2JhbCBhdHRhY2htZW50IHBv aW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIGljbXAtb2ZmPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjMuIGFjbC1hZ2dyZWdhdGUtaW50ZXJmYWNlIHN0YXRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Rm9yICgxKSwgbXkgZmlyc3QgcHJl ZmVyZW5jZSBpcyB0byBoYXZlIHRoZSBtb2RlbCBkZWZpbmUgYXR0YWNobWVudCBwb2ludCBmb3Ig aW50ZXJmYWNlcyBvbmx5LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4m Z3Q7IEkgaGF2ZSBzb21lIGRpZmZzLCBsYXllcmVkIG9uIHRvcCBvZiBNYWhlc2jigJlzIFBSIHRv IG5ldG1vZC13Zy9hY2wtbW9kZWwgdGhhdCBkbyB0aGlzLiBOZWFybHkgbGlrZSB0aGUgYXVnbWVu dGF0aW9uIEkgaGF2ZSBiZWxvdy4gRmVlbCBmcmVlIHRvIHRha2UgYSBsb29rIGF0OjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L21qZXRoYW5hbmRhbmkvYWNsLW1vZGVsL3B1bGwvMyIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5odHRwczovL2dpdGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9kZWwvcHVsbC8z PC9hPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIsIEtyaXN0aWFu IHdhbnRzIHRoZSBnbG9iYWwgYXR0YWNobWVudCBwb2ludCBhcyB3ZWxsIHNvIHRoYXQgaGUgY2Fu IGFkZCB0aGUgQUNMIHRvIHRoZSBsaW51eCB0YWJsZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+ZWluYXJubiZndDsgSSB0aGluayBLcmlzdGlhbiBkb2VzbuKAmXQgZmVlbCBhIGds b2JhbCBhdHRhY2htZW50IHBvaW50IG5lZWRzIHRvIGJlIGluIHRoaXMgZmlyc3QgcmV2aXNpb24u IEJ1dCBoZSBjYW4gY29uZmlybS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5JZiBhbiBBQ0wgaXMgYXR0YWNoZWQgZ2xvYmFsbHksIGRvZXMg dGhpcyBtZWFuIGl0IGlzIHBlciBkaXJlY3Rpb24gb3IgZG9lcyBpdCBtZWFuIGl0IGlzIGFjcm9z cyBkaXJlY3Rpb25zPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4mZ3Q7 IEkgZG9u4oCZdCBrbm93IHJpZ2h0IG5vdyA6LSk8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGlzIGdsb2JhbCBBQ0wgbWF5IG5vdCBiZSBh cHBsaWNhYmxlIHRvIGFueSBvZiBDaXNjbydzIHNlcnZpY2UgcHJvdmlkZXIgcm91dGVycyBhcyBJ IGRvbid0IHNlZSBhbnkgcGxhdGZvcm0gYWN0dWFsbHkgcmVwbGljYXRpbmcgdGhlIEFDTCB0byBh bGwgbGluZSBjYXJkcyBhbmQgYXR0YWNoaW5nIGl0IGluIGluZ3Jlc3MgYW5kIGVncmVzcyBkaXJl Y3Rpb25zIGFjcm9zcyBhbGwgaW50ZXJmYWNlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5laW5hcm5uJmd0OyBQZXIgb3RoZXIgZW1haWxzLCBJIGRvbuKAmXQgdGhpbmsgd2UgdW5k ZXJzdGFuZCB0aGlzIGVub3VnaCB5ZXQgdG8gc3BlY2lmeSBpdCwgc28gSSBzdWdnZXN0IHdlIGp1 c3QgbGVhdmUgaXQgb3V0IGZvciBub3cuIE5vdGhpbmcgaW4gdGhlIG1vZGVsIHByZXZlbnRzIGEg 4oCcZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnTigJ0gYmVpbmcgYWRkZWQgbGF0ZXIgb25jZSB3ZSB1 bmRlcnN0YW5kIHdoYXQgaXQgcmVhbGx5IG1lYW5zLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZvciAoMiksIEkgYW0gb2sgd2l0aCByZW1v dmluZyBpY21wLW9mZi48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5laW5hcm5uJmd0 OyBEb25lIGluIG15IFBSIGFib3ZlLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZvciAoMyksIHRoaXMgd291bGQgaGF2ZSB0byBiZSBhIGNv bWJpbmF0aW9uIG9mIEFDTCBzdGF0cyBhY3Jvc3MgYWxsIGludGVyZmFjZXMgZm9yIGFsbCBBQ0wn cy4gU29tZXRoaW5nIGxpa2UgdGhpcyBpcyBwb3NzaWJsZSBvbiBhbiBYUiBib3ggd2hlcmUgQUNF UyBoYXZlIGNvdW50ZXIgbmFtZXMgYXNzb2NpYXRlZCB3aXRoIGl0LiBMZXQncyBjaGF0IGFib3V0 IHRoaXMgb2ZmbGluZSB0b21vcnJvdy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5l aW5hcm5uJmd0OyBJ4oCZbGwgcGluZyB5b3UgdG8gY2xhcmlmeSwgYW5kIHdlIGNhbiBicmluZyBh bnkgY29uY2x1c2lvbiBiYWNrIHRvIHRoZSBsaXN0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlNvbmFsLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIERlYyAxMywg MjAxNyBhdCAxMjoxMCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8c3BhbiBkaXI9Imx0ciIgY2xh c3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5p QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+V2Ugd2FudCB0 byBzdXBwb3J0IOKAnGdsb2JhbOKAnSBhdHRhY2htZW50IHBvaW50IGRvd24gdGhlIGxpbmUsIGFu ZCB0aGF0IOKAnGdsb2JhbOKAnSBhdHRhY2htZW50IHBvaW50IHdpbGwgYmUgb25lIG9mIHRoZSBj aG9pY2VzICh0aGUgb3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQgd291bGQgdGhpcyBh dWdtZW50IGxvb2sgbGlrZS4gTm90ZSwgYXMgZmFyIGFzIEkga25vdywNCiB5b3UgY2Fubm90IGF1 Z21lbnQgaW5zaWRlIGEgY2hvaWNlIG5vZGUuDQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9Img1Ij48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywgMjAx NywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pICZsdDs8YSBocmVm PSJtYWlsdG86ZWluYXJubkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9Im1fNzEwMjQwODkwNzUzMzAxNzUwMUFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2xp bmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiIGNsYXNzPSIiPlBlcmhhcHMgbGlrZSB0aGlzLCBh cyBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGludGVyZmFjZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwIDANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0MHB4 O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyBhdWdtZW50IC9p ZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZTo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNw OyAmbmJzcDsgJiM0MzstLXJ3IGluZ3Jlc3MtYWNsczwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyBhY2wtc2V0czwvZm9udD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQq IFtuYW1lXTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvdHlwZTwvZm9udD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291 cmllciI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1y byBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlLzx3YnIgY2xhc3M9 IiI+bmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5i c3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1v Y3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZWdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wtc2V0czwvZm9u dD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNj ZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9h Y2wvdHlwZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0g e2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1l ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAv YWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS88d2JyIGNsYXNzPSIiPm5hbWU8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZh Y2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRl cjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5i c3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D b3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBib3RoIHRoZXNlICZh bXA7IHJlbmFtZSDigJxpbmdyZXNzLWFjbHMmcXVvdDsgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0 byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVkLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNiBEZWMgMjAxNywgYXQg MTk6NDMsIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bGVhckBjaXNjby5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV83MTAyNDA4OTA3NTMzMDE3NTAx QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAxMi82LzE3IDc6MjMgUE0sIE1haGVz aCBKZXRoYW5hbmRhbmkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+SG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBv aW50LCBjdXJyZW50bHkgYW48YnIgY2xhc3M9IiI+DQonaW50ZXJmYWNlLXJlZicsIHRvIGFuIGF1 Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50ZXJmYWNlcy9pbnRlcmZhY2UsPGJyIGNsYXNzPSIiPg0K aW5zaWRlIG9mIHRoZSDigJhhY2zigJkgJm5ic3A7Y29udGFpbmVyPyBEb3duIHRoZSBsaW5lIHdl IG1pZ2h0IG5lZWQgdG8gaGF2ZSBhbjxiciBjbGFzcz0iIj4NCmNvbnRhaW5lciBmb3IgJnF1b3Q7 YXR0YWNobWVudCBwb2ludHMmcXVvdDsgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9m PGJyIGNsYXNzPSIiPg0KYXR0YWNoaW5nIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9y IOKAnGdsb2JhbGx54oCdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxiciBjbGFzcz0iIj4NCktlZXBpbmcgaW4gbWluZCB0aGF0IG9uZSB1c2UgaXMgdGhhdCBh biBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW48YnIgY2xhc3M9IiI+DQppbnRlcmZhY2UgYXQgYWxs LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpuZXRtb2Qg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bmV0bW9k QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnIgY2xhc3M9 IiI+bGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxz cGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNsYXNzPSIiIGNvbG9yPSIjODg4ODg4Ij4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1haGVzaCBKZXRoYW5hbmRhbmk8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdt YWlsLmNvbTwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9mb250Pjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBt YWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn IiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnIgY2xhc3M9 IiI+bGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBjbGFz cz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZCIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8Zmll bGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PiA8YnIgY2xhc3M9 IiI+DQo8cHJlIGNsYXNzPSIiIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0 LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+bmV0bW9kQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1v ZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu b3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiI+ bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E2A33B749D0B49648280FF931CA1D330ciscocom_-- From nobody Wed Jan 10 05:12:45 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 9C1A4126DC2 for ; Wed, 10 Jan 2018 05:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Fvb_JcJeYh for ; Wed, 10 Jan 2018 05:12:39 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0138.outbound.protection.outlook.com [104.47.2.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D3612420B for ; Wed, 10 Jan 2018 05:12:38 -0800 (PST) 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; bh=tXEND4AGxHRW9Ias4z4wS26idYkUsIfG3W0FibmP5ZI=; b=PbO39hlDjgUdErqTz8Q85lQYTVUfRU1XMvavU81+pWy1a1pO9AsJPY/O85xuvbDdxHKzKBjutrlZrDoP+g6SooUucYDbC5XCpz/+e0yKW/CyF+qDn0FoaahKRdloP4uS7UwhTHFBJ2chKzayDXj5kYNH0fSUiQwAorm6yNziAL0= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB1683.eurprd07.prod.outlook.com (10.166.133.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Wed, 10 Jan 2018 13:12:36 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0%14]) with mapi id 15.20.0407.005; Wed, 10 Jan 2018 13:12:36 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Martin Bjorklund CC: "rwilton@cisco.com" , "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-entity-06 Thread-Index: AQHTeZsGj/By4wgWGkSTA5QT6Ag4U6NN6XKHgBw2jXCAAazigIABZ5tA Date: Wed, 10 Jan 2018 13:12:36 +0000 Message-ID: References: <20171221.123746.382540578845045602.mbj@tail-f.com> <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com> <20180109.163933.49682684192910889.mbj@tail-f.com> In-Reply-To: <20180109.163933.49682684192910889.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [2a02:1811:e41a:9e00:29d7:bd33:4b39:c03d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1683; 7:S4YS2BpL/ShZd8b9TRbPvnnnKKytnkoV1+LQgL57uAQgfQuqsin5dKPfUCYw7Uk6w7cacs5PRB81DI3UeuOm8fwdw4c/Hl4kPo3x9hOJSPLZSMDeONImIIGTKTWN+xqCPvFTtF+NFDQUaJw+f/Gu3iZRu3a1Fg8+9Cf3IGTmLpLfe6nD8njbye6jXw8HBe1Rfise4ucAsoIv8+OmC1NFAfWMXw2inL+Wd9ijJvxydvsMGqZrnz2ySnuaFFZMrAqG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6a444a76-3250-4f29-5a28-08d5582bd187 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB1683; x-ms-traffictypediagnostic: AM4PR07MB1683: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(11241501184)(806099)(944501075)(10201501046)(6055026)(6041268)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB1683; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB1683; x-forefront-prvs: 0548586081 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(396003)(366004)(39380400002)(51444003)(40224003)(24454002)(199004)(13464003)(189003)(81156014)(6916009)(305945005)(229853002)(5660300001)(3660700001)(86362001)(6436002)(81166006)(316002)(7736002)(2950100002)(3280700002)(8936002)(74316002)(68736007)(54906003)(8676002)(25786009)(53936002)(33656002)(6506007)(55016002)(6246003)(14454004)(102836004)(2900100001)(4326008)(230783001)(6116002)(97736004)(76176011)(93886005)(59450400001)(6306002)(478600001)(106356001)(7696005)(5250100002)(966005)(105586002)(9686003)(2906002)(99286004)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1683; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zXMUIH9ifi8fBdXtDKROHN+cgkzFgVMh8c1LAvgjvAmeqGk5oOTJ6ZLWySzqebXlalXLKVDB4HPz2ZpU7RndMiTccP4lxIk0231CtojLG4eg+mjrJ1KgWakmxZrpjAoM spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a444a76-3250-4f29-5a28-08d5582bd187 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 13:12:36.3846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1683 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 13:12:44 -0000 SGksDQoNCi0tLSBzbmlwIC0tLQ0KDQo+IHN0YXRlLuKAnSwgc28gdGhlIGFib3ZlIHNlbnRlbmNl IG9ubHkgYXBwbGllcyBmb3IgdGhlIHNlY29uZCBjYXNlIGJlbG93Lg0KDQpPay4NCg0KPiAyLiBU aGUgc2Vjb25kIGNhc2UgaXMgdGhhdCBzb21ldGhpbmcgaXMgZGV0ZWN0ZWQgYnV0IGl0IGNhbuKA mXQgYmUgcmVhZC4NCj4gV2UgZG8gbm90IHNlZSBhIHJlYXNvbiB0byB1c2UgdGhlIHZhbHVlIGNv bmZpZ3VyZWQgZm9yIHRoZSBsZWFmcyANCj4g4oCYc2VyaWFsLW51beKAmSwg4oCYbWZnLW5hbWXi gJkgYW5kIOKAmG1vZGVsLW5hbWXigJkgb2YgYSBtYXRjaGluZyBlbnRyeSBpbiB0aGUgDQo+IGNv bmZpZ3VyYXRpb24gZGF0YS4gIFRoZXNlIGxlYWZzIGFyZSBkZWZpbmVkIGFzIG9wdGlvbmFsIHNv IHdoeSB3b3VsZCANCj4gd2UgcmVwb3J0IHNvbWV0aGluZyBlbnRlcmVkIGJ5IGFuIG9wZXJhdG9y IGluIHRoZSBvcGVyYXRpb25hbCANCj4gZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byByZXBvcnQg b24gd2hhdCBpcyBkZXRlY3RlZD8gIElzIGl0IG5vdCANCj4gYmV0dGVyIHRvIG5vdCByZXBvcnQg dGhlbSBhdCBhbGw/ICBJbiBhbiBOTURBIGNvbnRleHQgaXQgd291bGQgYmUgDQo+IHBvc3NpYmxl IHRvIGhhdmUgYSBkaWZmZXJlbnQgdmFsdWUgKG9yIG5vIHZhbHVlIGF0IGFsbCkgZm9yIGNlcnRh aW4gDQo+IGxlYWZzIHdoaWxlIHRoZXJlIGlzIHNvbWV0aGluZyBpbiB0aGUgcnVubmluZy9pbnRl bmRlZCBkYXRhc3RvcmUuDQoNClRoZSBub3JtYWwgTk1EQSBwcm9jZWR1cmUgZm9yIGEgY29uZmln dXJhdGlvbiBsZWFmIGlzIHRvIHJlcGVhdCBpdCBpbiBvcGVyYXRpb25hbCBzdGF0ZS4gIFRoaXMg aXMgdGhlbiB0aGUgImFwcGxpZWQgY29uZmlndXJhdGlvbiIuICANCkkgZG9uJ3QgdGhpbmsgd2Ug c2hvdWxkIGhhdmUgYSBzcGVjaWFsIHJ1bGUgZm9yIHRoZXNlIGxlYWZzLg0KDQpUaGlzIGFsc28g bWVhbnMgdGhhdCBhIGNsaWVudCB0aGF0IGp1c3Qgd2FudHMgdG8gcmVhZCBhbGwgdGhlIHNlcmlh bCBudW1iZXJzIGNhbiBkbyBzbyBmcm9tIG9uZSBwbGFjZSwgdGhlIG9wZXJhdGlvbmFsIHN0YXRl LCByZWdhcmRsZXNzIG9mIGhvdyB0aGV5IGNhbWUgaW50byBleGlzdGFuY2UuDQoNCltCb2dhZXJ0 LCBCYXJ0IF0gDQoNCldlIGRvIHVuZGVyc3RhbmQgdGhhdCBhIHRhcmdldCBvZiBOTURBIGlzIHRv IHJlYWQgb3V0IHRoZSBhY3R1YWxseSBhcHBsaWVkIGRhdGEgaW4gb25lIHJlcXVlc3QuICBCdXQg dGhlIHJlc3VsdCBzaG91bGQgbm90IGJlIGNvbmZ1c2lvbi4gQSBrZXkgd29yZCBpcyDigJxhcHBs aWVk4oCdLg0KDQpTZWN0aW9uIDUuMyBvZiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFz dG9yZXMtMDkgYWxzbyBjb250YWlucyAoSSBwdXQgYSBwYXJ0IG9mIHRoZSBzZWN0aW9uIGJldHdl ZW4gKioqKToNClRoZSBkYXRhc3RvcmUgc2NoZW1hIGZvciA8b3BlcmF0aW9uYWw+IE1VU1QgYmUg YSBzdXBlcnNldCBvZiB0aGUgY29tYmluZWQgZGF0YXN0b3JlIHNjaGVtYSB1c2VkIGluIGFsbCBj b25maWd1cmF0aW9uIGRhdGFzdG9yZXMgZXhjZXB0IHRoYXQgY29uZmlndXJhdGlvbiBkYXRhIG5v ZGVzIHN1cHBvcnRlZCBpbiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlICoqKk1BWSBiZSBvbWl0 dGVkIGZyb20gPG9wZXJhdGlvbmFsPiBpZiBhIHNlcnZlciBpcyBub3QgYWJsZSB0byBhY2N1cmF0 ZWx5IHJlcG9ydCB0aGVtICoqKi4NCg0KRm9yIGV4YW1wbGUsIGl0IGlzIGV4cGVjdGVkIHRoYXQg dGhlIHZhbHVlIG9mIG11bHRpcGxlIGxlYWZzIG5lZWQgdG8gYmUgYSBjb25zaXN0ZW50IHNldCwg ZS5nLiB0aGUgbWZnLW5hbWUsIHRoZSBtb2RlbC1uYW1lLCBhbmQgdGhlIHNlcmlhbC1udW0uDQpT dXBwb3NlIHdlIGhhdmUgYSB1c2UgY2FzZSBpbiB3aGljaCBhIGhhcmR3YXJlIGNvbXBvbmVudCBp cyBwbGFubmVkL2NvbmZpZ3VyZWQgKGUuZy4gYSBib2FyZCBzdXBwb3J0aW5nIERTTCBpbnRlcmZh Y2VzKSBidXQgYSBkaWZmZXJlbnQgb25lIGlzIHBsdWdnZWQgKGUuZy4gYSBib2FyZCBzdXBwb3J0 aW5nIGV0aGVybmV0IGludGVyZmFjZXMpLg0KU3VwcG9zZSBpdCBpcyBwb3NzaWJsZSB0byByZWFk IHNvbWUgZmllbGRzIG9uIHRoZSBkZXRlY3RlZCBjb21wb25lbnQgYnV0IGR1ZSB0byBhbiBpc3N1 ZSBub3QgdG8gcmVhZCBvdGhlciBmaWVsZHMuDQpJZiBpbiB0aGF0IGNhc2UgdGhlIG9wZXJhdGlv bmFsIGRhdGFzdG9yZSB3aWxsIGJlIGNvbXBsZXRlZCB3aXRoIHRoZSBkYXRhIHRha2VuIGZyb20g dGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCB0aGVuIHRoZSBwcmVzZW50ZWQgdmlldyBtaWdodCBiZSBp bmNvbnNpc3RlbnQuDQpUaGUgcXVlc3Rpb24gaXMgYWxzbzogd2hhdCBkYXRhIGlzIGFwcGxpZWQ/ IE91ciBhc3N1bXB0aW9uOiBpZiB0aGVyZSBpcyBhIG1pc21hdGNoIGJldHdlZW4gZGV0ZWN0ZWQg dmVyc3VzIGNvbmZpZ3VyZWQgaGFyZHdhcmUsIHRoZW4gdGhlIGludGVyZmFjZS9zZXJ2aWNlIHJl bGF0ZWQgZGF0YSB0aGF0IGlzIGNvbmZpZ3VyZWQgY29uc2lzdGVudGx5IHdpdGggdGhlIHBsYW5u ZWQgaGFyZHdhcmUgaXMgbm90IGFwcGxpZWQgb24gdGhlIG1pc21hdGNoaW5nIGhhcmR3YXJlLiBJ LmUuIHRoZSBkZXRlY3RlZCBoYXJkd2FyZSBpcyBub3QgYnJvdWdodCBpbiBzZXJ2aWNlIHNvIG5v dCDigJhhcHBsaWVk4oCZLCB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIG9ubHkgKGFjY3VyYXRl bHkpIHJlcG9ydHMgb24gd2hhdCBpcyBkZXRlY3RlZC4NCg0KV2UgZG8gbm90IHNlZSB0aGlzIGFz IGEgc3BlY2lhbCBydWxlIGZvciB0aGlzIGRhdGEgYnV0IHJhdGhlciB3b3VsZCBhcHBseSBhIGdl bmVyYWwgcnVsZToNCi0JaWYgdGhlcmUgaXMgYSDigJhtaXNzaW5nIHJlc291cmNl4oCZLCB0aGVu IHRoZSBkYXRhIGlzIG5vdCByZXBvcnRlZCBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlLg0K LQlJZiB0aGUgc2VydmVyIGlzIG5vdCBhYmxlIHRvIHJlcG9ydCBhY2N1cmF0ZWx5LCB0aGVuIHRo ZSBkYXRhIGlzIG9taXR0ZWQgZnJvbSB0aGUgb3BlcmF0aW9uYWwNCg0KUmVnYXJkcywgQmFydA0K DQovbWFydGluDQoNCg0KPiANCj4gQmVzdCByZWdhcmRzLCBCYXJ0DQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCANCj4gV2lsdG9uDQo+IFNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciAyMSwgMjAxNyA0OjE0IFBNDQo+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA dGFpbC1mLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gQUQg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wNg0KPiANCj4gSGkgTWFydGluLA0K PiANCj4gDQo+IE9uIDIxLzEyLzIwMTcgMTE6MzcsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ ID4gSGksDQo+ID4NCj4gPiBJIG5lZWQgV0cgaW5wdXQgb24gdGhpcyBpc3N1ZS4gIFRoZSBxdWVz dGlvbiBpcyBob3cgdG8gaGFuZGxlIA0KPiA+ICdzZXJpYWwtbnVtJywgJ21mZy1uYW1lJywgYW5k ICdtb2RlbC1uYW1lJy4gIEkgdGhpbmsgdGhleSBzaG91bGQgYWxsIA0KPiA+IGJlIHRyZWF0ZWQg dGhlIHNhbWUuICBCYXNlZCBvbiBwcmV2aW91cyBXRyBkaXNjdXNzaW9uIChzZWUgZS5nLiB0aGUg DQo+ID4gbWFpbCB0aHJlYWQgImRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eSBpc3N1ZSAjMTMiKSwg SSB0aGluayB0aGV5IA0KPiA+IHNob3VsZCBhbGwgYmUgY29uZmlndXJhYmxlLCBidXQgdGhlIGNv bmZpZ3VyZWQgdmFsdWUgaXMgb25seSB1c2VkIGluIA0KPiA+IG9wZXJhdGlvbmFsIHN0YXRlIGlm IHRoZSBzeXN0ZW0gY2Fubm90IHJlYWQgaXQgZnJvbSB0aGUgaGFyZHdhcmUuDQo+IEkgdGhpbmsg dGhhdCB0aGlzIGFwcHJvYWNoIGlzIHByb2JhYmx5IE9LOg0KPiAgwqAtIFRoZSBjbGllbnQgY2Fu IGFsd2F5cyBzZWUgdGhlIHJlYWwgdmFsdWUgaWYgaXQgaXMgYXZhaWxhYmxlLg0KPiAgwqAtIElm IGl0IGlzIG5vdCBhdmFpbGFibGUgdGhlbiB0aGV5IGNhbiBhc3NpZ24gYSB2YWx1ZSB2aWEgIA0K PiBjb25maWd1cmF0aW9uLg0KPiANCj4gSSB3YXMgYWxzbyBjb25zaWRlcmluZyBhbiBhbHRlcm5h dGl2ZSBhcHByb2FjaCBvZiBoYXZpbmcgYSBzZXBhcmF0ZSANCj4gc2V0IG9mIGNvbmZpZyBmYWxz ZSBsZWF2ZXMgZm9yIHRoZSAiYnVybnQgaW4gdmFsdWVzIi7CoCBBbmQgdGhlbiBoYXZpbmcgDQo+ IHRoZSBjb25maWd1cmFibGUgbGVhdmVzIGFsd2F5cyBvdmVycmlkZSB0aGUgZGVmYXVsdCBvcGVy YXRpb25hbCANCj4gdmFsdWVzLiBFLmcuIHNpbWlsYXIgdG8gaG93IGFuIGludGVyZmFjZSBNQUMg YWRkcmVzcyB3b3VsZCBleHBlY3QgdG8gDQo+IGJlIGhhbmRsZWQuDQo+IA0KPiBCdXQgb25lIHNl dCBvZiBsZWF2ZXMgaXMgcHJvYmFibHkgc3VmZmljaWVudC4NCj4gDQo+IFRoYW5rcywNCj4gUm9i DQo+IA0KPiANCj4gPg0KPiA+IFNvIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQo+ ID4NCj4gPiBPTEQ6DQo+ID4NCj4gPiAgICAgICAgbGVhZiBzZXJpYWwtbnVtIHsNCj4gPiAgICAg ICAgICB0eXBlIHN0cmluZzsNCj4gPiAgICAgICAgICBjb25maWcgZmFsc2U7DQo+ID4gICAgICAg ICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICJUaGUgdmVuZG9yLXNwZWNpZmljIHNlcmlh bCBudW1iZXIgc3RyaW5nIGZvciB0aGUNCj4gPiAgICAgICAgICAgICBjb21wb25lbnQuICBUaGUg cHJlZmVycmVkIHZhbHVlIGlzIHRoZSBzZXJpYWwgbnVtYmVyDQo+ID4gICAgICAgICAgICAgc3Ry aW5nIGFjdHVhbGx5IHByaW50ZWQgb24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmDQo+ID4gICAg ICAgICAgICAgcHJlc2VudCkuIjsNCj4gPiAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzOiBl bnRQaHlzaWNhbFNlcmlhbE51bSI7DQo+ID4gICAgICAgIH0NCj4gPg0KPiA+IE5FVzoNCj4gPg0K PiA+ICAgICAgICBsZWFmIHNlcmlhbC1udW0gew0KPiA+ICAgICAgICAgIHR5cGUgc3RyaW5nOw0K PiA+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gICAgICAgICAgICAiVGhlIHZlbmRvci1zcGVj aWZpYyBzZXJpYWwgbnVtYmVyIHN0cmluZyBmb3IgdGhlDQo+ID4gICAgICAgICAgICAgY29tcG9u ZW50LiAgVGhlIHByZWZlcnJlZCB2YWx1ZSBpcyB0aGUgc2VyaWFsIG51bWJlcg0KPiA+ICAgICAg ICAgICAgIHN0cmluZyBhY3R1YWxseSBwcmludGVkIG9uIHRoZSBjb21wb25lbnQgaXRzZWxmIChp Zg0KPiA+ICAgICAgICAgICAgIHByZXNlbnQpLg0KPiA+DQo+ID4gICAgICAgICAgICAgVGhpcyBs ZWFmIGNhbiBiZSBjb25maWd1cmVkLiAgVGhlcmUgYXJlIHR3byB1c2UgY2FzZXMgZm9yDQo+ID4g ICAgICAgICAgICAgdGhpczsgYXMgYSAncG9zdC1pdCcgbm90ZSBpZiB0aGUgc2VydmVyIGNhbm5v dCBkZXRlcm1pbmUNCj4gPiAgICAgICAgICAgICB0aGlzIHZhbHVlIGZyb20gdGhlIGNvbXBvbmVu dCwgb3Igd2hlbiBwcmUtcHJvdmlzaW9uaW5nIGENCj4gPiAgICAgICAgICAgICBjb21wb25lbnQu DQo+ID4NCj4gPiAgICAgICAgICAgICBJZiB0aGUgc2VydmVyIGNhbiBkZXRlcm1pbmUgdGhlIHNl cmlhbCBudW1iZXIgZnJvbSB0aGUNCj4gPiAgICAgICAgICAgICBjb21wb25lbnQsIHRoZW4gdGhh dCB2YWx1ZSBpcyBhbHdheXMgdXNlZCBpbiBvcGVyYXRpb25hbA0KPiA+ICAgICAgICAgICAgIHN0 YXRlLCBldmVuIGlmIGFub3RoZXIgdmFsdWUgaGFzIGJlZW4gY29uZmlndXJlZC4iOw0KPiA+ICAg ICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6IGVudFBoeXNpY2FsU2VyaWFsTnVtIjsNCj4gPiAg ICAgICAgfQ0KPiA+DQo+ID4gQW5kIGNvcnJlc3BvbmRpbmcgdGV4dCBmb3IgJ21mZy1uYW1lJyBh bmQgJ21vZGVsLW5hbWUnLg0KPiA+DQo+ID4gQW5kIGFsc286DQo+ID4NCj4gPiBPTEQ6DQo+ID4N Cj4gPiAgICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29t cG9uZW50LCBpdA0KPiA+ICAgICAgICAgICBpbml0aWFsaXplcyBhIGxpc3QgZW50cnkgaW4gdGhl IG9wZXJhdGlvbmFsIHN0YXRlLg0KPiA+DQo+ID4gICAgICAgICAgIElmIHRoZSBzZXJ2ZXIgZG9l cyBub3Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gICAgICAgICAgIGNv bXBvbmVudHMsIGxpc3QgZW50cmllcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgYXJlDQo+ID4g ICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0 ZWQgYnkgdGhlDQo+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gICAgICAg ICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9sbG93ZWQ6DQo+ID4N Cj4gPiAgICAgICAgICAgICAxLiBJZiB0aGVyZSBpcyBhbiBlbnRyeSBpbiB0aGUgL2hhcmR3YXJl L2NvbXBvbmVudCBsaXN0IGluDQo+ID4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZp Z3VyYXRpb24gd2l0aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiA+ICAgICAgICAgICAgICAgICdj bGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRvDQo+ID4g ICAgICAgICAgICAgICAgdGhlIGRldGVjdGVkIHZhbHVlcywgdGhlbjoNCj4gPg0KPiA+ICAgICAg ICAgICAgIDFhLiBJZiB0aGUgY29uZmlndXJlZCBlbnRyeSBoYXMgYSB2YWx1ZSBmb3IgJ21mZy1u YW1lJw0KPiA+ICAgICAgICAgICAgICAgICB0aGF0IGlzIGVxdWFsIHRvIHRoZSBkZXRlY3RlZCB2 YWx1ZSwgb3IgaWYgdGhlDQo+ID4gICAgICAgICAgICAgICAgICdtZmctbmFtZScgdmFsdWUgY2Fu bm90IGJlIGRldGVjdGVkLCB0aGVuIHRoZSBsaXN0DQo+ID4gICAgICAgICAgICAgICAgIGVudHJ5 IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcyBpbml0aWFsaXplZCB3aXRoIHRoZQ0KPiA+ICAg ICAgICAgICAgICAgICBjb25maWd1cmVkIHZhbHVlcyBmb3IgYWxsIGNvbmZpZ3VyZWQgbm9kZXMs IGluY2x1ZGluZw0KPiA+ICAgICAgICAgICAgICAgICB0aGUgJ25hbWUnLg0KPiA+DQo+ID4gICAg ICAgICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGxpc3QgZW50cnkgaW4gdGhlIG9wZXJhdGlvbmFs IHN0YXRlIGlzDQo+ID4gICAgICAgICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZv ciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4gPiAgICAgICAgICAgICAgICAgdGhlIGltcGxl bWVudGF0aW9uLiAgVGhlIGltcGxlbWVudGF0aW9uIG1heSByYWlzZSBhbg0KPiA+ICAgICAgICAg ICAgICAgICBhbGFybSB0aGF0IGluZm9ybXMgYWJvdXQgdGhlICdtZmctbmFtZScgbWlzbWF0Y2gN Cj4gPiAgICAgICAgICAgICAgICAgY29uZGl0aW9uLiAgSG93IHRoaXMgaXMgZG9uZSBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZg0KPiA+ICAgICAgICAgICAgICAgICB0aGlzIGRvY3VtZW50Lg0KPiA+ DQo+ID4gICAgICAgICAgICAgMWIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUgaXMgbm8gbWF0Y2hp bmcgY29uZmlndXJhdGlvbg0KPiA+ICAgICAgICAgICAgICAgICBlbnRyeSksIHRoZSBsaXN0IGVu dHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcw0KPiA+ICAgICAgICAgICAgICAgICBpbml0 aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5DQo+ID4gICAg ICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+ICAgICAgICAgICBJZiB0 aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluIHRoZSBpbnRlbmRlZA0KPiA+ICAgICAgICAg ICBjb25maWd1cmF0aW9uIGlzIG1vZGlmaWVkLCB0aGVuIHRoZSBzeXN0ZW0gTVVTVCBiZWhhdmUg YXMgaWYNCj4gPiAgICAgICAgICAgaXQgcmUtaW5pdGlhbGl6ZXMgaXRzZWxmLCBhbmQgZm9sbG93 IHRoZSBwcm9jZWR1cmUgaW4gDQo+ID4gKDEpLiI7DQo+ID4NCj4gPiBORVc6DQo+ID4NCj4gPiAg ICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9uZW50 LCBpdA0KPiA+ICAgICAgICAgICBpbml0aWFsaXplcyBhIGxpc3QgZW50cnkgaW4gdGhlIG9wZXJh dGlvbmFsIHN0YXRlLg0KPiA+DQo+ID4gICAgICAgICAgIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qg c3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gICAgICAgICAgIGNvbXBvbmVu dHMsIGxpc3QgZW50cmllcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgYXJlDQo+ID4gICAgICAg ICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkg dGhlDQo+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gICAgICAgICAgIE90 aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9sbG93ZWQ6DQo+ID4NCj4gPiAg ICAgICAgICAgICAxLiBJZiB0aGVyZSBpcyBhbiBlbnRyeSBpbiB0aGUgL2hhcmR3YXJlL2NvbXBv bmVudCBsaXN0IGluDQo+ID4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRp b24gd2l0aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiA+ICAgICAgICAgICAgICAgICdjbGFzcycs ICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRvDQo+ID4gICAgICAg ICAgICAgICAgdGhlIGRldGVjdGVkIHZhbHVlcywgdGhlbiB0aGUgbGlzdCBlbnRyeSBpbiBvcGVy YXRpb25hbA0KPiA+ICAgICAgICAgICAgICAgIHN0YXRlIGlzIGluaXRpYWxpemVkIHdpdGggdGhl IGNvbmZpZ3VyZWQgdmFsdWVzLA0KPiA+ICAgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgJ25h bWUnLiAgVGhlIGxlYWZzICdzZXJpYWwtbnVtJywNCj4gPiAgICAgICAgICAgICAgICAnbWZnLW5h bWUnLCBhbmQgJ21vZGVsLW5hbWUnIGFyZSB0cmVhdGVkIHNwZWNpYWxseTsgc2VlDQo+ID4gICAg ICAgICAgICAgICAgdGhlaXIgZGVzY3JpcHRpb25zIGZvciBkZXRhaWxzLg0KPiA+DQo+ID4gICAg ICAgICAgICAgMi4gT3RoZXJ3aXNlIChpLmUuLCB0aGVyZSBpcyBubyBtYXRjaGluZyBjb25maWd1 cmF0aW9uDQo+ID4gICAgICAgICAgICAgICAgZW50cnkpLCB0aGUgbGlzdCBlbnRyeSBpbiB0aGUg b3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiAgICAgICAgICAgICAgICBpbml0aWFsaXplZCB3aXRo IHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5DQo+ID4gICAgICAgICAgICAgICAg dGhlIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gICAgICAgICAgIElmIHRoZSAvaGFyZHdhcmUv Y29tcG9uZW50IGxpc3QgaW4gdGhlIGludGVuZGVkDQo+ID4gICAgICAgICAgIGNvbmZpZ3VyYXRp b24gaXMgbW9kaWZpZWQsIHRoZW4gdGhlIHN5c3RlbSBNVVNUIGJlaGF2ZSBhcyBpZg0KPiA+ICAg ICAgICAgICBpdCByZS1pbml0aWFsaXplcyBpdHNlbGYsIGFuZCBmb2xsb3cgdGhlIHByb2NlZHVy ZSBpbiANCj4gPiAoMSkuIjsNCj4gPg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ ID4+IE9uIDEyLzIwLzIwMTcgNDowMCBQTSwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4+ IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+PiBIaSBNYXJ0 aW4sDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MuDQo+ID4+Pj4gT25seSBrZXB0IHRoZSByZWxldmFu dCBleGNlcnB0cy4NCj4gPj4+Pj4+IC0gU29tZSBvYmplY3RzIGFyZSByZWFkLXdyaXRlIGluIFJG QzY5MzM6DQo+ID4+Pj4+PiAgICAgICAgICBlbnRQaHlzaWNhbFNlcmlhbE51bQ0KPiA+Pj4+Pj4g ICAgICAgICAgZW50UGh5c2ljYWxBbGlhcw0KPiA+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxB c3NldElEDQo+ID4+Pj4+PiAgICAgICAgICBlbnRQaHlzaWNhbFVyaXMNCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBGb3IgZXhhbXBsZSwgZW50UGh5c2ljYWxTZXJpYWxOdW0gYmVpbmcgcmVhZC13cml0ZSBh bHdheXMgYm90aGVyZWQgbWUuDQo+ID4+Pj4+PiBzZXJpYWwtbnVtIGlzIG5vdyAiY29uZmlnIGZh bHNlIiwgd2hpY2ggaXMgYSBnb29kIG5ld3MgSU1PLg0KPiA+Pj4+PiBBY3R1YWxseSwgdGhpcyB3 YXMgbm90IHRoZSBpbnRlbnRpb24uICBJbg0KPiA+Pj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1lbnRp dHktMDMgdGhpcyBpcyBjb25maWd1cmFibGUuICBJIG1pc3NlZCB0aGlzIA0KPiA+Pj4+PiBpbiB0 aGUgY29udmVyc2lvbiB0byBOTURBLg0KPiA+Pj4+IEFoLiBTbyBubyBnb29kIG5ld3MgaW4gdGhp cyBjYXNlLi4uDQo+ID4+Pj4+PiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGVudFBoeXNpY2Fs TWZnTmFtZSBpcyByZWFkLW9ubHkgaW4gDQo+ID4+Pj4+PiBSRkM2OTMzLCB3aGlsZSBpdCdzICJj b25maWcgdHJ1ZSIgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5DQo+ID4+Pj4+IFllcywgdGhp cyB3YXMgYWRkZWQgcGVyIHJlcXVlc3QgZnJvbSB0aGUgV0cuICBTZWUgZS5nLiB0aGUgDQo+ID4+ Pj4+IHRocmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlzc3VlICMxMyIuDQo+ID4+Pj4g U3VyZS4gSXQgd2FzIG1haW5seSBhbiBvYnNlcnZhdGlvbi4NCj4gPj4+Pj4gSG93ZXZlciwgSSB0 aGluayB0aGF0IHdoYXQgd2UgaGF2ZSBub3cgaXMgcHJvYmFibHkgbm90IGNvcnJlY3QuICANCj4g Pj4+Pj4gSSB0aGluayB0aGF0IGFsbCBub2RlcyAnc2VyaWFsLW51bScsICdtZmctbmFtZScsIGFu ZCAnbW9kZWwtbmFtZScNCj4gPj4+Pj4gc2hvdWxkIGJlIGNvbmZpZyB0cnVlLCBhbmQgdGhlIGRl c2NyaXB0aW9uIG9mIGxpc3QgJ2NvbXBvbmVudCcgDQo+ID4+Pj4+IHVwZGF0ZWQgdG8gcmVmbGVj dCB0aGF0IGFsbCB0aGVzZSB0cmVlIGxlYWZzIGFyZSBoYW5kbGVkIHRoZSBzYW1lIHdheS4NCj4g Pj4+Pj4NCj4gPj4+Pj4gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hhdCB0aGUgV0cgdGhpbmtzIGFi b3V0IHRoaXMuDQo+ID4+Pj4gVGFsa2luZyBhcyBhIGNvbnRyaWJ1dG9yIHRoaXMgdGltZS4NCj4g Pj4+PiBJdCBzZWVtcyB0aGF0IGludmVudG9yeSBtYW5hZ2VtZW50IGlzIGtpbmQgb2YgYnJva2Vu IHdoZW4gc29tZW9uZSANCj4gPj4+PiBjYW4gY2hhbmdlICdzZXJpYWwtbnVtJywgJ21mZy1uYW1l JywgYW5kICdtb2RlbC1uYW1lLg0KPiA+Pj4gVGhleSBjYW4ndCByZWFsbHkgY2hhbmdlIHRoZW0u ICBUaGUgY29uZmlndXJlZCB2YWx1ZXMgYXJlIG9ubHkgDQo+ID4+PiB1c2VkIChpLmUuIHZpc2li bGUgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlKSBpZiB0aGUgZGV2aWNlIGNhbm5vdCANCj4gPj4+ IGRldGVjdCB0aGVtIGF1dG9tYXRpY2FsbHkuICBJLmUuLCB0aGV5IHdvcmsgYXMgInBvc3QtaXQi IG5vdGVzIG9ubHkuDQo+ID4+IElmIEkgbG9vayBhdCwgZm9yIGV4YW1wbGUsIHRoZSBtZmctbmFt ZSwgZGVzY3JpcHRpb24sIHRoaXMgaXMgbm90IA0KPiA+PiB3aGF0IGl0IHNheXMuDQo+ID4+DQo+ ID4+ICAgICBsZWFmIG1mZy1uYW1lIHsNCj4gPj4gICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQo+ ID4+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4+ICAgICAgICAgICAgICAgIlRoZSBuYW1l IG9mIHRoZSBtYW51ZmFjdHVyZXIgb2YgdGhpcyBwaHlzaWNhbCBjb21wb25lbnQuDQo+ID4+ICAg ICAgICAgICAgICAgIFRoZSBwcmVmZXJyZWQgdmFsdWUgaXMgdGhlIG1hbnVmYWN0dXJlciBuYW1l IHN0cmluZw0KPiA+PiAgICAgICAgICAgICAgICBhY3R1YWxseSBwcmludGVkIG9uIHRoZSBjb21w b25lbnQgaXRzZWxmIChpZiBwcmVzZW50KS4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgTm90 ZSB0aGF0IGNvbXBhcmlzb25zIGJldHdlZW4gaW5zdGFuY2VzIG9mIHRoZSBtb2RlbC1uYW1lLA0K PiA+PiAgICAgICAgICAgICAgICBmaXJtd2FyZS1yZXYsIHNvZnR3YXJlLXJldiwgYW5kIHRoZSBz ZXJpYWwtbnVtIG5vZGVzIGFyZQ0KPiA+PiAgICAgICAgICAgICAgICBvbmx5IG1lYW5pbmdmdWwg YW1vbmdzdCBjb21wb25lbnQgd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZg0KPiA+PiAgICAgICAgICAg ICAgICBtZmctbmFtZS4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgSWYgdGhlIG1hbnVmYWN0 dXJlciBuYW1lIHN0cmluZyBhc3NvY2lhdGVkIHdpdGggdGhlDQo+ID4+ICAgICAgICAgICAgICAg IHBoeXNpY2FsIGNvbXBvbmVudCBpcyB1bmtub3duIHRvIHRoZSBzZXJ2ZXIsIHRoZW4gdGhpcw0K PiA+PiAgICAgICAgICAgICAgICBub2RlIGlzIG5vdCBpbnN0YW50aWF0ZWQuIjsNCj4gPj4gICAg ICAgICAgICAgcmVmZXJlbmNlICJSRkMgNjkzMyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY5MzM+Og0KPiA+PiAgICAgICAgICAgICBlbnRQaHlzaWNhbE1mZ05hbWUiOw0KPiA+Pg0K PiA+PiBSZWdhcmRzLCBCZW5vaXQNCj4gPj4NCj4gPj4+DQo+ID4+PiAvbWFydGluDQo+ID4+PiAu DQo+ID4+Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gLg0KPiA+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Jan 10 05:15: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 9DF48126DC2; Wed, 10 Jan 2018 05:15:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 dDch6uGsst20; Wed, 10 Jan 2018 05:15:45 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03011124234; Wed, 10 Jan 2018 05:15:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BF307F38; Wed, 10 Jan 2018 14:15:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dcLN3JKT98ue; Wed, 10 Jan 2018 14:15:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 14:15:43 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5C602013D; Wed, 10 Jan 2018 14:15:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n8cSZSkvMfy9; Wed, 10 Jan 2018 14:15:42 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 732932013C; Wed, 10 Jan 2018 14:15:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 57EFD4209B08; Wed, 10 Jan 2018 14:15:42 +0100 (CET) Date: Wed, 10 Jan 2018 14:15:42 +0100 From: Juergen Schoenwaelder To: Eric Rescorla Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180110131542.sv73bd2cxgmdxg7g@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Eric Rescorla , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151541670915.11305.11069854448917067732.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151541670915.11305.11069854448917067732.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 13:15:47 -0000 On Mon, Jan 08, 2018 at 05:05:09AM -0800, Eric Rescorla wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > protocol interactions with other systems and that is neither > conventional nor dynamic configuration. > Could you provide an example of this? Many DHCP implementations do not go through a dynamic datastore and deliver configuration state straight into the operational state. An IP address learned via DHCP on such a system will be tagged with or:learned. > datastore that holds the complete current configuration on the > device. It MAY include configuration that requires further > transformation before it can be applied, e.g., inactive > > If I am reading the text, this doesn't seem to be true because "system > configuration" is not included. Yes, it might make sense to remove 'complete' here to align the sentence in 5.1.3 with the definition of 'running configuration datastore'. /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 Jan 10 05:46:45 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 C4C8D1275FD for ; Wed, 10 Jan 2018 05:46:41 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 BCrfU1uOg8p3 for ; Wed, 10 Jan 2018 05:46:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81C1012420B for ; Wed, 10 Jan 2018 05:46:36 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D2DB1AE0118; Wed, 10 Jan 2018 14:46:35 +0100 (CET) Date: Wed, 10 Jan 2018 14:44:53 +0100 (CET) Message-Id: <20180110.144453.957272588242505523.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180109.163933.49682684192910889.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 13:46:43 -0000 SGksDQoNCiJCb2dhZXJ0LCBCYXJ0IChOb2tpYSAtIEJFL0FudHdlcnApIiA8YmFydC5ib2dhZXJ0 QG5va2lhLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gLS0tIHNuaXAgLS0tDQo+IA0KPiA+IHN0 YXRlLuKAnSwgc28gdGhlIGFib3ZlIHNlbnRlbmNlIG9ubHkgYXBwbGllcyBmb3IgdGhlIHNlY29u ZCBjYXNlIGJlbG93Lg0KPiANCj4gT2suDQo+IA0KPiA+IDIuIFRoZSBzZWNvbmQgY2FzZSBpcyB0 aGF0IHNvbWV0aGluZyBpcyBkZXRlY3RlZCBidXQgaXQgY2Fu4oCZdCBiZSByZWFkLg0KPiA+IFdl IGRvIG5vdCBzZWUgYSByZWFzb24gdG8gdXNlIHRoZSB2YWx1ZSBjb25maWd1cmVkIGZvciB0aGUg bGVhZnMgDQo+ID4g4oCYc2VyaWFsLW51beKAmSwg4oCYbWZnLW5hbWXigJkgYW5kIOKAmG1vZGVs LW5hbWXigJkgb2YgYSBtYXRjaGluZyBlbnRyeSBpbiB0aGUgDQo+ID4gY29uZmlndXJhdGlvbiBk YXRhLiAgVGhlc2UgbGVhZnMgYXJlIGRlZmluZWQgYXMgb3B0aW9uYWwgc28gd2h5IHdvdWxkIA0K PiA+IHdlIHJlcG9ydCBzb21ldGhpbmcgZW50ZXJlZCBieSBhbiBvcGVyYXRvciBpbiB0aGUgb3Bl cmF0aW9uYWwgDQo+ID4gZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byByZXBvcnQgb24gd2hhdCBp cyBkZXRlY3RlZD8gIElzIGl0IG5vdCANCj4gPiBiZXR0ZXIgdG8gbm90IHJlcG9ydCB0aGVtIGF0 IGFsbD8gIEluIGFuIE5NREEgY29udGV4dCBpdCB3b3VsZCBiZSANCj4gPiBwb3NzaWJsZSB0byBo YXZlIGEgZGlmZmVyZW50IHZhbHVlIChvciBubyB2YWx1ZSBhdCBhbGwpIGZvciBjZXJ0YWluIA0K PiA+IGxlYWZzIHdoaWxlIHRoZXJlIGlzIHNvbWV0aGluZyBpbiB0aGUgcnVubmluZy9pbnRlbmRl ZCBkYXRhc3RvcmUuDQo+IA0KPiBUaGUgbm9ybWFsIE5NREEgcHJvY2VkdXJlIGZvciBhIGNvbmZp Z3VyYXRpb24gbGVhZiBpcyB0byByZXBlYXQgaXQgaW4NCj4gb3BlcmF0aW9uYWwgc3RhdGUuICBU aGlzIGlzIHRoZW4gdGhlICJhcHBsaWVkIGNvbmZpZ3VyYXRpb24iLg0KPiBJIGRvbid0IHRoaW5r IHdlIHNob3VsZCBoYXZlIGEgc3BlY2lhbCBydWxlIGZvciB0aGVzZSBsZWFmcy4NCj4gDQo+IFRo aXMgYWxzbyBtZWFucyB0aGF0IGEgY2xpZW50IHRoYXQganVzdCB3YW50cyB0byByZWFkIGFsbCB0 aGUgc2VyaWFsDQo+IG51bWJlcnMgY2FuIGRvIHNvIGZyb20gb25lIHBsYWNlLCB0aGUgb3BlcmF0 aW9uYWwgc3RhdGUsIHJlZ2FyZGxlc3Mgb2YNCj4gaG93IHRoZXkgY2FtZSBpbnRvIGV4aXN0YW5j ZS4NCj4gDQo+IFtCb2dhZXJ0LCBCYXJ0IF0gDQo+IA0KPiBXZSBkbyB1bmRlcnN0YW5kIHRoYXQg YSB0YXJnZXQgb2YgTk1EQSBpcyB0byByZWFkIG91dCB0aGUgYWN0dWFsbHkNCj4gYXBwbGllZCBk YXRhIGluIG9uZSByZXF1ZXN0LiAgQnV0IHRoZSByZXN1bHQgc2hvdWxkIG5vdCBiZQ0KPiBjb25m dXNpb24uIEEga2V5IHdvcmQgaXMg4oCcYXBwbGllZOKAnS4NCj4gDQo+IFNlY3Rpb24gNS4zIG9m IGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wOSBhbHNvIGNvbnRhaW5zDQo+ IChJIHB1dCBhIHBhcnQgb2YgdGhlIHNlY3Rpb24gYmV0d2VlbiAqKiopOg0KPiBUaGUgZGF0YXN0 b3JlIHNjaGVtYSBmb3IgPG9wZXJhdGlvbmFsPiBNVVNUIGJlIGEgc3VwZXJzZXQgb2YgdGhlDQo+ IGNvbWJpbmVkIGRhdGFzdG9yZSBzY2hlbWEgdXNlZCBpbiBhbGwgY29uZmlndXJhdGlvbiBkYXRh c3RvcmVzIGV4Y2VwdA0KPiB0aGF0IGNvbmZpZ3VyYXRpb24gZGF0YSBub2RlcyBzdXBwb3J0ZWQg aW4gYSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZQ0KPiAqKipNQVkgYmUgb21pdHRlZCBmcm9tIDxv cGVyYXRpb25hbD4gaWYgYSBzZXJ2ZXIgaXMgbm90IGFibGUgdG8NCj4gYWNjdXJhdGVseSByZXBv cnQgdGhlbSAqKiouDQoNCk5vdGUgdGhhdCB0aGlzIHRleHQgdGFsa3MgYWJvdXQgdGhlICpzY2hl bWEqLiAgSXQgaXMgaW50ZW5kZWQgZm9yDQpzZXJ2ZXJzIHRvIG1pZ3JhdGUgdG8gTk1EQSB3aXRo b3V0IGhhdmluZyB0byBpbnN0cnVtZW50IGFsbCBjb25maWcNCm5vZGVzIGluIDxvcGVyYXRpb25h bD4gaW1tZWRpYXRlbHkuICBJZiB5b3UgYXBwbHkgdGhpcyB0bw0KaWV0Zi1oYXJkd2FyZSwgaXQg Y291bGQgYmUgYSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHRoZSBub2RlDQoic2VyaWFsLW51bSIg aW4gY29uZmlnLCBidXQgbm90IGluIDxvcGVyYXRpb25hbD4gKHdoaWNoIHdvdWxkIGJlDQp3ZWly ZCkuDQoNCj4gRm9yIGV4YW1wbGUsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIHZhbHVlIG9mIG11 bHRpcGxlIGxlYWZzIG5lZWQgdG8NCj4gYmUgYSBjb25zaXN0ZW50IHNldCwgZS5nLiB0aGUgbWZn LW5hbWUsIHRoZSBtb2RlbC1uYW1lLCBhbmQgdGhlDQo+IHNlcmlhbC1udW0uDQo+IFN1cHBvc2Ug d2UgaGF2ZSBhIHVzZSBjYXNlIGluIHdoaWNoIGEgaGFyZHdhcmUgY29tcG9uZW50IGlzDQo+IHBs YW5uZWQvY29uZmlndXJlZCAoZS5nLiBhIGJvYXJkIHN1cHBvcnRpbmcgRFNMIGludGVyZmFjZXMp IGJ1dCBhDQo+IGRpZmZlcmVudCBvbmUgaXMgcGx1Z2dlZCAoZS5nLiBhIGJvYXJkIHN1cHBvcnRp bmcgZXRoZXJuZXQNCj4gaW50ZXJmYWNlcykuDQo+IFN1cHBvc2UgaXQgaXMgcG9zc2libGUgdG8g cmVhZCBzb21lIGZpZWxkcyBvbiB0aGUgZGV0ZWN0ZWQgY29tcG9uZW50DQo+IGJ1dCBkdWUgdG8g YW4gaXNzdWUgbm90IHRvIHJlYWQgb3RoZXIgZmllbGRzLg0KPiBJZiBpbiB0aGF0IGNhc2UgdGhl IG9wZXJhdGlvbmFsIGRhdGFzdG9yZSB3aWxsIGJlIGNvbXBsZXRlZCB3aXRoIHRoZQ0KPiBkYXRh IHRha2VuIGZyb20gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCB0aGVuIHRoZSBwcmVzZW50ZWQgdmll dyBtaWdodA0KPiBiZSBpbmNvbnNpc3RlbnQuDQoNClRoaXMgaXMgdHJ1ZSBmb3Igb3RoZXIgc2lt aWxhciBub2RlcyBhcyB3ZWxsIC0gImFzc2V0LWlkIiBhbmQgInVyaSIuDQoNCj4gVGhlIHF1ZXN0 aW9uIGlzIGFsc286IHdoYXQgZGF0YSBpcyBhcHBsaWVkPyBPdXIgYXNzdW1wdGlvbjogaWYgdGhl cmUNCj4gaXMgYSBtaXNtYXRjaCBiZXR3ZWVuIGRldGVjdGVkIHZlcnN1cyBjb25maWd1cmVkIGhh cmR3YXJlLCB0aGVuIHRoZQ0KPiBpbnRlcmZhY2Uvc2VydmljZSByZWxhdGVkIGRhdGEgdGhhdCBp cyBjb25maWd1cmVkIGNvbnNpc3RlbnRseSB3aXRoDQo+IHRoZSBwbGFubmVkIGhhcmR3YXJlIGlz IG5vdCBhcHBsaWVkIG9uIHRoZSBtaXNtYXRjaGluZw0KPiBoYXJkd2FyZS4gSS5lLiB0aGUgZGV0 ZWN0ZWQgaGFyZHdhcmUgaXMgbm90IGJyb3VnaHQgaW4gc2VydmljZSBzbyBub3QNCj4g4oCYYXBw bGllZOKAmSwgdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBvbmx5IChhY2N1cmF0ZWx5KSByZXBv cnRzIG9uIHdoYXQNCj4gaXMgZGV0ZWN0ZWQuDQoNCklmIHRoZXJlIGlzIGEgbWlzbWF0Y2ggYW5k IHRoZSBzZXJ2ZXIgZG9lc24ndCBhcHBseSB0aGUgY29uZmlndXJlZA0KdmFsdWVzLCB0aGVuIG9i dmlvdXNseSB0aGUgY29uZmlndXJlZCAnbWZnLW5hbWUnIGV0YyBhcmUgbm90IGNvcGllZCB0bw0K PG9wZXJhdGlvbmFsPi4NCg0KPiBXZSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzcGVjaWFsIHJ1bGUg Zm9yIHRoaXMgZGF0YSBidXQgcmF0aGVyIHdvdWxkDQo+IGFwcGx5IGEgZ2VuZXJhbCBydWxlOg0K PiAtCWlmIHRoZXJlIGlzIGEg4oCYbWlzc2luZyByZXNvdXJjZeKAmSwgdGhlbiB0aGUgZGF0YSBp cyBub3QgcmVwb3J0ZWQgaW4gdGhlDQo+ICAJb3BlcmF0aW9uYWwgZGF0YXN0b3JlLg0KPiAtCUlm IHRoZSBzZXJ2ZXIgaXMgbm90IGFibGUgdG8gcmVwb3J0IGFjY3VyYXRlbHksIHRoZW4gdGhlIGRh dGEgaXMNCj4gIAlvbWl0dGVkIGZyb20gdGhlIG9wZXJhdGlvbmFsDQoNCkkgdGhpbmsgdGhhdCBp ZiB5b3Ugd2FudCBjb21wbGV0ZSBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIHZhbHVlcyBvZg0KJ21m Zy1uYW1lJywgJ21vZGVsLW5hbWUnLCBhbmQgJ3NlcmlhbC1udW0nIGluIGNvbmZpZ3VyYXRpb24g YW5kDQpvcGVyYXRpb25hbCBzdGF0ZSwgdGhlbiB0aGVzZSBzaG91bGQgYmUgbW9kZWxsZWQgYXMg c2VwYXJhdGUgbGVhZnMuDQpXZSBzaG91bGQgaGF2ZSBhIGNvbmZpZyBmYWxzZSBsZWFmICdzZXJp YWwtbnVtJyB0aGF0IG9ubHkgY29udGFpbnMgdGhlDQpkZXRlY3RlZCB2YWx1ZSAoaWYgZm91bmQp LCBhbmQgYSBjb25maWcgdHJ1ZSBsZWFmICdjb25maWctc2VyaWFsLW51bScNCm9yIHNvbWV0aGlu ZywgdGhhdCBjb250YWlucyB0aGUgY29uZmlndXJlZCBzZXJpYWwgbnVtYmVyLg0KDQpCdXQgaWYg dGhpcyBpcyB0aGUgY2FzZSwgSSB3b25kZXIgaWYgaXQgd291bGRuJ3QgYmUgYmV0dGVyIHRvIGxl YXZlDQpzdWNoIGFkZGl0aW9uYWwgY29uZmlnIG9iamVjdHMgdG8gdmVuZG9ycywgYW5kIHNpbXBs eSBtYWtlIHRoZXNlIHRocmVlDQpub2RlcyBjb25maWcgZmFsc2UgaW4gaWV0Zi1oYXJkd2FyZS4N Cg0KDQovbWFydGluDQoNCj4gDQo+IFJlZ2FyZHMsIEJhcnQNCj4gDQo+IC9tYXJ0aW4NCj4gDQo+ IA0KPiA+IA0KPiA+IEJlc3QgcmVnYXJkcywgQmFydA0KPiA+IA0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgDQo+ID4gV2lsdG9uDQo+ID4gU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDIxLCAyMDE3IDQ6MTQgUE0NCj4gPiBUbzogTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW25ldG1v ZF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wNg0KPiA+IA0KPiA+IEhp IE1hcnRpbiwNCj4gPiANCj4gPiANCj4gPiBPbiAyMS8xMi8yMDE3IDExOjM3LCBNYXJ0aW4gQmpv cmtsdW5kIHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4gSSBuZWVkIFdHIGlucHV0IG9u IHRoaXMgaXNzdWUuICBUaGUgcXVlc3Rpb24gaXMgaG93IHRvIGhhbmRsZSANCj4gPiA+ICdzZXJp YWwtbnVtJywgJ21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJy4gIEkgdGhpbmsgdGhleSBzaG91 bGQgYWxsIA0KPiA+ID4gYmUgdHJlYXRlZCB0aGUgc2FtZS4gIEJhc2VkIG9uIHByZXZpb3VzIFdH IGRpc2N1c3Npb24gKHNlZSBlLmcuIHRoZSANCj4gPiA+IG1haWwgdGhyZWFkICJkcmFmdC1pZXRm LW5ldG1vZC1lbnRpdHkgaXNzdWUgIzEzIiksIEkgdGhpbmsgdGhleSANCj4gPiA+IHNob3VsZCBh bGwgYmUgY29uZmlndXJhYmxlLCBidXQgdGhlIGNvbmZpZ3VyZWQgdmFsdWUgaXMgb25seSB1c2Vk IGluIA0KPiA+ID4gb3BlcmF0aW9uYWwgc3RhdGUgaWYgdGhlIHN5c3RlbSBjYW5ub3QgcmVhZCBp dCBmcm9tIHRoZSBoYXJkd2FyZS4NCj4gPiBJIHRoaW5rIHRoYXQgdGhpcyBhcHByb2FjaCBpcyBw cm9iYWJseSBPSzoNCj4gPiAgwqAtIFRoZSBjbGllbnQgY2FuIGFsd2F5cyBzZWUgdGhlIHJlYWwg dmFsdWUgaWYgaXQgaXMgYXZhaWxhYmxlLg0KPiA+ICDCoC0gSWYgaXQgaXMgbm90IGF2YWlsYWJs ZSB0aGVuIHRoZXkgY2FuIGFzc2lnbiBhIHZhbHVlIHZpYSAgDQo+ID4gY29uZmlndXJhdGlvbi4N Cj4gPiANCj4gPiBJIHdhcyBhbHNvIGNvbnNpZGVyaW5nIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNo IG9mIGhhdmluZyBhIHNlcGFyYXRlIA0KPiA+IHNldCBvZiBjb25maWcgZmFsc2UgbGVhdmVzIGZv ciB0aGUgImJ1cm50IGluIHZhbHVlcyIuwqAgQW5kIHRoZW4gaGF2aW5nDQo+ID4gdGhlIGNvbmZp Z3VyYWJsZSBsZWF2ZXMgYWx3YXlzIG92ZXJyaWRlIHRoZSBkZWZhdWx0IG9wZXJhdGlvbmFsIA0K PiA+IHZhbHVlcy4gRS5nLiBzaW1pbGFyIHRvIGhvdyBhbiBpbnRlcmZhY2UgTUFDIGFkZHJlc3Mg d291bGQgZXhwZWN0IHRvIA0KPiA+IGJlIGhhbmRsZWQuDQo+ID4gDQo+ID4gQnV0IG9uZSBzZXQg b2YgbGVhdmVzIGlzIHByb2JhYmx5IHN1ZmZpY2llbnQuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+ IFJvYg0KPiA+IA0KPiA+IA0KPiA+ID4NCj4gPiA+IFNvIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5n IGNoYW5nZXM6DQo+ID4gPg0KPiA+ID4gT0xEOg0KPiA+ID4NCj4gPiA+ICAgICAgICBsZWFmIHNl cmlhbC1udW0gew0KPiA+ID4gICAgICAgICAgdHlwZSBzdHJpbmc7DQo+ID4gPiAgICAgICAgICBj b25maWcgZmFsc2U7DQo+ID4gPiAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAg ICAiVGhlIHZlbmRvci1zcGVjaWZpYyBzZXJpYWwgbnVtYmVyIHN0cmluZyBmb3IgdGhlDQo+ID4g PiAgICAgICAgICAgICBjb21wb25lbnQuICBUaGUgcHJlZmVycmVkIHZhbHVlIGlzIHRoZSBzZXJp YWwgbnVtYmVyDQo+ID4gPiAgICAgICAgICAgICBzdHJpbmcgYWN0dWFsbHkgcHJpbnRlZCBvbiB0 aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4gPiA+ICAgICAgICAgICAgIHByZXNlbnQpLiI7DQo+ ID4gPiAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzOiBlbnRQaHlzaWNhbFNlcmlhbE51bSI7 DQo+ID4gPiAgICAgICAgfQ0KPiA+ID4NCj4gPiA+IE5FVzoNCj4gPiA+DQo+ID4gPiAgICAgICAg bGVhZiBzZXJpYWwtbnVtIHsNCj4gPiA+ICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiA+ID4gICAg ICAgICAgZGVzY3JpcHRpb24NCj4gPiA+ICAgICAgICAgICAgIlRoZSB2ZW5kb3Itc3BlY2lmaWMg c2VyaWFsIG51bWJlciBzdHJpbmcgZm9yIHRoZQ0KPiA+ID4gICAgICAgICAgICAgY29tcG9uZW50 LiAgVGhlIHByZWZlcnJlZCB2YWx1ZSBpcyB0aGUgc2VyaWFsIG51bWJlcg0KPiA+ID4gICAgICAg ICAgICAgc3RyaW5nIGFjdHVhbGx5IHByaW50ZWQgb24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlm DQo+ID4gPiAgICAgICAgICAgICBwcmVzZW50KS4NCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICBU aGlzIGxlYWYgY2FuIGJlIGNvbmZpZ3VyZWQuICBUaGVyZSBhcmUgdHdvIHVzZSBjYXNlcyBmb3IN Cj4gPiA+ICAgICAgICAgICAgIHRoaXM7IGFzIGEgJ3Bvc3QtaXQnIG5vdGUgaWYgdGhlIHNlcnZl ciBjYW5ub3QgZGV0ZXJtaW5lDQo+ID4gPiAgICAgICAgICAgICB0aGlzIHZhbHVlIGZyb20gdGhl IGNvbXBvbmVudCwgb3Igd2hlbiBwcmUtcHJvdmlzaW9uaW5nIGENCj4gPiA+ICAgICAgICAgICAg IGNvbXBvbmVudC4NCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICBJZiB0aGUgc2VydmVyIGNhbiBk ZXRlcm1pbmUgdGhlIHNlcmlhbCBudW1iZXIgZnJvbSB0aGUNCj4gPiA+ICAgICAgICAgICAgIGNv bXBvbmVudCwgdGhlbiB0aGF0IHZhbHVlIGlzIGFsd2F5cyB1c2VkIGluIG9wZXJhdGlvbmFsDQo+ ID4gPiAgICAgICAgICAgICBzdGF0ZSwgZXZlbiBpZiBhbm90aGVyIHZhbHVlIGhhcyBiZWVuIGNv bmZpZ3VyZWQuIjsNCj4gPiA+ICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6IGVudFBoeXNp Y2FsU2VyaWFsTnVtIjsNCj4gPiA+ICAgICAgICB9DQo+ID4gPg0KPiA+ID4gQW5kIGNvcnJlc3Bv bmRpbmcgdGV4dCBmb3IgJ21mZy1uYW1lJyBhbmQgJ21vZGVsLW5hbWUnLg0KPiA+ID4NCj4gPiA+ IEFuZCBhbHNvOg0KPiA+ID4NCj4gPiA+IE9MRDoNCj4gPiA+DQo+ID4gPiAgICAgICAgICAgV2hl biB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9uZW50LCBpdA0KPiA+ID4g ICAgICAgICAgIGluaXRpYWxpemVzIGEgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3Rh dGUuDQo+ID4gPg0KPiA+ID4gICAgICAgICAgIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9y dCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gPiAgICAgICAgICAgY29tcG9uZW50cywg bGlzdCBlbnRyaWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBhcmUNCj4gPiA+ICAgICAgICAg ICBpbml0aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5IHRo ZQ0KPiA+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9uLg0KPiA+ID4NCj4gPiA+ICAgICAgICAg ICBPdGhlcndpc2UsIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIGlzIGZvbGxvd2VkOg0KPiA+ID4N Cj4gPiA+ICAgICAgICAgICAgIDEuIElmIHRoZXJlIGlzIGFuIGVudHJ5IGluIHRoZSAvaGFyZHdh cmUvY29tcG9uZW50IGxpc3QgaW4NCj4gPiA+ICAgICAgICAgICAgICAgIHRoZSBpbnRlbmRlZCBj b25maWd1cmF0aW9uIHdpdGggdmFsdWVzIGZvciB0aGUgbm9kZXMNCj4gPiA+ICAgICAgICAgICAg ICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRv DQo+ID4gPiAgICAgICAgICAgICAgICB0aGUgZGV0ZWN0ZWQgdmFsdWVzLCB0aGVuOg0KPiA+ID4N Cj4gPiA+ICAgICAgICAgICAgIDFhLiBJZiB0aGUgY29uZmlndXJlZCBlbnRyeSBoYXMgYSB2YWx1 ZSBmb3IgJ21mZy1uYW1lJw0KPiA+ID4gICAgICAgICAgICAgICAgIHRoYXQgaXMgZXF1YWwgdG8g dGhlIGRldGVjdGVkIHZhbHVlLCBvciBpZiB0aGUNCj4gPiA+ICAgICAgICAgICAgICAgICAnbWZn LW5hbWUnIHZhbHVlIGNhbm5vdCBiZSBkZXRlY3RlZCwgdGhlbiB0aGUgbGlzdA0KPiA+ID4gICAg ICAgICAgICAgICAgIGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcyBpbml0aWFsaXpl ZCB3aXRoIHRoZQ0KPiA+ID4gICAgICAgICAgICAgICAgIGNvbmZpZ3VyZWQgdmFsdWVzIGZvciBh bGwgY29uZmlndXJlZCBub2RlcywgaW5jbHVkaW5nDQo+ID4gPiAgICAgICAgICAgICAgICAgdGhl ICduYW1lJy4NCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgbGlz dCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiA+ICAgICAgICAgICAgICAg ICBpbml0aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5DQo+ ID4gPiAgICAgICAgICAgICAgICAgdGhlIGltcGxlbWVudGF0aW9uLiAgVGhlIGltcGxlbWVudGF0 aW9uIG1heSByYWlzZSBhbg0KPiA+ID4gICAgICAgICAgICAgICAgIGFsYXJtIHRoYXQgaW5mb3Jt cyBhYm91dCB0aGUgJ21mZy1uYW1lJyBtaXNtYXRjaA0KPiA+ID4gICAgICAgICAgICAgICAgIGNv bmRpdGlvbi4gIEhvdyB0aGlzIGlzIGRvbmUgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YNCj4gPiA+ ICAgICAgICAgICAgICAgICB0aGlzIGRvY3VtZW50Lg0KPiA+ID4NCj4gPiA+ICAgICAgICAgICAg IDFiLiBPdGhlcndpc2UgKGkuZS4sIHRoZXJlIGlzIG5vIG1hdGNoaW5nIGNvbmZpZ3VyYXRpb24N Cj4gPiA+ICAgICAgICAgICAgICAgICBlbnRyeSksIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVy YXRpb25hbCBzdGF0ZSBpcw0KPiA+ID4gICAgICAgICAgICAgICAgIGluaXRpYWxpemVkIHdpdGgg dmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4gPiA+ICAgICAgICAgICAgICAg ICB0aGUgaW1wbGVtZW50YXRpb24uDQo+ID4gPg0KPiA+ID4gICAgICAgICAgIElmIHRoZSAvaGFy ZHdhcmUvY29tcG9uZW50IGxpc3QgaW4gdGhlIGludGVuZGVkDQo+ID4gPiAgICAgICAgICAgY29u ZmlndXJhdGlvbiBpcyBtb2RpZmllZCwgdGhlbiB0aGUgc3lzdGVtIE1VU1QgYmVoYXZlIGFzIGlm DQo+ID4gPiAgICAgICAgICAgaXQgcmUtaW5pdGlhbGl6ZXMgaXRzZWxmLCBhbmQgZm9sbG93IHRo ZSBwcm9jZWR1cmUgaW4gDQo+ID4gPiAoMSkuIjsNCj4gPiA+DQo+ID4gPiBORVc6DQo+ID4gPg0K PiA+ID4gICAgICAgICAgIFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGEgbmV3IGhhcmR3YXJlIGNv bXBvbmVudCwgaXQNCj4gPiA+ICAgICAgICAgICBpbml0aWFsaXplcyBhIGxpc3QgZW50cnkgaW4g dGhlIG9wZXJhdGlvbmFsIHN0YXRlLg0KPiA+ID4NCj4gPiA+ICAgICAgICAgICBJZiB0aGUgc2Vy dmVyIGRvZXMgbm90IHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBoYXJkd2FyZQ0KPiA+ID4gICAg ICAgICAgIGNvbXBvbmVudHMsIGxpc3QgZW50cmllcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUg YXJlDQo+ID4gPiAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBub2Rl cyBhcyBkZXRlY3RlZCBieSB0aGUNCj4gPiA+ICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi4NCj4g PiA+DQo+ID4gPiAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5nIHByb2NlZHVyZSBp cyBmb2xsb3dlZDoNCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICAxLiBJZiB0aGVyZSBpcyBhbiBl bnRyeSBpbiB0aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluDQo+ID4gPiAgICAgICAgICAg ICAgICB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiB3aXRoIHZhbHVlcyBmb3IgdGhlIG5vZGVz DQo+ID4gPiAgICAgICAgICAgICAgICAnY2xhc3MnLCAncGFyZW50JywgJ3BhcmVudC1yZWwtcG9z JyB0aGF0IGFyZSBlcXVhbCB0bw0KPiA+ID4gICAgICAgICAgICAgICAgdGhlIGRldGVjdGVkIHZh bHVlcywgdGhlbiB0aGUgbGlzdCBlbnRyeSBpbiBvcGVyYXRpb25hbA0KPiA+ID4gICAgICAgICAg ICAgICAgc3RhdGUgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUgY29uZmlndXJlZCB2YWx1ZXMsDQo+ ID4gPiAgICAgICAgICAgICAgICBpbmNsdWRpbmcgdGhlICduYW1lJy4gIFRoZSBsZWFmcyAnc2Vy aWFsLW51bScsDQo+ID4gPiAgICAgICAgICAgICAgICAnbWZnLW5hbWUnLCBhbmQgJ21vZGVsLW5h bWUnIGFyZSB0cmVhdGVkIHNwZWNpYWxseTsgc2VlDQo+ID4gPiAgICAgICAgICAgICAgICB0aGVp ciBkZXNjcmlwdGlvbnMgZm9yIGRldGFpbHMuDQo+ID4gPg0KPiA+ID4gICAgICAgICAgICAgMi4g T3RoZXJ3aXNlIChpLmUuLCB0aGVyZSBpcyBubyBtYXRjaGluZyBjb25maWd1cmF0aW9uDQo+ID4g PiAgICAgICAgICAgICAgICBlbnRyeSksIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25h bCBzdGF0ZSBpcw0KPiA+ID4gICAgICAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMg Zm9yIGFsbCBub2RlcyBhcyBkZXRlY3RlZCBieQ0KPiA+ID4gICAgICAgICAgICAgICAgdGhlIGlt cGxlbWVudGF0aW9uLg0KPiA+ID4NCj4gPiA+ICAgICAgICAgICBJZiB0aGUgL2hhcmR3YXJlL2Nv bXBvbmVudCBsaXN0IGluIHRoZSBpbnRlbmRlZA0KPiA+ID4gICAgICAgICAgIGNvbmZpZ3VyYXRp b24gaXMgbW9kaWZpZWQsIHRoZW4gdGhlIHN5c3RlbSBNVVNUIGJlaGF2ZSBhcyBpZg0KPiA+ID4g ICAgICAgICAgIGl0IHJlLWluaXRpYWxpemVzIGl0c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2Vk dXJlIGluIA0KPiA+ID4gKDEpLiI7DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAvbWFydGlu DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQmVub2l0IENsYWlzZSA8YmNsYWlz ZUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4+IE9uIDEyLzIwLzIwMTcgNDowMCBQTSwgTWFydGlu IEJqb3JrbHVuZCB3cm90ZToNCj4gPiA+Pj4gQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5j b20+IHdyb3RlOg0KPiA+ID4+Pj4gSGkgTWFydGluLA0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFRoYW5r cy4NCj4gPiA+Pj4+IE9ubHkga2VwdCB0aGUgcmVsZXZhbnQgZXhjZXJwdHMuDQo+ID4gPj4+Pj4+ IC0gU29tZSBvYmplY3RzIGFyZSByZWFkLXdyaXRlIGluIFJGQzY5MzM6DQo+ID4gPj4+Pj4+ICAg ICAgICAgIGVudFBoeXNpY2FsU2VyaWFsTnVtDQo+ID4gPj4+Pj4+ICAgICAgICAgIGVudFBoeXNp Y2FsQWxpYXMNCj4gPiA+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxBc3NldElEDQo+ID4gPj4+ Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsVXJpcw0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBGb3Ig ZXhhbXBsZSwgZW50UGh5c2ljYWxTZXJpYWxOdW0gYmVpbmcgcmVhZC13cml0ZSBhbHdheXMgYm90 aGVyZWQNCj4gPiA+Pj4+Pj4gbWUuDQo+ID4gPj4+Pj4+IHNlcmlhbC1udW0gaXMgbm93ICJjb25m aWcgZmFsc2UiLCB3aGljaCBpcyBhIGdvb2QgbmV3cyBJTU8uDQo+ID4gPj4+Pj4gQWN0dWFsbHks IHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLiAgSW4NCj4gPiA+Pj4+PiBkcmFmdC1pZXRmLW5l dG1vZC1lbnRpdHktMDMgdGhpcyBpcyBjb25maWd1cmFibGUuICBJIG1pc3NlZCB0aGlzIA0KPiA+ ID4+Pj4+IGluIHRoZSBjb252ZXJzaW9uIHRvIE5NREEuDQo+ID4gPj4+PiBBaC4gU28gbm8gZ29v ZCBuZXdzIGluIHRoaXMgY2FzZS4uLg0KPiA+ID4+Pj4+PiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rp b24sIGVudFBoeXNpY2FsTWZnTmFtZSBpcyByZWFkLW9ubHkgaW4gDQo+ID4gPj4+Pj4+IFJGQzY5 MzMsIHdoaWxlIGl0J3MgImNvbmZpZyB0cnVlIiBpbiBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHkN Cj4gPiA+Pj4+PiBZZXMsIHRoaXMgd2FzIGFkZGVkIHBlciByZXF1ZXN0IGZyb20gdGhlIFdHLiAg U2VlIGUuZy4gdGhlIA0KPiA+ID4+Pj4+IHRocmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5 IGlzc3VlICMxMyIuDQo+ID4gPj4+PiBTdXJlLiBJdCB3YXMgbWFpbmx5IGFuIG9ic2VydmF0aW9u Lg0KPiA+ID4+Pj4+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCB3aGF0IHdlIGhhdmUgbm93IGlzIHBy b2JhYmx5IG5vdCBjb3JyZWN0LiAgDQo+ID4gPj4+Pj4gSSB0aGluayB0aGF0IGFsbCBub2RlcyAn c2VyaWFsLW51bScsICdtZmctbmFtZScsIGFuZCAnbW9kZWwtbmFtZScNCj4gPiA+Pj4+PiBzaG91 bGQgYmUgY29uZmlnIHRydWUsIGFuZCB0aGUgZGVzY3JpcHRpb24gb2YgbGlzdCAnY29tcG9uZW50 JyANCj4gPiA+Pj4+PiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhhdCBhbGwgdGhlc2UgdHJlZSBsZWFm cyBhcmUgaGFuZGxlZCB0aGUgc2FtZSB3YXkuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJIHdvdWxk IGxpa2UgdG8ga25vdyB3aGF0IHRoZSBXRyB0aGlua3MgYWJvdXQgdGhpcy4NCj4gPiA+Pj4+IFRh bGtpbmcgYXMgYSBjb250cmlidXRvciB0aGlzIHRpbWUuDQo+ID4gPj4+PiBJdCBzZWVtcyB0aGF0 IGludmVudG9yeSBtYW5hZ2VtZW50IGlzIGtpbmQgb2YgYnJva2VuIHdoZW4gc29tZW9uZSANCj4g PiA+Pj4+IGNhbiBjaGFuZ2UgJ3NlcmlhbC1udW0nLCAnbWZnLW5hbWUnLCBhbmQgJ21vZGVsLW5h bWUuDQo+ID4gPj4+IFRoZXkgY2FuJ3QgcmVhbGx5IGNoYW5nZSB0aGVtLiAgVGhlIGNvbmZpZ3Vy ZWQgdmFsdWVzIGFyZSBvbmx5IA0KPiA+ID4+PiB1c2VkIChpLmUuIHZpc2libGUgaW4gdGhlIG9w ZXJhdGlvbmFsIHN0YXRlKSBpZiB0aGUgZGV2aWNlIGNhbm5vdCANCj4gPiA+Pj4gZGV0ZWN0IHRo ZW0gYXV0b21hdGljYWxseS4gIEkuZS4sIHRoZXkgd29yayBhcyAicG9zdC1pdCIgbm90ZXMgb25s eS4NCj4gPiA+PiBJZiBJIGxvb2sgYXQsIGZvciBleGFtcGxlLCB0aGUgbWZnLW5hbWUsIGRlc2Ny aXB0aW9uLCB0aGlzIGlzIG5vdCANCj4gPiA+PiB3aGF0IGl0IHNheXMuDQo+ID4gPj4NCj4gPiA+ PiAgICAgbGVhZiBtZmctbmFtZSB7DQo+ID4gPj4gICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQo+ ID4gPj4gICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiA+PiAgICAgICAgICAgICAgICJUaGUg bmFtZSBvZiB0aGUgbWFudWZhY3R1cmVyIG9mIHRoaXMgcGh5c2ljYWwgY29tcG9uZW50Lg0KPiA+ ID4+ICAgICAgICAgICAgICAgIFRoZSBwcmVmZXJyZWQgdmFsdWUgaXMgdGhlIG1hbnVmYWN0dXJl ciBuYW1lIHN0cmluZw0KPiA+ID4+ICAgICAgICAgICAgICAgIGFjdHVhbGx5IHByaW50ZWQgb24g dGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmIHByZXNlbnQpLg0KPiA+ID4+DQo+ID4gPj4gICAgICAg ICAgICAgICAgTm90ZSB0aGF0IGNvbXBhcmlzb25zIGJldHdlZW4gaW5zdGFuY2VzIG9mIHRoZSBt b2RlbC1uYW1lLA0KPiA+ID4+ICAgICAgICAgICAgICAgIGZpcm13YXJlLXJldiwgc29mdHdhcmUt cmV2LCBhbmQgdGhlIHNlcmlhbC1udW0gbm9kZXMgYXJlDQo+ID4gPj4gICAgICAgICAgICAgICAg b25seSBtZWFuaW5nZnVsIGFtb25nc3QgY29tcG9uZW50IHdpdGggdGhlIHNhbWUgdmFsdWUgb2YN Cj4gPiA+PiAgICAgICAgICAgICAgICBtZmctbmFtZS4NCj4gPiA+Pg0KPiA+ID4+ICAgICAgICAg ICAgICAgIElmIHRoZSBtYW51ZmFjdHVyZXIgbmFtZSBzdHJpbmcgYXNzb2NpYXRlZCB3aXRoIHRo ZQ0KPiA+ID4+ICAgICAgICAgICAgICAgIHBoeXNpY2FsIGNvbXBvbmVudCBpcyB1bmtub3duIHRv IHRoZSBzZXJ2ZXIsIHRoZW4gdGhpcw0KPiA+ID4+ICAgICAgICAgICAgICAgIG5vZGUgaXMgbm90 IGluc3RhbnRpYXRlZC4iOw0KPiA+ID4+ICAgICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzMg PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTMzPjoNCj4gPiA+PiAgICAgICAgICAg ICBlbnRQaHlzaWNhbE1mZ05hbWUiOw0KPiA+ID4+DQo+ID4gPj4gUmVnYXJkcywgQmVub2l0DQo+ ID4gPj4NCj4gPiA+Pj4NCj4gPiA+Pj4gL21hcnRpbg0KPiA+ID4+PiAuDQo+ID4gPj4+DQo+ID4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g bmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ID4gLg0KPiA+ID4NCj4g PiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Jan 10 05:52: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 2E0141275FD for ; Wed, 10 Jan 2018 05:52:04 -0800 (PST) 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_RP_MATCHES_RCVD=-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 m-3x_Ueq10AG for ; Wed, 10 Jan 2018 05:52:01 -0800 (PST) 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 A037412420B for ; Wed, 10 Jan 2018 05:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14094; q=dns/txt; s=iport; t=1515592320; x=1516801920; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JmNzYVVKpw+TAmvHseC4X+IGiEjUyzpiex1sU4ySDmg=; b=hm+SrFWDDtMcyfbEfMbxE0aZFnogn3kj2wOwDThxifkOdMoJokO12hVD PWy2fOeqGFOxIA5qXoEyLJr3NgqagT+tZ0BiHMGq6pGP5bZrft8uKWUuT AuIHicTJrbFDBJiiRHz1xus7hfmQgvmLilsDZtNFnwW2PcBrxh2pananL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQAuGVZa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEB4sYj0MnfJhJChgLgV6Ca08ChQMUAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBAQECAQEBIQ8BBTYLDAQLEQQBAQECAiMDAgInHwkIBgEMBgIBARaKEQgQr?= =?us-ascii?q?m6CJ4o0AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4MRg2yBaSkMgWtYNoMvAQE?= =?us-ascii?q?CAYFOAQEIgy2CZQWKY4dEkT2IC406ghiKCyaHRY07gV6ICIE8NiIlgSsyGggbF?= =?us-ascii?q?T2CKoRXQTeJJII8AQEB?= X-IronPort-AV: E=Sophos;i="5.46,340,1511827200"; d="scan'208";a="1377783" 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; 10 Jan 2018 13:51:58 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0ADpvaU004491; Wed, 10 Jan 2018 13:51:58 GMT To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Martin Bjorklund Cc: "netmod@ietf.org" References: <20171221.123746.382540578845045602.mbj@tail-f.com> <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com> <20180109.163933.49682684192910889.mbj@tail-f.com> From: Robert Wilton Message-ID: <3174d547-0480-798e-c25b-42ebc0f64359@cisco.com> Date: Wed, 10 Jan 2018 13:51:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 13:52:04 -0000 Hi, On 10/01/2018 13:12, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hi, > > --- snip --- > >> state.”, so the above sentence only applies for the second case below. > Ok. > >> 2. The second case is that something is detected but it can’t be read. >> We do not see a reason to use the value configured for the leafs >> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the >> configuration data. These leafs are defined as optional so why would >> we report something entered by an operator in the operational >> datastore that intends to report on what is detected? Is it not >> better to not report them at all? In an NMDA context it would be >> possible to have a different value (or no value at all) for certain >> leafs while there is something in the running/intended datastore. > The normal NMDA procedure for a configuration leaf is to repeat it in operational state. This is then the "applied configuration". > I don't think we should have a special rule for these leafs. > > This also means that a client that just wants to read all the serial numbers can do so from one place, the operational state, regardless of how they came into existance. > > [Bogaert, Bart ] > > We do understand that a target of NMDA is to read out the actually applied data in one request. But the result should not be confusion. A key word is “applied”. > > Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains (I put a part of the section between ***): > The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that configuration data nodes supported in a configuration datastore ***MAY be omitted from if a server is not able to accurately report them ***. > > For example, it is expected that the value of multiple leafs need to be a consistent set, e.g. the mfg-name, the model-name, and the serial-num. > Suppose we have a use case in which a hardware component is planned/configured (e.g. a board supporting DSL interfaces) but a different one is plugged (e.g. a board supporting ethernet interfaces). > Suppose it is possible to read some fields on the detected component but due to an issue not to read other fields. > If in that case the operational datastore will be completed with the data taken from the running datastore, then the presented view might be inconsistent. > The question is also: what data is applied? Our assumption: if there is a mismatch between detected versus configured hardware, then the interface/service related data that is configured consistently with the planned hardware is not applied on the mismatching hardware. I.e. the detected hardware is not brought in service so not ‘applied’, the operational datastore only (accurately) reports on what is detected. > > We do not see this as a special rule for this data but rather would apply a general rule: > - if there is a ‘missing resource’, then the data is not reported in the operational datastore. > - If the server is not able to report accurately, then the data is omitted from the operational I was thinking that this would be a special case where a "system" provided value has precedence over an explicitly configured value:  - If the hardware has a value, then that is what is reported with origin "system".  - If the hardware has no value, but one is configured, then the configured value is reported with origin "intended".  - If the hardware has no value, and none is configured, then no value is reported. I see the aim of this approach is to provide the "in use" value on a single path. But it may be helpful to have a second sets of 3 leaves here that report the "burnt-in" information.  These would always report what values are read from hardware, or nothing if no value was available. (this is similar to what we are doing for Ethernet MAC address). An alternative approach would be to split the configured and operational values entirely, but then the client has the hassle of having to read/combine the two values together to get the useful "in use" value. Thanks, Rob > > Regards, Bart > > /martin > > >> Best regards, Bart >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >> Wilton >> Sent: Thursday, December 21, 2017 4:14 PM >> To: Martin Bjorklund ; netmod@ietf.org >> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >> >> Hi Martin, >> >> >> On 21/12/2017 11:37, Martin Bjorklund wrote: >>> Hi, >>> >>> I need WG input on this issue. The question is how to handle >>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>> be treated the same. Based on previous WG discussion (see e.g. the >>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>> should all be configurable, but the configured value is only used in >>> operational state if the system cannot read it from the hardware. >> I think that this approach is probably OK: >>  - The client can always see the real value if it is available. >>  - If it is not available then they can assign a value via >> configuration. >> >> I was also considering an alternative approach of having a separate >> set of config false leaves for the "burnt in values".  And then having >> the configurable leaves always override the default operational >> values. E.g. similar to how an interface MAC address would expect to >> be handled. >> >> But one set of leaves is probably sufficient. >> >> Thanks, >> Rob >> >> >>> So I suggest the following changes: >>> >>> OLD: >>> >>> leaf serial-num { >>> type string; >>> config false; >>> description >>> "The vendor-specific serial number string for the >>> component. The preferred value is the serial number >>> string actually printed on the component itself (if >>> present)."; >>> reference "RFC 6933: entPhysicalSerialNum"; >>> } >>> >>> NEW: >>> >>> leaf serial-num { >>> type string; >>> description >>> "The vendor-specific serial number string for the >>> component. The preferred value is the serial number >>> string actually printed on the component itself (if >>> present). >>> >>> This leaf can be configured. There are two use cases for >>> this; as a 'post-it' note if the server cannot determine >>> this value from the component, or when pre-provisioning a >>> component. >>> >>> If the server can determine the serial number from the >>> component, then that value is always used in operational >>> state, even if another value has been configured."; >>> reference "RFC 6933: entPhysicalSerialNum"; >>> } >>> >>> And corresponding text for 'mfg-name' and 'model-name'. >>> >>> And also: >>> >>> OLD: >>> >>> When the server detects a new hardware component, it >>> initializes a list entry in the operational state. >>> >>> If the server does not support configuration of hardware >>> components, list entries in the operational state are >>> initialized with values for all nodes as detected by the >>> implementation. >>> >>> Otherwise, the following procedure is followed: >>> >>> 1. If there is an entry in the /hardware/component list in >>> the intended configuration with values for the nodes >>> 'class', 'parent', 'parent-rel-pos' that are equal to >>> the detected values, then: >>> >>> 1a. If the configured entry has a value for 'mfg-name' >>> that is equal to the detected value, or if the >>> 'mfg-name' value cannot be detected, then the list >>> entry in the operational state is initialized with the >>> configured values for all configured nodes, including >>> the 'name'. >>> >>> Otherwise, the list entry in the operational state is >>> initialized with values for all nodes as detected by >>> the implementation. The implementation may raise an >>> alarm that informs about the 'mfg-name' mismatch >>> condition. How this is done is outside the scope of >>> this document. >>> >>> 1b. Otherwise (i.e., there is no matching configuration >>> entry), the list entry in the operational state is >>> initialized with values for all nodes as detected by >>> the implementation. >>> >>> If the /hardware/component list in the intended >>> configuration is modified, then the system MUST behave as if >>> it re-initializes itself, and follow the procedure in >>> (1)."; >>> >>> NEW: >>> >>> When the server detects a new hardware component, it >>> initializes a list entry in the operational state. >>> >>> If the server does not support configuration of hardware >>> components, list entries in the operational state are >>> initialized with values for all nodes as detected by the >>> implementation. >>> >>> Otherwise, the following procedure is followed: >>> >>> 1. If there is an entry in the /hardware/component list in >>> the intended configuration with values for the nodes >>> 'class', 'parent', 'parent-rel-pos' that are equal to >>> the detected values, then the list entry in operational >>> state is initialized with the configured values, >>> including the 'name'. The leafs 'serial-num', >>> 'mfg-name', and 'model-name' are treated specially; see >>> their descriptions for details. >>> >>> 2. Otherwise (i.e., there is no matching configuration >>> entry), the list entry in the operational state is >>> initialized with values for all nodes as detected by >>> the implementation. >>> >>> If the /hardware/component list in the intended >>> configuration is modified, then the system MUST behave as if >>> it re-initializes itself, and follow the procedure in >>> (1)."; >>> >>> >>> >>> /martin >>> >>> >>> >>> >>> Benoit Claise wrote: >>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>> Benoit Claise wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks. >>>>>> Only kept the relevant excerpts. >>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>> entPhysicalSerialNum >>>>>>>> entPhysicalAlias >>>>>>>> entPhysicalAssetID >>>>>>>> entPhysicalUris >>>>>>>> >>>>>>>> For example, entPhysicalSerialNum being read-write always bothered me. >>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>> Actually, this was not the intention. In >>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>> in the conversion to NMDA. >>>>>> Ah. So no good news in this case... >>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>> Sure. It was mainly an observation. >>>>>>> However, I think that what we have now is probably not correct. >>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' >>>>>>> should be config true, and the description of list 'component' >>>>>>> updated to reflect that all these tree leafs are handled the same way. >>>>>>> >>>>>>> I would like to know what the WG thinks about this. >>>>>> Talking as a contributor this time. >>>>>> It seems that inventory management is kind of broken when someone >>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>> They can't really change them. The configured values are only >>>>> used (i.e. visible in the operational state) if the device cannot >>>>> detect them automatically. I.e., they work as "post-it" notes only. >>>> If I look at, for example, the mfg-name, description, this is not >>>> what it says. >>>> >>>> leaf mfg-name { >>>> type string; >>>> description >>>> "The name of the manufacturer of this physical component. >>>> The preferred value is the manufacturer name string >>>> actually printed on the component itself (if present). >>>> >>>> Note that comparisons between instances of the model-name, >>>> firmware-rev, software-rev, and the serial-num nodes are >>>> only meaningful amongst component with the same value of >>>> mfg-name. >>>> >>>> If the manufacturer name string associated with the >>>> physical component is unknown to the server, then this >>>> node is not instantiated."; >>>> reference "RFC 6933 : >>>> entPhysicalMfgName"; >>>> >>>> Regards, Benoit >>>> >>>>> /martin >>>>> . >>>>> >>> _______________________________________________ >>> 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 Wed Jan 10 07:01:10 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 A068E12751F for ; Wed, 10 Jan 2018 07:01:04 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7rsrpTyhJ9IR for ; Wed, 10 Jan 2018 07:01:02 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 38DEA1271FD for ; Wed, 10 Jan 2018 07:01:00 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id c78so3366233ywb.13 for ; Wed, 10 Jan 2018 07:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=i/lkokqJSs6tC9dOkWUqLPmJuzKlt5lwy5IE5v1wxNs=; b=H/Lh0OHrfWXDvP4hF4hJLyVGAZ8c4DL6OhZ1h/RjZFzs0+BX6aa0N5PR8lBxc+xlSS LQvXRmael8H0q8gpVkfe6rChmRKdwR3IMvEqRh7YYLZF6atRWJVI1YTSuOq8e8NuRPXq 9XyxWEK3QS0hT5afo6j/Do7+AN0XUzAuLyPZavNLRmqWwSoH2EuhXSn33UYFWSLy6kru PXWpe71VT5eXITS4sapE5NfaoGA2/EC2GFswdaiNd8vVhfoenstOfR46yXYG8m5uUfMQ pJKV+o8eGbEFzQDM179ZoViB7sQbiWKOZSuBSHC++qlj3oe3hRr5+wKgNwJdnwK5Woh2 lWTw== 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=i/lkokqJSs6tC9dOkWUqLPmJuzKlt5lwy5IE5v1wxNs=; b=JMUnFq1eF0Y0aAPDWCAkV0CEQteMsMBktYeAugr/6OCtGWuT5XDdY8ElGz/PucTCGz T4ptqL5yFW9s2mbBvbOP+J19TMQQDAfDb3nE2D7mGMuIEwvJQDMu82gyEf4JW0nvJkzp cvZ+B3YDMqPZy+z9B5ns0+jFyCFCczo1A9WD6dN/RGWHHC6AnpKT5aVOLPyyB3IcMQ+i UE7y9K/EKxCngRrLQuX6ExbRSGv9Pq3BY+rq0oMOOepmHXgJGGavfsS7vu5I4vtJTv// cczrNCOMBmXS/mG3r/WTjyqyUymp9T25Hk9M/Xqd1jp4HcBWpmIel6H8zBLapeLnyHw4 hEjg== X-Gm-Message-State: AKGB3mKrMkMXf2ZWfD2gMhu4EV7DHPLAQPuppphDJyvn8KpfH9No79qc HOn1lQhIuBPUh8F3QN+8TSLlfAockOFa6ZYSdXP1Lw== X-Google-Smtp-Source: ACJfBot5eotPV9xC9luW34YKgpi/wWs2a39j7hG7QzaUsJSQ3tXPM9aTOF2r6D7PIqomVGs/aYUriE8wMlIK9jpYRek= X-Received: by 10.129.161.16 with SMTP id y16mr10718152ywg.2.1515596459313; Wed, 10 Jan 2018 07:00:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.75.20 with HTTP; Wed, 10 Jan 2018 07:00:18 -0800 (PST) In-Reply-To: <20180110131542.sv73bd2cxgmdxg7g@elstar.local> References: <151541670915.11305.11069854448917067732.idtracker@ietfa.amsl.com> <20180110131542.sv73bd2cxgmdxg7g@elstar.local> From: Eric Rescorla Date: Wed, 10 Jan 2018 07:00:18 -0800 Message-ID: To: Juergen Schoenwaelder , Eric Rescorla , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary="001a114f89bc94a1fb05626d4c21" Archived-At: Subject: Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:01:05 -0000 --001a114f89bc94a1fb05626d4c21 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 10, 2018 at 5:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jan 08, 2018 at 05:05:09AM -0800, Eric Rescorla wrote: > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > protocol interactions with other systems and that is neither > > conventional nor dynamic configuration. > > Could you provide an example of this? > > Many DHCP implementations do not go through a dynamic datastore and > deliver configuration state straight into the operational state. An IP > address learned via DHCP on such a system will be tagged with > or:learned. > I don't think it's imperative, but it would be nice to have this example in the text. > datastore that holds the complete current configuration on the > > device. It MAY include configuration that requires further > > transformation before it can be applied, e.g., inactive > > > > If I am reading the text, this doesn't seem to be true because "system > > configuration" is not included. > > Yes, it might make sense to remove 'complete' here to align the > sentence in 5.1.3 with the definition of 'running configuration > datastore'. > Thanks, -Ekr > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114f89bc94a1fb05626d4c21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 10, 2018 at 5:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 08, 2018 at 05:05:09AM = -0800, Eric Rescorla wrote:
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol interactions with other systems and= that is neither
>=C2=A0 =C2=A0 =C2=A0 =C2=A0conventional nor dynamic configuration.
> Could you provide an example of this?

Many DHCP implementations do not go through a dynamic datastore and<= br> deliver configuration state straight into the operational state. An IP
address learned via DHCP on such a system will be tagged with
or:learned.

I don't think it's = imperative, but it would be nice to have this example in the
text= .


>=C2=A0 =C2=A0 datastore that holds the complete current configuration o= n the
>=C2=A0 =C2=A0 device.=C2=A0 It MAY include configuration that requires = further
>=C2=A0 =C2=A0 transformation before it can be applied, e.g., inactive >
> If I am reading the text, this doesn't seem to be true because &qu= ot;system
> configuration" is not included.

Yes, it might make sense to remove 'complete' here to align = the
sentence in 5.1.3 with the definition of 'running configuration
datastore'.

Thanks,

<= /div>
-Ekr
=C2=A0

/js

--
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 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a114f89bc94a1fb05626d4c21-- From nobody Wed Jan 10 08:17: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 AED87128896; Wed, 10 Jan 2018 08:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 JrGYPNnMkmdh; Wed, 10 Jan 2018 08:17:11 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 1395112421A; Wed, 10 Jan 2018 08:17:11 -0800 (PST) Received: from MBP.local ([IPv6:2600:380:4636:796a:70b6:57fb:d3c2:25e2]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0AGH1Dh051449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 10 Jan 2018 16:17:06 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2600:380:4636:796a:70b6:57fb:d3c2:25e2] claimed to be MBP.local From: joel jaeggli To: NETMOD Working Group Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> Message-ID: Date: Wed, 10 Jan 2018 08:16:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:17:13 -0000 Just a reminder given the date that this was posted. This last call is expected to complete Monday 1/15/18. Thanks joel On 1/1/18 2:01 PM, joel jaeggli wrote: > Greetings, > > We hope the new year is a time to make great progess on outstanding > documents before preparation for the London IETF begins in earnest. > > This starts a two-week working group last call on: > > YANG Tree Diagrams > draft-ietf-netmod-yang-tree-diagrams > > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ > > Please send email to the list indicating your support or concerns. > > We are particularly interested in statements of the form: > > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > > Thank you, > NETMOD WG Chairs > > > > From nobody Wed Jan 10 08:18:38 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 7C57D12421A; Wed, 10 Jan 2018 08:18:18 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 aRCU13JoYkfq; Wed, 10 Jan 2018 08:18:15 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F44D12D85E; Wed, 10 Jan 2018 08:18:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0F35AEFF; Wed, 10 Jan 2018 17:18:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id L8dqL0pyke1O; Wed, 10 Jan 2018 17:18:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 17:18:14 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBE802013E; Wed, 10 Jan 2018 17:18:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mjv_G-uL-8nL; Wed, 10 Jan 2018 17:18:13 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 941152013D; Wed, 10 Jan 2018 17:18:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3347F420A065; Wed, 10 Jan 2018 17:18:13 +0100 (CET) Date: Wed, 10 Jan 2018 17:18:13 +0100 From: Juergen Schoenwaelder To: Eric Rescorla Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180110161813.yfn6sn522keuqz6a@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Eric Rescorla , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151541670915.11305.11069854448917067732.idtracker@ietfa.amsl.com> <20180110131542.sv73bd2cxgmdxg7g@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:18:18 -0000 On Wed, Jan 10, 2018 at 07:00:18AM -0800, Eric Rescorla wrote: > On Wed, Jan 10, 2018 at 5:15 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jan 08, 2018 at 05:05:09AM -0800, Eric Rescorla wrote: > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > > > > protocol interactions with other systems and that is neither > > > conventional nor dynamic configuration. > > > Could you provide an example of this? > > > > Many DHCP implementations do not go through a dynamic datastore and > > deliver configuration state straight into the operational state. An IP > > address learned via DHCP on such a system will be tagged with > > or:learned. > > > > I don't think it's imperative, but it would be nice to have this example in > the > text. There is more explanatory text in section 5.3.4 and I believe this should be sufficient: o learned: represents configuration that has been learned via protocol interactions with other systems, including protocols such as link-layer negotiations, routing protocols, DHCP, 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 Wed Jan 10 08:37: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 A3F4612D778; Wed, 10 Jan 2018 08:37:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 3Sf_JYyCzzlo; Wed, 10 Jan 2018 08:36:58 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C835F129C6B; Wed, 10 Jan 2018 08:36:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8E115EFF; Wed, 10 Jan 2018 17:36:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id eyCj5kwoH2F5; Wed, 10 Jan 2018 17:36:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 17:36:56 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CD2F2013D; Wed, 10 Jan 2018 17:36:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fpFR60_Iclsv; Wed, 10 Jan 2018 17:36:55 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E2DD2013C; Wed, 10 Jan 2018 17:36:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2360C420A198; Wed, 10 Jan 2018 17:36:53 +0100 (CET) Date: Wed, 10 Jan 2018 17:36:53 +0100 From: Juergen Schoenwaelder To: daedulus@btconnect.com Cc: ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org Message-ID: <20180110163653.fjfbmr3gbnue52pq@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: daedulus@btconnect.com, ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> <20180109.210824.760424986407969599.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109.210824.760424986407969599.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:37:01 -0000 On Tue, Jan 09, 2018 at 09:08:24PM +0100, Martin Bjorklund wrote: > Hi Tom, > > "tom p." wrote: > > Much of this I-D is about the idea that network management data objects > > can often take two different values. The I-D always refers to this as > > being two values but is that a limit that this architecture imposes; or > > can it be more? > > The I-D talks about two instantiations in the Objectives section, when > the original "config vs oper values" problem is explained, and how > NMDA solves the problem. > > But the archtecture allows for any number of instantiations; it all > depends on which datastores a particular server implements. For > example, a config node might have one value in , a > different in and yet a different value in . This > is not new to this document. > Right. Lets see there "two" is used: - 1st paragraph in 2. Objectives: I think the text is clear since it talks about a concrete example of a configured value and an operationally used value. - 2nd paragraph in 2. Objectives: This text talks about two separate branches in the old models, this should be fine. - 4th paragraph in 2. Objectives: I think this is potentially causing the confusion. It says: With the revised architectural model of datastores defined in this document, the data objects are defined only once in the YANG schema but independent instantiations can appear in two different datastores, one for configured values and one for operational state values. Perhaps a better wording would be this: With the revised architectural model of datastores defined in this document, the data objects are defined only once in the YANG schema but independent instantiations can appear in different datastores, e.g., for a configured value and one for an operationally used value. This e.g. then kind of continues the example the section started with. Would this change have avoided the question? /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 Jan 10 08:44: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 E78F312D96D; Wed, 10 Jan 2018 08:44:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 3GNdxlDohB3w; Wed, 10 Jan 2018 08:44:35 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E5712D963; Wed, 10 Jan 2018 08:44:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2C096F68; Wed, 10 Jan 2018 17:44:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SqytgF78eNZx; Wed, 10 Jan 2018 17:44:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 17:44:34 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1542D2013E; Wed, 10 Jan 2018 17:44:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ubp2I-mUix71; Wed, 10 Jan 2018 17:44:33 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43F9E2013D; Wed, 10 Jan 2018 17:44:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 643B1420A245; Wed, 10 Jan 2018 17:44:31 +0100 (CET) Date: Wed, 10 Jan 2018 17:44:31 +0100 From: Juergen Schoenwaelder To: Alexey Melnikov Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180110164431.iftsc7b6alwwrlr5@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexey Melnikov , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151549500977.9608.14570663429463756513.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151549500977.9608.14570663429463756513.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Alexey Melnikov's Yes on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:44:39 -0000 On Tue, Jan 09, 2018 at 02:50:09AM -0800, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-netmod-revised-datastores-09: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Appendix C.1: example hostnames "foo" and "bar" are used. Should these be fully qualified? > It probably does not matter much but we will change them to foo.example.com and bar.example.com since this reinforces that these are examples. /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 Jan 10 09:07: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 1799E129C6D; Wed, 10 Jan 2018 09:07:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 It00cwn0YVPA; Wed, 10 Jan 2018 09:07:08 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59531200C5; Wed, 10 Jan 2018 09:07:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B5F3169A; Wed, 10 Jan 2018 18:07:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id w44Pe2RqAjWm; Wed, 10 Jan 2018 18:07:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 18:07:06 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9569F2013E; Wed, 10 Jan 2018 18:07:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LSe20vTIRMNj; Wed, 10 Jan 2018 18:07:05 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 632F52013D; Wed, 10 Jan 2018 18:07:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1C75A420A491; Wed, 10 Jan 2018 18:07:04 +0100 (CET) Date: Wed, 10 Jan 2018 18:07:04 +0100 From: Juergen Schoenwaelder To: Alvaro Retana Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180110170704.5vyuvbiz2vg6h3vh@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alvaro Retana , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151555382321.21465.10788231800400955949.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <151555382321.21465.10788231800400955949.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 17:07:10 -0000 On Tue, Jan 09, 2018 at 07:10:23PM -0800, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-netmod-revised-datastores-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) Please add a sentence to the Introduction explaining how this document > updates rfc7950. I know that a couple of sections explicitly indicate what > part of rfc7950 they update, but having a short summary at the beginning would > be nice. > > (2) Section 3 says: “It is expected that the revised definitions provided in > this section will replace the definitions in [RFC6241] and [RFC7950] when these > documents are revised.” Why not formally Update those documents here? [See my > note above about the Update to rfc7950.] The formal 'update of RFC 7950' is driven by the sections 6.1 and 6.2 and not so much to the terminology section. While we expect that the terminology wording will be harmonized in a future revision of RFC 7950, this does not seem to require a formal update of RFC 7950 at this point in time (since the definitions are semantically equivalent). So back to the abstract: We could be more explicit by saying: This document updates the definition of the XPath context and the invocation context of operations in RFC 7950. Personally, I think this makes the abstract harder to read. Perhaps a better solution is to leave the abstract as is and to add this one sentence paragraph to the Introduction (before the key words boilerplate text). This document updates RFC 7950 by refining the definition of the accessible tree for some XPath context (see Section 6.1) and the invocation context of operations (see Section 6.2). > (3) s/Section 4.4 of this document/Section 4.4 of rfc6244 Yes, this is better. /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 Jan 10 11:21:16 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 B5B1812DB6D; Wed, 10 Jan 2018 11:21:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 11:21:13 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:21:14 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hello, Thanks for your work on this draft. I'm a little confused with some text in the draft and have a few questions. 1. The introductions says, "This architectural framework identifies a set of conceptual datastores but it does not mandate that all network management protocols expose all these conceptual datastores. This architecture is agnostic with regard to the encoding used by network management protocols." As such, the data stores could be exposed for some implementations, using whatever network management protocol (likely NetCONF or RESTCONF). If this is the case, why doesn't at least some of the security considerations template apply for at least secure transport? 2. Section 5.3.4 - Is there any integrity protection on the origin information? If not, can it be added or is there a good reason why it’s not possible? I realize these are conceptual models that may or may not be exposed, but if exposed and used, wouldn’t some integrity protection on this be helpful? Thanks in advance! From nobody Wed Jan 10 11:45:36 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 5CD7D12D88D; Wed, 10 Jan 2018 11:45:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 QOXGsGqiu3q1; Wed, 10 Jan 2018 11:45:33 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4058124207; Wed, 10 Jan 2018 11:45:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 833E56BA; Wed, 10 Jan 2018 20:45:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id IvWOA0ZhPPlt; Wed, 10 Jan 2018 20:45:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jan 2018 20:45:31 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41B282013E; Wed, 10 Jan 2018 20:45:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jzFnjxrZyhEI; Wed, 10 Jan 2018 20:45:30 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 915792013D; Wed, 10 Jan 2018 20:45:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3E3D8420A6F4; Wed, 10 Jan 2018 20:45:29 +0100 (CET) Date: Wed, 10 Jan 2018 20:45:29 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180110194529.3myrio6vrvsn3jjh@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:45:35 -0000 On Wed, Jan 10, 2018 at 11:21:13AM -0800, Kathleen Moriarty wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hello, > > Thanks for your work on this draft. I'm a little confused with some text in > the draft and have a few questions. > > 1. The introductions says, > "This architectural framework identifies a set of conceptual datastores but > it does not mandate that all network management protocols expose all > these conceptual datastores. This architecture is agnostic with > regard to the encoding used by network management protocols." > > As such, the data stores could be exposed for some implementations, using > whatever network management protocol (likely NetCONF or RESTCONF). If this is > the case, why doesn't at least some of the security considerations template > apply for at least secure transport? The security considerations text is IMHO correct. The YANG modules defined in this document do not define any accessible objects. Hence, the security YANG template does not apply. > 2. Section 5.3.4 - Is there any integrity protection on the origin information? > If not, can it be added or is there a good reason why it’s not possible? I > realize these are conceptual models that may or may not be exposed, but if > exposed and used, wouldn’t some integrity protection on this be helpful? Can you clarify what you mean with 'integrity protection' in this context and why you think origin attributes are special? The known published network management protocols all use standard security protocols (SSH and TLS). In general, security mechanisms are protocol specific, I do not see how the architectual definition of datastores requires discussion of special integrity mechanisms. Perhaps I do not understand your concern. /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 Jan 10 14:11:37 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 54E26127241; Wed, 10 Jan 2018 14:11:30 -0800 (PST) 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, UNPARSEABLE_RELAY=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 RzTOxo4Wn7p2; Wed, 10 Jan 2018 14:11:27 -0800 (PST) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::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 C644C126B72; Wed, 10 Jan 2018 14:11:27 -0800 (PST) Received: by mail-ot0-x243.google.com with SMTP id f6so459046oti.13; Wed, 10 Jan 2018 14:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=7f+LMdb2FqWxplEJEJmGy4l3N69095uAigV1180ZtWU=; b=AngfIZo10RDhyOR9e/ksHVOwZHHbME/hdeCbajCRhBzfv/tWGWiHBEAebuHU+MqzFz X4tkf4fYsSYHTBRe+Hh0VINVliSBFJmM3z2eGJwx7ulqbpcwzsA5FBF7hNDjGWTIzmVl fSDhxy+zZbpIFb7Z47rvgXqfYsXgBZPRpaA0wV5Xgzc6Z3ZKPp8sLFg8TUwIvD7TPaGj Au0T9RhIH20oFA6CtceB0dq+NDoWlzaxwNeXTt0vrZafWVBapd8wwyjGODQTWbaJW0n1 5L4lfIWEnMXVbf/W6WLR4culQIntJl9xizvhHo5lpm6kOVGwsNmCzurQUip3A9wfVWLJ xBhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=7f+LMdb2FqWxplEJEJmGy4l3N69095uAigV1180ZtWU=; b=TdmFRSfaPXaG+Qa+Mmrrs7PomfKhKrjrTBR2F6EzDhPFDtEft4SLMAuF+fjzfZYprQ 4+D4SdgtM2mbzLKz36aGJ8VylenaUzaMH5N58Et7Wi1OfhE7+S42b4U1pP85P2EyzNHP Dcv2MhVLSpWtTMjPT5n/Qde609B0g97Qy2M79UFN+lhIZciL2GTtVXVpyMuyQualNOzw ZqaMjSBT8qGHmXTVa1g6tZJi4R4OxTBnrupIpSVqYNRH5jjNInW/NzWkRSQKGI99/HgP 9qGxbIAL5893akOUhV5CxZt7zYT20FMDDRIZL3aFkj6yYXn2ejNYdv0c7gzh5/F3eth4 bbsg== X-Gm-Message-State: AKwxytcKEgIDeWWUIHTC6HhwxGQ1S5hYVCkyHGu6X7tZ7ZoklvxJhodQ +zWdAper772t2SIs/S85+A7GIXZx3X0hL0yYX10= X-Google-Smtp-Source: ACJfBovQMXjjyHrLbbpmcAvyzY7L2ZO/1E3g/k6JlAoGl0+32jwRmE+71Lois/LJhfZlgx3gn8E/NATXx9QQMoqYAcU= X-Received: by 10.157.67.38 with SMTP id s35mr3195747ote.3.1515622287201; Wed, 10 Jan 2018 14:11:27 -0800 (PST) Received: from 895490483151 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 17:11:26 -0500 From: Alvaro Retana In-Reply-To: <20180110170704.5vyuvbiz2vg6h3vh@elstar.local> References: <20180110170704.5vyuvbiz2vg6h3vh@elstar.local> X-Mailer: Airmail iOS (336) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 17:11:26 -0500 Message-ID: To: Juergen Schoenwaelder Cc: netmod-chairs@ietf.org, Lou Berger , netmod@ietf.org, The IESG , draft-ietf-netmod-revised-datastores@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1c1c4c0ae7b4056273501a" Archived-At: Subject: Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 22:11:31 -0000 --94eb2c1c1c4c0ae7b4056273501a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juergen: Hi! WFM. Thanks! Alvaro. On January 10, 2018 at 11:07:04 AM, Juergen Schoenwaelder ( j.schoenwaelder@jacobs-university.de) wrote: > On Tue, Jan 09, 2018 at 07:10:23PM -0800, Alvaro Retana wrote: > > Alvaro Retana has entered the following ballot position for > draft-ietf-netmod-revised-datastores-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) Please add a sentence to the Introduction explaining how this documen= t > updates rfc7950. I know that a couple of sections explicitly indicate wha= t > part of rfc7950 they update, but having a short summary at the beginning > would > be nice. > > (2) Section 3 says: =E2=80=9CIt is expected that the revised definitions = provided > in > this section will replace the definitions in [RFC6241] and [RFC7950] when > these > documents are revised.=E2=80=9D Why not formally Update those documents h= ere? [See > my > note above about the Update to rfc7950.] > > > The formal 'update of RFC 7950' is driven by the sections 6.1 and 6.2 > and not so much to the terminology section. While we expect that the > terminology wording will be harmonized in a future revision of RFC > 7950, this does not seem to require a formal update of RFC 7950 at > this point in time (since the definitions are semantically > equivalent). > > So back to the abstract: We could be more explicit by saying: > > This document updates the definition of the XPath context and the > invocation context of operations in RFC 7950. > > Personally, I think this makes the abstract harder to read. Perhaps a > better solution is to leave the abstract as is and to add this one > sentence paragraph to the Introduction (before the key words > boilerplate text). > > This document updates RFC 7950 by refining the definition of the > accessible tree for some XPath context (see Section 6.1) and the > invocation context of operations (see Section 6.2). > > (3) s/Section 4.4 of this document/Section 4.4 of rfc6244 > > > Yes, this is better. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1c1c4c0ae7b4056273501a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juergen:

Hi!

WFM.=C2=A0 Thanks!

Alvaro.

On January 10, 2018 at 11:07:04 AM, Juerg= en Schoenwaelder (j= .schoenwaelder@jacobs-university.de) wrote:

On Tue, Jan 09, 2018 at= 07:10:23PM -0800, Alvaro Retana wrote:
Alvaro Retana has entered the following ballo= t position for
draft-ietf-netmod-revised-datastores-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-data= stores/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Please add a sentence to the Introduction explaining how this docum= ent
updates rfc7950. I know that a couple of sections explicitly indicate = what
part of rfc7950 they update, but having a short summary at the beginnin= g would
be nice.

(2) Section 3 says: =E2=80=9CIt is expected that the revised definition= s provided in
this section will replace the definitions in [RFC6241] and [RFC7950] wh= en these
documents are revised.=E2=80=9D Why not formally Update those document= s here? [See my
note above about the Update to rfc7950.]

The formal 'update of RFC 7950' is driven by the sections 6.1 a= nd 6.2
and not so much to the terminology section. While we expect that the
terminology wording will be harmonized in a future revision of RFC
7950, this does not seem to require a formal update of RFC 7950 at
this point in time (since the definitions are semantically
equivalent).

So back to the abstract: We could be more explicit by saying:

This document updates the definition of the XPath context and the
invocation context of operations in RFC 7950.

Personally, I think this makes the abstract harder to read. Perhaps a
better solution is to leave the abstract as is and to add this one
sentence paragraph to the Introduction (before the key words
boilerplate text).

This document updates RFC 7950 by refining the definition of the
accessible tree for some XPath context (see Section 6.1) and the
invocation context of operations (see Section 6.2).
=20
(3) s/Section 4.4 of this document/Section 4.= 4 of rfc6244

Yes, this is better.

/js

-- =20
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>

--94eb2c1c1c4c0ae7b4056273501a-- From nobody Wed Jan 10 17:21: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 3C059126BFD for ; Wed, 10 Jan 2018 17:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 5ThoS4JHbwax for ; Wed, 10 Jan 2018 17:21:18 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 78366120454 for ; Wed, 10 Jan 2018 17:21:18 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w135so639895oie.3 for ; Wed, 10 Jan 2018 17:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qjUXtnAfFeP8y+GqaP0dl2jdtOpn0QZAGLZHQ0GK4PI=; b=EHl3FIPSLe0dIC76IiYRGDUz9xOycuzms4+EJ2KK9YMycOOg6suo56DOokgPzmn0fh BJOw0o+9DW0LMXN1dqdVdEnPZFo5DIvM3LLHAx8s6eVi+bAzbNn/kE40RrTexXlrPlkk p5/kI8UtDzWQxKI5fJrHMpC9D9gKfbWXfuYwGmMvjTCBU9L4wDftzZt3onYRuhTi8Owf TFUskuMczgwOgYJvWVcRHuhZyT7hz5xo+5sCgQAQLm1mjxzBSl98htsxOeso/4Qkvh8U LzWL0UIEJCq2P5BuUcxNDS2b6R+JSmIgdu4Q9vF3gKAVZTWyxN5YEvVTfKFDy+I5GBy6 f9IA== 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=qjUXtnAfFeP8y+GqaP0dl2jdtOpn0QZAGLZHQ0GK4PI=; b=JfeOTsWhQq4h7/2NivP+Jd4KqfEV0XsjDAmK73xPPC29QpHSy+02Ojhn7LHSQ7EUlm i8kn4G3+sytbFKFMHveMKEaWPy8ewOObneZAdDUzOGCe4jGZYjR35UdDC7B/+BMygMKf 5BlLcYDCxylh0ki1v8uyniDiT4q8bzwJrWHLDMOwXxooWnU4VGr3LrXLEhGYdzhy78LE s5yWehv/L+vw86VIkC9bkq3DGVPN4CjzSVOiG0jvHnmekSdgZiyc1Zcd/clxLHbeosZ3 T6WfXh5JhVWDoglSCMdZzogtMkBBoR9/X9za84Rhr8CTESWU30HBd2HcnlaWu6ocpk9A Sk0A== X-Gm-Message-State: AKGB3mKyMeSaDmCJVHh8A0FhkpEbuXlvqZEl1g4zZtOODbvjI0hx6SbF jpEKgGoEf6NEkRbqJnDYU8c= X-Google-Smtp-Source: ACJfBosVrZOT7bONTep4zB+L9AB5W9q50RYsYlaVPbkca82GVTm3fcKkIbgUw5YlvRftz8U0tOoFnQ== X-Received: by 10.202.75.80 with SMTP id y77mr11176261oia.328.1515633677500; Wed, 10 Jan 2018 17:21:17 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:cde:2fd2:87ac:1a5f]) by smtp.gmail.com with ESMTPSA id t36sm961800otc.40.2018.01.10.17.21.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 17:21:16 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1ED93493-BAB4-464D-8B1C-8DDF661A4D7D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 17:21:13 -0800 In-Reply-To: Cc: "netmod@ietf.org" To: Eliot Lear References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 01:21:23 -0000 --Apple-Mail=_1ED93493-BAB4-464D-8B1C-8DDF661A4D7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Einar, I can work on updating the draft as soon as we agree on the changes. = Should take only a couple of days to turn around and publish the draft. > On Jan 9, 2018, at 11:35 PM, Eliot Lear wrote: >=20 > Hi Mahesh, >=20 > Thanks for this work. I think this is okay. In the case of MUD we = simply won't have the other container. Can I please ask that you get = the draft out quickly as draft-ietf-opsawg-mud has been waiting quite = some time for this work to complete. >=20 > Eliot >=20 > On 10.01.18 04:08, Mahesh Jethanandani wrote: >> I have pulled in the changes as they relate to: >>=20 >> - moving =E2=80=9Cinterface-acl=E2=80=9D under the container = =E2=80=9Cattachment-points=E2=80=9D making it local to that container. >> - reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ctype=E2=80=9D >> - removed =E2=80=9Cinterface-all-aggregate=E2=80=9D feature >> - simplified source port and destination port definition >>=20 >> The pull request for the changes can be found here. >>=20 >> https://github.com/netmod-wg/acl-model/pull/20 = >>=20 >> After discussing with some of the original contributors, decided not = to include the change as it relates to augmenting ietf-interfaces. We = did not find that the change had a particular advantage over the current = implementation. Even if we do not completely understand how ACLs might = be attached =E2=80=9Cglobally=E2=80=9D or on something that is not an = interface, having the flexibility to attach them to other attachment = points is important. Keeping it as interface-ref gives us that = flexibility. >>=20 >> Cheers. >>=20 >>> On Dec 18, 2017, at 4:31 AM, Eliot Lear > wrote: >>>=20 >>> So long as nobody expects an interface construct in a MUD file, I'm = happy. >>>=20 >>> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: >>>> Eliot, >>>>=20 >>>> Nothing can force an implementation to have to implement either the = ietf-interfaces model or the augmentation in the = ietf-access-control-list model. I appreciate your desire for modularity = and cohesiveness, but I would resist #1, because I feel that the = majority of users will be targeting interface-based = attachment over time. I=E2=80=99ve adde back in use of the = =E2=80=9Cinterface-attachment=E2=80=9D feature (which I took out as part = of refactoring interface attachment). Part of: >>>>=20 >>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>=20 >>>> The augments part of the tree now looks like: >>>>=20 >>>> augment /if:interfaces/if:interface: >>>> +--rw acls {interface-attachment}? >>>> +--rw ingress >>>> | +--rw acl-sets >>>> | +--rw acl-set* [name] >>>> | +--rw name -> /access-lists/acl/name >>>> | +--rw type? -> /access-lists/acl/type >>>> | +--ro ace-statistics* [name] {interface-stats}? >>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>> | +--ro matched-packets? yang:counter64 >>>> | +--ro matched-octets? yang:counter64 >>>> +--rw egress >>>> +--rw acl-sets >>>> +--rw acl-set* [name] >>>> +--rw name -> /access-lists/acl/name >>>> +--rw type? -> /access-lists/acl/type >>>> +--ro ace-statistics* [name] {interface-stats}? >>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>> +--ro matched-packets? yang:counter64 >>>> +--ro matched-octets? yang:counter64 >>>>=20 >>>> Cheers, >>>>=20 >>>> Einar >>>>=20 >>>>=20 >>>>> On 17 Dec 2017, at 11:29, Eliot Lear > wrote: >>>>>=20 >>>>> Einar, >>>>>=20 >>>>> I think this change is fine, with one exception. I would rather = the augment to the interface not be required for implementations that = don't actually have interfaces. I understand that there may be two ways = to go about this: >>>>>=20 >>>>> Separate out the augment into a separate module (same doc is = fine); or >>>>> Somehow "feature-ize" the augment. >>>>> I don't know how to do (2) but if you do, that's okay by me. >>>>>=20 >>>>> Eliot >>>>>=20 >>>>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote: >>>>>> All, >>>>>>=20 >>>>>> After a series of discussions on- and off-list, I have a = candidate PR that includes the changes in the PR Mahesh sent out plus = some more edits. Please see consolidated PR here: >>>>>>=20 >>>>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>>>=20 >>>>>> Main changes in addition to Mahesh=E2=80=99s PR are: >>>>>>=20 >>>>>> Moved interface attachment to be via an interface augmentation. >>>>>> Restructured port matches slightly under both IPv4 and IPv6 = containers. >>>>>> Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. >>>>>> Removed action =E2=80=98icmp-off=E2=80=99, can be augmented = later. >>>>>>=20 >>>>>> For reference, here is the current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs: >>>>>>=20 >>>>>> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang >>>>>> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" = (should be date) >>>>>> module: ietf-access-control-list >>>>>> +--rw access-lists >>>>>> +--rw acl* [name] >>>>>> +--rw name string >>>>>> +--rw type? acl-type >>>>>> +--rw aces >>>>>> +--rw ace* [name] >>>>>> +--rw name string >>>>>> +--rw matches >>>>>> | +--rw (l2)? >>>>>> | | +--:(eth) >>>>>> | | +--rw eth {match-on-eth}? >>>>>> | | +--rw destination-mac-address? = yang:mac-address >>>>>> | | +--rw destination-mac-address-mask? = yang:mac-address >>>>>> | | +--rw source-mac-address? = yang:mac-address >>>>>> | | +--rw source-mac-address-mask? = yang:mac-address >>>>>> | | +--rw ethertype? = eth:ethertype >>>>>> | +--rw (l3)? >>>>>> | | +--:(ipv4) >>>>>> | | | +--rw ipv4 {match-on-ipv4}? >>>>>> | | | +--rw dscp? = inet:dscp >>>>>> | | | +--rw ecn? = uint8 >>>>>> | | | +--rw length? = uint16 >>>>>> | | | +--rw ttl? = uint8 >>>>>> | | | +--rw protocol? = uint8 >>>>>> | | | +--rw = (source-port-range-or-operator)? >>>>>> | | | | +--:(range) >>>>>> | | | | | +--rw source-port-lower = inet:port-number >>>>>> | | | | | +--rw source-port-upper = inet:port-number >>>>>> | | | | +--:(operator) >>>>>> | | | | +--rw source-operator = operator >>>>>> | | | | +--rw source-port = inet:port-number >>>>>> | | | +--rw = (destination-port-range-or-operator)? >>>>>> | | | | +--:(range) >>>>>> | | | | | +--rw destination-port-lower = inet:port-number >>>>>> | | | | | +--rw destination-port-upper = inet:port-number >>>>>> | | | | +--:(operator) >>>>>> | | | | +--rw destination-operator = operator >>>>>> | | | | +--rw destination-port = inet:port-number >>>>>> | | | +--rw ihl? = uint8 >>>>>> | | | +--rw flags? = bits >>>>>> | | | +--rw offset? = uint16 >>>>>> | | | +--rw identification? = uint16 >>>>>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>>>>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>>>>> | | +--:(ipv6) >>>>>> | | +--rw ipv6 {match-on-ipv6}? >>>>>> | | +--rw dscp? = inet:dscp >>>>>> | | +--rw ecn? = uint8 >>>>>> | | +--rw length? = uint16 >>>>>> | | +--rw ttl? = uint8 >>>>>> | | +--rw protocol? = uint8 >>>>>> | | +--rw = (source-port-range-or-operator)? >>>>>> | | | +--:(range) >>>>>> | | | | +--rw source-port-lower = inet:port-number >>>>>> | | | | +--rw source-port-upper = inet:port-number >>>>>> | | | +--:(operator) >>>>>> | | | +--rw source-operator = operator >>>>>> | | | +--rw source-port = inet:port-number >>>>>> | | +--rw = (destination-port-range-or-operator)? >>>>>> | | | +--:(range) >>>>>> | | | | +--rw destination-port-lower = inet:port-number >>>>>> | | | | +--rw destination-port-upper = inet:port-number >>>>>> | | | +--:(operator) >>>>>> | | | +--rw destination-operator = operator >>>>>> | | | +--rw destination-port = inet:port-number >>>>>> | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>>>>> | | +--rw source-ipv6-network? = inet:ipv6-prefix >>>>>> | | +--rw flow-label? = inet:ipv6-flow-label >>>>>> | +--rw (l4)? >>>>>> | | +--:(tcp) >>>>>> | | | +--rw tcp {match-on-tcp}? >>>>>> | | | +--rw sequence-number? = uint32 >>>>>> | | | +--rw acknowledgement-number? = uint32 >>>>>> | | | +--rw data-offset? uint8 >>>>>> | | | +--rw reserved? uint8 >>>>>> | | | +--rw flags? bits >>>>>> | | | +--rw window-size? = uint16 >>>>>> | | | +--rw urgent-pointer? = uint16 >>>>>> | | | +--rw options? = uint32 >>>>>> | | +--:(udp) >>>>>> | | | +--rw udp {match-on-udp}? >>>>>> | | | +--rw length? uint16 >>>>>> | | +--:(icmp) >>>>>> | | +--rw icmp {match-on-icmp}? >>>>>> | | +--rw type? uint8 >>>>>> | | +--rw code? uint8 >>>>>> | | +--rw rest-of-header? uint32 >>>>>> | +--rw egress-interface? if:interface-ref >>>>>> | +--rw ingress-interface? if:interface-ref >>>>>> +--rw actions >>>>>> | +--rw forwarding identityref >>>>>> | +--rw logging? identityref >>>>>> +--ro statistics {acl-aggregate-stats}? >>>>>> +--ro matched-packets? yang:counter64 >>>>>> +--ro matched-octets? yang:counter64 >>>>>>=20 >>>>>> augment /if:interfaces/if:interface: >>>>>> +--rw acls >>>>>> +--rw ingress >>>>>> | +--rw acl-sets >>>>>> | +--rw acl-set* [name] >>>>>> | +--rw name -> /access-lists/acl/name >>>>>> | +--rw type? -> /access-lists/acl/type >>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> | +--ro matched-packets? yang:counter64 >>>>>> | +--ro matched-octets? yang:counter64 >>>>>> +--rw egress >>>>>> +--rw acl-sets >>>>>> +--rw acl-set* [name] >>>>>> +--rw name -> /access-lists/acl/name >>>>>> +--rw type? -> /access-lists/acl/type >>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> +--ro matched-packets? yang:counter64 >>>>>> +--ro matched-octets? yang:counter64 >>>>>>=20 >>>>>> Comments welcome! >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Einar >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal > wrote: >>>>>>>>=20 >>>>>>>> Hi Einar, >>>>>>>>=20 >>>>>>>> You had 3 questions for me on all the several e-mail threads.=20= >>>>>>>> 1. Global attachment point >>>>>>>> 2. icmp-off >>>>>>>> 3. acl-aggregate-interface stats. >>>>>>>>=20 >>>>>>>> For (1), my first preference is to have the model define = attachment point for interfaces only. >>>>>>>=20 >>>>>>> einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to netmod-wg/acl-model that do this. Nearly like the augmentation I = have below. Feel free to take a look at: >>>>>>>=20 >>>>>>> https://github.com/mjethanandani/acl-model/pull/3 = >>>>>>>=20 >>>>>>>> However, Kristian wants the global attachment point as well so = that he can add the ACL to the linux tables. >>>>>>>=20 >>>>>>> einarnn> I think Kristian doesn=E2=80=99t feel a global = attachment point needs to be in this first revision. But he can confirm. >>>>>>>=20 >>>>>>>> If an ACL is attached globally, does this mean it is per = direction or does it mean it is across directions? >>>>>>>=20 >>>>>>> einarnn> I don=E2=80=99t know right now :-) >>>>>>>=20 >>>>>>>> This global ACL may not be applicable to any of Cisco's service = provider routers as I don't see any platform actually replicating the = ACL to all line cards and attaching it in ingress and egress directions = across all interfaces. >>>>>>>=20 >>>>>>> einarnn> Per other emails, I don=E2=80=99t think we understand = this enough yet to specify it, so I suggest we just leave it out for = now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80= =9D being added later once we understand what it really means. >>>>>>>=20 >>>>>>>> For (2), I am ok with removing icmp-off. >>>>>>>=20 >>>>>>> einarnn> Done in my PR above. >>>>>>>=20 >>>>>>>> For (3), this would have to be a combination of ACL stats = across all interfaces for all ACL's. Something like this is possible on = an XR box where ACES have counter names associated with it. Let's chat = about this offline tomorrow. >>>>>>>=20 >>>>>>> einarnn> I=E2=80=99ll ping you to clarify, and we can bring any = conclusion back to the list. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Einar >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Sonal. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani = > wrote: >>>>>>>> We want to support =E2=80=9Cglobal=E2=80=9D attachment point = down the line, and that =E2=80=9Cglobal=E2=80=9D attachment point will = be one of the choices (the other being the interface), what would this = augment look like. Note, as far as I know, you cannot augment inside a = choice node. >>>>>>>>=20 >>>>>>>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>>>=20 >>>>>>>>> Perhaps like this, as an augmentation to the interface: >>>>>>>>>=20 >>>>>>>>> augment /if:interfaces/if:interface: >>>>>>>>> +--rw ingress-acls >>>>>>>>> | +--rw acl-sets >>>>>>>>> | +--rw acl-set* [name] >>>>>>>>> | +--rw name -> /access-lists/acl/name >>>>>>>>> | +--rw type? -> /access-lists/acl/type >>>>>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>> | +--ro matched-packets? yang:counter64 >>>>>>>>> | +--ro matched-octets? yang:counter64 >>>>>>>>> +--rw egress-acls >>>>>>>>> +--rw acl-sets >>>>>>>>> +--rw acl-set* [name] >>>>>>>>> +--rw name -> /access-lists/acl/name >>>>>>>>> +--rw type? -> /access-lists/acl/type >>>>>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>> +--ro matched-packets? yang:counter64 >>>>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>>>=20 >>>>>>>>> Could also put an =E2=80=9Caces=E2=80=9D container above both = these & rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. = to give a single root for the augmentation if preferred. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Einar >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 6 Dec 2017, at 19:43, Eliot Lear > wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote: >>>>>>>>>>> How does one move the interface attachment point, currently = an >>>>>>>>>>> 'interface-ref', to an augmentation of the = if:interfaces/interface, >>>>>>>>>>> inside of the =E2=80=98acl=E2=80=99 container? Down the = line we might need to have an >>>>>>>>>>> container for "attachment points" to accommodate the = possibility of >>>>>>>>>>> attaching an ACL either to an interface or =E2=80=9Cglobally=E2= =80=9D. >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Keeping in mind that one use is that an ACL doesn't attach to = an >>>>>>>>>> interface at all. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> netmod mailing list >>>>>>>>>> netmod@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Mahesh Jethanandani >>>>>>>> mjethanandani@gmail.com >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1ED93493-BAB4-464D-8B1C-8DDF661A4D7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Einar,

I can work on = updating the draft as soon as we agree on the changes. Should take only = a couple of days to turn around and publish the draft.

On Jan 9, 2018, at 11:35 PM, Eliot Lear <lear@cisco.com> = wrote:

=20 =20

Hi = Mahesh,

Thanks for this work.  I think this is = okay.  In the case of MUD we simply won't have the other container.  Can I please ask = that you get the draft out quickly as draft-ietf-opsawg-mud has been waiting quite some time for this work to complete.

Eliot


On 10.01.18 04:08, Mahesh = Jethanandani wrote:
I have pulled in the changes as they relate to:

- moving =E2=80=9Cinterface-acl=E2=80=9D under the = container =E2=80=9Cattachment-points=E2=80=9D making it local to that = container.
- reverting =E2=80=9Cacl-type=E2=80=9D to = =E2=80=9Ctype=E2=80=9D
- removed =E2=80=9Cinterface-all-aggregate=E2=80=9D = feature
- simplified source port and destination port definition

The pull request for the changes can be found = here.

https://github.com/netmod-wg/acl-model/pull/20

After discussing with some of the original contributors, decided not to include the change as it relates to augmenting ietf-interfaces. We did not find that the change had a particular advantage over the current implementation. Even if we do not completely understand how ACLs might be attached =E2=80=9Cglobally=E2=80=9D or on something that is not an = interface, having the flexibility to attach them to other attachment points is important. Keeping it as interface-ref gives us that flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, Eliot Lear = <lear@cisco.com> wrote:

So long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
= Eliot,

Nothing can force an implementation to have to implement either the ietf-interfaces = model or the augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment over time. I=E2=80=99ve = adde back in use of the =E2=80=9Cinterface-attachment=E2=80=9D = feature (which I took out as part of refactoring interface attachment). Part of:

https://github.com/netmod-wg/acl-model/pull/21

The augments part of the tree now = looks like:

  augment = /if:interfaces/if:interface:
    +--rw acls {interface-attachment}?
       +--rw ingress
       |  +--rw acl-sets
       |     +--rw acl-set* [name]
       |        +--rw name   =            -> /access-lists/acl/name
       |        +--rw type?   =           -> /access-lists/acl/type
       |        +--ro ace-statistics* = [name] {interface-stats}?
       |           +--ro name =               -> /access-lists/acl/aces/ace/name
       |           +--ro = matched-packets?   yang:counter64
       |           +--ro = matched-octets?    yang:counter64
       +--rw egress
          +--rw acl-sets
             +--rw acl-set* = [name]
                +--rw name   =            -> /access-lists/acl/name
                +--rw type?   =           -> /access-lists/acl/type
                +--ro = ace-statistics* [name] {interface-stats}?
                   +--ro = name               -> /access-lists/acl/aces/ace/name
                   +--ro = matched-packets?   yang:counter64
                   +--ro = matched-octets?    yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:

Einar,

I think this change is = fine, with one exception.  I would rather = the augment to the interface not be required for implementations that don't actually have interfaces.  I understand that = there may be two ways to go about this:

  1. Separate out the augment = into a separate module (same doc is fine); or
  2. Somehow "feature-ize" the augment.

I don't know how to do = (2) but if you do, that's okay by me.

Eliot


On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
= All,

After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR = here:

https://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to Mahesh=E2=80=99s PR are:

  • Moved interface attachment to be via an interface augmentation.
  • Restructured port matches slightly under both IPv4 and IPv6 containers.
  • Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. =
  • Removed action =E2=80=98icmp-off=E2=80=99, can be = augmented later.

For reference, here is = the current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs:

13:12 $ pyang --ietf --lint -f tree = ietf-access-control-list.yang
ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" (should be date)
module: = ietf-access-control-list
    +--rw access-lists
       +--rw acl* [name]
          +--rw name   =  string
          +--rw type?   acl-type
          +--rw aces
             +--rw ace* [name]
                +--rw name       =    string
                +--rw matches
                = |  +--rw (l2)?
                = |  | =  +--:(eth)
                = |  |     +--rw eth = {match-on-eth}?
                = |  |       =  +--rw destination-mac-address?   =     =  yang:mac-address
                = |  |       =  +--rw destination-mac-address-mask? =   yang:mac-address
                = |  |       =  +--rw source-mac-address?     =         yang:mac-address
                = |  |       =  +--rw source-mac-address-mask?   =     =  yang:mac-address
                = |  |       =  +--rw ethertype?                   =    eth:ethertype
                = |  +--rw (l3)?
                = |  | =  +--:(ipv4)
                = |  |  |  +--rw ipv4 = {match-on-ipv4}?
                = |  |  |     = +--rw dscp?                       = inet:dscp
                = |  |  |     = +--rw ecn?                       =  uint8
                = |  |  |     = +--rw length?                     = uint16
                = |  |  |     = +--rw ttl?                       =  uint8
                = |  |  |     = +--rw protocol?                   = uint8
                = |  |  |     = +--rw = (source-port-range-or-operator)?
                = |  |  |     | =  +--:(range)
                = |  |  |     | =  |  +--rw source-port-lower     =       inet:port-number
                = |  |  |     | =  |  +--rw source-port-upper     =       inet:port-number
                = |  |  |     | =  +--:(operator)
                = |  |  |     | =     +--rw source-operator     =         operator
                = |  |  |     | =     +--rw source-port           =       inet:port-number
                = |  |  |     = +--rw = (destination-port-range-or-operator)?
                = |  |  |     | =  +--:(range)
                = |  |  |     | =  |  +--rw destination-port-lower   =   =  inet:port-number
                = |  |  |     | =  |  +--rw destination-port-upper   =   =  inet:port-number
                = |  |  |     | =  +--:(operator)
                = |  |  |     | =     +--rw destination-operator     =    operator
                = |  |  |     | =     +--rw destination-port     =       =  inet:port-number
                = |  |  |     = +--rw ihl?                       =  uint8
                = |  |  |     = +--rw flags?                     =  bits
                = |  |  |     = +--rw offset?                     = uint16
                = |  |  |     = +--rw identification?             = uint16
                = |  |  |     = +--rw destination-ipv4-network?   inet:ipv4-prefix
                = |  |  |     = +--rw source-ipv4-network?     =   =  inet:ipv4-prefix
                = |  | =  +--:(ipv6)
                = |  |     +--rw ipv6 = {match-on-ipv6}?
                = |  |       =  +--rw dscp?                       = inet:dscp
                = |  |       =  +--rw ecn?                       =  uint8
                = |  |       =  +--rw length?                     = uint16
                = |  |       =  +--rw ttl?                       =  uint8
                = |  |       =  +--rw protocol?                   = uint8
                = |  |       =  +--rw = (source-port-range-or-operator)?
                = |  |       =  |  +--:(range)
                = |  |       =  |  |  +--rw source-port-lower     =       inet:port-number
                = |  |       =  |  |  +--rw source-port-upper     =       inet:port-number
                = |  |       =  |  +--:(operator)
                = |  |       =  |     +--rw source-operator     =         operator
                = |  |       =  |     +--rw source-port           =       inet:port-number
                = |  |       =  +--rw = (destination-port-range-or-operator)?
                = |  |       =  |  +--:(range)
                = |  |       =  |  |  +--rw destination-port-lower   =   =  inet:port-number
                = |  |       =  |  |  +--rw destination-port-upper   =   =  inet:port-number
                = |  |       =  |  +--:(operator)
                = |  |       =  |     +--rw destination-operator     =    operator
                = |  |       =  |     +--rw destination-port     =       =  inet:port-number
                = |  |       =  +--rw destination-ipv6-network?   inet:ipv6-prefix
                = |  |       =  +--rw source-ipv6-network?     =   =  inet:ipv6-prefix
                = |  |       =  +--rw flow-label?                 = inet:ipv6-flow-label
                = |  +--rw (l4)?
                = |  | =  +--:(tcp)
                = |  |  |  +--rw tcp = {match-on-tcp}?
                = |  |  |     = +--rw sequence-number?         =  uint32
                = |  |  |     = +--rw acknowledgement-number?   = uint32
                = |  |  |     = +--rw data-offset?             =  uint8
                = |  |  |     = +--rw reserved?                 = uint8
                = |  |  |     = +--rw flags?                   =  bits
                = |  |  |     = +--rw window-size?             =  uint16
                = |  |  |     = +--rw urgent-pointer?           = uint16
                = |  |  |     = +--rw options?                 =  uint32
                = |  | =  +--:(udp)
                = |  |  |  +--rw udp = {match-on-udp}?
                = |  |  |     = +--rw length?   uint16
                = |  | =  +--:(icmp)
                = |  |     +--rw icmp = {match-on-icmp}?
                = |  |       =  +--rw type?             uint8
                = |  |       =  +--rw code?             uint8
                = |  |       =  +--rw rest-of-header?   uint32
                = |  +--rw egress-interface? =   =  if:interface-ref
                = |  +--rw ingress-interface? =   if:interface-ref
                +--rw actions
                = |  +--rw forwarding   =  identityref
                = |  +--rw logging?     =  identityref
                +--ro statistics = {acl-aggregate-stats}?
                =    +--ro matched-packets? =   yang:counter64
                =    +--ro matched-octets?    yang:counter64

  augment = /if:interfaces/if:interface:
    +--rw acls
       +--rw ingress
       |  +--rw acl-sets
       |     +--rw acl-set* [name]
       |        +--rw name     =          -> = /access-lists/acl/name
       |        +--rw type?     =         -> = /access-lists/acl/type
       |        +--ro ace-statistics* [name] {interface-stats}?
       |       =     +--ro name       =         -> = /access-lists/acl/aces/ace/name
       |       =     +--ro matched-packets?   yang:counter64
       |       =     +--ro matched-octets?    yang:counter64
       +--rw egress
          +--rw acl-sets
             +--rw acl-set* [name]
                +--rw name       =        -> = /access-lists/acl/name
                +--rw type?       =       -> = /access-lists/acl/type
                +--ro ace-statistics* [name] {interface-stats}?
                =    +--ro name     =           -> = /access-lists/acl/aces/ace/name
                =    +--ro matched-packets? =   yang:counter64
                =    +--ro matched-octets?    yang:counter64

Comments welcome!

Cheers,

Einar



On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:



On 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Einar,

You had = 3 questions for me on all the several e-mail threads. 
1. = Global attachment point
2. icmp-off
3. = acl-aggregate-interface stats.

For (1), my first preference is to have the model define attachment point for interfaces only.

einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s PR = to netmod-wg/acl-model that do this. Nearly like the augmentation I have below. Feel free to take a look = at:

https://github.com/mjethanandani/acl-model/pull/3=

=
However, Kristian wants the global attachment point as well so that he can add the ACL to the linux = tables.

einarnn> I think Kristian doesn=E2=80=99t= feel a global attachment point needs to be in this first revision. But he can confirm.

=
If an = ACL is attached globally, does this mean it is per direction or does it mean it is across directions?

einarnn> I don=E2=80=99t know right now = :-)

=
This global ACL may not be applicable to any of Cisco's service provider routers as I don't see any platform actually replicating the ACL to all line cards and attaching it in ingress and egress directions across all interfaces.

einarnn> = Per other emails, I don=E2=80=99t = think we understand this enough yet to specify it, so I suggest we just leave it out for now. Nothing in the model prevents a =E2=80=9Cglob= al attachment point=E2=80=9D = being added later once we understand what it really means.

=
For (2), = I am ok with removing icmp-off.

einarnn> = Done in my PR above.

=
For (3), this would have to be a combination of ACL stats across all interfaces for all ACL's. Something like this is possible on an XR box where ACES have counter names associated with it. Let's chat about this offline = tomorrow.

einarnn> = I=E2=80=99ll ping you to clarify, and we can bring any conclusion back to the list.

Cheers,

Einar



=
Sonal.


On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal=E2=80= =9D attachment point down the line, and that =E2=80=9Cglobal= =E2=80=9D attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.

=
On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = <einarnn@cisco.com> wrote:

=
Perhaps like this, as an augmentation to the interface:

=
  augment = /if:interfaces/if:interface:
=
    +--rw = ingress-acls
=
    | =  +--rw = acl-sets
=
    | =     +--rw acl-set* = [name]
=
    | =        +--rw = name       =        -> = /access-lists/acl/name
=
    | =        +--rw = type?       =       -> = /access-lists/acl/type
=
    | =        +--ro = ace-statistics* [name] = {interface-stats}?
=
    | =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
    | =           +--ro = matched-packets?   = yang:counter64
=
    | =           +--ro = matched-octets?   =  yang:counter64
=
    +--rw = egress-acls
=
      =  +--rw = acl-sets
=
      =     +--rw acl-set* = [name]
=
      =        +--rw = name       =        -> = /access-lists/acl/name
=
      =        +--rw = type?       =       -> = /access-lists/acl/type
=
      =        +--ro = ace-statistics* [name] = {interface-stats}?
=
      =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
      =           +--ro = matched-packets?   = yang:counter64
=
      =           +--ro = matched-octets?   =  yang:counter64

Could also put an =E2=80=9Caces=E2= =80=9D container above both these & rename = =E2=80=9Cingress-acls" to = =E2=80=9Cingress=E2=80=9D, etc. to give a single root for the augmentation if = preferred.

=
Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com> wrote:

=


On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently = an
'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2=80= =99 =  container? Down the line we might need to have an
container for "attachment points" to accommodate the possibility = of
attaching an ACL either to an interface or = =E2=80=9Cglobally=E2=80=9D.


Keeping in mind that one use is that an ACL doesn't attach to = an
interface at all.

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


=
Mahesh = Jethanandani
mjethanandani@gmail.com

=

_______________________________________________
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<= br class=3D""> 



_______________________________________________
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

Mahesh Jethanandani
mjethanandani@gmail.com



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


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_1ED93493-BAB4-464D-8B1C-8DDF661A4D7D-- From nobody Wed Jan 10 19:12:48 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 E018F12E855; Wed, 10 Jan 2018 19:12:45 -0800 (PST) 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 Z6g7BAeBqhW0; Wed, 10 Jan 2018 19:12:43 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 25AA612E044; Wed, 10 Jan 2018 19:12:43 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id e76so198701pfk.1; Wed, 10 Jan 2018 19:12:43 -0800 (PST) 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 :content-transfer-encoding; bh=5TunDxmGKO92Ent3Mcf8eUj4y4LIiWjKU4vjTY7mb+k=; b=vKLYGS+0q5dRMWan1sw5ScNSsNQwGKRdJdg9HrDAwNobyHb52eAQVjPcB+aRTwhw5q oj5jyRfGjzJXSS+nGx7cVzVqi+Agh5vQjeT9l/qY++vbfAJ5TLe+oMcMDh79YJmn4w3/ OKkRIlKez0vnLl00tA+yO4S0Gsl8cb19K5c43e5O4nFAu5G8NCMNdOm1zuNsUJHEaauO Vbq0D1V7v/qUIntbGEbtlP6fkfpdMBdb8RwIsMP6yNkP+jYJRF0cE48o9kIF99Wqxk5e YCe66O/j0uiqganHvOlzDVktqi3e37jikWVthAC/0q4gDSVZ53HqRoHI5li5UPD3CJUh 3+lQ== 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:content-transfer-encoding; bh=5TunDxmGKO92Ent3Mcf8eUj4y4LIiWjKU4vjTY7mb+k=; b=Rc0d6CGFrstU+FooZcTTl8xHVBHeSuVG9Tn0AzN5JrYXN5XhQAQeeQr8m7kWEAfuOO xT6k1EOmbrTIuw8++NWUgOJ7jOdQmxISvHE1NydLbmszorFPS931M4Tznbr4HC8NVKEm 25VgXpb8bznGCyW7egZ6SlwLTF8Ms7/mQWfZkygZDQ+xE4FYzyBk61rYcFZ9nNuFNCLU Frt30iohBgo415JSFs1TcbKOXxAxe6nuj2kH3ELVtUujKd3cwAMfA5xbN6yZmr1XahR1 Y4PZE0t3aHhfFw2L4yCkceQH1VPkaBxO9Ad64/QUXkv1yU9yRfld7spSTpo9d7DH4yZ8 yCuw== X-Gm-Message-State: AKGB3mLzR76BneP3K13cU4g728K/1rH9vLHBNpgXEonqRSZUdm+EeLTI kTPnNl3K3hQR4jaGLFdo0n+eSiC0CXO47Shvy4s= X-Google-Smtp-Source: ACJfBouOCbL3tU09HUJuqBVU7NJTqZ34MWmOWG/tWreMEjJYJAVDtlxY6UwE2/KKOkGtG4UUiQ15wxHuWagciYNvWMA= X-Received: by 10.84.217.14 with SMTP id o14mr9987516pli.78.1515640362484; Wed, 10 Jan 2018 19:12:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Wed, 10 Jan 2018 19:12:02 -0800 (PST) In-Reply-To: <20180110194529.3myrio6vrvsn3jjh@elstar.local> References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> From: Kathleen Moriarty Date: Wed, 10 Jan 2018 22:12:02 -0500 Message-ID: To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:12:46 -0000 Hi Juergen, Thanks for your quick response. Inline. On Wed, Jan 10, 2018 at 2:45 PM, Juergen Schoenwaelder wrote: > On Wed, Jan 10, 2018 at 11:21:13AM -0800, Kathleen Moriarty wrote: >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Hello, >> >> Thanks for your work on this draft. I'm a little confused with some tex= t in >> the draft and have a few questions. >> >> 1. The introductions says, >> "This architectural framework identifies a set of conceptual datastores = but >> it does not mandate that all network management protocols expose all >> these conceptual datastores. This architecture is agnostic with >> regard to the encoding used by network management protocols." >> >> As such, the data stores could be exposed for some implementations, usin= g >> whatever network management protocol (likely NetCONF or RESTCONF). If t= his is >> the case, why doesn't at least some of the security considerations templ= ate >> apply for at least secure transport? > > The security considerations text is IMHO correct. The YANG modules define= d > in this document do not define any accessible objects. Hence, the securit= y > YANG template does not apply. Could you make that more clear in the document? The section from the introduction quoted above says it is possible if network management protocols expose the datastores. > >> 2. Section 5.3.4 - Is there any integrity protection on the origin infor= mation? >> If not, can it be added or is there a good reason why it=E2=80=99s not = possible? I >> realize these are conceptual models that may or may not be exposed, but = if >> exposed and used, wouldn=E2=80=99t some integrity protection on this be = helpful? > > Can you clarify what you mean with 'integrity protection' in this > context and why you think origin attributes are special? The known > published network management protocols all use standard security > protocols (SSH and TLS). In general, security mechanisms are protocol > specific, I do not see how the architectual definition of datastores > requires discussion of special integrity mechanisms. Perhaps I do not > understand your concern. > What I'm wondering here and wanted to discuss was really how the information on origin information will be used. Does this information need to be from a source that can be validated? If so, should there be some way to provide a MAC for the values for origin information in the data stores? I am not referring to transport in this second question. Your answer may be an explanation of how the origin information will be used that excludes any need for integrity protection. I just wasn't clear on how the information from the data stores will be used from the draft. Thank you, Kathleen > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Best regards, Kathleen From nobody Wed Jan 10 20:16: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 8DF8112E877 for ; Wed, 10 Jan 2018 20:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 DVNrCmD9fdy4 for ; Wed, 10 Jan 2018 20:16:18 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 60684124B17 for ; Wed, 10 Jan 2018 20:16:18 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id j129so818137oib.12 for ; Wed, 10 Jan 2018 20:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kis1SYAuKj6gJ0j1AwQGdgD5FmQFcFbyAH741r2tj5c=; b=ECTEez9hQ4wfhmoqCZR9yzn8XPopS6+grnj2xnMUPKToVWqgk3T5UNhM6tEERwcmSZ 0YxqJCnwRKe620f+N9nS2gqYuLgC8UKihpW2y6k6xE1RsB27tfh4a4ga7H9ZUbPruAL+ ag0cwJQHL1wNgLadSje2Tmy2RL/Gjl5pE8RNZnbn8GsqpasTEhnNiBHdwV5U7C5lvcEJ Az9OUa3LAx8z0lH8phCbhViJTqy8I8A+X94an6Je/nWBuA0oPibfPAmBVhKxea6SK4F8 Fhx/gfpPdvu0CqcF+yUEMNNYpbnkmKkN1HkaCQubU36EJHX5KTWbjjSG3S57azbo8xTw jF2w== 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=kis1SYAuKj6gJ0j1AwQGdgD5FmQFcFbyAH741r2tj5c=; b=lZZyCy28VTFkb89EtHHfiMuODJZKsU14F5+ruW9QSa5xFiesbgC4GCKXZLY26Z1OaI GM+yu/k9JU79tf+w0t0xipyrlyQSfrfMkoWkRqZzWGSz8Hq+qoWit8g+KIx5+K8bUAB5 PocQNi4+ao70Ym/S2IvBogWZofW3APpc/g8Shl8rPVYuwGu5xw4JfbtXPOaPXIfrNJ9U p2vsZvSFB7AYzRr6kIvIXelR4JeTiv9DMqTcKHVLozOFCe7BXwjBgd1Op2V0svpkUAFR qyMjC0sfLzLDZeadzPKHgRtpvA+2meFxhtQCr43/cAmKA4xB2BHvXq9bzuwoZQXmmNIO I+7A== X-Gm-Message-State: AKwxytfCbHc3qg5/+bY1d7l/Vx23xu3GCnaQGuIX2uWPiBc6c3P/Yn5y g4l8/sJ6FMfS2pRNHjNL73c= X-Google-Smtp-Source: ACJfBotKu2dbgRW4MM8GVL+aeJZ5YMODblvRomW3o4DFBYbPDleP1KBYO5yFausP4Fxn6HGkxqvjrw== X-Received: by 10.202.199.82 with SMTP id x79mr5810136oif.159.1515644177130; Wed, 10 Jan 2018 20:16:17 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:cde:2fd2:87ac:1a5f]) by smtp.gmail.com with ESMTPSA id t124sm8053912oih.48.2018.01.10.20.16.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 20:16:16 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_717AA6EC-1EBE-4E14-9EB3-E7868633B2D2" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 20:16:13 -0800 In-Reply-To: Cc: "netmod@ietf.org" To: "Einar Nilsen-Nygaard (einarnn)" References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 04:16:23 -0000 --Apple-Mail=_717AA6EC-1EBE-4E14-9EB3-E7868633B2D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) = wrote: >=20 > Mahesh, >=20 > Two things: >=20 > First, I see that you have still left in the =E2=80=9Cicmp-off=E2=80=9D = action. This was something both Kristian and I recommended removing, and = I also discussed this with Sonal at the end of last year and she agreed = that it should probably be removed since it seems at this point (absent = anyone pointing out other implementations) to be a Cisco IOS-XR-specific = feature that should probably be dealt with via a vendor augmentation = initially. Can we remove this? You are right. It was discussed, but more to understand why we needed = it. Before we remove it, let me clarify why we need it, and if after = that the consensus is still to remove it, or move it to a Cisco specific = augmentation, we can do it. The idea behind having the leaf is for routers to setup a rule to accept = ICMP messages, allow the router to process the message, but suggest that = a response may be suppressed. That way one can have rules to receive and = process ICMP messages like =E2=80=9Cdestination unreachable=E2=80=9D or = =E2=80=9Cfragmentation required=E2=80=9D that are important for = routers/hosts, but prevent rogue machines from discovering machines in a = sweeping ping.=20 >=20 > Second, I would really like the contributors who wish to maintain the = separate ACL attachment interface list with interface references to lay = out how direct interface attachment prevents ACLs being used with other = attachment points. As I pointed out, direct interface attachment does = not remove any flexibility at all for other future attachment points. = While I=E2=80=99m not intrinsically opposed to a separate list with = interface refs, I just want to understand the rationale as the majority = of switches and routers, as far as I am aware, typically attach ACLs = directly to interfaces, meaning that the pattern is well-understood by = typical users of this model. I think the first issue in setting up alternate attachment point is, how = would you do setup the alternate attachment point as a choice between it = and attaching it to an interface under an augmentation. Secondly, if the = ACLs are used with multiple NI, each of them referring to the global set = of ietf-interfaces shared by all the instances, which the schema mount = draft outlines here = ,= it implies that you will need a reference to the interfaces.=20 Thanks. >=20 > Cheers, >=20 > Einar >=20 >=20 >> On 10 Jan 2018, at 03:08, Mahesh Jethanandani = > wrote: >>=20 >> I have pulled in the changes as they relate to: >>=20 >> - moving =E2=80=9Cinterface-acl=E2=80=9D under the container = =E2=80=9Cattachment-points=E2=80=9D making it local to that container. >> - reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ctype=E2=80=9D >> - removed =E2=80=9Cinterface-all-aggregate=E2=80=9D feature >> - simplified source port and destination port definition >>=20 >> The pull request for the changes can be found here. >>=20 >> https://github.com/netmod-wg/acl-model/pull/20 = >>=20 >> After discussing with some of the original contributors, decided not = to include the change as it relates to augmenting ietf-interfaces. We = did not find that the change had a particular advantage over the current = implementation. Even if we do not completely understand how ACLs might = be attached =E2=80=9Cglobally=E2=80=9D or on something that is not an = interface, having the flexibility to attach them to other attachment = points is important. Keeping it as interface-ref gives us that = flexibility. >>=20 >> Cheers. >>=20 >>> On Dec 18, 2017, at 4:31 AM, Eliot Lear > wrote: >>>=20 >>> So long as nobody expects an interface construct in a MUD file, I'm = happy. >>>=20 >>> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: >>>> Eliot, >>>>=20 >>>> Nothing can force an implementation to have to implement either the = ietf-interfaces model or the augmentation in the = ietf-access-control-list model. I appreciate your desire for modularity = and cohesiveness, but I would resist #1, because I feel that the = majority of users will be targeting interface-based attachment over = time. I=E2=80=99ve adde back in use of the =E2=80=9Cinterface-attachment=E2= =80=9D feature (which I took out as part of refactoring interface = attachment). Part of: >>>>=20 >>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>=20 >>>> The augments part of the tree now looks like: >>>>=20 >>>> augment /if:interfaces/if:interface: >>>> +--rw acls {interface-attachment}? >>>> +--rw ingress >>>> | +--rw acl-sets >>>> | +--rw acl-set* [name] >>>> | +--rw name -> /access-lists/acl/name >>>> | +--rw type? -> /access-lists/acl/type >>>> | +--ro ace-statistics* [name] {interface-stats}? >>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>> | +--ro matched-packets? yang:counter64 >>>> | +--ro matched-octets? yang:counter64 >>>> +--rw egress >>>> +--rw acl-sets >>>> +--rw acl-set* [name] >>>> +--rw name -> /access-lists/acl/name >>>> +--rw type? -> /access-lists/acl/type >>>> +--ro ace-statistics* [name] {interface-stats}? >>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>> +--ro matched-packets? yang:counter64 >>>> +--ro matched-octets? yang:counter64 >>>>=20 >>>> Cheers, >>>>=20 >>>> Einar >>>>=20 >>>>=20 >>>>> On 17 Dec 2017, at 11:29, Eliot Lear > wrote: >>>>>=20 >>>>> Einar, >>>>>=20 >>>>> I think this change is fine, with one exception. I would rather = the augment to the interface not be required for implementations that = don't actually have interfaces. I understand that there may be two ways = to go about this: >>>>>=20 >>>>> Separate out the augment into a separate module (same doc is = fine); or >>>>> Somehow "feature-ize" the augment. >>>>> I don't know how to do (2) but if you do, that's okay by me. >>>>>=20 >>>>> Eliot >>>>>=20 >>>>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote: >>>>>> All, >>>>>>=20 >>>>>> After a series of discussions on- and off-list, I have a = candidate PR that includes the changes in the PR Mahesh sent out plus = some more edits. Please see consolidated PR here: >>>>>>=20 >>>>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>>>=20 >>>>>> Main changes in addition to Mahesh=E2=80=99s PR are: >>>>>>=20 >>>>>> Moved interface attachment to be via an interface augmentation. >>>>>> Restructured port matches slightly under both IPv4 and IPv6 = containers. >>>>>> Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. >>>>>> Removed action =E2=80=98icmp-off=E2=80=99, can be augmented = later. >>>>>>=20 >>>>>> For reference, here is the current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs: >>>>>>=20 >>>>>> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang >>>>>> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" = (should be date) >>>>>> module: ietf-access-control-list >>>>>> +--rw access-lists >>>>>> +--rw acl* [name] >>>>>> +--rw name string >>>>>> +--rw type? acl-type >>>>>> +--rw aces >>>>>> +--rw ace* [name] >>>>>> +--rw name string >>>>>> +--rw matches >>>>>> | +--rw (l2)? >>>>>> | | +--:(eth) >>>>>> | | +--rw eth {match-on-eth}? >>>>>> | | +--rw destination-mac-address? = yang:mac-address >>>>>> | | +--rw destination-mac-address-mask? = yang:mac-address >>>>>> | | +--rw source-mac-address? = yang:mac-address >>>>>> | | +--rw source-mac-address-mask? = yang:mac-address >>>>>> | | +--rw ethertype? = eth:ethertype >>>>>> | +--rw (l3)? >>>>>> | | +--:(ipv4) >>>>>> | | | +--rw ipv4 {match-on-ipv4}? >>>>>> | | | +--rw dscp? = inet:dscp >>>>>> | | | +--rw ecn? = uint8 >>>>>> | | | +--rw length? = uint16 >>>>>> | | | +--rw ttl? = uint8 >>>>>> | | | +--rw protocol? = uint8 >>>>>> | | | +--rw = (source-port-range-or-operator)? >>>>>> | | | | +--:(range) >>>>>> | | | | | +--rw source-port-lower = inet:port-number >>>>>> | | | | | +--rw source-port-upper = inet:port-number >>>>>> | | | | +--:(operator) >>>>>> | | | | +--rw source-operator = operator >>>>>> | | | | +--rw source-port = inet:port-number >>>>>> | | | +--rw = (destination-port-range-or-operator)? >>>>>> | | | | +--:(range) >>>>>> | | | | | +--rw destination-port-lower = inet:port-number >>>>>> | | | | | +--rw destination-port-upper = inet:port-number >>>>>> | | | | +--:(operator) >>>>>> | | | | +--rw destination-operator = operator >>>>>> | | | | +--rw destination-port = inet:port-number >>>>>> | | | +--rw ihl? = uint8 >>>>>> | | | +--rw flags? = bits >>>>>> | | | +--rw offset? = uint16 >>>>>> | | | +--rw identification? = uint16 >>>>>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>>>>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>>>>> | | +--:(ipv6) >>>>>> | | +--rw ipv6 {match-on-ipv6}? >>>>>> | | +--rw dscp? = inet:dscp >>>>>> | | +--rw ecn? = uint8 >>>>>> | | +--rw length? = uint16 >>>>>> | | +--rw ttl? = uint8 >>>>>> | | +--rw protocol? = uint8 >>>>>> | | +--rw = (source-port-range-or-operator)? >>>>>> | | | +--:(range) >>>>>> | | | | +--rw source-port-lower = inet:port-number >>>>>> | | | | +--rw source-port-upper = inet:port-number >>>>>> | | | +--:(operator) >>>>>> | | | +--rw source-operator = operator >>>>>> | | | +--rw source-port = inet:port-number >>>>>> | | +--rw = (destination-port-range-or-operator)? >>>>>> | | | +--:(range) >>>>>> | | | | +--rw destination-port-lower = inet:port-number >>>>>> | | | | +--rw destination-port-upper = inet:port-number >>>>>> | | | +--:(operator) >>>>>> | | | +--rw destination-operator = operator >>>>>> | | | +--rw destination-port = inet:port-number >>>>>> | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>>>>> | | +--rw source-ipv6-network? = inet:ipv6-prefix >>>>>> | | +--rw flow-label? = inet:ipv6-flow-label >>>>>> | +--rw (l4)? >>>>>> | | +--:(tcp) >>>>>> | | | +--rw tcp {match-on-tcp}? >>>>>> | | | +--rw sequence-number? = uint32 >>>>>> | | | +--rw acknowledgement-number? = uint32 >>>>>> | | | +--rw data-offset? uint8 >>>>>> | | | +--rw reserved? uint8 >>>>>> | | | +--rw flags? bits >>>>>> | | | +--rw window-size? = uint16 >>>>>> | | | +--rw urgent-pointer? = uint16 >>>>>> | | | +--rw options? = uint32 >>>>>> | | +--:(udp) >>>>>> | | | +--rw udp {match-on-udp}? >>>>>> | | | +--rw length? uint16 >>>>>> | | +--:(icmp) >>>>>> | | +--rw icmp {match-on-icmp}? >>>>>> | | +--rw type? uint8 >>>>>> | | +--rw code? uint8 >>>>>> | | +--rw rest-of-header? uint32 >>>>>> | +--rw egress-interface? if:interface-ref >>>>>> | +--rw ingress-interface? if:interface-ref >>>>>> +--rw actions >>>>>> | +--rw forwarding identityref >>>>>> | +--rw logging? identityref >>>>>> +--ro statistics {acl-aggregate-stats}? >>>>>> +--ro matched-packets? yang:counter64 >>>>>> +--ro matched-octets? yang:counter64 >>>>>>=20 >>>>>> augment /if:interfaces/if:interface: >>>>>> +--rw acls >>>>>> +--rw ingress >>>>>> | +--rw acl-sets >>>>>> | +--rw acl-set* [name] >>>>>> | +--rw name -> /access-lists/acl/name >>>>>> | +--rw type? -> /access-lists/acl/type >>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> | +--ro matched-packets? yang:counter64 >>>>>> | +--ro matched-octets? yang:counter64 >>>>>> +--rw egress >>>>>> +--rw acl-sets >>>>>> +--rw acl-set* [name] >>>>>> +--rw name -> /access-lists/acl/name >>>>>> +--rw type? -> /access-lists/acl/type >>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> +--ro matched-packets? yang:counter64 >>>>>> +--ro matched-octets? yang:counter64 >>>>>>=20 >>>>>> Comments welcome! >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Einar >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal > wrote: >>>>>>>>=20 >>>>>>>> Hi Einar, >>>>>>>>=20 >>>>>>>> You had 3 questions for me on all the several e-mail threads.=20= >>>>>>>> 1. Global attachment point >>>>>>>> 2. icmp-off >>>>>>>> 3. acl-aggregate-interface stats. >>>>>>>>=20 >>>>>>>> For (1), my first preference is to have the model define = attachment point for interfaces only. >>>>>>>=20 >>>>>>> einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to netmod-wg/acl-model that do this. Nearly like the augmentation I = have below. Feel free to take a look at: >>>>>>>=20 >>>>>>> https://github.com/mjethanandani/acl-model/pull/3 = >>>>>>>=20 >>>>>>>> However, Kristian wants the global attachment point as well so = that he can add the ACL to the linux tables. >>>>>>>=20 >>>>>>> einarnn> I think Kristian doesn=E2=80=99t feel a global = attachment point needs to be in this first revision. But he can confirm. >>>>>>>=20 >>>>>>>> If an ACL is attached globally, does this mean it is per = direction or does it mean it is across directions? >>>>>>>=20 >>>>>>> einarnn> I don=E2=80=99t know right now :-) >>>>>>>=20 >>>>>>>> This global ACL may not be applicable to any of Cisco's service = provider routers as I don't see any platform actually replicating the = ACL to all line cards and attaching it in ingress and egress directions = across all interfaces. >>>>>>>=20 >>>>>>> einarnn> Per other emails, I don=E2=80=99t think we understand = this enough yet to specify it, so I suggest we just leave it out for = now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80= =9D being added later once we understand what it really means. >>>>>>>=20 >>>>>>>> For (2), I am ok with removing icmp-off. >>>>>>>=20 >>>>>>> einarnn> Done in my PR above. >>>>>>>=20 >>>>>>>> For (3), this would have to be a combination of ACL stats = across all interfaces for all ACL's. Something like this is possible on = an XR box where ACES have counter names associated with it. Let's chat = about this offline tomorrow. >>>>>>>=20 >>>>>>> einarnn> I=E2=80=99ll ping you to clarify, and we can bring any = conclusion back to the list. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Einar >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Sonal. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani = > wrote: >>>>>>>> We want to support =E2=80=9Cglobal=E2=80=9D attachment point = down the line, and that =E2=80=9Cglobal=E2=80=9D attachment point will = be one of the choices (the other being the interface), what would this = augment look like. Note, as far as I know, you cannot augment inside a = choice node. >>>>>>>>=20 >>>>>>>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>>>=20 >>>>>>>>> Perhaps like this, as an augmentation to the interface: >>>>>>>>>=20 >>>>>>>>> augment /if:interfaces/if:interface: >>>>>>>>> +--rw ingress-acls >>>>>>>>> | +--rw acl-sets >>>>>>>>> | +--rw acl-set* [name] >>>>>>>>> | +--rw name -> /access-lists/acl/name >>>>>>>>> | +--rw type? -> /access-lists/acl/type >>>>>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>> | +--ro matched-packets? yang:counter64 >>>>>>>>> | +--ro matched-octets? yang:counter64 >>>>>>>>> +--rw egress-acls >>>>>>>>> +--rw acl-sets >>>>>>>>> +--rw acl-set* [name] >>>>>>>>> +--rw name -> /access-lists/acl/name >>>>>>>>> +--rw type? -> /access-lists/acl/type >>>>>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>> +--ro matched-packets? yang:counter64 >>>>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>>>=20 >>>>>>>>> Could also put an =E2=80=9Caces=E2=80=9D container above both = these & rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. = to give a single root for the augmentation if preferred. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Einar >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 6 Dec 2017, at 19:43, Eliot Lear > wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote: >>>>>>>>>>> How does one move the interface attachment point, currently = an >>>>>>>>>>> 'interface-ref', to an augmentation of the = if:interfaces/interface, >>>>>>>>>>> inside of the =E2=80=98acl=E2=80=99 container? Down the = line we might need to have an >>>>>>>>>>> container for "attachment points" to accommodate the = possibility of >>>>>>>>>>> attaching an ACL either to an interface or =E2=80=9Cglobally=E2= =80=9D. >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Keeping in mind that one use is that an ACL doesn't attach to = an >>>>>>>>>> interface at all. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> netmod mailing list >>>>>>>>>> netmod@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Mahesh Jethanandani >>>>>>>> mjethanandani@gmail.com >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_717AA6EC-1EBE-4E14-9EB3-E7868633B2D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) = <einarnn@cisco.com> wrote:

Mahesh,

Two things:

First, I see that you have still left in the = =E2=80=9Cicmp-off=E2=80=9D action. This was something both Kristian and = I recommended removing, and I also discussed this with Sonal at the end = of last year and she agreed that it should probably be removed since it seems at this point (absent anyone pointing out other implementations) = to be a Cisco IOS-XR-specific feature that should probably be dealt with = via a vendor augmentation initially. Can we remove = this?

You = are right. It was discussed, but more to understand why we needed it. = Before we remove it, let me clarify why we need it, and if after that = the consensus is still to remove it, or move it to a Cisco specific = augmentation, we can do it.

The idea = behind having the leaf is for routers to setup a rule to accept ICMP = messages, allow the router to process the message, but suggest that a = response may be suppressed. That way one can have rules to receive and = process ICMP messages like =E2=80=9Cdestination unreachable=E2=80=9D or = =E2=80=9Cfragmentation required=E2=80=9D that are important for = routers/hosts, but prevent rogue machines from discovering machines in a = sweeping ping. 


Second, I would really like the contributors who wish to = maintain the separate ACL attachment interface list with interface = references to lay out how direct interface attachment prevents ACLs = being used with other attachment points. As I pointed out, direct interface attachment does not remove any flexibility at all = for other future attachment points. While I=E2=80=99m not intrinsically = opposed to a separate list with interface refs, I just want to = understand the rationale as the majority of switches and routers, as far as I am aware, typically attach ACLs directly to = interfaces, meaning that the pattern is well-understood by typical users = of this model.

I think the first issue in setting up alternate = attachment point is, how would you do setup the alternate attachment = point as a choice between it and attaching it to an interface under an = augmentation. Secondly, if the ACLs are used with multiple NI, each of = them referring to the global set of ietf-interfaces shared by all the = instances, which the schema mount draft outlines here, it implies that you will need a = reference to the interfaces. 

Thanks.


Cheers,

Einar


On 10 Jan 2018, at 03:08, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

I have pulled in the changes as they relate to:

- moving =E2=80=9Cinterface-acl=E2=80=9D under the = container =E2=80=9Cattachment-points=E2=80=9D making it local to that = container.
- reverting =E2=80=9Cacl-type=E2=80=9D to = =E2=80=9Ctype=E2=80=9D
- removed =E2=80=9Cinterface-all-aggregate=E2=80=9D = feature
- simplified source port and destination port = definition

The pull request for the changes can be found = here.

https://github.com/netmod-wg/acl-model/pull/20

After discussing with some of the original contributors, = decided not to include the change as it relates to augmenting = ietf-interfaces. We did not find that the change had a particular = advantage over the current implementation. Even if we do not completely understand how ACLs might be attached =E2=80=9Cglobally=E2=80=9D= or on something that is not an interface, having the flexibility to = attach them to other attachment points is important. Keeping it as = interface-ref gives us that flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, Eliot Lear <lear@cisco.com> = wrote:

So = long as nobody expects an interface construct in a MUD file, I'm = happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard = (einarnn) wrote:
Eliot,

Nothing can force an implementation to have to implement = either the ietf-interfaces model or the augmentation in the = ietf-access-control-list model. I appreciate your desire for modularity = and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment = over time. I=E2=80=99ve adde back in use of the = =E2=80=9Cinterface-attachment=E2=80=9D feature (which I took out as part = of refactoring interface attachment). Part of:

https://github.com/netmod-wg/acl-model/pull/21

The augments part of the tree now looks like:

  augment = /if:interfaces/if:interface:
    +--rw = acls {interface-attachment}?
      =  +--rw ingress
      =  |  +--rw acl-sets
      =  |     +--rw acl-set* [name]
      =  |        +--rw name       =        -> /access-lists/acl/name
      =  |        +--rw type?       =       -> /access-lists/acl/type
      =  |        +--ro ace-statistics* [name] = {interface-stats}?
      =  |           +--ro name     =           -> = /access-lists/acl/aces/ace/name
      =  |           +--ro matched-packets?   = yang:counter64
      =  |           +--ro matched-octets?   =  yang:counter64
      =  +--rw egress
      =     +--rw acl-sets
      =        +--rw acl-set* [name]
      =           +--rw name       =        -> /access-lists/acl/name
      =           +--rw type?       =       -> /access-lists/acl/type
      =           +--ro ace-statistics* [name] = {interface-stats}?
      =              +--ro name     =           -> = /access-lists/acl/aces/ace/name
      =              +--ro matched-packets? =   yang:counter64
      =              +--ro matched-octets? =    yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:

Einar,

I think this change is fine, with one = exception.  I would rather the augment to the interface not be = required for implementations that don't actually have interfaces.  = I understand that there may be two ways to go about this:

  1. Separate out the augment into a separate module (same doc = is fine); or
  2. Somehow "feature-ize" the augment.

I don't know how to do (2) but if you do, that's okay by = me.

Eliot


On 16.12.17 14:19, Einar Nilsen-Nygaard = (einarnn) wrote:
All,

After a series of discussions on- and off-list, I have a = candidate PR that includes the changes in the PR Mahesh sent out plus = some more edits. Please see consolidated PR here:

https://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to Mahesh=E2=80=99s PR = are:

  • Moved interface attachment to be via an interface = augmentation.
  • Restructured port matches slightly = under both IPv4 and IPv6 containers.
  • Removed unnecessary identity = 'interface-acl-aggregate=E2=80=99.
  • Removed action = =E2=80=98icmp-off=E2=80=99, can be augmented later.

For reference, here is the current YANG tree plus = =E2=80=9C--ietf=E2=80=9D logs:

13:12 $ pyang --ietf = --lint -f tree ietf-access-control-list.yang
ietf-access-control-list.yang:51: error: bad value = "YYYY-MM-DD" (should be date)
module: = ietf-access-control-list
    +--rw = access-lists
      =  +--rw acl* [name]
      =     +--rw name    string
      =     +--rw type?   acl-type
      =     +--rw aces
      =        +--rw ace* [name]
      =           +--rw name       =    string
      =           +--rw matches
      =           |  +--rw (l2)?
      =           |  | =  +--:(eth)
      =           |  |     +--rw eth = {match-on-eth}?
      =           |  |       =  +--rw destination-mac-address?       =  yang:mac-address
      =           |  |       =  +--rw destination-mac-address-mask?   = yang:mac-address
      =           |  |       =  +--rw source-mac-address?           =   yang:mac-address
      =           |  |       =  +--rw source-mac-address-mask?       =  yang:mac-address
      =           |  |       =  +--rw ethertype?               =        eth:ethertype
      =           |  +--rw (l3)?
      =           |  | =  +--:(ipv4)
      =           |  |  |  +--rw ipv4 = {match-on-ipv4}?
      =           |  |  |     +--rw = dscp?                   =     inet:dscp
      =           |  |  |     +--rw = ecn?                   =      uint8
      =           |  |  |     +--rw = length?                   =   uint16
      =           |  |  |     +--rw = ttl?                   =      uint8
      =           |  |  |     +--rw = protocol?                   = uint8
      =           |  |  |     +--rw = (source-port-range-or-operator)?
      =           |  |  |     | =  +--:(range)
      =           |  |  |     | =  |  +--rw source-port-lower           = inet:port-number
      =           |  |  |     | =  |  +--rw source-port-upper           = inet:port-number
      =           |  |  |     | =  +--:(operator)
      =           |  |  |     | =     +--rw source-operator           =   operator
      =           |  |  |     | =     +--rw source-port           =       inet:port-number
      =           |  |  |     +--rw = (destination-port-range-or-operator)?
      =           |  |  |     | =  +--:(range)
      =           |  |  |     | =  |  +--rw destination-port-lower     =  inet:port-number
      =           |  |  |     | =  |  +--rw destination-port-upper     =  inet:port-number
      =           |  |  |     | =  +--:(operator)
      =           |  |  |     | =     +--rw destination-operator       =  operator
      =           |  |  |     | =     +--rw destination-port           =  inet:port-number
      =           |  |  |     +--rw = ihl?                   =      uint8
      =           |  |  |     +--rw = flags?                   =    bits
      =           |  |  |     +--rw = offset?                   =   uint16
      =           |  |  |     +--rw = identification?             = uint16
      =           |  |  |     +--rw = destination-ipv4-network?   inet:ipv4-prefix
      =           |  |  |     +--rw = source-ipv4-network?       =  inet:ipv4-prefix
      =           |  | =  +--:(ipv6)
      =           |  |     +--rw ipv6 = {match-on-ipv6}?
      =           |  |       =  +--rw dscp?               =         inet:dscp
      =           |  |       =  +--rw ecn?                 =        uint8
      =           |  |       =  +--rw length?               =       uint16
      =           |  |       =  +--rw ttl?                 =        uint8
      =           |  |       =  +--rw protocol?               =     uint8
      =           |  |       =  +--rw (source-port-range-or-operator)?
      =           |  |       =  |  +--:(range)
      =           |  |       =  |  |  +--rw source-port-lower       =     inet:port-number
      =           |  |       =  |  |  +--rw source-port-upper       =     inet:port-number
      =           |  |       =  |  +--:(operator)
      =           |  |       =  |     +--rw source-operator         =     operator
      =           |  |       =  |     +--rw source-port         =         inet:port-number
      =           |  |       =  +--rw (destination-port-range-or-operator)?
      =           |  |       =  |  +--:(range)
      =           |  |       =  |  |  +--rw destination-port-lower     =  inet:port-number
      =           |  |       =  |  |  +--rw destination-port-upper     =  inet:port-number
      =           |  |       =  |  +--:(operator)
      =           |  |       =  |     +--rw destination-operator       =  operator
      =           |  |       =  |     +--rw destination-port         =    inet:port-number
      =           |  |       =  +--rw destination-ipv6-network?   = inet:ipv6-prefix
      =           |  |       =  +--rw source-ipv6-network?       =  inet:ipv6-prefix
      =           |  |       =  +--rw flow-label?               =   inet:ipv6-flow-label
      =           |  +--rw (l4)?
      =           |  | =  +--:(tcp)
      =           |  |  |  +--rw tcp = {match-on-tcp}?
      =           |  |  |     +--rw = sequence-number?          uint32
      =           |  |  |     +--rw = acknowledgement-number?   uint32
      =           |  |  |     +--rw = data-offset?             =  uint8
      =           |  |  |     +--rw = reserved?                 = uint8
      =           |  |  |     +--rw = flags?                   =  bits
      =           |  |  |     +--rw = window-size?             =  uint16
      =           |  |  |     +--rw = urgent-pointer?           uint16
      =           |  |  |     +--rw = options?                 =  uint32
      =           |  | =  +--:(udp)
      =           |  |  |  +--rw udp = {match-on-udp}?
      =           |  |  |     +--rw = length?   uint16
      =           |  | =  +--:(icmp)
      =           |  |     +--rw icmp = {match-on-icmp}?
      =           |  |       =  +--rw type?             = uint8
      =           |  |       =  +--rw code?             = uint8
      =           |  |       =  +--rw rest-of-header?   uint32
      =           |  +--rw egress-interface? =    if:interface-ref
      =           |  +--rw ingress-interface? =   if:interface-ref
      =           +--rw actions
      =           |  +--rw forwarding   =  identityref
      =           |  +--rw logging?     =  identityref
      =           +--ro statistics = {acl-aggregate-stats}?
      =              +--ro matched-packets? =   yang:counter64
      =              +--ro matched-octets? =    yang:counter64

  augment = /if:interfaces/if:interface:
    +--rw = acls
      =  +--rw ingress
      =  |  +--rw acl-sets
      =  |     +--rw acl-set* [name]
      =  |        +--rw name       =        -> /access-lists/acl/name
      =  |        +--rw type?       =       -> /access-lists/acl/type
      =  |        +--ro ace-statistics* [name] = {interface-stats}?
      =  |           +--ro name     =           -> = /access-lists/acl/aces/ace/name
      =  |           +--ro matched-packets?   = yang:counter64
      =  |           +--ro matched-octets?   =  yang:counter64
      =  +--rw egress
      =     +--rw acl-sets
      =        +--rw acl-set* [name]
      =           +--rw name       =        -> /access-lists/acl/name
      =           +--rw type?       =       -> /access-lists/acl/type
      =           +--ro ace-statistics* [name] = {interface-stats}?
      =              +--ro name     =           -> = /access-lists/acl/aces/ace/name
      =              +--ro matched-packets? =   yang:counter64
      =              +--ro matched-octets? =    yang:counter64

Comments welcome!

Cheers,

Einar



On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) = <einarnn@cisco.com> wrote:



On 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Einar,

You had 3 questions for me on all the several e-mail = threads. 
1. Global attachment point
2. icmp-off
3. acl-aggregate-interface stats.

For (1), my first preference is to have the model define = attachment point for interfaces only.

einarnn> I have some diffs, layered on top of = Mahesh=E2=80=99s PR to netmod-wg/acl-model that do this. Nearly like the = augmentation I have below. Feel free to take a look at:

https://github.com/mjethanandani/acl-model/pull/3=

However, Kristian wants the global attachment point as = well so that he can add the ACL to the linux tables.

einarnn> I think Kristian doesn=E2=80=99t feel a = global attachment point needs to be in this first revision. But he can = confirm.

If an ACL is attached globally, does this mean it is per = direction or does it mean it is across directions?

einarnn> I don=E2=80=99t know right now :-)

This global ACL may not be applicable to any of Cisco's = service provider routers as I don't see any platform actually = replicating the ACL to all line cards and attaching it in ingress and = egress directions across all interfaces.

einarnn> Per other emails, I don=E2=80=99t think we = understand this enough yet to specify it, so I suggest we just leave it = out for now. Nothing in the model prevents a =E2=80=9Cglobal attachment = point=E2=80=9D being added later once we understand what it really = means.

For (2), I am ok with removing icmp-off.

einarnn> Done in my PR above.

For (3), this would have to be a combination of ACL = stats across all interfaces for all ACL's. Something like this is = possible on an XR box where ACES have counter names associated with it. = Let's chat about this offline tomorrow.

einarnn> I=E2=80=99ll ping you to clarify, and we can = bring any conclusion back to the list.

Cheers,

Einar



Sonal.


On Wed, Dec 13, 2017 at 12:10 PM, Mahesh = Jethanandani <mjethanandani@gmail.com>= wrote:
We want to support = =E2=80=9Cglobal=E2=80=9D attachment point down the line, and that = =E2=80=9Cglobal=E2=80=9D attachment point will be one of the choices = (the other being the interface), what would this augment look like. = Note, as far as I know, you cannot augment inside a choice node.

On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard = (einarnn) <einarnn@cisco.com> = wrote:

Perhaps like this, as an augmentation to the interface:

  augment = /if:interfaces/if:interface:
    +--rw = ingress-acls
    | =  +--rw acl-sets
    |   =   +--rw acl-set* [name]
    |   =      +--rw name             =  -> /access-lists/acl/name
    |   =      +--rw type?           =   -> /access-lists/acl/type
    |   =      +--ro ace-statistics* [name] = {interface-stats}?
    |   =         +--ro name         =       -> /access-lists/acl/aces/ace/name
    |   =         +--ro matched-packets?   = yang:counter64
    |   =         +--ro matched-octets?   =  yang:counter64
    +--rw = egress-acls
      =  +--rw acl-sets
      =     +--rw acl-set* [name]
      =        +--rw name           =    -> /access-lists/acl/name
      =        +--rw type?         =     -> /access-lists/acl/type
      =        +--ro ace-statistics* [name] = {interface-stats}?
      =           +--ro name       =         -> /access-lists/acl/aces/ace/name
      =           +--ro matched-packets?   = yang:counter64
      =           +--ro matched-octets?   =  yang:counter64

Could also put an =E2=80=9Caces=E2=80=9D container above = both these & rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D= , etc. to give a single root for the augmentation if preferred.

Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com> wrote:



On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface = attachment point, currently an
'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2=80=99  container? Down the line we = might need to have an
container for "attachment points" to accommodate the possibility of
attaching an ACL either to an interface or =E2=80=9Cglobally=E2=80=9D.


Keeping in mind that one use is that an ACL doesn't attach to an
interface at all.

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


Mahesh Jethanandani
mjethanandani@gmail.com


_______________________________________________
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<= br class=3D""> 



_______________________________________________
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
=

Mahesh Jethanandani
mjethanandani@gmail.com

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


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_717AA6EC-1EBE-4E14-9EB3-E7868633B2D2-- From nobody Wed Jan 10 22:55: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 C588512EA67; Wed, 10 Jan 2018 22:55:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-netmod-entity@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 22:55:46 -0800 Archived-At: Subject: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 06:55:47 -0000 Adam Roach has entered the following ballot position for draft-ietf-netmod-entity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have one correction and one question about the ietf-hardware YANG module. enum exa { value 14; description "Data scaling factor of 10^15."; } enum peta { value 15; description "Data scaling factor of 10^18."; } I believe this is backwards -- "peta" should be 10^15, while "exa" should be 10^18. ---- typedef sensor-value-precision { type int32 { range "-8 .. 9"; } Why is this an int32 rather than an int8? From nobody Wed Jan 10 23:00: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 0DB6B126D74 for ; Wed, 10 Jan 2018 23:00:12 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 g_IiLLLdxZ4s for ; Wed, 10 Jan 2018 23:00:04 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476EF12EA58 for ; Wed, 10 Jan 2018 23:00:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0FA126BA; Thu, 11 Jan 2018 08:00:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id nBciBcmtzRbt; Thu, 11 Jan 2018 08:00:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 08:00:02 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3FB62013E; Thu, 11 Jan 2018 08:00:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lWDP-a2_pJiK; Thu, 11 Jan 2018 08:00:02 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EB822013C; Thu, 11 Jan 2018 08:00:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0F67420B1FB; Thu, 11 Jan 2018 08:00:01 +0100 (CET) Date: Thu, 11 Jan 2018 08:00:01 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" Message-ID: <20180111070001.aszydvhhfsrvmjii@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" References: <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:00:12 -0000 On Wed, Jan 10, 2018 at 08:16:13PM -0800, Mahesh Jethanandani wrote: > > > > On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) wrote: > > > > Mahesh, > > > > Two things: > > > > First, I see that you have still left in the “icmp-off” action. This was something both Kristian and I recommended removing, and I also discussed this with Sonal at the end of last year and she agreed that it should probably be removed since it seems at this point (absent anyone pointing out other implementations) to be a Cisco IOS-XR-specific feature that should probably be dealt with via a vendor augmentation initially. Can we remove this? > > You are right. It was discussed, but more to understand why we needed it. Before we remove it, let me clarify why we need it, and if after that the consensus is still to remove it, or move it to a Cisco specific augmentation, we can do it. > > The idea behind having the leaf is for routers to setup a rule to accept ICMP messages, allow the router to process the message, but suggest that a response may be suppressed. That way one can have rules to receive and process ICMP messages like “destination unreachable” or “fragmentation required” that are important for routers/hosts, but prevent rogue machines from discovering machines in a sweeping ping. > This sort of thing seems to be done in other implementations by having different rules for incoming and outgoing traffic; does the acl model support that? /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 Jan 10 23:13: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 ECAA512EA87; Wed, 10 Jan 2018 23:13:21 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 DKAQjXxmbBu8; Wed, 10 Jan 2018 23:13:19 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EA512EA81; Wed, 10 Jan 2018 23:13:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 52BAD6BA; Thu, 11 Jan 2018 08:13:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id afOOuiYaWu50; Thu, 11 Jan 2018 08:13:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 08:13:18 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DA842013D; Thu, 11 Jan 2018 08:13:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uqCsz57P7FsR; Thu, 11 Jan 2018 08:13:17 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 943F12013C; Thu, 11 Jan 2018 08:13:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7BF46420B309; Thu, 11 Jan 2018 08:13:17 +0100 (CET) Date: Thu, 11 Jan 2018 08:13:17 +0100 From: Juergen Schoenwaelder To: Adam Roach Cc: The IESG , netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org Message-ID: <20180111071317.wvqyyufx4bkyz5pi@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Adam Roach , The IESG , netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:13:22 -0000 On Wed, Jan 10, 2018 at 10:55:46PM -0800, Adam Roach wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have one correction and one question about the ietf-hardware YANG module. > > enum exa { > value 14; > description > "Data scaling factor of 10^15."; > } > enum peta { > value 15; > description > "Data scaling factor of 10^18."; > } > > I believe this is backwards -- "peta" should be 10^15, while "exa" should be 10^18. I agree this is wrong. This bug was most likely inherited from RFC 3433 but luckily there is a confirmed errata for RFC 3433. So Martin should fix this in the YANG module (and his copy of the MIB module). > typedef sensor-value-precision { > type int32 { > range "-8 .. 9"; > } > > Why is this an int32 rather than an int8? Likely because they way this was defined in the MIB module: SYNTAX Integer32 (-8..9) I assume using int8 would be fine as well. (Note that YANG update rules allow to expand the range restriction but they do not allow to replace int8 with int32; so the range resulting from the type is a hard limit, the range restriction is an expandable limit. I guess in this case using int8 would be safe but then this is a slight (but likely not important) departure from the MIB module.) /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 Jan 10 23:29:26 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 6FDB212EA87; Wed, 10 Jan 2018 23:29:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-netmod-rfc7277bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151565576445.10072.221877513960755879.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 23:29:24 -0800 Archived-At: Subject: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc7277bis-02: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:29:24 -0000 Adam Roach has entered the following ballot position for draft-ietf-netmod-rfc7277bis-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The MAC addresses in the examples are using an OUI of 00:01:02, which is assigned by IEEE to 3Com (and which presumably belongs to HP now). Please change the examples to make use of addresses from the unicast range documented in (e.g. 00:00:5E:00:53:AB). From nobody Wed Jan 10 23:50:43 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 064DC12025C; Wed, 10 Jan 2018 23:50:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151565703099.15530.3728806171831321340.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 23:50:30 -0800 Archived-At: Subject: [netmod] Adam Roach's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:50:31 -0000 Adam Roach has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The examples in Appendix C use IP addresses from RFC1918 ranges rather than addresses from those blocks reserved for documentation. At the same time, current IAB guidance calls for IPv6 examples in current standards-track documents. Consequently, I would suggest replacing "10.1.2.3" with "2001:DB8::BEEF:FACE" (or your favorite address from 2001:DB8::/32) everywhere. From nobody Wed Jan 10 23:52: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 D0FE012EA96; Wed, 10 Jan 2018 23:52:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 s1B5reEJREvM; Wed, 10 Jan 2018 23:52:22 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE0412EA6A; Wed, 10 Jan 2018 23:52:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 46AC1EC0; Thu, 11 Jan 2018 08:52:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id j1qLh2nV4QlN; Thu, 11 Jan 2018 08:52:20 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 08:52:21 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F7342013D; Thu, 11 Jan 2018 08:52:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Atz0YzXAZeqN; Thu, 11 Jan 2018 08:52:19 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DC512013C; Thu, 11 Jan 2018 08:52:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8BD4F420B3A8; Thu, 11 Jan 2018 08:52:18 +0100 (CET) Date: Thu, 11 Jan 2018 08:52:18 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180111075218.3tu65mthzlnef3bi@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:52:25 -0000 Kathleen, further thoughts inline... On Wed, Jan 10, 2018 at 10:12:02PM -0500, Kathleen Moriarty wrote: > Hi Juergen, > > Thanks for your quick response. Inline. > > On Wed, Jan 10, 2018 at 2:45 PM, Juergen Schoenwaelder > wrote: > > On Wed, Jan 10, 2018 at 11:21:13AM -0800, Kathleen Moriarty wrote: > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Hello, > >> > >> Thanks for your work on this draft. I'm a little confused with some text in > >> the draft and have a few questions. > >> > >> 1. The introductions says, > >> "This architectural framework identifies a set of conceptual datastores but > >> it does not mandate that all network management protocols expose all > >> these conceptual datastores. This architecture is agnostic with > >> regard to the encoding used by network management protocols." > >> > >> As such, the data stores could be exposed for some implementations, using > >> whatever network management protocol (likely NetCONF or RESTCONF). If this is > >> the case, why doesn't at least some of the security considerations template > >> apply for at least secure transport? > > > > The security considerations text is IMHO correct. The YANG modules defined > > in this document do not define any accessible objects. Hence, the security > > YANG template does not apply. > > Could you make that more clear in the document? The section from the > introduction quoted above says it is possible if network management > protocols expose the datastores. I am still not sure what you find missing. A datastore is a container for data. - The structure and semantics of the data contained in a datastore is defined using YANG modules. YANG modules have security considerations text that discusses the specifics of the data modeled in a YANG module. - The access to datastores is via management protocols such as NETCONF and RESTCONF. These protocols secure the data transport via SSH or TLS. In addition there is an access control system (NACM). Datastores have been with us since the beginning of NETCONF but they were kind of hardcoded and not extensible and not all data was contained in datastores. What this document does is essentially to introduce an architectural framework where all data is contained in datastores and the set of datastores becomes extensible. I assume the security template you have been referring to is the template we use for YANG modules, i.e., the definition of the concrete objects stored in a datastore. I do not see how this template relates to the introductory text. The template only applies to the YANG modules but as explained in the security considerations, these YANG modules do not define any objects. > >> 2. Section 5.3.4 - Is there any integrity protection on the origin information? > >> If not, can it be added or is there a good reason why it’s not possible? I > >> realize these are conceptual models that may or may not be exposed, but if > >> exposed and used, wouldn’t some integrity protection on this be helpful? > > > > Can you clarify what you mean with 'integrity protection' in this > > context and why you think origin attributes are special? The known > > published network management protocols all use standard security > > protocols (SSH and TLS). In general, security mechanisms are protocol > > specific, I do not see how the architectual definition of datastores > > requires discussion of special integrity mechanisms. Perhaps I do not > > understand your concern. > > > > What I'm wondering here and wanted to discuss was really how the > information on origin information will be used. Does this information > need to be from a source that can be validated? If so, should there > be some way to provide a MAC for the values for origin information in > the data stores? I am not referring to transport in this second > question. Your answer may be an explanation of how the origin > information will be used that excludes any need for integrity > protection. I just wasn't clear on how the information from the data > stores will be used from the draft. The origin tells a client where a value in the operational datastore is originating from. For example, if you see an IP address on an interface, you can determine from the origin whether the IP address was configured, learned say via DHCP or provided by the system (e.g. an auto-configured link-local IPv6 address). One obvious value is troubleshooting but this information can also help tools to determine in which way the actual applied config differs from intended config or what can be responsible for unexpected differences. The source of the information is the device itself. Can this information be validated? In general, not. Like pretty much anything else that is reported by the device. If the device or its NETCONF/RESTCONF server is lying at a client application, there is not much we can do about it in general. (For some information, it may be possible to cross check i.e. whether DHCP leases match up with learned IP addresses.) But note that we always had to trust information reported by devices, I do not see what the origin information is any different. (In fact, in some data models we had special purpose origin objects, in particular in forwarding table models.) There is no work as far as I know to introduce some form of cryptographic signatures for data exposed via NETCONF or RESTCONF. That all said, and coming back to the first issue, I do think we could actually say something about the origin annotation. RFC 7952 (which defined the syntax for metadata annotations) says in the Security Considerations: Security implications of a particular annotation defined using this mechanism MUST be duly considered and documented in the annotation's definition. So we should perhaps have text discussing the security implications of the origin annotation. I would have to think a bit more what exactly that text should say. /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 Jan 11 00:05: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 6021312D880 for ; Thu, 11 Jan 2018 00:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 3p7ppdq8xzC4 for ; Thu, 11 Jan 2018 00:05:18 -0800 (PST) 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 CB4CD124BFA for ; Thu, 11 Jan 2018 00:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2666; q=dns/txt; s=iport; t=1515657917; x=1516867517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KYf423ryfLPVQ7Td5Ef+DvcU3gdnx7z1sKgp8grDkek=; b=kwV6UYwhbwSvW9yACVG2haPnkYksOQLybWxIzCsSl2X8EHcOdZgpDG1R vftTQxTuU/d4+6211BTulXyMoD94EqsJ6AdTIubVelMgvX+jJHqGaXphq 0Dgkuj6w6jmpzozQw1Kl6xBUD4Ug4KmekqvFhFXaQkkSsbfKrwUqS/TaQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQDYGVda/4wNJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQWZ0J4QHiiSOXoIClzAUggIKH4UcAhqELj8YAQEBAQEBAQE?= =?us-ascii?q?BayiFIwEBAQECASMRRQUJAgIBCA4CCAICJgICAhkXFRACBA4FiisIsEWCJ4o9A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoMcghWDaYMFgy8EgVcYFwomglAxgjQ?= =?us-ascii?q?Fo2QClUWUDpZ3AhEZAYE7AR85gVBvFWcBgX8JhE54i2ABAQE?= X-IronPort-AV: E=Sophos;i="5.46,343,1511827200"; d="scan'208";a="55143057" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 08:05:17 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w0B85GSd025355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jan 2018 08:05:16 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 11 Jan 2018 03:05:15 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Thu, 11 Jan 2018 03:05:15 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpICAAshNAIABc5kAgAAzf4CAAXAVAIAjiDCAgABhzICAAUOSgIAALcSA//++aBQ= Date: Thu, 11 Jan 2018 08:05:15 +0000 Message-ID: <02CF0DC6-AC89-4BDF-9B0A-7B0C313D0A86@cisco.com> References: <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> , <20180111070001.aszydvhhfsrvmjii@elstar.local> In-Reply-To: <20180111070001.aszydvhhfsrvmjii@elstar.local> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 08:05:19 -0000 WWVzLCB0aGUgQUNMIG1vZGVsIHN1cHBvcnRzIGluZ3Jlc3MgYW5kIGVncmVzcyBydWxlcyB0aGF0 IGNhbiBiZSBkaWZmZXJlbnQuDQoNCg0KPiBPbiBKYW4gMTEsIDIwMTgsIGF0IDA3OjAwLCBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4g d3JvdGU6DQo+IA0KPj4gT24gV2VkLCBKYW4gMTAsIDIwMTggYXQgMDg6MTY6MTNQTSAtMDgwMCwg TWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToNCj4+IA0KPj4gDQo+Pj4gT24gSmFuIDEwLCAyMDE4 LCBhdCAxMjo1OCBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNp c2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gTWFoZXNoLA0KPj4+IA0KPj4+IFR3byB0aGluZ3M6 DQo+Pj4gDQo+Pj4gRmlyc3QsIEkgc2VlIHRoYXQgeW91IGhhdmUgc3RpbGwgbGVmdCBpbiB0aGUg 4oCcaWNtcC1vZmbigJ0gYWN0aW9uLiBUaGlzIHdhcyBzb21ldGhpbmcgYm90aCBLcmlzdGlhbiBh bmQgSSByZWNvbW1lbmRlZCByZW1vdmluZywgYW5kIEkgYWxzbyBkaXNjdXNzZWQgdGhpcyB3aXRo IFNvbmFsIGF0IHRoZSBlbmQgb2YgbGFzdCB5ZWFyIGFuZCBzaGUgYWdyZWVkIHRoYXQgaXQgc2hv dWxkIHByb2JhYmx5IGJlIHJlbW92ZWQgc2luY2UgaXQgc2VlbXMgYXQgdGhpcyBwb2ludCAoYWJz ZW50IGFueW9uZSBwb2ludGluZyBvdXQgb3RoZXIgaW1wbGVtZW50YXRpb25zKSB0byBiZSBhIENp c2NvIElPUy1YUi1zcGVjaWZpYyBmZWF0dXJlIHRoYXQgc2hvdWxkIHByb2JhYmx5IGJlIGRlYWx0 IHdpdGggdmlhIGEgdmVuZG9yIGF1Z21lbnRhdGlvbiBpbml0aWFsbHkuIENhbiB3ZSByZW1vdmUg dGhpcz8NCj4+IA0KPj4gWW91IGFyZSByaWdodC4gSXQgd2FzIGRpc2N1c3NlZCwgYnV0IG1vcmUg dG8gdW5kZXJzdGFuZCB3aHkgd2UgbmVlZGVkIGl0LiBCZWZvcmUgd2UgcmVtb3ZlIGl0LCBsZXQg bWUgY2xhcmlmeSB3aHkgd2UgbmVlZCBpdCwgYW5kIGlmIGFmdGVyIHRoYXQgdGhlIGNvbnNlbnN1 cyBpcyBzdGlsbCB0byByZW1vdmUgaXQsIG9yIG1vdmUgaXQgdG8gYSBDaXNjbyBzcGVjaWZpYyBh dWdtZW50YXRpb24sIHdlIGNhbiBkbyBpdC4NCj4+IA0KPj4gVGhlIGlkZWEgYmVoaW5kIGhhdmlu ZyB0aGUgbGVhZiBpcyBmb3Igcm91dGVycyB0byBzZXR1cCBhIHJ1bGUgdG8gYWNjZXB0IElDTVAg bWVzc2FnZXMsIGFsbG93IHRoZSByb3V0ZXIgdG8gcHJvY2VzcyB0aGUgbWVzc2FnZSwgYnV0IHN1 Z2dlc3QgdGhhdCBhIHJlc3BvbnNlIG1heSBiZSBzdXBwcmVzc2VkLiBUaGF0IHdheSBvbmUgY2Fu IGhhdmUgcnVsZXMgdG8gcmVjZWl2ZSBhbmQgcHJvY2VzcyBJQ01QIG1lc3NhZ2VzIGxpa2Ug4oCc ZGVzdGluYXRpb24gdW5yZWFjaGFibGXigJ0gb3Ig4oCcZnJhZ21lbnRhdGlvbiByZXF1aXJlZOKA nSB0aGF0IGFyZSBpbXBvcnRhbnQgZm9yIHJvdXRlcnMvaG9zdHMsIGJ1dCBwcmV2ZW50IHJvZ3Vl IG1hY2hpbmVzIGZyb20gZGlzY292ZXJpbmcgbWFjaGluZXMgaW4gYSBzd2VlcGluZyBwaW5nLiAN Cj4+IA0KPiANCj4gVGhpcyBzb3J0IG9mIHRoaW5nIHNlZW1zIHRvIGJlIGRvbmUgaW4gb3RoZXIg aW1wbGVtZW50YXRpb25zIGJ5IGhhdmluZw0KPiBkaWZmZXJlbnQgcnVsZXMgZm9yIGluY29taW5n IGFuZCBvdXRnb2luZyB0cmFmZmljOyBkb2VzIHRoZSBhY2wgbW9kZWwNCj4gc3VwcG9ydCB0aGF0 Pw0KPiANCj4gL2pzDQo+IA0KPiAtLSANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAg ICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLz4NCg== From nobody Thu Jan 11 00:20: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 CC68E12EAAA; Thu, 11 Jan 2018 00:20:11 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 TZZurnA6mPzX; Thu, 11 Jan 2018 00:20:10 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52C812EA9F; Thu, 11 Jan 2018 00:20:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ABB2F6AC; Thu, 11 Jan 2018 09:20:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id cQ2sYpBl0FLI; Thu, 11 Jan 2018 09:20:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 09:20:08 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7531D2013C; Thu, 11 Jan 2018 09:20:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id csP89T-LTlL0; Thu, 11 Jan 2018 09:20:08 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E19202013D; Thu, 11 Jan 2018 09:20:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45361420B542; Thu, 11 Jan 2018 09:20:07 +0100 (CET) Date: Thu, 11 Jan 2018 09:20:07 +0100 From: Juergen Schoenwaelder To: Adam Roach Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180111082007.cs2w2kmhypszq7ko@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Adam Roach , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151565703099.15530.3728806171831321340.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151565703099.15530.3728806171831321340.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 08:20:12 -0000 On Wed, Jan 10, 2018 at 11:50:30PM -0800, Adam Roach wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The examples in Appendix C use IP addresses from RFC1918 ranges rather than > addresses from those blocks reserved for documentation. At the same time, > current IAB guidance > calls for IPv6 examples in current standards-track documents. Consequently, I > would suggest replacing "10.1.2.3" with "2001:DB8::BEEF:FACE" (or your favorite > address from 2001:DB8::/32) everywhere. > I will replaced 10.1.2.3 with 2001:db8::2:3. /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 Jan 11 00:26:00 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 9C5A112D77C for ; Thu, 11 Jan 2018 00:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 R8WIrx8LzX9B for ; Thu, 11 Jan 2018 00:25:55 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF28126C23 for ; Thu, 11 Jan 2018 00:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=98257; q=dns/txt; s=iport; t=1515659154; x=1516868754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oU/NfaSXC2lvwv4sPDyODYwGVMTkZei0aHsvOX3iAwA=; b=LuuPIupil+sUugkHxbzcL9ibgq2umOHmuf1D8OBkSVQimxNWqnZMRaVT 1FS5KMZeVc56wErHChB4Doc/ciSzxSqureL1KbTnmy0wWi75Knh04To1P +JYluzmP5haMYjz/WTn+AQFzLODkNgatY6qfLmcLFRuDnk8fuhd+LTHKQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQAhH1da/4UNJK1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDETBmdCeEB4okjl6LDY4lFIF/AwoYAQqBOQGDD08CGoQuPxg?= =?us-ascii?q?BAQEBAQEBAQFrKIUkAgEDAQEYCQRHCxACAQgOKgEGAwICAh8GCxQRAgQOBYlPT?= =?us-ascii?q?AMVELA8gW06JocaDYJwAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEK4IVgz8BKYM?= =?us-ascii?q?FgmtEAQECAYFEEi8fgmExgjQFkieHS4k1PQKICYg7hQGCGIYci1qNPUCIegIRG?= =?us-ascii?q?QGBOwEfOYFQbxU9KgGBf4IbORyBZ3iLYAEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,343,1511827200"; d="scan'208,217"; a="54609164" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 08:25:53 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0B8PqKo020549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jan 2018 08:25:53 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 11 Jan 2018 03:25:52 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Thu, 11 Jan 2018 03:25:51 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani CC: "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpICAAshNAIABc5kAgAAzf4CAAXAVAIAjiDCAgABhzICAAUOSgP//8e7S Date: Thu, 11 Jan 2018 08:25:51 +0000 Message-ID: <3F9E5A58-C450-4EE0-AB19-D693A3F9B6EC@cisco.com> References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_3F9E5A58C4504EE0AB19D693A3F9B6ECciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 08:25:59 -0000 --_000_3F9E5A58C4504EE0AB19D693A3F9B6ECciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEphbiAxMSwgMjAxOCwgYXQgMDQ6MTYsIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRo YW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQoNCg0KT24gSmFuIDEwLCAyMDE4LCBhdCAxMjo1OCBBTSwgRWluYXIgTmlsc2VuLU55Z2Fh cmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+ PiB3cm90ZToNCg0KTWFoZXNoLA0KDQpUd28gdGhpbmdzOg0KDQpGaXJzdCwgSSBzZWUgdGhhdCB5 b3UgaGF2ZSBzdGlsbCBsZWZ0IGluIHRoZSDigJxpY21wLW9mZuKAnSBhY3Rpb24uIFRoaXMgd2Fz IHNvbWV0aGluZyBib3RoIEtyaXN0aWFuIGFuZCBJIHJlY29tbWVuZGVkIHJlbW92aW5nLCBhbmQg SSBhbHNvIGRpc2N1c3NlZCB0aGlzIHdpdGggU29uYWwgYXQgdGhlIGVuZCBvZiBsYXN0IHllYXIg YW5kIHNoZSBhZ3JlZWQgdGhhdCBpdCBzaG91bGQgcHJvYmFibHkgYmUgcmVtb3ZlZCBzaW5jZSBp dCBzZWVtcyBhdCB0aGlzIHBvaW50IChhYnNlbnQgYW55b25lIHBvaW50aW5nIG91dCBvdGhlciBp bXBsZW1lbnRhdGlvbnMpIHRvIGJlIGEgQ2lzY28gSU9TLVhSLXNwZWNpZmljIGZlYXR1cmUgdGhh dCBzaG91bGQgcHJvYmFibHkgYmUgZGVhbHQgd2l0aCB2aWEgYSB2ZW5kb3IgYXVnbWVudGF0aW9u IGluaXRpYWxseS4gQ2FuIHdlIHJlbW92ZSB0aGlzPw0KDQpZb3UgYXJlIHJpZ2h0LiBJdCB3YXMg ZGlzY3Vzc2VkLCBidXQgbW9yZSB0byB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkZWQgaXQuIEJlZm9y ZSB3ZSByZW1vdmUgaXQsIGxldCBtZSBjbGFyaWZ5IHdoeSB3ZSBuZWVkIGl0LCBhbmQgaWYgYWZ0 ZXIgdGhhdCB0aGUgY29uc2Vuc3VzIGlzIHN0aWxsIHRvIHJlbW92ZSBpdCwgb3IgbW92ZSBpdCB0 byBhIENpc2NvIHNwZWNpZmljIGF1Z21lbnRhdGlvbiwgd2UgY2FuIGRvIGl0Lg0KDQpUaGUgaWRl YSBiZWhpbmQgaGF2aW5nIHRoZSBsZWFmIGlzIGZvciByb3V0ZXJzIHRvIHNldHVwIGEgcnVsZSB0 byBhY2NlcHQgSUNNUCBtZXNzYWdlcywgYWxsb3cgdGhlIHJvdXRlciB0byBwcm9jZXNzIHRoZSBt ZXNzYWdlLCBidXQgc3VnZ2VzdCB0aGF0IGEgcmVzcG9uc2UgbWF5IGJlIHN1cHByZXNzZWQuIFRo YXQgd2F5IG9uZSBjYW4gaGF2ZSBydWxlcyB0byByZWNlaXZlIGFuZCBwcm9jZXNzIElDTVAgbWVz c2FnZXMgbGlrZSDigJxkZXN0aW5hdGlvbiB1bnJlYWNoYWJsZeKAnSBvciDigJxmcmFnbWVudGF0 aW9uIHJlcXVpcmVk4oCdIHRoYXQgYXJlIGltcG9ydGFudCBmb3Igcm91dGVycy9ob3N0cywgYnV0 IHByZXZlbnQgcm9ndWUgbWFjaGluZXMgZnJvbSBkaXNjb3ZlcmluZyBtYWNoaW5lcyBpbiBhIHN3 ZWVwaW5nIHBpbmcuDQoNCg0KU2Vjb25kLCBJIHdvdWxkIHJlYWxseSBsaWtlIHRoZSBjb250cmli dXRvcnMgd2hvIHdpc2ggdG8gbWFpbnRhaW4gdGhlIHNlcGFyYXRlIEFDTCBhdHRhY2htZW50IGlu dGVyZmFjZSBsaXN0IHdpdGggaW50ZXJmYWNlIHJlZmVyZW5jZXMgdG8gbGF5IG91dCBob3cgZGly ZWN0IGludGVyZmFjZSBhdHRhY2htZW50IHByZXZlbnRzIEFDTHMgYmVpbmcgdXNlZCB3aXRoIG90 aGVyIGF0dGFjaG1lbnQgcG9pbnRzLiBBcyBJIHBvaW50ZWQgb3V0LCBkaXJlY3QgaW50ZXJmYWNl IGF0dGFjaG1lbnQgZG9lcyBub3QgcmVtb3ZlIGFueSBmbGV4aWJpbGl0eSBhdCBhbGwgZm9yIG90 aGVyIGZ1dHVyZSBhdHRhY2htZW50IHBvaW50cy4gV2hpbGUgSeKAmW0gbm90IGludHJpbnNpY2Fs bHkgb3Bwb3NlZCB0byBhIHNlcGFyYXRlIGxpc3Qgd2l0aCBpbnRlcmZhY2UgcmVmcywgSSBqdXN0 IHdhbnQgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGFzIHRoZSBtYWpvcml0eSBvZiBzd2l0 Y2hlcyBhbmQgcm91dGVycywgYXMgZmFyIGFzIEkgYW0gYXdhcmUsIHR5cGljYWxseSBhdHRhY2gg QUNMcyBkaXJlY3RseSB0byBpbnRlcmZhY2VzLCBtZWFuaW5nIHRoYXQgdGhlIHBhdHRlcm4gaXMg d2VsbC11bmRlcnN0b29kIGJ5IHR5cGljYWwgdXNlcnMgb2YgdGhpcyBtb2RlbC4NCg0KSSB0aGlu ayB0aGUgZmlyc3QgaXNzdWUgaW4gc2V0dGluZyB1cCBhbHRlcm5hdGUgYXR0YWNobWVudCBwb2lu dCBpcywgaG93IHdvdWxkIHlvdSBkbyBzZXR1cCB0aGUgYWx0ZXJuYXRlIGF0dGFjaG1lbnQgcG9p bnQgYXMgYSBjaG9pY2UgYmV0d2VlbiBpdCBhbmQgYXR0YWNoaW5nIGl0IHRvIGFuIGludGVyZmFj ZSB1bmRlciBhbiBhdWdtZW50YXRpb24uDQoNCldoeSBkb2VzIGl0IG5lZWQgdG8gYmUgYSBjaG9p Y2UgYmV0d2VlbiB0aGUgdHdvIGF0dGFjaG1lbnQgcG9pbnRzPyBBbiBBQ0wgY2FuIGJlIGF0dGFj aGVkIHRvIG9uZSBvciBib3RoIG9mIGludGVyZmFjZXMgYW5kIG90aGVyIGF0dGFjaG1lbnQgcG9p bnRzLiBUaGVyZSBpcyBubyBuZWVkIGZvciBhIGNob2ljZS4NCg0KU2Vjb25kbHksIGlmIHRoZSBB Q0xzIGFyZSB1c2VkIHdpdGggbXVsdGlwbGUgTkksIGVhY2ggb2YgdGhlbSByZWZlcnJpbmcgdG8g dGhlIGdsb2JhbCBzZXQgb2YgaWV0Zi1pbnRlcmZhY2VzIHNoYXJlZCBieSBhbGwgdGhlIGluc3Rh bmNlcywgd2hpY2ggdGhlIHNjaGVtYSBtb3VudCBkcmFmdCBvdXRsaW5lcyBoZXJlPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQtMDYjc2Vj dGlvbi00PiwgaXQgaW1wbGllcyB0aGF0IHlvdSB3aWxsIG5lZWQgYSByZWZlcmVuY2UgdG8gdGhl IGludGVyZmFjZXMuDQoNClNvcnJ5LCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgcHJv YmxlbSBpcyBoZXJlPyBBcmUgeW91IGNvbmNlcm5lZCBhYm91dCB0aGUgQUNMIG1vZGVsIGJlaW5n IG1vdW50ZWQgdW5kZXIgYSBtb3VudCBwb2ludCwgYW5kIG5lZWRpbmcgdG8gdXNlIHRob3NlIEFD THMgb24gZ2xvYmFsbHkgZGVmaW5lZCBpbnRlcmZhY2VzPyBPciBhcmUgeW91IGNvbmNlcm5lZCBh Ym91dCB0aGUgaW50ZXJmYWNlIG1vZGVsIGJlaW5nIG1vdW50ZWQgdW5kZXIgYSBtb3VudCBwb2lu dCBhbmQgaG93IGdsb2JhbCBBQ0xzIHdvdWxkIGJlIHJlZmVyZW5jZWQ/DQoNCkNoZWVycywNCg0K RWluYXINCg0KDQpUaGFua3MuDQoNCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCk9uIDEwIEphbiAy MDE4LCBhdCAwMzowOCwgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5j b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgaGF2ZSBwdWxs ZWQgaW4gdGhlIGNoYW5nZXMgYXMgdGhleSByZWxhdGUgdG86DQoNCi0gbW92aW5nIOKAnGludGVy ZmFjZS1hY2zigJ0gdW5kZXIgdGhlIGNvbnRhaW5lciDigJxhdHRhY2htZW50LXBvaW50c+KAnSBt YWtpbmcgaXQgbG9jYWwgdG8gdGhhdCBjb250YWluZXIuDQotIHJldmVydGluZyDigJxhY2wtdHlw ZeKAnSB0byDigJx0eXBl4oCdDQotIHJlbW92ZWQg4oCcaW50ZXJmYWNlLWFsbC1hZ2dyZWdhdGXi gJ0gZmVhdHVyZQ0KLSBzaW1wbGlmaWVkIHNvdXJjZSBwb3J0IGFuZCBkZXN0aW5hdGlvbiBwb3J0 IGRlZmluaXRpb24NCg0KVGhlIHB1bGwgcmVxdWVzdCBmb3IgdGhlIGNoYW5nZXMgY2FuIGJlIGZv dW5kIGhlcmUuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwv MjANCg0KQWZ0ZXIgZGlzY3Vzc2luZyB3aXRoIHNvbWUgb2YgdGhlIG9yaWdpbmFsIGNvbnRyaWJ1 dG9ycywgZGVjaWRlZCBub3QgdG8gaW5jbHVkZSB0aGUgY2hhbmdlIGFzIGl0IHJlbGF0ZXMgdG8g YXVnbWVudGluZyBpZXRmLWludGVyZmFjZXMuIFdlIGRpZCBub3QgZmluZCB0aGF0IHRoZSBjaGFu Z2UgaGFkIGEgcGFydGljdWxhciBhZHZhbnRhZ2Ugb3ZlciB0aGUgY3VycmVudCBpbXBsZW1lbnRh dGlvbi4gRXZlbiBpZiB3ZSBkbyBub3QgY29tcGxldGVseSB1bmRlcnN0YW5kIGhvdyBBQ0xzIG1p Z2h0IGJlIGF0dGFjaGVkIOKAnGdsb2JhbGx54oCdIG9yIG9uIHNvbWV0aGluZyB0aGF0IGlzIG5v dCBhbiBpbnRlcmZhY2UsIGhhdmluZyB0aGUgZmxleGliaWxpdHkgdG8gYXR0YWNoIHRoZW0gdG8g b3RoZXIgYXR0YWNobWVudCBwb2ludHMgaXMgaW1wb3J0YW50LiBLZWVwaW5nIGl0IGFzIGludGVy ZmFjZS1yZWYgZ2l2ZXMgdXMgdGhhdCBmbGV4aWJpbGl0eS4NCg0KQ2hlZXJzLg0KDQpPbiBEZWMg MTgsIDIwMTcsIGF0IDQ6MzEgQU0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzps ZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNClNvIGxvbmcgYXMgbm9ib2R5IGV4cGVjdHMgYW4g aW50ZXJmYWNlIGNvbnN0cnVjdCBpbiBhIE1VRCBmaWxlLCBJJ20gaGFwcHkuDQoNCk9uIDE3LjEy LjE3IDE1OjM0LCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6DQpFbGlvdCwN Cg0KTm90aGluZyBjYW4gZm9yY2UgYW4gaW1wbGVtZW50YXRpb24gdG8gaGF2ZSB0byBpbXBsZW1l bnQgZWl0aGVyIHRoZSBpZXRmLWludGVyZmFjZXMgbW9kZWwgb3IgdGhlIGF1Z21lbnRhdGlvbiBp biB0aGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1vZGVsLiBJIGFwcHJlY2lhdGUgeW91ciBk ZXNpcmUgZm9yIG1vZHVsYXJpdHkgYW5kIGNvaGVzaXZlbmVzcywgYnV0IEkgd291bGQgcmVzaXN0 ICMxLCBiZWNhdXNlIEkgZmVlbCB0aGF0IHRoZSBtYWpvcml0eSBvZiB1c2VycyB3aWxsIGJlIHRh cmdldGluZyBpbnRlcmZhY2UtYmFzZWQgYXR0YWNobWVudCBvdmVyIHRpbWUuIEnigJl2ZSBhZGRl IGJhY2sgaW4gdXNlIG9mIHRoZSDigJxpbnRlcmZhY2UtYXR0YWNobWVudOKAnSBmZWF0dXJlICh3 aGljaCBJIHRvb2sgb3V0IGFzIHBhcnQgb2YgcmVmYWN0b3JpbmcgaW50ZXJmYWNlIGF0dGFjaG1l bnQpLiBQYXJ0IG9mOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9w dWxsLzIxDQoNClRoZSBhdWdtZW50cyBwYXJ0IG9mIHRoZSB0cmVlIG5vdyBsb29rcyBsaWtlOg0K DQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KICAgICstLXJ3IGFjbHMg e2ludGVyZmFjZS1hdHRhY2htZW50fT8NCiAgICAgICArLS1ydyBpbmdyZXNzDQogICAgICAgfCAg Ky0tcncgYWNsLXNldHMNCiAgICAgICB8ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICAg ICB8ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9u YW1lDQogICAgICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICAgLT4gL2FjY2Vzcy1s aXN0cy9hY2wvdHlwZQ0KICAgICAgIHwgICAgICAgICstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFt ZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgICAgfCAgICAgICAgICAgKy0tcm8gbmFtZSAgICAg ICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICB8ICAg ICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICB8 ICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAgICAg ICArLS1ydyBlZ3Jlc3MNCiAgICAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICAgICst LXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAg ICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICAgICArLS1ydyB0eXBl PyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgICAg Ky0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAg ICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wv YWNlcy9hY2UvbmFtZQ0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8g ICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRz PyAgICB5YW5nOmNvdW50ZXI2NA0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gMTcgRGVjIDIw MTcsIGF0IDExOjI5LCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNj by5jb20+PiB3cm90ZToNCg0KDQpFaW5hciwNCg0KSSB0aGluayB0aGlzIGNoYW5nZSBpcyBmaW5l LCB3aXRoIG9uZSBleGNlcHRpb24uICBJIHdvdWxkIHJhdGhlciB0aGUgYXVnbWVudCB0byB0aGUg aW50ZXJmYWNlIG5vdCBiZSByZXF1aXJlZCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qg YWN0dWFsbHkgaGF2ZSBpbnRlcmZhY2VzLiAgSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgbWF5IGJl IHR3byB3YXlzIHRvIGdvIGFib3V0IHRoaXM6DQoNCiAgMS4gIFNlcGFyYXRlIG91dCB0aGUgYXVn bWVudCBpbnRvIGEgc2VwYXJhdGUgbW9kdWxlIChzYW1lIGRvYyBpcyBmaW5lKTsgb3INCiAgMi4g IFNvbWVob3cgImZlYXR1cmUtaXplIiB0aGUgYXVnbWVudC4NCg0KSSBkb24ndCBrbm93IGhvdyB0 byBkbyAoMikgYnV0IGlmIHlvdSBkbywgdGhhdCdzIG9rYXkgYnkgbWUuDQoNCkVsaW90DQoNCk9u IDE2LjEyLjE3IDE0OjE5LCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6DQpB bGwsDQoNCkFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25zIG9uLSBhbmQgb2ZmLWxpc3QsIEkg aGF2ZSBhIGNhbmRpZGF0ZSBQUiB0aGF0IGluY2x1ZGVzIHRoZSBjaGFuZ2VzIGluIHRoZSBQUiBN YWhlc2ggc2VudCBvdXQgcGx1cyBzb21lIG1vcmUgZWRpdHMuIFBsZWFzZSBzZWUgY29uc29saWRh dGVkIFBSIGhlcmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1 bGwvMjENCg0KTWFpbiBjaGFuZ2VzIGluIGFkZGl0aW9uIHRvIE1haGVzaOKAmXMgUFIgYXJlOg0K DQoNCiAgKiAgIE1vdmVkIGludGVyZmFjZSBhdHRhY2htZW50IHRvIGJlIHZpYSBhbiBpbnRlcmZh Y2UgYXVnbWVudGF0aW9uLg0KICAqICAgUmVzdHJ1Y3R1cmVkIHBvcnQgbWF0Y2hlcyBzbGlnaHRs eSB1bmRlciBib3RoIElQdjQgYW5kIElQdjYgY29udGFpbmVycy4NCiAgKiAgIFJlbW92ZWQgdW5u ZWNlc3NhcnkgaWRlbnRpdHkgJ2ludGVyZmFjZS1hY2wtYWdncmVnYXRl4oCZLg0KICAqICAgUmVt b3ZlZCBhY3Rpb24g4oCYaWNtcC1vZmbigJksIGNhbiBiZSBhdWdtZW50ZWQgbGF0ZXIuDQoNCkZv ciByZWZlcmVuY2UsIGhlcmUgaXMgdGhlIGN1cnJlbnQgWUFORyB0cmVlIHBsdXMg4oCcLS1pZXRm 4oCdIGxvZ3M6DQoNCjEzOjEyICQgcHlhbmcgLS1pZXRmIC0tbGludCAtZiB0cmVlIGlldGYtYWNj ZXNzLWNvbnRyb2wtbGlzdC55YW5nDQppZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzo1MTog ZXJyb3I6IGJhZCB2YWx1ZSAiWVlZWS1NTS1ERCIgKHNob3VsZCBiZSBkYXRlKQ0KbW9kdWxlOiBp ZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QNCiAgICArLS1ydyBhY2Nlc3MtbGlzdHMNCiAgICAgICAr LS1ydyBhY2wqIFtuYW1lXQ0KICAgICAgICAgICstLXJ3IG5hbWUgICAgc3RyaW5nDQogICAgICAg ICAgKy0tcncgdHlwZT8gICBhY2wtdHlwZQ0KICAgICAgICAgICstLXJ3IGFjZXMNCiAgICAgICAg ICAgICArLS1ydyBhY2UqIFtuYW1lXQ0KICAgICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAg ICAgc3RyaW5nDQogICAgICAgICAgICAgICAgKy0tcncgbWF0Y2hlcw0KICAgICAgICAgICAgICAg IHwgICstLXJ3IChsMik/DQogICAgICAgICAgICAgICAgfCAgfCAgKy0tOihldGgpDQogICAgICAg ICAgICAgICAgfCAgfCAgICAgKy0tcncgZXRoIHttYXRjaC1vbi1ldGh9Pw0KICAgICAgICAgICAg ICAgIHwgIHwgICAgICAgICstLXJ3IGRlc3RpbmF0aW9uLW1hYy1hZGRyZXNzPyAgICAgICAgeWFu ZzptYWMtYWRkcmVzcw0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IGRlc3RpbmF0 aW9uLW1hYy1hZGRyZXNzLW1hc2s/ICAgeWFuZzptYWMtYWRkcmVzcw0KICAgICAgICAgICAgICAg IHwgIHwgICAgICAgICstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcz8gICAgICAgICAgICAgeWFuZzpt YWMtYWRkcmVzcw0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IHNvdXJjZS1tYWMt YWRkcmVzcy1tYXNrPyAgICAgICAgeWFuZzptYWMtYWRkcmVzcw0KICAgICAgICAgICAgICAgIHwg IHwgICAgICAgICstLXJ3IGV0aGVydHlwZT8gICAgICAgICAgICAgICAgICAgICAgZXRoOmV0aGVy dHlwZQ0KICAgICAgICAgICAgICAgIHwgICstLXJ3IChsMyk/DQogICAgICAgICAgICAgICAgfCAg fCAgKy0tOihpcHY0KQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGlwdjQge21hdGNo LW9uLWlwdjR9Pw0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGRzY3A/ICAgICAg ICAgICAgICAgICAgICAgICBpbmV0OmRzY3ANCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICAr LS1ydyBlY24/ICAgICAgICAgICAgICAgICAgICAgICAgdWludDgNCiAgICAgICAgICAgICAgICB8 ICB8ICB8ICAgICArLS1ydyBsZW5ndGg/ICAgICAgICAgICAgICAgICAgICAgdWludDE2DQogICAg ICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgdHRsPyAgICAgICAgICAgICAgICAgICAgICAg IHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgcHJvdG9jb2w/ICAgICAg ICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgKHNv dXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAg ICB8ICArLS06KHJhbmdlKQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3 IHNvdXJjZS1wb3J0LWxvd2VyICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAg ICAgICAgfCAgfCAgfCAgICAgfCAgfCAgKy0tcncgc291cmNlLXBvcnQtdXBwZXIgICAgICAgICAg IGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS06KG9w ZXJhdG9yKQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLXJ3IHNvdXJjZS1v cGVyYXRvciAgICAgICAgICAgICBvcGVyYXRvcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAg IHwgICAgICstLXJ3IHNvdXJjZS1wb3J0ICAgICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVy DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgKGRlc3RpbmF0aW9uLXBvcnQtcmFu Z2Utb3Itb3BlcmF0b3IpPw0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICstLToocmFu Z2UpDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAgfCAgKy0tcncgZGVzdGluYXRpb24t cG9ydC1sb3dlciAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8 ICAgICB8ICB8ICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LXVwcGVyICAgICAgaW5ldDpwb3J0LW51 bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICstLToob3BlcmF0b3IpDQogICAg ICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgKy0tcncgZGVzdGluYXRpb24tb3BlcmF0b3Ig ICAgICAgIG9wZXJhdG9yDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgKy0tcncg ZGVzdGluYXRpb24tcG9ydCAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAg ICAgICB8ICB8ICB8ICAgICArLS1ydyBpaGw/ICAgICAgICAgICAgICAgICAgICAgICAgdWludDgN CiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBmbGFncz8gICAgICAgICAgICAgICAg ICAgICAgYml0cw0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IG9mZnNldD8gICAg ICAgICAgICAgICAgICAgICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1y dyBpZGVudGlmaWNhdGlvbj8gICAgICAgICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAg fCAgfCAgICAgKy0tcncgZGVzdGluYXRpb24taXB2NC1uZXR3b3JrPyAgIGluZXQ6aXB2NC1wcmVm aXgNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBzb3VyY2UtaXB2NC1uZXR3b3Jr PyAgICAgICAgaW5ldDppcHY0LXByZWZpeA0KICAgICAgICAgICAgICAgIHwgIHwgICstLTooaXB2 NikNCiAgICAgICAgICAgICAgICB8ICB8ICAgICArLS1ydyBpcHY2IHttYXRjaC1vbi1pcHY2fT8N CiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBkc2NwPyAgICAgICAgICAgICAgICAg ICAgICAgaW5ldDpkc2NwDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZWNuPyAg ICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAg Ky0tcncgbGVuZ3RoPyAgICAgICAgICAgICAgICAgICAgIHVpbnQxNg0KICAgICAgICAgICAgICAg IHwgIHwgICAgICAgICstLXJ3IHR0bD8gICAgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAg ICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IHByb3RvY29sPyAgICAgICAgICAgICAgICAg ICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IChzb3VyY2UtcG9ydC1y YW5nZS1vci1vcGVyYXRvcik/DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihy YW5nZSkNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICB8ICArLS1ydyBzb3VyY2UtcG9y dC1sb3dlciAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwg ICAgICAgIHwgIHwgICstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyICAgICAgICAgICBpbmV0OnBvcnQt bnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihvcGVyYXRvcikNCiAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgICArLS1ydyBzb3VyY2Utb3BlcmF0b3IgICAg ICAgICAgICAgb3BlcmF0b3INCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgICArLS1y dyBzb3VyY2UtcG9ydCAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAg ICAgICAgIHwgIHwgICAgICAgICstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJh dG9yKT8NCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICArLS06KHJhbmdlKQ0KICAgICAg ICAgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIg ICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgfCAg Ky0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAg ICAgICAgICAgICB8ICB8ICAgICAgICB8ICArLS06KG9wZXJhdG9yKQ0KICAgICAgICAgICAgICAg IHwgIHwgICAgICAgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJhdG9yICAgICAgICBvcGVy YXRvcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9u LXBvcnQgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAg ICAgICAgKy0tcncgZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrPyAgIGluZXQ6aXB2Ni1wcmVmaXgN CiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBzb3VyY2UtaXB2Ni1uZXR3b3JrPyAg ICAgICAgaW5ldDppcHY2LXByZWZpeA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3 IGZsb3ctbGFiZWw/ICAgICAgICAgICAgICAgICBpbmV0OmlwdjYtZmxvdy1sYWJlbA0KICAgICAg ICAgICAgICAgIHwgICstLXJ3IChsNCk/DQogICAgICAgICAgICAgICAgfCAgfCAgKy0tOih0Y3Ap DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgdGNwIHttYXRjaC1vbi10Y3B9Pw0KICAg ICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHNlcXVlbmNlLW51bWJlcj8gICAgICAgICAg dWludDMyDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgYWNrbm93bGVkZ2VtZW50 LW51bWJlcj8gICB1aW50MzINCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBkYXRh LW9mZnNldD8gICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAg Ky0tcncgcmVzZXJ2ZWQ/ICAgICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwg IHwgIHwgICAgICstLXJ3IGZsYWdzPyAgICAgICAgICAgICAgICAgICAgYml0cw0KICAgICAgICAg ICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHdpbmRvdy1zaXplPyAgICAgICAgICAgICAgdWludDE2 DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgdXJnZW50LXBvaW50ZXI/ICAgICAg ICAgICB1aW50MTYNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBvcHRpb25zPyAg ICAgICAgICAgICAgICAgIHVpbnQzMg0KICAgICAgICAgICAgICAgIHwgIHwgICstLToodWRwKQ0K ICAgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IHVkcCB7bWF0Y2gtb24tdWRwfT8NCiAgICAg ICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBsZW5ndGg/ICAgdWludDE2DQogICAgICAgICAg ICAgICAgfCAgfCAgKy0tOihpY21wKQ0KICAgICAgICAgICAgICAgIHwgIHwgICAgICstLXJ3IGlj bXAge21hdGNoLW9uLWljbXB9Pw0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IHR5 cGU/ICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncg Y29kZT8gICAgICAgICAgICAgdWludDgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1y dyByZXN0LW9mLWhlYWRlcj8gICB1aW50MzINCiAgICAgICAgICAgICAgICB8ICArLS1ydyBlZ3Jl c3MtaW50ZXJmYWNlPyAgICBpZjppbnRlcmZhY2UtcmVmDQogICAgICAgICAgICAgICAgfCAgKy0t cncgaW5ncmVzcy1pbnRlcmZhY2U/ICAgaWY6aW50ZXJmYWNlLXJlZg0KICAgICAgICAgICAgICAg ICstLXJ3IGFjdGlvbnMNCiAgICAgICAgICAgICAgICB8ICArLS1ydyBmb3J3YXJkaW5nICAgIGlk ZW50aXR5cmVmDQogICAgICAgICAgICAgICAgfCAgKy0tcncgbG9nZ2luZz8gICAgICBpZGVudGl0 eXJlZg0KICAgICAgICAgICAgICAgICstLXJvIHN0YXRpc3RpY3Mge2FjbC1hZ2dyZWdhdGUtc3Rh dHN9Pw0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNv dW50ZXI2NA0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5n OmNvdW50ZXI2NA0KDQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KICAg ICstLXJ3IGFjbHMNCiAgICAgICArLS1ydyBpbmdyZXNzDQogICAgICAgfCAgKy0tcncgYWNsLXNl dHMNCiAgICAgICB8ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICAgICB8ICAgICAgICAr LS1ydyBuYW1lICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgICAg fCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlw ZQ0KICAgICAgIHwgICAgICAgICstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFj ZS1zdGF0c30/DQogICAgICAgfCAgICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+ IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICB8ICAgICAgICAgICArLS1y byBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICB8ICAgICAgICAgICAr LS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICArLS1ydyBlZ3Jl c3MNCiAgICAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICAgICstLXJ3IGFjbC1zZXQq IFtuYW1lXQ0KICAgICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+IC9hY2Nl c3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAg ICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgICAgKy0tcm8gYWNlLXN0 YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAgICAgICAgICAgICAr LS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFt ZQ0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50 ZXI2NA0KICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNv dW50ZXI2NA0KDQpDb21tZW50cyB3ZWxjb21lIQ0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KDQpP biAxNCBEZWMgMjAxNywgYXQgMTg6NTAsIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSA8 ZWluYXJubkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4gd3JvdGU6DQoNCg0K DQpPbiAxNCBEZWMgMjAxNywgYXQgMDg6MjEsIFNvbmFsIEFnYXJ3YWwgPHNhZ2Fyd2FsMTJAZ21h aWwuY29tPG1haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBFaW5hciwN Cg0KWW91IGhhZCAzIHF1ZXN0aW9ucyBmb3IgbWUgb24gYWxsIHRoZSBzZXZlcmFsIGUtbWFpbCB0 aHJlYWRzLg0KMS4gR2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQNCjIuIGljbXAtb2ZmDQozLiBhY2wt YWdncmVnYXRlLWludGVyZmFjZSBzdGF0cy4NCg0KRm9yICgxKSwgbXkgZmlyc3QgcHJlZmVyZW5j ZSBpcyB0byBoYXZlIHRoZSBtb2RlbCBkZWZpbmUgYXR0YWNobWVudCBwb2ludCBmb3IgaW50ZXJm YWNlcyBvbmx5Lg0KDQplaW5hcm5uPiBJIGhhdmUgc29tZSBkaWZmcywgbGF5ZXJlZCBvbiB0b3Ag b2YgTWFoZXNo4oCZcyBQUiB0byBuZXRtb2Qtd2cvYWNsLW1vZGVsIHRoYXQgZG8gdGhpcy4gTmVh cmx5IGxpa2UgdGhlIGF1Z21lbnRhdGlvbiBJIGhhdmUgYmVsb3cuIEZlZWwgZnJlZSB0byB0YWtl IGEgbG9vayBhdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL21qZXRoYW5hbmRhbmkvYWNsLW1vZGVs L3B1bGwvMw0KDQpIb3dldmVyLCBLcmlzdGlhbiB3YW50cyB0aGUgZ2xvYmFsIGF0dGFjaG1lbnQg cG9pbnQgYXMgd2VsbCBzbyB0aGF0IGhlIGNhbiBhZGQgdGhlIEFDTCB0byB0aGUgbGludXggdGFi bGVzLg0KDQplaW5hcm5uPiBJIHRoaW5rIEtyaXN0aWFuIGRvZXNu4oCZdCBmZWVsIGEgZ2xvYmFs IGF0dGFjaG1lbnQgcG9pbnQgbmVlZHMgdG8gYmUgaW4gdGhpcyBmaXJzdCByZXZpc2lvbi4gQnV0 IGhlIGNhbiBjb25maXJtLg0KDQpJZiBhbiBBQ0wgaXMgYXR0YWNoZWQgZ2xvYmFsbHksIGRvZXMg dGhpcyBtZWFuIGl0IGlzIHBlciBkaXJlY3Rpb24gb3IgZG9lcyBpdCBtZWFuIGl0IGlzIGFjcm9z cyBkaXJlY3Rpb25zPw0KDQplaW5hcm5uPiBJIGRvbuKAmXQga25vdyByaWdodCBub3cgOi0pDQoN ClRoaXMgZ2xvYmFsIEFDTCBtYXkgbm90IGJlIGFwcGxpY2FibGUgdG8gYW55IG9mIENpc2NvJ3Mg c2VydmljZSBwcm92aWRlciByb3V0ZXJzIGFzIEkgZG9uJ3Qgc2VlIGFueSBwbGF0Zm9ybSBhY3R1 YWxseSByZXBsaWNhdGluZyB0aGUgQUNMIHRvIGFsbCBsaW5lIGNhcmRzIGFuZCBhdHRhY2hpbmcg aXQgaW4gaW5ncmVzcyBhbmQgZWdyZXNzIGRpcmVjdGlvbnMgYWNyb3NzIGFsbCBpbnRlcmZhY2Vz Lg0KDQplaW5hcm5uPiBQZXIgb3RoZXIgZW1haWxzLCBJIGRvbuKAmXQgdGhpbmsgd2UgdW5kZXJz dGFuZCB0aGlzIGVub3VnaCB5ZXQgdG8gc3BlY2lmeSBpdCwgc28gSSBzdWdnZXN0IHdlIGp1c3Qg bGVhdmUgaXQgb3V0IGZvciBub3cuIE5vdGhpbmcgaW4gdGhlIG1vZGVsIHByZXZlbnRzIGEg4oCc Z2xvYmFsIGF0dGFjaG1lbnQgcG9pbnTigJ0gYmVpbmcgYWRkZWQgbGF0ZXIgb25jZSB3ZSB1bmRl cnN0YW5kIHdoYXQgaXQgcmVhbGx5IG1lYW5zLg0KDQpGb3IgKDIpLCBJIGFtIG9rIHdpdGggcmVt b3ZpbmcgaWNtcC1vZmYuDQoNCmVpbmFybm4+IERvbmUgaW4gbXkgUFIgYWJvdmUuDQoNCkZvciAo MyksIHRoaXMgd291bGQgaGF2ZSB0byBiZSBhIGNvbWJpbmF0aW9uIG9mIEFDTCBzdGF0cyBhY3Jv c3MgYWxsIGludGVyZmFjZXMgZm9yIGFsbCBBQ0wncy4gU29tZXRoaW5nIGxpa2UgdGhpcyBpcyBw b3NzaWJsZSBvbiBhbiBYUiBib3ggd2hlcmUgQUNFUyBoYXZlIGNvdW50ZXIgbmFtZXMgYXNzb2Np YXRlZCB3aXRoIGl0LiBMZXQncyBjaGF0IGFib3V0IHRoaXMgb2ZmbGluZSB0b21vcnJvdy4NCg0K ZWluYXJubj4gSeKAmWxsIHBpbmcgeW91IHRvIGNsYXJpZnksIGFuZCB3ZSBjYW4gYnJpbmcgYW55 IGNvbmNsdXNpb24gYmFjayB0byB0aGUgbGlzdC4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCg0K U29uYWwuDQoNCg0KT24gV2VkLCBEZWMgMTMsIDIwMTcgYXQgMTI6MTAgUE0sIE1haGVzaCBKZXRo YW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdt YWlsLmNvbT4+IHdyb3RlOg0KV2Ugd2FudCB0byBzdXBwb3J0IOKAnGdsb2JhbOKAnSBhdHRhY2ht ZW50IHBvaW50IGRvd24gdGhlIGxpbmUsIGFuZCB0aGF0IOKAnGdsb2JhbOKAnSBhdHRhY2htZW50 IHBvaW50IHdpbGwgYmUgb25lIG9mIHRoZSBjaG9pY2VzICh0aGUgb3RoZXIgYmVpbmcgdGhlIGlu dGVyZmFjZSksIHdoYXQgd291bGQgdGhpcyBhdWdtZW50IGxvb2sgbGlrZS4gTm90ZSwgYXMgZmFy IGFzIEkga25vdywgeW91IGNhbm5vdCBhdWdtZW50IGluc2lkZSBhIGNob2ljZSBub2RlLg0KDQpP biBEZWMgMTMsIDIwMTcsIGF0IDY6NTcgQU0sIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5u KSA8ZWluYXJubkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4gd3JvdGU6DQoN ClBlcmhhcHMgbGlrZSB0aGlzLCBhcyBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGludGVyZmFjZToN Cg0KICBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZToNCiAgICArLS1ydyBpbmdy ZXNzLWFjbHMNCiAgICB8ICArLS1ydyBhY2wtc2V0cw0KICAgIHwgICAgICstLXJ3IGFjbC1zZXQq IFtuYW1lXQ0KICAgIHwgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+IC9hY2Nlc3Mt bGlzdHMvYWNsL25hbWUNCiAgICB8ICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAgICAtPiAv YWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgfCAgICAgICAgKy0tcm8gYWNlLXN0YXRpc3RpY3Mq IFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICB8ICAgICAgICAgICArLS1ybyBuYW1lICAg ICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgIHwgICAg ICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgIHwgICAg ICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KICAgICstLXJ3 IGVncmVzcy1hY2xzDQogICAgICAgKy0tcncgYWNsLXNldHMNCiAgICAgICAgICArLS1ydyBhY2wt c2V0KiBbbmFtZV0NCiAgICAgICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAvYWNj ZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgICAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICAg LT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgICAgICAgICAgICstLXJvIGFjZS1zdGF0aXN0 aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgICAgICAgICAgICAgKy0tcm8gbmFt ZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAgICAg ICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAg ICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCg0KQ291 bGQgYWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBjb250YWluZXIgYWJvdmUgYm90aCB0aGVzZSAmIHJl bmFtZSDigJxpbmdyZXNzLWFjbHMiIHRvIOKAnGluZ3Jlc3PigJ0sIGV0Yy4gdG8gZ2l2ZSBhIHNp bmdsZSByb290IGZvciB0aGUgYXVnbWVudGF0aW9uIGlmIHByZWZlcnJlZC4NCg0KQ2hlZXJzLA0K DQpFaW5hcg0KDQoNCk9uIDYgRGVjIDIwMTcsIGF0IDE5OjQzLCBFbGlvdCBMZWFyIDxsZWFyQGNp c2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToNCg0KDQoNCk9uIDEyLzYvMTcg NzoyMyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToNCkhvdyBkb2VzIG9uZSBtb3ZlIHRo ZSBpbnRlcmZhY2UgYXR0YWNobWVudCBwb2ludCwgY3VycmVudGx5IGFuDQonaW50ZXJmYWNlLXJl ZicsIHRvIGFuIGF1Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50ZXJmYWNlcy9pbnRlcmZhY2UsDQpp bnNpZGUgb2YgdGhlIOKAmGFjbOKAmSAgY29udGFpbmVyPyBEb3duIHRoZSBsaW5lIHdlIG1pZ2h0 IG5lZWQgdG8gaGF2ZSBhbg0KY29udGFpbmVyIGZvciAiYXR0YWNobWVudCBwb2ludHMiIHRvIGFj Y29tbW9kYXRlIHRoZSBwb3NzaWJpbGl0eSBvZg0KYXR0YWNoaW5nIGFuIEFDTCBlaXRoZXIgdG8g YW4gaW50ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdLg0KDQoNCktlZXBpbmcgaW4gbWluZCB0aGF0 IG9uZSB1c2UgaXMgdGhhdCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW4NCmludGVyZmFjZSBh dCBhbGwuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0K TWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpNYWhlc2gg SmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFu aUBnbWFpbC5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v ZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQo= --_000_3F9E5A58C4504EE0AB19D693A3F9B6ECciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KT24gSmFuIDExLCAyMDE4LCBhdCAwNDoxNiwgTWFoZXNoIEpldGhh bmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IEphbiAxMCwgMjAxOCwgYXQgMTI6NTggQU0sIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5u KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVpbmFybm5AY2lzY28uY29tIiBjbGFzcz0iIj5laW5hcm5u QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KTWFoZXNoLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VHdvIHRoaW5nczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZpcnN0LCBJIHNlZSB0aGF0IHlvdSBoYXZlIHN0 aWxsIGxlZnQgaW4gdGhlIOKAnGljbXAtb2Zm4oCdIGFjdGlvbi4gVGhpcyB3YXMgc29tZXRoaW5n IGJvdGggS3Jpc3RpYW4gYW5kIEkgcmVjb21tZW5kZWQgcmVtb3ZpbmcsIGFuZCBJIGFsc28gZGlz Y3Vzc2VkIHRoaXMgd2l0aCBTb25hbCBhdCB0aGUgZW5kIG9mIGxhc3QgeWVhciBhbmQgc2hlIGFn cmVlZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJseSBiZSByZW1vdmVkIHNpbmNlIGl0DQogc2VlbXMg YXQgdGhpcyBwb2ludCAoYWJzZW50IGFueW9uZSBwb2ludGluZyBvdXQgb3RoZXIgaW1wbGVtZW50 YXRpb25zKSB0byBiZSBhIENpc2NvIElPUy1YUi1zcGVjaWZpYyBmZWF0dXJlIHRoYXQgc2hvdWxk IHByb2JhYmx5IGJlIGRlYWx0IHdpdGggdmlhIGEgdmVuZG9yIGF1Z21lbnRhdGlvbiBpbml0aWFs bHkuIENhbiB3ZSByZW1vdmUgdGhpcz88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpZb3UgYXJlIHJpZ2h0LiBJ dCB3YXMgZGlzY3Vzc2VkLCBidXQgbW9yZSB0byB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkZWQgaXQu IEJlZm9yZSB3ZSByZW1vdmUgaXQsIGxldCBtZSBjbGFyaWZ5IHdoeSB3ZSBuZWVkIGl0LCBhbmQg aWYgYWZ0ZXIgdGhhdCB0aGUgY29uc2Vuc3VzIGlzIHN0aWxsIHRvIHJlbW92ZSBpdCwgb3IgbW92 ZSBpdCB0byBhIENpc2NvIHNwZWNpZmljIGF1Z21lbnRhdGlvbiwgd2UgY2FuIGRvIGl0LjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIGlkZWEgYmVoaW5kIGhhdmlu ZyB0aGUgbGVhZiBpcyBmb3Igcm91dGVycyB0byBzZXR1cCBhIHJ1bGUgdG8gYWNjZXB0IElDTVAg bWVzc2FnZXMsIGFsbG93IHRoZSByb3V0ZXIgdG8gcHJvY2VzcyB0aGUgbWVzc2FnZSwgYnV0IHN1 Z2dlc3QgdGhhdCBhIHJlc3BvbnNlIG1heSBiZSBzdXBwcmVzc2VkLiBUaGF0IHdheSBvbmUgY2Fu IGhhdmUgcnVsZXMgdG8gcmVjZWl2ZSBhbmQgcHJvY2VzcyBJQ01QIG1lc3NhZ2VzIGxpa2Ug4oCc ZGVzdGluYXRpb24NCiB1bnJlYWNoYWJsZeKAnSBvciDigJxmcmFnbWVudGF0aW9uIHJlcXVpcmVk 4oCdIHRoYXQgYXJlIGltcG9ydGFudCBmb3Igcm91dGVycy9ob3N0cywgYnV0IHByZXZlbnQgcm9n dWUgbWFjaGluZXMgZnJvbSBkaXNjb3ZlcmluZyBtYWNoaW5lcyBpbiBhIHN3ZWVwaW5nIHBpbmcu Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5TZWNvbmQsIEkgd291bGQgcmVhbGx5IGxpa2UgdGhlIGNvbnRyaWJ1dG9ycyB3aG8gd2lzaCB0 byBtYWludGFpbiB0aGUgc2VwYXJhdGUgQUNMIGF0dGFjaG1lbnQgaW50ZXJmYWNlIGxpc3Qgd2l0 aCBpbnRlcmZhY2UgcmVmZXJlbmNlcyB0byBsYXkgb3V0IGhvdyBkaXJlY3QgaW50ZXJmYWNlIGF0 dGFjaG1lbnQgcHJldmVudHMgQUNMcyBiZWluZyB1c2VkIHdpdGggb3RoZXIgYXR0YWNobWVudCBw b2ludHMuIEFzIEkgcG9pbnRlZA0KIG91dCwgZGlyZWN0IGludGVyZmFjZSBhdHRhY2htZW50IGRv ZXMgbm90IHJlbW92ZSBhbnkgZmxleGliaWxpdHkgYXQgYWxsIGZvciBvdGhlciBmdXR1cmUgYXR0 YWNobWVudCBwb2ludHMuIFdoaWxlIEnigJltIG5vdCBpbnRyaW5zaWNhbGx5IG9wcG9zZWQgdG8g YSBzZXBhcmF0ZSBsaXN0IHdpdGggaW50ZXJmYWNlIHJlZnMsIEkganVzdCB3YW50IHRvIHVuZGVy c3RhbmQgdGhlIHJhdGlvbmFsZSBhcyB0aGUgbWFqb3JpdHkgb2Ygc3dpdGNoZXMgYW5kDQogcm91 dGVycywgYXMgZmFyIGFzIEkgYW0gYXdhcmUsIHR5cGljYWxseSBhdHRhY2ggQUNMcyBkaXJlY3Rs eSB0byBpbnRlcmZhY2VzLCBtZWFuaW5nIHRoYXQgdGhlIHBhdHRlcm4gaXMgd2VsbC11bmRlcnN0 b29kIGJ5IHR5cGljYWwgdXNlcnMgb2YgdGhpcyBtb2RlbC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJIHRo aW5rIHRoZSBmaXJzdCBpc3N1ZSBpbiBzZXR0aW5nIHVwIGFsdGVybmF0ZSBhdHRhY2htZW50IHBv aW50IGlzLCBob3cgd291bGQgeW91IGRvIHNldHVwIHRoZSBhbHRlcm5hdGUgYXR0YWNobWVudCBw b2ludCBhcyBhIGNob2ljZSBiZXR3ZWVuIGl0IGFuZCBhdHRhY2hpbmcgaXQgdG8gYW4gaW50ZXJm YWNlIHVuZGVyIGFuIGF1Z21lbnRhdGlvbi48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2h5IGRvZXMgaXQgbmVlZCB0byBiZSBhIGNob2ljZSBi ZXR3ZWVuIHRoZSB0d28gYXR0YWNobWVudCBwb2ludHM/IEFuIEFDTCBjYW4gYmUgYXR0YWNoZWQg dG8gb25lIG9yIGJvdGggb2YgaW50ZXJmYWNlcyBhbmQgb3RoZXIgYXR0YWNobWVudCBwb2ludHMu IFRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgY2hvaWNlLjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5TZWNvbmRseSwgaWYgdGhlIEFDTHMgYXJlIHVzZWQg d2l0aCBtdWx0aXBsZSBOSSwgZWFjaCBvZiB0aGVtIHJlZmVycmluZyB0byB0aGUgZ2xvYmFsIHNl dCBvZiBpZXRmLWludGVyZmFjZXMgc2hhcmVkIGJ5IGFsbCB0aGUgaW5zdGFuY2VzLCB3aGljaCB0 aGUgc2NoZW1hIG1vdW50IGRyYWZ0IG91dGxpbmVzJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wNiNzZWN0aW9u LTQiIGNsYXNzPSIiPmhlcmU8L2E+LCZuYnNwO2l0DQogaW1wbGllcyB0aGF0IHlvdSB3aWxsIG5l ZWQgYSByZWZlcmVuY2UgdG8gdGhlIGludGVyZmFjZXMuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpTb3JyeSwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdo YXQgdGhlIHByb2JsZW0gaXMgaGVyZT8gQXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgdGhlIEFDTCBt b2RlbCBiZWluZyBtb3VudGVkIHVuZGVyIGEgbW91bnQgcG9pbnQsIGFuZCBuZWVkaW5nIHRvIHVz ZSB0aG9zZSBBQ0xzIG9uIGdsb2JhbGx5IGRlZmluZWQgaW50ZXJmYWNlcz8gT3IgYXJlIHlvdSBj b25jZXJuZWQgYWJvdXQgdGhlIGludGVyZmFjZSBtb2RlbCBiZWluZyBtb3VudGVkIHVuZGVyDQog YSBtb3VudCBwb2ludCBhbmQgaG93IGdsb2JhbCBBQ0xzIHdvdWxkIGJlIHJlZmVyZW5jZWQ/PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5FaW5hcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5UaGFua3MuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hl ZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxMCBKYW4gMjAxOCwgYXQgMDM6MDgsIE1haGVzaCBKZXRo YW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xh c3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJIGhhdmUgcHVsbGVkIGlu IHRoZSBjaGFuZ2VzIGFzIHRoZXkgcmVsYXRlIHRvOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBtb3Zpbmcg4oCcaW50ZXJmYWNlLWFjbOKAnSB1 bmRlciB0aGUgY29udGFpbmVyIOKAnGF0dGFjaG1lbnQtcG9pbnRz4oCdIG1ha2luZyBpdCBsb2Nh bCB0byB0aGF0IGNvbnRhaW5lci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSByZXZlcnRpbmcg4oCc YWNsLXR5cGXigJ0gdG8g4oCcdHlwZeKAnTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIHJlbW92ZWQg 4oCcaW50ZXJmYWNlLWFsbC1hZ2dyZWdhdGXigJ0gZmVhdHVyZTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4tIHNpbXBsaWZpZWQgc291cmNlIHBvcnQgYW5kIGRlc3RpbmF0aW9uIHBvcnQgZGVmaW5pdGlv bjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhlIHB1bGwgcmVxdWVzdCBmb3IgdGhlIGNoYW5nZXMgY2FuIGJlIGZvdW5kIGhlcmUuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIwIiBj bGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIwPC9h PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+QWZ0ZXIgZGlzY3Vzc2luZyB3aXRoIHNvbWUgb2YgdGhlIG9yaWdpbmFsIGNvbnRyaWJ1dG9y cywgZGVjaWRlZCBub3QgdG8gaW5jbHVkZSB0aGUgY2hhbmdlIGFzIGl0IHJlbGF0ZXMgdG8gYXVn bWVudGluZyBpZXRmLWludGVyZmFjZXMuIFdlIGRpZCBub3QgZmluZCB0aGF0IHRoZSBjaGFuZ2Ug aGFkIGEgcGFydGljdWxhciBhZHZhbnRhZ2Ugb3ZlciB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlv bi4gRXZlbiBpZiB3ZSBkbyBub3QNCiBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgaG93IEFDTHMgbWln aHQgYmUgYXR0YWNoZWQg4oCcZ2xvYmFsbHnigJ0gb3Igb24gc29tZXRoaW5nIHRoYXQgaXMgbm90 IGFuIGludGVyZmFjZSwgaGF2aW5nIHRoZSBmbGV4aWJpbGl0eSB0byBhdHRhY2ggdGhlbSB0byBv dGhlciBhdHRhY2htZW50IHBvaW50cyBpcyBpbXBvcnRhbnQuIEtlZXBpbmcgaXQgYXMgaW50ZXJm YWNlLXJlZiBnaXZlcyB1cyB0aGF0IGZsZXhpYmlsaXR5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxOCwgMjAxNywgYXQgNDozMSBBTSwgRWxpb3Qg TGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIiBjbGFzcz0iIj5sZWFyQGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9 IiNGRkZGRkYiIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+U28gbG9uZyBhcyBub2JvZHkgZXhwZWN0 cyBhbiBpbnRlcmZhY2UgY29uc3RydWN0IGluIGEgTVVEIGZpbGUsIEknbSBoYXBweS48YnIgY2xh c3M9IiI+DQo8L3A+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgi Pk9uIDE3LjEyLjE3IDE1OjM0LCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6 NTI5OUUzMzMtRjFGMy00NzgxLUI0NjctMEJGQjI3MUE0OTE1QGNpc2NvLmNvbSIgY2xhc3M9IiI+ DQpFbGlvdCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPk5vdGhpbmcgY2FuIGZvcmNlIGFuIGltcGxlbWVudGF0aW9uIHRvIGhhdmUgdG8gaW1wbGVt ZW50IGVpdGhlciB0aGUmbmJzcDtpZXRmLWludGVyZmFjZXMgbW9kZWwgb3IgdGhlIGF1Z21lbnRh dGlvbiBpbiB0aGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1vZGVsLiBJIGFwcHJlY2lhdGUg eW91ciBkZXNpcmUgZm9yIG1vZHVsYXJpdHkgYW5kIGNvaGVzaXZlbmVzcywgYnV0IEkgd291bGQg cmVzaXN0ICMxLCBiZWNhdXNlIEkgZmVlbA0KIHRoYXQgdGhlIG1ham9yaXR5IG9mIHVzZXJzIHdp bGwgYmUgdGFyZ2V0aW5nIGludGVyZmFjZS1iYXNlZCBhdHRhY2htZW50IG92ZXIgdGltZS4gSeKA mXZlIGFkZGUgYmFjayBpbiB1c2Ugb2YgdGhlIOKAnGludGVyZmFjZS1hdHRhY2htZW504oCdIGZl YXR1cmUgKHdoaWNoIEkgdG9vayBvdXQgYXMgcGFydCBvZiByZWZhY3RvcmluZyBpbnRlcmZhY2Ug YXR0YWNobWVudCkuIFBhcnQgb2Y6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBu b25lOyBwYWRkaW5nOg0KICAgICAgICAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMSIgY2xh c3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdn L2FjbC1tb2RlbC9wdWxsLzIxPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGF1Z21lbnRzIHBhcnQg b2YgdGhlIHRyZWUgbm93IGxvb2tzIGxpa2U6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJm YWNlOjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291 cmllciI+Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNscyA8YiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBjb2xvcj0iI2ZmMjYwMCI+e2ludGVyZmFjZS1hdHRhY2htZW50fTwvZm9udD48L2I+Pzwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGluZ3Jlc3M8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm IzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2Fj bC90eXBlPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJD b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9 PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVy NjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBlZ3Jlc3M8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCog W25hbWVdPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJD b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGU/ ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3Mt bGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFj ZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNl cy9hY2UvbmFtZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7 IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZu YnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTcgRGVjIDIwMTcsIGF0IDExOjI5LCBFbGlvdCBM ZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iIGNsYXNzPSIiIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0 ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkVp bmFyLDwvcD4NCjxwIGNsYXNzPSIiPkkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgZmluZSwgd2l0aCBv bmUgZXhjZXB0aW9uLiZuYnNwOyBJIHdvdWxkIHJhdGhlciB0aGUgYXVnbWVudCB0byB0aGUgaW50 ZXJmYWNlIG5vdCBiZSByZXF1aXJlZCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3QgYWN0 dWFsbHkgaGF2ZSBpbnRlcmZhY2VzLiZuYnNwOyBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtYXkg YmUgdHdvIHdheXMgdG8gZ28gYWJvdXQgdGhpczo8L3A+DQo8b2wgY2xhc3M9IiI+DQo8bGkgY2xh c3M9IiI+U2VwYXJhdGUgb3V0IHRoZSBhdWdtZW50IGludG8gYSBzZXBhcmF0ZSBtb2R1bGUgKHNh bWUgZG9jIGlzIGZpbmUpOyBvcg0KPC9saT48bGkgY2xhc3M9IiI+U29tZWhvdyAmcXVvdDtmZWF0 dXJlLWl6ZSZxdW90OyB0aGUgYXVnbWVudC4gPC9saT48L29sPg0KPHAgY2xhc3M9IiI+SSBkb24n dCBrbm93IGhvdyB0byBkbyAoMikgYnV0IGlmIHlvdSBkbywgdGhhdCdzIG9rYXkgYnkgbWUuPC9w Pg0KPHAgY2xhc3M9IiI+RWxpb3Q8YnIgY2xhc3M9IiI+DQo8L3A+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDE2LjEyLjE3IDE0OjE5LCBFaW5hciBOaWxz ZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MEY0M0NERTktMjFEMi00RUQ3LUFFN0MtOUEyQjlG ODU0MTAxQGNpc2NvLmNvbSIgY2xhc3M9IiI+DQpBbGwsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BZnRlciBhIHNlcmllcyBvZiBkaXNjdXNzaW9u cyBvbi0gYW5kIG9mZi1saXN0LCBJIGhhdmUgYSBjYW5kaWRhdGUgUFIgdGhhdCBpbmNsdWRlcyB0 aGUgY2hhbmdlcyBpbiB0aGUgUFIgTWFoZXNoIHNlbnQgb3V0IHBsdXMgc29tZSBtb3JlIGVkaXRz LiBQbGVhc2Ugc2VlIGNvbnNvbGlkYXRlZCBQUiBoZXJlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQw cHg7IGJvcmRlcjogbm9uZTsNCiAgICAgICAgICAgICAgICAgICAgcGFkZGluZzogMHB4OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qt d2cvYWNsLW1vZGVsL3B1bGwvMjEiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0 cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMTwvYT48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYWluIGNoYW5nZXMgaW4gYWRkaXRpb24gdG8gTWFoZXNo 4oCZcyBQUiBhcmU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjx1bCBjbGFzcz0iTWFpbE91dGxpbmUiPg0KPGxpIGNsYXNzPSIiPk1v dmVkIGludGVyZmFjZSBhdHRhY2htZW50IHRvIGJlIHZpYSBhbiBpbnRlcmZhY2UgYXVnbWVudGF0 aW9uLiA8L2xpPjxsaSBjbGFzcz0iIj5SZXN0cnVjdHVyZWQgcG9ydCBtYXRjaGVzIHNsaWdodGx5 IHVuZGVyIGJvdGggSVB2NCBhbmQgSVB2NiBjb250YWluZXJzLg0KPC9saT48bGkgY2xhc3M9IiI+ UmVtb3ZlZCB1bm5lY2Vzc2FyeSBpZGVudGl0eSAnaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGXigJku IDwvbGk+PGxpIGNsYXNzPSIiPlJlbW92ZWQgYWN0aW9uIOKAmGljbXAtb2Zm4oCZLCBjYW4gYmUg YXVnbWVudGVkIGxhdGVyLiA8L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZvciByZWZlcmVuY2UsIGhlcmUgaXMgdGhl IGN1cnJlbnQgWUFORyB0cmVlIHBsdXMg4oCcLS1pZXRm4oCdIGxvZ3M6PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+MTM6MTIgJCBweWFuZyAtLWlldGYgLS1s aW50IC1mIHRyZWUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPmlldGYtYWNjZXNzLWNv bnRyb2wtbGlzdC55YW5nOjUxOiBlcnJvcjogYmFkIHZhbHVlICZxdW90O1lZWVktTU0tREQmcXVv dDsgKHNob3VsZCBiZSBkYXRlKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+bW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjY2Vzcy1saXN0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLXJ3IGFjbCogW25hbWVdPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDtzdHJpbmc8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGU/ICZuYnNwOyBhY2wtdHlwZTwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNlczwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGFjZSogW25h bWVdPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzdHJp bmc8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzstLXJ3IG1hdGNoZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgKGwyKT88L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwOyYjNDM7LS06KGV0aCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGV0aCB7 bWF0Y2gtb24tZXRofT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7 LS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 eWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IGRlc3RpbmF0aW9uLW1hYy1hZGRyZXNzLW1hc2s/ICZuYnNwOyB5YW5nOm1hYy1hZGRy ZXNzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgc291cmNl LW1hYy1hZGRyZXNzPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB5 YW5nOm1hYy1hZGRyZXNzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcncgc291cmNlLW1hYy1hZGRyZXNzLW1hc2s/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3lhbmc6bWFjLWFkZHJlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyBldGhlcnR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtldGg6ZXRoZXJ0eXBlPC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7JiM0MzstLXJ3IChsMyk/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihpcHY0KTwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgaXB2NCB7bWF0Y2gtb24taXB2NH0/PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRzY3A/ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgaW5ldDpkc2NwPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGVj bj8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBsZW5ndGg/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgdHRsPyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3VpbnQ4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHBy b3RvY29sPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPzwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS1ydyBzb3VyY2UtcG9ydC1sb3dlciAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IHNvdXJj ZS1wb3J0LXVwcGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0 LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLToo b3BlcmF0b3IpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBzb3VyY2Utb3BlcmF0b3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgb3BlcmF0b3I8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJiM0MzstLXJ3IHNvdXJjZS1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyAoZGVzdGluYXRpb24tcG9ydC1yYW5n ZS1vci1vcGVyYXRvcik/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsm IzQzOy0tOihyYW5nZSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7JiM0MzstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1wb3J0LXVwcGVyICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7JiM0MzstLToob3BlcmF0b3IpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRvcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzdGluYXRpb24tcG9ydCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaWhsPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3VpbnQ4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGZsYWdz PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Yml0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBvZmZzZXQ/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaWRlbnRpZmljYXRpb24/ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQxNjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ydyBkZXN0aW5hdGlvbi1pcHY0LW5ldHdvcms/ICZuYnNwOyBpbmV0Omlw djQtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHNvdXJj ZS1pcHY0LW5ldHdvcms/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZXQ6aXB2NC1wcmVm aXg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KGlwdjYpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBpcHY2IHttYXRjaC1vbi1pcHY2fT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBkc2NwPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6ZHNj cDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGVjbj8gJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLXJ3IGxlbmd0aD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQxNjwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR0bD8gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IHByb3RvY29sPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLXJ3IChzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/PC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KHJhbmdlKTwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyYjNDM7 LS1ydyBzb3VyY2UtcG9ydC1sb3dlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGluZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgc291cmNlLXBvcnQtdXBwZXIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2Ut b3BlcmF0b3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3BlcmF0 b3I8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcncgc291cmNlLXBvcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgKGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3Bl cmF0b3IpPzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQz Oy0tOihyYW5nZSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZh Y2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7 fCAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRpb24tcG9ydC1sb3dlciAmbmJzcDsgJm5ic3A7ICZu YnNwO2luZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAmbmJzcDsg Jm5ic3A7ICZuYnNwO2luZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLToob3BlcmF0b3IpPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRlc3RpbmF0aW9uLW9w ZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29wZXJhdG9yPC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRlc3RpbmF0 aW9uLXBvcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBv cnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg ZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrPyAmbmJzcDsgaW5ldDppcHY2LXByZWZpeDwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHNvdXJjZS1pcHY2LW5ldHdv cms/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZXQ6aXB2Ni1wcmVmaXg8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBmbG93LWxhYmVsPyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6aXB2 Ni1mbG93LWxhYmVsPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IChsNCk/PC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQz Oy0tOih0Y3ApPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyYjNDM7LS1ydyB0Y3Age21hdGNoLW9u LXRjcH0/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJD b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHNlcXVlbmNl LW51bWJlcj8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VpbnQzMjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2tub3dsZWRnZW1lbnQtbnVtYmVy PyAmbmJzcDsgdWludDMyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3 IGRhdGEtb2Zmc2V0PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyByZXNl cnZlZD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBmbGFn cz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Yml0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyB3aW5kb3ctc2l6ZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7dWludDE2PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3 IHVyZ2VudC1wb2ludGVyPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQx NjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBvcHRpb25zPyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3VpbnQzMjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7JiM0MzstLToodWRwKTwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAm bmJzcDsmIzQzOy0tcncgdWRwIHttYXRjaC1vbi11ZHB9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBsZW5ndGg/ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNw OyYjNDM7LS06KGljbXApPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpY21wIHtt YXRjaC1vbi1pY21wfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7 LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50 ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGNvZGU/ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQ4PC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgcmVzdC1vZi1oZWFkZXI/ICZuYnNw OyB1aW50MzI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgZWdyZXNzLWludGVyZmFjZT8gJm5ic3A7ICZuYnNw O2lmOmludGVyZmFjZS1yZWY8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgaW5ncmVzcy1pbnRlcmZhY2U/ICZu YnNwOyBpZjppbnRlcmZhY2UtcmVmPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY3Rpb25zPC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3 IGZvcndhcmRpbmcgJm5ic3A7ICZuYnNwO2lkZW50aXR5cmVmPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGxv Z2dpbmc/ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWRlbnRpdHlyZWY8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIHN0YXRpc3Rp Y3Mge2FjbC1hZ2dyZWdhdGUtc3RhdHN9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQt cGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0 Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+PGJyIGNsYXNzPSIiPg0K PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVy Ij4mbmJzcDsgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6PC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICYjNDM7LS1ydyBhY2xzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg aW5ncmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgYWNs LXNldHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IHR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0m Z3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFt ZV0ge2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMv YWNsL2FjZXMvYWNlL25hbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJz cDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNw OyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJ3IGVncmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncg YWNsLXNldHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wv bmFtZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291 cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvdHlwZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gYWNlLXN0YXRpc3Rp Y3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBuYW1l ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAv YWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0 Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1y byBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Db21tZW50cyB3ZWxjb21lITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTQg RGVjIDIwMTcsIGF0IDE4OjUwLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgJmx0Ozxh IGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5laW5hcm5uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiAxNCBEZWMgMjAxNywgYXQgMDg6MjEsIFNvbmFsIEFnYXJ3YWwg Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbSIgY2xhc3M9IiIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5zYWdhcndhbDEyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBFaW5hciwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPllvdSBoYWQgMyBxdWVzdGlvbnMgZm9yIG1l IG9uIGFsbCB0aGUgc2V2ZXJhbCBlLW1haWwgdGhyZWFkcy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+MS4gR2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4g aWNtcC1vZmY8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+My4gYWNsLWFnZ3JlZ2F0ZS1pbnRlcmZhY2Ug c3RhdHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Gb3IgKDEpLCBteSBmaXJzdCBwcmVmZXJlbmNlIGlzIHRvIGhhdmUgdGhlIG1vZGVs IGRlZmluZSBhdHRhY2htZW50IHBvaW50IGZvciBpbnRlcmZhY2VzIG9ubHkuPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVy ZWQgb24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8gbmV0bW9kLXdnL2FjbC1tb2RlbCB0aGF0IGRv IHRoaXMuIE5lYXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24gSSBoYXZlIGJlbG93LiBGZWVsIGZy ZWUgdG8gdGFrZSBhIGxvb2sgYXQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4Ow0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9kZWwvcHVs bC8zIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vZ2l0aHViLmNvbS9t amV0aGFuYW5kYW5pL2FjbC1tb2RlbC9wdWxsLzM8L2E+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+SG93ZXZlciwgS3Jpc3RpYW4gd2FudHMgdGhlIGdsb2JhbCBhdHRhY2htZW50 IHBvaW50IGFzIHdlbGwgc28gdGhhdCBoZSBjYW4gYWRkIHRoZSBBQ0wgdG8gdGhlIGxpbnV4IHRh Ymxlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5laW5hcm5uJmd0OyBJIHRoaW5r IEtyaXN0aWFuIGRvZXNu4oCZdCBmZWVsIGEgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQgbmVlZHMg dG8gYmUgaW4gdGhpcyBmaXJzdCByZXZpc2lvbi4gQnV0IGhlIGNhbiBjb25maXJtLjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPklmIGFuIEFD TCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9lcyB0aGlzIG1lYW4gaXQgaXMgcGVyIGRpcmVjdGlv biBvciBkb2VzIGl0IG1lYW4gaXQgaXMgYWNyb3NzIGRpcmVjdGlvbnM/PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgSSBkb27igJl0IGtub3cgcmlnaHQgbm93IDot KTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PlRoaXMgZ2xvYmFsIEFDTCBtYXkgbm90IGJlIGFwcGxpY2FibGUgdG8gYW55IG9mIENpc2NvJ3Mg c2VydmljZSBwcm92aWRlciByb3V0ZXJzIGFzIEkgZG9uJ3Qgc2VlIGFueSBwbGF0Zm9ybSBhY3R1 YWxseSByZXBsaWNhdGluZyB0aGUgQUNMIHRvIGFsbCBsaW5lIGNhcmRzIGFuZCBhdHRhY2hpbmcg aXQgaW4gaW5ncmVzcyBhbmQgZWdyZXNzIGRpcmVjdGlvbnMgYWNyb3NzIGFsbCBpbnRlcmZhY2Vz LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4mZ3Q7IFBlciBvdGhlciBl bWFpbHMsIEkgZG9u4oCZdCB0aGluayB3ZSB1bmRlcnN0YW5kIHRoaXMgZW5vdWdoIHlldCB0byBz cGVjaWZ5IGl0LCBzbyBJIHN1Z2dlc3Qgd2UganVzdCBsZWF2ZSBpdCBvdXQgZm9yIG5vdy4gTm90 aGluZyBpbiB0aGUgbW9kZWwgcHJldmVudHMgYSDigJxnbG9iYWwgYXR0YWNobWVudCBwb2ludOKA nSBiZWluZyBhZGRlZCBsYXRlciBvbmNlIHdlIHVuZGVyc3RhbmQgd2hhdCBpdCByZWFsbHkgbWVh bnMuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+Rm9yICgyKSwgSSBhbSBvayB3aXRoIHJlbW92aW5nIGljbXAtb2ZmLjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4mZ3Q7IERvbmUgaW4gbXkgUFIgYWJvdmUuPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Rm9yICgz KSwgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIGEgY29tYmluYXRpb24gb2YgQUNMIHN0YXRzIGFjcm9z cyBhbGwgaW50ZXJmYWNlcyBmb3IgYWxsIEFDTCdzLiBTb21ldGhpbmcgbGlrZSB0aGlzIGlzIHBv c3NpYmxlIG9uIGFuIFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3NvY2lh dGVkIHdpdGggaXQuIExldCdzIGNoYXQgYWJvdXQgdGhpcyBvZmZsaW5lIHRvbW9ycm93LjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4mZ3Q7IEnigJlsbCBwaW5nIHlvdSB0 byBjbGFyaWZ5LCBhbmQgd2UgY2FuIGJyaW5nIGFueSBjb25jbHVzaW9uIGJhY2sgdG8gdGhlIGxp c3QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+U29uYWwuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3otZG8t bm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIiBjbGFzcz0iIj5XZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFj aG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1l bnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRoZSBvdGhlciBiZWluZyB0aGUg aW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9vayBsaWtlLiBOb3RlLCBhcyBm YXIgYXMgSSBrbm93LA0KIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYSBjaG9pY2Ugbm9kZS4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4t TnlnYWFyZCAoZWluYXJubikgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZWluYXJubkBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV83MTAyNDA4OTA3NTMz MDE3NTAxQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7bGluZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSIg Y2xhc3M9IiI+UGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50 ZXJmYWNlOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW46MA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaW5ncmVzcy1h Y2xzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0Mzst LXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3 IG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZn dDsgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3Rz L2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2lu dGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbmFtZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1s aXN0cy9hY2wvYWNlcy9hY2UvPHdiciBjbGFzcz0iIj5uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291 bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBl Z3Jlc3MtYWNsczwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNs YXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlLzx3 YnIgY2xhc3M9IiI+bmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hl ZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0g Y29udGFpbmVyIGFib3ZlIGJvdGggdGhlc2UgJmFtcDsgcmVuYW1lIOKAnGluZ3Jlc3MtYWNscyZx dW90OyB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdpdmUgYSBzaW5nbGUgcm9vdCBmb3IgdGhl IGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWlu YXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiA2IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJtXzcxMDI0MDg5MDc1MzMwMTc1MDFBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCk9uIDEyLzYvMTcgNzoyMyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Ib3cgZG9lcyBvbmUgbW92 ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbjxiciBjbGFzcz0i Ij4NCidpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZh Y2VzL2ludGVyZmFjZSw8YnIgY2xhc3M9IiI+DQppbnNpZGUgb2YgdGhlIOKAmGFjbOKAmSAmbmJz cDtjb250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZlIGFuPGJyIGNs YXNzPSIiPg0KY29udGFpbmVyIGZvciAmcXVvdDthdHRhY2htZW50IHBvaW50cyZxdW90OyB0byBh Y2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2Y8YnIgY2xhc3M9IiI+DQphdHRhY2hpbmcgYW4g QUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KS2VlcGluZyBp biBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFjaCB0byBhbjxi ciBjbGFzcz0iIj4NCmludGVyZmFjZSBhdCBhbGwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY2xh c3M9IiIgY29sb3I9IiM4ODg4ODgiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWFo ZXNoIEpldGhhbmFuZGFuaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3otZG8tbm90 LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRI ZWFkZXIiPjwvZmllbGRzZXQ+IDxiciBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9IiIgd3JhcD0iIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1h aWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5uZXRtb2RAaWV0Zi5v cmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT4NCjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4N CjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9y ZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1haGVz aCBKZXRoYW5hbmRhbmk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48 L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9k IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bSIgY2xhc3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3F9E5A58C4504EE0AB19D693A3F9B6ECciscocom_-- From nobody Thu Jan 11 00:49: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 1732C12EABB; Thu, 11 Jan 2018 00:49:28 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DCJBy3uavYIB; Thu, 11 Jan 2018 00:49:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6412EAB8; Thu, 11 Jan 2018 00:49:26 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1178C1AE00B6; Thu, 11 Jan 2018 09:49:25 +0100 (CET) Date: Thu, 11 Jan 2018 09:49:24 +0100 (CET) Message-Id: <20180111.094924.121178859287289476.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: adam@nostrum.com, iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180111071317.wvqyyufx4bkyz5pi@elstar.local> References: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> <20180111071317.wvqyyufx4bkyz5pi@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 08:49:28 -0000 Hi, Juergen Schoenwaelder wrote: > On Wed, Jan 10, 2018 at 10:55:46PM -0800, Adam Roach wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I have one correction and one question about the ietf-hardware YANG module. > > > > enum exa { > > value 14; > > description > > "Data scaling factor of 10^15."; > > } > > enum peta { > > value 15; > > description > > "Data scaling factor of 10^18."; > > } > > > > I believe this is backwards -- "peta" should be 10^15, while "exa" should be 10^18. > > I agree this is wrong. This bug was most likely inherited from RFC > 3433 but luckily there is a confirmed errata for RFC 3433. So Martin > should fix this in the YANG module Yes, it was inherited from the MIB. I will fix this in the YANG module. (and his copy of the MIB module). Will do. As it happens, I always just look into the MIBs distributed by libsmi, and it seems the MIB is not updated there ;-) Which leads to an interesting issue - the errata for the MIB not only changes the description in the comment, but it also changes the *value*. I will thus do the same in the YANG module: enum peta { value 14; description "Data scaling factor of 10^15."; } enum exa { value 15; description "Data scaling factor of 10^18."; } This matches the verified MIB Errata, but since the original MIB is probably present in most distributions, I wouldn't be surprised if this object is not correctly implemented in real code... When I googled for the MIB I found several instances of NON-updated MIBs, and zero instances of an updated MIB. > > typedef sensor-value-precision { > > type int32 { > > range "-8 .. 9"; > > } > > > > Why is this an int32 rather than an int8? > > Likely because they way this was defined in the MIB module: > > SYNTAX Integer32 (-8..9) > > I assume using int8 would be fine as well. (Note that YANG update > rules allow to expand the range restriction but they do not allow to > replace int8 with int32; so the range resulting from the type is a > hard limit, the range restriction is an expandable limit. I guess in > this case using int8 would be safe but then this is a slight (but > likely not important) departure from the MIB module.) I agree. I will make the change to int8. /martin From nobody Thu Jan 11 01:11: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 3322312EAC1; Thu, 11 Jan 2018 01:11:28 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mXcNIaqf0KaI; Thu, 11 Jan 2018 01:11:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59B0B124239; Thu, 11 Jan 2018 01:11:26 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C5921AE00B6; Thu, 11 Jan 2018 10:11:25 +0100 (CET) Date: Thu, 11 Jan 2018 10:11:24 +0100 (CET) Message-Id: <20180111.101124.1945243507741650830.mbj@tail-f.com> To: adam@nostrum.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151565576445.10072.221877513960755879.idtracker@ietfa.amsl.com> References: <151565576445.10072.221877513960755879.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc7277bis-02: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:11:28 -0000 Hi, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-netmod-rfc7277bis-02: No Objection [...] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The MAC addresses in the examples are using an OUI of 00:01:02, which is > assigned by IEEE to 3Com (and which presumably belongs to HP now). Please > change the examples to make use of addresses from the unicast range documented > in > (e.g. 00:00:5E:00:53:AB). Thank you for drawing my attention to this RFC; I did not know about it. The MAC address is now fixed in my local copy. /martin From nobody Thu Jan 11 01:13:07 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 92DAF12EABB; Thu, 11 Jan 2018 01:13:04 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 ypy8vksNLSVQ; Thu, 11 Jan 2018 01:13:01 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67181124239; Thu, 11 Jan 2018 01:13:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3922769A; Thu, 11 Jan 2018 10:13:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id jYFzxs441-bI; Thu, 11 Jan 2018 10:12:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 10:13:00 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2202C2013D; Thu, 11 Jan 2018 10:13:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9jBzZHFwk-RN; Thu, 11 Jan 2018 10:12:59 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7EF32013C; Thu, 11 Jan 2018 10:12:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 94BF1420B8BD; Thu, 11 Jan 2018 10:12:59 +0100 (CET) Date: Thu, 11 Jan 2018 10:12:59 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: adam@nostrum.com, iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org Message-ID: <20180111091259.72vv7vs35jlqm4so@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , adam@nostrum.com, iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> <20180111071317.wvqyyufx4bkyz5pi@elstar.local> <20180111.094924.121178859287289476.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180111.094924.121178859287289476.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:13:05 -0000 On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote: > Will do. As it happens, I always just look into the MIBs distributed > by libsmi, and it seems the MIB is not updated there ;-) OK. My fault. > Which leads > to an interesting issue - the errata for the MIB not only changes the > description in the comment, but it also changes the *value*. I will > thus do the same in the YANG module: > > enum peta { > value 14; > description > "Data scaling factor of 10^15."; > } > enum exa { > value 15; > description > "Data scaling factor of 10^18."; > } > > This matches the verified MIB Errata, but since the original MIB is > probably present in most distributions, I wouldn't be surprised if > this object is not correctly implemented in real code... When I > googled for the MIB I found several instances of NON-updated MIBs, and > zero instances of an updated MIB. Yes. This is very subtle. Not changing the value would also have been somewhat odd since tera and exa are then 'out of natural order'. But it might have been more robust. Anyway, the errata says what it says and all we can do now is likely to hope that people running into this at the end find the errata linked to the RFC. Hence, I will commit the errata fix to the libsmi repository now. /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 Jan 11 03:04: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 80F1C12EAE6; Thu, 11 Jan 2018 03:04:05 -0800 (PST) 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_RP_MATCHES_RCVD=-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 4HfbcW0Jw_2G; Thu, 11 Jan 2018 03:04:03 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37C212EAE5; Thu, 11 Jan 2018 03:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1715; q=dns/txt; s=iport; t=1515668643; x=1516878243; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=HEa2J02e+bnUg5MKa/LyUOQkDnmkTLf3eaMSbhrDjb0=; b=IazkjRauRNL9iErviSXnnICDxXU0TxzB4efdO2YlBBj/Zu8dULtS69fs Wr9JFpTSlENSUYdrfNjUZaDurLozzsL7X4hLYIBS2KXA7ApcDi1xYnVJ/ LiTGFLroIqxEGmQiNmAHmCwNO7MT7wy9Bz0GkMyGcvnctA+3caIBRZXV2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAhRFda/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUbhC6LGI9smUYKhTsChQ0UAQEBAQEBAQEBayiFJAEFIxVRCw4?= =?us-ascii?q?KAgImAgJXBgEMCAEBii+wF4InijoBAQEBAQEBAwEBAQEBASKBD4Mcg2yCEgyCe?= =?us-ascii?q?Yg5gmUBBKNkjAGJRowjh2uPG4gJgTw2IoFQMhoIGxU9giuDCIFPQIwXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,344,1511827200"; d="scan'208";a="1343576" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 11:04:01 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0BB4004003599; Thu, 11 Jan 2018 11:04:00 GMT To: Martin Bjorklund , adam@nostrum.com, iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> <20180111071317.wvqyyufx4bkyz5pi@elstar.local> <20180111.094924.121178859287289476.mbj@tail-f.com> <20180111091259.72vv7vs35jlqm4so@elstar.local> From: Benoit Claise Message-ID: Date: Thu, 11 Jan 2018 12:04:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180111091259.72vv7vs35jlqm4so@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 11:04:05 -0000 On 1/11/2018 10:12 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote: > >> Will do. As it happens, I always just look into the MIBs distributed >> by libsmi, and it seems the MIB is not updated there ;-) > OK. My fault. > >> Which leads >> to an interesting issue - the errata for the MIB not only changes the >> description in the comment, but it also changes the *value*. I will >> thus do the same in the YANG module: >> >> enum peta { >> value 14; >> description >> "Data scaling factor of 10^15."; >> } >> enum exa { >> value 15; >> description >> "Data scaling factor of 10^18."; >> } >> >> This matches the verified MIB Errata, but since the original MIB is >> probably present in most distributions, I wouldn't be surprised if >> this object is not correctly implemented in real code... When I >> googled for the MIB I found several instances of NON-updated MIBs, and >> zero instances of an updated MIB. > Yes. This is very subtle. Not changing the value would also have been > somewhat odd since tera and exa are then 'out of natural order'. But > it might have been more robust. Anyway, the errata says what it says > and all we can do now is likely to hope that people running into this > at the end find the errata linked to the RFC. Hence, I will commit the > errata fix to the libsmi repository now. Exactly the discussion we've been having on the YANG doctor list. "- errata on the YANG module inside a RFC: this is looking for troubles IMO." Obviously the same applies for MIB modules. Regards, Benoit > > /js > From nobody Thu Jan 11 04:34: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 79F3212EB25; Thu, 11 Jan 2018 04:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 dkt9jE4VD60V; Thu, 11 Jan 2018 04:34:12 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0124.outbound.protection.outlook.com [104.47.1.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E65812EB11; Thu, 11 Jan 2018 04:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jJfLRu/TSHOwfN77W2q10KA0WYEUGWZN84Y93hTk87k=; b=Arcvwr8YmbUmQhKNfo/Mq/MICNv5bZqtohTyS4Ktn1KZgvXrUWjHJE6RL/8RffesRgAvqWchZmiGs/5FKt2AbKXgoIaJk1mUrS33nRXX8iWDfv9KU+NG3dg4IMPEd1sSJ5LCM25LxQQwuENbpzNm0a9iqYzZ7of8IzW673cLPQc= Received: from pc6 (86.169.153.236) by VI1PR07MB1566.eurprd07.prod.outlook.com (2a01:111:e400:7a65::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.407.1; Thu, 11 Jan 2018 12:34:08 +0000 Message-ID: <038f01d38ad8$59860240$4001a8c0@gateway.2wire.net> From: "tom p." To: "Juergen Schoenwaelder" Cc: , , , , References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> <20180109.210824.760424986407969599.mbj@tail-f.com> <20180110163653.fjfbmr3gbnue52pq@elstar.local> Date: Thu, 11 Jan 2018 12:32:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: AM3PR07CA0136.eurprd07.prod.outlook.com (2603:10a6:207:8::22) To VI1PR07MB1566.eurprd07.prod.outlook.com (2a01:111:e400:7a65::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f411c283-7768-48ca-69a5-08d558ef9cec X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020066)(4652020)(8989060)(4534096)(4602075)(4627192)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:VI1PR07MB1566; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1566; 3:OgfTXQ1EV+vpAslKsY63kLrcWTH7yu/7q64Kcv0RIGk8Ivt8Xl+YkLUOFp6JtWghkLg/P8DSLfqXwXnqmRJkkZEsiUYrJOfQ9opFnClNpK8eDUSu4jy9VipSU4b/Q4ctDMmOiC4u6i7jF9vvHcoQgRQOpZqcsCdPn0x6bFROcDvpJUAFVIkojLhcBdKNCX1t2tN02r0o35LGTuuQvf56QJJCqIrDDc9fsP/VFl0kcYyp1iFE/hehu5Bekb4Jl74nCpKwDv1/DrPZEz13h/KBGyB4jahPSmUhS4M3SUH3zIU=; 25:gkLGHMPyN7bUpijIYLghGgEmj2qrzhZBVCTWPAOvOvjrt/k2LW8mVEIgBHPqmXqMxHpqTdCOPT+qu1QjCln3M5cCBRYQqlTY63ekyLFUVf1BHi/EdkXTBh2A2iznrYjhmD39Rqbnbin/QQtYTyZ+tPV8xFQ+Wew1vBTMgFTcBjjypTzlGvJfUm9kL0Ecwr9e8kb7nSoxjVqe9dQZ2XKvgOn7v6x4OiYxBBC7D/LhBS21uZzeTNbQlS/LPYxeC+eEY+AiqZ4ghMdYpwal4dmErSrlV/e6OXVijexPa5UdmbLq/Q/E+9V5xZiTmZtLfz58IW5I851Wg0FxRIQlnMmkCQ==; 31://2gX7nXpsLrribR5On1+czDPefqD4t2IwUGrsEwGfVaEH+SHzeiA3va6mhkl3h5q238D1oNoHmf3S0cRdB2Tqv/CItZnvCe2sDv+8B2rDg4s8Pf0rruhOjd99ZKFyI+QBQ+bFIm73BIYftdgg2uofvO4AA0QgDSUbioFr98sL6KmOiHBgOh54NaBLr6l3ENlsykN6yi2aCW29JY23b/Tejxl9haRr3/VVFPGxu2XK4= X-MS-TrafficTypeDiagnostic: VI1PR07MB1566: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501134)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041268)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR07MB1566; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:VI1PR07MB1566; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1566; 4:1CHnB11jP/wojgrhJc32b7H90I9RCr5Zp30/r0iMtd3loBfQVHuay0JqzVP9FzQq7JuNBjfKM15k66WcOeMFZbB7KWH3LLBXEutZ0drEDdArpN/ug5qCNJqqTIdU76MMwUQu4Lc3Lj5MvLsNo7LtJkHWU99dcoL9eyav3zSatI1dNpz/iGRAOlsUTfelUqZh5GiLxq7gMAJrwI6eB98s/YjePzLa5Hy2BaLr4rDdVeK/VRlKnP6k/UzzRQuCTiSoaDaZ1ezIVjcgEhgS11g0BEGvvtM//i6d3p6WQV6Q160L+poT9em7CxY4ldheYFOo3EYxnW2L6+3pyyWQz83LDa5gAEcpFD6nFAxJfqk++B8= X-Forefront-PRVS: 0549E6FD50 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(346002)(376002)(366004)(13464003)(189003)(199004)(24454002)(44716002)(62236002)(316002)(7736002)(105586002)(53936002)(47776003)(106356001)(8936002)(52116002)(81166006)(81156014)(8676002)(116806002)(230783001)(6496006)(84392002)(6306002)(6246003)(9686003)(2906002)(54906003)(66066001)(4326008)(230700001)(478600001)(59450400001)(386003)(5660300001)(14496001)(6916009)(6666003)(4720700003)(81686011)(76176011)(81816011)(33896004)(50226002)(97736004)(50466002)(6116002)(93886005)(68736007)(3846002)(229853002)(6346003)(61296003)(16526018)(1556002)(6486002)(86362001)(1456003)(23756003)(305945005)(44736005)(25786009)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1566; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1566; 23:A6ylvOXsR5tPwXTL+JnCAYsmlviEZIU9eIAYGLw?= =?iso-8859-1?Q?o1xMuyZvmFhINGIcCXqaAdms+Q/6PdqfRQt6kcMxTVdBCgVSAZOexZ6svP?= =?iso-8859-1?Q?vuASiXD3uz4zhTBVdNPuMZM4s+TwUetsMGq8rE/Ey0rFLXY4ytAxtCeoM4?= =?iso-8859-1?Q?OFhXw80b1LJqTXe5jJ96uVwORq04eFtD88qywqG5WVrQ1gIbsLABfOVWU8?= =?iso-8859-1?Q?2uj26oshy4XclDFs9V0BWt8J8j8vbxZpyCMLFmD8XI5ciTcwX/vtAlCxAU?= =?iso-8859-1?Q?NK5MuYDGVh8Zv+CaBUyrqfoqPy6WC435a0688wONCIzTwKmhSvcmbRMS1T?= =?iso-8859-1?Q?HLq+f7loNxdNZQJ3rqwqqbN54524FBoS7+iHrlZp58tYi75kYG6Gd9Encz?= =?iso-8859-1?Q?oPhpf4BYVKNwG3paai9ifgYdUmVsI4nKeRce0asqZZEYJwpIk8LOFtKmpg?= =?iso-8859-1?Q?F4QEI8lPBtXUqFIAEudFqwPtbIrYuVvRJDCBR2wD1G37knlE6CtZlgaM1C?= =?iso-8859-1?Q?ACMspa9hN5c3I3wW9HAZnNxuq2M5vQ/ryXIQnxMTsnBeWeXIxmTLowcb2k?= =?iso-8859-1?Q?F9p+LBtvBAXbzsSf4K96fwUkfsbhO3eHET30drZnlugXZrLEPW3yw34PQp?= =?iso-8859-1?Q?raQJJ9o1iE+TQyhnAHiwHSEnywQEmXNf6jrMKhQP/r6uh4x2L8/ZilLeMD?= =?iso-8859-1?Q?hPqMjJPUArSFZFAfzxYS3qjwkiiBCXheN3p/mTDKtm8Z8oaJo8KXhmojuj?= =?iso-8859-1?Q?OYzyBmszWV8gZArlgg2u6EJpLGXoH1I45RE8s/UeTOP7MAJ2lJ2sRmbFfh?= =?iso-8859-1?Q?lQN7mjsQKNx8/KUomExIZy6K5TryO6Y1uJgNaeLKocYL2yGpJMiGQrANPh?= =?iso-8859-1?Q?eBPSb5OXwUEz7tq8uzhATNzD8dyazBSLNNwkzVRCUX9pynMJmZQH9RdsLZ?= =?iso-8859-1?Q?S7Lh6V+FhmP9GnExzhfQ5mfmJfUMRIkX4X8tC4eLCYkBGBnbI87f34hjyv?= =?iso-8859-1?Q?SoWO1N6L6F5ofmnLrmQJA6qtteQXuJuxSTyJtQ4NjsWntAysOVogvajfIV?= =?iso-8859-1?Q?0v+h+5u8KZmRb0LT3L9TO09LxiNzctZuggNmVLQFTuRhSrZdPMJhOKZz1G?= =?iso-8859-1?Q?e/iyykRqs/4e6cCKZHNvDgapA5PqkRZGvhZJVarupzYD/Jm8ZqWOfk0puT?= =?iso-8859-1?Q?VpoJXVAIA6quBLy9QJEfpGVBgpCprBAJ4Qm0bg0VmgBqTJMEKFGNz62F2b?= =?iso-8859-1?Q?GMX8GgB+BDnrIbejIb3HhMD8yBvDk9D8fG1Il4f67XY2GXxXu6R/J2Wyej?= =?iso-8859-1?Q?CIz04OahfRgboxOJeEuqyN/SDlTozerEI4PKkmnVhKxrUYMEWm8/f7AvKu?= =?iso-8859-1?Q?b8d1gr1aL/yC3M3C5mbGchFy1bYKZARzwu4j9oTfZnLnr84gHzH6IuuAd3?= =?iso-8859-1?Q?jpA6AHUZosotFTOOV2597m611rPCEEt92BLiLh0cE22u5SRYQrlw/rSnJa?= =?iso-8859-1?Q?u7unDurFTbDkfVPsbfG9MySI6d6rmkffrXOFZVOKUJ3pNA18ZQROtpFpen?= =?iso-8859-1?Q?9YTTCRhgI8lIrXUrnKEPdlp4DPWS3pDLveVRLExxIU2cyCJ?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1566; 6:gmtBqNvDwq0lKsjMtKnb+NmzpNhqx8dnyAIMooh+ZcjKwnRoZ2SnnuuqlnZHTSymcwuMAif39uwTYUfCTToSJDbjnswDNmXSqc7rFpoSCu+frSBD7u/S33Up5ZFJJ3uSqt/jf6kDLHnmsQoORdz/G8CQpyRsDHeSsa9xpJA/wAC3G9ztD08Mkmq+KY1xcAjdt9dTZvQi26W7Ay71dtvzg4Z+ZEqTV2NqUuizbzFj/cu8z8nn2YBJap2YjIOUNPq6m2ociyIqzEjtioTW9Z3UTuo5hN9m7cJCYC3WNiCnbsVeci+hiIiFmDMF8akbHuqQNBvBuzv6fnDpN/pSNt/HCcDuXvOdnz46Qeb1I8l6PGs=; 5:uEUVIixeeKvMeFqni7CqvYzHSJmFUUgrz59k/HrbfMUqfBCuKrzssUmx2IUxGNE1ajxXcYJaRuzFLRM5dtVtrAX3hrI2j+uWobqoS3hdjQ1Rc+Oo7nh2J1UFFsyLOD4eZZktHY4l9eAHZBDG+B+ypL8vDt0KsGQaVBMVWnOUfaQ=; 24:A9JTsJ5LkjRryA9Ffeb4ApwZFjsMQKrft95wcYgB5fpzF/zgUW+yWDsm+Df6ecVP8RhCV4rP4feho1TmTMzv3fLb/LwtOTpMRTZEQtBVjo0=; 7:Z0VGLENHFJGNF4AGMTjeZwhTbYfdTlYAUr+POvpcOcGuLdd48MC1D4LY0YoJ7mR7YBTS3jk+wBhdGg6c8t5BdYKd/ScsAkf9I/16M4szv+KCXgAG5B7HlkfzEDW8/V1LgJqOOOaXRHED89cnDYJmRhiq1YqwbQJGkDq+rcJA0dU5J0lj889FFUovP5ARX1vqEZz7S5LGBlz8yKtjPcUggtSGuJ+ZlTX72D6tSeCR9HZli8aYT6sa2JiVn2v6kE+B SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2018 12:34:08.8928 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f411c283-7768-48ca-69a5-08d558ef9cec X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1566 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 12:34:15 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Wednesday, January 10, 2018 4:36 PM > On Tue, Jan 09, 2018 at 09:08:24PM +0100, Martin Bjorklund wrote: > > Hi Tom, > > > > "tom p." wrote: > > > Much of this I-D is about the idea that network management data objects > > > can often take two different values. The I-D always refers to this as > > > being two values but is that a limit that this architecture imposes; or > > > can it be more? > > > > The I-D talks about two instantiations in the Objectives section, when > > the original "config vs oper values" problem is explained, and how > > NMDA solves the problem. > > > > But the archtecture allows for any number of instantiations; it all > > depends on which datastores a particular server implements. For > > example, a config node might have one value in , a > > different in and yet a different value in . This > > is not new to this document. > > > > Right. Lets see there "two" is used: > > - 1st paragraph in 2. Objectives: I think the text is clear since it > talks about a concrete example of a configured value and an > operationally used value. > > - 2nd paragraph in 2. Objectives: This text talks about two separate > branches in the old models, this should be fine. > > - 4th paragraph in 2. Objectives: I think this is potentially > causing the confusion. It says: > > With the revised architectural model of datastores defined in this > document, the data objects are defined only once in the YANG schema > but independent instantiations can appear in two different > datastores, one for configured values and one for operational state > values. > > Perhaps a better wording would be this: > > With the revised architectural model of datastores defined in this > document, the data objects are defined only once in the YANG > schema but independent instantiations can appear in different > datastores, e.g., for a configured value and one for an > operationally used value. > > This e.g. then kind of continues the example the section started > with. Would this change have avoided the question? Juergen Yes, I would find that clearer. Perhaps even better OLD e.g., for a configured value and one for an operationally used value. NEW e.g., one for a configured value and one (another?) for an operationally used value. I would say 'one' and 'another' but 'one' and 'one' would be clear enough. Tom Petch > /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 Jan 11 04:58: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 180BB12EB2F; Thu, 11 Jan 2018 04:58:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 o8KjcxpvOU8M; Thu, 11 Jan 2018 04:58:41 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79B612DA6A; Thu, 11 Jan 2018 04:58:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 88A896AC; Thu, 11 Jan 2018 13:58:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EnT3fYI9uD8Y; Thu, 11 Jan 2018 13:58:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 13:58:39 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 688472013E; Thu, 11 Jan 2018 13:58:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AqFjB8toDtRj; Thu, 11 Jan 2018 13:58:39 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE1B92013D; Thu, 11 Jan 2018 13:58:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CE11D420C3BE; Thu, 11 Jan 2018 13:58:37 +0100 (CET) Date: Thu, 11 Jan 2018 13:58:37 +0100 From: Juergen Schoenwaelder To: "tom p." Cc: ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org Message-ID: <20180111125837.vc6jvjpcbqpmexd2@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "tom p." , ietf@ietf.org, netmod-chairs@ietf.org, bclaise@cisco.com, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> <20180109.210824.760424986407969599.mbj@tail-f.com> <20180110163653.fjfbmr3gbnue52pq@elstar.local> <038f01d38ad8$59860240$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <038f01d38ad8$59860240$4001a8c0@gateway.2wire.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 12:58:51 -0000 On Thu, Jan 11, 2018 at 12:32:29PM -0000, tom p. wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Wednesday, January 10, 2018 4:36 PM > > > Right. Lets see there "two" is used: > > > > - 1st paragraph in 2. Objectives: I think the text is clear since it > > talks about a concrete example of a configured value and an > > operationally used value. > > > > - 2nd paragraph in 2. Objectives: This text talks about two separate > > branches in the old models, this should be fine. > > > > - 4th paragraph in 2. Objectives: I think this is potentially > > causing the confusion. It says: > > > > With the revised architectural model of datastores defined in this > > document, the data objects are defined only once in the YANG > schema > > but independent instantiations can appear in two different > > datastores, one for configured values and one for operational > state > > values. > > > > Perhaps a better wording would be this: > > > > With the revised architectural model of datastores defined in this > > document, the data objects are defined only once in the YANG > > schema but independent instantiations can appear in different > > datastores, e.g., for a configured value and one for an > > operationally used value. > > > > This e.g. then kind of continues the example the section started > > with. Would this change have avoided the question? > > Juergen > > Yes, I would find that clearer. Perhaps even better > > OLD > e.g., for a configured value and one for an > operationally used value. > NEW > e.g., one for a configured value and one (another?) for an > operationally used value. > > I would say 'one' and 'another' but 'one' and 'one' would be clear > enough. > I now have this: With the revised architectural model of datastores defined in this document, the data objects are defined only once in the YANG schema but independent instantiations can appear in different datastores, e.g., one for a configured value and another for an operationally used value. OK? /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 Jan 11 05:47: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 E17AB12EB2F for ; Thu, 11 Jan 2018 05:47:10 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 po1PWsssQ_En for ; Thu, 11 Jan 2018 05:47:07 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9C12EADE for ; Thu, 11 Jan 2018 05:47:07 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 75B451AE00B6; Thu, 11 Jan 2018 14:47:06 +0100 (CET) Date: Thu, 11 Jan 2018 14:47:05 +0100 (CET) Message-Id: <20180111.144705.493071366326080006.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180110.144453.957272588242505523.mbj@tail-f.com> References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 13:47:11 -0000 SGksDQoNClRvIHN1bW1hcml6ZSB0aGlzLCBJIHRoaW5rIHdlIGhhdmUgdGhyZWUgb3B0aW9ucyBm b3IgdGhlIHRocmVlIG5vZGVzDQonbW9kZWwtbmFtZScsICdtZmctbmFtZScsIGFuZCAnc2VyaWFs LW51bSc6DQoNCiAgMS4gIERvIG5vdGhpbmcgKGtlZXAgdGhlIG5vZGVzIGFzIGNvbmZpZyB0cnVl KS4NCg0KICAyLiAgTWFrZSB0aGVzZSB0aHJlZSBub2RlcyBjb25maWcgZmFsc2UgKGZhaXJseSBz aW1wbGUgY2hhbmdlKS4NCiAgICAgICh2ZW5kb3JzIGNhbiBhdWdtZW50IHcvIHRoZWlyIG93biBj b25maWcgdHJ1ZSBub2RlcykuDQoNCiAgMy4gIEFkZCB0aHJlZSBuZXcgbm9kZXMgZm9yIHRoZSBj b25maWd1cmVkIHZhbHVlcy4NCg0KDQpBZnRlciB0aGlua2luZyBhYm91dCB0aGlzIHNvbWUgbW9y ZSwgYW5kIGRpc2N1c3Npbmcgd2l0aCBCZW5vaXQsIEkNCnRoaW5rIHRoZSBiZXN0IHBhdGggZm9y d2FyZCBpcyB0byBkbyAyLCBpLmUuLCBtYXJrIHRoZSBub2Rlcw0KJ21vZGVsLW5hbWUnLCAnbWZn LW5hbWUnLCBhbmQgJ3NlcmlhbC1udW0nIGFzICJjb25maWcgZmFsc2UiLiAgQXMgc3VjaA0KdGhl eSB3b3VsZCBub3QgYmUgY29uZmlndXJhYmxlLCBhbmQgdGh1cyBjb250YWluIHRoZSBkZXRlY3Rl ZCB2YWx1ZXMuDQpJZiBubyB2YWx1ZSBpcyBkZXRlY3RlZCwgdGhlIG5vZGUgaXMgbm90IHByZXNl bnQuDQoNCk5vdGUgdGhhdCAxIG9yIDMgY2FuIGJlIGRvbmUgaW4gYSBmdXR1cmUgdXBkYXRlIHRv IHRoaXMgbW9kdWxlIChvciBieQ0KYSB2ZW5kb3IpLg0KDQoNCi9tYXJ0aW4NCg0KDQpNYXJ0aW4g QmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gIkJvZ2FlcnQs IEJhcnQgKE5va2lhIC0gQkUvQW50d2VycCkiIDxiYXJ0LmJvZ2FlcnRAbm9raWEuY29tPiB3cm90 ZToNCj4gPiBIaSwNCj4gPiANCj4gPiAtLS0gc25pcCAtLS0NCj4gPiANCj4gPiA+IHN0YXRlLuKA nSwgc28gdGhlIGFib3ZlIHNlbnRlbmNlIG9ubHkgYXBwbGllcyBmb3IgdGhlIHNlY29uZCBjYXNl IGJlbG93Lg0KPiA+IA0KPiA+IE9rLg0KPiA+IA0KPiA+ID4gMi4gVGhlIHNlY29uZCBjYXNlIGlz IHRoYXQgc29tZXRoaW5nIGlzIGRldGVjdGVkIGJ1dCBpdCBjYW7igJl0IGJlIHJlYWQuDQo+ID4g PiBXZSBkbyBub3Qgc2VlIGEgcmVhc29uIHRvIHVzZSB0aGUgdmFsdWUgY29uZmlndXJlZCBmb3Ig dGhlIGxlYWZzIA0KPiA+ID4g4oCYc2VyaWFsLW51beKAmSwg4oCYbWZnLW5hbWXigJkgYW5kIOKA mG1vZGVsLW5hbWXigJkgb2YgYSBtYXRjaGluZyBlbnRyeSBpbiB0aGUgDQo+ID4gPiBjb25maWd1 cmF0aW9uIGRhdGEuICBUaGVzZSBsZWFmcyBhcmUgZGVmaW5lZCBhcyBvcHRpb25hbCBzbyB3aHkg d291bGQgDQo+ID4gPiB3ZSByZXBvcnQgc29tZXRoaW5nIGVudGVyZWQgYnkgYW4gb3BlcmF0b3Ig aW4gdGhlIG9wZXJhdGlvbmFsIA0KPiA+ID4gZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byByZXBv cnQgb24gd2hhdCBpcyBkZXRlY3RlZD8gIElzIGl0IG5vdCANCj4gPiA+IGJldHRlciB0byBub3Qg cmVwb3J0IHRoZW0gYXQgYWxsPyAgSW4gYW4gTk1EQSBjb250ZXh0IGl0IHdvdWxkIGJlIA0KPiA+ ID4gcG9zc2libGUgdG8gaGF2ZSBhIGRpZmZlcmVudCB2YWx1ZSAob3Igbm8gdmFsdWUgYXQgYWxs KSBmb3IgY2VydGFpbiANCj4gPiA+IGxlYWZzIHdoaWxlIHRoZXJlIGlzIHNvbWV0aGluZyBpbiB0 aGUgcnVubmluZy9pbnRlbmRlZCBkYXRhc3RvcmUuDQo+ID4gDQo+ID4gVGhlIG5vcm1hbCBOTURB IHByb2NlZHVyZSBmb3IgYSBjb25maWd1cmF0aW9uIGxlYWYgaXMgdG8gcmVwZWF0IGl0IGluDQo+ ID4gb3BlcmF0aW9uYWwgc3RhdGUuICBUaGlzIGlzIHRoZW4gdGhlICJhcHBsaWVkIGNvbmZpZ3Vy YXRpb24iLg0KPiA+IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzcGVjaWFsIHJ1bGUg Zm9yIHRoZXNlIGxlYWZzLg0KPiA+IA0KPiA+IFRoaXMgYWxzbyBtZWFucyB0aGF0IGEgY2xpZW50 IHRoYXQganVzdCB3YW50cyB0byByZWFkIGFsbCB0aGUgc2VyaWFsDQo+ID4gbnVtYmVycyBjYW4g ZG8gc28gZnJvbSBvbmUgcGxhY2UsIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgcmVnYXJkbGVzcyBv Zg0KPiA+IGhvdyB0aGV5IGNhbWUgaW50byBleGlzdGFuY2UuDQo+ID4gDQo+ID4gW0JvZ2FlcnQs IEJhcnQgXSANCj4gPiANCj4gPiBXZSBkbyB1bmRlcnN0YW5kIHRoYXQgYSB0YXJnZXQgb2YgTk1E QSBpcyB0byByZWFkIG91dCB0aGUgYWN0dWFsbHkNCj4gPiBhcHBsaWVkIGRhdGEgaW4gb25lIHJl cXVlc3QuICBCdXQgdGhlIHJlc3VsdCBzaG91bGQgbm90IGJlDQo+ID4gY29uZnVzaW9uLiBBIGtl eSB3b3JkIGlzIOKAnGFwcGxpZWTigJ0uDQo+ID4gDQo+ID4gU2VjdGlvbiA1LjMgb2YgZHJhZnQt aWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTA5IGFsc28gY29udGFpbnMNCj4gPiAoSSBw dXQgYSBwYXJ0IG9mIHRoZSBzZWN0aW9uIGJldHdlZW4gKioqKToNCj4gPiBUaGUgZGF0YXN0b3Jl IHNjaGVtYSBmb3IgPG9wZXJhdGlvbmFsPiBNVVNUIGJlIGEgc3VwZXJzZXQgb2YgdGhlDQo+ID4g Y29tYmluZWQgZGF0YXN0b3JlIHNjaGVtYSB1c2VkIGluIGFsbCBjb25maWd1cmF0aW9uIGRhdGFz dG9yZXMgZXhjZXB0DQo+ID4gdGhhdCBjb25maWd1cmF0aW9uIGRhdGEgbm9kZXMgc3VwcG9ydGVk IGluIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUNCj4gPiAqKipNQVkgYmUgb21pdHRlZCBmcm9t IDxvcGVyYXRpb25hbD4gaWYgYSBzZXJ2ZXIgaXMgbm90IGFibGUgdG8NCj4gPiBhY2N1cmF0ZWx5 IHJlcG9ydCB0aGVtICoqKi4NCj4gDQo+IE5vdGUgdGhhdCB0aGlzIHRleHQgdGFsa3MgYWJvdXQg dGhlICpzY2hlbWEqLiAgSXQgaXMgaW50ZW5kZWQgZm9yDQo+IHNlcnZlcnMgdG8gbWlncmF0ZSB0 byBOTURBIHdpdGhvdXQgaGF2aW5nIHRvIGluc3RydW1lbnQgYWxsIGNvbmZpZw0KPiBub2RlcyBp biA8b3BlcmF0aW9uYWw+IGltbWVkaWF0ZWx5LiAgSWYgeW91IGFwcGx5IHRoaXMgdG8NCj4gaWV0 Zi1oYXJkd2FyZSwgaXQgY291bGQgYmUgYSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHRoZSBub2Rl DQo+ICJzZXJpYWwtbnVtIiBpbiBjb25maWcsIGJ1dCBub3QgaW4gPG9wZXJhdGlvbmFsPiAod2hp Y2ggd291bGQgYmUNCj4gd2VpcmQpLg0KPiANCj4gPiBGb3IgZXhhbXBsZSwgaXQgaXMgZXhwZWN0 ZWQgdGhhdCB0aGUgdmFsdWUgb2YgbXVsdGlwbGUgbGVhZnMgbmVlZCB0bw0KPiA+IGJlIGEgY29u c2lzdGVudCBzZXQsIGUuZy4gdGhlIG1mZy1uYW1lLCB0aGUgbW9kZWwtbmFtZSwgYW5kIHRoZQ0K PiA+IHNlcmlhbC1udW0uDQo+ID4gU3VwcG9zZSB3ZSBoYXZlIGEgdXNlIGNhc2UgaW4gd2hpY2gg YSBoYXJkd2FyZSBjb21wb25lbnQgaXMNCj4gPiBwbGFubmVkL2NvbmZpZ3VyZWQgKGUuZy4gYSBi b2FyZCBzdXBwb3J0aW5nIERTTCBpbnRlcmZhY2VzKSBidXQgYQ0KPiA+IGRpZmZlcmVudCBvbmUg aXMgcGx1Z2dlZCAoZS5nLiBhIGJvYXJkIHN1cHBvcnRpbmcgZXRoZXJuZXQNCj4gPiBpbnRlcmZh Y2VzKS4NCj4gPiBTdXBwb3NlIGl0IGlzIHBvc3NpYmxlIHRvIHJlYWQgc29tZSBmaWVsZHMgb24g dGhlIGRldGVjdGVkIGNvbXBvbmVudA0KPiA+IGJ1dCBkdWUgdG8gYW4gaXNzdWUgbm90IHRvIHJl YWQgb3RoZXIgZmllbGRzLg0KPiA+IElmIGluIHRoYXQgY2FzZSB0aGUgb3BlcmF0aW9uYWwgZGF0 YXN0b3JlIHdpbGwgYmUgY29tcGxldGVkIHdpdGggdGhlDQo+ID4gZGF0YSB0YWtlbiBmcm9tIHRo ZSBydW5uaW5nIGRhdGFzdG9yZSwgdGhlbiB0aGUgcHJlc2VudGVkIHZpZXcgbWlnaHQNCj4gPiBi ZSBpbmNvbnNpc3RlbnQuDQo+IA0KPiBUaGlzIGlzIHRydWUgZm9yIG90aGVyIHNpbWlsYXIgbm9k ZXMgYXMgd2VsbCAtICJhc3NldC1pZCIgYW5kICJ1cmkiLg0KPiANCj4gPiBUaGUgcXVlc3Rpb24g aXMgYWxzbzogd2hhdCBkYXRhIGlzIGFwcGxpZWQ/IE91ciBhc3N1bXB0aW9uOiBpZiB0aGVyZQ0K PiA+IGlzIGEgbWlzbWF0Y2ggYmV0d2VlbiBkZXRlY3RlZCB2ZXJzdXMgY29uZmlndXJlZCBoYXJk d2FyZSwgdGhlbiB0aGUNCj4gPiBpbnRlcmZhY2Uvc2VydmljZSByZWxhdGVkIGRhdGEgdGhhdCBp cyBjb25maWd1cmVkIGNvbnNpc3RlbnRseSB3aXRoDQo+ID4gdGhlIHBsYW5uZWQgaGFyZHdhcmUg aXMgbm90IGFwcGxpZWQgb24gdGhlIG1pc21hdGNoaW5nDQo+ID4gaGFyZHdhcmUuIEkuZS4gdGhl IGRldGVjdGVkIGhhcmR3YXJlIGlzIG5vdCBicm91Z2h0IGluIHNlcnZpY2Ugc28gbm90DQo+ID4g 4oCYYXBwbGllZOKAmSwgdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBvbmx5IChhY2N1cmF0ZWx5 KSByZXBvcnRzIG9uIHdoYXQNCj4gPiBpcyBkZXRlY3RlZC4NCj4gDQo+IElmIHRoZXJlIGlzIGEg bWlzbWF0Y2ggYW5kIHRoZSBzZXJ2ZXIgZG9lc24ndCBhcHBseSB0aGUgY29uZmlndXJlZA0KPiB2 YWx1ZXMsIHRoZW4gb2J2aW91c2x5IHRoZSBjb25maWd1cmVkICdtZmctbmFtZScgZXRjIGFyZSBu b3QgY29waWVkIHRvDQo+IDxvcGVyYXRpb25hbD4uDQo+IA0KPiA+IFdlIGRvIG5vdCBzZWUgdGhp cyBhcyBhIHNwZWNpYWwgcnVsZSBmb3IgdGhpcyBkYXRhIGJ1dCByYXRoZXIgd291bGQNCj4gPiBh cHBseSBhIGdlbmVyYWwgcnVsZToNCj4gPiAtCWlmIHRoZXJlIGlzIGEg4oCYbWlzc2luZyByZXNv dXJjZeKAmSwgdGhlbiB0aGUgZGF0YSBpcyBub3QgcmVwb3J0ZWQgaW4gdGhlDQo+ID4gIAlvcGVy YXRpb25hbCBkYXRhc3RvcmUuDQo+ID4gLQlJZiB0aGUgc2VydmVyIGlzIG5vdCBhYmxlIHRvIHJl cG9ydCBhY2N1cmF0ZWx5LCB0aGVuIHRoZSBkYXRhIGlzDQo+ID4gIAlvbWl0dGVkIGZyb20gdGhl IG9wZXJhdGlvbmFsDQo+IA0KPiBJIHRoaW5rIHRoYXQgaWYgeW91IHdhbnQgY29tcGxldGUgc2Vw YXJhdGlvbiBiZXR3ZWVuIHRoZSB2YWx1ZXMgb2YNCj4gJ21mZy1uYW1lJywgJ21vZGVsLW5hbWUn LCBhbmQgJ3NlcmlhbC1udW0nIGluIGNvbmZpZ3VyYXRpb24gYW5kDQo+IG9wZXJhdGlvbmFsIHN0 YXRlLCB0aGVuIHRoZXNlIHNob3VsZCBiZSBtb2RlbGxlZCBhcyBzZXBhcmF0ZSBsZWFmcy4NCj4g V2Ugc2hvdWxkIGhhdmUgYSBjb25maWcgZmFsc2UgbGVhZiAnc2VyaWFsLW51bScgdGhhdCBvbmx5 IGNvbnRhaW5zIHRoZQ0KPiBkZXRlY3RlZCB2YWx1ZSAoaWYgZm91bmQpLCBhbmQgYSBjb25maWcg dHJ1ZSBsZWFmICdjb25maWctc2VyaWFsLW51bScNCj4gb3Igc29tZXRoaW5nLCB0aGF0IGNvbnRh aW5zIHRoZSBjb25maWd1cmVkIHNlcmlhbCBudW1iZXIuDQo+IA0KPiBCdXQgaWYgdGhpcyBpcyB0 aGUgY2FzZSwgSSB3b25kZXIgaWYgaXQgd291bGRuJ3QgYmUgYmV0dGVyIHRvIGxlYXZlDQo+IHN1 Y2ggYWRkaXRpb25hbCBjb25maWcgb2JqZWN0cyB0byB2ZW5kb3JzLCBhbmQgc2ltcGx5IG1ha2Ug dGhlc2UgdGhyZWUNCj4gbm9kZXMgY29uZmlnIGZhbHNlIGluIGlldGYtaGFyZHdhcmUuDQo+IA0K PiANCj4gL21hcnRpbg0KPiANCj4gPiANCj4gPiBSZWdhcmRzLCBCYXJ0DQo+ID4gDQo+ID4gL21h cnRpbg0KPiA+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBCZXN0IHJlZ2FyZHMsIEJhcnQNCj4gPiA+ IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IA0KPiA+ ID4gV2lsdG9uDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjEsIDIwMTcgNDoxNCBQ TQ0KPiA+ID4gVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsgbmV0bW9kQGll dGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWll dGYtbmV0bW9kLWVudGl0eS0wNg0KPiA+ID4gDQo+ID4gPiBIaSBNYXJ0aW4sDQo+ID4gPiANCj4g PiA+IA0KPiA+ID4gT24gMjEvMTIvMjAxNyAxMTozNywgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN Cj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IEkgbmVlZCBXRyBpbnB1dCBvbiB0aGlzIGlz c3VlLiAgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBoYW5kbGUgDQo+ID4gPiA+ICdzZXJpYWwtbnVt JywgJ21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJy4gIEkgdGhpbmsgdGhleSBzaG91bGQgYWxs IA0KPiA+ID4gPiBiZSB0cmVhdGVkIHRoZSBzYW1lLiAgQmFzZWQgb24gcHJldmlvdXMgV0cgZGlz Y3Vzc2lvbiAoc2VlIGUuZy4gdGhlIA0KPiA+ID4gPiBtYWlsIHRocmVhZCAiZHJhZnQtaWV0Zi1u ZXRtb2QtZW50aXR5IGlzc3VlICMxMyIpLCBJIHRoaW5rIHRoZXkgDQo+ID4gPiA+IHNob3VsZCBh bGwgYmUgY29uZmlndXJhYmxlLCBidXQgdGhlIGNvbmZpZ3VyZWQgdmFsdWUgaXMgb25seSB1c2Vk IGluIA0KPiA+ID4gPiBvcGVyYXRpb25hbCBzdGF0ZSBpZiB0aGUgc3lzdGVtIGNhbm5vdCByZWFk IGl0IGZyb20gdGhlIGhhcmR3YXJlLg0KPiA+ID4gSSB0aGluayB0aGF0IHRoaXMgYXBwcm9hY2gg aXMgcHJvYmFibHkgT0s6DQo+ID4gPiAgwqAtIFRoZSBjbGllbnQgY2FuIGFsd2F5cyBzZWUgdGhl IHJlYWwgdmFsdWUgaWYgaXQgaXMgYXZhaWxhYmxlLg0KPiA+ID4gIMKgLSBJZiBpdCBpcyBub3Qg YXZhaWxhYmxlIHRoZW4gdGhleSBjYW4gYXNzaWduIGEgdmFsdWUgdmlhICANCj4gPiA+IGNvbmZp Z3VyYXRpb24uDQo+ID4gPiANCj4gPiA+IEkgd2FzIGFsc28gY29uc2lkZXJpbmcgYW4gYWx0ZXJu YXRpdmUgYXBwcm9hY2ggb2YgaGF2aW5nIGEgc2VwYXJhdGUgDQo+ID4gPiBzZXQgb2YgY29uZmln IGZhbHNlIGxlYXZlcyBmb3IgdGhlICJidXJudCBpbiB2YWx1ZXMiLsKgIEFuZCB0aGVuIGhhdmlu Zw0KPiA+ID4gdGhlIGNvbmZpZ3VyYWJsZSBsZWF2ZXMgYWx3YXlzIG92ZXJyaWRlIHRoZSBkZWZh dWx0IG9wZXJhdGlvbmFsIA0KPiA+ID4gdmFsdWVzLiBFLmcuIHNpbWlsYXIgdG8gaG93IGFuIGlu dGVyZmFjZSBNQUMgYWRkcmVzcyB3b3VsZCBleHBlY3QgdG8gDQo+ID4gPiBiZSBoYW5kbGVkLg0K PiA+ID4gDQo+ID4gPiBCdXQgb25lIHNldCBvZiBsZWF2ZXMgaXMgcHJvYmFibHkgc3VmZmljaWVu dC4NCj4gPiA+IA0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gUm9iDQo+ID4gPiANCj4gPiA+IA0KPiA+ ID4gPg0KPiA+ID4gPiBTbyBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KPiA+ID4g Pg0KPiA+ID4gPiBPTEQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICBsZWFmIHNlcmlhbC1udW0g ew0KPiA+ID4gPiAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiA+ID4gICAgICAgICAgY29uZmln IGZhbHNlOw0KPiA+ID4gPiAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gPiAgICAgICAgICAg ICJUaGUgdmVuZG9yLXNwZWNpZmljIHNlcmlhbCBudW1iZXIgc3RyaW5nIGZvciB0aGUNCj4gPiA+ ID4gICAgICAgICAgICAgY29tcG9uZW50LiAgVGhlIHByZWZlcnJlZCB2YWx1ZSBpcyB0aGUgc2Vy aWFsIG51bWJlcg0KPiA+ID4gPiAgICAgICAgICAgICBzdHJpbmcgYWN0dWFsbHkgcHJpbnRlZCBv biB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4gPiA+ID4gICAgICAgICAgICAgcHJlc2VudCku IjsNCj4gPiA+ID4gICAgICAgICAgcmVmZXJlbmNlICJSRkMgNjkzMzogZW50UGh5c2ljYWxTZXJp YWxOdW0iOw0KPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPg0KPiA+ID4gPiBORVc6DQo+ID4gPiA+ DQo+ID4gPiA+ICAgICAgICBsZWFmIHNlcmlhbC1udW0gew0KPiA+ID4gPiAgICAgICAgICB0eXBl IHN0cmluZzsNCj4gPiA+ID4gICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiA+ID4gICAgICAgICAg ICAiVGhlIHZlbmRvci1zcGVjaWZpYyBzZXJpYWwgbnVtYmVyIHN0cmluZyBmb3IgdGhlDQo+ID4g PiA+ICAgICAgICAgICAgIGNvbXBvbmVudC4gIFRoZSBwcmVmZXJyZWQgdmFsdWUgaXMgdGhlIHNl cmlhbCBudW1iZXINCj4gPiA+ID4gICAgICAgICAgICAgc3RyaW5nIGFjdHVhbGx5IHByaW50ZWQg b24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmDQo+ID4gPiA+ICAgICAgICAgICAgIHByZXNlbnQp Lg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICBUaGlzIGxlYWYgY2FuIGJlIGNvbmZpZ3Vy ZWQuICBUaGVyZSBhcmUgdHdvIHVzZSBjYXNlcyBmb3INCj4gPiA+ID4gICAgICAgICAgICAgdGhp czsgYXMgYSAncG9zdC1pdCcgbm90ZSBpZiB0aGUgc2VydmVyIGNhbm5vdCBkZXRlcm1pbmUNCj4g PiA+ID4gICAgICAgICAgICAgdGhpcyB2YWx1ZSBmcm9tIHRoZSBjb21wb25lbnQsIG9yIHdoZW4g cHJlLXByb3Zpc2lvbmluZyBhDQo+ID4gPiA+ICAgICAgICAgICAgIGNvbXBvbmVudC4NCj4gPiA+ ID4NCj4gPiA+ID4gICAgICAgICAgICAgSWYgdGhlIHNlcnZlciBjYW4gZGV0ZXJtaW5lIHRoZSBz ZXJpYWwgbnVtYmVyIGZyb20gdGhlDQo+ID4gPiA+ICAgICAgICAgICAgIGNvbXBvbmVudCwgdGhl biB0aGF0IHZhbHVlIGlzIGFsd2F5cyB1c2VkIGluIG9wZXJhdGlvbmFsDQo+ID4gPiA+ICAgICAg ICAgICAgIHN0YXRlLCBldmVuIGlmIGFub3RoZXIgdmFsdWUgaGFzIGJlZW4gY29uZmlndXJlZC4i Ow0KPiA+ID4gPiAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzOiBlbnRQaHlzaWNhbFNlcmlh bE51bSI7DQo+ID4gPiA+ICAgICAgICB9DQo+ID4gPiA+DQo+ID4gPiA+IEFuZCBjb3JyZXNwb25k aW5nIHRleHQgZm9yICdtZmctbmFtZScgYW5kICdtb2RlbC1uYW1lJy4NCj4gPiA+ID4NCj4gPiA+ ID4gQW5kIGFsc286DQo+ID4gPiA+DQo+ID4gPiA+IE9MRDoNCj4gPiA+ID4NCj4gPiA+ID4gICAg ICAgICAgIFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGEgbmV3IGhhcmR3YXJlIGNvbXBvbmVudCwg aXQNCj4gPiA+ID4gICAgICAgICAgIGluaXRpYWxpemVzIGEgbGlzdCBlbnRyeSBpbiB0aGUgb3Bl cmF0aW9uYWwgc3RhdGUuDQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICBJZiB0aGUgc2VydmVy IGRvZXMgbm90IHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBoYXJkd2FyZQ0KPiA+ID4gPiAgICAg ICAgICAgY29tcG9uZW50cywgbGlzdCBlbnRyaWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBh cmUNCj4gPiA+ID4gICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9k ZXMgYXMgZGV0ZWN0ZWQgYnkgdGhlDQo+ID4gPiA+ICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi4N Cj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9j ZWR1cmUgaXMgZm9sbG93ZWQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAgIDEuIElmIHRo ZXJlIGlzIGFuIGVudHJ5IGluIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50IGxpc3QgaW4NCj4gPiA+ ID4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gd2l0aCB2YWx1ZXMg Zm9yIHRoZSBub2Rlcw0KPiA+ID4gPiAgICAgICAgICAgICAgICAnY2xhc3MnLCAncGFyZW50Jywg J3BhcmVudC1yZWwtcG9zJyB0aGF0IGFyZSBlcXVhbCB0bw0KPiA+ID4gPiAgICAgICAgICAgICAg ICB0aGUgZGV0ZWN0ZWQgdmFsdWVzLCB0aGVuOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAg ICAxYS4gSWYgdGhlIGNvbmZpZ3VyZWQgZW50cnkgaGFzIGEgdmFsdWUgZm9yICdtZmctbmFtZScN Cj4gPiA+ID4gICAgICAgICAgICAgICAgIHRoYXQgaXMgZXF1YWwgdG8gdGhlIGRldGVjdGVkIHZh bHVlLCBvciBpZiB0aGUNCj4gPiA+ID4gICAgICAgICAgICAgICAgICdtZmctbmFtZScgdmFsdWUg Y2Fubm90IGJlIGRldGVjdGVkLCB0aGVuIHRoZSBsaXN0DQo+ID4gPiA+ICAgICAgICAgICAgICAg ICBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUN Cj4gPiA+ID4gICAgICAgICAgICAgICAgIGNvbmZpZ3VyZWQgdmFsdWVzIGZvciBhbGwgY29uZmln dXJlZCBub2RlcywgaW5jbHVkaW5nDQo+ID4gPiA+ICAgICAgICAgICAgICAgICB0aGUgJ25hbWUn Lg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgbGlzdCBl bnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiA+ID4gICAgICAgICAgICAgICAg IGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4g PiA+ID4gICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4gIFRoZSBpbXBsZW1lbnRh dGlvbiBtYXkgcmFpc2UgYW4NCj4gPiA+ID4gICAgICAgICAgICAgICAgIGFsYXJtIHRoYXQgaW5m b3JtcyBhYm91dCB0aGUgJ21mZy1uYW1lJyBtaXNtYXRjaA0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgY29uZGl0aW9uLiAgSG93IHRoaXMgaXMgZG9uZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZg0K PiA+ID4gPiAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudC4NCj4gPiA+ID4NCj4gPiA+ID4g ICAgICAgICAgICAgMWIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUgaXMgbm8gbWF0Y2hpbmcgY29u ZmlndXJhdGlvbg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgZW50cnkpLCB0aGUgbGlzdCBlbnRy eSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiA+ID4gICAgICAgICAgICAgICAgIGlu aXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4gPiA+ ID4gICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4g ICAgICAgICAgIElmIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50IGxpc3QgaW4gdGhlIGludGVuZGVk DQo+ID4gPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1vZGlmaWVkLCB0aGVuIHRoZSBz eXN0ZW0gTVVTVCBiZWhhdmUgYXMgaWYNCj4gPiA+ID4gICAgICAgICAgIGl0IHJlLWluaXRpYWxp emVzIGl0c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGluIA0KPiA+ID4gPiAoMSkuIjsN Cj4gPiA+ID4NCj4gPiA+ID4gTkVXOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgV2hlbiB0 aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9uZW50LCBpdA0KPiA+ID4gPiAg ICAgICAgICAgaW5pdGlhbGl6ZXMgYSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0 ZS4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3Vw cG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gPiA+ICAgICAgICAgICBjb21wb25l bnRzLCBsaXN0IGVudHJpZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGFyZQ0KPiA+ID4gPiAg ICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBub2RlcyBhcyBkZXRlY3Rl ZCBieSB0aGUNCj4gPiA+ID4gICAgICAgICAgIGltcGxlbWVudGF0aW9uLg0KPiA+ID4gPg0KPiA+ ID4gPiAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5nIHByb2NlZHVyZSBpcyBmb2xs b3dlZDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgMS4gSWYgdGhlcmUgaXMgYW4gZW50 cnkgaW4gdGhlIC9oYXJkd2FyZS9jb21wb25lbnQgbGlzdCBpbg0KPiA+ID4gPiAgICAgICAgICAg ICAgICB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiB3aXRoIHZhbHVlcyBmb3IgdGhlIG5vZGVz DQo+ID4gPiA+ICAgICAgICAgICAgICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFyZW50LXJlbC1w b3MnIHRoYXQgYXJlIGVxdWFsIHRvDQo+ID4gPiA+ICAgICAgICAgICAgICAgIHRoZSBkZXRlY3Rl ZCB2YWx1ZXMsIHRoZW4gdGhlIGxpc3QgZW50cnkgaW4gb3BlcmF0aW9uYWwNCj4gPiA+ID4gICAg ICAgICAgICAgICAgc3RhdGUgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUgY29uZmlndXJlZCB2YWx1 ZXMsDQo+ID4gPiA+ICAgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgJ25hbWUnLiAgVGhlIGxl YWZzICdzZXJpYWwtbnVtJywNCj4gPiA+ID4gICAgICAgICAgICAgICAgJ21mZy1uYW1lJywgYW5k ICdtb2RlbC1uYW1lJyBhcmUgdHJlYXRlZCBzcGVjaWFsbHk7IHNlZQ0KPiA+ID4gPiAgICAgICAg ICAgICAgICB0aGVpciBkZXNjcmlwdGlvbnMgZm9yIGRldGFpbHMuDQo+ID4gPiA+DQo+ID4gPiA+ ICAgICAgICAgICAgIDIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUgaXMgbm8gbWF0Y2hpbmcgY29u ZmlndXJhdGlvbg0KPiA+ID4gPiAgICAgICAgICAgICAgICBlbnRyeSksIHRoZSBsaXN0IGVudHJ5 IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcw0KPiA+ID4gPiAgICAgICAgICAgICAgICBpbml0 aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRldGVjdGVkIGJ5DQo+ID4gPiA+ ICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gICAg ICAgICAgIElmIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50IGxpc3QgaW4gdGhlIGludGVuZGVkDQo+ ID4gPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1vZGlmaWVkLCB0aGVuIHRoZSBzeXN0 ZW0gTVVTVCBiZWhhdmUgYXMgaWYNCj4gPiA+ID4gICAgICAgICAgIGl0IHJlLWluaXRpYWxpemVz IGl0c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGluIA0KPiA+ID4gPiAoMSkuIjsNCj4g PiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gL21hcnRpbg0KPiA+ID4gPg0KPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2Nv LmNvbT4gd3JvdGU6DQo+ID4gPiA+PiBPbiAxMi8yMC8yMDE3IDQ6MDAgUE0sIE1hcnRpbiBCam9y a2x1bmQgd3JvdGU6DQo+ID4gPiA+Pj4gQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+ IHdyb3RlOg0KPiA+ID4gPj4+PiBIaSBNYXJ0aW4sDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IFRo YW5rcy4NCj4gPiA+ID4+Pj4gT25seSBrZXB0IHRoZSByZWxldmFudCBleGNlcnB0cy4NCj4gPiA+ ID4+Pj4+PiAtIFNvbWUgb2JqZWN0cyBhcmUgcmVhZC13cml0ZSBpbiBSRkM2OTMzOg0KPiA+ID4g Pj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsU2VyaWFsTnVtDQo+ID4gPiA+Pj4+Pj4gICAgICAg ICAgZW50UGh5c2ljYWxBbGlhcw0KPiA+ID4gPj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsQXNz ZXRJRA0KPiA+ID4gPj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsVXJpcw0KPiA+ID4gPj4+Pj4+ DQo+ID4gPiA+Pj4+Pj4gRm9yIGV4YW1wbGUsIGVudFBoeXNpY2FsU2VyaWFsTnVtIGJlaW5nIHJl YWQtd3JpdGUgYWx3YXlzIGJvdGhlcmVkDQo+ID4gPiA+Pj4+Pj4gbWUuDQo+ID4gPiA+Pj4+Pj4g c2VyaWFsLW51bSBpcyBub3cgImNvbmZpZyBmYWxzZSIsIHdoaWNoIGlzIGEgZ29vZCBuZXdzIElN Ty4NCj4gPiA+ID4+Pj4+IEFjdHVhbGx5LCB0aGlzIHdhcyBub3QgdGhlIGludGVudGlvbi4gIElu DQo+ID4gPiA+Pj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDMgdGhpcyBpcyBjb25maWd1 cmFibGUuICBJIG1pc3NlZCB0aGlzIA0KPiA+ID4gPj4+Pj4gaW4gdGhlIGNvbnZlcnNpb24gdG8g Tk1EQS4NCj4gPiA+ID4+Pj4gQWguIFNvIG5vIGdvb2QgbmV3cyBpbiB0aGlzIGNhc2UuLi4NCj4g PiA+ID4+Pj4+PiBJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGVudFBoeXNpY2FsTWZnTmFtZSBp cyByZWFkLW9ubHkgaW4gDQo+ID4gPiA+Pj4+Pj4gUkZDNjkzMywgd2hpbGUgaXQncyAiY29uZmln IHRydWUiIGluIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eQ0KPiA+ID4gPj4+Pj4gWWVzLCB0aGlz IHdhcyBhZGRlZCBwZXIgcmVxdWVzdCBmcm9tIHRoZSBXRy4gIFNlZSBlLmcuIHRoZSANCj4gPiA+ ID4+Pj4+IHRocmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlzc3VlICMxMyIuDQo+ID4g PiA+Pj4+IFN1cmUuIEl0IHdhcyBtYWlubHkgYW4gb2JzZXJ2YXRpb24uDQo+ID4gPiA+Pj4+PiBI b3dldmVyLCBJIHRoaW5rIHRoYXQgd2hhdCB3ZSBoYXZlIG5vdyBpcyBwcm9iYWJseSBub3QgY29y cmVjdC4gIA0KPiA+ID4gPj4+Pj4gSSB0aGluayB0aGF0IGFsbCBub2RlcyAnc2VyaWFsLW51bScs ICdtZmctbmFtZScsIGFuZCAnbW9kZWwtbmFtZScNCj4gPiA+ID4+Pj4+IHNob3VsZCBiZSBjb25m aWcgdHJ1ZSwgYW5kIHRoZSBkZXNjcmlwdGlvbiBvZiBsaXN0ICdjb21wb25lbnQnIA0KPiA+ID4g Pj4+Pj4gdXBkYXRlZCB0byByZWZsZWN0IHRoYXQgYWxsIHRoZXNlIHRyZWUgbGVhZnMgYXJlIGhh bmRsZWQgdGhlIHNhbWUgd2F5Lg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEkgd291bGQgbGlr ZSB0byBrbm93IHdoYXQgdGhlIFdHIHRoaW5rcyBhYm91dCB0aGlzLg0KPiA+ID4gPj4+PiBUYWxr aW5nIGFzIGEgY29udHJpYnV0b3IgdGhpcyB0aW1lLg0KPiA+ID4gPj4+PiBJdCBzZWVtcyB0aGF0 IGludmVudG9yeSBtYW5hZ2VtZW50IGlzIGtpbmQgb2YgYnJva2VuIHdoZW4gc29tZW9uZSANCj4g PiA+ID4+Pj4gY2FuIGNoYW5nZSAnc2VyaWFsLW51bScsICdtZmctbmFtZScsIGFuZCAnbW9kZWwt bmFtZS4NCj4gPiA+ID4+PiBUaGV5IGNhbid0IHJlYWxseSBjaGFuZ2UgdGhlbS4gIFRoZSBjb25m aWd1cmVkIHZhbHVlcyBhcmUgb25seSANCj4gPiA+ID4+PiB1c2VkIChpLmUuIHZpc2libGUgaW4g dGhlIG9wZXJhdGlvbmFsIHN0YXRlKSBpZiB0aGUgZGV2aWNlIGNhbm5vdCANCj4gPiA+ID4+PiBk ZXRlY3QgdGhlbSBhdXRvbWF0aWNhbGx5LiAgSS5lLiwgdGhleSB3b3JrIGFzICJwb3N0LWl0IiBu b3RlcyBvbmx5Lg0KPiA+ID4gPj4gSWYgSSBsb29rIGF0LCBmb3IgZXhhbXBsZSwgdGhlIG1mZy1u YW1lLCBkZXNjcmlwdGlvbiwgdGhpcyBpcyBub3QgDQo+ID4gPiA+PiB3aGF0IGl0IHNheXMuDQo+ ID4gPiA+Pg0KPiA+ID4gPj4gICAgIGxlYWYgbWZnLW5hbWUgew0KPiA+ID4gPj4gICAgICAgICAg ICAgdHlwZSBzdHJpbmc7DQo+ID4gPiA+PiAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4g Pj4gICAgICAgICAgICAgICAiVGhlIG5hbWUgb2YgdGhlIG1hbnVmYWN0dXJlciBvZiB0aGlzIHBo eXNpY2FsIGNvbXBvbmVudC4NCj4gPiA+ID4+ICAgICAgICAgICAgICAgIFRoZSBwcmVmZXJyZWQg dmFsdWUgaXMgdGhlIG1hbnVmYWN0dXJlciBuYW1lIHN0cmluZw0KPiA+ID4gPj4gICAgICAgICAg ICAgICAgYWN0dWFsbHkgcHJpbnRlZCBvbiB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYgcHJlc2Vu dCkuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gICAgICAgICAgICAgICAgTm90ZSB0aGF0IGNvbXBhcmlz b25zIGJldHdlZW4gaW5zdGFuY2VzIG9mIHRoZSBtb2RlbC1uYW1lLA0KPiA+ID4gPj4gICAgICAg ICAgICAgICAgZmlybXdhcmUtcmV2LCBzb2Z0d2FyZS1yZXYsIGFuZCB0aGUgc2VyaWFsLW51bSBu b2RlcyBhcmUNCj4gPiA+ID4+ICAgICAgICAgICAgICAgIG9ubHkgbWVhbmluZ2Z1bCBhbW9uZ3N0 IGNvbXBvbmVudCB3aXRoIHRoZSBzYW1lIHZhbHVlIG9mDQo+ID4gPiA+PiAgICAgICAgICAgICAg ICBtZmctbmFtZS4NCj4gPiA+ID4+DQo+ID4gPiA+PiAgICAgICAgICAgICAgICBJZiB0aGUgbWFu dWZhY3R1cmVyIG5hbWUgc3RyaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4gPiA+ID4+ICAgICAg ICAgICAgICAgIHBoeXNpY2FsIGNvbXBvbmVudCBpcyB1bmtub3duIHRvIHRoZSBzZXJ2ZXIsIHRo ZW4gdGhpcw0KPiA+ID4gPj4gICAgICAgICAgICAgICAgbm9kZSBpcyBub3QgaW5zdGFudGlhdGVk LiI7DQo+ID4gPiA+PiAgICAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzIDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjkzMz46DQo+ID4gPiA+PiAgICAgICAgICAgICBlbnRQaHlz aWNhbE1mZ05hbWUiOw0KPiA+ID4gPj4NCj4gPiA+ID4+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+ID4g Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IC9tYXJ0aW4NCj4gPiA+ID4+PiAuDQo+ID4gPiA+Pj4N Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4g PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+ ID4gLg0KPiA+ID4gPg0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0 bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Thu Jan 11 05:58: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 3F0F012EB56 for ; Thu, 11 Jan 2018 05:58:13 -0800 (PST) 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_RP_MATCHES_RCVD=-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 8bAAmpBVTUL5 for ; Thu, 11 Jan 2018 05:58:11 -0800 (PST) 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 612C312EB50 for ; Thu, 11 Jan 2018 05:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16466; q=dns/txt; s=iport; t=1515679090; x=1516888690; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=00jn6A8+frSCqArO3vICfbqRboxwt2zvQqTpiSbtX8M=; b=CS31YRGeBDDB3OwIczH3VuRwyBedhGRF/3RLhauVXp9CsbrwplLaG9/v HyuZ0FYNEQMDK6xeR3+9JlR08Q+upDhGO1zjzosyB0RR8QRCc5NmtRkjo jYaHH2NrRlBKHMFFf8tZIzDEQ86lG9tm+76g44HT1tG2iSGd0OOGZVTYa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQDrbFda/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEB4sYj2x8lkiCAgoYC4FegmtPAoUAFAEBAQEBAQEBAWs?= =?us-ascii?q?ohSMBAQEEAQEhDwEFNgsMBAsOAwQBAQECAiMDAgInHwkIBgEMBgIBARYBihgQr?= =?us-ascii?q?zaCJ4o5AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4Mcg2yBaSmBd1g2gy8BAQI?= =?us-ascii?q?BgTYYAQEIgy2CZQWKY4dEkT2IC408ghiKCyaHRYpnglaBXogJgTw2IoFQMhoIG?= =?us-ascii?q?xU9giqEWEA3igOCPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,344,1511827200"; d="scan'208";a="1399894" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 13:57:47 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0BDvkVb023288; Thu, 11 Jan 2018 13:57:47 GMT To: Martin Bjorklund , bart.bogaert@nokia.com Cc: netmod@ietf.org References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> From: Benoit Claise Message-ID: <1b602a53-86ac-d4ee-690c-6fa6cbfa25cc@cisco.com> Date: Thu, 11 Jan 2018 14:57:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180111.144705.493071366326080006.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 13:58:13 -0000 Dear all, draft-ietf-netmod-entity is the IESG telechat today. In light of this discussion below, which I consider part of the IETF LC, I'll be deferring the document to the next IESG telechat in two weeks. You have a few days to provide feedback on this propose solution 2. Regards, Benoit (OPS AD). > Hi, > > To summarize this, I think we have three options for the three nodes > 'model-name', 'mfg-name', and 'serial-num': > > 1. Do nothing (keep the nodes as config true). > > 2. Make these three nodes config false (fairly simple change). > (vendors can augment w/ their own config true nodes). > > 3. Add three new nodes for the configured values. > > > After thinking about this some more, and discussing with Benoit, I > think the best path forward is to do 2, i.e., mark the nodes > 'model-name', 'mfg-name', and 'serial-num' as "config false". As such > they would not be configurable, and thus contain the detected values. > If no value is detected, the node is not present. > > Note that 1 or 3 can be done in a future update to this module (or by > a vendor). > > > /martin > > > Martin Bjorklund wrote: >> Hi, >> >> "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: >>> Hi, >>> >>> --- snip --- >>> >>>> state.”, so the above sentence only applies for the second case below. >>> Ok. >>> >>>> 2. The second case is that something is detected but it can’t be read. >>>> We do not see a reason to use the value configured for the leafs >>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the >>>> configuration data. These leafs are defined as optional so why would >>>> we report something entered by an operator in the operational >>>> datastore that intends to report on what is detected? Is it not >>>> better to not report them at all? In an NMDA context it would be >>>> possible to have a different value (or no value at all) for certain >>>> leafs while there is something in the running/intended datastore. >>> The normal NMDA procedure for a configuration leaf is to repeat it in >>> operational state. This is then the "applied configuration". >>> I don't think we should have a special rule for these leafs. >>> >>> This also means that a client that just wants to read all the serial >>> numbers can do so from one place, the operational state, regardless of >>> how they came into existance. >>> >>> [Bogaert, Bart ] >>> >>> We do understand that a target of NMDA is to read out the actually >>> applied data in one request. But the result should not be >>> confusion. A key word is “applied”. >>> >>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains >>> (I put a part of the section between ***): >>> The datastore schema for MUST be a superset of the >>> combined datastore schema used in all configuration datastores except >>> that configuration data nodes supported in a configuration datastore >>> ***MAY be omitted from if a server is not able to >>> accurately report them ***. >> Note that this text talks about the *schema*. It is intended for >> servers to migrate to NMDA without having to instrument all config >> nodes in immediately. If you apply this to >> ietf-hardware, it could be a server that implements the node >> "serial-num" in config, but not in (which would be >> weird). >> >>> For example, it is expected that the value of multiple leafs need to >>> be a consistent set, e.g. the mfg-name, the model-name, and the >>> serial-num. >>> Suppose we have a use case in which a hardware component is >>> planned/configured (e.g. a board supporting DSL interfaces) but a >>> different one is plugged (e.g. a board supporting ethernet >>> interfaces). >>> Suppose it is possible to read some fields on the detected component >>> but due to an issue not to read other fields. >>> If in that case the operational datastore will be completed with the >>> data taken from the running datastore, then the presented view might >>> be inconsistent. >> This is true for other similar nodes as well - "asset-id" and "uri". >> >>> The question is also: what data is applied? Our assumption: if there >>> is a mismatch between detected versus configured hardware, then the >>> interface/service related data that is configured consistently with >>> the planned hardware is not applied on the mismatching >>> hardware. I.e. the detected hardware is not brought in service so not >>> ‘applied’, the operational datastore only (accurately) reports on what >>> is detected. >> If there is a mismatch and the server doesn't apply the configured >> values, then obviously the configured 'mfg-name' etc are not copied to >> . >> >>> We do not see this as a special rule for this data but rather would >>> apply a general rule: >>> - if there is a ‘missing resource’, then the data is not reported in the >>> operational datastore. >>> - If the server is not able to report accurately, then the data is >>> omitted from the operational >> I think that if you want complete separation between the values of >> 'mfg-name', 'model-name', and 'serial-num' in configuration and >> operational state, then these should be modelled as separate leafs. >> We should have a config false leaf 'serial-num' that only contains the >> detected value (if found), and a config true leaf 'config-serial-num' >> or something, that contains the configured serial number. >> >> But if this is the case, I wonder if it wouldn't be better to leave >> such additional config objects to vendors, and simply make these three >> nodes config false in ietf-hardware. >> >> >> /martin >> >>> Regards, Bart >>> >>> /martin >>> >>> >>>> Best regards, Bart >>>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >>>> Wilton >>>> Sent: Thursday, December 21, 2017 4:14 PM >>>> To: Martin Bjorklund ; netmod@ietf.org >>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >>>> >>>> Hi Martin, >>>> >>>> >>>> On 21/12/2017 11:37, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> I need WG input on this issue. The question is how to handle >>>>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>>>> be treated the same. Based on previous WG discussion (see e.g. the >>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>>>> should all be configurable, but the configured value is only used in >>>>> operational state if the system cannot read it from the hardware. >>>> I think that this approach is probably OK: >>>>  - The client can always see the real value if it is available. >>>>  - If it is not available then they can assign a value via >>>> configuration. >>>> >>>> I was also considering an alternative approach of having a separate >>>> set of config false leaves for the "burnt in values".  And then having >>>> the configurable leaves always override the default operational >>>> values. E.g. similar to how an interface MAC address would expect to >>>> be handled. >>>> >>>> But one set of leaves is probably sufficient. >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>>> So I suggest the following changes: >>>>> >>>>> OLD: >>>>> >>>>> leaf serial-num { >>>>> type string; >>>>> config false; >>>>> description >>>>> "The vendor-specific serial number string for the >>>>> component. The preferred value is the serial number >>>>> string actually printed on the component itself (if >>>>> present)."; >>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>> } >>>>> >>>>> NEW: >>>>> >>>>> leaf serial-num { >>>>> type string; >>>>> description >>>>> "The vendor-specific serial number string for the >>>>> component. The preferred value is the serial number >>>>> string actually printed on the component itself (if >>>>> present). >>>>> >>>>> This leaf can be configured. There are two use cases for >>>>> this; as a 'post-it' note if the server cannot determine >>>>> this value from the component, or when pre-provisioning a >>>>> component. >>>>> >>>>> If the server can determine the serial number from the >>>>> component, then that value is always used in operational >>>>> state, even if another value has been configured."; >>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>> } >>>>> >>>>> And corresponding text for 'mfg-name' and 'model-name'. >>>>> >>>>> And also: >>>>> >>>>> OLD: >>>>> >>>>> When the server detects a new hardware component, it >>>>> initializes a list entry in the operational state. >>>>> >>>>> If the server does not support configuration of hardware >>>>> components, list entries in the operational state are >>>>> initialized with values for all nodes as detected by the >>>>> implementation. >>>>> >>>>> Otherwise, the following procedure is followed: >>>>> >>>>> 1. If there is an entry in the /hardware/component list in >>>>> the intended configuration with values for the nodes >>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>> the detected values, then: >>>>> >>>>> 1a. If the configured entry has a value for 'mfg-name' >>>>> that is equal to the detected value, or if the >>>>> 'mfg-name' value cannot be detected, then the list >>>>> entry in the operational state is initialized with the >>>>> configured values for all configured nodes, including >>>>> the 'name'. >>>>> >>>>> Otherwise, the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. The implementation may raise an >>>>> alarm that informs about the 'mfg-name' mismatch >>>>> condition. How this is done is outside the scope of >>>>> this document. >>>>> >>>>> 1b. Otherwise (i.e., there is no matching configuration >>>>> entry), the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. >>>>> >>>>> If the /hardware/component list in the intended >>>>> configuration is modified, then the system MUST behave as if >>>>> it re-initializes itself, and follow the procedure in >>>>> (1)."; >>>>> >>>>> NEW: >>>>> >>>>> When the server detects a new hardware component, it >>>>> initializes a list entry in the operational state. >>>>> >>>>> If the server does not support configuration of hardware >>>>> components, list entries in the operational state are >>>>> initialized with values for all nodes as detected by the >>>>> implementation. >>>>> >>>>> Otherwise, the following procedure is followed: >>>>> >>>>> 1. If there is an entry in the /hardware/component list in >>>>> the intended configuration with values for the nodes >>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>> the detected values, then the list entry in operational >>>>> state is initialized with the configured values, >>>>> including the 'name'. The leafs 'serial-num', >>>>> 'mfg-name', and 'model-name' are treated specially; see >>>>> their descriptions for details. >>>>> >>>>> 2. Otherwise (i.e., there is no matching configuration >>>>> entry), the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. >>>>> >>>>> If the /hardware/component list in the intended >>>>> configuration is modified, then the system MUST behave as if >>>>> it re-initializes itself, and follow the procedure in >>>>> (1)."; >>>>> >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>> >>>>> Benoit Claise wrote: >>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>>>> Benoit Claise wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Only kept the relevant excerpts. >>>>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>>>> entPhysicalSerialNum >>>>>>>>>> entPhysicalAlias >>>>>>>>>> entPhysicalAssetID >>>>>>>>>> entPhysicalUris >>>>>>>>>> >>>>>>>>>> For example, entPhysicalSerialNum being read-write always bothered >>>>>>>>>> me. >>>>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>>>> Actually, this was not the intention. In >>>>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>>>> in the conversion to NMDA. >>>>>>>> Ah. So no good news in this case... >>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>>>> Sure. It was mainly an observation. >>>>>>>>> However, I think that what we have now is probably not correct. >>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' >>>>>>>>> should be config true, and the description of list 'component' >>>>>>>>> updated to reflect that all these tree leafs are handled the same way. >>>>>>>>> >>>>>>>>> I would like to know what the WG thinks about this. >>>>>>>> Talking as a contributor this time. >>>>>>>> It seems that inventory management is kind of broken when someone >>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>>>> They can't really change them. The configured values are only >>>>>>> used (i.e. visible in the operational state) if the device cannot >>>>>>> detect them automatically. I.e., they work as "post-it" notes only. >>>>>> If I look at, for example, the mfg-name, description, this is not >>>>>> what it says. >>>>>> >>>>>> leaf mfg-name { >>>>>> type string; >>>>>> description >>>>>> "The name of the manufacturer of this physical component. >>>>>> The preferred value is the manufacturer name string >>>>>> actually printed on the component itself (if present). >>>>>> >>>>>> Note that comparisons between instances of the model-name, >>>>>> firmware-rev, software-rev, and the serial-num nodes are >>>>>> only meaningful amongst component with the same value of >>>>>> mfg-name. >>>>>> >>>>>> If the manufacturer name string associated with the >>>>>> physical component is unknown to the server, then this >>>>>> node is not instantiated."; >>>>>> reference "RFC 6933 : >>>>>> entPhysicalMfgName"; >>>>>> >>>>>> Regards, Benoit >>>>>> >>>>>>> /martin >>>>>>> . >>>>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 11 06:01: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 DFAB212EB59 for ; Thu, 11 Jan 2018 06:01:57 -0800 (PST) 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 zblb6Qiaa8Wz for ; Thu, 11 Jan 2018 06:01:53 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 C52D612EB5E for ; Thu, 11 Jan 2018 06:01:52 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id u42so1869858qte.7 for ; Thu, 11 Jan 2018 06:01:52 -0800 (PST) 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=w6QQkyw4nncwA4al5aFQoo49kmDWGFp+cwKMsXQqRBI=; b=QKB+GD04oKlEoatYNFRiSEAj+m1iQtFdmZWDxE8zud3xTqIi3wwT7vWgUhQnAbfrBk Dxx580XclRMjUuXdYomms5yCxUDwcR0/LeJl6vdsKqvJBKh03NuFQCHZO0FfNryX23jb qvg7WkQTPGY4+F49h7piMbis7IFyI8KRiS879l5OkA/X+OlmwM3/ySYTZO1ORx0joI05 o7XSEwPaQm4P5hWaVxePcWiyxFMvaLCxhidFtfeBKnbBZIAPAT7kyafwftjd19UA/TEL FLZn0xXuhhpbvyHBWVz1KyDLpMHopFayeJeKrJAGtqPGjV7DESsyNP0vcbVX2pdwqHck g0Jw== 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=w6QQkyw4nncwA4al5aFQoo49kmDWGFp+cwKMsXQqRBI=; b=k8gdLmYGguezN9tKImSD6Qz+gbSRWBedWpioP7OsbDvS006SNvF5wd5Y7pLNB5kN/Z qp0J8LxT7nUyIKb0Rs73DM+GRzibaFZdZcEU5yQniTvP5xaCktfj+8zlp7TfLoyz5i04 D6KI/3IcKEa0aBi+X2S8skGYCMj+ar4wcKq0aF/iLDxPZgXeptVzYL/v2Ik1f4ZsAq7M M7kixZU00pTXVujsaFn5tELPvVLfJb4wBq1OO0Cwy185koOpLwra2QQ8chumvKTbe0wV PvZadebtswtgMAt9MXkKZPMhCQbewl54TQI6eyM1ROW9mBGzxbyJCsPFAusv2LCzP+VD +Y+w== X-Gm-Message-State: AKwxytcx7pYl30s7a565wLMZ1SGF0OSkCYfVwCfPKzohCWNpKv7DduJh INznhWzG4Exmo++b1NhG0U/p+9nDmlPHvW4kX9o= X-Google-Smtp-Source: ACJfBovHnOniC6w4kcNUV4+hRJHiijo9T1VTNK/F+WBwq8/sMaFbNMsi277yfc7jqBFKZEuPJD4LofXJeT8w0YANvXc= X-Received: by 10.200.4.38 with SMTP id v38mr29822598qtg.69.1515679311799; Thu, 11 Jan 2018 06:01:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.106.166 with HTTP; Thu, 11 Jan 2018 06:01:51 -0800 (PST) In-Reply-To: <1b602a53-86ac-d4ee-690c-6fa6cbfa25cc@cisco.com> References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> <1b602a53-86ac-d4ee-690c-6fa6cbfa25cc@cisco.com> From: Dan Romascanu Date: Thu, 11 Jan 2018 16:01:51 +0200 Message-ID: To: Benoit Claise Cc: Martin Bjorklund , "Bogaert, Bart (Nokia - BE)" , NetMod WG Content-Type: multipart/alternative; boundary="f40304353634f930dc0562809656" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:01:58 -0000 --f40304353634f930dc0562809656 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Solution 2 seems fine to me at this stage. Regards, Dan On Thu, Jan 11, 2018 at 3:57 PM, Benoit Claise wrote: > Dear all, > > draft-ietf-netmod-entity is the IESG telechat today. > In light of this discussion below, which I consider part of the IETF LC, > I'll be deferring the document to the next IESG telechat in two weeks. > You have a few days to provide feedback on this propose solution 2. > > Regards, Benoit (OPS AD). > > Hi, >> >> To summarize this, I think we have three options for the three nodes >> 'model-name', 'mfg-name', and 'serial-num': >> >> 1. Do nothing (keep the nodes as config true). >> >> 2. Make these three nodes config false (fairly simple change). >> (vendors can augment w/ their own config true nodes). >> >> 3. Add three new nodes for the configured values. >> >> >> After thinking about this some more, and discussing with Benoit, I >> think the best path forward is to do 2, i.e., mark the nodes >> 'model-name', 'mfg-name', and 'serial-num' as "config false". As such >> they would not be configurable, and thus contain the detected values. >> If no value is detected, the node is not present. >> >> Note that 1 or 3 can be done in a future update to this module (or by >> a vendor). >> >> >> /martin >> >> >> Martin Bjorklund wrote: >> >>> Hi, >>> >>> "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: >>> >>>> Hi, >>>> >>>> --- snip --- >>>> >>>> state.=E2=80=9D, so the above sentence only applies for the second cas= e below. >>>>> >>>> Ok. >>>> >>>> 2. The second case is that something is detected but it can=E2=80=99t = be read. >>>>> We do not see a reason to use the value configured for the leafs >>>>> =E2=80=98serial-num=E2=80=99, =E2=80=98mfg-name=E2=80=99 and =E2=80= =98model-name=E2=80=99 of a matching entry in the >>>>> configuration data. These leafs are defined as optional so why would >>>>> we report something entered by an operator in the operational >>>>> datastore that intends to report on what is detected? Is it not >>>>> better to not report them at all? In an NMDA context it would be >>>>> possible to have a different value (or no value at all) for certain >>>>> leafs while there is something in the running/intended datastore. >>>>> >>>> The normal NMDA procedure for a configuration leaf is to repeat it in >>>> operational state. This is then the "applied configuration". >>>> I don't think we should have a special rule for these leafs. >>>> >>>> This also means that a client that just wants to read all the serial >>>> numbers can do so from one place, the operational state, regardless of >>>> how they came into existance. >>>> >>>> [Bogaert, Bart ] >>>> >>>> We do understand that a target of NMDA is to read out the actually >>>> applied data in one request. But the result should not be >>>> confusion. A key word is =E2=80=9Capplied=E2=80=9D. >>>> >>>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains >>>> (I put a part of the section between ***): >>>> The datastore schema for MUST be a superset of the >>>> combined datastore schema used in all configuration datastores except >>>> that configuration data nodes supported in a configuration datastore >>>> ***MAY be omitted from if a server is not able to >>>> accurately report them ***. >>>> >>> Note that this text talks about the *schema*. It is intended for >>> servers to migrate to NMDA without having to instrument all config >>> nodes in immediately. If you apply this to >>> ietf-hardware, it could be a server that implements the node >>> "serial-num" in config, but not in (which would be >>> weird). >>> >>> For example, it is expected that the value of multiple leafs need to >>>> be a consistent set, e.g. the mfg-name, the model-name, and the >>>> serial-num. >>>> Suppose we have a use case in which a hardware component is >>>> planned/configured (e.g. a board supporting DSL interfaces) but a >>>> different one is plugged (e.g. a board supporting ethernet >>>> interfaces). >>>> Suppose it is possible to read some fields on the detected component >>>> but due to an issue not to read other fields. >>>> If in that case the operational datastore will be completed with the >>>> data taken from the running datastore, then the presented view might >>>> be inconsistent. >>>> >>> This is true for other similar nodes as well - "asset-id" and "uri". >>> >>> The question is also: what data is applied? Our assumption: if there >>>> is a mismatch between detected versus configured hardware, then the >>>> interface/service related data that is configured consistently with >>>> the planned hardware is not applied on the mismatching >>>> hardware. I.e. the detected hardware is not brought in service so not >>>> =E2=80=98applied=E2=80=99, the operational datastore only (accurately)= reports on what >>>> is detected. >>>> >>> If there is a mismatch and the server doesn't apply the configured >>> values, then obviously the configured 'mfg-name' etc are not copied to >>> . >>> >>> We do not see this as a special rule for this data but rather would >>>> apply a general rule: >>>> - if there is a =E2=80=98missing resource=E2=80=99, then the dat= a is not reported >>>> in the >>>> operational datastore. >>>> - If the server is not able to report accurately, then the data = is >>>> omitted from the operational >>>> >>> I think that if you want complete separation between the values of >>> 'mfg-name', 'model-name', and 'serial-num' in configuration and >>> operational state, then these should be modelled as separate leafs. >>> We should have a config false leaf 'serial-num' that only contains the >>> detected value (if found), and a config true leaf 'config-serial-num' >>> or something, that contains the configured serial number. >>> >>> But if this is the case, I wonder if it wouldn't be better to leave >>> such additional config objects to vendors, and simply make these three >>> nodes config false in ietf-hardware. >>> >>> >>> /martin >>> >>> Regards, Bart >>>> >>>> /martin >>>> >>>> >>>> Best regards, Bart >>>>> >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >>>>> Wilton >>>>> Sent: Thursday, December 21, 2017 4:14 PM >>>>> To: Martin Bjorklund ; netmod@ietf.org >>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >>>>> >>>>> Hi Martin, >>>>> >>>>> >>>>> On 21/12/2017 11:37, Martin Bjorklund wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I need WG input on this issue. The question is how to handle >>>>>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>>>>> be treated the same. Based on previous WG discussion (see e.g. the >>>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>>>>> should all be configurable, but the configured value is only used in >>>>>> operational state if the system cannot read it from the hardware. >>>>>> >>>>> I think that this approach is probably OK: >>>>> - The client can always see the real value if it is available. >>>>> - If it is not available then they can assign a value via >>>>> configuration. >>>>> >>>>> I was also considering an alternative approach of having a separate >>>>> set of config false leaves for the "burnt in values". And then havin= g >>>>> the configurable leaves always override the default operational >>>>> values. E.g. similar to how an interface MAC address would expect to >>>>> be handled. >>>>> >>>>> But one set of leaves is probably sufficient. >>>>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>> So I suggest the following changes: >>>>>> >>>>>> OLD: >>>>>> >>>>>> leaf serial-num { >>>>>> type string; >>>>>> config false; >>>>>> description >>>>>> "The vendor-specific serial number string for the >>>>>> component. The preferred value is the serial number >>>>>> string actually printed on the component itself (if >>>>>> present)."; >>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>> } >>>>>> >>>>>> NEW: >>>>>> >>>>>> leaf serial-num { >>>>>> type string; >>>>>> description >>>>>> "The vendor-specific serial number string for the >>>>>> component. The preferred value is the serial number >>>>>> string actually printed on the component itself (if >>>>>> present). >>>>>> >>>>>> This leaf can be configured. There are two use cases f= or >>>>>> this; as a 'post-it' note if the server cannot determin= e >>>>>> this value from the component, or when pre-provisioning= a >>>>>> component. >>>>>> >>>>>> If the server can determine the serial number from the >>>>>> component, then that value is always used in operationa= l >>>>>> state, even if another value has been configured."; >>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>> } >>>>>> >>>>>> And corresponding text for 'mfg-name' and 'model-name'. >>>>>> >>>>>> And also: >>>>>> >>>>>> OLD: >>>>>> >>>>>> When the server detects a new hardware component, it >>>>>> initializes a list entry in the operational state. >>>>>> >>>>>> If the server does not support configuration of hardware >>>>>> components, list entries in the operational state are >>>>>> initialized with values for all nodes as detected by the >>>>>> implementation. >>>>>> >>>>>> Otherwise, the following procedure is followed: >>>>>> >>>>>> 1. If there is an entry in the /hardware/component list >>>>>> in >>>>>> the intended configuration with values for the nodes >>>>>> 'class', 'parent', 'parent-rel-pos' that are equal t= o >>>>>> the detected values, then: >>>>>> >>>>>> 1a. If the configured entry has a value for 'mfg-name' >>>>>> that is equal to the detected value, or if the >>>>>> 'mfg-name' value cannot be detected, then the list >>>>>> entry in the operational state is initialized with >>>>>> the >>>>>> configured values for all configured nodes, includi= ng >>>>>> the 'name'. >>>>>> >>>>>> Otherwise, the list entry in the operational state = is >>>>>> initialized with values for all nodes as detected b= y >>>>>> the implementation. The implementation may raise a= n >>>>>> alarm that informs about the 'mfg-name' mismatch >>>>>> condition. How this is done is outside the scope o= f >>>>>> this document. >>>>>> >>>>>> 1b. Otherwise (i.e., there is no matching configuration >>>>>> entry), the list entry in the operational state is >>>>>> initialized with values for all nodes as detected b= y >>>>>> the implementation. >>>>>> >>>>>> If the /hardware/component list in the intended >>>>>> configuration is modified, then the system MUST behave as >>>>>> if >>>>>> it re-initializes itself, and follow the procedure in >>>>>> (1)."; >>>>>> >>>>>> NEW: >>>>>> >>>>>> When the server detects a new hardware component, it >>>>>> initializes a list entry in the operational state. >>>>>> >>>>>> If the server does not support configuration of hardware >>>>>> components, list entries in the operational state are >>>>>> initialized with values for all nodes as detected by the >>>>>> implementation. >>>>>> >>>>>> Otherwise, the following procedure is followed: >>>>>> >>>>>> 1. If there is an entry in the /hardware/component list >>>>>> in >>>>>> the intended configuration with values for the nodes >>>>>> 'class', 'parent', 'parent-rel-pos' that are equal t= o >>>>>> the detected values, then the list entry in >>>>>> operational >>>>>> state is initialized with the configured values, >>>>>> including the 'name'. The leafs 'serial-num', >>>>>> 'mfg-name', and 'model-name' are treated specially; >>>>>> see >>>>>> their descriptions for details. >>>>>> >>>>>> 2. Otherwise (i.e., there is no matching configuration >>>>>> entry), the list entry in the operational state is >>>>>> initialized with values for all nodes as detected by >>>>>> the implementation. >>>>>> >>>>>> If the /hardware/component list in the intended >>>>>> configuration is modified, then the system MUST behave as >>>>>> if >>>>>> it re-initializes itself, and follow the procedure in >>>>>> (1)."; >>>>>> >>>>>> >>>>>> >>>>>> /martin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Benoit Claise wrote: >>>>>> >>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>>>> >>>>>>>> Benoit Claise wrote: >>>>>>>> >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> Only kept the relevant excerpts. >>>>>>>>> >>>>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>>>>> entPhysicalSerialNum >>>>>>>>>>> entPhysicalAlias >>>>>>>>>>> entPhysicalAssetID >>>>>>>>>>> entPhysicalUris >>>>>>>>>>> >>>>>>>>>>> For example, entPhysicalSerialNum being read-write always >>>>>>>>>>> bothered >>>>>>>>>>> me. >>>>>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>>>>>> >>>>>>>>>> Actually, this was not the intention. In >>>>>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>>>>> in the conversion to NMDA. >>>>>>>>>> >>>>>>>>> Ah. So no good news in this case... >>>>>>>>> >>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>>>>>> >>>>>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>>>>>> >>>>>>>>> Sure. It was mainly an observation. >>>>>>>>> >>>>>>>>>> However, I think that what we have now is probably not correct. >>>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name= ' >>>>>>>>>> should be config true, and the description of list 'component' >>>>>>>>>> updated to reflect that all these tree leafs are handled the sam= e >>>>>>>>>> way. >>>>>>>>>> >>>>>>>>>> I would like to know what the WG thinks about this. >>>>>>>>>> >>>>>>>>> Talking as a contributor this time. >>>>>>>>> It seems that inventory management is kind of broken when someone >>>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>>>>>> >>>>>>>> They can't really change them. The configured values are only >>>>>>>> used (i.e. visible in the operational state) if the device cannot >>>>>>>> detect them automatically. I.e., they work as "post-it" notes onl= y. >>>>>>>> >>>>>>> If I look at, for example, the mfg-name, description, this is not >>>>>>> what it says. >>>>>>> >>>>>>> leaf mfg-name { >>>>>>> type string; >>>>>>> description >>>>>>> "The name of the manufacturer of this physical >>>>>>> component. >>>>>>> The preferred value is the manufacturer name string >>>>>>> actually printed on the component itself (if >>>>>>> present). >>>>>>> >>>>>>> Note that comparisons between instances of the >>>>>>> model-name, >>>>>>> firmware-rev, software-rev, and the serial-num node= s >>>>>>> are >>>>>>> only meaningful amongst component with the same >>>>>>> value of >>>>>>> mfg-name. >>>>>>> >>>>>>> If the manufacturer name string associated with the >>>>>>> physical component is unknown to the server, then >>>>>>> this >>>>>>> node is not instantiated."; >>>>>>> reference "RFC 6933 >>>>>> fc6933>: >>>>>>> entPhysicalMfgName"; >>>>>>> >>>>>>> Regards, Benoit >>>>>>> >>>>>>> /martin >>>>>>>> . >>>>>>>> >>>>>>>> _______________________________________________ >>>>>> 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 >>> >> _______________________________________________ >> 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 > --f40304353634f930dc0562809656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Solution 2 seems fine to me at this stage.
<= br>
Regards,

Dan

=
On Thu, Jan 11, 2018 at 3:57 PM, Benoit Clai= se <bclaise@cisco.com> wrote:
Dear all,

draft-ietf-netmod-entity is the IESG telechat today.
In light of this discussion below, which I consider part of the IETF LC, I&= #39;ll be deferring the document to the next IESG telechat in two weeks. You have a few days to provide feedback on this propose solution 2.

Regards, Benoit (OPS AD).

Hi,

To summarize this, I think we have three options for the three nodes
'model-name', 'mfg-name', and 'serial-num':

=C2=A0 =C2=A01.=C2=A0 Do nothing (keep the nodes as config true).

=C2=A0 =C2=A02.=C2=A0 Make these three nodes config false (fairly simple ch= ange).
=C2=A0 =C2=A0 =C2=A0 =C2=A0(vendors can augment w/ their own config true no= des).

=C2=A0 =C2=A03.=C2=A0 Add three new nodes for the configured values.


After thinking about this some more, and discussing with Benoit, I
think the best path forward is to do 2, i.e., mark the nodes
'model-name', 'mfg-name', and 'serial-num' as "= ;config false".=C2=A0 As such
they would not be configurable, and thus contain the detected values.
If no value is detected, the node is not present.

Note that 1 or 3 can be done in a future update to this module (or by
a vendor).


/martin


Martin Bjorklund <mb= j@tail-f.com> wrote:
Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:
Hi,

--- snip ---

state.=E2=80=9D, so the above sentence only applies for the second case bel= ow.
Ok.

2. The second case is that something is detected but it can=E2=80=99t be re= ad.
We do not see a reason to use the value configured for the leafs
=E2=80=98serial-num=E2=80=99, =E2=80=98mfg-name=E2=80=99 and =E2=80=98model= -name=E2=80=99 of a matching entry in the
configuration data.=C2=A0 These leafs are defined as optional so why would<= br> we report something entered by an operator in the operational
datastore that intends to report on what is detected?=C2=A0 Is it not
better to not report them at all?=C2=A0 In an NMDA context it would be
possible to have a different value (or no value at all) for certain
leafs while there is something in the running/intended datastore.
The normal NMDA procedure for a configuration leaf is to repeat it in
operational state.=C2=A0 This is then the "applied configuration"= .
I don't think we should have a special rule for these leafs.

This also means that a client that just wants to read all the serial
numbers can do so from one place, the operational state, regardless of
how they came into existance.

[Bogaert, Bart ]

We do understand that a target of NMDA is to read out the actually
applied data in one request.=C2=A0 But the result should not be
confusion. A key word is =E2=80=9Capplied=E2=80=9D.

Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains (I put a part of the section between ***):
The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores except
that configuration data nodes supported in a configuration datastore
***MAY be omitted from <operational> if a server is not able to
accurately report them ***.
Note that this text talks about the *schema*.=C2=A0 It is intended for
servers to migrate to NMDA without having to instrument all config
nodes in <operational> immediately.=C2=A0 If you apply this to
ietf-hardware, it could be a server that implements the node
"serial-num" in config, but not in <operational> (which wou= ld be
weird).

For example, it is expected that the value of multiple leafs need to
be a consistent set, e.g. the mfg-name, the model-name, and the
serial-num.
Suppose we have a use case in which a hardware component is
planned/configured (e.g. a board supporting DSL interfaces) but a
different one is plugged (e.g. a board supporting ethernet
interfaces).
Suppose it is possible to read some fields on the detected component
but due to an issue not to read other fields.
If in that case the operational datastore will be completed with the
data taken from the running datastore, then the presented view might
be inconsistent.
This is true for other similar nodes as well - "asset-id" and &qu= ot;uri".

The question is also: what data is applied? Our assumption: if there
is a mismatch between detected versus configured hardware, then the
interface/service related data that is configured consistently with
the planned hardware is not applied on the mismatching
hardware. I.e. the detected hardware is not brought in service so not
=E2=80=98applied=E2=80=99, the operational datastore only (accurately) repo= rts on what
is detected.
If there is a mismatch and the server doesn't apply the configured
values, then obviously the configured 'mfg-name' etc are not copied= to
<operational>.

We do not see this as a special rule for this data but rather would
apply a general rule:
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if there is a =E2=80=98missing resource=E2=80= =99, then the data is not reported in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operational datastore.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0If the server is not able to report accurately,= then the data is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 omitted from the operational
I think that if you want complete separation between the values of
'mfg-name', 'model-name', and 'serial-num' in confi= guration and
operational state, then these should be modelled as separate leafs.
We should have a config false leaf 'serial-num' that only contains = the
detected value (if found), and a config true leaf 'config-serial-num= 9;
or something, that contains the configured serial number.

But if this is the case, I wonder if it wouldn't be better to leave
such additional config objects to vendors, and simply make these three
nodes config false in ietf-hardware.


/martin

Regards, Bart

/martin


Best regards, Bart

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
Wilton
Sent: Thursday, December 21, 2017 4:14 PM
To: Martin Bjorklund <mbj@tail-f.com>; netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06

Hi Martin,


On 21/12/2017 11:37, Martin Bjorklund wrote:
Hi,

I need WG input on this issue.=C2=A0 The question is how to handle
'serial-num', 'mfg-name', and 'model-name'.=C2=A0 I= think they should all
be treated the same.=C2=A0 Based on previous WG discussion (see e.g. the mail thread "draft-ietf-netmod-entity issue #13"), I think they should all be configurable, but the configured value is only used in
operational state if the system cannot read it from the hardware.
I think that this approach is probably OK:
=C2=A0 =C2=A0- The client can always see the real value if it is available.=
=C2=A0 =C2=A0- If it is not available then they can assign a value via
configuration.

I was also considering an alternative approach of having a separate
set of config false leaves for the "burnt in values".=C2=A0 And t= hen having
the configurable leaves always override the default operational
values. E.g. similar to how an interface MAC address would expect to
be handled.

But one set of leaves is probably sufficient.

Thanks,
Rob


So I suggest the following changes:

OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf serial-num {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The vendor-specific serial = number string for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component.=C2=A0 The prefer= red value is the serial number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string actually printed on = the component itself (if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present).";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reference "RFC 6933: entPhysicalSer= ialNum";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf serial-num {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The vendor-specific serial = number string for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component.=C2=A0 The prefer= red value is the serial number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string actually printed on = the component itself (if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This leaf can be configured= .=C2=A0 There are two use cases for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this; as a 'post-it'= ; note if the server cannot determine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this value from the compone= nt, or when pre-provisioning a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the server can determine= the serial number from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component, then that value = is always used in operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state, even if another valu= e has been configured.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reference "RFC 6933: entPhysicalSer= ialNum";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

And corresponding text for 'mfg-name' and 'model-name'.

And also:

OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When the server detects a new hard= ware component, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initializes a list entry in the op= erational state.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the server does not support con= figuration of hardware
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0components, list entries in the op= erational state are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initialized with values for all no= des as detected by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, the following procedure= is followed:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. If there is an entry in = the /hardware/component list in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the intended config= uration with values for the nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'class', &#= 39;parent', 'parent-rel-pos' that are equal to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the detected values= , then:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01a. If the configured entry= has a value for 'mfg-name'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that is equal= to the detected value, or if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'mfg-name= ' value cannot be detected, then the list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entry in the = operational state is initialized with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured va= lues for all configured nodes, including
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the 'name= '.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, th= e list entry in the operational state is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initialized w= ith values for all nodes as detected by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the implement= ation.=C2=A0 The implementation may raise an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alarm that in= forms about the 'mfg-name' mismatch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0condition.=C2= =A0 How this is done is outside the scope of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this document= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01b. Otherwise (i.e., there = is no matching configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entry), the l= ist entry in the operational state is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initialized w= ith values for all nodes as detected by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the implement= ation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the /hardware/component list in= the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration is modified, then th= e system MUST behave as if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it re-initializes itself, and foll= ow the procedure in
(1).";

NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When the server detects a new hard= ware component, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initializes a list entry in the op= erational state.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the server does not support con= figuration of hardware
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0components, list entries in the op= erational state are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initialized with values for all no= des as detected by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, the following procedure= is followed:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. If there is an entry in = the /hardware/component list in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the intended config= uration with values for the nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'class', &#= 39;parent', 'parent-rel-pos' that are equal to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the detected values= , then the list entry in operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 state is initialize= d with the configured values,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 including the '= name'.=C2=A0 The leafs 'serial-num',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'mfg-name',= and 'model-name' are treated specially; see
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 their descriptions = for details.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Otherwise (i.e., there i= s no matching configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entry), the list en= try in the operational state is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 initialized with va= lues for all nodes as detected by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the implementation.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the /hardware/component list in= the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration is modified, then th= e system MUST behave as if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it re-initializes itself, and foll= ow the procedure in
(1).";



/martin




Benoit Claise <bc= laise@cisco.com> wrote:
On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
Benoit Claise <bc= laise@cisco.com> wrote:
Hi Martin,

Thanks.
Only kept the relevant excerpts.
- Some objects are read-write in RFC6933:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entPhysicalSerialNum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entPhysicalAlias
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entPhysicalAssetID
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entPhysicalUris

For example, entPhysicalSerialNum being read-write always bothered
me.
serial-num is now "config false", which is a good news IMO.
Actually, this was not the intention.=C2=A0 In
draft-ietf-netmod-entity-03 this is configurable.=C2=A0 I missed this
in the conversion to NMDA.
Ah. So no good news in this case...
In the reverse direction, entPhysicalMfgName is read-only in
RFC6933, while it's "config true" in draft-ietf-netmod-entity=
Yes, this was added per request from the WG.=C2=A0 See e.g. the
thread "draft-ietf-netmod-entity issue #13".
Sure. It was mainly an observation.
However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'm= odel-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.

I would like to know what the WG thinks about this.
Talking as a contributor this time.
It seems that inventory management is kind of broken when someone
can change 'serial-num', 'mfg-name', and 'model-name.
They can't really change them.=C2=A0 The configured values are only
used (i.e. visible in the operational state) if the device cannot
detect them automatically.=C2=A0 I.e., they work as "post-it" not= es only.
If I look at, for example, the mfg-name, description, this is not
what it says.

=C2=A0 =C2=A0 =C2=A0leaf mfg-name {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The name of th= e manufacturer of this physical component.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The preferred value= is the manufacturer name string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actually printed on= the component itself (if present).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that compariso= ns between instances of the model-name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 firmware-rev, softw= are-rev, and the serial-num nodes are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only meaningful amo= ngst component with the same value of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mfg-name.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the manufacturer= name string associated with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 physical component = is unknown to the server, then this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node is not instant= iated.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reference "RFC 6933 &l= t;https://tools.ietf.org/html/rfc6933>:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entPhysicalMfgName";
Regards, Benoit

/martin
.

_______________________________________________
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
_______________________________________________
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

--f40304353634f930dc0562809656-- From nobody Thu Jan 11 07:43:19 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 B43AD12EB96; Thu, 11 Jan 2018 07:43:12 -0800 (PST) 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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568539269.29588.1124423893874376613@ietfa.amsl.com> Date: Thu, 11 Jan 2018 07:43:12 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:43:13 -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 : A YANG Data Model for Interface Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7223bis-03.txt Pages : 48 Date : 2018-01-11 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document obsoletes RFC 7223. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-03 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 Thu Jan 11 07:44:03 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 E74C612EBA8; Thu, 11 Jan 2018 07:44:02 -0800 (PST) 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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568544291.29551.11088325741043337862@ietfa.amsl.com> Date: Thu, 11 Jan 2018 07:44:02 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7277bis-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:44:03 -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 : A YANG Data Model for IP Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7277bis-03.txt Pages : 32 Date : 2018-01-11 Abstract: This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. This document obsoletes RFC 7277. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7277bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-03 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 Thu Jan 11 08:04: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 E7F3012EBB7; Thu, 11 Jan 2018 08:04:13 -0800 (PST) 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 efZvuZIFxE7F; Thu, 11 Jan 2018 08:04:11 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 4BF2912D87E; Thu, 11 Jan 2018 08:04:11 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id e3so1961350pfi.10; Thu, 11 Jan 2018 08:04:11 -0800 (PST) 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 :content-transfer-encoding; bh=gfh7RDtUZ/03knTAamkjuxT8ATB46c2ijyhWCuQOKt8=; b=ET0Z+ySmwE5DqzUm/WEgEBxMGs6wOfoOqHSFhHlkh6O7Pq/WagLGpae7S2EzBt6J4i zK5DV6ULRjXcswn0MuUYIEiojmDT8BnGX9V+ywxG36T/1DUxwk34v6lW9vfhAFKPXCN5 1FreRA9qDDQkyoreEaMnvQ+Z6R44XdBZw5pPG1/BIT5ufJXh7e68f4UkpXJn+zK0z0iv WyeiZvLEWG5RE5w3tl3CSBTembO5sPUXAASL0Np+pnkbN/YjHEgXa9fT/s/mBaVXANOL QhIz6qatCe7WALecdmgiG6ik6lPwLGupt+vaX6ic6o/rJKXqmQxYAEwdFOgfGFRE7kgK RX/g== 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:content-transfer-encoding; bh=gfh7RDtUZ/03knTAamkjuxT8ATB46c2ijyhWCuQOKt8=; b=HrmxGTUDp9ISds+BBn5JdB93xsnoHiYWAJJlg0h+F3Qy5DPlij6MTBtDG+/vgLBgsh n6qyF0gLFIXJnkO5QdXCvuBNzHdFXRbjvephk1Kh+ObahF3bez0RWAQPlMJ/OWTHPqWu TwJXRG9XcIbwT1q5uY9/YeRmXW8nsgQZZIIJGiwbAjklXuYIEYJjhVyS82kZBjJjnqeO 6qyMZMb0sxjRhwR7/1QFMIa3nhtrMRvggPJp42oYlt6sF9NqGtN9MTr6jD0VyinZ7vi3 o6BU8ieYu1h/Hr7V7S4NvGWErKR0oKZRJvi2aRFd6Rmx3KAULiHcUTgx+emPBEMQd3RU IrYw== X-Gm-Message-State: AKGB3mJWNWMVR6mM9OfEZK/8bzZfbbfY5Dz2w+QLaxelioN4Kbf2wN9P I6JGEpIJ8JFN30Uml5A1Aht7XsPrFQ4ZvxJ36Ok= X-Google-Smtp-Source: ACJfBouP8Hunp9wn5wE2blj3dC4xKccgSRM/v7PCxsMEWwiryGgBYdzCd+oTHKmZQs/lmBhha/1EwqrxMnhfhYlpUDg= X-Received: by 10.99.94.7 with SMTP id s7mr18117988pgb.132.1515686650667; Thu, 11 Jan 2018 08:04:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Thu, 11 Jan 2018 08:03:30 -0800 (PST) In-Reply-To: <20180111075218.3tu65mthzlnef3bi@elstar.local> References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> From: Kathleen Moriarty Date: Thu, 11 Jan 2018 11:03:30 -0500 Message-ID: To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:04:14 -0000 Hi Juergen, Thank you very much for the additional information. This was very helpful. Benoit and I discussed it a bit further on the telechat and some text changes in the introduction and security considerations section to provide some of this information for the reader will be helpful. I got the explanations and appreciate them and from the explanations, my discuss questions have been answered and I'll switch this to a no objection leaving you and Benoit to add the text as helpful for other readers. Best regards, Kathleen On Thu, Jan 11, 2018 at 2:52 AM, Juergen Schoenwaelder wrote: > Kathleen, > > further thoughts inline... > > On Wed, Jan 10, 2018 at 10:12:02PM -0500, Kathleen Moriarty wrote: >> Hi Juergen, >> >> Thanks for your quick response. Inline. >> >> On Wed, Jan 10, 2018 at 2:45 PM, Juergen Schoenwaelder >> wrote: >> > On Wed, Jan 10, 2018 at 11:21:13AM -0800, Kathleen Moriarty wrote: >> >> >> >> ---------------------------------------------------------------------= - >> >> DISCUSS: >> >> ---------------------------------------------------------------------= - >> >> >> >> Hello, >> >> >> >> Thanks for your work on this draft. I'm a little confused with some = text in >> >> the draft and have a few questions. >> >> >> >> 1. The introductions says, >> >> "This architectural framework identifies a set of conceptual datastor= es but >> >> it does not mandate that all network management protocols expose a= ll >> >> these conceptual datastores. This architecture is agnostic with >> >> regard to the encoding used by network management protocols." >> >> >> >> As such, the data stores could be exposed for some implementations, u= sing >> >> whatever network management protocol (likely NetCONF or RESTCONF). I= f this is >> >> the case, why doesn't at least some of the security considerations te= mplate >> >> apply for at least secure transport? >> > >> > The security considerations text is IMHO correct. The YANG modules def= ined >> > in this document do not define any accessible objects. Hence, the secu= rity >> > YANG template does not apply. >> >> Could you make that more clear in the document? The section from the >> introduction quoted above says it is possible if network management >> protocols expose the datastores. > > I am still not sure what you find missing. A datastore is a container > for data. > > - The structure and semantics of the data contained in a datastore is > defined using YANG modules. YANG modules have security > considerations text that discusses the specifics of the data modeled > in a YANG module. > > - The access to datastores is via management protocols such as NETCONF > and RESTCONF. These protocols secure the data transport via SSH or > TLS. In addition there is an access control system (NACM). > > Datastores have been with us since the beginning of NETCONF but they > were kind of hardcoded and not extensible and not all data was > contained in datastores. What this document does is essentially to > introduce an architectural framework where all data is contained in > datastores and the set of datastores becomes extensible. > > I assume the security template you have been referring to is the > template we use for YANG modules, i.e., the definition of the concrete > objects stored in a datastore. I do not see how this template relates > to the introductory text. The template only applies to the YANG > modules but as explained in the security considerations, these YANG > modules do not define any objects. > >> >> 2. Section 5.3.4 - Is there any integrity protection on the origin in= formation? >> >> If not, can it be added or is there a good reason why it=E2=80=99s n= ot possible? I >> >> realize these are conceptual models that may or may not be exposed, b= ut if >> >> exposed and used, wouldn=E2=80=99t some integrity protection on this = be helpful? >> > >> > Can you clarify what you mean with 'integrity protection' in this >> > context and why you think origin attributes are special? The known >> > published network management protocols all use standard security >> > protocols (SSH and TLS). In general, security mechanisms are protocol >> > specific, I do not see how the architectual definition of datastores >> > requires discussion of special integrity mechanisms. Perhaps I do not >> > understand your concern. >> > >> >> What I'm wondering here and wanted to discuss was really how the >> information on origin information will be used. Does this information >> need to be from a source that can be validated? If so, should there >> be some way to provide a MAC for the values for origin information in >> the data stores? I am not referring to transport in this second >> question. Your answer may be an explanation of how the origin >> information will be used that excludes any need for integrity >> protection. I just wasn't clear on how the information from the data >> stores will be used from the draft. > > The origin tells a client where a value in the operational datastore > is originating from. For example, if you see an IP address on an > interface, you can determine from the origin whether the IP address > was configured, learned say via DHCP or provided by the system > (e.g. an auto-configured link-local IPv6 address). One obvious value > is troubleshooting but this information can also help tools to > determine in which way the actual applied config differs from intended > config or what can be responsible for unexpected differences. > > The source of the information is the device itself. Can this > information be validated? In general, not. Like pretty much anything > else that is reported by the device. If the device or its > NETCONF/RESTCONF server is lying at a client application, there is not > much we can do about it in general. (For some information, it may be > possible to cross check i.e. whether DHCP leases match up with learned > IP addresses.) But note that we always had to trust information > reported by devices, I do not see what the origin information is any > different. (In fact, in some data models we had special purpose origin > objects, in particular in forwarding table models.) There is no work > as far as I know to introduce some form of cryptographic signatures > for data exposed via NETCONF or RESTCONF. > > That all said, and coming back to the first issue, I do think we > could actually say something about the origin annotation. RFC 7952 > (which defined the syntax for metadata annotations) says in the > Security Considerations: > > Security implications of a particular annotation defined using this > mechanism MUST be duly considered and documented in the annotation's > definition. > > So we should perhaps have text discussing the security implications of > the origin annotation. I would have to think a bit more what exactly > that text should say. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Best regards, Kathleen From nobody Thu Jan 11 08:05:31 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 D698012D860; Thu, 11 Jan 2018 08:05:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568672387.29482.1503781577338806147.idtracker@ietfa.amsl.com> Date: Thu, 11 Jan 2018 08:05:23 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:05:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-revised-datastores-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, Thanks for your work on this draft. I'm a little confused with some text in the draft and appreciate Benoit working with the authors to clarify text around these points. This was previously a discuss, but the explanations provided were helpful and the tweaks discussed are appreciated. Original questions from discuss: 1. The introductions says, "This architectural framework identifies a set of conceptual datastores but it does not mandate that all network management protocols expose all these conceptual datastores. This architecture is agnostic with regard to the encoding used by network management protocols." As such, the data stores could be exposed for some implementations, using whatever network management protocol (likely NetCONF or RESTCONF). If this is the case, why doesn't at least some of the security considerations template apply for at least secure transport? 2. Section 5.3.4 - Is there any integrity protection on the origin information? If not, can it be added or is there a good reason why it’s not possible? I realize these are conceptual models that may or may not be exposed, but if exposed and used, wouldn’t some integrity protection on this be helpful? Thanks in advance! From nobody Thu Jan 11 08:06:50 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 5217A12D860; Thu, 11 Jan 2018 08:06:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-rfc7277bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568680433.29506.621711331794922043.idtracker@ietfa.amsl.com> Date: Thu, 11 Jan 2018 08:06:44 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's No Objection on draft-ietf-netmod-rfc7277bis-03: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:06:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-rfc7277bis-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for applying the current security considerations template! From nobody Thu Jan 11 08:14: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 43C8C12D88F; Thu, 11 Jan 2018 08:14:49 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 9sesEXiU6Gx8; Thu, 11 Jan 2018 08:14:46 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AC112D860; Thu, 11 Jan 2018 08:14:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 31C7EFBA; Thu, 11 Jan 2018 17:14:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sYkAloZvGGeO; Thu, 11 Jan 2018 17:14:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Jan 2018 17:14:44 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 565C02013E; Thu, 11 Jan 2018 17:14:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x-ohmLO0y_DX; Thu, 11 Jan 2018 17:14:43 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F173E2013D; Thu, 11 Jan 2018 17:14:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 74DB1420C8FE; Thu, 11 Jan 2018 17:14:43 +0100 (CET) Date: Thu, 11 Jan 2018 17:14:43 +0100 From: Juergen Schoenwaelder To: Jan Lindblad Cc: yang-doctors@ietf.org, netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-revised-datastores.all@ietf.org Message-ID: <20180111161443.6l5jgzzjg77d6v5r@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jan Lindblad , yang-doctors@ietf.org, netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-revised-datastores.all@ietf.org References: <151551261178.1806.130953175040927039@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <151551261178.1806.130953175040927039@ietfa.amsl.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Yangdoctors early review of draft-ietf-netmod-revised-datastores-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:14:49 -0000 Jan, thanks for sharing your review - an interesting read. Many of the issues you have touched upon have kept us quite busy during 2017, both on the mailing list and during the regular webex calls of the main contributors. Thanks for actually sharing your notes. /js On Tue, Jan 09, 2018 at 07:43:31AM -0800, Jan Lindblad wrote: > Reviewer: Jan Lindblad > Review result: Ready > > Finally the NMDA datastores draft has reached WGLC, and I have been assigned as > YD reviewer; quite an honor ;-) > > Because of the pretty fundamental importance of this document, I performed what > I consider myself a pretty thorough review. Since this work has been going on > for a very long time and with high intensity at times, I have not even tried to > keep up to date with all the discussions. So in order not to resurrect all the > beaten zombies that this spec has seen, I decided to let the document shepherd > and principal author Martin Bjrklund review my review. > > The end result of which is that I withdraw every one of my comments and > proclaim review result Ready. > > For full transparency (and to show that I wasn't lazy after all), I have > enclosed my initial review findings below. Note that I now feel that they are > either discussed enough already, addressed in a different document (e.g. YANG > library), or misunderstandings/proposals on my part that do not necessarily > merit further discussion or clarification. Finally I will add that no blackmail > or bribery ;-) was involved in me reaching this conclusion; merely a good > discussion. > > /jan > > Topic #1: Loss of operational stringency > > According to RFC 6020 tradition, config false data returned from > operations MUST adhere to the constraints declared in the YANG modules; > max-elements, must statements, unique keys, etc. This is obviously a high > standard to live up to for server implementors. With NMDA, the situation > reverses so that operations will return data from where no > semantic guarantees apply. This moves the burden of managing flux and > inconsistency from the servers to the clients. > > Now each client has to be able to deal with potentially duplicate keys, > violated constraints and generally that any YANG model semantic guarantee is a > mere recommendation. > > Personally I find this rather shocking. One of the core values in NETCONF/YANG > has always been that it sides with the "operator" or "client" view of the > world. Decades ago we had SNMP (Simple ...) -- which in practice meant simple > to *implement*, not simple to use. NC/Y is supposed to be the other way around. > Hard to implement, but easy to use. > > If we feel strict adherence to the YANG declaration is a bar too high for > operational data, maybe we could find some middle ground? Just giving up and > saying that anything anywhere may be violated anytime is to make it too easy > for implementors and too hard for clients, IMHO. > > If I'm beating on a dead horse here, I apologize ;-) I just want to ensure that > if this is what we want, it should be an informed decision. > > Topic #2: Actions live in > > NMDA says actions are always invoked in context of the data > store. In many cases I agree this makes good sense. But there are a couple of > catches here. > > The first catch relates to timing. As the server is not obliged to make an > element committed in immediately available in , a > client that creates a bit of configuration and is interested to execute an > action on it will not know when to fire the action. Should it poll for the > object creation? Keep retrying? I sense the creation of Heisenbugs and interop > issues. > > The second catch relates to structure translation between and > . If the configuration committed to by the client has no > direct counterpart in and , there is nothing to invoke > the action on. Say I used a templating feature in to define a bit of > configuration, and now I want to execute a check-sync action on that piece of > config to see that the config has propagated properly. There is no context to > invoke the action on in . > > Similarly, for actions that update (e.g. config wizards), executing > in would make sense. Maybe an ability to specify the context > datastore in the rpc would be enough to fix this. Or better perhaps, the target > datastore should be formally declared by the action/rpc? > > Such a declaration would solve another issue that exists today. A client needs > to parse English to know if an action changes . Any configuration data > cached by the client would need to be invalidated iff so. With a formal > mechanism to declare which datastores are (not) affected, clients could be a > lot more efficient. This is a real issue. > > Topic #3: Datastore specific deviations > > How would I express a deviation that applies to one datastore but not another? > Say, for example, that I have a deviate not-implemented on an object in > but I support it in . > > Topic #4: NMDA compliance declaration > > How would a client know that a server works according to NMDA principles? I > suppose the intent is that there is no need to know because things are > "backwards compatible", and that for a given server the answer may vary > depending on which data model we're talking about. But as discussed in topic > #1, #2, #3 above (and more below), significant semantic differences are > introduced by NMDA. As client implementor, I would want to know what to expect > from a server. > > Topic #5: Origin of unset values > > When the operational view is constructed, the draft describes situations where > the operational value may be taken in some cases from or:intended and in other > from or:learned. While it would be valuable for clients to understand what the > precedence rule is, this may be a bit too complex to declare formally, since it > is quite possible that the mechanics of which value shows up isn't always > simple and may depend on other leaf values. > > In the example with a DHCP learned address trumping an intended address, it > could be that the DHCP server specifies only an IPv6 address. In which case the > device policy might be to override the IPv4 address in intended with no value. > In this situation, there is no way for the server to communicate why there is > no IPv4 address (it was or:learned), since the origin attribute cannot live on > a non-existent XML element. > > So the origin mechanism does not work well for optional elements. > > Topic #6: Datastore and origin identity trees > > Why are there two trees with identities, one for datastores and one with > origins? Most values seems to be the same, with the origins being a superset of > the datastores. By organizing them into a single tree with all the datastores > as one branch of the origins tree, we could get something simpler. > > moduel ietf-origin { > identity origin; > > identity unknown { base origin; } > identity system { base origin; } > identity learned { base origin; } > identity default { base origin; } > identity datastore { base origin; } > > identity conventional { base datastore; } > identity running { base conventional; } > identity candidate { base conventional; } > identity startup { base conventional; } > identity intended { base conventional; } > identity dynamic { base datastore; } > identity operational { base datastore; } > > /* > * Type definitions > */ > > typedef origin-ref { > type identityref { > base origin; > } > } > > typedef datastore-ref { > type identityref { > base datastore; > } > } > > Topic #7: Editorial > > Below are a few details about the wording: > > On pages 3 and 4, it is said that > "These datastores share a common datastore schema" > and > """datastore schema: The combined set of schema nodes for all modules > supported by a particular datastore, taking into consideration any > deviations and enabled features for that datastore.""" > > If we have a device that support macros/templates/services in , which > expands into concrete configuration in , I don't suppose the > macro/template/service instances would be part of ? If so, I guess > the schemas are not exactly the same? Maybe we can say that is a > subset of the schemas (plus all the config false data)? > > p15: Maybe we could point out that learned values etc MUST NOT update > / to make this entirely clear. > > p24: Juergen Schoenwaelder's funding is mentioned, but not his participation > > p27: what's ? > > p28: ds-ephemeral and or-ephemeral are not great names. Will be referred to as > ds:ds-ephemeral and or:or-ephemeral. Would prefer ds:ephemeral and or:ephemeral. > > /jan > > -- 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 Jan 11 08:44: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 4069C12D86A; Thu, 11 Jan 2018 08:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 SC5c-Xzjqohi; Thu, 11 Jan 2018 08:44:11 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40109.outbound.protection.outlook.com [40.107.4.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18F312EBAE; Thu, 11 Jan 2018 08:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/NiaemuvYmlfmJA/4iZ/ZfdDkUHnUrToao/ysvAUMvE=; b=Q4+DCRiRMw6Nrr0kNR+o3zgcC5qYOKynmjsxuvY5kqEGij91pRZ0I5qCH3sgqoCx+BculDd1H5n4saZ6FXVPYSK/fh0yhaEyepKhWsFyyHLggNGECUzEC6V5IPGA8n2T4SR4dqbfKDbr1SHZbdKQ1F5RgaJKBImJkqwRQO2gdVA= Received: from pc6 (86.169.153.236) by HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Thu, 11 Jan 2018 16:43:46 +0000 Message-ID: <025301d38afb$39261da0$4001a8c0@gateway.2wire.net> From: "tom p." To: "Juergen Schoenwaelder" Cc: , , , , References: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com> <012c01d3896d$68c41d80$4001a8c0@gateway.2wire.net> <20180109.210824.760424986407969599.mbj@tail-f.com> <20180110163653.fjfbmr3gbnue52pq@elstar.local> <038f01d38ad8$59860240$4001a8c0@gateway.2wire.net> <20180111125837.vc6jvjpcbqpmexd2@elstar.local> Date: Thu, 11 Jan 2018 16:16:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: DB6PR0201CA0015.eurprd02.prod.outlook.com (2603:10a6:4:3f::25) To HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6d836463-9909-4e4e-f08d-08d559127c32 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020068)(4652020)(8989060)(5600026)(4604075)(4534098)(4602075)(4627194)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 3:KpcD2fiXN9XmuQBSJTpA4iLVnGZkjOIipdna+1ji8z+HD5oZaxh+gLDw88b3s4UWiUHrX9FdYDzM1bPN0wuXRWt/N30ZF75vwT4e4XQ4Lmgv0+u+q9FRn6FtetnSSqrPxuhTl33lfG7GqQEy9HDu12jxtPs0+hoBi2NrQblHje3D8kN2s/xXz6uGRXZfqkbMS+q4zclNsH/x+lxWd2AgnQK4R6iOl8x89LGTjTvntXHJcH68ZP3N3Xap2PdOCa6U; 25:ZMd2sSTrmiCdEChueH/m8f0ffMziTl74q3c4L+HxNYdoiTtkux7gKV5Luj0UBc+vxcoAVVVik/Xm/Am7xIAFn8vtS9sT8TjiMeG/o4bikI0yo9nuz73UqZzJsE20lyAkgvgvyiGyHuJpw65K89lTodG2hym8jEnTordMWW29/JK/IXPgq1fjNs0mKH+g2gxZcY087ufuk5creQQCqPFdbGWw1waa0DfWSj0xd19B7Ffwi8lOXDduB1OoR62LwagaIK2aU4kfCk2HbOcLFljpKHMPli+7MZPAI4qmPXrwuUzvqgybRE9OkzF9idmfKU0gplo5f4080Liu7FShtADyOg==; 31:gKhs9Gfw9+QurC5NZgebuAmNv9yDZiBk9t14bjzCxvGhuvIWHvy1qvvyAhLldxJxzIbWAsVdKldz3TSFJJFbxa9WRvVkLrljNFgvIbLlQzKQpbnldjDsiWzLNtBgbiXrFa7Ic4Yt7DI2rneK/7etUIljnBVpQ2Dw741aUNND0GRpAF0PwAD9zNamHGRoK+OMFkfyzXDky4ZEddEMQOTUMojqv3BzarMpNnzgqxRwtA0= X-MS-TrafficTypeDiagnostic: HE1PR07MB1563: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(8121501046)(5005006)(3002001)(3231023)(944501134)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041268)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR07MB1563; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 4:kSo6ZeeiEs1V0IvwqBLc5mdW1bmz+/899p23jFR9t0sV6je9rwzkpNnsGwraBTMoFxBpK1E4j8Qq8nC31hPSEVVxGcbrwGXDbp0izj5XUld5eiPHNYltr7AbwdQh5O4YP+pqYUDbYGiaq+W7xMD1IoviTc2M6uq5kShSylHByHSkuLiA9cy5gO1rIHgFAtboG7wXTq+mjk2gky7z2mMsooyrvs8kQRHHaiIjpyVyXYSGWBMasZ6iGPmVCvbeVSv8MkaaIsdRaWFXgvOWq2o9yg== X-Forefront-PRVS: 0549E6FD50 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(24454002)(13464003)(230783001)(81816011)(6246003)(50226002)(23756003)(230700001)(76176011)(478600001)(53936002)(81686011)(8936002)(6306002)(8676002)(6916009)(4326008)(6486002)(6116002)(33896004)(2906002)(9686003)(3846002)(6666003)(44736005)(84392002)(316002)(97736004)(81156014)(4720700003)(81166006)(6496006)(54906003)(44716002)(16526018)(68736007)(66066001)(305945005)(1456003)(106356001)(25786009)(50466002)(5660300001)(7736002)(93886005)(47776003)(62236002)(229853002)(52116002)(14496001)(6346003)(1556002)(386003)(105586002)(86362001)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1563; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1563; 23:ZoLt+Sf/+MQmmoHvcQzbeeB/Vl8i3CcaUmZ/ywR?= =?iso-8859-1?Q?Eg5brKNa661n1tl780sOhWHRr0PF6hynmYYmytEGP1X7CmAgvcyps0WRU3?= =?iso-8859-1?Q?Q46FZfUm8uIWFjD1T3BfUxUHZNcVrtbydAPvacDV4Td8tahCRXKZwK7Z7c?= =?iso-8859-1?Q?nO8RE0YBGUSHMQK7R3BZ2clqRn+vec6aPt+Oh0oR0qMJDkoWtERanZC/yw?= =?iso-8859-1?Q?QmG376AtGLxhParVy5aOq/Wqg7WXLLIgxOpwYiEFohjNmXbCP0p6Ntzn/W?= =?iso-8859-1?Q?pM3D3ztDtyjIjjDttvB6tWHWEroi+vFqeH5A3dGkhxuOJWBfxyWiV+8HvU?= =?iso-8859-1?Q?k8YNnKzFjHn9yOiUEyZsFhKA5NIah8W09QWZBqKS8Xro2Ozz+5HR5MktYz?= =?iso-8859-1?Q?RlIt57H0D7Y5pkhTmetlntwgKI/Qo4wCOZ3AiyzNYTERBKtDLeC/lzGVa3?= =?iso-8859-1?Q?O/MGoa9MUoanWJPLmqcItmSmRHHnLfXJXHkSbN6Q3/rHqrfnceLtsNMQVx?= =?iso-8859-1?Q?Z5Yw73a45k/7Oh3f6tL0utf/3wTh2LTXMtd9JXMgbIixPXjvbAfmN902k4?= =?iso-8859-1?Q?eWOJW6C/p6BYEhbEvfFi8yr29Db8Fsr2rED+dpDUvSDosL1NDibFUijZ7z?= =?iso-8859-1?Q?7k8VJAP6sCaaMbG26gRLWdZsXzfOdvTQ9ib4Qu8+ddx4dzsBCLq3v1aFBI?= =?iso-8859-1?Q?4U5D+y+lI0g/MOYClgSZK0PcJ7QqEHCdCRM9WWSKdIy1/BV2DKsnzXG2in?= =?iso-8859-1?Q?3dQAZEtJ/kJQ7RZ1deqVtYWYJCB6uXQntYehVHEMjsJ6b/+nfuwUJkA1Mv?= =?iso-8859-1?Q?K6aPeAK4ya3opEhGaTM5rNJJ8Br9pHJCkUrvD6H8jSmU38dz+bG9uRRO7q?= =?iso-8859-1?Q?hyXPmt71dOs7m9hrz7kQwGlEJef89R1huE5ReAJEtqf9TWwfHt1KV/429I?= =?iso-8859-1?Q?wdoZLaHzk8ccKbzZ9IrwQQ9Jz4haVa3ClwrKBEGQB14V1b1TIC3ilabsMP?= =?iso-8859-1?Q?hykidHUsv/1OZuswPdHqyHTiHPwD6N59bugPTzOwsJwrBogcatTABx4os/?= =?iso-8859-1?Q?AnnHvJxiBfYNhteVpGOfLsVA/JH/OhwAsbLI+tHc3/bcG8c9Uj/h3z9nfg?= =?iso-8859-1?Q?4vs/UUjwb6eQcED6g5d/u3CG3Np+dt8OVrVibhXh/UBYTiGVpx0Bn05qqb?= =?iso-8859-1?Q?uufJxgsHYhxe0KDkxHux4SgONQs7kvXlz575oaeGUEYT+FAWR6l0Pay2uo?= =?iso-8859-1?Q?IMELolwEmf2lOTqTYr56qN/y9lYCvJk2w5i32ZpWu//3leIhIANVJgvpSW?= =?iso-8859-1?Q?UMHnjVPBRK2SIHFbe5Aa5YuPT1G8oaHaCb6b2WjWNfS123pLUmXLJrZdJV?= =?iso-8859-1?Q?oV8hxPbs+V2YRjiaiBpybGhunQpCdX5V9eU9Xb5tJwj3cgJQXc/HvwYrG3?= =?iso-8859-1?Q?Fy9/SQntDR1vcCyrTcK+pkOHCdBF8PiXUFPpAtVup2Ix03OMOYCLDw77AW?= =?iso-8859-1?Q?J8e5fWb8beDMbUmopw+W4J3ILh6aKsv7pbHfJ3tDC2zRUEsXitVLvx/LGt?= =?iso-8859-1?Q?GV3Mg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 6:B9E+2kKwjgzQx/7LSj7i+GdivfM2Z+hz/JEzpQGK0+dWRl/luOKS3CQ6zRN7p+76HcUVfUauOtzvk5IoAn1LFwQaF1b4n2j16HHw3+VDXGvYbjUbH/l1+AXd478cjCyMmDd2Ht8bPz6tkKH8Mh5M/I5oVRfVktJl8OEJ1HH5RgUKE+e2+XcPa8C2UnAAhhZ4dLYKRh+DrBqx3uwRLiwGV1jHHprDbwsIjHDHHIY2MHXD3z8NYO9sXLSvFr4LFrupB6eykqCys3pI7Bkpl5AOuQKomWuA6t5DOg9pS3GFmmIE8OVNaiby+v5YcdUyZn1/iyty5PXUmhrMR5UyUgMSos9mBN2Cm8UxNTrK5j4qh2E=; 5:06ipU9E5JlQN3N4Phwd6Fm8Ud9NnN3tf852j5J6u52HLEUw/j8/GtaFxH63/JrP4Q4Q1RvHfyOIAa2P/M/2jp0UrQBwl3p6FFPfnUmvSMOG71tWnbksffNbDEVfZnK1NOMLN8QpmNU9npwXxvczq2XEeZ7iYWJXht3EAP/rOpAE=; 24:YfrEF+sCGZQIyJMZsVjN2GLM90mGsnmIjY0mSQx+MxBCwG5VRzmB9sPIQFNn6L9ReTwaXc3xomA1YWJGU7MHKuU69dtw0gSXryLxupwOmos=; 7:gwNTiTsFHEjGbDsu1Y1BwHBVU0sfSp51yktnXxtzCzpfCBOn+DsZU2jAxRfXjosZS5O1cWew0qzrpXY7OyHkXlxGsSme773FqaOJAZWTXoUz3PfeRedx9UZu9srcFbSk68eHjOg+OzMP8a1V0MVoYRtYfTph7qLGw5GtTdekDcRZvmBG2P5fgTcp+WVNVWlDYA5ypvW86M4iSYzbHV06dPbuk29nHHGrgmlSRgGprKRN/5YNgOx5mbma7BOSLkNh SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2018 16:43:46.2664 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d836463-9909-4e4e-f08d-08d559127c32 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1563 Archived-At: Subject: Re: [netmod] Last Call: (Network Management Datastore Architecture) to Proposed Standard two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:44:14 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" Sent: Thursday, January 11, 2018 12:58 PM > On Thu, Jan 11, 2018 at 12:32:29PM -0000, tom p. wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > Sent: Wednesday, January 10, 2018 4:36 PM > > > > > Right. Lets see there "two" is used: > > > > > > - 1st paragraph in 2. Objectives: I think the text is clear since it > > > talks about a concrete example of a configured value and an > > > operationally used value. > > > > > > - 2nd paragraph in 2. Objectives: This text talks about two separate > > > branches in the old models, this should be fine. > > > > > > - 4th paragraph in 2. Objectives: I think this is potentially > > > causing the confusion. It says: > > > > > > With the revised architectural model of datastores defined in this > > > document, the data objects are defined only once in the YANG > > schema > > > but independent instantiations can appear in two different > > > datastores, one for configured values and one for operational > > state > > > values. > > > > > > Perhaps a better wording would be this: > > > > > > With the revised architectural model of datastores defined in this > > > document, the data objects are defined only once in the YANG > > > schema but independent instantiations can appear in different > > > datastores, e.g., for a configured value and one for an > > > operationally used value. > > > > > > This e.g. then kind of continues the example the section started > > > with. Would this change have avoided the question? > > > > Juergen > > > > Yes, I would find that clearer. Perhaps even better > > > > OLD > > e.g., for a configured value and one for an > > operationally used value. > > NEW > > e.g., one for a configured value and one (another?) for an > > operationally used value. > > > > I would say 'one' and 'another' but 'one' and 'one' would be clear > > enough. > > > > I now have this: > > With the revised architectural model of datastores defined in this > document, the data objects are defined only once in the YANG schema > but independent instantiations can appear in different datastores, > e.g., one for a configured value and another for an operationally used > value. > > OK? OK Tom Petch > /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 Jan 11 09:56:52 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 EAA3612EC16 for ; Thu, 11 Jan 2018 09:56:50 -0800 (PST) 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_RP_MATCHES_RCVD=-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 0D7bik7SKWOY for ; Thu, 11 Jan 2018 09:56:48 -0800 (PST) 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 E1A8412EC19 for ; Thu, 11 Jan 2018 09:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16277; q=dns/txt; s=iport; t=1515693392; x=1516902992; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DzFo7lQszuhEGrb7KdK2/REx8KuzgZlWks4qQ94rK4Q=; b=BMTox8y7V7L8Jo7w54ej9xyac3prbVZKCltCdTymYRhuPX1pcK5hVo9b 5DWZX4rFoGsuFmx2kxUy1izWXCT/Q+7k3rJdRhw1XpPzrvKpFn18T350V K5YoNffmPvRWN8QCxo8C2A6t6UQZsjoCvoc77U3rlq0ZNCYPOOanqFhi9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAgD/pFda/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEB4sYj0cnfJhKChgLgV6Ca08ChQEUAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBAQMBAQEhDwEFNgsMBAsOAwQBAQECAiMDAgInHwkIBgEMBgIBARaKEQgQr?= =?us-ascii?q?zaCJ4o8AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4Mcg2yBaSkMgWtYNoMvAQE?= =?us-ascii?q?CAYFOAQEIgy2CZQWKY4dEkT2IC408ghiKCyaHRYpnglaBXogJgTw2IoFQMhoIG?= =?us-ascii?q?xU9giqEV0E3igKCPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,345,1511827200"; d="scan'208";a="1357113" 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; 11 Jan 2018 17:56:29 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0BHuSq9010669; Thu, 11 Jan 2018 17:56:29 GMT To: Martin Bjorklund , bart.bogaert@nokia.com Cc: netmod@ietf.org References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> From: Robert Wilton Message-ID: <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> Date: Thu, 11 Jan 2018 17:56:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180111.144705.493071366326080006.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 17:56:51 -0000 On 11/01/2018 13:47, Martin Bjorklund wrote: > Hi, > > To summarize this, I think we have three options for the three nodes > 'model-name', 'mfg-name', and 'serial-num': > > 1. Do nothing (keep the nodes as config true). > > 2. Make these three nodes config false (fairly simple change). > (vendors can augment w/ their own config true nodes). > > 3. Add three new nodes for the configured values. > > > After thinking about this some more, and discussing with Benoit, I > think the best path forward is to do 2, i.e., mark the nodes > 'model-name', 'mfg-name', and 'serial-num' as "config false". As such > they would not be configurable, and thus contain the detected values. > If no value is detected, the node is not present. Option 2 suits me.  It keeps it simple. > > Note that 1 or 3 can be done in a future update to this module (or by > a vendor). Agreed. Thanks, Rob > > > /martin > > > Martin Bjorklund wrote: >> Hi, >> >> "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: >>> Hi, >>> >>> --- snip --- >>> >>>> state.”, so the above sentence only applies for the second case below. >>> Ok. >>> >>>> 2. The second case is that something is detected but it can’t be read. >>>> We do not see a reason to use the value configured for the leafs >>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the >>>> configuration data. These leafs are defined as optional so why would >>>> we report something entered by an operator in the operational >>>> datastore that intends to report on what is detected? Is it not >>>> better to not report them at all? In an NMDA context it would be >>>> possible to have a different value (or no value at all) for certain >>>> leafs while there is something in the running/intended datastore. >>> The normal NMDA procedure for a configuration leaf is to repeat it in >>> operational state. This is then the "applied configuration". >>> I don't think we should have a special rule for these leafs. >>> >>> This also means that a client that just wants to read all the serial >>> numbers can do so from one place, the operational state, regardless of >>> how they came into existance. >>> >>> [Bogaert, Bart ] >>> >>> We do understand that a target of NMDA is to read out the actually >>> applied data in one request. But the result should not be >>> confusion. A key word is “applied”. >>> >>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains >>> (I put a part of the section between ***): >>> The datastore schema for MUST be a superset of the >>> combined datastore schema used in all configuration datastores except >>> that configuration data nodes supported in a configuration datastore >>> ***MAY be omitted from if a server is not able to >>> accurately report them ***. >> Note that this text talks about the *schema*. It is intended for >> servers to migrate to NMDA without having to instrument all config >> nodes in immediately. If you apply this to >> ietf-hardware, it could be a server that implements the node >> "serial-num" in config, but not in (which would be >> weird). >> >>> For example, it is expected that the value of multiple leafs need to >>> be a consistent set, e.g. the mfg-name, the model-name, and the >>> serial-num. >>> Suppose we have a use case in which a hardware component is >>> planned/configured (e.g. a board supporting DSL interfaces) but a >>> different one is plugged (e.g. a board supporting ethernet >>> interfaces). >>> Suppose it is possible to read some fields on the detected component >>> but due to an issue not to read other fields. >>> If in that case the operational datastore will be completed with the >>> data taken from the running datastore, then the presented view might >>> be inconsistent. >> This is true for other similar nodes as well - "asset-id" and "uri". >> >>> The question is also: what data is applied? Our assumption: if there >>> is a mismatch between detected versus configured hardware, then the >>> interface/service related data that is configured consistently with >>> the planned hardware is not applied on the mismatching >>> hardware. I.e. the detected hardware is not brought in service so not >>> ‘applied’, the operational datastore only (accurately) reports on what >>> is detected. >> If there is a mismatch and the server doesn't apply the configured >> values, then obviously the configured 'mfg-name' etc are not copied to >> . >> >>> We do not see this as a special rule for this data but rather would >>> apply a general rule: >>> - if there is a ‘missing resource’, then the data is not reported in the >>> operational datastore. >>> - If the server is not able to report accurately, then the data is >>> omitted from the operational >> I think that if you want complete separation between the values of >> 'mfg-name', 'model-name', and 'serial-num' in configuration and >> operational state, then these should be modelled as separate leafs. >> We should have a config false leaf 'serial-num' that only contains the >> detected value (if found), and a config true leaf 'config-serial-num' >> or something, that contains the configured serial number. >> >> But if this is the case, I wonder if it wouldn't be better to leave >> such additional config objects to vendors, and simply make these three >> nodes config false in ietf-hardware. >> >> >> /martin >> >>> Regards, Bart >>> >>> /martin >>> >>> >>>> Best regards, Bart >>>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >>>> Wilton >>>> Sent: Thursday, December 21, 2017 4:14 PM >>>> To: Martin Bjorklund ; netmod@ietf.org >>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >>>> >>>> Hi Martin, >>>> >>>> >>>> On 21/12/2017 11:37, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> I need WG input on this issue. The question is how to handle >>>>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>>>> be treated the same. Based on previous WG discussion (see e.g. the >>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>>>> should all be configurable, but the configured value is only used in >>>>> operational state if the system cannot read it from the hardware. >>>> I think that this approach is probably OK: >>>>  - The client can always see the real value if it is available. >>>>  - If it is not available then they can assign a value via >>>> configuration. >>>> >>>> I was also considering an alternative approach of having a separate >>>> set of config false leaves for the "burnt in values".  And then having >>>> the configurable leaves always override the default operational >>>> values. E.g. similar to how an interface MAC address would expect to >>>> be handled. >>>> >>>> But one set of leaves is probably sufficient. >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>>> So I suggest the following changes: >>>>> >>>>> OLD: >>>>> >>>>> leaf serial-num { >>>>> type string; >>>>> config false; >>>>> description >>>>> "The vendor-specific serial number string for the >>>>> component. The preferred value is the serial number >>>>> string actually printed on the component itself (if >>>>> present)."; >>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>> } >>>>> >>>>> NEW: >>>>> >>>>> leaf serial-num { >>>>> type string; >>>>> description >>>>> "The vendor-specific serial number string for the >>>>> component. The preferred value is the serial number >>>>> string actually printed on the component itself (if >>>>> present). >>>>> >>>>> This leaf can be configured. There are two use cases for >>>>> this; as a 'post-it' note if the server cannot determine >>>>> this value from the component, or when pre-provisioning a >>>>> component. >>>>> >>>>> If the server can determine the serial number from the >>>>> component, then that value is always used in operational >>>>> state, even if another value has been configured."; >>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>> } >>>>> >>>>> And corresponding text for 'mfg-name' and 'model-name'. >>>>> >>>>> And also: >>>>> >>>>> OLD: >>>>> >>>>> When the server detects a new hardware component, it >>>>> initializes a list entry in the operational state. >>>>> >>>>> If the server does not support configuration of hardware >>>>> components, list entries in the operational state are >>>>> initialized with values for all nodes as detected by the >>>>> implementation. >>>>> >>>>> Otherwise, the following procedure is followed: >>>>> >>>>> 1. If there is an entry in the /hardware/component list in >>>>> the intended configuration with values for the nodes >>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>> the detected values, then: >>>>> >>>>> 1a. If the configured entry has a value for 'mfg-name' >>>>> that is equal to the detected value, or if the >>>>> 'mfg-name' value cannot be detected, then the list >>>>> entry in the operational state is initialized with the >>>>> configured values for all configured nodes, including >>>>> the 'name'. >>>>> >>>>> Otherwise, the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. The implementation may raise an >>>>> alarm that informs about the 'mfg-name' mismatch >>>>> condition. How this is done is outside the scope of >>>>> this document. >>>>> >>>>> 1b. Otherwise (i.e., there is no matching configuration >>>>> entry), the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. >>>>> >>>>> If the /hardware/component list in the intended >>>>> configuration is modified, then the system MUST behave as if >>>>> it re-initializes itself, and follow the procedure in >>>>> (1)."; >>>>> >>>>> NEW: >>>>> >>>>> When the server detects a new hardware component, it >>>>> initializes a list entry in the operational state. >>>>> >>>>> If the server does not support configuration of hardware >>>>> components, list entries in the operational state are >>>>> initialized with values for all nodes as detected by the >>>>> implementation. >>>>> >>>>> Otherwise, the following procedure is followed: >>>>> >>>>> 1. If there is an entry in the /hardware/component list in >>>>> the intended configuration with values for the nodes >>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>> the detected values, then the list entry in operational >>>>> state is initialized with the configured values, >>>>> including the 'name'. The leafs 'serial-num', >>>>> 'mfg-name', and 'model-name' are treated specially; see >>>>> their descriptions for details. >>>>> >>>>> 2. Otherwise (i.e., there is no matching configuration >>>>> entry), the list entry in the operational state is >>>>> initialized with values for all nodes as detected by >>>>> the implementation. >>>>> >>>>> If the /hardware/component list in the intended >>>>> configuration is modified, then the system MUST behave as if >>>>> it re-initializes itself, and follow the procedure in >>>>> (1)."; >>>>> >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>> >>>>> Benoit Claise wrote: >>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>>>> Benoit Claise wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Only kept the relevant excerpts. >>>>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>>>> entPhysicalSerialNum >>>>>>>>>> entPhysicalAlias >>>>>>>>>> entPhysicalAssetID >>>>>>>>>> entPhysicalUris >>>>>>>>>> >>>>>>>>>> For example, entPhysicalSerialNum being read-write always bothered >>>>>>>>>> me. >>>>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>>>> Actually, this was not the intention. In >>>>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>>>> in the conversion to NMDA. >>>>>>>> Ah. So no good news in this case... >>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>>>> Sure. It was mainly an observation. >>>>>>>>> However, I think that what we have now is probably not correct. >>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' >>>>>>>>> should be config true, and the description of list 'component' >>>>>>>>> updated to reflect that all these tree leafs are handled the same way. >>>>>>>>> >>>>>>>>> I would like to know what the WG thinks about this. >>>>>>>> Talking as a contributor this time. >>>>>>>> It seems that inventory management is kind of broken when someone >>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>>>> They can't really change them. The configured values are only >>>>>>> used (i.e. visible in the operational state) if the device cannot >>>>>>> detect them automatically. I.e., they work as "post-it" notes only. >>>>>> If I look at, for example, the mfg-name, description, this is not >>>>>> what it says. >>>>>> >>>>>> leaf mfg-name { >>>>>> type string; >>>>>> description >>>>>> "The name of the manufacturer of this physical component. >>>>>> The preferred value is the manufacturer name string >>>>>> actually printed on the component itself (if present). >>>>>> >>>>>> Note that comparisons between instances of the model-name, >>>>>> firmware-rev, software-rev, and the serial-num nodes are >>>>>> only meaningful amongst component with the same value of >>>>>> mfg-name. >>>>>> >>>>>> If the manufacturer name string associated with the >>>>>> physical component is unknown to the server, then this >>>>>> node is not instantiated."; >>>>>> reference "RFC 6933 : >>>>>> entPhysicalMfgName"; >>>>>> >>>>>> Regards, Benoit >>>>>> >>>>>>> /martin >>>>>>> . >>>>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 11 20:00:57 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 088A21270A7 for ; Thu, 11 Jan 2018 20:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.673 X-Spam-Level: X-Spam-Status: No, score=-3.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Z2Fo0SZ9_zrt for ; Thu, 11 Jan 2018 20:00:54 -0800 (PST) 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 99FBF124F57 for ; Thu, 11 Jan 2018 20:00:53 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 890FCA1E72924 for ; Fri, 12 Jan 2018 04:00:50 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 12 Jan 2018 04:00:49 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Fri, 12 Jan 2018 12:00:36 +0800 From: "Zhengguangying (Walker)" To: "mbj@tail-f.com" CC: "netmod@ietf.org" , "Qudan (Beijing-NOS)" Thread-Topic: hi Martin, one issue about RFC7950 7.20.3.2. The "deviate" Statement, please help to confirm Thread-Index: AdOLWcjG4z+RP4tHR668cstJJJyi4w== Date: Fri, 12 Jan 2018 04:00:35 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E140C92641FB@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.169.155] Content-Type: multipart/related; boundary="_004_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] hi Martin, one issue about RFC7950 7.20.3.2. The "deviate" Statement, please help to confirm X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 04:00:56 -0000 --_004_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_ Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_" --_000_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, When we define YANG model's deviation file, we find one scenario was nor su= pported but we have one problem depend on it. Our scenario: In ACl YANG module, there have two leafs: acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfName acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfAny And the acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfName have one = Constraints: when "not (../vrfAny =3D 'true')" In some product domain, the "vrfAny" does not supported, some they deviate = the leaf "vrfAny". From the sematic view, the Constraints of vrfName when = "not (../vrfAny =3D 'true')" should be deviated as "delete" too. But, in RFC7950 7.20.3.2. The "deviate" Statement , "when " is not the S= ubstatement of deviate, we can not deviate the when statement, and the prob= lem coming, some industry netconf tools compile fail because "../vrfAny" do= es not exist. And there have some other scenario about "when" deviate, So, I think whethe= r the YANG language should add "when" as the Substatement of deviate? What's your opinion? Thanks & regards Walker(guangying zheng) [cid:image001.png@01D38B9C.D7570600] --_000_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mart= in,

&n= bsp;

When we define YANG model’s deviation file, we f= ind one scenario was nor supported but we have one problem depend on it.

 

Our scenario:

In ACl YANG module, there have two leafs:

acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfNa= me

acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfAn= y

 

And the acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBa= s4/vrfName  have one Constraints:  when “not (../vrfAny =3D= ‘true’)”

 

 

In some product domain, the “vrfAny” does = not supported, some they deviate the leaf “vrfAny”. From the se= matic view, the Constraints of vrfName  when “not (../vrfAny =3D= ‘true’)” should be deviated as “delete” too.

 

But, in RFC7950 7.20.3.2.  The "deviate"= ; Statement ,  “when ” is not the  Substatement of de= viate, we can not deviate the when statement, and the problem coming, some = industry netconf tools compile fail because “../vrfAny” does not exist.=

 

And there have some other scenario about “when&#= 8221; deviate, So, I think whether the YANG language should add “when= ” as the Substatement of deviate?

 

What’s your opinion?

&n= bsp;

&n= bsp;

Thanks = & regards

&n= bsp;

Walker(= guangying zheng)

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

--_000_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_-- --_004_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=48704; creation-date="Fri, 12 Jan 2018 04:00:35 GMT"; modification-date="Fri, 12 Jan 2018 04:00:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeQAAAKWCAIAAAAXzn35AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO wwAADsQBiC4+owAAveVJREFUeF7tvQ18FFWWN1zdne4EOmGEBBNQAqTDhx8EnNfRYMYBxkl0kkHW 3RF3B3HXR4TVcdkHZnXnURmdQZh3h+eFGWd1JLK/VYHZlXGcQSVq0AWUAI7OaKJCIJ3Il9INBPLR 3SGdj37PvbequrqquruqUt3p7pyyLapv33Puuf97+/TJqVv/awmFQhweiAAigAggAqmNgDWaeT/9 6U9T23K0DhFABBCBEYSAxXBkPdjn6zq0euBSe1/AwwDLGldWcPNvRhB42FVEABFABJKFwBAi69DA QM9pR7DNmRXIdfTlWHx97R/3nvuz6itZ3cF2EAFEABHITASGEFkHO8+9XmHjegGYgYF+q9U+0Ofj OAt5WeBspWdLVm5xVt7ky771Umbih71CBBABRCApCEQ4693vvHvk8OfKdq+6+prK79wiKx8Mdp75 r+L8K7/OWe3wslgdnNVhsdk5C72GCyin1+0trxX+dVNSuoONIAKIACKQmQhEOOunn376gQcfVHb0 N88+u3LlSjVnPTm/+AbO5rBYwFNTl018tAN8tNVmD9FCq9Vx5sMNV/5Dd2bih71CBBABRCApCETN WWttHTw1ialZcA2vbOqyoSQbzlZbNrhyraqwHiKACCACiEAUBIbmrEl2msTRkPSgMXV2CPIeFgi0 SQKEhthZ5MLIUbfCwo4VdUbEUQYRQAQQgYxCQO6su7s67/jHV6QvKIEes2XX0jOFwUJy0zQNIsTU 1Eez/LU1i4TVUMHIUb0ZFhWGdi03IosyiAAigAhkGgLynPXddy9RdnHbtu3qOev/njJ++vdYAiRE vDOJslnaGkqEu472r9572GjOGuLrnYtCm6szDXbsDyKACCAC+hCQR9aBQI/yFUslWwdCIms+bU3D aiENQgtVxd2b5srTHCpF+jqDtREBRAARyFQEhpazhjQIc83kjiL11/R+I3mRC5q/hluOKkfdhtVl u2iig6thWWn3pqWsqGVj007MU2fqhMN+IQKIgDEEhrTO+nzdgrHFFXBfkbNmsTUh4jlEFu2x/LX9 y3eWqaRBII6etvoQsXr5LpLoUM14YBrE2LCiFCKACGQaAkN6grFj3xLn2KnkRiJ10yHismnCGhaB 0BuMZFmIzf7VngcVzlr0wuIFcd7Na4jbdtfVcdXVpQRqdNaZNuGwP4gAImAMgaE4666eT9f3XjzW 4/1T3LavWHJaXgf8cE0tX1i+seXgqlKhhL47JvlYjL7jtoMVEAFEABHITASMO+vMxAN7hQggAohA SiIwxBuMKn1CIuyUHGg0ChFABNIbAYys03v80HpEABEYIQhgZD1CBhq7iQggAumNwPBH1j09PYOD A32B/kuBS36/Lzjgu2rWnPQGFa1HBBABRMBsBIY5sg4EAoMDg0F/f6+/t8/fF/JbQhey33+r3uxu oj5EABFABNIbgeGMrElMDZ46EAz6g73+IFyAyw4G+uBtp72t6o670htatB4RQAQQAfMQGM7Iur8f AurgJX8vvMBNE08NLpuce7s9IfP6mE6a/K0NDa1+dk4nuzPJVm9Tk9dof4Yia7RNlBshCNiefPJJ c7s6f/58jQp9F319NKymMXUQroX4Ojjg52ZWzIiup2H9/HvWvPDVtH+4uVhjY5qqgdptVt06jUmp GeRv/dBbVFF8gZyvGktrgN/ee6SvqHjccOzh4G3afbCpra2ttdWf6yrM1YShkUrepnraTluMZqLV gfI2zjzjQJ238CYX9FWBfCQaflWbcwu5tgZvrt7hMjbKhixUGx+TMYw3BdhQmj6lVHthSltqmqHs AJ2zCemIOj6ETMnUA7w/6It9Zg2edn/5RePxYwdaPnvnsz/v/Pjgf3+wb8v79U+/88bP33x5zSvx jNq/bt66/fEqJeDzxLXrcze6fSF2Fg6fe//bb7/d6ElAR+Kp9DSK7frcbj0WgNH7JX2I1xD/eVyp uBWiNaRZECqKUMuQV0EjilpJTY09hzE3MsqGLdRqVuLqxR4RzeOlyUC92rTUJ9An8kupboP5aZAn nngCflljn9lPr9/fRbPVkAYh515fb2+AZELgfLb3eLyf52H6/NTxtkS17HSVuZwcO/OH3+Phioqc 3b6k50T8rW5udlkhs8PpcvFXWvruhUA8L1fsgxYRUsfnjyMVt0KUlrTa42/9xFMkdDQSeVU0otiT 69Q7XsZG2biFWkckcfViDqXW8dJons5po6l10FlUqOMrodFUsZq6zeY7a+1PMPYPdPO3FukNRvLy 8WdutCdq/xrWLyDH4+ElI6e2L4Pky/xl20/xQpCYoHUWhMtoHVKyvoHj4HM41jfwgqQoXBjWQeqs p6oE1Q3rlz7fatn9GNVCD0GV1NwIe/gKoIe0qG/U6PfRVZgnlYI/xukRzqtGKamvF6vA38v1TEoo U5ZEWkZadqrkPWhbvGaio76+oakJ/hFT7FDY6LFYvI2shK/T6meCYjWpHtay39ftVGtRtEtZQVQe tl3RL5k9MfDnnR9vTQTyqmjENVjrWEeOsiqqKqpkUmrjpcVCLRjKWhdFImTVZpRilKESnQbuqGOt Ol7K2RLNJEm5Slt6Z690AofnIUz7Rq+F6IL57KMgsO+j0KL67SbIm9DvDv0ORBnlOPho+ksiYZX2 vvHGge0H9zy/761f7n59/a5XHvvjb1e9/POVq6I3eHLbffdtOwmfi+kISQn7JPyRqAbqsKQJXLDk CYjPm8fXF6vJUhykDqkttqCuXCYl1A5LCXpUDIuJLPxBTdIJEX+B839+iX+wi3+QSUvoX2jhP6WU f5jH/VNdtYKgkbcL2oAraqLUxohrWgdcesQfjUo9TFXsPyxVK8gKtdSJBrlUVoa8LrVxOyIzQDnK qqjGltJloVKVFHkt9ot1lBfSDJ5yHrL0WOwmZJ+qzhblICpngqwt4QsS8b2IO3tVrY1sS/wKhr8X McyTIiZrXZSPgs9wRtbwWzWvpqbL7j7XcwpCbAj9z/S2tI/58Me/2hg9KDl5wl0yZZL0cyhxb7mH xtruEyfJJxWP7p23LyLWhjpV8yrgo0lLtjxK/iVH1botSyI0qbRKpSZNKeE1awmWBAsjpFjr+g6v 12MJtB3Y3eTh+DwIiab4jETRHJqjUC0J0AjiQFuAb6+wrMLploTVHKcsiTRNNSYTQ0/4Q5+PPyEa ds2BrI20vkwW3o4uualKyKjwNkNuh+NEPaRQf2CtIqXWr7ialaMiQ14djSgGg6yuv5BVRlkNVZmR Q7FQHpXKOhJvbkhhDyOjkILZIpuHpDId99gjIp8/LBMYOVuUQ6acdbK21O2JN3tVZ6asLaertAi+ oJAq66bqVI/CstlcI/uLmP0BSZREth4XH/OdNctWaz9uvfPuO/9pycJHq//2qTsf2vAvDz25IaZs 8eTStuOQ7gjnjqGk6qk95Ni7lznihu3bix/dC8e9J5ayzAPUqd9Hr041NAjJEs02Qlulk+XLThoa ouQ0JBYqpTS3yXHkW19WSY7ZRfBoJ5GEGSEo8LE0tmpJIROrrKygU8fr9TpdFUQP18gyI8oSmV3O XEnqhWTxpJ/De/b1CaeZpTk2/trv9QoWRklgh/VIVUVDKCKNJ5gky+2p9ktmT9QRCP90yJFXRUPV HvjzFr6xuhL8qqPMEIuebR2ChYr+a8FQJiSIgAPk7zMokYc6snkozNWwlOpYRBmviNmiFJT1QtmW qj1KnJWtK0dBUVJYmAeLbT1FUV01RxcZVcF3sKwwJGtU1BYXH/MfioGctV5/rcODEVe8fsHju0Mu V6nb7YboGBw05IhJKtkSci3bSoJl8n5LqwXqhiqfEhw4kYIS17KXtiw5uX7+Y7uhfqiSiPPNQ3JZ VsiXwOeVT+0R69E89WP1tGV2LVdF7XFzpfcTa6QVIN5/rJ7ZHKfPZKV1W8AC072Ma4Jf41BotKui wsWRBdgBsHx0CbwjX2i6JFu9JFQ4mwS0vCqCRmEZjXCVJSrWwPRq8lIMealwW8SqQl4JNWwO9wlk 4uAXgf91aKpv9DhdN1UUeWkveOPDt015m6V6mAXymrxdYYP5asSkXAaRRCRav6ArxB7euujIe5sa ukvmWBpVkM9tlaLBNy1qkgDbmlsh/hEB9nzCzWGYqB7yUR4czBnn7OnoYZ2SoSpqUJ8b2iyUmSEd xPB8AlQjxl1pO/zpJtwQAVNLbuJBU50tIX4eQowQIRV9PCLHS5jhdLbEgjFi8ijbEr87ZLRc/vDk UZ+9dLbExId9Jengxh1pad8HB8cV5baf5aeupHVfHHzMd9b6PG9K1wY/u29efMea0n1A4/Qg4G9t 9ekKjCXKwcW4nXF/EPRYg3XTAwFw1dLf6IQZbb6zTnhknTAsUDEigAggAimLgPnOOm5XB/t8XYdW D1xq7wvw6/OyxpUV3PybuIJYARFABBCBEYuA+TcY46+zDg0M9Jx2BNucWYFcR1+OxdfX/nHvuT+r vkbswGDHEQFEABGQIjAckXWw89zrFTauF+wYGOi3Wu0DfbDWAe5pWDgLnK30bMnKLc7Km3zZt17C AUMEEAFEABEwx1nvfufdI4c/V6J51dXXVH7nFln5YLDzzH8V51/5dc5qh5fF6uCsDovNzlnoNVxA Ob1ub3mt8K+bcJAQAUQAEUAEzHHWTz/99AMPPqhE8zfPPrty5Uo1Zz05v/gGzuawWMBTU5dNfLQD fLTVZg/RQqvVcebDDVf+QzcOEiKACCACiID5OWutmIKnJjE1C67hlU1dNpRkw9lqywZXrlUV1kME EAFEINMRGCZnTbLTJI6GpAeNqbNDkPewQKBNEiA0xM4iF0aOuhUWdqyok4q7N81VKzbSAsogAogA IpB0BExz1t1dnXf84yvSF5Sw7rD1IdIzuZcIPpqmQYSYmvpolr+2ZpGwGioYOao3ExaVXctlnnop t5Wyq+yaedRtRC3KIAKIACIwnAiYlrO+++4lyn5s27ZdPWf931PGT/8eS4CEiHcmUTZLW0OJcNfR /tV7DxvNWUN8vXNRaHM1sQmCanDVB1eVDifQ2DYigAggAkNBwLTIOhDoUb5iWcbWgZDImk9b07Ba SIPQQlVxlXxGnBTHseZDZTMiPDVLlayo4wWFhAn/du4mEnsLdYSLXcLFCirMKon1IoqGMiAoiwgg AoiAGgKmOWud8Fp410zuKFJ/Te83khe5oPlruOWoctRtWF22i+YzuBrmZN2blrKilo1NOyPy1HJx MZ2983aSJ6mt4XMjQgC+dMfiFlCzeMdS8MSQTmG5FP7Cwl/UcotIU9yO16m3rttZu5zaEwph7K5z EmB1RAAR0I6AOc4a1lO/qnZAuaop9jFTaEBNV4DweWoSVsM1nxUhTlw1sq7e3DJzLYlja2p51RA4 L19E8h2lqw4ytys7ps8sb6KJauZ2wbduriFVlu+KcK9CAF46o+xQ87GoENK2wnVA56KdGFdrn3FY ExFABAwhYI6zhidfIDetPJRPxDAjs5wTBwe50OBAaHAQXoODA4OD/eQ80Bca6Cfn/mBoIKjWo7oV 05rXRNxCBF9cyyJqd12d2s3D0lVrylZviBlzE2nBp7uPNpXPnC5tG0pkpoTr1G3aNJ3e0lzTPC1y /Ymh8UAhRAARQATUEYi5r5SRD9m+5jGOgd5O30f/2r77jtPbroj7UtEjXehRvhHyFuLSD/ouch0I iaPZKhC2PIS9FesIn7I6LRvLSR2mVFpQTsuXvyFRLkjyMmHdRjBDGUQAEUAE4iBgzmqQEfNLKF1k MmI6jR1FBBCBFEDAnDSItCPxWfeidNuwYBJhhAy1alo8iSZgU4gAIjAiEcDIekQOO3YaEUAE0g0B jKzTbcTQXkQAERiRCKRxZN3T0wMLSPoC/ZcCl2D37+CA76pZc0bkIGKnEQFEIPMRSNfIOhAIwEq/ oL+/19/b5+8L+S2hC9nvv1Wf+SOGPUQEEIERiUBaRtYkpgZPHQgG/cFefxAuwGUHA33wttPeVnXH XSNyKLHTiAAikMkIpGVk3d8PAXXwkr8XXuCmiacGl03Ovd2eUCYPV/S++VsbGlr97DwyEcBeMwRw JmTqTEjLyLrdAzuj9wkxdbCPRNYsvg4GAv5FjyyMPloN6+c/Vs9Vrdv7aIWZQwpq983TrdOYlJrd 8AVtza1w+ci5rNDbVN/khX0sucKyyrLCcH0o9xZWSUvMwwB0N3rJ5pnyRlWbUFoYzWaFOPFFnqKK CpeT/8jbtLvJC9ehUOHsqjIuSt/19lSzPXoVJ7h+5ExIcGOoPqkIpFZkrWS+jmTB5qEhMbWvN+gL BumZeGo4s2uf6kPqIqYVj+5dV2U+wqA2rvcH17y+IaJpLVJabPW3tnJzynLpmfjmwrKKktGjS26K 8NS0PK6nNhaag1QjN7uqkh5afgzAksrKm8BIZy7fQWWJes/9Ho+fg/vJoqeG3x/WLnPf0fquBUdp Ha326NWb2PrymZDY1lB7chEw31k/8cQTxroAgkw22llU6/d30Ww1pEHIGdx0b4BkQuB8tve4sdYT LnXqeFui2nC6ysBRsTM7fH5/Xq7wRkez3tZWI4LQXFGhJITX1qLSyPhmg6/mioqc3T6a6/G3urnZ wo+D0+WiJsRXos08c1VpbnNIFZUzYUjqUDilEDDfWRt+EFG7YP9AN39rkd5gJC8aX5OwerQnKr4N 6xeQ4/HwkpFT25fNh2PZ9lO8EES/tM6CcBmtQ0pIWAyfw7G+gRdkkbJQGNZB6qynqgTVDeuXPt9q 2f1YOLiWSVHhCHv4CqCHtKhr1vh93U4xZqWSEPvW19dH5LNJ0W56QNKEr9PosVi8jbHT3pB2ABFe hmmGBAgpjdQfYTFkFaiURLWKkQqz5b2mvtpVmMfKybvIbpLCeEpEKFhHGlp9YokMJaUqWd/VBgV0 MFThePv9D/cz2IW2+PsJUj2K1gV7GsiQhRFTjJeuKYGVMwCBNGVP2fvGGwe2H9zz/L63frn79fW7 Xnnsj79d9fLPV66K3p2T2+67b9tJ+Hz/unnr9pN6khL2SfgjUQ3UYbXhgkmB+Lx5fH2xmqiTlZA6 pLbYgrpymZRQOywl6FExLOa4eRrfbvTIa8gKtdRRNuJz79/v9oVCIE3/pYeqKqmsWEFaUymlRQ9p VahnrAvUYPCCERBpsRD6TlEVMFAbAqUeZVtKDNWk3qb2hduKC06afpPRbM0IpGVkDb+R82pquuzu cz2nIMSGv3vP9La0j/nwx7/aGP3n8+QJd8mUSdLPocS95R4aa7tPnCSfQBJ53r6IWBvqVM0j9yIn LdkiZqWr1m1ZEqFJpVUqNWlKCa9Zy8+6YGGEFGtd36EaXMoLIbnrdIfDahaqxo1KWRaC43Kd4SRL XClIJM/mGkmo2eQVI34DgbXX67EE2g7sbvJwJA+iqZuqwa+vGzL60vy9qEqqU6Yf4vgAjYgPtAWi jkdhYZGH9FS8kwtK5G0pMFS2Tkr4rI7QlNp46ZsWWDvNETDfWQ8lZ60LzFvvvPvOf1qy8NHqv33q zoc2/MtDT26IKV48ubTtOKQ7wrljKKl6ag859vK3Bxu2by9+dC8c955YyjIPUKd+H7061dAgJEs0 mwltlU4ullVvaIiS05BYqJTS3CZUjMjakjQ0EZalcr1er9NVAfflwI2yLEi4jt/rjbP8D5Qyp62i WWkpW4VC7z2GxFS6/ow1+OqiMnovcXYRucXozOXTIaRF1W4KhTKTojdNbl9GsxCkYHWN9GamWk/5 G63iL0H0DHoYQ6FOuHWhJFxHdbz0TAqsm/YImL90D1LPxvy1YUGtgwA568d3h1yuUrfbzVbvQY6Y pJItIdeyrSRYJu+3tJL1Z6HKpwQHTqSgxLXspS1LTsLKv91QP1QpWfxHlgNGFvIlIFX51B7JMhG6 cJBfN6iUojnrpc+7udL7iTXSChDva1xxSJZztAVIF9gRIktAcllhKDTaxa95C1ejFcSbg2QFnge8 eHhlXCS6dLVIwGIRFgVK9ISVKwZEWF0HHwwOjivKbT8rWAgmldw0x9IYtllipFQP3xBplyNr9Vi1 3FZ+kaK0m5F9l9335PXIW4mwMGecs6ejh8cwXFPoO1sjqHo/1d/a9AkE4BRqsV/ytuQYwi8Nv/qQ jFckICo48+MFWj7h5kQbJ63fCayXRgiY76zTqPMJM9W8BdQJMxEVJwAByUL2IfnSRC6IT0C3UWVy EDDfWRsOkA0LJgcpbAURQAQQgWFEwHxnnbjOXOy6sGLrHgs3aOH4Z8rH2YPPLr87cS2iZkQAEUAE UgQB85214QA5ruDZC94HfnsgO7+Q7LEb7AUELf72ZTcWqUL5nW98K0UgRjMQAUQAERg6AuY766Hb FE0Dc9Ya9f/+oTs01sRqiAAigAikPgLmO+u4AbIUlN3vvHvk8OdKmK66+prK79wiK2fO2jlxqtXC 2a0Wu81qt1gcNksWPZMS8rLabZa9H3+Kzjr1Jx9aiAggAtoRMN9Za28baj799NMPPPigUuQ3zz67 cuVKVWede8VUcMoO3jXz3lnw1Ba7xeqwcbv/gs5a1zhgZUQAEUh1BMx/KEY7xYcxbLKom4Zz+MJC gmuIssnLykG5Mc0ohQggAohAyiJgvrM29kSMdoAET23NslptgstmPpq8SFbEWKfqVljYsaJOao17 01y1Yu0GY01EABFABIaOgDG/FqtdvZF1d1fnHf/4ivQFJdCAktuatco7ZYivSRxtZW4ash98OQ2u DR3Vmwmjyq7lMk+9lNtKmVZ2zTzqNqQXhRABRAARGDoCw5+zvvvuJcpubNu2PVrOelLJNLiFSG4t srQ1ubVodRAfTSJrdqdxx8GPjd5ghPh656LQ5mpiEwTV4KoPriodOs6oARFABBCBISFgMAqN0abe yDoQ6FG+YugXctMkDQIv9pZkP8ILQtRz1ir5jDgpjmPNh8pmRHhqlipZUccLCgkT/u3cTST2FuoI F7uEixVUmFXCAxFABBABXQiY76yTkLOmaz8g+wEL+OAMLpuDG4xCwppcqEFQt2F12S6az+BqmJN1 b1rKilo2Nu2MyFPL5cV09s7bSZ6ktobPjQgB+NIdi1tAzeIdS8ETQzqF5VL4Cwt/UcstIk1xO15H b61rjmJlRAARAATMd9a6ImtYT/2q2gHl0YaH3FSkrpkt16MuGzLXbDUIR28wqjrr6s0tM9eS0Lam llcNgfPyRSTfUbrqIHO7smP6zPImmqhmbnf5rtDmGlJl+a6I1IgQgJfOKDvUfCzqtKJtxamDcxIR QAQQAXUEzHfWuiJrePIFctPKQ/lEjGg+n6dmSWqWA2FhNfXapCRKZL1iWvOaiFuI4ItrWUTtrqtT i3ZLV60pW70hZsxNpAWf7j7aVD5zuhRnKJHBrqyDMxMRQAQQAQ0ImH+DUdcTjBosDFc5f/Hciu37 NYqo3GCEZIYYVZdvbIHoWCih745JPqbhM7vNyNdhb0UVwqfMGshZT1t9iGNKpQXl5YcOHeKWvxFa 9JrQdqSkxt5gNUQAERjpCJjvrEc6our9ly4yQYQQAUQAEdCNgPlpEF05a932qgkkv0X9ZkPWWzUt rl8TSiACiMCIRAAj6xE57NhpRAARSDcEMLJOtxFDexEBRGBEIjASI+uenp7BwYG+QP+lwCXYJTs4 4Ltq1pwROfrYaUQAEUgbBEZcZB0IBAYHBoP+/l5/b5+/L+S3hC5kv/9WfdqMGBqKCCACIxKBkRVZ k5gaPHUgGPQHe/1BuACXHQz0wdtOe1vVHXeNyDmAnUYEEIE0QGBkRdb9/RBQBy/5e+EFbpp4anDZ 5Nzb7eE34U30oPlbGxpa/eyc6LaGV//I6enw4oytjxAERlZk3e5p7wv0CTF1sI9E1iy+DgYC/kWP LFSMesP6+Y/Vc1Xr9j5aYcqMAAfWmlvh8pFzWaEWld6m+iYveYC+sKySSbCS0SU3lfobZB/FVgiN H2gLhEKjXRUVLqdKXcOaVXTp76kWNLAOIjBiEcicyFrJfy0tYQNMYmpfb9AXDNIz8dRwZte+oNok qHh077oq02aHv7WVm1OWS8+aPDX10VWVlTeVjB7tzOXtKCyrKBkdgluj9AKcNu/E45jpbfqEm1NZ WVlVUeRp9apWNqhZ1VXr76lpMKMiRCATERhZkfWxpmbObyMJa5q2Jslrlr8OBL/qdT/0bz9SG2II rvfNMyuyNjiHIOT1FlaJDp685VxOlyu3NaI8hnYW6FINcAluO2psrVezwS6hGCKACOhCIHMiay3d 7h/o5m8t0huM5EXjaxJWj/bE1nBq+7IFCxbMn7++AerBm/lwLNt+Ct6AN58PH5E3DevDdbQYRHMa u3fvrq+XZLC9TVACR5MY/vp93U4xsAZvS96C2/XRCyc433qqQLjw0QuitqGhgWn2ezycRAPHhUQp 2hzffqRmFspHWKjUzLrJlEB6RluvsRYigAjoRcB8Z62LdU+vuar1tbd49XXfaO89DrcThbuLcEEW hJwYOPjQExtiGnPqvT1u17KX9pIQ+9T2n+5ZsHXv3r33nvgpeGiSKqkMVd67ZBJXPNnlWrZVexju bWrkZpPUxOy8VpaaAG/YyJVB0U0l3V7B9fn8/rzccJKZvi3M5XwecpHrdFXMLuKggnCRCxWKZtPk SNEcplmqgV4zKUugrcFbSHMjNIkdqZmUyCxUamY2UyUVrm53pt81NWXGohJEwAAC5jvr5DN16Gpx Xk1Nl919rucUhNjgec70trSP+fDHv9oYE7u2/1y29Hl3FXHH5Dh5wu3ecg/E0I/Xu0+cJCUVS+9v 29fANWx9vkSopGkwCstmc40simahM4mAXS6azy4S89pqgXUulwuV+YBbrMAuwueiIk4IysXQ3Ov1 FBXSdIivGxLe4eQKH7JHaIaUudRCVc1gc4BG1nD3UlOvsRIigAgYQIBuBotHDAT2r5s3b93+UAj+ Jf/AcXLbffyVRIxUm3fftpN6sPQ0vt3oIQLSi/1uHynyeTz0X+mnkW9BSCbuc+8nJUyb9BzyuRuZ WijmGwg3KposmKHUrKJTabyermNdRAAR0IeA7cknnzTg4mOIQJwL2VxzdcbWlsgWydK93RZL67tf 2V1tH7/y+xde+GraP3yv5rqTP1u0ctOLL76w337L7WVfI/YVT7Hv9y94/HvFOroOwXFTU1NbW5vX b4GcRq6rEJIbpxobj7a1tbbD/cPsUw17/3yUfOr3trW2ekKF+Rc/3NvcAZU9XFGx48IFR3HxOAcJ sqmeUxf7LN1nvgqGsr82OT94Ej5l5+JxznHc6b0Hm0AJ51pw1ViSuQjrAQ00lxFDM7Gh+0wHbC2U y+sUNEPruZz7w4+Iza2kC8KiFR04YFVEABGIi8DIWg0SF44hVGhYv+z40i18omQIelAUEUAEEAEV BEZczjphs6DiUfTUCQMXFSMCiABG1jgHEAFEABFIAwQwsk6DQUITEQFEABEYiZE18lnjvEcEEIG0 Q2DERdbIZ512cxQNRgQQAUBgZEXWyGeNkx4RQATSFIGRFVmnAp91qk0UZJ1OtRFBexABVQRGVmSt n89aBM1sYmtesTFKP2NSahNAhXWaeG9PkYTxGh4lpwRNoVDh7KoyTsGvbeyrpeTpNqZneKVYL0Sq cdEYGU2izMhoUsq+xNaTuL5HY1GHFpWdNWBGIvsFuhu9lggKeF0WJnRmauSUVwdZ3wOPGmrDI5Ea aplZhbUY+8zaO+3+8ovG48cOtHz2zmd/3vnxwf/+YN+W9+uffueNn7/58ppX4tkUft48Xk1zP09c u+wh9PCj6PQxd3hkXXiMPfJRd5/bTZ+NhxrCE+tD7aiJqoZqilF5Y10wJmXURoNySiONmW1MypjR POOCMWGJVGJsFrkeQD0jmlD5QkVt2vw0iHYOPF0/dzEqsxZjn5m4399FKVJhWy9yhm0HegNkZy84 n+09bpY9Jus5dbzNZI2iOqerDMj22Jk/CJNUUZGz20f3HPO3urnZAo02PP9OGaZkHIBDMc5EVUMx YyiyxrpgTGoodhqQVRppyGwv0BBISSMNWKJdhNBCUpqyIR6GehqnTfJtKhW/avxXDIgtZfhEbXpk cYN4v/qiv9MqbuXFdh5g23r15B29YX6UPWGApfrvf/Lii/8DvBq3/MPNhPwD+KwXrdwoYQaBxASp ImULoXUIfwiwidx8av38e9bA1S2EVGQjLSomRNi0kOkU3n711Zqf/ORFgXSkYf2iDR9Z2t5VVBOk 6ASJsIdXC3rWrBGVa5y7/lNHPLlXF1s8wXFAOkLeMfYRyeH3unlKkig6CcvIR83g87NP7zvY1Orh KKMJLREvmE6lKki5gEhMjhFQvw8IU+jh/uqC5+jn0raKmGapHtEeoXXBHo+nubkZ7ONl4kFE9JzO LvI1wtlVCLv+WMYBRIBGX9+pxqajbTwxiticFDdqDxgs1FFIKRtX0UOKWNdjIAR/xVMSmJj9ktkj Q4wZoxwdLeMl72lrw4en+i00BuAHXZgeCnz4cec77vcDS86pmIMjmy1E8EgH4dFpU++9mTNT01hE jKr029R38RQDBNTI8VGbG7SnkIgcWcfeN944sP3gnuf3vfXL3a+v3/XKY3/87aqXf75yVXQUgGOP kemJ6QhJCU+zp8xUQB1G0idS9KnS8skEBYY/sQVillK5rESoHZYS9KjIxhxuYNIjGQ4J+174jzVB UGTbi6HJ0wjbIfCUgKyaKkefTJXwt2GsP0HViArlbQnyfG9UWxeIBfX8uUvadrv3Q3Nw8MAQPQSy iD+/lf1iWIh//KpKKfGU6dGGvJzIUalWtFW0R4mYFDRRQ9zxUmrWqIfm1SLGi6KqwgwpGqPRZln3 zZqZWsZC0XT4GyEVV46ybEYJw2R+GkQXu3S8YEbT57pa1M9nDezVJVMYkTV/qPBZP7p33r7w3jFQ D+pUzSOb7E5askXcbLdqXXz+ECo1aUoJz5StBQHBwggp1rq+A6iuYTuCA7ubPBz5I03Go83HW5G7 1qg2EJUpW6TMZqGbbAMcLbzYhYVFHsIALm5nptIWy+RwHGzHILM5gvibz+rogqjb4yH5odDoEpYS Igpdc9iftiJjuLJfMo5yVSmlHXL8YYtMp5v0PcaGPAqGdBW1Cs50PvclQUw5OlrGSwsbu6oelfGi qKrOQH5MFaOsarOs+6bNTC1joYBeySmvgoZiRol88eY76+HKWWv/zt165913/tOShY9W/+1Tdz60 4V8eejL2HjHFk0vbjsP2XeHcMZRUPbWHHHTjGDgatm8vfhS2joG9Y5bSfb9gz5jSetiOAI5TDQ1k 8y9dB7RVOllOtgp7dKkrkViolNLRLtmWgGxSU1k5uwj244V9wPLC0iSzRt5FZNSEQlkj0ZOdMPHC +UvlBjhwE5wd6jtE8hvXwA7CleKeCdGTi2AccwKizeHWBalwHW04wSY7RYWhkJPplaCh2IonYmMf QbmP3QoQK8fOjMo+9Xq9sL0PGR2uMZq7ZqssoE5ZYShanhjUyuwR3kagETdjDRVk46Wqmdfj93qF ZqP0WjleWm6PxLE5QTNTy1jIZ1SuU/g6eb3d4UhBho9ybog4m790D+LcJPvrhLcIOevHd4dcrlK3 281VrQMHDTnipc+3Wiwh2MSLBMvk/ZZWslooVPmU4MCJFJTAZmBblpxkvNihUCUR54eRJ8uWFPIl 8HnlU3vEejSd/Vg9bZldy1VRe+Duxf3EGmkFiPcfq2c2x/FGZMVeW4CuQuPIWr1QaLSrogJ25IWl aaRfsMs67MtO64iaaKHsbg6vh4mHb1wK6/9AdnAwZ5yzp6OH1xOuSZd8BwhKZI2g6l0if2vTJxCA B6AO7HIzx9JI7JG3JegJr3+StC4VBGOEOpINhaMCBZ7Q7awo9TfAGbom7ekc7hPY69KpbpLYLzC5 oshLMaQ281IRQPGtK2HkS4SxiHITLaKnUWCU2MMPUQRi4YZIWxKcmWmxxkupmUiQtXQe+J0h00Ft eqi1Hg8fSsBOZ4tkBPnJKZ8PUSGlHxiZmcqxgJKou1CLE4otClRMbx6fqHOD43tqvrOO4xPw41gI mLeAOjNxlizP1fTtiIaCYpnvkLRlJtbYq1RDwHxnnfA4VwFh3BZfaXq5avp3x+SMCQ4E/3L6ozPd Zy4E2ieOmXjDpPJ8Z0GqDQnagwggAoiAEgHznXUKorxy54PN5w7PnnDde1/s6Qv1TRw/wZHt6LzY dbbz7PevvetH33okN1uSnE3BDqBJiAAiMOIRMP8Go661GabgH7fFTbf/Otue/ZeBg3nFo8dPz7eN t2aNtRZNu3zOrNl7jr+78IVbm88eMcUSVIIIIAKIQIIQGBGR9XMHn3nmg18Vziiw2+wOmyPbltPb HbTbHA6r3WqxZffmnL1w9nd378zJykkQyqgWEUAEEIEhImC+s46bQR6ixUx89zvvHjn8uVLVVVdf U/mdW2TlK1697+jgZzljsrNt2Ze6erPzHBbOOnHMFfAWXpaQ5f0P9le5vvtE5VpTbEMliAAigAiY joD5ztp0E1UVPv300z/84Q+VHz3zzDMrV66UlT/w6rJjtsPOXGefrz8/fxzx0dbs0xdPj7Pmj3aM ttuyg5eC73/23vN3vDB3SrwVbsnpHraCCCACiEAkApmQs55V9UjsYS1wFgxeGgQfDXkPcNMOW7a/ KzDWOq6j7+LEy6+4svCKGVNm3Fp267aPX8TpgQggAohAaiJgvrNO2hMxg6EQewGy0msl0LMKy3q6 e4O+3oL8AkdWtr/TX1hQVDxh8vVTb/j0eJPD6rh48YI9277/xHtnur7SP051KyzsWFHHC7OSuZvc yo9iq3dvmks1gah6RcOa9XcLJRABRCCVEDDfWcddm2Fi9+/4x1fgVTL1G+xC1MxsEM/XXXG9r9s3 bmw+eGoIq+EeY07n4FXvfVKy54NFbYGTr78/pWjqtVPLrrny2p2f/0G/edWbCWPLruVhSSiBt4d2 vD6dXizfFdpcrUGve9MvuK2U/WVN81J1d21Qs4bGsQoigAikNALmO+ukRdbdXZ0v/aISXm1ffMgu oISBLeO2dhWUOu1O7+mzdqvd3+GfUDBh4kctP6jOJ6+agm/Ye9uaWs61n/3mzJuPnFO5aWl0AJeX ca9HCZBVVbpf32GZUUo/ql5UtiOGrF7NRnuAcogAIpAyCJjvrJMWWQcCPewFYEqvldjWvf7HxaMW e/efObzz84sfnfe+f3r6RJI8Ycf114z6858+ck0o7Qp0Hzt/TCku5CbCaQ5OpUhlSBfN4L11iGPp C8iT8Be7yMXcuSzpwSdQjjUfkig51HxUlOKbE9MsnKiZCUSao9QsrRQ1w5IycxINQQQQARUEzHfW SYusxd7Uv7gq9tiea932o29/+ufVc975X8W/X3xZbTX37bnjQOS5356Gc+mU0TMLJh043DBr6rWn O08G+gKR2uo2rC7bRRMdXA1zl+5NS1lRy8amnUKeWs2E6oUzjh2FDywcS1/AIV6QN4u3siQJ0bxL oUCQqq1ZyrIjklyKoJkKRVjI9Eg1CzbvWNwSK8OC3w9EABFIZQTMd9bJiaxhPfWrageUq8L9eYtv 7a/bxDNz01cUZsP5zNnegoLJn7R8ctmosQV549vOt0ZqqN7cMnMtCX9ravkPIARevogkoUtXHYyd jC6dzh1pijr+ZXzSg68wfWa5pGr5zOn8u+W7Dq5i2RHJIdWstFCmGeTA5kOrp9FeHGpW+fMhlScp 2oYIIAIcZ76zTk5kDU++wHpq5aF8IgZG+dob7/v4C9fUGXPhXDzthv85PK6vn6RBFt4yHs77PvIF +/tKxpe8+PYL+bkFNpstcmLUrZjWvCbiFiJ41VoWUbvr6mJnpUunXyWfZu6jqu7bwpUuXCwE6nU7 mxYvVDhombcWNSstVE5tsBlCeHZoutuJ3w5EABFILQRi7M1k7KPh2t1cl7UvPvPg7/59fven3z/w ym3/5xd33PzT66/ZWFrzUuV1T199zndWrkq60KN8I8klCCX0nfRjGNzlb4RLwD+2bBS8JFyRsS8v p//cdhtNgLA0CD3TvAoLrlkrEXqYUWJbEZojTLjx/rtUNId1C8p1AYaVEQFEYJgRSNcnGIf+i1f7 m18xJcsf+Gc4d/R0HDvX7G5vuWvOD2wWWXA99NZQAyKACCACQ0LAfGedHG4Qaafjtoh81kOaIyiM CCACKYCA+c46BTolNwH5rFNwUNAkRAAR0IWA+TcYk7MaRBZZx+4z8lnrmhNYGRFABFIQgRERWSOf dQrOPDQJEUAEdCFgvrOOm0HWZV+0yshnbQqMqAQRQATSBQHznXVyeo581snBGVtBBBCBFEEgE3LW yGedIpMJzUAEEIHEIWC+s07OE4yASArzWfMMTHKa68QNI2pGBBCBTEfAfGedzNUghvmss7Mc2VYH cFuPH3U5UDiZzWft5haxJxvJc4ktizg9RKmZPuOwf4gAImAIgTTOWd999xLW5W/euX7/7x5l19u2 bVfuwTgYGpz7zNfzx48rdZUGOnsmjC9yZOV0XuwAeuvJE6bsa9p747QbQ31ctjXnaNvRX93+rCEk gZh056II2g1liSHFKIQIIAKIQCKInJIWWWvns7ZarBuqf+n1nj1+/KTVaoX9YrJtjiyrvbhoMuzp 9b3rbz94+GAi+KwlE4zf34uQSfOX3/0uJbJeIewAxlfmqamRdRq/nYgAIhCBgPlpkKTlrMV+xOWz hprfKpn/69uf+/LMl+fb27Ms9osXOiYXTSbbnNtymo42Xn3lNQnhsw5DzWisl68BrlPgvyM8TW++ SUpquUWEYonj94UBpmxkncavKCKACKggYL6zTk5krZfPGrp+05RvPvdXW770nH5t305/r9/fE4A0 iPe896ZZN5dPn5sYPmsp4tUP060KyE4BxGezg/Jil84o4zmmkXUav6WIACKgjkC65qwNj2d3b9c7 Lbvrj7156NSBvNF53551y4SxEwvyCt798J3+/oELfRfWfvvnV11+dWQGgyWjxRw0pCoIxTUUAZ81 V11NPa+WnDXUqamFsJrfTEAQAX2wFwwphKsNM+JsaGC46yiICCAC6YyA6RStacFnDb3u7Ol87fM/ rH/3Z/e+fPe85+aayGfN9gATNjsXKf95vmrJ+zARdrhQYLRG1mnTZyYqRATSGoERF1lH+2FNCp91 3Yq5Rx8O79GFy0XSOcxB2xGB5CJgvrNODjeIFKW4LSKfdXInFbaGCCAC5iNgvrM238Yha0Q+6yFD iAoQAURgmBFI19Ugssg6NorIZz3MswybRwQQgSEjMCIia+SzHvI8QQWIACIwzAiY76zjZpBN6THy WZsCIypBBBCBdEHAfGednJ4jn3VycMZWEAFEIEUQyIScNfJZp8hkQjMQAUQgcQiY76yTxg2SwnzW jKsJyJh40iYgbKqLP4asspaa8XVhDUQAEcgwBMx31snhBmHDkKp81oy26dCO16cz/qZdEdSp0aYQ k8IDEUAEEAEVBMx31kmLrLu7Ol/6RSW82r74kF1ACesis0E8uwpKnXan9/RZYG7yd/gnFExw2HI6 OjovXrhw7dRZVs7W6e841372mzNvPnLuc/OmyfIy7nXcdsA8PFETIjCiETDfWSctsk59PutFM3hv HeJJrCHFwec6dpGLuXPnquz8tVOWDYlguBZSJXwh5kxG9LcXOz+iEDDfWSctshbHKXX5rKsXzjh2 FOy0cGKKIyLXsXgrS5Ls4mpEt8szXDethX0K4JAxXDPx2hpg6SOcNED8hwcigAiMCATMd9bJiazT hM+6dDp3pCnqRCqbIdBaS6poYbhevivMBjUipil2EhFABMx31smJrCu/cwvstag8oDzGoH5j0o3v 3P/eI998rO9C//bdW59/s7arp9PT/pWvx1cyvuTFt1/Izy2w2WyRGupWEPJqKesp7PVSC9sIkLi3 ri52Vrp0+lVye9xHo7tvoS7UKZ85nbyDtkT+VIyj8QuLCIxgBEwneEU+6zciyKyBoJr3tjxVdXl5 OZlvt91GEyAsDcL2QQcW7I3sQ9hChr7nObBZUfnGY1Fosk0fRFSICCACqYZAuj7BaPrPa1L4rE23 GhUiAojASEHA/DRIcnLW0vGJ2yLwWXdd6gKR4EDw0IkDf/js9//xp9o3m99o958X9Vw26rIbist/ cN1Sm0WWBhkpUwH7iQggAqmMwIiIrJHPOpWnINqGCCACWhAYEZE18llrmQpYBxFABFIZgRERWSOf dSpPQbQNEUAEtCBgvrNGPmstuGMdRAARQAR0IWC+s9bVvOHKyGdtGDoURAQQgXREIBNy1shnnY4z D21GBBABXQiY76yT8wQjdDLV+ayBzhqYPQhVk2G6JVWGa57DidBlxxlqJMjW9V3AyohASiNgvrOO u+rZRDxSlc+advFQ8zHuWPOh2N0FfxrDlaswXLs3/YJxOIXWNC+N466RINvEuYaqEIFhRsB8Z520 yDq1+azhofKmo3VA8SE8P6460Fp4QiIE3a/vsPD0T9WLynYgX/Ywf3+weUQgaQiY76yTFlmnNp91 WVnZoeadzdzixWXCYAr5CzGWBoqo1YeA71QaXCsqgTRjuKZpj8hQ/VDzUZEpW8ZwzW8oVlMrTiXk xU7atwobQgQSgID5zjppkbWIRmryWS9atLy2trZsxgzBzroNq8sYW5PAXs3SFNJNv4C9mlVq2djE eP3goAzXoV1lqzfsUswAgSlbxnDt3rS2aWOLlCkQebET8O1BlYhAEhEw31knJ7JOAz5rIDfleJ5T OqDVm1tmriUhsiTalY80BM6Uz5orXXVQJERlJewgSsNHWL2M4Rr0yMiyoeTQ6mm0dZJMZwfyYifx q4ZNIQJDQ8B8Z52cyDoN+KxLZ5SVL14Y3l5AyYstGbq6OhpHx2HKtnClCxcLIXfdziap+oh5AHqa jkLWJJwTR17soX1RUBoRGHYETOdsRT5rymcNyY2WjRshoyFyVdNL8SinWQpxTwORvlqoQz8XBRjn NYmF3wC1LLjmNUjrSAaTFfO3N6l2QQ55sU2f86gQEUgCAun6BKPpP3LIZ206pKgQEUAETETA/DRI cnLWUgjitoh81ibOGFSFCCACw4LAiIiskc96WOYWNooIIAImIjAiImvkszZxxqAqRAARGBYERkRk jXzWwzK3sFFEABEwEQHznTXyWZs4PKgKEUAEEAGGgPnOOjnIIp91cnDGVhABRCBFEMiEnDXyWafI ZEIzEAFEIHEImO+sk/MEIyCSwnzW8OggJbJmh2E668QNO2pGBBCBdEPAfGcdd9WziRClKp81PFm+ Y7H4hOJM8uA3PWKzV5sIDKpCBBCBTEPAfGedtMg6tfmswzxK1atW8QQhutmrM222YX8QAUTAMALm O+ukRdYpzGctEuxJMyAx2KvZDl38LlwrwuzVhocVBREBRCDTEDDfWSctshaHIhX5rIHilDC7LNoZ 3ipRlb2aZUvYDl2sAmWvbtnI4S4wmfZdw/4gAkNCwHxnnZzIOg34rMm4gP9d0zwt2h1GdY5pwl4N 9Kph1ukhDTAKIwKIQGYgYL6zTk5kndp81u5Nm4RtXup21kp3IOBvNIrs1SI1qrjVAK0B2W2lVGbM OOwFIoAIGEPAdBpW5LNmJNbiIfpjFfZqCcc0XTwSlouUMn2UUCEigAikGQLp+gSjsV+mGFKpwWcN 9xh3LgpFRtmmdxUVIgKIQBoiYL6zTg43iBTquC0Cn3XV9O+OyRkTHAj+5fRHZ7rPXAi0Txwz8YZJ 5fnOgjQcNTQZEUAERhwC5jvrFIQQ+axTcFDQJEQAEdCFgPk3GJOzGkQWWcfuM/JZ65oTWBkRQARS EIEREVkjn3UKzjw0CRFABHQhYL6zjptB1mVftMq733n3yOHPlZ/C+mtY1ScrX/HqfUcHP8sZk51t y77U1Zud57Bw1oljroC38LKELO9/sL/K9d0nKteaYhsqQQQQAUTAdATMd9amm6iqEPmsk4MztoII IAIpgkAm5KyRzzpFJhOagQggAolDwHxnnZwnGAGRFOazZpRMiSOzNka1akwqcXMPNSMCiIAOBMx3 1slcDZKqfNYiZ1OoZeZaRqln6gH64z44o3TNWqRMNROVIQKIgHkImO+skxZZpzafNT9EpQsXDw9/ HnJnm/clQU2IQCogYL6zTlpkncJ81pKRlfLn8Xt9hUPtcLpELBP3AyNUfTzDdR1fyNj7hEK+EVUW bCV3tkyKCkfYI9WDG5GlwncTbUAEIhAw31knLbIW+5GKfNYq08y9aamUvZq43Z21Al/TQbabDNRZ XQZEUEBo3bSzTmC4rlnKbSWcMyz1wXIs4qHKgq3kzpZJsbaoPS2Ld8jYtAkNN/pr9BSIQGohYL6z Tk5knSZ81lKyUyV7NThQcItwiHE11FlO+Kw52LxAzEov38W78hhTh0rpY8GGtujeYxFSrHU8EAFE IOUQMN9ZJyeyTm0+6/Awu1/fwS1eSKPm6TPLZezVdZs2Td9MQmZxgwKoUwsRNYl76+p035dUZcGu Y9zZygPaaiJb+SJ3dsp9K9EgREANAdMpXZHP+g1pmkLKSy1nrxbfc5xYTchwlG+EDIWY7pBqURZG Y8Gm5byomiq+fdpURFusMlJqm/7lQIWIgHEE0vUJRtN/eVODz9pYt5AF2xhuKIUIpBMC5jvr5HCD SDFOfovpNMJoKyKACGQEAuY76xSEZbDP13Vo9cCl9r6Ah5mXNa6s4ObfpKCpaBIigAggAqoImH+D MTmrQWSRdZzRDQ0M9Jx2BNucWYFcR1+OxdfX/nHvuT+rvnCiIAKIACKQggiMjMg62Hnu9Qob1wsD MDDQb7XaB/p8HGchLwucrfRsycotzsqbfNm3XkrBcUKTEAFEYIQjYL6zTk4GWRef9WCw88x/Fedf +XXOaoeXxergrA6Lzc5Z6DVcQDm9bm95rfCvm0b4nMDuIwKIQAoiYL6zTk4ngc/6gQcfVLb1m2ef XblypaycOuvJ+cU3cDaHxQKemrps4qMd4KOtNnuIFlqtjjMfbrjyH7qT0wVsBRFABBAB7QhkQs5a a2/BU5OYmgXX8MqmLhtKsuFstWWDK9eqCushAogAIpBcBMx31sl5glE3SiQ7TeJoSHrQmDo7BHkP CwTaJAFCQ+wscmHkEOmYRD4NCZ+15FnySN1KKWXbWvTEshgZrI2MJ8ogAimJgPnOOmmrQYAilfFZ iy8oYSAzG6Rnci8RfDRNgwgxNfXRLH9tzSJhNVQwcgDFh/QJQFAR5rMGRiZu9Qa1B76VUsq2teiJ bnHdirVN5UY6hDKIACKQegiY76yTGVm/9ItK6UuEl9kgPcNbyIGQ7AdkqFn2A7w2c980eU0/Te00 SPnM6TomkHvT0UVbF+sQwKqIACKQygiY76yTFlmLfNbSi1hYs3UgJLLm09Y0rBbSILRQVTyCYprV UClSitbWAKHeNKA8Bf48kU5ajVdaKqrgvOY4qgdYUgXuPWXjSl5s96ZfcAsjCPRUuLNTeWKibYgA IhCJgPnOOpmRtZ7RtPCumdxRpP6a3m8kL3JB89dwy1HlqNvAKKZDu7galpWWsU5HswKIkIARicXD Ip20klc60lXLOa/hU0qotJVbyhOpKu1R8GITV/0IY8gWDiV3th7wsC4igAgMNwLmO+vkRNZ6+azt Y6bQgJquAOHz1CSshusQS4AQJ64aWVdvho0UCet0TS0/Wqqs06ojWf1wtJS1+sArOa+FemHWaaU9 Sl7sGdyOaTSsPwRhOf2FUdYZ7qmH7SMCiIAeBMx31smJrPXyWWc5Jw4OcqHBgdDgILwGBwcGB/vJ eaAvNNBPzv3B0EBQNbJeMa15TcQtRB2s06Wr1iyvXRuxZW6s3RGVnNeCRWHWadiyS2aPghe7tLr2 ILEYOFAhLKe7GCi5s/VME6yLCCACw46AcXbVKJIpyGc90Nvp++hf23ffcXrbFXFfKt2S7qIVSf4c yTrNBnO5hM+aZDAoa7R4wXHl5XSJxm23RYy9QB4t4bw+FrF9l4ReOtKeY6wFvnGasKGHWEpVq9cx ffRRISKACCQIgXR9gnHYf+TQAEQAEUAEkomA+WmQ5OSspRgZbtGwYDJHCNtCBBABRAAQwMgapwEi gAggAmmAAEbWaTBIaCIigAggAhhZ65gDPT09sICkL9B/KXDJ7/cFB3xXzZqjQx6rIgKIACJgFAGM rLUiFwgEYKVf0N/f6+/t8/eF/JbQhez336rXKo/1EAFEABEYAgIYWWsCj8TU4KkDwaA/2OsPwgW4 7GCgD9522tuq7rhLkxashAggAoiAUQQwstaEXH8/BNTBS/5eeIGbJp4aXDY593Z7QppUZFwlf2tD Q6ufnTOuc9ghRCDlEMDIWtOQtHtgZ/Q+IaYO9pHImsXXwUDAv+iRhdG1NKyf/1g9V7Vu76MVmprS WAnU7punW6cxKTWTwEm35la4fORcVuhtqm/ywj6WXGFZZVlhuD6UewurpCUau6ehGuhu9JLNM+WN QgmzR2aMBp2kiiGbyW+Wp6iiwuXkW/E27W7ywnUoVDi7qoyLgo9Gk8Rq0XDWq0elvmCwzGa9GCLy JoxFNBWmP2yTgk8wRusjmMqsjXYWBU+7v/yi8fixAy2fvfPZn3d+fPC/P9i35f36p9954+dvvrzm lXgY7l83b93+eJUS8Hni2vW5G92+EDuzw+fev198o6cvxgRB6u1GT4x2jKnVY7i0LjHn7bBBnkbx 2ud2UzNNtMdEVWIfmJm85qHZnAjzoo9L2iOvY8qZnwZJDjeI9LfHcIsgqGS+lrFgs4b8/i6arYY0 CDn3+np7AyQTAuezvccT+Fs6FNWnjrcNRTyWrNNVBjEkO7PD5/fn5QpvdDTrbW01IgjNFRVKQnhF i0bt0WF6uKrf4+GKipzdPpoP8re6udnCXxNOl4uaaaI9JqoSu8DM5DUPzeZEmBd1VNIfeR0Tznxn nfzHAg23qF2wf6Cbv7VIbzCSl48/c6M9UfFuWL+AHI+Hl4yc2r5sPhzLtp/ihSAxQessCJfROqRk fQPHwedwrG/gBUlRuDCsg9RZT1UJqhvWL32+1bL7MaqFHoIqqbkR9vAVQA9pUccsAgfl63Y6c6Ui kBior6+PyGeTot30gCQFc2sNjR6LxdsYO+0Nf6GDCC9DpUgChJRG6pc0T+zhvMQC1hI54C90qkds TM0euc1EjNkcViRHhnoMV2EeKyfvIqEghQp8ZEpEuFhnG1p9YokMSaUqGT4UoAicNQ6lTLOAYUTf 5W0pVI9o5FWAhsFgYwHH2+9/uJ9NMGGU+bs9UlQV4y7MhAbIqeGhCYG9b7xxYPvBPc/ve+uXu19f v+uVx/7421Uv/3zlqujCJ7fdd9+2k/C5mI6QlLBPwh+JaqAOS5rABUuegPi8eXx9sZosxUHqkNpi C+rKZVJC7bCUoEfFsJgoSf7wD9eTFWqpo2xE+KsapMN5FlVVUlmoQKuH/yYXRZQXMkFpekVMt8BF tLQLb5mg11g3wQZPI3yRI5I7qqbK9AuGqfRU07yWVFKOl4Ahb5WyLWUTIxl5VTTYtJEMpXyUlTNc da6+3YiRtcaog5tXU9Nld5/rOQUhNvyld6a3pX3Mhz/+1cbo8idPuEumTJJ+DiXuLffQWNt94iT5 pOLRvfP2RcTaUKdqHrkXOWnJFvGeZNW6LUsiNKm0SqUmTSnhNWvpl2BhhBRrXd+hGjjKCwvLKpzu cFjNwtC4ESfLMHBcrjOcZIkvBWpdc8QcDWmpsGw218giZP5vAA32kCiZz2MUzYlyn9Tr9VgCbQd2 N3k4kgfRBIUauiA4uuQm6d1YUZVUpzz89XgCNC470Bbgtar1S8twqgTWAoYMMUBD3pZqYD1ikVei XFhY5CGzTrzPrjLKihmuHHdS4nKZ76wNZ5C1zCfVOoZb1Ct465133/lPSxY+Wv23T9350IZ/eejJ DTFtLp5c2nYc0h3h3DGUVD21hxx7+YUcDdu3Fz+6F457TyxlmQeoU7+PXp1qaBCSJZqxgbZKJxfL qjc0RMlpSCxUSmluEypG5ClJGpoIy5KXXq/X6aqorKwEpymmFPg6fq83zvI/UMqctopmpaVC03xK EyqwNR7QellhiCXXY9kjaAQ94iVLSCsO8NVFZaAX+lUEj7VCBoRPh5CaqlAIhTJVylyvpBfhvL6s GryFBRvsYGtRVPulZTCVmhlQYrmyLUReirzK5Ghq5GaTWSf+BkfP6IdnuHLcWYn5S/cgEazXCWqZ STHqGG7RsKBWgyFn/fjukMtV6na72eo9yBGTVLIl5Fq2lQTL5P2WVrL+LFT5lODAiRSUuJa9tGXJ SVj5txvqhyoli//IcsDIQr4EpCqf2iNZJEgXDvLrBpVS8INA7HFzpfcTa6QVIN7XuOKQrFprC5Au sCNUWFZVlssKQ6HRLn49W7garSDeHCQr8DzgxcOr3iLRpQu5AxZxHZ5ET1i5bEDCdcIrzyKXppVV ufyC2YI9vJTEZpofp62HRpeoWciLkFY4slaPyea28gsZpVBE4iO7N6rWNPG7/Po/uBwczBnn7Ono 4XEOGylaSNcIFlKL2XBI+vUJNycavswumQHSt3O4TyDJSkeIE9Dg21J+D0Yy8ipewd/a9An8OUK/ CCU3zbE0yr4UIvbSGR4x7lJB8521VkeG9cxEwLwF1GZahboQgZGMgGTJPvyKxf3FjAoVr8f8NIj2 JRZmDaPhFg0LmmW5eXog923uQzfmmYaaEIERioDkT8gYfzvGB4fXg5F1LKgudl1YsXWPhRu0cPwz 5ePswWeX3x0fXqyBCCACiICpCGBkHQvOvv6+gZDVNu4Ky2UTQ6Pz4XUh6Hjnw/dUX6aOCypDBBAB RCACAYysY02Isxe8D/z2gMYp8/uH7tBYE6shAogAIqAXAfOddcKXWCi6qKvF3e+8e+Tw50qYrrr6 msrv3CIrZ87aOXGq1cLZrRa7zWq3WBw2SxY9kxLystptlr0ff4rOWu/kw/qIACKgHQHznbX2toel 5tNPP/3Agw8qm/7Ns8+uXLlS1VnnXjEVnLKDd828dxY8tcVusTps3O6/oLMelvHERhGBkYLAiM5Z axzkLOqm4Ry+sJDgGqJs8rJyUK5RFVZDBBABRMAYAuY76yQ/EQPdTnSLgqe2ZlmtNsFlMx9NXiQr YgzGuhUWdqyo40dPLCGlcze51QZVKaWspUVPrAkD8qJNxiYWSiECiIC5CBjzMrFsSP7iZb0tdnd1 3vGPr0hfUAJdYnqkZ9ZP3ilDfE3iaCtz05D94MtpcG3oqN5MKF52LQ8LQwm8Xb4Lils2cqs3CE5c ql4ppWxci57oJtetWNtUbqhHKIQIIAKJQsCgm4lhTqLjXGXTBlp86ReV0hfTqeS25p01JD0ggraA j+boWUiJsGQIfZuo8TFFb/nM6Tr0uDcdXbR1sQ4BrIoIIAJJQMB8Z603zh16J/W2GAj0KF8xzBBy 0yQNAi/2lmQ/wgtC1J21e9NcWZqDUylStlxbA2LTVpft2lzNsYQG5CTEiyiW8pqluROqZym39eCq UiqkbDycLhHk3Jt+wS2sHvqgoAZEABEwFwHznbWBOHeIXUp0i8LCDxJZ0xwIuGwIscWEdbTIum4D +Fua6OBqWAbYvWkpK2rZ2LRTLcXBkIA0CCRDWDzMEhrSC1W0QPOOxS2geU3zUjHVTdMpW7mlvCNW 2lO3s5bWgYM5dOKqH+Fd+xBHBcURAUTAVATMd9Z649yhd0dXi7Ce+lW1A8qjWUJuKlLXzLw2ddmQ uWarQTh6g1E1sq7e3DJzLYmLa2p51ceaDy1fRMLW0lUHIWqOcVQ/HC1lrS4Emg+tnkbbOtR8TFqn dEYZX6K0B34JFu2MuJc5g9tBtExbfQjCcrzHOPTJiRoQAbMQMN9ZJzrOVfZcV4vw5Ausp1Yeyidi xIbo4zDs7iK/Yo8Pq6nXZmlrtfGoWzGteU3ELcTpM8trWUTtrqtTXeoh6ildtWZ57dqI9SDuo01R hx00CzFyKPJnAKT4nLXSnrpNm6bTm5xrmqdRz1xaXXuQvG/ZSNTF/j0xawqiHkQAEdCCgPkPxeh6 nlCLiXHrJK7F8xfPrdi+P64BrILKE4yQEhaj6vKNLZBqEErou2OSj0HB8jdCi17jBYirnL5pLklc 8xeHuPLy8kOHDnG33ca99VbYJsGpQkIa4mEoL9947OCM/xtumGRVeLcbac+xgwvf4GVo6kXwzaIm 9Ncahx6rIQJJQMB8Z50Eo7EJRAARQARGGgLmp0F0ZZBNgXsktGgKUKgEEUAE0hcBjKzTd+zQckQA ERhBCGBkbWSwkx/LG7ESZRABRCCDEMDIOhmD2dPTMzg40BfovxS4BDtgBwd8V82ak4yGsQ1EABHI FAQwsjYykroi60AgMDgwGPT39/p7+/x9Ib8ldCH7/bfqjTSMMogAIjBSEcDIOrEjT2Jq8NSBYNAf 7PUH4QJcdjDQB2877W1Vd9yV2OZROyKACGQKAhhZGxlJ7ZF1fz8E1MFL/l54gZsmnhpcNjn3dnv4 TXiNWKBHxt/a0NDqZ2c9cqleN1P7leq4o33DhABG1okFvt3T3hfoE2LqYB+JrFl8HQwE/IseWaho vmH9/Mfquap1ex+tMMU0cGmtuRUuHzmXFWpR6W2qb/KSZzILyyqZhFgC16HRJRUVLqdCkVJK2Rar M7rkplJ/g6wJLYZF1NHfL91NoAAikEoIYGRtZDSUzNfRuLBJTO3rDfqCQXomnhrO7NoXVGu74tG9 66qMGKUq429t5eaU5dKzJk9NfXRVZeVNJaNHO3N5nYVlFfC25KbKysqyIr/HoxagK6WUBlE9IbjF KirUbJRMmZF+mQYqKkIEhgMBjKwTi/qxpmbObyMJa5q2Jslrlr8OBL/qdT/0bz9Sax6C633zzIqs DfYPgmBvYZXoS4W3EM9+ws1Ri6xpOzIp1djay7mcLldua4R+g1aiGCIwchDAyNrIWOvIWQ9087cW 6Q1G8qLxNQmrR3tit31q+7IFCxbMn7++AerBm/lwLNt+Ct6AN58PH5E3DevDdbR1BRzq7t276+sl GWxvE5TA0eQVVPh93U4xsOY4eMt5oFJ9g6dojssJLrueKhAvmJxMinpv2pagmFaACN8nqRlhD1VI RBoaGhQWhvVo6ynWQgQyCQHznbUuDjxToEzlFq++7hvtvcfhdqJwdxEuyIKQEwMHH3piQ8zun3pv j9u17KW9JMQ+tf2nexZs3bt3770nfgoemqRKKkOV9y6ZxBVPdrmWbdUehnubGrnZkM6omp3X2kp9 M/jHRq4Mim4q6fYK3trn9+flhhPT8LZoNklgO4uKoNTpqphdxEEF8YL1RCYFmr2FoLjC1e1m9zZp hcJczucR9MvsERviiuZILZTpMWXeoBJEIK0QMN9Za486zQIqxVucV1PTZXef6zkFITb4ojO9Le1j PvzxrzbG7H7bfy5b+ry7irhjcpw84XZvuQdi6Mfr3SdOkpKKpfe37WvgGrY+XyJU0oRnYdlsrpFF 0Sx0hhQ053LRfHaRmNdWBtakcmFhEeSbaTNiBWlNuZTHE6CR9YG2ALONr5ALjQqBe6Q9rAI5FxVx QnAPFsr0aOopVkIEMgwBtk8IHqmEwP518+at2x8Kwb/kHzhObruPv5LYSarNu2/bST2mexrfbvQQ AenFfrePFPk8Hvqv9FPZW4W4z72fVxhDSjRQEId/VcwAw1gF6VmpVk93sS4ikDkI2J588klzf34g zoXcqrk6Y2vLrBbJ0r3dFkvru1/ZXW0fv/L7F174ato/fK/mupM/W7Ry04svvrDffsvtZV8jiBRP se/3L3j8e8U6wIagtqmpqa2tzeu3QC4i11UISYlTjY1H29pa2+G+X/aphr1/Pko+9XvbWls9ocL8 ix/ube6Ayh6uqHhc0HPkyCm4mORgek5d7LN0n/nqoufoYYkUqengcnM594cfEc2tfqcr19sQ1uO4 cMFRTOtI7Ok+08Fx1tzi/OBJ+JSd5XrAYGGJio5eY1VEIAMQwNUg6TuIDeuXHV+6hU+UpG830HJE ABHQggDmrLWgJK+T/Cy5mpUVj6KnNjJ6KIMIpCUCGFmn5bCh0YgAIjDSEMDI2siIp0ZkbcRylEEE EIE0RQAj62QMHPJZJwNlbAMRyGgEMLI2Mry6ImvkszYCMcogAohAJAIYWSd2RiCfdWLxRe2IwIhB ACNrI0OtPbJOBT5rIz1MpAzyUCcSXdSdsQhgZJ3YodXPZy3aYzaxNa/YGKWfMSk1bCN5qLUwZUcb obgUf1GaBzIqCSM3PBBPaaZCocLZVWWcgsvb2PzQwu5tTLMuKWaGyEuuSzYJlQ2NoHG7UgQNw2Zg ZG1k7BPJZy3aYy6xtVRt3G0NwDVTqr/wAcbEldKCpJyHWgtTdjS9wKCtmw6bknELBCc8pStQTVG2 KcJbNWSibd5YLezeWvAaYh3WHQl9okzfMG8fpBjBxNoTD40hgq1VXLMZcjTMd9apzIGnFc549Vgf Y5+ZDr+/i1KkwrZe5AzbDvQGyM5ecD7bezxeO8P0+anjbYlq2ekqA6fIzuwQmPqAvamoVGUHGlMt IaxVwBvY7aMcgP5WNzdb8PfwrD1ls5IxBw6leRNVGTYjpg1eIAKQkisabsUkwYTbkwojonmOKdBA bhAj80w7G4n3qy/6O63iVl5s5wG2rVdP3tEb5kfZEwZYqv/+Jy+++D+tnOuWf7iZkH8An/WilRsl zCAQ/ZIqUrYQWofwhwCbyM2n1s+/Zw1c3UJIRTbSomJChE0LmU7h7VdfrfnJT14USEca1i/a8JGl 7V1FNUGKIhZhD68W9KxZIyrXBqzf6z516jRhJhl7wzcmOagQ/J14sIkwkzCOEcriShhL4GgldCZA KAIFHzWLn7OmIKEBYm1trIra4T91xJN7dbHFExwHisk7xj4iOcAenpIkiv1i09mn9x1sAhspewo1 RrzgrVaoohaCg9TKcCK2FaFZgYbQd6lmqLTvz0dbPd0hxzh5H1nPoMaHp/ot9PdLBCG2hbw9Hk9z c3N4dHjk+daj4EMoYjwgeKqPNaYcQVV7lIMgtVDRVrgjkYIqaKjo8fuBJYcw38DcIBMMbIahAlIb iqQEJRFAMu5yNBSzVzEzhTl2kc1zplmGvAoafkjV4ZFYBPa+8caB7Qf3PL/vrV/ufn39rlce++Nv V73885WrorcKHHuMTE+k3ZOU8DR7YUY+QQ/UYSR9IkWfKi2fTFBg+BNbIOqUymUlQu2wlKBHRTYm vBIiPkYHGMEHKGMIlGoSCQBZoUj/Bxe8IkW7IEIIBpVNSmrK1Kra7mmErRfCZIOqNivZAgXD4F+e 5lDLvFOlSZR1UKmZ76kEzCgdieiFYJkorSIkECaGe6HWegQ+IokidFsKrxLquOArLVSOhdJoJRqq iNHJIc4OcULpQ0M5XsqZKQLCWmSzl45pxNyQoeFpND8Non2lhLbQK36tFG9RP581sFeXTGFE1vyh wmf96N55+8J7x0A9qFM1j2yyO2nJFjG/XLUuPn8IlZo0pYRnyo4POG2LWhghxVrXd4gU2LCRAZ+c UDBuk0Sy0022jwnvZCPflEaVlVtmitfrsQTaDuxu8nCkKeW2NiTcjNwhRz0+93XDfpTSfLkxdm8t SKloVqCh5PtmhOCQaIrdHSX/OMkRcRyMRTTbiAifL+KrqLYuxUeVo1wV6rjg81ksiYUgIhsLpeVK NNQRc8EeSGHEnK7SIpgmkCrrph+oHUo0YK7G5YsnUt1uuK1dNJvfH0+VsV2ORmGZ+c565OSstXzZ WJ1b77z7zn9asvDR6r996s6HNvzLQ0/G3iOmeHJp23HYviucO4aSqqf2kINuHANHw/btxY/C1jGw d8xSdjMQ6tTDdgRwnGpoIJt/6TqgrdLJcrJV2FtLXYnEQqWUnnaFJCLk55ij4LdxJFvzFoZYPtXr 9cKONFACXwPRXSu3shGa9bGEtOIAX11ENsQBPXQPBWduXrgOyQ+SdxFqhUKZKmXiU8y7w+1LMQes tBBWZUhvZmrBSalZiQbUkWmGEqqc3E6NkZPmlfu93gjEwmOhtFA5Xqqty3YZgrdMUIpJVBjl9qgM pThbtCShlWjEsFmisLAwr7WB7WMXZai0zF6hdTK52MyEEn9eKdmYid8/iZQo54ZsdGDczV+6B3Fu kv11BrYIOevHd4dcrlK3281VrQMHDTnipc+3Wiwh2MSLBMvk/ZZWC4x9qPIpwYETKSiBzcC2LDnJ eLFDoUoizs82nixbUsiXwOeVT+2RLPigCwdpyzS1rVBF7XFzpfcTa6QVIN5/rJ7ZHMcbkZvdbQHS BTjCy8uEtXSkayFYL+DyC9XIO3I/kBcMhUa7xDV49M55APo7ukSyLk+0gBchrXBkrR6ThV17YWUb aYhozpXaIxTKtoRXaxqqSmweHMwZ5+zp6OH7FTZStJCuESwkvWjNrYi3niUCDQgi51gaedAENBge tO+85gh7IlCSjwjkVxs98EvIIjxBT/SlfuEhC9eRtC4OlqRR+Bi2WJ7DfSKeobEoMJJfaok9yvkT YWE0JcqfaX51Jp1RdM5wYcQibQY7YWtRHhFmetTdoYV5GGP2koGWzMybKoq8dDITM1x5wCqvtIfO DXZI0SBazHfWcb6h+HFqIWDeAurU6lfKWxPPE6RkB5K8MHpYMYj/Y5psNMx31hkY5yrmTNw+vtL0 ctX0747JGRMcCP7l9Ednus9cCLRPHDPxhknl+c6CYZ2D2DgigAikJQLmO+u0hMFso1fufLD53OHZ E65774s9faG+ieMnOLIdnRe7znae/f61d/3oW4/kZksSpma3jvoQAUQg8xAw/wZjiq/NMGUI4/Zx 0+2/zrZn/2XgYF7x6PHT823jrVljrUXTLp8za/ae4+8ufOHW5rNHTLEElSACiMAIQQAj64QM9HMH n3nmg18Vziiw2+wOmyPbltPbHbTbHA6r3WqxZffmnL1w9nd378zJyklI86gUEUAEMg4B85113Hyu 6Rgmp8Xd77x75PDnSuOvuvqayu/cIitf8ep9Rwc/yxmTnW3LvtTVm53nsHDWiWOugLfwsoQs73+w v8r13Scq15qOBipEBBCBjETAfGedkTBBp55++ukf/vCHyt4988wzK1eulJU/8OqyY7bDzlxnn68/ P38c8dHW7NMXT4+z5o92jLbbsoOXgu9/9t7zd7wwd0q8FW6ZCij2CxFABPQggDlrPWgJdWdVPRJb rMBZMHhpEHw05D3ATTts2f6uwFjruI6+ixMvv+LKwitmTJlxa9mt2z5+0UjzKIMIIAIjDwHznXWS n4iBIUtai4OhEHtBo9Jr5bSZVVjW090b9PUW5Bc4srL9nf7CgqLiCZOvn3rDp8ebHFbHxYsX7Nn2 /SfeO9P1lf5ZV7fCwo4VdbywWEJK525yq+lUSilrsTqgQEtl/YajBCKACBhFwHxnHXelhFFTo8ol s8U7/vEVeJVM/Qa7EG2SMVxfd8X1vm7fuLH54KkhrIZ7jDmdg1e990nJng8WtQVOvv7+lKKp104t u+bKa3d+/gf9gFRvJuwvu5aHJaEE3i7fBcUtG7nVGwQnLtWtlFK2zPQc2vH6dEHh5mr99qEEIoAI mI6A+c46aXGuiEXSWuzu6nzpF5XwavviQ3YBJcwMGbe1q6DUaXd6T5+1W+3+Dv+EggkTP2r5QXU+ edUUfMPe29bUcq797Ddn3nzknMpNS9OHWafC5WXc66rBuU49WB0RQARMQ8B8Z53MOJfBkLQWA4Ee 9oJGpdfK0ah7/Y+LRy327j9zeOfnFz86733/9PSJJHnCjuuvGfXnP33kmlDaFeg+dv6YUty9aa4s zcGpFCnlamtAbNrqsl0QDrM8BuRJxIsok4bXHJE7WTQjwltHNg4K587lDQwnYgQLo+RgTJuxqAgR GKEImO+skxbnJj+yFlusf3FV7PlyrnXbj7796Z9Xz3nnfxX/fvFltdXct+eOA5HnfnsazqVTRs8s mHTgcMOsqdee7jwZ6AtEaqvbAP6WJjq4GpaVdm9ayopaNjbtVEtxMAWQBoEkRvnM6XDNEhrSC1WT QfOOxS2geU3zUkmqu3rhjGNHBYEIe3bR0sVbWdZFaqGanhH6tcJuIwLmI2C+s05anCuCkZwWYT31 q2oHlKsOy+ctvrW/bhPPzE1fUZgN5zNnewsKJn/S8sllo8YW5I1vO98aqaF6c8vMtSQurqnlPzjW fGj5IpI8Ll11MHYSufrhaClr9ckDmg+tnkbbOtQsCfJLp3NHmngRpT1lM0pl6qLpMX/KokZEYGQi YL6zztTIGp58gfXUykP5RAzMpGtvvO/jL1xTZ8yFc/G0G/7n8Li+fpIGWXjLeDjv+8gX7O8rGV/y 4tsv5OcW2Gy2yMlXt2Ja85qIW4jTZ5bXsojaXVcXO5tcumrN8tq1EetB3EcFt6uc5KCZ3pYkR8TP QOn0q8TIWmGPDj0j83uFvUYEzEdAy9ZCuuo8+eSTuuoPvXJatPjiMw/+7t/nd3/6/QOv3PZ/fnHH zT+9/pqNpTUvVV739NXnfGflIEgXepRvJFkKoYS+k34MU2L5G+ES4nlbNpbTlAi74LjycvrPbbdF TB/BR/OVoNrGYxF64AOhjrTBG++/i8+3sKyLih5iMB6IACJgKgL4BKP5v3/RNNb+5lfso+UP/DOc O3o6jp1rdre33DXnBzaLLLhOnlXYEiKACKQFAuanQZKTQZaCm4ItAp9116UuMBL4rA+dOPCHz37/ H3+qnbTA9Tf3LGGeGo7LRl12Q3H5D65bip46Lb4qaCQiMLwIYGSdEPyRzzohsKJSRGAEI4CRtZHB jxvLI5+1EVhRBhFABKIjgJF1QmYH8lknBFZUigiMYATMd9bJYZeW5ayTsF4Q+axH8NcEu44IDD8C 5jvr4e9TYixAPuvE4IpaEQFEQBMCmLPWBJOsEvJZG0ENZRABRGAICJjvrJOQkZD1N2ktjhg+a54t G3igdvE8UJHs2UOYcCiKCCACxhAw31nHXSlhzNAYUsls0TCfdXaWI9vqAG7r8aMuBwqnFOazZo9L sucSN9fwhFD0eciZa5FSz/TZiwoRAY0ImO+skxbnij1MWotD4bN22HI6OjovXrhw7dRZVs7W6e9I YT5r9clTunAxtwN5rjV+s7AaImAyAuY762TGuQyMpLWonc/aarFuqP6l13v2+PGTVqsV9ovJtjmy rPbiosmwp9f3rr/94OGDqcxnHcVbzyiLYOYzeS6iOkQAEYiBgPnOOmlxbvIja7HFuHzWUPNbJfN/ fftzX5758nx7e5bFfvFCx+SiyWSbc1tO09HGq6+8JqX5rPFLgwggAimGgPnOOmlxrohkclrUy2cN 5t005ZvP/dWWLz2nX9u309/r9/cEYJcv73nvTbNuLp8+N7X5rNXmKVCtso0N8EAEEIGkI2C+s87U yFoXn7U4jt+YdOM797/3yDcf67vQv3331uffrO3q6fS0f+Xr8aU4n7VyKrpf38EtXijfdSDpUxYb RARGKAKmEq4SZWnBLj3EXhvrY2dP52uf/2H9uz+79+W75z03N7X5rNnXQcqUzSiy8UAEEIHhQQCf YBy2H2nksx426LFhRCANETA/DZKcDLIU6hRsUZXP+s3mN9r950XLkc86Db8vaDIiMGwIYGSdEOiR zzohsKJSRGAEI4CRtZHBjxvLI5+1EVhRBhFABKIjgJF1QmYH8lknBFZUigiMYATMd9bIZw3TacWr 9x0d/CxnDDwCk32pqzc7z2HhrBPHXEEfism2hCzvf7C/yvXdJyrXjuC5h11HBBABHQiY76x1NJ5W VZHPOq2GC41FBDINAcxZGxlR5LM2ghrKIAKIwBAQMN9ZZ+oTjAByCvNZsylQt8JigMQUpFbUDWEO oSgigAgkAQHznXXclRKm9yqZLaYqnzXz1TtruUPxSEyVrrl6c2hztemjggoRAUTAVATMd9YZHFmn OJ814Vm6//44lNNQydQJhMoQAUQgOQiY76yTGecyjJLWYorzWR9rPlT2V49EbBDg3jSXbdHF5znq VkxbfYirrQnnPSDQDn/MzzleimVU+AorSD3MliTnW4mtIAIqCJjvrDM4shbxS0k+a0ZgKt3Oxb1p 6eoyQr7UsrFpJ81KQ8aDbdkl5j1YifQAqR2LW0Bo8Y6l4K5ZhVpuEehZtBP9NboRRGCYEDDfWSct zhURS06Lqc5nDQSmhw6tnmaB0FnIW0OovXwRyUaXrjqoPStNAvQZQIRaKt0XhunBAxFABIYNAfOd daZG1qnOZw0+tnwjBMRku1veW0+fWV7LImp3XR1JaUiPurooK0BAquko1MatBobtW4kNIwJqCJjO zGqM63koZqRLi0ngsyaM03xWg5JPCxkO3o3zKNNSnpxazIFIyKpbNpaTqcKEpBXYNdJaD2W2oiwi YBABfIJx2H7Dkc962KDHhhGBNETA/DRIcjLIUqhTsEV3e0twIAhGDoQGPN1n2tpbD3s/O3Hx+KW+ S6LlyGedht8XNBkRGDYEMLJOCPTvfbH3Ys/FgtHjv+w6FeJCzlGjrTZb8FKwJ9hTmj9tzsSv2232 hDSMShEBRCBDEcDI2sjAxo3lb54yz2a1nQudceTZR12WYxllsWZbRl82qiC/4HTXqTeO7LzYc8FI wyiDCCACIxUBjKwTMvKfeT791NsIbtpqsYLXtllsA8FBq9Vqs1iBK9U2YAtc6vnujGqbNSshzaNS RAARyDgEzHfWyGcNk2RP67sdoQs2hw089UBwwGaHv2AsTkcueG0o4ULcGe+ZSV8rvmESXXaBByKA CCAC8RAw31nHazFdP9fFZ7239X86rBfsdvtA3+ConBzw0VaLzd/ry+ZysmxZJNAeGPyq/ctvu75T lDchXRFBuxEBRCCJCGDO2gjYcfmsR9lHhfpDJI6GpAdHPHV/sC+by+4d7HWOynWOdo7Nu6y4oPjo uWYjzaMMIoAIjDwEzHfWmfoEI8wN7XzW40bn9/cNDPQNjMoZBZnqvmDf6BxnnnPM5WMK27vPgxO/ 1HsJktlfdX/lD/r1zzpGrqRkVkoWn7XID4XkTvoHDyUQAWMImO+s466UMGZoDKlktqiRz3q883Jw 0DnZOeCpSXxNUtVWcrPRYh1lG3Xmwpkxo8fkjynId4774kKbfkCAXEn6bKGgIEl81kDdR5me6LFr Jnk0nR5aNjHQUkc/HiiBCIwABMx31hkcWWvns/7aqK9lWbMCvh5w0OC1yTprS1awN9jb25s/Jt/C WYL9wZ5LPRPGTjRxDV8S+awp0xM9qlet4i+1MGVrqTMCvnXYRUTAAALmO+tkxrmsw0lrUTufNbjj isnfCgQC3V3dcA05a7Joz2LNG50H11MunwrB9ddGfw1cdselDuWwyWmooYZKkVzODD5rPsFCqazJ Nb9LWATDdfXmlplr5UkYJVO20mRZHZFKO4JTW0zxGNmhzMA3AEUQgTRBwHxnncGRtTimWvisr/ja FfNKFvgC/p5LlyC+hph6DPXUsHSv/eL5cbn54K8hyvb1dvcP9kfOlroNjIY6tIurYXz/SmZqFQ9v Bp81OGJgcVq+BsJlEqhv3EriZoHhOrSmmTBcU8pVYh7QW4tbPiqZspW9kNURqbSlnNqQyhGIog4K MXuafJfQTEQgoQiY76yTFueKuCSnRQN81rAsb0HJt32B7i++/KJvoL+vvx/i656engkFE4suKzrf eT47KzvHMarzUmfkGIuha00t/4EGZmqz+KxLV61ZXrt2k5v4WuKz4YDWCVO2xVJTe6j5WNhWcLJr mqdF2z5G2QstMxl0wm8AHAZ2/tWiH+sgAumKgPnOOlMja2N81pfnFt5xzd98fcL1g5cGj55q/vzE 58H+Xn+Pv6+/b8yoMc0nm3Ps8JSjRRZZr5jWvCbiFmJMZmombBqfNVf98EZu9bSapo0P8xsOQOsi LSpsYuDetEmgwoY4GHankU1+nikbkh6yXkjqydi0w7nsuk2bptPbpzF+BtL1y4Z2IwJDQsAgtWp0 sXRhlx5Kx431sbe/F+j3Pjr1p3da6l/99HfbP37p9eY//nfj9kAwIDdGutNWJK00fSfbiGv5G1IS 66HzWdMGIlireYZrnuNa2nwkubWUKTvSzDCjdkQdgTq7nD7KCR0RW0Le7KHMUJTNQATwCcYh/dQN RRh8d0fPxc5LHdMKZsCf/UNRhbKIACKQ8QiYnwZJTgZZOjAp2OIrTS93XeoCI4HV+tCJA3/47Pf/ 8afaN5vfaPefFy2HhHVhXtH08TPRU2f81ww7iAgMHQGMrIeOoYqGlTsfbD53ePaE6977Yk9fqG/i +AmObEfnxa6znWe/f+1dP/rWI7nZeQlpGJUiAohAhiKAkbWRgY0by2+6/dfZ9uy/DBzMKx49fnq+ bbw1a6y1aNrlc2bN3nP83YUv3Np89oiRhlEGEUAERioCGFknZOSfO/jMMx/8qnBGAewI47A5sm05 vd1Bu83hsNphqXV2b87ZC2d/d/fOnKychDSPShEBRCDjEDDfWSOfNUySFa/ed3Tws5wx2dm27Etd vdl5DthzYOKYK+AtvCwhy/sf7K9yffeJyrUZN6OwQ4gAIpAQBMx31gkxMwWU6uKzfuDVZcdsh525 zj5ff37+OOKjrdmnL54eZ80f7Rhtt2XDfozvf/be83e8MHdKRQp0Dk1ABBCBVEcAc9ZGRigun3WB swCeggEfDXkPcNMOW7a/KzDWOq6j7+LEy6+4svCKGVNm3Fp267aPXzTSPMogAojAyEPAfGedqU8w wtzQzmc9q7Csp7s36OuFHXIdWdn+Tn9hQVHxhMnXT73h0+NNDqvj4sUL9mz7/hPvnen6Sv+sU+Oz Th7HdJhqSY1TW39vUAIRQAQ0IGC+s467UkKDVfqqJLNFjXzW111xva/bN25sPnhqCKvJPcYsR7bV AdfjR11+4HDDlKKp104tu+bKa3d+/gd9vSW1lXzW0Tim9euOLyG2zp5ehAfQ8UAEEIGEI2C+s87g yFo7n7WroNRpd3pPn7Vb7f4O/4SCCQ5bTkdH58ULF66dOsvK2Tr9Hefaz35z5s1Hzn1u0iCrcUyb pBrVIAKIwLAjYL6zTmacy+BLWova+ayBE3VD9S+93rPHj5+ELWIgvs62ObKs9uKiyZAD+d71tx88 fNA1obQr0H3svITGTpgO+vmsVTmmRRZsxmAn54/eJZbw7Qn8ecrmI/islZOW17yC7jaGdHnD/q1G AzISAfOddQZH1uIM0MJn/a2S+b++/bkvz3x5vr09y2K/eKFjctFkunQvp+lo49VXXgPJkFlTrz3d eTLQF4icW4b4rFU4pgUe6pbFOwgPtZw/2sKX1NYs5baGExpK7mwFn7X8q8A013KLQkDExO14Xdjo KyO/MtgpRGB4EDDfWSctzhUBS06LBvisb5ryzef+asuXntOv7dvp7/X7ewKQFfGe99406+by6XM/ afnkslFjC/LGt51vjRx8Q3zWvAopxzTZOobsv1U6oyyCh1o21ZbviqD5V3JnR+OzlutZBNnrOG0N zyzHVhGBDEDAfGedqZG1MT7rb0y68Z3733vkm4/1Xejfvnvr82/WdvV0etq/8vX4SsaXvPj2C/m5 BTabTRZZ6+ezVuWYBh7qJrKdLdnzJZJ1OtZeiErubBmfdcxpr2wrA74l2AVEIBUQMJ321RjX81DM SJcWO3s6X/v8D+vf/dm9L98977m512wsrXmp8rqnrz7nOztEPmtYlaHOMS3QRRMSbHpE8kffdhs/ BVVYqeGTMAe1hM/6mIJNm+1AtlyYzZG6hjKwKIsIIAJhBPAJxmH7xezo6Th2rtnd3nLXnB/YLLLg etisMtow3GPcuQiX8RmFD+UQgbgImJ8GSU4GWdqxFGxRC5/1ZaMuu6G4/AfXLU1/Tw2jAblyXHAd 9+uGFRAB4whgZG0cuxiSyGedEFhRKSIwghHAyNrI4MeN5ZHP2gisKIMIIALREcDIOiGzA/msEwIr KkUERjAC5jtr5LOG6YR81iP4O4VdRwQSgoD5zjohZqaAUuSzToFBQBMQgZGLAOasjYw98lkbQQ1l EAFEYAgImO+sM/UJRgA54/isYXE00C7VrSDcS3AtEDnJryltdfhTcbqJzFBDmIAoigggAtoQMN9Z x10poc0wHbWS2WJm8VlXL1oOpCHTZ3KrN6zYWbuccHvQQ7poWsmdLQ6NyAylY7CwKiKACBhDwHxn ncGRdebxWVP2kNebD3G1tbUy+hBj8wmlEAFEIEEImO+skxnnMlCS1mJa8VkLOYq4XNVHjjRFTC5t yQ1+b6+a2gRNTFSLCCACkQiY76wzOLIWoUsHPmueYzo2VzUhNH3+ea68HLom7DSjJbnh3rS2iZJD Sfmj8LuFCCACCUTAfGedtDhXRCU5LaYhnzUgFJermqBYtnhxOacrCyIwZSdwZqJqRAARiEDAfGed qZF1GvJZK+e6gqsaCsBNz9D7rZAwZesVxfqIACJgDAHT+WLThV16KB031sfk8lmLCYrYXNVQDSqw MztkgrJEh1CNFZfTBEpYdiigoiwigAjEQgCfYDT2G2eCVGbxWZsACKpABBCBGAiYnwZJTgZZ2qUU bHHk8VnjtwwRQAQSiwBG1gnBF/msEwIrKkUERjACGFkbGfy4sTzyWRuBFWUQAUQgOgIYWSdkdiCf dUJgRaWIwAhGwHxnjXzWMJ2Qz3oEf6ew64hAQhAw31knxMwUUIp81ikwCGgCIjByEcCctZGxRz5r I6ihDCKACAwBAfOddaY+wQggpzCfNc+rxJinVainNU+RCEUiwbVmcayICCACCULAfGcdd6WE6T1J ZoupymfN2Jf4xwtbFnFugyi7uUXAz8SrGoIeg82jGCKACERDAHPWWucG5KzvvnsJq/3NO9fv/92j 7Hrbtu0rV66UaRkMDc595uv548eVukoDnT0Txhc5snI6L3bYrfbJE6bsa9p747QbQ31ctjXnaNvR X93+rFYjIupBELxzUWizsGMAe7toZ0ShIcVkpxipZmNKUAoRQATMRAAjax1opjCfNetFbY1FJJhW 57Pm2a2lmRKxKNbeXWT7L+LDyfHd79KaK+g7Us4OXk+4QAeyWBURQATiIWC+s87gnLUIZiryWRPj GCUTO1T5rOs2rC6jhE27uBqWkHZvWtq8hudvAnExThf7yidY1qwq5YBrrxxYrN98k7RSyy0KhVo2 cjtep94a9OxYTBiu1zQvFf13vNmHnyMCiIBmBMx31snMILNuJqfF9OGzljpcGZ919eaWmWtJQCwG 4KULFzfV0BJul9JT837/4Y1NO+s44umJz2YH3bGRbF7QfIy8BYbrQ6unUc18ieY5iBURAURAAwLm O+tMjaxTm89aw1CTKnUrpolxNBMRY22VoFpUWrpqDQcZlqaNDwsJcv4j99EmftMCiLpFktVoTl+j kVgNEUAE1BAwnUHWGNfzUMxIlxYTx2f9hpyEWklLLQAspacmOQ3pxlzM26oTYbdsDDtjqVCYLRtq sAlG1eKBCCAC5iKAq0GG7Tc8Nfis4abh2pktB2l2I8YikLoVc48+zGqxCB2XiwzbxMGGRygC5jvr TOUGkU6QuH089umbU6bd7MjJHRjoO/vlZ/7uc5cCHc4xhUWTykaNHjtC5xp2GxFABIaAgPnOegjG ZI7o3jd+dvF8a0HhzK9OfNgf7OEs0DX4PwRn1zW3fb3iPke2M3N6iz1BBBCBxCNg/g3G5KzNkMW5 iQcqooW4fZxX87jVmnXS/V5/H/HUNpvd7hiVnTMGzq2fv/X6tuUXzrUm2WZsDhFABNIaAYysEzJ8 TX/67acfbKWqLeCpbVlZwd4A31KIs2bZnXmF1X/371lZ2QlpHpUiAohAxiFgvrOOm881HcPktLj7 nXePHP5caTysv4ZVfbLyd3c+7jnxZ4sVjqyB/iBLgeRdVmTNyrJZswYHQx3tJ0uuvnXuLf9sOhqo EBFABDISAfOddUbCBJ0CbpAHHnxQ2bvfPPuskhvkf3auOXPyI1uWAzx1zqiv2WxZVltWd4fXarPB BXhwq9V+qadjwaJ1E4u/nqmIYb8QAUTARAQwZ20imGFVOWTJh8VmtUNATbxzlr2786wty26zOfIL XfRVkj0q7+gnOxPSPCpFBBCBjEPAfGedqU8w6hr6/MIZUD/Y63fm5YOP9nedGzd+CnkVToX4Gkq6 Oz2jnGMh+vZ3ndWlOaJymHyakSsBiZJYhFzUxnFFSUQgBREw31nHXSlhOgpJa7G7q5PxWYsvKGHd YTaI58snXg1Z6lG5YyEBQm4w2hxwhvgaYm3iqTu8EFmPu3wqXLc2v2MUkLoV8AA4/7AgI1c6tOP1 6QKxNT7zbRRXlEMEUhIBzFlrHRYpn7VURpXPOhQa3LH5+6HBgdwx43v8F7827kq4tejvOg8pkbH5 xd1dXrjNCNew9Ywje+z87/1EqxHyuFrOZ81tnPnwqhkb8PFCQ4CiECKQyghgZK1jdEQ+a+mFqrzF Yq249cfwDIzf1w7hM/hlEmJn2S8rKIbrcQVT4Hrs5VPg0ZjO9hORGvg8BqWFJtflG7dQ4ugVdTxh NMtvwEfAnAcE1hG7eC2awTHGUnZEsleDyNy5cxU7fyEPtY4pgFURgWFDwHxnjTlrNphXTr1hXs0T ocHBfli6x3EB38XL8ieRZSEQYnefg4Ui/s5zubn5vq4z/X2XJOMPLKbAiLSccJESTruN21Yvo5mN 2pql3FZCDMPyG9J9vCQZj+qFM44dFbRFsFfvoqWLt7Itu6R81shDPWxfP2wYEdCOgPnOOmkZZLGT yWnRAJ/1xMlfn3/72lCIO/tVMzz/0hPohIg70H0BvPZl+cXgr3NyL4OV2B0XTkYMGBCSLq9dC/cK I/mjd4V5lGKMb+l07kgT/7mSvbpshkDFJKhAHmrtXxasiQgMJwKYs044+rAm5KS74cgnf/B1nIbG IDdy+cQZo52XWawkN/LF0YbKv/6/4y53RdgBqYlpqw8B1yjvoFVZ7lT3YNxcTWSBtBrCbbECubg9 tOi18CaN4laNUHvDjIN4NzLh0wAbQASGiID5zjo5zxNKu53oFi9MmmYA5XGnWmRSwUu+U1980O49 1tl+vKvjJPDw0adm+v76f22HZXyyyhJPzNLTcEi33RILSfkbxBGLdR4+Kvpfaa0b77/rA8s9/I66 kn112Q8DqAn/NhjoLoogAohAYhEw31kn1t7h0G7MWSfHUuVPQnLaxVYQAUQgyQiY76wTHecqAUp0 i6nsrJMwXfD3IAkgYxOIQFwEzHfWcZscIRXQxY+QgcZuIgLJQcB8Z53oODf5kbWJLZoLTir/HmA8 npwvMLYychAw31mPHOyS0NOenp7BwYG+QP+lwCW/3xcc8F01a04S2pU2YewnAZ11kocJm8t4BHCd tZEhNryyW5dgIBAYHBgM+vt7/b19/r6Q3xK6kP3+W/VGLB6CDLhdA68hNIiiiAAioIIARtYpOi1I TA2eOhAM+mGhdhAuwGUHA33wttPeVnXHXSlqN5qFCCACiUEAI2sjuOoKkKUNaBfs74eAOnjJ3wsv cNPEU4PLJufebg88WDM8h7+1oaHVz87mWOBtavLq0+Rtqtcroq8BbbXNBCGyRRXNaiiZPxbaOo61 hgsBjKyHC/k47bZ72vsCfUJMHewjkTWLr4OBgH/RIws12N2wfv5j9VzVur2PVmioHb8KuIfW3AqX j5zLCuPXj1sD/K63sEqXKhBxOysqXHo2hweZRq+F7DBfWFZZVki8nKdIpw5FX7xNDT6XPjvi4sEq qGqWF5o+FhqNw2rDhwBG1kaw1x4gy7SDoIz5GipIS8T6JKb29QZ9wSA9E08NZ3btI8xQGo6KR/eu q9JQT1sVf2srN6csl551eeooMSgU6/XUnL/V3e2ao8tTQzON3OyqSnoQw/0ej5+Du7Xaeq1ei/7K KD21CdF2FM1cYWFea6v4N4jhsRhKp1F2mBHAyHqYByBa88eamjm/jSSsadqaJK9Z/joQ/KrX/dC/ /Uib3RBc75tnVmStrUl5LRLXgreUOXjwa59wc/RFpsQX+kv1ReIQp0ZG76Rhfx7X7dTceDgwh66F QoWKvgg9Vu+pMdQUUkYAM6lpVJMaCGBkbWQchhJZa2yvf6Cbv7VIbzCSF42vSVg92qOmBPzysu2n 4Dx/fQN3avv2BqHSvvXzFyxYAJ/xBae2L5sPBysg9UFiPfkH5DQf4Dvq6+sbmprgH2kC29u0e/fu ejGrTOJaj8XibZQluSG85YqK9OQyID3Q2po3m/l82jo0RJLXtMXGE8yeVj8zgDVHqkEChBQJRtKG XYV5rKPKXkg0wyVV5XNV8YE5xOZV0X4rZD3lNYft8Ykl4gWzQYaY5hHAiiMNAfOd9UjgszbcR+2C V1/3jfbe43A7Ubi7CBdkQciJgYMPPbFBbZpWzKtyn6Bkq23/uWzpiSlCnrqem7d3z56nSp7fSn3x qe0/3bNg6969e+898VNw1yxVQurs3Ttvn3Z/7XRVzC7i/BCgVlWV+hvYLT9wQ27nTZWVs4s8bnYH klYLFZZVyWJon9+fl6vLV3ubGrtdLj7/4iS5EFALrtvr9YwuuWn2ZNKQJdAGqRXiUllzQuvhEnD4 7EeC5UGUvZBoBhtBs9zyaB5C1lP6VmpPLmsLei1eMMSowRWubh6xaPr1IzbSfFnG99d8Z2046jSM dRq1qMvUeTU1XXb3uZ5TEGLDV/VMb0v7mA9//KuN0YAqnlza9p//udtiaW1tLZ1cLFSrmhdxe/Hk Cbd7yz0Qaj9ez/t2qCiro2ko/L5u6tlgN5xupzOXeB4hXAaHJKoQP9WkNFolRbLaCS63G1AJJ7Gh IeJbI9MtstbBs4MDPbC7ycOBMP19UfTC6Sotkmhm8bV4xFgGI2tLaU8YKAliARpZH2gLxMYHLC8q 1HWrYEh4o3AKImC+s9YePJoFRxq1qNfUW++8+85/WrLw0eq/ferOhzb8y0NPqsbUPJCTppSAm3Z9 5zuuUKhkyqQo8IJLr3pqDzn2Di2XLYZ6iphPDF+JCfynfq9XuthP6s7jzwN/6yeteaWR9xWduXls WYdwv1E19IwsJB6vjN5pnF3E32JU6wW5mSdqhjiY3ZxkR4wsu6ynSnuEEnKLk/1dASWwQCWuZnZj VfizIj5eWCMjETDfWesKHk3BNI1aTKypxZNdIdeCe+aXcCywJkv3dlt2P8YnN+rpxaQlT0z+z/kk iw1Z65PqdeIOC0m7NnktHpKKhniRoxccRLsciUObuNlhn1ZYNptrrK//xBeR9YDwlWN/9ytXUChK JMlqiWWFhUWQxmCuWmpPOKZnRkLkCslsN8kZk/y1l6a5ofzMJ+9/uF+lFyAPPyWC5rhQhCuIPXU6 Ve2BFR1FQhjNoOMKXa7uRpJ8D2f5VRqE3yp/qb57sTrMxqrpggCuBhmekTJGuAG2ZhDnBqw/82kI F42srB7SoLIlzPqWJw6pwZjCSe9+4rqCmoeGgPnO2lxiOS29S6MWRVMNO2stgJhSJ4N+FUzBA5Ug AsOMgPnOepg7lCbNp76zTg6Q+JOQHJyxlQxAwHxnnUZxruHxM9xHw4KiqejljY0a/ioYww2lUgcB 85116vQtAywZLj5r/EkwPHnwV8EwdCgYGwHznfXQg0e9Y5biLe5+590jhz9Xduqqq6+p/M4tMToL fNahwRChRQ0AOSpP5NTec+rm28wj/NCLtdn18VfBGKL4k2AMt7SWMt9ZpzUciTD+6aef/uEPf6jU /Mwzz6xcuTJai8hnbe5Y4K8CwxO9vLnzKpnacJ21EbQNL5eeVfWIxvZGCp+1RjiiVGNLsrWQ3RnY 7MaAyNB6g9KIQCwEMLJO+PyAyPqBBx9kzcy+9V8b3/43dv2bZ5+NEVmbwWdtdtfYAmSBz5puAiCS ROttS8YxrVE8UirXbH5tjVakQDXDfyhgZJ0Co2fQBIysjQBnILK+4x9fgVfJ1G+wC9aqkttatMYo nzU8taiHPE9H7+UcysDOVFl5U8no0ZQXRNeh4JjWJC2TGtGczgaifiaiCWmslJIIYGSd8GGByPru u5ewZr555/r9v3uUXW/btj1GZG2QzxroT5eeuHdopB96EDGw1wuoT6aUnt5gXUQghRHAyNrI4OiN rAOBHvaCxqTXMdrWz2cNyhrWL32+NUwGQriqeSbrhvVwMW/eP/9vgb06OsO1HkCUlHoKdmZwzJT7 QqCri+SYDrM8S3moqT+X82LLman12Il1EYH0RwAj64SPIUTWf/3Xf61s5tVXX40RWUP9fbt2OTrz YWsYYLKmezCSNXwnBg7FYEml5E3SrWGEtxBx/5R7YsuSSZS5iYNtGYvFEvGzhvXLji8ldTQfshBZ YNUI72oiVpDWlEmBX27yEs5rkY5DqcdwOK65K1gREUhxBDCyNjJAuiJrWE8Nfll5QHnstvXyWatp q1h6f9u+Bq5h6/Ml94pemLJXA6Eqz2etynCtCRY5g7PHI2dnpkx0hAy6ycs4r+GIz/us1KOQ0mQf VkIEMgmBEB4ZhcD+dfPW7Yce7d9PzuSAknnz7tt2MvyWVji57T6+EK5oif7D0/h2oycsJnsLH4gl 0o+0S0ktUirXby9KIAJpjABG1kZ+eXVF1tIGDAtqthK26YLduebP38cJ+8NAcF1aFQ6rQVP945Cx vmeLEGtHMFwLGzXGbpAknmm4zLNFsz28lOzMAoMzqelphP1ZeKJnCce0yCgdblGhJ0KKtYUHIjDS EMCcdcaPuCwTnQL7nWc85NhBRCABCGBkbQRUwwGyYUEjVvIyFY9G3DOE0PvRiE0Zh6AaRREBRCBp CGBknTSosSFEABFABIwjgJG1EewMB8iGBY1YiTKIACKQQQhgZJ3SgzlcfNYpDQoahwiMSAQwsjYy 7IYDZF2CwGc9ODAY9Pf3+nv7/H0hvyV0Ifv9t+qNWIwyiAAikOYIYGSdogOIfNYpOjBoFiIwTAhg ZG0EeF0BsrQB7YKpyWdtBCx4+FAz67Qx/UOXSn0Lh95H1JDuCGBknaIjOAQ+a8L+Uc9VAf9H1CV6 wOv0+G7oeShUGasajw1RuNsCU0VLZQWekSzYxuBm3NmFZZUifUg0Nm0jhH5mWGisXyiFCGhHACNr 7ViFa2oPkGXaQVDJYS0tEesb5bMGBbCSel3MXRob1j/WtuylPXDs1bTmGhTu3bPnKYVOLdzZ5rBO F5ZVyIizo7FpS/mgtA2tORZqawtrIQLGEcDI2jh2CZU0yGcdjoWl3HsyS409xKiQSip3tmrEbCSM TuiooXJEIHEIYGRtBNuhRNYa2zPEZ00YUoH2Y8GCx8NLRsClEg7rZdt51g+W09gN9CDzhT1loAqV WkD3mCEs2PQj8ULVZBl3tsZuqSVJ6oHsuqEBzozzmhCB0EvxAoQIUx/nJR80eUUdcvo+QVDaCOXF pjQmRi1EOUQgNRAw31k/8cQTSe5aGrWo3dSrr/tGe+/xoL8X1u3Bi14ApTXwWR986IkNURA+tf0/ WX5DTFmc2v7TPQu27t27994TP2XumiRJKkOVT4VzIIQ/Fd6CFPcY+GgxixI7ncLr0ZDyjjkdnK6K 2UWcP6+0qqrCxXk8fo6V5OU6xQtQ4PP7/d3OOVCn2y0yOUEhVBPVS+uzQroRWFkl2X2s24veOsnf S2zOZATMd9aGo07DPUujFnWZqp/PGpipS6ZE7B2ghau64tGtk/+T7CkjiccND4Z+QRIfu1yFEkEx Yo64cM1xhR0zdcUgGLn/o5Jfm+M1F80Rb03qtxAlEIFUQMB8Z609eDSr/2nUol5Tb73z7jv/acnC R6v/9qk7H9rwLw89GS2mZlgWTy5tOw7x86njbTy4UFJFo+YY9xIhoQHbNqrdQgzriTlWkMQYwlgK 8bG3tZUrKiL+WCjxQ6DNQmdJCV9HUhhuWxZqw1vhM58PiVWHMEYomgoImH+DEYJHvS5piECkUYsJ N5WuyQu5XKVut5ut3iO3AWFjRkvItWyrsK0XrMMDzMNL8YSVfKSQVuO2L7tnSyvT0xKafZ2lsZGK REiRd3SZYMxVgvEGlyxxbgsQ5eGVeXSjL6G50SU3zbE0SuuERag9o10VFS4nXyi8pdJ0+XQA+j66 hFSJZwp+jgikMgLmO+tU7i3alnoI4IqO1BsTtCglETA/DaIrLWsKJmnUYvJNNQXhRCrRvzA6kdag bkQgZRHAyDplhwYNQwQQAUQgjABG1kZmg+EA2bCgEStRBhFABDIIAYysU3owkc86pYcHjUMEkogA RtZGwDYcIOsSRD5rI2ODMohAhiKAkXWKDizyWafowKBZiMAwIYCRtRHgdQXI0ga0C2YSn7URiNVk kHXaLCRRTzoigJF1io5aYvmsjXTaJK4+I01TmUjWacZnHYKFfy4fe/JlzNdCXZ3Ckzt0QSCrAw/V lPob4AJ0SBmxpYbgYm+GhsgSHgoVzgYEDQ+WSYJKHnOTFJumZmgWgnSjlz5uxmamdB4qGdsxsjYy bNoDZJn21OCzNtJlygAVfTcDXqWS4VqLlBZ75KzThWWzC8GhwAR3ukqLyFy/8QbCeV1yE/A2lRV5 CN0TZcEO+f0+RocNH0VzP4YWe7NAX4vxaVNHBKpqNtcYi6gwSX1X8phHgTJJ9ihb12yhUpTSjM2u gvlKpiz9YZTOQyVju/nOOsnPmkMP06hFMJVZG+0sDqnf3xWkNHuX6LnX19sbAO69IJzP9h5P0W+/ Ri4RI9Y7XWXwvDg7Rx7epsZuRtckMogAw5PIMgIXwAsiYw0xYoFcBrhMIkj/zNA5/DoEoID0sDs6 n0ry+q5t4JJnj3KEtFmoMrIgWFQY54+XCOXmO2vDUafhiZpGLWo3NWF81oTOg7FXhzmuKec1KSGE 1gKNNU+ETTmu5dzWfJ31VJVAla1kuFZjxI7g1w7rEcm1dU4Df6vbU1RKPThw7nEeoK+ub/AUMYY+ ysIHXwefkqAv/KsYyYLNk2g3NQF3djhuJqWMF5vn0yZRkcdi8TZKYmv4u5VUiGDllukhiQY5vzYt ieDplkKgbg/5e1nWFnlLaMEjDIqlWRVoNaAi2iKoxuu7ahApYy2ndeSaaVEEPoI9fE3WORliKvYo xku1s4qx0DSCMlWqTOuxx5RhSBIgpB4/YlL29vDkjCSWDOGRqgjsfeONA9sP7nl+31u/3P36+l2v PPbH3656+ecrV0W39+S2++7bdhI+379u3rr9pJ6khH0S/khUA3VYbbhgUiA+bx5fX6wm6mQlpA6p LbagrlwmJdQOSwl6VAyLPTCexrcbPXDa7/axirQgQoaVeIDUSvGRtJ5MEN4ypWK5UrOyOWVlpR6f ez8zES6YqcIF/Cv2Q97tGPbwHWTdpFCIZmjRrARYtRfMVCkISsSUdWTKSS9IpXBPlW0p8RE7KA6z ar+i2RNjBkVrS9pTJfKqiFHbwv3SiHy06Rp9ZmJkrTOSo9W1B8gy7boEE8NnDUnkefsi9o4Bzuuq eWRv3UlLtohZ6ap1hKIv9kGlJk0pcZ84qRVFgXE7Qoq1buDodothdQx661zO75EzX0cEr5HhC+XX JpF5OMqExKTTHQ6rqbA8BoUkOtfI9qRhLNtKPUD5KuPXhpIAjcIOtAWi9V/VHmlbzBJyLirihL5o 0awSAQviXq+H/xNd0S8tfVfXHMlaDglaOWJKfMCebjdAWjSbZ01U7ZdyLJTjJQ+IFW2p2KOcCYqO iaMTjoY1jKkKhhr42c131mmUQTbgHpiI4T7qFUwAn3XD9u3FsAEu2TtmKUtxAOd1/T56daqhgd/8 Szs0kKcunVwsqx+V4VrCuK2U0t4oXxP4qsMOQJk75EvAdUZuKSNrR8mCHUmizXm9XtiFBu4CSe+6 8VJ+r5feY2T38emdopBMXNSv5NeGErg1yo5oHK5ScaZZ1harID1DHS2alXgLnWp187cBVPrFlBNL ovc9qmYuzFquipggyPOPkw2C8krJRj/C/kCq/ZLbozZeykGXtaVlBKP3i/wQi/dJ4o5pGEOJxqgT WKhj/tK9hFM2KwBLoxYTbmp8PmvCb72llfJZVz7Fr+8Q+Kxdy17asuQk3aQRJkalZMsutnOjtJAv AT2wRZhkmYiU4VopBT8IhF/bzZXeT9i1pRUg3n+snnFwa/LaZNkT3Eynt9GVZNbSkjncJ59wc1Sd oUxQJgUpUqeUTZusFAwvKCEGeMCLM8USDu7BwXFFue1nAwAXcG1D60QPqccp+LVFxm31pXIq9hA9 vjDfN23rUu4c1kdJT+Wa4X00EBjcYZbwCPrvCG5xcT1f1L5HWfMXl7Wcapbwj99UUeSlROcEQ1de W5uXZyoXMYxATGqPpCMxVvkouc61jKD87rZav+KMaSTU6mzsYbXke8rX4cx31pq+aFgp7REwtuw6 7buNHTCEAC5kNwRbpJD5aRBdaVkTejCEDLLh1g330bCgYVMTJmjWAuqEGYiKUwgBQwvZU8j+lDAF I+uUGAY0AhFABBCB2AhgZG1khhgOkA0Lbvzw53//0t3weuK9HxuxGGUQAUQgzRHAyDo9BnD57/8h 6O8HW+2jsp6/84X0MBqtRAQQAfMQwMjaCJaGA2TDgj+p/smN10y/8Zppa2oeM2IxyiACiECaI4CR dUoP4N7z/9HfPxAcAMJU+H+gb4C8+uEMbwf6H/h/nkxp69E4RAARMA8BjKyNYGk4QNYr2DfQHwRH DW5a9NT8dX9f/6AR07XK1K2wsGNFnVYRE+tB69AuO5t7yDQPbzfN7Rpqy3AEMLJO6QF+88tniZsm cTTvr4WwmoTYP7ppXcKsBy+2c1Foc7XWBqB+TS2pvHyXDil17e5NczfMOPjwUXLWboEWS6No1ttZ LU1hHUTAZAQwsjYCqN4AWWxDC5+1x+P5wQN/d+ey73/pa4PwmaU+WPaDhtj9Dsvov7v2wb6+ATXT ExGNaoGoejMhoNm1XEvdOHXcx2Zs3VzNzmJVU/qlqtkEi1EFIpAEBDCyTgLI+pr49NNPH374YZD5 3sobJswcR8JqeA3SyJqmqlfeuDaqRggdpzWvGXJsy5EUhK7ImlmkV0qMx5l49KjctH6pIqfXbH0D irURAVMQwMjaCIxDiay1t3cJFutR7wwxdVBIhsB1dA11K6atPsTV1vCpXpaQXVEHno5e7CLOlKWh xQuqjK8wd5M7mi8jYvRjIsjq8UJRs9pa2mLxuHhEy3kkqF/ahwJrIgLDj4D5zlovsdzQMUijFnWZ OnNcBdxgZLcWyV3GfriG+42D6/b86+mOE4+9uVIBHfg+SESI8Sl7W1uzlNtK/OHmGo6VwCFeUK+7 dMfiFqiwpnmpqruu3tyysZxbvmZVKec+2lS+cStccHUbVpftoqkPrkb1NqCxtlSnQ4L6NfSphxoQ geQhYL6zNhx1Gu50GrWoy9R8+wSa+hiE81XjvrGyfO2PKtb/zdX3BPv7fnPw/wMPrg2x5bsOEuca /TjWfOjQ6mkQOtfUHmo+plqvdNWa5bVrN7mJhyY+m7r7lplrScDN7itqPCLaOsoH+Py6E50rT8zo l0arsRoikAIImO+sdQWPpiCQRi3GNfXpp59+5ZVXGCx//OMfP9p1hKRB+gcWlNSwwmkFV0N8zTx4 LPTq6uIseoMYmZefPrMcgnF2RF18Uf3wRm71tJqmjQ/zN/0gNQHJcW03FaO0RSN9LWkQSUfN7pcp MxCVIALJQCDGxjfGPnryySeNCRqWSqMW45oKjvnv//7vb6XHfffd98yHT/zy4Jr/u///PPPB/8vw +cW+nz382g9X/WHFD3+3LApiNNFB3K+4NkP0xUSCpDTgKC+n/9CP+CIo3EjSIbwLjpBiXjmiSLr0 48b774qYrXxFbW1pHHlT+qXalrxnGg3CaohAMhHA1SDJ+EXU1QYM/w9/+EOn07lhwwZdgqZWNnPd tKmGmatshHTTXNBQ2/AgYH4aRFda1pROp1GLWkyFDO6zzz47rJ4ahkVMUJj7VIopA26ikhHSTRMR Q1XDhgBG1sMGPTaMCCACiIB2BDCy1o5VuKaWAFlVr2FB5LM2Mk4ogwhkEAIYWafHYCKfdXqME1qJ CCQMAYysjUBrOEA2LIh81kbGCWUQgQxCACPrlB5M5LNO6eFB4xCBJCKAkbURsA0HyHoFkc8a+ayN TFCUyUQEMLJO6VFFPmtzVw4in3VKT3c0LiYCGFkbmSB6A2SxDeSz1gA38llrAAmrjDwEMLJOuTFH PmuVIUE+65Sbp2hQshHAyNoI4oYja12NIZ+1ABfyWeuaOFg5MxEw31nHJZYzHchMbRH5rIWpgnzW pn9pUGH6IWC+s05O1ClFOlNbRD7rmN8n5LNOP3eDFg8FAfOddabGuVKUE9dH5LOOM5uRz3ooX3eU TWsETOdjjUvZjC3GQAD5rKODg3zWpn91UGE6IYCrQVLupxb5rJM4JMhnnUSwsamhIWC+s4YMcuKy BKqdTcEWX2l6uWr6d8fkjAkOBP9y+qMz3WcuBNonjpl4w6TyfGfB0IYMpREBRGAkImC+sx6JKCr6 vHLng83nDs+ecN17X+zpC/VNHD/Bke3ovNh1tvPs96+960ffeiQ3Ow+BQgQQAURAOwLm32DM1LUZ utafbLr919n27L8MHMwrHj1+er5tvDVrrLVo2uVzZs3ec/zdhS/c2nz2iPZBwpqIACKACGBknZA5 8NzBZ5754FeFMwrsNrvD5si25fR2B+02h8Nqt1ps2b05Zy+c/d3dO3OychLSPCpFBBCBjEPAfGed ghlkU0Zt9zvvHjn8uVLVVVdfU/mdW2TlK1697+jgZzljsrNt2Ze6erPzHBbOOnHMFfAWXpaQ5f0P 9le5vvtE5VpTbEMliAAikPEImO+sMxUyWAH9wIMPKnv3m2efXblypaz8gVeXHbMdduY6+3z9+fnj iI+2Zp++eHqcNX+0Y7Tdlh28FHz/s/eev+OFuVMqMhUx7BcigAiYiADmrE0EM6yqwFkweGkQfDTk PcBNO2zZ/q7AWOu4jr6LEy+/4srCK2ZMmXFr2a3bPn4xIc2jUkQAEcg4BMx31kletwcjkvwW406D WYVlPd29QV9vQX6BIyvb3+kvLCgqnjD5+qk3fHq8yWF1XLx4wZ5t33/ivTNdX8XVFrUCrBLmjxWU pB/ez93kNq4PJREBRCBlETDfWWfwapDurs47/vEV6QtK2NCyXovn66643tftGzc2Hzw1hNXkHmOW I9vqgOvxoy4/cLhhStHUa6eWXXPltTs//4PRyVG3oqZpYwt7BIty9NftrOUO7XgdvbVRRFEOEUhh BDBnrXVwIGd9991LlLW3bduuzFkPhgbnPvP1/PHjSl2lgc6eCeOLHFk5nRc77Fb75AlT9jXtvXHa jaE+Ltuac7Tt6K9uf1arERH1II7euYi5aXoA5/PSI7O4T6/aenBVqSGNKIQIIAIpiwBG1jqGJhDo Ub5U5a0W64bqX3q9Z48fP2m1WiG+zrY5sqz24qLJkAP53vW3Hzx80DWhtCvQfez8sUgNfGqDpjPI dfnGLTTZsaIOnDG7IALsOenamnAJd6z5UNlfPbKYY7E107NiBflHFCFFRDPfCCvHAxFABNIAAfOd dfIzyMlvUcvAfqtk/q9vf+7LM1+eb2/PstgvXuiYXDSZLt3LaTraePWV10AyZNbUa093ngz0BSQK qze3bCznlq+B4Nh9tKl847bVyzaHgMOotmYpt1XMeHAixbOQA6G1Z04vXch7a1ahllsEFRbtJP6a FyGap88sL4cMirkbHGpBBesgAoiAQQTMd9aZmrOG9dSvqh1QHg37m6Z887m/2vKl5/Rr+3b6e/3+ ngCkQbznvTfNurl8+txPWj65bNTYgrzxbedbIzSUrlqzvHbtJnfdhtVlxLOyIx59s/v1HYcOrZ5m mbb6kCRvvXyRmCUhSqof3ti0s46L1Gxw6qAYIoAIJBMBzFknHO3u3q53WnbXH3vz0KkDeaPzvj3r lgljJxbkFbz74Tv9/QMX+i6s/fbPr7r86gg7yJaDqw9B8Mtnn+XpaVo5shDerZ1J64tXYgVpTZo/ CWtOePexAUQAETAFAfOddcY8wXhh0jQtEI871aKlGtTputS1r+1/PvN82nL+WNvF1vOBc1MKpn7V 8WX9/9pb4BwvUyLxr6o0nmIhCbrfCC16jaSwIfwObeZoNpu77TburbdYSE7SIFBEPoQ4G34INsw4 iBkQjaOG1RCBFEHAfGedIh0buhkanfXQGwIN2j3+kJurWzH36MO4XGTIOKICRCDJCJjvrEdaZJ3k AYvdXBKdfkr1G41BBDIfAfOddeZjFtnDZAbgycEWPX5ycMZWEAFdCJjvrDMmso6Bo+E+RhNMR4+P Pl3XNw0rIwJDRMB8Zz1Eg1BcikBPT8/g4EBfoP9S4JLf7wsO+K6aNScGRMl0+uisca4iAslEwHxn bTjqNNztNGpRl6mBQCA0GAoG+oKB3mAg2OsPwrm959TNt1UZxkqLoEaPj85aC5hYBxEwCwHznbVZ lo1wPSSmHhgE7xz082661w8uuw/edtrbqu64a4Tjg91HBEYaAvgEo5ERN/yUpnbB/v5+CKUv+Xvh BW6aeGqIrMm5t9sTMmK0GTL+1oaGVj87m6FvqDpSzZ6h9gflEYHoCGBknaKzo93T3hfoY6kPOPcJ aRC4DgT8ix5ZOAx2g2tsza1w+ci5rNDbVN/ktRSWVZYV6rCFSYGAXkGVNiLt0WEEVkUE0hABjKyN DJr2AFmmHQRlzNdQQVoi1icxtQ+2LwjCDgZwJl4bzuzaF4xudMP6+esbjPQproy/tZWbU5ZLz8Q9 F5ZVlIwe7cyNKxhRobCsqrLyJgOCimbk9uizA2sjAumGAEbWKTpix5qaOb+NJKxp2pokr1n+OhD8 qtf90L/9SN3uU9uXLT1x795Hk7KxI0TJ3sIqXYE1s9qwYIoOFpqFCCQBAYysjYA8lMhaY3v9A938 rUV6g5G8aHxNwurRnihKGtYvfb7VsvsxPriGKHv+ggULlm0/xTWsh4t58/75f8+HY/369UI5UwQu npSTijoOv6/byXkb6ushsSGKeZt2794dp4QIRkbkCilw51QPzY1DugMaaWhqgn9SJFmuAyasigiY hADbFQqPFERg7xtvHNh+cM/z+9765e7X1+965bE//nbVyz9fuSqmqfvXzVu3P1xDeHty2333bTtJ yqGE1giXiFf71/F1tIHhaXz77f1uX8jn3k/+gUO4gk+ilkA1+LjRE24DpOjbsB6xgvSCqZTJarMU ayECGYAARtZGfvSSEFmDWfNqarrs7nM9pyDE9vn9Z3pb2sd8+ONfbdRjccXS+9v2NXANW58vuXfJ JF6yah5kSSZNKXGfOElKTp5wu7fcA5H34/V8iaYWSHzsmuNyhiv7PR6uqAgKcp18qbIEassCa6gT oJH1gTZhE4bCstlcI5TsbvKyEFxsSxmUa7IVKyECGYBABvzgYBckCAih9P79QnxNQul54ZBZGWtD ZC0NxrXCKcS4Qw2slbGyamDNYnEMrLUOD9bLOAQwsjbyg5ucyNqIZVzFo3vn7YP88z5OuMcIwXVp VTisBq31j0MYfc8WIdaetOSJyf9Js9t6stYQ48KNQhIQ+0srWHztLCriWhsgHuZmq5aQ3DMNly0g KKafC12u7kaWoeZz34WFRVQzqXnmkz83NpDVfp5GssIbGqUXhrBBIUQgnRHA1SDpPHqabG9Yv+z4 0i1iDgTuOu6bl6TlIprsw0qIACKgBQGMrLWgJK+TwpG1sjsVj4Y9NXwKoXdyFvYZARZlEAFEIBoC GFnj3EAEEAFEIA0QwMjayCClVWRtpIMogwggAqmGAEbWqTYiEfbo5bNO6c6gcYgAIjAEBDCyNgJe ciJr4LMmLKl+oN/r7fP3hfyW0IXs99+qN2IxyiACiECaI4CRdYoOIPJZp+jAoFmIwDAhgJG1EeCT EFmnJp+1EbAot0fSWLCT2ZYxNFAKETCGAEbWxnBLuNQQ+KxhJfVj9VzVuhhL9IDX6fHd0IdQqDJW Nb6XROFuC0wVLZUVyKizTgNTU6PXok5sbZzzGhmuEz4xsYFhQwAjayPQDyWyTjCfNXQHVlKvi7lL Y8P6x9qWvbQHjr2a1lyDwr179jyl0KmFO1uVdRp8aiM3G4ityaGkWDXKeY0M10YmM8qkCwIYWafo SBnksw7HwjEeUzT2EKNCyjh3thY+ay11UnTs0CxEIBEIYGRtBNWhRNYa2zPEZ80x3mrCnyc2I+eq ZjmN3UAPAsTWbE8ZqEKlFtD3hAWbfiReqJos487W2C1GTg0JEEL+IZJTR7BXM01yej2eV4RQiIjs 2UrubM1WYEVEIP0QyDhqqszpkH4+awkzNc9qrcpVHYXzmlBdM/o95YW0UERYpkcz8jLqPCXJnpJe T8m2p2TB1tw+VkQE0hEBjKyN/L4mIbIGs/TzWQMzdckUgbWadkwLV3XFo1sZ654kHjeCilYZedCs YK9WCaxhw0enWxpWq7Bga20f6yEC6YlAOv7CoM1REBDiaPg3HFkruao1R9ZhPTEj6zB3tqaRMRJY e/idZVSjcE2tYiVEIM0RMP8GI0SdTzzxRDJ/udKoxYSbStfkhVyuUrfbzVbvkduAsDGjJeRatpXQ 7/Hr8GCAwkvxhJV8pJBW47Yvu2dLK9PTEpp9naWxkS6zi5Ai7+gywZirBCNnAlkG3RYgqkKh0a4K SnsNqWchDT04OK4ot/0srSCpI5GClSJs+QhdUB0gCwoLZxvZtDeZMxTbQgRMQMB8Z22CUagCEUAE EAFEIBIBzFkbmRHJyVkbsQxlEAFEIEMRwMg6QwcWu4UIIAKZhQBG1kbGEyNrI6ihDCKACAwBAYys hwBe4kWRzzrxGGMLiEB6IICRtZFxSk5kjXzWRsYGZRCBDEUAI+sUHVjks07RgUGzEIFhQgAjayPA JyGyziQ+ayMQq8kgV/XQkUQMh47hcGnAyHq4kI/TbmL5rI102iSuPiNNUxkVrmrieTxF7NEagwfj zg7BszYuH3vKZszXQl2dwlM59BkcVmd0yU2l/ga4gJYKy+TMriIHN7NDWcGgfeaKId+3uXgmVxtG 1kbwHkpknQJ81ka6TGmyH62II6pkuNYipcUeNa5q4Afxc36/T4t8tDpATFIIz0DCU5FOV2kRcbI3 3lBRMho8M6HaLvK4W/1QCCUhaIhekI9icHBTQZUK0Y1kwe5QOqFRFvm+NQKVotUwsk7RgUkkn3XC umyc4dqISeDkPvHncd3OOUMJreFp93pvIYuf3U4apQslpAGOKiclnMvpcuW2ssrq9hri4CZ75sBO DNF0GkEGZTISAYysjQzrUCJrje0ljM+a0Hkw9ur5y7afYtZQzmtSQgitBRprngibcV7LuK35t+up KkGNkuFajRE7gl87rEck19aID6RFPB6uyFWYxwQI33V9fUNTE/zD4lRaAkR9wDsCl4SxL1b86m91 e4pKaT4FWAE5D6Xb9hTNEUqcTnDQPjlhYKSx0k+V9ghWgiVh+kCyZ47HYvE2SmyLYPdW10MJVegh knuzkvow27dmILFiuiCQ5kRUmWx+YvislSTUIrceXIh81vPm3bftZAS6Sq4+yuwnMmZHEGFH47yW 8ALy+kEtYwjUyY4N/Hv73b6QhMIPLmmRWAaU1283Ero+vq76ZKEapDWU3NmsxAPkWPQi2qGkE4y0 R2psWEdcEkJFv0JixwRSb1JCDYN/KQR4ZCACGFkb+VVNQmQNZiWGzxqSyPP2kb1gxLgaOK+r5pFs 9KQlW8SsdNU6QtEX+6BSk6aUuE+c1IqiwLgdIcVa13d4vR5LoO3A7iYP1+2jCV8S17pIJCwGuCQL DR9C0NxNP4h6dLvFsFq5R41YkgvBfLfTmRtNjSzsVtpDkt+RrNy82VKdCnZvpR7yN4XLRVMxRXNo +gTZvfXNnvSsbb6zTjI/KsCeRi3qNfXWO+++85+WLHy0+m+fuvOhDf/y0JMbYk6z4smlbcchtXHq eBtfD0qqniJb44p74zZs314MG+Du3XvviaUsxQF16vfRq1MNDXxiRPtshrZKJxfL6jc0sA3DFIfE QqWU9kY58NVFZXS/3dlF/C1G8Mp5ucQjixewKKMwjy4Yiemqwdf5BecXKc4bxCsElyo0oWqppF3y udIer9frdFUQm7lGMX3BV/N7vfQnh6W96S3KkKw7UoWCAT72QwUfwa1Rdgwpga9jCLBqshEw31kb jjoNdz2NWkywqZOW3Fuy5Z4F83+6h+PqHyMZ6ElLnmC7wIgZ6mJuz1J+n0Y+ogWpKrIn44IFPz1e LBBe76bi4sHv3BhZWE+E7tlScq8Ygwth+z6OxspKKbBnwZ6l8+cv3bPgCZFcW2yL2Rz3IIle2MXR 6yW+DdbSnfnk/Q/3k9V1HpL6pSlnIQec63SycDv2wWeraZ5b0MMkpCVEmVpgze8PCYKQN4aUudsn leLtgUKfu5ElmuGGong/kUbS9fWf+OgPDfy8FLF0NO3XnxvD9oT7VehycSwLL0q5XN2NJEEv5KyT tsIk7mBhBdMQwNUgpkE5whQZW3adXJDYsmJcZ5Fc1LG1BCGAkbURYA0HyIYFjViZWBmzFlAn0kpI OqCnTiTAqDuZCGBknUy0sS1EABFABAwigJG1EeAMB8iGBTd++PO/f+lueD3x3o+NWIwyiAAikOYI YGSdHgO4/Pf/EPT3g632UVnP3/lCehiNViICiIB5CGBkbQRLwwGyYcGfVP/kxmum33jNtDU1jxmx GGUQAUQgzRHAyDqlB3Dv+f/o7x8IDgBhKvw/0DdAXv1whrcD/Q/8P0+mtPVoHCKACJiHAEbWRrA0 HCDrFewb6A+CowY3LXpq/rq/r3/QiOlaZepWWNixok6riIn1oHVol53NPWSah7eb5nYNtWU4AhhZ p/QAv/nls8RNkzia99dCWE1C7B/dtC5h1oMX27kotLlaawNQv6aWVF6+S4eUunb3prkbZhx8+Cg5 a7dAi6VRNOvtrJamsA4iYDICGFkbAVRvgCy2AYJx+aw9Hs8PHvi7O5d9/0tfG4TPLPXBsh80xO53 WEb/3bUP9vUNqJmeiGhUC0TVmwlzzq7lWurGqeM+NmPr5mp2Fqua0i9VzSZYjCoQgSQggJF1EkDW 18Snn3768MMPg8z3Vt4wYeY4ElbDa5BG1jRVvfLGtVE1Qug4rXnNkGNbjqQgdEXWzCK9UmI8zsSj R+Wm9UsVOb1m6xtQrI0ImIIARtZGYDQcWetq7BIs1qPeGWLqoJAMgevoSupWTFt9iKut4VO9LCG7 og48Hb3YRZwpS0OLF1QZX2HuJnc0X0bE6MdEkNXjhaJmtbW0xeJx8YiW80hQv3SNBlZGBIYZAfOd tV5iuaEDkKktzhxXATcY2a1FcpexH67hfuPguj3/errjxGNvrlRAB74PEhFifMre1tYs5bYSf7i5 hmMlcIgX1Osu3bG4BSqsaV6q6q6rN7dsLOeWr1lVyrmPNpVv3AoXXN2G1WW7aOqDq1G9DWisLdXp kKB+DX3qoQZEIHkImO+skxN1ShHK1Bbz7RNo6mMQzleN+8bK8rU/qlj/N1ffE+zv+83B/w88uLZp snzXQeJcox/Hmg8dWj0NQuea2kPNx1Trla5as7x27SY38dDEZ1N33zJzLQm42X1FjUdEW0f5AJ9f d6Jz5YkZ/dJoNVZDBFIAAfOddabGudLBSlwfn3766VdeeYW19cc//vGjXUdIGqR/YEFJDSucVnA1 xNfMg8eaP3V1cRa9QYzMy0+fWQ7BODuiLr6ofngjt3paTdPGh/mbfpCagOS4tpuKUdqikb6WNIik o2b3KwW+g2gCIqANAdN3v3nyySdN1xlbYSa1CI757//+72+lx3333ffMh0/88uCa/7v//zzzwf/L QPjFvp89/NoPV/1hxQ9/tywKLDTRQdyvuDZD9MVEgqQ04Cgvp//Qj/giKNxI0iG8C46QYl45oki6 9OPG+++KmG98RW1taZwvpvRLtS15zzQahNUQgWQigKtBtP2mJbEWDP8Pf/hDoLnfsCH2vjAJtcnM ddMJNXRoykdIN4cGEkqnBgLmO2vIICcuS6AKWgq2eOzTN6dMu9mRkwsrpM9++Zm/+9ylQIdzTGHR pLJRo8emxtCjFYgAIpBOCJjvrNOp9wmzde8bP7t4vrWgcOZXJz7sD/ZwFmgJ/g/B2XXNbV+vuM+R HW+nqYTZhooRAUQgHREw/wZjpq7NkI5u3D7Oq3ncas066X6vv494apvNbneMys4ZA+fWz996fdvy C+da03G6oM2IACIwXAhgZJ0Q5Jv+9NtPP9hKVVvAU9uysoK9Ab6lEGfNsjvzCqv/7t+zsrIT0jwq RQQQgYxDwHxnnYIZZFNGbfc77x45/LlS1VVXX1P5nVtk5e/ufNxz4s8WKxxZQJzHUiB5lxVZs7Js 1qzBwVBH+8mSq2+de8s/m2IbKkEEEIGMR8B8Z52pkMEKaFikoezdM888s3Kl/GHC/9m55szJj2xZ DvDUOaO+ZrNlWW1Z3R1eq80GF+DBrVb7pZ6OBYvWTSz+eqYihv1CBBABExHAnLURMGdVPRJbLIcs +bDYrHYIqIl3zrJ3d561ZdltNkd+oYu+SrJH5R39ZKeR5lEGEUAERh4C5jvrJK/bgyFLWouDoRB7 QaPSa+W0yS+cAYXBXr8zLx98tL/r3LjxU8ircCrE11DS3ekZ5RwL0be/66z+WadCmS8WRW4YoJdZ lKkBpiZk5dc/LCiBCCQSAfOdddyVEqZ3J5kt3vGPr8CrZOo32IXYFxlL9eUTr4Ys9ajcsZAAITcY bQ44Q3wNsTbx1B1eiKzHXT4Vrlub39EPiJI82s0tgmcP+SfxWhZxAn0e1NRF388okw7teH16JCeU fhtRAhFABExFwHxnnbQ4V8QhaS12d3W+9ItKeLV98SG7gBJmBrNBPF+WPznLPip4yW+xZgW62y/L nwS3Fv1d533d58YVTAEf7evw+jvPjh0/9cJZdVpSnaNcWl0dJmuKeKNTEa2+vIx73RSzjDSOMogA IqCGgPnOOplxLutR0loMBHrYCxqVXiuBtVisFbf+GNIlfl87uGZIW5MQO8t+WUExXDN/PfbyKfBo TGf7CaW4ClV0PPZotcGNJK0mFHdz51Jm64itFdXIrBfNiPDWkY3r0INfOkQAETALAfOdddLi3ORH 1mKL9S+uijsAV069YV7NE6HBQeCgJs7ddxHia7IsBELs7nOwUMTfeS43N9/Xdaa/71KkNiVVNFBO M/bolo1NOzXvISslreZbWLyVpUpEEuooZNbVC2ccOypYFWHPLlqqVU9cmLACIoAIaEPAfGedtDhX 7GByWoT11K+qHVAeDeqJk78+//a1cD/y7FfN8PxLT6ATIu5A9wXw2pflF4O/zsm9DFZid1w4GalB SRUNNNDLFxFu0tJVQ9pCtmyGnNk6Gpl16XTuiMChqrRHux5t0xBrIQKIQDwEzHfWmRpZw5MvsJ5a eSifiJFiXnRl2R33br1hwT8H+/rPn2k5fvSA5/ThC+dPBnztVpsd0tlwtlpssshaQRUNlNO1LKJ2 19WZmk2OSmZdOv0qMbLWQF2tiRQ73mzEzxEBRCAqAuY76+TEudIOpXiLkJguvaZq4ZLf/M19/3XD t/936TXVoUHbmVOftx3Z19b8fn9f7yjnOHlkDVkKfhOW2hqy4yHdqYUWLT06vZTfYAW2aGFlbFct xvYpbsCoWqKcB6WrtrINX8iCvRapktKFiynjNdkURmLP98r/yN9UjVAWocfUnxP89iICiABBAJ9g HLZ50Hup68K5L+AG44zZ34P0yLDZgQ0jAohAOiBgvo9I8TjXlEGJ28dXml7uutQFbQUHgodOHPjD Z7//jz/Vvtn8Rrv/vGgAkPBNmDR75pzb0VObMiioBBHIbAQwsk7I+K7c+WDzucOzJ1z33hd7+kJ9 E8dPcGQ7Oi92ne08+/1r7/rRtx7Jzc5LSMOoFBFABDIUAYysjQxs3Mh60+2/zrZn/2XgYF7x6PHT 823jrVljrUXTLp8za/ae4+8ufOHW5rNHjDSMMogAIjBSEcDIOiEj/9zBZ5754FeFMwrsNrvD5si2 5fR2B+02h8NK1n5k9+acvXD2d3fvzMnKSUjzqBQRQAQyDgHznTXyWcMkWfHqfUcHP8sZk51ty77U 1Zud57Bw1oljroC38LKELO9/sL/K9d0nKtdm3IzCDiECiEBCEDDfWSfEzBRQqovP+oFXlx2zHXbm Ovt8/fn544iPtmafvnh6nDV/tGO03ZYdvBR8/7P3nr/jhblTKlKgc2gCIoAIpDoCmLM2MkJx+awL nAWDlwbBR0PeA9y0w5bt7wqMtY7r6Ls48fIrriy8YsaUGbeW3brt4xeNNI8yiAAiMPIQMN9ZZ+oT jDA3tPNZzyos6+nuDfp6C/ILHFnZ/k5/YUFR8YTJ10+94dPjTQ6r4+LFC/Zs+/4T753p+kr/rFOS TUfQWZPHaFQOLRTVEj3sURuTD7382qx5Y1Imm47qEIHhRcB8Zx13pYTpHU5mixr5rK+74npft2/c 2Hzw1BBWk3uMWY5sqwOux4+6/MDhhilFU6+dWnbNldfu/PwP+gFR8lkzziZgaCJcT9zqDWqOViml bDmsp2Xm2ihOX7+9YQkt/NpK16xFaihWoSwikAYImO+sMziy1s5n7Sooddqd3tNn7Va7v8M/oWCC w5bT0dF58cKFa6fOsnK2Tn/Hufaz35x585FzKpvwpsLEgafNuR3DwWrtPioQSKUCDGgDIpAqCJjv rJMZ5zIUk9aidj5rq8W6ofqXXu/Z48dPAq8exNfZNkeW1V5cNBlyIN+7/vaDhw+6JpR2BbqPnT+m nAtG+awpVcg0IFOF3WFEMmsZq7WiNTU+a1KpdEbZoWbeOEWdcLpEDL8jjBYa5QtF9hIpkzZfZ4Ww kxif8Zi2+pCc4SSCf5tUi7BHqichuZtU+bKiHSMbAfOddQZH1uJU0cJn/a2S+b++/bkvz3x5vr09 y2K/eKFjctFkunQvp+lo49VXXgPJkFlTrz3deTLQF4ichIb5rAlR9XKufOZ00CeSWauwWkuai8Jn HWGQsk7dzlqacoHj4CrKuipj3GaN1tYs5baSSmxrMZklfB1uEU3d8FG8mIcRdyNT2i/Y07J4x1JI z0v0hBbt5GmtRvbXGnufiQiY76yTFueKw5GcFg3wWd805ZvP/dWWLz2nX9u309/r9/cEICviPe+9 adbN5dPnftLyyWWjxhbkjW873xo5tYbCZ139cLSUtfr0jcZnDe73aBNz+5yyDvhHcItsa12mV5Vx e/ku3pXH+OpQnm5pFB//awZtUULtCCnG940HIpCxCJjvrDM1sjbGZ/2NSTe+c/97j3zzsb4L/dt3 b33+zdqunk5P+1e+Hl/J+JIX334hP7fAZjOTz5qyqa6NWA8SKwsclYfa/foObvFCGjUr69Rt2gQ7 6sKxpnkayzwMjXE7/MMg+abV1UVZjwJtNR2FHwlVqYz9qmLHRjwC7G9ZE48nn3zSRG1aVKVLi509 na99/of17/7s3pfvnvfc3Gs2lta8VHnd01ef852VdxNSCOJRvhH2LSdJBXrQd9KPoWz5G+ESkp1o 2QhE1OIFyJRTYurbbouY7UIeg9Zmqo9JNQufE9skdYgx4fesHXqoWyjVIpqtkJGoCeviaymlxPYj oaHblVGYpI1qmUFYBxFIAwTwCcZh+7nu6Ok4dq7Z3d5y15wf2OSbxQybVcltGO4N7lzEZ7ST2zK2 hgikGwLmp0GSk0GW4pymLV426rIbist/cN3SkeqpYQxxAXW6OQy0d/gQwMg6IdgP9vl6T77GWbMH +/ysAeuo8aMmfTchjaFSRAARGAEIYGRtZJDjxvIWSGtYbbaBDru1z24bsFmCAz3egYBH+er3ybY2 N2IPyiACiEDGI4CRdUKGODTQG2h5ycL1g/ZQaBB8d2ggSFuywH/kzP5xfM3qGJNTfHtCjECliAAi kEEImO+skc+aOOiBXt/hfx+VV8TBTrgWKwm0+Re7hkJ65mw9F1ucM5Zl0IzCriACiEBCEDDfWSfE zBRQqovPmnfWYyaCU47wztRH8yUc+ch35lBe2b+kQP/QBEQAEUhpBDBnbWR44vJZ80ojPTXz0WKU bbGSvLaR5lEGEUAERh4C5jvrTH2CEeaGdj5rNpFkMXVI9N0cTYPAmbwMHInjsybGhEmakBbJwOCg CCKQGASMOYtYtsRdKWF6R5LZokY+a+arxdw0i6YtLFXNCdcksjaGf+L4rAmfHTymwj+TOJM81B3l wA0BTJ/IqBARiIWAMWcRS2MGR9ba+ax5gIS8hxBT05uKVhtJgIi3HFNrfgIjSJnIiFS9ijHqqR3I Op1aA4fWZD4C5jvrZMa5bHyS1qJ2PmvBWfMZahpT06QH89H8BQu0VY7h47MGQjuZPaps0XUr5KzT kuRJAjaYyfwvIvYQEYiHgPnOOoMjaxFMLXzWpHJ4xZ4QU7NkCImsrRa6GkRtgIaNz7pFxRpVtmgl 67SS4Tre1MPPEQFEQA8C5jvrpMW5YjeT06JePmtr9teEhR98QC2530jdNHXZaoM1jHzWwD6qOn3i skUrGa71TEOsiwggAvEQMN9ZZ2pkrZfP2mrPC4Xg8UVy8P+EYDkJPM84KLwG4EI1sl4xrXmNlHVU D1v0UPisazjYeTEk3lUE1uroNxgFw3nWaSXDdbyph58jAoiALgRMp3FNF3bpoXQ8bh8H+3uCZ94N tP2u69NfxX5d/NP/UbFkmPisZVzVlBZaSictY4umb3nuaJHxGtmkhzKzUBYRiIoAPsGo66cNKyMC iAAiMDwImJ8GSU4GWYpWCrb4StPLXZe6wMjgQPDQiQN/+Oz3//Gn2jeb32j3nx+eccZWEQFEIM0R wMg6IQO4cueDzecOz55w3Xtf7OkL9U0cP8GR7ei82HW28+z3r73rR996JDc7LyENo1JEABHIUAQw sjYysHFj+U23/zrbnv2XgYN5xaPHT8+3jbdmjbUWTbt8zqzZe46/u/CFW5vPHjHSMMogAojASEUA I+uEjPxzB5955oNfFc4osNvsDpsj25bT2x202xwOq91qsWX35py9cPZ3d+/MycpJSPOoFBFABDIO AfOdNfJZwyRZ8ep9Rwc/yxmTnW3LvtTVm53nsHDWiWOugLfwsoQs73+wv8r13Scq12bcjMIOIQKI QEIQMN9ZJ8TMFFCqi8/6gVeXHbMdduY6+3z9+fnjiI+2Zp++eHqcNX+0Y7Tdlh28FHz/s/eev+OF uVMqUqBzaAIigAikOgKYszYyQnH5rAucBYOXBsFHQ94D3LTDlu3vCoy1juvouzjx8iuuLLxixpQZ t5bduu3jF400jzKIACIw8hAw31ln6hOMMDe081nPKizr6e4N+noL8gscWdn+Tn9hQVHxhMnXT73h 0+NNDqvj4sUL9mz7/hPvnen6Sv+si8FnrYuCOsxcbYGDiCo167cOJRABRCABCJjvrOOulDC9F8ls USOf9XVXXO/r9o0bmw+eGsJqco8xy5FtdcD1+FGXHzjcMKVo6rVTy6658tqdn/9BPyAx+Kw3V+tQ J/IxkYemWhZxbk6pWYc6rIoIIAKJQ8B8Z53BkbV2PmtXQanT7vSePmu32v0d/gkFExy2nI6OzosX Llw7dZaVs3X6O861n/3mzJuPnPs8caOrWTPZSeBYdXVU9mrNirAiIoAIJAgB8511MuNcBkrSWtTO Z221WDdU/9LrPXv8+Emr1QrxdbbNkWW1FxdNhhzI966//eDhg64JpV2B7mPnjymH1iiftUITr0jC MC2qpomPXUSitsZSUxtzfsWyR0igJGiColpEABFgCJjvrDM4shYnjRY+62+VzP/17c99eebL8+3t WRb7xQsdk4sm06V7OU1HG6++8hpIhsyaeu3pzpOBvkDkdDTMZy2b1e5NS3csBnKmlsU7ljL+PCgR +fyAgWlzDSmECylxlPKroWpPhB49uRf86iECiIARBMx31kmLc8XuJqdFvXzWYN5NU7753F9t+dJz +rV9O/29fn9PALIi3vPem2bdXD597ictn1w2amxB3vi2862RQzcUPmupJtj2pWwGpDZKZ5QdaqYB PDCgNtWQWLiG2yXNbkOqOkayW2lPND1GpiDKIAKIgBYEzHfWmRpZ6+WzZuh/Y9KN79z/3iPffKzv Qv/23Vuff7O2q6fT0/6Vr8dXMr7kxbdfyM8tsNlk+8XAplnG+axZu0Av3UJYsJsIOTXsl1g+czot 3rC6jPCehmL5ZsW8UdpjTI+WCYl1EAFEIAoCptPHxuV6zoAWjXWhs6fztc//sP7dn9378t3znpt7 zcbSmpcqr3v66nO+s3KFxvmshWFmNNM8y3T5RspULWWnhuzHGxFc1YrPiSaerDoiTUKVSQwU6hgD BaUQAURAGwL4BOOw/Yx39HQcO9fsbm+5a84PbFF2zjXbOFj1sXZmy0G6aTlc71ykK8IOW2OWHrP7 h/oQgcxFwHxnnancIJk7B7BniAAikAYImO+sU7DTg32+rkOrBy619wU8zLyscWUFN/8mBU1FkxAB RAARUEXA/BuMyVmbIe1M/BZDAwM9px3BNmdWINfRl2Px9bV/3Hvuz6ovnCiIACKACKQgAiMjsg52 nnu9wsb1wgAMDPRbrfaBPh/HWcjLAmcrPVuycouz8iZf9q2XUnCc0CREABEY4QiY76yTk7Pe/c67 Rw6rPKgNq6FhjZ1sUAeDnWf+qzj/yq9zVju8LFYHZ3VYbHbOQq/hAsrpdXvLa4V/3TTC5wR2HxFA BFIQgf8fmXhUAysJ9m0AAAAASUVORK5CYII= --_004_381D7D55085B1E4D8B581BD652E1E140C92641FBnkgeml513mbschi_-- From nobody Fri Jan 12 01:21: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 643BF12DA68 for ; Fri, 12 Jan 2018 01:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBt3dmAQSQOL for ; Fri, 12 Jan 2018 01:21:00 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60131.outbound.protection.outlook.com [40.107.6.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF54712D77C for ; Fri, 12 Jan 2018 01:20:59 -0800 (PST) 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; bh=O2umOT4xLPsO28YeT8mSty3PENzoiMyXNd5mgUViHKw=; b=aayC28TiV/xJ0E/ZnLarzGfxNFE35Y1CknmYnsd/JPTS193GtFxafBR3tPsVMRsEzuAVv+5d5jMmKOtbvG8Jndt3QqsQwZq+f0iKJN6/tTHBHqRAW0tEgKuL/FnzuZVNrZIvTajG3fzJtrlrnkDDnzgBblP0K/X0hUsqPc0/uuM= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB1665.eurprd07.prod.outlook.com (10.166.133.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Fri, 12 Jan 2018 09:20:56 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::a52a:4acb:dfe8:24c0%14]) with mapi id 15.20.0407.009; Fri, 12 Jan 2018 09:20:56 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-entity-06 Thread-Index: AQHTeZsGj/By4wgWGkSTA5QT6Ag4U6NN6XKHgBw2jXCAAazigIABZ5tAgAGdp6OAAUenoA== Date: Fri, 12 Jan 2018 09:20:56 +0000 Message-ID: References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> In-Reply-To: <20180111.144705.493071366326080006.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1665; 7:dDMTrHy/1vLqdSSl0n1dPTHf+40To3cy9RW20/C8MM61z5Myj4O2qROfH0qES/CL8t5QSAsRlzUWQODSNMqDShScnAwHag66CFqUiK3+MHPg5qAJgitxlo8Vx8GaBjOgJHoxv5I/Ag5GYrODHqesAImbQC39AEDAMgxqfThVmG8mkjoyhO4pvfDV5buUPWX9nWHbMIf90uEwHI524Q14Bh9pZeGO3gi5B+p7yZlidGtmiH6HI92jJCPHLBOW+WFi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d70b7e7e-e975-4358-96d4-08d5599dc972 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020079)(4652020)(4534109)(4602075)(4627205)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB1665; x-ms-traffictypediagnostic: AM4PR07MB1665: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(82608151540597)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(11241501184)(806099)(944501142)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041268)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB1665; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB1665; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(366004)(346002)(376002)(39860400002)(54094003)(51444003)(24454002)(40224003)(13464003)(189003)(199004)(81166006)(102836004)(66066001)(8936002)(105586002)(106356001)(2906002)(966005)(7736002)(59450400001)(7696005)(99286004)(14454004)(93886005)(68736007)(316002)(230783001)(76176011)(6506007)(53546011)(8676002)(81156014)(6916009)(2950100002)(33656002)(55016002)(4326008)(53946003)(229853002)(478600001)(86362001)(74316002)(53936002)(3280700002)(3660700001)(305945005)(6116002)(3846002)(9686003)(5660300001)(25786009)(6246003)(6436002)(6306002)(5250100002)(97736004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1665; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: w/X/xlWOHLfMIMM+uyqI3DArigGnXy6NmfT5KcsQfQFYIS1c8p2QtDbp1+mXgtzSpcpNhtzeHGTi7+B5nlf9qu7G3Yf54gji9fbL6h9pIkJ3rvV2ehfR4NHmGForp76K spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d70b7e7e-e975-4358-96d4-08d5599dc972 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 09:20:56.6323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1665 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 09:21:03 -0000 SGkgTWFydGluLA0KDQpXZSBhZ3JlZSB3aXRoIG9wdGlvbiAyLg0KDQpSZWdhcmRzLCBCYXJ0DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWls dG86bWJqQHRhaWwtZi5jb21dIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggMjo0 NyBQTQ0KVG86IEJvZ2FlcnQsIEJhcnQgKE5va2lhIC0gQkUvQW50d2VycCkgPGJhcnQuYm9nYWVy dEBub2tpYS5jb20+DQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0g QUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wNg0KDQpIaSwNCg0KVG8gc3Vt bWFyaXplIHRoaXMsIEkgdGhpbmsgd2UgaGF2ZSB0aHJlZSBvcHRpb25zIGZvciB0aGUgdGhyZWUg bm9kZXMgJ21vZGVsLW5hbWUnLCAnbWZnLW5hbWUnLCBhbmQgJ3NlcmlhbC1udW0nOg0KDQogIDEu ICBEbyBub3RoaW5nIChrZWVwIHRoZSBub2RlcyBhcyBjb25maWcgdHJ1ZSkuDQoNCiAgMi4gIE1h a2UgdGhlc2UgdGhyZWUgbm9kZXMgY29uZmlnIGZhbHNlIChmYWlybHkgc2ltcGxlIGNoYW5nZSku DQogICAgICAodmVuZG9ycyBjYW4gYXVnbWVudCB3LyB0aGVpciBvd24gY29uZmlnIHRydWUgbm9k ZXMpLg0KDQogIDMuICBBZGQgdGhyZWUgbmV3IG5vZGVzIGZvciB0aGUgY29uZmlndXJlZCB2YWx1 ZXMuDQoNCg0KQWZ0ZXIgdGhpbmtpbmcgYWJvdXQgdGhpcyBzb21lIG1vcmUsIGFuZCBkaXNjdXNz aW5nIHdpdGggQmVub2l0LCBJIHRoaW5rIHRoZSBiZXN0IHBhdGggZm9yd2FyZCBpcyB0byBkbyAy LCBpLmUuLCBtYXJrIHRoZSBub2RlcyAnbW9kZWwtbmFtZScsICdtZmctbmFtZScsIGFuZCAnc2Vy aWFsLW51bScgYXMgImNvbmZpZyBmYWxzZSIuICBBcyBzdWNoIHRoZXkgd291bGQgbm90IGJlIGNv bmZpZ3VyYWJsZSwgYW5kIHRodXMgY29udGFpbiB0aGUgZGV0ZWN0ZWQgdmFsdWVzLg0KSWYgbm8g dmFsdWUgaXMgZGV0ZWN0ZWQsIHRoZSBub2RlIGlzIG5vdCBwcmVzZW50Lg0KDQpOb3RlIHRoYXQg MSBvciAzIGNhbiBiZSBkb25lIGluIGEgZnV0dXJlIHVwZGF0ZSB0byB0aGlzIG1vZHVsZSAob3Ig YnkgYSB2ZW5kb3IpLg0KDQoNCi9tYXJ0aW4NCg0KDQpNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFp bC1mLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gIkJvZ2FlcnQsIEJhcnQgKE5va2lhIC0gQkUv QW50d2VycCkiIDxiYXJ0LmJvZ2FlcnRAbm9raWEuY29tPiB3cm90ZToNCj4gPiBIaSwNCj4gPiAN Cj4gPiAtLS0gc25pcCAtLS0NCj4gPiANCj4gPiA+IHN0YXRlLuKAnSwgc28gdGhlIGFib3ZlIHNl bnRlbmNlIG9ubHkgYXBwbGllcyBmb3IgdGhlIHNlY29uZCBjYXNlIGJlbG93Lg0KPiA+IA0KPiA+ IE9rLg0KPiA+IA0KPiA+ID4gMi4gVGhlIHNlY29uZCBjYXNlIGlzIHRoYXQgc29tZXRoaW5nIGlz IGRldGVjdGVkIGJ1dCBpdCBjYW7igJl0IGJlIHJlYWQuDQo+ID4gPiBXZSBkbyBub3Qgc2VlIGEg cmVhc29uIHRvIHVzZSB0aGUgdmFsdWUgY29uZmlndXJlZCBmb3IgdGhlIGxlYWZzIA0KPiA+ID4g 4oCYc2VyaWFsLW51beKAmSwg4oCYbWZnLW5hbWXigJkgYW5kIOKAmG1vZGVsLW5hbWXigJkgb2Yg YSBtYXRjaGluZyBlbnRyeSBpbiANCj4gPiA+IHRoZSBjb25maWd1cmF0aW9uIGRhdGEuICBUaGVz ZSBsZWFmcyBhcmUgZGVmaW5lZCBhcyBvcHRpb25hbCBzbyANCj4gPiA+IHdoeSB3b3VsZCB3ZSBy ZXBvcnQgc29tZXRoaW5nIGVudGVyZWQgYnkgYW4gb3BlcmF0b3IgaW4gdGhlIA0KPiA+ID4gb3Bl cmF0aW9uYWwgZGF0YXN0b3JlIHRoYXQgaW50ZW5kcyB0byByZXBvcnQgb24gd2hhdCBpcyBkZXRl Y3RlZD8gIA0KPiA+ID4gSXMgaXQgbm90IGJldHRlciB0byBub3QgcmVwb3J0IHRoZW0gYXQgYWxs PyAgSW4gYW4gTk1EQSBjb250ZXh0IGl0IA0KPiA+ID4gd291bGQgYmUgcG9zc2libGUgdG8gaGF2 ZSBhIGRpZmZlcmVudCB2YWx1ZSAob3Igbm8gdmFsdWUgYXQgYWxsKSANCj4gPiA+IGZvciBjZXJ0 YWluIGxlYWZzIHdoaWxlIHRoZXJlIGlzIHNvbWV0aGluZyBpbiB0aGUgcnVubmluZy9pbnRlbmRl ZCBkYXRhc3RvcmUuDQo+ID4gDQo+ID4gVGhlIG5vcm1hbCBOTURBIHByb2NlZHVyZSBmb3IgYSBj b25maWd1cmF0aW9uIGxlYWYgaXMgdG8gcmVwZWF0IGl0IA0KPiA+IGluIG9wZXJhdGlvbmFsIHN0 YXRlLiAgVGhpcyBpcyB0aGVuIHRoZSAiYXBwbGllZCBjb25maWd1cmF0aW9uIi4NCj4gPiBJIGRv bid0IHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc3BlY2lhbCBydWxlIGZvciB0aGVzZSBsZWFmcy4N Cj4gPiANCj4gPiBUaGlzIGFsc28gbWVhbnMgdGhhdCBhIGNsaWVudCB0aGF0IGp1c3Qgd2FudHMg dG8gcmVhZCBhbGwgdGhlIHNlcmlhbCANCj4gPiBudW1iZXJzIGNhbiBkbyBzbyBmcm9tIG9uZSBw bGFjZSwgdGhlIG9wZXJhdGlvbmFsIHN0YXRlLCByZWdhcmRsZXNzIA0KPiA+IG9mIGhvdyB0aGV5 IGNhbWUgaW50byBleGlzdGFuY2UuDQo+ID4gDQo+ID4gW0JvZ2FlcnQsIEJhcnQgXQ0KPiA+IA0K PiA+IFdlIGRvIHVuZGVyc3RhbmQgdGhhdCBhIHRhcmdldCBvZiBOTURBIGlzIHRvIHJlYWQgb3V0 IHRoZSBhY3R1YWxseSANCj4gPiBhcHBsaWVkIGRhdGEgaW4gb25lIHJlcXVlc3QuICBCdXQgdGhl IHJlc3VsdCBzaG91bGQgbm90IGJlIA0KPiA+IGNvbmZ1c2lvbi4gQSBrZXkgd29yZCBpcyDigJxh cHBsaWVk4oCdLg0KPiA+IA0KPiA+IFNlY3Rpb24gNS4zIG9mIGRyYWZ0LWlldGYtbmV0bW9kLXJl dmlzZWQtZGF0YXN0b3Jlcy0wOSBhbHNvIGNvbnRhaW5zIA0KPiA+IChJIHB1dCBhIHBhcnQgb2Yg dGhlIHNlY3Rpb24gYmV0d2VlbiAqKiopOg0KPiA+IFRoZSBkYXRhc3RvcmUgc2NoZW1hIGZvciA8 b3BlcmF0aW9uYWw+IE1VU1QgYmUgYSBzdXBlcnNldCBvZiB0aGUgDQo+ID4gY29tYmluZWQgZGF0 YXN0b3JlIHNjaGVtYSB1c2VkIGluIGFsbCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMgDQo+ID4g ZXhjZXB0IHRoYXQgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIHN1cHBvcnRlZCBpbiBhIGNvbmZp Z3VyYXRpb24gDQo+ID4gZGF0YXN0b3JlICoqKk1BWSBiZSBvbWl0dGVkIGZyb20gPG9wZXJhdGlv bmFsPiBpZiBhIHNlcnZlciBpcyBub3QgDQo+ID4gYWJsZSB0byBhY2N1cmF0ZWx5IHJlcG9ydCB0 aGVtICoqKi4NCj4gDQo+IE5vdGUgdGhhdCB0aGlzIHRleHQgdGFsa3MgYWJvdXQgdGhlICpzY2hl bWEqLiAgSXQgaXMgaW50ZW5kZWQgZm9yIA0KPiBzZXJ2ZXJzIHRvIG1pZ3JhdGUgdG8gTk1EQSB3 aXRob3V0IGhhdmluZyB0byBpbnN0cnVtZW50IGFsbCBjb25maWcgDQo+IG5vZGVzIGluIDxvcGVy YXRpb25hbD4gaW1tZWRpYXRlbHkuICBJZiB5b3UgYXBwbHkgdGhpcyB0byANCj4gaWV0Zi1oYXJk d2FyZSwgaXQgY291bGQgYmUgYSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHRoZSBub2RlIA0KPiAi c2VyaWFsLW51bSIgaW4gY29uZmlnLCBidXQgbm90IGluIDxvcGVyYXRpb25hbD4gKHdoaWNoIHdv dWxkIGJlIA0KPiB3ZWlyZCkuDQo+IA0KPiA+IEZvciBleGFtcGxlLCBpdCBpcyBleHBlY3RlZCB0 aGF0IHRoZSB2YWx1ZSBvZiBtdWx0aXBsZSBsZWFmcyBuZWVkIHRvIA0KPiA+IGJlIGEgY29uc2lz dGVudCBzZXQsIGUuZy4gdGhlIG1mZy1uYW1lLCB0aGUgbW9kZWwtbmFtZSwgYW5kIHRoZSANCj4g PiBzZXJpYWwtbnVtLg0KPiA+IFN1cHBvc2Ugd2UgaGF2ZSBhIHVzZSBjYXNlIGluIHdoaWNoIGEg aGFyZHdhcmUgY29tcG9uZW50IGlzIA0KPiA+IHBsYW5uZWQvY29uZmlndXJlZCAoZS5nLiBhIGJv YXJkIHN1cHBvcnRpbmcgRFNMIGludGVyZmFjZXMpIGJ1dCBhIA0KPiA+IGRpZmZlcmVudCBvbmUg aXMgcGx1Z2dlZCAoZS5nLiBhIGJvYXJkIHN1cHBvcnRpbmcgZXRoZXJuZXQgDQo+ID4gaW50ZXJm YWNlcykuDQo+ID4gU3VwcG9zZSBpdCBpcyBwb3NzaWJsZSB0byByZWFkIHNvbWUgZmllbGRzIG9u IHRoZSBkZXRlY3RlZCBjb21wb25lbnQgDQo+ID4gYnV0IGR1ZSB0byBhbiBpc3N1ZSBub3QgdG8g cmVhZCBvdGhlciBmaWVsZHMuDQo+ID4gSWYgaW4gdGhhdCBjYXNlIHRoZSBvcGVyYXRpb25hbCBk YXRhc3RvcmUgd2lsbCBiZSBjb21wbGV0ZWQgd2l0aCB0aGUgDQo+ID4gZGF0YSB0YWtlbiBmcm9t IHRoZSBydW5uaW5nIGRhdGFzdG9yZSwgdGhlbiB0aGUgcHJlc2VudGVkIHZpZXcgbWlnaHQgDQo+ ID4gYmUgaW5jb25zaXN0ZW50Lg0KPiANCj4gVGhpcyBpcyB0cnVlIGZvciBvdGhlciBzaW1pbGFy IG5vZGVzIGFzIHdlbGwgLSAiYXNzZXQtaWQiIGFuZCAidXJpIi4NCj4gDQo+ID4gVGhlIHF1ZXN0 aW9uIGlzIGFsc286IHdoYXQgZGF0YSBpcyBhcHBsaWVkPyBPdXIgYXNzdW1wdGlvbjogaWYgdGhl cmUgDQo+ID4gaXMgYSBtaXNtYXRjaCBiZXR3ZWVuIGRldGVjdGVkIHZlcnN1cyBjb25maWd1cmVk IGhhcmR3YXJlLCB0aGVuIHRoZSANCj4gPiBpbnRlcmZhY2Uvc2VydmljZSByZWxhdGVkIGRhdGEg dGhhdCBpcyBjb25maWd1cmVkIGNvbnNpc3RlbnRseSB3aXRoIA0KPiA+IHRoZSBwbGFubmVkIGhh cmR3YXJlIGlzIG5vdCBhcHBsaWVkIG9uIHRoZSBtaXNtYXRjaGluZyBoYXJkd2FyZS4gDQo+ID4g SS5lLiB0aGUgZGV0ZWN0ZWQgaGFyZHdhcmUgaXMgbm90IGJyb3VnaHQgaW4gc2VydmljZSBzbyBu b3QgDQo+ID4g4oCYYXBwbGllZOKAmSwgdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBvbmx5IChh Y2N1cmF0ZWx5KSByZXBvcnRzIG9uIA0KPiA+IHdoYXQgaXMgZGV0ZWN0ZWQuDQo+IA0KPiBJZiB0 aGVyZSBpcyBhIG1pc21hdGNoIGFuZCB0aGUgc2VydmVyIGRvZXNuJ3QgYXBwbHkgdGhlIGNvbmZp Z3VyZWQgDQo+IHZhbHVlcywgdGhlbiBvYnZpb3VzbHkgdGhlIGNvbmZpZ3VyZWQgJ21mZy1uYW1l JyBldGMgYXJlIG5vdCBjb3BpZWQgdG8gDQo+IDxvcGVyYXRpb25hbD4uDQo+IA0KPiA+IFdlIGRv IG5vdCBzZWUgdGhpcyBhcyBhIHNwZWNpYWwgcnVsZSBmb3IgdGhpcyBkYXRhIGJ1dCByYXRoZXIg d291bGQgDQo+ID4gYXBwbHkgYSBnZW5lcmFsIHJ1bGU6DQo+ID4gLQlpZiB0aGVyZSBpcyBhIOKA mG1pc3NpbmcgcmVzb3VyY2XigJksIHRoZW4gdGhlIGRhdGEgaXMgbm90IHJlcG9ydGVkIGluIHRo ZQ0KPiA+ICAJb3BlcmF0aW9uYWwgZGF0YXN0b3JlLg0KPiA+IC0JSWYgdGhlIHNlcnZlciBpcyBu b3QgYWJsZSB0byByZXBvcnQgYWNjdXJhdGVseSwgdGhlbiB0aGUgZGF0YSBpcw0KPiA+ICAJb21p dHRlZCBmcm9tIHRoZSBvcGVyYXRpb25hbA0KPiANCj4gSSB0aGluayB0aGF0IGlmIHlvdSB3YW50 IGNvbXBsZXRlIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgdmFsdWVzIG9mIA0KPiAnbWZnLW5hbWUn LCAnbW9kZWwtbmFtZScsIGFuZCAnc2VyaWFsLW51bScgaW4gY29uZmlndXJhdGlvbiBhbmQgDQo+ IG9wZXJhdGlvbmFsIHN0YXRlLCB0aGVuIHRoZXNlIHNob3VsZCBiZSBtb2RlbGxlZCBhcyBzZXBh cmF0ZSBsZWFmcy4NCj4gV2Ugc2hvdWxkIGhhdmUgYSBjb25maWcgZmFsc2UgbGVhZiAnc2VyaWFs LW51bScgdGhhdCBvbmx5IGNvbnRhaW5zIHRoZSANCj4gZGV0ZWN0ZWQgdmFsdWUgKGlmIGZvdW5k KSwgYW5kIGEgY29uZmlnIHRydWUgbGVhZiAnY29uZmlnLXNlcmlhbC1udW0nDQo+IG9yIHNvbWV0 aGluZywgdGhhdCBjb250YWlucyB0aGUgY29uZmlndXJlZCBzZXJpYWwgbnVtYmVyLg0KPiANCj4g QnV0IGlmIHRoaXMgaXMgdGhlIGNhc2UsIEkgd29uZGVyIGlmIGl0IHdvdWxkbid0IGJlIGJldHRl ciB0byBsZWF2ZSANCj4gc3VjaCBhZGRpdGlvbmFsIGNvbmZpZyBvYmplY3RzIHRvIHZlbmRvcnMs IGFuZCBzaW1wbHkgbWFrZSB0aGVzZSB0aHJlZSANCj4gbm9kZXMgY29uZmlnIGZhbHNlIGluIGll dGYtaGFyZHdhcmUuDQo+IA0KPiANCj4gL21hcnRpbg0KPiANCj4gPiANCj4gPiBSZWdhcmRzLCBC YXJ0DQo+ID4gDQo+ID4gL21hcnRpbg0KPiA+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBCZXN0IHJl Z2FyZHMsIEJhcnQNCj4gPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUm9iZXJ0IA0KPiA+ID4gV2lsdG9uDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgRGVjZW1i ZXIgMjEsIDIwMTcgNDoxNCBQTQ0KPiA+ID4gVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPjsgbmV0bW9kQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gQUQg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wNg0KPiA+ID4gDQo+ID4gPiBIaSBN YXJ0aW4sDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gT24gMjEvMTIvMjAxNyAxMTozNywgTWFydGlu IEJqb3JrbHVuZCB3cm90ZToNCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IEkgbmVlZCBX RyBpbnB1dCBvbiB0aGlzIGlzc3VlLiAgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBoYW5kbGUgDQo+ ID4gPiA+ICdzZXJpYWwtbnVtJywgJ21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJy4gIEkgdGhp bmsgdGhleSBzaG91bGQgDQo+ID4gPiA+IGFsbCBiZSB0cmVhdGVkIHRoZSBzYW1lLiAgQmFzZWQg b24gcHJldmlvdXMgV0cgZGlzY3Vzc2lvbiAoc2VlIA0KPiA+ID4gPiBlLmcuIHRoZSBtYWlsIHRo cmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlzc3VlICMxMyIpLCBJIA0KPiA+ID4gPiB0 aGluayB0aGV5IHNob3VsZCBhbGwgYmUgY29uZmlndXJhYmxlLCBidXQgdGhlIGNvbmZpZ3VyZWQg dmFsdWUgDQo+ID4gPiA+IGlzIG9ubHkgdXNlZCBpbiBvcGVyYXRpb25hbCBzdGF0ZSBpZiB0aGUg c3lzdGVtIGNhbm5vdCByZWFkIGl0IGZyb20gdGhlIGhhcmR3YXJlLg0KPiA+ID4gSSB0aGluayB0 aGF0IHRoaXMgYXBwcm9hY2ggaXMgcHJvYmFibHkgT0s6DQo+ID4gPiAgwqAtIFRoZSBjbGllbnQg Y2FuIGFsd2F5cyBzZWUgdGhlIHJlYWwgdmFsdWUgaWYgaXQgaXMgYXZhaWxhYmxlLg0KPiA+ID4g IMKgLSBJZiBpdCBpcyBub3QgYXZhaWxhYmxlIHRoZW4gdGhleSBjYW4gYXNzaWduIGEgdmFsdWUg dmlhIA0KPiA+ID4gY29uZmlndXJhdGlvbi4NCj4gPiA+IA0KPiA+ID4gSSB3YXMgYWxzbyBjb25z aWRlcmluZyBhbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCBvZiBoYXZpbmcgYSANCj4gPiA+IHNlcGFy YXRlIHNldCBvZiBjb25maWcgZmFsc2UgbGVhdmVzIGZvciB0aGUgImJ1cm50IGluIHZhbHVlcyIu wqAgDQo+ID4gPiBBbmQgdGhlbiBoYXZpbmcgdGhlIGNvbmZpZ3VyYWJsZSBsZWF2ZXMgYWx3YXlz IG92ZXJyaWRlIHRoZSANCj4gPiA+IGRlZmF1bHQgb3BlcmF0aW9uYWwgdmFsdWVzLiBFLmcuIHNp bWlsYXIgdG8gaG93IGFuIGludGVyZmFjZSBNQUMgDQo+ID4gPiBhZGRyZXNzIHdvdWxkIGV4cGVj dCB0byBiZSBoYW5kbGVkLg0KPiA+ID4gDQo+ID4gPiBCdXQgb25lIHNldCBvZiBsZWF2ZXMgaXMg cHJvYmFibHkgc3VmZmljaWVudC4NCj4gPiA+IA0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gUm9iDQo+ ID4gPiANCj4gPiA+IA0KPiA+ID4gPg0KPiA+ID4gPiBTbyBJIHN1Z2dlc3QgdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzOg0KPiA+ID4gPg0KPiA+ID4gPiBPTEQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAg ICBsZWFmIHNlcmlhbC1udW0gew0KPiA+ID4gPiAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiA+ ID4gICAgICAgICAgY29uZmlnIGZhbHNlOw0KPiA+ID4gPiAgICAgICAgICBkZXNjcmlwdGlvbg0K PiA+ID4gPiAgICAgICAgICAgICJUaGUgdmVuZG9yLXNwZWNpZmljIHNlcmlhbCBudW1iZXIgc3Ry aW5nIGZvciB0aGUNCj4gPiA+ID4gICAgICAgICAgICAgY29tcG9uZW50LiAgVGhlIHByZWZlcnJl ZCB2YWx1ZSBpcyB0aGUgc2VyaWFsIG51bWJlcg0KPiA+ID4gPiAgICAgICAgICAgICBzdHJpbmcg YWN0dWFsbHkgcHJpbnRlZCBvbiB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4gPiA+ID4gICAg ICAgICAgICAgcHJlc2VudCkuIjsNCj4gPiA+ID4gICAgICAgICAgcmVmZXJlbmNlICJSRkMgNjkz MzogZW50UGh5c2ljYWxTZXJpYWxOdW0iOw0KPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPg0KPiA+ ID4gPiBORVc6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICBsZWFmIHNlcmlhbC1udW0gew0KPiA+ ID4gPiAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiA+ID4gICAgICAgICAgZGVzY3JpcHRpb24N Cj4gPiA+ID4gICAgICAgICAgICAiVGhlIHZlbmRvci1zcGVjaWZpYyBzZXJpYWwgbnVtYmVyIHN0 cmluZyBmb3IgdGhlDQo+ID4gPiA+ICAgICAgICAgICAgIGNvbXBvbmVudC4gIFRoZSBwcmVmZXJy ZWQgdmFsdWUgaXMgdGhlIHNlcmlhbCBudW1iZXINCj4gPiA+ID4gICAgICAgICAgICAgc3RyaW5n IGFjdHVhbGx5IHByaW50ZWQgb24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmDQo+ID4gPiA+ICAg ICAgICAgICAgIHByZXNlbnQpLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICBUaGlzIGxl YWYgY2FuIGJlIGNvbmZpZ3VyZWQuICBUaGVyZSBhcmUgdHdvIHVzZSBjYXNlcyBmb3INCj4gPiA+ ID4gICAgICAgICAgICAgdGhpczsgYXMgYSAncG9zdC1pdCcgbm90ZSBpZiB0aGUgc2VydmVyIGNh bm5vdCBkZXRlcm1pbmUNCj4gPiA+ID4gICAgICAgICAgICAgdGhpcyB2YWx1ZSBmcm9tIHRoZSBj b21wb25lbnQsIG9yIHdoZW4gcHJlLXByb3Zpc2lvbmluZyBhDQo+ID4gPiA+ICAgICAgICAgICAg IGNvbXBvbmVudC4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgSWYgdGhlIHNlcnZlciBj YW4gZGV0ZXJtaW5lIHRoZSBzZXJpYWwgbnVtYmVyIGZyb20gdGhlDQo+ID4gPiA+ICAgICAgICAg ICAgIGNvbXBvbmVudCwgdGhlbiB0aGF0IHZhbHVlIGlzIGFsd2F5cyB1c2VkIGluIG9wZXJhdGlv bmFsDQo+ID4gPiA+ICAgICAgICAgICAgIHN0YXRlLCBldmVuIGlmIGFub3RoZXIgdmFsdWUgaGFz IGJlZW4gY29uZmlndXJlZC4iOw0KPiA+ID4gPiAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMz OiBlbnRQaHlzaWNhbFNlcmlhbE51bSI7DQo+ID4gPiA+ICAgICAgICB9DQo+ID4gPiA+DQo+ID4g PiA+IEFuZCBjb3JyZXNwb25kaW5nIHRleHQgZm9yICdtZmctbmFtZScgYW5kICdtb2RlbC1uYW1l Jy4NCj4gPiA+ID4NCj4gPiA+ID4gQW5kIGFsc286DQo+ID4gPiA+DQo+ID4gPiA+IE9MRDoNCj4g PiA+ID4NCj4gPiA+ID4gICAgICAgICAgIFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGEgbmV3IGhh cmR3YXJlIGNvbXBvbmVudCwgaXQNCj4gPiA+ID4gICAgICAgICAgIGluaXRpYWxpemVzIGEgbGlz dCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUuDQo+ID4gPiA+DQo+ID4gPiA+ICAgICAg ICAgICBJZiB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBoYXJk d2FyZQ0KPiA+ID4gPiAgICAgICAgICAgY29tcG9uZW50cywgbGlzdCBlbnRyaWVzIGluIHRoZSBv cGVyYXRpb25hbCBzdGF0ZSBhcmUNCj4gPiA+ID4gICAgICAgICAgIGluaXRpYWxpemVkIHdpdGgg dmFsdWVzIGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkgdGhlDQo+ID4gPiA+ICAgICAgICAg ICBpbXBsZW1lbnRhdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgIE90aGVyd2lzZSwg dGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9sbG93ZWQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAg ICAgICAgICAgIDEuIElmIHRoZXJlIGlzIGFuIGVudHJ5IGluIHRoZSAvaGFyZHdhcmUvY29tcG9u ZW50IGxpc3QgaW4NCj4gPiA+ID4gICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZpZ3Vy YXRpb24gd2l0aCB2YWx1ZXMgZm9yIHRoZSBub2Rlcw0KPiA+ID4gPiAgICAgICAgICAgICAgICAn Y2xhc3MnLCAncGFyZW50JywgJ3BhcmVudC1yZWwtcG9zJyB0aGF0IGFyZSBlcXVhbCB0bw0KPiA+ ID4gPiAgICAgICAgICAgICAgICB0aGUgZGV0ZWN0ZWQgdmFsdWVzLCB0aGVuOg0KPiA+ID4gPg0K PiA+ID4gPiAgICAgICAgICAgICAxYS4gSWYgdGhlIGNvbmZpZ3VyZWQgZW50cnkgaGFzIGEgdmFs dWUgZm9yICdtZmctbmFtZScNCj4gPiA+ID4gICAgICAgICAgICAgICAgIHRoYXQgaXMgZXF1YWwg dG8gdGhlIGRldGVjdGVkIHZhbHVlLCBvciBpZiB0aGUNCj4gPiA+ID4gICAgICAgICAgICAgICAg ICdtZmctbmFtZScgdmFsdWUgY2Fubm90IGJlIGRldGVjdGVkLCB0aGVuIHRoZSBsaXN0DQo+ID4g PiA+ICAgICAgICAgICAgICAgICBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMgaW5p dGlhbGl6ZWQgd2l0aCB0aGUNCj4gPiA+ID4gICAgICAgICAgICAgICAgIGNvbmZpZ3VyZWQgdmFs dWVzIGZvciBhbGwgY29uZmlndXJlZCBub2RlcywgaW5jbHVkaW5nDQo+ID4gPiA+ICAgICAgICAg ICAgICAgICB0aGUgJ25hbWUnLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgT3Ro ZXJ3aXNlLCB0aGUgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiA+ ID4gICAgICAgICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMg YXMgZGV0ZWN0ZWQgYnkNCj4gPiA+ID4gICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlv bi4gIFRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgcmFpc2UgYW4NCj4gPiA+ID4gICAgICAgICAgICAg ICAgIGFsYXJtIHRoYXQgaW5mb3JtcyBhYm91dCB0aGUgJ21mZy1uYW1lJyBtaXNtYXRjaA0KPiA+ ID4gPiAgICAgICAgICAgICAgICAgY29uZGl0aW9uLiAgSG93IHRoaXMgaXMgZG9uZSBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudC4N Cj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgMWIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUg aXMgbm8gbWF0Y2hpbmcgY29uZmlndXJhdGlvbg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgZW50 cnkpLCB0aGUgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPiA+ID4g ICAgICAgICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVzIGZvciBhbGwgbm9kZXMgYXMg ZGV0ZWN0ZWQgYnkNCj4gPiA+ID4gICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4N Cj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgIElmIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50IGxp c3QgaW4gdGhlIGludGVuZGVkDQo+ID4gPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1v ZGlmaWVkLCB0aGVuIHRoZSBzeXN0ZW0gTVVTVCBiZWhhdmUgYXMgaWYNCj4gPiA+ID4gICAgICAg ICAgIGl0IHJlLWluaXRpYWxpemVzIGl0c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGlu IA0KPiA+ID4gPiAoMSkuIjsNCj4gPiA+ID4NCj4gPiA+ID4gTkVXOg0KPiA+ID4gPg0KPiA+ID4g PiAgICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9u ZW50LCBpdA0KPiA+ID4gPiAgICAgICAgICAgaW5pdGlhbGl6ZXMgYSBsaXN0IGVudHJ5IGluIHRo ZSBvcGVyYXRpb25hbCBzdGF0ZS4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgIElmIHRoZSBz ZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIGhhcmR3YXJlDQo+ID4gPiA+ ICAgICAgICAgICBjb21wb25lbnRzLCBsaXN0IGVudHJpZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0 YXRlIGFyZQ0KPiA+ID4gPiAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFs bCBub2RlcyBhcyBkZXRlY3RlZCBieSB0aGUNCj4gPiA+ID4gICAgICAgICAgIGltcGxlbWVudGF0 aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5n IHByb2NlZHVyZSBpcyBmb2xsb3dlZDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgMS4g SWYgdGhlcmUgaXMgYW4gZW50cnkgaW4gdGhlIC9oYXJkd2FyZS9jb21wb25lbnQgbGlzdCBpbg0K PiA+ID4gPiAgICAgICAgICAgICAgICB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiB3aXRoIHZh bHVlcyBmb3IgdGhlIG5vZGVzDQo+ID4gPiA+ICAgICAgICAgICAgICAgICdjbGFzcycsICdwYXJl bnQnLCAncGFyZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRvDQo+ID4gPiA+ICAgICAgICAg ICAgICAgIHRoZSBkZXRlY3RlZCB2YWx1ZXMsIHRoZW4gdGhlIGxpc3QgZW50cnkgaW4gb3BlcmF0 aW9uYWwNCj4gPiA+ID4gICAgICAgICAgICAgICAgc3RhdGUgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0 aGUgY29uZmlndXJlZCB2YWx1ZXMsDQo+ID4gPiA+ICAgICAgICAgICAgICAgIGluY2x1ZGluZyB0 aGUgJ25hbWUnLiAgVGhlIGxlYWZzICdzZXJpYWwtbnVtJywNCj4gPiA+ID4gICAgICAgICAgICAg ICAgJ21mZy1uYW1lJywgYW5kICdtb2RlbC1uYW1lJyBhcmUgdHJlYXRlZCBzcGVjaWFsbHk7IHNl ZQ0KPiA+ID4gPiAgICAgICAgICAgICAgICB0aGVpciBkZXNjcmlwdGlvbnMgZm9yIGRldGFpbHMu DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAgIDIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUg aXMgbm8gbWF0Y2hpbmcgY29uZmlndXJhdGlvbg0KPiA+ID4gPiAgICAgICAgICAgICAgICBlbnRy eSksIHRoZSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpcw0KPiA+ID4gPiAg ICAgICAgICAgICAgICBpbml0aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5vZGVzIGFzIGRl dGVjdGVkIGJ5DQo+ID4gPiA+ICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4g PiA+ID4NCj4gPiA+ID4gICAgICAgICAgIElmIHRoZSAvaGFyZHdhcmUvY29tcG9uZW50IGxpc3Qg aW4gdGhlIGludGVuZGVkDQo+ID4gPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1vZGlm aWVkLCB0aGVuIHRoZSBzeXN0ZW0gTVVTVCBiZWhhdmUgYXMgaWYNCj4gPiA+ID4gICAgICAgICAg IGl0IHJlLWluaXRpYWxpemVzIGl0c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGluIA0K PiA+ID4gPiAoMSkuIjsNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gL21hcnRp bg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBCZW5vaXQgQ2xh aXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+PiBPbiAxMi8yMC8yMDE3IDQ6 MDAgUE0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gPiA+Pj4gQmVub2l0IENsYWlzZSA8 YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPj4+PiBIaSBNYXJ0aW4sDQo+ID4gPiA+ Pj4+DQo+ID4gPiA+Pj4+IFRoYW5rcy4NCj4gPiA+ID4+Pj4gT25seSBrZXB0IHRoZSByZWxldmFu dCBleGNlcnB0cy4NCj4gPiA+ID4+Pj4+PiAtIFNvbWUgb2JqZWN0cyBhcmUgcmVhZC13cml0ZSBp biBSRkM2OTMzOg0KPiA+ID4gPj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2FsU2VyaWFsTnVtDQo+ ID4gPiA+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxBbGlhcw0KPiA+ID4gPj4+Pj4+ICAgICAg ICAgIGVudFBoeXNpY2FsQXNzZXRJRA0KPiA+ID4gPj4+Pj4+ICAgICAgICAgIGVudFBoeXNpY2Fs VXJpcw0KPiA+ID4gPj4+Pj4+DQo+ID4gPiA+Pj4+Pj4gRm9yIGV4YW1wbGUsIGVudFBoeXNpY2Fs U2VyaWFsTnVtIGJlaW5nIHJlYWQtd3JpdGUgYWx3YXlzIA0KPiA+ID4gPj4+Pj4+IGJvdGhlcmVk IG1lLg0KPiA+ID4gPj4+Pj4+IHNlcmlhbC1udW0gaXMgbm93ICJjb25maWcgZmFsc2UiLCB3aGlj aCBpcyBhIGdvb2QgbmV3cyBJTU8uDQo+ID4gPiA+Pj4+PiBBY3R1YWxseSwgdGhpcyB3YXMgbm90 IHRoZSBpbnRlbnRpb24uICBJbg0KPiA+ID4gPj4+Pj4gZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5 LTAzIHRoaXMgaXMgY29uZmlndXJhYmxlLiAgSSBtaXNzZWQgDQo+ID4gPiA+Pj4+PiB0aGlzIGlu IHRoZSBjb252ZXJzaW9uIHRvIE5NREEuDQo+ID4gPiA+Pj4+IEFoLiBTbyBubyBnb29kIG5ld3Mg aW4gdGhpcyBjYXNlLi4uDQo+ID4gPiA+Pj4+Pj4gSW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLCBl bnRQaHlzaWNhbE1mZ05hbWUgaXMgcmVhZC1vbmx5IA0KPiA+ID4gPj4+Pj4+IGluIFJGQzY5MzMs IHdoaWxlIGl0J3MgImNvbmZpZyB0cnVlIiBpbiANCj4gPiA+ID4+Pj4+PiBkcmFmdC1pZXRmLW5l dG1vZC1lbnRpdHkNCj4gPiA+ID4+Pj4+IFllcywgdGhpcyB3YXMgYWRkZWQgcGVyIHJlcXVlc3Qg ZnJvbSB0aGUgV0cuICBTZWUgZS5nLiB0aGUgDQo+ID4gPiA+Pj4+PiB0aHJlYWQgImRyYWZ0LWll dGYtbmV0bW9kLWVudGl0eSBpc3N1ZSAjMTMiLg0KPiA+ID4gPj4+PiBTdXJlLiBJdCB3YXMgbWFp bmx5IGFuIG9ic2VydmF0aW9uLg0KPiA+ID4gPj4+Pj4gSG93ZXZlciwgSSB0aGluayB0aGF0IHdo YXQgd2UgaGF2ZSBub3cgaXMgcHJvYmFibHkgbm90IGNvcnJlY3QuICANCj4gPiA+ID4+Pj4+IEkg dGhpbmsgdGhhdCBhbGwgbm9kZXMgJ3NlcmlhbC1udW0nLCAnbWZnLW5hbWUnLCBhbmQgJ21vZGVs LW5hbWUnDQo+ID4gPiA+Pj4+PiBzaG91bGQgYmUgY29uZmlnIHRydWUsIGFuZCB0aGUgZGVzY3Jp cHRpb24gb2YgbGlzdCAnY29tcG9uZW50JyANCj4gPiA+ID4+Pj4+IHVwZGF0ZWQgdG8gcmVmbGVj dCB0aGF0IGFsbCB0aGVzZSB0cmVlIGxlYWZzIGFyZSBoYW5kbGVkIHRoZSBzYW1lIHdheS4NCj4g PiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aGF0IHRoZSBXRyB0 aGlua3MgYWJvdXQgdGhpcy4NCj4gPiA+ID4+Pj4gVGFsa2luZyBhcyBhIGNvbnRyaWJ1dG9yIHRo aXMgdGltZS4NCj4gPiA+ID4+Pj4gSXQgc2VlbXMgdGhhdCBpbnZlbnRvcnkgbWFuYWdlbWVudCBp cyBraW5kIG9mIGJyb2tlbiB3aGVuIA0KPiA+ID4gPj4+PiBzb21lb25lIGNhbiBjaGFuZ2UgJ3Nl cmlhbC1udW0nLCAnbWZnLW5hbWUnLCBhbmQgJ21vZGVsLW5hbWUuDQo+ID4gPiA+Pj4gVGhleSBj YW4ndCByZWFsbHkgY2hhbmdlIHRoZW0uICBUaGUgY29uZmlndXJlZCB2YWx1ZXMgYXJlIG9ubHkg DQo+ID4gPiA+Pj4gdXNlZCAoaS5lLiB2aXNpYmxlIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSkg aWYgdGhlIGRldmljZSANCj4gPiA+ID4+PiBjYW5ub3QgZGV0ZWN0IHRoZW0gYXV0b21hdGljYWxs eS4gIEkuZS4sIHRoZXkgd29yayBhcyAicG9zdC1pdCIgbm90ZXMgb25seS4NCj4gPiA+ID4+IElm IEkgbG9vayBhdCwgZm9yIGV4YW1wbGUsIHRoZSBtZmctbmFtZSwgZGVzY3JpcHRpb24sIHRoaXMg aXMgDQo+ID4gPiA+PiBub3Qgd2hhdCBpdCBzYXlzLg0KPiA+ID4gPj4NCj4gPiA+ID4+ICAgICBs ZWFmIG1mZy1uYW1lIHsNCj4gPiA+ID4+ICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiA+ID4g Pj4gICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiA+ID4+ICAgICAgICAgICAgICAgIlRoZSBu YW1lIG9mIHRoZSBtYW51ZmFjdHVyZXIgb2YgdGhpcyBwaHlzaWNhbCBjb21wb25lbnQuDQo+ID4g PiA+PiAgICAgICAgICAgICAgICBUaGUgcHJlZmVycmVkIHZhbHVlIGlzIHRoZSBtYW51ZmFjdHVy ZXIgbmFtZSBzdHJpbmcNCj4gPiA+ID4+ICAgICAgICAgICAgICAgIGFjdHVhbGx5IHByaW50ZWQg b24gdGhlIGNvbXBvbmVudCBpdHNlbGYgKGlmIHByZXNlbnQpLg0KPiA+ID4gPj4NCj4gPiA+ID4+ ICAgICAgICAgICAgICAgIE5vdGUgdGhhdCBjb21wYXJpc29ucyBiZXR3ZWVuIGluc3RhbmNlcyBv ZiB0aGUgbW9kZWwtbmFtZSwNCj4gPiA+ID4+ICAgICAgICAgICAgICAgIGZpcm13YXJlLXJldiwg c29mdHdhcmUtcmV2LCBhbmQgdGhlIHNlcmlhbC1udW0gbm9kZXMgYXJlDQo+ID4gPiA+PiAgICAg ICAgICAgICAgICBvbmx5IG1lYW5pbmdmdWwgYW1vbmdzdCBjb21wb25lbnQgd2l0aCB0aGUgc2Ft ZSB2YWx1ZSBvZg0KPiA+ID4gPj4gICAgICAgICAgICAgICAgbWZnLW5hbWUuDQo+ID4gPiA+Pg0K PiA+ID4gPj4gICAgICAgICAgICAgICAgSWYgdGhlIG1hbnVmYWN0dXJlciBuYW1lIHN0cmluZyBh c3NvY2lhdGVkIHdpdGggdGhlDQo+ID4gPiA+PiAgICAgICAgICAgICAgICBwaHlzaWNhbCBjb21w b25lbnQgaXMgdW5rbm93biB0byB0aGUgc2VydmVyLCB0aGVuIHRoaXMNCj4gPiA+ID4+ICAgICAg ICAgICAgICAgIG5vZGUgaXMgbm90IGluc3RhbnRpYXRlZC4iOw0KPiA+ID4gPj4gICAgICAgICAg ICAgcmVmZXJlbmNlICJSRkMgNjkzMyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5 MzM+Og0KPiA+ID4gPj4gICAgICAgICAgICAgZW50UGh5c2ljYWxNZmdOYW1lIjsNCj4gPiA+ID4+ DQo+ID4gPiA+PiBSZWdhcmRzLCBCZW5vaXQNCj4gPiA+ID4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+ PiAvbWFydGluDQo+ID4gPiA+Pj4gLg0KPiA+ID4gPj4+DQo+ID4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4gPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPiA+IC4NCj4gPiA+ID4NCj4gPiA+IA0K PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlz dA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg== From nobody Fri Jan 12 01:45:10 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 0665A126C23; Fri, 12 Jan 2018 01:45:07 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 Stsca3nZdVVA; Fri, 12 Jan 2018 01:45:04 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D22C1267BB; Fri, 12 Jan 2018 01:45:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D857E6E5; Fri, 12 Jan 2018 10:45:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ceJBZ_oj_kJy; Fri, 12 Jan 2018 10:45:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 12 Jan 2018 10:45:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAF172013E; Fri, 12 Jan 2018 10:45:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YMz6V6WwL0Vh; Fri, 12 Jan 2018 10:45:02 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 194822013F; Fri, 12 Jan 2018 10:45:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 747A2420D539; Fri, 12 Jan 2018 10:45:00 +0100 (CET) Date: Fri, 12 Jan 2018 10:45:00 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180112094500.ymlrkswjfgkhibef@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 09:45:07 -0000 On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen Moriarty wrote: > Hi Juergen, > > Thank you very much for the additional information. This was very > helpful. Benoit and I discussed it a bit further on the telechat and > some text changes in the introduction and security considerations > section to provide some of this information for the reader will be > helpful. I got the explanations and appreciate them and from the > explanations, my discuss questions have been answered and I'll switch > this to a no objection leaving you and Benoit to add the text as > helpful for other readers. > Kathleen, we propose to add this text to the security considerations: The origin metadata annotation exposes the origin of values in the applied configuration. Origin information may provide hints that certain control plane protocols are active on a device. Since origin information is tied to applied configuration values, it is only accessible to clients that have the permissions to read the applied configuration values. Security administrators should consider the sensitivity of origin information while defining access control rules. /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 Jan 12 02:52:38 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 544F312DA23 for ; Fri, 12 Jan 2018 02:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GqCPYGl5dU59 for ; Fri, 12 Jan 2018 02:52:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158F3126C23 for ; Fri, 12 Jan 2018 02:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23188; q=dns/txt; s=iport; t=1515754352; x=1516963952; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8hOjDWBVRGDFF5vX5EmhbPN5BTfoQt2KB0kMJaMGNQc=; b=AnJn3JjzCf0oVlBK3XF2E7Dy8OnFduO5IIYqxFq13qJta26YUsD/HDxJ gdnL6o8Q9sAOJsd6Q84wi4mEWfznqXGt3DeW2tg4blffU+KetmTNdHHbw U1vZiUGmQEOabFBCx70Yao8MgpWJbYfcHPjt/72uQKMqCAWPwjzfdjHvg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAgDpklha/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNBZnQnB4QAmQSCAnyYSwoYC4FegmtPAhqEJ0MUAQEBAQEBAQE?= =?us-ascii?q?BayiFIwEBAQECAQEBIRE6CwUHBAIBCBEEAQEBAgIjAwICAiULFAEICAIEAQ0FG?= =?us-ascii?q?ooRCBCwDoInijsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgy2CFYNAKYF3WDa?= =?us-ascii?q?DLwEBAgGBRwcBAQgVAReDADGCNAWKY4dEkT0CiAqNP4IZijKHRYpoglaGIIMaA?= =?us-ascii?q?hEZAYE7ATYigVBvFT0qAYF/P4QYeIkiDxiBDYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,348,1511827200"; d="scan'208";a="336270859" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 10:52:31 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w0CAqVY9020398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jan 2018 10:52:31 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 12 Jan 2018 05:52:30 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Fri, 12 Jan 2018 05:52:30 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Martin Bjorklund , "bart.bogaert@nokia.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-entity-06 Thread-Index: AQHTeZsGj/By4wgWGkSTA5QT6Ag4U6NN6XKHgBw2jXCAAgC0gIABaUYAgAAJBYCAAZLygIAARa0AgAEb34A= Date: Fri, 12 Jan 2018 10:52:29 +0000 Message-ID: References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> In-Reply-To: <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.106.8] Content-Type: text/plain; charset="utf-8" Content-ID: <3154C7B8EFEC3E4FAE5CCAA7FD1BEBCF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 10:52:37 -0000 WWVzLCBPcHRpb24gMiBzZWVtcyBiZXN0Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KPiBPbiAx MSBKYW4gMjAxOCwgYXQgMTc6NTYsIFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQg TElNSVRFRCBhdCBDaXNjbykgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IA0KPiAN Cj4gT24gMTEvMDEvMjAxOCAxMzo0NywgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4+IEhpLA0K Pj4gDQo+PiBUbyBzdW1tYXJpemUgdGhpcywgSSB0aGluayB3ZSBoYXZlIHRocmVlIG9wdGlvbnMg Zm9yIHRoZSB0aHJlZSBub2Rlcw0KPj4gJ21vZGVsLW5hbWUnLCAnbWZnLW5hbWUnLCBhbmQgJ3Nl cmlhbC1udW0nOg0KPj4gDQo+PiAgIDEuICBEbyBub3RoaW5nIChrZWVwIHRoZSBub2RlcyBhcyBj b25maWcgdHJ1ZSkuDQo+PiANCj4+ICAgMi4gIE1ha2UgdGhlc2UgdGhyZWUgbm9kZXMgY29uZmln IGZhbHNlIChmYWlybHkgc2ltcGxlIGNoYW5nZSkuDQo+PiAgICAgICAodmVuZG9ycyBjYW4gYXVn bWVudCB3LyB0aGVpciBvd24gY29uZmlnIHRydWUgbm9kZXMpLg0KPj4gDQo+PiAgIDMuICBBZGQg dGhyZWUgbmV3IG5vZGVzIGZvciB0aGUgY29uZmlndXJlZCB2YWx1ZXMuDQo+PiANCj4+IA0KPj4g QWZ0ZXIgdGhpbmtpbmcgYWJvdXQgdGhpcyBzb21lIG1vcmUsIGFuZCBkaXNjdXNzaW5nIHdpdGgg QmVub2l0LCBJDQo+PiB0aGluayB0aGUgYmVzdCBwYXRoIGZvcndhcmQgaXMgdG8gZG8gMiwgaS5l LiwgbWFyayB0aGUgbm9kZXMNCj4+ICdtb2RlbC1uYW1lJywgJ21mZy1uYW1lJywgYW5kICdzZXJp YWwtbnVtJyBhcyAiY29uZmlnIGZhbHNlIi4gIEFzIHN1Y2gNCj4+IHRoZXkgd291bGQgbm90IGJl IGNvbmZpZ3VyYWJsZSwgYW5kIHRodXMgY29udGFpbiB0aGUgZGV0ZWN0ZWQgdmFsdWVzLg0KPj4g SWYgbm8gdmFsdWUgaXMgZGV0ZWN0ZWQsIHRoZSBub2RlIGlzIG5vdCBwcmVzZW50Lg0KPiBPcHRp b24gMiBzdWl0cyBtZS4gIEl0IGtlZXBzIGl0IHNpbXBsZS4NCj4gDQo+PiANCj4+IE5vdGUgdGhh dCAxIG9yIDMgY2FuIGJlIGRvbmUgaW4gYSBmdXR1cmUgdXBkYXRlIHRvIHRoaXMgbW9kdWxlIChv ciBieQ0KPj4gYSB2ZW5kb3IpLg0KPiBBZ3JlZWQuDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiAN Cj4gDQo+PiANCj4+IA0KPj4gL21hcnRpbg0KPj4gDQo+PiANCj4+IE1hcnRpbiBCam9ya2x1bmQg PG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4+PiBIaSwNCj4+PiANCj4+PiAiQm9nYWVydCwgQmFy dCAoTm9raWEgLSBCRS9BbnR3ZXJwKSIgPGJhcnQuYm9nYWVydEBub2tpYS5jb20+IHdyb3RlOg0K Pj4+PiBIaSwNCj4+Pj4gDQo+Pj4+IC0tLSBzbmlwIC0tLQ0KPj4+PiANCj4+Pj4+IHN0YXRlLuKA nSwgc28gdGhlIGFib3ZlIHNlbnRlbmNlIG9ubHkgYXBwbGllcyBmb3IgdGhlIHNlY29uZCBjYXNl IGJlbG93Lg0KPj4+PiBPay4NCj4+Pj4gDQo+Pj4+PiAyLiBUaGUgc2Vjb25kIGNhc2UgaXMgdGhh dCBzb21ldGhpbmcgaXMgZGV0ZWN0ZWQgYnV0IGl0IGNhbuKAmXQgYmUgcmVhZC4NCj4+Pj4+IFdl IGRvIG5vdCBzZWUgYSByZWFzb24gdG8gdXNlIHRoZSB2YWx1ZSBjb25maWd1cmVkIGZvciB0aGUg bGVhZnMNCj4+Pj4+IOKAmHNlcmlhbC1udW3igJksIOKAmG1mZy1uYW1l4oCZIGFuZCDigJhtb2Rl bC1uYW1l4oCZIG9mIGEgbWF0Y2hpbmcgZW50cnkgaW4gdGhlDQo+Pj4+PiBjb25maWd1cmF0aW9u IGRhdGEuICBUaGVzZSBsZWFmcyBhcmUgZGVmaW5lZCBhcyBvcHRpb25hbCBzbyB3aHkgd291bGQN Cj4+Pj4+IHdlIHJlcG9ydCBzb21ldGhpbmcgZW50ZXJlZCBieSBhbiBvcGVyYXRvciBpbiB0aGUg b3BlcmF0aW9uYWwNCj4+Pj4+IGRhdGFzdG9yZSB0aGF0IGludGVuZHMgdG8gcmVwb3J0IG9uIHdo YXQgaXMgZGV0ZWN0ZWQ/ICBJcyBpdCBub3QNCj4+Pj4+IGJldHRlciB0byBub3QgcmVwb3J0IHRo ZW0gYXQgYWxsPyAgSW4gYW4gTk1EQSBjb250ZXh0IGl0IHdvdWxkIGJlDQo+Pj4+PiBwb3NzaWJs ZSB0byBoYXZlIGEgZGlmZmVyZW50IHZhbHVlIChvciBubyB2YWx1ZSBhdCBhbGwpIGZvciBjZXJ0 YWluDQo+Pj4+PiBsZWFmcyB3aGlsZSB0aGVyZSBpcyBzb21ldGhpbmcgaW4gdGhlIHJ1bm5pbmcv aW50ZW5kZWQgZGF0YXN0b3JlLg0KPj4+PiBUaGUgbm9ybWFsIE5NREEgcHJvY2VkdXJlIGZvciBh IGNvbmZpZ3VyYXRpb24gbGVhZiBpcyB0byByZXBlYXQgaXQgaW4NCj4+Pj4gb3BlcmF0aW9uYWwg c3RhdGUuICBUaGlzIGlzIHRoZW4gdGhlICJhcHBsaWVkIGNvbmZpZ3VyYXRpb24iLg0KPj4+PiBJ IGRvbid0IHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc3BlY2lhbCBydWxlIGZvciB0aGVzZSBsZWFm cy4NCj4+Pj4gDQo+Pj4+IFRoaXMgYWxzbyBtZWFucyB0aGF0IGEgY2xpZW50IHRoYXQganVzdCB3 YW50cyB0byByZWFkIGFsbCB0aGUgc2VyaWFsDQo+Pj4+IG51bWJlcnMgY2FuIGRvIHNvIGZyb20g b25lIHBsYWNlLCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUsIHJlZ2FyZGxlc3Mgb2YNCj4+Pj4gaG93 IHRoZXkgY2FtZSBpbnRvIGV4aXN0YW5jZS4NCj4+Pj4gDQo+Pj4+IFtCb2dhZXJ0LCBCYXJ0IF0N Cj4+Pj4gDQo+Pj4+IFdlIGRvIHVuZGVyc3RhbmQgdGhhdCBhIHRhcmdldCBvZiBOTURBIGlzIHRv IHJlYWQgb3V0IHRoZSBhY3R1YWxseQ0KPj4+PiBhcHBsaWVkIGRhdGEgaW4gb25lIHJlcXVlc3Qu ICBCdXQgdGhlIHJlc3VsdCBzaG91bGQgbm90IGJlDQo+Pj4+IGNvbmZ1c2lvbi4gQSBrZXkgd29y ZCBpcyDigJxhcHBsaWVk4oCdLg0KPj4+PiANCj4+Pj4gU2VjdGlvbiA1LjMgb2YgZHJhZnQtaWV0 Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTA5IGFsc28gY29udGFpbnMNCj4+Pj4gKEkgcHV0 IGEgcGFydCBvZiB0aGUgc2VjdGlvbiBiZXR3ZWVuICoqKik6DQo+Pj4+IFRoZSBkYXRhc3RvcmUg c2NoZW1hIGZvciA8b3BlcmF0aW9uYWw+IE1VU1QgYmUgYSBzdXBlcnNldCBvZiB0aGUNCj4+Pj4g Y29tYmluZWQgZGF0YXN0b3JlIHNjaGVtYSB1c2VkIGluIGFsbCBjb25maWd1cmF0aW9uIGRhdGFz dG9yZXMgZXhjZXB0DQo+Pj4+IHRoYXQgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIHN1cHBvcnRl ZCBpbiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlDQo+Pj4+ICoqKk1BWSBiZSBvbWl0dGVkIGZy b20gPG9wZXJhdGlvbmFsPiBpZiBhIHNlcnZlciBpcyBub3QgYWJsZSB0bw0KPj4+PiBhY2N1cmF0 ZWx5IHJlcG9ydCB0aGVtICoqKi4NCj4+PiBOb3RlIHRoYXQgdGhpcyB0ZXh0IHRhbGtzIGFib3V0 IHRoZSAqc2NoZW1hKi4gIEl0IGlzIGludGVuZGVkIGZvcg0KPj4+IHNlcnZlcnMgdG8gbWlncmF0 ZSB0byBOTURBIHdpdGhvdXQgaGF2aW5nIHRvIGluc3RydW1lbnQgYWxsIGNvbmZpZw0KPj4+IG5v ZGVzIGluIDxvcGVyYXRpb25hbD4gaW1tZWRpYXRlbHkuICBJZiB5b3UgYXBwbHkgdGhpcyB0bw0K Pj4+IGlldGYtaGFyZHdhcmUsIGl0IGNvdWxkIGJlIGEgc2VydmVyIHRoYXQgaW1wbGVtZW50cyB0 aGUgbm9kZQ0KPj4+ICJzZXJpYWwtbnVtIiBpbiBjb25maWcsIGJ1dCBub3QgaW4gPG9wZXJhdGlv bmFsPiAod2hpY2ggd291bGQgYmUNCj4+PiB3ZWlyZCkuDQo+Pj4gDQo+Pj4+IEZvciBleGFtcGxl LCBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSB2YWx1ZSBvZiBtdWx0aXBsZSBsZWFmcyBuZWVkIHRv DQo+Pj4+IGJlIGEgY29uc2lzdGVudCBzZXQsIGUuZy4gdGhlIG1mZy1uYW1lLCB0aGUgbW9kZWwt bmFtZSwgYW5kIHRoZQ0KPj4+PiBzZXJpYWwtbnVtLg0KPj4+PiBTdXBwb3NlIHdlIGhhdmUgYSB1 c2UgY2FzZSBpbiB3aGljaCBhIGhhcmR3YXJlIGNvbXBvbmVudCBpcw0KPj4+PiBwbGFubmVkL2Nv bmZpZ3VyZWQgKGUuZy4gYSBib2FyZCBzdXBwb3J0aW5nIERTTCBpbnRlcmZhY2VzKSBidXQgYQ0K Pj4+PiBkaWZmZXJlbnQgb25lIGlzIHBsdWdnZWQgKGUuZy4gYSBib2FyZCBzdXBwb3J0aW5nIGV0 aGVybmV0DQo+Pj4+IGludGVyZmFjZXMpLg0KPj4+PiBTdXBwb3NlIGl0IGlzIHBvc3NpYmxlIHRv IHJlYWQgc29tZSBmaWVsZHMgb24gdGhlIGRldGVjdGVkIGNvbXBvbmVudA0KPj4+PiBidXQgZHVl IHRvIGFuIGlzc3VlIG5vdCB0byByZWFkIG90aGVyIGZpZWxkcy4NCj4+Pj4gSWYgaW4gdGhhdCBj YXNlIHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgd2lsbCBiZSBjb21wbGV0ZWQgd2l0aCB0aGUN Cj4+Pj4gZGF0YSB0YWtlbiBmcm9tIHRoZSBydW5uaW5nIGRhdGFzdG9yZSwgdGhlbiB0aGUgcHJl c2VudGVkIHZpZXcgbWlnaHQNCj4+Pj4gYmUgaW5jb25zaXN0ZW50Lg0KPj4+IFRoaXMgaXMgdHJ1 ZSBmb3Igb3RoZXIgc2ltaWxhciBub2RlcyBhcyB3ZWxsIC0gImFzc2V0LWlkIiBhbmQgInVyaSIu DQo+Pj4gDQo+Pj4+IFRoZSBxdWVzdGlvbiBpcyBhbHNvOiB3aGF0IGRhdGEgaXMgYXBwbGllZD8g T3VyIGFzc3VtcHRpb246IGlmIHRoZXJlDQo+Pj4+IGlzIGEgbWlzbWF0Y2ggYmV0d2VlbiBkZXRl Y3RlZCB2ZXJzdXMgY29uZmlndXJlZCBoYXJkd2FyZSwgdGhlbiB0aGUNCj4+Pj4gaW50ZXJmYWNl L3NlcnZpY2UgcmVsYXRlZCBkYXRhIHRoYXQgaXMgY29uZmlndXJlZCBjb25zaXN0ZW50bHkgd2l0 aA0KPj4+PiB0aGUgcGxhbm5lZCBoYXJkd2FyZSBpcyBub3QgYXBwbGllZCBvbiB0aGUgbWlzbWF0 Y2hpbmcNCj4+Pj4gaGFyZHdhcmUuIEkuZS4gdGhlIGRldGVjdGVkIGhhcmR3YXJlIGlzIG5vdCBi cm91Z2h0IGluIHNlcnZpY2Ugc28gbm90DQo+Pj4+IOKAmGFwcGxpZWTigJksIHRoZSBvcGVyYXRp b25hbCBkYXRhc3RvcmUgb25seSAoYWNjdXJhdGVseSkgcmVwb3J0cyBvbiB3aGF0DQo+Pj4+IGlz IGRldGVjdGVkLg0KPj4+IElmIHRoZXJlIGlzIGEgbWlzbWF0Y2ggYW5kIHRoZSBzZXJ2ZXIgZG9l c24ndCBhcHBseSB0aGUgY29uZmlndXJlZA0KPj4+IHZhbHVlcywgdGhlbiBvYnZpb3VzbHkgdGhl IGNvbmZpZ3VyZWQgJ21mZy1uYW1lJyBldGMgYXJlIG5vdCBjb3BpZWQgdG8NCj4+PiA8b3BlcmF0 aW9uYWw+Lg0KPj4+IA0KPj4+PiBXZSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzcGVjaWFsIHJ1bGUg Zm9yIHRoaXMgZGF0YSBidXQgcmF0aGVyIHdvdWxkDQo+Pj4+IGFwcGx5IGEgZ2VuZXJhbCBydWxl Og0KPj4+PiAtCWlmIHRoZXJlIGlzIGEg4oCYbWlzc2luZyByZXNvdXJjZeKAmSwgdGhlbiB0aGUg ZGF0YSBpcyBub3QgcmVwb3J0ZWQgaW4gdGhlDQo+Pj4+ICAJb3BlcmF0aW9uYWwgZGF0YXN0b3Jl Lg0KPj4+PiAtCUlmIHRoZSBzZXJ2ZXIgaXMgbm90IGFibGUgdG8gcmVwb3J0IGFjY3VyYXRlbHks IHRoZW4gdGhlIGRhdGEgaXMNCj4+Pj4gIAlvbWl0dGVkIGZyb20gdGhlIG9wZXJhdGlvbmFsDQo+ Pj4gSSB0aGluayB0aGF0IGlmIHlvdSB3YW50IGNvbXBsZXRlIHNlcGFyYXRpb24gYmV0d2VlbiB0 aGUgdmFsdWVzIG9mDQo+Pj4gJ21mZy1uYW1lJywgJ21vZGVsLW5hbWUnLCBhbmQgJ3NlcmlhbC1u dW0nIGluIGNvbmZpZ3VyYXRpb24gYW5kDQo+Pj4gb3BlcmF0aW9uYWwgc3RhdGUsIHRoZW4gdGhl c2Ugc2hvdWxkIGJlIG1vZGVsbGVkIGFzIHNlcGFyYXRlIGxlYWZzLg0KPj4+IFdlIHNob3VsZCBo YXZlIGEgY29uZmlnIGZhbHNlIGxlYWYgJ3NlcmlhbC1udW0nIHRoYXQgb25seSBjb250YWlucyB0 aGUNCj4+PiBkZXRlY3RlZCB2YWx1ZSAoaWYgZm91bmQpLCBhbmQgYSBjb25maWcgdHJ1ZSBsZWFm ICdjb25maWctc2VyaWFsLW51bScNCj4+PiBvciBzb21ldGhpbmcsIHRoYXQgY29udGFpbnMgdGhl IGNvbmZpZ3VyZWQgc2VyaWFsIG51bWJlci4NCj4+PiANCj4+PiBCdXQgaWYgdGhpcyBpcyB0aGUg Y2FzZSwgSSB3b25kZXIgaWYgaXQgd291bGRuJ3QgYmUgYmV0dGVyIHRvIGxlYXZlDQo+Pj4gc3Vj aCBhZGRpdGlvbmFsIGNvbmZpZyBvYmplY3RzIHRvIHZlbmRvcnMsIGFuZCBzaW1wbHkgbWFrZSB0 aGVzZSB0aHJlZQ0KPj4+IG5vZGVzIGNvbmZpZyBmYWxzZSBpbiBpZXRmLWhhcmR3YXJlLg0KPj4+ IA0KPj4+IA0KPj4+IC9tYXJ0aW4NCj4+PiANCj4+Pj4gUmVnYXJkcywgQmFydA0KPj4+PiANCj4+ Pj4gL21hcnRpbg0KPj4+PiANCj4+Pj4gDQo+Pj4+PiBCZXN0IHJlZ2FyZHMsIEJhcnQNCj4+Pj4+ IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQo+Pj4+ PiBXaWx0b24NCj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMSwgMjAxNyA0OjE0IFBN DQo+Pj4+PiBUbzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+OyBuZXRtb2RAaWV0 Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1uZXRtb2QtZW50aXR5LTA2DQo+Pj4+PiANCj4+Pj4+IEhpIE1hcnRpbiwNCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiBPbiAyMS8xMi8yMDE3IDExOjM3LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0K Pj4+Pj4+IEhpLA0KPj4+Pj4+IA0KPj4+Pj4+IEkgbmVlZCBXRyBpbnB1dCBvbiB0aGlzIGlzc3Vl LiAgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBoYW5kbGUNCj4+Pj4+PiAnc2VyaWFsLW51bScsICdt ZmctbmFtZScsIGFuZCAnbW9kZWwtbmFtZScuICBJIHRoaW5rIHRoZXkgc2hvdWxkIGFsbA0KPj4+ Pj4+IGJlIHRyZWF0ZWQgdGhlIHNhbWUuICBCYXNlZCBvbiBwcmV2aW91cyBXRyBkaXNjdXNzaW9u IChzZWUgZS5nLiB0aGUNCj4+Pj4+PiBtYWlsIHRocmVhZCAiZHJhZnQtaWV0Zi1uZXRtb2QtZW50 aXR5IGlzc3VlICMxMyIpLCBJIHRoaW5rIHRoZXkNCj4+Pj4+PiBzaG91bGQgYWxsIGJlIGNvbmZp Z3VyYWJsZSwgYnV0IHRoZSBjb25maWd1cmVkIHZhbHVlIGlzIG9ubHkgdXNlZCBpbg0KPj4+Pj4+ IG9wZXJhdGlvbmFsIHN0YXRlIGlmIHRoZSBzeXN0ZW0gY2Fubm90IHJlYWQgaXQgZnJvbSB0aGUg aGFyZHdhcmUuDQo+Pj4+PiBJIHRoaW5rIHRoYXQgdGhpcyBhcHByb2FjaCBpcyBwcm9iYWJseSBP SzoNCj4+Pj4+ICAgLSBUaGUgY2xpZW50IGNhbiBhbHdheXMgc2VlIHRoZSByZWFsIHZhbHVlIGlm IGl0IGlzIGF2YWlsYWJsZS4NCj4+Pj4+ICAgLSBJZiBpdCBpcyBub3QgYXZhaWxhYmxlIHRoZW4g dGhleSBjYW4gYXNzaWduIGEgdmFsdWUgdmlhDQo+Pj4+PiBjb25maWd1cmF0aW9uLg0KPj4+Pj4g DQo+Pj4+PiBJIHdhcyBhbHNvIGNvbnNpZGVyaW5nIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIG9m IGhhdmluZyBhIHNlcGFyYXRlDQo+Pj4+PiBzZXQgb2YgY29uZmlnIGZhbHNlIGxlYXZlcyBmb3Ig dGhlICJidXJudCBpbiB2YWx1ZXMiLiAgQW5kIHRoZW4gaGF2aW5nDQo+Pj4+PiB0aGUgY29uZmln dXJhYmxlIGxlYXZlcyBhbHdheXMgb3ZlcnJpZGUgdGhlIGRlZmF1bHQgb3BlcmF0aW9uYWwNCj4+ Pj4+IHZhbHVlcy4gRS5nLiBzaW1pbGFyIHRvIGhvdyBhbiBpbnRlcmZhY2UgTUFDIGFkZHJlc3Mg d291bGQgZXhwZWN0IHRvDQo+Pj4+PiBiZSBoYW5kbGVkLg0KPj4+Pj4gDQo+Pj4+PiBCdXQgb25l IHNldCBvZiBsZWF2ZXMgaXMgcHJvYmFibHkgc3VmZmljaWVudC4NCj4+Pj4+IA0KPj4+Pj4gVGhh bmtzLA0KPj4+Pj4gUm9iDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4+IFNvIEkgc3VnZ2VzdCB0aGUg Zm9sbG93aW5nIGNoYW5nZXM6DQo+Pj4+Pj4gDQo+Pj4+Pj4gT0xEOg0KPj4+Pj4+IA0KPj4+Pj4+ ICAgICAgICBsZWFmIHNlcmlhbC1udW0gew0KPj4+Pj4+ICAgICAgICAgIHR5cGUgc3RyaW5nOw0K Pj4+Pj4+ICAgICAgICAgIGNvbmZpZyBmYWxzZTsNCj4+Pj4+PiAgICAgICAgICBkZXNjcmlwdGlv bg0KPj4+Pj4+ICAgICAgICAgICAgIlRoZSB2ZW5kb3Itc3BlY2lmaWMgc2VyaWFsIG51bWJlciBz dHJpbmcgZm9yIHRoZQ0KPj4+Pj4+ICAgICAgICAgICAgIGNvbXBvbmVudC4gIFRoZSBwcmVmZXJy ZWQgdmFsdWUgaXMgdGhlIHNlcmlhbCBudW1iZXINCj4+Pj4+PiAgICAgICAgICAgICBzdHJpbmcg YWN0dWFsbHkgcHJpbnRlZCBvbiB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4+Pj4+PiAgICAg ICAgICAgICBwcmVzZW50KS4iOw0KPj4+Pj4+ICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6 IGVudFBoeXNpY2FsU2VyaWFsTnVtIjsNCj4+Pj4+PiAgICAgICAgfQ0KPj4+Pj4+IA0KPj4+Pj4+ IE5FVzoNCj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgbGVhZiBzZXJpYWwtbnVtIHsNCj4+Pj4+PiAg ICAgICAgICB0eXBlIHN0cmluZzsNCj4+Pj4+PiAgICAgICAgICBkZXNjcmlwdGlvbg0KPj4+Pj4+ ICAgICAgICAgICAgIlRoZSB2ZW5kb3Itc3BlY2lmaWMgc2VyaWFsIG51bWJlciBzdHJpbmcgZm9y IHRoZQ0KPj4+Pj4+ICAgICAgICAgICAgIGNvbXBvbmVudC4gIFRoZSBwcmVmZXJyZWQgdmFsdWUg aXMgdGhlIHNlcmlhbCBudW1iZXINCj4+Pj4+PiAgICAgICAgICAgICBzdHJpbmcgYWN0dWFsbHkg cHJpbnRlZCBvbiB0aGUgY29tcG9uZW50IGl0c2VsZiAoaWYNCj4+Pj4+PiAgICAgICAgICAgICBw cmVzZW50KS4NCj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgICBUaGlzIGxlYWYgY2FuIGJlIGNv bmZpZ3VyZWQuICBUaGVyZSBhcmUgdHdvIHVzZSBjYXNlcyBmb3INCj4+Pj4+PiAgICAgICAgICAg ICB0aGlzOyBhcyBhICdwb3N0LWl0JyBub3RlIGlmIHRoZSBzZXJ2ZXIgY2Fubm90IGRldGVybWlu ZQ0KPj4+Pj4+ICAgICAgICAgICAgIHRoaXMgdmFsdWUgZnJvbSB0aGUgY29tcG9uZW50LCBvciB3 aGVuIHByZS1wcm92aXNpb25pbmcgYQ0KPj4+Pj4+ICAgICAgICAgICAgIGNvbXBvbmVudC4NCj4+ Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgICBJZiB0aGUgc2VydmVyIGNhbiBkZXRlcm1pbmUgdGhl IHNlcmlhbCBudW1iZXIgZnJvbSB0aGUNCj4+Pj4+PiAgICAgICAgICAgICBjb21wb25lbnQsIHRo ZW4gdGhhdCB2YWx1ZSBpcyBhbHdheXMgdXNlZCBpbiBvcGVyYXRpb25hbA0KPj4+Pj4+ICAgICAg ICAgICAgIHN0YXRlLCBldmVuIGlmIGFub3RoZXIgdmFsdWUgaGFzIGJlZW4gY29uZmlndXJlZC4i Ow0KPj4+Pj4+ICAgICAgICAgIHJlZmVyZW5jZSAiUkZDIDY5MzM6IGVudFBoeXNpY2FsU2VyaWFs TnVtIjsNCj4+Pj4+PiAgICAgICAgfQ0KPj4+Pj4+IA0KPj4+Pj4+IEFuZCBjb3JyZXNwb25kaW5n IHRleHQgZm9yICdtZmctbmFtZScgYW5kICdtb2RlbC1uYW1lJy4NCj4+Pj4+PiANCj4+Pj4+PiBB bmQgYWxzbzoNCj4+Pj4+PiANCj4+Pj4+PiBPTEQ6DQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgICAgICAg IFdoZW4gdGhlIHNlcnZlciBkZXRlY3RzIGEgbmV3IGhhcmR3YXJlIGNvbXBvbmVudCwgaXQNCj4+ Pj4+PiAgICAgICAgICAgaW5pdGlhbGl6ZXMgYSBsaXN0IGVudHJ5IGluIHRoZSBvcGVyYXRpb25h bCBzdGF0ZS4NCj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgSWYgdGhlIHNlcnZlciBkb2VzIG5v dCBzdXBwb3J0IGNvbmZpZ3VyYXRpb24gb2YgaGFyZHdhcmUNCj4+Pj4+PiAgICAgICAgICAgY29t cG9uZW50cywgbGlzdCBlbnRyaWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBhcmUNCj4+Pj4+ PiAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBub2RlcyBhcyBkZXRl Y3RlZCBieSB0aGUNCj4+Pj4+PiAgICAgICAgICAgaW1wbGVtZW50YXRpb24uDQo+Pj4+Pj4gDQo+ Pj4+Pj4gICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgZm9s bG93ZWQ6DQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgICAgICAgICAgMS4gSWYgdGhlcmUgaXMgYW4gZW50 cnkgaW4gdGhlIC9oYXJkd2FyZS9jb21wb25lbnQgbGlzdCBpbg0KPj4+Pj4+ICAgICAgICAgICAg ICAgIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIHdpdGggdmFsdWVzIGZvciB0aGUgbm9kZXMN Cj4+Pj4+PiAgICAgICAgICAgICAgICAnY2xhc3MnLCAncGFyZW50JywgJ3BhcmVudC1yZWwtcG9z JyB0aGF0IGFyZSBlcXVhbCB0bw0KPj4+Pj4+ICAgICAgICAgICAgICAgIHRoZSBkZXRlY3RlZCB2 YWx1ZXMsIHRoZW46DQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgICAgICAgICAgMWEuIElmIHRoZSBjb25m aWd1cmVkIGVudHJ5IGhhcyBhIHZhbHVlIGZvciAnbWZnLW5hbWUnDQo+Pj4+Pj4gICAgICAgICAg ICAgICAgIHRoYXQgaXMgZXF1YWwgdG8gdGhlIGRldGVjdGVkIHZhbHVlLCBvciBpZiB0aGUNCj4+ Pj4+PiAgICAgICAgICAgICAgICAgJ21mZy1uYW1lJyB2YWx1ZSBjYW5ub3QgYmUgZGV0ZWN0ZWQs IHRoZW4gdGhlIGxpc3QNCj4+Pj4+PiAgICAgICAgICAgICAgICAgZW50cnkgaW4gdGhlIG9wZXJh dGlvbmFsIHN0YXRlIGlzIGluaXRpYWxpemVkIHdpdGggdGhlDQo+Pj4+Pj4gICAgICAgICAgICAg ICAgIGNvbmZpZ3VyZWQgdmFsdWVzIGZvciBhbGwgY29uZmlndXJlZCBub2RlcywgaW5jbHVkaW5n DQo+Pj4+Pj4gICAgICAgICAgICAgICAgIHRoZSAnbmFtZScuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAg ICAgICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGxpc3QgZW50cnkgaW4gdGhlIG9wZXJhdGlvbmFs IHN0YXRlIGlzDQo+Pj4+Pj4gICAgICAgICAgICAgICAgIGluaXRpYWxpemVkIHdpdGggdmFsdWVz IGZvciBhbGwgbm9kZXMgYXMgZGV0ZWN0ZWQgYnkNCj4+Pj4+PiAgICAgICAgICAgICAgICAgdGhl IGltcGxlbWVudGF0aW9uLiAgVGhlIGltcGxlbWVudGF0aW9uIG1heSByYWlzZSBhbg0KPj4+Pj4+ ICAgICAgICAgICAgICAgICBhbGFybSB0aGF0IGluZm9ybXMgYWJvdXQgdGhlICdtZmctbmFtZScg bWlzbWF0Y2gNCj4+Pj4+PiAgICAgICAgICAgICAgICAgY29uZGl0aW9uLiAgSG93IHRoaXMgaXMg ZG9uZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZg0KPj4+Pj4+ICAgICAgICAgICAgICAgICB0aGlz IGRvY3VtZW50Lg0KPj4+Pj4+IA0KPj4+Pj4+ICAgICAgICAgICAgIDFiLiBPdGhlcndpc2UgKGku ZS4sIHRoZXJlIGlzIG5vIG1hdGNoaW5nIGNvbmZpZ3VyYXRpb24NCj4+Pj4+PiAgICAgICAgICAg ICAgICAgZW50cnkpLCB0aGUgbGlzdCBlbnRyeSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMN Cj4+Pj4+PiAgICAgICAgICAgICAgICAgaW5pdGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBu b2RlcyBhcyBkZXRlY3RlZCBieQ0KPj4+Pj4+ICAgICAgICAgICAgICAgICB0aGUgaW1wbGVtZW50 YXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gICAgICAgICAgIElmIHRoZSAvaGFyZHdhcmUvY29tcG9u ZW50IGxpc3QgaW4gdGhlIGludGVuZGVkDQo+Pj4+Pj4gICAgICAgICAgIGNvbmZpZ3VyYXRpb24g aXMgbW9kaWZpZWQsIHRoZW4gdGhlIHN5c3RlbSBNVVNUIGJlaGF2ZSBhcyBpZg0KPj4+Pj4+ICAg ICAgICAgICBpdCByZS1pbml0aWFsaXplcyBpdHNlbGYsIGFuZCBmb2xsb3cgdGhlIHByb2NlZHVy ZSBpbg0KPj4+Pj4+ICgxKS4iOw0KPj4+Pj4+IA0KPj4+Pj4+IE5FVzoNCj4+Pj4+PiANCj4+Pj4+ PiAgICAgICAgICAgV2hlbiB0aGUgc2VydmVyIGRldGVjdHMgYSBuZXcgaGFyZHdhcmUgY29tcG9u ZW50LCBpdA0KPj4+Pj4+ICAgICAgICAgICBpbml0aWFsaXplcyBhIGxpc3QgZW50cnkgaW4gdGhl IG9wZXJhdGlvbmFsIHN0YXRlLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgICAgICAgICBJZiB0aGUgc2Vy dmVyIGRvZXMgbm90IHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBoYXJkd2FyZQ0KPj4+Pj4+ICAg ICAgICAgICBjb21wb25lbnRzLCBsaXN0IGVudHJpZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRl IGFyZQ0KPj4+Pj4+ICAgICAgICAgICBpbml0aWFsaXplZCB3aXRoIHZhbHVlcyBmb3IgYWxsIG5v ZGVzIGFzIGRldGVjdGVkIGJ5IHRoZQ0KPj4+Pj4+ICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi4N Cj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5nIHByb2Nl ZHVyZSBpcyBmb2xsb3dlZDoNCj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgICAxLiBJZiB0aGVy ZSBpcyBhbiBlbnRyeSBpbiB0aGUgL2hhcmR3YXJlL2NvbXBvbmVudCBsaXN0IGluDQo+Pj4+Pj4g ICAgICAgICAgICAgICAgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gd2l0aCB2YWx1ZXMgZm9y IHRoZSBub2Rlcw0KPj4+Pj4+ICAgICAgICAgICAgICAgICdjbGFzcycsICdwYXJlbnQnLCAncGFy ZW50LXJlbC1wb3MnIHRoYXQgYXJlIGVxdWFsIHRvDQo+Pj4+Pj4gICAgICAgICAgICAgICAgdGhl IGRldGVjdGVkIHZhbHVlcywgdGhlbiB0aGUgbGlzdCBlbnRyeSBpbiBvcGVyYXRpb25hbA0KPj4+ Pj4+ICAgICAgICAgICAgICAgIHN0YXRlIGlzIGluaXRpYWxpemVkIHdpdGggdGhlIGNvbmZpZ3Vy ZWQgdmFsdWVzLA0KPj4+Pj4+ICAgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgJ25hbWUnLiAg VGhlIGxlYWZzICdzZXJpYWwtbnVtJywNCj4+Pj4+PiAgICAgICAgICAgICAgICAnbWZnLW5hbWUn LCBhbmQgJ21vZGVsLW5hbWUnIGFyZSB0cmVhdGVkIHNwZWNpYWxseTsgc2VlDQo+Pj4+Pj4gICAg ICAgICAgICAgICAgdGhlaXIgZGVzY3JpcHRpb25zIGZvciBkZXRhaWxzLg0KPj4+Pj4+IA0KPj4+ Pj4+ICAgICAgICAgICAgIDIuIE90aGVyd2lzZSAoaS5lLiwgdGhlcmUgaXMgbm8gbWF0Y2hpbmcg Y29uZmlndXJhdGlvbg0KPj4+Pj4+ICAgICAgICAgICAgICAgIGVudHJ5KSwgdGhlIGxpc3QgZW50 cnkgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGlzDQo+Pj4+Pj4gICAgICAgICAgICAgICAgaW5p dGlhbGl6ZWQgd2l0aCB2YWx1ZXMgZm9yIGFsbCBub2RlcyBhcyBkZXRlY3RlZCBieQ0KPj4+Pj4+ ICAgICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiAgICAg ICAgICAgSWYgdGhlIC9oYXJkd2FyZS9jb21wb25lbnQgbGlzdCBpbiB0aGUgaW50ZW5kZWQNCj4+ Pj4+PiAgICAgICAgICAgY29uZmlndXJhdGlvbiBpcyBtb2RpZmllZCwgdGhlbiB0aGUgc3lzdGVt IE1VU1QgYmVoYXZlIGFzIGlmDQo+Pj4+Pj4gICAgICAgICAgIGl0IHJlLWluaXRpYWxpemVzIGl0 c2VsZiwgYW5kIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGluDQo+Pj4+Pj4gKDEpLiI7DQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gL21hcnRpbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3 cm90ZToNCj4+Pj4+Pj4gT24gMTIvMjAvMjAxNyA0OjAwIFBNLCBNYXJ0aW4gQmpvcmtsdW5kIHdy b3RlOg0KPj4+Pj4+Pj4gQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0K Pj4+Pj4+Pj4+IEhpIE1hcnRpbiwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUaGFua3MuDQo+Pj4+ Pj4+Pj4gT25seSBrZXB0IHRoZSByZWxldmFudCBleGNlcnB0cy4NCj4+Pj4+Pj4+Pj4+IC0gU29t ZSBvYmplY3RzIGFyZSByZWFkLXdyaXRlIGluIFJGQzY5MzM6DQo+Pj4+Pj4+Pj4+PiAgICAgICAg ICBlbnRQaHlzaWNhbFNlcmlhbE51bQ0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxB bGlhcw0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgZW50UGh5c2ljYWxBc3NldElEDQo+Pj4+Pj4+Pj4+ PiAgICAgICAgICBlbnRQaHlzaWNhbFVyaXMNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gRm9y IGV4YW1wbGUsIGVudFBoeXNpY2FsU2VyaWFsTnVtIGJlaW5nIHJlYWQtd3JpdGUgYWx3YXlzIGJv dGhlcmVkDQo+Pj4+Pj4+Pj4+PiBtZS4NCj4+Pj4+Pj4+Pj4+IHNlcmlhbC1udW0gaXMgbm93ICJj b25maWcgZmFsc2UiLCB3aGljaCBpcyBhIGdvb2QgbmV3cyBJTU8uDQo+Pj4+Pj4+Pj4+IEFjdHVh bGx5LCB0aGlzIHdhcyBub3QgdGhlIGludGVudGlvbi4gIEluDQo+Pj4+Pj4+Pj4+IGRyYWZ0LWll dGYtbmV0bW9kLWVudGl0eS0wMyB0aGlzIGlzIGNvbmZpZ3VyYWJsZS4gIEkgbWlzc2VkIHRoaXMN Cj4+Pj4+Pj4+Pj4gaW4gdGhlIGNvbnZlcnNpb24gdG8gTk1EQS4NCj4+Pj4+Pj4+PiBBaC4gU28g bm8gZ29vZCBuZXdzIGluIHRoaXMgY2FzZS4uLg0KPj4+Pj4+Pj4+Pj4gSW4gdGhlIHJldmVyc2Ug ZGlyZWN0aW9uLCBlbnRQaHlzaWNhbE1mZ05hbWUgaXMgcmVhZC1vbmx5IGluDQo+Pj4+Pj4+Pj4+ PiBSRkM2OTMzLCB3aGlsZSBpdCdzICJjb25maWcgdHJ1ZSIgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qt ZW50aXR5DQo+Pj4+Pj4+Pj4+IFllcywgdGhpcyB3YXMgYWRkZWQgcGVyIHJlcXVlc3QgZnJvbSB0 aGUgV0cuICBTZWUgZS5nLiB0aGUNCj4+Pj4+Pj4+Pj4gdGhyZWFkICJkcmFmdC1pZXRmLW5ldG1v ZC1lbnRpdHkgaXNzdWUgIzEzIi4NCj4+Pj4+Pj4+PiBTdXJlLiBJdCB3YXMgbWFpbmx5IGFuIG9i c2VydmF0aW9uLg0KPj4+Pj4+Pj4+PiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgd2hhdCB3ZSBoYXZl IG5vdyBpcyBwcm9iYWJseSBub3QgY29ycmVjdC4NCj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGF0IGFs bCBub2RlcyAnc2VyaWFsLW51bScsICdtZmctbmFtZScsIGFuZCAnbW9kZWwtbmFtZScNCj4+Pj4+ Pj4+Pj4gc2hvdWxkIGJlIGNvbmZpZyB0cnVlLCBhbmQgdGhlIGRlc2NyaXB0aW9uIG9mIGxpc3Qg J2NvbXBvbmVudCcNCj4+Pj4+Pj4+Pj4gdXBkYXRlZCB0byByZWZsZWN0IHRoYXQgYWxsIHRoZXNl IHRyZWUgbGVhZnMgYXJlIGhhbmRsZWQgdGhlIHNhbWUgd2F5Lg0KPj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hhdCB0aGUgV0cgdGhpbmtzIGFib3V0IHRoaXMu DQo+Pj4+Pj4+Pj4gVGFsa2luZyBhcyBhIGNvbnRyaWJ1dG9yIHRoaXMgdGltZS4NCj4+Pj4+Pj4+ PiBJdCBzZWVtcyB0aGF0IGludmVudG9yeSBtYW5hZ2VtZW50IGlzIGtpbmQgb2YgYnJva2VuIHdo ZW4gc29tZW9uZQ0KPj4+Pj4+Pj4+IGNhbiBjaGFuZ2UgJ3NlcmlhbC1udW0nLCAnbWZnLW5hbWUn LCBhbmQgJ21vZGVsLW5hbWUuDQo+Pj4+Pj4+PiBUaGV5IGNhbid0IHJlYWxseSBjaGFuZ2UgdGhl bS4gIFRoZSBjb25maWd1cmVkIHZhbHVlcyBhcmUgb25seQ0KPj4+Pj4+Pj4gdXNlZCAoaS5lLiB2 aXNpYmxlIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSkgaWYgdGhlIGRldmljZSBjYW5ub3QNCj4+ Pj4+Pj4+IGRldGVjdCB0aGVtIGF1dG9tYXRpY2FsbHkuICBJLmUuLCB0aGV5IHdvcmsgYXMgInBv c3QtaXQiIG5vdGVzIG9ubHkuDQo+Pj4+Pj4+IElmIEkgbG9vayBhdCwgZm9yIGV4YW1wbGUsIHRo ZSBtZmctbmFtZSwgZGVzY3JpcHRpb24sIHRoaXMgaXMgbm90DQo+Pj4+Pj4+IHdoYXQgaXQgc2F5 cy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAgICBsZWFmIG1mZy1uYW1lIHsNCj4+Pj4+Pj4gICAgICAg ICAgICAgdHlwZSBzdHJpbmc7DQo+Pj4+Pj4+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgIlRoZSBuYW1lIG9mIHRoZSBtYW51ZmFjdHVyZXIgb2YgdGhpcyBw aHlzaWNhbCBjb21wb25lbnQuDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIFRoZSBwcmVmZXJyZWQg dmFsdWUgaXMgdGhlIG1hbnVmYWN0dXJlciBuYW1lIHN0cmluZw0KPj4+Pj4+PiAgICAgICAgICAg ICAgICBhY3R1YWxseSBwcmludGVkIG9uIHRoZSBjb21wb25lbnQgaXRzZWxmIChpZiBwcmVzZW50 KS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIE5vdGUgdGhhdCBjb21wYXJpc29u cyBiZXR3ZWVuIGluc3RhbmNlcyBvZiB0aGUgbW9kZWwtbmFtZSwNCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgZmlybXdhcmUtcmV2LCBzb2Z0d2FyZS1yZXYsIGFuZCB0aGUgc2VyaWFsLW51bSBub2Rl cyBhcmUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgb25seSBtZWFuaW5nZnVsIGFtb25nc3QgY29t cG9uZW50IHdpdGggdGhlIHNhbWUgdmFsdWUgb2YNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgbWZn LW5hbWUuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgICAgICAgICAgICAgICBJZiB0aGUgbWFudWZhY3R1 cmVyIG5hbWUgc3RyaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgcGh5c2ljYWwgY29tcG9uZW50IGlzIHVua25vd24gdG8gdGhlIHNlcnZlciwgdGhlbiB0aGlz DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIG5vZGUgaXMgbm90IGluc3RhbnRpYXRlZC4iOw0KPj4+ Pj4+PiAgICAgICAgICAgICByZWZlcmVuY2UgIlJGQyA2OTMzIDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjkzMz46DQo+Pj4+Pj4+ICAgICAgICAgICAgIGVudFBoeXNpY2FsTWZnTmFt ZSI7DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBSZWdhcmRzLCBCZW5vaXQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiAvbWFydGluDQo+Pj4+Pj4+PiAuDQo+Pj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+IC4NCj4+Pj4+PiANCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0 bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0 DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KDQo= From nobody Fri Jan 12 05:33:10 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 C85DD12E87C for ; Fri, 12 Jan 2018 05:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zL7xo8o4RFEf for ; Fri, 12 Jan 2018 05:33:06 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D52126BF3 for ; Fri, 12 Jan 2018 05:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17627; q=dns/txt; s=iport; t=1515763985; x=1516973585; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QEebpw7VprBBNkRZtxBeO5ZYQMVSXCpPd177hAd2UIA=; b=GcYkdCJVEbQY5j52GGnbSwkhXCCokXfCUW++wc01UyQTjj9llWwDB2Ej cW5g9ATJwOS8gLEBvb7h0lcio7nsV0mBGtsMLs1d1Fc6e8JqwF5UjOpo7 V/x0eW7Y18LgBuKj2fr9M87B+aNG6+jeu7nKuVBCaJE/pFKoDbiCH4WS3 U=; X-IronPort-AV: E=Sophos;i="5.46,348,1511827200"; d="scan'208";a="55258762" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 13:33:05 +0000 Received: from [10.118.87.84] (rtp-jclarke-nitro3.cisco.com [10.118.87.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0CDX48Q025402; Fri, 12 Jan 2018 13:33:05 GMT To: "Einar Nilsen-Nygaard (einarnn)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Martin Bjorklund , "bart.bogaert@nokia.com" Cc: "netmod@ietf.org" References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: <823fdeb7-3b4b-2504-364d-ef68502adccf@cisco.com> Date: Fri, 12 Jan 2018 08:33:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 13:33:09 -0000 On 1/12/18 05:52, Einar Nilsen-Nygaard (einarnn) wrote: > Yes, Option 2 seems best. Agreed. I believe most assume these are static values from the vendor that are not field-writeable (certainly that is true from what I've seen here at Cisco). Joe > > Cheers, > > Einar > > >> On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) wrote: >> >> >> >> On 11/01/2018 13:47, Martin Bjorklund wrote: >>> Hi, >>> >>> To summarize this, I think we have three options for the three nodes >>> 'model-name', 'mfg-name', and 'serial-num': >>> >>> 1. Do nothing (keep the nodes as config true). >>> >>> 2. Make these three nodes config false (fairly simple change). >>> (vendors can augment w/ their own config true nodes). >>> >>> 3. Add three new nodes for the configured values. >>> >>> >>> After thinking about this some more, and discussing with Benoit, I >>> think the best path forward is to do 2, i.e., mark the nodes >>> 'model-name', 'mfg-name', and 'serial-num' as "config false". As such >>> they would not be configurable, and thus contain the detected values. >>> If no value is detected, the node is not present. >> Option 2 suits me. It keeps it simple. >> >>> >>> Note that 1 or 3 can be done in a future update to this module (or by >>> a vendor). >> Agreed. >> >> Thanks, >> Rob >> >> >>> >>> >>> /martin >>> >>> >>> Martin Bjorklund wrote: >>>> Hi, >>>> >>>> "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: >>>>> Hi, >>>>> >>>>> --- snip --- >>>>> >>>>>> state.”, so the above sentence only applies for the second case below. >>>>> Ok. >>>>> >>>>>> 2. The second case is that something is detected but it can’t be read. >>>>>> We do not see a reason to use the value configured for the leafs >>>>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the >>>>>> configuration data. These leafs are defined as optional so why would >>>>>> we report something entered by an operator in the operational >>>>>> datastore that intends to report on what is detected? Is it not >>>>>> better to not report them at all? In an NMDA context it would be >>>>>> possible to have a different value (or no value at all) for certain >>>>>> leafs while there is something in the running/intended datastore. >>>>> The normal NMDA procedure for a configuration leaf is to repeat it in >>>>> operational state. This is then the "applied configuration". >>>>> I don't think we should have a special rule for these leafs. >>>>> >>>>> This also means that a client that just wants to read all the serial >>>>> numbers can do so from one place, the operational state, regardless of >>>>> how they came into existance. >>>>> >>>>> [Bogaert, Bart ] >>>>> >>>>> We do understand that a target of NMDA is to read out the actually >>>>> applied data in one request. But the result should not be >>>>> confusion. A key word is “applied”. >>>>> >>>>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains >>>>> (I put a part of the section between ***): >>>>> The datastore schema for MUST be a superset of the >>>>> combined datastore schema used in all configuration datastores except >>>>> that configuration data nodes supported in a configuration datastore >>>>> ***MAY be omitted from if a server is not able to >>>>> accurately report them ***. >>>> Note that this text talks about the *schema*. It is intended for >>>> servers to migrate to NMDA without having to instrument all config >>>> nodes in immediately. If you apply this to >>>> ietf-hardware, it could be a server that implements the node >>>> "serial-num" in config, but not in (which would be >>>> weird). >>>> >>>>> For example, it is expected that the value of multiple leafs need to >>>>> be a consistent set, e.g. the mfg-name, the model-name, and the >>>>> serial-num. >>>>> Suppose we have a use case in which a hardware component is >>>>> planned/configured (e.g. a board supporting DSL interfaces) but a >>>>> different one is plugged (e.g. a board supporting ethernet >>>>> interfaces). >>>>> Suppose it is possible to read some fields on the detected component >>>>> but due to an issue not to read other fields. >>>>> If in that case the operational datastore will be completed with the >>>>> data taken from the running datastore, then the presented view might >>>>> be inconsistent. >>>> This is true for other similar nodes as well - "asset-id" and "uri". >>>> >>>>> The question is also: what data is applied? Our assumption: if there >>>>> is a mismatch between detected versus configured hardware, then the >>>>> interface/service related data that is configured consistently with >>>>> the planned hardware is not applied on the mismatching >>>>> hardware. I.e. the detected hardware is not brought in service so not >>>>> ‘applied’, the operational datastore only (accurately) reports on what >>>>> is detected. >>>> If there is a mismatch and the server doesn't apply the configured >>>> values, then obviously the configured 'mfg-name' etc are not copied to >>>> . >>>> >>>>> We do not see this as a special rule for this data but rather would >>>>> apply a general rule: >>>>> - if there is a ‘missing resource’, then the data is not reported in the >>>>> operational datastore. >>>>> - If the server is not able to report accurately, then the data is >>>>> omitted from the operational >>>> I think that if you want complete separation between the values of >>>> 'mfg-name', 'model-name', and 'serial-num' in configuration and >>>> operational state, then these should be modelled as separate leafs. >>>> We should have a config false leaf 'serial-num' that only contains the >>>> detected value (if found), and a config true leaf 'config-serial-num' >>>> or something, that contains the configured serial number. >>>> >>>> But if this is the case, I wonder if it wouldn't be better to leave >>>> such additional config objects to vendors, and simply make these three >>>> nodes config false in ietf-hardware. >>>> >>>> >>>> /martin >>>> >>>>> Regards, Bart >>>>> >>>>> /martin >>>>> >>>>> >>>>>> Best regards, Bart >>>>>> >>>>>> -----Original Message----- >>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >>>>>> Wilton >>>>>> Sent: Thursday, December 21, 2017 4:14 PM >>>>>> To: Martin Bjorklund ; netmod@ietf.org >>>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> >>>>>> On 21/12/2017 11:37, Martin Bjorklund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I need WG input on this issue. The question is how to handle >>>>>>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>>>>>> be treated the same. Based on previous WG discussion (see e.g. the >>>>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>>>>>> should all be configurable, but the configured value is only used in >>>>>>> operational state if the system cannot read it from the hardware. >>>>>> I think that this approach is probably OK: >>>>>> - The client can always see the real value if it is available. >>>>>> - If it is not available then they can assign a value via >>>>>> configuration. >>>>>> >>>>>> I was also considering an alternative approach of having a separate >>>>>> set of config false leaves for the "burnt in values". And then having >>>>>> the configurable leaves always override the default operational >>>>>> values. E.g. similar to how an interface MAC address would expect to >>>>>> be handled. >>>>>> >>>>>> But one set of leaves is probably sufficient. >>>>>> >>>>>> Thanks, >>>>>> Rob >>>>>> >>>>>> >>>>>>> So I suggest the following changes: >>>>>>> >>>>>>> OLD: >>>>>>> >>>>>>> leaf serial-num { >>>>>>> type string; >>>>>>> config false; >>>>>>> description >>>>>>> "The vendor-specific serial number string for the >>>>>>> component. The preferred value is the serial number >>>>>>> string actually printed on the component itself (if >>>>>>> present)."; >>>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>>> } >>>>>>> >>>>>>> NEW: >>>>>>> >>>>>>> leaf serial-num { >>>>>>> type string; >>>>>>> description >>>>>>> "The vendor-specific serial number string for the >>>>>>> component. The preferred value is the serial number >>>>>>> string actually printed on the component itself (if >>>>>>> present). >>>>>>> >>>>>>> This leaf can be configured. There are two use cases for >>>>>>> this; as a 'post-it' note if the server cannot determine >>>>>>> this value from the component, or when pre-provisioning a >>>>>>> component. >>>>>>> >>>>>>> If the server can determine the serial number from the >>>>>>> component, then that value is always used in operational >>>>>>> state, even if another value has been configured."; >>>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>>> } >>>>>>> >>>>>>> And corresponding text for 'mfg-name' and 'model-name'. >>>>>>> >>>>>>> And also: >>>>>>> >>>>>>> OLD: >>>>>>> >>>>>>> When the server detects a new hardware component, it >>>>>>> initializes a list entry in the operational state. >>>>>>> >>>>>>> If the server does not support configuration of hardware >>>>>>> components, list entries in the operational state are >>>>>>> initialized with values for all nodes as detected by the >>>>>>> implementation. >>>>>>> >>>>>>> Otherwise, the following procedure is followed: >>>>>>> >>>>>>> 1. If there is an entry in the /hardware/component list in >>>>>>> the intended configuration with values for the nodes >>>>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>>>> the detected values, then: >>>>>>> >>>>>>> 1a. If the configured entry has a value for 'mfg-name' >>>>>>> that is equal to the detected value, or if the >>>>>>> 'mfg-name' value cannot be detected, then the list >>>>>>> entry in the operational state is initialized with the >>>>>>> configured values for all configured nodes, including >>>>>>> the 'name'. >>>>>>> >>>>>>> Otherwise, the list entry in the operational state is >>>>>>> initialized with values for all nodes as detected by >>>>>>> the implementation. The implementation may raise an >>>>>>> alarm that informs about the 'mfg-name' mismatch >>>>>>> condition. How this is done is outside the scope of >>>>>>> this document. >>>>>>> >>>>>>> 1b. Otherwise (i.e., there is no matching configuration >>>>>>> entry), the list entry in the operational state is >>>>>>> initialized with values for all nodes as detected by >>>>>>> the implementation. >>>>>>> >>>>>>> If the /hardware/component list in the intended >>>>>>> configuration is modified, then the system MUST behave as if >>>>>>> it re-initializes itself, and follow the procedure in >>>>>>> (1)."; >>>>>>> >>>>>>> NEW: >>>>>>> >>>>>>> When the server detects a new hardware component, it >>>>>>> initializes a list entry in the operational state. >>>>>>> >>>>>>> If the server does not support configuration of hardware >>>>>>> components, list entries in the operational state are >>>>>>> initialized with values for all nodes as detected by the >>>>>>> implementation. >>>>>>> >>>>>>> Otherwise, the following procedure is followed: >>>>>>> >>>>>>> 1. If there is an entry in the /hardware/component list in >>>>>>> the intended configuration with values for the nodes >>>>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>>>> the detected values, then the list entry in operational >>>>>>> state is initialized with the configured values, >>>>>>> including the 'name'. The leafs 'serial-num', >>>>>>> 'mfg-name', and 'model-name' are treated specially; see >>>>>>> their descriptions for details. >>>>>>> >>>>>>> 2. Otherwise (i.e., there is no matching configuration >>>>>>> entry), the list entry in the operational state is >>>>>>> initialized with values for all nodes as detected by >>>>>>> the implementation. >>>>>>> >>>>>>> If the /hardware/component list in the intended >>>>>>> configuration is modified, then the system MUST behave as if >>>>>>> it re-initializes itself, and follow the procedure in >>>>>>> (1)."; >>>>>>> >>>>>>> >>>>>>> >>>>>>> /martin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Benoit Claise wrote: >>>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>>>>>> Benoit Claise wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> Only kept the relevant excerpts. >>>>>>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>>>>>> entPhysicalSerialNum >>>>>>>>>>>> entPhysicalAlias >>>>>>>>>>>> entPhysicalAssetID >>>>>>>>>>>> entPhysicalUris >>>>>>>>>>>> >>>>>>>>>>>> For example, entPhysicalSerialNum being read-write always bothered >>>>>>>>>>>> me. >>>>>>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>>>>>> Actually, this was not the intention. In >>>>>>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>>>>>> in the conversion to NMDA. >>>>>>>>>> Ah. So no good news in this case... >>>>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>>>>>> Sure. It was mainly an observation. >>>>>>>>>>> However, I think that what we have now is probably not correct. >>>>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' >>>>>>>>>>> should be config true, and the description of list 'component' >>>>>>>>>>> updated to reflect that all these tree leafs are handled the same way. >>>>>>>>>>> >>>>>>>>>>> I would like to know what the WG thinks about this. >>>>>>>>>> Talking as a contributor this time. >>>>>>>>>> It seems that inventory management is kind of broken when someone >>>>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>>>>>> They can't really change them. The configured values are only >>>>>>>>> used (i.e. visible in the operational state) if the device cannot >>>>>>>>> detect them automatically. I.e., they work as "post-it" notes only. >>>>>>>> If I look at, for example, the mfg-name, description, this is not >>>>>>>> what it says. >>>>>>>> >>>>>>>> leaf mfg-name { >>>>>>>> type string; >>>>>>>> description >>>>>>>> "The name of the manufacturer of this physical component. >>>>>>>> The preferred value is the manufacturer name string >>>>>>>> actually printed on the component itself (if present). >>>>>>>> >>>>>>>> Note that comparisons between instances of the model-name, >>>>>>>> firmware-rev, software-rev, and the serial-num nodes are >>>>>>>> only meaningful amongst component with the same value of >>>>>>>> mfg-name. >>>>>>>> >>>>>>>> If the manufacturer name string associated with the >>>>>>>> physical component is unknown to the server, then this >>>>>>>> node is not instantiated."; >>>>>>>> reference "RFC 6933 : >>>>>>>> entPhysicalMfgName"; >>>>>>>> >>>>>>>> Regards, Benoit >>>>>>>> >>>>>>>>> /martin >>>>>>>>> . >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> _______________________________________________ >>> 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 > From nobody Fri Jan 12 06:24: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 C569012DA45; Fri, 12 Jan 2018 06:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 dPr5EWaFbpxt; Fri, 12 Jan 2018 06:24:09 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 9DAF812D77D; Fri, 12 Jan 2018 06:24:09 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id t67so4654233pgc.5; Fri, 12 Jan 2018 06:24:09 -0800 (PST) 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; bh=j7uQ7x5AIwuNCpGRBMUGKnSvuxl/ZsxjpEovt/2FdT0=; b=bnGovCTxFC9uyDeaXM8nHEc9I8Q1JeFHBgdMKFPjUbl2mMalma9c5kEM4jnL/qezOe xlR8HR5LmkkolzpzUNJgYo3/W5DGIARVXhzt+/ad7IdxLMTCDU5sugPNolMDd6Z7TOBZ XFkTusN6mPpo5NlB5O5/4hM2nU1xidyxlN2I585OkXK+DmvlYu7+ds9XZe6ncHAsmN/V +LqCOHgjgpwa1bjgkQR2quZfjUKJIo2jhv6p+nwNC8kI7bXGU7L0c4qtTyDkGBmpEXth PzVFJUrwlWPyXhBgq+htcMNNiONL1sFWyrPmw0slIZUsdFUVQiFXdg5WvoP+yjSUKpUD MgRw== 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=j7uQ7x5AIwuNCpGRBMUGKnSvuxl/ZsxjpEovt/2FdT0=; b=L/VVSYTG0Ex0kJo8YGqN6WN1pjdqDKP1JmvVKJw2Rt6JPuSGAw+tZRnkJey7UMONxs oRmpYKEp3rW0uvq6bBmosGRaulrU+1BVGe858x0aejBgpymDKKyFp9s6JiB+I4wv/lJf SfzmJI75oNl6SVdLeMEtZoPway0Dh0xxuwgn2Fg5CRQLIfiXtJC9LMuuTEs61nt5ouJ4 QmX0631Bz/pr+FT5BStAEDM3gAjvxCZKmMWMx7AAh/cK0W+bhGeoChV8Bse82rMlW0AL Kwt8YElya2HVjpeA+NgoThkeeFRJCfphaADq6H6WaoDWv/nEsYzGPBLAgY4cO12nXSt0 7kdw== X-Gm-Message-State: AKGB3mIbbKZcc2S4+oO5sv49jLtcO48O9U9QQZqEl9uR6Aa1qecRJSPX J7TDORLXKGaSemfnaY5H/jmf5RUApope/7gBGs8= X-Google-Smtp-Source: ACJfBoviIwiw33ldd8PhUiedalfQFNM11Txm3N7KVRAFJ9TkZ7E4+cYXtu8h6CDv5ovSmaket2zBCbUb/OJAJOec4iw= X-Received: by 10.101.81.7 with SMTP id f7mr20865742pgq.443.1515767049232; Fri, 12 Jan 2018 06:24:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 12 Jan 2018 06:23:28 -0800 (PST) In-Reply-To: <20180112094500.ymlrkswjfgkhibef@elstar.local> References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> <20180112094500.ymlrkswjfgkhibef@elstar.local> From: Kathleen Moriarty Date: Fri, 12 Jan 2018 09:23:28 -0500 Message-ID: To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 14:24:12 -0000 Hi Juergen, On Fri, Jan 12, 2018 at 4:45 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen Moriarty wrote: >> Hi Juergen, >> >> Thank you very much for the additional information. This was very >> helpful. Benoit and I discussed it a bit further on the telechat and >> some text changes in the introduction and security considerations >> section to provide some of this information for the reader will be >> helpful. I got the explanations and appreciate them and from the >> explanations, my discuss questions have been answered and I'll switch >> this to a no objection leaving you and Benoit to add the text as >> helpful for other readers. >> > > Kathleen, > > we propose to add this text to the security considerations: > > The origin metadata annotation exposes the origin of values in the > applied configuration. Origin information may provide hints that > certain control plane protocols are active on a device. Since origin > information is tied to applied configuration values, it is only > accessible to clients that have the permissions to read the applied > configuration values. Security administrators should consider the > sensitivity of origin information while defining access control > rules. Thank you, that is very helpful. Would it also be possible to add text in the introduction on where the data for these values comes from (the device itself)? Best regards, Kathleen > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Best regards, Kathleen From nobody Fri Jan 12 07:35: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 7D38812E89A for ; Fri, 12 Jan 2018 07:35:47 -0800 (PST) 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_RP_MATCHES_RCVD=-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 9qt_Ws55eL01 for ; Fri, 12 Jan 2018 07:35:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E62F1270AE for ; Fri, 12 Jan 2018 07:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=174268; q=dns/txt; s=iport; t=1515771341; x=1516980941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vL/KURld5G6Pz7mVbWaOsckXJm1MBT2JjXKErlqoBR4=; b=N+cSP4VkUElwFUQrodzW8gD6TJl2G1D0Rd28gSj2PCg2XLFxGAHal8ov ZjKjHZNdTewHmKTjt5N87ZRdEX+NrjnU61hMh7xPvv14CeAKPdIByFCkz rUvcccmKre2NCmZ6ibqN2CC9SBmpn6wEmXGHpNN9PQil6xA2p0RmnTd8Z M=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAi1Vha/xbLJq1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEYEWdCeEB4sYj26JC44mFIICBwMYAQqESU8CGoRnFwEBAQE?= =?us-ascii?q?BAQEBAWsohSQBAQQBARgBCARHCxAJAg4KIAEGAwICAh8GHxEGDQYCAQGKFwMVE?= =?us-ascii?q?JBnnXCBbTomhxUNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWEPIVUASmDBYJ?= =?us-ascii?q?rRAEBAoFFEi8fgmGCZQWSJ4dLiTU9hFeCMIEFiD2FAoIZhh2Db4drjT5AiSeBP?= =?us-ascii?q?CABN4FQMhoIGxU9giqCGzkcgWhAN4w1AQEB?= X-IronPort-AV: E=Sophos;i="5.46,349,1511827200"; d="asc'?scan'208,217";a="1368831" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 15:35:38 +0000 Received: from [10.61.225.122] ([10.61.225.122]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0CFZbmg023136; Fri, 12 Jan 2018 15:35:38 GMT To: Mahesh Jethanandani Cc: "netmod@ietf.org" References: <20171102074318.GC12688@spritelink.se> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> From: Eliot Lear Message-ID: <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> Date: Fri, 12 Jan 2018 16:35:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NDjgprMq7aMndfRVLV9dHQ9l6kHeXjgH4" Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:35:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NDjgprMq7aMndfRVLV9dHQ9l6kHeXjgH4 Content-Type: multipart/mixed; boundary="J7TI0on49WEEtibdc4GqEf4iR36SwtPQs"; protected-headers="v1" From: Eliot Lear To: Mahesh Jethanandani Cc: "netmod@ietf.org" Message-ID: <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> In-Reply-To: --J7TI0on49WEEtibdc4GqEf4iR36SwtPQs Content-Type: multipart/alternative; boundary="------------3F537B3F27FFC5DFDD92E390" Content-Language: en-US This is a multi-part message in MIME format. --------------3F537B3F27FFC5DFDD92E390 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T2suwqAgV2hhdCBpcyBsZWZ0IHRvIGFncmVlIG9uIGF0IHRoaXMgcG9pbnQ/CgpUaGFua3Mg TWFoZXNoLAoKRWxpb3QKCgpPbiAxMS4wMS4xOCAwMjoyMSwgTWFoZXNoIEpldGhhbmFuZGFu aSB3cm90ZToKPiBIaSBFaW5hciwKPgo+IEkgY2FuIHdvcmsgb24gdXBkYXRpbmcgdGhlIGRy YWZ0IGFzIHNvb24gYXMgd2UgYWdyZWUgb24gdGhlIGNoYW5nZXMuCj4gU2hvdWxkIHRha2Ug b25seSBhIGNvdXBsZSBvZiBkYXlzIHRvIHR1cm4gYXJvdW5kIGFuZCBwdWJsaXNoIHRoZSBk cmFmdC4KPgo+PiBPbiBKYW4gOSwgMjAxOCwgYXQgMTE6MzUgUE0sIEVsaW90IExlYXIgPGxl YXJAY2lzY28uY29tCj4+IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToKPj4KPj4g SGkgTWFoZXNoLAo+Pgo+PiBUaGFua3MgZm9yIHRoaXMgd29yay7CoCBJIHRoaW5rIHRoaXMg aXMgb2theS7CoCBJbiB0aGUgY2FzZSBvZiBNVUQgd2UKPj4gc2ltcGx5IHdvbid0IGhhdmUg dGhlIG90aGVyIGNvbnRhaW5lci7CoCBDYW4gSSBwbGVhc2UgYXNrIHRoYXQgeW91IGdldAo+ PiB0aGUgZHJhZnQgb3V0IHF1aWNrbHkgYXMgZHJhZnQtaWV0Zi1vcHNhd2ctbXVkIGhhcyBi ZWVuIHdhaXRpbmcgcXVpdGUKPj4gc29tZSB0aW1lIGZvciB0aGlzIHdvcmsgdG8gY29tcGxl dGUuCj4+Cj4+IEVsaW90Cj4+Cj4+Cj4+IE9uIDEwLjAxLjE4IDA0OjA4LCBNYWhlc2ggSmV0 aGFuYW5kYW5pIHdyb3RlOgo+Pj4gSSBoYXZlIHB1bGxlZCBpbiB0aGUgY2hhbmdlcyBhcyB0 aGV5IHJlbGF0ZSB0bzoKPj4+Cj4+PiAtIG1vdmluZyDigJxpbnRlcmZhY2UtYWNs4oCdIHVu ZGVyIHRoZSBjb250YWluZXIg4oCcYXR0YWNobWVudC1wb2ludHPigJ0KPj4+IG1ha2luZyBp dCBsb2NhbCB0byB0aGF0IGNvbnRhaW5lci4KPj4+IC0gcmV2ZXJ0aW5nIOKAnGFjbC10eXBl 4oCdIHRvIOKAnHR5cGXigJ0KPj4+IC0gcmVtb3ZlZCDigJxpbnRlcmZhY2UtYWxsLWFnZ3Jl Z2F0ZeKAnSBmZWF0dXJlCj4+PiAtIHNpbXBsaWZpZWQgc291cmNlIHBvcnQgYW5kIGRlc3Rp bmF0aW9uIHBvcnQgZGVmaW5pdGlvbgo+Pj4KPj4+IFRoZSBwdWxsIHJlcXVlc3QgZm9yIHRo ZSBjaGFuZ2VzIGNhbiBiZSBmb3VuZCBoZXJlLgo+Pj4KPj4+IGh0dHBzOi8vZ2l0aHViLmNv bS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjAKPj4+Cj4+PiBBZnRlciBkaXNjdXNzaW5n IHdpdGggc29tZSBvZiB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzLCBkZWNpZGVkIG5vdAo+ Pj4gdG8gaW5jbHVkZSB0aGUgY2hhbmdlIGFzIGl0IHJlbGF0ZXMgdG8gYXVnbWVudGluZyBp ZXRmLWludGVyZmFjZXMuCj4+PiBXZSBkaWQgbm90IGZpbmQgdGhhdCB0aGUgY2hhbmdlIGhh ZCBhIHBhcnRpY3VsYXIgYWR2YW50YWdlIG92ZXIgdGhlCj4+PiBjdXJyZW50IGltcGxlbWVu dGF0aW9uLiBFdmVuIGlmIHdlIGRvIG5vdCBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgaG93Cj4+ PiBBQ0xzIG1pZ2h0IGJlIGF0dGFjaGVkIOKAnGdsb2JhbGx54oCdIG9yIG9uIHNvbWV0aGlu ZyB0aGF0IGlzIG5vdCBhbgo+Pj4gaW50ZXJmYWNlLCBoYXZpbmcgdGhlIGZsZXhpYmlsaXR5 IHRvIGF0dGFjaCB0aGVtIHRvIG90aGVyIGF0dGFjaG1lbnQKPj4+IHBvaW50cyBpcyBpbXBv cnRhbnQuIEtlZXBpbmcgaXQgYXMgaW50ZXJmYWNlLXJlZiBnaXZlcyB1cyB0aGF0Cj4+PiBm bGV4aWJpbGl0eS4KPj4+Cj4+PiBDaGVlcnMuCj4+Pgo+Pj4+IE9uIERlYyAxOCwgMjAxNywg YXQgNDozMSBBTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20KPj4+PiA8bWFpbHRvOmxl YXJAY2lzY28uY29tPj4gd3JvdGU6Cj4+Pj4KPj4+PiBTbyBsb25nIGFzIG5vYm9keSBleHBl Y3RzIGFuIGludGVyZmFjZSBjb25zdHJ1Y3QgaW4gYSBNVUQgZmlsZSwgSSdtCj4+Pj4gaGFw cHkuCj4+Pj4KPj4+Pgo+Pj4+IE9uIDE3LjEyLjE3IDE1OjM0LCBFaW5hciBOaWxzZW4tTnln YWFyZCAoZWluYXJubikgd3JvdGU6Cj4+Pj4+IEVsaW90LAo+Pj4+Pgo+Pj4+PiBOb3RoaW5n IGNhbiBmb3JjZSBhbiBpbXBsZW1lbnRhdGlvbiB0byBoYXZlIHRvIGltcGxlbWVudCBlaXRo ZXIKPj4+Pj4gdGhlwqBpZXRmLWludGVyZmFjZXMgbW9kZWwgb3IgdGhlIGF1Z21lbnRhdGlv biBpbiB0aGUKPj4+Pj4gaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1vZGVsLiBJIGFwcHJl Y2lhdGUgeW91ciBkZXNpcmUgZm9yCj4+Pj4+IG1vZHVsYXJpdHkgYW5kIGNvaGVzaXZlbmVz cywgYnV0IEkgd291bGQgcmVzaXN0ICMxLCBiZWNhdXNlIEkgZmVlbAo+Pj4+PiB0aGF0IHRo ZSBtYWpvcml0eSBvZiB1c2VycyB3aWxsIGJlIHRhcmdldGluZyBpbnRlcmZhY2UtYmFzZWQK Pj4+Pj4gYXR0YWNobWVudCBvdmVyIHRpbWUuIEnigJl2ZSBhZGRlIGJhY2sgaW4gdXNlIG9m IHRoZQo+Pj4+PiDigJxpbnRlcmZhY2UtYXR0YWNobWVudOKAnSBmZWF0dXJlICh3aGljaCBJ IHRvb2sgb3V0IGFzIHBhcnQgb2YKPj4+Pj4gcmVmYWN0b3JpbmcgaW50ZXJmYWNlIGF0dGFj aG1lbnQpLiBQYXJ0IG9mOgo+Pj4+Pgo+Pj4+PiAgICAgaHR0cHM6Ly9naXRodWIuY29tL25l dG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMQo+Pj4+Pgo+Pj4+Pgo+Pj4+PiBUaGUgYXVnbWVu dHMgcGFydCBvZiB0aGUgdHJlZSBub3cgbG9va3MgbGlrZToKPj4+Pj4KPj4+Pj4gwqAgYXVn bWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6Cj4+Pj4+IMKgIMKgICstLXJ3IGFj bHMgKntpbnRlcmZhY2UtYXR0YWNobWVudH0qPwo+Pj4+PiDCoCDCoCDCoCDCoCstLXJ3IGlu Z3Jlc3MKPj4+Pj4gwqAgwqAgwqAgwqB8IMKgKy0tcncgYWNsLXNldHMKPj4+Pj4gwqAgwqAg wqAgwqB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+PiDCoCDCoCDCoCDCoHwg wqAgwqAgwqAgwqArLS1ydyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgLT4gL2FjY2Vzcy1s aXN0cy9hY2wvbmFtZQo+Pj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ydyB0eXBl PyDCoCDCoCDCoCDCoCDCoCDCoCAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+Pj4+IMKg IMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2lu dGVyZmFjZS1zdGF0c30/Cj4+Pj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCArLS1y byBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0+Cj4+Pj4+IC9hY2Nlc3MtbGlzdHMvYWNs L2FjZXMvYWNlL25hbWUKPj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJv IG1hdGNoZWQtcGFja2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPj4+Pj4gwqAgwqAgwqAgwqB8 IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRl cjY0Cj4+Pj4+IMKgIMKgIMKgIMKgKy0tcncgZWdyZXNzCj4+Pj4+IMKgIMKgIMKgIMKgIMKg ICstLXJ3IGFjbC1zZXRzCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNl dCogW25hbWVdCj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IG5hbWUgwqAg wqAgwqAgwqAgwqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lCj4+Pj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9h Y2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0t cm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKg IMKgIC0+Cj4+Pj4+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUKPj4+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlh bmc6Y291bnRlcjY0Cj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8g bWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+Pj4KPj4+Pj4gQ2hlZXJz LAo+Pj4+Pgo+Pj4+PiBFaW5hcgo+Pj4+Pgo+Pj4+Pgo+Pj4+Pj4gT24gMTcgRGVjIDIwMTcs IGF0IDExOjI5LCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbQo+Pj4+Pj4gPG1haWx0bzps ZWFyQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pj4+Pj4KPj4+Pj4+IEVpbmFyLAo+Pj4+Pj4KPj4+ Pj4+IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgZmluZSwgd2l0aCBvbmUgZXhjZXB0aW9uLsKg IEkgd291bGQgcmF0aGVyCj4+Pj4+PiB0aGUgYXVnbWVudCB0byB0aGUgaW50ZXJmYWNlIG5v dCBiZSByZXF1aXJlZCBmb3IgaW1wbGVtZW50YXRpb25zCj4+Pj4+PiB0aGF0IGRvbid0IGFj dHVhbGx5IGhhdmUgaW50ZXJmYWNlcy7CoCBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtYXkK Pj4+Pj4+IGJlIHR3byB3YXlzIHRvIGdvIGFib3V0IHRoaXM6Cj4+Pj4+Pgo+Pj4+Pj4gIDEu IFNlcGFyYXRlIG91dCB0aGUgYXVnbWVudCBpbnRvIGEgc2VwYXJhdGUgbW9kdWxlIChzYW1l IGRvYyBpcwo+Pj4+Pj4gICAgIGZpbmUpOyBvcgo+Pj4+Pj4gIDIuIFNvbWVob3cgImZlYXR1 cmUtaXplIiB0aGUgYXVnbWVudC4KPj4+Pj4+Cj4+Pj4+PiBJIGRvbid0IGtub3cgaG93IHRv IGRvICgyKSBidXQgaWYgeW91IGRvLCB0aGF0J3Mgb2theSBieSBtZS4KPj4+Pj4+Cj4+Pj4+ PiBFbGlvdAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiBPbiAxNi4xMi4xNyAxNDoxOSwgRWluYXIg Tmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOgo+Pj4+Pj4+IEFsbCwKPj4+Pj4+Pgo+ Pj4+Pj4+IEFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25zIG9uLSBhbmQgb2ZmLWxpc3Qs IEkgaGF2ZSBhCj4+Pj4+Pj4gY2FuZGlkYXRlIFBSIHRoYXQgaW5jbHVkZXMgdGhlIGNoYW5n ZXMgaW4gdGhlIFBSIE1haGVzaCBzZW50IG91dAo+Pj4+Pj4+IHBsdXMgc29tZSBtb3JlIGVk aXRzLiBQbGVhc2Ugc2VlIGNvbnNvbGlkYXRlZCBQUiBoZXJlOgo+Pj4+Pj4+Cj4+Pj4+Pj4g ICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjEKPj4+ Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gTWFpbiBjaGFuZ2VzIGluIGFkZGl0aW9uIHRvIE1haGVz aOKAmXMgUFIgYXJlOgo+Pj4+Pj4+Cj4+Pj4+Pj4gICAqIE1vdmVkIGludGVyZmFjZSBhdHRh Y2htZW50IHRvIGJlIHZpYSBhbiBpbnRlcmZhY2UgYXVnbWVudGF0aW9uLgo+Pj4+Pj4+ICAg KiBSZXN0cnVjdHVyZWQgcG9ydCBtYXRjaGVzIHNsaWdodGx5IHVuZGVyIGJvdGggSVB2NCBh bmQgSVB2Ngo+Pj4+Pj4+ICAgICBjb250YWluZXJzLgo+Pj4+Pj4+ICAgKiBSZW1vdmVkIHVu bmVjZXNzYXJ5IGlkZW50aXR5ICdpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZeKAmS4KPj4+Pj4+ PiAgICogUmVtb3ZlZCBhY3Rpb24g4oCYaWNtcC1vZmbigJksIGNhbiBiZSBhdWdtZW50ZWQg bGF0ZXIuCj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+IEZvciByZWZlcmVuY2UsIGhlcmUgaXMg dGhlIGN1cnJlbnQgWUFORyB0cmVlIHBsdXMg4oCcLS1pZXRm4oCdIGxvZ3M6Cj4+Pj4+Pj4K Pj4+Pj4+PiAxMzoxMiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJlZSBpZXRmLWFjY2Vz cy1jb250cm9sLWxpc3QueWFuZwo+Pj4+Pj4+IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55 YW5nOjUxOiBlcnJvcjogYmFkIHZhbHVlICJZWVlZLU1NLUREIgo+Pj4+Pj4+IChzaG91bGQg YmUgZGF0ZSkKPj4+Pj4+PiBtb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdAo+Pj4+ Pj4+IMKgIMKgICstLXJ3IGFjY2Vzcy1saXN0cwo+Pj4+Pj4+IMKgIMKgIMKgIMKgKy0tcncg YWNsKiBbbmFtZV0KPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCArLS1ydyBuYW1lIMKgIMKgc3Ry aW5nCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgKy0tcncgdHlwZT8gwqAgYWNsLXR5cGUKPj4+ Pj4+PiDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY2VzCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqArLS1ydyBhY2UqIFtuYW1lXQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqBzdHJpbmcKPj4+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCArLS1ydyBtYXRjaGVzCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoCstLXJ3IChsMik/Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqArLS06KGV0aCkKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oCDCoCArLS1ydyBldGgge21hdGNoLW9uLWV0aH0/Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVz cz8gwqAgwqAgwqAKPj4+Pj4+PiDCoHlhbmc6bWFjLWFkZHJlc3MKPj4+Pj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGRlc3RpbmF0aW9uLW1h Yy1hZGRyZXNzLW1hc2s/Cj4+Pj4+Pj4gwqAgeWFuZzptYWMtYWRkcmVzcwo+Pj4+Pj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgc291cmNlLW1h Yy1hZGRyZXNzPyDCoCDCoCDCoCDCoCDCoAo+Pj4+Pj4+IMKgIHlhbmc6bWFjLWFkZHJlc3MK Pj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3 IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNrPyDCoCDCoCDCoAo+Pj4+Pj4+IMKgeWFuZzptYWMt YWRkcmVzcwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKg IMKgKy0tcncgZXRoZXJ0eXBlPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoAo+Pj4+ Pj4+IMKgZXRoOmV0aGVydHlwZQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqArLS1ydyAobDMpPwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg Ky0tOihpcHY0KQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDC oCstLXJ3IGlwdjQge21hdGNoLW9uLWlwdjR9Pwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBkc2NwPyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoAo+Pj4+Pj4+IGluZXQ6ZHNjcAo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBlY24/IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgdWludDgKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgbGVuZ3RoPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB1aW50MTYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgKy0tcncgdHRsPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHVpbnQ4Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg ICstLXJ3IHByb3RvY29sPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+Pj4+ Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyAoc291 cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgKy0tOihyYW5nZSkKPj4+Pj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwgwqArLS1ydyBzb3VyY2Ut cG9ydC1sb3dlciDCoCDCoCDCoAo+Pj4+Pj4+IMKgIMKgIGluZXQ6cG9ydC1udW1iZXIKPj4+ Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwgwqAr LS1ydyBzb3VyY2UtcG9ydC11cHBlciDCoCDCoCDCoAo+Pj4+Pj4+IMKgIMKgIGluZXQ6cG9y dC1udW1iZXIKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAg wqAgfCDCoCstLToob3BlcmF0b3IpCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgIHwgwqAgwqAgKy0tcncgc291cmNlLW9wZXJhdG9yIMKgIMKgIMKg IMKgCj4+Pj4+Pj4gwqAgwqAgb3BlcmF0b3IKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCDCoCArLS1ydyBzb3VyY2UtcG9ydCDCoCDCoCDC oCDCoCDCoCDCoAo+Pj4+Pj4+IMKgIMKgIGluZXQ6cG9ydC1udW1iZXIKPj4+Pj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncKPj4+Pj4+PiAoZGVz dGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06KHJhbmdlKQo+Pj4+Pj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgfCDCoCstLXJ3IGRl c3RpbmF0aW9uLXBvcnQtbG93ZXIgwqAKPj4+Pj4+PiDCoCDCoGluZXQ6cG9ydC1udW1iZXIK Pj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwg wqArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LXVwcGVyIMKgCj4+Pj4+Pj4gwqAgwqBpbmV0OnBv cnQtbnVtYmVyCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKg IMKgIHwgwqArLS06KG9wZXJhdG9yKQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgfCDCoCDCoCB8IMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJhdG9yIMKg IMKgCj4+Pj4+Pj4gwqAgwqBvcGVyYXRvcgo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQgwqAg wqAgwqAgwqAKPj4+Pj4+PiDCoCDCoGluZXQ6cG9ydC1udW1iZXIKPj4+Pj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgaWhsPyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGZsYWdzPyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGJpdHMKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IMKgfCDCoHwgwqAgwqAgKy0tcncgb2Zmc2V0PyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB1aW50MTYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwg wqAgwqAgKy0tcncgaWRlbnRpZmljYXRpb24/IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBk ZXN0aW5hdGlvbi1pcHY0LW5ldHdvcms/IMKgCj4+Pj4+Pj4gaW5ldDppcHY0LXByZWZpeAo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBz b3VyY2UtaXB2NC1uZXR3b3JrPyDCoCDCoCDCoAo+Pj4+Pj4+IMKgaW5ldDppcHY0LXByZWZp eAo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgKy0tOihpcHY2KQo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgICstLXJ3IGlwdjYg e21hdGNoLW9uLWlwdjZ9Pwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgIMKgIMKgIMKgKy0tcncgZHNjcD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAKPj4+Pj4+PiBpbmV0OmRzY3AKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGVjbj8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB1aW50OAo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg IMKgIMKgIMKgKy0tcncgbGVuZ3RoPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1 aW50MTYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oCstLXJ3IHR0bD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncg cHJvdG9jb2w/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4+Pj4+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyAoc291cmNlLXBv cnQtcmFuZ2Utb3Itb3BlcmF0b3IpPwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToocmFuZ2UpCj4+Pj4+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDCoCstLXJ3IHNvdXJjZS1wb3J0 LWxvd2VyIMKgIMKgIMKgCj4+Pj4+Pj4gwqAgwqAgaW5ldDpwb3J0LW51bWJlcgo+Pj4+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoHwgwqArLS1y dyBzb3VyY2UtcG9ydC11cHBlciDCoCDCoCDCoAo+Pj4+Pj4+IMKgIMKgIGluZXQ6cG9ydC1u dW1iZXIKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oHwgwqArLS06KG9wZXJhdG9yKQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBzb3VyY2Utb3BlcmF0b3IgwqAgwqAgwqAg wqAKPj4+Pj4+PiDCoCDCoCBvcGVyYXRvcgo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBzb3VyY2UtcG9ydCDCoCDCoCDC oCDCoCDCoCDCoAo+Pj4+Pj4+IMKgIMKgIGluZXQ6cG9ydC1udW1iZXIKPj4+Pj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3Cj4+Pj4+Pj4gKGRl c3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPwo+Pj4+Pj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToocmFuZ2UpCj4+Pj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDCoCstLXJ3 IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgwqAKPj4+Pj4+PiDCoCDCoGluZXQ6cG9ydC1udW1i ZXIKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwg wqB8IMKgKy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciDCoAo+Pj4+Pj4+IMKgIMKgaW5l dDpwb3J0LW51bWJlcgo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg IMKgIMKgIMKgfCDCoCstLToob3BlcmF0b3IpCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJh dG9yIMKgIMKgCj4+Pj4+Pj4gwqAgwqBvcGVyYXRvcgo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBkZXN0aW5hdGlvbi1w b3J0IMKgIMKgIMKgIMKgCj4+Pj4+Pj4gwqAgwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkZXN0aW5h dGlvbi1pcHY2LW5ldHdvcms/IMKgCj4+Pj4+Pj4gaW5ldDppcHY2LXByZWZpeAo+Pj4+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgc291cmNl LWlwdjYtbmV0d29yaz8gwqAgwqAgwqAKPj4+Pj4+PiDCoGluZXQ6aXB2Ni1wcmVmaXgKPj4+ Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGZs b3ctbGFiZWw/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgCj4+Pj4+Pj4gaW5ldDppcHY2LWZs b3ctbGFiZWwKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgKGw0 KT8KPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToodGNwKQo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IHRjcCB7 bWF0Y2gtb24tdGNwfT8KPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgKy0tcncgc2VxdWVuY2UtbnVtYmVyPyDCoCDCoCDCoCDCoCDCoHVpbnQzMgo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBh Y2tub3dsZWRnZW1lbnQtbnVtYmVyPyDCoCB1aW50MzIKPj4+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgZGF0YS1vZmZzZXQ/IMKgIMKgIMKg IMKgIMKgIMKgIMKgdWludDgKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoHwgwqAgwqAgKy0tcncgcmVzZXJ2ZWQ/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVp bnQ4Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICst LXJ3IGZsYWdzPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJpdHMKPj4+Pj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgd2luZG93LXNp emU/IMKgIMKgIMKgIMKgIMKgIMKgIMKgdWludDE2Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IHVyZ2VudC1wb2ludGVyPyDCoCDCoCDC oCDCoCDCoCB1aW50MTYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgKy0tcncgb3B0aW9ucz8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50 MzIKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToodWRwKQo+ Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IHVkcCB7 bWF0Y2gtb24tdWRwfT8KPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgKy0tcncgbGVuZ3RoPyDCoCB1aW50MTYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoCstLTooaWNtcCkKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoCDCoCArLS1ydyBpY21wIHttYXRjaC1vbi1pY21wfT8KPj4+Pj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/ IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBjb2RlPyDCoCDCoCDCoCDCoCDCoCDCoCB1aW50 OAo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0t cncgcmVzdC1vZi1oZWFkZXI/IMKgIHVpbnQzMgo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqArLS1ydyBlZ3Jlc3MtaW50ZXJmYWNlPyDCoCDCoGlmOmludGVyZmFjZS1y ZWYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgaW5ncmVzcy1p bnRlcmZhY2U/IMKgIGlmOmludGVyZmFjZS1yZWYKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCArLS1ydyBhY3Rpb25zCj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoCstLXJ3IGZvcndhcmRpbmcgwqAgwqBpZGVudGl0eXJlZgo+Pj4+Pj4+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBsb2dnaW5nPyDCoCDCoCDCoGlkZW50aXR5cmVm Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gc3RhdGlzdGljcyB7YWNs LWFnZ3JlZ2F0ZS1zdGF0c30/Cj4+Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4+Pj4+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5 YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+Cj4+Pj4+Pj4gwqAgYXVnbWVudCAvaWY6aW50ZXJmYWNl cy9pZjppbnRlcmZhY2U6Cj4+Pj4+Pj4gwqAgwqAgKy0tcncgYWNscwo+Pj4+Pj4+IMKgIMKg IMKgIMKgKy0tcncgaW5ncmVzcwo+Pj4+Pj4+IMKgIMKgIMKgIMKgfCDCoCstLXJ3IGFjbC1z ZXRzCj4+Pj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+ Pj4+Pj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAg wqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lCj4+Pj4+Pj4gwqAgwqAgwqAgwqB8 IMKgIMKgIMKgIMKgKy0tcncgdHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4gL2FjY2Vzcy1s aXN0cy9hY2wvdHlwZQo+Pj4+Pj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJvIGFj ZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/Cj4+Pj4+Pj4gwqAgwqAg wqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAg LT4KPj4+Pj4+PiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+Pj4+Pj4gwqAg wqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAgeWFu Zzpjb3VudGVyNjQKPj4+Pj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8g bWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+Pj4+PiDCoCDCoCDCoCDC oCstLXJ3IGVncmVzcwo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjbC1zZXRzCj4+ Pj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyBhY2wtc2V0KiBbbmFtZV0KPj4+Pj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKg IMKgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMv YWNsL3R5cGUKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBhY2Utc3Rh dGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+Pj4+Pj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+ Pj4+Pj4+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUKPj4+Pj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAgeWFuZzpj b3VudGVyNjQKPj4+Pj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG1h dGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4+Pj4KPj4+Pj4+PiBDb21t ZW50cyB3ZWxjb21lIQo+Pj4+Pj4+Cj4+Pj4+Pj4gQ2hlZXJzLAo+Pj4+Pj4+Cj4+Pj4+Pj4g RWluYXIKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4KPj4+Pj4+Pj4gT24gMTQgRGVjIDIwMTcs IGF0IDE4OjUwLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikKPj4+Pj4+Pj4gPGVp bmFybm5AY2lzY28uY29tIDxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToKPj4+ Pj4+Pj4KPj4+Pj4+Pj4KPj4+Pj4+Pj4KPj4+Pj4+Pj4+IE9uIDE0IERlYyAyMDE3LCBhdCAw ODoyMSwgU29uYWwgQWdhcndhbCA8c2FnYXJ3YWwxMkBnbWFpbC5jb20KPj4+Pj4+Pj4+IDxt YWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20+PiB3cm90ZToKPj4+Pj4+Pj4+Cj4+Pj4+Pj4+ PiBIaSBFaW5hciwKPj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBZb3UgaGFkIDMgcXVlc3Rpb25zIGZv ciBtZSBvbiBhbGwgdGhlIHNldmVyYWwgZS1tYWlsIHRocmVhZHMuwqAKPj4+Pj4+Pj4+IDEu IEdsb2JhbCBhdHRhY2htZW50IHBvaW50Cj4+Pj4+Pj4+PiAyLiBpY21wLW9mZgo+Pj4+Pj4+ Pj4gMy4gYWNsLWFnZ3JlZ2F0ZS1pbnRlcmZhY2Ugc3RhdHMuCj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4gRm9yICgxKSwgbXkgZmlyc3QgcHJlZmVyZW5jZSBpcyB0byBoYXZlIHRoZSBtb2RlbCBk ZWZpbmUKPj4+Pj4+Pj4+IGF0dGFjaG1lbnQgcG9pbnQgZm9yIGludGVyZmFjZXMgb25seS4K Pj4+Pj4+Pj4KPj4+Pj4+Pj4gZWluYXJubj4gSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVyZWQg b24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8KPj4+Pj4+Pj4gbmV0bW9kLXdnL2FjbC1tb2Rl bCB0aGF0IGRvIHRoaXMuIE5lYXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24KPj4+Pj4+Pj4g SSBoYXZlIGJlbG93LiBGZWVsIGZyZWUgdG8gdGFrZSBhIGxvb2sgYXQ6Cj4+Pj4+Pj4+Cj4+ Pj4+Pj4+ICAgICBodHRwczovL2dpdGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9kZWwv cHVsbC8zCj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBIb3dldmVyLCBLcmlzdGlhbiB3 YW50cyB0aGUgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQgYXMgd2VsbCBzbwo+Pj4+Pj4+Pj4g dGhhdCBoZSBjYW4gYWRkIHRoZSBBQ0wgdG8gdGhlIGxpbnV4IHRhYmxlcy4KPj4+Pj4+Pj4K Pj4+Pj4+Pj4gZWluYXJubj4gSSB0aGluayBLcmlzdGlhbiBkb2VzbuKAmXQgZmVlbCBhIGds b2JhbCBhdHRhY2htZW50Cj4+Pj4+Pj4+IHBvaW50IG5lZWRzIHRvIGJlIGluIHRoaXMgZmly c3QgcmV2aXNpb24uIEJ1dCBoZSBjYW4gY29uZmlybS4KPj4+Pj4+Pj4KPj4+Pj4+Pj4+IElm IGFuIEFDTCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9lcyB0aGlzIG1lYW4gaXQgaXMgcGVy Cj4+Pj4+Pj4+PiBkaXJlY3Rpb24gb3IgZG9lcyBpdCBtZWFuIGl0IGlzIGFjcm9zcyBkaXJl Y3Rpb25zPwo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBlaW5hcm5uPiBJIGRvbuKAmXQga25vdyByaWdo dCBub3cgOi0pCj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBUaGlzIGdsb2JhbCBBQ0wgbWF5IG5vdCBi ZSBhcHBsaWNhYmxlIHRvIGFueSBvZiBDaXNjbydzCj4+Pj4+Pj4+PiBzZXJ2aWNlIHByb3Zp ZGVyIHJvdXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFjdHVhbGx5Cj4+Pj4+ Pj4+PiByZXBsaWNhdGluZyB0aGUgQUNMIHRvIGFsbCBsaW5lIGNhcmRzIGFuZCBhdHRhY2hp bmcgaXQgaW4KPj4+Pj4+Pj4+IGluZ3Jlc3MgYW5kIGVncmVzcyBkaXJlY3Rpb25zIGFjcm9z cyBhbGwgaW50ZXJmYWNlcy4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gZWluYXJubj4gUGVyIG90aGVy IGVtYWlscywgSSBkb27igJl0IHRoaW5rIHdlIHVuZGVyc3RhbmQgdGhpcwo+Pj4+Pj4+PiBl bm91Z2ggeWV0IHRvIHNwZWNpZnkgaXQsIHNvIEkgc3VnZ2VzdCB3ZSBqdXN0IGxlYXZlIGl0 IG91dCBmb3IKPj4+Pj4+Pj4gbm93LiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50cyBh IOKAnGdsb2JhbCBhdHRhY2htZW50IHBvaW504oCdCj4+Pj4+Pj4+IGJlaW5nIGFkZGVkIGxh dGVyIG9uY2Ugd2UgdW5kZXJzdGFuZCB3aGF0IGl0IHJlYWxseSBtZWFucy4KPj4+Pj4+Pj4K Pj4+Pj4+Pj4+IEZvciAoMiksIEkgYW0gb2sgd2l0aCByZW1vdmluZyBpY21wLW9mZi4KPj4+ Pj4+Pj4KPj4+Pj4+Pj4gZWluYXJubj4gRG9uZSBpbiBteSBQUiBhYm92ZS4KPj4+Pj4+Pj4K Pj4+Pj4+Pj4+IEZvciAoMyksIHRoaXMgd291bGQgaGF2ZSB0byBiZSBhIGNvbWJpbmF0aW9u IG9mIEFDTCBzdGF0cwo+Pj4+Pj4+Pj4gYWNyb3NzIGFsbCBpbnRlcmZhY2VzIGZvciBhbGwg QUNMJ3MuIFNvbWV0aGluZyBsaWtlIHRoaXMgaXMKPj4+Pj4+Pj4+IHBvc3NpYmxlIG9uIGFu IFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3NvY2lhdGVkCj4+Pj4+ Pj4+PiB3aXRoIGl0LiBMZXQncyBjaGF0IGFib3V0IHRoaXMgb2ZmbGluZSB0b21vcnJvdy4K Pj4+Pj4+Pj4KPj4+Pj4+Pj4gZWluYXJubj4gSeKAmWxsIHBpbmcgeW91IHRvIGNsYXJpZnks IGFuZCB3ZSBjYW4gYnJpbmcgYW55Cj4+Pj4+Pj4+IGNvbmNsdXNpb24gYmFjayB0byB0aGUg bGlzdC4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gQ2hlZXJzLAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBFaW5h cgo+Pj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gU29uYWwuCj4+Pj4+Pj4+ Pgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBN LCBNYWhlc2ggSmV0aGFuYW5kYW5pCj4+Pj4+Pj4+PiA8bWpldGhhbmFuZGFuaUBnbWFpbC5j b20gPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOgo+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+ICAgICBXZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1l bnQgcG9pbnQgZG93biB0aGUKPj4+Pj4+Pj4+ICAgICBsaW5lLCBhbmQgdGhhdCDigJxnbG9i YWzigJ0gYXR0YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZgo+Pj4+Pj4+Pj4gICAgIHRo ZSBjaG9pY2VzICh0aGUgb3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQgd291bGQK Pj4+Pj4+Pj4+ICAgICB0aGlzIGF1Z21lbnQgbG9vayBsaWtlLiBOb3RlLCBhcyBmYXIgYXMg SSBrbm93LCB5b3UgY2Fubm90Cj4+Pj4+Pj4+PiAgICAgYXVnbWVudCBpbnNpZGUgYSBjaG9p Y2Ugbm9kZS4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gICAgIE9uIERlYyAxMywgMjAxNywgYXQg Njo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQKPj4+Pj4+Pj4+PiAgICAgKGVpbmFybm4p IDxlaW5hcm5uQGNpc2NvLmNvbSA8bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4KPj4+Pj4+ Pj4+PiAgICAgd3JvdGU6Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiAgICAgUGVyaGFwcyBsaWtl IHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOgo+Pj4+Pj4+Pj4+ Cj4+Pj4+Pj4+Pj4gICAgICAgICDCoCBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVy ZmFjZToKPj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgICstLXJ3IGluZ3Jlc3MtYWNscwo+Pj4+ Pj4+Pj4+ICAgICAgICAgwqAgwqAgfCDCoCstLXJ3IGFjbC1zZXRzCj4+Pj4+Pj4+Pj4gICAg ICAgICDCoCDCoCB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+Pj4+Pj4+ICAg ICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAg wqAtPgo+Pj4+Pj4+Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4+Pj4+ Pj4+ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKg IMKgIMKgIC0+Cj4+Pj4+Pj4+Pj4gICAgICAgICAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+ Pj4+Pj4+Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcm8gYWNlLXN0YXRpc3Rp Y3MqIFtuYW1lXQo+Pj4+Pj4+Pj4+ICAgICAgICAge2ludGVyZmFjZS1zdGF0c30/Cj4+Pj4+ Pj4+Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAg wqAgwqAgwqAgwqAgwqAgLT4KPj4+Pj4+Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNs L2FjZXMvYWNlL25hbWUKPj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIHwgwqAgwqAgwqAgwqAg wqAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+Pj4+ ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLW9jdGV0cz8g wqAgwqB5YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgKy0tcncgZWdy ZXNzLWFjbHMKPj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNldHMK Pj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1l XQo+Pj4+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyBuYW1lIMKg IMKgIMKgIMKgIMKgIMKgIMKgLT4KPj4+Pj4+Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMv YWNsL25hbWUKPj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcncg dHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+Pj4+Pj4+PiAgICAgICAgIC9hY2Nlc3Mt bGlzdHMvYWNsL3R5cGUKPj4+Pj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Ky0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXQo+Pj4+Pj4+Pj4+ICAgICAgICAge2ludGVy ZmFjZS1zdGF0c30/Cj4+Pj4+Pj4+Pj4gICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCArLS1ybyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0+Cj4+Pj4+Pj4+Pj4gICAgICAg ICAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+Pj4+Pj4+Pj4gICAgICAgICDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6 Y291bnRlcjY0Cj4+Pj4+Pj4+Pj4gICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAr LS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiAgICAgQ291bGQgYWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBj b250YWluZXIgYWJvdmUgYm90aCB0aGVzZSAmCj4+Pj4+Pj4+Pj4gICAgIHJlbmFtZSDigJxp bmdyZXNzLWFjbHMiIHRvIOKAnGluZ3Jlc3PigJ0sIGV0Yy4gdG8gZ2l2ZSBhIHNpbmdsZQo+ Pj4+Pj4+Pj4+ICAgICByb290IGZvciB0aGUgYXVnbWVudGF0aW9uIGlmIHByZWZlcnJlZC4K Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ICAgICBDaGVlcnMsCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+ PiAgICAgRWluYXIKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+ICAgICBPbiA2 IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20KPj4+Pj4+ Pj4+Pj4gICAgIDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToKPj4+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gICAgIE9uIDEyLzYvMTcgNzoy MyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPj4+Pj4+Pj4+Pj4+ICAgICBIb3cg ZG9lcyBvbmUgbW92ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsCj4+Pj4+Pj4+ Pj4+PiAgICAgY3VycmVudGx5IGFuCj4+Pj4+Pj4+Pj4+PiAgICAgJ2ludGVyZmFjZS1yZWYn LCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlCj4+Pj4+Pj4+Pj4+PiAgICAgaWY6aW50ZXJm YWNlcy9pbnRlcmZhY2UsCj4+Pj4+Pj4+Pj4+PiAgICAgaW5zaWRlIG9mIHRoZSDigJhhY2zi gJkgwqBjb250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQKPj4+Pj4+Pj4+Pj4+ICAg ICBuZWVkIHRvIGhhdmUgYW4KPj4+Pj4+Pj4+Pj4+ICAgICBjb250YWluZXIgZm9yICJhdHRh Y2htZW50IHBvaW50cyIgdG8gYWNjb21tb2RhdGUgdGhlCj4+Pj4+Pj4+Pj4+PiAgICAgcG9z c2liaWxpdHkgb2YKPj4+Pj4+Pj4+Pj4+ICAgICBhdHRhY2hpbmcgYW4gQUNMIGVpdGhlciB0 byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uCj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+Pgo+Pj4+Pj4+Pj4+PiAgICAgS2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0 aGF0IGFuIEFDTCBkb2Vzbid0Cj4+Pj4+Pj4+Pj4+ICAgICBhdHRhY2ggdG8gYW4KPj4+Pj4+ Pj4+Pj4gICAgIGludGVyZmFjZSBhdCBhbGwuCj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+ICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+ Pj4+Pj4+PiAgICAgbmV0bW9kIG1haWxpbmcgbGlzdAo+Pj4+Pj4+Pj4+PiAgICAgbmV0bW9k QGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+Pj4+Pj4+Pj4+PiAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPj4+Pj4+Pj4+Pj4g ICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZD4KPj4+ Pj4+Pj4+Pgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+ICAgICBNYWhlc2ggSmV0aGFuYW5kYW5pCj4+ Pj4+Pj4+PiAgICAgbWpldGhhbmFuZGFuaUBnbWFpbC5jb20gPG1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbT4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Pj4+PiAg ICAgbmV0bW9kIG1haWxpbmcgbGlzdAo+Pj4+Pj4+Pj4gICAgIG5ldG1vZEBpZXRmLm9yZyA8 bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KPj4+Pj4+Pj4+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Pj4+Pj4gICAgIDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZD4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+ Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+Pj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+IG5l dG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KPj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPj4+Pj4+Pgo+Pj4+Pj4+ Cj4+Pj4+Pj4KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+Pj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4+Pj4+PiBuZXRtb2RA aWV0Zi5vcmcKPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo+Pj4+Pj4KPj4+Pj4KPj4+Pgo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+Pj4+ IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4KPj4+IE1haGVzaCBK ZXRoYW5hbmRhbmkKPj4+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhh bmFuZGFuaUBnbWFpbC5jb20+Cj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+ Pj4gbmV0bW9kQGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo+Pgo+Cj4gTWFoZXNoIEpldGhhbmFuZGFuaQo+IG1qZXRoYW5hbmRh bmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Cj4KCg== --------------3F537B3F27FFC5DFDD92E390 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ok.=C2=A0 What is left to agree on at this point?

Thanks Mahesh,

Eliot


On 11.01.18 02:21, Mahesh Jethanandani= wrote:
Hi Einar,

I can work on updating the draft as soon as we agre= e on the changes. Should take only a couple of days to turn around and publish the draft.

On Jan 9, 2018, at 11:35 PM, Eliot Lear <<= a href=3D"mailto:lear@cisco.com" class=3D"" moz-do-not-send=3D"true">lear@cisco.com> wrote:

Hi Mahesh,

Thanks for this work.=C2=A0 I think this is= okay.=C2=A0 In the case of MUD we simply won't have the= other container.=C2=A0 Can I please ask that you get th= e draft out quickly as draft-ietf-opsawg-mud has been waiting quite some time for this work to complete.

Eliot


On 10.01.18 04:08, Mahesh Jethanandani wrote:
I have pulled in the changes as they relate= to:

- moving =E2=80=9Cinterface-acl=E2=80=9D= under the container =E2=80=9Cattachment-points=E2=80=9D making = it local to that container.
- reverting =E2=80=9Cacl-type=E2=80=9D = to =E2=80=9Ctype=E2=80=9D
- removed =E2=80=9Cinterface-all-aggreg= ate=E2=80=9D feature
- simplified source port and destinatio= n port definition

The pull request for the changes can be= found here.

https://github.= com/netmod-wg/acl-model/pull/20

After discussing with some of the original contributors, decided not to include the change as it relates to augmenting ietf-interfaces. We did not find that the change had a particular advantage over the current implementation. Even if we do not completely understand how ACLs might be attached =E2=80=9Cglobally=E2=80=9D or on something t= hat is not an interface, having the flexibility to attach them to other attachment points is important. Keeping it as interface-ref gives us that flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, Elio= t Lear <lear@cisc= o.com> wrote:

So long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
Eliot,

Nothing can force an implementation to have to implement either the=C2=A0ietf-interfaces model or = the augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment over time. I=E2=80=99ve adde b= ack in use of the =E2=80=9Cinterface-attachment=E2= =80=9D feature (which I took out as part of refactoring interface attachment). Part of:

h= ttps://github.com/netmod-wg/acl-model/pull/21

The augments part of the tree now looks like:

=C2=A0 augment /if:interfaces/if:interface:
=C2=A0 =C2=A0 +--rw = acls {interface-atta= chment}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0+--rw ingress
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0+--rw acl-sets
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0-> /access-lists/acl/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -> /access-lists/acl/type
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics* [name] {interface-stats}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets? =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets? =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0+--rw egress
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--rw acl-sets
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0-> /access-lists/acl/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -> /access-lists/acl/type
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro ace-statistics* [name] {interface-stats}?
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/ace/name
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-packets? =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro matched-octets? =C2=A0 =C2=A0yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:

Einar,

I think this change= is fine, with one exception.=C2= =A0 I would rather the augment to the interface not be required for implementations that don't actually have interfaces.=C2=A0= I understand that there may be two ways to go about this:

  1. Separate out the= augment into a separate module (same doc is fine); or
  2. Somehow "feature-ize" the augment.

I don't know how to= do (2) but if you do, that's okay by me.

Eliot


On= 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
All,

=
After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR here:

=
= https://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to Mahesh=E2=80= =99s PR are:

  • Moved interface attachment to be via an interface augmentation.
  • Restructur= ed port matches slightly under both IPv4 and IPv6 containers.
  • Removed unnecessary identity 'interface-acl-aggregat= e=E2=80=99.
  • Removed action =E2=80=98icmp-of= f=E2=80=99, can be augmented later.

For reference= , here is the current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs:

13:12 = $ pyang --ietf --lint -f tree ietf-access-control-lis= t.yang
ietf-a= ccess-control-list.yang:51: error: bad value "YYYY-MM-DD" (should be date)
module= : ietf-access-control-list
=C2=A0= =C2=A0 +--rw access-lists
=C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw acl* [name]=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0= =C2=A0string
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type? =C2=A0= acl-type
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw aces
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--= rw ace* [name]
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0str= ing
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw matches
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw (l2)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(eth)<= /div>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 +--rw eth {match-on-eth}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw destination-mac-address= ? =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:mac-address<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw destination-mac-address= -mask? =C2=A0 yang:mac-address=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw source-mac-address? =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 yang:mac-address=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw source-mac-address-mask= ? =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:mac-address<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ethertype? = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eth:ethertype
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw (l3)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(ipv4)=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0+--rw ipv4 {match-on-ipv4}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw dscp? =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:dscp
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw ecn? =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw length? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw ttl? =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw protocol? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw (source-port-range-or-o= perator)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0+--:(range)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--rw source-port-lower =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 in= et:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--rw source-port-upper =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 in= et:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0+--:(operator)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw source-operator =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 op= erator
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw sou= rce-port =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:port-number=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw (destination-port-range= -or-operator)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0+--:(range)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--rw destination-port-lower =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0| =C2=A0+--rw destination-port-upper =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0+--:(operator)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw destination-operator =C2= =A0 =C2=A0 =C2=A0 =C2=A0ope= rator
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw destination-port =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw ihl? =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw flags? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0bits
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw offset? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw identification? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw destination-ipv4-networ= k? =C2=A0 inet:ipv4-prefix=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw source-ipv4-network? =C2= =A0 =C2=A0 =C2=A0 =C2=A0ine= t:ipv4-prefix
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(ipv6)=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 +--rw ipv6 {match-on-ipv6}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw dscp? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:dscp
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ecn? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw length? =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ttl? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw protocol? =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw (source-port-range-or-o= perator)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--:(range)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0+--rw source-port-lower =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 in= et:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0+--rw source-port-upper =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 in= et:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--:(operator)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw source-operator =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 op= erator
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw sou= rce-port =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:port-number=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw (destination-port-range= -or-operator)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--:(range)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0+--rw destination-port-lower =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0+--rw destination-port-upper =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--:(operator)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw destination-operator =C2= =A0 =C2=A0 =C2=A0 =C2=A0ope= rator
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw destination-port =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ine= t:port-number
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw destination-ipv6-networ= k? =C2=A0 inet:ipv6-prefix=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw source-ipv6-network? =C2= =A0 =C2=A0 =C2=A0 =C2=A0ine= t:ipv6-prefix
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw flow-label?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:ipv6-flow-label
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw (l4)?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(tcp)<= /div>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0+--rw tcp {match-on-tcp}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw sequence-number? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint32
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw acknowledgement-number?= =C2=A0 uint32
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw data-offset? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw reserved? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw flags? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0bits
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw window-size? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw urgent-pointer? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uint16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw options? =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint32
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(udp)<= /div>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0+--rw udp {match-on-udp}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 +--rw length? =C2=A0 ui= nt16
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0+--:(icmp)=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 +--rw icmp {match-on-icmp}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw code? =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rest-of-hea= der? =C2=A0 uint32
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw egress-interface? =C2=A0= =C2=A0if:interface-ref<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw ingress-interface? =C2=A0= if:interface-ref=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw actions
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw forwarding =C2=A0 =C2=A0identityref
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0+--rw logging? =C2=A0 =C2=A0 =C2=A0identityref
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--ro statistics {acl-aggregate-stats}?<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--ro matched-packets? =C2=A0= yang:counter64
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--ro matched-octets? =C2=A0 =C2=A0yang:counter64

=C2=A0= augment /if:interfaces/if:inter= face:
=C2=A0= =C2=A0 +--rw acls
=
=C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw ingress
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0+--rw acl= -sets
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 += --rw acl-set* [name]
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-> /access-lists/acl/name<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--rw type? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/acl/type<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--ro ace-statistics* [name] {interface-stats}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--ro name =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/= ace/name
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--ro matched-packets? =C2=A0= yang:counter64
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--ro matched-octets? =C2=A0 =C2=A0yang:counter64
=C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw egress
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw acl-sets
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--= rw acl-set* [name]
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-> /access-lists/acl/name<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -> /access-lists/acl/type<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--ro ace-statistics* [name] {interface-stats}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/aces/= ace/name
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--ro matched-packets? =C2=A0= yang:counter64
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--ro matched-octets? =C2=A0 =C2=A0yang:counter64

Comments welcome!

Cheers,

Einar
=



On 14 Dec= 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:



O= n 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Einar,

You had 3 questions for me on all the several e-mail threads.=C2=A0<= /div>
1. Global attachment point
2. icmp-off
3. acl-aggregate-interface stats.

For (1), my first preference is to have the model define attachment point for interfaces only.
ein= arnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to netmod-wg/acl-mod= el that do this. Nearly like the augmentation I have below. Feel free to take a look at:
https://github.com/mjethanandani/acl-model/pull/3
<= br class=3D"">
However, Kristian wants the global attachment point as well so that he can add the ACL to the linux tables.
ein= arnn> I think Kristian doesn=E2=80=99t f= eel a global attachment point needs to be in this first revision. But he can confirm.
If an ACL is attached globally, does this mean it is per direction or does it mean it is across directions?
ein= arnn> I don=E2=80=99t k= now right now :-)
This global ACL may not be applicable to any of Cisco's service provider routers as I don't see any platform actually replicating the ACL to all line cards and attaching it in ingress and egress directions across all interfaces.
ein= arnn> Per other emails, I don=E2=80= =99t think we understand this enough yet to specify it, so I suggest we just leave it out for now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80=9D be= ing added later once we understand what it really means.

For (2), I am ok with removing icmp-off.
=
ein= arnn> Done in my PR above.

For (3), this would have to be a combination of ACL stats across all interfaces for all ACL's. Something like this is possible on an XR box where ACES have counter names associated with it. Let's chat about this offline tomorrow.
=
ein= arnn> I=E2=80=99ll ping= you to clarify, and we can bring any conclusion back to the list.
C= heers,
<= br class=3D"">
E= inar
<= br class=3D"">
<= br class=3D"">

Sonal.


On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <= ;mjethanandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal= =E2=80=9D attachment point down the line, and that =E2=80=9Cglobal= =E2=80=9D attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.
On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <<= a href=3D"mailto:einarnn@cisco.com" target=3D"_blank" class=3D"" moz-do-not-send= =3D"true">einarnn@cisco.com> wrote:

Perh= aps like this, as an augmentation to the interface:

=C2=A0 augment /if:interfaces/= if:interface:
=C2=A0 =C2=A0 +--rw ingress-acls
=C2=A0 =C2=A0 | =C2=A0= +--rw acl-sets=
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw nam= e =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/a= cl/name
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw typ= e? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/type
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics*= [name] {interface-stat= s}?
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/aces/ace/name=
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets= ? =C2=A0 yang:counter64<= /font>
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets?= =C2=A0 =C2=A0yang:coun= ter64
=C2=A0 =C2=A0 +--rw egress-acls
=C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw acl-sets=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw acl-set* [name]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw nam= e =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> /access-lists/a= cl/name
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--rw typ= e? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/type
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--ro ace-statistics*= [name] {interface-stat= s}?
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -> /access-lists/a= cl/aces/ace/name=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-packets= ? =C2=A0 yang:counter64<= /font>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matched-octets?= =C2=A0 =C2=A0yang:coun= ter64

Could also put an =E2=80=9Caces=E2= =80=9D container above both these & rename =E2=80=9Cingres= s-acls" to =E2=80=9Cing= ress=E2=80=9D, etc. to give a single root for the augmentation if preferred.

Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com&= gt; wrote:



= On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently an 'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2= =80=99 =C2=A0container= ? Down the line we might need to have an
container for "attachment points" to accommodate the possibility of<= br class=3D""> attaching an ACL either to an interface or =E2=80=9Cglo= bally=E2=80=9D.

=

= Keeping in mind that one use is that an ACL doesn't attach to an interface at all.

= _______________________________________________
netmod mailing list
netmod@ietf.org=
https://www.ietf.or= g/mailman/list= info/netmod

=

=
Mahesh Jethanandani
mjethanandani@gmail.com

= <= /div>

= _______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/list= info/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/lis=
tinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org<= br class=3D""> https://www.ietf.org= /mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.co= m



_____________________________=
__________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/netmod


Mahesh Jethanandani
mjethanandani@gmail.com=


--------------3F537B3F27FFC5DFDD92E390-- --J7TI0on49WEEtibdc4GqEf4iR36SwtPQs-- --NDjgprMq7aMndfRVLV9dHQ9l6kHeXjgH4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpY1ckACgkQh7ZrRtnS ejM3GAf+O7MQPR8G/ZYi1XJSQ4HJIQiSvIrzW9FDyJviF2Ce44u7XcvP+nl839DH ilveUycDF1UP4QEjHfP0IaqW64iBmE6IGm0lZuv+XtwI0iSp6uCZ3m2iIckYxVws NyEn89SksjUmlQO5g4zbFI/gpggk0SnDxgU0e3exWbhm4gl3mO8wnvXbSa5+QS3O MHbthEjb8/3JLEZS+yt1EKjv8jPuQiUhL92Oc9uaTQExabvwQIcW4kx3NZ3S84Q3 mN+r40CcygpZD9wlpxkKmO+NG/wecGAF7uqDm3d+gkkLrP+/X7WGU7p0kSt6+o9a lbE9/fAnUo4Zo0JxLtwEJ0KJ1kSHZA== =88/g -----END PGP SIGNATURE----- --NDjgprMq7aMndfRVLV9dHQ9l6kHeXjgH4-- From nobody Fri Jan 12 08:00: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 E98A612420B; Fri, 12 Jan 2018 08:00:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 k7U96csx3JUn; Fri, 12 Jan 2018 08:00:25 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F61312E8B1; Fri, 12 Jan 2018 08:00:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 01184ED4; Fri, 12 Jan 2018 17:00:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id STjdWCcwZZfy; Fri, 12 Jan 2018 17:00:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 12 Jan 2018 17:00:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D245D2013F; Fri, 12 Jan 2018 17:00:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SwWT3Sv0iHPD; Fri, 12 Jan 2018 17:00:23 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8ED42013E; Fri, 12 Jan 2018 17:00:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AD079420DEF3; Fri, 12 Jan 2018 17:00:21 +0100 (CET) Date: Fri, 12 Jan 2018 17:00:20 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Cc: The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Message-ID: <20180112160020.ovnu3xtns5y325ug@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> <20180112094500.ymlrkswjfgkhibef@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 16:00:28 -0000 On Fri, Jan 12, 2018 at 09:23:28AM -0500, Kathleen Moriarty wrote: > Hi Juergen, > > On Fri, Jan 12, 2018 at 4:45 AM, Juergen Schoenwaelder > wrote: > > On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen Moriarty wrote: > >> Hi Juergen, > >> > >> Thank you very much for the additional information. This was very > >> helpful. Benoit and I discussed it a bit further on the telechat and > >> some text changes in the introduction and security considerations > >> section to provide some of this information for the reader will be > >> helpful. I got the explanations and appreciate them and from the > >> explanations, my discuss questions have been answered and I'll switch > >> this to a no objection leaving you and Benoit to add the text as > >> helpful for other readers. > >> > > > > Kathleen, > > > > we propose to add this text to the security considerations: > > > > The origin metadata annotation exposes the origin of values in the > > applied configuration. Origin information may provide hints that > > certain control plane protocols are active on a device. Since origin > > information is tied to applied configuration values, it is only > > accessible to clients that have the permissions to read the applied > > configuration values. Security administrators should consider the > > sensitivity of origin information while defining access control > > rules. > > Thank you, that is very helpful. Would it also be possible to add > text in the introduction on where the data for these values comes from > (the device itself)? The Introduction does not really talk about the origin annotation details and hence it seems such text would be misplaced or at least confusing to read. The definition of origin is in section 5.3.4. This section starts with: As configuration flows into , it is conceptually marked with a metadata annotation ([RFC7952]) that indicates its origin. Since the whole data flow between datastores resides on a 'device', it seems clear that the origin values are added by the device itself. And if any clarification is needed, I think it belongs into 5.3.4 and not into the Introduction. /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 Jan 12 09:52: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 2114F12D7F5; Fri, 12 Jan 2018 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 3D6slLm46stq; Fri, 12 Jan 2018 09:52:15 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 1FF1B12D778; Fri, 12 Jan 2018 09:52:14 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id j4so5036661pgp.1; Fri, 12 Jan 2018 09:52:14 -0800 (PST) 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; bh=9QLSQv/TiRntjSnq2coLicino+CMhgNXOjiAS4hxkIY=; b=Qla/HOP9G79F0wrsgt3YTn5N1MJLmCDvXIJbpD6o7wc6w9JOrxkxsMAdxuT2DTx4Ew 10kG0MSP/aZ8U4C37wjRwrj+AKSP962f+mecJnIXG2BAyFl0c2duJEKaRSlXilS6ax26 5UnWMeIoTi1geps8WHBMxs4kn3OV+vt7gib3FvOOjb4Dc9cnrJ1U3vJOIuOa0YbUqYyk qBKIUI9VJ+Jjrib8txuu6JK/ZX5CiCyLFWJUgMa62zlx1EJGPl6b6fxFkQF7DlySTohr Nv+N/WSeD5cJlxsdm6uJfnd0OqzPPcbz96XTfyg+ThYLPfZhd3tdK/V+WDI3kbli5N17 2SrQ== 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=9QLSQv/TiRntjSnq2coLicino+CMhgNXOjiAS4hxkIY=; b=ic9jOJOKw7Afa9JxtFyYRKBziTor37zSEODHFFzAFh0NCQC4/McOhd25UsmvY/T5oF flEhAemvv4FX/6VJ28YmSoz1XYmikf1dKbEZ53dOX5h0Jt6VtNFaX8HQKxKYcXszVgPe lCRxxPGceOkWGsPo57Gg80Nt+t2gTnNDLvffsFLZVjvkWS8V8QDgh/e6Iahia9IJk4BM dykWNKYYrxrHgxl+GXuskvDQStaVO00CuiQQVJF379ni8HmDW94XMrRECjMEyHn+NdW6 CLc/4cRd0Npj5Lxqfy67pv39kitMyd3lY3sTM+8po00IkYARSbCj0kqNIvCQXL7m9+41 /5kA== X-Gm-Message-State: AKGB3mKbAwPpZmjrIWG9QS4yPOwqNDXF1BcUXRHNalJVCpvb5/4Jq9sm hSlDonGoXorbskRvErFUz5SFlW4cOC+Lf1aSFEM= X-Google-Smtp-Source: ACJfBouodVCfdjbSxNHMbLUajsO51rlsr/de9HZ0wXMG8xfb+iXTOtp9eMlmsNOiaaxwJyPY5Wf+iM/DWL5OsTLeFzM= X-Received: by 10.98.138.3 with SMTP id y3mr24278951pfd.132.1515779534586; Fri, 12 Jan 2018 09:52:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 12 Jan 2018 09:51:34 -0800 (PST) In-Reply-To: <20180112160020.ovnu3xtns5y325ug@elstar.local> References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> <20180112094500.ymlrkswjfgkhibef@elstar.local> <20180112160020.ovnu3xtns5y325ug@elstar.local> From: Kathleen Moriarty Date: Fri, 12 Jan 2018 12:51:34 -0500 Message-ID: To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 17:52:17 -0000 On Fri, Jan 12, 2018 at 11:00 AM, Juergen Schoenwaelder wrote: > On Fri, Jan 12, 2018 at 09:23:28AM -0500, Kathleen Moriarty wrote: >> Hi Juergen, >> >> On Fri, Jan 12, 2018 at 4:45 AM, Juergen Schoenwaelder >> wrote: >> > On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen Moriarty wrote: >> >> Hi Juergen, >> >> >> >> Thank you very much for the additional information. This was very >> >> helpful. Benoit and I discussed it a bit further on the telechat and >> >> some text changes in the introduction and security considerations >> >> section to provide some of this information for the reader will be >> >> helpful. I got the explanations and appreciate them and from the >> >> explanations, my discuss questions have been answered and I'll switch >> >> this to a no objection leaving you and Benoit to add the text as >> >> helpful for other readers. >> >> >> > >> > Kathleen, >> > >> > we propose to add this text to the security considerations: >> > >> > The origin metadata annotation exposes the origin of values in the >> > applied configuration. Origin information may provide hints that >> > certain control plane protocols are active on a device. Since origin >> > information is tied to applied configuration values, it is only >> > accessible to clients that have the permissions to read the applied >> > configuration values. Security administrators should consider the >> > sensitivity of origin information while defining access control >> > rules. >> >> Thank you, that is very helpful. Would it also be possible to add >> text in the introduction on where the data for these values comes from >> (the device itself)? > > The Introduction does not really talk about the origin annotation > details and hence it seems such text would be misplaced or at least > confusing to read. The definition of origin is in section 5.3.4. This > section starts with: > > As configuration flows into , it is conceptually marked > with a metadata annotation ([RFC7952]) that indicates its origin. > > Since the whole data flow between datastores resides on a 'device', it > seems clear that the origin values are added by the device itself. And > if any clarification is needed, I think it belongs into 5.3.4 and not > into the Introduction. That sounds good, thank you. Kathleen > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Best regards, Kathleen From nobody Fri Jan 12 10:47:25 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 BAD7B126D0C; Fri, 12 Jan 2018 10:47:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-netmod-rfc7223bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151578284375.18659.4642982402668057343.idtracker@ietfa.amsl.com> Date: Fri, 12 Jan 2018 10:47:23 -0800 Archived-At: Subject: [netmod] Kathleen Moriarty's No Objection on draft-ietf-netmod-rfc7223bis-03: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 18:47:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netmod-rfc7223bis-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for applying the updated security considerations template. From nobody Fri Jan 12 10:56: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 924FE128D2E for ; Fri, 12 Jan 2018 10:56:04 -0800 (PST) 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_RP_MATCHES_RCVD=-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 c8bR-9981xBT for ; Fri, 12 Jan 2018 10:56:00 -0800 (PST) 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 886AA126D0C for ; Fri, 12 Jan 2018 10:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40647; q=dns/txt; s=iport; t=1515783359; x=1516992959; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=JhxTO5W2xQs9IetLQu/vWaX8kiN4qdoApjOtpL9mNoI=; b=Agwy/WG5awSqCVKHHuvwNAi3P70sETXyJ1wAUKIP34yDq21D4MbpCLom yq+pKz4z81s+FSe57xL9oWU7ZqwzgUPe1RNLG8lvyvFa13Q9X/+5pN7dv Zhca3v8+B9qqQO/bMHRMH9i0MEkGeycXYW7zln4k6KK6MQ0Zb9ieDwkyk k=; X-IronPort-AV: E=Sophos;i="5.46,350,1511827200"; d="scan'208,217";a="1377247" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 18:55:57 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0CItv1B006176; Fri, 12 Jan 2018 18:55:57 GMT To: Joe Clarke , "Einar Nilsen-Nygaard (einarnn)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Martin Bjorklund , "bart.bogaert@nokia.com" Cc: "netmod@ietf.org" References: <20180109.163933.49682684192910889.mbj@tail-f.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> <823fdeb7-3b4b-2504-364d-ef68502adccf@cisco.com> From: Benoit Claise Message-ID: <64740fb9-7f4c-59ee-ecd2-4474ae5deb77@cisco.com> Date: Fri, 12 Jan 2018 19:55:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <823fdeb7-3b4b-2504-364d-ef68502adccf@cisco.com> Content-Type: multipart/alternative; boundary="------------2471BAC3EEA934B9A4AC988A" Content-Language: en-US Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 18:56:05 -0000 This is a multi-part message in MIME format. --------------2471BAC3EEA934B9A4AC988A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/12/2018 2:33 PM, Joe Clarke wrote: > On 1/12/18 05:52, Einar Nilsen-Nygaard (einarnn) wrote: >> Yes, Option 2 seems best. > Agreed. I believe most assume these are static values from the vendor > that are not field-writeable (certainly that is true from what I've seen > here at Cisco). Yep, this is why I wrote in a previous email: For example, entPhysicalSerialNum being read-write always bothered me. serial-num is now "config false", which is a good news IMO. So option 2 seems about right to me. Would be nice if the new draft explain that/how people can augment. Regards, Benoit (as a contributor) > > Joe > >> Cheers, >> >> Einar >> >> >>> On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) wrote: >>> >>> >>> >>> On 11/01/2018 13:47, Martin Bjorklund wrote: >>>> Hi, >>>> >>>> To summarize this, I think we have three options for the three nodes >>>> 'model-name', 'mfg-name', and 'serial-num': >>>> >>>> 1. Do nothing (keep the nodes as config true). >>>> >>>> 2. Make these three nodes config false (fairly simple change). >>>> (vendors can augment w/ their own config true nodes). >>>> >>>> 3. Add three new nodes for the configured values. >>>> >>>> >>>> After thinking about this some more, and discussing with Benoit, I >>>> think the best path forward is to do 2, i.e., mark the nodes >>>> 'model-name', 'mfg-name', and 'serial-num' as "config false". As such >>>> they would not be configurable, and thus contain the detected values. >>>> If no value is detected, the node is not present. >>> Option 2 suits me. It keeps it simple. >>> >>>> Note that 1 or 3 can be done in a future update to this module (or by >>>> a vendor). >>> Agreed. >>> >>> Thanks, >>> Rob >>> >>> >>>> >>>> /martin >>>> >>>> >>>> Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: >>>>>> Hi, >>>>>> >>>>>> --- snip --- >>>>>> >>>>>>> state.”, so the above sentence only applies for the second case below. >>>>>> Ok. >>>>>> >>>>>>> 2. The second case is that something is detected but it can’t be read. >>>>>>> We do not see a reason to use the value configured for the leafs >>>>>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the >>>>>>> configuration data. These leafs are defined as optional so why would >>>>>>> we report something entered by an operator in the operational >>>>>>> datastore that intends to report on what is detected? Is it not >>>>>>> better to not report them at all? In an NMDA context it would be >>>>>>> possible to have a different value (or no value at all) for certain >>>>>>> leafs while there is something in the running/intended datastore. >>>>>> The normal NMDA procedure for a configuration leaf is to repeat it in >>>>>> operational state. This is then the "applied configuration". >>>>>> I don't think we should have a special rule for these leafs. >>>>>> >>>>>> This also means that a client that just wants to read all the serial >>>>>> numbers can do so from one place, the operational state, regardless of >>>>>> how they came into existance. >>>>>> >>>>>> [Bogaert, Bart ] >>>>>> >>>>>> We do understand that a target of NMDA is to read out the actually >>>>>> applied data in one request. But the result should not be >>>>>> confusion. A key word is “applied”. >>>>>> >>>>>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains >>>>>> (I put a part of the section between ***): >>>>>> The datastore schema for MUST be a superset of the >>>>>> combined datastore schema used in all configuration datastores except >>>>>> that configuration data nodes supported in a configuration datastore >>>>>> ***MAY be omitted from if a server is not able to >>>>>> accurately report them ***. >>>>> Note that this text talks about the *schema*. It is intended for >>>>> servers to migrate to NMDA without having to instrument all config >>>>> nodes in immediately. If you apply this to >>>>> ietf-hardware, it could be a server that implements the node >>>>> "serial-num" in config, but not in (which would be >>>>> weird). >>>>> >>>>>> For example, it is expected that the value of multiple leafs need to >>>>>> be a consistent set, e.g. the mfg-name, the model-name, and the >>>>>> serial-num. >>>>>> Suppose we have a use case in which a hardware component is >>>>>> planned/configured (e.g. a board supporting DSL interfaces) but a >>>>>> different one is plugged (e.g. a board supporting ethernet >>>>>> interfaces). >>>>>> Suppose it is possible to read some fields on the detected component >>>>>> but due to an issue not to read other fields. >>>>>> If in that case the operational datastore will be completed with the >>>>>> data taken from the running datastore, then the presented view might >>>>>> be inconsistent. >>>>> This is true for other similar nodes as well - "asset-id" and "uri". >>>>> >>>>>> The question is also: what data is applied? Our assumption: if there >>>>>> is a mismatch between detected versus configured hardware, then the >>>>>> interface/service related data that is configured consistently with >>>>>> the planned hardware is not applied on the mismatching >>>>>> hardware. I.e. the detected hardware is not brought in service so not >>>>>> ‘applied’, the operational datastore only (accurately) reports on what >>>>>> is detected. >>>>> If there is a mismatch and the server doesn't apply the configured >>>>> values, then obviously the configured 'mfg-name' etc are not copied to >>>>> . >>>>> >>>>>> We do not see this as a special rule for this data but rather would >>>>>> apply a general rule: >>>>>> - if there is a ‘missing resource’, then the data is not reported in the >>>>>> operational datastore. >>>>>> - If the server is not able to report accurately, then the data is >>>>>> omitted from the operational >>>>> I think that if you want complete separation between the values of >>>>> 'mfg-name', 'model-name', and 'serial-num' in configuration and >>>>> operational state, then these should be modelled as separate leafs. >>>>> We should have a config false leaf 'serial-num' that only contains the >>>>> detected value (if found), and a config true leaf 'config-serial-num' >>>>> or something, that contains the configured serial number. >>>>> >>>>> But if this is the case, I wonder if it wouldn't be better to leave >>>>> such additional config objects to vendors, and simply make these three >>>>> nodes config false in ietf-hardware. >>>>> >>>>> >>>>> /martin >>>>> >>>>>> Regards, Bart >>>>>> >>>>>> /martin >>>>>> >>>>>> >>>>>>> Best regards, Bart >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert >>>>>>> Wilton >>>>>>> Sent: Thursday, December 21, 2017 4:14 PM >>>>>>> To: Martin Bjorklund ; netmod@ietf.org >>>>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> >>>>>>> On 21/12/2017 11:37, Martin Bjorklund wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I need WG input on this issue. The question is how to handle >>>>>>>> 'serial-num', 'mfg-name', and 'model-name'. I think they should all >>>>>>>> be treated the same. Based on previous WG discussion (see e.g. the >>>>>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they >>>>>>>> should all be configurable, but the configured value is only used in >>>>>>>> operational state if the system cannot read it from the hardware. >>>>>>> I think that this approach is probably OK: >>>>>>> - The client can always see the real value if it is available. >>>>>>> - If it is not available then they can assign a value via >>>>>>> configuration. >>>>>>> >>>>>>> I was also considering an alternative approach of having a separate >>>>>>> set of config false leaves for the "burnt in values". And then having >>>>>>> the configurable leaves always override the default operational >>>>>>> values. E.g. similar to how an interface MAC address would expect to >>>>>>> be handled. >>>>>>> >>>>>>> But one set of leaves is probably sufficient. >>>>>>> >>>>>>> Thanks, >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>>> So I suggest the following changes: >>>>>>>> >>>>>>>> OLD: >>>>>>>> >>>>>>>> leaf serial-num { >>>>>>>> type string; >>>>>>>> config false; >>>>>>>> description >>>>>>>> "The vendor-specific serial number string for the >>>>>>>> component. The preferred value is the serial number >>>>>>>> string actually printed on the component itself (if >>>>>>>> present)."; >>>>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>>>> } >>>>>>>> >>>>>>>> NEW: >>>>>>>> >>>>>>>> leaf serial-num { >>>>>>>> type string; >>>>>>>> description >>>>>>>> "The vendor-specific serial number string for the >>>>>>>> component. The preferred value is the serial number >>>>>>>> string actually printed on the component itself (if >>>>>>>> present). >>>>>>>> >>>>>>>> This leaf can be configured. There are two use cases for >>>>>>>> this; as a 'post-it' note if the server cannot determine >>>>>>>> this value from the component, or when pre-provisioning a >>>>>>>> component. >>>>>>>> >>>>>>>> If the server can determine the serial number from the >>>>>>>> component, then that value is always used in operational >>>>>>>> state, even if another value has been configured."; >>>>>>>> reference "RFC 6933: entPhysicalSerialNum"; >>>>>>>> } >>>>>>>> >>>>>>>> And corresponding text for 'mfg-name' and 'model-name'. >>>>>>>> >>>>>>>> And also: >>>>>>>> >>>>>>>> OLD: >>>>>>>> >>>>>>>> When the server detects a new hardware component, it >>>>>>>> initializes a list entry in the operational state. >>>>>>>> >>>>>>>> If the server does not support configuration of hardware >>>>>>>> components, list entries in the operational state are >>>>>>>> initialized with values for all nodes as detected by the >>>>>>>> implementation. >>>>>>>> >>>>>>>> Otherwise, the following procedure is followed: >>>>>>>> >>>>>>>> 1. If there is an entry in the /hardware/component list in >>>>>>>> the intended configuration with values for the nodes >>>>>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>>>>> the detected values, then: >>>>>>>> >>>>>>>> 1a. If the configured entry has a value for 'mfg-name' >>>>>>>> that is equal to the detected value, or if the >>>>>>>> 'mfg-name' value cannot be detected, then the list >>>>>>>> entry in the operational state is initialized with the >>>>>>>> configured values for all configured nodes, including >>>>>>>> the 'name'. >>>>>>>> >>>>>>>> Otherwise, the list entry in the operational state is >>>>>>>> initialized with values for all nodes as detected by >>>>>>>> the implementation. The implementation may raise an >>>>>>>> alarm that informs about the 'mfg-name' mismatch >>>>>>>> condition. How this is done is outside the scope of >>>>>>>> this document. >>>>>>>> >>>>>>>> 1b. Otherwise (i.e., there is no matching configuration >>>>>>>> entry), the list entry in the operational state is >>>>>>>> initialized with values for all nodes as detected by >>>>>>>> the implementation. >>>>>>>> >>>>>>>> If the /hardware/component list in the intended >>>>>>>> configuration is modified, then the system MUST behave as if >>>>>>>> it re-initializes itself, and follow the procedure in >>>>>>>> (1)."; >>>>>>>> >>>>>>>> NEW: >>>>>>>> >>>>>>>> When the server detects a new hardware component, it >>>>>>>> initializes a list entry in the operational state. >>>>>>>> >>>>>>>> If the server does not support configuration of hardware >>>>>>>> components, list entries in the operational state are >>>>>>>> initialized with values for all nodes as detected by the >>>>>>>> implementation. >>>>>>>> >>>>>>>> Otherwise, the following procedure is followed: >>>>>>>> >>>>>>>> 1. If there is an entry in the /hardware/component list in >>>>>>>> the intended configuration with values for the nodes >>>>>>>> 'class', 'parent', 'parent-rel-pos' that are equal to >>>>>>>> the detected values, then the list entry in operational >>>>>>>> state is initialized with the configured values, >>>>>>>> including the 'name'. The leafs 'serial-num', >>>>>>>> 'mfg-name', and 'model-name' are treated specially; see >>>>>>>> their descriptions for details. >>>>>>>> >>>>>>>> 2. Otherwise (i.e., there is no matching configuration >>>>>>>> entry), the list entry in the operational state is >>>>>>>> initialized with values for all nodes as detected by >>>>>>>> the implementation. >>>>>>>> >>>>>>>> If the /hardware/component list in the intended >>>>>>>> configuration is modified, then the system MUST behave as if >>>>>>>> it re-initializes itself, and follow the procedure in >>>>>>>> (1)."; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /martin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Benoit Claise wrote: >>>>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: >>>>>>>>>> Benoit Claise wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> Only kept the relevant excerpts. >>>>>>>>>>>>> - Some objects are read-write in RFC6933: >>>>>>>>>>>>> entPhysicalSerialNum >>>>>>>>>>>>> entPhysicalAlias >>>>>>>>>>>>> entPhysicalAssetID >>>>>>>>>>>>> entPhysicalUris >>>>>>>>>>>>> >>>>>>>>>>>>> For example, entPhysicalSerialNum being read-write always bothered >>>>>>>>>>>>> me. >>>>>>>>>>>>> serial-num is now "config false", which is a good news IMO. >>>>>>>>>>>> Actually, this was not the intention. In >>>>>>>>>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this >>>>>>>>>>>> in the conversion to NMDA. >>>>>>>>>>> Ah. So no good news in this case... >>>>>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in >>>>>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity >>>>>>>>>>>> Yes, this was added per request from the WG. See e.g. the >>>>>>>>>>>> thread "draft-ietf-netmod-entity issue #13". >>>>>>>>>>> Sure. It was mainly an observation. >>>>>>>>>>>> However, I think that what we have now is probably not correct. >>>>>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' >>>>>>>>>>>> should be config true, and the description of list 'component' >>>>>>>>>>>> updated to reflect that all these tree leafs are handled the same way. >>>>>>>>>>>> >>>>>>>>>>>> I would like to know what the WG thinks about this. >>>>>>>>>>> Talking as a contributor this time. >>>>>>>>>>> It seems that inventory management is kind of broken when someone >>>>>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name. >>>>>>>>>> They can't really change them. The configured values are only >>>>>>>>>> used (i.e. visible in the operational state) if the device cannot >>>>>>>>>> detect them automatically. I.e., they work as "post-it" notes only. >>>>>>>>> If I look at, for example, the mfg-name, description, this is not >>>>>>>>> what it says. >>>>>>>>> >>>>>>>>> leaf mfg-name { >>>>>>>>> type string; >>>>>>>>> description >>>>>>>>> "The name of the manufacturer of this physical component. >>>>>>>>> The preferred value is the manufacturer name string >>>>>>>>> actually printed on the component itself (if present). >>>>>>>>> >>>>>>>>> Note that comparisons between instances of the model-name, >>>>>>>>> firmware-rev, software-rev, and the serial-num nodes are >>>>>>>>> only meaningful amongst component with the same value of >>>>>>>>> mfg-name. >>>>>>>>> >>>>>>>>> If the manufacturer name string associated with the >>>>>>>>> physical component is unknown to the server, then this >>>>>>>>> node is not instantiated."; >>>>>>>>> reference "RFC 6933 : >>>>>>>>> entPhysicalMfgName"; >>>>>>>>> >>>>>>>>> Regards, Benoit >>>>>>>>> >>>>>>>>>> /martin >>>>>>>>>> . >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------2471BAC3EEA934B9A4AC988A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/12/2018 2:33 PM, Joe Clarke wrote:
On 1/12/18 05:52, Einar Nilsen-Nygaard (einarnn) wrote:

Yes, Option 2 seems best.

Agreed.  I believe most assume these are static values from the vendor
that are not field-writeable (certainly that is true from what I've seen
here at Cisco).
Yep, this is why I wrote in a previous email:
For example, entPhysicalSerialNum being read-write always bothered me. 
serial-num is now "config false", which is a good news IMO.
So option 2 seems about right to me.
Would be nice if the new draft explain that/how people can augment.

Regards, Benoit (as a contributor)

Joe


Cheers,

Einar



On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwilton@cisco.com> wrote:



On 11/01/2018 13:47, Martin Bjorklund wrote:

Hi,

To summarize this, I think we have three options for the three nodes
'model-name', 'mfg-name', and 'serial-num':

  1.  Do nothing (keep the nodes as config true).

  2.  Make these three nodes config false (fairly simple change).
      (vendors can augment w/ their own config true nodes).

  3.  Add three new nodes for the configured values.


After thinking about this some more, and discussing with Benoit, I
think the best path forward is to do 2, i.e., mark the nodes
'model-name', 'mfg-name', and 'serial-num' as "config false".  As such
they would not be configurable, and thus contain the detected values.
If no value is detected, the node is not present.

Option 2 suits me.  It keeps it simple.


Note that 1 or 3 can be done in a future update to this module (or by
a vendor).

Agreed.

Thanks,
Rob




/martin


Martin Bjorklund <mbj@tail-f.com> wrote:

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:

Hi,

--- snip ---


state.”, so the above sentence only applies for the second case below.

Ok.


2. The second case is that something is detected but it can’t be read.
We do not see a reason to use the value configured for the leafs
‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the
configuration data.  These leafs are defined as optional so why would
we report something entered by an operator in the operational
datastore that intends to report on what is detected?  Is it not
better to not report them at all?  In an NMDA context it would be
possible to have a different value (or no value at all) for certain
leafs while there is something in the running/intended datastore.

The normal NMDA procedure for a configuration leaf is to repeat it in
operational state.  This is then the "applied configuration".
I don't think we should have a special rule for these leafs.

This also means that a client that just wants to read all the serial
numbers can do so from one place, the operational state, regardless of
how they came into existance.

[Bogaert, Bart ]

We do understand that a target of NMDA is to read out the actually
applied data in one request.  But the result should not be
confusion. A key word is “applied”.

Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains
(I put a part of the section between ***):
The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores except
that configuration data nodes supported in a configuration datastore
***MAY be omitted from <operational> if a server is not able to
accurately report them ***.

Note that this text talks about the *schema*.  It is intended for
servers to migrate to NMDA without having to instrument all config
nodes in <operational> immediately.  If you apply this to
ietf-hardware, it could be a server that implements the node
"serial-num" in config, but not in <operational> (which would be
weird).


For example, it is expected that the value of multiple leafs need to
be a consistent set, e.g. the mfg-name, the model-name, and the
serial-num.
Suppose we have a use case in which a hardware component is
planned/configured (e.g. a board supporting DSL interfaces) but a
different one is plugged (e.g. a board supporting ethernet
interfaces).
Suppose it is possible to read some fields on the detected component
but due to an issue not to read other fields.
If in that case the operational datastore will be completed with the
data taken from the running datastore, then the presented view might
be inconsistent.

This is true for other similar nodes as well - "asset-id" and "uri".


The question is also: what data is applied? Our assumption: if there
is a mismatch between detected versus configured hardware, then the
interface/service related data that is configured consistently with
the planned hardware is not applied on the mismatching
hardware. I.e. the detected hardware is not brought in service so not
‘applied’, the operational datastore only (accurately) reports on what
is detected.

If there is a mismatch and the server doesn't apply the configured
values, then obviously the configured 'mfg-name' etc are not copied to
<operational>.


We do not see this as a special rule for this data but rather would
apply a general rule:
-	if there is a ‘missing resource’, then the data is not reported in the
 	operational datastore.
-	If the server is not able to report accurately, then the data is
 	omitted from the operational

I think that if you want complete separation between the values of
'mfg-name', 'model-name', and 'serial-num' in configuration and
operational state, then these should be modelled as separate leafs.
We should have a config false leaf 'serial-num' that only contains the
detected value (if found), and a config true leaf 'config-serial-num'
or something, that contains the configured serial number.

But if this is the case, I wonder if it wouldn't be better to leave
such additional config objects to vendors, and simply make these three
nodes config false in ietf-hardware.


/martin


Regards, Bart

/martin



Best regards, Bart

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
Wilton
Sent: Thursday, December 21, 2017 4:14 PM
To: Martin Bjorklund <mbj@tail-f.com>; netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06

Hi Martin,


On 21/12/2017 11:37, Martin Bjorklund wrote:

Hi,

I need WG input on this issue.  The question is how to handle
'serial-num', 'mfg-name', and 'model-name'.  I think they should all
be treated the same.  Based on previous WG discussion (see e.g. the
mail thread "draft-ietf-netmod-entity issue #13"), I think they
should all be configurable, but the configured value is only used in
operational state if the system cannot read it from the hardware.

I think that this approach is probably OK:
  - The client can always see the real value if it is available.
  - If it is not available then they can assign a value via
configuration.

I was also considering an alternative approach of having a separate
set of config false leaves for the "burnt in values".  And then having
the configurable leaves always override the default operational
values. E.g. similar to how an interface MAC address would expect to
be handled.

But one set of leaves is probably sufficient.

Thanks,
Rob



So I suggest the following changes:

OLD:

       leaf serial-num {
         type string;
         config false;
         description
           "The vendor-specific serial number string for the
            component.  The preferred value is the serial number
            string actually printed on the component itself (if
            present).";
         reference "RFC 6933: entPhysicalSerialNum";
       }

NEW:

       leaf serial-num {
         type string;
         description
           "The vendor-specific serial number string for the
            component.  The preferred value is the serial number
            string actually printed on the component itself (if
            present).

            This leaf can be configured.  There are two use cases for
            this; as a 'post-it' note if the server cannot determine
            this value from the component, or when pre-provisioning a
            component.

            If the server can determine the serial number from the
            component, then that value is always used in operational
            state, even if another value has been configured.";
         reference "RFC 6933: entPhysicalSerialNum";
       }

And corresponding text for 'mfg-name' and 'model-name'.

And also:

OLD:

          When the server detects a new hardware component, it
          initializes a list entry in the operational state.

          If the server does not support configuration of hardware
          components, list entries in the operational state are
          initialized with values for all nodes as detected by the
          implementation.

          Otherwise, the following procedure is followed:

            1. If there is an entry in the /hardware/component list in
               the intended configuration with values for the nodes
               'class', 'parent', 'parent-rel-pos' that are equal to
               the detected values, then:

            1a. If the configured entry has a value for 'mfg-name'
                that is equal to the detected value, or if the
                'mfg-name' value cannot be detected, then the list
                entry in the operational state is initialized with the
                configured values for all configured nodes, including
                the 'name'.

                Otherwise, the list entry in the operational state is
                initialized with values for all nodes as detected by
                the implementation.  The implementation may raise an
                alarm that informs about the 'mfg-name' mismatch
                condition.  How this is done is outside the scope of
                this document.

            1b. Otherwise (i.e., there is no matching configuration
                entry), the list entry in the operational state is
                initialized with values for all nodes as detected by
                the implementation.

          If the /hardware/component list in the intended
          configuration is modified, then the system MUST behave as if
          it re-initializes itself, and follow the procedure in
(1).";

NEW:

          When the server detects a new hardware component, it
          initializes a list entry in the operational state.

          If the server does not support configuration of hardware
          components, list entries in the operational state are
          initialized with values for all nodes as detected by the
          implementation.

          Otherwise, the following procedure is followed:

            1. If there is an entry in the /hardware/component list in
               the intended configuration with values for the nodes
               'class', 'parent', 'parent-rel-pos' that are equal to
               the detected values, then the list entry in operational
               state is initialized with the configured values,
               including the 'name'.  The leafs 'serial-num',
               'mfg-name', and 'model-name' are treated specially; see
               their descriptions for details.

            2. Otherwise (i.e., there is no matching configuration
               entry), the list entry in the operational state is
               initialized with values for all nodes as detected by
               the implementation.

          If the /hardware/component list in the intended
          configuration is modified, then the system MUST behave as if
          it re-initializes itself, and follow the procedure in
(1).";



/martin




Benoit Claise <bclaise@cisco.com> wrote:

On 12/20/2017 4:00 PM, Martin Bjorklund wrote:

Benoit Claise <bclaise@cisco.com> wrote:

Hi Martin,

Thanks.
Only kept the relevant excerpts.

- Some objects are read-write in RFC6933:
         entPhysicalSerialNum
         entPhysicalAlias
         entPhysicalAssetID
         entPhysicalUris

For example, entPhysicalSerialNum being read-write always bothered
me.
serial-num is now "config false", which is a good news IMO.

Actually, this was not the intention.  In
draft-ietf-netmod-entity-03 this is configurable.  I missed this
in the conversion to NMDA.

Ah. So no good news in this case...

In the reverse direction, entPhysicalMfgName is read-only in
RFC6933, while it's "config true" in draft-ietf-netmod-entity

Yes, this was added per request from the WG.  See e.g. the
thread "draft-ietf-netmod-entity issue #13".

Sure. It was mainly an observation.

However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.

I would like to know what the WG thinks about this.

Talking as a contributor this time.
It seems that inventory management is kind of broken when someone
can change 'serial-num', 'mfg-name', and 'model-name.

They can't really change them.  The configured values are only
used (i.e. visible in the operational state) if the device cannot
detect them automatically.  I.e., they work as "post-it" notes only.

If I look at, for example, the mfg-name, description, this is not
what it says.

    leaf mfg-name {
            type string;
            description
              "The name of the manufacturer of this physical component.
               The preferred value is the manufacturer name string
               actually printed on the component itself (if present).

               Note that comparisons between instances of the model-name,
               firmware-rev, software-rev, and the serial-num nodes are
               only meaningful amongst component with the same value of
               mfg-name.

               If the manufacturer name string associated with the
               physical component is unknown to the server, then this
               node is not instantiated.";
            reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
            entPhysicalMfgName";

Regards, Benoit


/martin
.


_______________________________________________
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

_______________________________________________
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


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

--------------2471BAC3EEA934B9A4AC988A-- From nobody Fri Jan 12 11:37:42 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 464F612D873 for ; Fri, 12 Jan 2018 11:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 N03MJrLADwtk for ; Fri, 12 Jan 2018 11:37:26 -0800 (PST) Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53]) (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 5AFDA12D877 for ; Fri, 12 Jan 2018 11:37:24 -0800 (PST) Received: by mail-pg0-f53.google.com with SMTP id 136so4647263pgd.8 for ; Fri, 12 Jan 2018 11:37:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BEOHcqKpn+hdVYrSNbkOAy1Cg2FUhroS6cmpOpLivQg=; b=Shbnb8Xzb9nS2ba66MQjryHNssl4iTOcODDKEBMgJ4l+vHkQYYxVpawy4JX9YdtZWQ U4vHobjCvWMFguIpozQI3Akyu2BjMat1GbO4FRPWI0SgGsNkhjALe4gD2CxclM4KUNFb zH0Pd8gABgjmiKIFiBLf4E3YdlJxPLYg7BB/hpM8HSzaD7yunPwUHRw58JC7LibJhHvb fvC4WZmt6/QlWcqwLV+dyXd4UIab48C4QaWPx2jyEiOAzUVZIFUahbmpimrqkDzSGhL2 vANmbc8XTSMDEzKlSeldzuHseTRFYWIoKKXEyGqDoGmGvU1IWll3O64T6gdbSrgKjWrh hyvw== X-Gm-Message-State: AKwxyteJCaxIETusxYIcaEmw+Dc9XOPU5Gl3u0YE2fYutDJb0qBO2oD+ L4wciqGScuB6GITBPEjAsoyfp7z9dWo= X-Google-Smtp-Source: ACJfBouGyO3uGEK8+O0/lhU+T3tFguRgUvdBS5Ri2iHK7IgeCjReRiSzqLg3qQt2CWmcbHLMOAx/EQ== X-Received: by 10.98.69.82 with SMTP id s79mr7944337pfa.214.1515785843517; Fri, 12 Jan 2018 11:37:23 -0800 (PST) Received: from [192.168.1.101] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id g13sm988451pfe.50.2018.01.12.11.37.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 11:37:23 -0800 (PST) To: Kathleen Moriarty , The IESG , draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <151561207372.18313.8094240527199424975.idtracker@ietfa.amsl.com> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <20180111075218.3tu65mthzlnef3bi@elstar.local> <20180112094500.ymlrkswjfgkhibef@elstar.local> <20180112160020.ovnu3xtns5y325ug@elstar.local> From: Randy Presuhn Message-ID: Date: Fri, 12 Jan 2018 11:37:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180112160020.ovnu3xtns5y325ug@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 19:37:36 -0000 Hi - On 1/12/2018 8:00 AM, Juergen Schoenwaelder wrote: > On Fri, Jan 12, 2018 at 09:23:28AM -0500, Kathleen Moriarty wrote: >> Hi Juergen, >> >> On Fri, Jan 12, 2018 at 4:45 AM, Juergen Schoenwaelder >> wrote: >>> On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen Moriarty wrote: >>>> Hi Juergen, >>>> >>>> Thank you very much for the additional information. This was very >>>> helpful. Benoit and I discussed it a bit further on the telechat and >>>> some text changes in the introduction and security considerations >>>> section to provide some of this information for the reader will be >>>> helpful. I got the explanations and appreciate them and from the >>>> explanations, my discuss questions have been answered and I'll switch >>>> this to a no objection leaving you and Benoit to add the text as >>>> helpful for other readers. >>>> >>> >>> Kathleen, >>> >>> we propose to add this text to the security considerations: >>> >>> The origin metadata annotation exposes the origin of values in the >>> applied configuration. Origin information may provide hints that >>> certain control plane protocols are active on a device. Since origin >>> information is tied to applied configuration values, it is only >>> accessible to clients that have the permissions to read the applied >>> configuration values. Security administrators should consider the >>> sensitivity of origin information while defining access control >>> rules. >> >> Thank you, that is very helpful. Would it also be possible to add >> text in the introduction on where the data for these values comes from >> (the device itself)? > > The Introduction does not really talk about the origin annotation > details and hence it seems such text would be misplaced or at least > confusing to read. The definition of origin is in section 5.3.4. This > section starts with: > > As configuration flows into , it is conceptually marked > with a metadata annotation ([RFC7952]) that indicates its origin. > > Since the whole data flow between datastores resides on a 'device', it > seems clear that the origin values are added by the device itself. And > if any clarification is needed, I think it belongs into 5.3.4 and not > into the Introduction. Except when the netmod server is acting as a "front" for other devices. Randy From nobody Fri Jan 12 14:07: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 C8881124BE8 for ; Fri, 12 Jan 2018 14:07:22 -0800 (PST) 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 ffnDyut2WI3S for ; Fri, 12 Jan 2018 14:07:18 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 93707120721 for ; Fri, 12 Jan 2018 14:07:18 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id w4so6271371otg.3 for ; Fri, 12 Jan 2018 14:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VoAHP9R1iA/l0HB4lsaowtw8zr+WvBaKl7d5/h8LtWQ=; b=DS74al+uuoM9rZKgvzcMb5BdSKl0RsTpIu+zTfEBVaYeeKZwHdNKgZwJmznhikXnSi jFZclKVz/VizzlbxdSTkgjvSPkDjNZ4+R5f8T6rlwrDcodN2rM4bA1BiiKV73ie97QbH 8vdY9+QRUakqoQOdTkj9nSpjYN+hs1yHIJSLECZNd930cx55uU1wSmmLxvT7ju7SQR3l Z63wr/5ZRIi5RVvrIvaQT4PA4guZPJawJNrQN6VY2oULjwkgv/kRxqzXfXdd9rSXguL5 +3VDNg8+vYbYVf6lZSvg33V7KVDjGJQnG/NZpccEoSO1SJj3MHu+jn5Auyf0Q3RKsjzR C5VQ== 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=VoAHP9R1iA/l0HB4lsaowtw8zr+WvBaKl7d5/h8LtWQ=; b=T2kX/q4VIHr9JcJimfncghxgB5l1BiUPlK0ll791yTip+bKrQ7zeSPAbyW8BqEqDx+ HzCtKir9UbU7AJnm+jBVfEuHUkbGLggp0saZeeoLmtn8RbxV77U0+JCpV9aob1lfbhYQ nJwRJO6eIDg/CYlDFnVDNGUpKi6eU/S/RoMa5hSKPheHuTfSr6sPu0/XAFC0JIFMEd58 i/XKJijr4BEmipy0ZHPx50COeF6beV1epmOwwDsfNB32VGTST40i3hDVFUv41h+6yR8+ V2sPseBI19gTYS6OGfJ541ISiOYTOMHALPK5ZWAx9vWVoxK5iqb4QcLkOcJszNVXFhnk 37Wg== X-Gm-Message-State: AKwxytc1YQD2EEi1G13aMSrok1yYND9keZyfROoX+akS8ONRr8ULiDbb a0E2M9gVvDkI+I4217/lc/p7vPve X-Google-Smtp-Source: ACJfBougIBYZmG+nqo4vQg40N5kYiH4aiGp1VplFWznwvIYNtIqhfyQAgtC5ro+j/gUDDXn02HW4sA== X-Received: by 10.157.6.193 with SMTP id 59mr1084719otx.169.1515794837829; Fri, 12 Jan 2018 14:07:17 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d4a4:75b0:373d:81a9]) by smtp.gmail.com with ESMTPSA id 9sm8963913otj.13.2018.01.12.14.07.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 14:07:16 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_42401CCB-3552-4FF5-AD98-AAEF1834FAA5" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 12 Jan 2018 14:07:13 -0800 In-Reply-To: <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> Cc: "netmod@ietf.org" To: Eliot Lear References: <20171102074318.GC12688@spritelink.se> <20171102.132634.1363976895007772742.mbj@tail-f.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 22:07:23 -0000 --Apple-Mail=_42401CCB-3552-4FF5-AD98-AAEF1834FAA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 An updated version of the draft, along with changes to remove icmp-off = from the model, and updates to examples has been posted in the PR here = . If there are no = objections to the changes by Tuesday, I will pull in the PR, and publish = the draft. Cheers. > On Jan 12, 2018, at 7:35 AM, Eliot Lear wrote: >=20 > Ok. What is left to agree on at this point? >=20 > Thanks Mahesh, >=20 > Eliot >=20 > On 11.01.18 02:21, Mahesh Jethanandani wrote: >> Hi Einar, >>=20 >> I can work on updating the draft as soon as we agree on the changes. = Should take only a couple of days to turn around and publish the draft. >>=20 >>> On Jan 9, 2018, at 11:35 PM, Eliot Lear > wrote: >>>=20 >>> Hi Mahesh, >>>=20 >>> Thanks for this work. I think this is okay. In the case of MUD we = simply won't have the other container. Can I please ask that you get = the draft out quickly as draft-ietf-opsawg-mud has been waiting quite = some time for this work to complete. >>>=20 >>> Eliot >>>=20 >>> On 10.01.18 04:08, Mahesh Jethanandani wrote: >>>> I have pulled in the changes as they relate to: >>>>=20 >>>> - moving =E2=80=9Cinterface-acl=E2=80=9D under the container = =E2=80=9Cattachment-points=E2=80=9D making it local to that container. >>>> - reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ctype=E2=80=9D >>>> - removed =E2=80=9Cinterface-all-aggregate=E2=80=9D feature >>>> - simplified source port and destination port definition >>>>=20 >>>> The pull request for the changes can be found here. >>>>=20 >>>> https://github.com/netmod-wg/acl-model/pull/20 = >>>>=20 >>>> After discussing with some of the original contributors, decided = not to include the change as it relates to augmenting ietf-interfaces. = We did not find that the change had a particular advantage over the = current implementation. Even if we do not completely understand how ACLs = might be attached =E2=80=9Cglobally=E2=80=9D or on something that is not = an interface, having the flexibility to attach them to other attachment = points is important. Keeping it as interface-ref gives us that = flexibility. >>>>=20 >>>> Cheers. >>>>=20 >>>>> On Dec 18, 2017, at 4:31 AM, Eliot Lear > wrote: >>>>>=20 >>>>> So long as nobody expects an interface construct in a MUD file, = I'm happy. >>>>>=20 >>>>> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote: >>>>>> Eliot, >>>>>>=20 >>>>>> Nothing can force an implementation to have to implement either = the ietf-interfaces model or the augmentation in the = ietf-access-control-list model. I appreciate your desire for modularity = and cohesiveness, but I would resist #1, because I feel that the = majority of users will be targeting interface-based attachment over = time. I=E2=80=99ve adde back in use of the =E2=80=9Cinterface-attachment=E2= =80=9D feature (which I took out as part of refactoring interface = attachment). Part of: >>>>>>=20 >>>>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>>>=20 >>>>>> The augments part of the tree now looks like: >>>>>>=20 >>>>>> augment /if:interfaces/if:interface: >>>>>> +--rw acls {interface-attachment}? >>>>>> +--rw ingress >>>>>> | +--rw acl-sets >>>>>> | +--rw acl-set* [name] >>>>>> | +--rw name -> /access-lists/acl/name >>>>>> | +--rw type? -> /access-lists/acl/type >>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> | +--ro matched-packets? yang:counter64 >>>>>> | +--ro matched-octets? yang:counter64 >>>>>> +--rw egress >>>>>> +--rw acl-sets >>>>>> +--rw acl-set* [name] >>>>>> +--rw name -> /access-lists/acl/name >>>>>> +--rw type? -> /access-lists/acl/type >>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>> +--ro matched-packets? yang:counter64 >>>>>> +--ro matched-octets? yang:counter64 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Einar >>>>>>=20 >>>>>>=20 >>>>>>> On 17 Dec 2017, at 11:29, Eliot Lear > wrote: >>>>>>>=20 >>>>>>> Einar, >>>>>>>=20 >>>>>>> I think this change is fine, with one exception. I would rather = the augment to the interface not be required for implementations that = don't actually have interfaces. I understand that there may be two ways = to go about this: >>>>>>>=20 >>>>>>> Separate out the augment into a separate module (same doc is = fine); or >>>>>>> Somehow "feature-ize" the augment. >>>>>>> I don't know how to do (2) but if you do, that's okay by me. >>>>>>>=20 >>>>>>> Eliot >>>>>>>=20 >>>>>>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote: >>>>>>>> All, >>>>>>>>=20 >>>>>>>> After a series of discussions on- and off-list, I have a = candidate PR that includes the changes in the PR Mahesh sent out plus = some more edits. Please see consolidated PR here: >>>>>>>>=20 >>>>>>>> https://github.com/netmod-wg/acl-model/pull/21 = >>>>>>>>=20 >>>>>>>> Main changes in addition to Mahesh=E2=80=99s PR are: >>>>>>>>=20 >>>>>>>> Moved interface attachment to be via an interface augmentation. >>>>>>>> Restructured port matches slightly under both IPv4 and IPv6 = containers. >>>>>>>> Removed unnecessary identity 'interface-acl-aggregate=E2=80=99. >>>>>>>> Removed action =E2=80=98icmp-off=E2=80=99, can be augmented = later. >>>>>>>>=20 >>>>>>>> For reference, here is the current YANG tree plus =E2=80=9C--ietf= =E2=80=9D logs: >>>>>>>>=20 >>>>>>>> 13:12 $ pyang --ietf --lint -f tree = ietf-access-control-list.yang >>>>>>>> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" = (should be date) >>>>>>>> module: ietf-access-control-list >>>>>>>> +--rw access-lists >>>>>>>> +--rw acl* [name] >>>>>>>> +--rw name string >>>>>>>> +--rw type? acl-type >>>>>>>> +--rw aces >>>>>>>> +--rw ace* [name] >>>>>>>> +--rw name string >>>>>>>> +--rw matches >>>>>>>> | +--rw (l2)? >>>>>>>> | | +--:(eth) >>>>>>>> | | +--rw eth {match-on-eth}? >>>>>>>> | | +--rw destination-mac-address? = yang:mac-address >>>>>>>> | | +--rw destination-mac-address-mask? = yang:mac-address >>>>>>>> | | +--rw source-mac-address? = yang:mac-address >>>>>>>> | | +--rw source-mac-address-mask? = yang:mac-address >>>>>>>> | | +--rw ethertype? = eth:ethertype >>>>>>>> | +--rw (l3)? >>>>>>>> | | +--:(ipv4) >>>>>>>> | | | +--rw ipv4 {match-on-ipv4}? >>>>>>>> | | | +--rw dscp? = inet:dscp >>>>>>>> | | | +--rw ecn? = uint8 >>>>>>>> | | | +--rw length? = uint16 >>>>>>>> | | | +--rw ttl? = uint8 >>>>>>>> | | | +--rw protocol? = uint8 >>>>>>>> | | | +--rw = (source-port-range-or-operator)? >>>>>>>> | | | | +--:(range) >>>>>>>> | | | | | +--rw source-port-lower = inet:port-number >>>>>>>> | | | | | +--rw source-port-upper = inet:port-number >>>>>>>> | | | | +--:(operator) >>>>>>>> | | | | +--rw source-operator = operator >>>>>>>> | | | | +--rw source-port = inet:port-number >>>>>>>> | | | +--rw = (destination-port-range-or-operator)? >>>>>>>> | | | | +--:(range) >>>>>>>> | | | | | +--rw destination-port-lower = inet:port-number >>>>>>>> | | | | | +--rw destination-port-upper = inet:port-number >>>>>>>> | | | | +--:(operator) >>>>>>>> | | | | +--rw destination-operator = operator >>>>>>>> | | | | +--rw destination-port = inet:port-number >>>>>>>> | | | +--rw ihl? = uint8 >>>>>>>> | | | +--rw flags? = bits >>>>>>>> | | | +--rw offset? = uint16 >>>>>>>> | | | +--rw identification? = uint16 >>>>>>>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>>>>>>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>>>>>>> | | +--:(ipv6) >>>>>>>> | | +--rw ipv6 {match-on-ipv6}? >>>>>>>> | | +--rw dscp? = inet:dscp >>>>>>>> | | +--rw ecn? = uint8 >>>>>>>> | | +--rw length? = uint16 >>>>>>>> | | +--rw ttl? = uint8 >>>>>>>> | | +--rw protocol? = uint8 >>>>>>>> | | +--rw = (source-port-range-or-operator)? >>>>>>>> | | | +--:(range) >>>>>>>> | | | | +--rw source-port-lower = inet:port-number >>>>>>>> | | | | +--rw source-port-upper = inet:port-number >>>>>>>> | | | +--:(operator) >>>>>>>> | | | +--rw source-operator = operator >>>>>>>> | | | +--rw source-port = inet:port-number >>>>>>>> | | +--rw = (destination-port-range-or-operator)? >>>>>>>> | | | +--:(range) >>>>>>>> | | | | +--rw destination-port-lower = inet:port-number >>>>>>>> | | | | +--rw destination-port-upper = inet:port-number >>>>>>>> | | | +--:(operator) >>>>>>>> | | | +--rw destination-operator = operator >>>>>>>> | | | +--rw destination-port = inet:port-number >>>>>>>> | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>>>>>>> | | +--rw source-ipv6-network? = inet:ipv6-prefix >>>>>>>> | | +--rw flow-label? = inet:ipv6-flow-label >>>>>>>> | +--rw (l4)? >>>>>>>> | | +--:(tcp) >>>>>>>> | | | +--rw tcp {match-on-tcp}? >>>>>>>> | | | +--rw sequence-number? = uint32 >>>>>>>> | | | +--rw acknowledgement-number? = uint32 >>>>>>>> | | | +--rw data-offset? = uint8 >>>>>>>> | | | +--rw reserved? = uint8 >>>>>>>> | | | +--rw flags? = bits >>>>>>>> | | | +--rw window-size? = uint16 >>>>>>>> | | | +--rw urgent-pointer? = uint16 >>>>>>>> | | | +--rw options? = uint32 >>>>>>>> | | +--:(udp) >>>>>>>> | | | +--rw udp {match-on-udp}? >>>>>>>> | | | +--rw length? uint16 >>>>>>>> | | +--:(icmp) >>>>>>>> | | +--rw icmp {match-on-icmp}? >>>>>>>> | | +--rw type? uint8 >>>>>>>> | | +--rw code? uint8 >>>>>>>> | | +--rw rest-of-header? uint32 >>>>>>>> | +--rw egress-interface? if:interface-ref >>>>>>>> | +--rw ingress-interface? if:interface-ref >>>>>>>> +--rw actions >>>>>>>> | +--rw forwarding identityref >>>>>>>> | +--rw logging? identityref >>>>>>>> +--ro statistics {acl-aggregate-stats}? >>>>>>>> +--ro matched-packets? yang:counter64 >>>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>>=20 >>>>>>>> augment /if:interfaces/if:interface: >>>>>>>> +--rw acls >>>>>>>> +--rw ingress >>>>>>>> | +--rw acl-sets >>>>>>>> | +--rw acl-set* [name] >>>>>>>> | +--rw name -> = /access-lists/acl/name >>>>>>>> | +--rw type? -> = /access-lists/acl/type >>>>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>> | +--ro matched-packets? yang:counter64 >>>>>>>> | +--ro matched-octets? yang:counter64 >>>>>>>> +--rw egress >>>>>>>> +--rw acl-sets >>>>>>>> +--rw acl-set* [name] >>>>>>>> +--rw name -> = /access-lists/acl/name >>>>>>>> +--rw type? -> = /access-lists/acl/type >>>>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>> +--ro matched-packets? yang:counter64 >>>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>>=20 >>>>>>>> Comments welcome! >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Einar >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal > wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi Einar, >>>>>>>>>>=20 >>>>>>>>>> You had 3 questions for me on all the several e-mail threads.=20= >>>>>>>>>> 1. Global attachment point >>>>>>>>>> 2. icmp-off >>>>>>>>>> 3. acl-aggregate-interface stats. >>>>>>>>>>=20 >>>>>>>>>> For (1), my first preference is to have the model define = attachment point for interfaces only. >>>>>>>>>=20 >>>>>>>>> einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to netmod-wg/acl-model that do this. Nearly like the augmentation I = have below. Feel free to take a look at: >>>>>>>>>=20 >>>>>>>>> https://github.com/mjethanandani/acl-model/pull/3 = >>>>>>>>>=20 >>>>>>>>>> However, Kristian wants the global attachment point as well = so that he can add the ACL to the linux tables. >>>>>>>>>=20 >>>>>>>>> einarnn> I think Kristian doesn=E2=80=99t feel a global = attachment point needs to be in this first revision. But he can confirm. >>>>>>>>>=20 >>>>>>>>>> If an ACL is attached globally, does this mean it is per = direction or does it mean it is across directions? >>>>>>>>>=20 >>>>>>>>> einarnn> I don=E2=80=99t know right now :-) >>>>>>>>>=20 >>>>>>>>>> This global ACL may not be applicable to any of Cisco's = service provider routers as I don't see any platform actually = replicating the ACL to all line cards and attaching it in ingress and = egress directions across all interfaces. >>>>>>>>>=20 >>>>>>>>> einarnn> Per other emails, I don=E2=80=99t think we understand = this enough yet to specify it, so I suggest we just leave it out for = now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80= =9D being added later once we understand what it really means. >>>>>>>>>=20 >>>>>>>>>> For (2), I am ok with removing icmp-off. >>>>>>>>>=20 >>>>>>>>> einarnn> Done in my PR above. >>>>>>>>>=20 >>>>>>>>>> For (3), this would have to be a combination of ACL stats = across all interfaces for all ACL's. Something like this is possible on = an XR box where ACES have counter names associated with it. Let's chat = about this offline tomorrow. >>>>>>>>>=20 >>>>>>>>> einarnn> I=E2=80=99ll ping you to clarify, and we can bring = any conclusion back to the list. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Einar >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Sonal. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani = > wrote: >>>>>>>>>> We want to support =E2=80=9Cglobal=E2=80=9D attachment point = down the line, and that =E2=80=9Cglobal=E2=80=9D attachment point will = be one of the choices (the other being the interface), what would this = augment look like. Note, as far as I know, you cannot augment inside a = choice node. >>>>>>>>>>=20 >>>>>>>>>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Perhaps like this, as an augmentation to the interface: >>>>>>>>>>>=20 >>>>>>>>>>> augment /if:interfaces/if:interface: >>>>>>>>>>> +--rw ingress-acls >>>>>>>>>>> | +--rw acl-sets >>>>>>>>>>> | +--rw acl-set* [name] >>>>>>>>>>> | +--rw name -> = /access-lists/acl/name >>>>>>>>>>> | +--rw type? -> = /access-lists/acl/type >>>>>>>>>>> | +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>>>> | +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>>>> | +--ro matched-packets? yang:counter64 >>>>>>>>>>> | +--ro matched-octets? yang:counter64 >>>>>>>>>>> +--rw egress-acls >>>>>>>>>>> +--rw acl-sets >>>>>>>>>>> +--rw acl-set* [name] >>>>>>>>>>> +--rw name -> = /access-lists/acl/name >>>>>>>>>>> +--rw type? -> = /access-lists/acl/type >>>>>>>>>>> +--ro ace-statistics* [name] {interface-stats}? >>>>>>>>>>> +--ro name -> = /access-lists/acl/aces/ace/name >>>>>>>>>>> +--ro matched-packets? yang:counter64 >>>>>>>>>>> +--ro matched-octets? yang:counter64 >>>>>>>>>>>=20 >>>>>>>>>>> Could also put an =E2=80=9Caces=E2=80=9D container above = both these & rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, = etc. to give a single root for the augmentation if preferred. >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>>=20 >>>>>>>>>>> Einar >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 6 Dec 2017, at 19:43, Eliot Lear > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote: >>>>>>>>>>>>> How does one move the interface attachment point, = currently an >>>>>>>>>>>>> 'interface-ref', to an augmentation of the = if:interfaces/interface, >>>>>>>>>>>>> inside of the =E2=80=98acl=E2=80=99 container? Down the = line we might need to have an >>>>>>>>>>>>> container for "attachment points" to accommodate the = possibility of >>>>>>>>>>>>> attaching an ACL either to an interface or =E2=80=9Cglobally= =E2=80=9D. >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Keeping in mind that one use is that an ACL doesn't attach = to an >>>>>>>>>>>> interface at all. >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> netmod mailing list >>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Mahesh Jethanandani >>>>>>>>>> mjethanandani@gmail.com >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> netmod mailing list >>>>>>>>>> netmod@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> netmod mailing list >>>>>>>>> netmod@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod = >>>>=20 >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod = >>>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_42401CCB-3552-4FF5-AD98-AAEF1834FAA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 An = updated version of the draft, along with changes to remove icmp-off from = the model, and updates to examples has been posted in the PR here. If there are no objections to the changes by = Tuesday, I will pull in the PR, and publish the draft.

Cheers.

On Jan = 12, 2018, at 7:35 AM, Eliot Lear <lear@cisco.com> wrote:

=20 =20

Ok.  What is left to agree on at this point?

Thanks Mahesh,

Eliot


On 11.01.18 02:21, Mahesh = Jethanandani wrote:
Hi Einar,

I can work on updating the draft as soon as we = agree on the changes. Should take only a couple of days to turn around and publish the draft.

On Jan 9, 2018, at 11:35 PM, Eliot Lear = <lear@cisco.com> wrote:

Hi Mahesh,

Thanks for this work.  I = think this is okay.  In the case of MUD we simply won't have = the other container.  Can I please ask that you get = the draft out quickly as draft-ietf-opsawg-mud has been waiting quite some time for this work to = complete.

Eliot


On 10.01.18 04:08, Mahesh Jethanandani wrote:
= I have pulled in the changes as they relate to:

- moving =E2=80=9Cinterface-acl=E2=80=9D= under the container =E2=80=9Cattachment-points=E2=80=9D making = it local to that container.
- reverting =E2=80=9Cacl-type=E2=80=9D = to =E2=80=9Ctype=E2=80=9D
- removed = =E2=80=9Cinterface-all-aggregate=E2=80=9D feature
- simplified source port and = destination port definition

The pull request for the changes can = be found here.

https://github.com/netmod-wg/acl-model/pull/20

After discussing with some of the original contributors, decided not to include the change as it relates to augmenting ietf-interfaces. We did not find that the change had a particular advantage over the current implementation. Even if we do not completely understand how ACLs might be attached =E2=80=9Cglobally=E2=80=9D or on something = that is not an interface, having the flexibility to attach them to other attachment points is important. Keeping it as interface-ref gives us that flexibility.

Cheers.

On Dec 18, 2017, at 4:31 AM, = Eliot Lear <lear@cisco.com> wrote:

So long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
= Eliot,

Nothing can force an implementation to have to implement either the ietf-interfaces model or = the augmentation in the ietf-access-control-list model. I appreciate your desire for modularity and cohesiveness, but I would resist #1, because I feel that the majority of users will be targeting interface-based attachment over time. I=E2=80=99ve adde = back in use of the =E2=80=9Cinterface-attachment=E2= =80=9D feature (which I took out as part of refactoring interface attachment). Part of:

https://github.com/netmod-wg/acl-model/pull/21

The augments part of the tree now looks like:

  augment = /if:interfaces/if:interface:
    +--rw acls {interface-attachment}?
       +--rw ingress
       |  +--rw acl-sets
       |     +--rw acl-set* [name]
       |       =  +--rw name         =      -> /access-lists/acl/name
       |       =  +--rw type?         =     -> /access-lists/acl/type
       |       =  +--ro ace-statistics* [name] {interface-stats}?
       |       =     +--ro name       =         -> = /access-lists/acl/aces/ace/name
       |       =     +--ro matched-packets?   yang:counter64
       |       =     +--ro matched-octets?    yang:counter64
       +--rw egress
          +--rw acl-sets
             +--rw acl-set* [name]
                = +--rw name         =      -> /access-lists/acl/name
                = +--rw type?         =     -> /access-lists/acl/type
                = +--ro ace-statistics* [name] {interface-stats}?
                =    +--ro name     =           -> = /access-lists/acl/aces/ace/name
                =    +--ro matched-packets?   yang:counter64
                =    +--ro matched-octets?    yang:counter64

Cheers,

Einar


On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:

Einar,

I = think this change is fine, with one = exception.  I would rather the augment to the interface not be required for implementations that don't actually have = interfaces.  I understand that there may be two ways to go about this:

  1. Separate out = the augment into a separate module (same doc is fine); or
  2. Somehow "feature-ize" the augment. =

I don't know = how to do (2) but if you do, that's okay by me.

Eliot


On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
= All,

After a series of discussions on- and off-list, I have a candidate PR that includes the changes in the PR Mahesh sent out plus some more edits. Please see consolidated PR = here:

https://github.com/netmod-wg/acl-model/pull/21

Main changes in addition to Mahesh=E2=80=99= s PR are:

  • Moved interface attachment to be via an interface augmentation.
  • Restructured port matches slightly under both IPv4 and IPv6 containers.
  • Removed unnecessary identity = 'interface-acl-aggregate=E2=80=99.
  • Removed action =E2=80=98icmp-off= =E2=80=99, can be augmented later. =

For = reference, here is the current YANG tree plus =E2=80=9C--ietf=E2= =80=9D logs:

13:12 $ pyang --ietf --lint -f tree = ietf-access-control-list.yang
ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" (should be date)
module: ietf-access-control-list
    +--rw = access-lists
       +--rw acl* = [name]
          +--rw name =    string
          +--rw type? =   acl-type
          +--rw = aces
            =  +--rw ace* [name]
              =   +--rw name         =  string
              =   +--rw matches
              =   |  +--rw (l2)?
              =   |  | =  +--:(eth)
              =   |  |     +--rw eth = {match-on-eth}?
              =   |  |        +--rw = destination-mac-address?       =  yang:mac-address
              =   |  |        +--rw = destination-mac-address-mask?   = yang:mac-address
              =   |  |        +--rw source-mac-address? =         =     = yang:mac-address
              =   |  |        +--rw = source-mac-address-mask?       =  yang:mac-address
              =   |  |        +--rw ethertype? =           =           =  eth:ethertype
              =   |  +--rw (l3)?
              =   |  | =  +--:(ipv4)
              =   |  |  |  +--rw ipv4 = {match-on-ipv4}?
              =   |  |  |     +--rw dscp?   =               =       inet:dscp
              =   |  |  |     +--rw ecn?   =                 =      uint8
              =   |  |  |     +--rw length?   =             =       uint16
              =   |  |  |     +--rw ttl?   =                 =      uint8
              =   |  |  |     +--rw protocol?   =           =       uint8
              =   |  |  |     +--rw = (source-port-range-or-operator)?
              =   |  |  |     | =  +--:(range)
              =   |  |  |     |  |  +--rw source-port-lower =           = inet:port-number
              =   |  |  |     |  |  +--rw source-port-upper =           = inet:port-number
              =   |  |  |     | =  +--:(operator)
              =   |  |  |     |     +--rw source-operator   =           = operator
              =   |  |  |     |     +--rw = source-port       =           = inet:port-number
              =   |  |  |     +--rw = (destination-port-range-or-operator)?
              =   |  |  |     | =  +--:(range)
              =   |  |  |     |  |  +--rw destination-port-lower     =  inet:port-number
              =   |  |  |     |  |  +--rw destination-port-upper     =  inet:port-number
              =   |  |  |     | =  +--:(operator)
              =   |  |  |     |     +--rw destination-operator =       =  operator
              =   |  |  |     |     +--rw destination-port =           =  inet:port-number
              =   |  |  |     +--rw ihl?   =                 =      uint8
              =   |  |  |     +--rw flags?   =               =      bits
              =   |  |  |     +--rw offset?   =             =       uint16
              =   |  |  |     +--rw identification?       =       uint16
              =   |  |  |     +--rw = destination-ipv4-network?   = inet:ipv4-prefix
              =   |  |  |     +--rw source-ipv4-network? =       =  inet:ipv4-prefix
              =   |  | =  +--:(ipv6)
              =   |  |     +--rw ipv6 = {match-on-ipv6}?
              =   |  |        +--rw dscp? =                 =       inet:dscp
              =   |  |        +--rw ecn? =                 =        uint8
              =   |  |        +--rw length? =               =       uint16
              =   |  |        +--rw ttl? =                 =        uint8
              =   |  |        +--rw protocol? =             =       uint8
              =   |  |        +--rw = (source-port-range-or-operator)?
              =   |  |        | =  +--:(range)
              =   |  |        |  |  +--rw source-port-lower =           = inet:port-number
              =   |  |        |  |  +--rw source-port-upper =           = inet:port-number
              =   |  |        | =  +--:(operator)
              =   |  |        |     +--rw source-operator   =           = operator
              =   |  |        |     +--rw = source-port       =           = inet:port-number
              =   |  |        +--rw = (destination-port-range-or-operator)?
              =   |  |        | =  +--:(range)
              =   |  |        |  |  +--rw destination-port-lower     =  inet:port-number
              =   |  |        |  |  +--rw destination-port-upper     =  inet:port-number
              =   |  |        | =  +--:(operator)
              =   |  |        |     +--rw destination-operator =       =  operator
              =   |  |        |     +--rw destination-port =           =  inet:port-number
              =   |  |        +--rw = destination-ipv6-network?   = inet:ipv6-prefix
              =   |  |        +--rw source-ipv6-network? =       =  inet:ipv6-prefix
              =   |  |        +--rw = flow-label?           =       = inet:ipv6-flow-label
              =   |  +--rw (l4)?
              =   |  | =  +--:(tcp)
              =   |  |  |  +--rw tcp = {match-on-tcp}?
              =   |  |  |     +--rw sequence-number?       =    uint32
              =   |  |  |     +--rw = acknowledgement-number?   = uint32
              =   |  |  |     +--rw data-offset? =           =    uint8
              =   |  |  |     +--rw reserved?   =           =     uint8
              =   |  |  |     +--rw flags?   =               =    bits
              =   |  |  |     +--rw window-size? =           =    uint16
              =   |  |  |     +--rw urgent-pointer?       =     uint16
              =   |  |  |     +--rw options?   =             =    uint32
              =   |  | =  +--:(udp)
              =   |  |  |  +--rw udp = {match-on-udp}?
              =   |  |  |     +--rw length?   = uint16
              =   |  | =  +--:(icmp)
              =   |  |     +--rw icmp = {match-on-icmp}?
              =   |  |        +--rw type? =             = uint8
              =   |  |        +--rw code? =             = uint8
              =   |  |        +--rw = rest-of-header?   = uint32
              =   |  +--rw egress-interface? =   =  if:interface-ref
              =   |  +--rw ingress-interface? =   = if:interface-ref
              =   +--rw actions
              =   |  +--rw forwarding   =  identityref
              =   |  +--rw logging?     =  identityref
              =   +--ro statistics = {acl-aggregate-stats}?
              =      +--ro matched-packets? =   = yang:counter64
              =      +--ro matched-octets?   =  yang:counter64

  augment = /if:interfaces/if:interface:
    +--rw = acls
       +--rw = ingress
       |  +--rw = acl-sets
       |     = +--rw acl-set* [name]
       |     =    +--rw name         =      -> = /access-lists/acl/name
       |     =    +--rw type?       =       -> = /access-lists/acl/type
       |     =    +--ro ace-statistics* [name] = {interface-stats}?
       |     =       +--ro name     =           -> = /access-lists/acl/aces/ace/name
       |     =       +--ro matched-packets? =   = yang:counter64
       |     =       +--ro matched-octets?   =  yang:counter64
       +--rw = egress
          +--rw = acl-sets
            =  +--rw acl-set* [name]
              =   +--rw name           =    -> = /access-lists/acl/name
              =   +--rw type?         =     -> = /access-lists/acl/type
              =   +--ro ace-statistics* [name] = {interface-stats}?
              =      +--ro name       =         -> = /access-lists/acl/aces/ace/name
              =      +--ro matched-packets? =   = yang:counter64
              =      +--ro matched-octets?   =  yang:counter64

Comments welcome!

Cheers,

Einar



On 14 = Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:



On= 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Einar,

You had 3 questions for me on all the several e-mail = threads. 
1. Global attachment point
2. icmp-off
3. acl-aggregate-interface stats.

For (1), my first preference is to have the model define attachment point for interfaces only.

einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s = PR to = netmod-wg/acl-model that do this. Nearly like the augmentation I have below. Feel free to take a look at:

https://github.com/mjethanandani/acl-model/pull/3=

However, Kristian wants the global attachment point as well so that he can add the ACL to the linux tables.

einarnn> I think Kristian doesn=E2=80=99t = feel a global attachment point needs to be in this first revision. But he can = confirm.

If an ACL is attached globally, does this mean it is per direction or does it mean it is across = directions?

einarnn> I don=E2=80=99t = know right now = :-)

This global ACL may not be applicable to any of Cisco's service provider routers as I don't see any platform actually replicating the ACL to all line cards and attaching it in ingress and egress directions across all = interfaces.

einarnn> Per other emails, I = don=E2=80=99t think we understand this enough yet to specify it, so I suggest we just leave it out for now. Nothing in the model prevents a =E2=80=9Cglobal attachment point=E2=80=9D = being added later once we understand what it really means.

For (2), I am ok with removing = icmp-off.

einarnn> Done in my PR above.

For (3), this would have to be a combination of ACL stats across all interfaces for all ACL's. Something like this is possible on an XR box where ACES have counter names associated with it. Let's chat about this offline = tomorrow.

einarnn> I=E2=80=99ll = ping you to clarify, and we can bring any conclusion back to the = list.

Cheers,

Einar



Sonal.


On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal=E2= =80=9D attachment point down the line, and that =E2=80=9Cglobal=E2= =80=9D attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.
=
=

=
On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) = <einarnn@cisco.com> wrote:

=
Perhaps like this, as an augmentation to the interface:

=
  augment = /if:interfaces/if:interface:
=
    +--rw = ingress-acls
=
    | =  +--rw = acl-sets
=
    | =     +--rw acl-set* = [name]
=
    | =        +--rw = name       =        -> = /access-lists/acl/name
=
    | =        +--rw = type?       =       -> = /access-lists/acl/type
=
    | =        +--ro = ace-statistics* [name] = {interface-stats}?
=
    | =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
    | =           +--ro = matched-packets?   = yang:counter64
=
    | =           +--ro = matched-octets?   =  yang:counter64
=
    +--rw = egress-acls
=
      =  +--rw = acl-sets
=
      =     +--rw acl-set* = [name]
=
      =        +--rw = name       =        -> = /access-lists/acl/name
=
      =        +--rw = type?       =       -> = /access-lists/acl/type
=
      =        +--ro = ace-statistics* [name] = {interface-stats}?
=
      =           +--ro name =         =       -> = /access-lists/acl/aces/ace/name
=
      =           +--ro = matched-packets?   = yang:counter64
=
      =           +--ro = matched-octets?   =  yang:counter64

Could also put an =E2=80=9Caces=E2= =80=9D container above both these & rename = =E2=80=9Cingress-acls" to = =E2=80=9Cingress=E2=80=9D, etc. to give a single root for the augmentation if = preferred.

=
Cheers,

Einar


On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com> wrote:

=


On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
How does one move the interface attachment point, currently = an
'interface-ref', to an augmentation of the if:interfaces/interface,
inside of the =E2=80=98acl=E2=80= =99 =  container? Down the line we might need to have an
container for "attachment points" to accommodate the possibility = of
attaching an ACL either to an interface or = =E2=80=9Cglobally=E2=80=9D.


Keeping in mind that one use is that an ACL doesn't attach to = an
interface at all.

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


=
Mahesh = Jethanandani
mjethanandani@gmail.com

=

_______________________________________________
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<= br class=3D""> 



_______________________________________________
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<= br class=3D"">

Mahesh Jethanandani
mjethanandani@gmail.com



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


Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_42401CCB-3552-4FF5-AD98-AAEF1834FAA5-- From nobody Fri Jan 12 14:58:15 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 7641F128961; Fri, 12 Jan 2018 14:58:14 -0800 (PST) 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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151579789446.21777.985631371557420470@ietfa.amsl.com> Date: Fri, 12 Jan 2018 14:58:14 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 22:58:14 -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 : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-19.txt Pages : 35 Date : 2018-01-12 Abstract: This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "zzzz" --> the assigned RFC value for this draft The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-19 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-19 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 Fri Jan 12 15:09:07 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 9C45312AF83; Fri, 12 Jan 2018 15:08:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, The IESG , Joel Jaeggli , netmod@ietf.org, joelja@bogus.com, bclaise@cisco.com, draft-ietf-netmod-rfc7223bis@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151579853761.21825.17655942416834108037.idtracker@ietfa.amsl.com> Date: Fri, 12 Jan 2018 15:08:57 -0800 Archived-At: Subject: [netmod] Protocol Action: 'A YANG Data Model for Interface Management' to Proposed Standard (draft-ietf-netmod-rfc7223bis-03.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 23:08:58 -0000 The IESG has approved the following document: - 'A YANG Data Model for Interface Management' (draft-ietf-netmod-rfc7223bis-03.txt) as Proposed Standard This document is the product of the Network Modeling Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ Technical Summary This document defines a YANG [RFC7950] data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics). This version revised version of the interfaces data model supports the Network Management Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores]. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Working Group last call commenced on 28 Nov 2017 and completed 14 Dec 2017. Changes made to the document to produce -01 were largely editorial. Personnel Joel Jaeggli is the document shepherd, Benoit Claise is responsible AD. From nobody Fri Jan 12 15:25:30 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 BB49E126BF3; Fri, 12 Jan 2018 15:25:23 -0800 (PST) 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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151579952370.21786.5566343832383320089@ietfa.amsl.com> Date: Fri, 12 Jan 2018 15:25:23 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 23:25: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 : Network Management Datastore Architecture Authors : Martin Bjorklund Juergen Schoenwaelder Phil Shafer Kent Watsen Robert Wilton Filename : draft-ietf-netmod-revised-datastores-10.txt Pages : 39 Date : 2018-01-12 Abstract: Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-10 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-10 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 Fri Jan 12 19:49: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 F15E9124C27; Fri, 12 Jan 2018 19:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 oG4XmmnDwYhc; Fri, 12 Jan 2018 19:49:46 -0800 (PST) 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 73C381205F0; Fri, 12 Jan 2018 19:49:46 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9582F4E180AD6; Sat, 13 Jan 2018 03:49:42 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 13 Jan 2018 03:49:43 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sat, 13 Jan 2018 11:49:34 +0800 From: Qin Wu To: "netmod@ietf.org" , "joelja@bogus.com" CC: "draft-ietf-netmod-yang-tree-diagrams@ietf.org" Thread-Topic: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams Thread-Index: AQHTjCGGvO6NmcIERU2JzccfastGTQ== Date: Sat, 13 Jan 2018 03:49:34 +0000 Message-ID: References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan5a5981ce5fd2fe4577aQinWudeiPhone_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] =?gb2312?b?tPC4tDogICBSZW1pbmRlcjogV0dMQyAtIGRyYWZ0LWll?= =?gb2312?b?dGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcw==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 03:49:49 -0000 --_000_etPan5a5981ce5fd2fe4577aQinWudeiPhone_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiBhbmQgSSBmb3VuZCBubyBpc3N1ZSB3aXRoIGl0Lg0K DQoNClNlbnQgZnJvbSBIVUFXRUkgQW55T2ZmaWNlDQq3orz+yMujuiBqb2VsIGphZWdnbGkNCsrV vP7Iy6O6IE5FVE1PRCBXb3JraW5nIEdyb3VwOw0Ks63LzaO6IGRyYWZ0LWlldGYtbmV0bW9kLXlh bmctdHJlZS1kaWFncmFtc0BpZXRmLm9yZzsNCtb3zOKjuiBbbmV0bW9kXSBSZW1pbmRlcjogV0dM QyAtIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcw0KyrG85KO6IDIwMTgtMDEt MTEgMDA6MTc6MzINCg0KDQpKdXN0IGEgcmVtaW5kZXIgZ2l2ZW4gdGhlIGRhdGUgdGhhdCB0aGlz IHdhcyBwb3N0ZWQuIFRoaXMgbGFzdCBjYWxsIGlzDQpleHBlY3RlZCB0byBjb21wbGV0ZSBNb25k YXkgMS8xNS8xOC4NCg0KVGhhbmtzDQoNCmpvZWwNCg0KDQpPbiAxLzEvMTggMjowMSBQTSwgam9l bCBqYWVnZ2xpIHdyb3RlOg0KPiBHcmVldGluZ3MsDQo+DQo+IFdlIGhvcGUgIHRoZSBuZXcgeWVh ciBpcyBhIHRpbWUgdG8gbWFrZSBncmVhdCBwcm9nZXNzIG9uIG91dHN0YW5kaW5nDQo+IGRvY3Vt ZW50cyBiZWZvcmUgcHJlcGFyYXRpb24gZm9yIHRoZSAgTG9uZG9uIElFVEYgYmVnaW5zIGluIGVh cm5lc3QuDQo+DQo+IFRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNh bGwgb246DQo+DQo+ICBZQU5HIFRyZWUgRGlhZ3JhbXMNCj4gZHJhZnQtaWV0Zi1uZXRtb2QteWFu Zy10cmVlLWRpYWdyYW1zDQo+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcy8NCj4NCj4gUGxlYXNlIHNlbmQgZW1h aWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMuDQo+DQo+ IFdlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBzdGF0ZW1lbnRzIG9mIHRoZSBmb3Jt Og0KPg0KPiAgICogSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIG5vIGlzc3Vl cy4NCj4gICAqIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCB0aGUgZm9sbG93 aW5nIGlzc3VlczogLi4uDQo+DQo+DQo+IFRoYW5rIHlvdSwNCj4gTkVUTU9EIFdHIENoYWlycw0K Pg0KPg0KPg0KPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_etPan5a5981ce5fd2fe4577aQinWudeiPhone_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
The draft is well written and I fou= nd no issue with it.


Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BA joel jaeggli
=CA=D5=BC=FE=C8=CB=A3=BA NETMOD Working Group;
=B3=AD=CB=CD=A3=BA draft-ietf-netmod-yang-tree-diagrams@ietf.or= g;
=D6=F7=CC=E2=A3=BA [netmod] Reminder: WGLC - draft-ietf-netmod-= yang-tree-diagrams
=CA=B1=BC=E4=A3=BA 2018-01-11 00:17:32


Just a reminder given the date that this was poste= d. This last call is
expected to complete Monday 1/15/18.

Thanks

joel


On 1/1/18 2:01 PM, joel jaeggli wrote:
> Greetings,
>
> We hope  the new year is a time to make great progess on outstand= ing
> documents before preparation for the  London IETF begins in earne= st.
>
> This starts a two-week working group last call on:
>
>  YANG Tree Diagrams
> draft-ietf-netmod-yang-tree-diagrams
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/<= br> >
> Please send email to the list indicating your support or concerns.
>
> We are particularly interested in statements of the form:
>
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issue= s: ...
>
>
> Thank you,
> NETMOD WG Chairs
>
>
>
>


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod
 --_000_etPan5a5981ce5fd2fe4577aQinWudeiPhone_-- From nobody Sat Jan 13 05:04: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 56502129515; Sat, 13 Jan 2018 05:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 nje5aAy_SmNH; Sat, 13 Jan 2018 05:04:21 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D075127136; Sat, 13 Jan 2018 05:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xsjk3nV5MY25/qOKUaV7viwSoENTGXlQbrrZyC/BRec=; b=h80i1iOWgdl9ut27XAVUES45ToskoT82js1f2ewm6T8IPLNj+uP9/OmsW0eQ+ODE65vj7dCf/NWsg6nZEVz8AXsPy5X4UJAb2EP4VFktNaO/f6ckG79Q11LOX4rWgWpL3iQP7tzFXYTBPU/HW0sQcnra2VG29wBWWiSwkbaS/0I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.169.153.236) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Sat, 13 Jan 2018 13:04:18 +0000 Message-ID: <022301d38c6e$e2f0cf00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "NETMOD Working Group" , "joel jaeggli" Cc: References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> Date: Sat, 13 Jan 2018 13:00:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: HE1PR0502CA0008.eurprd05.prod.outlook.com (2603:10a6:3:e3::18) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 57936015-bf17-4abc-8315-08d55a862818 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:ewUIUL8npgyP/sYxZbJS1fGI/MMsqRPXmi/zBmZ6HKyHsUfgZXxPTpjYVusA/RrifN5RZAvc/tzEHX0qIQQPWSpYu3Fq5wy0kAoYp+opkBwa7S/biKUO7BAgfQJYPMFcz2708mx8i1E3QvulDkEOocuMjlHssOpBjgSWoCqwVTGDFD0ERubBKRMRa5+DSQgA3O+GUXyEVWfsEjwuZLofH+NaKyVxacZK5j0+OkkKd1GOvxBRkIw8Kw0zHe8skURU; 25:O0wMe2C7XLjGNxVbOLlhn2fC6u2oChce6/j2I7XCC0vqq/V+ARijmzbmSgKXziZYVlAA4TO9F7LwP9c/vAF9pM128hcxKTUZ1Ono4DGdC6LGVFjgIHBc9/HRl2eC7w0Uj/j/kTCkvC7NxqHRwANc0Av8tbgAnJ9oQZZW274tYRLXnqwWxht6OcSCW49zD9QGrfPwQ+mxB7/Lw4jOMCFFn4c8jw+OgO52D8Q/8c80gg3YVfvaAHtFg3m7B7jOQqPn9mdMJ/Ctfd/6jy6m80GnX2MXkonk1VtmMVYQNY9Qvny5BzxSEd6lJvOqgo4Uv6Qw2gdwAkKgO0qK4pYYQqvxkA==; 31:JLiqfbntA111x9Wb6D3Lhm7XWErZ65Wvl0SA5fpTKcob/2z7OjMeqlkwHWS855gRTYvtiv3srrZY3gnv7tlNOdehUE4EwRN/zyeT0Z713+0c1MPTGucuWOaFzpox/sDwRM67F8rtEcPLTtFzHT9pqpiSGQu2rZMW3pxR6NtcfTK+CsSkwdqJ5Xhgot6g90j6gvtgYnn8r+XEN2nGO/h4t6ukFNpcDODb11gzJX3z7Zg= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041268)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 4:s1xeD6IeZxRnzSdEWKPI9U4s7zKNp/P4RZd8tKpUU6di/27aR5QSCZoGNUbMCXzigNVP0p9g3JAeX+4lEsL/5bxAzdu43fG7FzS0zhNBVXcCSTqdeSRaKgWoCNMHJoOVcjeNYni3ea/fzaNkyOHQ3hy7suhBYcrm/Pk7aqr8i9paq73nowDyfxRHMDg6qA0GEiqqwont/Dvb73wvLuxaI2tSW27WAEGC2C5g4zzt9F/Qlb/CbGMdPciBTBsPl1fOxC5MEQhQwwFoHkHc+FdS+gE+0P9SCXrp2x+71T4WxpAwqdGwoHVBnWgY1qu6ame2 X-Forefront-PRVS: 05514B7026 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(39380400002)(346002)(396003)(189003)(199004)(51444003)(13464003)(61296003)(44736005)(1556002)(86362001)(106356001)(105586002)(50466002)(14496001)(230783001)(478600001)(966005)(2906002)(3846002)(6116002)(84392002)(6486002)(7736002)(230700001)(6306002)(9686003)(97736004)(305945005)(53936002)(316002)(110136005)(8676002)(229853002)(16526018)(47776003)(66066001)(62236002)(44716002)(68736007)(1456003)(8936002)(4326008)(50226002)(81156014)(81166006)(6246003)(386003)(5660300001)(4720700003)(25786009)(23676004)(81686011)(76176011)(59450400001)(2486003)(52116002)(6496006)(33896004)(81816011)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTc7MjM6dXdtcVRiaENtcTJ3OVhjTzd6UzJpN29Y?= =?utf-8?B?UjhHVkVMYXp5NmV6TlVPQW8vN0N3Y0IwK2FMS3Fad2xuUnNsQTE0ZzRUZm1O?= =?utf-8?B?WUsyamRaeENZbXFzdXkzTlVwNVBDWFNRUlV3amJod3hsZ243WDNSdTUrVHR1?= =?utf-8?B?Q1g2eUY3TmdQenNaTzBZc2xmODdRUjlFK2d4REpGUGhBV1BuSzRoRmRuYlZ6?= =?utf-8?B?c1VBR1BXTk1pRHliSFZ1akVMRGc0TmppU1RjUElDNHdEaHF3QzRydGNZUC9M?= =?utf-8?B?a2grSHVmQ3VzblZJWExWS3luSkFBeTVyMU5oQll6VU5UZnNZMWxEeDdyL1RD?= =?utf-8?B?T0pUTHNlVmtRWTI5aWtFZE5NaU9qRHRwTXp0Z0pnWmlZTVlLL29OV2tUMlVY?= =?utf-8?B?bGhhT0FGTUF1dVgvYk0venFFRTdVVDAxa2hLYWlOdlNCZTZGTXpET1NaUms2?= =?utf-8?B?RnQ1dkxqc25PWkQrcjZIRHROeUd2RjdDcG83VGJ3TWxSYVQ0NHZwVEx0Q3pT?= =?utf-8?B?OG9DR1BMc2JNS0dNRmh4cC9jVUhncVhSaGx4Y3lkaUJxdFF0UExjeVF2OVVo?= =?utf-8?B?Zmg0V1lZZkNDWWluNG9mdExoVFBiTncvSkIxM3VwN1hKWjVDeU1nYm14Ylhs?= =?utf-8?B?bmQrNy9zc3E3emM0bHlXeFV3bFEyMVdHeG8vZU5PZkhjZUtSRldUczI5YVpk?= =?utf-8?B?amlvMHRKVWNuN2s5aUpsS1VPUmlWeFhWM1JNZFF5d3RvamlRNnFoVFdQcnUr?= =?utf-8?B?SU5FYzRUS2ZPUFE0UlIrdnJIVC8xakhLNG1DM2QyNy8xMkNSdCtQNktncDBH?= =?utf-8?B?UGtSa1NzTmhFcEJQUS8xcDNONXlVdmoxQUl6azIrMFJaWERlcTI5UHdPS3Zs?= =?utf-8?B?ZStUNU5RRElTdFJIZldtejYrZkxrbFpQQ2NSakg4MU51MFM5OXVTZHc1T2RB?= =?utf-8?B?Z25MMVYzY2ZXWUI2aTAvUm1OaWZmM0Y2UklMazlGQjd3UHRpNUZlc3E3amFi?= =?utf-8?B?WGFVUUk4NnVDSFB5VmxmSGdxcGpuTGN2cFdlaUo2eWI5SHZaOW80bU9zV2sz?= =?utf-8?B?aFRmSDhUOFBBbS9iUTZGT2JIcFY4VWNSakdBSVdSZTE3bXpBVE9VdGZIUmtq?= =?utf-8?B?eVp4dmZiVUFJbDZNYkxrTFg4NUY2byt5Z3MwTXk0VzZka25xZjNMcUhVM3cv?= =?utf-8?B?RkNEeVQ2NDkzemQxdVd4Z1RWam1tWjBFZ1FtQXc2dnhFbUtDU29nOGlmSlVO?= =?utf-8?B?OFdsL0xpcU90bUh0bW9KalVmWUloUTZXcGQwMnhtRDBNeGZyczMwUWE3cHNq?= =?utf-8?B?aStkYndUeXowbkNCblkxeHBLamNoRGlOQWdGMVFDZFl5TzNyVWZMN2QxVHR1?= =?utf-8?B?dVN3Umg3VnJMdE1PdUlWK3ZlVlVvSkpkNWhKamV4TTV5YVZ1MDdjR2p0QWgz?= =?utf-8?B?SjlCOXlIL0pSRnd2ZkhYS1JGRnE0eTNPV3k2UzBMSFc0ZmZONlgrdnQvQlBF?= =?utf-8?B?RUFTTnNhK1dPRDh1SVJ0V0ltbUFQNVJjNnNYcnIvV2t6eXZ2d2c5SjlzN1FH?= =?utf-8?B?U2xkTDBxaUNyZUMxYWpuS0NYQUZkMG9wR1dvU010dTNWZkE4N2s2RHFBVUE2?= =?utf-8?B?QjV0ZVVlRElTMjRab0tvWjdmWlZVanNVd2RubWxEZnlZRGl5Q3ZpOG5WKzhK?= =?utf-8?B?bGRLNVJjZHFDV3dCa0RaQXNtdi9RcDdMNC9GOGVodlIrTXk4cWlrOGNsVjdn?= =?utf-8?B?aXZFbzIxWDlSZkhrODNZd0d1Sm1NeUtUZVJqREU0K1cveWJ2a2JSVlVDT294?= =?utf-8?B?ZW5TTnNkR01MNEc5STZqNE9tZlUyd1ZDSDM4MmhmSGZlc2doM0lLRnBrYjBJ?= =?utf-8?B?aFRtTjd6K2lOWDRIYkIyZFZaalZ0SzZTMm9uUEUrYVM4TStVV3VHbzV1S3VS?= =?utf-8?B?NnFMZEttdVJkSjRsTHR0S2lrblhZK2IvRFo4eGFHaUlvWUQzOWtjY3J6UkpL?= =?utf-8?Q?pPwwKZp6?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:idAbaRFcPrLfo6it4y6Y2tGTNYbJBci08oWZ7WAR9PqXG45C2Hq4BDKhzv7e7Mqxwdv8eWSeKilXevT2RVTg1AjzfdO9FEkL3iE78L50ErqyTDxw+UYVB2h78yqVfO4SqnzNonXqCqDAebZr0VdjLF6pXi/YAzBhvVUzn9g5wxpADYypKa5rF3vzLl/+cOJNMAm7Ixd18Fmj92P6P9WsrYiTAoTuOer0mJv2RrfN1ZNaW58uIJOQC3M2ANtOCh+4HFyshVQ+zcDfl9RYYJmsDccu4N3HZp+rOy3MUY8gQVdvfjkvYueASz4LEmFu1ppszR3n0YNxsMVmK6O94GIv1/tchGZrmEhElmh2nAFAqDc=; 5:QsDBcpLQkltlWdWXrqL6fyRkh/RyJ01tG4fitw7kCCEcdQ9/ww3z3MThLQAK8z6iuNP5QsHm48GMSTeeJe4QIvlTQiJXaqPu4OJTOlrQzF5HpmHMxE6E33uFtx8ME1PbE71n0GSwJ5LcTA6QSfhEp+xu5+wrq2aoKdDJKcwGZTc=; 24:NXwa9Kbiadu59Ez/Kxya9cmuM6M0cvvWax7x8vsy754onWiSOhZ6vPWTK8ggmlihZByfjOO6Jx9lh/gQ8L9NTJFTjYQ7k2JeBRsLd6bs/ZM=; 7:ar1n4N6Xr5AjopVazbMhaaiHE0HQQgQRZ8CKvaHVqu530S4CI4Ykr/23CwcOFZTyMP2PvdF01mMzVJ3B9jiVhzXQPBe28wkn1saJhKtc+IMvpJelE1z30Nt1pEdtaiTZXz2KSEIY1yr1CLsTXunNs3BOVRjI25m5WXjdd2xsIUbolLwnWOPQB1zvfRiXO1dTR0jFWXIuBrRvf9XrZb4KPby+zDkatGmlzlbBjvyaCd2b9Fkcz7goUcuTEoqXiDZi SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2018 13:04:18.1668 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 57936015-bf17-4abc-8315-08d55a862818 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997 Archived-At: Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 13:04:23 -0000 I think that the outstanding issue is what to do with long tree diagrams. Yes, we have discussed it and have a statement about one page being a good idea but very few of the I-Ds I see can manage that. RIP has four pages, NAT has six. OSPF and BFD have divided the diagram up but many if not most of the subdivisions still exceed one page (I would regard two as more or less ok but many exceed that). My own take is that a too long tree diagram reflects a too flat module structure, just as many years ago, code would be a long unbroken sequence and now is divided up into manageable modules, so a YANG module should be structured as smaller pieces, bite-size chunks, and a tree diagram of one page is a good indicator of a manageable chunk size. Tom Petch ----- Original Message ----- From: "joel jaeggli" Sent: Monday, January 01, 2018 10:01 PM Greetings, We hope the new year is a time to make great progess on outstanding documents before preparation for the London IETF begins in earnest. This starts a two-week working group last call on: YANG Tree Diagrams draft-ietf-netmod-yang-tree-diagrams https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ Please send email to the list indicating your support or concerns. We are particularly interested in statements of the form: * I have reviewed this draft and found no issues. * I have reviewed this draft and found the following issues: ... Thank you, NETMOD WG Chairs ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Sat Jan 13 06: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 AD99B12D7F9; Sat, 13 Jan 2018 06:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[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_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-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 nvUqmq0iP8rQ; Sat, 13 Jan 2018 06:08:32 -0800 (PST) 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 8E2D51274D2; Sat, 13 Jan 2018 06:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6917; q=dns/txt; s=iport; t=1515852510; x=1517062110; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9o2ZRYljFUzLNrN5QWHIbdVKh8SOIuR5tev6v8BtKqE=; b=QKBANeL+BoCIcAmk+s6SBbnQ3ooeWtTxkrlMfJ+vRRimxW/yJwkpY4kC K+XJNbgaBek+VaFPLgNbLJewIlPw96kurkZDzXGapI4D/MQ/jKkhcMS7D JXHgSL8krJ+Pb/RaY8IlJA26mI3wYleybPK6ojmiGO8JEhYWUs1urEMFW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQAHElpa/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJ3QnhBOLGI9vkVuFZYICChgBDIRHTwKFBBQBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBAQMBASFLCwwECxUBLAICJzAGAQwGAgEBii8QNK4jgicmihUBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEigxqDbIFpKYF3gQ6DLwEBAQEBAReBIwEPAwG?= =?us-ascii?q?DNheCTgWKVIIvlmGIDI0/ghmGHYNvh2uNPoFeiAmBPDYiEU9wMhoIGxU9giqEW?= =?us-ascii?q?EA3AQGLBYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.46,353,1511827200"; d="scan'208,217";a="1435470" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2018 14:08:28 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0DE8SHG008041; Sat, 13 Jan 2018 14:08:28 GMT To: "t.petch" , NETMOD Working Group , joel jaeggli Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> <022301d38c6e$e2f0cf00$4001a8c0@gateway.2wire.net> From: Benoit Claise Message-ID: <50492eeb-57ea-94dc-cb1d-0c52bda05750@cisco.com> Date: Sat, 13 Jan 2018 15:08:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <022301d38c6e$e2f0cf00$4001a8c0@gateway.2wire.net> Content-Type: multipart/alternative; boundary="------------9B8D4DDFAA96A45382EE9653" Content-Language: en-US Archived-At: Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 14:08:33 -0000 This is a multi-part message in MIME format. --------------9B8D4DDFAA96A45382EE9653 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tom, IMO, the best to proceed is exactly like done in the RIP draft. Some sections 2.* explains how the module was build, based one excerpts of the tree diagram. Then we have the full tree if someone wants to see the big structure. In the end, the tree view should be browsed with tooling. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/    => Yang catalog entry for ietf-rip@2018-01-09.yang    => [Tree View for ietf-rip] Tree View Regards, Benoit > I think that the outstanding issue is what to do with long tree > diagrams. Yes, we have discussed it and have a statement about one page > being a good idea but very few of the I-Ds I see can manage that. > > RIP has four pages, NAT has six. OSPF and BFD have divided the diagram > up but many if not most of the subdivisions still exceed one page (I > would regard two as more or less ok but many exceed that). > > My own take is that a too long tree diagram reflects a too flat module > structure, just as many years ago, code would be a long unbroken > sequence and now is divided up into manageable modules, so a YANG module > should be structured as smaller pieces, bite-size chunks, and a tree > diagram of one page is a good indicator of a manageable chunk size. > > Tom Petch > > ----- Original Message ----- > From: "joel jaeggli" > Sent: Monday, January 01, 2018 10:01 PM > > Greetings, > > We hope the new year is a time to make great progess on outstanding > documents before preparation for the London IETF begins in earnest. > > This starts a two-week working group last call on: > > YANG Tree Diagrams > draft-ietf-netmod-yang-tree-diagrams > > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ > > Please send email to the list indicating your support or concerns. > > We are particularly interested in statements of the form: > > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > > Thank you, > NETMOD WG Chairs > > > > > > > > ------------------------------------------------------------------------ > -------- > > >> _______________________________________________ >> 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 > . > --------------9B8D4DDFAA96A45382EE9653 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Tom,

IMO, the best to proceed is exactly like done in the RIP draft.
Some sections 2.* explains how the module was build, based one excerpts of the tree diagram.
Then we have the full tree if someone wants to see the big structure.

In the end, the tree view should be browsed with tooling.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
   => Yang catalog entry for ietf-rip@2018-01-09.yang
   => Tree View

Regards, Benoit
I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

Tom Petch

----- Original Message -----
From: "joel jaeggli" <joelja@bogus.com>
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs







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



_______________________________________________
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
.

--------------9B8D4DDFAA96A45382EE9653-- From nobody Mon Jan 15 01:13:54 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 2D83D127076 for ; Mon, 15 Jan 2018 01:13:53 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 1HkRskSDXDiV for ; Mon, 15 Jan 2018 01:13:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D903F12D880 for ; Mon, 15 Jan 2018 01:13:51 -0800 (PST) Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id EA6901AE0144; Mon, 15 Jan 2018 10:13:50 +0100 (CET) Date: Mon, 15 Jan 2018 10:13:50 +0100 (CET) Message-Id: <20180115.101350.1803615051443159645.mbj@tail-f.com> To: zhengguangying@huawei.com Cc: netmod@ietf.org, qudan.qudan@huawei.com From: Martin Bjorklund In-Reply-To: <381D7D55085B1E4D8B581BD652E1E140C92641FB@nkgeml513-mbs.china.huawei.com> References: <381D7D55085B1E4D8B581BD652E1E140C92641FB@nkgeml513-mbs.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] hi Martin, one issue about RFC7950 7.20.3.2. The "deviate" Statement, please help to confirm X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 09:13:53 -0000 Hi, This is an issue that has been reported before. It is tracked in https://github.com/netmod-wg/yang-next/issues/14. This said, I think in this particular case, where you define both the when expression and the if-feature leaf, I think the correct solution is to ensure that the when expression can handle the case that the leaf is not implemented (due to the if-feature). In this case, the when expression you have will be "true" if the node ../vrfAny is not implemented, which is what you want (I assume, since otherwise you should mark the node with the when expression with the same if-feature as ../vrfAny). /martin "Zhengguangying (Walker)" wrote: > Hi Martin, > > When we define YANG model's deviation file, we find one scenario was > nor supported but we have one problem depend on it. > > Our scenario: > In ACl YANG module, there have two leafs: > acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfName > acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfAny > > And the acl/aclGroups/aclGroup/aclRuleBas4s/ aclRuleBas4/vrfName have > one Constraints: when "not (../vrfAny = 'true')" > > > In some product domain, the "vrfAny" does not supported, some they > deviate the leaf "vrfAny". From the sematic view, the Constraints of > vrfName when "not (../vrfAny = 'true')" should be deviated as "delete" > too. > > But, in RFC7950 7.20.3.2. The "deviate" Statement , "when " is not > the Substatement of deviate, we can not deviate the when statement, > and the problem coming, some industry netconf tools compile fail > because "../vrfAny" does not exist. > > And there have some other scenario about "when" deviate, So, I think > whether the YANG language should add "when" as the Substatement of > deviate? > > What's your opinion? > > > Thanks & regards > > Walker(guangying zheng) > > > [cid:image001.png@01D38B9C.D7570600] > > From nobody Mon Jan 15 02:53: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 B28811205D3; Mon, 15 Jan 2018 02:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-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 12S-rY5ZLQZz; Mon, 15 Jan 2018 02:53:26 -0800 (PST) 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 D09E912DA4D; Mon, 15 Jan 2018 02:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11160; q=dns/txt; s=iport; t=1516013606; x=1517223206; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=dA2uVsf6pcEFh7UmEkU2+NL1r9KsSae9xDKO6v2LJHE=; b=My9ERS5aj37dkLUgFXJ0Bm3Smkdi718M11PbGCjAqXx8PfE4cM9GSMMD mrbEZCKsigFFn5MzJBf7Nf5LZr5OPsKI4Ej9xlkQbt9aXPRh9FDyAfnvU 9BqzkSPSxeiMgV/sd5nMuJBDXS9Xw/Sx7iXQaRK1mr3RwVu+8h4DeMPAU 0=; X-IronPort-AV: E=Sophos;i="5.46,363,1511827200"; d="scan'208,217";a="1459954" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 10:53:24 +0000 Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0FArNHo011273; Mon, 15 Jan 2018 10:53:23 GMT To: Benoit Claise , "t.petch" , NETMOD Working Group , joel jaeggli Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> <022301d38c6e$e2f0cf00$4001a8c0@gateway.2wire.net> <50492eeb-57ea-94dc-cb1d-0c52bda05750@cisco.com> From: Robert Wilton Message-ID: <7431e6e6-4a1f-a4db-59f3-093994c33934@cisco.com> Date: Mon, 15 Jan 2018 10:53:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <50492eeb-57ea-94dc-cb1d-0c52bda05750@cisco.com> Content-Type: multipart/alternative; boundary="------------300114B0A55A8AD6AD0B1930" Content-Language: en-US Archived-At: Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 10:53:28 -0000 This is a multi-part message in MIME format. --------------300114B0A55A8AD6AD0B1930 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I agree with all of Benoit's points below. On 13/01/2018 14:08, Benoit Claise wrote: > Hi Tom, > > IMO, the best to proceed is exactly like done in the RIP draft. > Some sections 2.* explains how the module was build, based one > excerpts of the tree diagram. Yes, smaller chunks of tree output can be very useful to explain parts of the model. > Then we have the full tree if someone wants to see the big structure. Yes, personally, I think that it is probably useful to have the full tree output as a reference (probably even if it is 10 pages long). If it is particularly long then it would be better put into an appendix. > > In the end, the tree view should be browsed with tooling. > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/ >    => Yang catalog entry for ietf-rip@2018-01-09.yang > >    => [Tree View for ietf-rip] Tree View > +1, having a GUI interface into YANG modules (and the combined YANG tree with all standard YANG models augmented together) seems like it should be the future. > > > Regards, Benoit >> I think that the outstanding issue is what to do with long tree >> diagrams. Yes, we have discussed it and have a statement about one page >> being a good idea but very few of the I-Ds I see can manage that. >> >> RIP has four pages, NAT has six. OSPF and BFD have divided the diagram >> up but many if not most of the subdivisions still exceed one page (I >> would regard two as more or less ok but many exceed that). >> >> My own take is that a too long tree diagram reflects a too flat module >> structure, just as many years ago, code would be a long unbroken >> sequence and now is divided up into manageable modules, so a YANG module >> should be structured as smaller pieces, bite-size chunks, and a tree >> diagram of one page is a good indicator of a manageable chunk size. I think its hard to judge whether a module is too flat or not. I'm more concerned that YANG groupings make it easy to repeat large chunks of YANG in multiple places in a module tree, and I'm not convinced that this is always the right thing to do.  Sometimes it may be better to add a layer of indrection to avoid the need to reuse the same large chunk of YANG in multiple places in the tree. Of course, this is all highly subjective ... Thanks, Rob >> >> Tom Petch >> >> ----- Original Message ----- >> From: "joel jaeggli" >> Sent: Monday, January 01, 2018 10:01 PM >> >> Greetings, >> >> We hope the new year is a time to make great progess on outstanding >> documents before preparation for the London IETF begins in earnest. >> >> This starts a two-week working group last call on: >> >> YANG Tree Diagrams >> draft-ietf-netmod-yang-tree-diagrams >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ >> >> Please send email to the list indicating your support or concerns. >> >> We are particularly interested in statements of the form: >> >> * I have reviewed this draft and found no issues. >> * I have reviewed this draft and found the following issues: ... >> >> >> Thank you, >> NETMOD WG Chairs >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> -------- >> >> >>> _______________________________________________ >>> 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 --------------300114B0A55A8AD6AD0B1930 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I agree with all of Benoit's points below.

On 13/01/2018 14:08, Benoit Claise wrote:
Hi Tom,

IMO, the best to proceed is exactly like done in the RIP draft.
Some sections 2.* explains how the module was build, based one excerpts of the tree diagram.
Yes, smaller chunks of tree output can be very useful to explain parts of the model.


Then we have the full tree if someone wants to see the big structure.
Yes, personally, I think that it is probably useful to have the full tree output as a reference (probably even if it is 10 pages long).  If it is particularly long then it would be better put into an appendix.


In the end, the tree view should be browsed with tooling.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
   => Yang catalog entry for ietf-rip@2018-01-09.yang
   => Tree View
+1, having a GUI interface into YANG modules (and the combined YANG tree with all standard YANG models augmented together) seems like it should be the future.



Regards, Benoit
I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.
I think its hard to judge whether a module is too flat or not.

I'm more concerned that YANG groupings make it easy to repeat large chunks of YANG in multiple places in a module tree, and I'm not convinced that this is always the right thing to do.  Sometimes it may be better to add a layer of indrection to avoid the need to reuse the same large chunk of YANG in multiple places in the tree.  Of course, this is all highly subjective ...

Thanks,
Rob



Tom Petch

----- Original Message -----
From: "joel jaeggli" <joelja@bogus.com>
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs







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



_______________________________________________
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

--------------300114B0A55A8AD6AD0B1930-- From nobody Mon Jan 15 05:56: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 2768D12D0C3; Mon, 15 Jan 2018 05:56:12 -0800 (PST) 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_RP_MATCHES_RCVD=-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 Yx7VSmqdwa1P; Mon, 15 Jan 2018 05:56:10 -0800 (PST) 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 A056412D574; Mon, 15 Jan 2018 05:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7009; q=dns/txt; s=iport; t=1516024570; x=1517234170; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=f9ohAF9PNkhf8ipSloFJBkmgVOivzxDZ2Aw85tiLQCE=; b=P1988XFvegskTAtt/nqeHxtrj1a8QrlTw04/HjJe62A9nANjbrodjnEr YRhjxWbW7SOPSwwXBs7XTssHjMAk03QpDECnGog6bj1ny+RN864WatPa2 n9SjvCHpFKUAq+QgICsc8lFGwDNiLx+ckxQe99sTtUP/oNNopOw/d3Usp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAQBcsFxa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgV10J4QTixiPbJFbhWWCAgoYAQqESU8ChRIUAQEBAQEBAQE?= =?us-ascii?q?BayiFJAEBAQMBASFLGwsYKgICJzAGAQwGAgEBii8QqjKCJyaKDgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhDyDbIFpKYMFgy8BAQIBAYE6AQ8DAYM2gmUFkieHS4l?= =?us-ascii?q?yiAyNP4IZhh2DbyaHRY0+gV6ICYE8NiJgcDIaCBsVPYIqhFdBN4l/gjwBAQE?= X-IronPort-AV: E=Sophos;i="5.46,363,1511827200"; d="scan'208,217";a="1463186" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 13:56:07 +0000 Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0FDu7vp000585; Mon, 15 Jan 2018 13:56:07 GMT To: joel jaeggli , NETMOD Working Group , draft-ietf-netmod-yang-tree-diagrams@ietf.org References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> From: Robert Wilton Message-ID: <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> Date: Mon, 15 Jan 2018 13:56:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DA38265615B0C7F0C6D4DFD7" Content-Language: en-US Archived-At: Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 13:56:12 -0000 This is a multi-part message in MIME format. --------------DA38265615B0C7F0C6D4DFD7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Lou, Martin I've done a quick review of draft -04. It looks well written to me. I have a spotted a few minor nits/questions. Section 1: (i) "Such diagrams are commonly used to provided " => "Such diagrams are used to provide"? (ii) "This document provides the syntax used in YANG Tree Diagrams." => "This document describes the syntax used in YANG Tree Diagrams", or if not "describes", perhaps "specifies"? (iii) "common practice is include" => "common practice is to include" Section 2: (iv) Are the top level data nodes really offset by 4 spaces, or should this be 2 spaces?  The example in section 2, and section 4 seem to differ here.  The submodule example in Sec 2.1 looks like it is using 2 spaces. (v) "is prefaces with" => "is prefaced with" (vi) Section 2.2, should there be an example of an unexpanded uses statement?  I was wondering if this section was under specified? Section 2.6: (vii) "If the node is augmented into the tree from another module, its name is printed as :."  Does there need to be a clarification that the prefix name used is the one used by the module's import statement?  Or does it use the prefix statement from the imported modules instead (I know that these should normally be the same, but this is not guaranteed). Section 3.2. (viii) It would be slightly easier to read if there wasn't a linebreak between "--" and "tree-print-groupings", not sure if that is feasible to force this. Thanks, Rob On 10/01/2018 16:16, joel jaeggli wrote: > Just a reminder given the date that this was posted. This last call is > expected to complete Monday 1/15/18. > > Thanks > > joel > > > On 1/1/18 2:01 PM, joel jaeggli wrote: >> Greetings, >> >> We hope the new year is a time to make great progess on outstanding >> documents before preparation for the London IETF begins in earnest. >> >> This starts a two-week working group last call on: >> >> YANG Tree Diagrams >> draft-ietf-netmod-yang-tree-diagrams >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ >> >> Please send email to the list indicating your support or concerns. >> >> We are particularly interested in statements of the form: >> >> * I have reviewed this draft and found no issues. >> * I have reviewed this draft and found the following issues: ... >> >> >> Thank you, >> NETMOD WG Chairs >> >> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------DA38265615B0C7F0C6D4DFD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Lou, Martin

I've done a quick review of draft -04.

It looks well written to me.

I have a spotted a few minor nits/questions.

Section 1:

(i) "Such diagrams are commonly used to provided " => "Such diagrams are used to provide"?

(ii) "This document provides the syntax used in YANG Tree Diagrams." => "This document describes the syntax used in YANG Tree Diagrams", or if not "describes", perhaps "specifies"?

(iii) "common practice is include" => "common practice is to include"

Section 2:
(iv) Are the top level data nodes really offset by 4 spaces, or should this be 2 spaces?  The example in section 2, and section 4 seem to differ here.  The submodule example in Sec 2.1 looks like it is using 2 spaces.

(v) "is prefaces with" => "is prefaced with"

(vi) Section 2.2, should there be an example of an unexpanded uses statement?  I was wondering if this section was under specified?

Section 2.6:
(vii) "If the node is augmented into the tree from another module, its name is printed as <prefix>:<name>."  Does there need to be a clarification that the prefix name used is the one used by the module's import statement?  Or does it use the prefix statement from the imported modules instead (I know that these should normally be the same, but this is not guaranteed).

Section 3.2.
(viii) It would be slightly easier to read if there wasn't a linebreak between "--" and "tree-print-groupings", not sure if that is feasible to force this.

Thanks,
Rob


    
On 10/01/2018 16:16, joel jaeggli
      wrote:

    

    

      
Just a reminder given the date that this was posted. This last call is
expected to complete Monday 1/15/18.

Thanks

joel


On 1/1/18 2:01 PM, joel jaeggli wrote:


      

        
Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs






      

      

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



    

    

  


--------------DA38265615B0C7F0C6D4DFD7--


From nobody Mon Jan 15 06:39: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 419E512D7EC; Mon, 15 Jan 2018 06:39:38 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0N-aTFOZSqu6; Mon, 15 Jan 2018 06:39:36 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37CBF12D7E2; Mon, 15 Jan 2018 06:39:36 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 23CDC1AE03DD; Mon, 15 Jan 2018 15:39:35 +0100 (CET)
Date: Mon, 15 Jan 2018 15:39:33 +0100 (CET)
Message-Id: <20180115.153933.1215610340924130656.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: joelja@bogus.com, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
From: Martin Bjorklund 
In-Reply-To: <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com>
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 14:39:38 -0000

Hi,

Thanks for the review!  Comments inline.

Robert Wilton  wrote:
> Hi Lou, Martin
> =

> I've done a quick review of draft -04.
> =

> It looks well written to me.
> =

> I have a spotted a few minor nits/questions.
> =

> Section 1:
> =

> (i) "Such diagrams are commonly used to provided " =3D> "Such diagram=
s
> are used to provide"?

Ok.

> (ii) "This document provides the syntax used in YANG Tree Diagrams."
> =3D> "This document describes the syntax used in YANG Tree Diagrams",=
 or
> if not "describes", perhaps "specifies"?

I changed to "describes".

> (iii) "common practice is include" =3D> "common practice is to includ=
e"

Ok.

> Section 2:
> (iv) Are the top level data nodes really offset by 4 spaces, or shoul=
d
> this be 2 spaces?=A0 The example in section 2, and section 4 seem to
> differ here.=A0 The submodule example in Sec 2.1 looks like it is usi=
ng
> 2 spaces.

It should be 4 spaces.  I fixed the example in 2.1.

> (v) "is prefaces with" =3D> "is prefaced with"

Ok.

> (vi) Section 2.2, should there be an example of an unexpanded uses
> statement?=A0 I was wondering if this section was under specified?

I have added:

   For example, the following diagram shows the "tls-transport" groupin=
g
   from [RFC7407] unexpanded:

       +--rw tls
          +---u tls-transport

   If the grouping is expanded, it could be printed as:

       +--rw tls
          +--rw port?                 inet:port-number
          +--rw client-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-identity?      snmp:admin-string

> Section 2.6:
> (vii) "If the node is augmented into the tree from another module, it=
s
> name is printed as :."=A0 Does there need to be a
> clarification that the prefix name used is the one used by the
> module's import statement?=A0 Or does it use the prefix statement fro=
m
> the imported modules instead (I know that these should normally be th=
e
> same, but this is not guaranteed).

Since this is used when a node is augmented *into* the main tree, it
can't be the prefix in import, since the augmenting module is not
imported from the augmented module.  I did:

OLD:

      If the node is augmented into the tree from another module,
      its name is printed as :.

NEW:

      If the node is augmented into the tree from another module,
      its name is printed as :, where  is the
      prefix defined in the module where the node is defined.

> Section 3.2.
> (viii) It would be slightly easier to read if there wasn't a linebrea=
k
> between "--" and "tree-print-groupings", not sure if that is feasible=

> to force this.

I don't think I can enforce this, but I'll look into it.  If nothing
else, the RFC editor will fix this.


/martin


> =

> Thanks,
> Rob
> =

> On 10/01/2018 16:16, joel jaeggli wrote:
> > Just a reminder given the date that this was posted. This last call=
 is
> > expected to complete Monday 1/15/18.
> >
> > Thanks
> >
> > joel
> >
> >
> > On 1/1/18 2:01 PM, joel jaeggli wrote:
> >> Greetings,
> >>
> >> We hope  the new year is a time to make great progess on outstandi=
ng
> >> documents before preparation for the  London IETF begins in earnes=
t.
> >>
> >> This starts a two-week working group last call on:
> >>
> >>   YANG Tree Diagrams
> >> draft-ietf-netmod-yang-tree-diagrams
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagr=
ams/
> >>
> >> Please send email to the list indicating your support or concerns.=

> >>
> >> We are particularly interested in statements of the form:
> >>
> >>    * I have reviewed this draft and found no issues.
> >>    * I have reviewed this draft and found the following issues: ..=
.=

> >>
> >>
> >> Thank you,
> >> NETMOD WG Chairs
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> =


From nobody Mon Jan 15 07:07: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 A049312D835; Mon, 15 Jan 2018 07:07:27 -0800 (PST)
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_RP_MATCHES_RCVD=-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 ijdOZWmgFutn; Mon, 15 Jan 2018 07:07:25 -0800 (PST)
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 EF4931204DA; Mon, 15 Jan 2018 07:07:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5843; q=dns/txt; s=iport; t=1516028845; x=1517238445; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=kV3drZFhEECPKt1J6FM05ICKOVUfkfOZaILWWMJLCSA=; b=cYkyfohSuX6mcDn/2E/k1Pnr78w5q9CixuxLzN+Ef+DEeDO4y9sEsXj8 qJPN1fVAGDVGZOrNVOPFD5LsvRkuVKaDBKVCbuM4ocL++Cl2lCSPgwbda tmqmAc8A5+hILXufLRCGf9f8nj1ZEbROuVh8NDN2exWmNAOcYmzTH6oCS o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAQBdw1xa/xbLJq1UCRoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGDEYEWdCeEE4sYj2yXQIICChgLhElPAoUUFAEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEDAQEBIQQLAQU2CxALDgoCAiYCAicwBg0GAgEBF4oQCBCqM4FtOolIAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEZBYEPhxmBaSmDBYMvAQECAQGBOgEIBwMBCYMtgmU?= =?us-ascii?q?FkieRPYgMjT+CGYYdg28mh0WNPoFeiAmBPDYiYHAyGggbFT2CKoJUHIFnQTeKU?= =?us-ascii?q?II8AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,364,1511827200";  d="scan'208";a="1417217"
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 Jan 2018 15:07:22 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0FF7M7T025636; Mon, 15 Jan 2018 15:07:22 GMT
To: Martin Bjorklund 
Cc: joelja@bogus.com, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
Date: Mon, 15 Jan 2018 15:07:22 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180115.153933.1215610340924130656.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 15:07:28 -0000

Hi Martin,

All OK with me except where I have further comments/questions inline below:

On 15/01/2018 14:39, Martin Bjorklund wrote:
> Hi,
>
> Thanks for the review!  Comments inline.
>
> Robert Wilton  wrote:
>> Hi Lou, Martin
>>
>> I've done a quick review of draft -04.
>>
>> It looks well written to me.
>>
>> I have a spotted a few minor nits/questions.
>>
>> Section 1:
>>
>> (i) "Such diagrams are commonly used to provided " => "Such diagrams
>> are used to provide"?
> Ok.
>
>> (ii) "This document provides the syntax used in YANG Tree Diagrams."
>> => "This document describes the syntax used in YANG Tree Diagrams", or
>> if not "describes", perhaps "specifies"?
> I changed to "describes".
>
>> (iii) "common practice is include" => "common practice is to include"
> Ok.
>
>> Section 2:
>> (iv) Are the top level data nodes really offset by 4 spaces, or should
>> this be 2 spaces?  The example in section 2, and section 4 seem to
>> differ here.  The submodule example in Sec 2.1 looks like it is using
>> 2 spaces.
> It should be 4 spaces.  I fixed the example in 2.1.
Hum, OK.  Is this the right choice?
  - It means that the tree is indented 2 spaces further than everything 
else (e.g. groupings, augments, etc).
  - YANG modules in RFC's already struggle with line length anyway, 
hence wouldn't the use of 2 spaces give the model a bit more space.

I also think that it would be good to check the indent of all the tree 
diagram snippets in the doc, it looks like they may be using somewhat 
varying levels of indents (between 2 and 6 spaces).


>
>> (v) "is prefaces with" => "is prefaced with"
> Ok.
>
>> (vi) Section 2.2, should there be an example of an unexpanded uses
>> statement?  I was wondering if this section was under specified?
> I have added:
>
>     For example, the following diagram shows the "tls-transport" grouping
>     from [RFC7407] unexpanded:
>
>         +--rw tls
>            +---u tls-transport
>
>     If the grouping is expanded, it could be printed as:
>
>         +--rw tls
>            +--rw port?                 inet:port-number
>            +--rw client-fingerprint?   x509c2n:tls-fingerprint
>            +--rw server-fingerprint?   x509c2n:tls-fingerprint
>            +--rw server-identity?      snmp:admin-string
Yes, looks good.

>
>> Section 2.6:
>> (vii) "If the node is augmented into the tree from another module, its
>> name is printed as :."  Does there need to be a
>> clarification that the prefix name used is the one used by the
>> module's import statement?  Or does it use the prefix statement from
>> the imported modules instead (I know that these should normally be the
>> same, but this is not guaranteed).
> Since this is used when a node is augmented *into* the main tree, it
> can't be the prefix in import, since the augmenting module is not
> imported from the augmented module.  I did:
But the YANG module must import the module that it is augmenting. If a 
local import prefix is used in the actual YANG module then it would be 
slightly harder to relate the tree output back to local import prefixes 
used in the YANG module.

>
> OLD:
>
>        If the node is augmented into the tree from another module,
>        its name is printed as :.
>
> NEW:
>
>        If the node is augmented into the tree from another module,
>        its name is printed as :, where  is the
>        prefix defined in the module where the node is defined.
This is OK with me, but there is still a potential for a prefix 
namespace clash (since prefixes are not guaranteed to be unique).

An alternative solution would be for the YANG tree diagram to list (at 
the beginning or the end of the diagram) the mappings from prefix -> 
module name used.  This has the bonus that it also explicitly lists the 
YANG modules that are being augmented, but conversely, this might end up 
just adding unnecessary noise to a diagram that should be short and 
simple ...

A second alternative would be to add some vague text to state that the 
prefix to module mapping should be explicitly listed in any cases where 
the prefix name alone is not obvious.

Thanks,
Rob


>
>> Section 3.2.
>> (viii) It would be slightly easier to read if there wasn't a linebreak
>> between "--" and "tree-print-groupings", not sure if that is feasible
>> to force this.
> I don't think I can enforce this, but I'll look into it.  If nothing
> else, the RFC editor will fix this.
>
>
> /martin
>
>
>> Thanks,
>> Rob
>>
>> On 10/01/2018 16:16, joel jaeggli wrote:
>>> Just a reminder given the date that this was posted. This last call is
>>> expected to complete Monday 1/15/18.
>>>
>>> Thanks
>>>
>>> joel
>>>
>>>
>>> On 1/1/18 2:01 PM, joel jaeggli wrote:
>>>> Greetings,
>>>>
>>>> We hope  the new year is a time to make great progess on outstanding
>>>> documents before preparation for the  London IETF begins in earnest.
>>>>
>>>> This starts a two-week working group last call on:
>>>>
>>>>    YANG Tree Diagrams
>>>> draft-ietf-netmod-yang-tree-diagrams
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>>>
>>>> Please send email to the list indicating your support or concerns.
>>>>
>>>> We are particularly interested in statements of the form:
>>>>
>>>>     * I have reviewed this draft and found no issues.
>>>>     * I have reviewed this draft and found the following issues: ...
>>>>
>>>>
>>>> Thank you,
>>>> NETMOD WG Chairs
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
> .
>


From nobody Mon Jan 15 07:20: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 8F6FE12D867; Mon, 15 Jan 2018 07:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AnuvsvHX9yIn; Mon, 15 Jan 2018 07:20:18 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8326712762F; Mon, 15 Jan 2018 07:20:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8778; q=dns/txt; s=iport; t=1516029618; x=1517239218; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qDd29z5Ha/cq5pj5H9xZtoJaQlGYY7+okW/nwLXLDgg=; b=clfOPJ7r9LcSge5vL80CQ0MUVQr+1Yhs4bgtZcOY7kPL4mszQyTDLjwM j85bp8dN3K79HShPIfrfDnXqilgfHai/k51d9LuvHbkfRCWFYwKJCV+4u kVtFuDJ6GfsvHJIOXU63NwensSn1Ok/EIW92ObFHiX7q+tjM09PFD5m5w 4=;
X-IronPort-AV: E=Sophos;i="5.46,364,1511827200"; d="scan'208";a="346548912"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 15:19:52 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w0FFJqbS011679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jan 2018 15:19:52 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 15 Jan 2018 10:19:51 -0500
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; Mon, 15 Jan 2018 10:19:51 -0500
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Martin Bjorklund 
CC: "netmod@ietf.org" , "draft-ietf-netmod-yang-tree-diagrams@ietf.org" 
Thread-Topic: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
Thread-Index: AQHTii5+kOM0Mut6PUiVQFAfLfsz8aN1UKKAgAAMI4CAAAfGAP//r52A
Date: Mon, 15 Jan 2018 15:19:51 +0000
Message-ID: 
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com> <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
In-Reply-To: <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <71A4A216B75F4B45B479D4D8A44C9C14@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 15:20:20 -0000

SGkgUm9iLCANCg0KT24gMS8xNS8xOCwgMTA6MDcgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIFJv
YmVydCBXaWx0b24gLVggKHJ3aWx0b24gLQ0KRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIiA8bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQpyd2lsdG9uQGNpc2NvLmNvbT4gd3Jv
dGU6DQoNCj5IaSBNYXJ0aW4sDQo+DQo+QWxsIE9LIHdpdGggbWUgZXhjZXB0IHdoZXJlIEkgaGF2
ZSBmdXJ0aGVyIGNvbW1lbnRzL3F1ZXN0aW9ucyBpbmxpbmUNCj5iZWxvdzoNCj4NCj5PbiAxNS8w
MS8yMDE4IDE0OjM5LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gVGhh
bmtzIGZvciB0aGUgcmV2aWV3ISAgQ29tbWVudHMgaW5saW5lLg0KPj4NCj4+IFJvYmVydCBXaWx0
b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+PiBIaSBMb3UsIE1hcnRpbg0KPj4+DQo+
Pj4gSSd2ZSBkb25lIGEgcXVpY2sgcmV2aWV3IG9mIGRyYWZ0IC0wNC4NCj4+Pg0KPj4+IEl0IGxv
b2tzIHdlbGwgd3JpdHRlbiB0byBtZS4NCj4+Pg0KPj4+IEkgaGF2ZSBhIHNwb3R0ZWQgYSBmZXcg
bWlub3Igbml0cy9xdWVzdGlvbnMuDQo+Pj4NCj4+PiBTZWN0aW9uIDE6DQo+Pj4NCj4+PiAoaSkg
IlN1Y2ggZGlhZ3JhbXMgYXJlIGNvbW1vbmx5IHVzZWQgdG8gcHJvdmlkZWQgIiA9PiAiU3VjaCBk
aWFncmFtcw0KPj4+IGFyZSB1c2VkIHRvIHByb3ZpZGUiPw0KPj4gT2suDQo+Pg0KPj4+IChpaSkg
IlRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIHN5bnRheCB1c2VkIGluIFlBTkcgVHJlZSBEaWFn
cmFtcy4iDQo+Pj4gPT4gIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBzeW50YXggdXNlZCBp
biBZQU5HIFRyZWUgRGlhZ3JhbXMiLCBvcg0KPj4+IGlmIG5vdCAiZGVzY3JpYmVzIiwgcGVyaGFw
cyAic3BlY2lmaWVzIj8NCj4+IEkgY2hhbmdlZCB0byAiZGVzY3JpYmVzIi4NCj4+DQo+Pj4gKGlp
aSkgImNvbW1vbiBwcmFjdGljZSBpcyBpbmNsdWRlIiA9PiAiY29tbW9uIHByYWN0aWNlIGlzIHRv
IGluY2x1ZGUiDQo+PiBPay4NCj4+DQo+Pj4gU2VjdGlvbiAyOg0KPj4+IChpdikgQXJlIHRoZSB0
b3AgbGV2ZWwgZGF0YSBub2RlcyByZWFsbHkgb2Zmc2V0IGJ5IDQgc3BhY2VzLCBvciBzaG91bGQN
Cj4+PiB0aGlzIGJlIDIgc3BhY2VzPyAgVGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAyLCBhbmQgc2Vj
dGlvbiA0IHNlZW0gdG8NCj4+PiBkaWZmZXIgaGVyZS4gIFRoZSBzdWJtb2R1bGUgZXhhbXBsZSBp
biBTZWMgMi4xIGxvb2tzIGxpa2UgaXQgaXMgdXNpbmcNCj4+PiAyIHNwYWNlcy4NCj4+IEl0IHNo
b3VsZCBiZSA0IHNwYWNlcy4gIEkgZml4ZWQgdGhlIGV4YW1wbGUgaW4gMi4xLg0KPkh1bSwgT0su
ICBJcyB0aGlzIHRoZSByaWdodCBjaG9pY2U/DQo+ICAtIEl0IG1lYW5zIHRoYXQgdGhlIHRyZWUg
aXMgaW5kZW50ZWQgMiBzcGFjZXMgZnVydGhlciB0aGFuIGV2ZXJ5dGhpbmcNCj5lbHNlIChlLmcu
IGdyb3VwaW5ncywgYXVnbWVudHMsIGV0YykuDQo+ICAtIFlBTkcgbW9kdWxlcyBpbiBSRkMncyBh
bHJlYWR5IHN0cnVnZ2xlIHdpdGggbGluZSBsZW5ndGggYW55d2F5LA0KPmhlbmNlIHdvdWxkbid0
IHRoZSB1c2Ugb2YgMiBzcGFjZXMgZ2l2ZSB0aGUgbW9kZWwgYSBiaXQgbW9yZSBzcGFjZS4NCj4N
Cj5JIGFsc28gdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBnb29kIHRvIGNoZWNrIHRoZSBpbmRlbnQg
b2YgYWxsIHRoZSB0cmVlDQo+ZGlhZ3JhbSBzbmlwcGV0cyBpbiB0aGUgZG9jLCBpdCBsb29rcyBs
aWtlIHRoZXkgbWF5IGJlIHVzaW5nIHNvbWV3aGF0DQo+dmFyeWluZyBsZXZlbHMgb2YgaW5kZW50
cyAoYmV0d2VlbiAyIGFuZCA2IHNwYWNlcykuDQoNCkkgYWdyZWUgLSBpdCBpcyBhbHJlYWR5IGhh
cmQgdG8gZml0IHRoZSB0cmVlIGRpYWdyYW1zIGludG8gUkZDcy4NCg0KVGhhbmtzLA0KQWNlZSAN
Cj4NCj4NCj4+DQo+Pj4gKHYpICJpcyBwcmVmYWNlcyB3aXRoIiA9PiAiaXMgcHJlZmFjZWQgd2l0
aCINCj4+IE9rLg0KPj4NCj4+PiAodmkpIFNlY3Rpb24gMi4yLCBzaG91bGQgdGhlcmUgYmUgYW4g
ZXhhbXBsZSBvZiBhbiB1bmV4cGFuZGVkIHVzZXMNCj4+PiBzdGF0ZW1lbnQ/ICBJIHdhcyB3b25k
ZXJpbmcgaWYgdGhpcyBzZWN0aW9uIHdhcyB1bmRlciBzcGVjaWZpZWQ/DQo+PiBJIGhhdmUgYWRk
ZWQ6DQo+Pg0KPj4gICAgIEZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIGRpYWdyYW0gc2hvd3Mg
dGhlICJ0bHMtdHJhbnNwb3J0Ig0KPj5ncm91cGluZw0KPj4gICAgIGZyb20gW1JGQzc0MDddIHVu
ZXhwYW5kZWQ6DQo+Pg0KPj4gICAgICAgICArLS1ydyB0bHMNCj4+ICAgICAgICAgICAgKy0tLXUg
dGxzLXRyYW5zcG9ydA0KPj4NCj4+ICAgICBJZiB0aGUgZ3JvdXBpbmcgaXMgZXhwYW5kZWQsIGl0
IGNvdWxkIGJlIHByaW50ZWQgYXM6DQo+Pg0KPj4gICAgICAgICArLS1ydyB0bHMNCj4+ICAgICAg
ICAgICAgKy0tcncgcG9ydD8gICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCj4+ICAg
ICAgICAgICAgKy0tcncgY2xpZW50LWZpbmdlcnByaW50PyAgIHg1MDljMm46dGxzLWZpbmdlcnBy
aW50DQo+PiAgICAgICAgICAgICstLXJ3IHNlcnZlci1maW5nZXJwcmludD8gICB4NTA5YzJuOnRs
cy1maW5nZXJwcmludA0KPj4gICAgICAgICAgICArLS1ydyBzZXJ2ZXItaWRlbnRpdHk/ICAgICAg
c25tcDphZG1pbi1zdHJpbmcNCj5ZZXMsIGxvb2tzIGdvb2QuDQo+DQo+Pg0KPj4+IFNlY3Rpb24g
Mi42Og0KPj4+ICh2aWkpICJJZiB0aGUgbm9kZSBpcyBhdWdtZW50ZWQgaW50byB0aGUgdHJlZSBm
cm9tIGFub3RoZXIgbW9kdWxlLCBpdHMNCj4+PiBuYW1lIGlzIHByaW50ZWQgYXMgPHByZWZpeD46
PG5hbWU+LiIgIERvZXMgdGhlcmUgbmVlZCB0byBiZSBhDQo+Pj4gY2xhcmlmaWNhdGlvbiB0aGF0
IHRoZSBwcmVmaXggbmFtZSB1c2VkIGlzIHRoZSBvbmUgdXNlZCBieSB0aGUNCj4+PiBtb2R1bGUn
cyBpbXBvcnQgc3RhdGVtZW50PyAgT3IgZG9lcyBpdCB1c2UgdGhlIHByZWZpeCBzdGF0ZW1lbnQg
ZnJvbQ0KPj4+IHRoZSBpbXBvcnRlZCBtb2R1bGVzIGluc3RlYWQgKEkga25vdyB0aGF0IHRoZXNl
IHNob3VsZCBub3JtYWxseSBiZSB0aGUNCj4+PiBzYW1lLCBidXQgdGhpcyBpcyBub3QgZ3VhcmFu
dGVlZCkuDQo+PiBTaW5jZSB0aGlzIGlzIHVzZWQgd2hlbiBhIG5vZGUgaXMgYXVnbWVudGVkICpp
bnRvKiB0aGUgbWFpbiB0cmVlLCBpdA0KPj4gY2FuJ3QgYmUgdGhlIHByZWZpeCBpbiBpbXBvcnQs
IHNpbmNlIHRoZSBhdWdtZW50aW5nIG1vZHVsZSBpcyBub3QNCj4+IGltcG9ydGVkIGZyb20gdGhl
IGF1Z21lbnRlZCBtb2R1bGUuICBJIGRpZDoNCj5CdXQgdGhlIFlBTkcgbW9kdWxlIG11c3QgaW1w
b3J0IHRoZSBtb2R1bGUgdGhhdCBpdCBpcyBhdWdtZW50aW5nLiBJZiBhDQo+bG9jYWwgaW1wb3J0
IHByZWZpeCBpcyB1c2VkIGluIHRoZSBhY3R1YWwgWUFORyBtb2R1bGUgdGhlbiBpdCB3b3VsZCBi
ZQ0KPnNsaWdodGx5IGhhcmRlciB0byByZWxhdGUgdGhlIHRyZWUgb3V0cHV0IGJhY2sgdG8gbG9j
YWwgaW1wb3J0IHByZWZpeGVzDQo+dXNlZCBpbiB0aGUgWUFORyBtb2R1bGUuDQo+DQo+Pg0KPj4g
T0xEOg0KPj4NCj4+ICAgICAgICBJZiB0aGUgbm9kZSBpcyBhdWdtZW50ZWQgaW50byB0aGUgdHJl
ZSBmcm9tIGFub3RoZXIgbW9kdWxlLA0KPj4gICAgICAgIGl0cyBuYW1lIGlzIHByaW50ZWQgYXMg
PHByZWZpeD46PG5hbWU+Lg0KPj4NCj4+IE5FVzoNCj4+DQo+PiAgICAgICAgSWYgdGhlIG5vZGUg
aXMgYXVnbWVudGVkIGludG8gdGhlIHRyZWUgZnJvbSBhbm90aGVyIG1vZHVsZSwNCj4+ICAgICAg
ICBpdHMgbmFtZSBpcyBwcmludGVkIGFzIDxwcmVmaXg+OjxuYW1lPiwgd2hlcmUgPHByZWZpeD4g
aXMgdGhlDQo+PiAgICAgICAgcHJlZml4IGRlZmluZWQgaW4gdGhlIG1vZHVsZSB3aGVyZSB0aGUg
bm9kZSBpcyBkZWZpbmVkLg0KPlRoaXMgaXMgT0sgd2l0aCBtZSwgYnV0IHRoZXJlIGlzIHN0aWxs
IGEgcG90ZW50aWFsIGZvciBhIHByZWZpeA0KPm5hbWVzcGFjZSBjbGFzaCAoc2luY2UgcHJlZml4
ZXMgYXJlIG5vdCBndWFyYW50ZWVkIHRvIGJlIHVuaXF1ZSkuDQo+DQo+QW4gYWx0ZXJuYXRpdmUg
c29sdXRpb24gd291bGQgYmUgZm9yIHRoZSBZQU5HIHRyZWUgZGlhZ3JhbSB0byBsaXN0IChhdA0K
PnRoZSBiZWdpbm5pbmcgb3IgdGhlIGVuZCBvZiB0aGUgZGlhZ3JhbSkgdGhlIG1hcHBpbmdzIGZy
b20gcHJlZml4IC0+DQo+bW9kdWxlIG5hbWUgdXNlZC4gIFRoaXMgaGFzIHRoZSBib251cyB0aGF0
IGl0IGFsc28gZXhwbGljaXRseSBsaXN0cyB0aGUNCj5ZQU5HIG1vZHVsZXMgdGhhdCBhcmUgYmVp
bmcgYXVnbWVudGVkLCBidXQgY29udmVyc2VseSwgdGhpcyBtaWdodCBlbmQgdXANCj5qdXN0IGFk
ZGluZyB1bm5lY2Vzc2FyeSBub2lzZSB0byBhIGRpYWdyYW0gdGhhdCBzaG91bGQgYmUgc2hvcnQg
YW5kDQo+c2ltcGxlIC4uLg0KPg0KPkEgc2Vjb25kIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGFk
ZCBzb21lIHZhZ3VlIHRleHQgdG8gc3RhdGUgdGhhdCB0aGUNCj5wcmVmaXggdG8gbW9kdWxlIG1h
cHBpbmcgc2hvdWxkIGJlIGV4cGxpY2l0bHkgbGlzdGVkIGluIGFueSBjYXNlcyB3aGVyZQ0KPnRo
ZSBwcmVmaXggbmFtZSBhbG9uZSBpcyBub3Qgb2J2aW91cy4NCj4NCj5UaGFua3MsDQo+Um9iDQo+
DQo+DQo+Pg0KPj4+IFNlY3Rpb24gMy4yLg0KPj4+ICh2aWlpKSBJdCB3b3VsZCBiZSBzbGlnaHRs
eSBlYXNpZXIgdG8gcmVhZCBpZiB0aGVyZSB3YXNuJ3QgYSBsaW5lYnJlYWsNCj4+PiBiZXR3ZWVu
ICItLSIgYW5kICJ0cmVlLXByaW50LWdyb3VwaW5ncyIsIG5vdCBzdXJlIGlmIHRoYXQgaXMgZmVh
c2libGUNCj4+PiB0byBmb3JjZSB0aGlzLg0KPj4gSSBkb24ndCB0aGluayBJIGNhbiBlbmZvcmNl
IHRoaXMsIGJ1dCBJJ2xsIGxvb2sgaW50byBpdC4gIElmIG5vdGhpbmcNCj4+IGVsc2UsIHRoZSBS
RkMgZWRpdG9yIHdpbGwgZml4IHRoaXMuDQo+Pg0KPj4NCj4+IC9tYXJ0aW4NCj4+DQo+Pg0KPj4+
IFRoYW5rcywNCj4+PiBSb2INCj4+Pg0KPj4+IE9uIDEwLzAxLzIwMTggMTY6MTYsIGpvZWwgamFl
Z2dsaSB3cm90ZToNCj4+Pj4gSnVzdCBhIHJlbWluZGVyIGdpdmVuIHRoZSBkYXRlIHRoYXQgdGhp
cyB3YXMgcG9zdGVkLiBUaGlzIGxhc3QgY2FsbCBpcw0KPj4+PiBleHBlY3RlZCB0byBjb21wbGV0
ZSBNb25kYXkgMS8xNS8xOC4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+DQo+Pj4+IGpvZWwNCj4+
Pj4NCj4+Pj4NCj4+Pj4gT24gMS8xLzE4IDI6MDEgUE0sIGpvZWwgamFlZ2dsaSB3cm90ZToNCj4+
Pj4+IEdyZWV0aW5ncywNCj4+Pj4+DQo+Pj4+PiBXZSBob3BlICB0aGUgbmV3IHllYXIgaXMgYSB0
aW1lIHRvIG1ha2UgZ3JlYXQgcHJvZ2VzcyBvbiBvdXRzdGFuZGluZw0KPj4+Pj4gZG9jdW1lbnRz
IGJlZm9yZSBwcmVwYXJhdGlvbiBmb3IgdGhlICBMb25kb24gSUVURiBiZWdpbnMgaW4gZWFybmVz
dC4NCj4+Pj4+DQo+Pj4+PiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFz
dCBjYWxsIG9uOg0KPj4+Pj4NCj4+Pj4+ICAgIFlBTkcgVHJlZSBEaWFncmFtcw0KPj4+Pj4gZHJh
ZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zDQo+Pj4+Pg0KPj4+Pj4gDQo+Pj4+Pmh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJl
ZS1kaWFncmFtcy8NCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBp
bmRpY2F0aW5nIHlvdXIgc3VwcG9ydCBvciBjb25jZXJucy4NCj4+Pj4+DQo+Pj4+PiBXZSBhcmUg
cGFydGljdWxhcmx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50cyBvZiB0aGUgZm9ybToNCj4+Pj4+
DQo+Pj4+PiAgICAgKiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBhbmQgZm91bmQgbm8gaXNz
dWVzLg0KPj4+Pj4gICAgICogSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIHRo
ZSBmb2xsb3dpbmcgaXNzdWVzOiAuLi4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmsgeW91LA0K
Pj4+Pj4gTkVUTU9EIFdHIENoYWlycw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4gLg0KPj4+Pg0KPj4gLg0KPj4N
Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5l
dG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Mon Jan 15 07:26:19 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 C0FBD12D95C for ; Mon, 15 Jan 2018 07:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 gsyUeD44QsDU for ; Mon, 15 Jan 2018 07:26:16 -0800 (PST)
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 768B112762F for ; Mon, 15 Jan 2018 07:26:16 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 14048175B9E for ; Mon, 15 Jan 2018 08:26:07 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id yfS31w00n2SSUrH01fS62n; Mon, 15 Jan 2018 08:26:07 -0700
X-Authority-Analysis: v=2.2 cv=CqXPSjwD c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=fC67E2oIJ13vzxDXsYYA:9 a=FJ2y6T8I_TDCZBPC:21 a=227dm0NZJxQOYM0q:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8LSbu5iPkRiDNdfCsEv8jBgLtB0Fu26wYW0XA7F4NyY=; b=XLOYN2Qr/gqDcUyc7rR2lREpEH y4xDFyV9Qf461srFi7fhpB4b04fh6yz/iE9VMIP/Aan35lat9ZGeKQbeTiyQzKF3bWJw4FCkgJr3g A3SmrD0DZKADvm0jtHtkc31yH;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39692 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eb6eB-000bFc-4X; Mon, 15 Jan 2018 08:26:03 -0700
To: Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com> <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
From: Lou Berger 
Message-ID: <101b0bbf-a943-a349-4d14-fe6d0b6b4e9c@labn.net>
Date: Mon, 15 Jan 2018 10:26:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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-Exim-ID: 1eb6eB-000bFc-4X
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:39692
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 15:26:18 -0000

Rob,
	Thanks for all the helpful feedback!

On 01/15/2018 10:07 AM, Robert Wilton wrote:
...

>> NEW:
>>
>>        If the node is augmented into the tree from another module,
>>        its name is printed as :, where  is the
>>        prefix defined in the module where the node is defined.
> This is OK with me, but there is still a potential for a prefix
> namespace clash (since prefixes are not guaranteed to be unique).
> 
> An alternative solution would be 
I don't we need to optimize for a every corner case.  We have the actual
module that provides detail.

> for the YANG tree diagram to list (at
> the beginning or the end of the diagram) the mappings from prefix ->
> module name used.  This has the bonus that it also explicitly lists the
> YANG modules that are being augmented, but conversely, this might end up
> just adding unnecessary noise to a diagram that should be short and
> simple ...

I think this falls in the category of unnecessary noise.  At least at
this time.

Lou
(as contributor)


From nobody Mon Jan 15 07:26: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 2279D12D963; Mon, 15 Jan 2018 07:26:32 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 nLLPMaXbMNnM; Mon, 15 Jan 2018 07:26:25 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4780A12D965; Mon, 15 Jan 2018 07:26:25 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 20F331AE03DD; Mon, 15 Jan 2018 16:26:24 +0100 (CET)
Date: Mon, 15 Jan 2018 16:26:23 +0100 (CET)
Message-Id: <20180115.162623.2008313631188177181.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: joelja@bogus.com, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
From: Martin Bjorklund 
In-Reply-To: <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
References: <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com> <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 15:26:32 -0000

Robert Wilton  wrote:
> Hi Martin,
> =

> All OK with me except where I have further comments/questions inline
> below:
> =

> On 15/01/2018 14:39, Martin Bjorklund wrote:
> > Hi,
> >
> > Thanks for the review!  Comments inline.
> >
> > Robert Wilton  wrote:
> >> Hi Lou, Martin
> >>
> >> I've done a quick review of draft -04.
> >>
> >> It looks well written to me.
> >>
> >> I have a spotted a few minor nits/questions.
> >>
> >> Section 1:
> >>
> >> (i) "Such diagrams are commonly used to provided " =3D> "Such diag=
rams
> >> are used to provide"?
> > Ok.
> >
> >> (ii) "This document provides the syntax used in YANG Tree Diagrams=
."
> >> =3D> "This document describes the syntax used in YANG Tree Diagram=
s", or
> >> if not "describes", perhaps "specifies"?
> > I changed to "describes".
> >
> >> (iii) "common practice is include" =3D> "common practice is to inc=
lude"
> > Ok.
> >
> >> Section 2:
> >> (iv) Are the top level data nodes really offset by 4 spaces, or sh=
ould
> >> this be 2 spaces?=A0 The example in section 2, and section 4 seem =
to
> >> differ here.=A0 The submodule example in Sec 2.1 looks like it is =
using
> >> 2 spaces.
> > It should be 4 spaces.  I fixed the example in 2.1.
> Hum, OK.=A0 Is this the right choice?
> =A0- It means that the tree is indented 2 spaces further than everyth=
ing
> else (e.g. groupings, augments, etc).

Well, I think it is consistent as it is now:

module: 
    +--
    |  +--
    |     +--
    +--
       +--
          +--

  augment :
    +--
       +--
       +--
          +--

Nodes are always intended 4 spaces.

> =A0- YANG modules in RFC's already struggle with line length anyway,
> hence wouldn't the use of 2 spaces give the model a bit more space.

This is a good argument.  I'm happy to save spaces by using 2 instead:

module: 
  +--
  |  +--
  |     +--
  +--
     +--
        +--

  augment :
  +--
     +--
     +--
        +--


> I also think that it would be good to check the indent of all the tre=
e
> diagram snippets in the doc, it looks like they may be using somewhat=

> varying levels of indents (between 2 and 6 spaces).

Ok.


> >> (v) "is prefaces with" =3D> "is prefaced with"
> > Ok.
> >
> >> (vi) Section 2.2, should there be an example of an unexpanded uses=

> >> statement?=A0 I was wondering if this section was under specified?=

> > I have added:
> >
> >     For example, the following diagram shows the "tls-transport" gr=
ouping
> >     from [RFC7407] unexpanded:
> >
> >         +--rw tls
> >            +---u tls-transport
> >
> >     If the grouping is expanded, it could be printed as:
> >
> >         +--rw tls
> >            +--rw port?                 inet:port-number
> >            +--rw client-fingerprint?   x509c2n:tls-fingerprint
> >            +--rw server-fingerprint?   x509c2n:tls-fingerprint
> >            +--rw server-identity?      snmp:admin-string
> Yes, looks good.
> =

> >
> >> Section 2.6:
> >> (vii) "If the node is augmented into the tree from another module,=
 its
> >> name is printed as :."=A0 Does there need to be a
> >> clarification that the prefix name used is the one used by the
> >> module's import statement?=A0 Or does it use the prefix statement =
from
> >> the imported modules instead (I know that these should normally be=
 the
> >> same, but this is not guaranteed).
> > Since this is used when a node is augmented *into* the main tree, i=
t
> > can't be the prefix in import, since the augmenting module is not
> > imported from the augmented module.  I did:
> But the YANG module must import the module that it is augmenting. If =
a
> local import prefix is used in the actual YANG module then it would b=
e
> slightly harder to relate the tree output back to local import
> prefixes used in the YANG module.

Here's an example:

module: ietf-interfaces
    +--rw interfaces
    |  +--rw interface* [name]
    |     +--rw name                        string
    ...
    |     +--rw ip:ipv4!

ietf-interfaces doesn't import ietf-ip, so there is no other prefix to
use for "ipv4" than the one defined in ietf-ip!

> > OLD:
> >
> >        If the node is augmented into the tree from another module,
> >        its name is printed as :.
> >
> > NEW:
> >
> >        If the node is augmented into the tree from another module,
> >        its name is printed as :, where  is th=
e
> >        prefix defined in the module where the node is defined.
> This is OK with me, but there is still a potential for a prefix
> namespace clash (since prefixes are not guaranteed to be unique).
> =

> An alternative solution would be for the YANG tree diagram to list (a=
t
> the beginning or the end of the diagram) the mappings from prefix ->
> module name used.

The tree diagram is supposed to give a simplified overview of the
structure of a module.  I agree with your statemenet below that such a
mappig adds noise...  I prefer to keep the diagram as is.


/martin


> This has the bonus that it also explicitly lists
> the YANG modules that are being augmented, but conversely, this might=

> end up just adding unnecessary noise to a diagram that should be shor=
t
> and simple ...
> =

> A second alternative would be to add some vague text to state that th=
e
> prefix to module mapping should be explicitly listed in any cases
> where the prefix name alone is not obvious.
> =

> Thanks,
> Rob
> =

> =

> >
> >> Section 3.2.
> >> (viii) It would be slightly easier to read if there wasn't a lineb=
reak
> >> between "--" and "tree-print-groupings", not sure if that is feasi=
ble
> >> to force this.
> > I don't think I can enforce this, but I'll look into it.  If nothin=
g
> > else, the RFC editor will fix this.
> >
> >
> > /martin
> >
> >
> >> Thanks,
> >> Rob
> >>
> >> On 10/01/2018 16:16, joel jaeggli wrote:
> >>> Just a reminder given the date that this was posted. This last ca=
ll is
> >>> expected to complete Monday 1/15/18.
> >>>
> >>> Thanks
> >>>
> >>> joel
> >>>
> >>>
> >>> On 1/1/18 2:01 PM, joel jaeggli wrote:
> >>>> Greetings,
> >>>>
> >>>> We hope  the new year is a time to make great progess on outstan=
ding
> >>>> documents before preparation for the  London IETF begins in earn=
est.
> >>>>
> >>>> This starts a two-week working group last call on:
> >>>>
> >>>>    YANG Tree Diagrams
> >>>> draft-ietf-netmod-yang-tree-diagrams
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-dia=
grams/
> >>>>
> >>>> Please send email to the list indicating your support or concern=
s.
> >>>>
> >>>> We are particularly interested in statements of the form:
> >>>>
> >>>>     * I have reviewed this draft and found no issues.
> >>>>     * I have reviewed this draft and found the following issues:=
 ...
> >>>>
> >>>>
> >>>> Thank you,
> >>>> NETMOD WG Chairs
> >>>>
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>> .
> >>>
> > .
> >
> =


From nobody Mon Jan 15 07:48:45 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 C0E5A12D7F4; Mon, 15 Jan 2018 07:48:43 -0800 (PST)
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_RP_MATCHES_RCVD=-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 S6M2J2tEEKVf; Mon, 15 Jan 2018 07:48:41 -0800 (PST)
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 DFDF112DA02; Mon, 15 Jan 2018 07:48:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8513; q=dns/txt; s=iport; t=1516031321; x=1517240921; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=aIMXhv76kIm0fzT8zH/8F5c92NrVj4QQbBA84fFznVE=; b=ix8iK3FDi8QEc9Ox4W1QPm8+z59tN1rcDr/6bClmHOFxhVEl9cDKWPXy wW79R+7zAbKzvX7NueC9bmS5Vb8hLsawDVdHhajXEE425gv+N7HYviQou /qman72tJNktCExCZIhc8KOGf76bu4JEtFbfwd8Od9xaAcKDycPqUKaod E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAQCSzFxa/xbLJq1UCRoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGEJ3QnhBOLGI9sfJZEggIKGAuESU8ChRQUAQEBAQEBAQEBayiFIwE?= =?us-ascii?q?BAQMBAQEhBAsBBTYLEAsOCgICJgICJzAGDQYCAQEXihAIEKo1gW06iUkBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARkFgQ+HGYFpKYF3WDaDLwEBAgEBgToBCAcDAQmDLYJ?= =?us-ascii?q?lBZInkT2IDI0/ghmGHYNvJodFjT6BXogJgTw2ImBwMhoIGxU9giqCVByBZ0E3i?= =?us-ascii?q?lCCPAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,364,1511827200";  d="scan'208";a="1417895"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 15:48:38 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0FFmcM1011231; Mon, 15 Jan 2018 15:48:38 GMT
To: Martin Bjorklund 
Cc: joelja@bogus.com, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com> <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com> <20180115.162623.2008313631188177181.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <5bbfb2b8-597c-1d19-0d4f-95f83c0ab4b5@cisco.com>
Date: Mon, 15 Jan 2018 15:48:38 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180115.162623.2008313631188177181.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 15:48:44 -0000

On 15/01/2018 15:26, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Martin,
>>
>> All OK with me except where I have further comments/questions inline
>> below:
>>
>> On 15/01/2018 14:39, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Thanks for the review!  Comments inline.
>>>
>>> Robert Wilton  wrote:
>>>> Hi Lou, Martin
>>>>
>>>> I've done a quick review of draft -04.
>>>>
>>>> It looks well written to me.
>>>>
>>>> I have a spotted a few minor nits/questions.
>>>>
>>>> Section 1:
>>>>
>>>> (i) "Such diagrams are commonly used to provided " => "Such diagrams
>>>> are used to provide"?
>>> Ok.
>>>
>>>> (ii) "This document provides the syntax used in YANG Tree Diagrams."
>>>> => "This document describes the syntax used in YANG Tree Diagrams", or
>>>> if not "describes", perhaps "specifies"?
>>> I changed to "describes".
>>>
>>>> (iii) "common practice is include" => "common practice is to include"
>>> Ok.
>>>
>>>> Section 2:
>>>> (iv) Are the top level data nodes really offset by 4 spaces, or should
>>>> this be 2 spaces?  The example in section 2, and section 4 seem to
>>>> differ here.  The submodule example in Sec 2.1 looks like it is using
>>>> 2 spaces.
>>> It should be 4 spaces.  I fixed the example in 2.1.
>> Hum, OK.  Is this the right choice?
>>   - It means that the tree is indented 2 spaces further than everything
>> else (e.g. groupings, augments, etc).
> Well, I think it is consistent as it is now:
>
> module: 
>      +--
>      |  +--
>      |     +--
>      +--
>         +--
>            +--
>
>    augment :
>      +--
>         +--
>         +--
>            +--
>
> Nodes are always intended 4 spaces.
Yes, agree that it is consistent, but personally I would also be happy 
for the nodes to be intended 2 spaces for the main tree, and then 4 
spaces for everything else (effectively 2 spaces beyond the 
augment/rpc/etc).

>
>>   - YANG modules in RFC's already struggle with line length anyway,
>> hence wouldn't the use of 2 spaces give the model a bit more space.
> This is a good argument.  I'm happy to save spaces by using 2 instead:
>
> module: 
>    +--
>    |  +--
>    |     +--
>    +--
>       +--
>          +--
>
>    augment :
>    +--
>       +--
>       +--
>          +--
I think that compact is better, if not quite so pretty, so this solution 
is also OK with me.

Personally, I quite like a relative indent, i.e. the tree is intended 2 
spaces more than its parent "thing", e.g.

module: 
   +--
   |  +--
   |     +--
   +--
      +--
         +--

   augment :
     +--
        +--
        +--
           +--


>
>> I also think that it would be good to check the indent of all the tree
>> diagram snippets in the doc, it looks like they may be using somewhat
>> varying levels of indents (between 2 and 6 spaces).
> Ok.
>
>
>>>> (v) "is prefaces with" => "is prefaced with"
>>> Ok.
>>>
>>>> (vi) Section 2.2, should there be an example of an unexpanded uses
>>>> statement?  I was wondering if this section was under specified?
>>> I have added:
>>>
>>>      For example, the following diagram shows the "tls-transport" grouping
>>>      from [RFC7407] unexpanded:
>>>
>>>          +--rw tls
>>>             +---u tls-transport
>>>
>>>      If the grouping is expanded, it could be printed as:
>>>
>>>          +--rw tls
>>>             +--rw port?                 inet:port-number
>>>             +--rw client-fingerprint?   x509c2n:tls-fingerprint
>>>             +--rw server-fingerprint?   x509c2n:tls-fingerprint
>>>             +--rw server-identity?      snmp:admin-string
>> Yes, looks good.
>>
>>>> Section 2.6:
>>>> (vii) "If the node is augmented into the tree from another module, its
>>>> name is printed as :."  Does there need to be a
>>>> clarification that the prefix name used is the one used by the
>>>> module's import statement?  Or does it use the prefix statement from
>>>> the imported modules instead (I know that these should normally be the
>>>> same, but this is not guaranteed).
>>> Since this is used when a node is augmented *into* the main tree, it
>>> can't be the prefix in import, since the augmenting module is not
>>> imported from the augmented module.  I did:
>> But the YANG module must import the module that it is augmenting. If a
>> local import prefix is used in the actual YANG module then it would be
>> slightly harder to relate the tree output back to local import
>> prefixes used in the YANG module.
> Here's an example:
>
> module: ietf-interfaces
>      +--rw interfaces
>      |  +--rw interface* [name]
>      |     +--rw name                        string
>      ...
>      |     +--rw ip:ipv4!
>
> ietf-interfaces doesn't import ietf-ip, so there is no other prefix to
> use for "ipv4" than the one defined in ietf-ip!
Ah, yes, OK.  I was assuming that the tree diagram would always be done 
from the augmenting module, but clearly that is not necessarily the case.


>
>>> OLD:
>>>
>>>         If the node is augmented into the tree from another module,
>>>         its name is printed as :.
>>>
>>> NEW:
>>>
>>>         If the node is augmented into the tree from another module,
>>>         its name is printed as :, where  is the
>>>         prefix defined in the module where the node is defined.
>> This is OK with me, but there is still a potential for a prefix
>> namespace clash (since prefixes are not guaranteed to be unique).
>>
>> An alternative solution would be for the YANG tree diagram to list (at
>> the beginning or the end of the diagram) the mappings from prefix ->
>> module name used.
> The tree diagram is supposed to give a simplified overview of the
> structure of a module.  I agree with your statemenet below that such a
> mappig adds noise...  I prefer to keep the diagram as is.
That is fine with me, really just raising so that the point could be 
discussed and closed.

Thanks,
Rob


>
>
> /martin
>
>
>> This has the bonus that it also explicitly lists
>> the YANG modules that are being augmented, but conversely, this might
>> end up just adding unnecessary noise to a diagram that should be short
>> and simple ...
>>
>> A second alternative would be to add some vague text to state that the
>> prefix to module mapping should be explicitly listed in any cases
>> where the prefix name alone is not obvious.
>>
>> Thanks,
>> Rob
>>
>>
>>>> Section 3.2.
>>>> (viii) It would be slightly easier to read if there wasn't a linebreak
>>>> between "--" and "tree-print-groupings", not sure if that is feasible
>>>> to force this.
>>> I don't think I can enforce this, but I'll look into it.  If nothing
>>> else, the RFC editor will fix this.
>>>
>>>
>>> /martin
>>>
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> On 10/01/2018 16:16, joel jaeggli wrote:
>>>>> Just a reminder given the date that this was posted. This last call is
>>>>> expected to complete Monday 1/15/18.
>>>>>
>>>>> Thanks
>>>>>
>>>>> joel
>>>>>
>>>>>
>>>>> On 1/1/18 2:01 PM, joel jaeggli wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> We hope  the new year is a time to make great progess on outstanding
>>>>>> documents before preparation for the  London IETF begins in earnest.
>>>>>>
>>>>>> This starts a two-week working group last call on:
>>>>>>
>>>>>>     YANG Tree Diagrams
>>>>>> draft-ietf-netmod-yang-tree-diagrams
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>>>>>
>>>>>> Please send email to the list indicating your support or concerns.
>>>>>>
>>>>>> We are particularly interested in statements of the form:
>>>>>>
>>>>>>      * I have reviewed this draft and found no issues.
>>>>>>      * I have reviewed this draft and found the following issues: ...
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>> NETMOD WG Chairs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> .
>>>>>
>>> .
>>>
> .
>


From nobody Mon Jan 15 09:44:53 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 90EBD12EAB8; Mon, 15 Jan 2018 09:44:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , Joel Jaeggli , netmod@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, joelja@bogus.com, bclaise@cisco.com, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151603827758.28475.11293059226407792681.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jan 2018 09:44:37 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'A YANG Data Model for IP Management' to Proposed Standard (draft-ietf-netmod-rfc7277bis-03.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 17:44:38 -0000

The IESG has approved the following document:
- 'A YANG Data Model for IP Management'
  (draft-ietf-netmod-rfc7277bis-03.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/





Technical Summary

   This document defines a YANG data model for management of IP
   implementations.  The data model includes configuration and system
   state.  This document obsoletes RFC 7277.

   The "ipv4" and "ipv6" subtrees with "config false" data nodes in the
   "/interfaces-state/interface" subtree are deprecated.  All "config
   false" data nodes are now present in the "ipv4" and "ipv6" subtrees
   in the "/interfaces/interface" subtree.

   Servers that do not implement NMDA (the Netconf Management 
   Datastore Architecture), or that wish to support client that do not 
   implement NMDA, MAY implement the deprecated "ipv4" and
   "ipv6" subtrees in the "/interfaces-state/interface" subtree.

Working Group Summary

Working Group last call commenced on  28 Nov 2017  and completed 
14 Dec  2017. Changes were largely editorial.  Vladimir Vassilev noted 
that updated implementations he was working with could validate the 
module and included examples. A bug was noted in the
ietf-netconf-datastores for which a correction was proposed.

Document Quality

There are known implementations that employ the rfc7277 data model
for ip manangement as well as the bis draft model.

Personnel

Joel Jaeggli is the document shepherd.
Benoit Claise is the responsible area director.


From nobody Mon Jan 15 09:56:15 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 8DED012EADE; Mon, 15 Jan 2018 09:56:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger ,  bclaise@cisco.com, lberger@labn.net, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151603897357.28602.8456150365441953158.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jan 2018 09:56:13 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'Network Management Datastore Architecture' to Proposed Standard (draft-ietf-netmod-revised-datastores-10.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 17:56:14 -0000

The IESG has approved the following document:
- 'Network Management Datastore Architecture'
  (draft-ietf-netmod-revised-datastores-10.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/





Technical Summary

   This document defines an architectural framework for datastores based
   on the experience gained with the initial simpler model, addressing
   requirements that were not well supported in the initial model.
   Datastores are a fundamental concept binding the data models written
   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document updates RFC 7950.

Working Group Summary

This work has occupied significant attention within the WG as well as
other organizations.  It is driving revision of all existing and
in-development YANG models. 

Document Quality

While it is unclear when vendors will be implementing revised
datastores, significant vendors and users have shown interest in this
work as well as willingness to support it by updating existing and
in-development models.

Personnel

   Lou Berger is the Document Shepherd?
   Benoit Claise is the Responsible Area  Director?


From nobody Mon Jan 15 10:23:37 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 5FB8F12EB15; Mon, 15 Jan 2018 10:23:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: netmod-chairs@ietf.org, bclaise@cisco.com, lberger@labn.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151604060135.28475.9618725760452859860.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jan 2018 10:23:21 -0800
Archived-At: 
Subject: [netmod] netmod - New Meeting Session Request for IETF 101
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 18:23:35 -0000

A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group.


---------------------------------------------------------
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2 Hours, 1.5 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf rtgwg
 Second Priority: teas i2rs anima
 Third Priority: saag isis ospf


People who must be present:
  Lou Berger
  Joel Jaeggli
  Benoit Claise
  Kent Watsen

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Mon Jan 15 12:42: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 A5555129C6E for ; Mon, 15 Jan 2018 12:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LQHKeszfmFEs for ; Mon, 15 Jan 2018 12:41:59 -0800 (PST)
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 0A09C12D77B for ; Mon, 15 Jan 2018 12:41:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7401E1442CC5 for ; Mon, 15 Jan 2018 21:41:56 +0100 (CET)
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 mJC_sJcmf-0x for ; Mon, 15 Jan 2018 21:41:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id DBF1B1442CC3 for ; Mon, 15 Jan 2018 21:41:55 +0100 (CET)
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 tmTRda4ZqiVR for ; Mon, 15 Jan 2018 21:41:55 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id B37391442CC1 for ; Mon, 15 Jan 2018 21:41:55 +0100 (CET)
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>
From: Vladimir Vassilev 
To: "netmod@ietf.org" 
Message-ID: 
Date: Mon, 15 Jan 2018 21:41:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 20:42:01 -0000

Hi,

I have reviewed and implemented (apart from schema mount specific=20
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found the=20
following issues:

=3D=3Dsec 2.6.=C2=A0 Node Representation=3D=3D

1. To correctly reflect the current pyang output one needs to add '--'=20
between  and .
OLD:
 =C2=A0=C2=A0=C2=A0      
NEW:
 =C2=A0=C2=A0=C2=A0 --    

There is also undocumented alignment space count function before =20
that pyang uses to align the  fields of child data leafs with=20
common ancestor. If this is specified in the draft the tree output can=20
be deterministic and for me this is an advantage. This is currently one=20
of the few underspecified pieces of the tree format so I had to check=20
pyang implementation in oder to generate same alignment space counts and=20
binary identical tree output results.


2. It is unclear which  option should be used for rpc and action=20
input/output and child nodes and the notification child nodes. pyang=20
uses '-w' for input and input/* and 'ro' for output and output/*:

 =C2=A0=C2=A0=C2=A0 module: ietf-netconf-partial-lock
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rpcs:
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---x partial-lock
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +---w input
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +---w select*=
=C2=A0=C2=A0 string
 =C2=A0=C2=A0=C2=A0 ...

pyang also uses '--' as  for augmentation data nodes for actions=20
input.

 =C2=A0=C2=A0=C2=A0 ...
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 augment /rt:routing-state/rt:ribs/rt:rib/=
rt:active-route/rt:input:
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---- destination-address?=C2=
=A0=C2=A0 inet:ipv4-address
 =C2=A0=C2=A0=C2=A0 ...


3. pyang is prefixing choice node names with the parent  e.g.=20
+--ro (next-hop-options) while case nodes are not prefixed. I guess this=20
is a bug in pyang since it is not specified in the draft but choice=20
nodes prefixed with parent  are=C2=A0 also present in the sec 4 an=
d=20
4.1 examples?

4. This bit I found confusing. I propose this change to unambiguously=20
describe the current pyang format.

OLD:
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-list=
 or list
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [] for a list's k=
eys
NEW:
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-list=
 or list without keys
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * [] for a list w=
ith keys

Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:
> Greetings,
>
> We hope  the new year is a time to make great progess on outstanding
> documents before preparation for the  London IETF begins in earnest.
>
> This starts a two-week working group last call on:
>
>   YANG Tree Diagrams
> draft-ietf-netmod-yang-tree-diagrams
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>
> Please send email to the list indicating your support or concerns.
>
> We are particularly interested in statements of the form:
>
>    * I have reviewed this draft and found no issues.
>    * I have reviewed this draft and found the following issues: ...
>
>
> Thank you,
> NETMOD WG Chairs


From nobody Mon Jan 15 13:20: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 8731312EC2F for ; Mon, 15 Jan 2018 13:20:32 -0800 (PST)
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 l6KjImobF0EO for ; Mon, 15 Jan 2018 13:20:29 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 8EA0512EC3B for ; Mon, 15 Jan 2018 13:20:29 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0FBDA1E0626 for ; Mon, 15 Jan 2018 14:20:26 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id ylLN1w00L2SSUrH01lLRTg; Mon, 15 Jan 2018 14:20:26 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=Y81ArVjFRdG0jJs3R1UA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:From:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WgomHMKbdBnFOUTlwQ8s+VJ727ORrtKiz8maVp0wigg=; b=vVkd15ZDSS6P5JBwHysKpB8v97 GxCG/uSj+Qj7I+cJGOactwN/PmGONLXo1akI6oiOJpyVjKL907RCtouLYbY0upGnbWkSlfMmCEcfY Vvt+i0o4d39VMm45Ih4M+IbHp;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:45426 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebCB4-002nqt-1d; Mon, 15 Jan 2018 14:20:22 -0700
To: Ladislav Lhotka , Martin Bjorklund 
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz>
From: Lou Berger 
Cc: NETMOD WG 
Message-ID: <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net>
Date: Mon, 15 Jan 2018 16:20:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1513690008.2479.70.camel@nic.cz>
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-Exim-ID: 1ebCB4-002nqt-1d
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]:45426
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 21:20:32 -0000

Lada/Martin,

I don't believe we reached closure on this discussion.  The open issues 
relate to proposed new text (slightly modified):

at the end of the section [3.2] adding a new paragraph along the
lines of:

   The use of mount points does not impact the nature of the
   mounted data or in which data store information is made
   available. For example, mounted YANG Library modules define
   only operational state data and, as such, the information in
   these modules is available from operational data stores using
   the appropriate protocol operations.  It is also worth
   noting that the Schema Mount module itself parallels the
   YANG Library module and only defines operational state data.

Is this change acceptable?

What other issues related to SM are outstanding?

Thank you,

Lou

On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>> Hi Lada,
>>>>
>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>> Lada,
>>>>>>
>>>>>>
>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka  wrote:
>>>>>>
>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>> lada,
>>>>>>>>
>>>>>>>>      See below.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>> library
>>>>>>>>> data
>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>> either
>>>>>>>>> because now under NMDA actions can be used only on instances in
>>>>>>>>> the
>>>>>>>>>  datastore.
>>>>>>>> but the inline/embedded library would (only) be present in the in
>>>>>>>> the
>>>>>>>> operational datastore, so what's the issue?
>>>>>>> Well, the issue is described in my initial mail of this thread: the
>>>>>>> current
>>>>>>> text
>>>>>>> requires that every instance of an inline mount point contains the
>>>>>>> embedded
>>>>>>> YANG library. Tha latter is state data, so the above requirement
>>>>>>> cannot
>>>>>>> be
>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>> datastore.
>>>>>>>
>>>>>> That's not how I read the intent of the current text.  I don't see SM
>>>>>> impacting which data stores information is presented.  Just like use
>>>>>> of
>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>> operational information.  I sent you a couple of sentences clarifying
>>>>>> this
>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>> Please do, this has to be discussed in the WG mailing list.
>>>> Agreed - that's why I asked to start this thread!
>>>>
>>>> Here's the original proposal:
>>>>
>>>>    How about at the end of the section [3.2] adding a new
>>>>    paragraph along the lines of:
>>>>
>>>>    It is important to note that both YANG Library and Schema
>>>>    Mount Modules contain only operational state data. As such,
>>> s/contain/define/
>>>
>>>>    the information in these modules should be retrieved by
>>>>    clients from operational data stores using the appropriate
>>> This is based on two assumptions:
>>>
>>> 1. For every configuration datastore there is a corresponding operational
>>> datastore.
>> well the text is revised below.  In any case, "these modules" refers to
>> yang library, and yes, I'm assuming YL is always and only in
>> operational.  If the revised text below isn't clear s/these/YANG Library/ -
> The thing is that we have the top-level YANG library in , and then
> embedded YANG libraries scattered inside inline mount point instances.
>
>>> 2. For every mount point instance in any configuration datastore there is a
>>> corresponding mount point instance (with the same path) in an operational
>>> datastore.
>>>
>>> I think that neither of these has to be true in general.
>> agreed in general, but for inline, where YL is required, it must be true.
> How do you know? I provided an example in Singapore where a mount point instance
> in  is a part of pre-provisioned data (for non-existent hardware).
> Then, according to the NMDA rules there is no corresponding instance in
> , hence no place where the embedded YANG library can be placed.
> (I can easily provide a concrete example if needed).
>
>
> Dean replied that this cannot happen, so it seems there are some assumptions how
> the inline method of schema mount may be applied. If so, these assumptions have
> to be explicitly stated.
>
>>>>    protocol operations.
>>> In contrast, the substance of my proposal with metadata annotations is to be
>>> able to retrieve all schemas from a well-known location in *the*
>>> 
>>> datastore, namely from the top-level YANG library.
>> What about a schema that is based on dll that contains modules that
>> isn't loaded until a mount point is instantiated -- this is certainly a
>> valid approach for supporting LNEs, but would be precluded in this
>> approach.  I really don't think a top level approach works for all
>> inline (managed) types of mounts.
> It isn't precluded: when the mount point is instantiated (no matter which
> datastore it is in), the server adds the schema as a new entry to the "schema"
> list in the top level YANG library (with a unique key), and annotates the mount
> point instance with a leafref pointing to that key. So different instances of
> the same mount point can have different schemas.
>
>>>> Given this discussion, we can generalize it further to:
>>>>
>>>>    The use of mount points does not impact the nature of the
>>>>    mounted data or in which data store information is made
>>>>    available. For example, mounted YANG Library modules contain
>>>>    only operational state data and, as such, the information in
>>>>    these modules is available from operational data stores using
>>>>    the appropriate protocol operations.
>>> The whole question here is whether and how we can locate the schema for an
>>> inline mount point in any configuration datastore.
>> Why is a mounted YL different than a top level YL?  What works for and
> It is not different, but it can be only in an operational datastores, and so for
> mount point instances inside configuration datastores we need a way how to
> locate the schema for that mount point, because it cannot be found directly
> under the mount point instance (as the current text assumes).
>
>> is sufficient for the normal case of YL shouldn't be impacted or
>> modified by SM -- at least that's how I thought we've been talking about
>> since SM was started.  Again, we never made any special provisions for
>> any other rw/ro/state data, assuming top level YL is not handled as
>> metadata, why start now?
>>
>> I'm getting the impression that your argument may be more about if YL
>> should be treated as something other than operational data, is this wrong?
> This is wrong. My argument is that there should be only one top-level YANG
> library (state data) and each inline mount point instance just points to a
> schema inside it by means of a metadata annotation attached to the mount point
> (in any datastore).
>
> Lada
>
>> Thanks,
>> Lou
>>
>>> Lada
>>>
>>>> Lou
>>>>
>>>>> Lada
>>>>>
>>>>>> Lou
>>>>>>>>> However, a good alternative seems to be a metadata annotation
>>>>>>>>> along
>>>>>>>>> the
>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>> newly
>>>>>>>>> proposed YANG library schema:
>>>>>>>>>
>>>>>>>>>       md:annotation schema-ref {
>>>>>>>>>         type leafref {
>>>>>>>>>           path "/yanglib:yang-
>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>         }
>>>>>>>>>       }
>>>>>>>>>
>>>>>>>>> In other words, all inline mounted schemas would be included in
>>>>>>>>> the
>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>> datastores
>>>>>>>>> would be annotated with leafref pointing to the actual schema.
>>>>>>>>>
>>>>>>>>> Unlike regular state data, it is IMO no problem to permit such
>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>
>>>>>>>>> Opinions?
>>>>>>>> I'm not sure this will work for all architectures of LNEs as well
>>>>>>>> as
>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>> restrictive.
>>>>>>> I don't understand, IMO it is not restrictive at all. What kind of
>>>>>>> restrictions
>>>>>>> do you see?
>>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>> Thanks, Lada
>>>>>>>>>
>>>>>>>>> Ladislav Lhotka  writes:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong for
>>>>>>>>>> traditional
>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>
>>>>>>>>>>     In case 1 ["inline"], the mounted schema is determined at
>>>>>>>>>> run
>>>>>>>>>> time:
>>>>>>>>>> every
>>>>>>>>>>     instance of the mount point that exists in the parent tree
>>>>>>>>>> MUST
>>>>>>>>>>     contain a copy of YANG library data [RFC7895] that defines
>>>>>>>>>> the
>>>>>>>>>>     mounted schema exactly as for a top-level data model.  A
>>>>>>>>>> client
>>>>>>>>>> is
>>>>>>>>>>     expected to retrieve this data from the instance tree,
>>>>>>>>>> possibly
>>>>>>>>>> after
>>>>>>>>>>     creating the mount point.  Instances of the same mount
>>>>>>>>>> point
>>>>>>>>>> MAY
>>>>>>>>>> use
>>>>>>>>>>     different mounted schemas.
>>>>>>>>>>
>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>> datastores
>>>>>>>>>> cannot
>>>>>>>>>> contain
>>>>>>>>>> YANG library (being state data), and so the MUST cannot hold.
>>>>>>>>>>
>>>>>>>>>> It is not clear to me how to repair this without considerable
>>>>>>>>>> complications
>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>> solution
>>>>>>>>>> but it
>>>>>>>>>> has
>>>>>>>>>> impact on YANG library: the server could provide it in a reply
>>>>>>>>>> to
>>>>>>>>>> an
>>>>>>>>>> operation,
>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>> everything
>>>>>>>>>> would be
>>>>>>>>>> fine
>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>> point,
>>>>>>>>>> and it
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>
>>>>>>>>>> So my proposal is to move from YANG library as state data to
>>>>>>>>>> an
>>>>>>>>>> operation.
>>>>>>>>>> It
>>>>>>>>>> could be done along with changing the YANG library structure,
>>>>>>>>>> so
>>>>>>>>>> there
>>>>>>>>>> will be
>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>
>>>>>>>>>> Lada
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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 Mon Jan 15 14:15: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 0642612ECB0 for ; Mon, 15 Jan 2018 14:15:18 -0800 (PST)
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 pmdiRdFyvfO5 for ; Mon, 15 Jan 2018 14:15:16 -0800 (PST)
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 02CBF12ECAF for ; Mon, 15 Jan 2018 14:15:15 -0800 (PST)
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 w0FMFDiB005976 for ; Mon, 15 Jan 2018 14:15:13 -0800
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=YSPwx2eZhY5oNPuheNAcgSMCDZxyHjlBhHhW/ChPGVU=; b=lxJ2w1Kjs/QM478A82Sl8GYJmmhSFPJFQ9dLv96u1b2o/PMaeB/lpczkDGbp/yxvIwse +1O/2IhXSWh804OP4KyQpZo03CRCfyyQ1Z9WAWFNSIwuS3nmTeJ/LL29lz/tK6b/WmK5 75K6z5OFvNLhJxv7I7ShiHjkMK9IDxZe8drGQnpCuIXITGo8N7CyVqZrg1GzLo/aAjgk TUKTessLkH5wizOKFvXrN6a8dXhs6mq4NbZ+9pE2tno0maQg5u67GTe+o/Z2DXmuXH6l JO3of+OYWtkbe/AbnpGNvG0m68loLoUhTg4X9b38bLBFwHfUD3FCyq8WsAAEuXC1Pyki lQ== 
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0019.outbound.protection.outlook.com [207.46.163.19]) by mx0b-00273201.pphosted.com with ESMTP id 2fh1d38dsg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 15 Jan 2018 14:15:13 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3579.namprd05.prod.outlook.com (10.174.242.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Mon, 15 Jan 2018 22:15:12 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Mon, 15 Jan 2018 22:15:12 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: rfc6087bis shepherd writeup issues
Thread-Index: AQHTjk5PObzC4gOr+kyp3emJqB/ObQ==
Date: Mon, 15 Jan 2018 22:15:12 +0000
Message-ID: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net>
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; DM5PR05MB3579; 7:owvU2ff8MlUjJTyynDlgiMvUMuBJaMbiSIjCFGmKhe8kHlB4ApZcV5oOc51mske7TnbZPjTRyA0CGVMwWNaBJ2dP62kyArTmrrizPvs0/gTByHhoOmdOGDiMwnCy7MJe7IW4vhyh6HFrRhRDvU7WoNDPZzNFo01FUugT+b5P0Kxt+T3zVANyOwGYtc0yMxsl/5QiW6b+RnJKx0b8c88ShAOgrWFTLdG8MUTvwZtI/adVMU7Tr8eeOukDNiUPKsxk
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a33dd7c8-14e7-4723-3d6d-08d55c657244
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3579; 
x-ms-traffictypediagnostic: DM5PR05MB3579:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(944501161)(10201501046)(3002001)(6055026)(6041268)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3579; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3579; 
x-forefront-prvs: 0553CBB77A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(396003)(39380400002)(51444003)(76104003)(199004)(189003)(53936002)(36756003)(5660300001)(2906002)(106356001)(478600001)(14454004)(105586002)(25786009)(2501003)(5640700003)(6916009)(68736007)(6512007)(2351001)(2900100001)(81166006)(81156014)(1730700003)(33656002)(8936002)(8676002)(26005)(6116002)(6486002)(77096006)(97736004)(6436002)(66066001)(7736002)(3660700001)(99286004)(305945005)(58126008)(316002)(86362001)(3280700002)(83506002)(6506007)(82746002)(59450400001)(102836004)(83716003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3579; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: LSCp8X/NFJSk9sCXTfzGZKR3oc+9NsGKOQ5s0wDUNsCNqLqe0jPPprhB8/9zGmILfdo96jOwDFaZrYuTerahXw==
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: a33dd7c8-14e7-4723-3d6d-08d55c657244
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 22:15:12.0851 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3579
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-15_09:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801150312
Archived-At: 
Subject: [netmod] rfc6087bis shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 22:15:18 -0000

SGkgQW5keSwNCg0KDQoxKSBiZWZvcmUgSSBmb3JnZXQsIGNvdWxkIHlvdSBwbGVhc2UgY29uZmly
bSBvbmUgbW9yZSB0aW1lICh0aGUgbGFzdCB0aW1lIGJlaW5nIGluIDIwMTYsIHNoZWVzaCEpIHRo
YXQgeW91IGFyZSB1bmF3YXJlIG9mIGFueSBJUFIgdGhhdCBuZWVkcyB0byBiZSBmaWxlZCBmb3Ig
dGhpcyBkcmFmdCwgYWNjb3JkaW5nIHRvIEJDUHMgNzggYW5kIDc5Pw0KDQoNCg0KMikgSWRuaXRz
IGZvdW5kIHRocmVlIHdhcm5pbmdzLCBvbmx5IHRoZSBmaXJzdCBtaWdodCByZXF1aXJlIHRob3Vn
aHQgZm9yIGhvdyBiZXN0IHRvIGZpeCBpdDoNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZD
NTM3OCcgaXMgZGVmaW5lZCBvbiBsaW5lIDI1MDIsIGJ1dCBubyBleHBsaWNpdA0KICAgICByZWZl
cmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQoNCiAgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBB
IGxhdGVyIHZlcnNpb24gKC0xMCkgZXhpc3RzIG9mDQogICAgIGRyYWZ0LWlldGYtbmV0bW9kLXJl
dmlzZWQtZGF0YXN0b3Jlcy0wNw0KDQogID09IE91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2
ZXJzaW9uICgtMDQpIGV4aXN0cyBvZg0KICAgICBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUt
ZGlhZ3JhbXMtMDINCg0KDQoNCjMpIGluIHRoZSBJbnRyb2R1Y3Rpb24sIHdvdWxkIHRoaXMgYmUg
YmV0dGVyPw0KIE9MRA0KICAgVGhlIHN0YW5kYXJkaXphdGlvbiBvZiBuZXR3b3JrIGNvbmZpZ3Vy
YXRpb24gaW50ZXJmYWNlcyBmb3IgdXNlIHdpdGgNCiAgICoqKnRoZSBOZXR3b3JrIENvbmZpZ3Vy
YXRpb24gUHJvdG9jb2wgW1JGQzYyNDFdIGFuZCBSRVNUQ09ORiBbUkZDODA0MF0qKioNCiAgIHJl
cXVpcmVzIGEgbW9kdWxhciBzZXQgb2YgZGF0YSBtb2RlbHMsIHdoaWNoIGNhbiBiZSByZXVzZWQg
YW5kDQogICBleHRlbmRlZCBvdmVyIHRpbWUuDQogTkVXDQogICBUaGUgc3RhbmRhcmRpemF0aW9u
IG9mIG5ldHdvcmsgY29uZmlndXJhdGlvbiBpbnRlcmZhY2VzIGZvciB1c2Ugd2l0aA0KICAgbmV0
d29yayBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQgcHJvdG9jb2xzLCBzdWNoIGFzIE5FVENPTkYg
W1JGQzYyNDFdDQogICBhbmQgUkVTVENPTkYgW1JGQzgwNDBdLCByZXF1aXJlcyBhIG1vZHVsYXIg
c2V0IG9mIGRhdGEgbW9kZWxzLCB3aGljaA0KICAgY2FuIGJlIHJldXNlZCBhbmQgZXh0ZW5kZWQg
b3ZlciB0aW1lLg0KDQoNCjQpIEluIHRoZSBuZXh0IHBhcmFncmFwaCwgc2hvdWxkICJzZXJ2ZXIi
IGJlIHF1YWxpZmllZD8NCiAgIEEgKk5FVENPTkYgb3IgUkVTVENPTkYqIHNlcnZlciB0aGF0IHN1
cHBvcnRzDQogICBhIHBhcnRpY3VsYXIgWUFORyBtb2R1bGUgd2lsbCBzdXBwb3J0IGNsaWVudCBO
RVRDT05GIGFuZC9vciBSRVNUQ09ORg0KICAgb3BlcmF0aW9uIHJlcXVlc3RzLCBhcyBpbmRpY2F0
ZWQgYnkgdGhlIHNwZWNpZmljIGNvbnRlbnQgZGVmaW5lZCBpbg0KICAgdGhlIFlBTkcgbW9kdWxl
Lg0KDQoNCjUpIFRoZSBuZXh0IHBhcmFncmFwaCBpcyBubyBsb25nZXIgYWNjdXJhdGUgYW5kLCBn
aXZlbiBpdHMgdmFsdWUgaXMgdW5sZXNzLCBtYXliZSBpdCBzaG91bGQgYmUgcmVtb3ZlZCBhbHRv
Z2V0aGVyPw0KIE9MRA0KICAgVGhpcyBkb2N1bWVudCBpcyBzaW1pbGFyIHRvIHRoZSBTdHJ1Y3R1
cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbg0KICAgdmVyc2lvbiAyIChTTUl2MikgdXNhZ2Ug
Z3VpZGVsaW5lcyBzcGVjaWZpY2F0aW9uIFtSRkM0MTgxXSBpbiBpbnRlbnQNCiAgIGFuZCBzdHJ1
Y3R1cmUuICBIb3dldmVyLCBzaW5jZSB0aGF0IGRvY3VtZW50IHdhcyB3cml0dGVuIGEgZGVjYWRl
DQogICBhZnRlciBTTUl2MiBtb2R1bGVzIGhhZCBiZWVuIGluIHVzZSwgaXQgd2FzIHB1Ymxpc2hl
ZCBhcyBhICdCZXN0DQogICBDdXJyZW50IFByYWN0aWNlJyAoQkNQKS4gIFRoaXMgZG9jdW1lbnQg
aXMgbm90IGEgQkNQLCBidXQgcmF0aGVyIGFuDQogICBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSwg
aW50ZW5kZWQgdG8gcHJvbW90ZSBjb25zaXN0ZW5jeSBpbiBkb2N1bWVudHMNCiAgIGNvbnRhaW5p
bmcgWUFORyBtb2R1bGVzLg0KDQoNCjYpIEluIHRoZSBuZXh0IHBhcmFncmFwaCwgc29tZXRoaW5n
IHNlZW1zIG9mZiB3aXRoIHRoZSAibWF5IHJlcXVpcmUiIGxhbmd1YWdlLiAgU2hvdWxkIGl0IGJl
IGp1c3QgInJlcXVpcmVzIiBvciBwZXJoYXBzICJlbnRhaWxzIj8gICBBbHNvLCBpcyBpdCByZWFs
bHkgdG8gIm1heGltaXplIGludGVyb3BlcmFiaWxpdHkgb2YgTkVUQ09ORiBhbmQgUkVTVENPTkYg
aW1wbGVtZW50YXRpb25zIiwgb3IgbW9yZSBqdXN0IHRvIG1ha2UgWUFORyBtb2R1bGVzIG1vcmUg
dXNlZnVsPw0KIE9MRA0KICAgTWFueSBZQU5HIGNvbnN0cnVjdHMgYXJlIGRlZmluZWQgYXMgb3B0
aW9uYWwgdG8gdXNlLCBzdWNoIGFzIHRoZQ0KICAgZGVzY3JpcHRpb24gc3RhdGVtZW50LiAgSG93
ZXZlciwgaW4gb3JkZXIgdG8gKioqbWF4aW1pemUNCiAgIGludGVyb3BlcmFiaWxpdHkgb2YgTkVU
Q09ORiBhbmQgUkVTVENPTkYgaW1wbGVtZW50YXRpb25zIHV0aWxpemluZw0KICAgWUFORyBkYXRh
IG1vZGVscyoqKiwgaXQgaXMgZGVzaXJhYmxlIHRvIGRlZmluZSBhIHNldCBvZiB1c2FnZSBndWlk
ZWxpbmVzDQogICB0aGF0ICoqKm1heSByZXF1aXJlKioqIGEgaGlnaGVyIGxldmVsIG9mIGNvbXBs
aWFuY2UgdGhhbiB0aGUgbWluaW11bSBsZXZlbA0KICAgZGVmaW5lZCBpbiB0aGUgWUFORyBzcGVj
aWZpY2F0aW9uLg0KDQoNCjcpIEluIHRoZSBUZXJtaW5vbG9neSBTZWN0aW9uLCBwbGVhc2UgYWRk
IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgODE3NCwgU2VjdGlvbiAyLiAgVGhlIGV4cGVj
dGVkIHJlc3VsdCBmb2xsb3dzOg0KICAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P
VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTA0KICAgICAgTk9UIiwgIlNIT1VMRCIsICJT
SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsDQogICAgICAiTUFZ
IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg
YXMNCiAgICAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBh
bmQgb25seSB3aGVuLCB0aGV5DQogICAgICBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93
biBoZXJlLg0KDQoNCjgpIFNob3VsZCB0aGUgcmVmZXJlbmNlIHRvIFJGQyA2OTkxIGJlIGluZm9y
bWF0aXZlIGluc3RlYWQ/DQoNCg0KOSkgVGhlIHJlZmVyZW5jZSB0byB0aGUgdHJlZS1kaWFncmFt
cyBkcmFmdCBiZWluZyBpbmZvcm1hdGl2ZSBjYXVnaHQgbXkgZXllLiBMb29raW5nIGludG8gaXQg
cmV2ZWFsZWQgbW9yZTogDQo5YSkgSSB0aGluayB0aGF0IFNlY3Rpb24gMi41LjEgc2hvdWxkIGJl
IGRlbGV0ZWQsIGFzIHRoZSBkcmFmdCBpdHNlbGYgZG9lcyBub3QgZGVmaW5lIGFueSB0cmVlIGRp
YWdyYW1zIG91dHNpZGUgb2Ygc2VjdGlvbnMgMy40LCB3aGljaCBhbHJlYWR5IGhhcyBhIHJlZmVy
ZW5jZSB0byB0aGF0IGRyYWZ0IChhcyBpdCBzaG91bGQpLiAgDQo5Yikgc2hvdWxkIHRoZSBndWlk
ZWxpbmVzIG1ha2UgdGhlIFNlY3Rpb24gMy4zIHJlY29tbWVuZGF0aW9uIGFueW1vcmU/ICAtIEkg
dGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgbWFpbiBiZW5lZml0cyBvZiBoYXZpbmcgdGhlIHRyZWUt
ZGlhZ3JhbXMgZHJhZnQgd2FzIHNvIHRoYXQgb3RoZXIgZHJhZnRzIGNvdWxkIGVhc2lseSBpbmxp
bmUtcmVmZXJlbmNlIGl0LCBzbyBhcyB0byBhdm9pZCBuZWVkaW5nIHRvIHNheSBhbnl0aGluZyBp
biB0aGVpciBUZXJtaW5vbG9neSBzZWN0aW9ucy4gIA0KOWMpIEkgdGhpbmsgU2VjdGlvbiAzLjQg
c2hvdWxkIDEpIHNheSB0aGF0IGRyYWZ0cyBzaG91bGQgcHJlZml4IGVhY2ggdHJlZS1kaWFncmFt
IHdpdGggYSAqbm9ybWF0aXZlKiByZWZlcmVuY2UgdG8gdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQg
YW5kIDIpIHVwZGF0ZSB0aGUgZXhhbXBsZSBpbGx1c3RyYXRpbmcgaG93IGl0IG1pZ2h0IGJlIGRv
bmUuDQo5ZCkgRmluYWxseSwgYmFjayB0byB0aGUgdHJlZS1kaWFncmFtcyBkcmFmdCBiZWluZyBp
bmZvcm1hdGl2ZSwgeWVzLCBJIGd1ZXNzIGl0IGlzIGluZm9ybWF0aXZlIGFmdGVyIGFsbC4gIGMn
ZXN0IGxhIHZpZSAgOykNCg0KDQoxMCkgU2hvdWxkIFNlY3Rpb24gOCAoQ2hhbmdlcyB0byBSRkMg
NjA4NykgYmUgbW92ZWQgdG8gdGhlIEludHJvZHVjdGlvbj8gIE5vdGUgdGhhdCB0aGUgc2hlcGhl
cmQgY2hlY2tsaXN0IHNheXMgIklmIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdl
cyB0aGUgc3RhdHVzIG9mIGFueSBleGlzdGluZyBSRkNzLCBhcmUgdGhvc2UgUkZDcyBsaXN0ZWQg
b24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBhbmQgYXJlIHRoZSBjaGFuZ2VzIGxpc3RlZCBpbiB0
aGUgYWJzdHJhY3QgYW5kIGRpc2N1c3NlZCAoZXhwbGFpbmVkLCBub3QganVzdCBtZW50aW9uZWQp
IGluIHRoZSBpbnRyb2R1Y3Rpb24/Ig0KDQoNCjExKSBJIHRoaW5rIHRoYXQgU2VjdGlvbiA2IChT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucykgc2hvdWxkIGJlIGxhcmdlbHkgbW92ZWQgaW50byBTZWN0
aW9uIDMuNy4gIEZvciB0aGlzIGRvY3VtZW50LCBTZWN0aW9uIDYgc2hvdWxkIHByb2JhYmx5IGp1
c3Qgc2F5IHNvbWV0aGluZyBsaWtlICJUaGlzIGRvY3VtZW50IG9ubHkgZGVmaW5lcyBndWlkZWxp
bmVzIGZvciBZQU5HIG1vZHVsZSBkZXNpZ25lcnMgYW5kIHRoZXJlZm9yZSBkb2VzIG5vdCBpdHNl
bGYgaGF2ZSBhbnkgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBuZWVkIHRvIGJlIGxpc3Rl
ZCBoZXJlLiIgIFdoYXQgZG8geW91IHRoaW5rPw0KDQoNClRoYW5rcywNCktlbnQgIC8vIHNoZXBo
ZXJkDQoNCg0KDQo=


From nobody Mon Jan 15 15:49:42 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 EF1AF12ECC5 for ; Mon, 15 Jan 2018 15:49:40 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 3t1KXMfT23en for ; Mon, 15 Jan 2018 15:49:38 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 D32CB12ECA3 for ; Mon, 15 Jan 2018 15:49:37 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id y71so15208569lfd.12 for ; Mon, 15 Jan 2018 15:49:37 -0800 (PST)
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=H9KJ3koTlby+89+xZYg2uP/wUcxOVsqgO6UQkTAoCwY=; b=VG5bAvA1KQhsXuhoGsA8VBMuoXPiMKYzXRyoAbz1BSR6p9Ozj1aLxdEmkYunAZrl+p oBGbqwp0nWbp+Wgj1mO/4MnPTiOQN92ucRScpb+e0fzEBnozcJXHuxalKfyWhf94/t3G dZdjARP7qnz7PFg5fL3029uVHHCa42UbATD5HBBCQ8AGKB2gNvicHny1m1jv2wIipL9Y dojzRF9DOi83vZdvIrxu7ywUr6BqeD0SHqD16nwpyM64VTNydbG94Zh9Niz43/7rxbyu UL6wQJ6hTuafPR7P8FPkr25IABXwzJ7y/cs4TwXUJXQ6G86WcpGVxEoajJPJZqKh3bCq 85xg==
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=H9KJ3koTlby+89+xZYg2uP/wUcxOVsqgO6UQkTAoCwY=; b=k3vGFCdEtK8muOQUeukeDsHBBHiDeEJ99nkWkL1D+9epSMFd7Na/FBR7v3fHTWfMG2 mzbnbeySPQit4WUmWav+xt1qBH57f+aW/XB5QIoqTSCIdIYu1duFSgjoJcSBDgdjNSdH TaaKKPcLb1T3GlTzzYbkZ4Gx49hCz9GT5nEU+QfFAhhwCFAHILwFgXxhUzGB2i5npnfT /vKF5xuDPfW9qQYtxOgTgthDrz315xIBqrc+XsI2HEhHhTLdt4MyyXYBl4MBkQhnGxO2 +Dn8mzhQ8SijZ+BRTVqWmpYiE3bSf1XeYKhv5kw2kxJmwy+O2PvHbJMr5lyeF3aG5wrf cYCg==
X-Gm-Message-State: AKwxytdA4Dw+JuzrAue9ZWaWY9TDGMBbEWBOjsxI5WR1izWv7swqhpCM 4lHROpXNNXThYm6R85KES9eSkGFuJJBY+zj1QHwzEw==
X-Google-Smtp-Source: ACJfBov7sXvqpzMY0eDZegBLhKAb69jvTgHIvp8/l/+Jr1ioOCQpzq3JxorKWLWSRl/0+ZtIfFSMXJ1JxPAavkDLv84=
X-Received: by 10.25.123.20 with SMTP id w20mr312801lfc.104.1516060176106; Mon, 15 Jan 2018 15:49:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.196.65 with HTTP; Mon, 15 Jan 2018 15:49:35 -0800 (PST)
In-Reply-To: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net>
References: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net>
From: Andy Bierman 
Date: Mon, 15 Jan 2018 15:49:35 -0800
Message-ID: 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082ed460415d960562d94426"
Archived-At: 
Subject: Re: [netmod] rfc6087bis shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jan 2018 23:49:41 -0000

--089e082ed460415d960562d94426
Content-Type: text/plain; charset="UTF-8"

Hi,

I am unaware of any IPR for the rfc6087bis draft


Andy


On Mon, Jan 15, 2018 at 2:15 PM, Kent Watsen  wrote:

> Hi Andy,
>
>
> 1) before I forget, could you please confirm one more time (the last time
> being in 2016, sheesh!) that you are unaware of any IPR that needs to be
> filed for this draft, according to BCPs 78 and 79?
>
>
>
> 2) Idnits found three warnings, only the first might require thought for
> how best to fix it:
>
>   == Unused Reference: 'RFC5378' is defined on line 2502, but no explicit
>      reference was found in the text
>
>   == Outdated reference: A later version (-10) exists of
>      draft-ietf-netmod-revised-datastores-07
>
>   == Outdated reference: A later version (-04) exists of
>      draft-ietf-netmod-yang-tree-diagrams-02
>
>
>
> 3) in the Introduction, would this be better?
>  OLD
>    The standardization of network configuration interfaces for use with
>    ***the Network Configuration Protocol [RFC6241] and RESTCONF
> [RFC8040]***
>    requires a modular set of data models, which can be reused and
>    extended over time.
>  NEW
>    The standardization of network configuration interfaces for use with
>    network configuration management protocols, such as NETCONF [RFC6241]
>    and RESTCONF [RFC8040], requires a modular set of data models, which
>    can be reused and extended over time.
>
>
> 4) In the next paragraph, should "server" be qualified?
>    A *NETCONF or RESTCONF* server that supports
>    a particular YANG module will support client NETCONF and/or RESTCONF
>    operation requests, as indicated by the specific content defined in
>    the YANG module.
>
>
> 5) The next paragraph is no longer accurate and, given its value is
> unless, maybe it should be removed altogether?
>  OLD
>    This document is similar to the Structure of Management Information
>    version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
>    and structure.  However, since that document was written a decade
>    after SMIv2 modules had been in use, it was published as a 'Best
>    Current Practice' (BCP).  This document is not a BCP, but rather an
>    informational reference, intended to promote consistency in documents
>    containing YANG modules.
>
>
> 6) In the next paragraph, something seems off with the "may require"
> language.  Should it be just "requires" or perhaps "entails"?   Also, is it
> really to "maximize interoperability of NETCONF and RESTCONF
> implementations", or more just to make YANG modules more useful?
>  OLD
>    Many YANG constructs are defined as optional to use, such as the
>    description statement.  However, in order to ***maximize
>    interoperability of NETCONF and RESTCONF implementations utilizing
>    YANG data models***, it is desirable to define a set of usage guidelines
>    that ***may require*** a higher level of compliance than the minimum
> level
>    defined in the YANG specification.
>
>
> 7) In the Terminology Section, please add a normative reference to RFC
> 8174, Section 2.  The expected result follows:
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>       "MAY", and "OPTIONAL" in this document are to be interpreted as
>       described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>       appear in all capitals, as shown here.
>
>
> 8) Should the reference to RFC 6991 be informative instead?
>
>
> 9) The reference to the tree-diagrams draft being informative caught my
> eye. Looking into it revealed more:
> 9a) I think that Section 2.5.1 should be deleted, as the draft itself does
> not define any tree diagrams outside of sections 3.4, which already has a
> reference to that draft (as it should).
> 9b) should the guidelines make the Section 3.3 recommendation anymore?  -
> I thought that one of the main benefits of having the tree-diagrams draft
> was so that other drafts could easily inline-reference it, so as to avoid
> needing to say anything in their Terminology sections.
> 9c) I think Section 3.4 should 1) say that drafts should prefix each
> tree-diagram with a *normative* reference to the tree-diagrams draft and 2)
> update the example illustrating how it might be done.
> 9d) Finally, back to the tree-diagrams draft being informative, yes, I
> guess it is informative after all.  c'est la vie  ;)
>
>
> 10) Should Section 8 (Changes to RFC 6087) be moved to the Introduction?
> Note that the shepherd checklist says "If publication of this document
> changes the status of any existing RFCs, are those RFCs listed on the title
> page header, and are the changes listed in the abstract and discussed
> (explained, not just mentioned) in the introduction?"
>
>
> 11) I think that Section 6 (Security Considerations) should be largely
> moved into Section 3.7.  For this document, Section 6 should probably just
> say something like "This document only defines guidelines for YANG module
> designers and therefore does not itself have any Security considerations
> that need to be listed here."  What do you think?
>
>
> Thanks,
> Kent  // shepherd
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I am unaware of any IPR for the rfc=
6087bis draft


Andy


On Mon,=
 Jan 15, 2018 at 2:15 PM, Kent Watsen <kwatsen@juniper.net> wrote:
Hi Andy,





1) before I forget, could you please confirm one more time (the last time b=
eing in 2016, sheesh!) that you are unaware of any IPR that needs to be fil=
ed for this draft, according to BCPs 78 and 79?







2) Idnits found three warnings, only the first might require thought for ho=
w best to fix it:



=C2=A0 =3D=3D Unused Reference: 'RFC5378' is defined on line 2502, =
but no explicit

=C2=A0 =C2=A0 =C2=A0reference was found in the text



=C2=A0 =3D=3D Outdated reference: A later version (-10) exists of

=C2=A0 =C2=A0 =C2=A0draft-ietf-netmod-revised-datastores-07



=C2=A0 =3D=3D Outdated reference: A later version (-04) exists of

=C2=A0 =C2=A0 =C2=A0draft-ietf-netmod-yang-tree-diagrams-02







3) in the Introduction, would this be better?

=C2=A0OLD

=C2=A0 =C2=A0The standardization of network configuration interfaces for us=
e with

=C2=A0 =C2=A0***the Network Configuration Protocol [RFC6241] and RESTCONF [=
RFC8040]***

=C2=A0 =C2=A0requires a modular set of data models, which can be reused and=


=C2=A0 =C2=A0extended over time.

=C2=A0NEW

=C2=A0 =C2=A0The standardization of network configuration interfaces for us=
e with

=C2=A0 =C2=A0network configuration management protocols, such as NETCONF [R=
FC6241]

=C2=A0 =C2=A0and RESTCONF [RFC8040], requires a modular set of data models,=
 which

=C2=A0 =C2=A0can be reused and extended over time.





4) In the next paragraph, should "server" be qualified?

=C2=A0 =C2=A0A *NETCONF or RESTCONF* server that supports

=C2=A0 =C2=A0a particular YANG module will support client NETCONF and/or RE=
STCONF

=C2=A0 =C2=A0operation requests, as indicated by the specific content defin=
ed in

=C2=A0 =C2=A0the YANG module.





5) The next paragraph is no longer accurate and, given its value is unless,=
 maybe it should be removed altogether?

=C2=A0OLD

=C2=A0 =C2=A0This document is similar to the Structure of Management Inform=
ation

=C2=A0 =C2=A0version 2 (SMIv2) usage guidelines specification [RFC4181] in =
intent

=C2=A0 =C2=A0and structure.=C2=A0 However, since that document was written =
a decade

=C2=A0 =C2=A0after SMIv2 modules had been in use, it was published as a =
9;Best

=C2=A0 =C2=A0Current Practice' (BCP).=C2=A0 This document is not a BCP,=
 but rather an

=C2=A0 =C2=A0informational reference, intended to promote consistency in do=
cuments

=C2=A0 =C2=A0containing YANG modules.





6) In the next paragraph, something seems off with the "may require&qu=
ot; language.=C2=A0 Should it be just "requires" or perhaps "=
;entails"?=C2=A0 =C2=A0Also, is it really to "maximize interopera=
bility of NETCONF and RESTCONF implementations", or more just to make =
YANG modules more useful?

=C2=A0OLD

=C2=A0 =C2=A0Many YANG constructs are defined as optional to use, such as t=
he

=C2=A0 =C2=A0description statement.=C2=A0 However, in order to ***maximize<=
br>
=C2=A0 =C2=A0interoperability of NETCONF and RESTCONF implementations utili=
zing

=C2=A0 =C2=A0YANG data models***, it is desirable to define a set of usage =
guidelines

=C2=A0 =C2=A0that ***may require*** a higher level of compliance than the m=
inimum level

=C2=A0 =C2=A0defined in the YANG specification.





7) In the Terminology Section, please add a normative reference to RFC 8174=
, Section 2.=C2=A0 The expected result follows:

=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL

=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT",=
 "RECOMMENDED", "NOT RECOMMENDED",

=C2=A0 =C2=A0 =C2=A0 "MAY", and "OPTIONAL" in this docu=
ment are to be interpreted as

=C2=A0 =C2=A0 =C2=A0 described in BCP 14 [RFC2119] [RFC8174] when, and only=
 when, they

=C2=A0 =C2=A0 =C2=A0 appear in all capitals, as shown here.





8) Should the reference to RFC 6991 be informative instead?





9) The reference to the tree-diagrams draft being informative caught my eye=
. Looking into it revealed more:

9a) I think that Section 2.5.1 should be deleted, as the draft itself does =
not define any tree diagrams outside of sections 3.4, which already has a r=
eference to that draft (as it should).

9b) should the guidelines make the Section 3.3 recommendation anymore?=C2=
=A0 - I thought that one of the main benefits of having the tree-diagrams d=
raft was so that other drafts could easily inline-reference it, so as to av=
oid needing to say anything in their Terminology sections.

9c) I think Section 3.4 should 1) say that drafts should prefix each tree-d=
iagram with a *normative* reference to the tree-diagrams draft and 2) updat=
e the example illustrating how it might be done.

9d) Finally, back to the tree-diagrams draft being informative, yes, I gues=
s it is informative after all.=C2=A0 c'est la vie=C2=A0 ;)





10) Should Section 8 (Changes to RFC 6087) be moved to the Introduction?=C2=
=A0 Note that the shepherd checklist says "If publication of this docu=
ment changes the status of any existing RFCs, are those RFCs listed on the =
title page header, and are the changes listed in the abstract and discussed=
 (explained, not just mentioned) in the introduction?"





11) I think that Section 6 (Security Considerations) should be largely move=
d into Section 3.7.=C2=A0 For this document, Section 6 should probably just=
 say something like "This document only defines guidelines for YANG mo=
dule designers and therefore does not itself have any Security consideratio=
ns that need to be listed here."=C2=A0 What do you think?





Thanks,

Kent=C2=A0 // shepherd







_______________________________________________

netmod mailing list

netmod@ietf.org

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




--089e082ed460415d960562d94426--


From nobody Mon Jan 15 23:14:16 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 6D2B212F4CC for ; Mon, 15 Jan 2018 23:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 w2vGNVUXZXUc for ; Mon, 15 Jan 2018 23:14:11 -0800 (PST)
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 DCDA212F4DA for ; Mon, 15 Jan 2018 23:14:10 -0800 (PST)
Received: from birdie (cst-prg-30-134.cust.vodafone.cz [46.135.30.134]) by mail.nic.cz (Postfix) with ESMTPSA id 87E6B641DC; Tue, 16 Jan 2018 08:14:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516086847; bh=5aV1bcjSGtN9ABFdMusBN59ie9TTRwzbYM69mwKVrrc=; h=From:To:Date; b=IgIBBOrL4TcviyRsE5Gw7A//UcM1/s9gDWhkVgOMaSnO0WWwEy7ZFMCMn9b2eqZM6 iWWzzBOlZvLEATWQEYGsx7kVgGyGrHdofXxOCCYqRwIdc6mpnp8rvnOsoT2US+be1x dTkGplsQC26zrJy/g6w4ttQnxrMPtIWwDdgeT8PE=
Message-ID: <1516086847.3188.24.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: NETMOD WG 
Date: Tue, 16 Jan 2018 08:14:07 +0100
In-Reply-To: <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 07:14:14 -0000

Hi Lou,

in my view, we should do the following two (significant) changes:

1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
list of mounted schemas, we should keep *all* mounted schemas directly in the
YANG library and refer to them from schema-mounts structures. Juergen suggested
this change and it is IMO the right thing to do.

2. Define a metadata annotation (e.g. @schema-ref) that would be required for
inline mount point instances and specify the inline-mounted schema also by
referring to a schema specified in YANG library.

The advantage of #2 is that an annotation can be attached equally well to both
state an configuration data. So, instead of papering over the issue that YANG
library (state data) cannot appear in configuration datastores, we can use this
general and straightforward approach. This also allows for defining different
mounted schemas for instances of the same mount point in different datastores.

I strongly believe that these changes (along with the new YANG library schema
and NMDA) make for a simple and elegant datastore architecture in which schema
mount would be an optional feature.

Lada 

 

On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> Lada/Martin,
> 
> I don't believe we reached closure on this discussion.  The open issues 
> relate to proposed new text (slightly modified):
> 
> at the end of the section [3.2] adding a new paragraph along the
> lines of:
> 
>    The use of mount points does not impact the nature of the
>    mounted data or in which data store information is made
>    available. For example, mounted YANG Library modules define
>    only operational state data and, as such, the information in
>    these modules is available from operational data stores using
>    the appropriate protocol operations.  It is also worth
>    noting that the Schema Mount module itself parallels the
>    YANG Library module and only defines operational state data.
> 
> Is this change acceptable?
> 
> What other issues related to SM are outstanding?
> 
> Thank you,
> 
> Lou
> 
> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > Hi Lada,
> > > > > 
> > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > Lada,
> > > > > > > 
> > > > > > > 
> > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka 
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > lada,
> > > > > > > > > 
> > > > > > > > >      See below.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > unfortunately, using an action for querying embedded YANG
> > > > > > > > > > library
> > > > > > > > > > data
> > > > > > > > > > (needed for the "inline" case of schema mount) doesn't work
> > > > > > > > > > either
> > > > > > > > > > because now under NMDA actions can be used only on instances
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > >  datastore.
> > > > > > > > > 
> > > > > > > > > but the inline/embedded library would (only) be present in the
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > 
> > > > > > > > Well, the issue is described in my initial mail of this thread:
> > > > > > > > the
> > > > > > > > current
> > > > > > > > text
> > > > > > > > requires that every instance of an inline mount point contains
> > > > > > > > the
> > > > > > > > embedded
> > > > > > > > YANG library. Tha latter is state data, so the above requirement
> > > > > > > > cannot
> > > > > > > > be
> > > > > > > > satisfied if the mount point instance is in a configuration
> > > > > > > > datastore.
> > > > > > > > 
> > > > > > > 
> > > > > > > That's not how I read the intent of the current text.  I don't see
> > > > > > > SM
> > > > > > > impacting which data stores information is presented.  Just like
> > > > > > > use
> > > > > > > of
> > > > > > > scheme mount doesn't transform RO configuration information into
> > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > clarifying
> > > > > > > this
> > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > 
> > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > 
> > > > > Agreed - that's why I asked to start this thread!
> > > > > 
> > > > > Here's the original proposal:
> > > > > 
> > > > >    How about at the end of the section [3.2] adding a new
> > > > >    paragraph along the lines of:
> > > > > 
> > > > >    It is important to note that both YANG Library and Schema
> > > > >    Mount Modules contain only operational state data. As such,
> > > > 
> > > > s/contain/define/
> > > > 
> > > > >    the information in these modules should be retrieved by
> > > > >    clients from operational data stores using the appropriate
> > > > 
> > > > This is based on two assumptions:
> > > > 
> > > > 1. For every configuration datastore there is a corresponding
> > > > operational
> > > > datastore.
> > > 
> > > well the text is revised below.  In any case, "these modules" refers to
> > > yang library, and yes, I'm assuming YL is always and only in
> > > operational.  If the revised text below isn't clear s/these/YANG Library/
> > > -
> > 
> > The thing is that we have the top-level YANG library in , and
> > then
> > embedded YANG libraries scattered inside inline mount point instances.
> > 
> > > > 2. For every mount point instance in any configuration datastore there
> > > > is a
> > > > corresponding mount point instance (with the same path) in an
> > > > operational
> > > > datastore.
> > > > 
> > > > I think that neither of these has to be true in general.
> > > 
> > > agreed in general, but for inline, where YL is required, it must be true.
> > 
> > How do you know? I provided an example in Singapore where a mount point
> > instance
> > in  is a part of pre-provisioned data (for non-existent hardware).
> > Then, according to the NMDA rules there is no corresponding instance in
> > , hence no place where the embedded YANG library can be placed.
> > (I can easily provide a concrete example if needed).
> > 
> > 
> > Dean replied that this cannot happen, so it seems there are some assumptions
> > how
> > the inline method of schema mount may be applied. If so, these assumptions
> > have
> > to be explicitly stated.
> > 
> > > > >    protocol operations.
> > > > 
> > > > In contrast, the substance of my proposal with metadata annotations is
> > > > to be
> > > > able to retrieve all schemas from a well-known location in *the*
> > > > 
> > > > datastore, namely from the top-level YANG library.
> > > 
> > > What about a schema that is based on dll that contains modules that
> > > isn't loaded until a mount point is instantiated -- this is certainly a
> > > valid approach for supporting LNEs, but would be precluded in this
> > > approach.  I really don't think a top level approach works for all
> > > inline (managed) types of mounts.
> > 
> > It isn't precluded: when the mount point is instantiated (no matter which
> > datastore it is in), the server adds the schema as a new entry to the
> > "schema"
> > list in the top level YANG library (with a unique key), and annotates the
> > mount
> > point instance with a leafref pointing to that key. So different instances
> > of
> > the same mount point can have different schemas.
> > 
> > > > > Given this discussion, we can generalize it further to:
> > > > > 
> > > > >    The use of mount points does not impact the nature of the
> > > > >    mounted data or in which data store information is made
> > > > >    available. For example, mounted YANG Library modules contain
> > > > >    only operational state data and, as such, the information in
> > > > >    these modules is available from operational data stores using
> > > > >    the appropriate protocol operations.
> > > > 
> > > > The whole question here is whether and how we can locate the schema for
> > > > an
> > > > inline mount point in any configuration datastore.
> > > 
> > > Why is a mounted YL different than a top level YL?  What works for and
> > 
> > It is not different, but it can be only in an operational datastores, and so
> > for
> > mount point instances inside configuration datastores we need a way how to
> > locate the schema for that mount point, because it cannot be found directly
> > under the mount point instance (as the current text assumes).
> > 
> > > is sufficient for the normal case of YL shouldn't be impacted or
> > > modified by SM -- at least that's how I thought we've been talking about
> > > since SM was started.  Again, we never made any special provisions for
> > > any other rw/ro/state data, assuming top level YL is not handled as
> > > metadata, why start now?
> > > 
> > > I'm getting the impression that your argument may be more about if YL
> > > should be treated as something other than operational data, is this wrong?
> > 
> > This is wrong. My argument is that there should be only one top-level YANG
> > library (state data) and each inline mount point instance just points to a
> > schema inside it by means of a metadata annotation attached to the mount
> > point
> > (in any datastore).
> > 
> > Lada
> > 
> > > Thanks,
> > > Lou
> > > 
> > > > Lada
> > > > 
> > > > > Lou
> > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > > Lou
> > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > annotation
> > > > > > > > > > along
> > > > > > > > > > the
> > > > > > > > > > lines of RFC 7952, for example with the alternative B of the
> > > > > > > > > > newly
> > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > 
> > > > > > > > > >       md:annotation schema-ref {
> > > > > > > > > >         type leafref {
> > > > > > > > > >           path "/yanglib:yang-
> > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > >         }
> > > > > > > > > >       }
> > > > > > > > > > 
> > > > > > > > > > In other words, all inline mounted schemas would be included
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > top-level YANG library, and mount point instances in all
> > > > > > > > > > datastores
> > > > > > > > > > would be annotated with leafref pointing to the actual
> > > > > > > > > > schema.
> > > > > > > > > > 
> > > > > > > > > > Unlike regular state data, it is IMO no problem to permit
> > > > > > > > > > such
> > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > 
> > > > > > > > > > Opinions?
> > > > > > > > > 
> > > > > > > > > I'm not sure this will work for all architectures of LNEs as
> > > > > > > > > well
> > > > > > > > > as
> > > > > > > > > other possible future use cases.  In short, this seems *very*
> > > > > > > > > restrictive.
> > > > > > > > 
> > > > > > > > I don't understand, IMO it is not restrictive at all. What kind
> > > > > > > > of
> > > > > > > > restrictions
> > > > > > > > do you see?
> > > > > > > > 
> > > > > > > > Lada
> > > > > > > > 
> > > > > > > > > Lou
> > > > > > > > > 
> > > > > > > > > > Thanks, Lada
> > > > > > > > > > 
> > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > 
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is wrong
> > > > > > > > > > > for
> > > > > > > > > > > traditional
> > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > 
> > > > > > > > > > >     In case 1 ["inline"], the mounted schema is determined
> > > > > > > > > > > at
> > > > > > > > > > > run
> > > > > > > > > > > time:
> > > > > > > > > > > every
> > > > > > > > > > >     instance of the mount point that exists in the parent
> > > > > > > > > > > tree
> > > > > > > > > > > MUST
> > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
> > > > > > > > > > > defines
> > > > > > > > > > > the
> > > > > > > > > > >     mounted schema exactly as for a top-level data
> > > > > > > > > > > model.  A
> > > > > > > > > > > client
> > > > > > > > > > > is
> > > > > > > > > > >     expected to retrieve this data from the instance tree,
> > > > > > > > > > > possibly
> > > > > > > > > > > after
> > > > > > > > > > >     creating the mount point.  Instances of the same mount
> > > > > > > > > > > point
> > > > > > > > > > > MAY
> > > > > > > > > > > use
> > > > > > > > > > >     different mounted schemas.
> > > > > > > > > > > 
> > > > > > > > > > > An instance of the mount point in any *configuration*
> > > > > > > > > > > datastores
> > > > > > > > > > > cannot
> > > > > > > > > > > contain
> > > > > > > > > > > YANG library (being state data), and so the MUST cannot
> > > > > > > > > > > hold.
> > > > > > > > > > > 
> > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > considerable
> > > > > > > > > > > complications
> > > > > > > > > > > and/or a lot of handwaving. There is actually one good
> > > > > > > > > > > solution
> > > > > > > > > > > but it
> > > > > > > > > > > has
> > > > > > > > > > > impact on YANG library: the server could provide it in a
> > > > > > > > > > > reply
> > > > > > > > > > > to
> > > > > > > > > > > an
> > > > > > > > > > > operation,
> > > > > > > > > > > say "get-yang-library" rather than as state data. Then
> > > > > > > > > > > everything
> > > > > > > > > > > would be
> > > > > > > > > > > fine
> > > > > > > > > > > - this operation would turn into an action for the mount
> > > > > > > > > > > point,
> > > > > > > > > > > and it
> > > > > > > > > > > can
> > > > > > > > > > > be
> > > > > > > > > > > used equally well for config true and false mount points.
> > > > > > > > > > > 
> > > > > > > > > > > So my proposal is to move from YANG library as state data
> > > > > > > > > > > to
> > > > > > > > > > > an
> > > > > > > > > > > operation.
> > > > > > > > > > > It
> > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > structure,
> > > > > > > > > > > so
> > > > > > > > > > > there
> > > > > > > > > > > will be
> > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > 
> > > > > > > > > > > Lada
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > 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
> > > > > > > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 00:45: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 A0DBA12FAD5; Tue, 16 Jan 2018 00:45:23 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FSRdLFcaf8_N; Tue, 16 Jan 2018 00:45:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40712FAC5; Tue, 16 Jan 2018 00:45:21 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 85C861AE0399; Tue, 16 Jan 2018 09:45:18 +0100 (CET)
Date: Tue, 16 Jan 2018 09:45:17 +0100 (CET)
Message-Id: <20180116.094517.1289080428198654451.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: joelja@bogus.com, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5bbfb2b8-597c-1d19-0d4f-95f83c0ab4b5@cisco.com>
References: <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com> <20180115.162623.2008313631188177181.mbj@tail-f.com> <5bbfb2b8-597c-1d19-0d4f-95f83c0ab4b5@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 08:45:24 -0000

Robert Wilton  wrote:
> =

> =

> On 15/01/2018 15:26, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >> Hi Martin,
> >>
> >> All OK with me except where I have further comments/questions inli=
ne
> >> below:
> >>
> >> On 15/01/2018 14:39, Martin Bjorklund wrote:
> >>> Hi,
> >>>
> >>> Thanks for the review!  Comments inline.
> >>>
> >>> Robert Wilton  wrote:
> >>>> Hi Lou, Martin
> >>>>
> >>>> I've done a quick review of draft -04.
> >>>>
> >>>> It looks well written to me.
> >>>>
> >>>> I have a spotted a few minor nits/questions.
> >>>>
> >>>> Section 1:
> >>>>
> >>>> (i) "Such diagrams are commonly used to provided " =3D> "Such di=
agrams
> >>>> are used to provide"?
> >>> Ok.
> >>>
> >>>> (ii) "This document provides the syntax used in YANG Tree Diagra=
ms."
> >>>> =3D> "This document describes the syntax used in YANG Tree Diagr=
ams", or
> >>>> if not "describes", perhaps "specifies"?
> >>> I changed to "describes".
> >>>
> >>>> (iii) "common practice is include" =3D> "common practice is to i=
nclude"
> >>> Ok.
> >>>
> >>>> Section 2:
> >>>> (iv) Are the top level data nodes really offset by 4 spaces, or =
should
> >>>> this be 2 spaces?=A0 The example in section 2, and section 4 see=
m to
> >>>> differ here.=A0 The submodule example in Sec 2.1 looks like it i=
s using
> >>>> 2 spaces.
> >>> It should be 4 spaces.  I fixed the example in 2.1.
> >> Hum, OK.=A0 Is this the right choice?
> >>  =A0- It means that the tree is indented 2 spaces further than eve=
rything
> >> else (e.g. groupings, augments, etc).
> > Well, I think it is consistent as it is now:
> >
> > module: 
> >      +--
> >      |  +--
> >      |     +--
> >      +--
> >         +--
> >            +--
> >
> >    augment :
> >      +--
> >         +--
> >         +--
> >            +--
> >
> > Nodes are always intended 4 spaces.
> Yes, agree that it is consistent, but personally I would also be happ=
y
> for the nodes to be intended 2 spaces for the main tree, and then 4
> spaces for everything else (effectively 2 spaces beyond the
> augment/rpc/etc).

Ok.

> >>  =A0- YANG modules in RFC's already struggle with line length anyw=
ay,
> >> hence wouldn't the use of 2 spaces give the model a bit more space=
.=

> > This is a good argument.  I'm happy to save spaces by using 2 inste=
ad:
> >
> > module: 
> >    +--
> >    |  +--
> >    |     +--
> >    +--
> >       +--
> >          +--
> >
> >    augment :
> >    +--
> >       +--
> >       +--
> >          +--
> I think that compact is better, if not quite so pretty, so this
> solution is also OK with me.
> =

> Personally, I quite like a relative indent, i.e. the tree is intended=

> 2 spaces more than its parent "thing", e.g.
> =

> module: 
>   +--
>   |  +--
>   |     +--
>   +--
>      +--
>         +--
> =

>   augment :
>     +--
>        +--
>        +--
>           +--

Ok, I will use this.


/martin


> >> I also think that it would be good to check the indent of all the =
tree
> >> diagram snippets in the doc, it looks like they may be using somew=
hat
> >> varying levels of indents (between 2 and 6 spaces).
> > Ok.
> >
> >
> >>>> (v) "is prefaces with" =3D> "is prefaced with"
> >>> Ok.
> >>>
> >>>> (vi) Section 2.2, should there be an example of an unexpanded us=
es
> >>>> statement?=A0 I was wondering if this section was under specifie=
d?
> >>> I have added:
> >>>
> >>>      For example, the following diagram shows the "tls-transport"=
 grouping
> >>>      from [RFC7407] unexpanded:
> >>>
> >>>          +--rw tls
> >>>             +---u tls-transport
> >>>
> >>>      If the grouping is expanded, it could be printed as:
> >>>
> >>>          +--rw tls
> >>>             +--rw port?                 inet:port-number
> >>>             +--rw client-fingerprint?   x509c2n:tls-fingerprint
> >>>             +--rw server-fingerprint?   x509c2n:tls-fingerprint
> >>>             +--rw server-identity?      snmp:admin-string
> >> Yes, looks good.
> >>
> >>>> Section 2.6:
> >>>> (vii) "If the node is augmented into the tree from another modul=
e, its
> >>>> name is printed as :."=A0 Does there need to be a
> >>>> clarification that the prefix name used is the one used by the
> >>>> module's import statement?=A0 Or does it use the prefix statemen=
t from
> >>>> the imported modules instead (I know that these should normally =
be the
> >>>> same, but this is not guaranteed).
> >>> Since this is used when a node is augmented *into* the main tree,=
 it
> >>> can't be the prefix in import, since the augmenting module is not=

> >>> imported from the augmented module.  I did:
> >> But the YANG module must import the module that it is augmenting. =
If a
> >> local import prefix is used in the actual YANG module then it woul=
d be
> >> slightly harder to relate the tree output back to local import
> >> prefixes used in the YANG module.
> > Here's an example:
> >
> > module: ietf-interfaces
> >      +--rw interfaces
> >      |  +--rw interface* [name]
> >      |     +--rw name                        string
> >      ...
> >      |     +--rw ip:ipv4!
> >
> > ietf-interfaces doesn't import ietf-ip, so there is no other prefix=
 to
> > use for "ipv4" than the one defined in ietf-ip!
> Ah, yes, OK.=A0 I was assuming that the tree diagram would always be
> done from the augmenting module, but clearly that is not necessarily
> the case.
> =

> =

> >
> >>> OLD:
> >>>
> >>>         If the node is augmented into the tree from another modul=
e,
> >>>         its name is printed as :.
> >>>
> >>> NEW:
> >>>
> >>>         If the node is augmented into the tree from another modul=
e,
> >>>         its name is printed as :, where  is=
 the
> >>>         prefix defined in the module where the node is defined.
> >> This is OK with me, but there is still a potential for a prefix
> >> namespace clash (since prefixes are not guaranteed to be unique).
> >>
> >> An alternative solution would be for the YANG tree diagram to list=
 (at
> >> the beginning or the end of the diagram) the mappings from prefix =
->
> >> module name used.
> > The tree diagram is supposed to give a simplified overview of the
> > structure of a module.  I agree with your statemenet below that suc=
h a
> > mappig adds noise...  I prefer to keep the diagram as is.
> That is fine with me, really just raising so that the point could be
> discussed and closed.
> =

> Thanks,
> Rob
> =

> =

> >
> >
> > /martin
> >
> >
> >> This has the bonus that it also explicitly lists
> >> the YANG modules that are being augmented, but conversely, this mi=
ght
> >> end up just adding unnecessary noise to a diagram that should be s=
hort
> >> and simple ...
> >>
> >> A second alternative would be to add some vague text to state that=
 the
> >> prefix to module mapping should be explicitly listed in any cases
> >> where the prefix name alone is not obvious.
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >>>> Section 3.2.
> >>>> (viii) It would be slightly easier to read if there wasn't a lin=
ebreak
> >>>> between "--" and "tree-print-groupings", not sure if that is fea=
sible
> >>>> to force this.
> >>> I don't think I can enforce this, but I'll look into it.  If noth=
ing
> >>> else, the RFC editor will fix this.
> >>>
> >>>
> >>> /martin
> >>>
> >>>
> >>>> Thanks,
> >>>> Rob
> >>>>
> >>>> On 10/01/2018 16:16, joel jaeggli wrote:
> >>>>> Just a reminder given the date that this was posted. This last =
call is
> >>>>> expected to complete Monday 1/15/18.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> joel
> >>>>>
> >>>>>
> >>>>> On 1/1/18 2:01 PM, joel jaeggli wrote:
> >>>>>> Greetings,
> >>>>>>
> >>>>>> We hope  the new year is a time to make great progess on outst=
anding
> >>>>>> documents before preparation for the  London IETF begins in ea=
rnest.
> >>>>>>
> >>>>>> This starts a two-week working group last call on:
> >>>>>>
> >>>>>>     YANG Tree Diagrams
> >>>>>> draft-ietf-netmod-yang-tree-diagrams
> >>>>>>
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-d=
iagrams/
> >>>>>>
> >>>>>> Please send email to the list indicating your support or conce=
rns.
> >>>>>>
> >>>>>> We are particularly interested in statements of the form:
> >>>>>>
> >>>>>>      * I have reviewed this draft and found no issues.
> >>>>>>      * I have reviewed this draft and found the following issu=
es: ...
> >>>>>>
> >>>>>>
> >>>>>> Thank you,
> >>>>>> NETMOD WG Chairs
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> netmod mailing list
> >>>>> netmod@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>> .
> >>>>>
> >>> .
> >>>
> > .
> >
> =


From nobody Tue Jan 16 01:20:38 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 CB5CE12FAFB for ; Tue, 16 Jan 2018 01:20:36 -0800 (PST)
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 4hc_cL0tvcpX for ; Tue, 16 Jan 2018 01:20:34 -0800 (PST)
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 9C6BA12FB03 for ; Tue, 16 Jan 2018 01:19:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E4BAB1442D35 for ; Tue, 16 Jan 2018 10:19:34 +0100 (CET)
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 JedJ4yeIxfwV for ; Tue, 16 Jan 2018 10:19:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B92D71442D36 for ; Tue, 16 Jan 2018 10:19:34 +0100 (CET)
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 RUGbsZEsEktE for ; Tue, 16 Jan 2018 10:19:34 +0100 (CET)
Received: from [192.168.2.191] (cm-84.211.71.154.getinternet.no [84.211.71.154]) by mail.transpacket.com (Postfix) with ESMTPSA id 9671A1442D2E for ; Tue, 16 Jan 2018 10:19:34 +0100 (CET)
To: netmod@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> 
From: Vladimir Vassilev 
Message-ID: 
Date: Tue, 16 Jan 2018 10:19:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 09:20:37 -0000

On 01/15/2018 09:41 PM, Vladimir Vassilev wrote:
> Hi,
>
> I have reviewed and implemented (apart from schema mount specific=20
> functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found=20
> the following issues:
>
> =3D=3Dsec 2.6.=C2=A0 Node Representation=3D=3D
>
> 1. To correctly reflect the current pyang output one needs to add '--'=20
> between  and .
> OLD:
> =C2=A0=C2=A0=C2=A0      
> NEW:
> =C2=A0=C2=A0=C2=A0 --    
>
> There is also undocumented alignment space count function before=20
>  that pyang uses to align the  fields of child data leafs=20
> with common ancestor. If this is specified in the draft the tree=20
> output can be deterministic and for me this is an advantage. This is=20
> currently one of the few underspecified pieces of the tree format so I=20
> had to check pyang implementation in oder to generate same alignment=20
> space counts and binary identical tree output results.
>
>
> 2. It is unclear which  option should be used for rpc and=20
> action input/output and child nodes and the notification child nodes.=20
> pyang uses '-w' for input and input/* and 'ro' for output and output/*:
>
> =C2=A0=C2=A0=C2=A0 module: ietf-netconf-partial-lock
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rpcs:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---x partial-lock
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +---w input
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +---w select=
*=C2=A0=C2=A0 string
> =C2=A0=C2=A0=C2=A0 ...
>
> pyang also uses '--' as  for augmentation data nodes for=20
> actions input.
>
> =C2=A0=C2=A0=C2=A0 ...
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 augment /rt:routing-state/rt:ribs/rt:rib=
/rt:active-route/rt:input:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---- destination-address?=C2=
=A0=C2=A0 inet:ipv4-address
> =C2=A0=C2=A0=C2=A0 ...
>
>
> 3. pyang is prefixing choice node names with the parent  e.g.=20
> +--ro (next-hop-options) while case nodes are not prefixed. I guess=20
> this is a bug in pyang since it is not specified in the draft but=20
> choice nodes prefixed with parent  are=C2=A0 also present in the=
 sec=20
> 4 and 4.1 examples?
Ignore 3. choice had a config substatement which explains the presence=20
of .
>
> 4. This bit I found confusing. I propose this change to unambiguously=20
> describe the current pyang format.
>
> OLD:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-lis=
t or list
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [] for a list's =
keys
> NEW:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-lis=
t or list without keys
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * [] for a list =
with keys
>
> Vladimir
>
> On 01/01/2018 11:01 PM, joel jaeggli wrote:
>> Greetings,
>>
>> We hope=C2=A0 the new year is a time to make great progess on outstand=
ing
>> documents before preparation for the=C2=A0 London IETF begins in earne=
st.
>>
>> This starts a two-week working group last call on:
>>
>> =C2=A0 YANG Tree Diagrams
>> draft-ietf-netmod-yang-tree-diagrams
>>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>
>> Please send email to the list indicating your support or concerns.
>>
>> We are particularly interested in statements of the form:
>>
>> =C2=A0=C2=A0 * I have reviewed this draft and found no issues.
>> =C2=A0=C2=A0 * I have reviewed this draft and found the following issu=
es: ...
>>
>>
>> Thank you,
>> NETMOD WG Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 16 01:51: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 2F13512F4B1; Tue, 16 Jan 2018 01:51:17 -0800 (PST)
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_RP_MATCHES_RCVD=-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 7aFSzY60z61R; Tue, 16 Jan 2018 01:51:14 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA3012FB10; Tue, 16 Jan 2018 01:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4348; q=dns/txt; s=iport; t=1516096273; x=1517305873; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=yKrK8vPMjLnLnIP08ipqGLuaAmg+LYKRt8dvtCGQRO4=; b=UsACSD7wYVLKPE0OalNyfUvmg5Z/ycHwp/cfPFsOldlCG4Yoh+kQvrEI mpXI/X/oP8j5MK6N0YMSBlh86i3ExKF+gqg0QUcupCLsePDytMfxVYHRl E+T7fLl1clp73R8Yyt6NkzePHJ0p55hEQaCKT7/wGE8LT16VKFFDUqcRk I=;
X-IronPort-AV: E=Sophos;i="5.46,367,1511827200"; d="scan'208,217";a="1423865"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 09:51:11 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0G9pBVW026979; Tue, 16 Jan 2018 09:51:11 GMT
To: Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <66857af8-80b4-8c7c-f952-f04c3f2adaa7@cisco.com> <20180115.153933.1215610340924130656.mbj@tail-f.com> <9a7e9c47-c8bb-afdc-81d2-1799cfd635cf@cisco.com> <20180115.162623.2008313631188177181.mbj@tail-f.com> <5bbfb2b8-597c-1d19-0d4f-95f83c0ab4b5@cisco.com>
From: Benoit Claise 
Message-ID: 
Date: Tue, 16 Jan 2018 10:51:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <5bbfb2b8-597c-1d19-0d4f-95f83c0ab4b5@cisco.com>
Content-Type: multipart/alternative; boundary="------------C2900FD8BD87F97BEF45311E"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 09:51:18 -0000

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

On 1/15/2018 4:48 PM, Robert Wilton wrote:
>>>> OLD:
>>>>
>>>>         If the node is augmented into the tree from another module,
>>>>         its name is printed as :.
>>>>
>>>> NEW:
>>>>
>>>>         If the node is augmented into the tree from another module,
>>>>         its name is printed as :, where  is the
>>>>         prefix defined in the module where the node is defined.
>>> This is OK with me, but there is still a potential for a prefix
>>> namespace clash (since prefixes are not guaranteed to be unique).
>>>
>>> An alternative solution would be for the YANG tree diagram to list (at
>>> the beginning or the end of the diagram) the mappings from prefix ->
>>> module name used.
>> The tree diagram is supposed to give a simplified overview of the
>> structure of a module.  I agree with your statemenet below that such a
>> mappig adds noise...  I prefer to keep the diagram as is.
> That is fine with me, really just raising so that the point could be 
> discussed and closed.
Sections such as this one are super useful and should ideally become 
common practice.
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-08#section-2.3

Regards, Benoit
>
> Thanks,
> Rob 


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


  
    
  
  
    
On 1/15/2018 4:48 PM, Robert Wilton
      wrote:

    

    

      

        

          
OLD:
            

            

                    If the node is augmented into the tree from another
            module,
            

                    its name is printed as <prefix>:<name>.
            

            

            NEW:
            

            

                    If the node is augmented into the tree from another
            module,
            

                    its name is printed as <prefix>:<name>,
            where <prefix> is the
            

                    prefix defined in the module where the node is
            defined.
            

          

          This is OK with me, but there is still a potential for a
          prefix
          

          namespace clash (since prefixes are not guaranteed to be
          unique).
          

          

          An alternative solution would be for the YANG tree diagram to
          list (at
          

          the beginning or the end of the diagram) the mappings from
          prefix ->
          

          module name used.
          

        

        The tree diagram is supposed to give a simplified overview of
        the
        

        structure of a module.  I agree with your statemenet below that
        such a
        

        mappig adds noise...  I prefer to keep the diagram as is.
        

      

      That is fine with me, really just raising so that the point could
      be discussed and closed.
      

    

    Sections such as this one are super useful and should ideally become
    common practice.

https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-08#section-2.3

    

    Regards, Benoit

    

      

      Thanks,
      

      Rob
    

    

  


--------------C2900FD8BD87F97BEF45311E--


From nobody Tue Jan 16 02:56: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 44E4C12D86B for ; Tue, 16 Jan 2018 02:56:16 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YcbttTJagqe4 for ; Tue, 16 Jan 2018 02:56:14 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E93FB12DA09 for ; Tue, 16 Jan 2018 02:56:08 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CF3201AE0399; Tue, 16 Jan 2018 11:56:07 +0100 (CET)
Date: Tue, 16 Jan 2018 11:56:06 +0100 (CET)
Message-Id: <20180116.115606.561861432247288407.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 10:56:16 -0000

Vladimir Vassilev  wrote:
> Hi,
> =

> I have reviewed and implemented (apart from schema mount specific
> functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found
> the following issues:
> =

> =3D=3Dsec 2.6.=A0 Node Representation=3D=3D
> =

> 1. To correctly reflect the current pyang output one needs to add '--=
'
> between  and .
> OLD:
> =A0=A0=A0      
> NEW:
> =A0=A0=A0 --    

Ok.

> There is also undocumented alignment space count function before
>  that pyang uses to align the  fields of child data leafs=

> with common ancestor. If this is specified in the draft the tree
> output can be deterministic and for me this is an advantage. This is
> currently one of the few underspecified pieces of the tree format so =
I
> had to check pyang implementation in oder to generate same alignment
> space counts and binary identical tree output results.

I think that we at least should write that there may be more than one
space between  and :

  There may be any number of additional space characters between
   and .


I also just realized that we need to add text to the line wrapping
section about line breaks between  and :

OLD:

   Internet Drafts and RFCs limit the number of characters that may in =
a
   line of text to 72 characters.  When the tree representation of a
   node results in line being longer than this limit the line should be=

   broken between  and .  The type should be indented so
   that the new line starts below  with a white space offset of a=
t
   least two characters.

NEW:

   Internet Drafts and RFCs limit the number of characters in a line
   of text to 72 characters.  When the tree representation of a node
   results in line being longer than this limit the line should be
   broken between  and , or between  and
   .  The new line should be indented so that it starts
   below  with a white space offset of at least two characters.


> 2. It is unclear which  option should be used for rpc and
> action input/output and child nodes and the notification child
> nodes. pyang uses '-w' for input and input/* and 'ro' for output and
> output/*:
> =

> =A0=A0=A0 module: ietf-netconf-partial-lock
> =A0=A0=A0=A0=A0 rpcs:
> =A0=A0=A0=A0=A0=A0=A0 +---x partial-lock
> =A0=A0=A0=A0=A0=A0=A0 |=A0 +---w input
> =A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0 +---w select*=A0=A0 string
> =A0=A0=A0 ...

I'll do:

OLD:

        is one of:
         rw  for configuration data
         ro  for non-configuration data
         -u  for uses of a grouping
         -x  for rpcs and actions
         -n  for notifications
         mp  for nodes containing a "mount-point" extension statment

NEW:

        is one of:
         rw  for configuration data
         ro  for non-configuration data, output parameters to rpcs
             and actions, and notification parameters
         -w  for input parameters to rpcs and actions
         -u  for uses of a grouping
         -x  for rpcs and actions
         -n  for notifications
         mp  for nodes containing a "mount-point" extension statment

> pyang also uses '--' as  for augmentation data nodes for
> actions input.

I think that this is a bug in pyang, which I have now fixed.

> =A0=A0=A0 ...
> =A0=A0=A0=A0=A0 augment
> /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
> =A0=A0=A0=A0=A0=A0=A0 +---- destination-address?=A0=A0 inet:ipv4-addr=
ess
> =A0=A0=A0 ...
> =

> =

> 3. pyang is prefixing choice node names with the parent 
> e.g. +--ro (next-hop-options) while case nodes are not prefixed. I
> guess this is a bug in pyang since it is not specified in the draft
> but choice nodes prefixed with parent  are=A0 also present in =
the
> sec 4 and 4.1 examples?

[ignoring based on latest email from Vladimir]

> 4. This bit I found confusing. I propose this change to unambiguously=

> describe the current pyang format.
> =

> OLD:
> =A0=A0=A0=A0=A0=A0=A0=A0 *=A0 for a leaf-list or list
> =A0=A0=A0=A0=A0=A0=A0=A0 [] for a list's keys
> NEW:
> =A0=A0=A0=A0=A0=A0=A0=A0 *=A0 for a leaf-list or list without keys
> =A0=A0=A0=A0=A0=A0=A0=A0 * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?


/martin



> =

> Vladimir
> =

> On 01/01/2018 11:01 PM, joel jaeggli wrote:
> > Greetings,
> >
> > We hope  the new year is a time to make great progess on outstandin=
g
> > documents before preparation for the  London IETF begins in earnest=
.=

> >
> > This starts a two-week working group last call on:
> >
> >   YANG Tree Diagrams
> > draft-ietf-netmod-yang-tree-diagrams
> >
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagra=
ms/
> >
> > Please send email to the list indicating your support or concerns.
> >
> > We are particularly interested in statements of the form:
> >
> >    * I have reviewed this draft and found no issues.
> >    * I have reviewed this draft and found the following issues: ...=

> >
> >
> > Thank you,
> > NETMOD WG Chairs
> =

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


From nobody Tue Jan 16 03:27: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 A8E5A12DA50 for ; Tue, 16 Jan 2018 03:27:12 -0800 (PST)
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_RP_MATCHES_RCVD=-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 QVTtmhaVhDlE for ; Tue, 16 Jan 2018 03:27:06 -0800 (PST)
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 7DE2112DA19 for ; Tue, 16 Jan 2018 03:27:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16017; q=dns/txt; s=iport; t=1516102025; x=1517311625; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=ev6jx7IrzaCEopk82L0TCU9KuozeKYTOBFvlBLWMw0g=; b=JuknpO6HqpZ+v8Y/YaKhm+m/jqO0YSnsEkDsYmCOGb1jbnTkrZOUBfEn wGDG0eYxx2BXdC2VjgUhH6xtaNofnGS5HkrL6ojFLBK8ezH+uW0XZpDDp hat72I1YS38sTZtpjlmrFLeLHCPZyRcajZkW3xY0Q5f0J8AozTK042PYG 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACBADO4F1a/xbLJq1DGhwBAQEEAQEKA?= =?us-ascii?q?QGEJ3QnhBOLGI9HkgKFZYICCiaFFQIahQEUAQEBAQEBAQEBayiFJAYjZglEAgI?= =?us-ascii?q?CVQYNCAEBFooZEDSHdJ1wgicmiSMBAQEBAQEBAQEBAQEBAQEBARwFiCiBaSkMh?= =?us-ascii?q?igCAQEBAYE1g0+CZQWZcolyiAyNP4IZhh2Db4drjT6BXogJgTw2IoFQMhoIGxW?= =?us-ascii?q?CZ4RYQDcBjUMBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200"; d="scan'208,217";a="1477272"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 11:27:01 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0GBR1RO002647 for ; Tue, 16 Jan 2018 11:27:01 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: 
Message-ID: <2a8653ac-eee8-3ced-4644-23c04cf87a51@cisco.com>
Date: Tue, 16 Jan 2018 12:27:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------56FB4018894B70831905DACF"
Content-Language: en-US
Archived-At: 
Subject: [netmod] YANG modules publication: what to focus on next?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 11:27:12 -0000

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

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.

Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
)
   Note that draft-ietf-netmod-revised-datastores, a normative reference 
for many YANG modules,
   was just approved. Good news!

We now have many YANG modules in RFC editor queue:
***draft-ietf-lime-yang-connectionless-oam-18 
**
****draft-ietf-lime-yang-connectionless-oam-methods-13 
**
****draft-ietf-i2rs-yang-l3-topology-16 
**
****draft-ietf-i2rs-yang-network-topo-20 
**
****draft-wu-l3sm-rfc8049bis-11 
****
**draft-ietf-netconf-rfc6536bis-09 

*draft-ietf-netmod-rfc7223bis-03 

draft-ietf-netmod-rfc7277bis-03 

draft-ietf-rtgwg-yang-vrrp-09 

draft-ietf-rtgwg-yang-rip-08 

draft-ietf-netmod-revised-datastores-10 


Here are the YANG module dependencies 
 
for these RFC editor modules, as requirement before publishing.

Some more YANG modules are on the IESG table:
     draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)
     draft-ietf-netmod-rfc8022bis is on the Jan 25th IESG telechat
     draft-ietf-netmod-entity is on the Jan 25th IESG telechat

Assuming those are in the RFC editor queue, this is the new set of YANG 
module dependencies 
.
It takes a little bit of re-arrangering the elements, but all the 
information is there.

The next bottlenecks for publishing those YANG modules are:
     draft-ietf-netmod-schema-mount
     draft-ietf-rtgwg-ni-model
     ietf-bfd-yang
     draft-ietf-ospf-yang
     draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NI, LNE, and schema mount, RFC7895bis, schema mount:_
     draft-ietf-rtgwg-lne-model
         Status: Publication requested, Alia's AD review
     draft-ietf-rtgwg-ni-model
         Status: Publication requested, Alia's AD review
     draft-ietf-netmod-schema-mount:
         Status:  WG LC closed, not sure on the next steps ...
     draft-ietf-netconf-rfc7895bis
         Status not clear...

_LIME:_
draft-ietf-lime-yang-connection-oriented-oam-model-00
         Status: Benoit to perform the AD review.

Regards, Benoit

--------------56FB4018894B70831905DACF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KDQogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl
IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICA8L2hlYWQ+DQogIDxi
b2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgIERlYXIgYWxsLDxi
cj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otZm9yd2FyZC1jb250YWluZXIiPg0KICAgICAgPGRp
diBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgPGRpdiBjbGFzcz0i
bW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJtb3otZm9y
d2FyZC1jb250YWluZXIiPiA8YnI+DQogICAgICAgICAgICBBdCB0aGUgbGFzdCBJRVRGIG1l
ZXRpbmcsIEFsaWEsIERlYm9yYWggYW5kIEkgbG9va2VkIGF0IHRoZQ0KICAgICAgICAgICAg
cHVibGljYXRpb24gc3RhdHVzIG9mIG1vc3QgWUFORyBtb2R1bGVzLjxicj4NCiAgICAgICAg
ICAgIFNpbmNlIHRoYXQgdGltZSwgSSd2ZSBiZWVuIGtlZXBpbmcgYSBzdW1tYXJ5IG9mIHRo
ZQ0KICAgICAgICAgICAgc2l0dWF0aW9uLiBMZXQgbWUgc2hhcmUgaXQgd2l0aCBldmVyeWJv
ZHkuPGJyPg0KICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgQmVmb3JlIHB1Ymxpc2hp
bmcgWUFORyBtb2R1bGVzLCB3ZSBoYXZlIHR3byBzZXJpZXMgb2YNCiAgICAgICAgICAgIGJv
dHRsZW5lY2tzOiA8YnI+DQogICAgICAgICAgICAtIHRoZSBZQU5HIG1vZHVsZSBpbXBvcnQg
KHNob3duIGJ5IHRvb2xpbmcgYmVsb3cpPGJyPg0KICAgICAgICAgICAgLSB0aGUgbm9ybWF0
aXZlIHJlZmVyZW5jZXMgKE1JU1NSRUYgaW4gdGhlIDxhDQogICAgICAgICAgICAgIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cucmZj
LWVkaXRvci5vcmcvY3VycmVudF9xdWV1ZS5waHAiPlJGQw0KICAgICAgICAgICAgICBlZGl0
b3IgcXVldWU8L2E+KTxicj4NCiAgICAgICAgICAgIMKgIE5vdGUgdGhhdCBkcmFmdC1pZXRm
LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMsIGENCiAgICAgICAgICAgIG5vcm1hdGl2ZSBy
ZWZlcmVuY2UgZm9yIG1hbnkgWUFORyBtb2R1bGVzLDxicj4NCiAgICAgICAgICAgIMKgIHdh
cyBqdXN0IGFwcHJvdmVkLiBHb29kIG5ld3MhPGJyPg0KICAgICAgICAgICAgPGJyPg0KICAg
ICAgICAgICAgV2Ugbm93IGhhdmUgbWFueSBZQU5HIG1vZHVsZXMgaW4gUkZDIGVkaXRvciBx
dWV1ZTo8YnI+DQogICAgICAgICAgICA8Yj7CoMKgwqAgPC9iPjxiPjxhDQpocmVmPSJodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25u
ZWN0aW9ubGVzcy1vYW0iDQogICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
Ij5kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0tMTg8L2E+PC9iPjxi
Pjxicj4NCiAgICAgICAgICAgIDwvYj48Yj7CoMKgwqAgPC9iPjxiPjxhDQpocmVmPSJodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25u
ZWN0aW9ubGVzcy1vYW0tbWV0aG9kcyINCiAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl
bmQ9InRydWUiPmRyYWZ0LWlldGYtbGltZS15YW5nLWNvbm5lY3Rpb25sZXNzLW9hbS1tZXRo
b2RzLTEzPC9hPjwvYj48Yj48YnI+DQogICAgICAgICAgICA8L2I+PGI+wqDCoMKgIDwvYj48
Yj48YQ0KICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5Ig0KICAgICAgICAgICAg
ICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9w
b2xvZ3ktMTY8L2E+PC9iPjxiPjxicj4NCiAgICAgICAgICAgIDwvYj48Yj7CoMKgwqAgPC9i
PjxiPjxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p
ZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8iDQogICAgICAgICAgICAgICAgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8tMjA8L2E+
PC9iPjxiPjxicj4NCiAgICAgICAgICAgIDwvYj48Yj7CoMKgwqAgPC9iPjxiPjxhDQogICAg
ICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtd3UtbDNzbS1yZmM4MDQ5YmlzIg0KICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2Vu
ZD0idHJ1ZSI+ZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTExPC9hPjwvYj48Yj4NCiAgICAg
ICAgICAgIDwvYj48Yj48YnI+DQogICAgICAgICAgICAgIMKgwqDCoCA8L2I+PGI+PGENCiAg
ICAgICAgICAgICAgICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcyINCiAgICAgICAgICAgICAgICBtb3otZG8t
bm90LXNlbmQ9InRydWUiPmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2YmlzLTA5PC9hPjxi
cj4NCiAgICAgICAgICAgICAgwqDCoMKgIDwvYj48YQ0KICAgICAgICAgICAgICBocmVmPSJo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yZmM3
MjIzYmlzLyINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1p
ZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzPC9hPjxicj4NCiAgICAgICAgICAgIMKgwqDCoCA8
YQ0KICAgICAgICAgICAgICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLyINCiAgICAgICAgICAgICAgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLTAzPC9hPjxi
cj4NCiAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICBocmVmPSJodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycC8i
DQogICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1ydGd3
Zy15YW5nLXZycnAtMDk8L2E+PGJyPg0KICAgICAgICAgICAgwqDCoMKgIDxhDQogICAgICAg
ICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtcnRnd2cteWFuZy1yaXAvIg0KICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRy
dWUiPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1yaXAtMDg8L2E+PGJyPg0KICAgICAgICAgICAg
wqDCoMKgIDxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMvIj5kcmFmdC1pZXRmLW5ldG1vZC1y
ZXZpc2VkLWRhdGFzdG9yZXMtMTA8L2E+PGJyPg0KICAgICAgICAgICAgPGJyPg0KICAgICAg
ICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cueWFu
Z2NhdGFsb2cub3JnL3lhbmctc2VhcmNoL2ltcGFjdF9hbmFseXNpcy5waHA/bW9kdWxlc1td
PWlldGYtaXAmYW1wO21vZHVsZXNbXT1pZXRmLWNvbm5lY3Rpb25sZXNzLW9hbSZhbXA7bW9k
dWxlc1tdPWlldGYtbGltZS10aW1lLXR5cGVzJmFtcDttb2R1bGVzW109aWV0Zi1jb25uZWN0
aW9ubGVzcy1vYW0tbWV0aG9kcyZhbXA7bW9kdWxlc1tdPWlldGYtbDMtdW5pY2FzdC10b3Bv
bG9neSZhbXA7bW9kdWxlc1tdPWlldGYtbDMtdW5pY2FzdC10b3BvbG9neS1zdGF0ZSZhbXA7
bW9kdWxlc1tdPWlldGYtbmV0d29yay10b3BvbG9neSZhbXA7bW9kdWxlc1tdPWlldGYtbmV0
d29yay10b3BvbG9neS1zdGF0ZSZhbXA7bW9kdWxlc1tdPWlldGYtbmV0d29yayZhbXA7bW9k
dWxlc1tdPWlldGYtbmV0d29yay1zdGF0ZSZhbXA7bW9kdWxlc1tdPWlldGYtbDN2cG4tc3Zj
JmFtcDttb2R1bGVzW109aWV0Zi1uZXRjb25mLWFjbSZhbXA7bW9kdWxlc1tdPWlldGYtaW50
ZXJmYWNlcyZhbXA7bW9kdWxlc1tdPWlldGYtdnJycCZhbXA7bW9kdWxlc1tdPWlldGYtcmlw
JmFtcDttb2R1bGVzW109aWV0Zi1kYXRhc3RvcmVzJmFtcDttb2R1bGVzW109aWV0Zi1vcmln
aW4mYW1wO3JlY3Vyc2U9MSZhbXA7cmZjcz0xJmFtcDtzaG93X3N1Ym09MSZhbXA7c2hvd19k
aXI9ZGVwZW5kZW5jaWVzIj5IZXJlDQogICAgICAgICAgICAgIGFyZSB0aGUgWUFORyBtb2R1
bGUgZGVwZW5kZW5jaWVzPC9hPiBmb3IgdGhlc2UgUkZDIGVkaXRvcg0KICAgICAgICAgICAg
bW9kdWxlcywgYXMgcmVxdWlyZW1lbnQgYmVmb3JlIHB1Ymxpc2hpbmcuPGJyPg0KICAgICAg
ICAgICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgICAg
ICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgICAgICAg
ICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPiA8YnI+DQogICAgICAgICAgICAgICAg
ICBTb21lIG1vcmUgWUFORyBtb2R1bGVzIGFyZSBvbiB0aGUgSUVTRyB0YWJsZTo8YnI+DQog
ICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1waW0teWFuZyBoYXMgYSBESVND
VVNTIChKYW4gMTF0aCBJRVNHDQogICAgICAgICAgICAgICAgICB0ZWxlY2hhdCk8YnI+DQog
ICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcyBp
cyBvbiB0aGUgSmFuIDI1dGgNCiAgICAgICAgICAgICAgICAgIElFU0cgdGVsZWNoYXQ8YnI+
DQogICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGlz
IG9uIHRoZSBKYW4gMjV0aCBJRVNHDQogICAgICAgICAgICAgICAgICB0ZWxlY2hhdCDCoMKg
IDxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIEFzc3Vt
aW5nIHRob3NlIGFyZSBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSwgdGhpcyBpcw0KICAgICAg
ICAgICAgICAgICAgdGhlIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHBz
Oi8vd3d3LnlhbmdjYXRhbG9nLm9yZy95YW5nLXNlYXJjaC9pbXBhY3RfYW5hbHlzaXMucGhw
P21vZHVsZXNbXT1pZXRmLWlwJmFtcDttb2R1bGVzW109aWV0Zi1jb25uZWN0aW9ubGVzcy1v
YW0mYW1wO21vZHVsZXNbXT1pZXRmLWxpbWUtdGltZS10eXBlcyZhbXA7bW9kdWxlc1tdPWll
dGYtY29ubmVjdGlvbmxlc3Mtb2FtLW1ldGhvZHMmYW1wO21vZHVsZXNbXT1pZXRmLWwzLXVu
aWNhc3QtdG9wb2xvZ3kmYW1wO21vZHVsZXNbXT1pZXRmLWwzLXVuaWNhc3QtdG9wb2xvZ3kt
c3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xvZ3kmYW1wO21vZHVsZXNb
XT1pZXRmLW5ldHdvcmstdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdv
cmsmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRm
LWwzdnBuLXN2YyZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29uZi1hY20mYW1wO21vZHVsZXNb
XT1pZXRmLWludGVyZmFjZXMmYW1wO21vZHVsZXNbXT1pZXRmLXZycnAmYW1wO21vZHVsZXNb
XT1pZXRmLXJpcCZhbXA7bW9kdWxlc1tdPWlldGYtcGltLWRtJmFtcDttb2R1bGVzW109aWV0
Zi1waW0tYmFzZSZhbXA7bW9kdWxlc1tdPWlldGYtcGltLXNtJmFtcDttb2R1bGVzW109aWV0
Zi1waW0tYmlkaXImYW1wO21vZHVsZXNbXT1pZXRmLXBpbS1ycCZhbXA7bW9kdWxlc1tdPWll
dGYtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtaXB2Ni1yb3V0ZXItYWR2ZXJ0aXNlbWVu
dHMmYW1wO21vZHVsZXNbXT1pZXRmLWlwdjQtdW5pY2FzdC1yb3V0aW5nJmFtcDttb2R1bGVz
W109aWV0Zi1pcHY2LXVuaWNhc3Qtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtZW50aXR5
JmFtcDttb2R1bGVzW109aWV0Zi1kYXRhc3RvcmVzJmFtcDttb2R1bGVzW109aWV0Zi1vcmln
aW4mYW1wO3JlY3Vyc2U9MSZhbXA7cmZjcz0xJmFtcDtzaG93X3N1Ym09MSZhbXA7c2hvd19k
aXI9ZGVwZW5kZW5jaWVzIj5uZXcNCiAgICAgICAgICAgICAgICAgICAgc2V0IG9mIFlBTkcg
bW9kdWxlIGRlcGVuZGVuY2llczwvYT4uPGJyPg0KICAgICAgICAgICAgICAgICAgSXQgdGFr
ZXMgYSBsaXR0bGUgYml0IG9mIHJlLWFycmFuZ2VyaW5nIHRoZSBlbGVtZW50cywNCiAgICAg
ICAgICAgICAgICAgIGJ1dCBhbGwgdGhlIGluZm9ybWF0aW9uIGlzIHRoZXJlLjxicj4NCiAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIDxmb250IGNvbG9yPSIj
ZmYwMDAwIj5UaGUgbmV4dCBib3R0bGVuZWNrcyBmb3INCiAgICAgICAgICAgICAgICAgICAg
cHVibGlzaGluZyB0aG9zZSBZQU5HIG1vZHVsZXMgYXJlOjxicj4NCiAgICAgICAgICAgICAg
ICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWw8YnI+DQog
ICAgICAgICAgICAgICAgICAgIMKgwqDCoCBpZXRmLWJmZC15YW5nPGJyPg0KICAgICAgICAg
ICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1vc3BmLXlhbmc8YnI+DQogICAgICAgICAg
ICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZzxicj4NCiAg
ICAgICAgICAgICAgICAgICAgUGxlYXNlIHByb2dyZXNzIHRob3NlIGRvY3VtZW50cyBhc2Fw
PC9mb250Pjxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
IFNvbWUgbW9yZSB1cGRhdGVzIGJlbG93Ljxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4N
CiAgICAgICAgICAgICAgICAgIDx1PiBOSSwgTE5FLCBhbmQgc2NoZW1hIG1vdW50LCBSRkM3
ODk1YmlzLCBzY2hlbWENCiAgICAgICAgICAgICAgICAgICAgbW91bnQ6PC91Pjxicj4NCiAg
ICAgICAgICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLXJ0Z3dnLWxuZS1tb2RlbDxicj4N
CiAgICAgICAgICAgICAgICAgIMKgwqDCoCDCoMKgwqAgU3RhdHVzOiBQdWJsaWNhdGlvbiBy
ZXF1ZXN0ZWQsIEFsaWEncyBBRA0KICAgICAgICAgICAgICAgICAgcmV2aWV3PGJyPg0KICAg
ICAgICAgICAgICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWw8YnI+DQog
ICAgICAgICAgICAgICAgICDCoMKgwqAgwqDCoMKgIFN0YXR1czogUHVibGljYXRpb24gcmVx
dWVzdGVkLCBBbGlhJ3MgQUQNCiAgICAgICAgICAgICAgICAgIHJldmlldzxicj4NCiAgICAg
ICAgICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQ6PGJy
Pg0KICAgICAgICAgICAgICAgICAgwqDCoMKgIMKgwqDCoCBTdGF0dXM6wqAgV0cgTEMgY2xv
c2VkLCBub3Qgc3VyZSBvbiB0aGUgbmV4dA0KICAgICAgICAgICAgICAgICAgc3RlcHMgLi4u
wqAgPGJyPg0KICAgICAgICAgICAgICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtbmV0Y29uZi1y
ZmM3ODk1YmlzPGJyPg0KICAgICAgICAgICAgICAgICAgwqDCoMKgIMKgwqDCoCBTdGF0dXMg
bm90IGNsZWFyLi4uPGJyPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDx1PkxJTUU6PC91Pjxicj4NCiAgICAgICAg
ICAgICAgICDCoMKgwqANCiAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWxpbWUteWFuZy1j
b25uZWN0aW9uLW9yaWVudGVkLW9hbS1tb2RlbC0wMDxicj4NCiAgICAgICAgICAgICAgICDC
oMKgwqAgwqDCoMKgIFN0YXR1czogQmVub2l0IHRvIHBlcmZvcm0gdGhlIEFEIHJldmlldy48
YnI+DQogICAgICAgICAgICAgICAgwqDCoMKgIDxicj4NCiAgICAgICAgICAgICAgICBSZWdh
cmRzLCBCZW5vaXQ8YnI+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQog
ICAgPC9kaXY+DQogIDwvYm9keT4NCjwvaHRtbD4NCg==
--------------56FB4018894B70831905DACF--


From nobody Tue Jan 16 03:32:00 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 960AA131465 for ; Tue, 16 Jan 2018 03:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 UrYsEWJF_5Qv for ; Tue, 16 Jan 2018 03:31:52 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 DEDF913146C for ; Tue, 16 Jan 2018 03:31:42 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id F01D51AD4D8 for ; Tue, 16 Jan 2018 04:30:11 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id yzW81w00q2SSUrH01zWBNx; Tue, 16 Jan 2018 04:30:11 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=rZezk55Em_u8EZyG8o4A:9 a=CjuIK1q_8ugA:10 a=w1C3t2QeGrPiZgrLijVG:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=89QdueGaXk+C9M6uRfrWxfU5ucEHlXXVgGoj0P1P4N8=; b=RD4tZ2NopA0guDK9ntDro4nKBA Y9u8ZCyV4mK5OdLtgO+rIjVkwoQLRHyYgmubmdbjx5x4rp3NIDQL0IiH3Mn/GRj125FsABsD83LcF eIhIRsi+B3r+Y5y+HqFYYrx3N;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44508 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebPRQ-002mNC-JV; Tue, 16 Jan 2018 04:30:08 -0700
From: Lou Berger 
To: Ladislav Lhotka , Martin Bjorklund 
CC: NETMOD WG 
Date: Tue, 16 Jan 2018 06:30:06 -0500
Message-ID: <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <1516086847.3188.24.camel@nic.cz>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
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-Exim-ID: 1ebPRQ-002mNC-JV
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:44508
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 11:31:55 -0000

Lada,

It sounds like you are proposing in (1) a fairly significant change in the 
direction of the draft and in (2) a basic approach that has been 
rejectected by the WG multiple times.  FWIW there are drafts already with 
the iesg that will need to be returned to their WGs if either change is made.

Martin,

Do share Lada's view?

Lou


On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:

> Hi Lou,
>
> in my view, we should do the following two (significant) changes:
>
> 1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
> list of mounted schemas, we should keep *all* mounted schemas directly in the
> YANG library and refer to them from schema-mounts structures. Juergen suggested
> this change and it is IMO the right thing to do.
>
> 2. Define a metadata annotation (e.g. @schema-ref) that would be required for
> inline mount point instances and specify the inline-mounted schema also by
> referring to a schema specified in YANG library.
>
> The advantage of #2 is that an annotation can be attached equally well to both
> state an configuration data. So, instead of papering over the issue that YANG
> library (state data) cannot appear in configuration datastores, we can use this
> general and straightforward approach. This also allows for defining different
> mounted schemas for instances of the same mount point in different datastores.
>
> I strongly believe that these changes (along with the new YANG library schema
> and NMDA) make for a simple and elegant datastore architecture in which schema
> mount would be an optional feature.
>
> Lada
>
>
>
> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> Lada/Martin,
>>
>> I don't believe we reached closure on this discussion.  The open issues
>> relate to proposed new text (slightly modified):
>>
>> at the end of the section [3.2] adding a new paragraph along the
>> lines of:
>>
>>    The use of mount points does not impact the nature of the
>>    mounted data or in which data store information is made
>>    available. For example, mounted YANG Library modules define
>>    only operational state data and, as such, the information in
>>    these modules is available from operational data stores using
>>    the appropriate protocol operations.  It is also worth
>>    noting that the Schema Mount module itself parallels the
>>    YANG Library module and only defines operational state data.
>>
>> Is this change acceptable?
>>
>> What other issues related to SM are outstanding?
>>
>> Thank you,
>>
>> Lou
>>
>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>> > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>> > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>> > > > > Hi Lada,
>> > > > >
>> > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>> > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>> > > > > > > Lada,
>> > > > > > >
>> > > > > > >
>> > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka 
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>> > > > > > > > > lada,
>> > > > > > > > >
>> > > > > > > > >      See below.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>> > > > > > > > > > Hi,
>> > > > > > > > > >
>> > > > > > > > > > unfortunately, using an action for querying embedded YANG
>> > > > > > > > > > library
>> > > > > > > > > > data
>> > > > > > > > > > (needed for the "inline" case of schema mount) doesn't work
>> > > > > > > > > > either
>> > > > > > > > > > because now under NMDA actions can be used only on instances
>> > > > > > > > > > in
>> > > > > > > > > > the
>> > > > > > > > > >  datastore.
>> > > > > > > > >
>> > > > > > > > > but the inline/embedded library would (only) be present in the
>> > > > > > > > > in
>> > > > > > > > > the
>> > > > > > > > > operational datastore, so what's the issue?
>> > > > > > > >
>> > > > > > > > Well, the issue is described in my initial mail of this thread:
>> > > > > > > > the
>> > > > > > > > current
>> > > > > > > > text
>> > > > > > > > requires that every instance of an inline mount point contains
>> > > > > > > > the
>> > > > > > > > embedded
>> > > > > > > > YANG library. Tha latter is state data, so the above requirement
>> > > > > > > > cannot
>> > > > > > > > be
>> > > > > > > > satisfied if the mount point instance is in a configuration
>> > > > > > > > datastore.
>> > > > > > > >
>> > > > > > >
>> > > > > > > That's not how I read the intent of the current text.  I don't see
>> > > > > > > SM
>> > > > > > > impacting which data stores information is presented.  Just like
>> > > > > > > use
>> > > > > > > of
>> > > > > > > scheme mount doesn't transform RO configuration information into
>> > > > > > > operational information.  I sent you a couple of sentences
>> > > > > > > clarifying
>> > > > > > > this
>> > > > > > > at one point, I'll dig up the proposed text and resend.
>> > > > > >
>> > > > > > Please do, this has to be discussed in the WG mailing list.
>> > > > >
>> > > > > Agreed - that's why I asked to start this thread!
>> > > > >
>> > > > > Here's the original proposal:
>> > > > >
>> > > > >    How about at the end of the section [3.2] adding a new
>> > > > >    paragraph along the lines of:
>> > > > >
>> > > > >    It is important to note that both YANG Library and Schema
>> > > > >    Mount Modules contain only operational state data. As such,
>> > > >
>> > > > s/contain/define/
>> > > >
>> > > > >    the information in these modules should be retrieved by
>> > > > >    clients from operational data stores using the appropriate
>> > > >
>> > > > This is based on two assumptions:
>> > > >
>> > > > 1. For every configuration datastore there is a corresponding
>> > > > operational
>> > > > datastore.
>> > >
>> > > well the text is revised below.  In any case, "these modules" refers to
>> > > yang library, and yes, I'm assuming YL is always and only in
>> > > operational.  If the revised text below isn't clear s/these/YANG Library/
>> > > -
>> >
>> > The thing is that we have the top-level YANG library in , and
>> > then
>> > embedded YANG libraries scattered inside inline mount point instances.
>> >
>> > > > 2. For every mount point instance in any configuration datastore there
>> > > > is a
>> > > > corresponding mount point instance (with the same path) in an
>> > > > operational
>> > > > datastore.
>> > > >
>> > > > I think that neither of these has to be true in general.
>> > >
>> > > agreed in general, but for inline, where YL is required, it must be true.
>> >
>> > How do you know? I provided an example in Singapore where a mount point
>> > instance
>> > in  is a part of pre-provisioned data (for non-existent hardware).
>> > Then, according to the NMDA rules there is no corresponding instance in
>> > , hence no place where the embedded YANG library can be placed.
>> > (I can easily provide a concrete example if needed).
>> >
>> >
>> > Dean replied that this cannot happen, so it seems there are some assumptions
>> > how
>> > the inline method of schema mount may be applied. If so, these assumptions
>> > have
>> > to be explicitly stated.
>> >
>> > > > >    protocol operations.
>> > > >
>> > > > In contrast, the substance of my proposal with metadata annotations is
>> > > > to be
>> > > > able to retrieve all schemas from a well-known location in *the*
>> > > > 
>> > > > datastore, namely from the top-level YANG library.
>> > >
>> > > What about a schema that is based on dll that contains modules that
>> > > isn't loaded until a mount point is instantiated -- this is certainly a
>> > > valid approach for supporting LNEs, but would be precluded in this
>> > > approach.  I really don't think a top level approach works for all
>> > > inline (managed) types of mounts.
>> >
>> > It isn't precluded: when the mount point is instantiated (no matter which
>> > datastore it is in), the server adds the schema as a new entry to the
>> > "schema"
>> > list in the top level YANG library (with a unique key), and annotates the
>> > mount
>> > point instance with a leafref pointing to that key. So different instances
>> > of
>> > the same mount point can have different schemas.
>> >
>> > > > > Given this discussion, we can generalize it further to:
>> > > > >
>> > > > >    The use of mount points does not impact the nature of the
>> > > > >    mounted data or in which data store information is made
>> > > > >    available. For example, mounted YANG Library modules contain
>> > > > >    only operational state data and, as such, the information in
>> > > > >    these modules is available from operational data stores using
>> > > > >    the appropriate protocol operations.
>> > > >
>> > > > The whole question here is whether and how we can locate the schema for
>> > > > an
>> > > > inline mount point in any configuration datastore.
>> > >
>> > > Why is a mounted YL different than a top level YL?  What works for and
>> >
>> > It is not different, but it can be only in an operational datastores, and so
>> > for
>> > mount point instances inside configuration datastores we need a way how to
>> > locate the schema for that mount point, because it cannot be found directly
>> > under the mount point instance (as the current text assumes).
>> >
>> > > is sufficient for the normal case of YL shouldn't be impacted or
>> > > modified by SM -- at least that's how I thought we've been talking about
>> > > since SM was started.  Again, we never made any special provisions for
>> > > any other rw/ro/state data, assuming top level YL is not handled as
>> > > metadata, why start now?
>> > >
>> > > I'm getting the impression that your argument may be more about if YL
>> > > should be treated as something other than operational data, is this wrong?
>> >
>> > This is wrong. My argument is that there should be only one top-level YANG
>> > library (state data) and each inline mount point instance just points to a
>> > schema inside it by means of a metadata annotation attached to the mount
>> > point
>> > (in any datastore).
>> >
>> > Lada
>> >
>> > > Thanks,
>> > > Lou
>> > >
>> > > > Lada
>> > > >
>> > > > > Lou
>> > > > >
>> > > > > > Lada
>> > > > > >
>> > > > > > > Lou
>> > > > > > > > > > However, a good alternative seems to be a metadata
>> > > > > > > > > > annotation
>> > > > > > > > > > along
>> > > > > > > > > > the
>> > > > > > > > > > lines of RFC 7952, for example with the alternative B of the
>> > > > > > > > > > newly
>> > > > > > > > > > proposed YANG library schema:
>> > > > > > > > > >
>> > > > > > > > > >       md:annotation schema-ref {
>> > > > > > > > > >         type leafref {
>> > > > > > > > > >           path "/yanglib:yang-
>> > > > > > > > > > library/yanglib:schema/yanglib:name";
>> > > > > > > > > >         }
>> > > > > > > > > >       }
>> > > > > > > > > >
>> > > > > > > > > > In other words, all inline mounted schemas would be included
>> > > > > > > > > > in
>> > > > > > > > > > the
>> > > > > > > > > > top-level YANG library, and mount point instances in all
>> > > > > > > > > > datastores
>> > > > > > > > > > would be annotated with leafref pointing to the actual
>> > > > > > > > > > schema.
>> > > > > > > > > >
>> > > > > > > > > > Unlike regular state data, it is IMO no problem to permit
>> > > > > > > > > > such
>> > > > > > > > > > annotations in configuration datastores.
>> > > > > > > > > >
>> > > > > > > > > > Opinions?
>> > > > > > > > >
>> > > > > > > > > I'm not sure this will work for all architectures of LNEs as
>> > > > > > > > > well
>> > > > > > > > > as
>> > > > > > > > > other possible future use cases.  In short, this seems *very*
>> > > > > > > > > restrictive.
>> > > > > > > >
>> > > > > > > > I don't understand, IMO it is not restrictive at all. What kind
>> > > > > > > > of
>> > > > > > > > restrictions
>> > > > > > > > do you see?
>> > > > > > > >
>> > > > > > > > Lada
>> > > > > > > >
>> > > > > > > > > Lou
>> > > > > > > > >
>> > > > > > > > > > Thanks, Lada
>> > > > > > > > > >
>> > > > > > > > > > Ladislav Lhotka  writes:
>> > > > > > > > > >
>> > > > > > > > > > > Hi,
>> > > > > > > > > > >
>> > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is wrong
>> > > > > > > > > > > for
>> > > > > > > > > > > traditional
>> > > > > > > > > > > datastores, and even more so for NDMA:
>> > > > > > > > > > >
>> > > > > > > > > > >     In case 1 ["inline"], the mounted schema is determined
>> > > > > > > > > > > at
>> > > > > > > > > > > run
>> > > > > > > > > > > time:
>> > > > > > > > > > > every
>> > > > > > > > > > >     instance of the mount point that exists in the parent
>> > > > > > > > > > > tree
>> > > > > > > > > > > MUST
>> > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
>> > > > > > > > > > > defines
>> > > > > > > > > > > the
>> > > > > > > > > > >     mounted schema exactly as for a top-level data
>> > > > > > > > > > > model.  A
>> > > > > > > > > > > client
>> > > > > > > > > > > is
>> > > > > > > > > > >     expected to retrieve this data from the instance tree,
>> > > > > > > > > > > possibly
>> > > > > > > > > > > after
>> > > > > > > > > > >     creating the mount point.  Instances of the same mount
>> > > > > > > > > > > point
>> > > > > > > > > > > MAY
>> > > > > > > > > > > use
>> > > > > > > > > > >     different mounted schemas.
>> > > > > > > > > > >
>> > > > > > > > > > > An instance of the mount point in any *configuration*
>> > > > > > > > > > > datastores
>> > > > > > > > > > > cannot
>> > > > > > > > > > > contain
>> > > > > > > > > > > YANG library (being state data), and so the MUST cannot
>> > > > > > > > > > > hold.
>> > > > > > > > > > >
>> > > > > > > > > > > It is not clear to me how to repair this without
>> > > > > > > > > > > considerable
>> > > > > > > > > > > complications
>> > > > > > > > > > > and/or a lot of handwaving. There is actually one good
>> > > > > > > > > > > solution
>> > > > > > > > > > > but it
>> > > > > > > > > > > has
>> > > > > > > > > > > impact on YANG library: the server could provide it in a
>> > > > > > > > > > > reply
>> > > > > > > > > > > to
>> > > > > > > > > > > an
>> > > > > > > > > > > operation,
>> > > > > > > > > > > say "get-yang-library" rather than as state data. Then
>> > > > > > > > > > > everything
>> > > > > > > > > > > would be
>> > > > > > > > > > > fine
>> > > > > > > > > > > - this operation would turn into an action for the mount
>> > > > > > > > > > > point,
>> > > > > > > > > > > and it
>> > > > > > > > > > > can
>> > > > > > > > > > > be
>> > > > > > > > > > > used equally well for config true and false mount points.
>> > > > > > > > > > >
>> > > > > > > > > > > So my proposal is to move from YANG library as state data
>> > > > > > > > > > > to
>> > > > > > > > > > > an
>> > > > > > > > > > > operation.
>> > > > > > > > > > > It
>> > > > > > > > > > > could be done along with changing the YANG library
>> > > > > > > > > > > structure,
>> > > > > > > > > > > so
>> > > > > > > > > > > there
>> > > > > > > > > > > will be
>> > > > > > > > > > > little extra impact on implementations.
>> > > > > > > > > > >
>> > > > > > > > > > > Lada
>> > > > > > > > > > >
>> > > > > > > > > > > --
>> > > > > > > > > > > Ladislav Lhotka
>> > > > > > > > > > > Head, CZ.NIC Labs
>> > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
>> > > > > > > > > > >
>> > > > > > > > > > > _______________________________________________
>> > > > > > > > > > > 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
>> > > > > > > >
>>
>>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>



From nobody Tue Jan 16 04:07: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 2055613145D for ; Tue, 16 Jan 2018 04:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 BZPHpo3wydBh for ; Tue, 16 Jan 2018 04:06:50 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 D30841274D2 for ; Tue, 16 Jan 2018 04:06:47 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id EDDE1644A1; Tue, 16 Jan 2018 13:06:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516104405; bh=MrPjjXGIEyAqLO1sMKfbVb3yEL1Ncmtg8sxWQP9EvUs=; h=From:To:Date; b=pXDirk56vNpJYPsDFFnhfr+PcGlBAoq5szvk4/dRjudcbCDGfRxeti7B7VRMZUmLe p81+0+G5xM68myb3SlP5NZlYJPuRcAWCV3sU96MKZybLrwP/kZOuQ7zxXaFeeN5jDh 7eB4VrrFqdNJop81gW1TNRUT+nj/LhEVTcVlRTz8=
Message-ID: <1516104404.11372.15.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: NETMOD WG 
Date: Tue, 16 Jan 2018 13:06:44 +0100
In-Reply-To: <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz> <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:07:00 -0000

On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> Lada,
> 
> It sounds like you are proposing in (1) a fairly significant change in the 
> direction of the draft and in (2) a basic approach that has been

It is no change in direction, just a simplification of the schema-describing
state data. Given the recent developments in 7895bis it makes no sense to me to
have two "schema" lists if we can have just one.

>  
> rejectected by the WG multiple times.  FWIW there are drafts already with

No at all. The first and last time I proposed this was on 15 December 2017:

https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html

The only reply was from you. To me, it is the cleanest solution of the inline
case. Of course, I am open to technical objections.

If it's not clear what I mean, I can make up some examples.

Lada


> the iesg that will need to be returned to their WGs if either change is made.
> 
> Martin,
> 
> Do share Lada's view?
> 
> Lou
> 
> 
> On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:
> 
> > Hi Lou,
> > 
> > in my view, we should do the following two (significant) changes:
> > 
> > 1. Instead of borrowing a grouping from ietf-yang-library and having a
> > parallel
> > list of mounted schemas, we should keep *all* mounted schemas directly in
> > the
> > YANG library and refer to them from schema-mounts structures. Juergen
> > suggested
> > this change and it is IMO the right thing to do.
> > 
> > 2. Define a metadata annotation (e.g. @schema-ref) that would be required
> > for
> > inline mount point instances and specify the inline-mounted schema also by
> > referring to a schema specified in YANG library.
> > 
> > The advantage of #2 is that an annotation can be attached equally well to
> > both
> > state an configuration data. So, instead of papering over the issue that
> > YANG
> > library (state data) cannot appear in configuration datastores, we can use
> > this
> > general and straightforward approach. This also allows for defining
> > different
> > mounted schemas for instances of the same mount point in different
> > datastores.
> > 
> > I strongly believe that these changes (along with the new YANG library
> > schema
> > and NMDA) make for a simple and elegant datastore architecture in which
> > schema
> > mount would be an optional feature.
> > 
> > Lada
> > 
> > 
> > 
> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> > > Lada/Martin,
> > > 
> > > I don't believe we reached closure on this discussion.  The open issues
> > > relate to proposed new text (slightly modified):
> > > 
> > > at the end of the section [3.2] adding a new paragraph along the
> > > lines of:
> > > 
> > >    The use of mount points does not impact the nature of the
> > >    mounted data or in which data store information is made
> > >    available. For example, mounted YANG Library modules define
> > >    only operational state data and, as such, the information in
> > >    these modules is available from operational data stores using
> > >    the appropriate protocol operations.  It is also worth
> > >    noting that the Schema Mount module itself parallels the
> > >    YANG Library module and only defines operational state data.
> > > 
> > > Is this change acceptable?
> > > 
> > > What other issues related to SM are outstanding?
> > > 
> > > Thank you,
> > > 
> > > Lou
> > > 
> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > > > Hi Lada,
> > > > > > > 
> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > > > Lada,
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka  > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > > > lada,
> > > > > > > > > > > 
> > > > > > > > > > >      See below.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > unfortunately, using an action for querying embedded
> > > > > > > > > > > > YANG
> > > > > > > > > > > > library
> > > > > > > > > > > > data
> > > > > > > > > > > > (needed for the "inline" case of schema mount) doesn't
> > > > > > > > > > > > work
> > > > > > > > > > > > either
> > > > > > > > > > > > because now under NMDA actions can be used only on
> > > > > > > > > > > > instances
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > >  datastore.
> > > > > > > > > > > 
> > > > > > > > > > > but the inline/embedded library would (only) be present in
> > > > > > > > > > > the
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > > > 
> > > > > > > > > > Well, the issue is described in my initial mail of this
> > > > > > > > > > thread:
> > > > > > > > > > the
> > > > > > > > > > current
> > > > > > > > > > text
> > > > > > > > > > requires that every instance of an inline mount point
> > > > > > > > > > contains
> > > > > > > > > > the
> > > > > > > > > > embedded
> > > > > > > > > > YANG library. Tha latter is state data, so the above
> > > > > > > > > > requirement
> > > > > > > > > > cannot
> > > > > > > > > > be
> > > > > > > > > > satisfied if the mount point instance is in a configuration
> > > > > > > > > > datastore.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > That's not how I read the intent of the current text.  I don't
> > > > > > > > > see
> > > > > > > > > SM
> > > > > > > > > impacting which data stores information is presented.  Just
> > > > > > > > > like
> > > > > > > > > use
> > > > > > > > > of
> > > > > > > > > scheme mount doesn't transform RO configuration information
> > > > > > > > > into
> > > > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > > > clarifying
> > > > > > > > > this
> > > > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > > > 
> > > > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > > > 
> > > > > > > Agreed - that's why I asked to start this thread!
> > > > > > > 
> > > > > > > Here's the original proposal:
> > > > > > > 
> > > > > > >    How about at the end of the section [3.2] adding a new
> > > > > > >    paragraph along the lines of:
> > > > > > > 
> > > > > > >    It is important to note that both YANG Library and Schema
> > > > > > >    Mount Modules contain only operational state data. As such,
> > > > > > 
> > > > > > s/contain/define/
> > > > > > 
> > > > > > >    the information in these modules should be retrieved by
> > > > > > >    clients from operational data stores using the appropriate
> > > > > > 
> > > > > > This is based on two assumptions:
> > > > > > 
> > > > > > 1. For every configuration datastore there is a corresponding
> > > > > > operational
> > > > > > datastore.
> > > > > 
> > > > > well the text is revised below.  In any case, "these modules" refers
> > > > > to
> > > > > yang library, and yes, I'm assuming YL is always and only in
> > > > > operational.  If the revised text below isn't clear s/these/YANG
> > > > > Library/
> > > > > -
> > > > 
> > > > The thing is that we have the top-level YANG library in ,
> > > > and
> > > > then
> > > > embedded YANG libraries scattered inside inline mount point instances.
> > > > 
> > > > > > 2. For every mount point instance in any configuration datastore
> > > > > > there
> > > > > > is a
> > > > > > corresponding mount point instance (with the same path) in an
> > > > > > operational
> > > > > > datastore.
> > > > > > 
> > > > > > I think that neither of these has to be true in general.
> > > > > 
> > > > > agreed in general, but for inline, where YL is required, it must be
> > > > > true.
> > > > 
> > > > How do you know? I provided an example in Singapore where a mount point
> > > > instance
> > > > in  is a part of pre-provisioned data (for non-existent
> > > > hardware).
> > > > Then, according to the NMDA rules there is no corresponding instance in
> > > > , hence no place where the embedded YANG library can be
> > > > placed.
> > > > (I can easily provide a concrete example if needed).
> > > > 
> > > > 
> > > > Dean replied that this cannot happen, so it seems there are some
> > > > assumptions
> > > > how
> > > > the inline method of schema mount may be applied. If so, these
> > > > assumptions
> > > > have
> > > > to be explicitly stated.
> > > > 
> > > > > > >    protocol operations.
> > > > > > 
> > > > > > In contrast, the substance of my proposal with metadata annotations
> > > > > > is
> > > > > > to be
> > > > > > able to retrieve all schemas from a well-known location in *the*
> > > > > > 
> > > > > > datastore, namely from the top-level YANG library.
> > > > > 
> > > > > What about a schema that is based on dll that contains modules that
> > > > > isn't loaded until a mount point is instantiated -- this is certainly
> > > > > a
> > > > > valid approach for supporting LNEs, but would be precluded in this
> > > > > approach.  I really don't think a top level approach works for all
> > > > > inline (managed) types of mounts.
> > > > 
> > > > It isn't precluded: when the mount point is instantiated (no matter
> > > > which
> > > > datastore it is in), the server adds the schema as a new entry to the
> > > > "schema"
> > > > list in the top level YANG library (with a unique key), and annotates
> > > > the
> > > > mount
> > > > point instance with a leafref pointing to that key. So different
> > > > instances
> > > > of
> > > > the same mount point can have different schemas.
> > > > 
> > > > > > > Given this discussion, we can generalize it further to:
> > > > > > > 
> > > > > > >    The use of mount points does not impact the nature of the
> > > > > > >    mounted data or in which data store information is made
> > > > > > >    available. For example, mounted YANG Library modules contain
> > > > > > >    only operational state data and, as such, the information in
> > > > > > >    these modules is available from operational data stores using
> > > > > > >    the appropriate protocol operations.
> > > > > > 
> > > > > > The whole question here is whether and how we can locate the schema
> > > > > > for
> > > > > > an
> > > > > > inline mount point in any configuration datastore.
> > > > > 
> > > > > Why is a mounted YL different than a top level YL?  What works for and
> > > > 
> > > > It is not different, but it can be only in an operational datastores,
> > > > and so
> > > > for
> > > > mount point instances inside configuration datastores we need a way how
> > > > to
> > > > locate the schema for that mount point, because it cannot be found
> > > > directly
> > > > under the mount point instance (as the current text assumes).
> > > > 
> > > > > is sufficient for the normal case of YL shouldn't be impacted or
> > > > > modified by SM -- at least that's how I thought we've been talking
> > > > > about
> > > > > since SM was started.  Again, we never made any special provisions for
> > > > > any other rw/ro/state data, assuming top level YL is not handled as
> > > > > metadata, why start now?
> > > > > 
> > > > > I'm getting the impression that your argument may be more about if YL
> > > > > should be treated as something other than operational data, is this
> > > > > wrong?
> > > > 
> > > > This is wrong. My argument is that there should be only one top-level
> > > > YANG
> > > > library (state data) and each inline mount point instance just points to
> > > > a
> > > > schema inside it by means of a metadata annotation attached to the mount
> > > > point
> > > > (in any datastore).
> > > > 
> > > > Lada
> > > > 
> > > > > Thanks,
> > > > > Lou
> > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > > Lou
> > > > > > > 
> > > > > > > > Lada
> > > > > > > > 
> > > > > > > > > Lou
> > > > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > > > annotation
> > > > > > > > > > > > along
> > > > > > > > > > > > the
> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B of
> > > > > > > > > > > > the
> > > > > > > > > > > > newly
> > > > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > > > 
> > > > > > > > > > > >       md:annotation schema-ref {
> > > > > > > > > > > >         type leafref {
> > > > > > > > > > > >           path "/yanglib:yang-
> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > > > >         }
> > > > > > > > > > > >       }
> > > > > > > > > > > > 
> > > > > > > > > > > > In other words, all inline mounted schemas would be
> > > > > > > > > > > > included
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > top-level YANG library, and mount point instances in all
> > > > > > > > > > > > datastores
> > > > > > > > > > > > would be annotated with leafref pointing to the actual
> > > > > > > > > > > > schema.
> > > > > > > > > > > > 
> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> > > > > > > > > > > > permit
> > > > > > > > > > > > such
> > > > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > > > 
> > > > > > > > > > > > Opinions?
> > > > > > > > > > > 
> > > > > > > > > > > I'm not sure this will work for all architectures of LNEs
> > > > > > > > > > > as
> > > > > > > > > > > well
> > > > > > > > > > > as
> > > > > > > > > > > other possible future use cases.  In short, this seems
> > > > > > > > > > > *very*
> > > > > > > > > > > restrictive.
> > > > > > > > > > 
> > > > > > > > > > I don't understand, IMO it is not restrictive at all. What
> > > > > > > > > > kind
> > > > > > > > > > of
> > > > > > > > > > restrictions
> > > > > > > > > > do you see?
> > > > > > > > > > 
> > > > > > > > > > Lada
> > > > > > > > > > 
> > > > > > > > > > > Lou
> > > > > > > > > > > 
> > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is
> > > > > > > > > > > > > wrong
> > > > > > > > > > > > > for
> > > > > > > > > > > > > traditional
> > > > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > > > 
> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
> > > > > > > > > > > > > determined
> > > > > > > > > > > > > at
> > > > > > > > > > > > > run
> > > > > > > > > > > > > time:
> > > > > > > > > > > > > every
> > > > > > > > > > > > >     instance of the mount point that exists in the
> > > > > > > > > > > > > parent
> > > > > > > > > > > > > tree
> > > > > > > > > > > > > MUST
> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
> > > > > > > > > > > > > defines
> > > > > > > > > > > > > the
> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
> > > > > > > > > > > > > model.  A
> > > > > > > > > > > > > client
> > > > > > > > > > > > > is
> > > > > > > > > > > > >     expected to retrieve this data from the instance
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > possibly
> > > > > > > > > > > > > after
> > > > > > > > > > > > >     creating the mount point.  Instances of the same
> > > > > > > > > > > > > mount
> > > > > > > > > > > > > point
> > > > > > > > > > > > > MAY
> > > > > > > > > > > > > use
> > > > > > > > > > > > >     different mounted schemas.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > An instance of the mount point in any *configuration*
> > > > > > > > > > > > > datastores
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > contain
> > > > > > > > > > > > > YANG library (being state data), and so the MUST
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > hold.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > > > considerable
> > > > > > > > > > > > > complications
> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one good
> > > > > > > > > > > > > solution
> > > > > > > > > > > > > but it
> > > > > > > > > > > > > has
> > > > > > > > > > > > > impact on YANG library: the server could provide it in
> > > > > > > > > > > > > a
> > > > > > > > > > > > > reply
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation,
> > > > > > > > > > > > > say "get-yang-library" rather than as state data. Then
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > would be
> > > > > > > > > > > > > fine
> > > > > > > > > > > > > - this operation would turn into an action for the
> > > > > > > > > > > > > mount
> > > > > > > > > > > > > point,
> > > > > > > > > > > > > and it
> > > > > > > > > > > > > can
> > > > > > > > > > > > > be
> > > > > > > > > > > > > used equally well for config true and false mount
> > > > > > > > > > > > > points.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So my proposal is to move from YANG library as state
> > > > > > > > > > > > > data
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation.
> > > > > > > > > > > > > It
> > > > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > > > structure,
> > > > > > > > > > > > > so
> > > > > > > > > > > > > there
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Lada
> > > > > > > > > > > > > 
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > 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
> > > > > > > > > > 
> > > 
> > > 
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 04:19:57 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 2D7141314A4 for ; Tue, 16 Jan 2018 04:19:53 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 a4OW3PpZYAvY for ; Tue, 16 Jan 2018 04:19:49 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 900AD126D73 for ; Tue, 16 Jan 2018 04:19:11 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 437801AE0399; Tue, 16 Jan 2018 13:19:10 +0100 (CET)
Date: Tue, 16 Jan 2018 13:19:09 +0100 (CET)
Message-Id: <20180116.131909.1138141751153857700.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1516086847.3188.24.camel@nic.cz>
References: <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:19:56 -0000

Ladislav Lhotka  wrote:
> Hi Lou,
> 
> in my view, we should do the following two (significant) changes:
> 
> 1. Instead of borrowing a grouping from ietf-yang-library and having
> a parallel list of mounted schemas, we should keep *all* mounted
> schemas directly in the YANG library and refer to them from
> schema-mounts structures. Juergen suggested this change and it is
> IMO the right thing to do.

I agree.

> 2. Define a metadata annotation (e.g. @schema-ref) that would be required for
> inline mount point instances and specify the inline-mounted schema also by
> referring to a schema specified in YANG library.
> 
> The advantage of #2 is that an annotation can be attached equally
> well to both state an configuration data. So, instead of papering
> over the issue that YANG library (state data) cannot appear in
> configuration datastores, we can use this general and
> straightforward approach. This also allows for defining different
> mounted schemas for instances of the same mount point in different
> datastores.

This is a clever idea!  I assume this would be used instead of
requiring the mounting of ietf-yang-library and ietf-schema-mount?

For "peer mount", it might be the case that this doesn't work as well
as the current solution for inline, but I think it is ok.

> I strongly believe that these changes (along with the new YANG library schema
> and NMDA) make for a simple and elegant datastore architecture in which schema
> mount would be an optional feature.


/martin


> 
> Lada 
> 
>  
> 
> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> > Lada/Martin,
> > 
> > I don't believe we reached closure on this discussion.  The open issues 
> > relate to proposed new text (slightly modified):
> > 
> > at the end of the section [3.2] adding a new paragraph along the
> > lines of:
> > 
> >    The use of mount points does not impact the nature of the
> >    mounted data or in which data store information is made
> >    available. For example, mounted YANG Library modules define
> >    only operational state data and, as such, the information in
> >    these modules is available from operational data stores using
> >    the appropriate protocol operations.  It is also worth
> >    noting that the Schema Mount module itself parallels the
> >    YANG Library module and only defines operational state data.
> > 
> > Is this change acceptable?
> > 
> > What other issues related to SM are outstanding?
> > 
> > Thank you,
> > 
> > Lou
> > 
> > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > > Hi Lada,
> > > > > > 
> > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > > Lada,
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka 
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > > lada,
> > > > > > > > > > 
> > > > > > > > > >      See below.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > unfortunately, using an action for querying embedded YANG
> > > > > > > > > > > library
> > > > > > > > > > > data
> > > > > > > > > > > (needed for the "inline" case of schema mount) doesn't work
> > > > > > > > > > > either
> > > > > > > > > > > because now under NMDA actions can be used only on instances
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > >  datastore.
> > > > > > > > > > 
> > > > > > > > > > but the inline/embedded library would (only) be present in the
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > > 
> > > > > > > > > Well, the issue is described in my initial mail of this thread:
> > > > > > > > > the
> > > > > > > > > current
> > > > > > > > > text
> > > > > > > > > requires that every instance of an inline mount point contains
> > > > > > > > > the
> > > > > > > > > embedded
> > > > > > > > > YANG library. Tha latter is state data, so the above requirement
> > > > > > > > > cannot
> > > > > > > > > be
> > > > > > > > > satisfied if the mount point instance is in a configuration
> > > > > > > > > datastore.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > That's not how I read the intent of the current text.  I don't see
> > > > > > > > SM
> > > > > > > > impacting which data stores information is presented.  Just like
> > > > > > > > use
> > > > > > > > of
> > > > > > > > scheme mount doesn't transform RO configuration information into
> > > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > > clarifying
> > > > > > > > this
> > > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > > 
> > > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > > 
> > > > > > Agreed - that's why I asked to start this thread!
> > > > > > 
> > > > > > Here's the original proposal:
> > > > > > 
> > > > > >    How about at the end of the section [3.2] adding a new
> > > > > >    paragraph along the lines of:
> > > > > > 
> > > > > >    It is important to note that both YANG Library and Schema
> > > > > >    Mount Modules contain only operational state data. As such,
> > > > > 
> > > > > s/contain/define/
> > > > > 
> > > > > >    the information in these modules should be retrieved by
> > > > > >    clients from operational data stores using the appropriate
> > > > > 
> > > > > This is based on two assumptions:
> > > > > 
> > > > > 1. For every configuration datastore there is a corresponding
> > > > > operational
> > > > > datastore.
> > > > 
> > > > well the text is revised below.  In any case, "these modules" refers to
> > > > yang library, and yes, I'm assuming YL is always and only in
> > > > operational.  If the revised text below isn't clear s/these/YANG Library/
> > > > -
> > > 
> > > The thing is that we have the top-level YANG library in , and
> > > then
> > > embedded YANG libraries scattered inside inline mount point instances.
> > > 
> > > > > 2. For every mount point instance in any configuration datastore there
> > > > > is a
> > > > > corresponding mount point instance (with the same path) in an
> > > > > operational
> > > > > datastore.
> > > > > 
> > > > > I think that neither of these has to be true in general.
> > > > 
> > > > agreed in general, but for inline, where YL is required, it must be true.
> > > 
> > > How do you know? I provided an example in Singapore where a mount point
> > > instance
> > > in  is a part of pre-provisioned data (for non-existent hardware).
> > > Then, according to the NMDA rules there is no corresponding instance in
> > > , hence no place where the embedded YANG library can be placed.
> > > (I can easily provide a concrete example if needed).
> > > 
> > > 
> > > Dean replied that this cannot happen, so it seems there are some assumptions
> > > how
> > > the inline method of schema mount may be applied. If so, these assumptions
> > > have
> > > to be explicitly stated.
> > > 
> > > > > >    protocol operations.
> > > > > 
> > > > > In contrast, the substance of my proposal with metadata annotations is
> > > > > to be
> > > > > able to retrieve all schemas from a well-known location in *the*
> > > > > 
> > > > > datastore, namely from the top-level YANG library.
> > > > 
> > > > What about a schema that is based on dll that contains modules that
> > > > isn't loaded until a mount point is instantiated -- this is certainly a
> > > > valid approach for supporting LNEs, but would be precluded in this
> > > > approach.  I really don't think a top level approach works for all
> > > > inline (managed) types of mounts.
> > > 
> > > It isn't precluded: when the mount point is instantiated (no matter which
> > > datastore it is in), the server adds the schema as a new entry to the
> > > "schema"
> > > list in the top level YANG library (with a unique key), and annotates the
> > > mount
> > > point instance with a leafref pointing to that key. So different instances
> > > of
> > > the same mount point can have different schemas.
> > > 
> > > > > > Given this discussion, we can generalize it further to:
> > > > > > 
> > > > > >    The use of mount points does not impact the nature of the
> > > > > >    mounted data or in which data store information is made
> > > > > >    available. For example, mounted YANG Library modules contain
> > > > > >    only operational state data and, as such, the information in
> > > > > >    these modules is available from operational data stores using
> > > > > >    the appropriate protocol operations.
> > > > > 
> > > > > The whole question here is whether and how we can locate the schema for
> > > > > an
> > > > > inline mount point in any configuration datastore.
> > > > 
> > > > Why is a mounted YL different than a top level YL?  What works for and
> > > 
> > > It is not different, but it can be only in an operational datastores, and so
> > > for
> > > mount point instances inside configuration datastores we need a way how to
> > > locate the schema for that mount point, because it cannot be found directly
> > > under the mount point instance (as the current text assumes).
> > > 
> > > > is sufficient for the normal case of YL shouldn't be impacted or
> > > > modified by SM -- at least that's how I thought we've been talking about
> > > > since SM was started.  Again, we never made any special provisions for
> > > > any other rw/ro/state data, assuming top level YL is not handled as
> > > > metadata, why start now?
> > > > 
> > > > I'm getting the impression that your argument may be more about if YL
> > > > should be treated as something other than operational data, is this wrong?
> > > 
> > > This is wrong. My argument is that there should be only one top-level YANG
> > > library (state data) and each inline mount point instance just points to a
> > > schema inside it by means of a metadata annotation attached to the mount
> > > point
> > > (in any datastore).
> > > 
> > > Lada
> > > 
> > > > Thanks,
> > > > Lou
> > > > 
> > > > > Lada
> > > > > 
> > > > > > Lou
> > > > > > 
> > > > > > > Lada
> > > > > > > 
> > > > > > > > Lou
> > > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > > annotation
> > > > > > > > > > > along
> > > > > > > > > > > the
> > > > > > > > > > > lines of RFC 7952, for example with the alternative B of the
> > > > > > > > > > > newly
> > > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > > 
> > > > > > > > > > >       md:annotation schema-ref {
> > > > > > > > > > >         type leafref {
> > > > > > > > > > >           path "/yanglib:yang-
> > > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > > >         }
> > > > > > > > > > >       }
> > > > > > > > > > > 
> > > > > > > > > > > In other words, all inline mounted schemas would be included
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > top-level YANG library, and mount point instances in all
> > > > > > > > > > > datastores
> > > > > > > > > > > would be annotated with leafref pointing to the actual
> > > > > > > > > > > schema.
> > > > > > > > > > > 
> > > > > > > > > > > Unlike regular state data, it is IMO no problem to permit
> > > > > > > > > > > such
> > > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > > 
> > > > > > > > > > > Opinions?
> > > > > > > > > > 
> > > > > > > > > > I'm not sure this will work for all architectures of LNEs as
> > > > > > > > > > well
> > > > > > > > > > as
> > > > > > > > > > other possible future use cases.  In short, this seems *very*
> > > > > > > > > > restrictive.
> > > > > > > > > 
> > > > > > > > > I don't understand, IMO it is not restrictive at all. What kind
> > > > > > > > > of
> > > > > > > > > restrictions
> > > > > > > > > do you see?
> > > > > > > > > 
> > > > > > > > > Lada
> > > > > > > > > 
> > > > > > > > > > Lou
> > > > > > > > > > 
> > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > 
> > > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > > 
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is wrong
> > > > > > > > > > > > for
> > > > > > > > > > > > traditional
> > > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > > 
> > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is determined
> > > > > > > > > > > > at
> > > > > > > > > > > > run
> > > > > > > > > > > > time:
> > > > > > > > > > > > every
> > > > > > > > > > > >     instance of the mount point that exists in the parent
> > > > > > > > > > > > tree
> > > > > > > > > > > > MUST
> > > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
> > > > > > > > > > > > defines
> > > > > > > > > > > > the
> > > > > > > > > > > >     mounted schema exactly as for a top-level data
> > > > > > > > > > > > model.  A
> > > > > > > > > > > > client
> > > > > > > > > > > > is
> > > > > > > > > > > >     expected to retrieve this data from the instance tree,
> > > > > > > > > > > > possibly
> > > > > > > > > > > > after
> > > > > > > > > > > >     creating the mount point.  Instances of the same mount
> > > > > > > > > > > > point
> > > > > > > > > > > > MAY
> > > > > > > > > > > > use
> > > > > > > > > > > >     different mounted schemas.
> > > > > > > > > > > > 
> > > > > > > > > > > > An instance of the mount point in any *configuration*
> > > > > > > > > > > > datastores
> > > > > > > > > > > > cannot
> > > > > > > > > > > > contain
> > > > > > > > > > > > YANG library (being state data), and so the MUST cannot
> > > > > > > > > > > > hold.
> > > > > > > > > > > > 
> > > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > > considerable
> > > > > > > > > > > > complications
> > > > > > > > > > > > and/or a lot of handwaving. There is actually one good
> > > > > > > > > > > > solution
> > > > > > > > > > > > but it
> > > > > > > > > > > > has
> > > > > > > > > > > > impact on YANG library: the server could provide it in a
> > > > > > > > > > > > reply
> > > > > > > > > > > > to
> > > > > > > > > > > > an
> > > > > > > > > > > > operation,
> > > > > > > > > > > > say "get-yang-library" rather than as state data. Then
> > > > > > > > > > > > everything
> > > > > > > > > > > > would be
> > > > > > > > > > > > fine
> > > > > > > > > > > > - this operation would turn into an action for the mount
> > > > > > > > > > > > point,
> > > > > > > > > > > > and it
> > > > > > > > > > > > can
> > > > > > > > > > > > be
> > > > > > > > > > > > used equally well for config true and false mount points.
> > > > > > > > > > > > 
> > > > > > > > > > > > So my proposal is to move from YANG library as state data
> > > > > > > > > > > > to
> > > > > > > > > > > > an
> > > > > > > > > > > > operation.
> > > > > > > > > > > > It
> > > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > > structure,
> > > > > > > > > > > > so
> > > > > > > > > > > > there
> > > > > > > > > > > > will be
> > > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > > 
> > > > > > > > > > > > Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > --
> > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > 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
> > > > > > > > > 
> > 
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Tue Jan 16 04:25: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 4B79B12DA69 for ; Tue, 16 Jan 2018 04:25:22 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8ujdSbJ9aNZa for ; Tue, 16 Jan 2018 04:25:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6912711D for ; Tue, 16 Jan 2018 04:25:19 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BBCD1AE0399; Tue, 16 Jan 2018 13:25:18 +0100 (CET)
Date: Tue, 16 Jan 2018 13:25:18 +0100 (CET)
Message-Id: <20180116.132518.1169908668198730099.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1516104404.11372.15.camel@nic.cz>
References: <1516086847.3188.24.camel@nic.cz> <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516104404.11372.15.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:25:22 -0000

Ladislav Lhotka  wrote:
> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> > Lada,
> > 
> > It sounds like you are proposing in (1) a fairly significant change in the 
> > direction of the draft and in (2) a basic approach that has been
> 
> It is no change in direction, just a simplification of the schema-describing
> state data. Given the recent developments in 7895bis it makes no
> sense to me to
> have two "schema" lists if we can have just one.

I agree.  I have always thought that we would align schema mount to
7895bis.  Using an old version of yang library does not seem very
future proof.


/martin


> > rejectected by the WG multiple times.  FWIW there are drafts already with
> 
> No at all. The first and last time I proposed this was on 15 December 2017:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> 
> The only reply was from you. To me, it is the cleanest solution of the inline
> case. Of course, I am open to technical objections.
> 
> If it's not clear what I mean, I can make up some examples.
> 
> Lada
> 
> 
> > the iesg that will need to be returned to their WGs if either change is made.
> > 
> > Martin,
> > 
> > Do share Lada's view?
> > 
> > Lou
> > 
> > 
> > On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:
> > 
> > > Hi Lou,
> > > 
> > > in my view, we should do the following two (significant) changes:
> > > 
> > > 1. Instead of borrowing a grouping from ietf-yang-library and having a
> > > parallel
> > > list of mounted schemas, we should keep *all* mounted schemas directly in
> > > the
> > > YANG library and refer to them from schema-mounts structures. Juergen
> > > suggested
> > > this change and it is IMO the right thing to do.
> > > 
> > > 2. Define a metadata annotation (e.g. @schema-ref) that would be required
> > > for
> > > inline mount point instances and specify the inline-mounted schema also by
> > > referring to a schema specified in YANG library.
> > > 
> > > The advantage of #2 is that an annotation can be attached equally well to
> > > both
> > > state an configuration data. So, instead of papering over the issue that
> > > YANG
> > > library (state data) cannot appear in configuration datastores, we can use
> > > this
> > > general and straightforward approach. This also allows for defining
> > > different
> > > mounted schemas for instances of the same mount point in different
> > > datastores.
> > > 
> > > I strongly believe that these changes (along with the new YANG library
> > > schema
> > > and NMDA) make for a simple and elegant datastore architecture in which
> > > schema
> > > mount would be an optional feature.
> > > 
> > > Lada
> > > 
> > > 
> > > 
> > > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> > > > Lada/Martin,
> > > > 
> > > > I don't believe we reached closure on this discussion.  The open issues
> > > > relate to proposed new text (slightly modified):
> > > > 
> > > > at the end of the section [3.2] adding a new paragraph along the
> > > > lines of:
> > > > 
> > > >    The use of mount points does not impact the nature of the
> > > >    mounted data or in which data store information is made
> > > >    available. For example, mounted YANG Library modules define
> > > >    only operational state data and, as such, the information in
> > > >    these modules is available from operational data stores using
> > > >    the appropriate protocol operations.  It is also worth
> > > >    noting that the Schema Mount module itself parallels the
> > > >    YANG Library module and only defines operational state data.
> > > > 
> > > > Is this change acceptable?
> > > > 
> > > > What other issues related to SM are outstanding?
> > > > 
> > > > Thank you,
> > > > 
> > > > Lou
> > > > 
> > > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > > > > Hi Lada,
> > > > > > > > 
> > > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > > > > Lada,
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka  > > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > > > > lada,
> > > > > > > > > > > > 
> > > > > > > > > > > >      See below.
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > unfortunately, using an action for querying embedded
> > > > > > > > > > > > > YANG
> > > > > > > > > > > > > library
> > > > > > > > > > > > > data
> > > > > > > > > > > > > (needed for the "inline" case of schema mount) doesn't
> > > > > > > > > > > > > work
> > > > > > > > > > > > > either
> > > > > > > > > > > > > because now under NMDA actions can be used only on
> > > > > > > > > > > > > instances
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > >  datastore.
> > > > > > > > > > > > 
> > > > > > > > > > > > but the inline/embedded library would (only) be present in
> > > > > > > > > > > > the
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > > > > 
> > > > > > > > > > > Well, the issue is described in my initial mail of this
> > > > > > > > > > > thread:
> > > > > > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > text
> > > > > > > > > > > requires that every instance of an inline mount point
> > > > > > > > > > > contains
> > > > > > > > > > > the
> > > > > > > > > > > embedded
> > > > > > > > > > > YANG library. Tha latter is state data, so the above
> > > > > > > > > > > requirement
> > > > > > > > > > > cannot
> > > > > > > > > > > be
> > > > > > > > > > > satisfied if the mount point instance is in a configuration
> > > > > > > > > > > datastore.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > That's not how I read the intent of the current text.  I don't
> > > > > > > > > > see
> > > > > > > > > > SM
> > > > > > > > > > impacting which data stores information is presented.  Just
> > > > > > > > > > like
> > > > > > > > > > use
> > > > > > > > > > of
> > > > > > > > > > scheme mount doesn't transform RO configuration information
> > > > > > > > > > into
> > > > > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > > > > clarifying
> > > > > > > > > > this
> > > > > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > > > > 
> > > > > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > > > > 
> > > > > > > > Agreed - that's why I asked to start this thread!
> > > > > > > > 
> > > > > > > > Here's the original proposal:
> > > > > > > > 
> > > > > > > >    How about at the end of the section [3.2] adding a new
> > > > > > > >    paragraph along the lines of:
> > > > > > > > 
> > > > > > > >    It is important to note that both YANG Library and Schema
> > > > > > > >    Mount Modules contain only operational state data. As such,
> > > > > > > 
> > > > > > > s/contain/define/
> > > > > > > 
> > > > > > > >    the information in these modules should be retrieved by
> > > > > > > >    clients from operational data stores using the appropriate
> > > > > > > 
> > > > > > > This is based on two assumptions:
> > > > > > > 
> > > > > > > 1. For every configuration datastore there is a corresponding
> > > > > > > operational
> > > > > > > datastore.
> > > > > > 
> > > > > > well the text is revised below.  In any case, "these modules" refers
> > > > > > to
> > > > > > yang library, and yes, I'm assuming YL is always and only in
> > > > > > operational.  If the revised text below isn't clear s/these/YANG
> > > > > > Library/
> > > > > > -
> > > > > 
> > > > > The thing is that we have the top-level YANG library in ,
> > > > > and
> > > > > then
> > > > > embedded YANG libraries scattered inside inline mount point instances.
> > > > > 
> > > > > > > 2. For every mount point instance in any configuration datastore
> > > > > > > there
> > > > > > > is a
> > > > > > > corresponding mount point instance (with the same path) in an
> > > > > > > operational
> > > > > > > datastore.
> > > > > > > 
> > > > > > > I think that neither of these has to be true in general.
> > > > > > 
> > > > > > agreed in general, but for inline, where YL is required, it must be
> > > > > > true.
> > > > > 
> > > > > How do you know? I provided an example in Singapore where a mount point
> > > > > instance
> > > > > in  is a part of pre-provisioned data (for non-existent
> > > > > hardware).
> > > > > Then, according to the NMDA rules there is no corresponding instance in
> > > > > , hence no place where the embedded YANG library can be
> > > > > placed.
> > > > > (I can easily provide a concrete example if needed).
> > > > > 
> > > > > 
> > > > > Dean replied that this cannot happen, so it seems there are some
> > > > > assumptions
> > > > > how
> > > > > the inline method of schema mount may be applied. If so, these
> > > > > assumptions
> > > > > have
> > > > > to be explicitly stated.
> > > > > 
> > > > > > > >    protocol operations.
> > > > > > > 
> > > > > > > In contrast, the substance of my proposal with metadata annotations
> > > > > > > is
> > > > > > > to be
> > > > > > > able to retrieve all schemas from a well-known location in *the*
> > > > > > > 
> > > > > > > datastore, namely from the top-level YANG library.
> > > > > > 
> > > > > > What about a schema that is based on dll that contains modules that
> > > > > > isn't loaded until a mount point is instantiated -- this is certainly
> > > > > > a
> > > > > > valid approach for supporting LNEs, but would be precluded in this
> > > > > > approach.  I really don't think a top level approach works for all
> > > > > > inline (managed) types of mounts.
> > > > > 
> > > > > It isn't precluded: when the mount point is instantiated (no matter
> > > > > which
> > > > > datastore it is in), the server adds the schema as a new entry to the
> > > > > "schema"
> > > > > list in the top level YANG library (with a unique key), and annotates
> > > > > the
> > > > > mount
> > > > > point instance with a leafref pointing to that key. So different
> > > > > instances
> > > > > of
> > > > > the same mount point can have different schemas.
> > > > > 
> > > > > > > > Given this discussion, we can generalize it further to:
> > > > > > > > 
> > > > > > > >    The use of mount points does not impact the nature of the
> > > > > > > >    mounted data or in which data store information is made
> > > > > > > >    available. For example, mounted YANG Library modules contain
> > > > > > > >    only operational state data and, as such, the information in
> > > > > > > >    these modules is available from operational data stores using
> > > > > > > >    the appropriate protocol operations.
> > > > > > > 
> > > > > > > The whole question here is whether and how we can locate the schema
> > > > > > > for
> > > > > > > an
> > > > > > > inline mount point in any configuration datastore.
> > > > > > 
> > > > > > Why is a mounted YL different than a top level YL?  What works for and
> > > > > 
> > > > > It is not different, but it can be only in an operational datastores,
> > > > > and so
> > > > > for
> > > > > mount point instances inside configuration datastores we need a way how
> > > > > to
> > > > > locate the schema for that mount point, because it cannot be found
> > > > > directly
> > > > > under the mount point instance (as the current text assumes).
> > > > > 
> > > > > > is sufficient for the normal case of YL shouldn't be impacted or
> > > > > > modified by SM -- at least that's how I thought we've been talking
> > > > > > about
> > > > > > since SM was started.  Again, we never made any special provisions for
> > > > > > any other rw/ro/state data, assuming top level YL is not handled as
> > > > > > metadata, why start now?
> > > > > > 
> > > > > > I'm getting the impression that your argument may be more about if YL
> > > > > > should be treated as something other than operational data, is this
> > > > > > wrong?
> > > > > 
> > > > > This is wrong. My argument is that there should be only one top-level
> > > > > YANG
> > > > > library (state data) and each inline mount point instance just points to
> > > > > a
> > > > > schema inside it by means of a metadata annotation attached to the mount
> > > > > point
> > > > > (in any datastore).
> > > > > 
> > > > > Lada
> > > > > 
> > > > > > Thanks,
> > > > > > Lou
> > > > > > 
> > > > > > > Lada
> > > > > > > 
> > > > > > > > Lou
> > > > > > > > 
> > > > > > > > > Lada
> > > > > > > > > 
> > > > > > > > > > Lou
> > > > > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > > > > annotation
> > > > > > > > > > > > > along
> > > > > > > > > > > > > the
> > > > > > > > > > > > > lines of RFC 7952, for example with the alternative B of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > newly
> > > > > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > > > > 
> > > > > > > > > > > > >       md:annotation schema-ref {
> > > > > > > > > > > > >         type leafref {
> > > > > > > > > > > > >           path "/yanglib:yang-
> > > > > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > > > > >         }
> > > > > > > > > > > > >       }
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In other words, all inline mounted schemas would be
> > > > > > > > > > > > > included
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > top-level YANG library, and mount point instances in all
> > > > > > > > > > > > > datastores
> > > > > > > > > > > > > would be annotated with leafref pointing to the actual
> > > > > > > > > > > > > schema.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> > > > > > > > > > > > > permit
> > > > > > > > > > > > > such
> > > > > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Opinions?
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm not sure this will work for all architectures of LNEs
> > > > > > > > > > > > as
> > > > > > > > > > > > well
> > > > > > > > > > > > as
> > > > > > > > > > > > other possible future use cases.  In short, this seems
> > > > > > > > > > > > *very*
> > > > > > > > > > > > restrictive.
> > > > > > > > > > > 
> > > > > > > > > > > I don't understand, IMO it is not restrictive at all. What
> > > > > > > > > > > kind
> > > > > > > > > > > of
> > > > > > > > > > > restrictions
> > > > > > > > > > > do you see?
> > > > > > > > > > > 
> > > > > > > > > > > Lada
> > > > > > > > > > > 
> > > > > > > > > > > > Lou
> > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is
> > > > > > > > > > > > > > wrong
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > traditional
> > > > > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
> > > > > > > > > > > > > > determined
> > > > > > > > > > > > > > at
> > > > > > > > > > > > > > run
> > > > > > > > > > > > > > time:
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > >     instance of the mount point that exists in the
> > > > > > > > > > > > > > parent
> > > > > > > > > > > > > > tree
> > > > > > > > > > > > > > MUST
> > > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
> > > > > > > > > > > > > > defines
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > >     mounted schema exactly as for a top-level data
> > > > > > > > > > > > > > model.  A
> > > > > > > > > > > > > > client
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > >     expected to retrieve this data from the instance
> > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > possibly
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > >     creating the mount point.  Instances of the same
> > > > > > > > > > > > > > mount
> > > > > > > > > > > > > > point
> > > > > > > > > > > > > > MAY
> > > > > > > > > > > > > > use
> > > > > > > > > > > > > >     different mounted schemas.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > An instance of the mount point in any *configuration*
> > > > > > > > > > > > > > datastores
> > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > contain
> > > > > > > > > > > > > > YANG library (being state data), and so the MUST
> > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > hold.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > > > > considerable
> > > > > > > > > > > > > > complications
> > > > > > > > > > > > > > and/or a lot of handwaving. There is actually one good
> > > > > > > > > > > > > > solution
> > > > > > > > > > > > > > but it
> > > > > > > > > > > > > > has
> > > > > > > > > > > > > > impact on YANG library: the server could provide it in
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > reply
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > an
> > > > > > > > > > > > > > operation,
> > > > > > > > > > > > > > say "get-yang-library" rather than as state data. Then
> > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > would be
> > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > - this operation would turn into an action for the
> > > > > > > > > > > > > > mount
> > > > > > > > > > > > > > point,
> > > > > > > > > > > > > > and it
> > > > > > > > > > > > > > can
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > used equally well for config true and false mount
> > > > > > > > > > > > > > points.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So my proposal is to move from YANG library as state
> > > > > > > > > > > > > > data
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > an
> > > > > > > > > > > > > > operation.
> > > > > > > > > > > > > > It
> > > > > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > > > > structure,
> > > > > > > > > > > > > > so
> > > > > > > > > > > > > > there
> > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Lada
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > 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
> > > > > > > > > > > 
> > > > 
> > > > 
> > > 
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > 
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Tue Jan 16 04:26:48 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 2468C1314AC for ; Tue, 16 Jan 2018 04:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 lCTmnFz5Q4oK for ; Tue, 16 Jan 2018 04:26:44 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 B121B1314A9 for ; Tue, 16 Jan 2018 04:26:38 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id A26731E0638 for ; Tue, 16 Jan 2018 05:26:32 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id z0SU1w00n2SSUrH010SX27; Tue, 16 Jan 2018 05:26:32 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=_uGserV50VcALC-ziA0A:9 a=CjuIK1q_8ugA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=w1C3t2QeGrPiZgrLijVG:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5/FqdPKeltHI90WpLe/G+bO/ey1vJf0kTBMg36ZmKxw=; b=XReRgC0ZPKf7QV+Oo23IKqdA5t ufQgDG5ODQhEvkYrVZJlJXfNXLMGLGvqmW/r2x4am4sjvByuIarDlcVQHJhBYW7dncq85ywzuUepE NR04KCsD6PEeC66BERRNfRXv5;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44651 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebQJw-0033vc-IN; Tue, 16 Jan 2018 05:26:28 -0700
From: Lou Berger 
To: Ladislav Lhotka , Martin Bjorklund 
CC: NETMOD WG 
Date: Tue, 16 Jan 2018 07:26:26 -0500
Message-ID: <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <1516104404.11372.15.camel@nic.cz>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz> <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516104404.11372.15.camel@nic.cz>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
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-Exim-ID: 1ebQJw-0033vc-IN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:44651
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:26:46 -0000

Lada,


On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:

> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
>> Lada,
>>
>> It sounds like you are proposing in (1) a fairly significant change in the
>> direction of the draft and in (2) a basic approach that has been
>
> It is no change in direction, just a simplification of the schema-describing
> state data. Given the recent developments in 7895bis it makes no sense to me to
> have two "schema" lists if we can have just one.
>

Managing transition is hard. It's also highlights why Yang Library this 
needs to be at least equally discussed in this group.

I will talk with my co-chairs and perhaps the ADs to get their opinion on 
making such a change this point in the process.


>>
>> rejectected by the WG multiple times.  FWIW there are drafts already with
>
> No at all. The first and last time I proposed this was on 15 December 2017:
>
> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>

Oh, I certainly would call you proposing that the schema for inline be part 
of the rest of the schema Mount module well before that. I'm sure I can dig 
up mail / slides it really necessary...


> The only reply was from you. To me, it is the cleanest solution of the inline
> case. Of course, I am open to technical objections.
>

I'm sure I can find material on this as well....

Lou

> If it's not clear what I mean, I can make up some examples.
>
> Lada
>
>
>> the iesg that will need to be returned to their WGs if either change is made.
>>
>> Martin,
>>
>> Do share Lada's view?
>>
>> Lou
>>
>>
>> On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:
>>
>> > Hi Lou,
>> >
>> > in my view, we should do the following two (significant) changes:
>> >
>> > 1. Instead of borrowing a grouping from ietf-yang-library and having a
>> > parallel
>> > list of mounted schemas, we should keep *all* mounted schemas directly in
>> > the
>> > YANG library and refer to them from schema-mounts structures. Juergen
>> > suggested
>> > this change and it is IMO the right thing to do.
>> >
>> > 2. Define a metadata annotation (e.g. @schema-ref) that would be required
>> > for
>> > inline mount point instances and specify the inline-mounted schema also by
>> > referring to a schema specified in YANG library.
>> >
>> > The advantage of #2 is that an annotation can be attached equally well to
>> > both
>> > state an configuration data. So, instead of papering over the issue that
>> > YANG
>> > library (state data) cannot appear in configuration datastores, we can use
>> > this
>> > general and straightforward approach. This also allows for defining
>> > different
>> > mounted schemas for instances of the same mount point in different
>> > datastores.
>> >
>> > I strongly believe that these changes (along with the new YANG library
>> > schema
>> > and NMDA) make for a simple and elegant datastore architecture in which
>> > schema
>> > mount would be an optional feature.
>> >
>> > Lada
>> >
>> >
>> >
>> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> > > Lada/Martin,
>> > >
>> > > I don't believe we reached closure on this discussion.  The open issues
>> > > relate to proposed new text (slightly modified):
>> > >
>> > > at the end of the section [3.2] adding a new paragraph along the
>> > > lines of:
>> > >
>> > >    The use of mount points does not impact the nature of the
>> > >    mounted data or in which data store information is made
>> > >    available. For example, mounted YANG Library modules define
>> > >    only operational state data and, as such, the information in
>> > >    these modules is available from operational data stores using
>> > >    the appropriate protocol operations.  It is also worth
>> > >    noting that the Schema Mount module itself parallels the
>> > >    YANG Library module and only defines operational state data.
>> > >
>> > > Is this change acceptable?
>> > >
>> > > What other issues related to SM are outstanding?
>> > >
>> > > Thank you,
>> > >
>> > > Lou
>> > >
>> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>> > > > > > > Hi Lada,
>> > > > > > >
>> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>> > > > > > > > > Lada,
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka > > > > > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>> > > > > > > > > > > lada,
>> > > > > > > > > > >
>> > > > > > > > > > >      See below.
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>> > > > > > > > > > > > Hi,
>> > > > > > > > > > > >
>> > > > > > > > > > > > unfortunately, using an action for querying embedded
>> > > > > > > > > > > > YANG
>> > > > > > > > > > > > library
>> > > > > > > > > > > > data
>> > > > > > > > > > > > (needed for the "inline" case of schema mount) doesn't
>> > > > > > > > > > > > work
>> > > > > > > > > > > > either
>> > > > > > > > > > > > because now under NMDA actions can be used only on
>> > > > > > > > > > > > instances
>> > > > > > > > > > > > in
>> > > > > > > > > > > > the
>> > > > > > > > > > > >  datastore.
>> > > > > > > > > > >
>> > > > > > > > > > > but the inline/embedded library would (only) be present in
>> > > > > > > > > > > the
>> > > > > > > > > > > in
>> > > > > > > > > > > the
>> > > > > > > > > > > operational datastore, so what's the issue?
>> > > > > > > > > >
>> > > > > > > > > > Well, the issue is described in my initial mail of this
>> > > > > > > > > > thread:
>> > > > > > > > > > the
>> > > > > > > > > > current
>> > > > > > > > > > text
>> > > > > > > > > > requires that every instance of an inline mount point
>> > > > > > > > > > contains
>> > > > > > > > > > the
>> > > > > > > > > > embedded
>> > > > > > > > > > YANG library. Tha latter is state data, so the above
>> > > > > > > > > > requirement
>> > > > > > > > > > cannot
>> > > > > > > > > > be
>> > > > > > > > > > satisfied if the mount point instance is in a configuration
>> > > > > > > > > > datastore.
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > That's not how I read the intent of the current text.  I don't
>> > > > > > > > > see
>> > > > > > > > > SM
>> > > > > > > > > impacting which data stores information is presented.  Just
>> > > > > > > > > like
>> > > > > > > > > use
>> > > > > > > > > of
>> > > > > > > > > scheme mount doesn't transform RO configuration information
>> > > > > > > > > into
>> > > > > > > > > operational information.  I sent you a couple of sentences
>> > > > > > > > > clarifying
>> > > > > > > > > this
>> > > > > > > > > at one point, I'll dig up the proposed text and resend.
>> > > > > > > >
>> > > > > > > > Please do, this has to be discussed in the WG mailing list.
>> > > > > > >
>> > > > > > > Agreed - that's why I asked to start this thread!
>> > > > > > >
>> > > > > > > Here's the original proposal:
>> > > > > > >
>> > > > > > >    How about at the end of the section [3.2] adding a new
>> > > > > > >    paragraph along the lines of:
>> > > > > > >
>> > > > > > >    It is important to note that both YANG Library and Schema
>> > > > > > >    Mount Modules contain only operational state data. As such,
>> > > > > >
>> > > > > > s/contain/define/
>> > > > > >
>> > > > > > >    the information in these modules should be retrieved by
>> > > > > > >    clients from operational data stores using the appropriate
>> > > > > >
>> > > > > > This is based on two assumptions:
>> > > > > >
>> > > > > > 1. For every configuration datastore there is a corresponding
>> > > > > > operational
>> > > > > > datastore.
>> > > > >
>> > > > > well the text is revised below.  In any case, "these modules" refers
>> > > > > to
>> > > > > yang library, and yes, I'm assuming YL is always and only in
>> > > > > operational.  If the revised text below isn't clear s/these/YANG
>> > > > > Library/
>> > > > > -
>> > > >
>> > > > The thing is that we have the top-level YANG library in ,
>> > > > and
>> > > > then
>> > > > embedded YANG libraries scattered inside inline mount point instances.
>> > > >
>> > > > > > 2. For every mount point instance in any configuration datastore
>> > > > > > there
>> > > > > > is a
>> > > > > > corresponding mount point instance (with the same path) in an
>> > > > > > operational
>> > > > > > datastore.
>> > > > > >
>> > > > > > I think that neither of these has to be true in general.
>> > > > >
>> > > > > agreed in general, but for inline, where YL is required, it must be
>> > > > > true.
>> > > >
>> > > > How do you know? I provided an example in Singapore where a mount point
>> > > > instance
>> > > > in  is a part of pre-provisioned data (for non-existent
>> > > > hardware).
>> > > > Then, according to the NMDA rules there is no corresponding instance in
>> > > > , hence no place where the embedded YANG library can be
>> > > > placed.
>> > > > (I can easily provide a concrete example if needed).
>> > > >
>> > > >
>> > > > Dean replied that this cannot happen, so it seems there are some
>> > > > assumptions
>> > > > how
>> > > > the inline method of schema mount may be applied. If so, these
>> > > > assumptions
>> > > > have
>> > > > to be explicitly stated.
>> > > >
>> > > > > > >    protocol operations.
>> > > > > >
>> > > > > > In contrast, the substance of my proposal with metadata annotations
>> > > > > > is
>> > > > > > to be
>> > > > > > able to retrieve all schemas from a well-known location in *the*
>> > > > > > 
>> > > > > > datastore, namely from the top-level YANG library.
>> > > > >
>> > > > > What about a schema that is based on dll that contains modules that
>> > > > > isn't loaded until a mount point is instantiated -- this is certainly
>> > > > > a
>> > > > > valid approach for supporting LNEs, but would be precluded in this
>> > > > > approach.  I really don't think a top level approach works for all
>> > > > > inline (managed) types of mounts.
>> > > >
>> > > > It isn't precluded: when the mount point is instantiated (no matter
>> > > > which
>> > > > datastore it is in), the server adds the schema as a new entry to the
>> > > > "schema"
>> > > > list in the top level YANG library (with a unique key), and annotates
>> > > > the
>> > > > mount
>> > > > point instance with a leafref pointing to that key. So different
>> > > > instances
>> > > > of
>> > > > the same mount point can have different schemas.
>> > > >
>> > > > > > > Given this discussion, we can generalize it further to:
>> > > > > > >
>> > > > > > >    The use of mount points does not impact the nature of the
>> > > > > > >    mounted data or in which data store information is made
>> > > > > > >    available. For example, mounted YANG Library modules contain
>> > > > > > >    only operational state data and, as such, the information in
>> > > > > > >    these modules is available from operational data stores using
>> > > > > > >    the appropriate protocol operations.
>> > > > > >
>> > > > > > The whole question here is whether and how we can locate the schema
>> > > > > > for
>> > > > > > an
>> > > > > > inline mount point in any configuration datastore.
>> > > > >
>> > > > > Why is a mounted YL different than a top level YL?  What works for and
>> > > >
>> > > > It is not different, but it can be only in an operational datastores,
>> > > > and so
>> > > > for
>> > > > mount point instances inside configuration datastores we need a way how
>> > > > to
>> > > > locate the schema for that mount point, because it cannot be found
>> > > > directly
>> > > > under the mount point instance (as the current text assumes).
>> > > >
>> > > > > is sufficient for the normal case of YL shouldn't be impacted or
>> > > > > modified by SM -- at least that's how I thought we've been talking
>> > > > > about
>> > > > > since SM was started.  Again, we never made any special provisions for
>> > > > > any other rw/ro/state data, assuming top level YL is not handled as
>> > > > > metadata, why start now?
>> > > > >
>> > > > > I'm getting the impression that your argument may be more about if YL
>> > > > > should be treated as something other than operational data, is this
>> > > > > wrong?
>> > > >
>> > > > This is wrong. My argument is that there should be only one top-level
>> > > > YANG
>> > > > library (state data) and each inline mount point instance just points to
>> > > > a
>> > > > schema inside it by means of a metadata annotation attached to the mount
>> > > > point
>> > > > (in any datastore).
>> > > >
>> > > > Lada
>> > > >
>> > > > > Thanks,
>> > > > > Lou
>> > > > >
>> > > > > > Lada
>> > > > > >
>> > > > > > > Lou
>> > > > > > >
>> > > > > > > > Lada
>> > > > > > > >
>> > > > > > > > > Lou
>> > > > > > > > > > > > However, a good alternative seems to be a metadata
>> > > > > > > > > > > > annotation
>> > > > > > > > > > > > along
>> > > > > > > > > > > > the
>> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B of
>> > > > > > > > > > > > the
>> > > > > > > > > > > > newly
>> > > > > > > > > > > > proposed YANG library schema:
>> > > > > > > > > > > >
>> > > > > > > > > > > >       md:annotation schema-ref {
>> > > > > > > > > > > >         type leafref {
>> > > > > > > > > > > >           path "/yanglib:yang-
>> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
>> > > > > > > > > > > >         }
>> > > > > > > > > > > >       }
>> > > > > > > > > > > >
>> > > > > > > > > > > > In other words, all inline mounted schemas would be
>> > > > > > > > > > > > included
>> > > > > > > > > > > > in
>> > > > > > > > > > > > the
>> > > > > > > > > > > > top-level YANG library, and mount point instances in all
>> > > > > > > > > > > > datastores
>> > > > > > > > > > > > would be annotated with leafref pointing to the actual
>> > > > > > > > > > > > schema.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
>> > > > > > > > > > > > permit
>> > > > > > > > > > > > such
>> > > > > > > > > > > > annotations in configuration datastores.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Opinions?
>> > > > > > > > > > >
>> > > > > > > > > > > I'm not sure this will work for all architectures of LNEs
>> > > > > > > > > > > as
>> > > > > > > > > > > well
>> > > > > > > > > > > as
>> > > > > > > > > > > other possible future use cases.  In short, this seems
>> > > > > > > > > > > *very*
>> > > > > > > > > > > restrictive.
>> > > > > > > > > >
>> > > > > > > > > > I don't understand, IMO it is not restrictive at all. What
>> > > > > > > > > > kind
>> > > > > > > > > > of
>> > > > > > > > > > restrictions
>> > > > > > > > > > do you see?
>> > > > > > > > > >
>> > > > > > > > > > Lada
>> > > > > > > > > >
>> > > > > > > > > > > Lou
>> > > > > > > > > > >
>> > > > > > > > > > > > Thanks, Lada
>> > > > > > > > > > > >
>> > > > > > > > > > > > Ladislav Lhotka  writes:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > Hi,
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is
>> > > > > > > > > > > > > wrong
>> > > > > > > > > > > > > for
>> > > > > > > > > > > > > traditional
>> > > > > > > > > > > > > datastores, and even more so for NDMA:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
>> > > > > > > > > > > > > determined
>> > > > > > > > > > > > > at
>> > > > > > > > > > > > > run
>> > > > > > > > > > > > > time:
>> > > > > > > > > > > > > every
>> > > > > > > > > > > > >     instance of the mount point that exists in the
>> > > > > > > > > > > > > parent
>> > > > > > > > > > > > > tree
>> > > > > > > > > > > > > MUST
>> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
>> > > > > > > > > > > > > defines
>> > > > > > > > > > > > > the
>> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
>> > > > > > > > > > > > > model.  A
>> > > > > > > > > > > > > client
>> > > > > > > > > > > > > is
>> > > > > > > > > > > > >     expected to retrieve this data from the instance
>> > > > > > > > > > > > > tree,
>> > > > > > > > > > > > > possibly
>> > > > > > > > > > > > > after
>> > > > > > > > > > > > >     creating the mount point.  Instances of the same
>> > > > > > > > > > > > > mount
>> > > > > > > > > > > > > point
>> > > > > > > > > > > > > MAY
>> > > > > > > > > > > > > use
>> > > > > > > > > > > > >     different mounted schemas.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > An instance of the mount point in any *configuration*
>> > > > > > > > > > > > > datastores
>> > > > > > > > > > > > > cannot
>> > > > > > > > > > > > > contain
>> > > > > > > > > > > > > YANG library (being state data), and so the MUST
>> > > > > > > > > > > > > cannot
>> > > > > > > > > > > > > hold.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > It is not clear to me how to repair this without
>> > > > > > > > > > > > > considerable
>> > > > > > > > > > > > > complications
>> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one good
>> > > > > > > > > > > > > solution
>> > > > > > > > > > > > > but it
>> > > > > > > > > > > > > has
>> > > > > > > > > > > > > impact on YANG library: the server could provide it in
>> > > > > > > > > > > > > a
>> > > > > > > > > > > > > reply
>> > > > > > > > > > > > > to
>> > > > > > > > > > > > > an
>> > > > > > > > > > > > > operation,
>> > > > > > > > > > > > > say "get-yang-library" rather than as state data. Then
>> > > > > > > > > > > > > everything
>> > > > > > > > > > > > > would be
>> > > > > > > > > > > > > fine
>> > > > > > > > > > > > > - this operation would turn into an action for the
>> > > > > > > > > > > > > mount
>> > > > > > > > > > > > > point,
>> > > > > > > > > > > > > and it
>> > > > > > > > > > > > > can
>> > > > > > > > > > > > > be
>> > > > > > > > > > > > > used equally well for config true and false mount
>> > > > > > > > > > > > > points.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > So my proposal is to move from YANG library as state
>> > > > > > > > > > > > > data
>> > > > > > > > > > > > > to
>> > > > > > > > > > > > > an
>> > > > > > > > > > > > > operation.
>> > > > > > > > > > > > > It
>> > > > > > > > > > > > > could be done along with changing the YANG library
>> > > > > > > > > > > > > structure,
>> > > > > > > > > > > > > so
>> > > > > > > > > > > > > there
>> > > > > > > > > > > > > will be
>> > > > > > > > > > > > > little extra impact on implementations.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Lada
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > Ladislav Lhotka
>> > > > > > > > > > > > > Head, CZ.NIC Labs
>> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > _______________________________________________
>> > > > > > > > > > > > > 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
>> > > > > > > > > >
>> > >
>> > >
>> >
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> >
>>
>>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>



From nobody Tue Jan 16 04:29:37 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 ACB001314A4 for ; Tue, 16 Jan 2018 04:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 9EDmNrOTZymi for ; Tue, 16 Jan 2018 04:29:32 -0800 (PST)
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 DE9D812FB01 for ; Tue, 16 Jan 2018 04:29:31 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 38CDA644D1; Tue, 16 Jan 2018 13:29:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516105770; bh=SmXjhLL/ny5Dr4cSxqf/jHOUO+Y4WTH8T4Lm5lkT/J0=; h=From:To:Date; b=tK57176S212iRXxjOO80vSYyXg2+wUs2YbGbEWobk7K1iOMrImP7VrH76EDGOW+Ee Q4VIycIpAZoh6jvfxAliQ7s6+i9AYgs0BuH0Bpo/XBX9lDvgxAPosZg0GcBs0AgjoW C54Pf4kW9DbNRFykdUvOxKcmGxo0NTOwIPp5Mj2M=
Message-ID: <1516105770.11372.25.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: lberger@labn.net, netmod@ietf.org
Date: Tue, 16 Jan 2018 13:29:30 +0100
In-Reply-To: <20180116.131909.1138141751153857700.mbj@tail-f.com>
References: <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz> <20180116.131909.1138141751153857700.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:29:35 -0000

On Tue, 2018-01-16 at 13:19 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi Lou,
> > 
> > in my view, we should do the following two (significant) changes:
> > 
> > 1. Instead of borrowing a grouping from ietf-yang-library and having
> > a parallel list of mounted schemas, we should keep *all* mounted
> > schemas directly in the YANG library and refer to them from
> > schema-mounts structures. Juergen suggested this change and it is
> > IMO the right thing to do.
> 
> I agree.
> 
> > 2. Define a metadata annotation (e.g. @schema-ref) that would be required
> for
> > inline mount point instances and specify the inline-mounted schema also by
> > referring to a schema specified in YANG library.
> > 
> > The advantage of #2 is that an annotation can be attached equally
> > well to both state an configuration data. So, instead of papering
> > over the issue that YANG library (state data) cannot appear in
> > configuration datastores, we can use this general and
> > straightforward approach. This also allows for defining different
> > mounted schemas for instances of the same mount point in different
> > datastores.
> 
> This is a clever idea!  I assume this would be used instead of
> requiring the mounting of ietf-yang-library and ietf-schema-mount?

Right. It doesn't preclude mounting them though, e.g. for split management, but
then we can deal with it exactly as with NACM data: the embedded ietf-yang-
library and/or ietf-schema-mount will be ignored in the parent schema.

> 
> For "peer mount", it might be the case that this doesn't work as well
> as the current solution for inline, but I think it is ok.

I am not sure what you exactly mean but the data can be mounted dynamically as
before: the mount point instance is created, its schema written as a new entry
in the top-level YANG library, and the metadata annotation created pointing to
that schema.

Lada

> 
> > I strongly believe that these changes (along with the new YANG library
> schema
> > and NMDA) make for a simple and elegant datastore architecture in which
> schema
> > mount would be an optional feature.
> 
> 
> /martin
> 
> 
> > 
> > Lada 
> > 
> >  
> > 
> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> > > Lada/Martin,
> > > 
> > > I don't believe we reached closure on this discussion.  The open issues 
> > > relate to proposed new text (slightly modified):
> > > 
> > > at the end of the section [3.2] adding a new paragraph along the
> > > lines of:
> > > 
> > >    The use of mount points does not impact the nature of the
> > >    mounted data or in which data store information is made
> > >    available. For example, mounted YANG Library modules define
> > >    only operational state data and, as such, the information in
> > >    these modules is available from operational data stores using
> > >    the appropriate protocol operations.  It is also worth
> > >    noting that the Schema Mount module itself parallels the
> > >    YANG Library module and only defines operational state data.
> > > 
> > > Is this change acceptable?
> > > 
> > > What other issues related to SM are outstanding?
> > > 
> > > Thank you,
> > > 
> > > Lou
> > > 
> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > > > Hi Lada,
> > > > > > > 
> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > > > Lada,
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka  >
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > > > lada,
> > > > > > > > > > > 
> > > > > > > > > > >      See below.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > unfortunately, using an action for querying embedded
> YANG
> > > > > > > > > > > > library
> > > > > > > > > > > > data
> > > > > > > > > > > > (needed for the "inline" case of schema mount) doesn't
> work
> > > > > > > > > > > > either
> > > > > > > > > > > > because now under NMDA actions can be used only on
> instances
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > >  datastore.
> > > > > > > > > > > 
> > > > > > > > > > > but the inline/embedded library would (only) be present in
> the
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > > > 
> > > > > > > > > > Well, the issue is described in my initial mail of this
> thread:
> > > > > > > > > > the
> > > > > > > > > > current
> > > > > > > > > > text
> > > > > > > > > > requires that every instance of an inline mount point
> contains
> > > > > > > > > > the
> > > > > > > > > > embedded
> > > > > > > > > > YANG library. Tha latter is state data, so the above
> requirement
> > > > > > > > > > cannot
> > > > > > > > > > be
> > > > > > > > > > satisfied if the mount point instance is in a configuration
> > > > > > > > > > datastore.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > That's not how I read the intent of the current text.  I don't
> see
> > > > > > > > > SM
> > > > > > > > > impacting which data stores information is presented.  Just
> like
> > > > > > > > > use
> > > > > > > > > of
> > > > > > > > > scheme mount doesn't transform RO configuration information
> into
> > > > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > > > clarifying
> > > > > > > > > this
> > > > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > > > 
> > > > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > > > 
> > > > > > > Agreed - that's why I asked to start this thread!
> > > > > > > 
> > > > > > > Here's the original proposal:
> > > > > > > 
> > > > > > >    How about at the end of the section [3.2] adding a new
> > > > > > >    paragraph along the lines of:
> > > > > > > 
> > > > > > >    It is important to note that both YANG Library and Schema
> > > > > > >    Mount Modules contain only operational state data. As such,
> > > > > > 
> > > > > > s/contain/define/
> > > > > > 
> > > > > > >    the information in these modules should be retrieved by
> > > > > > >    clients from operational data stores using the appropriate
> > > > > > 
> > > > > > This is based on two assumptions:
> > > > > > 
> > > > > > 1. For every configuration datastore there is a corresponding
> > > > > > operational
> > > > > > datastore.
> > > > > 
> > > > > well the text is revised below.  In any case, "these modules" refers
> to
> > > > > yang library, and yes, I'm assuming YL is always and only in
> > > > > operational.  If the revised text below isn't clear s/these/YANG
> Library/
> > > > > -
> > > > 
> > > > The thing is that we have the top-level YANG library in ,
> and
> > > > then
> > > > embedded YANG libraries scattered inside inline mount point instances.
> > > > 
> > > > > > 2. For every mount point instance in any configuration datastore
> there
> > > > > > is a
> > > > > > corresponding mount point instance (with the same path) in an
> > > > > > operational
> > > > > > datastore.
> > > > > > 
> > > > > > I think that neither of these has to be true in general.
> > > > > 
> > > > > agreed in general, but for inline, where YL is required, it must be
> true.
> > > > 
> > > > How do you know? I provided an example in Singapore where a mount point
> > > > instance
> > > > in  is a part of pre-provisioned data (for non-existent
> hardware).
> > > > Then, according to the NMDA rules there is no corresponding instance in
> > > > , hence no place where the embedded YANG library can be
> placed.
> > > > (I can easily provide a concrete example if needed).
> > > > 
> > > > 
> > > > Dean replied that this cannot happen, so it seems there are some
> assumptions
> > > > how
> > > > the inline method of schema mount may be applied. If so, these
> assumptions
> > > > have
> > > > to be explicitly stated.
> > > > 
> > > > > > >    protocol operations.
> > > > > > 
> > > > > > In contrast, the substance of my proposal with metadata annotations
> is
> > > > > > to be
> > > > > > able to retrieve all schemas from a well-known location in *the*
> > > > > > 
> > > > > > datastore, namely from the top-level YANG library.
> > > > > 
> > > > > What about a schema that is based on dll that contains modules that
> > > > > isn't loaded until a mount point is instantiated -- this is certainly
> a
> > > > > valid approach for supporting LNEs, but would be precluded in this
> > > > > approach.  I really don't think a top level approach works for all
> > > > > inline (managed) types of mounts.
> > > > 
> > > > It isn't precluded: when the mount point is instantiated (no matter
> which
> > > > datastore it is in), the server adds the schema as a new entry to the
> > > > "schema"
> > > > list in the top level YANG library (with a unique key), and annotates
> the
> > > > mount
> > > > point instance with a leafref pointing to that key. So different
> instances
> > > > of
> > > > the same mount point can have different schemas.
> > > > 
> > > > > > > Given this discussion, we can generalize it further to:
> > > > > > > 
> > > > > > >    The use of mount points does not impact the nature of the
> > > > > > >    mounted data or in which data store information is made
> > > > > > >    available. For example, mounted YANG Library modules contain
> > > > > > >    only operational state data and, as such, the information in
> > > > > > >    these modules is available from operational data stores using
> > > > > > >    the appropriate protocol operations.
> > > > > > 
> > > > > > The whole question here is whether and how we can locate the schema
> for
> > > > > > an
> > > > > > inline mount point in any configuration datastore.
> > > > > 
> > > > > Why is a mounted YL different than a top level YL?  What works for and
> > > > 
> > > > It is not different, but it can be only in an operational datastores,
> and so
> > > > for
> > > > mount point instances inside configuration datastores we need a way how
> to
> > > > locate the schema for that mount point, because it cannot be found
> directly
> > > > under the mount point instance (as the current text assumes).
> > > > 
> > > > > is sufficient for the normal case of YL shouldn't be impacted or
> > > > > modified by SM -- at least that's how I thought we've been talking
> about
> > > > > since SM was started.  Again, we never made any special provisions for
> > > > > any other rw/ro/state data, assuming top level YL is not handled as
> > > > > metadata, why start now?
> > > > > 
> > > > > I'm getting the impression that your argument may be more about if YL
> > > > > should be treated as something other than operational data, is this
> wrong?
> > > > 
> > > > This is wrong. My argument is that there should be only one top-level
> YANG
> > > > library (state data) and each inline mount point instance just points to
> a
> > > > schema inside it by means of a metadata annotation attached to the mount
> > > > point
> > > > (in any datastore).
> > > > 
> > > > Lada
> > > > 
> > > > > Thanks,
> > > > > Lou
> > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > > Lou
> > > > > > > 
> > > > > > > > Lada
> > > > > > > > 
> > > > > > > > > Lou
> > > > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > > > annotation
> > > > > > > > > > > > along
> > > > > > > > > > > > the
> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B of
> the
> > > > > > > > > > > > newly
> > > > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > > > 
> > > > > > > > > > > >       md:annotation schema-ref {
> > > > > > > > > > > >         type leafref {
> > > > > > > > > > > >           path "/yanglib:yang-
> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > > > >         }
> > > > > > > > > > > >       }
> > > > > > > > > > > > 
> > > > > > > > > > > > In other words, all inline mounted schemas would be
> included
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > top-level YANG library, and mount point instances in all
> > > > > > > > > > > > datastores
> > > > > > > > > > > > would be annotated with leafref pointing to the actual
> > > > > > > > > > > > schema.
> > > > > > > > > > > > 
> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> permit
> > > > > > > > > > > > such
> > > > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > > > 
> > > > > > > > > > > > Opinions?
> > > > > > > > > > > 
> > > > > > > > > > > I'm not sure this will work for all architectures of LNEs
> as
> > > > > > > > > > > well
> > > > > > > > > > > as
> > > > > > > > > > > other possible future use cases.  In short, this seems
> *very*
> > > > > > > > > > > restrictive.
> > > > > > > > > > 
> > > > > > > > > > I don't understand, IMO it is not restrictive at all. What
> kind
> > > > > > > > > > of
> > > > > > > > > > restrictions
> > > > > > > > > > do you see?
> > > > > > > > > > 
> > > > > > > > > > Lada
> > > > > > > > > > 
> > > > > > > > > > > Lou
> > > > > > > > > > > 
> > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is
> wrong
> > > > > > > > > > > > > for
> > > > > > > > > > > > > traditional
> > > > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > > > 
> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
> determined
> > > > > > > > > > > > > at
> > > > > > > > > > > > > run
> > > > > > > > > > > > > time:
> > > > > > > > > > > > > every
> > > > > > > > > > > > >     instance of the mount point that exists in the
> parent
> > > > > > > > > > > > > tree
> > > > > > > > > > > > > MUST
> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895] that
> > > > > > > > > > > > > defines
> > > > > > > > > > > > > the
> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
> > > > > > > > > > > > > model.  A
> > > > > > > > > > > > > client
> > > > > > > > > > > > > is
> > > > > > > > > > > > >     expected to retrieve this data from the instance
> tree,
> > > > > > > > > > > > > possibly
> > > > > > > > > > > > > after
> > > > > > > > > > > > >     creating the mount point.  Instances of the same
> mount
> > > > > > > > > > > > > point
> > > > > > > > > > > > > MAY
> > > > > > > > > > > > > use
> > > > > > > > > > > > >     different mounted schemas.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > An instance of the mount point in any *configuration*
> > > > > > > > > > > > > datastores
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > contain
> > > > > > > > > > > > > YANG library (being state data), and so the MUST
> cannot
> > > > > > > > > > > > > hold.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > > > considerable
> > > > > > > > > > > > > complications
> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one good
> > > > > > > > > > > > > solution
> > > > > > > > > > > > > but it
> > > > > > > > > > > > > has
> > > > > > > > > > > > > impact on YANG library: the server could provide it in
> a
> > > > > > > > > > > > > reply
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation,
> > > > > > > > > > > > > say "get-yang-library" rather than as state data. Then
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > would be
> > > > > > > > > > > > > fine
> > > > > > > > > > > > > - this operation would turn into an action for the
> mount
> > > > > > > > > > > > > point,
> > > > > > > > > > > > > and it
> > > > > > > > > > > > > can
> > > > > > > > > > > > > be
> > > > > > > > > > > > > used equally well for config true and false mount
> points.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So my proposal is to move from YANG library as state
> data
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation.
> > > > > > > > > > > > > It
> > > > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > > > structure,
> > > > > > > > > > > > > so
> > > > > > > > > > > > > there
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Lada
> > > > > > > > > > > > > 
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > 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
> > > > > > > > > > 
> > > 
> > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 04:41: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 E8DED12DB6D for ; Tue, 16 Jan 2018 04:41:25 -0800 (PST)
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_RP_MATCHES_RCVD=-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 XpiHo2n90933 for ; Tue, 16 Jan 2018 04:41:23 -0800 (PST)
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 6E9B912711B for ; Tue, 16 Jan 2018 04:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14431; q=dns/txt; s=iport; t=1516106482; x=1517316082; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KCbVMsgnQTPnkRQGbs7lGXDmF9L5DLbW2rw6p7Duz2M=; b=DV5Pf2QTwNLC8l2C5680E08kLJv497BA72zfjx0HX2OLc/o9j5TjnA0w Px2SVqwnEJrdHncvDUTDEDXthIs44uwt+IztbHQ8niH3Pph3hEDiBhU8/ WVUYNxD3ZQ/JczgyAE/GaN+Wh0r9AHoLLClRyE2Weyx0Fug0RYe9BhN5l 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQBs8l1a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj26ZQgoYC4RJTwKFHhQBAQEBAQEBAQFrKIUjAQE?= =?us-ascii?q?BAQIBAQEhDwEFNgsQCxIGAgImAgInIg4GAQwGAgEBF4oQCBClb4IniUkBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEPhxmBaSmDBYMvAQECgU8BAQhCgmuCZQWSJ5E?= =?us-ascii?q?9iziKE4IZhh2DbyaHRY8ciAmBPDYigVAyGggbFT2CKoRXQTeLA4I8AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200";  d="scan'208";a="1478661"
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; 16 Jan 2018 12:41:18 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0GCfHPr029061; Tue, 16 Jan 2018 12:41:18 GMT
To: Ladislav Lhotka , Lou Berger , Martin Bjorklund 
Cc: NETMOD WG 
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Tue, 16 Jan 2018 12:41:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1516086847.3188.24.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 12:41:26 -0000

On 16/01/2018 07:14, Ladislav Lhotka wrote:
> Hi Lou,
>
> in my view, we should do the following two (significant) changes:
>
> 1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
> list of mounted schemas, we should keep *all* mounted schemas directly in the
> YANG library and refer to them from schema-mounts structures. Juergen suggested
> this change and it is IMO the right thing to do.
I also support this approach.  I think that it easier for everyone if 
schema are defined in one place.

This was also the suggested approach that I presented at IETF 100 for 
the YANG library bis draft, which seemed to have reasonable support in 
the room, and I don't recall anyone objecting to this approach.

I also provided the same comment in November during the WG LC on schema 
mount ...

Thanks,
Rob


>
> 2. Define a metadata annotation (e.g. @schema-ref) that would be required for
> inline mount point instances and specify the inline-mounted schema also by
> referring to a schema specified in YANG library.
>
> The advantage of #2 is that an annotation can be attached equally well to both
> state an configuration data. So, instead of papering over the issue that YANG
> library (state data) cannot appear in configuration datastores, we can use this
> general and straightforward approach. This also allows for defining different
> mounted schemas for instances of the same mount point in different datastores.
>
> I strongly believe that these changes (along with the new YANG library schema
> and NMDA) make for a simple and elegant datastore architecture in which schema
> mount would be an optional feature.
>
> Lada
>
>   
>
> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> Lada/Martin,
>>
>> I don't believe we reached closure on this discussion.  The open issues
>> relate to proposed new text (slightly modified):
>>
>> at the end of the section [3.2] adding a new paragraph along the
>> lines of:
>>
>>     The use of mount points does not impact the nature of the
>>     mounted data or in which data store information is made
>>     available. For example, mounted YANG Library modules define
>>     only operational state data and, as such, the information in
>>     these modules is available from operational data stores using
>>     the appropriate protocol operations.  It is also worth
>>     noting that the Schema Mount module itself parallels the
>>     YANG Library module and only defines operational state data.
>>
>> Is this change acceptable?
>>
>> What other issues related to SM are outstanding?
>>
>> Thank you,
>>
>> Lou
>>
>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>> Hi Lada,
>>>>>>
>>>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>>>> Lada,
>>>>>>>>
>>>>>>>>
>>>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>>>> lada,
>>>>>>>>>>
>>>>>>>>>>       See below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>>>> library
>>>>>>>>>>> data
>>>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>>>> either
>>>>>>>>>>> because now under NMDA actions can be used only on instances
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>>  datastore.
>>>>>>>>>> but the inline/embedded library would (only) be present in the
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> operational datastore, so what's the issue?
>>>>>>>>> Well, the issue is described in my initial mail of this thread:
>>>>>>>>> the
>>>>>>>>> current
>>>>>>>>> text
>>>>>>>>> requires that every instance of an inline mount point contains
>>>>>>>>> the
>>>>>>>>> embedded
>>>>>>>>> YANG library. Tha latter is state data, so the above requirement
>>>>>>>>> cannot
>>>>>>>>> be
>>>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>>>> datastore.
>>>>>>>>>
>>>>>>>> That's not how I read the intent of the current text.  I don't see
>>>>>>>> SM
>>>>>>>> impacting which data stores information is presented.  Just like
>>>>>>>> use
>>>>>>>> of
>>>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>>>> operational information.  I sent you a couple of sentences
>>>>>>>> clarifying
>>>>>>>> this
>>>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>>>> Please do, this has to be discussed in the WG mailing list.
>>>>>> Agreed - that's why I asked to start this thread!
>>>>>>
>>>>>> Here's the original proposal:
>>>>>>
>>>>>>     How about at the end of the section [3.2] adding a new
>>>>>>     paragraph along the lines of:
>>>>>>
>>>>>>     It is important to note that both YANG Library and Schema
>>>>>>     Mount Modules contain only operational state data. As such,
>>>>> s/contain/define/
>>>>>
>>>>>>     the information in these modules should be retrieved by
>>>>>>     clients from operational data stores using the appropriate
>>>>> This is based on two assumptions:
>>>>>
>>>>> 1. For every configuration datastore there is a corresponding
>>>>> operational
>>>>> datastore.
>>>> well the text is revised below.  In any case, "these modules" refers to
>>>> yang library, and yes, I'm assuming YL is always and only in
>>>> operational.  If the revised text below isn't clear s/these/YANG Library/
>>>> -
>>> The thing is that we have the top-level YANG library in , and
>>> then
>>> embedded YANG libraries scattered inside inline mount point instances.
>>>
>>>>> 2. For every mount point instance in any configuration datastore there
>>>>> is a
>>>>> corresponding mount point instance (with the same path) in an
>>>>> operational
>>>>> datastore.
>>>>>
>>>>> I think that neither of these has to be true in general.
>>>> agreed in general, but for inline, where YL is required, it must be true.
>>> How do you know? I provided an example in Singapore where a mount point
>>> instance
>>> in  is a part of pre-provisioned data (for non-existent hardware).
>>> Then, according to the NMDA rules there is no corresponding instance in
>>> , hence no place where the embedded YANG library can be placed.
>>> (I can easily provide a concrete example if needed).
>>>
>>>
>>> Dean replied that this cannot happen, so it seems there are some assumptions
>>> how
>>> the inline method of schema mount may be applied. If so, these assumptions
>>> have
>>> to be explicitly stated.
>>>
>>>>>>     protocol operations.
>>>>> In contrast, the substance of my proposal with metadata annotations is
>>>>> to be
>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>> 
>>>>> datastore, namely from the top-level YANG library.
>>>> What about a schema that is based on dll that contains modules that
>>>> isn't loaded until a mount point is instantiated -- this is certainly a
>>>> valid approach for supporting LNEs, but would be precluded in this
>>>> approach.  I really don't think a top level approach works for all
>>>> inline (managed) types of mounts.
>>> It isn't precluded: when the mount point is instantiated (no matter which
>>> datastore it is in), the server adds the schema as a new entry to the
>>> "schema"
>>> list in the top level YANG library (with a unique key), and annotates the
>>> mount
>>> point instance with a leafref pointing to that key. So different instances
>>> of
>>> the same mount point can have different schemas.
>>>
>>>>>> Given this discussion, we can generalize it further to:
>>>>>>
>>>>>>     The use of mount points does not impact the nature of the
>>>>>>     mounted data or in which data store information is made
>>>>>>     available. For example, mounted YANG Library modules contain
>>>>>>     only operational state data and, as such, the information in
>>>>>>     these modules is available from operational data stores using
>>>>>>     the appropriate protocol operations.
>>>>> The whole question here is whether and how we can locate the schema for
>>>>> an
>>>>> inline mount point in any configuration datastore.
>>>> Why is a mounted YL different than a top level YL?  What works for and
>>> It is not different, but it can be only in an operational datastores, and so
>>> for
>>> mount point instances inside configuration datastores we need a way how to
>>> locate the schema for that mount point, because it cannot be found directly
>>> under the mount point instance (as the current text assumes).
>>>
>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>> modified by SM -- at least that's how I thought we've been talking about
>>>> since SM was started.  Again, we never made any special provisions for
>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>> metadata, why start now?
>>>>
>>>> I'm getting the impression that your argument may be more about if YL
>>>> should be treated as something other than operational data, is this wrong?
>>> This is wrong. My argument is that there should be only one top-level YANG
>>> library (state data) and each inline mount point instance just points to a
>>> schema inside it by means of a metadata annotation attached to the mount
>>> point
>>> (in any datastore).
>>>
>>> Lada
>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>>> Lada
>>>>>
>>>>>> Lou
>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>> Lou
>>>>>>>>>>> However, a good alternative seems to be a metadata
>>>>>>>>>>> annotation
>>>>>>>>>>> along
>>>>>>>>>>> the
>>>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>>>> newly
>>>>>>>>>>> proposed YANG library schema:
>>>>>>>>>>>
>>>>>>>>>>>        md:annotation schema-ref {
>>>>>>>>>>>          type leafref {
>>>>>>>>>>>            path "/yanglib:yang-
>>>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>>>          }
>>>>>>>>>>>        }
>>>>>>>>>>>
>>>>>>>>>>> In other words, all inline mounted schemas would be included
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>>>> datastores
>>>>>>>>>>> would be annotated with leafref pointing to the actual
>>>>>>>>>>> schema.
>>>>>>>>>>>
>>>>>>>>>>> Unlike regular state data, it is IMO no problem to permit
>>>>>>>>>>> such
>>>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>>>
>>>>>>>>>>> Opinions?
>>>>>>>>>> I'm not sure this will work for all architectures of LNEs as
>>>>>>>>>> well
>>>>>>>>>> as
>>>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>>>> restrictive.
>>>>>>>>> I don't understand, IMO it is not restrictive at all. What kind
>>>>>>>>> of
>>>>>>>>> restrictions
>>>>>>>>> do you see?
>>>>>>>>>
>>>>>>>>> Lada
>>>>>>>>>
>>>>>>>>>> Lou
>>>>>>>>>>
>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>
>>>>>>>>>>> Ladislav Lhotka  writes:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong
>>>>>>>>>>>> for
>>>>>>>>>>>> traditional
>>>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>>>
>>>>>>>>>>>>      In case 1 ["inline"], the mounted schema is determined
>>>>>>>>>>>> at
>>>>>>>>>>>> run
>>>>>>>>>>>> time:
>>>>>>>>>>>> every
>>>>>>>>>>>>      instance of the mount point that exists in the parent
>>>>>>>>>>>> tree
>>>>>>>>>>>> MUST
>>>>>>>>>>>>      contain a copy of YANG library data [RFC7895] that
>>>>>>>>>>>> defines
>>>>>>>>>>>> the
>>>>>>>>>>>>      mounted schema exactly as for a top-level data
>>>>>>>>>>>> model.  A
>>>>>>>>>>>> client
>>>>>>>>>>>> is
>>>>>>>>>>>>      expected to retrieve this data from the instance tree,
>>>>>>>>>>>> possibly
>>>>>>>>>>>> after
>>>>>>>>>>>>      creating the mount point.  Instances of the same mount
>>>>>>>>>>>> point
>>>>>>>>>>>> MAY
>>>>>>>>>>>> use
>>>>>>>>>>>>      different mounted schemas.
>>>>>>>>>>>>
>>>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>>>> datastores
>>>>>>>>>>>> cannot
>>>>>>>>>>>> contain
>>>>>>>>>>>> YANG library (being state data), and so the MUST cannot
>>>>>>>>>>>> hold.
>>>>>>>>>>>>
>>>>>>>>>>>> It is not clear to me how to repair this without
>>>>>>>>>>>> considerable
>>>>>>>>>>>> complications
>>>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>>>> solution
>>>>>>>>>>>> but it
>>>>>>>>>>>> has
>>>>>>>>>>>> impact on YANG library: the server could provide it in a
>>>>>>>>>>>> reply
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> operation,
>>>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>>>> everything
>>>>>>>>>>>> would be
>>>>>>>>>>>> fine
>>>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>>>> point,
>>>>>>>>>>>> and it
>>>>>>>>>>>> can
>>>>>>>>>>>> be
>>>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>>>
>>>>>>>>>>>> So my proposal is to move from YANG library as state data
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> operation.
>>>>>>>>>>>> It
>>>>>>>>>>>> could be done along with changing the YANG library
>>>>>>>>>>>> structure,
>>>>>>>>>>>> so
>>>>>>>>>>>> there
>>>>>>>>>>>> will be
>>>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>>>
>>>>>>>>>>>> Lada
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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 Jan 16 05:26: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 6F313131509 for ; Tue, 16 Jan 2018 05:26:27 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1pup7e7bsAGy for ; Tue, 16 Jan 2018 05:26:20 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA6E713151E for ; Tue, 16 Jan 2018 05:24:10 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DE971AE0399; Tue, 16 Jan 2018 14:24:08 +0100 (CET)
Date: Tue, 16 Jan 2018 14:24:07 +0100 (CET)
Message-Id: <20180116.142407.1498790690296330642.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516104404.11372.15.camel@nic.cz> <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 13:26:27 -0000

Lou Berger  wrote:
> Lada,
> 
> 
> On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:
> 
> > On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> >> Lada,
> >>
> >> It sounds like you are proposing in (1) a fairly significant change in
> >> the
> >> direction of the draft and in (2) a basic approach that has been
> >
> > It is no change in direction, just a simplification of the
> > schema-describing
> > state data. Given the recent developments in 7895bis it makes no sense
> > to me to
> > have two "schema" lists if we can have just one.
> >
> 
> Managing transition is hard. It's also highlights why Yang Library
> this needs to be at least equally discussed in this group.
> 
> I will talk with my co-chairs and perhaps the ADs to get their opinion
> on making such a change this point in the process.
> 
> 
> >>
> >> rejectected by the WG multiple times.  FWIW there are drafts already
> >> with
> >
> > No at all. The first and last time I proposed this was on 15 December
> > 2017:
> >
> > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> >
> 
> Oh, I certainly would call you proposing that the schema for inline be
> part of the rest of the schema Mount module well before that. I'm sure
> I can dig up mail / slides it really necessary...

I don't think this has been proposed before.  All previous proposals
were basically variants on what is now "use-schema", which works fine
when all instances have the same schema.  This new proposal solves the
issue with different schemas in different instances.

> > The only reply was from you. To me, it is the cleanest solution of the
> > inline
> > case. Of course, I am open to technical objections.
> >
> 
> I'm sure I can find material on this as well....

Ok.


/martin


> 
> Lou
> 
> > If it's not clear what I mean, I can make up some examples.
> >
> > Lada
> >
> >
> >> the iesg that will need to be returned to their WGs if either change
> >> is made.
> >>
> >> Martin,
> >>
> >> Do share Lada's view?
> >>
> >> Lou
> >>
> >>
> >> On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:
> >>
> >> > Hi Lou,
> >> >
> >> > in my view, we should do the following two (significant) changes:
> >> >
> >> > 1. Instead of borrowing a grouping from ietf-yang-library and having a
> >> > parallel
> >> > list of mounted schemas, we should keep *all* mounted schemas directly
> >> > in
> >> > the
> >> > YANG library and refer to them from schema-mounts structures. Juergen
> >> > suggested
> >> > this change and it is IMO the right thing to do.
> >> >
> >> > 2. Define a metadata annotation (e.g. @schema-ref) that would be
> >> > required
> >> > for
> >> > inline mount point instances and specify the inline-mounted schema
> >> > also by
> >> > referring to a schema specified in YANG library.
> >> >
> >> > The advantage of #2 is that an annotation can be attached equally well
> >> > to
> >> > both
> >> > state an configuration data. So, instead of papering over the issue
> >> > that
> >> > YANG
> >> > library (state data) cannot appear in configuration datastores, we can
> >> > use
> >> > this
> >> > general and straightforward approach. This also allows for defining
> >> > different
> >> > mounted schemas for instances of the same mount point in different
> >> > datastores.
> >> >
> >> > I strongly believe that these changes (along with the new YANG library
> >> > schema
> >> > and NMDA) make for a simple and elegant datastore architecture in
> >> > which
> >> > schema
> >> > mount would be an optional feature.
> >> >
> >> > Lada
> >> >
> >> >
> >> >
> >> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> >> > > Lada/Martin,
> >> > >
> >> > > I don't believe we reached closure on this discussion.  The open
> >> > > issues
> >> > > relate to proposed new text (slightly modified):
> >> > >
> >> > > at the end of the section [3.2] adding a new paragraph along the
> >> > > lines of:
> >> > >
> >> > >    The use of mount points does not impact the nature of the
> >> > >    mounted data or in which data store information is made
> >> > >    available. For example, mounted YANG Library modules define
> >> > >    only operational state data and, as such, the information in
> >> > >    these modules is available from operational data stores using
> >> > >    the appropriate protocol operations.  It is also worth
> >> > >    noting that the Schema Mount module itself parallels the
> >> > >    YANG Library module and only defines operational state data.
> >> > >
> >> > > Is this change acceptable?
> >> > >
> >> > > What other issues related to SM are outstanding?
> >> > >
> >> > > Thank you,
> >> > >
> >> > > Lou
> >> > >
> >> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> >> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> >> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> >> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> >> > > > > > > Hi Lada,
> >> > > > > > >
> >> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> >> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> >> > > > > > > > > Lada,
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka
> >> > > > > > > > >  >> > > > > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> >> > > > > > > > > > > lada,
> >> > > > > > > > > > >
> >> > > > > > > > > > >      See below.
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> >> > > > > > > > > > > > Hi,
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > unfortunately, using an action for querying embedded
> >> > > > > > > > > > > > YANG
> >> > > > > > > > > > > > library
> >> > > > > > > > > > > > data
> >> > > > > > > > > > > > (needed for the "inline" case of schema mount)
> >> > > > > > > > > > > > doesn't
> >> > > > > > > > > > > > work
> >> > > > > > > > > > > > either
> >> > > > > > > > > > > > because now under NMDA actions can be used only on
> >> > > > > > > > > > > > instances
> >> > > > > > > > > > > > in
> >> > > > > > > > > > > > the
> >> > > > > > > > > > > >  datastore.
> >> > > > > > > > > > >
> >> > > > > > > > > > > but the inline/embedded library would (only) be present
> >> > > > > > > > > > > in
> >> > > > > > > > > > > the
> >> > > > > > > > > > > in
> >> > > > > > > > > > > the
> >> > > > > > > > > > > operational datastore, so what's the issue?
> >> > > > > > > > > >
> >> > > > > > > > > > Well, the issue is described in my initial mail of this
> >> > > > > > > > > > thread:
> >> > > > > > > > > > the
> >> > > > > > > > > > current
> >> > > > > > > > > > text
> >> > > > > > > > > > requires that every instance of an inline mount point
> >> > > > > > > > > > contains
> >> > > > > > > > > > the
> >> > > > > > > > > > embedded
> >> > > > > > > > > > YANG library. Tha latter is state data, so the above
> >> > > > > > > > > > requirement
> >> > > > > > > > > > cannot
> >> > > > > > > > > > be
> >> > > > > > > > > > satisfied if the mount point instance is in a
> >> > > > > > > > > > configuration
> >> > > > > > > > > > datastore.
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > That's not how I read the intent of the current text.  I
> >> > > > > > > > > don't
> >> > > > > > > > > see
> >> > > > > > > > > SM
> >> > > > > > > > > impacting which data stores information is presented.  Just
> >> > > > > > > > > like
> >> > > > > > > > > use
> >> > > > > > > > > of
> >> > > > > > > > > scheme mount doesn't transform RO configuration information
> >> > > > > > > > > into
> >> > > > > > > > > operational information.  I sent you a couple of sentences
> >> > > > > > > > > clarifying
> >> > > > > > > > > this
> >> > > > > > > > > at one point, I'll dig up the proposed text and resend.
> >> > > > > > > >
> >> > > > > > > > Please do, this has to be discussed in the WG mailing list.
> >> > > > > > >
> >> > > > > > > Agreed - that's why I asked to start this thread!
> >> > > > > > >
> >> > > > > > > Here's the original proposal:
> >> > > > > > >
> >> > > > > > >    How about at the end of the section [3.2] adding a new
> >> > > > > > >    paragraph along the lines of:
> >> > > > > > >
> >> > > > > > >    It is important to note that both YANG Library and Schema
> >> > > > > > >    Mount Modules contain only operational state data. As such,
> >> > > > > >
> >> > > > > > s/contain/define/
> >> > > > > >
> >> > > > > > >    the information in these modules should be retrieved by
> >> > > > > > >    clients from operational data stores using the appropriate
> >> > > > > >
> >> > > > > > This is based on two assumptions:
> >> > > > > >
> >> > > > > > 1. For every configuration datastore there is a corresponding
> >> > > > > > operational
> >> > > > > > datastore.
> >> > > > >
> >> > > > > well the text is revised below.  In any case, "these modules"
> >> > > > > refers
> >> > > > > to
> >> > > > > yang library, and yes, I'm assuming YL is always and only in
> >> > > > > operational.  If the revised text below isn't clear s/these/YANG
> >> > > > > Library/
> >> > > > > -
> >> > > >
> >> > > > The thing is that we have the top-level YANG library in
> >> > > > ,
> >> > > > and
> >> > > > then
> >> > > > embedded YANG libraries scattered inside inline mount point
> >> > > > instances.
> >> > > >
> >> > > > > > 2. For every mount point instance in any configuration datastore
> >> > > > > > there
> >> > > > > > is a
> >> > > > > > corresponding mount point instance (with the same path) in an
> >> > > > > > operational
> >> > > > > > datastore.
> >> > > > > >
> >> > > > > > I think that neither of these has to be true in general.
> >> > > > >
> >> > > > > agreed in general, but for inline, where YL is required, it must be
> >> > > > > true.
> >> > > >
> >> > > > How do you know? I provided an example in Singapore where a mount
> >> > > > point
> >> > > > instance
> >> > > > in  is a part of pre-provisioned data (for non-existent
> >> > > > hardware).
> >> > > > Then, according to the NMDA rules there is no corresponding instance
> >> > > > in
> >> > > > , hence no place where the embedded YANG library can be
> >> > > > placed.
> >> > > > (I can easily provide a concrete example if needed).
> >> > > >
> >> > > >
> >> > > > Dean replied that this cannot happen, so it seems there are some
> >> > > > assumptions
> >> > > > how
> >> > > > the inline method of schema mount may be applied. If so, these
> >> > > > assumptions
> >> > > > have
> >> > > > to be explicitly stated.
> >> > > >
> >> > > > > > >    protocol operations.
> >> > > > > >
> >> > > > > > In contrast, the substance of my proposal with metadata
> >> > > > > > annotations
> >> > > > > > is
> >> > > > > > to be
> >> > > > > > able to retrieve all schemas from a well-known location in *the*
> >> > > > > > 
> >> > > > > > datastore, namely from the top-level YANG library.
> >> > > > >
> >> > > > > What about a schema that is based on dll that contains modules that
> >> > > > > isn't loaded until a mount point is instantiated -- this is
> >> > > > > certainly
> >> > > > > a
> >> > > > > valid approach for supporting LNEs, but would be precluded in this
> >> > > > > approach.  I really don't think a top level approach works for all
> >> > > > > inline (managed) types of mounts.
> >> > > >
> >> > > > It isn't precluded: when the mount point is instantiated (no matter
> >> > > > which
> >> > > > datastore it is in), the server adds the schema as a new entry to the
> >> > > > "schema"
> >> > > > list in the top level YANG library (with a unique key), and annotates
> >> > > > the
> >> > > > mount
> >> > > > point instance with a leafref pointing to that key. So different
> >> > > > instances
> >> > > > of
> >> > > > the same mount point can have different schemas.
> >> > > >
> >> > > > > > > Given this discussion, we can generalize it further to:
> >> > > > > > >
> >> > > > > > >    The use of mount points does not impact the nature of the
> >> > > > > > >    mounted data or in which data store information is made
> >> > > > > > >    available. For example, mounted YANG Library modules contain
> >> > > > > > >    only operational state data and, as such, the information in
> >> > > > > > >    these modules is available from operational data stores
> >> > > > > > >    using
> >> > > > > > >    the appropriate protocol operations.
> >> > > > > >
> >> > > > > > The whole question here is whether and how we can locate the
> >> > > > > > schema
> >> > > > > > for
> >> > > > > > an
> >> > > > > > inline mount point in any configuration datastore.
> >> > > > >
> >> > > > > Why is a mounted YL different than a top level YL?  What works for
> >> > > > > and
> >> > > >
> >> > > > It is not different, but it can be only in an operational datastores,
> >> > > > and so
> >> > > > for
> >> > > > mount point instances inside configuration datastores we need a way
> >> > > > how
> >> > > > to
> >> > > > locate the schema for that mount point, because it cannot be found
> >> > > > directly
> >> > > > under the mount point instance (as the current text assumes).
> >> > > >
> >> > > > > is sufficient for the normal case of YL shouldn't be impacted or
> >> > > > > modified by SM -- at least that's how I thought we've been talking
> >> > > > > about
> >> > > > > since SM was started.  Again, we never made any special provisions
> >> > > > > for
> >> > > > > any other rw/ro/state data, assuming top level YL is not handled as
> >> > > > > metadata, why start now?
> >> > > > >
> >> > > > > I'm getting the impression that your argument may be more about if
> >> > > > > YL
> >> > > > > should be treated as something other than operational data, is this
> >> > > > > wrong?
> >> > > >
> >> > > > This is wrong. My argument is that there should be only one top-level
> >> > > > YANG
> >> > > > library (state data) and each inline mount point instance just points
> >> > > > to
> >> > > > a
> >> > > > schema inside it by means of a metadata annotation attached to the
> >> > > > mount
> >> > > > point
> >> > > > (in any datastore).
> >> > > >
> >> > > > Lada
> >> > > >
> >> > > > > Thanks,
> >> > > > > Lou
> >> > > > >
> >> > > > > > Lada
> >> > > > > >
> >> > > > > > > Lou
> >> > > > > > >
> >> > > > > > > > Lada
> >> > > > > > > >
> >> > > > > > > > > Lou
> >> > > > > > > > > > > > However, a good alternative seems to be a metadata
> >> > > > > > > > > > > > annotation
> >> > > > > > > > > > > > along
> >> > > > > > > > > > > > the
> >> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B
> >> > > > > > > > > > > > of
> >> > > > > > > > > > > > the
> >> > > > > > > > > > > > newly
> >> > > > > > > > > > > > proposed YANG library schema:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >       md:annotation schema-ref {
> >> > > > > > > > > > > >         type leafref {
> >> > > > > > > > > > > >           path "/yanglib:yang-
> >> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
> >> > > > > > > > > > > >         }
> >> > > > > > > > > > > >       }
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > In other words, all inline mounted schemas would be
> >> > > > > > > > > > > > included
> >> > > > > > > > > > > > in
> >> > > > > > > > > > > > the
> >> > > > > > > > > > > > top-level YANG library, and mount point instances in
> >> > > > > > > > > > > > all
> >> > > > > > > > > > > > datastores
> >> > > > > > > > > > > > would be annotated with leafref pointing to the
> >> > > > > > > > > > > > actual
> >> > > > > > > > > > > > schema.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> >> > > > > > > > > > > > permit
> >> > > > > > > > > > > > such
> >> > > > > > > > > > > > annotations in configuration datastores.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Opinions?
> >> > > > > > > > > > >
> >> > > > > > > > > > > I'm not sure this will work for all architectures of
> >> > > > > > > > > > > LNEs
> >> > > > > > > > > > > as
> >> > > > > > > > > > > well
> >> > > > > > > > > > > as
> >> > > > > > > > > > > other possible future use cases.  In short, this seems
> >> > > > > > > > > > > *very*
> >> > > > > > > > > > > restrictive.
> >> > > > > > > > > >
> >> > > > > > > > > > I don't understand, IMO it is not restrictive at
> >> > > > > > > > > > all. What
> >> > > > > > > > > > kind
> >> > > > > > > > > > of
> >> > > > > > > > > > restrictions
> >> > > > > > > > > > do you see?
> >> > > > > > > > > >
> >> > > > > > > > > > Lada
> >> > > > > > > > > >
> >> > > > > > > > > > > Lou
> >> > > > > > > > > > >
> >> > > > > > > > > > > > Thanks, Lada
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Ladislav Lhotka  writes:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > > Hi,
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08
> >> > > > > > > > > > > > > is
> >> > > > > > > > > > > > > wrong
> >> > > > > > > > > > > > > for
> >> > > > > > > > > > > > > traditional
> >> > > > > > > > > > > > > datastores, and even more so for NDMA:
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
> >> > > > > > > > > > > > > determined
> >> > > > > > > > > > > > > at
> >> > > > > > > > > > > > > run
> >> > > > > > > > > > > > > time:
> >> > > > > > > > > > > > > every
> >> > > > > > > > > > > > >     instance of the mount point that exists in the
> >> > > > > > > > > > > > > parent
> >> > > > > > > > > > > > > tree
> >> > > > > > > > > > > > > MUST
> >> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895]
> >> > > > > > > > > > > > >     that
> >> > > > > > > > > > > > > defines
> >> > > > > > > > > > > > > the
> >> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
> >> > > > > > > > > > > > > model.  A
> >> > > > > > > > > > > > > client
> >> > > > > > > > > > > > > is
> >> > > > > > > > > > > > >     expected to retrieve this data from the
> >> > > > > > > > > > > > >     instance
> >> > > > > > > > > > > > > tree,
> >> > > > > > > > > > > > > possibly
> >> > > > > > > > > > > > > after
> >> > > > > > > > > > > > >     creating the mount point.  Instances of the
> >> > > > > > > > > > > > >     same
> >> > > > > > > > > > > > > mount
> >> > > > > > > > > > > > > point
> >> > > > > > > > > > > > > MAY
> >> > > > > > > > > > > > > use
> >> > > > > > > > > > > > >     different mounted schemas.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > An instance of the mount point in any
> >> > > > > > > > > > > > > *configuration*
> >> > > > > > > > > > > > > datastores
> >> > > > > > > > > > > > > cannot
> >> > > > > > > > > > > > > contain
> >> > > > > > > > > > > > > YANG library (being state data), and so the MUST
> >> > > > > > > > > > > > > cannot
> >> > > > > > > > > > > > > hold.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > It is not clear to me how to repair this without
> >> > > > > > > > > > > > > considerable
> >> > > > > > > > > > > > > complications
> >> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one
> >> > > > > > > > > > > > > good
> >> > > > > > > > > > > > > solution
> >> > > > > > > > > > > > > but it
> >> > > > > > > > > > > > > has
> >> > > > > > > > > > > > > impact on YANG library: the server could provide it
> >> > > > > > > > > > > > > in
> >> > > > > > > > > > > > > a
> >> > > > > > > > > > > > > reply
> >> > > > > > > > > > > > > to
> >> > > > > > > > > > > > > an
> >> > > > > > > > > > > > > operation,
> >> > > > > > > > > > > > > say "get-yang-library" rather than as state
> >> > > > > > > > > > > > > data. Then
> >> > > > > > > > > > > > > everything
> >> > > > > > > > > > > > > would be
> >> > > > > > > > > > > > > fine
> >> > > > > > > > > > > > > - this operation would turn into an action for the
> >> > > > > > > > > > > > > mount
> >> > > > > > > > > > > > > point,
> >> > > > > > > > > > > > > and it
> >> > > > > > > > > > > > > can
> >> > > > > > > > > > > > > be
> >> > > > > > > > > > > > > used equally well for config true and false mount
> >> > > > > > > > > > > > > points.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > So my proposal is to move from YANG library as
> >> > > > > > > > > > > > > state
> >> > > > > > > > > > > > > data
> >> > > > > > > > > > > > > to
> >> > > > > > > > > > > > > an
> >> > > > > > > > > > > > > operation.
> >> > > > > > > > > > > > > It
> >> > > > > > > > > > > > > could be done along with changing the YANG library
> >> > > > > > > > > > > > > structure,
> >> > > > > > > > > > > > > so
> >> > > > > > > > > > > > > there
> >> > > > > > > > > > > > > will be
> >> > > > > > > > > > > > > little extra impact on implementations.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Lada
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > Ladislav Lhotka
> >> > > > > > > > > > > > > Head, CZ.NIC Labs
> >> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > _______________________________________________
> >> > > > > > > > > > > > > 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
> >> > > > > > > > > >
> >> > >
> >> > >
> >> >
> >> > --
> >> > Ladislav Lhotka
> >> > Head, CZ.NIC Labs
> >> > PGP Key ID: 0xB8F92B08A9F76C67
> >> >
> >>
> >>
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> 
> 


From nobody Tue Jan 16 05:31: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 D3056131543 for ; Tue, 16 Jan 2018 05:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 Sul9sx5j0X-D for ; Tue, 16 Jan 2018 05:31:31 -0800 (PST)
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 1B64312FB28 for ; Tue, 16 Jan 2018 05:29:27 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id C1030175FF7 for ; Tue, 16 Jan 2018 06:29:26 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id z1VP1w00X2SSUrH011VSBn; Tue, 16 Jan 2018 06:29:26 -0700
X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=RgaUWeydRksA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=cy_EonuG9ftVD075yNYA:9 a=CjuIK1q_8ugA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/5xVYHGHCFT6tiYkZD9HTb/+5w/RsyYr1CZqhoGWAzY=; b=fqMxkXelkG6dWFMxtDYO2OSefz xjQNFkQG1Ovj0j08tfJrZu3oMr02UGYhtgQqOWDhYmM5m7wR45epsnajk+awUQMXAvt9oCr4JDnIT yD//0gVIWMTTSal6AVhmhpDV3;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44743 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebRIp-003TTr-Ex; Tue, 16 Jan 2018 06:29:23 -0700
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Tue, 16 Jan 2018 08:29:21 -0500
Message-ID: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20180116.142407.1498790690296330642.mbj@tail-f.com>
References: <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516104404.11372.15.camel@nic.cz> <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.142407.1498790690296330642.mbj@tail-f.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
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-Exim-ID: 1ebRIp-003TTr-Ex
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:44743
X-Source-Auth: lberger@labn.net
X-Email-Count: 10
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 13:31:39 -0000

On January 16, 2018 8:24:42 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>> Lada,
>>
>>
>> On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:
>>
>> > On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
>> >> Lada,
>> >>
>> >> It sounds like you are proposing in (1) a fairly significant change in
>> >> the
>> >> direction of the draft and in (2) a basic approach that has been
>> >
>> > It is no change in direction, just a simplification of the
>> > schema-describing
>> > state data. Given the recent developments in 7895bis it makes no sense
>> > to me to
>> > have two "schema" lists if we can have just one.
>> >
>>
>> Managing transition is hard. It's also highlights why Yang Library
>> this needs to be at least equally discussed in this group.
>>
>> I will talk with my co-chairs and perhaps the ADs to get their opinion
>> on making such a change this point in the process.
>>
>>
>> >>
>> >> rejectected by the WG multiple times.  FWIW there are drafts already
>> >> with
>> >
>> > No at all. The first and last time I proposed this was on 15 December
>> > 2017:
>> >
>> > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>> >
>>
>> Oh, I certainly would call you proposing that the schema for inline be
>> part of the rest of the schema Mount module well before that. I'm sure
>> I can dig up mail / slides it really necessary...
>
> I don't think this has been proposed before.  All previous proposals
> were basically variants on what is now "use-schema", which works fine
> when all instances have the same schema.  This new proposal solves the
> issue with different schemas in different instances.
>

I thought the previous proposals that as well, so don't see material 
difference - at least from the usage standpoint. I also don't see why the 
previous arguments that resulted in consensus for using Yang Library 
underneath the an in line Mount Point don't apply.

Lou

>> > The only reply was from you. To me, it is the cleanest solution of the
>> > inline
>> > case. Of course, I am open to technical objections.
>> >
>>
>> I'm sure I can find material on this as well....
>
> Ok.
>
>
> /martin
>
>
>>
>> Lou
>>
>> > If it's not clear what I mean, I can make up some examples.
>> >
>> > Lada
>> >
>> >
>> >> the iesg that will need to be returned to their WGs if either change
>> >> is made.
>> >>
>> >> Martin,
>> >>
>> >> Do share Lada's view?
>> >>
>> >> Lou
>> >>
>> >>
>> >> On January 16, 2018 2:14:42 AM Ladislav Lhotka  wrote:
>> >>
>> >> > Hi Lou,
>> >> >
>> >> > in my view, we should do the following two (significant) changes:
>> >> >
>> >> > 1. Instead of borrowing a grouping from ietf-yang-library and having a
>> >> > parallel
>> >> > list of mounted schemas, we should keep *all* mounted schemas directly
>> >> > in
>> >> > the
>> >> > YANG library and refer to them from schema-mounts structures. Juergen
>> >> > suggested
>> >> > this change and it is IMO the right thing to do.
>> >> >
>> >> > 2. Define a metadata annotation (e.g. @schema-ref) that would be
>> >> > required
>> >> > for
>> >> > inline mount point instances and specify the inline-mounted schema
>> >> > also by
>> >> > referring to a schema specified in YANG library.
>> >> >
>> >> > The advantage of #2 is that an annotation can be attached equally well
>> >> > to
>> >> > both
>> >> > state an configuration data. So, instead of papering over the issue
>> >> > that
>> >> > YANG
>> >> > library (state data) cannot appear in configuration datastores, we can
>> >> > use
>> >> > this
>> >> > general and straightforward approach. This also allows for defining
>> >> > different
>> >> > mounted schemas for instances of the same mount point in different
>> >> > datastores.
>> >> >
>> >> > I strongly believe that these changes (along with the new YANG library
>> >> > schema
>> >> > and NMDA) make for a simple and elegant datastore architecture in
>> >> > which
>> >> > schema
>> >> > mount would be an optional feature.
>> >> >
>> >> > Lada
>> >> >
>> >> >
>> >> >
>> >> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> >> > > Lada/Martin,
>> >> > >
>> >> > > I don't believe we reached closure on this discussion.  The open
>> >> > > issues
>> >> > > relate to proposed new text (slightly modified):
>> >> > >
>> >> > > at the end of the section [3.2] adding a new paragraph along the
>> >> > > lines of:
>> >> > >
>> >> > >    The use of mount points does not impact the nature of the
>> >> > >    mounted data or in which data store information is made
>> >> > >    available. For example, mounted YANG Library modules define
>> >> > >    only operational state data and, as such, the information in
>> >> > >    these modules is available from operational data stores using
>> >> > >    the appropriate protocol operations.  It is also worth
>> >> > >    noting that the Schema Mount module itself parallels the
>> >> > >    YANG Library module and only defines operational state data.
>> >> > >
>> >> > > Is this change acceptable?
>> >> > >
>> >> > > What other issues related to SM are outstanding?
>> >> > >
>> >> > > Thank you,
>> >> > >
>> >> > > Lou
>> >> > >
>> >> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>> >> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> >> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>> >> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>> >> > > > > > > Hi Lada,
>> >> > > > > > >
>> >> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>> >> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>> >> > > > > > > > > Lada,
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka
>> >> > > > > > > > > > >> > > > > > > > > >
>> >> > > > > > > > > wrote:
>> >> > > > > > > > >
>> >> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>> >> > > > > > > > > > > lada,
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >      See below.
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>> >> > > > > > > > > > > > Hi,
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > unfortunately, using an action for querying embedded
>> >> > > > > > > > > > > > YANG
>> >> > > > > > > > > > > > library
>> >> > > > > > > > > > > > data
>> >> > > > > > > > > > > > (needed for the "inline" case of schema mount)
>> >> > > > > > > > > > > > doesn't
>> >> > > > > > > > > > > > work
>> >> > > > > > > > > > > > either
>> >> > > > > > > > > > > > because now under NMDA actions can be used only on
>> >> > > > > > > > > > > > instances
>> >> > > > > > > > > > > > in
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > >  datastore.
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > but the inline/embedded library would (only) be present
>> >> > > > > > > > > > > in
>> >> > > > > > > > > > > the
>> >> > > > > > > > > > > in
>> >> > > > > > > > > > > the
>> >> > > > > > > > > > > operational datastore, so what's the issue?
>> >> > > > > > > > > >
>> >> > > > > > > > > > Well, the issue is described in my initial mail of this
>> >> > > > > > > > > > thread:
>> >> > > > > > > > > > the
>> >> > > > > > > > > > current
>> >> > > > > > > > > > text
>> >> > > > > > > > > > requires that every instance of an inline mount point
>> >> > > > > > > > > > contains
>> >> > > > > > > > > > the
>> >> > > > > > > > > > embedded
>> >> > > > > > > > > > YANG library. Tha latter is state data, so the above
>> >> > > > > > > > > > requirement
>> >> > > > > > > > > > cannot
>> >> > > > > > > > > > be
>> >> > > > > > > > > > satisfied if the mount point instance is in a
>> >> > > > > > > > > > configuration
>> >> > > > > > > > > > datastore.
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > That's not how I read the intent of the current text.  I
>> >> > > > > > > > > don't
>> >> > > > > > > > > see
>> >> > > > > > > > > SM
>> >> > > > > > > > > impacting which data stores information is presented.  Just
>> >> > > > > > > > > like
>> >> > > > > > > > > use
>> >> > > > > > > > > of
>> >> > > > > > > > > scheme mount doesn't transform RO configuration information
>> >> > > > > > > > > into
>> >> > > > > > > > > operational information.  I sent you a couple of sentences
>> >> > > > > > > > > clarifying
>> >> > > > > > > > > this
>> >> > > > > > > > > at one point, I'll dig up the proposed text and resend.
>> >> > > > > > > >
>> >> > > > > > > > Please do, this has to be discussed in the WG mailing list.
>> >> > > > > > >
>> >> > > > > > > Agreed - that's why I asked to start this thread!
>> >> > > > > > >
>> >> > > > > > > Here's the original proposal:
>> >> > > > > > >
>> >> > > > > > >    How about at the end of the section [3.2] adding a new
>> >> > > > > > >    paragraph along the lines of:
>> >> > > > > > >
>> >> > > > > > >    It is important to note that both YANG Library and Schema
>> >> > > > > > >    Mount Modules contain only operational state data. As such,
>> >> > > > > >
>> >> > > > > > s/contain/define/
>> >> > > > > >
>> >> > > > > > >    the information in these modules should be retrieved by
>> >> > > > > > >    clients from operational data stores using the appropriate
>> >> > > > > >
>> >> > > > > > This is based on two assumptions:
>> >> > > > > >
>> >> > > > > > 1. For every configuration datastore there is a corresponding
>> >> > > > > > operational
>> >> > > > > > datastore.
>> >> > > > >
>> >> > > > > well the text is revised below.  In any case, "these modules"
>> >> > > > > refers
>> >> > > > > to
>> >> > > > > yang library, and yes, I'm assuming YL is always and only in
>> >> > > > > operational.  If the revised text below isn't clear s/these/YANG
>> >> > > > > Library/
>> >> > > > > -
>> >> > > >
>> >> > > > The thing is that we have the top-level YANG library in
>> >> > > > ,
>> >> > > > and
>> >> > > > then
>> >> > > > embedded YANG libraries scattered inside inline mount point
>> >> > > > instances.
>> >> > > >
>> >> > > > > > 2. For every mount point instance in any configuration datastore
>> >> > > > > > there
>> >> > > > > > is a
>> >> > > > > > corresponding mount point instance (with the same path) in an
>> >> > > > > > operational
>> >> > > > > > datastore.
>> >> > > > > >
>> >> > > > > > I think that neither of these has to be true in general.
>> >> > > > >
>> >> > > > > agreed in general, but for inline, where YL is required, it must be
>> >> > > > > true.
>> >> > > >
>> >> > > > How do you know? I provided an example in Singapore where a mount
>> >> > > > point
>> >> > > > instance
>> >> > > > in  is a part of pre-provisioned data (for non-existent
>> >> > > > hardware).
>> >> > > > Then, according to the NMDA rules there is no corresponding instance
>> >> > > > in
>> >> > > > , hence no place where the embedded YANG library can be
>> >> > > > placed.
>> >> > > > (I can easily provide a concrete example if needed).
>> >> > > >
>> >> > > >
>> >> > > > Dean replied that this cannot happen, so it seems there are some
>> >> > > > assumptions
>> >> > > > how
>> >> > > > the inline method of schema mount may be applied. If so, these
>> >> > > > assumptions
>> >> > > > have
>> >> > > > to be explicitly stated.
>> >> > > >
>> >> > > > > > >    protocol operations.
>> >> > > > > >
>> >> > > > > > In contrast, the substance of my proposal with metadata
>> >> > > > > > annotations
>> >> > > > > > is
>> >> > > > > > to be
>> >> > > > > > able to retrieve all schemas from a well-known location in *the*
>> >> > > > > > 
>> >> > > > > > datastore, namely from the top-level YANG library.
>> >> > > > >
>> >> > > > > What about a schema that is based on dll that contains modules that
>> >> > > > > isn't loaded until a mount point is instantiated -- this is
>> >> > > > > certainly
>> >> > > > > a
>> >> > > > > valid approach for supporting LNEs, but would be precluded in this
>> >> > > > > approach.  I really don't think a top level approach works for all
>> >> > > > > inline (managed) types of mounts.
>> >> > > >
>> >> > > > It isn't precluded: when the mount point is instantiated (no matter
>> >> > > > which
>> >> > > > datastore it is in), the server adds the schema as a new entry to the
>> >> > > > "schema"
>> >> > > > list in the top level YANG library (with a unique key), and annotates
>> >> > > > the
>> >> > > > mount
>> >> > > > point instance with a leafref pointing to that key. So different
>> >> > > > instances
>> >> > > > of
>> >> > > > the same mount point can have different schemas.
>> >> > > >
>> >> > > > > > > Given this discussion, we can generalize it further to:
>> >> > > > > > >
>> >> > > > > > >    The use of mount points does not impact the nature of the
>> >> > > > > > >    mounted data or in which data store information is made
>> >> > > > > > >    available. For example, mounted YANG Library modules contain
>> >> > > > > > >    only operational state data and, as such, the information in
>> >> > > > > > >    these modules is available from operational data stores
>> >> > > > > > >    using
>> >> > > > > > >    the appropriate protocol operations.
>> >> > > > > >
>> >> > > > > > The whole question here is whether and how we can locate the
>> >> > > > > > schema
>> >> > > > > > for
>> >> > > > > > an
>> >> > > > > > inline mount point in any configuration datastore.
>> >> > > > >
>> >> > > > > Why is a mounted YL different than a top level YL?  What works for
>> >> > > > > and
>> >> > > >
>> >> > > > It is not different, but it can be only in an operational datastores,
>> >> > > > and so
>> >> > > > for
>> >> > > > mount point instances inside configuration datastores we need a way
>> >> > > > how
>> >> > > > to
>> >> > > > locate the schema for that mount point, because it cannot be found
>> >> > > > directly
>> >> > > > under the mount point instance (as the current text assumes).
>> >> > > >
>> >> > > > > is sufficient for the normal case of YL shouldn't be impacted or
>> >> > > > > modified by SM -- at least that's how I thought we've been talking
>> >> > > > > about
>> >> > > > > since SM was started.  Again, we never made any special provisions
>> >> > > > > for
>> >> > > > > any other rw/ro/state data, assuming top level YL is not handled as
>> >> > > > > metadata, why start now?
>> >> > > > >
>> >> > > > > I'm getting the impression that your argument may be more about if
>> >> > > > > YL
>> >> > > > > should be treated as something other than operational data, is this
>> >> > > > > wrong?
>> >> > > >
>> >> > > > This is wrong. My argument is that there should be only one top-level
>> >> > > > YANG
>> >> > > > library (state data) and each inline mount point instance just points
>> >> > > > to
>> >> > > > a
>> >> > > > schema inside it by means of a metadata annotation attached to the
>> >> > > > mount
>> >> > > > point
>> >> > > > (in any datastore).
>> >> > > >
>> >> > > > Lada
>> >> > > >
>> >> > > > > Thanks,
>> >> > > > > Lou
>> >> > > > >
>> >> > > > > > Lada
>> >> > > > > >
>> >> > > > > > > Lou
>> >> > > > > > >
>> >> > > > > > > > Lada
>> >> > > > > > > >
>> >> > > > > > > > > Lou
>> >> > > > > > > > > > > > However, a good alternative seems to be a metadata
>> >> > > > > > > > > > > > annotation
>> >> > > > > > > > > > > > along
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B
>> >> > > > > > > > > > > > of
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > newly
>> >> > > > > > > > > > > > proposed YANG library schema:
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > >       md:annotation schema-ref {
>> >> > > > > > > > > > > >         type leafref {
>> >> > > > > > > > > > > >           path "/yanglib:yang-
>> >> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
>> >> > > > > > > > > > > >         }
>> >> > > > > > > > > > > >       }
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > In other words, all inline mounted schemas would be
>> >> > > > > > > > > > > > included
>> >> > > > > > > > > > > > in
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > top-level YANG library, and mount point instances in
>> >> > > > > > > > > > > > all
>> >> > > > > > > > > > > > datastores
>> >> > > > > > > > > > > > would be annotated with leafref pointing to the
>> >> > > > > > > > > > > > actual
>> >> > > > > > > > > > > > schema.
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
>> >> > > > > > > > > > > > permit
>> >> > > > > > > > > > > > such
>> >> > > > > > > > > > > > annotations in configuration datastores.
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Opinions?
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > I'm not sure this will work for all architectures of
>> >> > > > > > > > > > > LNEs
>> >> > > > > > > > > > > as
>> >> > > > > > > > > > > well
>> >> > > > > > > > > > > as
>> >> > > > > > > > > > > other possible future use cases.  In short, this seems
>> >> > > > > > > > > > > *very*
>> >> > > > > > > > > > > restrictive.
>> >> > > > > > > > > >
>> >> > > > > > > > > > I don't understand, IMO it is not restrictive at
>> >> > > > > > > > > > all. What
>> >> > > > > > > > > > kind
>> >> > > > > > > > > > of
>> >> > > > > > > > > > restrictions
>> >> > > > > > > > > > do you see?
>> >> > > > > > > > > >
>> >> > > > > > > > > > Lada
>> >> > > > > > > > > >
>> >> > > > > > > > > > > Lou
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > > Thanks, Lada
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Ladislav Lhotka  writes:
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > > Hi,
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08
>> >> > > > > > > > > > > > > is
>> >> > > > > > > > > > > > > wrong
>> >> > > > > > > > > > > > > for
>> >> > > > > > > > > > > > > traditional
>> >> > > > > > > > > > > > > datastores, and even more so for NDMA:
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
>> >> > > > > > > > > > > > > determined
>> >> > > > > > > > > > > > > at
>> >> > > > > > > > > > > > > run
>> >> > > > > > > > > > > > > time:
>> >> > > > > > > > > > > > > every
>> >> > > > > > > > > > > > >     instance of the mount point that exists in the
>> >> > > > > > > > > > > > > parent
>> >> > > > > > > > > > > > > tree
>> >> > > > > > > > > > > > > MUST
>> >> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895]
>> >> > > > > > > > > > > > >     that
>> >> > > > > > > > > > > > > defines
>> >> > > > > > > > > > > > > the
>> >> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
>> >> > > > > > > > > > > > > model.  A
>> >> > > > > > > > > > > > > client
>> >> > > > > > > > > > > > > is
>> >> > > > > > > > > > > > >     expected to retrieve this data from the
>> >> > > > > > > > > > > > >     instance
>> >> > > > > > > > > > > > > tree,
>> >> > > > > > > > > > > > > possibly
>> >> > > > > > > > > > > > > after
>> >> > > > > > > > > > > > >     creating the mount point.  Instances of the
>> >> > > > > > > > > > > > >     same
>> >> > > > > > > > > > > > > mount
>> >> > > > > > > > > > > > > point
>> >> > > > > > > > > > > > > MAY
>> >> > > > > > > > > > > > > use
>> >> > > > > > > > > > > > >     different mounted schemas.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > An instance of the mount point in any
>> >> > > > > > > > > > > > > *configuration*
>> >> > > > > > > > > > > > > datastores
>> >> > > > > > > > > > > > > cannot
>> >> > > > > > > > > > > > > contain
>> >> > > > > > > > > > > > > YANG library (being state data), and so the MUST
>> >> > > > > > > > > > > > > cannot
>> >> > > > > > > > > > > > > hold.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > It is not clear to me how to repair this without
>> >> > > > > > > > > > > > > considerable
>> >> > > > > > > > > > > > > complications
>> >> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one
>> >> > > > > > > > > > > > > good
>> >> > > > > > > > > > > > > solution
>> >> > > > > > > > > > > > > but it
>> >> > > > > > > > > > > > > has
>> >> > > > > > > > > > > > > impact on YANG library: the server could provide it
>> >> > > > > > > > > > > > > in
>> >> > > > > > > > > > > > > a
>> >> > > > > > > > > > > > > reply
>> >> > > > > > > > > > > > > to
>> >> > > > > > > > > > > > > an
>> >> > > > > > > > > > > > > operation,
>> >> > > > > > > > > > > > > say "get-yang-library" rather than as state
>> >> > > > > > > > > > > > > data. Then
>> >> > > > > > > > > > > > > everything
>> >> > > > > > > > > > > > > would be
>> >> > > > > > > > > > > > > fine
>> >> > > > > > > > > > > > > - this operation would turn into an action for the
>> >> > > > > > > > > > > > > mount
>> >> > > > > > > > > > > > > point,
>> >> > > > > > > > > > > > > and it
>> >> > > > > > > > > > > > > can
>> >> > > > > > > > > > > > > be
>> >> > > > > > > > > > > > > used equally well for config true and false mount
>> >> > > > > > > > > > > > > points.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > So my proposal is to move from YANG library as
>> >> > > > > > > > > > > > > state
>> >> > > > > > > > > > > > > data
>> >> > > > > > > > > > > > > to
>> >> > > > > > > > > > > > > an
>> >> > > > > > > > > > > > > operation.
>> >> > > > > > > > > > > > > It
>> >> > > > > > > > > > > > > could be done along with changing the YANG library
>> >> > > > > > > > > > > > > structure,
>> >> > > > > > > > > > > > > so
>> >> > > > > > > > > > > > > there
>> >> > > > > > > > > > > > > will be
>> >> > > > > > > > > > > > > little extra impact on implementations.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > Lada
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > --
>> >> > > > > > > > > > > > > Ladislav Lhotka
>> >> > > > > > > > > > > > > Head, CZ.NIC Labs
>> >> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > _______________________________________________
>> >> > > > > > > > > > > > > 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
>> >> > > > > > > > > >
>> >> > >
>> >> > >
>> >> >
>> >> > --
>> >> > Ladislav Lhotka
>> >> > Head, CZ.NIC Labs
>> >> > PGP Key ID: 0xB8F92B08A9F76C67
>> >> >
>> >>
>> >>
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> >
>>
>>
>



From nobody Tue Jan 16 05:41: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 8F5DF12DA72 for ; Tue, 16 Jan 2018 05:41:02 -0800 (PST)
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_RP_MATCHES_RCVD=-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 K7qk0RbJAQ00 for ; Tue, 16 Jan 2018 05:41:00 -0800 (PST)
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 D4BB912DA41 for ; Tue, 16 Jan 2018 05:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17398; q=dns/txt; s=iport; t=1516110049; x=1517319649; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RuDQUNdUFBw5ZcNOQzHObNPsubjyVNGn+jglbndUysM=; b=LUhtEA2VYNK65GGq3WfSFoHzoSyuw/nFaLQdE/o0XlBu4pdj3Hi3stkQ WAI8hvafmXmpnymdgf/HPKN8TAbCwevBxbwr7EkoRsL03WHnCnd5N3/8+ /a/vj4nvrIvcEEH6WCRXiuMdcmF92BN5kyLHYO9VqD7KsUZ+6F4EPRI+d 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQCT/11a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj26XQIICChgLhElPAoUfFAEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEBAgEBASEPAQU2CxAJAg4EBgICJgICJyIOBgEMBgIBAReKEAgQh2+dcIIni?= =?us-ascii?q?UkBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhxmBaSmDBYMvAQECgTwBEQIBCEK?= =?us-ascii?q?Ca4JlBZInkT2LOIoTghmGHYNvJodFjxyICYE8NiJgcDIaCBsVPYIqhFdBN40/A?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200";  d="scan'208";a="1433971"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 13:40:46 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0GDekHR023880; Tue, 16 Jan 2018 13:40:46 GMT
To: Lou Berger , Ladislav Lhotka , Martin Bjorklund 
Cc: NETMOD WG 
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>  <91b3916b-ba51-b066-8600-83127d8f1e76@labn.net>
From: Robert Wilton 
Message-ID: <7ae6819c-3af6-e194-e83f-146a90ae8426@cisco.com>
Date: Tue, 16 Jan 2018 13:40:46 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <91b3916b-ba51-b066-8600-83127d8f1e76@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 13:41:03 -0000

On 16/01/2018 13:23, Lou Berger wrote:
> On 1/16/2018 7:41 AM, Robert Wilton wrote:
>>
>> On 16/01/2018 07:14, Ladislav Lhotka wrote:
>>> Hi Lou,
>>>
>>> in my view, we should do the following two (significant) changes:
>>>
>>> 1. Instead of borrowing a grouping from ietf-yang-library and having 
>>> a parallel
>>> list of mounted schemas, we should keep *all* mounted schemas 
>>> directly in the
>>> YANG library and refer to them from schema-mounts structures. 
>>> Juergen suggested
>>> this change and it is IMO the right thing to do.
>> I also support this approach.  I think that it easier for everyone if
>> schema are defined in one place.
>
> I think we have a question of what is workable vs what is optimal, 
> i.e., this proposal is arguably better for those supporting YL bis, 
> but the other isn't broken.   -- I have also raised this privately 
> with the chairs and ADs of the impacted groups (keep in mind that 
> RTGWG and BESS are already using the current definitions) to see if 
> they have opinions.
The NMDA solution to this problem is to publish both ...

E.g. either (i) publish SM now (so that folks can use) it but then 
immediately bis the draft, to cover YL-bis (probably keeping the 
existing library in the appendix).

Or (ii) put the current SM YANG library into the appendix (marked as 
deprecated) and include a new YL-bis compatible version in the body of 
the document.


>
>> This was also the suggested approach that I presented at IETF 100 for
>> the YANG library bis draft, which seemed to have reasonable support in
>> the room, and I don't recall anyone objecting to this approach.
>
> In the email discussion on the results of the December NetConf 
> interim, the sentiment was that YL bis shouldn't consider schema 
> mount.  As stated on the list, I personally (with all hats) think this 
> is a mistake and would likely feel differently if YL bis 
> covered/obsoleted schema mount.
I think that the conclusion was more nuanced that that:

YL-bis should not cover SM directly.  I.e. YL-bis should not contain SM 
specific nodes (even under a feature keyword).

However, there seems to good support for YL-bis being designed in an SM 
sympathetic way, such that SM can cleanly augment YL-bis and provide the 
required functionality without needing to a separate schema mount 
specific YANG library tree.

Thanks,
Rob


>
> Lou
>> I also provided the same comment in November during the WG LC on schema
>> mount ...
>>
>> Thanks,
>> Rob
>>
>>
>>> 2. Define a metadata annotation (e.g. @schema-ref) that would be 
>>> required for
>>> inline mount point instances and specify the inline-mounted schema 
>>> also by
>>> referring to a schema specified in YANG library.
>>>
>>> The advantage of #2 is that an annotation can be attached equally 
>>> well to both
>>> state an configuration data. So, instead of papering over the issue 
>>> that YANG
>>> library (state data) cannot appear in configuration datastores, we 
>>> can use this
>>> general and straightforward approach. This also allows for defining 
>>> different
>>> mounted schemas for instances of the same mount point in different 
>>> datastores.
>>>
>>> I strongly believe that these changes (along with the new YANG 
>>> library schema
>>> and NMDA) make for a simple and elegant datastore architecture in 
>>> which schema
>>> mount would be an optional feature.
>>>
>>> Lada
>>>
>>>
>>> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>>>> Lada/Martin,
>>>>
>>>> I don't believe we reached closure on this discussion.  The open 
>>>> issues
>>>> relate to proposed new text (slightly modified):
>>>>
>>>> at the end of the section [3.2] adding a new paragraph along the
>>>> lines of:
>>>>
>>>>      The use of mount points does not impact the nature of the
>>>>      mounted data or in which data store information is made
>>>>      available. For example, mounted YANG Library modules define
>>>>      only operational state data and, as such, the information in
>>>>      these modules is available from operational data stores using
>>>>      the appropriate protocol operations.  It is also worth
>>>>      noting that the Schema Mount module itself parallels the
>>>>      YANG Library module and only defines operational state data.
>>>>
>>>> Is this change acceptable?
>>>>
>>>> What other issues related to SM are outstanding?
>>>>
>>>> Thank you,
>>>>
>>>> Lou
>>>>
>>>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>>>> Hi Lada,
>>>>>>>>
>>>>>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>>>>>> Lada,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>>>>>> lada,
>>>>>>>>>>>>
>>>>>>>>>>>>        See below.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>>>>>> library
>>>>>>>>>>>>> data
>>>>>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>>>>>> either
>>>>>>>>>>>>> because now under NMDA actions can be used only on instances
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>  datastore.
>>>>>>>>>>>> but the inline/embedded library would (only) be present in the
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> operational datastore, so what's the issue?
>>>>>>>>>>> Well, the issue is described in my initial mail of this thread:
>>>>>>>>>>> the
>>>>>>>>>>> current
>>>>>>>>>>> text
>>>>>>>>>>> requires that every instance of an inline mount point contains
>>>>>>>>>>> the
>>>>>>>>>>> embedded
>>>>>>>>>>> YANG library. Tha latter is state data, so the above 
>>>>>>>>>>> requirement
>>>>>>>>>>> cannot
>>>>>>>>>>> be
>>>>>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>>>>>> datastore.
>>>>>>>>>>>
>>>>>>>>>> That's not how I read the intent of the current text.  I 
>>>>>>>>>> don't see
>>>>>>>>>> SM
>>>>>>>>>> impacting which data stores information is presented.  Just like
>>>>>>>>>> use
>>>>>>>>>> of
>>>>>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>>>>>> operational information.  I sent you a couple of sentences
>>>>>>>>>> clarifying
>>>>>>>>>> this
>>>>>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>>>>>> Please do, this has to be discussed in the WG mailing list.
>>>>>>>> Agreed - that's why I asked to start this thread!
>>>>>>>>
>>>>>>>> Here's the original proposal:
>>>>>>>>
>>>>>>>>      How about at the end of the section [3.2] adding a new
>>>>>>>>      paragraph along the lines of:
>>>>>>>>
>>>>>>>>      It is important to note that both YANG Library and Schema
>>>>>>>>      Mount Modules contain only operational state data. As such,
>>>>>>> s/contain/define/
>>>>>>>
>>>>>>>>      the information in these modules should be retrieved by
>>>>>>>>      clients from operational data stores using the appropriate
>>>>>>> This is based on two assumptions:
>>>>>>>
>>>>>>> 1. For every configuration datastore there is a corresponding
>>>>>>> operational
>>>>>>> datastore.
>>>>>> well the text is revised below.  In any case, "these modules" 
>>>>>> refers to
>>>>>> yang library, and yes, I'm assuming YL is always and only in
>>>>>> operational.  If the revised text below isn't clear s/these/YANG 
>>>>>> Library/
>>>>>> -
>>>>> The thing is that we have the top-level YANG library in 
>>>>> , and
>>>>> then
>>>>> embedded YANG libraries scattered inside inline mount point 
>>>>> instances.
>>>>>
>>>>>>> 2. For every mount point instance in any configuration datastore 
>>>>>>> there
>>>>>>> is a
>>>>>>> corresponding mount point instance (with the same path) in an
>>>>>>> operational
>>>>>>> datastore.
>>>>>>>
>>>>>>> I think that neither of these has to be true in general.
>>>>>> agreed in general, but for inline, where YL is required, it must 
>>>>>> be true.
>>>>> How do you know? I provided an example in Singapore where a mount 
>>>>> point
>>>>> instance
>>>>> in  is a part of pre-provisioned data (for non-existent 
>>>>> hardware).
>>>>> Then, according to the NMDA rules there is no corresponding 
>>>>> instance in
>>>>> , hence no place where the embedded YANG library can 
>>>>> be placed.
>>>>> (I can easily provide a concrete example if needed).
>>>>>
>>>>>
>>>>> Dean replied that this cannot happen, so it seems there are some 
>>>>> assumptions
>>>>> how
>>>>> the inline method of schema mount may be applied. If so, these 
>>>>> assumptions
>>>>> have
>>>>> to be explicitly stated.
>>>>>
>>>>>>>>      protocol operations.
>>>>>>> In contrast, the substance of my proposal with metadata 
>>>>>>> annotations is
>>>>>>> to be
>>>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>>>> 
>>>>>>> datastore, namely from the top-level YANG library.
>>>>>> What about a schema that is based on dll that contains modules that
>>>>>> isn't loaded until a mount point is instantiated -- this is 
>>>>>> certainly a
>>>>>> valid approach for supporting LNEs, but would be precluded in this
>>>>>> approach.  I really don't think a top level approach works for all
>>>>>> inline (managed) types of mounts.
>>>>> It isn't precluded: when the mount point is instantiated (no 
>>>>> matter which
>>>>> datastore it is in), the server adds the schema as a new entry to the
>>>>> "schema"
>>>>> list in the top level YANG library (with a unique key), and 
>>>>> annotates the
>>>>> mount
>>>>> point instance with a leafref pointing to that key. So different 
>>>>> instances
>>>>> of
>>>>> the same mount point can have different schemas.
>>>>>
>>>>>>>> Given this discussion, we can generalize it further to:
>>>>>>>>
>>>>>>>>      The use of mount points does not impact the nature of the
>>>>>>>>      mounted data or in which data store information is made
>>>>>>>>      available. For example, mounted YANG Library modules contain
>>>>>>>>      only operational state data and, as such, the information in
>>>>>>>>      these modules is available from operational data stores using
>>>>>>>>      the appropriate protocol operations.
>>>>>>> The whole question here is whether and how we can locate the 
>>>>>>> schema for
>>>>>>> an
>>>>>>> inline mount point in any configuration datastore.
>>>>>> Why is a mounted YL different than a top level YL?  What works 
>>>>>> for and
>>>>> It is not different, but it can be only in an operational 
>>>>> datastores, and so
>>>>> for
>>>>> mount point instances inside configuration datastores we need a 
>>>>> way how to
>>>>> locate the schema for that mount point, because it cannot be found 
>>>>> directly
>>>>> under the mount point instance (as the current text assumes).
>>>>>
>>>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>>>> modified by SM -- at least that's how I thought we've been 
>>>>>> talking about
>>>>>> since SM was started.  Again, we never made any special 
>>>>>> provisions for
>>>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>>>> metadata, why start now?
>>>>>>
>>>>>> I'm getting the impression that your argument may be more about 
>>>>>> if YL
>>>>>> should be treated as something other than operational data, is 
>>>>>> this wrong?
>>>>> This is wrong. My argument is that there should be only one 
>>>>> top-level YANG
>>>>> library (state data) and each inline mount point instance just 
>>>>> points to a
>>>>> schema inside it by means of a metadata annotation attached to the 
>>>>> mount
>>>>> point
>>>>> (in any datastore).
>>>>>
>>>>> Lada
>>>>>
>>>>>> Thanks,
>>>>>> Lou
>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>> Lada
>>>>>>>>>
>>>>>>>>>> Lou
>>>>>>>>>>>>> However, a good alternative seems to be a metadata
>>>>>>>>>>>>> annotation
>>>>>>>>>>>>> along
>>>>>>>>>>>>> the
>>>>>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>>>>>> newly
>>>>>>>>>>>>> proposed YANG library schema:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         md:annotation schema-ref {
>>>>>>>>>>>>>           type leafref {
>>>>>>>>>>>>>             path "/yanglib:yang-
>>>>>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>         }
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words, all inline mounted schemas would be included
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>>>>>> datastores
>>>>>>>>>>>>> would be annotated with leafref pointing to the actual
>>>>>>>>>>>>> schema.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unlike regular state data, it is IMO no problem to permit
>>>>>>>>>>>>> such
>>>>>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Opinions?
>>>>>>>>>>>> I'm not sure this will work for all architectures of LNEs as
>>>>>>>>>>>> well
>>>>>>>>>>>> as
>>>>>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>>>>>> restrictive.
>>>>>>>>>>> I don't understand, IMO it is not restrictive at all. What kind
>>>>>>>>>>> of
>>>>>>>>>>> restrictions
>>>>>>>>>>> do you see?
>>>>>>>>>>>
>>>>>>>>>>> Lada
>>>>>>>>>>>
>>>>>>>>>>>> Lou
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ladislav Lhotka  writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> traditional
>>>>>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       In case 1 ["inline"], the mounted schema is determined
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> run
>>>>>>>>>>>>>> time:
>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>       instance of the mount point that exists in the parent
>>>>>>>>>>>>>> tree
>>>>>>>>>>>>>> MUST
>>>>>>>>>>>>>>       contain a copy of YANG library data [RFC7895] that
>>>>>>>>>>>>>> defines
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>       mounted schema exactly as for a top-level data
>>>>>>>>>>>>>> model.  A
>>>>>>>>>>>>>> client
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>       expected to retrieve this data from the instance tree,
>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>       creating the mount point. Instances of the same mount
>>>>>>>>>>>>>> point
>>>>>>>>>>>>>> MAY
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>       different mounted schemas.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>>>>>> datastores
>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>> contain
>>>>>>>>>>>>>> YANG library (being state data), and so the MUST cannot
>>>>>>>>>>>>>> hold.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is not clear to me how to repair this without
>>>>>>>>>>>>>> considerable
>>>>>>>>>>>>>> complications
>>>>>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>> impact on YANG library: the server could provide it in a
>>>>>>>>>>>>>> reply
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> operation,
>>>>>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>>>>>> point,
>>>>>>>>>>>>>> and it
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So my proposal is to move from YANG library as state data
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> operation.
>>>>>>>>>>>>>> It
>>>>>>>>>>>>>> could be done along with changing the YANG library
>>>>>>>>>>>>>> structure,
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lada
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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 Jan 16 05:42: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 9711212D873 for ; Tue, 16 Jan 2018 05:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 FafAX_plCQgk for ; Tue, 16 Jan 2018 05:41:58 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 ABCA61276AF for ; Tue, 16 Jan 2018 05:41:53 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 4447E1E1D69 for ; Tue, 16 Jan 2018 06:23:33 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id z1PW1w0082SSUrH011PZQy; Tue, 16 Jan 2018 06:23:33 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=8IRrpNYRkOprUy1_46wA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sq+i8LGdSUKBEUNWPZ34LBljRg1P1SVnc7HEha7OoSI=; b=Y5822X7Gk+2InIKbvC3ch0j64c egp5p+MnzU3j/I70ZbutWLJYfkJSM87zbmTeIy9+hR5QTkL2eDWvhFx9OWgBVrVfiFRPcK0wtZf+G TOvxRHt+IFEhbvcJMVGio4iis;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39172 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebRD7-003Rj7-Tw; Tue, 16 Jan 2018 06:23:30 -0700
To: Robert Wilton , Ladislav Lhotka , Martin Bjorklund 
Cc: NETMOD WG 
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz> 
From: Lou Berger 
Message-ID: <91b3916b-ba51-b066-8600-83127d8f1e76@labn.net>
Date: Tue, 16 Jan 2018 08:23:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
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-Exim-ID: 1ebRD7-003Rj7-Tw
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]:39172
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 13:42:03 -0000

On 1/16/2018 7:41 AM, Robert Wilton wrote:
>
> On 16/01/2018 07:14, Ladislav Lhotka wrote:
>> Hi Lou,
>>
>> in my view, we should do the following two (significant) changes:
>>
>> 1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
>> list of mounted schemas, we should keep *all* mounted schemas directly in the
>> YANG library and refer to them from schema-mounts structures. Juergen suggested
>> this change and it is IMO the right thing to do.
> I also support this approach.  I think that it easier for everyone if
> schema are defined in one place.

I think we have a question of what is workable vs what is optimal, i.e., 
this proposal is arguably better for those supporting YL bis, but the 
other isn't broken.   -- I have also raised this privately with the 
chairs and ADs of the impacted groups (keep in mind that RTGWG and BESS 
are already using the current definitions) to see if they have opinions.

> This was also the suggested approach that I presented at IETF 100 for
> the YANG library bis draft, which seemed to have reasonable support in
> the room, and I don't recall anyone objecting to this approach.

In the email discussion on the results of the December NetConf interim, 
the sentiment was that YL bis shouldn't consider schema mount.  As 
stated on the list, I personally (with all hats) think this is a mistake 
and would likely feel differently if YL bis covered/obsoleted schema mount.

Lou
> I also provided the same comment in November during the WG LC on schema
> mount ...
>
> Thanks,
> Rob
>
>
>> 2. Define a metadata annotation (e.g. @schema-ref) that would be required for
>> inline mount point instances and specify the inline-mounted schema also by
>> referring to a schema specified in YANG library.
>>
>> The advantage of #2 is that an annotation can be attached equally well to both
>> state an configuration data. So, instead of papering over the issue that YANG
>> library (state data) cannot appear in configuration datastores, we can use this
>> general and straightforward approach. This also allows for defining different
>> mounted schemas for instances of the same mount point in different datastores.
>>
>> I strongly believe that these changes (along with the new YANG library schema
>> and NMDA) make for a simple and elegant datastore architecture in which schema
>> mount would be an optional feature.
>>
>> Lada
>>
>>    
>>
>> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>>> Lada/Martin,
>>>
>>> I don't believe we reached closure on this discussion.  The open issues
>>> relate to proposed new text (slightly modified):
>>>
>>> at the end of the section [3.2] adding a new paragraph along the
>>> lines of:
>>>
>>>      The use of mount points does not impact the nature of the
>>>      mounted data or in which data store information is made
>>>      available. For example, mounted YANG Library modules define
>>>      only operational state data and, as such, the information in
>>>      these modules is available from operational data stores using
>>>      the appropriate protocol operations.  It is also worth
>>>      noting that the Schema Mount module itself parallels the
>>>      YANG Library module and only defines operational state data.
>>>
>>> Is this change acceptable?
>>>
>>> What other issues related to SM are outstanding?
>>>
>>> Thank you,
>>>
>>> Lou
>>>
>>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>>> Hi Lada,
>>>>>>>
>>>>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>>>>> Lada,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>>>>> lada,
>>>>>>>>>>>
>>>>>>>>>>>        See below.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>>>>> library
>>>>>>>>>>>> data
>>>>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>>>>> either
>>>>>>>>>>>> because now under NMDA actions can be used only on instances
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>  datastore.
>>>>>>>>>>> but the inline/embedded library would (only) be present in the
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> operational datastore, so what's the issue?
>>>>>>>>>> Well, the issue is described in my initial mail of this thread:
>>>>>>>>>> the
>>>>>>>>>> current
>>>>>>>>>> text
>>>>>>>>>> requires that every instance of an inline mount point contains
>>>>>>>>>> the
>>>>>>>>>> embedded
>>>>>>>>>> YANG library. Tha latter is state data, so the above requirement
>>>>>>>>>> cannot
>>>>>>>>>> be
>>>>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>>>>> datastore.
>>>>>>>>>>
>>>>>>>>> That's not how I read the intent of the current text.  I don't see
>>>>>>>>> SM
>>>>>>>>> impacting which data stores information is presented.  Just like
>>>>>>>>> use
>>>>>>>>> of
>>>>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>>>>> operational information.  I sent you a couple of sentences
>>>>>>>>> clarifying
>>>>>>>>> this
>>>>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>>>>> Please do, this has to be discussed in the WG mailing list.
>>>>>>> Agreed - that's why I asked to start this thread!
>>>>>>>
>>>>>>> Here's the original proposal:
>>>>>>>
>>>>>>>      How about at the end of the section [3.2] adding a new
>>>>>>>      paragraph along the lines of:
>>>>>>>
>>>>>>>      It is important to note that both YANG Library and Schema
>>>>>>>      Mount Modules contain only operational state data. As such,
>>>>>> s/contain/define/
>>>>>>
>>>>>>>      the information in these modules should be retrieved by
>>>>>>>      clients from operational data stores using the appropriate
>>>>>> This is based on two assumptions:
>>>>>>
>>>>>> 1. For every configuration datastore there is a corresponding
>>>>>> operational
>>>>>> datastore.
>>>>> well the text is revised below.  In any case, "these modules" refers to
>>>>> yang library, and yes, I'm assuming YL is always and only in
>>>>> operational.  If the revised text below isn't clear s/these/YANG Library/
>>>>> -
>>>> The thing is that we have the top-level YANG library in , and
>>>> then
>>>> embedded YANG libraries scattered inside inline mount point instances.
>>>>
>>>>>> 2. For every mount point instance in any configuration datastore there
>>>>>> is a
>>>>>> corresponding mount point instance (with the same path) in an
>>>>>> operational
>>>>>> datastore.
>>>>>>
>>>>>> I think that neither of these has to be true in general.
>>>>> agreed in general, but for inline, where YL is required, it must be true.
>>>> How do you know? I provided an example in Singapore where a mount point
>>>> instance
>>>> in  is a part of pre-provisioned data (for non-existent hardware).
>>>> Then, according to the NMDA rules there is no corresponding instance in
>>>> , hence no place where the embedded YANG library can be placed.
>>>> (I can easily provide a concrete example if needed).
>>>>
>>>>
>>>> Dean replied that this cannot happen, so it seems there are some assumptions
>>>> how
>>>> the inline method of schema mount may be applied. If so, these assumptions
>>>> have
>>>> to be explicitly stated.
>>>>
>>>>>>>      protocol operations.
>>>>>> In contrast, the substance of my proposal with metadata annotations is
>>>>>> to be
>>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>>> 
>>>>>> datastore, namely from the top-level YANG library.
>>>>> What about a schema that is based on dll that contains modules that
>>>>> isn't loaded until a mount point is instantiated -- this is certainly a
>>>>> valid approach for supporting LNEs, but would be precluded in this
>>>>> approach.  I really don't think a top level approach works for all
>>>>> inline (managed) types of mounts.
>>>> It isn't precluded: when the mount point is instantiated (no matter which
>>>> datastore it is in), the server adds the schema as a new entry to the
>>>> "schema"
>>>> list in the top level YANG library (with a unique key), and annotates the
>>>> mount
>>>> point instance with a leafref pointing to that key. So different instances
>>>> of
>>>> the same mount point can have different schemas.
>>>>
>>>>>>> Given this discussion, we can generalize it further to:
>>>>>>>
>>>>>>>      The use of mount points does not impact the nature of the
>>>>>>>      mounted data or in which data store information is made
>>>>>>>      available. For example, mounted YANG Library modules contain
>>>>>>>      only operational state data and, as such, the information in
>>>>>>>      these modules is available from operational data stores using
>>>>>>>      the appropriate protocol operations.
>>>>>> The whole question here is whether and how we can locate the schema for
>>>>>> an
>>>>>> inline mount point in any configuration datastore.
>>>>> Why is a mounted YL different than a top level YL?  What works for and
>>>> It is not different, but it can be only in an operational datastores, and so
>>>> for
>>>> mount point instances inside configuration datastores we need a way how to
>>>> locate the schema for that mount point, because it cannot be found directly
>>>> under the mount point instance (as the current text assumes).
>>>>
>>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>>> modified by SM -- at least that's how I thought we've been talking about
>>>>> since SM was started.  Again, we never made any special provisions for
>>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>>> metadata, why start now?
>>>>>
>>>>> I'm getting the impression that your argument may be more about if YL
>>>>> should be treated as something other than operational data, is this wrong?
>>>> This is wrong. My argument is that there should be only one top-level YANG
>>>> library (state data) and each inline mount point instance just points to a
>>>> schema inside it by means of a metadata annotation attached to the mount
>>>> point
>>>> (in any datastore).
>>>>
>>>> Lada
>>>>
>>>>> Thanks,
>>>>> Lou
>>>>>
>>>>>> Lada
>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>>> Lada
>>>>>>>>
>>>>>>>>> Lou
>>>>>>>>>>>> However, a good alternative seems to be a metadata
>>>>>>>>>>>> annotation
>>>>>>>>>>>> along
>>>>>>>>>>>> the
>>>>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>>>>> newly
>>>>>>>>>>>> proposed YANG library schema:
>>>>>>>>>>>>
>>>>>>>>>>>>         md:annotation schema-ref {
>>>>>>>>>>>>           type leafref {
>>>>>>>>>>>>             path "/yanglib:yang-
>>>>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>>>>           }
>>>>>>>>>>>>         }
>>>>>>>>>>>>
>>>>>>>>>>>> In other words, all inline mounted schemas would be included
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>>>>> datastores
>>>>>>>>>>>> would be annotated with leafref pointing to the actual
>>>>>>>>>>>> schema.
>>>>>>>>>>>>
>>>>>>>>>>>> Unlike regular state data, it is IMO no problem to permit
>>>>>>>>>>>> such
>>>>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>>>>
>>>>>>>>>>>> Opinions?
>>>>>>>>>>> I'm not sure this will work for all architectures of LNEs as
>>>>>>>>>>> well
>>>>>>>>>>> as
>>>>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>>>>> restrictive.
>>>>>>>>>> I don't understand, IMO it is not restrictive at all. What kind
>>>>>>>>>> of
>>>>>>>>>> restrictions
>>>>>>>>>> do you see?
>>>>>>>>>>
>>>>>>>>>> Lada
>>>>>>>>>>
>>>>>>>>>>> Lou
>>>>>>>>>>>
>>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>>
>>>>>>>>>>>> Ladislav Lhotka  writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong
>>>>>>>>>>>>> for
>>>>>>>>>>>>> traditional
>>>>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>>>>
>>>>>>>>>>>>>       In case 1 ["inline"], the mounted schema is determined
>>>>>>>>>>>>> at
>>>>>>>>>>>>> run
>>>>>>>>>>>>> time:
>>>>>>>>>>>>> every
>>>>>>>>>>>>>       instance of the mount point that exists in the parent
>>>>>>>>>>>>> tree
>>>>>>>>>>>>> MUST
>>>>>>>>>>>>>       contain a copy of YANG library data [RFC7895] that
>>>>>>>>>>>>> defines
>>>>>>>>>>>>> the
>>>>>>>>>>>>>       mounted schema exactly as for a top-level data
>>>>>>>>>>>>> model.  A
>>>>>>>>>>>>> client
>>>>>>>>>>>>> is
>>>>>>>>>>>>>       expected to retrieve this data from the instance tree,
>>>>>>>>>>>>> possibly
>>>>>>>>>>>>> after
>>>>>>>>>>>>>       creating the mount point.  Instances of the same mount
>>>>>>>>>>>>> point
>>>>>>>>>>>>> MAY
>>>>>>>>>>>>> use
>>>>>>>>>>>>>       different mounted schemas.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>>>>> datastores
>>>>>>>>>>>>> cannot
>>>>>>>>>>>>> contain
>>>>>>>>>>>>> YANG library (being state data), and so the MUST cannot
>>>>>>>>>>>>> hold.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is not clear to me how to repair this without
>>>>>>>>>>>>> considerable
>>>>>>>>>>>>> complications
>>>>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>>>>> solution
>>>>>>>>>>>>> but it
>>>>>>>>>>>>> has
>>>>>>>>>>>>> impact on YANG library: the server could provide it in a
>>>>>>>>>>>>> reply
>>>>>>>>>>>>> to
>>>>>>>>>>>>> an
>>>>>>>>>>>>> operation,
>>>>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>>>>> everything
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> fine
>>>>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>>>>> point,
>>>>>>>>>>>>> and it
>>>>>>>>>>>>> can
>>>>>>>>>>>>> be
>>>>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So my proposal is to move from YANG library as state data
>>>>>>>>>>>>> to
>>>>>>>>>>>>> an
>>>>>>>>>>>>> operation.
>>>>>>>>>>>>> It
>>>>>>>>>>>>> could be done along with changing the YANG library
>>>>>>>>>>>>> structure,
>>>>>>>>>>>>> so
>>>>>>>>>>>>> there
>>>>>>>>>>>>> will be
>>>>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lada
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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 Jan 16 05:50:16 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 D4E461314E0 for ; Tue, 16 Jan 2018 05:50:07 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2nmINvRaBRWh for ; Tue, 16 Jan 2018 05:50:04 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4EC1314D4 for ; Tue, 16 Jan 2018 05:50:04 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 915CA1AE0399; Tue, 16 Jan 2018 14:50:03 +0100 (CET)
Date: Tue, 16 Jan 2018 14:50:03 +0100 (CET)
Message-Id: <20180116.145003.1110791592584714461.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.142407.1498790690296330642.mbj@tail-f.com> <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 13:50:08 -0000

Lou Berger  wrote:
> 
> 
> On January 16, 2018 8:24:42 AM Martin Bjorklund 
> wrote:
> 
> > Lou Berger  wrote:
> >> Lada,
> >>
> >>
> >> On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:
> >>
> >> > On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> >> >> Lada,
> >> >>
> >> >> It sounds like you are proposing in (1) a fairly significant change in
> >> >> the
> >> >> direction of the draft and in (2) a basic approach that has been
> >> >
> >> > It is no change in direction, just a simplification of the
> >> > schema-describing
> >> > state data. Given the recent developments in 7895bis it makes no sense
> >> > to me to
> >> > have two "schema" lists if we can have just one.
> >> >
> >>
> >> Managing transition is hard. It's also highlights why Yang Library
> >> this needs to be at least equally discussed in this group.
> >>
> >> I will talk with my co-chairs and perhaps the ADs to get their opinion
> >> on making such a change this point in the process.
> >>
> >>
> >> >>
> >> >> rejectected by the WG multiple times.  FWIW there are drafts already
> >> >> with
> >> >
> >> > No at all. The first and last time I proposed this was on 15 December
> >> > 2017:
> >> >
> >> > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> >> >
> >>
> >> Oh, I certainly would call you proposing that the schema for inline be
> >> part of the rest of the schema Mount module well before that. I'm sure
> >> I can dig up mail / slides it really necessary...
> >
> > I don't think this has been proposed before.  All previous proposals
> > were basically variants on what is now "use-schema", which works fine
> > when all instances have the same schema.  This new proposal solves the
> > issue with different schemas in different instances.
> >
> 
> I thought the previous proposals that as well, so don't see material
> difference - at least from the usage standpoint. I also don't see why
> the previous arguments that resulted in consensus for using Yang
> Library underneath the an in line Mount Point don't apply.

B/c it doesn't work well with the NMDA.  You can't mount yang library
in the configuration datastores; it has to be mounted in operational.
With meta-data, you can actually report the correct schema even in
running.  (This is actually true also for pre-NMDA systems).


/martin


From nobody Tue Jan 16 06:19:47 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 601201289B0 for ; Tue, 16 Jan 2018 06:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 lhHTWRBTWVSq for ; Tue, 16 Jan 2018 06:19:44 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 84CF1131451 for ; Tue, 16 Jan 2018 06:19:08 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 5F93E1E0CED for ; Tue, 16 Jan 2018 07:19:06 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id z2K21w01y2SSUrH012K5Ps; Tue, 16 Jan 2018 07:19:06 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=Glo0LdafOhxctCdWWAoA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wMNTpQD/gwxAC6p8YpfbbYfJa64Ae6AqJydKtFzJw78=; b=j0VzwoRSozp4yQFI3gTfue2Tw/ hhwo88o4S0mONIWBNPL6mWXzywKSPlnwVhweZoMRpe0fac2yJmdRjychdFIwHzxk4Ted3hqSo0Ujm AW9NRFKpBrmXPnbDCjT3ZQD7A;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:43902 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebS4s-003ggZ-9c; Tue, 16 Jan 2018 07:19:02 -0700
To: Robert Wilton , Ladislav Lhotka , Martin Bjorklund 
Cc: NETMOD WG 
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>  <91b3916b-ba51-b066-8600-83127d8f1e76@labn.net> <7ae6819c-3af6-e194-e83f-146a90ae8426@cisco.com>
From: Lou Berger 
Message-ID: 
Date: Tue, 16 Jan 2018 09:19:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <7ae6819c-3af6-e194-e83f-146a90ae8426@cisco.com>
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-Exim-ID: 1ebS4s-003ggZ-9c
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]:43902
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 14:19:46 -0000

On 1/16/2018 8:40 AM, Robert Wilton wrote:
>
> On 16/01/2018 13:23, Lou Berger wrote:
>> On 1/16/2018 7:41 AM, Robert Wilton wrote:
>>> On 16/01/2018 07:14, Ladislav Lhotka wrote:
>>>> Hi Lou,
>>>>
>>>> in my view, we should do the following two (significant) changes:
>>>>
>>>> 1. Instead of borrowing a grouping from ietf-yang-library and having
>>>> a parallel
>>>> list of mounted schemas, we should keep *all* mounted schemas
>>>> directly in the
>>>> YANG library and refer to them from schema-mounts structures.
>>>> Juergen suggested
>>>> this change and it is IMO the right thing to do.
>>> I also support this approach.  I think that it easier for everyone if
>>> schema are defined in one place.
>> I think we have a question of what is workable vs what is optimal,
>> i.e., this proposal is arguably better for those supporting YL bis,
>> but the other isn't broken.   -- I have also raised this privately
>> with the chairs and ADs of the impacted groups (keep in mind that
>> RTGWG and BESS are already using the current definitions) to see if
>> they have opinions.
> The NMDA solution to this problem is to publish both ...
>
> E.g. either (i) publish SM now (so that folks can use)
This would permit the current dependent work to continue, uninterrupted 
so I think has a lot of benefit.
> it but then
> immediately bis the draft, to cover YL-bis (probably keeping the
> existing library in the appendix).
Lots of variations on how to immediately address YL-bis and SM.  -- I 
think you know my preferred solution, but other are certainly workable.


> Or (ii) put the current SM YANG library into the appendix (marked as
> deprecated) and include a new YL-bis compatible version in the body of
> the document.

>
>>> This was also the suggested approach that I presented at IETF 100 for
>>> the YANG library bis draft, which seemed to have reasonable support in
>>> the room, and I don't recall anyone objecting to this approach.
>> In the email discussion on the results of the December NetConf
>> interim, the sentiment was that YL bis shouldn't consider schema
>> mount.  As stated on the list, I personally (with all hats) think this
>> is a mistake and would likely feel differently if YL bis
>> covered/obsoleted schema mount.
> I think that the conclusion was more nuanced that that:
>
> YL-bis should not cover SM directly.  I.e. YL-bis should not contain SM
> specific nodes (even under a feature keyword).
>
> However, there seems to good support for YL-bis being designed in an SM
> sympathetic way, such that SM can cleanly augment YL-bis and provide the
> required functionality without needing to a separate schema mount
> specific YANG library tree.

I'm certainly glad to hear that the topic of schema mount and server 
metadata will be / is being considered as part of YL-bis.  This is more 
than I thought was evidenced by the on-list discussion in December.

Lou

>
> Thanks,
> Rob
>
>
>> Lou
>>> I also provided the same comment in November during the WG LC on schema
>>> mount ...
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>> 2. Define a metadata annotation (e.g. @schema-ref) that would be
>>>> required for
>>>> inline mount point instances and specify the inline-mounted schema
>>>> also by
>>>> referring to a schema specified in YANG library.
>>>>
>>>> The advantage of #2 is that an annotation can be attached equally
>>>> well to both
>>>> state an configuration data. So, instead of papering over the issue
>>>> that YANG
>>>> library (state data) cannot appear in configuration datastores, we
>>>> can use this
>>>> general and straightforward approach. This also allows for defining
>>>> different
>>>> mounted schemas for instances of the same mount point in different
>>>> datastores.
>>>>
>>>> I strongly believe that these changes (along with the new YANG
>>>> library schema
>>>> and NMDA) make for a simple and elegant datastore architecture in
>>>> which schema
>>>> mount would be an optional feature.
>>>>
>>>> Lada
>>>>
>>>>
>>>> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>>>>> Lada/Martin,
>>>>>
>>>>> I don't believe we reached closure on this discussion.  The open
>>>>> issues
>>>>> relate to proposed new text (slightly modified):
>>>>>
>>>>> at the end of the section [3.2] adding a new paragraph along the
>>>>> lines of:
>>>>>
>>>>>       The use of mount points does not impact the nature of the
>>>>>       mounted data or in which data store information is made
>>>>>       available. For example, mounted YANG Library modules define
>>>>>       only operational state data and, as such, the information in
>>>>>       these modules is available from operational data stores using
>>>>>       the appropriate protocol operations.  It is also worth
>>>>>       noting that the Schema Mount module itself parallels the
>>>>>       YANG Library module and only defines operational state data.
>>>>>
>>>>> Is this change acceptable?
>>>>>
>>>>> What other issues related to SM are outstanding?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Lou
>>>>>
>>>>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>>>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>>>>> Hi Lada,
>>>>>>>>>
>>>>>>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>>>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>>>>>>> Lada,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>>>>>>> lada,
>>>>>>>>>>>>>
>>>>>>>>>>>>>         See below.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>>>>>>> library
>>>>>>>>>>>>>> data
>>>>>>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> because now under NMDA actions can be used only on instances
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>  datastore.
>>>>>>>>>>>>> but the inline/embedded library would (only) be present in the
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> operational datastore, so what's the issue?
>>>>>>>>>>>> Well, the issue is described in my initial mail of this thread:
>>>>>>>>>>>> the
>>>>>>>>>>>> current
>>>>>>>>>>>> text
>>>>>>>>>>>> requires that every instance of an inline mount point contains
>>>>>>>>>>>> the
>>>>>>>>>>>> embedded
>>>>>>>>>>>> YANG library. Tha latter is state data, so the above
>>>>>>>>>>>> requirement
>>>>>>>>>>>> cannot
>>>>>>>>>>>> be
>>>>>>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>>>>>>> datastore.
>>>>>>>>>>>>
>>>>>>>>>>> That's not how I read the intent of the current text.  I
>>>>>>>>>>> don't see
>>>>>>>>>>> SM
>>>>>>>>>>> impacting which data stores information is presented.  Just like
>>>>>>>>>>> use
>>>>>>>>>>> of
>>>>>>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>>>>>>> operational information.  I sent you a couple of sentences
>>>>>>>>>>> clarifying
>>>>>>>>>>> this
>>>>>>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>>>>>>> Please do, this has to be discussed in the WG mailing list.
>>>>>>>>> Agreed - that's why I asked to start this thread!
>>>>>>>>>
>>>>>>>>> Here's the original proposal:
>>>>>>>>>
>>>>>>>>>       How about at the end of the section [3.2] adding a new
>>>>>>>>>       paragraph along the lines of:
>>>>>>>>>
>>>>>>>>>       It is important to note that both YANG Library and Schema
>>>>>>>>>       Mount Modules contain only operational state data. As such,
>>>>>>>> s/contain/define/
>>>>>>>>
>>>>>>>>>       the information in these modules should be retrieved by
>>>>>>>>>       clients from operational data stores using the appropriate
>>>>>>>> This is based on two assumptions:
>>>>>>>>
>>>>>>>> 1. For every configuration datastore there is a corresponding
>>>>>>>> operational
>>>>>>>> datastore.
>>>>>>> well the text is revised below.  In any case, "these modules"
>>>>>>> refers to
>>>>>>> yang library, and yes, I'm assuming YL is always and only in
>>>>>>> operational.  If the revised text below isn't clear s/these/YANG
>>>>>>> Library/
>>>>>>> -
>>>>>> The thing is that we have the top-level YANG library in
>>>>>> , and
>>>>>> then
>>>>>> embedded YANG libraries scattered inside inline mount point
>>>>>> instances.
>>>>>>
>>>>>>>> 2. For every mount point instance in any configuration datastore
>>>>>>>> there
>>>>>>>> is a
>>>>>>>> corresponding mount point instance (with the same path) in an
>>>>>>>> operational
>>>>>>>> datastore.
>>>>>>>>
>>>>>>>> I think that neither of these has to be true in general.
>>>>>>> agreed in general, but for inline, where YL is required, it must
>>>>>>> be true.
>>>>>> How do you know? I provided an example in Singapore where a mount
>>>>>> point
>>>>>> instance
>>>>>> in  is a part of pre-provisioned data (for non-existent
>>>>>> hardware).
>>>>>> Then, according to the NMDA rules there is no corresponding
>>>>>> instance in
>>>>>> , hence no place where the embedded YANG library can
>>>>>> be placed.
>>>>>> (I can easily provide a concrete example if needed).
>>>>>>
>>>>>>
>>>>>> Dean replied that this cannot happen, so it seems there are some
>>>>>> assumptions
>>>>>> how
>>>>>> the inline method of schema mount may be applied. If so, these
>>>>>> assumptions
>>>>>> have
>>>>>> to be explicitly stated.
>>>>>>
>>>>>>>>>       protocol operations.
>>>>>>>> In contrast, the substance of my proposal with metadata
>>>>>>>> annotations is
>>>>>>>> to be
>>>>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>>>>> 
>>>>>>>> datastore, namely from the top-level YANG library.
>>>>>>> What about a schema that is based on dll that contains modules that
>>>>>>> isn't loaded until a mount point is instantiated -- this is
>>>>>>> certainly a
>>>>>>> valid approach for supporting LNEs, but would be precluded in this
>>>>>>> approach.  I really don't think a top level approach works for all
>>>>>>> inline (managed) types of mounts.
>>>>>> It isn't precluded: when the mount point is instantiated (no
>>>>>> matter which
>>>>>> datastore it is in), the server adds the schema as a new entry to the
>>>>>> "schema"
>>>>>> list in the top level YANG library (with a unique key), and
>>>>>> annotates the
>>>>>> mount
>>>>>> point instance with a leafref pointing to that key. So different
>>>>>> instances
>>>>>> of
>>>>>> the same mount point can have different schemas.
>>>>>>
>>>>>>>>> Given this discussion, we can generalize it further to:
>>>>>>>>>
>>>>>>>>>       The use of mount points does not impact the nature of the
>>>>>>>>>       mounted data or in which data store information is made
>>>>>>>>>       available. For example, mounted YANG Library modules contain
>>>>>>>>>       only operational state data and, as such, the information in
>>>>>>>>>       these modules is available from operational data stores using
>>>>>>>>>       the appropriate protocol operations.
>>>>>>>> The whole question here is whether and how we can locate the
>>>>>>>> schema for
>>>>>>>> an
>>>>>>>> inline mount point in any configuration datastore.
>>>>>>> Why is a mounted YL different than a top level YL?  What works
>>>>>>> for and
>>>>>> It is not different, but it can be only in an operational
>>>>>> datastores, and so
>>>>>> for
>>>>>> mount point instances inside configuration datastores we need a
>>>>>> way how to
>>>>>> locate the schema for that mount point, because it cannot be found
>>>>>> directly
>>>>>> under the mount point instance (as the current text assumes).
>>>>>>
>>>>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>>>>> modified by SM -- at least that's how I thought we've been
>>>>>>> talking about
>>>>>>> since SM was started.  Again, we never made any special
>>>>>>> provisions for
>>>>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>>>>> metadata, why start now?
>>>>>>>
>>>>>>> I'm getting the impression that your argument may be more about
>>>>>>> if YL
>>>>>>> should be treated as something other than operational data, is
>>>>>>> this wrong?
>>>>>> This is wrong. My argument is that there should be only one
>>>>>> top-level YANG
>>>>>> library (state data) and each inline mount point instance just
>>>>>> points to a
>>>>>> schema inside it by means of a metadata annotation attached to the
>>>>>> mount
>>>>>> point
>>>>>> (in any datastore).
>>>>>>
>>>>>> Lada
>>>>>>
>>>>>>> Thanks,
>>>>>>> Lou
>>>>>>>
>>>>>>>> Lada
>>>>>>>>
>>>>>>>>> Lou
>>>>>>>>>
>>>>>>>>>> Lada
>>>>>>>>>>
>>>>>>>>>>> Lou
>>>>>>>>>>>>>> However, a good alternative seems to be a metadata
>>>>>>>>>>>>>> annotation
>>>>>>>>>>>>>> along
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>>>>>>> newly
>>>>>>>>>>>>>> proposed YANG library schema:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          md:annotation schema-ref {
>>>>>>>>>>>>>>            type leafref {
>>>>>>>>>>>>>>              path "/yanglib:yang-
>>>>>>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In other words, all inline mounted schemas would be included
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>>>>>>> datastores
>>>>>>>>>>>>>> would be annotated with leafref pointing to the actual
>>>>>>>>>>>>>> schema.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unlike regular state data, it is IMO no problem to permit
>>>>>>>>>>>>>> such
>>>>>>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Opinions?
>>>>>>>>>>>>> I'm not sure this will work for all architectures of LNEs as
>>>>>>>>>>>>> well
>>>>>>>>>>>>> as
>>>>>>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>>>>>>> restrictive.
>>>>>>>>>>>> I don't understand, IMO it is not restrictive at all. What kind
>>>>>>>>>>>> of
>>>>>>>>>>>> restrictions
>>>>>>>>>>>> do you see?
>>>>>>>>>>>>
>>>>>>>>>>>> Lada
>>>>>>>>>>>>
>>>>>>>>>>>>> Lou
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ladislav Lhotka  writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> traditional
>>>>>>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        In case 1 ["inline"], the mounted schema is determined
>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>> time:
>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>        instance of the mount point that exists in the parent
>>>>>>>>>>>>>>> tree
>>>>>>>>>>>>>>> MUST
>>>>>>>>>>>>>>>        contain a copy of YANG library data [RFC7895] that
>>>>>>>>>>>>>>> defines
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>        mounted schema exactly as for a top-level data
>>>>>>>>>>>>>>> model.  A
>>>>>>>>>>>>>>> client
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>        expected to retrieve this data from the instance tree,
>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>>        creating the mount point. Instances of the same mount
>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>> MAY
>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>        different mounted schemas.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>>>>>>> datastores
>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>> contain
>>>>>>>>>>>>>>> YANG library (being state data), and so the MUST cannot
>>>>>>>>>>>>>>> hold.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not clear to me how to repair this without
>>>>>>>>>>>>>>> considerable
>>>>>>>>>>>>>>> complications
>>>>>>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>> impact on YANG library: the server could provide it in a
>>>>>>>>>>>>>>> reply
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> operation,
>>>>>>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>>>>>>> point,
>>>>>>>>>>>>>>> and it
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So my proposal is to move from YANG library as state data
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> operation.
>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>> could be done along with changing the YANG library
>>>>>>>>>>>>>>> structure,
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lada
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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 Jan 16 06: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 00CD61314EA for ; Tue, 16 Jan 2018 06:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 qddPg3JWQk94 for ; Tue, 16 Jan 2018 06:24:52 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 0C9271314F4 for ; Tue, 16 Jan 2018 06:24:42 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id C93BF140568 for ; Tue, 16 Jan 2018 07:24:40 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id z2Qd1w0072SSUrH012QgUi; Tue, 16 Jan 2018 07:24:40 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=wU2YTnxGAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=3W2mLpD6AtZF7ffR4YQA:9 a=QEXdDO2ut3YA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=V5S/j2ScnKF9eFZKRGKdylEE+u5g4sQyATv54WDAKxc=; b=vVCbHb49eMcZfv8XlN9yXrM1Sy kmI1XhbwfWwdw9CJljkSFrfnFzCMIoQbvQdyCIvhd8Co5aI+M7fEGkql0uB9aCi8GIkU4eo4HKpry GJtjZ1e6TTJDHssDfObG7AnMa;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44360 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebSAG-003iII-Ra; Tue, 16 Jan 2018 07:24:36 -0700
To: Martin Bjorklund 
Cc: lhotka@nic.cz, netmod@ietf.org
References: <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.142407.1498790690296330642.mbj@tail-f.com> <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net>
Date: Tue, 16 Jan 2018 09:24:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180116.145003.1110791592584714461.mbj@tail-f.com>
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-Exim-ID: 1ebSAG-003iII-Ra
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]:44360
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 14:24:54 -0000

On 1/16/2018 8:50 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On January 16, 2018 8:24:42 AM Martin Bjorklund 
>> wrote:
>>
>>> Lou Berger  wrote:
>>>> Lada,
>>>>
>>>>
>>>> On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:
>>>>
>>>>> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
>>>>>> Lada,
>>>>>>
>>>>>> It sounds like you are proposing in (1) a fairly significant change in
>>>>>> the
>>>>>> direction of the draft and in (2) a basic approach that has been
>>>>> It is no change in direction, just a simplification of the
>>>>> schema-describing
>>>>> state data. Given the recent developments in 7895bis it makes no sense
>>>>> to me to
>>>>> have two "schema" lists if we can have just one.
>>>>>
>>>> Managing transition is hard. It's also highlights why Yang Library
>>>> this needs to be at least equally discussed in this group.
>>>>
>>>> I will talk with my co-chairs and perhaps the ADs to get their opinion
>>>> on making such a change this point in the process.
>>>>
>>>>
>>>>>> rejectected by the WG multiple times.  FWIW there are drafts already
>>>>>> with
>>>>> No at all. The first and last time I proposed this was on 15 December
>>>>> 2017:
>>>>>
>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>>>>>
>>>> Oh, I certainly would call you proposing that the schema for inline be
>>>> part of the rest of the schema Mount module well before that. I'm sure
>>>> I can dig up mail / slides it really necessary...
>>> I don't think this has been proposed before.  All previous proposals
>>> were basically variants on what is now "use-schema", which works fine
>>> when all instances have the same schema.  This new proposal solves the
>>> issue with different schemas in different instances.
>>>
>> I thought the previous proposals that as well, so don't see material
>> difference - at least from the usage standpoint. I also don't see why
>> the previous arguments that resulted in consensus for using Yang
>> Library underneath the an in line Mount Point don't apply.
> B/c it doesn't work well with the NMDA.  You can't mount yang library
> in the configuration datastores; it has to be mounted in operational.
> With meta-data, you can actually report the correct schema even in
> running.  (This is actually true also for pre-NMDA systems).
>
Understood and agree there is nothing new here and the current version 
of SM (including inline) has the same limitation as rfc7895, and I'd 
expect it to behave the same once we have rfc7985bis -- in fact the 
inline case "just works" with YL-bis as defined today.

The argument I recall being the key point on inline was handling the 
large variety of possible different implementation approaches for 
modules using inline.  For example an LNE that is implemented using VMs 
which can be managed by the host at different times of the VMs 
operational life cycle based on customer/provider requirements.  I 
really don't see how YL-bis has any bearing on this point and I think it 
is incumbent upon those revisiting past/closed WG decisions (in this 
case, inline schema being represented by YL) to argue why the decision 
needs to be revisited.

Lou

> /martin
>


From nobody Tue Jan 16 06:57: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 5ACE9131517 for ; Tue, 16 Jan 2018 06:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 c0VMEuIaDuJ8 for ; Tue, 16 Jan 2018 06:57:47 -0800 (PST)
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 EB4DE1314E5 for ; Tue, 16 Jan 2018 06:57:46 -0800 (PST)
Received: from birdie (cst-prg-6-126.cust.vodafone.cz [46.135.6.126]) by mail.nic.cz (Postfix) with ESMTPSA id 01D5564636; Tue, 16 Jan 2018 15:57:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516114665; bh=Dkcw7tSLec7A2eDd7zC9/pl5JKrHqcEpzYdm+5eILLk=; h=From:To:Date; b=FZpZ8KinKeVAyhObeA+tWSHBOgJ0v8G6UXYZafGKqbw3mj2EqeRVVFKKbiJXlxvbr cBHle8GJdOLkCdYe6J4Vv5kcMiFkJSKU4iVT9dMUgp8isf38ZjZQ7vJFrfEUTNQ6g0 D8qTnoqJRykB0XBZ4HxWutUUeD9C4mXERQXBJleQ=
Message-ID: <1516114664.18487.13.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , Lou Berger , Martin Bjorklund 
Cc: NETMOD WG 
Date: Tue, 16 Jan 2018 15:57:44 +0100
In-Reply-To: <7ae6819c-3af6-e194-e83f-146a90ae8426@cisco.com>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz>  <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>  <91b3916b-ba51-b066-8600-83127d8f1e76@labn.net> <7ae6819c-3af6-e194-e83f-146a90ae8426@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 14:57:51 -0000

On Tue, 2018-01-16 at 13:40 +0000, Robert Wilton wrote:
> 
> On 16/01/2018 13:23, Lou Berger wrote:
> > On 1/16/2018 7:41 AM, Robert Wilton wrote:
> > > 
> > > On 16/01/2018 07:14, Ladislav Lhotka wrote:
> > > > Hi Lou,
> > > > 
> > > > in my view, we should do the following two (significant) changes:
> > > > 
> > > > 1. Instead of borrowing a grouping from ietf-yang-library and having 
> > > > a parallel
> > > > list of mounted schemas, we should keep *all* mounted schemas 
> > > > directly in the
> > > > YANG library and refer to them from schema-mounts structures. 
> > > > Juergen suggested
> > > > this change and it is IMO the right thing to do.
> > > 
> > > I also support this approach.  I think that it easier for everyone if
> > > schema are defined in one place.
> > 
> > I think we have a question of what is workable vs what is optimal, 
> > i.e., this proposal is arguably better for those supporting YL bis, 
> > but the other isn't broken.   -- I have also raised this privately 
> > with the chairs and ADs of the impacted groups (keep in mind that 
> > RTGWG and BESS are already using the current definitions) to see if 
> > they have opinions.
> 
> The NMDA solution to this problem is to publish both ...
> 
> E.g. either (i) publish SM now (so that folks can use) it but then

If folks means module authors, then they are IMO largely unaffected. As before,
they just have to place the mount-point extension to desired places in their
modules. Everything we discuss here is of interest to data model implementors.

> immediately bis the draft, to cover YL-bis (probably keeping the 
> existing library in the appendix).
> 
> Or (ii) put the current SM YANG library into the appendix (marked as 
> deprecated) and include a new YL-bis compatible version in the body of 
> the document.
> 
> 
> > 
> > > This was also the suggested approach that I presented at IETF 100 for
> > > the YANG library bis draft, which seemed to have reasonable support in
> > > the room, and I don't recall anyone objecting to this approach.
> > 
> > In the email discussion on the results of the December NetConf 
> > interim, the sentiment was that YL bis shouldn't consider schema 
> > mount.  As stated on the list, I personally (with all hats) think this 
> > is a mistake and would likely feel differently if YL bis 
> > covered/obsoleted schema mount.
> 
> I think that the conclusion was more nuanced that that:
> 
> YL-bis should not cover SM directly.  I.e. YL-bis should not contain SM 
> specific nodes (even under a feature keyword).

Absolutely. YL should be completely independent of schema mount.

> 
> However, there seems to good support for YL-bis being designed in an SM 
> sympathetic way, such that SM can cleanly augment YL-bis and provide the 
> required functionality without needing to a separate schema mount 
> specific YANG library tree.

I think that schema-mount needn't even augment YL. Specifically, ietf-schema-
mount would do:

1. Define the "schema-mounts" hierarchy, the only change being that the "name"
leafref in the "use-schema" list now points to YL "schema" list entries rather
than to /schema-mounts/schema.

2. Extension "mount-point", exactly as before.

3. Metadata annotation "@schema-ref" for use with inline mount point instances.

All in all, a piece of cake.

Lada  

> 
> Thanks,
> Rob
> 
> 
> > 
> > Lou
> > > I also provided the same comment in November during the WG LC on schema
> > > mount ...
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > > 2. Define a metadata annotation (e.g. @schema-ref) that would be 
> > > > required for
> > > > inline mount point instances and specify the inline-mounted schema 
> > > > also by
> > > > referring to a schema specified in YANG library.
> > > > 
> > > > The advantage of #2 is that an annotation can be attached equally 
> > > > well to both
> > > > state an configuration data. So, instead of papering over the issue 
> > > > that YANG
> > > > library (state data) cannot appear in configuration datastores, we 
> > > > can use this
> > > > general and straightforward approach. This also allows for defining 
> > > > different
> > > > mounted schemas for instances of the same mount point in different 
> > > > datastores.
> > > > 
> > > > I strongly believe that these changes (along with the new YANG 
> > > > library schema
> > > > and NMDA) make for a simple and elegant datastore architecture in 
> > > > which schema
> > > > mount would be an optional feature.
> > > > 
> > > > Lada
> > > > 
> > > > 
> > > > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
> > > > > Lada/Martin,
> > > > > 
> > > > > I don't believe we reached closure on this discussion.  The open 
> > > > > issues
> > > > > relate to proposed new text (slightly modified):
> > > > > 
> > > > > at the end of the section [3.2] adding a new paragraph along the
> > > > > lines of:
> > > > > 
> > > > >      The use of mount points does not impact the nature of the
> > > > >      mounted data or in which data store information is made
> > > > >      available. For example, mounted YANG Library modules define
> > > > >      only operational state data and, as such, the information in
> > > > >      these modules is available from operational data stores using
> > > > >      the appropriate protocol operations.  It is also worth
> > > > >      noting that the Schema Mount module itself parallels the
> > > > >      YANG Library module and only defines operational state data.
> > > > > 
> > > > > Is this change acceptable?
> > > > > 
> > > > > What other issues related to SM are outstanding?
> > > > > 
> > > > > Thank you,
> > > > > 
> > > > > Lou
> > > > > 
> > > > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> > > > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
> > > > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > > > > > > Hi Lada,
> > > > > > > > > 
> > > > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > > > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> > > > > > > > > > > Lada,
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka  > > > > > > > > > > c.cz>
> > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > > > > > > > > > > > lada,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >        See below.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > unfortunately, using an action for querying embedded
> > > > > > > > > > > > > > YANG
> > > > > > > > > > > > > > library
> > > > > > > > > > > > > > data
> > > > > > > > > > > > > > (needed for the "inline" case of schema mount)
> > > > > > > > > > > > > > doesn't work
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > because now under NMDA actions can be used only on
> > > > > > > > > > > > > > instances
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > >  datastore.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > but the inline/embedded library would (only) be
> > > > > > > > > > > > > present in the
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > operational datastore, so what's the issue?
> > > > > > > > > > > > 
> > > > > > > > > > > > Well, the issue is described in my initial mail of this
> > > > > > > > > > > > thread:
> > > > > > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > text
> > > > > > > > > > > > requires that every instance of an inline mount point
> > > > > > > > > > > > contains
> > > > > > > > > > > > the
> > > > > > > > > > > > embedded
> > > > > > > > > > > > YANG library. Tha latter is state data, so the above 
> > > > > > > > > > > > requirement
> > > > > > > > > > > > cannot
> > > > > > > > > > > > be
> > > > > > > > > > > > satisfied if the mount point instance is in a
> > > > > > > > > > > > configuration
> > > > > > > > > > > > datastore.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > That's not how I read the intent of the current text.  I 
> > > > > > > > > > > don't see
> > > > > > > > > > > SM
> > > > > > > > > > > impacting which data stores information is presented. 
> > > > > > > > > > > Just like
> > > > > > > > > > > use
> > > > > > > > > > > of
> > > > > > > > > > > scheme mount doesn't transform RO configuration
> > > > > > > > > > > information into
> > > > > > > > > > > operational information.  I sent you a couple of sentences
> > > > > > > > > > > clarifying
> > > > > > > > > > > this
> > > > > > > > > > > at one point, I'll dig up the proposed text and resend.
> > > > > > > > > > 
> > > > > > > > > > Please do, this has to be discussed in the WG mailing list.
> > > > > > > > > 
> > > > > > > > > Agreed - that's why I asked to start this thread!
> > > > > > > > > 
> > > > > > > > > Here's the original proposal:
> > > > > > > > > 
> > > > > > > > >      How about at the end of the section [3.2] adding a new
> > > > > > > > >      paragraph along the lines of:
> > > > > > > > > 
> > > > > > > > >      It is important to note that both YANG Library and Schema
> > > > > > > > >      Mount Modules contain only operational state data. As
> > > > > > > > > such,
> > > > > > > > 
> > > > > > > > s/contain/define/
> > > > > > > > 
> > > > > > > > >      the information in these modules should be retrieved by
> > > > > > > > >      clients from operational data stores using the
> > > > > > > > > appropriate
> > > > > > > > 
> > > > > > > > This is based on two assumptions:
> > > > > > > > 
> > > > > > > > 1. For every configuration datastore there is a corresponding
> > > > > > > > operational
> > > > > > > > datastore.
> > > > > > > 
> > > > > > > well the text is revised below.  In any case, "these modules" 
> > > > > > > refers to
> > > > > > > yang library, and yes, I'm assuming YL is always and only in
> > > > > > > operational.  If the revised text below isn't clear s/these/YANG 
> > > > > > > Library/
> > > > > > > -
> > > > > > 
> > > > > > The thing is that we have the top-level YANG library in 
> > > > > > , and
> > > > > > then
> > > > > > embedded YANG libraries scattered inside inline mount point 
> > > > > > instances.
> > > > > > 
> > > > > > > > 2. For every mount point instance in any configuration
> > > > > > > > datastore 
> > > > > > > > there
> > > > > > > > is a
> > > > > > > > corresponding mount point instance (with the same path) in an
> > > > > > > > operational
> > > > > > > > datastore.
> > > > > > > > 
> > > > > > > > I think that neither of these has to be true in general.
> > > > > > > 
> > > > > > > agreed in general, but for inline, where YL is required, it must 
> > > > > > > be true.
> > > > > > 
> > > > > > How do you know? I provided an example in Singapore where a mount 
> > > > > > point
> > > > > > instance
> > > > > > in  is a part of pre-provisioned data (for non-existent 
> > > > > > hardware).
> > > > > > Then, according to the NMDA rules there is no corresponding 
> > > > > > instance in
> > > > > > , hence no place where the embedded YANG library can 
> > > > > > be placed.
> > > > > > (I can easily provide a concrete example if needed).
> > > > > > 
> > > > > > 
> > > > > > Dean replied that this cannot happen, so it seems there are some 
> > > > > > assumptions
> > > > > > how
> > > > > > the inline method of schema mount may be applied. If so, these 
> > > > > > assumptions
> > > > > > have
> > > > > > to be explicitly stated.
> > > > > > 
> > > > > > > > >      protocol operations.
> > > > > > > > 
> > > > > > > > In contrast, the substance of my proposal with metadata 
> > > > > > > > annotations is
> > > > > > > > to be
> > > > > > > > able to retrieve all schemas from a well-known location in *the*
> > > > > > > > 
> > > > > > > > datastore, namely from the top-level YANG library.
> > > > > > > 
> > > > > > > What about a schema that is based on dll that contains modules
> > > > > > > that
> > > > > > > isn't loaded until a mount point is instantiated -- this is 
> > > > > > > certainly a
> > > > > > > valid approach for supporting LNEs, but would be precluded in this
> > > > > > > approach.  I really don't think a top level approach works for all
> > > > > > > inline (managed) types of mounts.
> > > > > > 
> > > > > > It isn't precluded: when the mount point is instantiated (no 
> > > > > > matter which
> > > > > > datastore it is in), the server adds the schema as a new entry to
> > > > > > the
> > > > > > "schema"
> > > > > > list in the top level YANG library (with a unique key), and 
> > > > > > annotates the
> > > > > > mount
> > > > > > point instance with a leafref pointing to that key. So different 
> > > > > > instances
> > > > > > of
> > > > > > the same mount point can have different schemas.
> > > > > > 
> > > > > > > > > Given this discussion, we can generalize it further to:
> > > > > > > > > 
> > > > > > > > >      The use of mount points does not impact the nature of the
> > > > > > > > >      mounted data or in which data store information is made
> > > > > > > > >      available. For example, mounted YANG Library modules
> > > > > > > > > contain
> > > > > > > > >      only operational state data and, as such, the information
> > > > > > > > > in
> > > > > > > > >      these modules is available from operational data stores
> > > > > > > > > using
> > > > > > > > >      the appropriate protocol operations.
> > > > > > > > 
> > > > > > > > The whole question here is whether and how we can locate the 
> > > > > > > > schema for
> > > > > > > > an
> > > > > > > > inline mount point in any configuration datastore.
> > > > > > > 
> > > > > > > Why is a mounted YL different than a top level YL?  What works 
> > > > > > > for and
> > > > > > 
> > > > > > It is not different, but it can be only in an operational 
> > > > > > datastores, and so
> > > > > > for
> > > > > > mount point instances inside configuration datastores we need a 
> > > > > > way how to
> > > > > > locate the schema for that mount point, because it cannot be found 
> > > > > > directly
> > > > > > under the mount point instance (as the current text assumes).
> > > > > > 
> > > > > > > is sufficient for the normal case of YL shouldn't be impacted or
> > > > > > > modified by SM -- at least that's how I thought we've been 
> > > > > > > talking about
> > > > > > > since SM was started.  Again, we never made any special 
> > > > > > > provisions for
> > > > > > > any other rw/ro/state data, assuming top level YL is not handled
> > > > > > > as
> > > > > > > metadata, why start now?
> > > > > > > 
> > > > > > > I'm getting the impression that your argument may be more about 
> > > > > > > if YL
> > > > > > > should be treated as something other than operational data, is 
> > > > > > > this wrong?
> > > > > > 
> > > > > > This is wrong. My argument is that there should be only one 
> > > > > > top-level YANG
> > > > > > library (state data) and each inline mount point instance just 
> > > > > > points to a
> > > > > > schema inside it by means of a metadata annotation attached to the 
> > > > > > mount
> > > > > > point
> > > > > > (in any datastore).
> > > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > > Thanks,
> > > > > > > Lou
> > > > > > > 
> > > > > > > > Lada
> > > > > > > > 
> > > > > > > > > Lou
> > > > > > > > > 
> > > > > > > > > > Lada
> > > > > > > > > > 
> > > > > > > > > > > Lou
> > > > > > > > > > > > > > However, a good alternative seems to be a metadata
> > > > > > > > > > > > > > annotation
> > > > > > > > > > > > > > along
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > lines of RFC 7952, for example with the alternative
> > > > > > > > > > > > > > B of the
> > > > > > > > > > > > > > newly
> > > > > > > > > > > > > > proposed YANG library schema:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >         md:annotation schema-ref {
> > > > > > > > > > > > > >           type leafref {
> > > > > > > > > > > > > >             path "/yanglib:yang-
> > > > > > > > > > > > > > library/yanglib:schema/yanglib:name";
> > > > > > > > > > > > > >           }
> > > > > > > > > > > > > >         }
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > In other words, all inline mounted schemas would be
> > > > > > > > > > > > > > included
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > top-level YANG library, and mount point instances in
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > datastores
> > > > > > > > > > > > > > would be annotated with leafref pointing to the
> > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> > > > > > > > > > > > > > permit
> > > > > > > > > > > > > > such
> > > > > > > > > > > > > > annotations in configuration datastores.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Opinions?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I'm not sure this will work for all architectures of
> > > > > > > > > > > > > LNEs as
> > > > > > > > > > > > > well
> > > > > > > > > > > > > as
> > > > > > > > > > > > > other possible future use cases.  In short, this seems
> > > > > > > > > > > > > *very*
> > > > > > > > > > > > > restrictive.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't understand, IMO it is not restrictive at all.
> > > > > > > > > > > > What kind
> > > > > > > > > > > > of
> > > > > > > > > > > > restrictions
> > > > > > > > > > > > do you see?
> > > > > > > > > > > > 
> > > > > > > > > > > > Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > > Lou
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08
> > > > > > > > > > > > > > > is wrong
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > traditional
> > > > > > > > > > > > > > > datastores, and even more so for NDMA:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >       In case 1 ["inline"], the mounted schema is
> > > > > > > > > > > > > > > determined
> > > > > > > > > > > > > > > at
> > > > > > > > > > > > > > > run
> > > > > > > > > > > > > > > time:
> > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > >       instance of the mount point that exists in
> > > > > > > > > > > > > > > the parent
> > > > > > > > > > > > > > > tree
> > > > > > > > > > > > > > > MUST
> > > > > > > > > > > > > > >       contain a copy of YANG library data
> > > > > > > > > > > > > > > [RFC7895] that
> > > > > > > > > > > > > > > defines
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > >       mounted schema exactly as for a top-level
> > > > > > > > > > > > > > > data
> > > > > > > > > > > > > > > model.  A
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > >       expected to retrieve this data from the
> > > > > > > > > > > > > > > instance tree,
> > > > > > > > > > > > > > > possibly
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >       creating the mount point. Instances of the
> > > > > > > > > > > > > > > same mount
> > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > MAY
> > > > > > > > > > > > > > > use
> > > > > > > > > > > > > > >       different mounted schemas.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > An instance of the mount point in any
> > > > > > > > > > > > > > > *configuration*
> > > > > > > > > > > > > > > datastores
> > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > contain
> > > > > > > > > > > > > > > YANG library (being state data), and so the MUST
> > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > hold.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > It is not clear to me how to repair this without
> > > > > > > > > > > > > > > considerable
> > > > > > > > > > > > > > > complications
> > > > > > > > > > > > > > > and/or a lot of handwaving. There is actually one
> > > > > > > > > > > > > > > good
> > > > > > > > > > > > > > > solution
> > > > > > > > > > > > > > > but it
> > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > impact on YANG library: the server could provide
> > > > > > > > > > > > > > > it in a
> > > > > > > > > > > > > > > reply
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > operation,
> > > > > > > > > > > > > > > say "get-yang-library" rather than as state data.
> > > > > > > > > > > > > > > Then
> > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > would be
> > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > - this operation would turn into an action for the
> > > > > > > > > > > > > > > mount
> > > > > > > > > > > > > > > point,
> > > > > > > > > > > > > > > and it
> > > > > > > > > > > > > > > can
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > used equally well for config true and false mount
> > > > > > > > > > > > > > > points.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So my proposal is to move from YANG library as
> > > > > > > > > > > > > > > state data
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > operation.
> > > > > > > > > > > > > > > It
> > > > > > > > > > > > > > > could be done along with changing the YANG library
> > > > > > > > > > > > > > > structure,
> > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > little extra impact on implementations.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Lada
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > 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
> > > > > > > > > > > > 
> > 
> > .
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 07:09: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 79D1712D7FB for ; Tue, 16 Jan 2018 07:09:02 -0800 (PST)
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 Q2BN_7Lukc5D for ; Tue, 16 Jan 2018 07:08:58 -0800 (PST)
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 2B17D12D859 for ; Tue, 16 Jan 2018 07:08:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6FA1B146215E; Tue, 16 Jan 2018 16:08:51 +0100 (CET)
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 bnPoeHWZlEBU; Tue, 16 Jan 2018 16:08:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 47B431462160; Tue, 16 Jan 2018 16:08:51 +0100 (CET)
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 s7uxIj8LKE6s; Tue, 16 Jan 2018 16:08:51 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 1E5BD146215E; Tue, 16 Jan 2018 16:08:51 +0100 (CET)
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <20180116.115606.561861432247288407.mbj@tail-f.com>
From: Vladimir Vassilev 
Message-ID: 
Date: Tue, 16 Jan 2018 16:08:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20180116.115606.561861432247288407.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:09:02 -0000

On 01/16/2018 11:56 AM, Martin Bjorklund wrote:

> Vladimir Vassilev  wrote:
>> Hi,
>>
>> I have reviewed and implemented (apart from schema mount specific
>> functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found
>> the following issues:
>>
>> =3D=3Dsec 2.6.=C2=A0 Node Representation=3D=3D
>>
>> 1. To correctly reflect the current pyang output one needs to add '--'
>> between  and .
>> OLD:
>>  =C2=A0=C2=A0=C2=A0      
>> NEW:
>>  =C2=A0=C2=A0=C2=A0 --    
> Ok.
>
>> There is also undocumented alignment space count function before
>>  that pyang uses to align the  fields of child data leafs
>> with common ancestor. If this is specified in the draft the tree
>> output can be deterministic and for me this is an advantage. This is
>> currently one of the few underspecified pieces of the tree format so I
>> had to check pyang implementation in oder to generate same alignment
>> space counts and binary identical tree output results.
> I think that we at least should write that there may be more than one
> space between  and :
>
>    There may be any number of additional space characters between
>     and .
For the sake of the argument (at least having this on the mailing list=20
as reference):

 =C2=A0  should be aligned at a common offset for all sibling nodes
 =C2=A0 from the start of  by adding trailing spaces. The recommend=
ed
 =C2=A0 offset is 3 plus the length of the longest node name among all=20
sibling nodes
 =C2=A0 including those siblings defined under choice and case nodes.

This is what pyang does now. It is not a perfect solution but it allows=20
identical output down to the bit.

>
> I also just realized that we need to add text to the line wrapping
> section about line breaks between  and :
>
> OLD:
>
>     Internet Drafts and RFCs limit the number of characters that may in=
 a
>     line of text to 72 characters.  When the tree representation of a
>     node results in line being longer than this limit the line should b=
e
>     broken between  and .  The type should be indented so
>     that the new line starts below  with a white space offset of =
at
>     least two characters.
>
> NEW:
>
>     Internet Drafts and RFCs limit the number of characters in a line
>     of text to 72 characters.  When the tree representation of a node
>     results in line being longer than this limit the line should be
>     broken between  and , or between  and
>     .  The new line should be indented so that it starts
>     below  with a white space offset of at least two characters.
>
>
>> 2. It is unclear which  option should be used for rpc and
>> action input/output and child nodes and the notification child
>> nodes. pyang uses '-w' for input and input/* and 'ro' for output and
>> output/*:
>>
>>  =C2=A0=C2=A0=C2=A0 module: ietf-netconf-partial-lock
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rpcs:
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---x partial-lock
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +---w input
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +---w sele=
ct*=C2=A0=C2=A0 string
>>  =C2=A0=C2=A0=C2=A0 ...
> I'll do:
>
> OLD:
>
>          is one of:
>           rw  for configuration data
>           ro  for non-configuration data
>           -u  for uses of a grouping
>           -x  for rpcs and actions
>           -n  for notifications
>           mp  for nodes containing a "mount-point" extension statment
>
> NEW:
>
>          is one of:
>           rw  for configuration data
>           ro  for non-configuration data, output parameters to rpcs
>               and actions, and notification parameters
>           -w  for input parameters to rpcs and actions
>           -u  for uses of a grouping
>           -x  for rpcs and actions
>           -n  for notifications
>           mp  for nodes containing a "mount-point" extension statment
OK
>
>> pyang also uses '--' as  for augmentation data nodes for
>> actions input.
> I think that this is a bug in pyang, which I have now fixed.
OK
>
>>  =C2=A0=C2=A0=C2=A0 ...
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 augment
>> /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---- destination-address?=
=C2=A0=C2=A0 inet:ipv4-address
>>  =C2=A0=C2=A0=C2=A0 ...
>>
>>
>> 3. pyang is prefixing choice node names with the parent 
>> e.g. +--ro (next-hop-options) while case nodes are not prefixed. I
>> guess this is a bug in pyang since it is not specified in the draft
>> but choice nodes prefixed with parent  are=C2=A0 also present i=
n the
>> sec 4 and 4.1 examples?
> [ignoring based on latest email from Vladimir]
>
>> 4. This bit I found confusing. I propose this change to unambiguously
>> describe the current pyang format.
>>
>> OLD:
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-l=
ist or list
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [] for a list'=
s keys
>> NEW:
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 for a leaf-l=
ist or list without keys
>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * [] for a lis=
t with keys
> Hmm, wouldn't it be better to use [] for a list w/o keys?
Yes I also agree this improves readability at the cost of slight=20
redundancy increase and modification to format of diagrams already used=20
in RFCs. Your call.

Vladimir
>
>
> /martin
>
>
>
>> Vladimir
>>
>> On 01/01/2018 11:01 PM, joel jaeggli wrote:
>>> Greetings,
>>>
>>> We hope  the new year is a time to make great progess on outstanding
>>> documents before preparation for the  London IETF begins in earnest.
>>>
>>> This starts a two-week working group last call on:
>>>
>>>    YANG Tree Diagrams
>>> draft-ietf-netmod-yang-tree-diagrams
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams=
/
>>>
>>> Please send email to the list indicating your support or concerns.
>>>
>>> We are particularly interested in statements of the form:
>>>
>>>     * I have reviewed this draft and found no issues.
>>>     * I have reviewed this draft and found the following issues: ...
>>>
>>>
>>> Thank you,
>>> NETMOD WG Chairs
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 16 07:14:37 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 D4BA2131550 for ; Tue, 16 Jan 2018 07:14:36 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 3T6NNPi4hliA for ; Tue, 16 Jan 2018 07:14:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 195A8131555 for ; Tue, 16 Jan 2018 07:13:50 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id C76A31AE0399; Tue, 16 Jan 2018 16:13:48 +0100 (CET)
Date: Tue, 16 Jan 2018 16:13:47 +0100 (CET)
Message-Id: <20180116.161347.1518992717170489943.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net>
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:14:37 -0000

Lou Berger  wrote:
> =

> =

> On 1/16/2018 8:50 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >>
> >> On January 16, 2018 8:24:42 AM Martin Bjorklund 
> >> wrote:
> >>
> >>> Lou Berger  wrote:
> >>>> Lada,
> >>>>
> >>>>
> >>>> On January 16, 2018 7:07:15 AM Ladislav Lhotka  w=
rote:
> >>>>
> >>>>> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> >>>>>> Lada,
> >>>>>>
> >>>>>> It sounds like you are proposing in (1) a fairly significant c=
hange in
> >>>>>> the
> >>>>>> direction of the draft and in (2) a basic approach that has be=
en
> >>>>> It is no change in direction, just a simplification of the
> >>>>> schema-describing
> >>>>> state data. Given the recent developments in 7895bis it makes n=
o sense
> >>>>> to me to
> >>>>> have two "schema" lists if we can have just one.
> >>>>>
> >>>> Managing transition is hard. It's also highlights why Yang Libra=
ry
> >>>> this needs to be at least equally discussed in this group.
> >>>>
> >>>> I will talk with my co-chairs and perhaps the ADs to get their o=
pinion
> >>>> on making such a change this point in the process.
> >>>>
> >>>>
> >>>>>> rejectected by the WG multiple times.  FWIW there are drafts a=
lready
> >>>>>> with
> >>>>> No at all. The first and last time I proposed this was on 15 De=
cember
> >>>>> 2017:
> >>>>>
> >>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.h=
tml
> >>>>>
> >>>> Oh, I certainly would call you proposing that the schema for inl=
ine be
> >>>> part of the rest of the schema Mount module well before that. I'=
m sure
> >>>> I can dig up mail / slides it really necessary...
> >>> I don't think this has been proposed before.  All previous propos=
als
> >>> were basically variants on what is now "use-schema", which works =
fine
> >>> when all instances have the same schema.  This new proposal solve=
s the
> >>> issue with different schemas in different instances.
> >>>
> >> I thought the previous proposals that as well, so don't see materi=
al
> >> difference - at least from the usage standpoint. I also don't see =
why
> >> the previous arguments that resulted in consensus for using Yang
> >> Library underneath the an in line Mount Point don't apply.
> > B/c it doesn't work well with the NMDA.  You can't mount yang libra=
ry
> > in the configuration datastores; it has to be mounted in operationa=
l.
> > With meta-data, you can actually report the correct schema even in
> > running.  (This is actually true also for pre-NMDA systems).
> >
> Understood and agree there is nothing new here and the current versio=
n
> of SM (including inline) has the same limitation as rfc7895, and I'd
> expect it to behave the same once we have rfc7985bis -- in fact the
> inline case "just works" with YL-bis as defined today.
> =

> The argument I recall being the key point on inline was handling the
> large variety of possible different implementation approaches for
> modules using inline.

I think these still are covered.

> For example an LNE that is implemented using
> VMs which can be managed by the host at different times of the VMs
> operational life cycle based on customer/provider requirements.=A0 I
> really don't see how YL-bis has any bearing on this point and

Using the new proposed meta data annotation together with the new YL
means that SM can support the use case above also in an NMDA server.
I think the new proposed solution covers more use cases than the
previous solution.

Do you think that there is any use case that the proposed solution
cannot handle, but the previous solution did?

> I think
> it is incumbent upon those revisiting past/closed WG decisions (in
> this case, inline schema being represented by YL) to argue why the
> decision needs to be revisited.

I'm repeating my self: b/c the current solution doesn't work well with
the NMDA.


/martin


From nobody Tue Jan 16 07:17: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 7F800131513 for ; Tue, 16 Jan 2018 07:17:23 -0800 (PST)
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_RP_MATCHES_RCVD=-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 Oi2_6gC2mg_z for ; Tue, 16 Jan 2018 07:17:22 -0800 (PST)
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 068B9131564 for ; Tue, 16 Jan 2018 07:15:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=998; q=dns/txt; s=iport; t=1516115732; x=1517325332; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=FwEwvcjdJC4OQeMgFpszqOIhpwh71E1LtvVWh0S4vmg=; b=YimwZR5wb9FRv+A38V6tY12dIZ6wb7lsXG6NwSVOiUckAuNdMaMUopgP Up1GM6zBXryyQpVIOx9eUJ5afRmgxkxYS/iI5+b9YfjTzBgUzAkt9qxC7 SvEuBtRaWN5XQKINRHg2Q8vPF+SOiJmW/WBgFvVn1dC+cWgGoXZy+E7cy Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhBADoFV5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUbJ4QTixiPbplCCoU7AoUgEwEBAQEBAQEBAWsohSQBBSMPAQV?= =?us-ascii?q?RCQIYAgImAgJXBgEMBgIBAYovh2ydcIIniUoBAQEBAQEBAwEBAQEBASKBD4cZg?= =?us-ascii?q?WkpgwWDLwSFBoJlBaNklUuMJYdrjxyICYE8NyGBUDIaCBsVPYIqhFdBN40/AQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200";  d="scan'208";a="1482884"
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; 16 Jan 2018 15:15:28 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0GFFStm025130; Tue, 16 Jan 2018 15:15:28 GMT
To: Vladimir Vassilev , Martin Bjorklund , netmod@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <20180116.115606.561861432247288407.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 16 Jan 2018 15:15:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:17:23 -0000

On 16/01/2018 15:08, Vladimir Vassilev wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
>
>> Vladimir Vassilev  wrote:

>>
>>> 4. This bit I found confusing. I propose this change to unambiguously
>>> describe the current pyang format.
>>>
>>> OLD:
>>>           *  for a leaf-list or list
>>>           [] for a list's keys
>>> NEW:
>>>           *  for a leaf-list or list without keys
>>>           * [] for a list with keys
>> Hmm, wouldn't it be better to use [] for a list w/o keys?
> Yes I also agree this improves readability at the cost of slight 
> redundancy increase and modification to format of diagrams already 
> used in RFCs. Your call.

I like the idea of using [] for a list without keys, to cleanly 
differentiate list vs leaf-list.

I presume that they don't turn up that much in practice, so presumably 
not many RFC's would be impacted.

Thanks,
Rob


From nobody Tue Jan 16 07:25:52 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 6948C13158D for ; Tue, 16 Jan 2018 07:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 aNxaQAi8cQqv for ; Tue, 16 Jan 2018 07:25:50 -0800 (PST)
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 A4B8C1315B8 for ; Tue, 16 Jan 2018 07:22:48 -0800 (PST)
Received: from birdie (cst-prg-6-126.cust.vodafone.cz [46.135.6.126]) by mail.nic.cz (Postfix) with ESMTPSA id 33C7C64668; Tue, 16 Jan 2018 16:22:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516116167; bh=mRWHlzljLehwtNhrplYVL6p3SziBwM04YtvC/OBZ1Zg=; h=From:To:Date; b=HSx3LMblddp76tJQktJvUh5y+JXPEssMYQFrfHf3HseGvHe1xd4OOhZ3MeamZ2ADK oB/KUDFYXCUelDbs+bAtvkYwECqHcW9HRQwA4/SMzzXoFmdC2zPHhvzX4K/f0F8p8m kKJUX+hfZ5Y6opOonWAMxxctjXEkhMJmgDvlJ18g=
Message-ID: <1516116166.18487.18.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund , lberger@labn.net
Cc: netmod@ietf.org
Date: Tue, 16 Jan 2018 16:22:46 +0100
In-Reply-To: <20180116.161347.1518992717170489943.mbj@tail-f.com>
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:25:51 -0000

On Tue, 2018-01-16 at 16:13 +0100, Martin Bjorklund wrote:
> Lou Berger  wrote:
> > 
> > 
> > On 1/16/2018 8:50 AM, Martin Bjorklund wrote:
> > > Lou Berger  wrote:
> > >>
> > >> On January 16, 2018 8:24:42 AM Martin Bjorklund 
> > >> wrote:
> > >>
> > >>> Lou Berger  wrote:
> > >>>> Lada,
> > >>>>
> > >>>>
> > >>>> On January 16, 2018 7:07:15 AM Ladislav Lhotka  wrote:
> > >>>>
> > >>>>> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> > >>>>>> Lada,
> > >>>>>>
> > >>>>>> It sounds like you are proposing in (1) a fairly significant change
> in
> > >>>>>> the
> > >>>>>> direction of the draft and in (2) a basic approach that has been
> > >>>>> It is no change in direction, just a simplification of the
> > >>>>> schema-describing
> > >>>>> state data. Given the recent developments in 7895bis it makes no sense
> > >>>>> to me to
> > >>>>> have two "schema" lists if we can have just one.
> > >>>>>
> > >>>> Managing transition is hard. It's also highlights why Yang Library
> > >>>> this needs to be at least equally discussed in this group.
> > >>>>
> > >>>> I will talk with my co-chairs and perhaps the ADs to get their opinion
> > >>>> on making such a change this point in the process.
> > >>>>
> > >>>>
> > >>>>>> rejectected by the WG multiple times.  FWIW there are drafts already
> > >>>>>> with
> > >>>>> No at all. The first and last time I proposed this was on 15 December
> > >>>>> 2017:
> > >>>>>
> > >>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
> > >>>>>
> > >>>> Oh, I certainly would call you proposing that the schema for inline be
> > >>>> part of the rest of the schema Mount module well before that. I'm sure
> > >>>> I can dig up mail / slides it really necessary...
> > >>> I don't think this has been proposed before.  All previous proposals
> > >>> were basically variants on what is now "use-schema", which works fine
> > >>> when all instances have the same schema.  This new proposal solves the
> > >>> issue with different schemas in different instances.
> > >>>
> > >> I thought the previous proposals that as well, so don't see material
> > >> difference - at least from the usage standpoint. I also don't see why
> > >> the previous arguments that resulted in consensus for using Yang
> > >> Library underneath the an in line Mount Point don't apply.
> > > B/c it doesn't work well with the NMDA.  You can't mount yang library
> > > in the configuration datastores; it has to be mounted in operational.
> > > With meta-data, you can actually report the correct schema even in
> > > running.  (This is actually true also for pre-NMDA systems).
> > >
> > Understood and agree there is nothing new here and the current version
> > of SM (including inline) has the same limitation as rfc7895, and I'd
> > expect it to behave the same once we have rfc7985bis -- in fact the
> > inline case "just works" with YL-bis as defined today.
> > 
> > The argument I recall being the key point on inline was handling the
> > large variety of possible different implementation approaches for
> > modules using inline.
> 
> I think these still are covered.

Yes, I think they are.

> 
> > For example an LNE that is implemented using
> > VMs which can be managed by the host at different times of the VMs
> > operational life cycle based on customer/provider requirements.  I
> > really don't see how YL-bis has any bearing on this point and
> 
> Using the new proposed meta data annotation together with the new YL
> means that SM can support the use case above also in an NMDA server.
> I think the new proposed solution covers more use cases than the
> previous solution.
> 
> Do you think that there is any use case that the proposed solution
> cannot handle, but the previous solution did?
> 
> > I think
> > it is incumbent upon those revisiting past/closed WG decisions (in
> > this case, inline schema being represented by YL) to argue why the
> > decision needs to be revisited.
> 
> I'm repeating my self: b/c the current solution doesn't work well with
> the NMDA.

We can try to update the draft and the examples, it should then be much more
clear. It is really very little extra work.

Lada

> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 07:35: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 1664113156A for ; Tue, 16 Jan 2018 07:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 iyMo6WEUknxT for ; Tue, 16 Jan 2018 07:35:05 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 9B219131571 for ; Tue, 16 Jan 2018 07:34:17 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id A79A51406BA for ; Tue, 16 Jan 2018 08:34:15 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id z3aC1w00S2SSUrH013aF8i; Tue, 16 Jan 2018 08:34:15 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=ExnqA3jNLuRNEmwaKCUA:9 a=QEXdDO2ut3YA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hS2hZG7esnInJwu1lVEexWPtm7Kqust5cJ0ijHzOwwQ=; b=Gay4Ccq2zJzkSJdov6XaGYN11K dPfGPLkz2A/E8KpS+hM9iZvmXC2ObB5gkEbrrqhdYNu4DjKNIWCJp1mR1MUKLYubapBCe0Zj9oKL/ 1wI4oRfv3TytZVXYNi9C7AJMW;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52420 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebTFc-0043kF-8U; Tue, 16 Jan 2018 08:34:12 -0700
To: Martin Bjorklund 
Cc: lhotka@nic.cz, netmod@ietf.org
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net>
Date: Tue, 16 Jan 2018 10:34:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180116.161347.1518992717170489943.mbj@tail-f.com>
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-Exim-ID: 1ebTFc-0043kF-8U
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]:52420
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:35:07 -0000

On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
... (trimming to topic)
>>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts already
>>>>>>>> with
>>>>>>> No at all. The first and last time I proposed this was on 15 December
>>>>>>> 2017:
>>>>>>>
>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>>>>>>>
>>>>>> Oh, I certainly would call you proposing that the schema for inline be
>>>>>> part of the rest of the schema Mount module well before that. I'm sure
>>>>>> I can dig up mail / slides it really necessary...
>>>>> I don't think this has been proposed before.  All previous proposals
>>>>> were basically variants on what is now "use-schema", which works fine
>>>>> when all instances have the same schema.  This new proposal solves the
>>>>> issue with different schemas in different instances.
>>>>>
>>>> I thought the previous proposals that as well, so don't see material
>>>> difference - at least from the usage standpoint. I also don't see why
>>>> the previous arguments that resulted in consensus for using Yang
>>>> Library underneath the an in line Mount Point don't apply.
>>> B/c it doesn't work well with the NMDA.  You can't mount yang library
>>> in the configuration datastores; it has to be mounted in operational.
>>> With meta-data, you can actually report the correct schema even in
>>> running.  (This is actually true also for pre-NMDA systems).
>>>
>> Understood and agree there is nothing new here and the current version
>> of SM (including inline) has the same limitation as rfc7895, and I'd
>> expect it to behave the same once we have rfc7985bis -- in fact the
>> inline case "just works" with YL-bis as defined today.
Martin,

you didn't respond to this point.

>> The argument I recall being the key point on inline was handling the
>> large variety of possible different implementation approaches for
>> modules using inline.
> I think these still are covered.
>
>> For example an LNE that is implemented using
>> VMs which can be managed by the host at different times of the VMs
>> operational life cycle based on customer/provider requirements.  I
>> really don't see how YL-bis has any bearing on this point and
> Using the new proposed meta data annotation together with the new YL
> means that SM can support the use case above also in an NMDA server.
> I think the new proposed solution covers more use cases than the
> previous solution.

how so?  The inline mount point would contain YL-bis and have the same 
information there, just scoped for the mount point.  It's true a client 
would need to understand the mount point's schema only upon parsing the 
YL under the mount point and this schema could not be shared across 
inline mount points.  But this is as was discussed in the past and 
unchanged from YL.

> Do you think that there is any use case that the proposed solution
> cannot handle, but the previous solution did?
yes.  with VM/container technologies the YL / schema can change under 
the mount point from time to time during normal operation (i.e., during 
runtime, no reboot) and, in some implementations, may require some level 
of rpc operation to access even the schema.  The new (and previously 
proposed approach) of having inline schema available from the top level 
greatly complicates these cases.  Also keep in mind that there will be 
cases where the ability to access information under an inline mount 
point will dynamically change in operation (and top level YL would need 
to remove schema information for the inline mount point.)  As before, 
from the usage standpoint, these changes don't provide a whole lot of 
value and seem to optimizing for something not needed in the inline case.

>> I think
>> it is incumbent upon those revisiting past/closed WG decisions (in
>> this case, inline schema being represented by YL) to argue why the
>> decision needs to be revisited.
> I'm repeating my self: b/c the current solution doesn't work well with
> the NMDA.
I simply don't understand how YL-bis works at the root node but doesn't 
work equally at an inline mount point.  Can you elaborate?

Lou

>
>
> /martin
>


From nobody Tue Jan 16 07:41: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 C893413155A for ; Tue, 16 Jan 2018 07:41:20 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 g7IKj-0tDwsx for ; Tue, 16 Jan 2018 07:41:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B45EF1314F4 for ; Tue, 16 Jan 2018 07:40:55 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 886911AE0399; Tue, 16 Jan 2018 16:40:54 +0100 (CET)
Date: Tue, 16 Jan 2018 16:40:53 +0100 (CET)
Message-Id: <20180116.164053.2123534827829006518.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20180116.115606.561861432247288407.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:41:21 -0000

Vladimir Vassilev  wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
> =

> > Vladimir Vassilev  wrote:

[...]

> >> There is also undocumented alignment space count function before
> >>  that pyang uses to align the  fields of child data le=
afs
> >> with common ancestor. If this is specified in the draft the tree
> >> output can be deterministic and for me this is an advantage. This =
is
> >> currently one of the few underspecified pieces of the tree format =
so I
> >> had to check pyang implementation in oder to generate same alignme=
nt
> >> space counts and binary identical tree output results.
> > I think that we at least should write that there may be more than o=
ne
> > space between  and :
> >
> >    There may be any number of additional space characters between
> >     and .
> For the sake of the argument (at least having this on the mailing lis=
t
> as reference):
> =

> =A0  should be aligned at a common offset for all sibling nodes=

> =A0 from the start of  by adding trailing spaces. The recommend=
ed
> =A0 offset is 3 plus the length of the longest node name among all
> sibling nodes
> =A0 including those siblings defined under choice and case nodes.
> =

> This is what pyang does now. It is not a perfect solution but it
> allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

  1) allow any number of addtional spaces
  2) allow any number of addtional spaces + define a suggested
     alignment algorithm
  3) mandate the alignment algorithm


/martin


From nobody Tue Jan 16 07:43: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 41D6213159A for ; Tue, 16 Jan 2018 07:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 WmogEhhRmxrf for ; Tue, 16 Jan 2018 07:43:45 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 B0EB813155A for ; Tue, 16 Jan 2018 07:43:17 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 4790C1E17CC for ; Tue, 16 Jan 2018 08:18:28 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id z3JQ1w0052SSUrH013JTmQ; Tue, 16 Jan 2018 08:18:28 -0700
X-Authority-Analysis: v=2.2 cv=CqXPSjwD c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=5awoqvzuvkKRslJaNPYA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WLVtr4IjZ/LZk+oe+exNOJ/6dQomKQYp4Bwppw4R0Yo=; b=MrNxTzwo889IbTwgzU8KFT0+a4 7kfAu47Fgg3I3pKuWoA85Ra5Gwbc+1S6lS+9jWZD8uNk77ViD31My99sN6V0/I/R42EUNWSTR57sz YbEtYfUbfjiPDp1gWDiZel68C;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51170 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebT0J-003yt1-Rh; Tue, 16 Jan 2018 08:18:23 -0700
To: Vladimir Vassilev , Martin Bjorklund 
Cc: netmod@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <20180116.115606.561861432247288407.mbj@tail-f.com> 
From: Lou Berger 
Message-ID: 
Date: Tue, 16 Jan 2018 10:18:22 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
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-Exim-ID: 1ebT0J-003yt1-Rh
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]:51170
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:43:47 -0000

On 1/16/2018 10:08 AM, Vladimir Vassilev wrote:
>>> 4. This bit I found confusing. I propose this change to unambiguously
>>> describe the current pyang format.
>>>
>>> OLD:
>>>            *  for a leaf-list or list
>>>            [] for a list's keys
>>> NEW:
>>>            *  for a leaf-list or list without keys
>>>            * [] for a list with keys
>> Hmm, wouldn't it be better to use [] for a list w/o keys?
> Yes I also agree this improves readability at the cost of slight
> redundancy increase and modification to format of diagrams already used
> in RFCs. Your call.
>
> Vladimir

(as contributor) I agree with martin on this point.

Lou


From nobody Tue Jan 16 07:47:00 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 D840013152C for ; Tue, 16 Jan 2018 07:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 zVQFChKXCbIE for ; Tue, 16 Jan 2018 07:46:55 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 4860C12FAC8 for ; Tue, 16 Jan 2018 07:46:26 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id EA310140528 for ; Tue, 16 Jan 2018 08:46:25 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id z3mN1w0182SSUrH013mRmP; Tue, 16 Jan 2018 08:46:25 -0700
X-Authority-Analysis: v=2.2 cv=CqXPSjwD c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=tAv7CelNV0ADJ-CClv0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1oio9udTb8yLcReNCHP+mXdAcSXIli6HrZ8aL5Uk61M=; b=CmhfHGN0TZjBcOUh0KAe29DfNo 9m/MiRPcrUzp2EprPskXU/+AlavjMitf1bB16SDY1xeN9Q61tFcB8owWUPfyrKb1+mDJNJtkw1em1 lH8UZaQtylNwPwn010cXCrXau;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:53488 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebTRO-00478V-LH; Tue, 16 Jan 2018 08:46:22 -0700
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <1516116166.18487.18.camel@nic.cz>
From: Lou Berger 
Message-ID: <8f131d74-878a-6edb-a09c-6047b83dc6de@labn.net>
Date: Tue, 16 Jan 2018 10:46:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516116166.18487.18.camel@nic.cz>
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-Exim-ID: 1ebTRO-00478V-LH
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]:53488
X-Source-Auth: lberger@labn.net
X-Email-Count: 14
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:46:58 -0000

On 1/16/2018 10:22 AM, Ladislav Lhotka wrote:
>>> I think
>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>> this case, inline schema being represented by YL) to argue why the
>>> decision needs to be revisited.
>> I'm repeating my self: b/c the current solution doesn't work well with
>> the NMDA.
> We can try to update the draft and the examples, it should then be much more
> clear. It is really very little extra work.
>
> Lada
>

Lada,
     Understanding impact of your proposal on the following would be 
quite helpful:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub requested)
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub requested)
https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/

Lou



From nobody Tue Jan 16 07:50: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 EEA51126CF6 for ; Tue, 16 Jan 2018 07:50:23 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 k0K3oUbUoTb4 for ; Tue, 16 Jan 2018 07:50:16 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5512D833 for ; Tue, 16 Jan 2018 07:50:16 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 3266B1AE0399; Tue, 16 Jan 2018 16:50:15 +0100 (CET)
Date: Tue, 16 Jan 2018 16:50:14 +0100 (CET)
Message-Id: <20180116.165014.297580929914718463.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net>
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:50:24 -0000

Lou Berger  wrote:
> =

> =

> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> ... (trimming to topic)
> >>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts=
 already
> >>>>>>>> with
> >>>>>>> No at all. The first and last time I proposed this was on 15 =
December
> >>>>>>> 2017:
> >>>>>>>
> >>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753=
.html
> >>>>>>>
> >>>>>> Oh, I certainly would call you proposing that the schema for i=
nline be
> >>>>>> part of the rest of the schema Mount module well before that. =
I'm sure
> >>>>>> I can dig up mail / slides it really necessary...
> >>>>> I don't think this has been proposed before.  All previous prop=
osals
> >>>>> were basically variants on what is now "use-schema", which work=
s fine
> >>>>> when all instances have the same schema.  This new proposal sol=
ves the
> >>>>> issue with different schemas in different instances.
> >>>>>
> >>>> I thought the previous proposals that as well, so don't see mate=
rial
> >>>> difference - at least from the usage standpoint. I also don't se=
e why
> >>>> the previous arguments that resulted in consensus for using Yang=

> >>>> Library underneath the an in line Mount Point don't apply.
> >>> B/c it doesn't work well with the NMDA.  You can't mount yang lib=
rary
> >>> in the configuration datastores; it has to be mounted in operatio=
nal.
> >>> With meta-data, you can actually report the correct schema even i=
n
> >>> running.  (This is actually true also for pre-NMDA systems).
> >>>
> >> Understood and agree there is nothing new here and the current ver=
sion
> >> of SM (including inline) has the same limitation as rfc7895, and I=
'd
> >> expect it to behave the same once we have rfc7985bis -- in fact th=
e
> >> inline case "just works" with YL-bis as defined today.
> Martin,
> =

> you didn't respond to this point.

I agree, it works for non-NMDA servers. But see below.

> >> The argument I recall being the key point on inline was handling t=
he
> >> large variety of possible different implementation approaches for
> >> modules using inline.
> > I think these still are covered.
> >
> >> For example an LNE that is implemented using
> >> VMs which can be managed by the host at different times of the VMs=

> >> operational life cycle based on customer/provider requirements.=A0=
 I
> >> really don't see how YL-bis has any bearing on this point and
> > Using the new proposed meta data annotation together with the new Y=
L
> > means that SM can support the use case above also in an NMDA server=
.=

> > I think the new proposed solution covers more use cases than the
> > previous solution.
> =

> how so?=A0 The inline mount point would contain YL-bis and have the s=
ame
> information there, just scoped for the mount point.=A0 It's true a
> client would need to understand the mount point's schema only upon
> parsing the YL under the mount point and this schema could not be
> shared across inline mount points.=A0 But this is as was discussed in=

> the past and unchanged from YL.
> =

> > Do you think that there is any use case that the proposed solution
> > cannot handle, but the previous solution did?
> yes.=A0 with VM/container technologies the YL / schema can change und=
er
> the mount point from time to time during normal operation (i.e.,
> during runtime, no reboot) and, in some implementations, may require
> some level of rpc operation to access even the schema.=A0 The new (an=
d
> previously proposed approach) of having inline schema available from
> the top level greatly complicates these cases.=A0 Also keep in mind t=
hat
> there will be cases where the ability to access information under an
> inline mount point will dynamically change in operation (and top leve=
l
> YL would need to remove schema information for the inline mount
> point.)=A0 As before, from the usage standpoint, these changes don't
> provide a whole lot of value and seem to optimizing for something not=

> needed in the inline case.

I think this is an implementation issue, rather than a problem with
the proposed mechanism, and it is present in the current solution as
well.  An implementation that can handle dynamically changing mounted
YLs in the current solution can do that in the new solution as well.

> >> I think
> >> it is incumbent upon those revisiting past/closed WG decisions (in=

> >> this case, inline schema being represented by YL) to argue why the=

> >> decision needs to be revisited.
> > I'm repeating my self: b/c the current solution doesn't work well w=
ith
> > the NMDA.
> I simply don't understand how YL-bis works at the root node but
> doesn't work equally at an inline mount point.=A0 Can you elaborate?

With NMDA, a server may have one schema for the config datastore and
another one for operational (one is a superset of the other).  A
mounted YL can only be present in operational.  Thus, there's no way a
client can learn the schema for config.

With the proposed solution, there can be different schema-ref pointers
in config and operational (if needed).


/martin


From nobody Tue Jan 16 07:56:07 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 A0A8913155F for ; Tue, 16 Jan 2018 07:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 EdxCD8DLXYQG for ; Tue, 16 Jan 2018 07:56:01 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 883EF12D833 for ; Tue, 16 Jan 2018 07:55:58 -0800 (PST)
Received: from birdie (cst-prg-6-126.cust.vodafone.cz [46.135.6.126]) by mail.nic.cz (Postfix) with ESMTPSA id 592FB646A8; Tue, 16 Jan 2018 16:55:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516118156; bh=13jCBYh4AUt2umx/hnuNu8xG6oRBt+VhWydpBKnSr+k=; h=From:To:Date; b=ZHmXCTDCFiTX1IbNn5kZARYKxr/j5/ez/LNrrVOR/vFTKGykoxlJW9RyuLuGD8xzn 6C1qSg6OD7pOGd8kzSpESx/NqVuFqB/P2ylT8z+yKI9NqpjRGAGnOrJahnsTlbnzwT WJK4Psv6YSkRzWtKoHFWoKr6vhmQ7+x5Ig7GYG7M=
Message-ID: <1516118150.18487.33.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Tue, 16 Jan 2018 16:55:50 +0100
In-Reply-To: <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net>
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 15:56:03 -0000

On Tue, 2018-01-16 at 10:34 -0500, Lou Berger wrote:
> 
> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> ... (trimming to topic)
> > > > > > > > > rejectected by the WG multiple times.  FWIW there are drafts
> > > > > > > > > already
> > > > > > > > > with
> > > > > > > > 
> > > > > > > > No at all. The first and last time I proposed this was on 15
> > > > > > > > December
> > > > > > > > 2017:
> > > > > > > > 
> > > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.ht
> > > > > > > > ml
> > > > > > > > 
> > > > > > > 
> > > > > > > Oh, I certainly would call you proposing that the schema for
> > > > > > > inline be
> > > > > > > part of the rest of the schema Mount module well before that. I'm
> > > > > > > sure
> > > > > > > I can dig up mail / slides it really necessary...
> > > > > > 
> > > > > > I don't think this has been proposed before.  All previous proposals
> > > > > > were basically variants on what is now "use-schema", which works
> > > > > > fine
> > > > > > when all instances have the same schema.  This new proposal solves
> > > > > > the
> > > > > > issue with different schemas in different instances.
> > > > > > 
> > > > > 
> > > > > I thought the previous proposals that as well, so don't see material
> > > > > difference - at least from the usage standpoint. I also don't see why
> > > > > the previous arguments that resulted in consensus for using Yang
> > > > > Library underneath the an in line Mount Point don't apply.
> > > > 
> > > > B/c it doesn't work well with the NMDA.  You can't mount yang library
> > > > in the configuration datastores; it has to be mounted in operational.
> > > > With meta-data, you can actually report the correct schema even in
> > > > running.  (This is actually true also for pre-NMDA systems).
> > > > 
> > > 
> > > Understood and agree there is nothing new here and the current version
> > > of SM (including inline) has the same limitation as rfc7895, and I'd
> > > expect it to behave the same once we have rfc7985bis -- in fact the
> > > inline case "just works" with YL-bis as defined today.
> 
> Martin,
> 
> you didn't respond to this point.
> 
> > > The argument I recall being the key point on inline was handling the
> > > large variety of possible different implementation approaches for
> > > modules using inline.
> > 
> > I think these still are covered.
> > 
> > > For example an LNE that is implemented using
> > > VMs which can be managed by the host at different times of the VMs
> > > operational life cycle based on customer/provider requirements.  I
> > > really don't see how YL-bis has any bearing on this point and
> > 
> > Using the new proposed meta data annotation together with the new YL
> > means that SM can support the use case above also in an NMDA server.
> > I think the new proposed solution covers more use cases than the
> > previous solution.
> 
> how so?  The inline mount point would contain YL-bis and have the same 
> information there, just scoped for the mount point.  It's true a client

As Martin already wrote, this cannot be done for in config datastores.

>  
> would need to understand the mount point's schema only upon parsing the 
> YL under the mount point and this schema could not be shared across 
> inline mount points.  But this is as was discussed in the past and 
> unchanged from YL.
> 
> > Do you think that there is any use case that the proposed solution
> > cannot handle, but the previous solution did?
> 
> yes.  with VM/container technologies the YL / schema can change under 
> the mount point from time to time during normal operation (i.e., during 
> runtime, no reboot) and, in some implementations, may require some level 
> of rpc operation to access even the schema.  The new (and previously 
> proposed approach) of having inline schema available from the top level 
> greatly complicates these cases.  Also keep in mind that there will be

Why? I assume that new schemas can be added as entries of the parent YL "schema"
list even at runtime. So you just do it, and change the @schema-ref leafref with
which the mount point instance undergoing the change is annotated.

> cases where the ability to access information under an inline mount 
> point will dynamically change in operation (and top level YL would need 
> to remove schema information for the inline mount point.)  As before, 
> from the usage standpoint, these changes don't provide a whole lot of 
> value and seem to optimizing for something not needed in the inline case.
> 
> > > I think
> > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > this case, inline schema being represented by YL) to argue why the
> > > decision needs to be revisited.
> > 
> > I'm repeating my self: b/c the current solution doesn't work well with
> > the NMDA.
> 
> I simply don't understand how YL-bis works at the root node but doesn't 
> work equally at an inline mount point.  Can you elaborate?

I propose that we update the schema mount draft in a separate branch on GitHub,
and then continue the discussion.

Lada 

> 
> Lou
> 
> > 
> > 
> > /martin
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Jan 16 08:01: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 4824612D7E2 for ; Tue, 16 Jan 2018 08:01:58 -0800 (PST)
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_RP_MATCHES_RCVD=-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 Y2Dvytvv-FCW for ; Tue, 16 Jan 2018 08:01:52 -0800 (PST)
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 A9A3612D833 for ; Tue, 16 Jan 2018 08:01:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2518; q=dns/txt; s=iport; t=1516118511; x=1517328111; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8SEMMdlzHv5a9eW5Kh2XKPJoqOAShjHXPGW5MBpVoxQ=; b=WCXg/ZxOCi+K1J5YGhERT4vGXmmFUsWLAVOdJmZO8EQdycSy1NLI31n9 UrDKRpbbTxGDeaGcnf4YG3mwvy8K1CUJ92hQ+f6dz39lx3NJKpVFGajng WLTez8sIdnPE0/XPAbJawLZZIl4TzgcukG+wqTQuWHzH+2A2y2ZFrbtob g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgA0IF5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMRgRZ0J4QTixiPRyeZQgoYC4RJTwKFHxQBAQEBAQEBAQFrKIU?= =?us-ascii?q?kAQEBAwEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBF4oYEKVIgieJSgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQ+HGYFpKQyCeYMvAQEChQaCZQWSJ5E9lUuMJYd?= =?us-ascii?q?rjxyICYE8NiKBUDIaCBsVPYIqhFdBN40/AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200";  d="scan'208";a="1482317"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 16:01:49 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0GG1mCX002666; Tue, 16 Jan 2018 16:01:49 GMT
To: Martin Bjorklund , vladimir@transpacket.com
Cc: netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 16 Jan 2018 16:01:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180116.164053.2123534827829006518.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 16:01:58 -0000

On 16/01/2018 15:40, Martin Bjorklund wrote:
> Vladimir Vassilev  wrote:
>> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
>>
>>> Vladimir Vassilev  wrote:
> [...]
>
>>>> There is also undocumented alignment space count function before
>>>>  that pyang uses to align the  fields of child data leafs
>>>> with common ancestor. If this is specified in the draft the tree
>>>> output can be deterministic and for me this is an advantage. This is
>>>> currently one of the few underspecified pieces of the tree format so I
>>>> had to check pyang implementation in oder to generate same alignment
>>>> space counts and binary identical tree output results.
>>> I think that we at least should write that there may be more than one
>>> space between  and :
>>>
>>>     There may be any number of additional space characters between
>>>      and .
>> For the sake of the argument (at least having this on the mailing list
>> as reference):
>>
>>     should be aligned at a common offset for all sibling nodes
>>    from the start of  by adding trailing spaces. The recommended
>>    offset is 3 plus the length of the longest node name among all
>> sibling nodes
>>    including those siblings defined under choice and case nodes.
>>
>> This is what pyang does now. It is not a perfect solution but it
>> allows identical output down to the bit.
> Does anyone else have an opinion on this?  I can see three
> alternatives:
>
>    1) allow any number of addtional spaces
>    2) allow any number of addtional spaces + define a suggested
>       alignment algorithm
>    3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers can 
consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft should 
provide guideline to ensure the output is readable, and likely to be 
broadly consistent (since consistency aids readability).

If the IETF data modeling group is trying to specify text output 
precisely enough that it can be screen scraped then we may want to 
consider whether we are focusing on the right solution ;-)

In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob

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


From nobody Tue Jan 16 08:16: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 CEA3912DDD2 for ; Tue, 16 Jan 2018 08:16:03 -0800 (PST)
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_RP_MATCHES_RCVD=-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 ScNaRwYi-2Uw for ; Tue, 16 Jan 2018 08:16:02 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE4312DB72 for ; Tue, 16 Jan 2018 08:16:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5949; q=dns/txt; s=iport; t=1516119361; x=1517328961; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NJbcYCgV4MnOgSvRmF5QUG/LlhtnOikPZ33tOTuBHbE=; b=nI4vAMKrTKJtoXy/LyQVIjCeTLPiMhHZFeLagOsqORTYxVazfryNtK4d 7QonKa5MFB8ISGyDLSiSMXj+KiM0V8hNNOPX8PT6NDXsCFunhURwM7ooT sGUMwVkQJCgs9tIq2fpi4QYP33E8HlMszaszQgonBaEo6KuWakJBVmGcS s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAQACJV5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYjTeCN5lCChgLhElPAoUfFAEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEBAgEBASEPAQU2CxALDgoCAiYCAicwBgEMBgIBARUCihAIEKVEgieJSgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+HGYFpKYMFglFeAQEBAYFPAQEIgy2CZQW?= =?us-ascii?q?jZJVLjCWHa48ciAmBPDYigVAyGggbFT2CKoJUHIFnQTcBiwKCPAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,369,1511827200";  d="scan'208";a="1431038"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 16:15:57 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0GGFvEC002837; Tue, 16 Jan 2018 16:15:57 GMT
To: Martin Bjorklund , lberger@labn.net
Cc: netmod@ietf.org
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 16 Jan 2018 16:15:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180116.165014.297580929914718463.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 16:16:04 -0000

On 16/01/2018 15:50, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
>> ... (trimming to topic)
>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts already
>>>>>>>>>> with
>>>>>>>>> No at all. The first and last time I proposed this was on 15 December
>>>>>>>>> 2017:
>>>>>>>>>
>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>>>>>>>>>
>>>>>>>> Oh, I certainly would call you proposing that the schema for inline be
>>>>>>>> part of the rest of the schema Mount module well before that. I'm sure
>>>>>>>> I can dig up mail / slides it really necessary...
>>>>>>> I don't think this has been proposed before.  All previous proposals
>>>>>>> were basically variants on what is now "use-schema", which works fine
>>>>>>> when all instances have the same schema.  This new proposal solves the
>>>>>>> issue with different schemas in different instances.
>>>>>>>
>>>>>> I thought the previous proposals that as well, so don't see material
>>>>>> difference - at least from the usage standpoint. I also don't see why
>>>>>> the previous arguments that resulted in consensus for using Yang
>>>>>> Library underneath the an in line Mount Point don't apply.
>>>>> B/c it doesn't work well with the NMDA.  You can't mount yang library
>>>>> in the configuration datastores; it has to be mounted in operational.
>>>>> With meta-data, you can actually report the correct schema even in
>>>>> running.  (This is actually true also for pre-NMDA systems).
>>>>>
>>>> Understood and agree there is nothing new here and the current version
>>>> of SM (including inline) has the same limitation as rfc7895, and I'd
>>>> expect it to behave the same once we have rfc7985bis -- in fact the
>>>> inline case "just works" with YL-bis as defined today.
>> Martin,
>>
>> you didn't respond to this point.
> I agree, it works for non-NMDA servers. But see below.
>
>>>> The argument I recall being the key point on inline was handling the
>>>> large variety of possible different implementation approaches for
>>>> modules using inline.
>>> I think these still are covered.
>>>
>>>> For example an LNE that is implemented using
>>>> VMs which can be managed by the host at different times of the VMs
>>>> operational life cycle based on customer/provider requirements.  I
>>>> really don't see how YL-bis has any bearing on this point and
>>> Using the new proposed meta data annotation together with the new YL
>>> means that SM can support the use case above also in an NMDA server.
>>> I think the new proposed solution covers more use cases than the
>>> previous solution.
>> how so?  The inline mount point would contain YL-bis and have the same
>> information there, just scoped for the mount point.  It's true a
>> client would need to understand the mount point's schema only upon
>> parsing the YL under the mount point and this schema could not be
>> shared across inline mount points.  But this is as was discussed in
>> the past and unchanged from YL.
>>
>>> Do you think that there is any use case that the proposed solution
>>> cannot handle, but the previous solution did?
>> yes.  with VM/container technologies the YL / schema can change under
>> the mount point from time to time during normal operation (i.e.,
>> during runtime, no reboot) and, in some implementations, may require
>> some level of rpc operation to access even the schema.  The new (and
>> previously proposed approach) of having inline schema available from
>> the top level greatly complicates these cases.  Also keep in mind that
>> there will be cases where the ability to access information under an
>> inline mount point will dynamically change in operation (and top level
>> YL would need to remove schema information for the inline mount
>> point.)  As before, from the usage standpoint, these changes don't
>> provide a whole lot of value and seem to optimizing for something not
>> needed in the inline case.
> I think this is an implementation issue, rather than a problem with
> the proposed mechanism, and it is present in the current solution as
> well.  An implementation that can handle dynamically changing mounted
> YLs in the current solution can do that in the new solution as well.
>
>>>> I think
>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>> this case, inline schema being represented by YL) to argue why the
>>>> decision needs to be revisited.
>>> I'm repeating my self: b/c the current solution doesn't work well with
>>> the NMDA.
>> I simply don't understand how YL-bis works at the root node but
>> doesn't work equally at an inline mount point.  Can you elaborate?
> With NMDA, a server may have one schema for the config datastore and
> another one for operational (one is a superset of the other).  A
> mounted YL can only be present in operational.  Thus, there's no way a
> client can learn the schema for config.
If the LNE mounted the full YL-bis at the mount point then you would 
have the list of datastores, and the schema associated with each 
datastore.  Of course, this would only be available in operational, but 
that is the same as a regular server support YL-bis.

I thought that the problem with the current solution and NMDA, was that 
there is no way to find out what the LNE schema is if the LNE isn't 
booted, and hence isn't providing .  But I'm not sure what 
issues that actually causes.  E.g. does it cause issues with 
pre-configuration of the LNE?

Thanks,
Rob


>
> With the proposed solution, there can be different schema-ref pointers
> in config and operational (if needed).
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Jan 16 08:59:10 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 3331212FB12 for ; Tue, 16 Jan 2018 08:59:09 -0800 (PST)
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 jEF4Pgq_e0O5 for ; Tue, 16 Jan 2018 08:59:07 -0800 (PST)
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 4AB9712AAB6 for ; Tue, 16 Jan 2018 08:59:07 -0800 (PST)
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 w0GGuIVD005034 for ; Tue, 16 Jan 2018 08:59:07 -0800
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=lhwyJBxKSY2TkxrfyGYBJGAp5m/hSNvaG1Mi+diKTb4=; b=kz8hlANrHg7Zp4G8tdiKa6+fbke4jNfRHktvhn5mOPqBBMvvqmRflPVQ6uJ12OGwgz4M I1D6q+hiNvHntFHEcTK3fUxy/o6Z+67jaQiB/Od6AJOd9mPzCruisAE3sQ13aX16YAig SycWaUg2YRg72ObRkOwYQANmSBf21cwRRiW05thttTXoMon8Bdw9P6OCGiFMiYrdnoal bVw7DSyemAq98LN3WAJzdujY8VHcYQ1wbZyzFoT1Ct//G4xAshnl02KU+4lfbwSdFpy1 ZkXmlOV/nmWArfC9WuWMk4SfOnCbsV8mYCHhVR01k9a2zGUwKl4DlaQf6wHY5V1HjASm 4A== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0a-00273201.pphosted.com with ESMTP id 2fhna8013m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 16 Jan 2018 08:59:06 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3033.namprd05.prod.outlook.com (10.168.177.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Tue, 16 Jan 2018 16:59:04 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Tue, 16 Jan 2018 16:59:04 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
Thread-Index: AQHTi/jgm64n1kE5c0S5iq2VpQaBSqN2at0A
Date: Tue, 16 Jan 2018 16:59:04 +0000
Message-ID: 
References: <151579789446.21777.985631371557420470@ietfa.amsl.com>
In-Reply-To: <151579789446.21777.985631371557420470@ietfa.amsl.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.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3033; 7:FpUJwACBInk834cxXUgI34+Mq2+7W+j7eejbfspvrP8grybJwoHHR7VeEStCyr1VTqVXT7Dh+LnmT2PQa48+rcxqO/tQtUReJstTnfAodEMrru9adaG/IugFkDuUYV/BdD2gRCGZPMMVDxQ94cn4ZmBvoGwn47lqXCePB7Epj6CLxeJfPs/xJZ232Yv8UAOmC1gE4cogLTgyrUliMJn8PwSe/n910ks10Tb7GichwISFSr1ssG4ZAbrRytIjDcI3
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9efb4f18-c151-408a-1f23-08d55d02735b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3033; 
x-ms-traffictypediagnostic: DM5PR05MB3033:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(2400037)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041268)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3033; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR05MB3033; 
x-forefront-prvs: 0554B1F54F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(39380400002)(396003)(189003)(199004)(81166006)(230783001)(8676002)(36756003)(99286004)(1730700003)(53936002)(14454004)(8936002)(25786009)(2950100002)(6916009)(6512007)(86362001)(6306002)(5660300001)(6486002)(81156014)(966005)(77096006)(2900100001)(6246003)(5640700003)(478600001)(83716003)(6116002)(6436002)(229853002)(3846002)(2906002)(66066001)(3660700001)(105586002)(59450400001)(6506007)(316002)(3280700002)(102836004)(106356001)(2501003)(97736004)(82746002)(26005)(305945005)(2351001)(7736002)(58126008)(76176011)(83506002)(33656002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3033; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MIS3uvVZ+eaVbDEtl4XEvg4UiSimyzUpZ8OT/EIhXFVoZyGj6ca88fTrvryOoyl6DvaCidZu2pbyL0TO1NG9pw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <43245C34B55F2640AC48D4F285789059@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9efb4f18-c151-408a-1f23-08d55d02735b
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2018 16:59:04.8681 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3033
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-16_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-1711220000 definitions=main-1801160234
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 16:59:09 -0000

Q2x5ZGUsDQoNClRoaXMgZHJhZnQgc3RpbGwgaXNuJ3QgcGFzc2luZyBpZG5pdHMuICBJIHByb3Zp
ZGVkIHRoZSBsaW5rIHRvIGlkbml0cyBwcmV2aW91c2x5LCBidXQgaGVyZSBpdCBpcyBhZ2Fpbjog
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLiAgQmVsb3cgaXMgdGhlIGlkbml0cyBv
dXRwdXQgZm9yIC0xOSB3aXRoIGlubGluZWQgY29tbWVudHMuDQoNClBTOiBJIGRpZG4ndCBhbHNv
IGNoZWNrZWQgdGhlIG90aGVyIGlzc3VlcyB3ZSdyZSB0cmFja2luZywgYnV0IHdpbGwgd2hlbiB3
ZSBnZXQgcGFzdCB0aGVzZSBpZG5pdHMgaXNzdWVzLg0KDQpLZW50DQoNCg0KPT09PT0gU1RBUlQg
PT09PT0NCmlkbml0cyAyLjE1LjAwIA0KDQovdG1wL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1t
b2RlbC0xOS50eHQ6DQoNCiAgQ2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUz
NzggYW5kIHRoZSBJRVRGIFRydXN0IChzZWUNCiAgaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xp
Y2Vuc2UtaW5mbyk6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICBObyBpc3N1ZXMgZm91
bmQgaGVyZS4NCg0KICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwczovL3d3dy5pZXRm
Lm9yZy9pZC1pbmZvLzFpZC1ndWlkZWxpbmVzLnR4dDoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQogICAgIE5vIGlzc3VlcyBmb3VuZCBoZXJlLg0KDQogIENoZWNraW5nIG5pdHMgYWNjb3JkaW5n
IHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoNCiAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KDQogICoqIFRoZXJlIGlzIDEgaW5zdGFuY2Ugb2YgdG9vIGxvbmcgbGluZXMg
aW4gdGhlIGRvY3VtZW50LCB0aGUgbG9uZ2VzdCBvbmUNCiAgICAgYmVpbmcgMSBjaGFyYWN0ZXIg
aW4gZXhjZXNzIG9mIDcyLg0KDQpLZW50OiB0aGlzIGlzbid0IGEgYmlnIGRlYWwgSU1PLCBidXQg
aWYgaXQncyBlYXN5IHRvIGZpeCwgaXQgc2F2ZXMgdGhlIFJGQyBlZGl0b3IgYSBzdGVwIGxhdGVy
IG9uLg0KDQoNCiAgTWlzY2VsbGFuZW91cyB3YXJuaW5nczoNCiAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQogID09IExpbmUgMzUyIGhhcyB3ZWlyZCBzcGFjaW5nOiAnLi4uZ29yaXRobSAgICBpZGUu
Li4nDQoNCktlbnQ6IHRoaXMgaXMgZmluZS4gIGl0IGlzIGluIGEgdHJlZSBkaWFncmFtLg0KDQoN
CiAgPT0gVGhlIGRvY3VtZW50IHNlZW1zIHRvIGxhY2sgdGhlIHJlY29tbWVuZGVkIFJGQyAyMTE5
IGJvaWxlcnBsYXRlLCBldmVuIGlmDQogICAgIGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5IGtl
eXdvcmRzIC0tIGhvd2V2ZXIsIHRoZXJlJ3MgYSBwYXJhZ3JhcGggd2l0aA0KICAgICBhIG1hdGNo
aW5nIGJlZ2lubmluZy4gQm9pbGVycGxhdGUgZXJyb3I/DQoNCiAgICAgKFRoZSBkb2N1bWVudCBk
b2VzIHNlZW0gdG8gaGF2ZSB0aGUgcmVmZXJlbmNlIHRvIFJGQyAyMTE5IHdoaWNoIHRoZQ0KICAg
ICBJRC1DaGVja2xpc3QgcmVxdWlyZXMpLg0KDQpLZW50OiBJIGNhbid0IGZpbmQgdGhlIGVycm9y
LiAgTG9va2luZyBhdCB0aGUgeG1sLCBpdCBpcyB2ZXJiYXRpbSB3aGF0IEkgaGF2ZSBpbiB0aGUg
emVyb3RvdWNoIGRyYWZ0LiAgbXkgZ3Vlc3MgaXMgdGhhdCB0aGlzIGlzIGEgdG9vbGluZyBlcnJv
ciBhbmQgd2Ugc2hvdWxkIGlnbm9yZSBpdC4NCg0KDQogIC0tIFRoZSBkb2N1bWVudCBkYXRlIChK
YW51YXJ5IDEyLCAyMDE4KSBpcyA0IGRheXMgaW4gdGhlIHBhc3QuICBJcyB0aGlzDQogICAgIGlu
dGVudGlvbmFsPw0KDQpLZW50OiB0aGlzIGlzIGZpbmUsIGl0IGlzIGludGVudGlvbmFsLg0KDQoN
CiAgQ2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFu
ZGFyZA0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgKFNlZSBSRkNzIDM5NjcgYW5kIDQ4
OTcgZm9yIGluZm9ybWF0aW9uIGFib3V0IHVzaW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzDQogICAg
IHRvIGxvd2VyLW1hdHVyaXR5IGRvY3VtZW50cyBpbiBSRkNzKQ0KDQogID09IFVudXNlZCBSZWZl
cmVuY2U6ICdJLUQuaWV0Zi1uZXRjb25mLWtleXN0b3JlJyBpcyBkZWZpbmVkIG9uIGxpbmUgMTM4
NiwNCiAgICAgYnV0IG5vIGV4cGxpY2l0IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQN
Cg0KS2VudDogbG9va2luZyBhdCB0aGUgWE1MLCBJIHNlZSB0aGF0IHRoZSBlbnRpcmUgcGFyYWdy
YXBoIHVzZXMgJ1snIGFuZCAnXScgYXMgb3Bwb3NlZCB0byA8eHJlZiAuLi4vPi4gIFBsZWFzZSBm
aXggdGhpcy4NCg0KDQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM3ODk1JyBpcyBkZWZpbmVk
IG9uIGxpbmUgMTQ1NiwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQg
aW4gdGhlIHRleHQNCg0KS2VudDogbG9va2luZyBhdCB0aGUgWE1MLCBJIHNlZSB0d28gaW5zdGFu
Y2VzIG9mIGFuIHVud2FudGVkICIvJmd0OyIgc3RyaW5nLiAgRm9yIGluc3RhbmNlOiA8eHJlZiB0
YXJnZXQ9IlJGQzc4OTUiLz4vJmd0OyAgUGxlYXNlIGZpeCB0aGlzLg0KDQoNCiAgKiogRG93bnJl
ZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQyA2NTg3DQoNCktl
bnQ6IGhtbW0sIHdoYXQncyBnb2luZyBvbiBoZXJlPyAgVGhpcyBZQU5HIG1vZHVsZSBpcyBwcm92
aWRpbmcgYW4gYWJpbGl0eSB0byBjb25maWd1cmUgdGhlICJ0Y3AiIHRyYW5zcG9ydCwgZXZlbiB0
aG91Z2ggdGhlIElFU0cgbWFkZSB0aGF0IGFiaWxpdHkgaGlzdG9yaWMgaW4gMjAxMiAoc2VlIElF
U0cgTm90ZSBiZWxvdykuICBTZWFyY2hpbmcgb25saW5lLCBpdCBsb29rcyBsaWtlIENpc2NvIHN1
cHBvcnRzIHRoaXMsIGJ1dCBKdW5pcGVyIGRvZXMgbm90LiAgV2hhdCBhYm91dCBvdGhlciB2ZW5k
b3JzLCBpcyBpdCB3aWRlbHkgc3VwcG9ydGVkPyAgV2FzIHRoaXMgZGlzY3Vzc2VkIGluIHRoZSBX
Rz8gIEFuc3dlcmluZyBteSBvd24gcXVlc3Rpb24sIHNlYXJjaGluZyBteSBsb2NhbCBtYWlsYm94
LCBJIGRvbid0IHNlZSB0aGlzIGV2ZXIgYmVpbmcgZGlzY3Vzc2VkIGJlZm9yZSwgb3RoZXIgdGhh
biBNYXJ0aW4gcXVlc3Rpb25pbmcgaWYgaXQgd2FzIGEgZ29vZCBpZGVhIGluIE1hciAyMDE2IChu
byByZXNwb25zZSkuICBQbGVhc2Ugc3RhcnQgYSB0aHJlYWQgb24gdGhlIGxpc3QgdG8gZ2V0IFdH
IG9waW5pb24gaWYgaXQncyBva2F5IGZvciB0aGUgZHJhZnQgdG8gcHJvY2VlZCBhcyBpcyBvciBu
b3QuICBIZXJlJ3MgdGhlIElFU0cgTm90ZSBmcm9tIFJGQyA2NTg3Og0KDQogICBJRVNHIE5vdGUN
Cg0KICAgVGhlIElFU0cgZG9lcyBub3QgcmVjb21tZW5kIGltcGxlbWVudGluZyBvciBkZXBsb3lp
bmcgc3lzbG9nIG92ZXINCiAgIHBsYWluIHRjcCwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIHRoaXMg
ZG9jdW1lbnQsIGJlY2F1c2UgaXQgbGFja3MgdGhlDQogICBhYmlsaXR5IHRvIGVuYWJsZSBzdHJv
bmcgc2VjdXJpdHkgW1JGQzMzNjVdLg0KDQogICBJbXBsZW1lbnRhdGlvbiBvZiB0aGUgVExTIHRy
YW5zcG9ydCBbUkZDNTQyNV0gaXMgcmVjb21tZW5kZWQgc28gdGhhdA0KICAgYXBwcm9wcmlhdGUg
c2VjdXJpdHkgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRvcnMgd2hvIHdhbnQgdG8N
CiAgIGRlcGxveSBzZWN1cmUgc3lzbG9nLiAgU2ltaWxhcmx5LCB0aG9zZSBzZWN1cml0eSBmZWF0
dXJlcyBjYW4gYmUNCiAgIHR1cm5lZCBvZmYgZm9yIHRob3NlIHdobyBkbyBub3Qgd2FudCB0aGVt
Lg0KDQoNCg0KDQoNCiAgICAgU3VtbWFyeTogMiBlcnJvcnMgKCoqKSwgMCBmbGF3cyAofn4pLCA0
IHdhcm5pbmdzICg9PSksIDEgY29tbWVudCAoLS0pLg0KDQogICAgIFJ1biBpZG5pdHMgd2l0aCB0
aGUgLS12ZXJib3NlIG9wdGlvbiBmb3IgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhYm91dA0K
ICAgICB0aGUgaXRlbXMgYWJvdmUuDQo9PT09PSBFTkQgPT09PT0NCg0KVGhhbmtzLA0KS2VudCAv
LyBzaGVwaGVyZA0KDQoNCg0K


From nobody Tue Jan 16 09:22: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 6E56B12D833 for ; Tue, 16 Jan 2018 09:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 wtsqloQx4Z3D for ; Tue, 16 Jan 2018 09:22:14 -0800 (PST)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 414DD126DFB for ; Tue, 16 Jan 2018 09:22:14 -0800 (PST)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id F1A20175C27 for ; Tue, 16 Jan 2018 10:22:13 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id z5NA1w00T2SSUrH015NDPr; Tue, 16 Jan 2018 10:22:13 -0700
X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=HezPT-qgJyWz8boQbkgA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=o79a8CcnL+dOpFuxc5w7R+gpu3cgv0+FmzTkGHg72RI=; b=crYVtrW4lGfumZd3NDHxKJKzCp HFA/s3a4afz1OaJPvda1P2YPwKBYyQlfM3G3J6/wB8wnJk3sCv3ocsr1tfDy6OsTwYEf7ypZJtKHN zE8+TD/9kkiGMX9aVHztAqDil;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:33850 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebUw6-000B84-46; Tue, 16 Jan 2018 10:22:10 -0700
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <1516118150.18487.33.camel@nic.cz>
From: Lou Berger 
Message-ID: 
Date: Tue, 16 Jan 2018 12:22:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516118150.18487.33.camel@nic.cz>
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-Exim-ID: 1ebUw6-000B84-46
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]:33850
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 17:22:15 -0000

That's a fine idea, but ultimately we'll need to discuss/understand the 
impact to the other dependent drafts, including the two already with the 
IESG.  If you can look at those and comment now, that would be helpful.

Lou


On 1/16/2018 10:55 AM, Ladislav Lhotka wrote:
> I propose that we update the schema mount draft in a separate branch on GitHub,
> and then continue the discussion.


From nobody Tue Jan 16 09:23: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 714E312E059 for ; Tue, 16 Jan 2018 09:23:52 -0800 (PST)
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_RP_MATCHES_RCVD=-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 IGb1eX_pMZbE for ; Tue, 16 Jan 2018 09:23:51 -0800 (PST)
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 1297212E044 for ; Tue, 16 Jan 2018 09:23:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1352; q=dns/txt; s=iport; t=1516123431; x=1517333031; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=puW82ppZm4IYpuB7TVbpi8k9NT1I8n1qhlNIOuQhTtg=; b=Nz8Ivd1YhLYm0NQKJEBSxG4yP8ApHvfAPtEPjNW9uw6opdMk4J/nMXf2 h6BtJ1mPhgu4OYJfX2WFUsUvjkAfClMlm0x2L/5muKHVSaRyqrbuul7Bg FXiqhc9dvV2u+kAtES1D49xZaCshFvO6rLKfLjEKOLIZwhxOnXEbltgar 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQBvNF5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUbhDqLGI88mXQKhTsChR8UAQEBAQEBAQEBayiFJAYjFVELDgw?= =?us-ascii?q?CJgICVwYBDAgBAYovpSyCJ4lLAQEBAQEBAQMBAQEBAQEigQ+HGYFpKYMFhFslg?= =?us-ascii?q?zmCZQEEo2SVS4IZhh2Db4drjxyEWIMxgTw2IoFQMhoIGxU9giuEV0CKS4I8AQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.46,369,1511827200";  d="scan'208";a="1484902"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 17:23:47 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0GHNl4R032296; Tue, 16 Jan 2018 17:23:47 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <151579789446.21777.985631371557420470@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: 
Date: Tue, 16 Jan 2018 18:23:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 17:23:52 -0000

Hi,
>
>    ** Downref: Normative reference to an Historic RFC: RFC 6587
>
> Kent: hmmm, what's going on here?  This YANG module is providing an ability to configure the "tcp" transport, even though the IESG made that ability historic in 2012 (see IESG Note below).  Searching online, it looks like Cisco supports this, but Juniper does not.  What about other vendors, is it widely supported?  Was this discussed in the WG?  Answering my own question, searching my local mailbox, I don't see this ever being discussed before, other than Martin questioning if it was a good idea in Mar 2016 (no response).  Please start a thread on the list to get WG opinion if it's okay for the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:
>
>     IESG Note
>
>     The IESG does not recommend implementing or deploying syslog over
>     plain tcp, which is described in this document, because it lacks the
>     ability to enable strong security [RFC3365].
>
>     Implementation of the TLS transport [RFC5425] is recommended so that
>     appropriate security features are available to operators who want to
>     deploy secure syslog.  Similarly, those security features can be
>     turned off for those who do not want them.
>
>
>
Well, I believe it's clear plain TCP should not be in the YANG module.

Regards, Benoit


From nobody Tue Jan 16 09:24: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 4C7E2131453; Tue, 16 Jan 2018 09:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 uRrkinrYQeKV; Tue, 16 Jan 2018 09:24:18 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 12B8D12E893; Tue, 16 Jan 2018 09:24:13 -0800 (PST)
Received: from MBP.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0GHOCWt062321 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 16 Jan 2018 17:24:12 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be MBP.local
From: joel jaeggli 
To: NETMOD Working Group 
Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com> 
Message-ID: <1fcc0c28-4c99-c0c7-91ae-f2e3f0b009af@bogus.com>
Date: Tue, 16 Jan 2018 09:24:06 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 17:24:19 -0000

The current dicussion on the draft is not yet concluded. The WGLC will
conclude when discussion of the editorial changes is complete.

Thanks
joel

On 1/10/18 8:16 AM, joel jaeggli wrote:
> Just a reminder given the date that this was posted. This last call is
> expected to complete Monday 1/15/18.
>
> Thanks
>
> joel
>
>
> On 1/1/18 2:01 PM, joel jaeggli wrote:
>> Greetings,
>>
>> We hope  the new year is a time to make great progess on outstanding
>> documents before preparation for the  London IETF begins in earnest.
>>
>> This starts a two-week working group last call on:
>>
>>  YANG Tree Diagrams
>> draft-ietf-netmod-yang-tree-diagrams
>>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>
>> Please send email to the list indicating your support or concerns.
>>
>> We are particularly interested in statements of the form:
>>
>>   * I have reviewed this draft and found no issues.
>>   * I have reviewed this draft and found the following issues: ...
>>
>>
>> Thank you,
>> NETMOD WG Chairs
>>
>>
>>
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Tue Jan 16 09:32: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 E2ED712E036 for ; Tue, 16 Jan 2018 09:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 CWH2hfl0ya2R for ; Tue, 16 Jan 2018 09:32:17 -0800 (PST)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 40768124D6C for ; Tue, 16 Jan 2018 09:32:14 -0800 (PST)
Received: from cmgw2 (cmgw3 [10.0.90.83]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 0475D175BE3 for ; Tue, 16 Jan 2018 10:32:14 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id z5YA1w0082SSUrH015YDmr; Tue, 16 Jan 2018 10:32:13 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=C7WBV6Q5AnGmQvLs2mIA:9 a=QEXdDO2ut3YA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6Anm1X/Yax7VkWNEPELupRhgHsaL+LGMkrHn5CcBBAo=; b=gj8S+0Ec2oZPoGbSveRJ57Fg12 /BY3HMKJhholUwNTvBZEbYetRlIRF8e5b21/vYALZik71q/phqKEq65qW6b7rjqHuSgGQe2VGuR0t NdW+WZ2yrZ6as+0pBYA2nTIz+;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:34542 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebV5l-000Dp7-Sp; Tue, 16 Jan 2018 10:32:09 -0700
To: Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com> 
From: Lou Berger 
Message-ID: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net>
Date: Tue, 16 Jan 2018 12:32:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
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-Exim-ID: 1ebV5l-000Dp7-Sp
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]:34542
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 17:32:20 -0000

On 1/16/2018 11:15 AM, Robert Wilton wrote:
>
> On 16/01/2018 15:50, Martin Bjorklund wrote:
>> Lou Berger  wrote:
>>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
>>> ... (trimming to topic)
>>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts already
>>>>>>>>>>> with
>>>>>>>>>> No at all. The first and last time I proposed this was on 15 December
>>>>>>>>>> 2017:
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>>>>>>>>>>
>>>>>>>>> Oh, I certainly would call you proposing that the schema for inline be
>>>>>>>>> part of the rest of the schema Mount module well before that. I'm sure
>>>>>>>>> I can dig up mail / slides it really necessary...
>>>>>>>> I don't think this has been proposed before.  All previous proposals
>>>>>>>> were basically variants on what is now "use-schema", which works fine
>>>>>>>> when all instances have the same schema.  This new proposal solves the
>>>>>>>> issue with different schemas in different instances.
>>>>>>>>
>>>>>>> I thought the previous proposals that as well, so don't see material
>>>>>>> difference - at least from the usage standpoint. I also don't see why
>>>>>>> the previous arguments that resulted in consensus for using Yang
>>>>>>> Library underneath the an in line Mount Point don't apply.
>>>>>> B/c it doesn't work well with the NMDA.  You can't mount yang library
>>>>>> in the configuration datastores; it has to be mounted in operational.
>>>>>> With meta-data, you can actually report the correct schema even in
>>>>>> running.  (This is actually true also for pre-NMDA systems).
>>>>>>
>>>>> Understood and agree there is nothing new here and the current version
>>>>> of SM (including inline) has the same limitation as rfc7895, and I'd
>>>>> expect it to behave the same once we have rfc7985bis -- in fact the
>>>>> inline case "just works" with YL-bis as defined today.
>>> Martin,
>>>
>>> you didn't respond to this point.
>> I agree, it works for non-NMDA servers. But see below.
>>
>>>>> The argument I recall being the key point on inline was handling the
>>>>> large variety of possible different implementation approaches for
>>>>> modules using inline.
>>>> I think these still are covered.
>>>>
>>>>> For example an LNE that is implemented using
>>>>> VMs which can be managed by the host at different times of the VMs
>>>>> operational life cycle based on customer/provider requirements.  I
>>>>> really don't see how YL-bis has any bearing on this point and
>>>> Using the new proposed meta data annotation together with the new YL
>>>> means that SM can support the use case above also in an NMDA server.
>>>> I think the new proposed solution covers more use cases than the
>>>> previous solution.
>>> how so?  The inline mount point would contain YL-bis and have the same
>>> information there, just scoped for the mount point.  It's true a
>>> client would need to understand the mount point's schema only upon
>>> parsing the YL under the mount point and this schema could not be
>>> shared across inline mount points.  But this is as was discussed in
>>> the past and unchanged from YL.
>>>
>>>> Do you think that there is any use case that the proposed solution
>>>> cannot handle, but the previous solution did?
>>> yes.  with VM/container technologies the YL / schema can change under
>>> the mount point from time to time during normal operation (i.e.,
>>> during runtime, no reboot) and, in some implementations, may require
>>> some level of rpc operation to access even the schema.  The new (and
>>> previously proposed approach) of having inline schema available from
>>> the top level greatly complicates these cases.  Also keep in mind that
>>> there will be cases where the ability to access information under an
>>> inline mount point will dynamically change in operation (and top level
>>> YL would need to remove schema information for the inline mount
>>> point.)  As before, from the usage standpoint, these changes don't
>>> provide a whole lot of value and seem to optimizing for something not
>>> needed in the inline case.
>> I think this is an implementation issue, rather than a problem with
>> the proposed mechanism, and it is present in the current solution as
>> well.  An implementation that can handle dynamically changing mounted
>> YLs in the current solution can do that in the new solution as well.
>>
>>>>> I think
>>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>>> this case, inline schema being represented by YL) to argue why the
>>>>> decision needs to be revisited.
>>>> I'm repeating my self: b/c the current solution doesn't work well with
>>>> the NMDA.
>>> I simply don't understand how YL-bis works at the root node but
>>> doesn't work equally at an inline mount point.  Can you elaborate?
>> With NMDA, a server may have one schema for the config datastore and
>> another one for operational (one is a superset of the other).  A
>> mounted YL can only be present in operational.  Thus, there's no way a
>> client can learn the schema for config.
> If the LNE mounted the full YL-bis at the mount point then you would
> have the list of datastores, and the schema associated with each
> datastore.  Of course, this would only be available in operational, but
> that is the same as a regular server support YL-bis.
exactly my point.

> I thought that the problem with the current solution and NMDA, was that
> there is no way to find out what the LNE schema is if the LNE isn't
> booted, and hence isn't providing .
I've never heard anyone mention this issue/limitation.  My understanding 
of the previously raised objections were (a) that the full schema can't 
be obtained by just reading the top level YL and (b) that when multiple 
inline mount points have the same schema the information can't be 
combined using a shared schema approach as is taken in base SM.  Yes 
both increase client operations/work, but without incurring the server 
side implementation overhead that is implied in this approach.  -- 
Again, I don't see how YL-bis or NMDA changes any of this.

>   But I'm not sure what
> issues that actually causes.  E.g. does it cause issues with
> pre-configuration of the LNE?
Assignment of host resources takes place at the root level, not the 
within the context of the inline mount point, other preprovisiong can be 
handled via the inline/managed mechanisms defined in the LNE module.  We 
looked at this in detail for multiple server/vendor implementations and 
agreed the current mechanisms work even if not optimal in all cases.

Lou

> Thanks,
> Rob
>
>
>> With the proposed solution, there can be different schema-ref pointers
>> in config and operational (if needed).
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>


From nobody Tue Jan 16 09:35:00 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 86CC612E867 for ; Tue, 16 Jan 2018 09:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 8Yyp8y8VKpZm for ; Tue, 16 Jan 2018 09:34:58 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 4D5EF12D82D for ; Tue, 16 Jan 2018 09:34:37 -0800 (PST)
Received: from MBP.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0GHYXVr062391 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 16 Jan 2018 17:34:34 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be MBP.local
To: Robert Wilton , Martin Bjorklund , vladimir@transpacket.com
Cc: netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com> 
From: joel jaeggli 
Message-ID: 
Date: Tue, 16 Jan 2018 09:34:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 17:34:59 -0000

On 1/16/18 8:01 AM, Robert Wilton wrote:
>
>
> On 16/01/2018 15:40, Martin Bjorklund wrote:
>> Vladimir Vassilev  wrote:

>> Does anyone else have an opinion on this?=C2=A0 I can see three
>> alternatives:
>>
>> =C2=A0=C2=A0 1) allow any number of addtional spaces
>> =C2=A0=C2=A0 2) allow any number of addtional spaces + define a sugges=
ted
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alignment algorithm
>> =C2=A0=C2=A0 3) mandate the alignment algorithm
>
> Definition of symbols should be precise/consistent, so that readers
> can consistently interpret tree diagrams.
>
> I think that flexibility in layout should be OK, but the draft should
> provide guideline to ensure the output is readable, and likely to be
> broadly consistent (since consistency aids readability).
>
> If the IETF data modeling group is trying to specify text output
> precisely enough that it can be screen scraped then we may want to
> consider whether we are focusing on the right solution ;-)
I would hope that we are not, as the diagrams are programmatically=C2=A0
generated if you wanted to for example validate them one should do that
from the sources.=C2=A0

Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).

> In summary, (2) is my preference, followed by (1), followed by (3).
>
> Thanks,
> Rob
>
>>
>>
>> /martin
>>
>> _______________________________________________
>> 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 Tue Jan 16 11:19:45 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 2A2BC12EAA4 for ; Tue, 16 Jan 2018 11:19:44 -0800 (PST)
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 c-MinCYzSP2t for ; Tue, 16 Jan 2018 11:19:42 -0800 (PST)
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 139811242F5 for ; Tue, 16 Jan 2018 11:19:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E0B3214621B5; Tue, 16 Jan 2018 20:19:39 +0100 (CET)
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 OHKp_wIZ3tXV; Tue, 16 Jan 2018 20:19:39 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B050014621B9; Tue, 16 Jan 2018 20:19:39 +0100 (CET)
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 FZ6Srj0WpCYW; Tue, 16 Jan 2018 20:19:39 +0100 (CET)
Received: from [192.168.43.32] (77.16.194.13.tmi.telenormobil.no [77.16.194.13]) by mail.transpacket.com (Postfix) with ESMTPSA id 6284014621B5; Tue, 16 Jan 2018 20:19:39 +0100 (CET)
To: joel jaeggli , Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  
From: Vladimir Vassilev 
Message-ID: <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com>
Date: Tue, 16 Jan 2018 20:19:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 19:19:44 -0000

On 01/16/2018 06:34 PM, joel jaeggli wrote:

>
> On 1/16/18 8:01 AM, Robert Wilton wrote:
>>
>> On 16/01/2018 15:40, Martin Bjorklund wrote:
>>> Vladimir Vassilev  wrote:
> 
>>> Does anyone else have an opinion on this?=C2=A0 I can see three
>>> alternatives:
>>>
>>>  =C2=A0=C2=A0 1) allow any number of addtional spaces
>>>  =C2=A0=C2=A0 2) allow any number of addtional spaces + define a sugg=
ested
>>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alignment algorithm
>>>  =C2=A0=C2=A0 3) mandate the alignment algorithm
>> Definition of symbols should be precise/consistent, so that readers
>> can consistently interpret tree diagrams.
>>
>> I think that flexibility in layout should be OK, but the draft should
>> provide guideline to ensure the output is readable, and likely to be
>> broadly consistent (since consistency aids readability).
>>
>> If the IETF data modeling group is trying to specify text output
>> precisely enough that it can be screen scraped then we may want to
>> consider whether we are focusing on the right solution ;-)
> I would hope that we are not, as the diagrams are programmatically
> generated if you wanted to for example validate them one should do that
> from the sources.
>
> Approaches that result in the most easily human readable, followed by
> consistency between tools is probably better for that. That said this i=
s
> almost the indentation wars so the proscriptive it gets the more dissen=
t
> you can probably find (e.g. 3).
To make it clear I think 1) works with the text proposed by Martin.

As said I posted the pyang alignment algorithm description in a sort of=20
2) variant only for reference on the mailing list since I implemented=20
that too. Starting indentation war was not my intention.

As for the automated validation of the tree diagrams as an added value=20
to the human readability I have the following thoughts. I would like to=20
be able to compare unlimited line length tree outputs generated by=20
different YANG compilers for equality. This is mainly a way to have some=20
partial common denominator output for validating YANG is correctly=20
compiled which we did not have until now. For example as soon as I have=20
support for Schema mount I would compare the tree output with another=20
tool known to work and add some testcases based on that. I do not see=20
any automated alternative for doing this except writing NETCONF chat=20
scripts (also module specific), or writing not only YANG module specific=20
but also API specific test cases as 3rd option. 1) does not compromise=20
this automated validation option since space sequences can be collapsed=20
to single space. If the alignment algorithm was creating a possibility=20
for nontrivial output variation then I would have supported strongly 3)=20
but this is not the current case.

Vladimir
>
>> In summary, (2) is my preference, followed by (1), followed by (3).
>>
>> Thanks,
>> Rob
>>
>>>
>>> /martin
>>>


From nobody Tue Jan 16 12:06:42 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 135FA12E957 for ; Tue, 16 Jan 2018 12:06:41 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 Ez9oLvcJaqWQ for ; Tue, 16 Jan 2018 12:06:39 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87FC126C19 for ; Tue, 16 Jan 2018 12:06:38 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7431CDBD; Tue, 16 Jan 2018 21:06:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id eUVAB8dxn4lB; Tue, 16 Jan 2018 21:06:37 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 Jan 2018 21:06:37 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57C3C2013F; Tue, 16 Jan 2018 21:06:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j3lIe1HO8FjB; Tue, 16 Jan 2018 21:06:36 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8591F2013E; Tue, 16 Jan 2018 21:06:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 47B854212505; Tue, 16 Jan 2018 21:06:36 +0100 (CET)
Date: Tue, 16 Jan 2018 21:06:36 +0100
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Cc: joel jaeggli , Robert Wilton , Martin Bjorklund , netmod@ietf.org
Message-ID: <20180116200636.w437ttcwyqswnj2t@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Vladimir Vassilev , joel jaeggli , Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>   <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 20:06:41 -0000

On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:
> 
> As for the automated validation of the tree diagrams as an added value to
> the human readability I have the following thoughts. I would like to be able
> to compare unlimited line length tree outputs generated by different YANG
> compilers for equality. This is mainly a way to have some partial common
> denominator output for validating YANG is correctly compiled which we did
> not have until now. For example as soon as I have support for Schema mount I
> would compare the tree output with another tool known to work and add some
> testcases based on that. I do not see any automated alternative for doing
> this except writing NETCONF chat scripts (also module specific), or writing
> not only YANG module specific but also API specific test cases as 3rd
> option. 1) does not compromise this automated validation option since space
> sequences can be collapsed to single space. If the alignment algorithm was
> creating a possibility for nontrivial output variation then I would have
> supported strongly 3) but this is not the current case.
>

If you want to make sure a YANG compiler is correct, simply write a
backend that generates a serialized YANG module in canonical
form. They YANG modules should be the same. Determining YANG compiler
correctness by comparing tree diagrams does not seem to be a
convincing approach since tree diagrams by design leave many details
out.

/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 Jan 16 13:46: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 B45A212EB47 for ; Tue, 16 Jan 2018 13:46:23 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 iO9ldMRwurTR for ; Tue, 16 Jan 2018 13:46:22 -0800 (PST)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9DC12EB3E for ; Tue, 16 Jan 2018 13:46:22 -0800 (PST)
From: Alex Campbell 
To: Benoit Claise , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
Thread-Index: AQHTi/jfigWQjGIjg0uBhuY8mQzMfKN3RMsAgAAG6ID//8MWuw==
Date: Tue, 16 Jan 2018 21:46:20 +0000
Message-ID: <1516139180331.69061@Aviatnet.com>
References: <151579789446.21777.985631371557420470@ietfa.amsl.com> , 
In-Reply-To: 
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jan 2018 21:46:23 -0000

By the same reasoning surely UDP should not be available either, because it=
 also doesn't provide security.=0A=
________________________________________=0A=
From: netmod  on behalf of Benoit Claise =0A=
Sent: Wednesday, 17 January 2018 6:23 a.m.=0A=
To: Kent Watsen; netmod@ietf.org=0A=
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt=0A=
=0A=
Hi,=0A=
>=0A=
>    ** Downref: Normative reference to an Historic RFC: RFC 6587=0A=
>=0A=
> Kent: hmmm, what's going on here?  This YANG module is providing an abili=
ty to configure the "tcp" transport, even though the IESG made that ability=
 historic in 2012 (see IESG Note below).  Searching online, it looks like C=
isco supports this, but Juniper does not.  What about other vendors, is it =
widely supported?  Was this discussed in the WG?  Answering my own question=
, searching my local mailbox, I don't see this ever being discussed before,=
 other than Martin questioning if it was a good idea in Mar 2016 (no respon=
se).  Please start a thread on the list to get WG opinion if it's okay for =
the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:=0A=
>=0A=
>     IESG Note=0A=
>=0A=
>     The IESG does not recommend implementing or deploying syslog over=0A=
>     plain tcp, which is described in this document, because it lacks the=
=0A=
>     ability to enable strong security [RFC3365].=0A=
>=0A=
>     Implementation of the TLS transport [RFC5425] is recommended so that=
=0A=
>     appropriate security features are available to operators who want to=
=0A=
>     deploy secure syslog.  Similarly, those security features can be=0A=
>     turned off for those who do not want them.=0A=
>=0A=
>=0A=
>=0A=
Well, I believe it's clear plain TCP should not be in the YANG module.=0A=
=0A=
Regards, Benoit=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Tue Jan 16 18:08:19 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 B3E1712EC1D for ; Tue, 16 Jan 2018 18:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LgYMDMh95Fv2 for ; Tue, 16 Jan 2018 18:08:15 -0800 (PST)
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 AA2EF12EC01 for ; Tue, 16 Jan 2018 18:08:15 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E4518FE3846AE for ; Wed, 17 Jan 2018 02:08:10 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 02:07:24 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Tue, 16 Jan 2018 18:07:19 -0800
From: Alexander Clemm 
To: Alex Campbell , Benoit Claise , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
Thread-Index: AQHTi/jz+X7eCw0jfk6j/DOoJ8NZ+qN3RMsAgAAG54CAAElbAP//wJfA
Date: Wed, 17 Jan 2018 02:07:18 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB117@sjceml521-mbx.china.huawei.com>
References: <151579789446.21777.985631371557420470@ietfa.amsl.com> ,  <1516139180331.69061@Aviatnet.com>
In-Reply-To: <1516139180331.69061@Aviatnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 02:08:18 -0000

IMHO, if this module is supposed to be useful in practice, without requirin=
g immediately proprietary augmentations, UDP needs to be supported.  RFC 54=
24 also states that implementations SHOULD support a UDP transport per RFC =
5426. =20

Whether TCP support should be included is debatable because not a standard =
transport.  Perhaps it should not, however given that it has already been s=
pecified, I don't think it hurts to have it as a feature/option for impleme=
ntations that require it. =20
--- Alex

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Alex
> Campbell
> Sent: Tuesday, January 16, 2018 1:46 PM
> To: Benoit Claise ; Kent Watsen
> ; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
>=20
> By the same reasoning surely UDP should not be available either, because =
it
> also doesn't provide security.
> ________________________________________
> From: netmod  on behalf of Benoit Claise
> 
> Sent: Wednesday, 17 January 2018 6:23 a.m.
> To: Kent Watsen; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
>=20
> Hi,
> >
> >    ** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> > Kent: hmmm, what's going on here?  This YANG module is providing an
> ability to configure the "tcp" transport, even though the IESG made that
> ability historic in 2012 (see IESG Note below).  Searching online, it loo=
ks like
> Cisco supports this, but Juniper does not.  What about other vendors, is =
it
> widely supported?  Was this discussed in the WG?  Answering my own
> question, searching my local mailbox, I don't see this ever being discuss=
ed
> before, other than Martin questioning if it was a good idea in Mar 2016 (=
no
> response).  Please start a thread on the list to get WG opinion if it's o=
kay for
> the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:
> >
> >     IESG Note
> >
> >     The IESG does not recommend implementing or deploying syslog over
> >     plain tcp, which is described in this document, because it lacks th=
e
> >     ability to enable strong security [RFC3365].
> >
> >     Implementation of the TLS transport [RFC5425] is recommended so tha=
t
> >     appropriate security features are available to operators who want t=
o
> >     deploy secure syslog.  Similarly, those security features can be
> >     turned off for those who do not want them.
> >
> >
> >
> Well, I believe it's clear plain TCP should not be in the YANG module.
>=20
> Regards, Benoit
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 16 18:21:07 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 E01CA12EC2C for ; Tue, 16 Jan 2018 18:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NUflNs61GT4U for ; Tue, 16 Jan 2018 18:21:03 -0800 (PST)
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 0E6DB12EC34 for ; Tue, 16 Jan 2018 18:21:02 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2782582050F85 for ; Wed, 17 Jan 2018 02:20:59 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 02:21:00 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Tue, 16 Jan 2018 18:20:53 -0800
From: Alexander Clemm 
To: Robert Wilton , Martin Bjorklund , "vladimir@transpacket.com" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
Thread-Index: AQHTg0wvNmxA9EXf+EaKXhpG/Wu106N2AhOAgADuqACAAEadAIAACPSAgAAF2ACAACYBQA==
Date: Wed, 17 Jan 2018 02:20:53 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com>
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.214]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 02:21:06 -0000

KzEgdG8gKDIpIGFzIHByZWZlcmVuY2UsIGZvbGxvd2VkIGJ5ICgxKS4gIEkgZG9uJ3QgdGhpbmsg
KDMpIGlzIG5lZWRlZCBoZXJlLiAgVGhlIHB1cnBvc2UgaXMgdG8gbWFrZSB0aGlzIGh1bWFuLXJl
YWRhYmxlIGFuZCBwcm92aWRlIHJlYWRlcnMgYSBnb29kIHNlbnNlIG9mIHRoZSBvdmVyYWxsIHN0
cnVjdHVyZS4gIFRoZSBhdXRob3JpdGF0aXZlIHNwZWNpZmljYXRpb24gaXMgc3RpbGwgdGhlIC55
YW5nIGl0c2VsZi4gIFByb3ZpZGluZyBzb21lIGd1aWRhbmNlIGZvciBob3cgdG8gcmVwcmVzZW50
IHRoZSB0cmVlIGlzIGdvb2QgYnV0IGxldCdzIG5vdCBvdmVyLWVuZ2luZWVyIHRoaXM7IEkgYmVs
aWV2ZSByZXRhaW5pbmcgc29tZSBmbGV4aWJpbGl0eSBpcyBnb29kLiANCg0KLS0tIEFsZXggDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCi4uLg0KPiA+IERvZXMgYW55b25lIGVsc2Ug
aGF2ZSBhbiBvcGluaW9uIG9uIHRoaXM/ICBJIGNhbiBzZWUgdGhyZWUNCj4gPiBhbHRlcm5hdGl2
ZXM6DQo+ID4NCj4gPiAgICAxKSBhbGxvdyBhbnkgbnVtYmVyIG9mIGFkZHRpb25hbCBzcGFjZXMN
Cj4gPiAgICAyKSBhbGxvdyBhbnkgbnVtYmVyIG9mIGFkZHRpb25hbCBzcGFjZXMgKyBkZWZpbmUg
YSBzdWdnZXN0ZWQNCj4gPiAgICAgICBhbGlnbm1lbnQgYWxnb3JpdGhtDQo+ID4gICAgMykgbWFu
ZGF0ZSB0aGUgYWxpZ25tZW50IGFsZ29yaXRobQ0KPiANCj4gRGVmaW5pdGlvbiBvZiBzeW1ib2xz
IHNob3VsZCBiZSBwcmVjaXNlL2NvbnNpc3RlbnQsIHNvIHRoYXQgcmVhZGVycyBjYW4NCj4gY29u
c2lzdGVudGx5IGludGVycHJldCB0cmVlIGRpYWdyYW1zLg0KPiANCj4gSSB0aGluayB0aGF0IGZs
ZXhpYmlsaXR5IGluIGxheW91dCBzaG91bGQgYmUgT0ssIGJ1dCB0aGUgZHJhZnQgc2hvdWxkIHBy
b3ZpZGUNCj4gZ3VpZGVsaW5lIHRvIGVuc3VyZSB0aGUgb3V0cHV0IGlzIHJlYWRhYmxlLCBhbmQg
bGlrZWx5IHRvIGJlIGJyb2FkbHkgY29uc2lzdGVudA0KPiAoc2luY2UgY29uc2lzdGVuY3kgYWlk
cyByZWFkYWJpbGl0eSkuDQo+IA0KPiBJZiB0aGUgSUVURiBkYXRhIG1vZGVsaW5nIGdyb3VwIGlz
IHRyeWluZyB0byBzcGVjaWZ5IHRleHQgb3V0cHV0IHByZWNpc2VseQ0KPiBlbm91Z2ggdGhhdCBp
dCBjYW4gYmUgc2NyZWVuIHNjcmFwZWQgdGhlbiB3ZSBtYXkgd2FudCB0byBjb25zaWRlciB3aGV0
aGVyDQo+IHdlIGFyZSBmb2N1c2luZyBvbiB0aGUgcmlnaHQgc29sdXRpb24gOy0pDQo+IA0KPiBJ
biBzdW1tYXJ5LCAoMikgaXMgbXkgcHJlZmVyZW5jZSwgZm9sbG93ZWQgYnkgKDEpLCBmb2xsb3dl
ZCBieSAoMykuDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiANCj4gPg0KPiA+DQo+ID4gL21hcnRp
bg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiAuDQo+ID4NCj4g
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Tue Jan 16 19:11:17 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 8484612EC5A; Tue, 16 Jan 2018 19:11:12 -0800 (PST)
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.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151615867250.15562.7858111799192763218@ietfa.amsl.com>
Date: Tue, 16 Jan 2018 19:11:12 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 03:11:12 -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           : Network Access Control List (ACL) YANG Data Model
        Authors         : Mahesh Jethanandani
                          Lisa Huang
                          Sonal Agarwal
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-15.txt
	Pages           : 51
	Date            : 2018-01-16

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "XXXX" --> the assigned RFC value for this draft both in this
      draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
      draft gets approved.  The date also needs to get reflected on the
      line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15


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 Tue Jan 16 19:13:15 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 A67AF12EC5C for ; Tue, 16 Jan 2018 19:13:14 -0800 (PST)
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 uztBBquXI3d5 for ; Tue, 16 Jan 2018 19:13:11 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 C227712D949 for ; Tue, 16 Jan 2018 19:13:10 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id u10so20923655qtg.2 for ; Tue, 16 Jan 2018 19:13:10 -0800 (PST)
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=iD2dTQW4kNnuGbyxW72NvfFxcawdDHjDSYaayzUE3Oc=; b=qgOyNfr6NwY+6LQv/lsWNA+QmTny4tUepsNlyki8rP0mhrVv2et9iuV/Q+DEUbpD6+ VO10qRoraPCWD1LEbDqNOFyvBfql+GFaZP6DESCaeINJMpvsqS6O+ZpvE7aNRWA8IGc9 5KXSg6Yfd1n0QfPQB6Kya9e7ACtXHroQUxha3Mnsrp3k9x938Dx8fSy5puNBjzUbn6Ge 6iKPREaqIBGkoGVlirwQoapjmaIsrXqfd0xFi8jRbszJNF+LKcl3xkNki3oyDVCxuxT/ eVzyMoJhgALoL2rMINcoG0tL1gp8qpZDy4NwNZX1vACtYCZZBfL6rQ9A5/cD7nZvmFlB F04Q==
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=iD2dTQW4kNnuGbyxW72NvfFxcawdDHjDSYaayzUE3Oc=; b=Q00BAgktVCEolcwUEIelJcwKRK52C42F1HhanlzpUOLpqnajN077v8NbkCaYhjvDjM E2NtNSRAmTkHBqR/eVI1KTlBp9Q0JFoJKQVqfqYzH62LwDhyZSNGPemlWJZXsoU50rBp KEABHUJ6VdZa/q2yQyRSwLPPtuwSNdGprUmtivfmYjLeglCbMgK34/kP5Pn8YVl4id7Q 77fOchhuVKd+ut+ohxwOdivnLh7Ly4QB1a3SzVp3lhmLLj+CPvOeFRHfT2LRrh3RHrUp IPVG16abg6KqwGv8ZTehmLrnFL/e6Db3PwihOdGIhtjfhnKonTklp9tOIsoh6hgXO8Mu 0oYg==
X-Gm-Message-State: AKwxytfw9iFRWG0DvdFc57KhB3J4+aCk0i1mCdmcA4Sl6AdxNru1+SL6 q95Q4lIJxGbc/uBxC6Ul1oh7F8WrcUKVBs4bFzg=
X-Google-Smtp-Source: ACJfBouQkGHABaLdC16W0zu/Ys6G2C/9CXXOsOVfFtNHsyFMacHUGVzOBJ4E8FkPgeeq1X/FPVJA3G9PcYyaIMjOoRU=
X-Received: by 10.200.43.68 with SMTP id 4mr4830946qtv.265.1516158789809; Tue, 16 Jan 2018 19:13:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.96.11 with HTTP; Tue, 16 Jan 2018 19:13:08 -0800 (PST)
In-Reply-To: 
References: <20171102074318.GC12688@spritelink.se>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se>   <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com>  <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com>  <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com>   <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> 
From: Sonal Agarwal 
Date: Tue, 16 Jan 2018 19:13:08 -0800
Message-ID: 
To: Mahesh Jethanandani 
Cc: Eliot Lear , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11404f4c16fa170562f03af3"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 03:13:15 -0000

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

I have reviewed the changes and they look good to me.

Thanks,
Sonal.


On Fri, Jan 12, 2018 at 2:07 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> An updated version of the draft, along with changes to remove icmp-off
> from the model, and updates to examples has been posted in the PR here
> . If there are no
> objections to the changes by Tuesday, I will pull in the PR, and publish
> the draft.
>
> Cheers.
>
> On Jan 12, 2018, at 7:35 AM, Eliot Lear  wrote:
>
> Ok.  What is left to agree on at this point?
>
> Thanks Mahesh,
>
> Eliot
>
> On 11.01.18 02:21, Mahesh Jethanandani wrote:
>
> Hi Einar,
>
> I can work on updating the draft as soon as we agree on the changes.
> Should take only a couple of days to turn around and publish the draft.
>
> On Jan 9, 2018, at 11:35 PM, Eliot Lear  wrote:
>
> Hi Mahesh,
>
> Thanks for this work.  I think this is okay.  In the case of MUD we simpl=
y
> won't have the other container.  Can I please ask that you get the draft
> out quickly as draft-ietf-opsawg-mud has been waiting quite some time for
> this work to complete.
>
> Eliot
>
> On 10.01.18 04:08, Mahesh Jethanandani wrote:
>
> I have pulled in the changes as they relate to:
>
> - moving =E2=80=9Cinterface-acl=E2=80=9D under the container =E2=80=9Catt=
achment-points=E2=80=9D making it
> local to that container.
> - reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ctype=E2=80=9D
> - removed =E2=80=9Cinterface-all-aggregate=E2=80=9D feature
> - simplified source port and destination port definition
>
> The pull request for the changes can be found here.
>
> https://github.com/netmod-wg/acl-model/pull/20
>
> After discussing with some of the original contributors, decided not to
> include the change as it relates to augmenting ietf-interfaces. We did no=
t
> find that the change had a particular advantage over the current
> implementation. Even if we do not completely understand how ACLs might be
> attached =E2=80=9Cglobally=E2=80=9D or on something that is not an interf=
ace, having the
> flexibility to attach them to other attachment points is important. Keepi=
ng
> it as interface-ref gives us that flexibility.
>
> Cheers.
>
> On Dec 18, 2017, at 4:31 AM, Eliot Lear  wrote:
>
> So long as nobody expects an interface construct in a MUD file, I'm happy=
.
>
> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
>
> Eliot,
>
> Nothing can force an implementation to have to implement either
> the ietf-interfaces model or the augmentation in the
> ietf-access-control-list model. I appreciate your desire for modularity a=
nd
> cohesiveness, but I would resist #1, because I feel that the majority of
> users will be targeting interface-based attachment over time. I=E2=80=99v=
e adde
> back in use of the =E2=80=9Cinterface-attachment=E2=80=9D feature (which =
I took out as part
> of refactoring interface attachment). Part of:
>
> https://github.com/netmod-wg/acl-model/pull/21
>
>
> The augments part of the tree now looks like:
>
>   augment /if:interfaces/if:interface:
>     +--rw acls *{interface-attachment}*?
>        +--rw ingress
>        |  +--rw acl-sets
>        |     +--rw acl-set* [name]
>        |        +--rw name              -> /access-lists/acl/name
>        |        +--rw type?             -> /access-lists/acl/type
>        |        +--ro ace-statistics* [name] {interface-stats}?
>        |           +--ro name               -> /access-lists/acl/aces/ace=
/
> name
>        |           +--ro matched-packets?   yang:counter64
>        |           +--ro matched-octets?    yang:counter64
>        +--rw egress
>           +--rw acl-sets
>              +--rw acl-set* [name]
>                 +--rw name              -> /access-lists/acl/name
>                 +--rw type?             -> /access-lists/acl/type
>                 +--ro ace-statistics* [name] {interface-stats}?
>                    +--ro name               -> /access-lists/acl/aces/ace=
/
> name
>                    +--ro matched-packets?   yang:counter64
>                    +--ro matched-octets?    yang:counter64
>
> Cheers,
>
> Einar
>
>
> On 17 Dec 2017, at 11:29, Eliot Lear  wrote:
>
> Einar,
>
> I think this change is fine, with one exception.  I would rather the
> augment to the interface not be required for implementations that don't
> actually have interfaces.  I understand that there may be two ways to go
> about this:
>
>    1. Separate out the augment into a separate module (same doc is fine);
>    or
>    2. Somehow "feature-ize" the augment.
>
> I don't know how to do (2) but if you do, that's okay by me.
>
> Eliot
>
> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
>
> All,
>
> After a series of discussions on- and off-list, I have a candidate PR tha=
t
> includes the changes in the PR Mahesh sent out plus some more edits. Plea=
se
> see consolidated PR here:
>
> https://github.com/netmod-wg/acl-model/pull/21
>
>
> Main changes in addition to Mahesh=E2=80=99s PR are:
>
>
>    - Moved interface attachment to be via an interface augmentation.
>    - Restructured port matches slightly under both IPv4 and IPv6
>    containers.
>    - Removed unnecessary identity 'interface-acl-aggregate=E2=80=99.
>    - Removed action =E2=80=98icmp-off=E2=80=99, can be augmented later.
>
>
> For reference, here is the current YANG tree plus =E2=80=9C--ietf=E2=80=
=9D logs:
>
> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" (should
> be date)
> module: ietf-access-control-list
>     +--rw access-lists
>        +--rw acl* [name]
>           +--rw name    string
>           +--rw type?   acl-type
>           +--rw aces
>              +--rw ace* [name]
>                 +--rw name          string
>                 +--rw matches
>                 |  +--rw (l2)?
>                 |  |  +--:(eth)
>                 |  |     +--rw eth {match-on-eth}?
>                 |  |        +--rw destination-mac-address?
>  yang:mac-address
>                 |  |        +--rw destination-mac-address-mask?
> yang:mac-address
>                 |  |        +--rw source-mac-address?
> yang:mac-address
>                 |  |        +--rw source-mac-address-mask?
>  yang:mac-address
>                 |  |        +--rw ethertype?
>  eth:ethertype
>                 |  +--rw (l3)?
>                 |  |  +--:(ipv4)
>                 |  |  |  +--rw ipv4 {match-on-ipv4}?
>                 |  |  |     +--rw dscp?                       inet:dscp
>                 |  |  |     +--rw ecn?                        uint8
>                 |  |  |     +--rw length?                     uint16
>                 |  |  |     +--rw ttl?                        uint8
>                 |  |  |     +--rw protocol?                   uint8
>                 |  |  |     +--rw (source-port-range-or-operator)?
>                 |  |  |     |  +--:(range)
>                 |  |  |     |  |  +--rw source-port-lower
> inet:port-number
>                 |  |  |     |  |  +--rw source-port-upper
> inet:port-number
>                 |  |  |     |  +--:(operator)
>                 |  |  |     |     +--rw source-operator
> operator
>                 |  |  |     |     +--rw source-port
> inet:port-number
>                 |  |  |     +--rw (destination-port-range-or-operator)?
>                 |  |  |     |  +--:(range)
>                 |  |  |     |  |  +--rw destination-port-lower
>  inet:port-number
>                 |  |  |     |  |  +--rw destination-port-upper
>  inet:port-number
>                 |  |  |     |  +--:(operator)
>                 |  |  |     |     +--rw destination-operator
>  operator
>                 |  |  |     |     +--rw destination-port
>  inet:port-number
>                 |  |  |     +--rw ihl?                        uint8
>                 |  |  |     +--rw flags?                      bits
>                 |  |  |     +--rw offset?                     uint16
>                 |  |  |     +--rw identification?             uint16
>                 |  |  |     +--rw destination-ipv4-network?
> inet:ipv4-prefix
>                 |  |  |     +--rw source-ipv4-network?
>  inet:ipv4-prefix
>                 |  |  +--:(ipv6)
>                 |  |     +--rw ipv6 {match-on-ipv6}?
>                 |  |        +--rw dscp?                       inet:dscp
>                 |  |        +--rw ecn?                        uint8
>                 |  |        +--rw length?                     uint16
>                 |  |        +--rw ttl?                        uint8
>                 |  |        +--rw protocol?                   uint8
>                 |  |        +--rw (source-port-range-or-operator)?
>                 |  |        |  +--:(range)
>                 |  |        |  |  +--rw source-port-lower
> inet:port-number
>                 |  |        |  |  +--rw source-port-upper
> inet:port-number
>                 |  |        |  +--:(operator)
>                 |  |        |     +--rw source-operator
> operator
>                 |  |        |     +--rw source-port
> inet:port-number
>                 |  |        +--rw (destination-port-range-or-operator)?
>                 |  |        |  +--:(range)
>                 |  |        |  |  +--rw destination-port-lower
>  inet:port-number
>                 |  |        |  |  +--rw destination-port-upper
>  inet:port-number
>                 |  |        |  +--:(operator)
>                 |  |        |     +--rw destination-operator
>  operator
>                 |  |        |     +--rw destination-port
>  inet:port-number
>                 |  |        +--rw destination-ipv6-network?
> inet:ipv6-prefix
>                 |  |        +--rw source-ipv6-network?
>  inet:ipv6-prefix
>                 |  |        +--rw flow-label?
> inet:ipv6-flow-label
>                 |  +--rw (l4)?
>                 |  |  +--:(tcp)
>                 |  |  |  +--rw tcp {match-on-tcp}?
>                 |  |  |     +--rw sequence-number?          uint32
>                 |  |  |     +--rw acknowledgement-number?   uint32
>                 |  |  |     +--rw data-offset?              uint8
>                 |  |  |     +--rw reserved?                 uint8
>                 |  |  |     +--rw flags?                    bits
>                 |  |  |     +--rw window-size?              uint16
>                 |  |  |     +--rw urgent-pointer?           uint16
>                 |  |  |     +--rw options?                  uint32
>                 |  |  +--:(udp)
>                 |  |  |  +--rw udp {match-on-udp}?
>                 |  |  |     +--rw length?   uint16
>                 |  |  +--:(icmp)
>                 |  |     +--rw icmp {match-on-icmp}?
>                 |  |        +--rw type?             uint8
>                 |  |        +--rw code?             uint8
>                 |  |        +--rw rest-of-header?   uint32
>                 |  +--rw egress-interface?    if:interface-ref
>                 |  +--rw ingress-interface?   if:interface-ref
>                 +--rw actions
>                 |  +--rw forwarding    identityref
>                 |  +--rw logging?      identityref
>                 +--ro statistics {acl-aggregate-stats}?
>                    +--ro matched-packets?   yang:counter64
>                    +--ro matched-octets?    yang:counter64
>
>   augment /if:interfaces/if:interface:
>     +--rw acls
>        +--rw ingress
>        |  +--rw acl-sets
>        |     +--rw acl-set* [name]
>        |        +--rw name              -> /access-lists/acl/name
>        |        +--rw type?             -> /access-lists/acl/type
>        |        +--ro ace-statistics* [name] {interface-stats}?
>        |           +--ro name               -> /access-lists/acl/aces/ace=
/
> name
>        |           +--ro matched-packets?   yang:counter64
>        |           +--ro matched-octets?    yang:counter64
>        +--rw egress
>           +--rw acl-sets
>              +--rw acl-set* [name]
>                 +--rw name              -> /access-lists/acl/name
>                 +--rw type?             -> /access-lists/acl/type
>                 +--ro ace-statistics* [name] {interface-stats}?
>                    +--ro name               -> /access-lists/acl/aces/ace=
/
> name
>                    +--ro matched-packets?   yang:counter64
>                    +--ro matched-octets?    yang:counter64
>
> Comments welcome!
>
> Cheers,
>
> Einar
>
>
>
> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <
> einarnn@cisco.com> wrote:
>
>
>
> On 14 Dec 2017, at 08:21, Sonal Agarwal  wrote:
>
> Hi Einar,
>
> You had 3 questions for me on all the several e-mail threads.
> 1. Global attachment point
> 2. icmp-off
> 3. acl-aggregate-interface stats.
>
> For (1), my first preference is to have the model define attachment point
> for interfaces only.
>
>
> einarnn> I have some diffs, layered on top of Mahesh=E2=80=99s PR to
> netmod-wg/acl-model that do this. Nearly like the augmentation I have
> below. Feel free to take a look at:
>
> https://github.com/mjethanandani/acl-model/pull/3
>
>
> However, Kristian wants the global attachment point as well so that he ca=
n
> add the ACL to the linux tables.
>
>
> einarnn> I think Kristian doesn=E2=80=99t feel a global attachment point =
needs to
> be in this first revision. But he can confirm.
>
> If an ACL is attached globally, does this mean it is per direction or doe=
s
> it mean it is across directions?
>
>
> einarnn> I don=E2=80=99t know right now :-)
>
> This global ACL may not be applicable to any of Cisco's service provider
> routers as I don't see any platform actually replicating the ACL to all
> line cards and attaching it in ingress and egress directions across all
> interfaces.
>
>
> einarnn> Per other emails, I don=E2=80=99t think we understand this enoug=
h yet to
> specify it, so I suggest we just leave it out for now. Nothing in the mod=
el
> prevents a =E2=80=9Cglobal attachment point=E2=80=9D being added later on=
ce we understand
> what it really means.
>
> For (2), I am ok with removing icmp-off.
>
>
> einarnn> Done in my PR above.
>
> For (3), this would have to be a combination of ACL stats across all
> interfaces for all ACL's. Something like this is possible on an XR box
> where ACES have counter names associated with it. Let's chat about this
> offline tomorrow.
>
>
> einarnn> I=E2=80=99ll ping you to clarify, and we can bring any conclusio=
n back to
> the list.
>
> Cheers,
>
> Einar
>
>
>
> Sonal.
>
>
> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
>
>> We want to support =E2=80=9Cglobal=E2=80=9D attachment point down the li=
ne, and that
>> =E2=80=9Cglobal=E2=80=9D attachment point will be one of the choices (th=
e other being the
>> interface), what would this augment look like. Note, as far as I know, y=
ou
>> cannot augment inside a choice node.
>>
>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <
>> einarnn@cisco.com> wrote:
>>
>> Perhaps like this, as an augmentation to the interface:
>>
>>   augment /if:interfaces/if:interface:
>>     +--rw ingress-acls
>>     |  +--rw acl-sets
>>     |     +--rw acl-set* [name]
>>     |        +--rw name              -> /access-lists/acl/name
>>     |        +--rw type?             -> /access-lists/acl/type
>>     |        +--ro ace-statistics* [name] {interface-stats}?
>>     |           +--ro name               -> /access-lists/acl/aces/ace/n=
am
>> e
>>     |           +--ro matched-packets?   yang:counter64
>>     |           +--ro matched-octets?    yang:counter64
>>     +--rw egress-acls
>>        +--rw acl-sets
>>           +--rw acl-set* [name]
>>              +--rw name              -> /access-lists/acl/name
>>              +--rw type?             -> /access-lists/acl/type
>>              +--ro ace-statistics* [name] {interface-stats}?
>>                 +--ro name               -> /access-lists/acl/aces/ace/n=
am
>> e
>>                 +--ro matched-packets?   yang:counter64
>>                 +--ro matched-octets?    yang:counter64
>>
>>
>> Could also put an =E2=80=9Caces=E2=80=9D container above both these & re=
name
>> =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. to give a sing=
le root for the
>> augmentation if preferred.
>>
>> Cheers,
>>
>> Einar
>>
>>
>> On 6 Dec 2017, at 19:43, Eliot Lear  wrote:
>>
>>
>>
>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
>>
>> How does one move the interface attachment point, currently an
>> 'interface-ref', to an augmentation of the if:interfaces/interface,
>> inside of the =E2=80=98acl=E2=80=99  container? Down the line we might n=
eed to have an
>> container for "attachment points" to accommodate the possibility of
>> attaching an ACL either to an interface or =E2=80=9Cglobally=E2=80=9D.
>>
>>
>> Keeping in mind that one use is that an ACL doesn't attach to an
>> interface at all.
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>> _______________________________________________
>> 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


I have reviewed the changes and they look good to me.
=

Thanks,
Sonal.


On Fri, Jan 12, 2018 at 2:=
07 PM, Mahesh Jethanandani <mjethanandani@gmail.com> w=
rote:
An updated version of the draft, along with c=
hanges to remove icmp-off from the model, and updates to examples has been =
posted in the PR=C2=A0here. If there are no objections to the changes=
 by Tuesday, I will pull in the PR, and publish the draft.

Cheers.

On Jan 12, 2018, at 7=
:35 AM, Eliot Lear <=
lear@cisco.com> wrote:


 =20
   =20
 =20
  
Ok.=C2=A0 What is left to ag=
ree on at this point?
Thanks Mahesh,
Eliot

    

    

    
On 11.01.18 02:21,=
 Mahesh Jethanandani
      wrote:

    

    

     =20
      Hi Einar,
      


      

      
I can work on updating the draft as soon as we agree
        on the changes. Should take only a couple of days to turn around
        and publish the draft.

        


          

            
On Jan 9, 2018, at 11:35 PM, Eliot Lear <lear@cisco.com> wrote:

            

            

              
Hi Mahesh,
Thanks for this work.=C2=A0 I think this is
                  okay.=C2=A0 In the case of MUD we simply won't have t=
he
                  other container.=C2=A0 Can I please ask that you get the
                  draft out quickly as draft-ietf-opsawg-mud has been
                  waiting quite some time for this work to complete.
=
Eliot

                

                

                
On 10.=
01.18 04:08, Mahesh
                  Jethanandani wrote:

                

                
 I have pulled in the changes as =
they relate
                  to:
                  


                  

                  
- moving =E2=80=9Cinterface-acl=E2=80=9D under the
                    container =E2=80=9Cattachment-points=E2=80=9D making it=
 local to
                    that container.

                  
- reverting =E2=80=9Cacl-type=E2=80=9D to =E2=80=9Ct=
ype=E2=80=9D

                  
- removed =E2=80=9Cinterface-all-aggregate=E2=80=9D
                    feature

                  
- simplified source port and destination
                    port definition

                  


                  

                  
The pull request for the changes can be
                    found here.

                  


                  

                  
                  


                  

                  
After discussing with some of the
                    original contributors, decided not to include the
                    change as it relates to augmenting ietf-interfaces.
                    We did not find that the change had a particular
                    advantage over the current implementation. Even if
                    we do not completely understand how ACLs might be
                    attached =E2=80=9Cglobally=E2=80=9D or on something tha=
t is not an
                    interface, having the flexibility to attach them to
                    other attachment points is important. Keeping it as
                    interface-ref gives us that flexibility.

                  


                  

                  
Cheers.

                    


                      

                        
On Dec 18, 2017, at 4:31 AM, Eliot
                          Lear <lear@cisco.com>
                          wrote:

                        

                        

                          
So l=
ong as nobody expects an
                              interface construct in a MUD file, I'm
                              happy.

                            

                            

                            
On 17.12.17
                              15:34, Einar Nilsen-Nygaard (einarnn)
                              wrote:

                            

                            
 Eliot,
                              


                              

                              
Nothing can force an
                                implementation to have to implement
                                either the=C2=A0ietf-interfaces model or th=
e
                                augmentation in the
                                ietf-access-control-list model. I
                                appreciate your desire for modularity
                                and cohesiveness, but I would resist #1,
                                because I feel that the majority of
                                users will be targeting interface-based
                                attachment over time. I=E2=80=99ve adde bac=
k in
                                use of the =E2=80=9Cinterface-attachment=E2=
=80=9D
                                feature (which I took out as part of
                                refactoring interface attachment). Part
                                of:

                              


                              

                              

                                
                              

                              


                              

                              
The augments part of the
                                tree now looks like:

                              


                              

                              

                                
=C2=A0 augment
                                    /if:interfaces/if:interface:
                                
=C2=A0 =C2=A0 +=
--rw acls {interface-attachment}?

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0+--rw ingress

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0+--rw
                                    acl-sets

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 +--rw
                                    acl-set* [name]

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw
                                    name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0->
                                    /access-lists/acl/name

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw
                                    type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ->
                                    /access-lists/acl/type

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro
                                    ace-statistics* [name]
                                    {interface-stats}?

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    +--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ->
                                    /access-lists/acl/aces/ace/name

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    +--ro matched-packets? =C2=A0
                                    yang:counter64

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    +--ro matched-octets? =C2=A0
                                    =C2=A0yang:counter64

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0+--rw egress

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 +--rw
                                    acl-sets

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw
                                    acl-set* [name]

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw
                                    name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0->
                                    /access-lists/acl/name

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw
                                    type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ->
                                    /access-lists/acl/type

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro
                                    ace-statistics* [name]
                                    {interface-stats}?

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ->
                                    /access-lists/acl/aces/ace/name

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0+--ro matched-packets? =C2=A0
                                    yang:counter64

                                
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0+--ro matched-octets? =C2=A0
                                    =C2=A0yang:counter64

                              

                              


                              

                              

                                
Cheers,

                                


                                

                                
Einar

                                


                                

                                


                                  

                                    
On 17 Dec 2017, at
                                      11:29, Eliot Lear <lear@cisco.com>
                                      wrote:

                                    

                                    

                                      
Einar,
I think this change
                                          is fine, with one exception.=C2=
=A0
                                          I would rather the augment to
                                          the interface not be required
                                          for implementations that don'=
t
                                          actually have interfaces.=C2=A0 I
                                          understand that there may be
                                          two ways to go about this:

                                        
    
                                          
  1. Separate out the
                                            augment into a separate
                                            module (same doc is fine);
                                            or 
    2. 
                                          
  2. Somehow
                                            "feature-ize" the aug=
ment. 
    3. 
                                        
I don't know how to
                                          do (2) but if you do, that's
                                          okay by me.
Eliot

                                        

                                        

                                        
On
                                          16.12.17 14:19, Einar
                                          Nilsen-Nygaard (einarnn)
                                          wrote:

                                        

                                        
 All,
                                          


                                          

                                          
After a series
                                            of discussions on- and
                                            off-list, I have a candidate
                                            PR that includes the changes
                                            in the PR Mahesh sent out
                                            plus some more edits. Please
                                            see consolidated PR here:

                                          


                                          

                                          

                                            
                                          

                                          

                                            


                                            

                                            
Main changes
                                              in addition to Mahesh=E2=80=
=99s PR
                                              are:

                                            


                                            

                                            

                                              
    
                                                
  • Moved
                                                  interface attachment
                                                  to be via an interface
                                                  augmentation. 
    • 
                                                
  • Restructured
                                                  port matches slightly
                                                  under both IPv4 and
                                                  IPv6 containers. 
    • 
                                                
  • Removed
                                                  unnecessary identity
                                                  'interface-acl-aggreg=
ate=E2=80=99.
                                                
    • 
                                                
  • Removed
                                                  action =E2=80=98icmp-off=
=E2=80=99, can
                                                  be augmented later. 
    • 
                                              

                                            

                                            


                                            

                                            
For reference,
                                              here is the current YANG
                                              tree plus =E2=80=9C--ietf=E2=
=80=9D logs:

                                            


                                            

                                            

                                              
1=
3:12 $
                                                  pyang --ietf --lint -f
                                                  tree
                                                  ietf-access-control-list.=
yang

                                              
i=
etf-access-control-list.yang:51:
                                                  error: bad value
                                                  "YYYY-MM-DD" (s=
hould
                                                  be date)

                                              
m=
odule:
ietf-access-control-list

                                              
=
=C2=A0 =C2=A0
                                                  +--rw access-lists=


                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw acl* [name]

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 +--rw name =C2=A0 =
=C2=A0string

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 +--rw type? =C2=A0
                                                  acl-type

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 +--rw aces<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0+--rw=
 ace* [name]

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--rw name =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0strin=
g

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--rw matches

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw (l2)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(eth)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw
                                                  eth {match-on-eth}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  destination-mac-address?
                                                  =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0yang:mac-address

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  destination-mac-address-m=
ask?
                                                  =C2=A0 yang:mac-address

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  source-mac-address? =C2=
=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                                  yang:mac-address
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  source-mac-address-mask?
                                                  =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0yang:mac-address

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw ethertype? =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0eth:ethertype

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw (l3)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(ipv4)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0+--rw
                                                  ipv4 {match-on-ipv4}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw dscp? =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 inet:dscp

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw ecn? =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw length? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw ttl? =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw protocol? =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw
                                                  (source-port-range-or-operator)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0+--:(range)<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0| =C2=A0+--rw
                                                  source-port-lower =C2=A0 =
=C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 inet=
:port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0| =C2=A0+--rw
                                                  source-port-upper =C2=A0 =
=C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 inet=
:port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0+--:(operator)

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0 =C2=A0 +--rw
                                                  source-operator =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 oper=
ator

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0 =C2=A0 +--rw sourc=
e-port
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  inet:port-number
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw
                                                  (destination-port-range-o=
r-operator)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0+--:(range)<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0| =C2=A0+--rw
                                                  destination-port-lower
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0| =C2=A0+--rw
                                                  destination-port-upper
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0+--:(operator)

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0 =C2=A0 +--rw
                                                  destination-operator =C2=
=A0
                                                  =C2=A0 =C2=A0 =C2=A0opera=
tor

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
                                                  =C2=A0 =C2=A0 +--rw
                                                  destination-port =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw ihl? =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw flags? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0bits

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw offset? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw identification?
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw
                                                  destination-ipv4-network?
                                                  =C2=A0 inet:ipv4-prefix

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw
                                                  source-ipv4-network? =C2=
=A0
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
ipv4-prefix

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(ipv6)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw
                                                  ipv6 {match-on-ipv6}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw dscp? =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 inet:dscp

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw ecn? =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw length? =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw ttl? =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw protocol? =C2=
=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  (source-port-range-or-operator)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0+--:(range)<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0| =C2=A0+--rw
                                                  source-port-lower =C2=A0 =
=C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 inet=
:port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0| =C2=A0+--rw
                                                  source-port-upper =C2=A0 =
=C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 inet=
:port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0+--:(operator)

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0 =C2=A0 +--rw
                                                  source-operator =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 oper=
ator

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0 =C2=A0 +--rw sourc=
e-port
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  inet:port-number
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  (destination-port-range-o=
r-operator)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0+--:(range)<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0| =C2=A0+--rw
                                                  destination-port-lower
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0| =C2=A0+--rw
                                                  destination-port-upper
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0+--:(operator)

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0 =C2=A0 +--rw
                                                  destination-operator =C2=
=A0
                                                  =C2=A0 =C2=A0 =C2=A0opera=
tor

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
                                                  =C2=A0 =C2=A0 +--rw
                                                  destination-port =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
port-number

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  destination-ipv6-network?
                                                  =C2=A0 inet:ipv6-prefix

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw
                                                  source-ipv6-network? =C2=
=A0
                                                  =C2=A0 =C2=A0 =C2=A0inet:=
ipv6-prefix

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw flow-label? =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                  inet:ipv6-flow-label

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw (l4)?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(tcp)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0+--rw
                                                  tcp {match-on-tcp}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw sequence-number?
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0uint32

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw
                                                  acknowledgement-number?
                                                  =C2=A0 uint32
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw data-offset? =C2=A0=
 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw reserved? =C2=A0 =
=C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw flags? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0bits

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw window-size? =C2=A0=
 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw urgent-pointer?
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 uint16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw options? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0uint32

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(udp)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0+--rw
                                                  udp {match-on-udp}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0| =C2=A0 =C2=A0
                                                  +--rw length? =C2=A0 uint=
16

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0|
                                                  =C2=A0+--:(icmp)
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 +--rw
                                                  icmp {match-on-icmp}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw type? =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw code? =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 uint8

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0| =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw rest-of-heade=
r?
                                                  =C2=A0 uint32
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw
                                                  egress-interface? =C2=A0
                                                  =C2=A0if:interface-ref

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw
                                                  ingress-interface? =C2=A0
                                                  if:interface-ref
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--rw actions

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw
                                                  forwarding =C2=A0
                                                  =C2=A0identityref<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0+--rw
                                                  logging? =C2=A0 =C2=A0
                                                  =C2=A0identityref<=
/div>
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--ro
                                                  statistics
                                                  {acl-aggregate-stats}?

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0+--ro
                                                  matched-packets? =C2=A0
                                                  yang:counter64
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0+--ro
                                                  matched-octets? =C2=A0
                                                  =C2=A0yang:counter64

                                              
<=
br>
                                                

                                              
=
=C2=A0
                                                  augment
                                                  /if:interfaces/if:interfa=
ce:

                                              
=
=C2=A0 =C2=A0
                                                  +--rw acls

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw ingress

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0+--rw acl-s=
ets

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 +--=
rw acl-set*
                                                  [name]

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw name =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0->
                                                  /access-lists/acl/name

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw type?
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ->
                                                  /access-lists/acl/type

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--ro
                                                  ace-statistics* [name]
                                                  {interface-stats}?=


                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 +--ro
                                                  name =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  ->
                                                  /access-lists/acl/aces/ac=
e/name

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 +--ro
                                                  matched-packets? =C2=A0
                                                  yang:counter64
                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 +--ro
                                                  matched-octets? =C2=A0
                                                  =C2=A0yang:counter64

                                              
=
=C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0+--rw egress=


                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 +--rw acl-sets

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0+--rw=
 acl-set*
                                                  [name]

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--rw name =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0->
                                                  /access-lists/acl/name

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--rw type? =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ->
                                                  /access-lists/acl/type

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +--ro
                                                  ace-statistics* [name]
                                                  {interface-stats}?=


                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0+--ro name
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ->
                                                  /access-lists/acl/aces/ac=
e/name

                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0+--ro
                                                  matched-packets? =C2=A0
                                                  yang:counter64
                                              
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                  =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0+--ro
                                                  matched-octets? =C2=A0
                                                  =C2=A0yang:counter64

                                              


                                              

                                            

                                            
Comments
                                              welcome!

                                            


                                            

                                            

                                              
Cheers,

                                              


                                              

                                              
Einar

                                              


                                              

                                            

                                            


                                            

                                            


                                              

                                                
On 14 Dec
                                                  2017, at 18:50, Einar
                                                  Nilsen-Nygaard
                                                  (einarnn) <einarnn@cisco.com>
                                                  wrote:

                                                

                                                

                                                  
 

                                                    


                                                      

                                                        
On
                                                          14 Dec 2017,
                                                          at 08:21,
                                                          Sonal Agarwal
                                                          <sagarwal12@gmail.com>
                                                          wrote:

                                                        

                                                        

                                                          
=
Hi
                                                          Einar,
                                                          


                                                          

                                                          
You
                                                          had 3
                                                          questions for
                                                          me on all the
                                                          several e-mail
                                                          threads.=C2=A0
                                                          
1.
                                                          Global
                                                          attachment
                                                          point

                                                          
2.
                                                          icmp-off

                                                          
3.
acl-aggregate-interface stats.

                                                          


                                                          

                                                          
For
                                                          (1), my first
                                                          preference is
                                                          to have the
                                                          model define
                                                          attachment
                                                          point for
                                                          interfaces
                                                          only.

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        I have some
                                                        diffs, layered
                                                        on top of
                                                        Mahesh=E2=80=99s PR=
 to
                                                        netmod-wg/acl-model
                                                        that do this.
                                                        Nearly like the
                                                        augmentation I
                                                        have below. Feel
                                                        free to take a
                                                        look at:

                                                      


                                                      

                                                    

                                                    

                                                      
                                                    

                                                    

                                                      

                                                        


                                                        

                                                      

                                                      

                                                        

                                                          

                                                          
However,
                                                          Kristian wants
                                                          the global
                                                          attachment
                                                          point as well
                                                          so that he can
                                                          add the ACL to
                                                          the linux
                                                          tables.

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        I think Kristian
                                                        doesn=E2=80=99t fee=
l a
                                                        global
                                                        attachment point
                                                        needs to be in
                                                        this first
                                                        revision. But he
                                                        can confirm.

                                                      

                                                      

                                                        

                                                          

                                                          
If
                                                          an ACL is
                                                          attached
                                                          globally, does
                                                          this mean it
                                                          is per
                                                          direction or
                                                          does it mean
                                                          it is across
                                                          directions?

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        I don=E2=80=99t kno=
w
                                                        right now :-)

                                                      

                                                      

                                                        

                                                          

                                                          
This
                                                          global ACL may
                                                          not be
                                                          applicable to
                                                          any of Cisco'=
s
                                                          service
                                                          provider
                                                          routers as I
                                                          don't see any
                                                          platform
                                                          actually
                                                          replicating
                                                          the ACL to all
                                                          line cards and
                                                          attaching it
                                                          in ingress and
                                                          egress
                                                          directions
                                                          across all
                                                          interfaces.

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        Per other
                                                        emails, I don=E2=80=
=99t
                                                        think we
                                                        understand this
                                                        enough yet to
                                                        specify it, so I
                                                        suggest we just
                                                        leave it out for
                                                        now. Nothing in
                                                        the model
                                                        prevents a
                                                        =E2=80=9Cglobal
                                                        attachment
                                                        point=E2=80=9D bein=
g
                                                        added later once
                                                        we understand
                                                        what it really
                                                        means.

                                                      

                                                      

                                                        

                                                          

                                                          
For
                                                          (2), I am ok
                                                          with removing
                                                          icmp-off.

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        Done in my PR
                                                        above.

                                                      

                                                      

                                                        

                                                          

                                                          
For
                                                          (3), this
                                                          would have to
                                                          be a
                                                          combination of
                                                          ACL stats
                                                          across all
                                                          interfaces for
                                                          all ACL's.
                                                          Something like
                                                          this is
                                                          possible on an
                                                          XR box where
                                                          ACES have
                                                          counter names
                                                          associated
                                                          with it. Let'=
s
                                                          chat about
                                                          this offline
                                                          tomorrow.

                                                          

                                                        

                                                      

                                                      


                                                      

                                                      
einarnn>
                                                        I=E2=80=99ll ping y=
ou to
                                                        clarify, and we
                                                        can bring any
                                                        conclusion back
                                                        to the list.

                                                      


                                                      

                                                      

                                                        
Cheers,

                                                        


                                                        

                                                        
Einar

                                                        


                                                        

                                                        


                                                        

                                                      

                                                      

                                                      

                                                        

                                                          

                                                          
Sonal.

                                                          


                                                          

                                                          

                                                          


                                                          
On
                                                          Wed, Dec 13,
                                                          2017 at 12:10
                                                          PM, Mahesh
                                                          Jethanandani  <mjethanandani@gmail.com>
                                                          wrote:

                                                          

                                                          
We
                                                          want to
                                                          support
                                                          =E2=80=9Cglobal=
=E2=80=9D
                                                          attachment
                                                          point down the
                                                          line, and that
                                                          =E2=80=9Cglobal=
=E2=80=9D
                                                          attachment
                                                          point will be
                                                          one of the
                                                          choices (the
                                                          other being
                                                          the
                                                          interface),
                                                          what would
                                                          this augment
                                                          look like.
                                                          Note, as far
                                                          as I know, you
                                                          cannot augment
                                                          inside a
                                                          choice node.
                                                          

                                                          

                                                          


                                                          

                                                          

                                                          
On
                                                          Dec 13, 2017,
                                                          at 6:57 AM,
                                                          Einar
                                                          Nilsen-Nygaard
                                                          (einarnn) <einarnn@cisco.com&g=
t;
                                                          wrote:

                                                          

                                                          

                                                          
Perhaps
                                                          like this, as
                                                          an
                                                          augmentation
                                                          to the
                                                          interface:
                                                          


                                                          

                                                          

                                                          

                                                          
=C2=A0
                                                          augment
                                                          /if:interfaces/if=
:interface:

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 +--rw
                                                          ingress-acls

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0+-=
-rw
                                                          acl-sets
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 +--rw
                                                          acl-set*
                                                          [name]
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0
                                                          =C2=A0+--rw name =
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0->
                                                          /access-lists/acl=
/name

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0
                                                          =C2=A0+--rw type?=
 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          ->
                                                          /access-lists/acl=
/type

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0
                                                          =C2=A0+--ro
                                                          ace-statistics*
                                                          [name]
                                                          {interface-stats}=
?

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro name =C2=A0=
 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          ->
                                                          /access-lists/acl=
/aces/ace/name

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro
                                                          matched-packets?
                                                          =C2=A0
                                                          yang:counter64

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro
                                                          matched-octets?
                                                          =C2=A0
                                                          =C2=A0yang:counte=
r64

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 +--rw
                                                          egress-acls

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0+--rw
                                                          acl-sets
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 +--rw
                                                          acl-set*
                                                          [name]
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0+--rw name =
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0->
                                                          /access-lists/acl=
/name

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0+--rw type?=
 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          ->
                                                          /access-lists/acl=
/type

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0+--ro
                                                          ace-statistics*
                                                          [name]
                                                          {interface-stats}=
?

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro name =C2=A0=
 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          ->
                                                          /access-lists/acl=
/aces/ace/name

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro
                                                          matched-packets?
                                                          =C2=A0
                                                          yang:counter64

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          +--ro
                                                          matched-octets?
                                                          =C2=A0
                                                          =C2=A0yang:counte=
r64

                                                          

                                                          

                                                          


                                                          

                                                          
Could
                                                          also put an
                                                          =E2=80=9Caces=E2=
=80=9D
                                                          container
                                                          above both
                                                          these &
                                                          rename
                                                          =E2=80=9Cingress-=
acls"
                                                          to =E2=80=9Cingre=
ss=E2=80=9D,
                                                          etc. to give a
                                                          single root
                                                          for the
                                                          augmentation
                                                          if preferred.
                                                          


                                                          

                                                          

                                                          
Cheers,
                                                          


                                                          

                                                          
Einar

                                                          


                                                          

                                                          


                                                          

                                                          
On
                                                          6 Dec 2017, at
                                                          19:43, Eliot
                                                          Lear <lear@cisco.com>
                                                          wrote:

                                                          

                                                          

                                                          


                                                          

                                                          On 12/6/17
                                                          7:23 PM,
                                                          Mahesh
                                                          Jethanandani
                                                          wrote:

                                                          
How
                                                          does one move
                                                          the interface
                                                          attachment
                                                          point,
                                                          currently an

'interface-ref', to an augmentation of the if:interfaces/interface,=


                                                          inside of the
                                                          =E2=80=98acl=E2=
=80=99
                                                          =C2=A0container?
                                                          Down the line
                                                          we might need
                                                          to have an

                                                          container for
                                                          "attachment
                                                          points" to
                                                          accommodate
                                                          the
                                                          possibility of
                                                          attaching an
                                                          ACL either to
                                                          an interface
                                                          or =E2=80=9Cgloba=
lly=E2=80=9D.

                                                          

                                                          

                                                          

                                                          Keeping in
                                                          mind that one
                                                          use is that an
                                                          ACL doesn't
                                                          attach to an

                                                          interface at
                                                          all.

                                                          

_______________________________________________

                                                          netmod mailing
                                                          list

                                                          netmod@ietf.org

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

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
                                                          

                                                          
Mahesh
                                                          Jethanandani
                                                          
                                                          

                                                          

                                                          
                                                          

                                                          

_______________________________________________

                                                          netmod mailing
                                                          list

                                                          netmod@ietf.org

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

                                                          

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                    

                                                  

_______________________________________________

                                                  netmod mailing list

                                                  netmod@ietf.org

                                                  https://www.ietf.org/mail=
man/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

                        

                      

                    

                    

                    

                      
Mahesh Jethanandani

                      
                    

                    

                  

                  

                  

                  

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


                

                

              

            

          

        

        

        

          
Mahesh Jethanandani

          
        

        

      

    

    

  






Mahesh Jethanandani






____________________________________=
___________

netmod mailing list

netmod@ietf.org

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




--001a11404f4c16fa170562f03af3--


From nobody Tue Jan 16 19:17:15 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 ED8A612EB93 for ; Tue, 16 Jan 2018 19:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_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=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 aTZxFMuEvRnh for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 3ADEE12D949 for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST)
Received: by mail-oi0-x236.google.com with SMTP id a70so12151031oib.1 for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bNOyaV6Iml9LyOczFv5stNdyYipgSHLguHfxjWN0iaU=; b=oriZu3nhgY6FFUAK66m/nxmsJapRxezDu4Fv+s8FJ5DAdvaVzy+aQ3NuCz+cws7LaX PyJfyHaLQxdygyc4lcUt2jSWdtCs36zfgoT+a10i+G4F7IUwuykaBdPa4SiKbO6VNkIv NIU1OVAWmmZtIvun2FhPr0uVgKOQlVHAebcT7c091aRI1zYNVSujsFq3UG9JjPWavc0r dFYV9CyOWTFGX9YrrGX6Ayc6P+NSdPeAlQVxrGiNEIE7GVZnit3IO111FZAVbf/dSNdt wL9GSUO5McyC2ChDTmxh3txzEpAPK6W6eM1vxnW1JSOIsVPU2KS+Xvyi4a/bqD506WBG s4LQ==
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:date:references:to:in-reply-to:message-id; bh=bNOyaV6Iml9LyOczFv5stNdyYipgSHLguHfxjWN0iaU=; b=HFW3qEsbhQT/Y/aWdkCnCwPE1Hu50L7jP+h+F+yzp6397aIq5ALgPGzjRUBtG2GdpD lf4vJsPxIdG8z2ztdNIspLWLU6Y60jh2M+3MHNe4MbtNMk7lyxVkD0C4kbD51V70mc7G mKu+SpnDOmOXiiEa8juMUC2wBiwgbVQq/DPJS38v1RaDNKk06nQcMd2Ol/YSbzKHQXhH 7QasOTO3iDRMlE4yhN0TbucYrNySJAlOyXU+SM9+43hzgr+KA5t42kSmvavAP50P8T4R AdoghyKJ9J//pXF/VBGY3nNYx7pkY+pxLI31bkUSS5oHa2UNpXIUU2T4jw74+uW0gpUg 4BYA==
X-Gm-Message-State: AKwxytfBVDHh+gXGbYj38hmlIYLxci4Vcj5LaCgButJdP9jI41lDFqaE MqF2m1V4+fVvfaOXb5AKl1SGBuvX
X-Google-Smtp-Source: ACJfBostmQQ6Cr4eGRlKC3wSsafzZkJf44S5YV26w3XPNLkQYBuypE1YP71oPsuu16HCCyPW2LLMGw==
X-Received: by 10.202.68.215 with SMTP id r206mr303071oia.80.1516159031180; Tue, 16 Jan 2018 19:17:11 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:9460:66f7:4529:bc31]) by smtp.gmail.com with ESMTPSA id w2sm1749693ota.5.2018.01.16.19.17.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 19:17:10 -0800 (PST)
From: Mahesh Jethanandani 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 16 Jan 2018 19:17:08 -0800
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com>
To: NETMOD Working Group 
In-Reply-To: <151615867250.15562.7858111799192763218@ietfa.amsl.com>
Message-Id: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 03:17:14 -0000

This version of the drafts addresses comments received during the last =
run of the LC. We, the authors, believe that this document is ready for =
LC.

> On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        Title           : Network Access Control List (ACL) YANG Data =
Model
>        Authors         : Mahesh Jethanandani
>                          Lisa Huang
>                          Sonal Agarwal
>                          Dana Blair
> 	Filename        : draft-ietf-netmod-acl-model-15.txt
> 	Pages           : 51
> 	Date            : 2018-01-16
>=20
> Abstract:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
>=20
>   Editorial Note (To be removed by RFC Editor)
>=20
>   This draft contains many placeholder values that need to be replaced
>   with finalized values at the time of publication.  This note
>   summarizes all of the substitutions that are needed.  Please note
>   that no other RFC Editor instructions are specified anywhere else in
>   this document.
>=20
>   Artwork in this document contains shorthand references to drafts in
>   progress.  Please apply the following replacements
>=20
>   o  "XXXX" --> the assigned RFC value for this draft both in this
>      draft and in the YANG models under the revision statement.
>=20
>   o  Revision date in model needs to get updated with the date the
>      draft gets approved.  The date also needs to get reflected on the
>      line with .
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-15
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Tue Jan 16 22:50:36 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 2A58113160E; Tue, 16 Jan 2018 22:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NBqQ9q2F7C3D; Tue, 16 Jan 2018 22:50:32 -0800 (PST)
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 578E813160B; Tue, 16 Jan 2018 22:50:13 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C91A8D64A988B; Wed, 17 Jan 2018 06:50:09 +0000 (GMT)
Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 06:50:10 +0000
Received: from DGGEMA503-MBX.china.huawei.com ([169.254.1.5]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0361.001; Wed, 17 Jan 2018 14:50:01 +0800
From: "Hejia (Jia)" 
To: "rtg-ads@ietf.org" 
CC: "rtg-dir@ietf.org" , "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
Thread-Index: AdOPXq3GoHXlPWDwRv+GyrBCDNGb/Q==
Date: Wed, 17 Jan 2018 06:50:00 +0000
Message-ID: <735916399E11684EAF4EB4FB376B719553034791@DGGEMA503-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.57.113.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 06:50:34 -0000

SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl
IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0
byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh
c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg
b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp
ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi
b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHA6Ly90cmFjLnRvb2xz
LmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2UgY29t
bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv
dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg
b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2
ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk
cmFmdC4NCg0KRG9jdW1lbnQgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wOC50eHQgDQpS
ZXZpZXdlcjogSmlhIEhlIA0KUmV2aWV3IERhdGU6IDE3IEphbnVhcnkgMjAxOA0KSUVURiBMQyBF
bmQgRGF0ZTogMTUgSmFudWFyeSAyMDE4IA0KVGVsZWNoYXQgZGF0ZTogMjUgSmFudWFyeSAyMDE4
DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5DQpUaGlzIGRvY3Vt
ZW50IHByb3ZpZGVzIGFuIE5NREEtY29tcGxpYW50IHZlcnNpb24gb2YgWUFORyBkYXRhIG1vZGVs
IGZvciByb3V0aW5nIG1hbmFnZW1lbnQuIEl0IGlzIHZlcnkgd2VsbCB3cml0dGVuIGFuZCByZWFk
eSBmb3IgcHVibGljYXRpb24uIEJ1dCBJIGhhcHBlbmVkIHRvIHNlZSBhIHNtYWxsIG5pdCBpbiBB
cHBlbmRpeCBEIGp1c3QgYmVmb3JlIEkgZmluaXNoZWQgbXkgcmV2aWV3LCBzZWUgYmVsb3cuDQoN
CkNvbW1lbnRzDQpOb25lLg0KDQpNYWpvciBJc3N1ZXM6DQpObyBtYWpvciBpc3N1ZXMgZm91bmQu
DQoNCk1pbm9yIElzc3VlczoNCk5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCg0KTml0czoNCkluIEFw
cGVuZGl4IEQsIHRoZSBuYW1lc3BhY2Ugb2YgImlldGYtaXB2Ni11bmljYXN0LXJvdXRpbmciIGlz
IHdyaXR0ZW4gYXMgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWlwdjYtdW5pY2Fz
dC1yb3V0aW5nLTMiLiAiLTMiIGlzIG5vdCBtZWFuaW5nZnVsIGFuZCBuZWVkcyB0byBiZSBkZWxl
dGVkLg0KDQoNCg0KUmVnYXJkcywNCkppYQ0K


From nobody Tue Jan 16 22:59: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 930771314D1 for ; Tue, 16 Jan 2018 22:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 270zXldKEN7X for ; Tue, 16 Jan 2018 22:59:37 -0800 (PST)
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 C456512F49B for ; Tue, 16 Jan 2018 22:59:35 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id 6B0DF646B7; Wed, 17 Jan 2018 07:59:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516172373; bh=L6Acca97Cui60TGyoNw2eIHJ8VGqjIDYRDWUIdAvlCY=; h=From:To:Date; b=P8DWN9g23lsPNRRtoYbh/5UkLCqgOOiA8q2zBH/w33F34FxMYAJR7uVX4VK7PNnWc evYXEk7a2BYLRTDmQmwzg0PW8i6PoBOMkHaRkDDnALDmUgfYYRVXrhKnCAYJB3ztVv dAmVrJ/0nnsMEWp0Doa0REzenmWPYYy+9Giz0UHU=
Message-ID: <1516172373.21945.16.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , Martin Bjorklund ,  lberger@labn.net
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 07:59:33 +0100
In-Reply-To: 
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 06:59:39 -0000

On Tue, 2018-01-16 at 16:15 +0000, Robert Wilton wrote:
> 
> On 16/01/2018 15:50, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> > > 
> > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > ... (trimming to topic)
> > > > > > > > > > > rejectected by the WG multiple times.  FWIW there are
> > > > > > > > > > > drafts already
> > > > > > > > > > > with
> > > > > > > > > > 
> > > > > > > > > > No at all. The first and last time I proposed this was on 15
> > > > > > > > > > December
> > > > > > > > > > 2017:
> > > > > > > > > > 
> > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg1975
> > > > > > > > > > 3.html
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Oh, I certainly would call you proposing that the schema for
> > > > > > > > > inline be
> > > > > > > > > part of the rest of the schema Mount module well before that.
> > > > > > > > > I'm sure
> > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > 
> > > > > > > > I don't think this has been proposed before.  All previous
> > > > > > > > proposals
> > > > > > > > were basically variants on what is now "use-schema", which works
> > > > > > > > fine
> > > > > > > > when all instances have the same schema.  This new proposal
> > > > > > > > solves the
> > > > > > > > issue with different schemas in different instances.
> > > > > > > > 
> > > > > > > 
> > > > > > > I thought the previous proposals that as well, so don't see
> > > > > > > material
> > > > > > > difference - at least from the usage standpoint. I also don't see
> > > > > > > why
> > > > > > > the previous arguments that resulted in consensus for using Yang
> > > > > > > Library underneath the an in line Mount Point don't apply.
> > > > > > 
> > > > > > B/c it doesn't work well with the NMDA.  You can't mount yang
> > > > > > library
> > > > > > in the configuration datastores; it has to be mounted in
> > > > > > operational.
> > > > > > With meta-data, you can actually report the correct schema even in
> > > > > > running.  (This is actually true also for pre-NMDA systems).
> > > > > > 
> > > > > 
> > > > > Understood and agree there is nothing new here and the current version
> > > > > of SM (including inline) has the same limitation as rfc7895, and I'd
> > > > > expect it to behave the same once we have rfc7985bis -- in fact the
> > > > > inline case "just works" with YL-bis as defined today.
> > > 
> > > Martin,
> > > 
> > > you didn't respond to this point.
> > 
> > I agree, it works for non-NMDA servers. But see below.
> > 
> > > > > The argument I recall being the key point on inline was handling the
> > > > > large variety of possible different implementation approaches for
> > > > > modules using inline.
> > > > 
> > > > I think these still are covered.
> > > > 
> > > > > For example an LNE that is implemented using
> > > > > VMs which can be managed by the host at different times of the VMs
> > > > > operational life cycle based on customer/provider requirements.  I
> > > > > really don't see how YL-bis has any bearing on this point and
> > > > 
> > > > Using the new proposed meta data annotation together with the new YL
> > > > means that SM can support the use case above also in an NMDA server.
> > > > I think the new proposed solution covers more use cases than the
> > > > previous solution.
> > > 
> > > how so?  The inline mount point would contain YL-bis and have the same
> > > information there, just scoped for the mount point.  It's true a
> > > client would need to understand the mount point's schema only upon
> > > parsing the YL under the mount point and this schema could not be
> > > shared across inline mount points.  But this is as was discussed in
> > > the past and unchanged from YL.
> > > 
> > > > Do you think that there is any use case that the proposed solution
> > > > cannot handle, but the previous solution did?
> > > 
> > > yes.  with VM/container technologies the YL / schema can change under
> > > the mount point from time to time during normal operation (i.e.,
> > > during runtime, no reboot) and, in some implementations, may require
> > > some level of rpc operation to access even the schema.  The new (and
> > > previously proposed approach) of having inline schema available from
> > > the top level greatly complicates these cases.  Also keep in mind that
> > > there will be cases where the ability to access information under an
> > > inline mount point will dynamically change in operation (and top level
> > > YL would need to remove schema information for the inline mount
> > > point.)  As before, from the usage standpoint, these changes don't
> > > provide a whole lot of value and seem to optimizing for something not
> > > needed in the inline case.
> > 
> > I think this is an implementation issue, rather than a problem with
> > the proposed mechanism, and it is present in the current solution as
> > well.  An implementation that can handle dynamically changing mounted
> > YLs in the current solution can do that in the new solution as well.
> > 
> > > > > I think
> > > > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > > > this case, inline schema being represented by YL) to argue why the
> > > > > decision needs to be revisited.
> > > > 
> > > > I'm repeating my self: b/c the current solution doesn't work well with
> > > > the NMDA.
> > > 
> > > I simply don't understand how YL-bis works at the root node but
> > > doesn't work equally at an inline mount point.  Can you elaborate?
> > 
> > With NMDA, a server may have one schema for the config datastore and
> > another one for operational (one is a superset of the other).  A
> > mounted YL can only be present in operational.  Thus, there's no way a
> > client can learn the schema for config.
> 
> If the LNE mounted the full YL-bis at the mount point then you would 
> have the list of datastores, and the schema associated with each 
> datastore.  Of course, this would only be available in operational, but 
> that is the same as a regular server support YL-bis.

YL-bis is different in that it is in fact metadata even though we call it state
data. In any case, no matter what datastores the server has, YL-bis is the
single well-known location from which the schema of all datastores can be
retrieved.

We could refer to  as the place from which the mounted schemas of
NMDA-standard config datastores can be retrieved (except for special cases, one
is discussed below). But if there is another config datastore (e.g. dynamic)
with an inline mount point instance, it is unclear where to look for the mounted
schema. With my proposal, the mount point instance will be annotated with
@schema-ref that points to a schema in the top-level YL.

> 
> I thought that the problem with the current solution and NMDA, was that 
> there is no way to find out what the LNE schema is if the LNE isn't 
> booted, and hence isn't providing .  But I'm not sure what 
> issues that actually causes.  E.g. does it cause issues with 
> pre-configuration of the LNE?

The issue that this causes is that the schema for the pre-configured LNE isn't
known and validity of  is unclear.

Lada

> 
> Thanks,
> Rob
> 
> 
> > 
> > With the proposed solution, there can be different schema-ref pointers
> > in config and operational (if needed).
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > 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 Jan 16 23:11: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 6FCB813160C for ; Tue, 16 Jan 2018 23:11:26 -0800 (PST)
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_RP_MATCHES_RCVD=-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 pUAlNuKFBj3x for ; Tue, 16 Jan 2018 23:11:23 -0800 (PST)
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 0F4A91315EE for ; Tue, 16 Jan 2018 23:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10127; q=dns/txt; s=iport; t=1516173083; x=1517382683; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=lvMVkjqIoSiXCxHJPcwala50EioyBjstaZJ5Lc+Ks58=; b=ZR6C4+r3UJhJ2P/sYG5Ljs6Nrmy0/Rln0Aug0+LNlpGcOYLm0NSKrF2D WJgFhzaL24YnyexPSaSvTD9l4kg40hS6DzwfN6/XN8hrgMofLGwSJfWpC mlQuxHcdiSmglg3Fm8Pbh1Y8atG3dRqRSsM6pxIxkMfDYM748eGD5pdF0 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQCO9l5a/xbLJq1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEYEWdCeEE4sYj3CJB4hWhWWCAgoYAQeETE8ChSEUAQEBAQE?= =?us-ascii?q?BAQEBayiFJAEBBAEBIQRHGwsOCioCAiEGMAYBDAYCAQGKFwMVEDSlLIFtOiaHG?= =?us-ascii?q?Q2CBAEBAQEBAQEBAQEBAQEBAQEBAQEfiCiBaSmDBYJrRAEBAQEBAReBPoMvgmU?= =?us-ascii?q?FgV2hUD2IDYEghyGFA4IZZ4U2g2+HbI1BQIEeiAqBPDYigVAyGggbFRkkgioJh?= =?us-ascii?q?E9ANwEBAQGJHiyCHQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,371,1511827200"; d="scan'208,217";a="1446585"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 07:11:21 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0H7BKjD016154; Wed, 17 Jan 2018 07:11:20 GMT
To: Mahesh Jethanandani , NETMOD Working Group 
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
From: Benoit Claise 
Message-ID: <61065d4e-db09-365c-de81-d8ebad60ab0c@cisco.com>
Date: Wed, 17 Jan 2018 08:11:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
Content-Type: multipart/alternative; boundary="------------BFD425118A5151D8A29AFA6C"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 07:11:26 -0000

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

Hi Mahesh,

There is an error with the yangdump-pro:

    Error: Feature 'match-on-eth and match-on-ipv4' not found for
    if-feature statement
    ietf-access-control-list@2018-01-16.yang:242.16: error(250):
    definition not found

    Error: Feature 'match-on-eth and match-on-ipv6' not found for
    if-feature statement
    ietf-access-control-list@2018-01-16.yang:248.16: error(250):
    definition not found

    Error: Feature 'match-on-eth and match-on-ipv4
    and match-on-ipv6' not found for if-feature statement
    ietf-access-control-list@2018-01-16.yang:253.16: error(250):
    definition not found

    ***
    *** 3 Errors, 0 Warnings

See http://www.claise.be/IETFYANGPageCompilation.html

Also, you want to inform and help the dependent YANG modules (Yang 
impact analysis for draft-ietf-netmod-acl-model 
) 
validate correctly.

Regards, Benoit
> This version of the drafts addresses comments received during the last run of the LC. We, the authors, believe that this document is ready for LC.
>
>> On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:
>>
>>
>> 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           : Network Access Control List (ACL) YANG Data Model
>>         Authors         : Mahesh Jethanandani
>>                           Lisa Huang
>>                           Sonal Agarwal
>>                           Dana Blair
>> 	Filename        : draft-ietf-netmod-acl-model-15.txt
>> 	Pages           : 51
>> 	Date            : 2018-01-16
>>
>> Abstract:
>>    This document describes a data model of Access Control List (ACL)
>>    basic building blocks.
>>
>>    Editorial Note (To be removed by RFC Editor)
>>
>>    This draft contains many placeholder values that need to be replaced
>>    with finalized values at the time of publication.  This note
>>    summarizes all of the substitutions that are needed.  Please note
>>    that no other RFC Editor instructions are specified anywhere else in
>>    this document.
>>
>>    Artwork in this document contains shorthand references to drafts in
>>    progress.  Please apply the following replacements
>>
>>    o  "XXXX" --> the assigned RFC value for this draft both in this
>>       draft and in the YANG models under the revision statement.
>>
>>    o  Revision date in model needs to get updated with the date the
>>       draft gets approved.  The date also needs to get reflected on the
>>       line with .
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
>>
>>
>> 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/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------BFD425118A5151D8A29AFA6C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Mahesh,

      

      There is an error with the yangdump-pro:

      

      
Error: Feature 'match-on-eth and match-on-ipv4' not
        found for if-feature statement

        ietf-access-control-list@2018-01-16.yang:242.16: error(250):
        definition not found

        

        Error: Feature 'match-on-eth and match-on-ipv6' not found for
        if-feature statement

        ietf-access-control-list@2018-01-16.yang:248.16: error(250):
        definition not found

        

        Error: Feature 'match-on-eth and match-on-ipv4

        and match-on-ipv6' not found for if-feature statement

        ietf-access-control-list@2018-01-16.yang:253.16: error(250):
        definition not found

        

        *** 

        *** 3 Errors, 0 Warnings

    

    See http://www.claise.be/IETFYANGPageCompilation.html

    

    Also, you want to inform and help the dependent YANG modules (Yang
      impact analysis for draft-ietf-netmod-acl-model) validate
    correctly.

    

    Regards, Benoit

    

      
This version of the drafts addresses comments received during the last run of the LC. We, the authors, believe that this document is ready for LC.



      

        
On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:


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           : Network Access Control List (ACL) YANG Data Model
       Authors         : Mahesh Jethanandani
                         Lisa Huang
                         Sonal Agarwal
                         Dana Blair
	Filename        : draft-ietf-netmod-acl-model-15.txt
	Pages           : 51
	Date            : 2018-01-16

Abstract:
  This document describes a data model of Access Control List (ACL)
  basic building blocks.

  Editorial Note (To be removed by RFC Editor)

  This draft contains many placeholder values that need to be replaced
  with finalized values at the time of publication.  This note
  summarizes all of the substitutions that are needed.  Please note
  that no other RFC Editor instructions are specified anywhere else in
  this document.

  Artwork in this document contains shorthand references to drafts in
  progress.  Please apply the following replacements

  o  "XXXX" --> the assigned RFC value for this draft both in this
     draft and in the YANG models under the revision statement.

  o  Revision date in model needs to get updated with the date the
     draft gets approved.  The date also needs to get reflected on the
     line with <CODE BEGINS>.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15


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/

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


      

      
Mahesh Jethanandani
mjethanandani@gmail.com

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



    

    

  


--------------BFD425118A5151D8A29AFA6C--


From nobody Tue Jan 16 23:43: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 BE6A912F3D0 for ; Tue, 16 Jan 2018 23:43:22 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 W0Xcq32tVCR6 for ; Tue, 16 Jan 2018 23:43:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF59812EC56 for ; Tue, 16 Jan 2018 23:43:20 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 20A811AE0385; Wed, 17 Jan 2018 08:43:18 +0100 (CET)
Date: Wed, 17 Jan 2018 08:43:18 +0100 (CET)
Message-Id: <20180117.084318.1633996450082512639.mbj@tail-f.com>
To: alexander.clemm@huawei.com
Cc: rwilton@cisco.com, vladimir@transpacket.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com>
References: <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 07:43:23 -0000

Alexander Clemm  wrote:
> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> here.  The purpose is to make this human-readable and provide readers
> a good sense of the overall structure.  The authoritative
> specification is still the .yang itself.  Providing some guidance for
> how to represent the tree is good but let's not over-engineer this; I
> believe retaining some flexibility is good.

The last sentence summarizes my personal view.  I prefer (1), followed
by (2).


/martin

> --- Alex 
> 
> > -----Original Message-----
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >    1) allow any number of addtional spaces
> > >    2) allow any number of addtional spaces + define a suggested
> > >       alignment algorithm
> > >    3) mandate the alignment algorithm
> > 
> > Definition of symbols should be precise/consistent, so that readers
> > can
> > consistently interpret tree diagrams.
> > 
> > I think that flexibility in layout should be OK, but the draft should
> > provide
> > guideline to ensure the output is readable, and likely to be broadly
> > consistent
> > (since consistency aids readability).
> > 
> > If the IETF data modeling group is trying to specify text output
> > precisely
> > enough that it can be screen scraped then we may want to consider
> > whether
> > we are focusing on the right solution ;-)
> > 
> > In summary, (2) is my preference, followed by (1), followed by (3).
> > 
> > Thanks,
> > Rob
> > 
> > >
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > 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 Wed Jan 17 00:04:38 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 E3A58126C2F for ; Wed, 17 Jan 2018 00:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tm7eAtTzzz0O for ; Wed, 17 Jan 2018 00:04:34 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8B124B18 for ; Wed, 17 Jan 2018 00:04:34 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 4B3151820412; Wed, 17 Jan 2018 09:03:47 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 367171820410; Wed, 17 Jan 2018 09:03:44 +0100 (CET)
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
In-Reply-To: <8f131d74-878a-6edb-a09c-6047b83dc6de@labn.net>
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <1516116166.18487.18.camel@nic.cz> <8f131d74-878a-6edb-a09c-6047b83dc6de@labn.net>
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
Date: Wed, 17 Jan 2018 09:04:29 +0100
Message-ID: <87tvvk6hde.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:04:37 -0000

Lou Berger  writes:

> On 1/16/2018 10:22 AM, Ladislav Lhotka wrote:
>>>> I think
>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>> this case, inline schema being represented by YL) to argue why the
>>>> decision needs to be revisited.
>>> I'm repeating my self: b/c the current solution doesn't work well with
>>> the NMDA.
>> We can try to update the draft and the examples, it should then be much =
more
>> clear. It is really very little extra work.
>>
>> Lada
>>
>
> Lada,
>  =C2=A0=C2=A0=C2=A0 Understanding impact of your proposal on the followin=
g would be=20
> quite helpful:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub request=
ed)
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub
>  requested)

In these two drafts, the examples in their appendices have to be updated.

> https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/

AFAICT, there is no impact on this draft.

Lada

>
> Lou
>
>

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 17 00:20:10 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 8B7CE12F4D0 for ; Wed, 17 Jan 2018 00:20:08 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 121Ufpnwp2hW for ; Wed, 17 Jan 2018 00:20:05 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0912F4D8 for ; Wed, 17 Jan 2018 00:20:04 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id D2F601AE0385; Wed, 17 Jan 2018 09:20:02 +0100 (CET)
Date: Wed, 17 Jan 2018 09:20:02 +0100 (CET)
Message-Id: <20180117.092002.464472752076487902.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net>
References: <20180116.165014.297580929914718463.mbj@tail-f.com>  <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:20:08 -0000

Lou Berger  wrote:
> =

> =

> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >
> > On 16/01/2018 15:50, Martin Bjorklund wrote:
> >> Lou Berger  wrote:
> >>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> >>> ... (trimming to topic)
> >>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are dra=
fts
> >>>>>>>>>>> already
> >>>>>>>>>>> with
> >>>>>>>>>> No at all. The first and last time I proposed this was on =
15
> >>>>>>>>>> December
> >>>>>>>>>> 2017:
> >>>>>>>>>>
> >>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19=
753.html
> >>>>>>>>>>
> >>>>>>>>> Oh, I certainly would call you proposing that the schema fo=
r inline
> >>>>>>>>> be
> >>>>>>>>> part of the rest of the schema Mount module well before tha=
t. I'm
> >>>>>>>>> sure
> >>>>>>>>> I can dig up mail / slides it really necessary...
> >>>>>>>> I don't think this has been proposed before.  All previous p=
roposals
> >>>>>>>> were basically variants on what is now "use-schema", which w=
orks fine
> >>>>>>>> when all instances have the same schema.  This new proposal =
solves the
> >>>>>>>> issue with different schemas in different instances.
> >>>>>>>>
> >>>>>>> I thought the previous proposals that as well, so don't see m=
aterial
> >>>>>>> difference - at least from the usage standpoint. I also don't=
 see why
> >>>>>>> the previous arguments that resulted in consensus for using Y=
ang
> >>>>>>> Library underneath the an in line Mount Point don't apply.
> >>>>>> B/c it doesn't work well with the NMDA.  You can't mount yang =
library
> >>>>>> in the configuration datastores; it has to be mounted in opera=
tional.
> >>>>>> With meta-data, you can actually report the correct schema eve=
n in
> >>>>>> running.  (This is actually true also for pre-NMDA systems).
> >>>>>>
> >>>>> Understood and agree there is nothing new here and the current =
version
> >>>>> of SM (including inline) has the same limitation as rfc7895, an=
d I'd
> >>>>> expect it to behave the same once we have rfc7985bis -- in fact=
 the
> >>>>> inline case "just works" with YL-bis as defined today.
> >>> Martin,
> >>>
> >>> you didn't respond to this point.
> >> I agree, it works for non-NMDA servers. But see below.
> >>
> >>>>> The argument I recall being the key point on inline was handlin=
g the
> >>>>> large variety of possible different implementation approaches f=
or
> >>>>> modules using inline.
> >>>> I think these still are covered.
> >>>>
> >>>>> For example an LNE that is implemented using
> >>>>> VMs which can be managed by the host at different times of the =
VMs
> >>>>> operational life cycle based on customer/provider requirements.=
=A0 I
> >>>>> really don't see how YL-bis has any bearing on this point and
> >>>> Using the new proposed meta data annotation together with the ne=
w YL
> >>>> means that SM can support the use case above also in an NMDA ser=
ver.
> >>>> I think the new proposed solution covers more use cases than the=

> >>>> previous solution.
> >>> how so?=A0 The inline mount point would contain YL-bis and have t=
he same
> >>> information there, just scoped for the mount point.=A0 It's true =
a
> >>> client would need to understand the mount point's schema only upo=
n
> >>> parsing the YL under the mount point and this schema could not be=

> >>> shared across inline mount points.=A0 But this is as was discusse=
d in
> >>> the past and unchanged from YL.
> >>>
> >>>> Do you think that there is any use case that the proposed soluti=
on
> >>>> cannot handle, but the previous solution did?
> >>> yes.=A0 with VM/container technologies the YL / schema can change=
 under
> >>> the mount point from time to time during normal operation (i.e.,
> >>> during runtime, no reboot) and, in some implementations, may requ=
ire
> >>> some level of rpc operation to access even the schema.=A0 The new=
 (and
> >>> previously proposed approach) of having inline schema available f=
rom
> >>> the top level greatly complicates these cases.=A0 Also keep in mi=
nd that
> >>> there will be cases where the ability to access information under=
 an
> >>> inline mount point will dynamically change in operation (and top =
level
> >>> YL would need to remove schema information for the inline mount
> >>> point.)=A0 As before, from the usage standpoint, these changes do=
n't
> >>> provide a whole lot of value and seem to optimizing for something=
 not
> >>> needed in the inline case.
> >> I think this is an implementation issue, rather than a problem wit=
h
> >> the proposed mechanism, and it is present in the current solution =
as
> >> well.  An implementation that can handle dynamically changing moun=
ted
> >> YLs in the current solution can do that in the new solution as wel=
l.
> >>
> >>>>> I think
> >>>>> it is incumbent upon those revisiting past/closed WG decisions =
(in
> >>>>> this case, inline schema being represented by YL) to argue why =
the
> >>>>> decision needs to be revisited.
> >>>> I'm repeating my self: b/c the current solution doesn't work wel=
l with
> >>>> the NMDA.
> >>> I simply don't understand how YL-bis works at the root node but
> >>> doesn't work equally at an inline mount point.=A0 Can you elabora=
te?
> >> With NMDA, a server may have one schema for the config datastore a=
nd
> >> another one for operational (one is a superset of the other).  A
> >> mounted YL can only be present in operational.  Thus, there's no w=
ay a
> >> client can learn the schema for config.
> > If the LNE mounted the full YL-bis at the mount point then you woul=
d
> > have the list of datastores, and the schema associated with each
> > datastore.=A0 Of course, this would only be available in operationa=
l,
> > but
> > that is the same as a regular server support YL-bis.
> exactly my point.

Yes, you're right.  But it requires the usage of YL-bis.

> > I thought that the problem with the current solution and NMDA, was
> > that
> > there is no way to find out what the LNE schema is if the LNE isn't=

> > booted, and hence isn't providing .
> I've never heard anyone mention this issue/limitation.

This has been dicussed, but this does not change with the introduction
of the meta annotation; if the server has off-line knowledge of the
instance's schema then it can populate an inline YL as well as the
meta annotation and corresponding SM data.

> My
> understanding of the previously raised objections were (a) that the
> full schema can't be obtained by just reading the top level YL and (b=
)
> that when multiple inline mount points have the same schema the
> information can't be combined using a shared schema approach as is
> taken in base SM.

Right.  Both these issues are addressed by using a meta annotation.


/martin


> Yes both increase client operations/work, but
> without incurring the server side implementation overhead that is
> implied in this approach.=A0 -- Again, I don't see how YL-bis or NMDA=

> changes any of this.
> =

> >   But I'm not sure what
> > issues that actually causes.=A0 E.g. does it cause issues with
> > pre-configuration of the LNE?
> Assignment of host resources takes place at the root level, not the
> within the context of the inline mount point, other preprovisiong can=

> be handled via the inline/managed mechanisms defined in the LNE
> module.=A0 We looked at this in detail for multiple server/vendor
> implementations and agreed the current mechanisms work even if not
> optimal in all cases.
> =

> Lou
> =

> > Thanks,
> > Rob
> >
> >
> >> With the proposed solution, there can be different schema-ref poin=
ters
> >> in config and operational (if needed).
> >>
> >>
> >> /martin
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> .
> >>
> >
> =


From nobody Wed Jan 17 00:27: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 B2E7A12F4C9 for ; Wed, 17 Jan 2018 00:27:24 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 xPKl2N08TQ7U for ; Wed, 17 Jan 2018 00:27:22 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D8012F4C3 for ; Wed, 17 Jan 2018 00:27:22 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 76C07673; Wed, 17 Jan 2018 09:27:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id JEWPWRup-azW; Wed, 17 Jan 2018 09:27:19 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 09:27:20 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B61B2013F; Wed, 17 Jan 2018 09:27:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yTAw1Q3qvCur; Wed, 17 Jan 2018 09:27:20 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E65F2013E; Wed, 17 Jan 2018 09:27:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D335A4212C91; Wed, 17 Jan 2018 09:27:18 +0100 (CET)
Date: Wed, 17 Jan 2018 09:27:18 +0100
From: Juergen Schoenwaelder 
To: Lou Berger , Martin Bjorklund , netmod@ietf.org
Message-ID: <20180117082718.32ob6hd55xan5s7x@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <1516116166.18487.18.camel@nic.cz> <8f131d74-878a-6edb-a09c-6047b83dc6de@labn.net> <87tvvk6hde.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <87tvvk6hde.fsf@nic.cz>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:27:25 -0000

On Wed, Jan 17, 2018 at 09:04:29AM +0100, Ladislav Lhotka wrote:
> > Lada,
> >   Understanding impact of your proposal on the following would be 
> > quite helpful:
> > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub requested)
> > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub
> >  requested)
> 
> In these two drafts, the examples in their appendices have to be updated.
> 
> > https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/
> 
> AFAICT, there is no impact on this draft.

Ideally data models should be decoupled from the mechanics with which
the (datastore) schema is announced.

/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 Jan 17 00:30: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 5076412FA71 for ; Wed, 17 Jan 2018 00:30:13 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 vV84X5jiCB6z for ; Wed, 17 Jan 2018 00:30:11 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AB312FA7B for ; Wed, 17 Jan 2018 00:30:08 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AAB869A; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id L7zOa5id6HOT; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 919F720147; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YNmbjTdSnutD; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CDF52013F; Wed, 17 Jan 2018 09:30:07 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0F87E4212D62; Wed, 17 Jan 2018 09:30:05 +0100 (CET)
Date: Wed, 17 Jan 2018 09:30:05 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: alexander.clemm@huawei.com, netmod@ietf.org
Message-ID: <20180117083005.q5mllkolafiehgtx@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , alexander.clemm@huawei.com, netmod@ietf.org
References: <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <20180117.084318.1633996450082512639.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180117.084318.1633996450082512639.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:30:13 -0000

On Wed, Jan 17, 2018 at 08:43:18AM +0100, Martin Bjorklund wrote:
> Alexander Clemm  wrote:
> > +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> > here.  The purpose is to make this human-readable and provide readers
> > a good sense of the overall structure.  The authoritative
> > specification is still the .yang itself.  Providing some guidance for
> > how to represent the tree is good but let's not over-engineer this; I
> > believe retaining some flexibility is good.
> 
> The last sentence summarizes my personal view.  I prefer (1), followed
> by (2).

+1

/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 Jan 17 00:33: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 9F02612FA76 for ; Wed, 17 Jan 2018 00:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 7KPRXgNEb-KE for ; Wed, 17 Jan 2018 00:33:50 -0800 (PST)
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 1B96712F5DB for ; Wed, 17 Jan 2018 00:33:49 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id 87C6F64259; Wed, 17 Jan 2018 09:33:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516178027; bh=LKG/Q3FQvNGUZfx8ow1434DEImBOULlExARlHsOohs4=; h=From:To:Date; b=vKEsK84cRZh6bWealSZTjOK6UO9onqGKKyrjCnESPx1geu8TYHeLW55o2s5lGDUts poEfujSGEn63KevQioSrpfBGoOy19SCQ6yZ8f0VCjH7cqOtEnikl2Sz30lOsusu6SR VXuGOybNzwcvQvGk2tOmAuWJf+ekXGxIJHRWIzvA=
Message-ID: <1516178027.21945.35.camel@nic.cz>
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Lou Berger , Martin Bjorklund , netmod@ietf.org
Date: Wed, 17 Jan 2018 09:33:47 +0100
In-Reply-To: <20180117082718.32ob6hd55xan5s7x@elstar.local>
References: <160ff28ef68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180116.145003.1110791592584714461.mbj@tail-f.com> <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <1516116166.18487.18.camel@nic.cz> <8f131d74-878a-6edb-a09c-6047b83dc6de@labn.net> <87tvvk6hde.fsf@nic.cz> <20180117082718.32ob6hd55xan5s7x@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:33:53 -0000

On Wed, 2018-01-17 at 09:27 +0100, Juergen Schoenwaelder wrote:
> On Wed, Jan 17, 2018 at 09:04:29AM +0100, Ladislav Lhotka wrote:
> > > Lada,
> > >      Understanding impact of your proposal on the following would be 
> > > quite helpful:
> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub
> > > requested)
> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub
> > >  requested)
> > 
> > In these two drafts, the examples in their appendices have to be updated.
> > 
> > > https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/
> > 
> > AFAICT, there is no impact on this draft.
> 
> Ideally data models should be decoupled from the mechanics with which
> the (datastore) schema is announced.

Agreed, and that's why the l3vpn draft is unaffected. The LNE and NI drafts
demonstrate in the appendices how the entire data model is constructed via
schema mount, so this would change.

Lada 

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 17 00:59: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 9679F12FAB6 for ; Wed, 17 Jan 2018 00:59:10 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aBvseQbMHhNZ for ; Wed, 17 Jan 2018 00:59:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAAA12FAC2 for ; Wed, 17 Jan 2018 00:59:06 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 56A911AE0385; Wed, 17 Jan 2018 09:59:04 +0100 (CET)
Date: Wed, 17 Jan 2018 09:59:04 +0100 (CET)
Message-Id: <20180117.095904.378804835069157722.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: mjethanandani@gmail.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <61065d4e-db09-365c-de81-d8ebad60ab0c@cisco.com>
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> <61065d4e-db09-365c-de81-d8ebad60ab0c@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 08:59:11 -0000

Hi,

These errors seem to be issues with the tool, not the draft.


/martin

Benoit Claise  wrote:
> Hi Mahesh,
> 
> There is an error with the yangdump-pro:
> 
>    Error: Feature 'match-on-eth and match-on-ipv4' not found for
>    if-feature statement
>    ietf-access-control-list@2018-01-16.yang:242.16: error(250):
>    definition not found
> 
>    Error: Feature 'match-on-eth and match-on-ipv6' not found for
>    if-feature statement
>    ietf-access-control-list@2018-01-16.yang:248.16: error(250):
>    definition not found
> 
>    Error: Feature 'match-on-eth and match-on-ipv4
>    and match-on-ipv6' not found for if-feature statement
>    ietf-access-control-list@2018-01-16.yang:253.16: error(250):
>    definition not found
> 
>    ***
>    *** 3 Errors, 0 Warnings
> 
> See http://www.claise.be/IETFYANGPageCompilation.html
> 
> Also, you want to inform and help the dependent YANG modules (Yang
> impact analysis for draft-ietf-netmod-acl-model
> )
> validate correctly.
> 
> Regards, Benoit
> > This version of the drafts addresses comments received during the last
> > run of the LC. We, the authors, believe that this document is ready
> > for LC.
> >
> >> On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:
> >>
> >>
> >> 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           : Network Access Control List (ACL) YANG Data Model
> >>         Authors         : Mahesh Jethanandani
> >>                           Lisa Huang
> >>                           Sonal Agarwal
> >>                           Dana Blair
> >> 	Filename        : draft-ietf-netmod-acl-model-15.txt
> >> 	Pages           : 51
> >> 	Date            : 2018-01-16
> >>
> >> Abstract:
> >>    This document describes a data model of Access Control List (ACL)
> >>    basic building blocks.
> >>
> >>    Editorial Note (To be removed by RFC Editor)
> >>
> >>    This draft contains many placeholder values that need to be replaced
> >>    with finalized values at the time of publication.  This note
> >>    summarizes all of the substitutions that are needed.  Please note
> >>    that no other RFC Editor instructions are specified anywhere else in
> >>    this document.
> >>
> >>    Artwork in this document contains shorthand references to drafts in
> >>    progress.  Please apply the following replacements
> >>
> >>    o  "XXXX" --> the assigned RFC value for this draft both in this
> >>       draft and in the YANG models under the revision statement.
> >>
> >>    o  Revision date in model needs to get updated with the date the
> >>       draft gets approved.  The date also needs to get reflected on the
> >>       line with .
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
> >>
> >>
> >> 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/
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > Mahesh Jethanandani
> > mjethanandani@gmail.com
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 


From nobody Wed Jan 17 01:05:16 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 C2CF112F26D for ; Wed, 17 Jan 2018 01:05:14 -0800 (PST)
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_RP_MATCHES_RCVD=-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 G0r2Ivz3_OUk for ; Wed, 17 Jan 2018 01:05:12 -0800 (PST)
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 58C9E12FAE5 for ; Wed, 17 Jan 2018 01:05:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4431; q=dns/txt; s=iport; t=1516179908; x=1517389508; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=c901HFExehs08cBBa4gKlnhZuNezYZS0MF2/gkCXQPc=; b=gfAsgYRYvlcRhV1e58Su8ATUFGcuRCpY5kwOEL8iOWNcGV9YTCavZtyx tpy7ze3FaR9k7Xa/yzphmhI2RA21aYHoArsWnHUcAvOUcWWsXa5ZwXHtz BIFJ6K6slG1AKKLAMHyFvssnFl2DMLfp+Ol9f8ycvDrrhdsn6nmkwb7gX E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAQBmEV9a/xbLJq1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJ3QnhBOLGI9HJ4kHjjuCAgoYC4RJTwKFIhQBAQEBAQEBAQF?= =?us-ascii?q?rKIUkAQEEAQEhBBE2CxALDgoCAiYCAiEGMAYNBgIBAYoXAxUQNKVggW06hz4Ng?= =?us-ascii?q?gQBAQEBAQEBAQEBAQEBAQEBAQEBAR6BD4cZgWkpDIJ5gmtEAQEBAQEBF4E+gy+?= =?us-ascii?q?CZQWjLT2IDYEghyGFA4IZZ4U2g2+HbI1BQIEeiAqBPDYigVAyGggbFRkkgioJh?= =?us-ascii?q?E9ANwGJISyCHQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200";  d="scan'208";a="1494033"
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; 17 Jan 2018 09:05:05 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0H9550h001027; Wed, 17 Jan 2018 09:05:05 GMT
To: Martin Bjorklund 
Cc: mjethanandani@gmail.com, netmod@ietf.org
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> <61065d4e-db09-365c-de81-d8ebad60ab0c@cisco.com> <20180117.095904.378804835069157722.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: <7097e456-2900-ef1f-2efa-feaaa6a37d38@cisco.com>
Date: Wed, 17 Jan 2018 10:05:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180117.095904.378804835069157722.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 09:05:15 -0000

On 1/17/2018 9:59 AM, Martin Bjorklund wrote:
> Hi,
>
> These errors seem to be issues with the tool, not the draft.
Good to know Martin. Thanks.

Regards, Benoit
>
>
> /martin
>
> Benoit Claise  wrote:
>> Hi Mahesh,
>>
>> There is an error with the yangdump-pro:
>>
>>     Error: Feature 'match-on-eth and match-on-ipv4' not found for
>>     if-feature statement
>>     ietf-access-control-list@2018-01-16.yang:242.16: error(250):
>>     definition not found
>>
>>     Error: Feature 'match-on-eth and match-on-ipv6' not found for
>>     if-feature statement
>>     ietf-access-control-list@2018-01-16.yang:248.16: error(250):
>>     definition not found
>>
>>     Error: Feature 'match-on-eth and match-on-ipv4
>>     and match-on-ipv6' not found for if-feature statement
>>     ietf-access-control-list@2018-01-16.yang:253.16: error(250):
>>     definition not found
>>
>>     ***
>>     *** 3 Errors, 0 Warnings
>>
>> See http://www.claise.be/IETFYANGPageCompilation.html
>>
>> Also, you want to inform and help the dependent YANG modules (Yang
>> impact analysis for draft-ietf-netmod-acl-model
>> )
>> validate correctly.
>>
>> Regards, Benoit
>>> This version of the drafts addresses comments received during the last
>>> run of the LC. We, the authors, believe that this document is ready
>>> for LC.
>>>
>>>> On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:
>>>>
>>>>
>>>> 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           : Network Access Control List (ACL) YANG Data Model
>>>>          Authors         : Mahesh Jethanandani
>>>>                            Lisa Huang
>>>>                            Sonal Agarwal
>>>>                            Dana Blair
>>>> 	Filename        : draft-ietf-netmod-acl-model-15.txt
>>>> 	Pages           : 51
>>>> 	Date            : 2018-01-16
>>>>
>>>> Abstract:
>>>>     This document describes a data model of Access Control List (ACL)
>>>>     basic building blocks.
>>>>
>>>>     Editorial Note (To be removed by RFC Editor)
>>>>
>>>>     This draft contains many placeholder values that need to be replaced
>>>>     with finalized values at the time of publication.  This note
>>>>     summarizes all of the substitutions that are needed.  Please note
>>>>     that no other RFC Editor instructions are specified anywhere else in
>>>>     this document.
>>>>
>>>>     Artwork in this document contains shorthand references to drafts in
>>>>     progress.  Please apply the following replacements
>>>>
>>>>     o  "XXXX" --> the assigned RFC value for this draft both in this
>>>>        draft and in the YANG models under the revision statement.
>>>>
>>>>     o  Revision date in model needs to get updated with the date the
>>>>        draft gets approved.  The date also needs to get reflected on the
>>>>        line with .
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15
>>>>
>>>>
>>>> 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/
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
> .
>


From nobody Wed Jan 17 01:08: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 B0E1012FAA8 for ; Wed, 17 Jan 2018 01:08:11 -0800 (PST)
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 cPjNbrTAgLS0 for ; Wed, 17 Jan 2018 01:08:09 -0800 (PST)
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 A63AD12EB6B for ; Wed, 17 Jan 2018 01:08:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D4A4414620BF; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
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 vfioZH7y-bFN; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id AB67614620D4; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
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 axRBhy5QK7RB; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from [192.168.43.32] (77.16.194.13.tmi.telenormobil.no [77.16.194.13]) by mail.transpacket.com (Postfix) with ESMTPSA id 65F9914620BF; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
To: joel jaeggli , Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>   <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com> <20180116200636.w437ttcwyqswnj2t@elstar.local>
From: Vladimir Vassilev 
Message-ID: 
Date: Wed, 17 Jan 2018 10:08:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20180116200636.w437ttcwyqswnj2t@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 09:08:11 -0000

On 01/16/2018 09:06 PM, Juergen Schoenwaelder wrote:
> On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:
>> As for the automated validation of the tree diagrams as an added value=
 to
>> the human readability I have the following thoughts. I would like to b=
e able
>> to compare unlimited line length tree outputs generated by different Y=
ANG
>> compilers for equality. This is mainly a way to have some partial comm=
on
>> denominator output for validating YANG is correctly compiled which we =
did
>> not have until now. For example as soon as I have support for Schema m=
ount I
>> would compare the tree output with another tool known to work and add =
some
>> testcases based on that. I do not see any automated alternative for do=
ing
>> this except writing NETCONF chat scripts (also module specific), or wr=
iting
>> not only YANG module specific but also API specific test cases as 3rd
>> option. 1) does not compromise this automated validation option since =
space
>> sequences can be collapsed to single space. If the alignment algorithm=
 was
>> creating a possibility for nontrivial output variation then I would ha=
ve
>> supported strongly 3) but this is not the current case.
>>
> If you want to make sure a YANG compiler is correct, simply write a
> backend that generates a serialized YANG module in canonical
> form. They YANG modules should be the same. Determining YANG compiler
> correctness by comparing tree diagrams does not seem to be a
> convincing approach since tree diagrams by design leave many details
> out.
The advantage I see is that 'uses' and 'augments' are resolved in the=20
tree output. For example one can not cach bug in the reolution of the=20
configure flag in a uses expanded under case with "configure false;" by=20
generating YANG with unresolved 'uses'.=C2=A0 Another example - one can n=
ot=20
represent the result of multiple modules augmenting e.g. /interfaces=20
with a YANG module. The only universal representation is the YANG tree.

Vladimir
> /js
>


From nobody Wed Jan 17 01:17: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 7A2E112FA8E for ; Wed, 17 Jan 2018 01:17:57 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 2xWOLvLOQ_3b for ; Wed, 17 Jan 2018 01:17:56 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5751912EA9F for ; Wed, 17 Jan 2018 01:17:56 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1F6A9EAF; Wed, 17 Jan 2018 10:17:55 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id A-EYQ8w0HBSI; Wed, 17 Jan 2018 10:17:54 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 10:17:55 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 051032013F; Wed, 17 Jan 2018 10:17:55 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g_thNEBzeHmv; Wed, 17 Jan 2018 10:17:54 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74F0B2013E; Wed, 17 Jan 2018 10:17:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EB555421313C; Wed, 17 Jan 2018 10:17:52 +0100 (CET)
Date: Wed, 17 Jan 2018 10:17:52 +0100
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Cc: joel jaeggli , Robert Wilton , Martin Bjorklund , netmod@ietf.org
Message-ID: <20180117091752.qfgzfl6f2oqvqvs7@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Vladimir Vassilev , joel jaeggli , Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>   <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com> <20180116200636.w437ttcwyqswnj2t@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 09:17:57 -0000

On Wed, Jan 17, 2018 at 10:08:02AM +0100, Vladimir Vassilev wrote:
> 
> The advantage I see is that 'uses' and 'augments' are resolved in the tree
> output. For example one can not cach bug in the reolution of the configure
> flag in a uses expanded under case with "configure false;" by generating
> YANG with unresolved 'uses'. Another example - one can not represent the
> result of multiple modules augmenting e.g. /interfaces with a YANG module.
> The only universal representation is the YANG tree.
>

But then the tree diagram leave out tons of other details. Anyway, if
you insist on using tree diagrams for testing, your test can simply
tolerate white space differences.

/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 Jan 17 02:11: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 2E29F126E64 for ; Wed, 17 Jan 2018 02:11:01 -0800 (PST)
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_RP_MATCHES_RCVD=-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 NwWJpP1fpyPN for ; Wed, 17 Jan 2018 02:10:59 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480961242F7 for ; Wed, 17 Jan 2018 02:10:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2707; q=dns/txt; s=iport; t=1516183859; x=1517393459; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mk02hXcxkC79g9wV8rGHQ4eUL1RGptN9mpobzDEkL0M=; b=dW83zEwzOeb0UvONNgr4t8jcOxl8udLSvWz19CNsf4lJYQYtzEOFu1Q1 dB+Wkog0Dh7A7Af9FSd4qaBjl0kVNdRWFKQdv8eq71v8gPVEvWghcJn14 raSg7FAQ7EvYgoYy6qjXEA+9aPjGFZRoWMsrCte95+MflvldpTWTbDpLE U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQCBIF9a/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj3CZRAoYC4RJTwKFIxQBAQEBAQEBAQFrKIUjAQE?= =?us-ascii?q?BBAEBIQ8BBTYLDAQLDgoCAiYCAicwBgEMBgIBAReKGBCmFoIniU8BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYEPhxmBaSmDBYMvAQEChQaCZQWjapVRjCWHbI8fiAq?= =?us-ascii?q?BPDYigVAyGggbFT2CKoRXQTeLawEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200";  d="scan'208";a="1444151"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 10:10:57 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0HAAvBY011958; Wed, 17 Jan 2018 10:10:57 GMT
To: Martin Bjorklund , alexander.clemm@huawei.com
Cc: vladimir@transpacket.com, netmod@ietf.org
References: <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <20180117.084318.1633996450082512639.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <52dd8202-605b-0dcb-2a2e-6f38a44ef72c@cisco.com>
Date: Wed, 17 Jan 2018 10:10:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180117.084318.1633996450082512639.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 10:11:17 -0000

On 17/01/2018 07:43, Martin Bjorklund wrote:
> Alexander Clemm  wrote:
>> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
>> here.  The purpose is to make this human-readable and provide readers
>> a good sense of the overall structure.  The authoritative
>> specification is still the .yang itself.  Providing some guidance for
>> how to represent the tree is good but let's not over-engineer this; I
>> believe retaining some flexibility is good.
> The last sentence summarizes my personal view.  I prefer (1), followed
> by (2).
OK, so the "Providing some guidance for how to represent the tree is 
good" is along the lines of what I was thinking for the "algorithm" 
would be for 2.

E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace separated 
fields (e.g.  and ).  Additional whitespace may be used to 
column align fields (e.g. within a list or container) to improve 
readability".

But just saying implementations can use arbitrary whitespace is also 
fine with me.  I certainly err on the side of not being overly 
prescriptive on this ..

I'm not really a fan of the comparing tree output as a method of 
verifying a YANG parser idea.

Thanks,
Rob


>
>
> /martin
>
>> --- Alex
>>
>>> -----Original Message-----
>> ...
>>>> Does anyone else have an opinion on this?  I can see three
>>>> alternatives:
>>>>
>>>>     1) allow any number of addtional spaces
>>>>     2) allow any number of addtional spaces + define a suggested
>>>>        alignment algorithm
>>>>     3) mandate the alignment algorithm
>>> Definition of symbols should be precise/consistent, so that readers
>>> can
>>> consistently interpret tree diagrams.
>>>
>>> I think that flexibility in layout should be OK, but the draft should
>>> provide
>>> guideline to ensure the output is readable, and likely to be broadly
>>> consistent
>>> (since consistency aids readability).
>>>
>>> If the IETF data modeling group is trying to specify text output
>>> precisely
>>> enough that it can be screen scraped then we may want to consider
>>> whether
>>> we are focusing on the right solution ;-)
>>>
>>> In summary, (2) is my preference, followed by (1), followed by (3).
>>>
>>> Thanks,
>>> Rob
>>>
>>>>
>>>> /martin
>>>>
>>>> _______________________________________________
>>>> 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 Wed Jan 17 02:23:16 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 39C8912FB1E for ; Wed, 17 Jan 2018 02:23:15 -0800 (PST)
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 (1024-bit key) header.d=btconnect.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 1zqxWTT1wp2x for ; Wed, 17 Jan 2018 02:23:13 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0091.outbound.protection.outlook.com [104.47.0.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A1D12FAF8 for ; Wed, 17 Jan 2018 02:23:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6RYf+ewSNCNSU+7a0f7eQ2ZIbtS8enkB+LEEBXfMd8w=; b=K4rp/SmAprtC51XQBdfV9QTz0yWlcccpdStsHx1OG2NQSOAuSYINI1MN03IRVoEAUrcpDbm5lZS/DJqSOlQGyLMaggLqEvKoh6KTOY2jwfc7FH/m/b2WNc1Xx54RwUo2Jg1LyQSe5Z4Wf49zEP32ehsburU8EZvXCOzM6tmDXco=
Received: from pc6 (86.169.153.236) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 10:23:06 +0000
Message-ID: <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Alexander Clemm" , "Robert Wilton" , "Martin Bjorklund" 
Cc: 
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com>
Date: Wed, 17 Jan 2018 09:52:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB3PR0102CA0003.eurprd01.prod.exchangelabs.com (2603:10a6:8::16) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e431f923-6a3e-4d09-b016-08d55d944d04
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:+Sjz1/v/xVEyvukv/LkkEj0T11AxEFg6kLM3IQEcEyy469DeIZgRMTT8qDgMHN/eNF+UCKFlfUq7KEigrYyBqUXWsXcwdViddwoce5A/ZuR8h+URZ9W9VVU8cVcQoy89wrzNFHvTK7dyGb22EQAdO5+VleIFmGBWWsDMEm3U+vmJcq+IlqR/VK4uzMUxMwKOOBZVvHUhZTEYr0NRhOkVwu5Tx7sEvwmfWzvztr0EwtAswNTKwr3zcy8c0n+c4Csm; 25:uWFsXtt1f7MRChxB2174B3WfSm6gBq+hU1Eg4LMhrdKJkNT+88RwDA3y4TyMh/RR6TcF4/j5vlxulRPpLfz3Ncb5dYhTbz//pDAcDSFu4MrYPHmSDuzpmYuoiWBzD2ac8CvSFc/FoF2a6PUnY429ejX4u+mAQrAoOiW4uYZ9bpqzutGHvo+xLNrdC7xy47j5QXv8FY8wA5jlSYfgV48rJAi4+LRy2AQ8F89TyCvpzO2z9THAdO5n55aXpFrZg9pmhoYi7N/n2KRzlbiRMwQD24el+RHg5MBrsX5cc7Q4gKU4ffwu55uZfBSib+20JA2pzC9P7khcf/Y/MQlut1K7/g==; 31:ehpfaLG/yPjY7AzBbJiQbzpC5KvbQWtpptJg2/kQSnGiDR93jkjgbMER58j4tVNpdNWtTJb0LKKt5hkfhMeExbYlsT1EZf7LDufXlqipITeKUCE2wzrVow2dMgZcoEK2mgsu9R6APag0nOUuA3QGXo/zSLEMiehIhrL/eVsjNO5oc4X8Oq5E8EXCycfyurAMgSnF8dQCD56s6wvi6nLgY/aVEoZOTRsTVIWP33y1gQk=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(50582790962513);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231042)(2400043)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041268)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:5ocCfaAIrqqBTlgJQJGK7zgohqR70/2X0xE0CUQBsa6OJGrA38cLsvY0eqrT9GDdg62/OLGdX4ZSGEWutS5GpgKE0DZApI60rEtQQvYkBZCLnJRu64KxzxWalFOniy4y5pYGRSbzeV4Ti7UeRh7VVymp8ztfB3pZc4DTCfBmmcrqVEoUUGUaFrjX//Uk2stIaGOqD0eP1A9oKpE17Brf+2ZqKEJgqalmfdh46aRvvmYhfW1wI/ZLGzKyD5GR9D/BpO6tjt+G2xPKwpYcAruUfK2lhgWNQdvc/v1/dt6UVFrU0As1AeUvGeJW07ZYndLS
X-Forefront-PRVS: 0555EC8317
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(39380400002)(396003)(13464003)(189003)(199004)(51444003)(14496001)(50466002)(478600001)(6496006)(5660300001)(1456003)(68736007)(23756003)(106356001)(105586002)(76176011)(81816011)(1556002)(33896004)(386003)(6116002)(26005)(84392002)(16526018)(3846002)(2906002)(86362001)(97736004)(52116002)(81686011)(62236002)(44716002)(93886005)(66066001)(316002)(47776003)(230700001)(4326008)(6246003)(110136005)(6666003)(61296003)(4720700003)(25786009)(229853002)(53936002)(9686003)(230783001)(8676002)(7736002)(50226002)(8936002)(305945005)(44736005)(6486002)(81156014)(81166006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:lm1+bTUc5ltI4aRId1AT4hqCkhOX2mopLQ25K?= =?iso-8859-1?Q?NvVdAuiyaXE3hiK34Gd4yJ23DQZz/pvzVeRRsJrd5s1NCftciEbolopcnt?= =?iso-8859-1?Q?MdcexsmGpFxT6YddVoTKLUnHigenNt1pTsjra5rtqI1CRqtnYGb7JdKAk3?= =?iso-8859-1?Q?ftYHI4gX9kV7sIY+qVcoNXj+2kGxbIBKU6piD02OIBrmFKWFA05yNBLkbq?= =?iso-8859-1?Q?RKmC3NQrFA+6gzOuKwFMq7IZp6isrgVjgq3vVBEKggUPcVFYKl4LdOmCcu?= =?iso-8859-1?Q?H2pnsr0XlPpgZNFWbO6jO0JTAzBi2PeC0BAs8CV40FGLHGn7PGZhI8b1fY?= =?iso-8859-1?Q?EgS40VgMALkdPYEwAZQz/ufUnhVVhWcw3Osiq4VW/8fGzVlJu2stLmdt97?= =?iso-8859-1?Q?7k+/5Ro6MmniplOKnYdeOZ7O1DLz1TuArPbQ+87RfnXR9L4Tbko+0ff89Z?= =?iso-8859-1?Q?x+C8kKyXE71n+b9kqQoEciKseQ4vLQjCI+sdDmr/NdjgloJyNliwkUD+vj?= =?iso-8859-1?Q?VXCOfCuf2NC+ptYIqHCTKjIYJWyYdEkYeG9TEhgxREX+3J8f8ppZnQLhq8?= =?iso-8859-1?Q?gad7AyshevN093UMea/rZE4lWPc1jg2aErRCzGyoa3KSRaCXW8quSiayrt?= =?iso-8859-1?Q?NQuLK+7jbTKWI8tEQ6Ngm2hfoj1wRQWgvxRfQPTA4Ys7N2F5yt6HvZEq5s?= =?iso-8859-1?Q?ydXlM7ED9dI/A6Oa4a5hiTfIMPhhogAuWYuoiKzZWxP25o9qRWEZHUTwOD?= =?iso-8859-1?Q?d5GYbSYdlz2RAiit1gyK7yTj5ies2KTeMU2YXfcJNyHUjH2bwi9jBEOByf?= =?iso-8859-1?Q?8k2CMc2lKaLAuIujMrFQ1nf1ogbf3KDg26TBnVg1F95ftBd+OotZlj8w+a?= =?iso-8859-1?Q?DSylTEkkvP2QGWzbu9NOdv7Z2i3nRIvh8XRqCfZnqV3n96qRbVAaaFm8Tf?= =?iso-8859-1?Q?rI4lzb7H9CxPU5NDqNWHiqU5Oc0NYpIvJmLFD4M+rzOFVuISsTHJnQc9WQ?= =?iso-8859-1?Q?Lv5XNpStP4RE0TJC/4ss5+AJu21OB3jKysQFrE8nwgGSRR74AFHlO/wU00?= =?iso-8859-1?Q?Yc656N85RAIHcdmRK0Cb09Rz6er0exueefP7EWk2R+MLcMUrs8uelHarj9?= =?iso-8859-1?Q?fuG8hHHSO7xf2PC+1RGP3JGvYUwOhi3limhVS6PbIORieZlxcH2S3XTn7s?= =?iso-8859-1?Q?AYO23OTI8DILWO55BwN32sUP9YYxovYyI8uQ5Bg8m3DVpDdYuWZgeE01um?= =?iso-8859-1?Q?Qx4bGcIPFWR64L6le8rD9jakm3eJFblnm+j2iqBcMX47kY1J5hAqi/+69B?= =?iso-8859-1?Q?ZvFOVfOlFWC0HlwlIKHP/9LtfayE4ckWXIcX78K78h/QmrgaOvqRcXbJ6E?= =?iso-8859-1?Q?y1GlbscdrPd2XS/8gcfr5g9vm3wwUkCQE4nsIIAliBc7XgWza/rdJF//O2?= =?iso-8859-1?Q?Gulw3Yf6g9YWbdRsIuLS5UJogRGnYDfNfd9QeELCPS/ye1v+ETdWMoVn3Q?= =?iso-8859-1?Q?SNzeiRM3CbjlEh9ZG43PtU=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:cCxPPGuMgP7LnFQR8Ikho7/hyO9F6T9ZgtlLaVAhSAADjh5pvJ+2rFDUPFropEyhWOPeexdq37tmZ0yyOrkg8cG278Ky6nxXS5k4dZ0Q2WgfXBZTarF4S2FUgoDisAuUdZ6KzNel+lEO81RiMKdl26uUNbLRLbjbc0LbwkndBfKke/NePJ+vlR4hjDxeo5FcfA0GQH3WLUplbQliHzJK1hRLecRhKcNzCva8ituIwesGKHKNpQa8fT6xzD8Nz2KrQ4Smk8L04Au/gJsb/JdxvOpWNz7MhMOjnUPBHPsfYkObJnetUgRdzS/wHvJuwV18EC2EtcWmDUfm72xxA9hkNSfH3WYf1a2ObJ7kcNn+zgY=; 5:vN3RhuDoY3xT0ukof4MGgLh6xqYVa2Nr8rF+YdhMai746ajGac2Tix5RCZy9w1R2pL6iNVws4uHAlwLQ9vqF6RBpDMVkvr0eqdw6wZGuYETbdnRS1VST5XOJ1NQ1+xAHD5F2fFWemHSX1/FVIaFI+VAx1hdgBC0gMoXplZZTGxM=; 24:jsz1GJprXq4hqOb8/MKTHLrVCat2+L49sGhG2KkYllhoKI+5i696LYeAqyk4345uSC5vo1WO7wz4ujdAjeqmo8xlEhtY4egj4UQKflAt99Q=; 7:rAkJ5DPYTh04k93je834H76x19sRrBLkqWsPhiQVpFT2WSuoA3pxiUlEZ7k+YFihC6Qmqh0WRa9a7H0MsqGMbjAFoeZQB1U1ERmY0xObFHt5Y18l+b8Adw11i+ZDV9Qma40zn+SyMbvvXRdhmwazaK/nBnMPrhB54Z3d64FvFjsV7tUyNLiYJx5XeBduZExNuQygJqlOSQfGQWteKEajUXvzRKjtoXDkvEtSf1UqRA1Qgc4b7NRzyv8Th6GreEzK
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2018 10:23:06.5239 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e431f923-6a3e-4d09-b016-08d55d944d04
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 10:23:15 -0000

----- Original Message -----
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM

> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'

i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


   The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.
>
> --- Alex
>
> > -----Original Message-----
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >    1) allow any number of addtional spaces
> > >    2) allow any number of addtional spaces + define a suggested
> > >       alignment algorithm
> > >    3) mandate the alignment algorithm
> >
> > Definition of symbols should be precise/consistent, so that readers
can
> > consistently interpret tree diagrams.
> >
> > I think that flexibility in layout should be OK, but the draft
should provide
> > guideline to ensure the output is readable, and likely to be broadly
consistent
> > (since consistency aids readability).
> >
> > If the IETF data modeling group is trying to specify text output
precisely
> > enough that it can be screen scraped then we may want to consider
whether
> > we are focusing on the right solution ;-)
> >
> > In summary, (2) is my preference, followed by (1), followed by (3).
> >
> > Thanks,
> > Rob
> >
> > >
> > >
> > > /martin


From nobody Wed Jan 17 02:25: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 9A7AE126DD9 for ; Wed, 17 Jan 2018 02:25:00 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 EFI9nyxzvP1b for ; Wed, 17 Jan 2018 02:24:59 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F24B4126DFF for ; Wed, 17 Jan 2018 02:24:58 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F67B1AE0385; Wed, 17 Jan 2018 11:24:57 +0100 (CET)
Date: Wed, 17 Jan 2018 11:24:57 +0100 (CET)
Message-Id: <20180117.112457.2094197769485990789.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: alexander.clemm@huawei.com, vladimir@transpacket.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <52dd8202-605b-0dcb-2a2e-6f38a44ef72c@cisco.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <20180117.084318.1633996450082512639.mbj@tail-f.com> <52dd8202-605b-0dcb-2a2e-6f38a44ef72c@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 10:25:00 -0000

Hi,

Robert Wilton  wrote:
> On 17/01/2018 07:43, Martin Bjorklund wrote:
> > Alexander Clemm  wrote:
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is ne=
eded
> >> here.  The purpose is to make this human-readable and provide read=
ers
> >> a good sense of the overall structure.  The authoritative
> >> specification is still the .yang itself.  Providing some guidance =
for
> >> how to represent the tree is good but let's not over-engineer this=
; I
> >> believe retaining some flexibility is good.
> > The last sentence summarizes my personal view.  I prefer (1), follo=
wed
> > by (2).
> OK, so the "Providing some guidance for how to represent the tree is
> good" is along the lines of what I was thinking for the "algorithm"
> would be for 2.
> =

> E.g. something along the lines of:
> "Arbitrary whitespace is allowed between any of the whitespace
> separated fields (e.g.  and ).=A0 Additional whitespace m=
ay
> be used to column align fields (e.g. within a list or container) to
> improve readability".

This is fine with me.  It is something in between (1) and (2) which
people preferred.  I will add this text.

> But just saying implementations can use arbitrary whitespace is also
> fine with me.=A0 I certainly err on the side of not being overly
> prescriptive on this ..
> =

> I'm not really a fan of the comparing tree output as a method of
> verifying a YANG parser idea.

This is getting off-topic, but if an implementor wants to do this in
order to verify his implementation, go for it!  It doesn't have to be
discussed on this ML.  Speaking from own experience of two different
implementations, I can tell you that it is a useful test to do ;-)


/martin


From nobody Wed Jan 17 02:44: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 BE66812D94F for ; Wed, 17 Jan 2018 02:44:22 -0800 (PST)
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_RP_MATCHES_RCVD=-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 9DSW3Bup3SKU for ; Wed, 17 Jan 2018 02:44:20 -0800 (PST)
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 5CC4C12D880 for ; Wed, 17 Jan 2018 02:44:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2926; q=dns/txt; s=iport; t=1516185860; x=1517395460; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7nOPipfAGYFphzTkyvt2Mny9ZM9fsNgTzY+2yr8oL4E=; b=GYjGvE56yfG1h1D3JFnjhqPzjJcbIV/8zcArKuS7LOwPpowanJzSZ0OX IQDfWuJpo/RdSN1d+EAHNL/bJ68DX1hJV4bmmBhYNSeXLCuVTVeyhrJuN HKfViyLdH2vQyGrw0zw6d58mZ2EYi3CVwSA75qHu14whwkr56yCC9OTRC I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQC4J19a/xbLJq1BGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJ3QnhBOLGI9wmUQKI4UYAoUkFAEBAQEBAQEBAWsohSMBAQE?= =?us-ascii?q?DASMPAQVBDAQLFQECAgImAgJXBgEMBgIBAReKEAgQNKVMgieJTwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQ+HGYFpKYMFgy8EGYRtgmUFjQaWZJVRjCWHbI8fiAq?= =?us-ascii?q?BPDYiEYE/MhoIGxWCZ4JUHIFnQTcBi2oBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200";  d="scan'208";a="1450536"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 10:44:18 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0HAiIuE009212; Wed, 17 Jan 2018 10:44:18 GMT
To: "t.petch" , Alexander Clemm , Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: <40145d13-a6aa-feb5-bfb2-b87b236e7700@cisco.com>
Date: Wed, 17 Jan 2018 10:44:18 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 10:44:23 -0000

Hi Tom,


On 17/01/2018 09:52, t.petch wrote:
> ----- Original Message -----
> From: "Alexander Clemm" 
> Sent: Wednesday, January 17, 2018 2:20 AM
>
>> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> here.  The purpose is to make this human-readable and provide readers a
> good sense of the overall structure.
>
> 
>
> That's what I thought until Benoit said, and Robert agreed, that
>
> 'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.

By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long term 
way of interacting with and browsing YANG modules.  For example, the 
link below for the RIP module.

https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. This 
will become even more powerful when all of the standard YANG modules are 
available together in a single browsable tree.

Hopefully, that clarifies my previous comment.

Thanks,
Rob

>
> i.e. the tree view should be machine readable after which something is
> produced for human consumption; not a view I share.
>
> Tom Petch
>
>
>     The authoritative specification is still the .yang itself.  Providing
> some guidance for how to represent the tree is good but let's not
> over-engineer this; I believe retaining some flexibility is good.
>> --- Alex
>>
>>> -----Original Message-----
>> ...
>>>> Does anyone else have an opinion on this?  I can see three
>>>> alternatives:
>>>>
>>>>     1) allow any number of addtional spaces
>>>>     2) allow any number of addtional spaces + define a suggested
>>>>        alignment algorithm
>>>>     3) mandate the alignment algorithm
>>> Definition of symbols should be precise/consistent, so that readers
> can
>>> consistently interpret tree diagrams.
>>>
>>> I think that flexibility in layout should be OK, but the draft
> should provide
>>> guideline to ensure the output is readable, and likely to be broadly
> consistent
>>> (since consistency aids readability).
>>>
>>> If the IETF data modeling group is trying to specify text output
> precisely
>>> enough that it can be screen scraped then we may want to consider
> whether
>>> we are focusing on the right solution ;-)
>>>
>>> In summary, (2) is my preference, followed by (1), followed by (3).
>>>
>>> Thanks,
>>> Rob
>>>
>>>>
>>>> /martin
> .
>


From nobody Wed Jan 17 02:46: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 6CCE912D880 for ; Wed, 17 Jan 2018 02:46:32 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 GSIIkFnZ7cv9 for ; Wed, 17 Jan 2018 02:46:31 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BCF12D80F for ; Wed, 17 Jan 2018 02:46:30 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7D4ABF79; Wed, 17 Jan 2018 11:46:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id KbfMlgQqtfyj; Wed, 17 Jan 2018 11:46:28 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 11:46:29 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65C2E2013E; Wed, 17 Jan 2018 11:46:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UuRxqaqVIJL8; Wed, 17 Jan 2018 11:46:29 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FD4A2013F; Wed, 17 Jan 2018 11:46:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 684FB4213336; Wed, 17 Jan 2018 11:46:27 +0100 (CET)
Date: Wed, 17 Jan 2018 11:46:26 +0100
From: Juergen Schoenwaelder 
To: "t.petch" 
Cc: Alexander Clemm , Robert Wilton , Martin Bjorklund , netmod@ietf.org
Message-ID: <20180117104626.tuyedcv6kwq4wibf@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "t.petch" , Alexander Clemm , Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 10:46:32 -0000

On Wed, Jan 17, 2018 at 09:52:27AM -0000, t.petch wrote:
> 
> That's what I thought until Benoit said, and Robert agreed, that
> 
> 'In the end, the tree view should be browsed with tooling.'
> 
> i.e. the tree view should be machine readable after which something is
> produced for human consumption; not a view I share.
>

I think they did not say that the tooling should rely on tree views
published in RFCs as input. We should discourage tools to read tree
rendings as input; tools should read YANG modules as input. I doubt
Benoit's tools read tree views as input.

/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 Jan 17 05:22:00 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 21C021270B4 for ; Wed, 17 Jan 2018 05:21:58 -0800 (PST)
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_RP_MATCHES_RCVD=-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 1hrk_WKgg7qT for ; Wed, 17 Jan 2018 05:21:56 -0800 (PST)
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 0A3DB12702E for ; Wed, 17 Jan 2018 05:21:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5171; q=dns/txt; s=iport; t=1516195316; x=1517404916; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mHlGYwrhatjxFl8QbAaGgmqQJgqteqvk5iu2aymTTz4=; b=Wzv8Kt36WRwsJI5neD3KZ/sIeqI/SPOoFPva6M9fp23mFo8eQYj0PMLQ 0/29eE6hRQ7oB6/uOoDzWkLCzdnC+/1wcqD++qgMr1gck0R6U/l8vvbxD F94uYlf0ByIgSioa6MF5u9w/l2FmT939FUujuoI3Hyue3Ye5nT1MxZyjg Y=;
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200"; d="scan'208,217";a="1499201"
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; 17 Jan 2018 13:21:54 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0HDLrpY019282; Wed, 17 Jan 2018 13:21:54 GMT
To: Robert Wilton , "t.petch" , Alexander Clemm , Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net> <40145d13-a6aa-feb5-bfb2-b87b236e7700@cisco.com>
From: Benoit Claise 
Message-ID: <20881920-6db6-e4f3-2587-b288ca55bcbd@cisco.com>
Date: Wed, 17 Jan 2018 14:21:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <40145d13-a6aa-feb5-bfb2-b87b236e7700@cisco.com>
Content-Type: multipart/alternative; boundary="------------626CBE2AA81DA61CAFA005F7"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 13:21:58 -0000

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

Hi Tom,
> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
>> ----- Original Message -----
>> From: "Alexander Clemm" 
>> Sent: Wednesday, January 17, 2018 2:20 AM
>>
>>> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
>> here.  The purpose is to make this human-readable and provide readers a
>> good sense of the overall structure.
>>
>> 
>>
>> That's what I thought until Benoit said, and Robert agreed, that
>>
>> 'In the end, the tree view should be browsed with tooling.'
> The text based YANG tree diagram (i.e. covered by this draft) doesn't 
> need to be browsable by tooling.  The purpose of these diagrams should 
> be to go in text documents to help explain and illustrate (to human 
> readers) the structure of a YANG model.
>
> By "In the end, the tree view should be browsed with tooling.", what I 
> mean is that I think that tools like YANG catalog will be the long 
> term way of interacting with and browsing YANG modules. For example, 
> the link below for the RIP module.
>
> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
>
> This provides an interactive GUI "tree view" of a YANG model, which 
> should be structurally equivalent as the text tree diagram, but 
> otherwise the information may be represented in a more visual way. 
> This will become even more powerful when all of the standard YANG 
> modules are available together in a single browsable tree.
>
Exactly what I meant.
'In the end, the tree view should be browsed with tooling.' doesn't mean 
that the tree diagram, to be inserted in the RFC text,(according to 
draft-ietf-netmod-yang-tree-diagrams-04 
should 
be browsed with tooling.

Sorry if it was not clear.

Regards, Benoit

--------------626CBE2AA81DA61CAFA005F7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Tom, 

    

    
Hi Tom,
      

      

      

      On 17/01/2018 09:52, t.petch wrote:
      

      
----- Original Message -----
        

        From: "Alexander Clemm" <alexander.clemm@huawei.com>
        

        Sent: Wednesday, January 17, 2018 2:20 AM
        

        

        
+1 to (2) as preference, followed by
          (1).  I don't think (3) is needed
          

        

        here.  The purpose is to make this human-readable and provide
        readers a
        

        good sense of the overall structure.
        

        

        <tp>
        

        

        That's what I thought until Benoit said, and Robert agreed, that
        

        

        'In the end, the tree view should be browsed with tooling.'
        

      

      The text based YANG tree diagram (i.e. covered by this draft)
      doesn't need to be browsable by tooling.  The purpose of these
      diagrams should be to go in text documents to help explain and
      illustrate (to human readers) the structure of a YANG model.
      

      

      By "In the end, the tree view should be browsed with tooling.",
      what I mean is that I think that tools like YANG catalog will be
      the long term way of interacting with and browsing YANG modules. 
      For example, the link below for the RIP module.
      

      

https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
      

      

      This provides an interactive GUI "tree view" of a YANG model,
      which should be structurally equivalent as the text tree diagram,
      but otherwise the information may be represented in a more visual
      way. This will become even more powerful when all of the standard
      YANG modules are available together in a single browsable tree.
      

      

    

    Exactly what I meant. 

    'In the end, the tree view should be browsed with tooling.' doesn't
    mean that the tree diagram, to be inserted in the RFC
    text,(according to draft-ietf-netmod-yang-tree-diagrams-04
    should be browsed with tooling.

    

    Sorry if it was not clear.

    

    Regards, Benoit

  


--------------626CBE2AA81DA61CAFA005F7--


From nobody Wed Jan 17 05:27: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 326F112706D for ; Wed, 17 Jan 2018 05:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level: 
X-Spam-Status: No, score=-14.529 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 E7mObpI3yPUs for ; Wed, 17 Jan 2018 05:26:58 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803DC120727 for ; Wed, 17 Jan 2018 05:26:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7916; q=dns/txt; s=iport; t=1516195618; x=1517405218; h=from:to:subject:date:message-id:mime-version; bh=EEWmHsx1ZsoK0tOKC2oXQPXwQKxIZeozXlQFoOf7Flw=; b=d5OdHHiVEOi78P2zYN2hHNKK3/u14OZXXHIx/6dR+BtjX0GrnZftJfqe cdoSMY7nIBn8OP1V2yKMYykHQ4Gkzny00DRLyxSzEuRYJjHqFUticOmpc J3NBAFeez8TaIMI2Zr274r2kxbE6zwH2238uwsnBWC8z1YsW6rZG63Rmu 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxBwDNTV9a/4QNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNBZnQoBoQMmQaBW5IEh2cKI4UYHIRHQhUBAQEBAQEBAQFrHQu?= =?us-ascii?q?FTWgBLR0CBDAnBIliZBClRoIniUwBAQEBAQEBAwEBAQEBAQEBAR+EPIIVg2kMh?= =?us-ascii?q?EKBWwsBAQIBgW2CWz0xgjQFo2oCiAuNRIIZZ5ERimmCWIYhgxoCERkBgTsBNSO?= =?us-ascii?q?BUG8VZwGCAAg2giEpgU6LTIEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200";  d="scan'208,217";a="333930620"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 13:26:57 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0HDQvuv023206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jan 2018 13:26:57 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Jan 2018 08:26:56 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 17 Jan 2018 08:26:56 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "netmod@ietf.org" 
Thread-Topic: yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bYiGDflCZ3h0a24DFWm/LfUw==
Date: Wed, 17 Jan 2018 13:26:56 +0000
Message-ID: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.5.20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.99.225]
Content-Type: multipart/alternative; boundary="_000_616655B024944E63906C290E4AA6C1DEciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 13:27:00 -0000

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

QWxsLA0KDQpJbiBkaXNjdXNzaW9ucyB3aXRoIHNvbWUgY3VzdG9tZXJzIGFuZCBvbiBpbXBsZW1l
bnRhdGlvbiwgdGhlIGlzc3VlIG9mIGRlZmF1bHRzIGhhcyBjb21lIHVwLiBGb3IgZ2V0L2dldC1j
b25maWcgd2UgaGF2ZSB0aGUg4oCcd2l0aCBkZWZhdWx0cyBjYXBhYmlsaXR54oCdIGRlZmluZWQg
aW4gUkZDIDYyNDMgdGhhdCBhbGxvd3MgdXMgdG8gY29udHJvbCB0aGUgYmVoYXZpb3VyIHdpdGgg
cmVzcGVjdCB0byBkZWZhdWx0cy4gVG8gcmVtaW5kIGZvbGsgd2l0aCBhbiBleGFtcGxlLCB3ZSBj
b3VsZCBoYXZlOg0KDQogICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICB4bWxucz0i
dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgICAgIDxnZXQ+DQog
ICAgICAgIDxmaWx0ZXIgdHlwZT0ic3VidHJlZSI+DQogICAgICAgICAgPGludGVyZmFjZXMgeG1s
bnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pbnRlcmZhY2VzIi8+DQogICAgICAgIDwvZmlsdGVy
Pg0KICAgICAgICA8d2l0aC1kZWZhdWx0cw0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFt
czp4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cyI+DQogICAgICAgICAgcmVw
b3J0LWFsbA0KICAgICAgICA8L3dpdGgtZGVmYXVsdHM+DQogICAgICA8L2dldD4NCiAgICA8L3Jw
Yz4NCg0KVGhlIGFkZGl0aW9uIG9mIHRoZSDigJx3aXRoLWRlZmF1bHRz4oCdIHRhZyBhbmQgdmFs
dWUgZGV0ZXJtaW5lcyB0aGUgYmVoYXZpb3Igb2YgdGhlIGdldCBpbiB0aGlzIGV4YW1wbGUgKHRh
a2VuIGZyb20gQS4zLjEgaW4gUkZDIDYyNDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzYyNDMjcGFnZS0yMj4pLg0KDQpJdCBzdHJpa2VzIG1lIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEg
c2ltaWxhciBtZWNoYW5pc20gZm9yIHRlbGVtZXRyeSwgYWxsb3dpbmcgYSB1c2VyIHRvIHNwZWNp
ZnksIGZvciBleGFtcGxlLCB0aGF0IGZvciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiBvbiBhIHN1
YnRyZWUsIHRoZXkgYWxzbyB3aXNoIGRlZmF1bHQgdmFsdWVzIHRvIGJlIHJlcG9ydGVkLiBJIHRo
aW5rIGF0IG1pbmltdW0gd2UgbmVlZCBjbGFyaWZpY2F0aW9uIG9uIHRoaXMsIGFzIHNlY3Rpb24g
My43IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgY3VycmVudGx5IHNheXM6DQoN
ClRoZSBjb250ZW50IG9mIHRoZSB1cGRhdGUgcmVjb3JkIGlzIGVxdWl2YWxlbnQgdG8gdGhlIGNv
bnRlbnRzIHRoYXQgd291bGQgYmUgb2J0YWluZWQgaGFkIHRoZSBzYW1lIGRhdGEgYmVlbiBleHBs
aWNpdGx5IHJldHJpZXZlZCB1c2luZyBlLmcuLCBhIE5FVENPTkYgImdldCIgb3BlcmF0aW9uLCB3
aXRoIHRoZSBzYW1lIGZpbHRlcnMgYXBwbGllZC4NCg0KVGhpcyB0ZXh0IGNhbiBjdXJyZW50bHkg
b25seSByZWZlciB0byBhIOKAnGdldOKAnSBhcyBkZWZpbmVkIGluIFJGQyA2MjQxIGFzIHRoZXJl
IGlzIG5vIHJlZmVyZW5jZSB0byBSRkMgNjI0MyBhcyB5ZXQuIEkgdGhpbmsgd2UgbmVlZCB0byBh
ZGRyZXNzIHRoaXMgaXNzdWUgbm93IHRvIGRlZmluZSBleHBlY3RhdGlvbnMsIGV2ZW4gaWYgaXQg
aXMgdG8gZXhwbGljaXRseSBub3QgY29uc2lkZXIgYW4gUkZDIDYyNDMtbGlrZSBtZWNoYW5pc20g
b3IgdG8gc2F5IHRoYXQgd2Ugb25seSBjb25zaWRlciBleHBsaWNpdGx5IHNldCB2YWx1ZXMgaW4g
dGVsZW1ldHJ5LCBvcuKApg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg==

--_000_616655B024944E63906C290E4AA6C1DEciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIGRpc2N1c3Npb25zIHdpdGggc29tZSBjdXN0
b21lcnMgYW5kIG9uIGltcGxlbWVudGF0aW9uLCB0aGUgaXNzdWUgb2YgZGVmYXVsdHMgaGFzIGNv
bWUgdXAuIEZvciBnZXQvZ2V0LWNvbmZpZyB3ZSBoYXZlIHRoZSDigJx3aXRoIGRlZmF1bHRzIGNh
cGFiaWxpdHnigJ0gZGVmaW5lZCBpbiBSRkMgNjI0MyB0aGF0IGFsbG93cyB1cyB0byBjb250cm9s
IHRoZSBiZWhhdmlvdXIgd2l0aCByZXNwZWN0IHRvIGRlZmF1bHRzLiBUbyByZW1pbmQNCiBmb2xr
IHdpdGggYW4gZXhhbXBsZSwgd2UgY291bGQgaGF2ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm
YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZsdDtycGMgbWVzc2FnZS1pZD0m
cXVvdDsxMDEmcXVvdDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv
dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxucz0m
cXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PC9m
b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7Z2V0Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZsdDtmaWx0ZXIgdHlwZT0mcXVvdDtzdWJ0cmVlJnF1b3Q7Jmd0OzwvZm9udD48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aW50ZXJmYWNlcyB4bWxucz0mcXVvdDs8YSBocmVm
PSJodHRwOi8vZXhhbXBsZS5jb20vbnMvaW50ZXJmYWNlcyIgY2xhc3M9IiI+aHR0cDovL2V4YW1w
bGUuY29tL25zL2ludGVyZmFjZXM8L2E+JnF1b3Q7LyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbHQ7L2ZpbHRlciZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250
IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7
d2l0aC1kZWZhdWx0czwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291
cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zPSZx
dW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0
cyZxdW90OyZndDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp
ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVwb3J0LWFs
bDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9
IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvd2l0aC1kZWZhdWx0cyZndDs8L2Zv
bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvZ2V0Jmd0OzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbHQ7L3JwYyZn
dDs8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBhZGRpdGlvbiBvZiB0aGUg4oCcPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+d2l0aC1kZWZhdWx0czwvc3Bhbj7igJ0gdGFn
IGFuZCB2YWx1ZSBkZXRlcm1pbmVzIHRoZSBiZWhhdmlvciBvZiB0aGUgZ2V0IGluIHRoaXMgZXhh
bXBsZSAodGFrZW4gZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM2MjQzI3BhZ2UtMjIiIGNsYXNzPSIiPkEuMy4xIGluIFJGQyA2MjQzPC9hPikuPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBz
dHJpa2VzIG1lIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgc2ltaWxhciBtZWNoYW5pc20gZm9yIHRl
bGVtZXRyeSwgYWxsb3dpbmcgYSB1c2VyIHRvIHNwZWNpZnksIGZvciBleGFtcGxlLCB0aGF0IGZv
ciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiBvbiBhIHN1YnRyZWUsIHRoZXkgYWxzbyB3aXNoIGRl
ZmF1bHQgdmFsdWVzIHRvIGJlIHJlcG9ydGVkLiBJIHRoaW5rIGF0IG1pbmltdW0gd2UgbmVlZCBj
bGFyaWZpY2F0aW9uDQogb24gdGhpcywgYXMgc2VjdGlvbiAzLjcgb2YmbmJzcDtkcmFmdC1pZXRm
LW5ldGNvbmYteWFuZy1wdXNoLTEyIGN1cnJlbnRseSBzYXlzOjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAw
IDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0iIj5UaGUgY29udGVudCBvZiB0aGUgdXBkYXRl
IHJlY29yZCBpcyBlcXVpdmFsZW50IHRvIHRoZSBjb250ZW50cyB0aGF0IHdvdWxkIGJlIG9idGFp
bmVkIGhhZCB0aGUgc2FtZSBkYXRhIGJlZW4gZXhwbGljaXRseSByZXRyaWV2ZWQgdXNpbmcgZS5n
LiwgYSBORVRDT05GICZxdW90O2dldCZxdW90OyBvcGVyYXRpb24sIHdpdGggdGhlIHNhbWUgZmls
dGVycyBhcHBsaWVkLjwvaT48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj5UaGlzIHRleHQgY2FuIGN1cnJlbnRseSBvbmx5IHJlZmVyIHRv
IGEg4oCcZ2V04oCdIGFzIGRlZmluZWQgaW4gUkZDIDYyNDEgYXMgdGhlcmUgaXMgbm8gcmVmZXJl
bmNlIHRvIFJGQyA2MjQzIGFzIHlldC4gSSB0aGluayB3ZSBuZWVkIHRvIGFkZHJlc3MgdGhpcyBp
c3N1ZSBub3cgdG8gZGVmaW5lIGV4cGVjdGF0aW9ucywgZXZlbiBpZiBpdCBpcyB0byBleHBsaWNp
dGx5IG5vdCBjb25zaWRlciBhbiBSRkMgNjI0My1saWtlIG1lY2hhbmlzbQ0KIG9yIHRvIHNheSB0
aGF0IHdlIG9ubHkgY29uc2lkZXIgZXhwbGljaXRseSBzZXQgdmFsdWVzIGluIHRlbGVtZXRyeSwg
b3LigKY8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_616655B024944E63906C290E4AA6C1DEciscocom_--


From nobody Wed Jan 17 06:09: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 C1D09127599 for ; Wed, 17 Jan 2018 06:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 emLj8uBudYiV for ; Wed, 17 Jan 2018 06:09:18 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 E2BAB127444 for ; Wed, 17 Jan 2018 06:09:17 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 6845E1E0848 for ; Wed, 17 Jan 2018 07:09:16 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id zS9C1w00l2SSUrH01S9F42; Wed, 17 Jan 2018 07:09:16 -0700
X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=Chlqg--EEEERaDeMNk4A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+QmYSPRvnxBzHHDb14ybruygPPORK3vFp+gsNnFipQw=; b=iz3k9DZSMQwcauEoM0LZqlFt6/ Zz/t9RdmOgW73eM7ZPB8Y2cwAFZT4lFBP1QBV0GKGue4MX6y7qTkeg9/libilnyxDn51LgtykOrEP rIL0zlLLFDGC1EAyrMRBMr/hz;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47786 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eboOu-002XkE-Ht; Wed, 17 Jan 2018 07:09:12 -0700
To: Ladislav Lhotka , Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com>  <1516172373.21945.16.camel@nic.cz>
From: Lou Berger 
Message-ID: <2d3e40ab-7dd6-20ea-ee41-c06c498d767c@labn.net>
Date: Wed, 17 Jan 2018 09:09:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516172373.21945.16.camel@nic.cz>
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-Exim-ID: 1eboOu-002XkE-Ht
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]:47786
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 14:09:20 -0000

On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
...
>>>>>> I think
>>>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>>>> this case, inline schema being represented by YL) to argue why the
>>>>>> decision needs to be revisited.
>>>>> I'm repeating my self: b/c the current solution doesn't work well with
>>>>> the NMDA.
>>>> I simply don't understand how YL-bis works at the root node but
>>>> doesn't work equally at an inline mount point.  Can you elaborate?
>>> With NMDA, a server may have one schema for the config datastore and
>>> another one for operational (one is a superset of the other).  A
>>> mounted YL can only be present in operational.  Thus, there's no way a
>>> client can learn the schema for config.
>> If the LNE mounted the full YL-bis at the mount point then you would
>> have the list of datastores, and the schema associated with each
>> datastore.  Of course, this would only be available in operational, but
>> that is the same as a regular server support YL-bis.
> YL-bis is different in that it is in fact metadata even though we call it state
> data.
I couldn't agree more.  YL and SM are server metadata and are 
independent of any DS.  They could be accessed via any (as others have 
suggested), but we are currently choosing to access if via operational 
state.  With NMDA, I think personally think server meta data should have 
it's own DS.  This discussion has convinced me that the current proposed 
alternative, of accessing as operational data is flawed and even access 
via *any* DS is preferable.

> In any case, no matter what datastores the server has, YL-bis is the
> single well-known location from which the schema of all datastores can be
> retrieved.
That's a nice idea, but as was discussed in december, the direction 
being taken doesn't include SM so this statement isn't *currently* true.

>
> We could refer to  as the place from which the mounted schemas of
> NMDA-standard config datastores can be retrieved (except for special cases, one
> is discussed below). But if there is another config datastore (e.g. dynamic)
> with an inline mount point instance, it is unclear where to look for the mounted
> schema.
Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
any different than YL?

>   With my proposal, the mount point instance will be annotated with
> @schema-ref that points to a schema in the top-level YL.
right and as we thrashed out the last time we had discussed this with 
the whole WG, having inline schema available at the top level was not 
the preferred solution.

>
>> I thought that the problem with the current solution and NMDA, was that
>> there is no way to find out what the LNE schema is if the LNE isn't
>> booted, and hence isn't providing .  But I'm not sure what
>> issues that actually causes.  E.g. does it cause issues with
>> pre-configuration of the LNE?
> The issue that this causes is that the schema for the pre-configured LNE isn't
> known and validity of  is unclear.
Please elaborate on what you see here as a problem.  Those working on 
LNE's (including myself) don't see an issue here.

Lou
>
> Lada
>


From nobody Wed Jan 17 06:17: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 F1DAB124217 for ; Wed, 17 Jan 2018 06:17:31 -0800 (PST)
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 lWpM57yu7NnH for ; Wed, 17 Jan 2018 06:17:30 -0800 (PST)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 2131A127735 for ; Wed, 17 Jan 2018 06:17:27 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id A754C40521 for ; Wed, 17 Jan 2018 07:17:24 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id zSHL1w00Q2SSUrH01SHP1D; Wed, 17 Jan 2018 07:17:24 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=TI5KlET8cEl4fF2YEbAA:9 a=QEXdDO2ut3YA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JqDmE6ozrI7qptz9p+p1bDkLaorl/WzJfLggfnIyD+k=; b=fs2OauX4N7bleE+71prNmBmZpV 2Kdl9WF1Zc/46+d2fMymwm24AAFCTDRUtsUWWV6JDopm1UT0gLI3J6GmI9n95hF9CCAqj7TpJ/vEA sHI4kjUxxTrhbBZpFCQBhl+I1;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48394 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eboWm-002a3g-59; Wed, 17 Jan 2018 07:17:20 -0700
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References: <20180116.165014.297580929914718463.mbj@tail-f.com>  <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net> <20180117.092002.464472752076487902.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Wed, 17 Jan 2018 09:17:17 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180117.092002.464472752076487902.mbj@tail-f.com>
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-Exim-ID: 1eboWm-002a3g-59
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]:48394
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 14:17:32 -0000

On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 1/16/2018 11:15 AM, Robert Wilton wrote:
>>> On 16/01/2018 15:50, Martin Bjorklund wrote:
>>>> Lou Berger  wrote:
>>>>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
>>>>> ... (trimming to topic)
>>>>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts
>>>>>>>>>>>>> already
>>>>>>>>>>>>> with
>>>>>>>>>>>> No at all. The first and last time I proposed this was on 15
>>>>>>>>>>>> December
>>>>>>>>>>>> 2017:
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>>>>>>>>>>>>
>>>>>>>>>>> Oh, I certainly would call you proposing that the schema for inline
>>>>>>>>>>> be
>>>>>>>>>>> part of the rest of the schema Mount module well before that. I'm
>>>>>>>>>>> sure
>>>>>>>>>>> I can dig up mail / slides it really necessary...
>>>>>>>>>> I don't think this has been proposed before.  All previous proposals
>>>>>>>>>> were basically variants on what is now "use-schema", which works fine
>>>>>>>>>> when all instances have the same schema.  This new proposal solves the
>>>>>>>>>> issue with different schemas in different instances.
>>>>>>>>>>
>>>>>>>>> I thought the previous proposals that as well, so don't see material
>>>>>>>>> difference - at least from the usage standpoint. I also don't see why
>>>>>>>>> the previous arguments that resulted in consensus for using Yang
>>>>>>>>> Library underneath the an in line Mount Point don't apply.
>>>>>>>> B/c it doesn't work well with the NMDA.  You can't mount yang library
>>>>>>>> in the configuration datastores; it has to be mounted in operational.
>>>>>>>> With meta-data, you can actually report the correct schema even in
>>>>>>>> running.  (This is actually true also for pre-NMDA systems).
>>>>>>>>
>>>>>>> Understood and agree there is nothing new here and the current version
>>>>>>> of SM (including inline) has the same limitation as rfc7895, and I'd
>>>>>>> expect it to behave the same once we have rfc7985bis -- in fact the
>>>>>>> inline case "just works" with YL-bis as defined today.
>>>>> Martin,
>>>>>
>>>>> you didn't respond to this point.
>>>> I agree, it works for non-NMDA servers. But see below.
>>>>
>>>>>>> The argument I recall being the key point on inline was handling the
>>>>>>> large variety of possible different implementation approaches for
>>>>>>> modules using inline.
>>>>>> I think these still are covered.
>>>>>>
>>>>>>> For example an LNE that is implemented using
>>>>>>> VMs which can be managed by the host at different times of the VMs
>>>>>>> operational life cycle based on customer/provider requirements.  I
>>>>>>> really don't see how YL-bis has any bearing on this point and
>>>>>> Using the new proposed meta data annotation together with the new YL
>>>>>> means that SM can support the use case above also in an NMDA server.
>>>>>> I think the new proposed solution covers more use cases than the
>>>>>> previous solution.
>>>>> how so?  The inline mount point would contain YL-bis and have the same
>>>>> information there, just scoped for the mount point.  It's true a
>>>>> client would need to understand the mount point's schema only upon
>>>>> parsing the YL under the mount point and this schema could not be
>>>>> shared across inline mount points.  But this is as was discussed in
>>>>> the past and unchanged from YL.
>>>>>
>>>>>> Do you think that there is any use case that the proposed solution
>>>>>> cannot handle, but the previous solution did?
>>>>> yes.  with VM/container technologies the YL / schema can change under
>>>>> the mount point from time to time during normal operation (i.e.,
>>>>> during runtime, no reboot) and, in some implementations, may require
>>>>> some level of rpc operation to access even the schema.  The new (and
>>>>> previously proposed approach) of having inline schema available from
>>>>> the top level greatly complicates these cases.  Also keep in mind that
>>>>> there will be cases where the ability to access information under an
>>>>> inline mount point will dynamically change in operation (and top level
>>>>> YL would need to remove schema information for the inline mount
>>>>> point.)  As before, from the usage standpoint, these changes don't
>>>>> provide a whole lot of value and seem to optimizing for something not
>>>>> needed in the inline case.
>>>> I think this is an implementation issue, rather than a problem with
>>>> the proposed mechanism, and it is present in the current solution as
>>>> well.  An implementation that can handle dynamically changing mounted
>>>> YLs in the current solution can do that in the new solution as well.
>>>>
>>>>>>> I think
>>>>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>>>>> this case, inline schema being represented by YL) to argue why the
>>>>>>> decision needs to be revisited.
>>>>>> I'm repeating my self: b/c the current solution doesn't work well with
>>>>>> the NMDA.
>>>>> I simply don't understand how YL-bis works at the root node but
>>>>> doesn't work equally at an inline mount point.  Can you elaborate?
>>>> With NMDA, a server may have one schema for the config datastore and
>>>> another one for operational (one is a superset of the other).  A
>>>> mounted YL can only be present in operational.  Thus, there's no way a
>>>> client can learn the schema for config.
>>> If the LNE mounted the full YL-bis at the mount point then you would
>>> have the list of datastores, and the schema associated with each
>>> datastore.  Of course, this would only be available in operational,
>>> but
>>> that is the same as a regular server support YL-bis.
>> exactly my point.
> Yes, you're right.  But it requires the usage of YL-bis.
>
>>> I thought that the problem with the current solution and NMDA, was
>>> that
>>> there is no way to find out what the LNE schema is if the LNE isn't
>>> booted, and hence isn't providing .
>> I've never heard anyone mention this issue/limitation.
> This has been dicussed, but this does not change with the introduction
> of the meta annotation; if the server has off-line knowledge of the
> instance's schema then it can populate an inline YL as well as the
> meta annotation and corresponding SM data.
>
>> My
>> understanding of the previously raised objections were (a) that the
>> full schema can't be obtained by just reading the top level YL and (b)
>> that when multiple inline mount points have the same schema the
>> information can't be combined using a shared schema approach as is
>> taken in base SM.
> Right.  Both these issues are addressed by using a meta annotation.

But when we discussed this the last time having inline schema available 
at the top level (in the SM module), the general consensus was that 
having YL under inline was the preferred approach.  Lada stated that he 
didn't like the approach, but would go with the WG decision.  Why are we 
reopening this closed discussion -- many months after we closed the 
issue?  Most who contributed, notably users, have moved from SM assuming 
it's a solved problem.

At this point, I think the case needs to be made why the existing 
mechanisms in the draft are broken vs how they might be improved. My 
understanding is that there was one issue that could be clarified by the 
proposed text I included when restarting this discussion.

What else is *broken* in the current draft?

Lou
>
>
> /martin
>
>
>> Yes both increase client operations/work, but
>> without incurring the server side implementation overhead that is
>> implied in this approach.  -- Again, I don't see how YL-bis or NMDA
>> changes any of this.
>>
>>>    But I'm not sure what
>>> issues that actually causes.  E.g. does it cause issues with
>>> pre-configuration of the LNE?
>> Assignment of host resources takes place at the root level, not the
>> within the context of the inline mount point, other preprovisiong can
>> be handled via the inline/managed mechanisms defined in the LNE
>> module.  We looked at this in detail for multiple server/vendor
>> implementations and agreed the current mechanisms work even if not
>> optimal in all cases.
>>
>> Lou
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>> With the proposed solution, there can be different schema-ref pointers
>>>> in config and operational (if needed).
>>>>
>>>>
>>>> /martin
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> .
>>>>


From nobody Wed Jan 17 06:42:10 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 5121912DB6D for ; Wed, 17 Jan 2018 06:42:09 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aoyAskLYF9WM for ; Wed, 17 Jan 2018 06:42:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 170041309F4 for ; Wed, 17 Jan 2018 06:42:07 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id E859C1AE0428; Wed, 17 Jan 2018 15:42:05 +0100 (CET)
Date: Wed, 17 Jan 2018 15:42:05 +0100 (CET)
Message-Id: <20180117.154205.449528767667713089.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net> <20180117.092002.464472752076487902.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 14:42:09 -0000

Lou Berger  wrote:
> =

> =

> On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >>
> >> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >>> On 16/01/2018 15:50, Martin Bjorklund wrote:
> >>>> Lou Berger  wrote:
> >>>>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> >>>>> ... (trimming to topic)
> >>>>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are d=
rafts
> >>>>>>>>>>>>> already
> >>>>>>>>>>>>> with
> >>>>>>>>>>>> No at all. The first and last time I proposed this was o=
n 15
> >>>>>>>>>>>> December
> >>>>>>>>>>>> 2017:
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg=
19753.html
> >>>>>>>>>>>>
> >>>>>>>>>>> Oh, I certainly would call you proposing that the schema =
for inline
> >>>>>>>>>>> be
> >>>>>>>>>>> part of the rest of the schema Mount module well before t=
hat. I'm
> >>>>>>>>>>> sure
> >>>>>>>>>>> I can dig up mail / slides it really necessary...
> >>>>>>>>>> I don't think this has been proposed before.  All previous=
 proposals
> >>>>>>>>>> were basically variants on what is now "use-schema", which=
 works
> >>>>>>>>>> fine
> >>>>>>>>>> when all instances have the same schema.  This new proposa=
l solves
> >>>>>>>>>> the
> >>>>>>>>>> issue with different schemas in different instances.
> >>>>>>>>>>
> >>>>>>>>> I thought the previous proposals that as well, so don't see=
 material
> >>>>>>>>> difference - at least from the usage standpoint. I also don=
't see why
> >>>>>>>>> the previous arguments that resulted in consensus for using=
 Yang
> >>>>>>>>> Library underneath the an in line Mount Point don't apply.
> >>>>>>>> B/c it doesn't work well with the NMDA.  You can't mount yan=
g library
> >>>>>>>> in the configuration datastores; it has to be mounted in ope=
rational.
> >>>>>>>> With meta-data, you can actually report the correct schema e=
ven in
> >>>>>>>> running.  (This is actually true also for pre-NMDA systems).=

> >>>>>>>>
> >>>>>>> Understood and agree there is nothing new here and the curren=
t version
> >>>>>>> of SM (including inline) has the same limitation as rfc7895, =
and I'd
> >>>>>>> expect it to behave the same once we have rfc7985bis -- in fa=
ct the
> >>>>>>> inline case "just works" with YL-bis as defined today.
> >>>>> Martin,
> >>>>>
> >>>>> you didn't respond to this point.
> >>>> I agree, it works for non-NMDA servers. But see below.
> >>>>
> >>>>>>> The argument I recall being the key point on inline was handl=
ing the
> >>>>>>> large variety of possible different implementation approaches=
 for
> >>>>>>> modules using inline.
> >>>>>> I think these still are covered.
> >>>>>>
> >>>>>>> For example an LNE that is implemented using
> >>>>>>> VMs which can be managed by the host at different times of th=
e VMs
> >>>>>>> operational life cycle based on customer/provider requirement=
s.=A0 I
> >>>>>>> really don't see how YL-bis has any bearing on this point and=

> >>>>>> Using the new proposed meta data annotation together with the =
new YL
> >>>>>> means that SM can support the use case above also in an NMDA s=
erver.
> >>>>>> I think the new proposed solution covers more use cases than t=
he
> >>>>>> previous solution.
> >>>>> how so?=A0 The inline mount point would contain YL-bis and have=
 the same
> >>>>> information there, just scoped for the mount point.=A0 It's tru=
e a
> >>>>> client would need to understand the mount point's schema only u=
pon
> >>>>> parsing the YL under the mount point and this schema could not =
be
> >>>>> shared across inline mount points.=A0 But this is as was discus=
sed in
> >>>>> the past and unchanged from YL.
> >>>>>
> >>>>>> Do you think that there is any use case that the proposed solu=
tion
> >>>>>> cannot handle, but the previous solution did?
> >>>>> yes.=A0 with VM/container technologies the YL / schema can chan=
ge under
> >>>>> the mount point from time to time during normal operation (i.e.=
,
> >>>>> during runtime, no reboot) and, in some implementations, may re=
quire
> >>>>> some level of rpc operation to access even the schema.=A0 The n=
ew (and
> >>>>> previously proposed approach) of having inline schema available=
 from
> >>>>> the top level greatly complicates these cases.=A0 Also keep in =
mind that
> >>>>> there will be cases where the ability to access information und=
er an
> >>>>> inline mount point will dynamically change in operation (and to=
p level
> >>>>> YL would need to remove schema information for the inline mount=

> >>>>> point.)=A0 As before, from the usage standpoint, these changes =
don't
> >>>>> provide a whole lot of value and seem to optimizing for somethi=
ng not
> >>>>> needed in the inline case.
> >>>> I think this is an implementation issue, rather than a problem w=
ith
> >>>> the proposed mechanism, and it is present in the current solutio=
n as
> >>>> well.  An implementation that can handle dynamically changing mo=
unted
> >>>> YLs in the current solution can do that in the new solution as w=
ell.
> >>>>
> >>>>>>> I think
> >>>>>>> it is incumbent upon those revisiting past/closed WG decision=
s (in
> >>>>>>> this case, inline schema being represented by YL) to argue wh=
y the
> >>>>>>> decision needs to be revisited.
> >>>>>> I'm repeating my self: b/c the current solution doesn't work w=
ell with
> >>>>>> the NMDA.
> >>>>> I simply don't understand how YL-bis works at the root node but=

> >>>>> doesn't work equally at an inline mount point.=A0 Can you elabo=
rate?
> >>>> With NMDA, a server may have one schema for the config datastore=
 and
> >>>> another one for operational (one is a superset of the other).  A=

> >>>> mounted YL can only be present in operational.  Thus, there's no=
 way a
> >>>> client can learn the schema for config.
> >>> If the LNE mounted the full YL-bis at the mount point then you wo=
uld
> >>> have the list of datastores, and the schema associated with each
> >>> datastore.=A0 Of course, this would only be available in operatio=
nal,
> >>> but
> >>> that is the same as a regular server support YL-bis.
> >> exactly my point.
> > Yes, you're right.  But it requires the usage of YL-bis.
> >
> >>> I thought that the problem with the current solution and NMDA, wa=
s
> >>> that
> >>> there is no way to find out what the LNE schema is if the LNE isn=
't
> >>> booted, and hence isn't providing .
> >> I've never heard anyone mention this issue/limitation.
> > This has been dicussed, but this does not change with the introduct=
ion
> > of the meta annotation; if the server has off-line knowledge of the=

> > instance's schema then it can populate an inline YL as well as the
> > meta annotation and corresponding SM data.
> >
> >> My
> >> understanding of the previously raised objections were (a) that th=
e
> >> full schema can't be obtained by just reading the top level YL and=
 (b)
> >> that when multiple inline mount points have the same schema the
> >> information can't be combined using a shared schema approach as is=

> >> taken in base SM.
> > Right.  Both these issues are addressed by using a meta annotation.=

> =

> But when we discussed this the last time having inline schema
> available at the top level (in the SM module), the general consensus
> was that having YL under inline was the preferred approach.

What is new now is that we have an indirection; each instance has its
own pointer to the schema at the top level.  In the previous
discussion, having the schema at the top level implied that all
instances shared the same schema, and *that* was rejected.

> Lada
> stated that he didn't like the approach, but would go with the WG
> decision.=A0 Why are we reopening this closed discussion -- many mont=
hs
> after we closed the issue?=A0 Most who contributed, notably users, ha=
ve
> moved from SM assuming it's a solved problem.
> =

> At this point, I think the case needs to be made why the existing
> mechanisms in the draft are broken vs how they might be improved. My
> understanding is that there was one issue that could be clarified by
> the proposed text I included when restarting this discussion.
> =

> What else is *broken* in the current draft?

My main concern is actually the YL version.  I strongly think SM need
to use YL-bis rather that the old YL, so that it can support NMDA.

The implementation effort for supporting the new YL in clients and
servers is minimal, esp. when compared to the efforts involved in
supporting SM.

Adding an indirection is (for me) less important, but it has the
benefit of solving the two issues (a) and (b) above, and I haven't
seen any technical problem with it.

Do you have any technical concerns with using an annotation as an
indirection?


/martin


From nobody Wed Jan 17 07:43: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 76504129C5D for ; Wed, 17 Jan 2018 07:43:45 -0800 (PST)
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 eNt0i1ZsSPCX for ; Wed, 17 Jan 2018 07:43:41 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 C1620131483 for ; Wed, 17 Jan 2018 07:43:37 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 8A2AD1E0972 for ; Wed, 17 Jan 2018 08:43:33 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id zTjW1w0092SSUrH01TjZWf; Wed, 17 Jan 2018 08:43:33 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=yy8xooHgIfOp-6ErD7oA:9 a=QEXdDO2ut3YA:10 a=ZVvG44Nqbz4A:10 a=aztA8ZntzogA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sMWsj9xLSo/TIfcKNRdXANDzRDFPtXrEo357BGHbQuk=; b=LWrL3DutX/Rb9C1ldZfrQnsr67 x+L9MWolXqlLrr+2rm3SRTpVUOI1a+MPvJBUe8C/3oFVCIOI4g+/J38cvdH+j47G/K4nr9z+i5XIn xEH0ZzaOr38sfpISXTSlS9z1Z;
Received: from [172.58.185.95] (port=31266 helo=[IPV6:2607:fb90:6505:8e19:0:4e:ebc5:4d01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebps9-0032d8-O6; Wed, 17 Jan 2018 08:43:30 -0700
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Wed, 17 Jan 2018 10:43:25 -0500
Message-ID: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20180117.154205.449528767667713089.mbj@tail-f.com>
References: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net> <20180117.092002.464472752076487902.mbj@tail-f.com>  <20180117.154205.449528767667713089.mbj@tail-f.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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: 172.58.185.95
X-Exim-ID: 1ebps9-0032d8-O6
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:6505:8e19:0:4e:ebc5:4d01]) [172.58.185.95]:31266
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 15:43:45 -0000

On January 17, 2018 9:42:43 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>>
>>
>> On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
>> > Lou Berger  wrote:
>> >>
>> >> On 1/16/2018 11:15 AM, Robert Wilton wrote:
>> >>> On 16/01/2018 15:50, Martin Bjorklund wrote:
>> >>>> Lou Berger  wrote:
>> >>>>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
>> >>>>> ... (trimming to topic)
>> >>>>>>>>>>>>> rejectected by the WG multiple times.  FWIW there are drafts
>> >>>>>>>>>>>>> already
>> >>>>>>>>>>>>> with
>> >>>>>>>>>>>> No at all. The first and last time I proposed this was on 15
>> >>>>>>>>>>>> December
>> >>>>>>>>>>>> 2017:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Oh, I certainly would call you proposing that the schema for inline
>> >>>>>>>>>>> be
>> >>>>>>>>>>> part of the rest of the schema Mount module well before that. I'm
>> >>>>>>>>>>> sure
>> >>>>>>>>>>> I can dig up mail / slides it really necessary...
>> >>>>>>>>>> I don't think this has been proposed before.  All previous proposals
>> >>>>>>>>>> were basically variants on what is now "use-schema", which works
>> >>>>>>>>>> fine
>> >>>>>>>>>> when all instances have the same schema.  This new proposal solves
>> >>>>>>>>>> the
>> >>>>>>>>>> issue with different schemas in different instances.
>> >>>>>>>>>>
>> >>>>>>>>> I thought the previous proposals that as well, so don't see material
>> >>>>>>>>> difference - at least from the usage standpoint. I also don't see why
>> >>>>>>>>> the previous arguments that resulted in consensus for using Yang
>> >>>>>>>>> Library underneath the an in line Mount Point don't apply.
>> >>>>>>>> B/c it doesn't work well with the NMDA.  You can't mount yang library
>> >>>>>>>> in the configuration datastores; it has to be mounted in operational.
>> >>>>>>>> With meta-data, you can actually report the correct schema even in
>> >>>>>>>> running.  (This is actually true also for pre-NMDA systems).
>> >>>>>>>>
>> >>>>>>> Understood and agree there is nothing new here and the current version
>> >>>>>>> of SM (including inline) has the same limitation as rfc7895, and I'd
>> >>>>>>> expect it to behave the same once we have rfc7985bis -- in fact the
>> >>>>>>> inline case "just works" with YL-bis as defined today.
>> >>>>> Martin,
>> >>>>>
>> >>>>> you didn't respond to this point.
>> >>>> I agree, it works for non-NMDA servers. But see below.
>> >>>>
>> >>>>>>> The argument I recall being the key point on inline was handling the
>> >>>>>>> large variety of possible different implementation approaches for
>> >>>>>>> modules using inline.
>> >>>>>> I think these still are covered.
>> >>>>>>
>> >>>>>>> For example an LNE that is implemented using
>> >>>>>>> VMs which can be managed by the host at different times of the VMs
>> >>>>>>> operational life cycle based on customer/provider requirements.  I
>> >>>>>>> really don't see how YL-bis has any bearing on this point and
>> >>>>>> Using the new proposed meta data annotation together with the new YL
>> >>>>>> means that SM can support the use case above also in an NMDA server.
>> >>>>>> I think the new proposed solution covers more use cases than the
>> >>>>>> previous solution.
>> >>>>> how so?  The inline mount point would contain YL-bis and have the same
>> >>>>> information there, just scoped for the mount point.  It's true a
>> >>>>> client would need to understand the mount point's schema only upon
>> >>>>> parsing the YL under the mount point and this schema could not be
>> >>>>> shared across inline mount points.  But this is as was discussed in
>> >>>>> the past and unchanged from YL.
>> >>>>>
>> >>>>>> Do you think that there is any use case that the proposed solution
>> >>>>>> cannot handle, but the previous solution did?
>> >>>>> yes.  with VM/container technologies the YL / schema can change under
>> >>>>> the mount point from time to time during normal operation (i.e.,
>> >>>>> during runtime, no reboot) and, in some implementations, may require
>> >>>>> some level of rpc operation to access even the schema.  The new (and
>> >>>>> previously proposed approach) of having inline schema available from
>> >>>>> the top level greatly complicates these cases.  Also keep in mind that
>> >>>>> there will be cases where the ability to access information under an
>> >>>>> inline mount point will dynamically change in operation (and top level
>> >>>>> YL would need to remove schema information for the inline mount
>> >>>>> point.)  As before, from the usage standpoint, these changes don't
>> >>>>> provide a whole lot of value and seem to optimizing for something not
>> >>>>> needed in the inline case.
>> >>>> I think this is an implementation issue, rather than a problem with
>> >>>> the proposed mechanism, and it is present in the current solution as
>> >>>> well.  An implementation that can handle dynamically changing mounted
>> >>>> YLs in the current solution can do that in the new solution as well.
>> >>>>
>> >>>>>>> I think
>> >>>>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>> >>>>>>> this case, inline schema being represented by YL) to argue why the
>> >>>>>>> decision needs to be revisited.
>> >>>>>> I'm repeating my self: b/c the current solution doesn't work well with
>> >>>>>> the NMDA.
>> >>>>> I simply don't understand how YL-bis works at the root node but
>> >>>>> doesn't work equally at an inline mount point.  Can you elaborate?
>> >>>> With NMDA, a server may have one schema for the config datastore and
>> >>>> another one for operational (one is a superset of the other).  A
>> >>>> mounted YL can only be present in operational.  Thus, there's no way a
>> >>>> client can learn the schema for config.
>> >>> If the LNE mounted the full YL-bis at the mount point then you would
>> >>> have the list of datastores, and the schema associated with each
>> >>> datastore.  Of course, this would only be available in operational,
>> >>> but
>> >>> that is the same as a regular server support YL-bis.
>> >> exactly my point.
>> > Yes, you're right.  But it requires the usage of YL-bis.
>> >
>> >>> I thought that the problem with the current solution and NMDA, was
>> >>> that
>> >>> there is no way to find out what the LNE schema is if the LNE isn't
>> >>> booted, and hence isn't providing .
>> >> I've never heard anyone mention this issue/limitation.
>> > This has been dicussed, but this does not change with the introduction
>> > of the meta annotation; if the server has off-line knowledge of the
>> > instance's schema then it can populate an inline YL as well as the
>> > meta annotation and corresponding SM data.
>> >
>> >> My
>> >> understanding of the previously raised objections were (a) that the
>> >> full schema can't be obtained by just reading the top level YL and (b)
>> >> that when multiple inline mount points have the same schema the
>> >> information can't be combined using a shared schema approach as is
>> >> taken in base SM.
>> > Right.  Both these issues are addressed by using a meta annotation.
>>
>> But when we discussed this the last time having inline schema
>> available at the top level (in the SM module), the general consensus
>> was that having YL under inline was the preferred approach.
>
> What is new now is that we have an indirection; each instance has its
> own pointer to the schema at the top level.  In the previous
> discussion, having the schema at the top level implied that all
> instances shared the same schema, and *that* was rejected.
>

Indirection was possible at the previous time and is part of the current 
scheme Mount definition. Yes, you need to use different mount points to 
reference different schema, but take a look at the ni document that's 
exactly what we are doing there. So I don't believe this is the point that 
caused the previous proposal to be rejected.

>> Lada
>> stated that he didn't like the approach, but would go with the WG
>> decision.  Why are we reopening this closed discussion -- many months
>> after we closed the issue?  Most who contributed, notably users, have
>> moved from SM assuming it's a solved problem.
>>
>> At this point, I think the case needs to be made why the existing
>> mechanisms in the draft are broken vs how they might be improved. My
>> understanding is that there was one issue that could be clarified by
>> the proposed text I included when restarting this discussion.
>>
>> What else is *broken* in the current draft?
>
> My main concern is actually the YL version.  I strongly think SM need
> to use YL-bis rather that the old YL, so that it can support NMDA.
>

Right now to SM is independent of Yang Library version and can run with 
either. I certainly would expect use of Yang Library bis and nmda to have 
advantages.

> The implementation effort for supporting the new YL in clients and
> servers is minimal, esp. when compared to the efforts involved in
> supporting SM.
>
> Adding an indirection is (for me) less important, but it has the
> benefit of solving the two issues (a) and (b) above, and I haven't
> seen any technical problem with it.
>
(A) has implementation implications and those participating in the 
discussion at the time expressed as not being worth the cost.
I don't believe b was seen as a significant issue either.

> Do you have any technical concerns with using an annotation as an
> indirection?
>

The technicsl issue I have with the approaches the same one that was raised 
when debated previously, ie the implementation overhead of requiring inline 
schemas to be available at the top level.

>From a process perspective, I don't think it's fair to those who provided 
input or contributed in the past  in order to get scheme mount to satisfy 
their requirements to reopen something that is not broken. Particularly 
because a number of those contributors are implementers and users  who are 
now focused on other topics.

Lou

>
> /martin
>



From nobody Wed Jan 17 08:00: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 24A2D13148C; Wed, 17 Jan 2018 07:59:55 -0800 (PST)
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.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151620479510.10840.2508407655600449329@ietfa.amsl.com>
Date: Wed, 17 Jan 2018 07:59:55 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 15:59:55 -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           : A YANG Data Model for Routing Management (NDMA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-09.txt
	Pages           : 77
	Date            : 2018-01-17

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-09


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 Wed Jan 17 08:03: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 DFDBA131494; Wed, 17 Jan 2018 08:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HM3fHkpgAJBt; Wed, 17 Jan 2018 08:03:16 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E58113148E; Wed, 17 Jan 2018 08:02:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2332; q=dns/txt; s=iport; t=1516204968; x=1517414568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EU0ZF/ijgOg2EsP/0LnuvAfzO9LT2etzMUxoe1p8Y+Q=; b=U4i6reEU1sEao3UTq4RgiM0sK7+sI4tlXfjiEDv2QPa4RYDO0bPQ5Tr9 kYF8Br3aFBp0tz5XaoyboerJ2Wgs5GU0M2z9DX7OoO4kZnWSNq0Jfh/Mv MA1Znfo5d6+BkNeaho04wajHvTGxDlL5cQmKdf7e6HPadTOwZoTtazQvA U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAADGcl9a/5NdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNBZnQnB4QMiiSOXoICly6CFgojhRgCGoRKPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUkBiMRRRACAQgUBgImAgICMBUQAQEEAQ0FijMQpT2CJ4lNAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYEPhUKDQIMugyQLAgKFBoJlAQSjbAKIDI1FghlnhTaLXY1?= =?us-ascii?q?DiT8CERkBgTsBHzmBUG8VgmcJhE54AYsEgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200"; d="scan'208";a="57993162"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 16:02:47 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0HG2lPP031819 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2018 16:02:47 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; Wed, 17 Jan 2018 11:02:46 -0500
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; Wed, 17 Jan 2018 11:02:46 -0500
From: "Acee Lindem (acee)" 
To: "Hejia (Jia)" , "rtg-ads@ietf.org" 
CC: "rtg-dir@ietf.org" , "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
Thread-Index: AdOPXq3GoHXlPWDwRv+GyrBCDNGb/QATeQyA
Date: Wed, 17 Jan 2018 16:02:46 +0000
Message-ID: 
References: <735916399E11684EAF4EB4FB376B719553034791@DGGEMA503-MBX.china.huawei.com>
In-Reply-To: <735916399E11684EAF4EB4FB376B719553034791@DGGEMA503-MBX.china.huawei.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <822982CFE4292444A9748B8B801ED6BB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:03:21 -0000

SGkgSmlhLCANCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4gVGhlIEFwcGVuZGl4IEQgbml0IGhh
cyBiZWVuIGZpeGVkIGluIHRoZSAtMDkNCnZlcnNpb24gICh0aGUgb25seSBjaGFuZ2UpLg0KDQpU
aGFua3MsDQpBY2VlDQoNCk9uIDEvMTcvMTgsIDE6NTAgQU0sICJIZWppYSAoSmlhKSIgPGhlamlh
QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGVsbG8sDQo+DQo+SSBoYXZlIGJlZW4gc2VsZWN0ZWQg
YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQo+VGhl
IFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRp
bmctcmVsYXRlZA0KPmRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBh
bmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMNCj5vbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBw
dXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvDQo+dGhlIFJv
dXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3Rv
cmF0ZSwNCj5wbGVhc2Ugc2VlIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3Ry
YWMvd2lraS9SdGdEaXINCj4NCj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5
IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQNCj53b3VsZCBiZSBoZWxwZnVsIGlm
IHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYNCj5MYXN0
IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRo
ZW0gdGhyb3VnaA0KPmRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KPg0KPkRv
Y3VtZW50IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDgudHh0DQo+UmV2aWV3ZXI6IEpp
YSBIZSANCj5SZXZpZXcgRGF0ZTogMTcgSmFudWFyeSAyMDE4DQo+SUVURiBMQyBFbmQgRGF0ZTog
MTUgSmFudWFyeSAyMDE4DQo+VGVsZWNoYXQgZGF0ZTogMjUgSmFudWFyeSAyMDE4DQo+SW50ZW5k
ZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCj4NCj5TdW1tYXJ5DQo+VGhpcyBkb2N1bWVudCBw
cm92aWRlcyBhbiBOTURBLWNvbXBsaWFudCB2ZXJzaW9uIG9mIFlBTkcgZGF0YSBtb2RlbCBmb3IN
Cj5yb3V0aW5nIG1hbmFnZW1lbnQuIEl0IGlzIHZlcnkgd2VsbCB3cml0dGVuIGFuZCByZWFkeSBm
b3IgcHVibGljYXRpb24uDQo+QnV0IEkgaGFwcGVuZWQgdG8gc2VlIGEgc21hbGwgbml0IGluIEFw
cGVuZGl4IEQganVzdCBiZWZvcmUgSSBmaW5pc2hlZCBteQ0KPnJldmlldywgc2VlIGJlbG93Lg0K
Pg0KPkNvbW1lbnRzDQo+Tm9uZS4NCj4NCj5NYWpvciBJc3N1ZXM6DQo+Tm8gbWFqb3IgaXNzdWVz
IGZvdW5kLg0KPg0KPk1pbm9yIElzc3VlczoNCj5ObyBtaW5vciBpc3N1ZXMgZm91bmQuDQo+DQo+
Tml0czoNCj5JbiBBcHBlbmRpeCBELCB0aGUgbmFtZXNwYWNlIG9mICJpZXRmLWlwdjYtdW5pY2Fz
dC1yb3V0aW5nIiBpcyB3cml0dGVuIGFzDQo+InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp
ZXRmLWlwdjYtdW5pY2FzdC1yb3V0aW5nLTMiLiAiLTMiIGlzIG5vdA0KPm1lYW5pbmdmdWwgYW5k
IG5lZWRzIHRvIGJlIGRlbGV0ZWQuDQo+DQo+DQo+DQo+UmVnYXJkcywNCj5KaWENCg0K


From nobody Wed Jan 17 08:06: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 3DA331314A7 for ; Wed, 17 Jan 2018 08:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 VcAM6wVNLxcj for ; Wed, 17 Jan 2018 08:06:19 -0800 (PST)
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 99FDE131499 for ; Wed, 17 Jan 2018 08:06:16 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id DBB1064ADD; Wed, 17 Jan 2018 17:06:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516205174; bh=++cm7nusS0duLVk6ejRwjHWNoVvpmOymhDCExS+6a2A=; h=From:To:Date; b=OacwlzAkGcxZoZYTDRUPCAcBgZz1fAd/8Rb8T0NHeOzH6Oo5QQ8hHKf+yc+Z0KWfj DggZxGNuR4ix5Tu2MRMOpKYzq7S/7TSyjUm4uxjFCVgGXeq9bnsA7sGmgxY8Yytxaz 8SnOANgKQX7frN9J9vxuhGYfbkrqqS+6ixUAgE/M=
Message-ID: <1516205174.1388.48.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 17:06:14 +0100
In-Reply-To: <2d3e40ab-7dd6-20ea-ee41-c06c498d767c@labn.net>
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com>  <1516172373.21945.16.camel@nic.cz> <2d3e40ab-7dd6-20ea-ee41-c06c498d767c@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:06:27 -0000

On Wed, 2018-01-17 at 09:09 -0500, Lou Berger wrote:
> 
> On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
> ...
> > > > > > > I think
> > > > > > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > > > > > this case, inline schema being represented by YL) to argue why the
> > > > > > > decision needs to be revisited.
> > > > > > 
> > > > > > I'm repeating my self: b/c the current solution doesn't work well
> > > > > > with
> > > > > > the NMDA.
> > > > > 
> > > > > I simply don't understand how YL-bis works at the root node but
> > > > > doesn't work equally at an inline mount point.  Can you elaborate?
> > > > 
> > > > With NMDA, a server may have one schema for the config datastore and
> > > > another one for operational (one is a superset of the other).  A
> > > > mounted YL can only be present in operational.  Thus, there's no way a
> > > > client can learn the schema for config.
> > > 
> > > If the LNE mounted the full YL-bis at the mount point then you would
> > > have the list of datastores, and the schema associated with each
> > > datastore.  Of course, this would only be available in operational, but
> > > that is the same as a regular server support YL-bis.
> > 
> > YL-bis is different in that it is in fact metadata even though we call it
> > state
> > data.
> 
> I couldn't agree more.  YL and SM are server metadata and are 
> independent of any DS.  They could be accessed via any (as others have 
> suggested), but we are currently choosing to access if via operational 
> state.  With NMDA, I think personally think server meta data should have 
> it's own DS.  This discussion has convinced me that the current proposed 
> alternative, of accessing as operational data is flawed and even access 
> via *any* DS is preferable.

Yes, I would support an extra datastore.

> 
> > In any case, no matter what datastores the server has, YL-bis is the
> > single well-known location from which the schema of all datastores can be
> > retrieved.
> 
> That's a nice idea, but as was discussed in december, the direction 
> being taken doesn't include SM so this statement isn't *currently* true.

I assume SM is also part of metadata, so it would be in the same datastore as
YL.

> 
> > 
> > We could refer to  as the place from which the mounted schemas
> > of
> > NMDA-standard config datastores can be retrieved (except for special cases,
> > one
> > is discussed below). But if there is another config datastore (e.g. dynamic)
> > with an inline mount point instance, it is unclear where to look for the
> > mounted
> > schema.
> 
> Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
> any different than YL?

NMDA requires that standard config data be also in , so if we have
a mount point instance in , there is (mostly) a corresponding instance
in , which is the place where the embedded YL can be found. I don't
think other non-standard datastores necessarily have this relationship with
.

> 
> >   With my proposal, the mount point instance will be annotated with
> > @schema-ref that points to a schema in the top-level YL.
> 
> right and as we thrashed out the last time we had discussed this with 
> the whole WG, having inline schema available at the top level was not 
> the preferred solution.

Because we didn't have the metadata annotation that can now refer from any
inline mount point instance to a schema that is placed at the top level. It is
just a simple indirection.

> 
> > 
> > > I thought that the problem with the current solution and NMDA, was that
> > > there is no way to find out what the LNE schema is if the LNE isn't
> > > booted, and hence isn't providing .  But I'm not sure what
> > > issues that actually causes.  E.g. does it cause issues with
> > > pre-configuration of the LNE?
> > 
> > The issue that this causes is that the schema for the pre-configured LNE
> > isn't
> > known and validity of  is unclear.
> 
> Please elaborate on what you see here as a problem.  Those working on 
> LNE's (including myself) don't see an issue here.

Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
configuration for a LNE entry? If so, then I assume there is no corresponding
LNE entry in . If this is correct, then I don't see from where you
get the embedded YL instance. That is,  may contain

  "ietf-logical-network-element:logical-network-element": [
    { "name": "foo",
      "root": { ... pre-provisioned config ... }
    },
    ...
  ]

But if the "foo" LNE isn't booted, then there is no "foo" entry in
, i.e. also no corresponding instance of the "root" mount point.

Is this reasoning flawed?

Lada

> 
> Lou
> > 
> > Lada
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 17 08:18: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 A7D5112D7F8 for ; Wed, 17 Jan 2018 08:18:21 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AYulCR14bsp5 for ; Wed, 17 Jan 2018 08:18:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 561E412D7F2 for ; Wed, 17 Jan 2018 08:18:19 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 1BDB91AE0428; Wed, 17 Jan 2018 17:18:18 +0100 (CET)
Date: Wed, 17 Jan 2018 17:18:17 +0100 (CET)
Message-Id: <20180117.171817.479473055872371790.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References:  <20180117.154205.449528767667713089.mbj@tail-f.com> <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:18:21 -0000

Lou Berger  wrote:
> =

> =

> On January 17, 2018 9:42:43 AM Martin Bjorklund 
> wrote:
> =

> > Lou Berger  wrote:
> >>
> >>
> >> On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> >> > Lou Berger  wrote:
> >> >>
> >> >> On 1/16/2018 11:15 AM, Robert Wilton wrote:
> >> >>> On 16/01/2018 15:50, Martin Bjorklund wrote:
> >> >>>> Lou Berger  wrote:
> >> >>>>> On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> >> >>>>> ... (trimming to topic)
> >> >>>>>>>>>>>>> rejectected by the WG multiple times.  FWIW there ar=
e drafts
> >> >>>>>>>>>>>>> already
> >> >>>>>>>>>>>>> with
> >> >>>>>>>>>>>> No at all. The first and last time I proposed this wa=
s on 15
> >> >>>>>>>>>>>> December
> >> >>>>>>>>>>>> 2017:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> https://www.ietf.org/mail-archive/web/netmod/current/=
msg19753.html
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> Oh, I certainly would call you proposing that the sche=
ma for
> >> >>>>>>>>>>> inline
> >> >>>>>>>>>>> be
> >> >>>>>>>>>>> part of the rest of the schema Mount module well befor=
e
> >> >>>>>>>>>>> that. I'm
> >> >>>>>>>>>>> sure
> >> >>>>>>>>>>> I can dig up mail / slides it really necessary...
> >> >>>>>>>>>> I don't think this has been proposed before.  All previ=
ous
> >> >>>>>>>>>> proposals
> >> >>>>>>>>>> were basically variants on what is now "use-schema", wh=
ich works
> >> >>>>>>>>>> fine
> >> >>>>>>>>>> when all instances have the same schema.  This new prop=
osal
> >> >>>>>>>>>> solves
> >> >>>>>>>>>> the
> >> >>>>>>>>>> issue with different schemas in different instances.
> >> >>>>>>>>>>
> >> >>>>>>>>> I thought the previous proposals that as well, so don't =
see
> >> >>>>>>>>> material
> >> >>>>>>>>> difference - at least from the usage standpoint. I also =
don't see
> >> >>>>>>>>> why
> >> >>>>>>>>> the previous arguments that resulted in consensus for us=
ing Yang
> >> >>>>>>>>> Library underneath the an in line Mount Point don't appl=
y.
> >> >>>>>>>> B/c it doesn't work well with the NMDA.  You can't mount =
yang
> >> >>>>>>>> library
> >> >>>>>>>> in the configuration datastores; it has to be mounted in
> >> >>>>>>>> operational.
> >> >>>>>>>> With meta-data, you can actually report the correct schem=
a even in
> >> >>>>>>>> running.  (This is actually true also for pre-NMDA system=
s).
> >> >>>>>>>>
> >> >>>>>>> Understood and agree there is nothing new here and the cur=
rent
> >> >>>>>>> version
> >> >>>>>>> of SM (including inline) has the same limitation as rfc789=
5, and I'd
> >> >>>>>>> expect it to behave the same once we have rfc7985bis -- in=
 fact the
> >> >>>>>>> inline case "just works" with YL-bis as defined today.
> >> >>>>> Martin,
> >> >>>>>
> >> >>>>> you didn't respond to this point.
> >> >>>> I agree, it works for non-NMDA servers. But see below.
> >> >>>>
> >> >>>>>>> The argument I recall being the key point on inline was ha=
ndling the
> >> >>>>>>> large variety of possible different implementation approac=
hes for
> >> >>>>>>> modules using inline.
> >> >>>>>> I think these still are covered.
> >> >>>>>>
> >> >>>>>>> For example an LNE that is implemented using
> >> >>>>>>> VMs which can be managed by the host at different times of=
 the VMs
> >> >>>>>>> operational life cycle based on customer/provider requirem=
ents.=A0 I
> >> >>>>>>> really don't see how YL-bis has any bearing on this point =
and
> >> >>>>>> Using the new proposed meta data annotation together with t=
he new YL
> >> >>>>>> means that SM can support the use case above also in an NMD=
A server.
> >> >>>>>> I think the new proposed solution covers more use cases tha=
n the
> >> >>>>>> previous solution.
> >> >>>>> how so?=A0 The inline mount point would contain YL-bis and h=
ave the same
> >> >>>>> information there, just scoped for the mount point.=A0 It's =
true a
> >> >>>>> client would need to understand the mount point's schema onl=
y upon
> >> >>>>> parsing the YL under the mount point and this schema could n=
ot be
> >> >>>>> shared across inline mount points.=A0 But this is as was dis=
cussed in
> >> >>>>> the past and unchanged from YL.
> >> >>>>>
> >> >>>>>> Do you think that there is any use case that the proposed s=
olution
> >> >>>>>> cannot handle, but the previous solution did?
> >> >>>>> yes.=A0 with VM/container technologies the YL / schema can c=
hange under
> >> >>>>> the mount point from time to time during normal operation (i=
.e.,
> >> >>>>> during runtime, no reboot) and, in some implementations, may=
 require
> >> >>>>> some level of rpc operation to access even the schema.=A0 Th=
e new (and
> >> >>>>> previously proposed approach) of having inline schema availa=
ble from
> >> >>>>> the top level greatly complicates these cases.=A0 Also keep =
in mind that
> >> >>>>> there will be cases where the ability to access information =
under an
> >> >>>>> inline mount point will dynamically change in operation (and=
 top level
> >> >>>>> YL would need to remove schema information for the inline mo=
unt
> >> >>>>> point.)=A0 As before, from the usage standpoint, these chang=
es don't
> >> >>>>> provide a whole lot of value and seem to optimizing for some=
thing not
> >> >>>>> needed in the inline case.
> >> >>>> I think this is an implementation issue, rather than a proble=
m with
> >> >>>> the proposed mechanism, and it is present in the current solu=
tion as
> >> >>>> well.  An implementation that can handle dynamically changing=
 mounted
> >> >>>> YLs in the current solution can do that in the new solution a=
s well.
> >> >>>>
> >> >>>>>>> I think
> >> >>>>>>> it is incumbent upon those revisiting past/closed WG decis=
ions (in
> >> >>>>>>> this case, inline schema being represented by YL) to argue=
 why the
> >> >>>>>>> decision needs to be revisited.
> >> >>>>>> I'm repeating my self: b/c the current solution doesn't wor=
k well
> >> >>>>>> with
> >> >>>>>> the NMDA.
> >> >>>>> I simply don't understand how YL-bis works at the root node =
but
> >> >>>>> doesn't work equally at an inline mount point.=A0 Can you el=
aborate?
> >> >>>> With NMDA, a server may have one schema for the config datast=
ore and
> >> >>>> another one for operational (one is a superset of the other).=
  A
> >> >>>> mounted YL can only be present in operational.  Thus, there's=
 no way a
> >> >>>> client can learn the schema for config.
> >> >>> If the LNE mounted the full YL-bis at the mount point then you=
 would
> >> >>> have the list of datastores, and the schema associated with ea=
ch
> >> >>> datastore.=A0 Of course, this would only be available in opera=
tional,
> >> >>> but
> >> >>> that is the same as a regular server support YL-bis.
> >> >> exactly my point.
> >> > Yes, you're right.  But it requires the usage of YL-bis.
> >> >
> >> >>> I thought that the problem with the current solution and NMDA,=
 was
> >> >>> that
> >> >>> there is no way to find out what the LNE schema is if the LNE =
isn't
> >> >>> booted, and hence isn't providing .
> >> >> I've never heard anyone mention this issue/limitation.
> >> > This has been dicussed, but this does not change with the introd=
uction
> >> > of the meta annotation; if the server has off-line knowledge of =
the
> >> > instance's schema then it can populate an inline YL as well as t=
he
> >> > meta annotation and corresponding SM data.
> >> >
> >> >> My
> >> >> understanding of the previously raised objections were (a) that=
 the
> >> >> full schema can't be obtained by just reading the top level YL =
and (b)
> >> >> that when multiple inline mount points have the same schema the=

> >> >> information can't be combined using a shared schema approach as=
 is
> >> >> taken in base SM.
> >> > Right.  Both these issues are addressed by using a meta annotati=
on.
> >>
> >> But when we discussed this the last time having inline schema
> >> available at the top level (in the SM module), the general consens=
us
> >> was that having YL under inline was the preferred approach.
> >
> > What is new now is that we have an indirection; each instance has i=
ts
> > own pointer to the schema at the top level.  In the previous
> > discussion, having the schema at the top level implied that all
> > instances shared the same schema, and *that* was rejected.
> >
> =

> Indirection was possible at the previous time and is part of the
> current scheme Mount definition. Yes, you need to use different mount=

> points to reference different schema, but take a look at the ni
> document that's exactly what we are doing there. So I don't believe
> this is the point that caused the previous proposal to be rejected.
> =

> >> Lada
> >> stated that he didn't like the approach, but would go with the WG
> >> decision.=A0 Why are we reopening this closed discussion -- many m=
onths
> >> after we closed the issue?=A0 Most who contributed, notably users,=
 have
> >> moved from SM assuming it's a solved problem.
> >>
> >> At this point, I think the case needs to be made why the existing
> >> mechanisms in the draft are broken vs how they might be improved. =
My
> >> understanding is that there was one issue that could be clarified =
by
> >> the proposed text I included when restarting this discussion.
> >>
> >> What else is *broken* in the current draft?
> >
> > My main concern is actually the YL version.  I strongly think SM ne=
ed
> > to use YL-bis rather that the old YL, so that it can support NMDA.
> >
> =

> Right now to SM is independent of Yang Library version and can run
> with either.

No this is not correct.  SM uses a grouping from the old YANG
library (for the "use-schema" case), and talks about mounting
"modules-state" ("inline" case).

> I certainly would expect use of Yang Library bis and nmda
> to have advantages.
> =

> > The implementation effort for supporting the new YL in clients and
> > servers is minimal, esp. when compared to the efforts involved in
> > supporting SM.
> >
> > Adding an indirection is (for me) less important, but it has the
> > benefit of solving the two issues (a) and (b) above, and I haven't
> > seen any technical problem with it.
> >
> (A) has implementation implications and those participating in the
> discussion at the time expressed as not being worth the cost.
> I don't believe b was seen as a significant issue either.
> =

> > Do you have any technical concerns with using an annotation as an
> > indirection?
> >
> =

> The technicsl issue I have with the approaches the same one that was
> raised when debated previously, ie the implementation overhead of
> requiring inline schemas to be available at the top level.

Ok.  I'm ok with keeping the inline case as it is.  However, I think
we need to use the new YL-bis, so that we can support the NMDA.


/martin





> =

> From a process perspective, I don't think it's fair to those who
> provided input or contributed in the past in order to get scheme moun=
t
> to satisfy their requirements to reopen something that is not
> broken. Particularly because a number of those contributors are
> implementers and users who are now focused on other topics.
> =

> Lou
> =

> >
> > /martin
> >
> =

> =


From nobody Wed Jan 17 08:26: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 D385813149B for ; Wed, 17 Jan 2018 08:26:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 BlkDqjC8SVTr for ; Wed, 17 Jan 2018 08:26:23 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 BACF612D7EC for ; Wed, 17 Jan 2018 08:26:22 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id E169564AF1; Wed, 17 Jan 2018 17:26:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516206380; bh=VB7V8FKM1xCkrdfJXtnQJvIcBmKtMs8DNZAvBjCpBL4=; h=From:To:Date; b=d7fsbEjeptpDoQ4NyClpof9LUIeP7ZlRN+WZY6TNW10SZTnWLAaWDfV8QgIoIB+mP IzSZks0eHVZf5L2aPPDKIDpHX5ZI1O8S8uYswuQsK7s13KufhhmcMED9+ugQNlo9kA ShfP1tNOooSEZ5ZHB+up8kIoYB04eUetu/oqNG2Q=
Message-ID: <1516206380.1388.62.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 17:26:20 +0100
In-Reply-To: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net> <20180117.092002.464472752076487902.mbj@tail-f.com>  <20180117.154205.449528767667713089.mbj@tail-f.com> <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:26:26 -0000

On Wed, 2018-01-17 at 10:43 -0500, Lou Berger wrote:
> 
> On January 17, 2018 9:42:43 AM Martin Bjorklund  wrote:
> 
> > Lou Berger  wrote:
> > > 
> > > 
> > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > Lou Berger  wrote:
> > > > > 
> > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > Lou Berger  wrote:
> > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > No at all. The first and last time I proposed this
> > > > > > > > > > > > > > > was on 15
> > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/curre
> > > > > > > > > > > > > > > nt/msg19753.html
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > schema for inline
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > before that. I'm
> > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > previous proposals
> > > > > > > > > > > > > were basically variants on what is now "use-schema",
> > > > > > > > > > > > > which works
> > > > > > > > > > > > > fine
> > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > proposal solves
> > > > > > > > > > > > > the
> > > > > > > > > > > > > issue with different schemas in different instances.
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > I thought the previous proposals that as well, so don't
> > > > > > > > > > > > see material
> > > > > > > > > > > > difference - at least from the usage standpoint. I also
> > > > > > > > > > > > don't see why
> > > > > > > > > > > > the previous arguments that resulted in consensus for
> > > > > > > > > > > > using Yang
> > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > apply.
> > > > > > > > > > > 
> > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > yang library
> > > > > > > > > > > in the configuration datastores; it has to be mounted in
> > > > > > > > > > > operational.
> > > > > > > > > > > With meta-data, you can actually report the correct schema
> > > > > > > > > > > even in
> > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > systems).
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > current version
> > > > > > > > > > of SM (including inline) has the same limitation as rfc7895,
> > > > > > > > > > and I'd
> > > > > > > > > > expect it to behave the same once we have rfc7985bis -- in
> > > > > > > > > > fact the
> > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > 
> > > > > > > > Martin,
> > > > > > > > 
> > > > > > > > you didn't respond to this point.
> > > > > > > 
> > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > 
> > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > handling the
> > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > approaches for
> > > > > > > > > > modules using inline.
> > > > > > > > > 
> > > > > > > > > I think these still are covered.
> > > > > > > > > 
> > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > VMs which can be managed by the host at different times of
> > > > > > > > > > the VMs
> > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > requirements.  I
> > > > > > > > > > really don't see how YL-bis has any bearing on this point
> > > > > > > > > > and
> > > > > > > > > 
> > > > > > > > > Using the new proposed meta data annotation together with the
> > > > > > > > > new YL
> > > > > > > > > means that SM can support the use case above also in an NMDA
> > > > > > > > > server.
> > > > > > > > > I think the new proposed solution covers more use cases than
> > > > > > > > > the
> > > > > > > > > previous solution.
> > > > > > > > 
> > > > > > > > how so?  The inline mount point would contain YL-bis and have
> > > > > > > > the same
> > > > > > > > information there, just scoped for the mount point.  It's true a
> > > > > > > > client would need to understand the mount point's schema only
> > > > > > > > upon
> > > > > > > > parsing the YL under the mount point and this schema could not
> > > > > > > > be
> > > > > > > > shared across inline mount points.  But this is as was discussed
> > > > > > > > in
> > > > > > > > the past and unchanged from YL.
> > > > > > > > 
> > > > > > > > > Do you think that there is any use case that the proposed
> > > > > > > > > solution
> > > > > > > > > cannot handle, but the previous solution did?
> > > > > > > > 
> > > > > > > > yes.  with VM/container technologies the YL / schema can change
> > > > > > > > under
> > > > > > > > the mount point from time to time during normal operation (i.e.,
> > > > > > > > during runtime, no reboot) and, in some implementations, may
> > > > > > > > require
> > > > > > > > some level of rpc operation to access even the schema.  The new
> > > > > > > > (and
> > > > > > > > previously proposed approach) of having inline schema available
> > > > > > > > from
> > > > > > > > the top level greatly complicates these cases.  Also keep in
> > > > > > > > mind that
> > > > > > > > there will be cases where the ability to access information
> > > > > > > > under an
> > > > > > > > inline mount point will dynamically change in operation (and top
> > > > > > > > level
> > > > > > > > YL would need to remove schema information for the inline mount
> > > > > > > > point.)  As before, from the usage standpoint, these changes
> > > > > > > > don't
> > > > > > > > provide a whole lot of value and seem to optimizing for
> > > > > > > > something not
> > > > > > > > needed in the inline case.
> > > > > > > 
> > > > > > > I think this is an implementation issue, rather than a problem
> > > > > > > with
> > > > > > > the proposed mechanism, and it is present in the current solution
> > > > > > > as
> > > > > > > well.  An implementation that can handle dynamically changing
> > > > > > > mounted
> > > > > > > YLs in the current solution can do that in the new solution as
> > > > > > > well.
> > > > > > > 
> > > > > > > > > > I think
> > > > > > > > > > it is incumbent upon those revisiting past/closed WG
> > > > > > > > > > decisions (in
> > > > > > > > > > this case, inline schema being represented by YL) to argue
> > > > > > > > > > why the
> > > > > > > > > > decision needs to be revisited.
> > > > > > > > > 
> > > > > > > > > I'm repeating my self: b/c the current solution doesn't work
> > > > > > > > > well with
> > > > > > > > > the NMDA.
> > > > > > > > 
> > > > > > > > I simply don't understand how YL-bis works at the root node but
> > > > > > > > doesn't work equally at an inline mount point.  Can you
> > > > > > > > elaborate?
> > > > > > > 
> > > > > > > With NMDA, a server may have one schema for the config datastore
> > > > > > > and
> > > > > > > another one for operational (one is a superset of the other).  A
> > > > > > > mounted YL can only be present in operational.  Thus, there's no
> > > > > > > way a
> > > > > > > client can learn the schema for config.
> > > > > > 
> > > > > > If the LNE mounted the full YL-bis at the mount point then you would
> > > > > > have the list of datastores, and the schema associated with each
> > > > > > datastore.  Of course, this would only be available in operational,
> > > > > > but
> > > > > > that is the same as a regular server support YL-bis.
> > > > > 
> > > > > exactly my point.
> > > > 
> > > > Yes, you're right.  But it requires the usage of YL-bis.
> > > > 
> > > > > > I thought that the problem with the current solution and NMDA, was
> > > > > > that
> > > > > > there is no way to find out what the LNE schema is if the LNE isn't
> > > > > > booted, and hence isn't providing .
> > > > > 
> > > > > I've never heard anyone mention this issue/limitation.
> > > > 
> > > > This has been dicussed, but this does not change with the introduction
> > > > of the meta annotation; if the server has off-line knowledge of the
> > > > instance's schema then it can populate an inline YL as well as the
> > > > meta annotation and corresponding SM data.
> > > > 
> > > > > My
> > > > > understanding of the previously raised objections were (a) that the
> > > > > full schema can't be obtained by just reading the top level YL and (b)
> > > > > that when multiple inline mount points have the same schema the
> > > > > information can't be combined using a shared schema approach as is
> > > > > taken in base SM.
> > > > 
> > > > Right.  Both these issues are addressed by using a meta annotation.
> > > 
> > > But when we discussed this the last time having inline schema
> > > available at the top level (in the SM module), the general consensus
> > > was that having YL under inline was the preferred approach.
> > 
> > What is new now is that we have an indirection; each instance has its
> > own pointer to the schema at the top level.  In the previous
> > discussion, having the schema at the top level implied that all
> > instances shared the same schema, and *that* was rejected.
> > 
> 
> Indirection was possible at the previous time and is part of the current 
> scheme Mount definition. Yes, you need to use different mount points to 
> reference different schema, but take a look at the ni document that's 
> exactly what we are doing there. So I don't believe this is the point that

What Martin and I are talking about is a mount point that is a list node of the
"use-schema" type. There is no way how different entries of this list could have
different schemas.

The same applies to a container mount point that is inside a list. Then you can
also have multiple *instances* of the mount point, and with "use-schema" there
is no way how these instances could have different schemas.

Lada

>  
> caused the previous proposal to be rejected.
> 
> > > Lada
> > > stated that he didn't like the approach, but would go with the WG
> > > decision.  Why are we reopening this closed discussion -- many months
> > > after we closed the issue?  Most who contributed, notably users, have
> > > moved from SM assuming it's a solved problem.
> > > 
> > > At this point, I think the case needs to be made why the existing
> > > mechanisms in the draft are broken vs how they might be improved. My
> > > understanding is that there was one issue that could be clarified by
> > > the proposed text I included when restarting this discussion.
> > > 
> > > What else is *broken* in the current draft?
> > 
> > My main concern is actually the YL version.  I strongly think SM need
> > to use YL-bis rather that the old YL, so that it can support NMDA.
> > 
> 
> Right now to SM is independent of Yang Library version and can run with 
> either. I certainly would expect use of Yang Library bis and nmda to have 
> advantages.
> 
> > The implementation effort for supporting the new YL in clients and
> > servers is minimal, esp. when compared to the efforts involved in
> > supporting SM.
> > 
> > Adding an indirection is (for me) less important, but it has the
> > benefit of solving the two issues (a) and (b) above, and I haven't
> > seen any technical problem with it.
> > 
> 
> (A) has implementation implications and those participating in the 
> discussion at the time expressed as not being worth the cost.
> I don't believe b was seen as a significant issue either.
> 
> > Do you have any technical concerns with using an annotation as an
> > indirection?
> > 
> 
> The technicsl issue I have with the approaches the same one that was raised 
> when debated previously, ie the implementation overhead of requiring inline 
> schemas to be available at the top level.
> 
> > From a process perspective, I don't think it's fair to those who provided 
> 
> input or contributed in the past  in order to get scheme mount to satisfy 
> their requirements to reopen something that is not broken. Particularly 
> because a number of those contributors are implementers and users  who are 
> now focused on other topics.
> 
> Lou
> 
> > 
> > /martin
> > 
> 
> 
> _______________________________________________
> 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 Wed Jan 17 08:34: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 58C1D12D7F1 for ; Wed, 17 Jan 2018 08:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 5ItF74rHucw5 for ; Wed, 17 Jan 2018 08:34:36 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 47E6213149F for ; Wed, 17 Jan 2018 08:34:35 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id EE99B64AF3; Wed, 17 Jan 2018 17:34:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516206874; bh=/sFKiD+YiyTJO49QJFoKTCDO02FSaZaqZCO1NFDghvg=; h=From:To:Date; b=vHoHo+xzL+xGKTN5qBNVxDzhNYyiqDdQx1u37VUHkO+JtYjvCy+cT6s0MDp66M6bd iKgk1W5iVZLXSJuyqnnXEA+8moZ4d04VJlHKJuCk/Ojz4cvglQa3UthZ4whUm86C4a Md/04XbCpB52tvFx7yaIkwnoTxaaBSLBYzHmluaU=
Message-ID: <1516206873.1388.68.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund , lberger@labn.net
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 17:34:33 +0100
In-Reply-To: <20180117.171817.479473055872371790.mbj@tail-f.com>
References:  <20180117.154205.449528767667713089.mbj@tail-f.com> <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:34:38 -0000

On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> Lou Berger  wrote:
> > 
> > 
> > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > wrote:
> > 
> > > Lou Berger  wrote:
> > > > 
> > > > 
> > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > Lou Berger  wrote:
> > > > > > 
> > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > Lou Berger  wrote:
> > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > No at all. The first and last time I proposed
> > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/cur
> > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > were basically variants on what is now "use-schema", 
> > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > issue with different schemas in different instances.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > don't see
> > > > > > > > > > > > > material
> > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > why
> > > > > > > > > > > > > the previous arguments that resulted in consensus for
> > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > > apply.
> > > > > > > > > > > > 
> > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > > yang
> > > > > > > > > > > > library
> > > > > > > > > > > > in the configuration datastores; it has to be mounted in
> > > > > > > > > > > > operational.
> > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > schema even in
> > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > systems).
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > current
> > > > > > > > > > > version
> > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > expect it to behave the same once we have rfc7985bis -- in
> > > > > > > > > > > fact the
> > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > 
> > > > > > > > > Martin,
> > > > > > > > > 
> > > > > > > > > you didn't respond to this point.
> > > > > > > > 
> > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > 
> > > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > > handling the
> > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > approaches for
> > > > > > > > > > > modules using inline.
> > > > > > > > > > 
> > > > > > > > > > I think these still are covered.
> > > > > > > > > > 
> > > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > > VMs which can be managed by the host at different times of
> > > > > > > > > > > the VMs
> > > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > > requirements.  I
> > > > > > > > > > > really don't see how YL-bis has any bearing on this point
> > > > > > > > > > > and
> > > > > > > > > > 
> > > > > > > > > > Using the new proposed meta data annotation together with
> > > > > > > > > > the new YL
> > > > > > > > > > means that SM can support the use case above also in an NMDA
> > > > > > > > > > server.
> > > > > > > > > > I think the new proposed solution covers more use cases than
> > > > > > > > > > the
> > > > > > > > > > previous solution.
> > > > > > > > > 
> > > > > > > > > how so?  The inline mount point would contain YL-bis and have
> > > > > > > > > the same
> > > > > > > > > information there, just scoped for the mount point.  It's true
> > > > > > > > > a
> > > > > > > > > client would need to understand the mount point's schema only
> > > > > > > > > upon
> > > > > > > > > parsing the YL under the mount point and this schema could not
> > > > > > > > > be
> > > > > > > > > shared across inline mount points.  But this is as was
> > > > > > > > > discussed in
> > > > > > > > > the past and unchanged from YL.
> > > > > > > > > 
> > > > > > > > > > Do you think that there is any use case that the proposed
> > > > > > > > > > solution
> > > > > > > > > > cannot handle, but the previous solution did?
> > > > > > > > > 
> > > > > > > > > yes.  with VM/container technologies the YL / schema can
> > > > > > > > > change under
> > > > > > > > > the mount point from time to time during normal operation
> > > > > > > > > (i.e.,
> > > > > > > > > during runtime, no reboot) and, in some implementations, may
> > > > > > > > > require
> > > > > > > > > some level of rpc operation to access even the schema.  The
> > > > > > > > > new (and
> > > > > > > > > previously proposed approach) of having inline schema
> > > > > > > > > available from
> > > > > > > > > the top level greatly complicates these cases.  Also keep in
> > > > > > > > > mind that
> > > > > > > > > there will be cases where the ability to access information
> > > > > > > > > under an
> > > > > > > > > inline mount point will dynamically change in operation (and
> > > > > > > > > top level
> > > > > > > > > YL would need to remove schema information for the inline
> > > > > > > > > mount
> > > > > > > > > point.)  As before, from the usage standpoint, these changes
> > > > > > > > > don't
> > > > > > > > > provide a whole lot of value and seem to optimizing for
> > > > > > > > > something not
> > > > > > > > > needed in the inline case.
> > > > > > > > 
> > > > > > > > I think this is an implementation issue, rather than a problem
> > > > > > > > with
> > > > > > > > the proposed mechanism, and it is present in the current
> > > > > > > > solution as
> > > > > > > > well.  An implementation that can handle dynamically changing
> > > > > > > > mounted
> > > > > > > > YLs in the current solution can do that in the new solution as
> > > > > > > > well.
> > > > > > > > 
> > > > > > > > > > > I think
> > > > > > > > > > > it is incumbent upon those revisiting past/closed WG
> > > > > > > > > > > decisions (in
> > > > > > > > > > > this case, inline schema being represented by YL) to argue
> > > > > > > > > > > why the
> > > > > > > > > > > decision needs to be revisited.
> > > > > > > > > > 
> > > > > > > > > > I'm repeating my self: b/c the current solution doesn't work
> > > > > > > > > > well
> > > > > > > > > > with
> > > > > > > > > > the NMDA.
> > > > > > > > > 
> > > > > > > > > I simply don't understand how YL-bis works at the root node
> > > > > > > > > but
> > > > > > > > > doesn't work equally at an inline mount point.  Can you
> > > > > > > > > elaborate?
> > > > > > > > 
> > > > > > > > With NMDA, a server may have one schema for the config datastore
> > > > > > > > and
> > > > > > > > another one for operational (one is a superset of the other).  A
> > > > > > > > mounted YL can only be present in operational.  Thus, there's no
> > > > > > > > way a
> > > > > > > > client can learn the schema for config.
> > > > > > > 
> > > > > > > If the LNE mounted the full YL-bis at the mount point then you
> > > > > > > would
> > > > > > > have the list of datastores, and the schema associated with each
> > > > > > > datastore.  Of course, this would only be available in
> > > > > > > operational,
> > > > > > > but
> > > > > > > that is the same as a regular server support YL-bis.
> > > > > > 
> > > > > > exactly my point.
> > > > > 
> > > > > Yes, you're right.  But it requires the usage of YL-bis.
> > > > > 
> > > > > > > I thought that the problem with the current solution and NMDA, was
> > > > > > > that
> > > > > > > there is no way to find out what the LNE schema is if the LNE
> > > > > > > isn't
> > > > > > > booted, and hence isn't providing .
> > > > > > 
> > > > > > I've never heard anyone mention this issue/limitation.
> > > > > 
> > > > > This has been dicussed, but this does not change with the introduction
> > > > > of the meta annotation; if the server has off-line knowledge of the
> > > > > instance's schema then it can populate an inline YL as well as the
> > > > > meta annotation and corresponding SM data.
> > > > > 
> > > > > > My
> > > > > > understanding of the previously raised objections were (a) that the
> > > > > > full schema can't be obtained by just reading the top level YL and
> > > > > > (b)
> > > > > > that when multiple inline mount points have the same schema the
> > > > > > information can't be combined using a shared schema approach as is
> > > > > > taken in base SM.
> > > > > 
> > > > > Right.  Both these issues are addressed by using a meta annotation.
> > > > 
> > > > But when we discussed this the last time having inline schema
> > > > available at the top level (in the SM module), the general consensus
> > > > was that having YL under inline was the preferred approach.
> > > 
> > > What is new now is that we have an indirection; each instance has its
> > > own pointer to the schema at the top level.  In the previous
> > > discussion, having the schema at the top level implied that all
> > > instances shared the same schema, and *that* was rejected.
> > > 
> > 
> > Indirection was possible at the previous time and is part of the
> > current scheme Mount definition. Yes, you need to use different mount
> > points to reference different schema, but take a look at the ni
> > document that's exactly what we are doing there. So I don't believe
> > this is the point that caused the previous proposal to be rejected.
> > 
> > > > Lada
> > > > stated that he didn't like the approach, but would go with the WG
> > > > decision.  Why are we reopening this closed discussion -- many months
> > > > after we closed the issue?  Most who contributed, notably users, have
> > > > moved from SM assuming it's a solved problem.
> > > > 
> > > > At this point, I think the case needs to be made why the existing
> > > > mechanisms in the draft are broken vs how they might be improved. My
> > > > understanding is that there was one issue that could be clarified by
> > > > the proposed text I included when restarting this discussion.
> > > > 
> > > > What else is *broken* in the current draft?
> > > 
> > > My main concern is actually the YL version.  I strongly think SM need
> > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > 
> > 
> > Right now to SM is independent of Yang Library version and can run
> > with either.
> 
> No this is not correct.  SM uses a grouping from the old YANG
> library (for the "use-schema" case), and talks about mounting
> "modules-state" ("inline" case).
> 
> > I certainly would expect use of Yang Library bis and nmda
> > to have advantages.
> > 
> > > The implementation effort for supporting the new YL in clients and
> > > servers is minimal, esp. when compared to the efforts involved in
> > > supporting SM.
> > > 
> > > Adding an indirection is (for me) less important, but it has the
> > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > seen any technical problem with it.
> > > 
> > 
> > (A) has implementation implications and those participating in the
> > discussion at the time expressed as not being worth the cost.
> > I don't believe b was seen as a significant issue either.
> > 
> > > Do you have any technical concerns with using an annotation as an
> > > indirection?
> > > 
> > 
> > The technicsl issue I have with the approaches the same one that was
> > raised when debated previously, ie the implementation overhead of
> > requiring inline schemas to be available at the top level.

Could you specify where this overhead comes from? Does it matter whether you
place some data inside the data tree or somewhere at the top level and point to
it from inside the tree?

> 
> Ok.  I'm ok with keeping the inline case as it is.  However, I think

I don't agree. The metadata annotation solves real issues.

Lada

> we need to use the new YL-bis, so that we can support the NMDA.
> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > From a process perspective, I don't think it's fair to those who
> > provided input or contributed in the past in order to get scheme mount
> > to satisfy their requirements to reopen something that is not
> > broken. Particularly because a number of those contributors are
> > implementers and users who are now focused on other topics.
> > 
> > Lou
> > 
> > > 
> > > /martin
> > > 
> > 
> > 
> 
> _______________________________________________
> 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 Wed Jan 17 08:40:45 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 D409612D837 for ; Wed, 17 Jan 2018 08:40:43 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vTZn6lHwYAvH for ; Wed, 17 Jan 2018 08:40:40 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7701612D7F1 for ; Wed, 17 Jan 2018 08:40:40 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id B4A651AE0428; Wed, 17 Jan 2018 17:40:39 +0100 (CET)
Date: Wed, 17 Jan 2018 17:40:39 +0100 (CET)
Message-Id: <20180117.174039.2105430212248651483.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1516206873.1388.68.camel@nic.cz>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:40:44 -0000

Ladislav Lhotka  wrote:
> On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> > > 
> > > 
> > > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > > wrote:
> > > 
> > > > Lou Berger  wrote:
> > > > > 
> > > > > 
> > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > > Lou Berger  wrote:
> > > > > > > 
> > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > > Lou Berger  wrote:
> > > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > > rejectected by the WG multiple times.  FWIW
> > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > No at all. The first and last time I proposed
> > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/cur
> > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > > were basically variants on what is now "use-schema", 
> > > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > issue with different schemas in different instances.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > > don't see
> > > > > > > > > > > > > > material
> > > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > > why
> > > > > > > > > > > > > > the previous arguments that resulted in consensus for
> > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > Library underneath the an in line Mount Point don't
> > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > > > yang
> > > > > > > > > > > > > library
> > > > > > > > > > > > > in the configuration datastores; it has to be mounted in
> > > > > > > > > > > > > operational.
> > > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > > schema even in
> > > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > > systems).
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > > current
> > > > > > > > > > > > version
> > > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > > expect it to behave the same once we have rfc7985bis -- in
> > > > > > > > > > > > fact the
> > > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > > 
> > > > > > > > > > Martin,
> > > > > > > > > > 
> > > > > > > > > > you didn't respond to this point.
> > > > > > > > > 
> > > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > > 
> > > > > > > > > > > > The argument I recall being the key point on inline was
> > > > > > > > > > > > handling the
> > > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > > approaches for
> > > > > > > > > > > > modules using inline.
> > > > > > > > > > > 
> > > > > > > > > > > I think these still are covered.
> > > > > > > > > > > 
> > > > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > > > VMs which can be managed by the host at different times of
> > > > > > > > > > > > the VMs
> > > > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > > > requirements.  I
> > > > > > > > > > > > really don't see how YL-bis has any bearing on this point
> > > > > > > > > > > > and
> > > > > > > > > > > 
> > > > > > > > > > > Using the new proposed meta data annotation together with
> > > > > > > > > > > the new YL
> > > > > > > > > > > means that SM can support the use case above also in an NMDA
> > > > > > > > > > > server.
> > > > > > > > > > > I think the new proposed solution covers more use cases than
> > > > > > > > > > > the
> > > > > > > > > > > previous solution.
> > > > > > > > > > 
> > > > > > > > > > how so?  The inline mount point would contain YL-bis and have
> > > > > > > > > > the same
> > > > > > > > > > information there, just scoped for the mount point.  It's true
> > > > > > > > > > a
> > > > > > > > > > client would need to understand the mount point's schema only
> > > > > > > > > > upon
> > > > > > > > > > parsing the YL under the mount point and this schema could not
> > > > > > > > > > be
> > > > > > > > > > shared across inline mount points.  But this is as was
> > > > > > > > > > discussed in
> > > > > > > > > > the past and unchanged from YL.
> > > > > > > > > > 
> > > > > > > > > > > Do you think that there is any use case that the proposed
> > > > > > > > > > > solution
> > > > > > > > > > > cannot handle, but the previous solution did?
> > > > > > > > > > 
> > > > > > > > > > yes.  with VM/container technologies the YL / schema can
> > > > > > > > > > change under
> > > > > > > > > > the mount point from time to time during normal operation
> > > > > > > > > > (i.e.,
> > > > > > > > > > during runtime, no reboot) and, in some implementations, may
> > > > > > > > > > require
> > > > > > > > > > some level of rpc operation to access even the schema.  The
> > > > > > > > > > new (and
> > > > > > > > > > previously proposed approach) of having inline schema
> > > > > > > > > > available from
> > > > > > > > > > the top level greatly complicates these cases.  Also keep in
> > > > > > > > > > mind that
> > > > > > > > > > there will be cases where the ability to access information
> > > > > > > > > > under an
> > > > > > > > > > inline mount point will dynamically change in operation (and
> > > > > > > > > > top level
> > > > > > > > > > YL would need to remove schema information for the inline
> > > > > > > > > > mount
> > > > > > > > > > point.)  As before, from the usage standpoint, these changes
> > > > > > > > > > don't
> > > > > > > > > > provide a whole lot of value and seem to optimizing for
> > > > > > > > > > something not
> > > > > > > > > > needed in the inline case.
> > > > > > > > > 
> > > > > > > > > I think this is an implementation issue, rather than a problem
> > > > > > > > > with
> > > > > > > > > the proposed mechanism, and it is present in the current
> > > > > > > > > solution as
> > > > > > > > > well.  An implementation that can handle dynamically changing
> > > > > > > > > mounted
> > > > > > > > > YLs in the current solution can do that in the new solution as
> > > > > > > > > well.
> > > > > > > > > 
> > > > > > > > > > > > I think
> > > > > > > > > > > > it is incumbent upon those revisiting past/closed WG
> > > > > > > > > > > > decisions (in
> > > > > > > > > > > > this case, inline schema being represented by YL) to argue
> > > > > > > > > > > > why the
> > > > > > > > > > > > decision needs to be revisited.
> > > > > > > > > > > 
> > > > > > > > > > > I'm repeating my self: b/c the current solution doesn't work
> > > > > > > > > > > well
> > > > > > > > > > > with
> > > > > > > > > > > the NMDA.
> > > > > > > > > > 
> > > > > > > > > > I simply don't understand how YL-bis works at the root node
> > > > > > > > > > but
> > > > > > > > > > doesn't work equally at an inline mount point.  Can you
> > > > > > > > > > elaborate?
> > > > > > > > > 
> > > > > > > > > With NMDA, a server may have one schema for the config datastore
> > > > > > > > > and
> > > > > > > > > another one for operational (one is a superset of the other).  A
> > > > > > > > > mounted YL can only be present in operational.  Thus, there's no
> > > > > > > > > way a
> > > > > > > > > client can learn the schema for config.
> > > > > > > > 
> > > > > > > > If the LNE mounted the full YL-bis at the mount point then you
> > > > > > > > would
> > > > > > > > have the list of datastores, and the schema associated with each
> > > > > > > > datastore.  Of course, this would only be available in
> > > > > > > > operational,
> > > > > > > > but
> > > > > > > > that is the same as a regular server support YL-bis.
> > > > > > > 
> > > > > > > exactly my point.
> > > > > > 
> > > > > > Yes, you're right.  But it requires the usage of YL-bis.
> > > > > > 
> > > > > > > > I thought that the problem with the current solution and NMDA, was
> > > > > > > > that
> > > > > > > > there is no way to find out what the LNE schema is if the LNE
> > > > > > > > isn't
> > > > > > > > booted, and hence isn't providing .
> > > > > > > 
> > > > > > > I've never heard anyone mention this issue/limitation.
> > > > > > 
> > > > > > This has been dicussed, but this does not change with the introduction
> > > > > > of the meta annotation; if the server has off-line knowledge of the
> > > > > > instance's schema then it can populate an inline YL as well as the
> > > > > > meta annotation and corresponding SM data.
> > > > > > 
> > > > > > > My
> > > > > > > understanding of the previously raised objections were (a) that the
> > > > > > > full schema can't be obtained by just reading the top level YL and
> > > > > > > (b)
> > > > > > > that when multiple inline mount points have the same schema the
> > > > > > > information can't be combined using a shared schema approach as is
> > > > > > > taken in base SM.
> > > > > > 
> > > > > > Right.  Both these issues are addressed by using a meta annotation.
> > > > > 
> > > > > But when we discussed this the last time having inline schema
> > > > > available at the top level (in the SM module), the general consensus
> > > > > was that having YL under inline was the preferred approach.
> > > > 
> > > > What is new now is that we have an indirection; each instance has its
> > > > own pointer to the schema at the top level.  In the previous
> > > > discussion, having the schema at the top level implied that all
> > > > instances shared the same schema, and *that* was rejected.
> > > > 
> > > 
> > > Indirection was possible at the previous time and is part of the
> > > current scheme Mount definition. Yes, you need to use different mount
> > > points to reference different schema, but take a look at the ni
> > > document that's exactly what we are doing there. So I don't believe
> > > this is the point that caused the previous proposal to be rejected.
> > > 
> > > > > Lada
> > > > > stated that he didn't like the approach, but would go with the WG
> > > > > decision.  Why are we reopening this closed discussion -- many months
> > > > > after we closed the issue?  Most who contributed, notably users, have
> > > > > moved from SM assuming it's a solved problem.
> > > > > 
> > > > > At this point, I think the case needs to be made why the existing
> > > > > mechanisms in the draft are broken vs how they might be improved. My
> > > > > understanding is that there was one issue that could be clarified by
> > > > > the proposed text I included when restarting this discussion.
> > > > > 
> > > > > What else is *broken* in the current draft?
> > > > 
> > > > My main concern is actually the YL version.  I strongly think SM need
> > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > 
> > > 
> > > Right now to SM is independent of Yang Library version and can run
> > > with either.
> > 
> > No this is not correct.  SM uses a grouping from the old YANG
> > library (for the "use-schema" case), and talks about mounting
> > "modules-state" ("inline" case).
> > 
> > > I certainly would expect use of Yang Library bis and nmda
> > > to have advantages.
> > > 
> > > > The implementation effort for supporting the new YL in clients and
> > > > servers is minimal, esp. when compared to the efforts involved in
> > > > supporting SM.
> > > > 
> > > > Adding an indirection is (for me) less important, but it has the
> > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > seen any technical problem with it.
> > > > 
> > > 
> > > (A) has implementation implications and those participating in the
> > > discussion at the time expressed as not being worth the cost.
> > > I don't believe b was seen as a significant issue either.
> > > 
> > > > Do you have any technical concerns with using an annotation as an
> > > > indirection?
> > > > 
> > > 
> > > The technicsl issue I have with the approaches the same one that was
> > > raised when debated previously, ie the implementation overhead of
> > > requiring inline schemas to be available at the top level.
> 
> Could you specify where this overhead comes from? Does it matter whether you
> place some data inside the data tree or somewhere at the top level and point to
> it from inside the tree?
> 
> > 
> > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> 
> I don't agree. The metadata annotation solves real issues.

One issue with the annotation is that since the schema might be
different in different datastores, it means that the client needs to
read the annotation in all datastores, and then fetch the schemas.  So
it is a bit more difficult to work with for a client.


/martin



> 
> Lada
> 
> > we need to use the new YL-bis, so that we can support the NMDA.
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > 
> > > 
> > > From a process perspective, I don't think it's fair to those who
> > > provided input or contributed in the past in order to get scheme mount
> > > to satisfy their requirements to reopen something that is not
> > > broken. Particularly because a number of those contributors are
> > > implementers and users who are now focused on other topics.
> > > 
> > > Lou
> > > 
> > > > 
> > > > /martin
> > > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > 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 Wed Jan 17 08:57: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 3E0DD124235 for ; Wed, 17 Jan 2018 08:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 N50yKLTw9eM4 for ; Wed, 17 Jan 2018 08:57:49 -0800 (PST)
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 2529A1204DA for ; Wed, 17 Jan 2018 08:57:48 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id AA1CA64A3A; Wed, 17 Jan 2018 17:57:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516208266; bh=D2iH3yvXhQ0Yk7GeHZmnsx4dwxe7Jg/xwd6B5lYc82Q=; h=From:To:Date; b=U4h7/m39ME+O1DPhJAmCpenhyTdM8jY89YWAmAxpDQHtG5qaCPq2nNDnThgyY6P/e /RlY1NAwipCOz/oNWLGsZiNJ7G9mGWF8yzXp2qhSK/e2PoS3hXi3FQgFCBI4209Mfc XAGh2ZArgY4EOh1vQuzdNjtR/BM5xU9qV04PDkps=
Message-ID: <1516208266.1388.80.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: lberger@labn.net, netmod@ietf.org
Date: Wed, 17 Jan 2018 17:57:46 +0100
In-Reply-To: <20180117.174039.2105430212248651483.mbj@tail-f.com>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:57:55 -0000

On Wed, 2018-01-17 at 17:40 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > > Lou Berger  wrote:
> > > > 
> > > > 
> > > > On January 17, 2018 9:42:43 AM Martin Bjorklund 
> > > > wrote:
> > > > 
> > > > > Lou Berger  wrote:
> > > > > > 
> > > > > > 
> > > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > > > Lou Berger  wrote:
> > > > > > > > 
> > > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > > > Lou Berger  wrote:
> > > > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > > > rejectected by the WG multiple times. 
> FWIW
> > > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > No at all. The first and last time I
> proposed
> > > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod
> /cur
> > > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that
> the
> > > > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > part of the rest of the schema Mount module
> well
> > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > I can dig up mail / slides it really
> necessary...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I don't think this has been proposed before. 
> All
> > > > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > > > were basically variants on what is now "use-
> schema", 
> > > > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > > when all instances have the same schema.  This
> new
> > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > issue with different schemas in different
> instances.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > > > don't see
> > > > > > > > > > > > > > > material
> > > > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > > > why
> > > > > > > > > > > > > > > the previous arguments that resulted in consensus
> for
> > > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > > Library underneath the an in line Mount Point
> don't
> > > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't
> mount
> > > > > > > > > > > > > > yang
> > > > > > > > > > > > > > library
> > > > > > > > > > > > > > in the configuration datastores; it has to be
> mounted in
> > > > > > > > > > > > > > operational.
> > > > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > > > schema even in
> > > > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > > > systems).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > version
> > > > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > > > expect it to behave the same once we have rfc7985bis
> -- in
> > > > > > > > > > > > > fact the
> > > > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > > > 
> > > > > > > > > > > Martin,
> > > > > > > > > > > 
> > > > > > > > > > > you didn't respond to this point.
> > > > > > > > > > 
> > > > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > > > 
> > > > > > > > > > > > > The argument I recall being the key point on inline
> was
> > > > > > > > > > > > > handling the
> > > > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > > > approaches for
> > > > > > > > > > > > > modules using inline.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think these still are covered.
> > > > > > > > > > > > 
> > > > > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > > > > VMs which can be managed by the host at different
> times of
> > > > > > > > > > > > > the VMs
> > > > > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > > > > requirements.  I
> > > > > > > > > > > > > really don't see how YL-bis has any bearing on this
> point
> > > > > > > > > > > > > and
> > > > > > > > > > > > 
> > > > > > > > > > > > Using the new proposed meta data annotation together
> with
> > > > > > > > > > > > the new YL
> > > > > > > > > > > > means that SM can support the use case above also in an
> NMDA
> > > > > > > > > > > > server.
> > > > > > > > > > > > I think the new proposed solution covers more use cases
> than
> > > > > > > > > > > > the
> > > > > > > > > > > > previous solution.
> > > > > > > > > > > 
> > > > > > > > > > > how so?  The inline mount point would contain YL-bis and
> have
> > > > > > > > > > > the same
> > > > > > > > > > > information there, just scoped for the mount point.  It's
> true
> > > > > > > > > > > a
> > > > > > > > > > > client would need to understand the mount point's schema
> only
> > > > > > > > > > > upon
> > > > > > > > > > > parsing the YL under the mount point and this schema could
> not
> > > > > > > > > > > be
> > > > > > > > > > > shared across inline mount points.  But this is as was
> > > > > > > > > > > discussed in
> > > > > > > > > > > the past and unchanged from YL.
> > > > > > > > > > > 
> > > > > > > > > > > > Do you think that there is any use case that the
> proposed
> > > > > > > > > > > > solution
> > > > > > > > > > > > cannot handle, but the previous solution did?
> > > > > > > > > > > 
> > > > > > > > > > > yes.  with VM/container technologies the YL / schema can
> > > > > > > > > > > change under
> > > > > > > > > > > the mount point from time to time during normal operation
> > > > > > > > > > > (i.e.,
> > > > > > > > > > > during runtime, no reboot) and, in some implementations,
> may
> > > > > > > > > > > require
> > > > > > > > > > > some level of rpc operation to access even the schema. 
> The
> > > > > > > > > > > new (and
> > > > > > > > > > > previously proposed approach) of having inline schema
> > > > > > > > > > > available from
> > > > > > > > > > > the top level greatly complicates these cases.  Also keep
> in
> > > > > > > > > > > mind that
> > > > > > > > > > > there will be cases where the ability to access
> information
> > > > > > > > > > > under an
> > > > > > > > > > > inline mount point will dynamically change in operation
> (and
> > > > > > > > > > > top level
> > > > > > > > > > > YL would need to remove schema information for the inline
> > > > > > > > > > > mount
> > > > > > > > > > > point.)  As before, from the usage standpoint, these
> changes
> > > > > > > > > > > don't
> > > > > > > > > > > provide a whole lot of value and seem to optimizing for
> > > > > > > > > > > something not
> > > > > > > > > > > needed in the inline case.
> > > > > > > > > > 
> > > > > > > > > > I think this is an implementation issue, rather than a
> problem
> > > > > > > > > > with
> > > > > > > > > > the proposed mechanism, and it is present in the current
> > > > > > > > > > solution as
> > > > > > > > > > well.  An implementation that can handle dynamically
> changing
> > > > > > > > > > mounted
> > > > > > > > > > YLs in the current solution can do that in the new solution
> as
> > > > > > > > > > well.
> > > > > > > > > > 
> > > > > > > > > > > > > I think
> > > > > > > > > > > > > it is incumbent upon those revisiting past/closed WG
> > > > > > > > > > > > > decisions (in
> > > > > > > > > > > > > this case, inline schema being represented by YL) to
> argue
> > > > > > > > > > > > > why the
> > > > > > > > > > > > > decision needs to be revisited.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm repeating my self: b/c the current solution doesn't
> work
> > > > > > > > > > > > well
> > > > > > > > > > > > with
> > > > > > > > > > > > the NMDA.
> > > > > > > > > > > 
> > > > > > > > > > > I simply don't understand how YL-bis works at the root
> node
> > > > > > > > > > > but
> > > > > > > > > > > doesn't work equally at an inline mount point.  Can you
> > > > > > > > > > > elaborate?
> > > > > > > > > > 
> > > > > > > > > > With NMDA, a server may have one schema for the config
> datastore
> > > > > > > > > > and
> > > > > > > > > > another one for operational (one is a superset of the
> other).  A
> > > > > > > > > > mounted YL can only be present in operational.  Thus,
> there's no
> > > > > > > > > > way a
> > > > > > > > > > client can learn the schema for config.
> > > > > > > > > 
> > > > > > > > > If the LNE mounted the full YL-bis at the mount point then you
> > > > > > > > > would
> > > > > > > > > have the list of datastores, and the schema associated with
> each
> > > > > > > > > datastore.  Of course, this would only be available in
> > > > > > > > > operational,
> > > > > > > > > but
> > > > > > > > > that is the same as a regular server support YL-bis.
> > > > > > > > 
> > > > > > > > exactly my point.
> > > > > > > 
> > > > > > > Yes, you're right.  But it requires the usage of YL-bis.
> > > > > > > 
> > > > > > > > > I thought that the problem with the current solution and NMDA,
> was
> > > > > > > > > that
> > > > > > > > > there is no way to find out what the LNE schema is if the LNE
> > > > > > > > > isn't
> > > > > > > > > booted, and hence isn't providing .
> > > > > > > > 
> > > > > > > > I've never heard anyone mention this issue/limitation.
> > > > > > > 
> > > > > > > This has been dicussed, but this does not change with the
> introduction
> > > > > > > of the meta annotation; if the server has off-line knowledge of
> the
> > > > > > > instance's schema then it can populate an inline YL as well as the
> > > > > > > meta annotation and corresponding SM data.
> > > > > > > 
> > > > > > > > My
> > > > > > > > understanding of the previously raised objections were (a) that
> the
> > > > > > > > full schema can't be obtained by just reading the top level YL
> and
> > > > > > > > (b)
> > > > > > > > that when multiple inline mount points have the same schema the
> > > > > > > > information can't be combined using a shared schema approach as
> is
> > > > > > > > taken in base SM.
> > > > > > > 
> > > > > > > Right.  Both these issues are addressed by using a meta
> annotation.
> > > > > > 
> > > > > > But when we discussed this the last time having inline schema
> > > > > > available at the top level (in the SM module), the general consensus
> > > > > > was that having YL under inline was the preferred approach.
> > > > > 
> > > > > What is new now is that we have an indirection; each instance has its
> > > > > own pointer to the schema at the top level.  In the previous
> > > > > discussion, having the schema at the top level implied that all
> > > > > instances shared the same schema, and *that* was rejected.
> > > > > 
> > > > 
> > > > Indirection was possible at the previous time and is part of the
> > > > current scheme Mount definition. Yes, you need to use different mount
> > > > points to reference different schema, but take a look at the ni
> > > > document that's exactly what we are doing there. So I don't believe
> > > > this is the point that caused the previous proposal to be rejected.
> > > > 
> > > > > > Lada
> > > > > > stated that he didn't like the approach, but would go with the WG
> > > > > > decision.  Why are we reopening this closed discussion -- many
> months
> > > > > > after we closed the issue?  Most who contributed, notably users,
> have
> > > > > > moved from SM assuming it's a solved problem.
> > > > > > 
> > > > > > At this point, I think the case needs to be made why the existing
> > > > > > mechanisms in the draft are broken vs how they might be improved. My
> > > > > > understanding is that there was one issue that could be clarified by
> > > > > > the proposed text I included when restarting this discussion.
> > > > > > 
> > > > > > What else is *broken* in the current draft?
> > > > > 
> > > > > My main concern is actually the YL version.  I strongly think SM need
> > > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > > 
> > > > 
> > > > Right now to SM is independent of Yang Library version and can run
> > > > with either.
> > > 
> > > No this is not correct.  SM uses a grouping from the old YANG
> > > library (for the "use-schema" case), and talks about mounting
> > > "modules-state" ("inline" case).
> > > 
> > > > I certainly would expect use of Yang Library bis and nmda
> > > > to have advantages.
> > > > 
> > > > > The implementation effort for supporting the new YL in clients and
> > > > > servers is minimal, esp. when compared to the efforts involved in
> > > > > supporting SM.
> > > > > 
> > > > > Adding an indirection is (for me) less important, but it has the
> > > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > > seen any technical problem with it.
> > > > > 
> > > > 
> > > > (A) has implementation implications and those participating in the
> > > > discussion at the time expressed as not being worth the cost.
> > > > I don't believe b was seen as a significant issue either.
> > > > 
> > > > > Do you have any technical concerns with using an annotation as an
> > > > > indirection?
> > > > > 
> > > > 
> > > > The technicsl issue I have with the approaches the same one that was
> > > > raised when debated previously, ie the implementation overhead of
> > > > requiring inline schemas to be available at the top level.
> > 
> > Could you specify where this overhead comes from? Does it matter whether you
> > place some data inside the data tree or somewhere at the top level and point
> to
> > it from inside the tree?
> > 
> > > 
> > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > 
> > I don't agree. The metadata annotation solves real issues.
> 
> One issue with the annotation is that since the schema might be
> different in different datastores, it means that the client needs to
> read the annotation in all datastores, and then fetch the schemas.  So
> it is a bit more difficult to work with for a client.

But it doesn't mean that the schemas *must* be different, and it is easy to
figure out when they are the same. Also, modules sets in YLbis can further help
avoid redundant parsing of the same modules.

Lada

> 
> 
> /martin
> 
> 
> 
> > 
> > Lada
> > 
> > > we need to use the new YL-bis, so that we can support the NMDA.
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > From a process perspective, I don't think it's fair to those who
> > > > provided input or contributed in the past in order to get scheme mount
> > > > to satisfy their requirements to reopen something that is not
> > > > broken. Particularly because a number of those contributors are
> > > > implementers and users who are now focused on other topics.
> > > > 
> > > > Lou
> > > > 
> > > > > 
> > > > > /martin
> > > > > 
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 17 08:58:36 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 4D9D412D9FE for ; Wed, 17 Jan 2018 08:58:33 -0800 (PST)
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 X0YUPCWZSrzB for ; Wed, 17 Jan 2018 08:58:30 -0800 (PST)
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 CF8601204DA for ; Wed, 17 Jan 2018 08:58:30 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0HGXevQ007042 for ; Wed, 17 Jan 2018 08:35:15 -0800
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=kHJOfrIBxn1Ko4riRwQ9Tf7amaeYEO+WUxGUNM7mda8=; b=q9RHaZ1eWrZR+znHqjghz+4SUvq47+Nbfj5JyPzx1OOEqXGBwus4mJPqA+DDNnu/sa2T LB2m+yzu1C5Ud2eRpaCRfwhCLEimxBZsknoTZzR3RctMr1RZA6wkoEUBDLINy9DUT2Yl mVOsB1PXZqTLigfX8yn/9RhEuRd74FLD+Nebe743HdDVNPJY8pAKr+PsYS9XbCi3aA1V +NYKZM1MIOjsiRVWix1m5osVMnEsBWqn+q9AFAHA21IYdI2Dc9zLqAO8IJB9Ibri8tgN 0uSzxaNQIYqWIaYLMYglH9w/QcV66rZNbFaVXCAn+x14qADF+mSdvNN/KGADUWefsfFc eQ== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0b-00273201.pphosted.com with ESMTP id 2fja44g049-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 17 Jan 2018 08:35:14 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3242.namprd05.prod.outlook.com (10.173.220.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 16:35:12 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 16:35:12 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
Thread-Index: AQHTi/jgm64n1kE5c0S5iq2VpQaBSqN2at0AgAGLqQA=
Date: Wed, 17 Jan 2018 16:35:12 +0000
Message-ID: <90BE8219-327C-42E9-B391-53E862F33D17@juniper.net>
References: <151579789446.21777.985631371557420470@ietfa.amsl.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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3242; 7:T3o8m5ZM3xc005hYmlHRaPSQrRjSLU/tFSzeN9A7EQTeZRl30BmhVqBZVyYzZI9OXnhcRsAXf+ZFETa3Xj/PK/cLAtytJQpGIhuRat83k05OlQ7PNTlS8Nrc4AbSzJLhzcu2tr1hLZu8H2DQBz+cREQPpFBSzDZNmKSKrRKDurCR+TAVhXTa8cNuYfGyMRlABwGvdHnnniPbHX7QfEuYsoOqAH5gvirFHbpaOLQp9RyBAUlg6BJhUheqwnwNibWY
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6ed0fc78-8de7-4eee-c149-08d55dc847ec
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3242; 
x-ms-traffictypediagnostic: DM5PR05MB3242:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(209352067349851)(192374486261705); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(944501161)(6055026)(6041268)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3242; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3242; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(39380400002)(366004)(189003)(199004)(2900100001)(5660300001)(86362001)(2950100002)(575784001)(305945005)(966005)(14454004)(2906002)(68736007)(58126008)(478600001)(3660700001)(8676002)(316002)(26005)(1730700003)(81166006)(81156014)(3280700002)(83716003)(8936002)(6506007)(229853002)(102836004)(230783001)(59450400001)(6246003)(6486002)(77096006)(82746002)(2351001)(6436002)(25786009)(6916009)(2501003)(6306002)(76176011)(99286004)(6512007)(53936002)(33656002)(3846002)(7736002)(83506002)(6116002)(66066001)(36756003)(97736004)(106356001)(5640700003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3242; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: +3CGvMIWrhCVnr53QkVL5WPDYIRV01UaIEVF7ifryzuiJ71yrLHGITvJUVc6o6CYWA4ue0TowMil42LbU+K4XA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A5D998101F25C48A16C63D62DEB2305@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ed0fc78-8de7-4eee-c149-08d55dc847ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 16:35:12.3865 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3242
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_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-1711220000 definitions=main-1801170232
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 16:58:33 -0000

SGkgQ2x5ZGUsDQoNCk9uZSBxdWljayBmb2xsb3ctdXAsIGl0IHNlZW1zIHRoYXQgYWxsIGRyYWZ0
cyBhcmUgbW92aW5nIG92ZXIgdG8gcmVmZXJlbmNlIHRoZSB0cmVlLWRpYWdyYW1zIGRyYWZ0IHRo
ZXNlIGRheXMuICBBcyBzdWNoLCBJIHRoaW5rIFNlY3Rpb24gMS4zIChUcmVlIERpYWdyYW0gTm90
YXRpb24pIHNob3VsZCBub3cgYmUgcmVtb3ZlZCBhbmQgU2VjdGlvbiAzLjEgc2hvdWxkIGNoYW5n
ZSBhcyBmb2xsb3dzOg0KDQogIE9MRA0KICBQbGVhc2Ugc2VlIFNlY3Rpb24gMS4zIGZvciB0cmVl
IGRpYWdyYW0gbm90YXRpb24uDQoNCiAgTkVXDQogIFBsZWFzZSBzZWUgW0ktRC5pZXRmLW5ldG1v
ZC15YW5nLXRyZWUtZGlhZ3JhbXNdIGZvciB0cmVlIGRpYWdyYW0gbm90YXRpb24uDQogICh5ZXMs
IHRoYXQgc2hvdWxkIGJlIGh5cGVybGluaykNCg0KYW5kIGFkZCBJLUQuaWV0Zi1uZXRtb2QteWFu
Zy10cmVlLWRpYWdyYW1zIGFzIGFuIEluZm9ybWF0aXZlIHJlZmVyZW5jZS4NCg0KVGhhbmtzLA0K
S2VudA0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KQ2x5ZGUsDQoNClRoaXMg
ZHJhZnQgc3RpbGwgaXNuJ3QgcGFzc2luZyBpZG5pdHMuICBJIHByb3ZpZGVkIHRoZSBsaW5rIHRv
IGlkbml0cyBwcmV2aW91c2x5LCBidXQgaGVyZSBpdCBpcyBhZ2FpbjogaHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfdG9vbHNf
aWRuaXRzJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNX
em9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1BMngx
Q3l2RkdWN3pQenVuek5Mel9fQ2UyTnN3eVlPdzBpUVZJLWNOd1RvJnM9RkVyejVHMkhJQ0tuVF9s
STZnZWRnN25pNjZYQ01Ccmo3NTZlaC1sWGRXMCZlPS4gIEJlbG93IGlzIHRoZSBpZG5pdHMgb3V0
cHV0IGZvciAtMTkgd2l0aCBpbmxpbmVkIGNvbW1lbnRzLg0KDQpQUzogSSBkaWRuJ3QgYWxzbyBj
aGVja2VkIHRoZSBvdGhlciBpc3N1ZXMgd2UncmUgdHJhY2tpbmcsIGJ1dCB3aWxsIHdoZW4gd2Ug
Z2V0IHBhc3QgdGhlc2UgaWRuaXRzIGlzc3Vlcy4NCg0KS2VudA0KDQoNCj09PT09IFNUQVJUID09
PT09DQppZG5pdHMgMi4xNS4wMCANCg0KL3RtcC9kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9k
ZWwtMTkudHh0Og0KDQogIENoZWNraW5nIGJvaWxlcnBsYXRlIHJlcXVpcmVkIGJ5IFJGQyA1Mzc4
IGFuZCB0aGUgSUVURiBUcnVzdCAoc2VlDQogIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdHJ1c3RlZS5pZXRmLm9yZ19saWNlbnNlLTJEaW5mbyZk
PUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05
emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09QTJ4MUN5dkZHVjd6
UHp1bnpOTHpfX0NlMk5zd3lZT3cwaVFWSS1jTndUbyZzPVgwMF9ENm1TX0NZZERETV9MQUJ3LWFf
dWhReml3alN2YWF6OFVIQzZOYzAmZT0pOg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAg
Tm8gaXNzdWVzIGZvdW5kIGhlcmUuDQoNCiAgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8gaHR0
cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0
Zi5vcmdfaWQtMkRpbmZvXzFpZC0yRGd1aWRlbGluZXMudHh0JmQ9RHdJQ0FnJmM9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1BMngxQ3l2RkdWN3pQenVuek5Mel9fQ2UyTnN3eVlP
dzBpUVZJLWNOd1RvJnM9VTlQcVk4a3BkYnd6X3NMNGExRGhCSmFnU3ZFeDlzdjl6WnF1bGRoZWQ3
VSZlPToNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgIE5vIGlzc3VlcyBmb3VuZCBoZXJl
Lg0KDQogIENoZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2lkLTJEaW5mb19jaGVj
a2xpc3QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUEyeDFD
eXZGR1Y3elB6dW56Tkx6X19DZTJOc3d5WU93MGlRVkktY053VG8mcz1LODMzSVJ6d04zc0JacjJB
cG1RWVJIanZTbUtIT2hOalk0SlEybVVFbTE4JmU9IDoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQogICoqIFRoZXJlIGlzIDEgaW5zdGFuY2Ugb2YgdG9vIGxvbmcgbGluZXMgaW4gdGhlIGRvY3Vt
ZW50LCB0aGUgbG9uZ2VzdCBvbmUNCiAgICAgYmVpbmcgMSBjaGFyYWN0ZXIgaW4gZXhjZXNzIG9m
IDcyLg0KDQpLZW50OiB0aGlzIGlzbid0IGEgYmlnIGRlYWwgSU1PLCBidXQgaWYgaXQncyBlYXN5
IHRvIGZpeCwgaXQgc2F2ZXMgdGhlIFJGQyBlZGl0b3IgYSBzdGVwIGxhdGVyIG9uLg0KDQoNCiAg
TWlzY2VsbGFuZW91cyB3YXJuaW5nczoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogID09IExp
bmUgMzUyIGhhcyB3ZWlyZCBzcGFjaW5nOiAnLi4uZ29yaXRobSAgICBpZGUuLi4nDQoNCktlbnQ6
IHRoaXMgaXMgZmluZS4gIGl0IGlzIGluIGEgdHJlZSBkaWFncmFtLg0KDQoNCiAgPT0gVGhlIGRv
Y3VtZW50IHNlZW1zIHRvIGxhY2sgdGhlIHJlY29tbWVuZGVkIFJGQyAyMTE5IGJvaWxlcnBsYXRl
LCBldmVuIGlmDQogICAgIGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5IGtleXdvcmRzIC0tIGhv
d2V2ZXIsIHRoZXJlJ3MgYSBwYXJhZ3JhcGggd2l0aA0KICAgICBhIG1hdGNoaW5nIGJlZ2lubmlu
Zy4gQm9pbGVycGxhdGUgZXJyb3I/DQoNCiAgICAgKFRoZSBkb2N1bWVudCBkb2VzIHNlZW0gdG8g
aGF2ZSB0aGUgcmVmZXJlbmNlIHRvIFJGQyAyMTE5IHdoaWNoIHRoZQ0KICAgICBJRC1DaGVja2xp
c3QgcmVxdWlyZXMpLg0KDQpLZW50OiBJIGNhbid0IGZpbmQgdGhlIGVycm9yLiAgTG9va2luZyBh
dCB0aGUgeG1sLCBpdCBpcyB2ZXJiYXRpbSB3aGF0IEkgaGF2ZSBpbiB0aGUgemVyb3RvdWNoIGRy
YWZ0LiAgbXkgZ3Vlc3MgaXMgdGhhdCB0aGlzIGlzIGEgdG9vbGluZyBlcnJvciBhbmQgd2Ugc2hv
dWxkIGlnbm9yZSBpdC4NCg0KDQogIC0tIFRoZSBkb2N1bWVudCBkYXRlIChKYW51YXJ5IDEyLCAy
MDE4KSBpcyA0IGRheXMgaW4gdGhlIHBhc3QuICBJcyB0aGlzDQogICAgIGludGVudGlvbmFsPw0K
DQpLZW50OiB0aGlzIGlzIGZpbmUsIGl0IGlzIGludGVudGlvbmFsLg0KDQoNCiAgQ2hlY2tpbmcg
cmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgKFNlZSBSRkNzIDM5NjcgYW5kIDQ4OTcgZm9yIGluZm9y
bWF0aW9uIGFib3V0IHVzaW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzDQogICAgIHRvIGxvd2VyLW1h
dHVyaXR5IGRvY3VtZW50cyBpbiBSRkNzKQ0KDQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdJLUQu
aWV0Zi1uZXRjb25mLWtleXN0b3JlJyBpcyBkZWZpbmVkIG9uIGxpbmUgMTM4NiwNCiAgICAgYnV0
IG5vIGV4cGxpY2l0IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCg0KS2VudDogbG9v
a2luZyBhdCB0aGUgWE1MLCBJIHNlZSB0aGF0IHRoZSBlbnRpcmUgcGFyYWdyYXBoIHVzZXMgJ1sn
IGFuZCAnXScgYXMgb3Bwb3NlZCB0byA8eHJlZiAuLi4vPi4gIFBsZWFzZSBmaXggdGhpcy4NCg0K
DQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM3ODk1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTQ1
NiwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQN
Cg0KS2VudDogbG9va2luZyBhdCB0aGUgWE1MLCBJIHNlZSB0d28gaW5zdGFuY2VzIG9mIGFuIHVu
d2FudGVkICIvJmd0OyIgc3RyaW5nLiAgRm9yIGluc3RhbmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzc4
OTUiLz4vJmd0OyAgUGxlYXNlIGZpeCB0aGlzLg0KDQoNCiAgKiogRG93bnJlZjogTm9ybWF0aXZl
IHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQyA2NTg3DQoNCktlbnQ6IGhtbW0sIHdo
YXQncyBnb2luZyBvbiBoZXJlPyAgVGhpcyBZQU5HIG1vZHVsZSBpcyBwcm92aWRpbmcgYW4gYWJp
bGl0eSB0byBjb25maWd1cmUgdGhlICJ0Y3AiIHRyYW5zcG9ydCwgZXZlbiB0aG91Z2ggdGhlIElF
U0cgbWFkZSB0aGF0IGFiaWxpdHkgaGlzdG9yaWMgaW4gMjAxMiAoc2VlIElFU0cgTm90ZSBiZWxv
dykuICBTZWFyY2hpbmcgb25saW5lLCBpdCBsb29rcyBsaWtlIENpc2NvIHN1cHBvcnRzIHRoaXMs
IGJ1dCBKdW5pcGVyIGRvZXMgbm90LiAgV2hhdCBhYm91dCBvdGhlciB2ZW5kb3JzLCBpcyBpdCB3
aWRlbHkgc3VwcG9ydGVkPyAgV2FzIHRoaXMgZGlzY3Vzc2VkIGluIHRoZSBXRz8gIEFuc3dlcmlu
ZyBteSBvd24gcXVlc3Rpb24sIHNlYXJjaGluZyBteSBsb2NhbCBtYWlsYm94LCBJIGRvbid0IHNl
ZSB0aGlzIGV2ZXIgYmVpbmcgZGlzY3Vzc2VkIGJlZm9yZSwgb3RoZXIgdGhhbiBNYXJ0aW4gcXVl
c3Rpb25pbmcgaWYgaXQgd2FzIGEgZ29vZCBpZGVhIGluIE1hciAyMDE2IChubyByZXNwb25zZSku
ICBQbGVhc2Ugc3RhcnQgYSB0aHJlYWQgb24gdGhlIGxpc3QgdG8gZ2V0IFdHIG9waW5pb24gaWYg
aXQncyBva2F5IGZvciB0aGUgZHJhZnQgdG8gcHJvY2VlZCBhcyBpcyBvciBub3QuICBIZXJlJ3Mg
dGhlIElFU0cgTm90ZSBmcm9tIFJGQyA2NTg3Og0KDQogICBJRVNHIE5vdGUNCg0KICAgVGhlIElF
U0cgZG9lcyBub3QgcmVjb21tZW5kIGltcGxlbWVudGluZyBvciBkZXBsb3lpbmcgc3lzbG9nIG92
ZXINCiAgIHBsYWluIHRjcCwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQsIGJl
Y2F1c2UgaXQgbGFja3MgdGhlDQogICBhYmlsaXR5IHRvIGVuYWJsZSBzdHJvbmcgc2VjdXJpdHkg
W1JGQzMzNjVdLg0KDQogICBJbXBsZW1lbnRhdGlvbiBvZiB0aGUgVExTIHRyYW5zcG9ydCBbUkZD
NTQyNV0gaXMgcmVjb21tZW5kZWQgc28gdGhhdA0KICAgYXBwcm9wcmlhdGUgc2VjdXJpdHkgZmVh
dHVyZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRvcnMgd2hvIHdhbnQgdG8NCiAgIGRlcGxveSBz
ZWN1cmUgc3lzbG9nLiAgU2ltaWxhcmx5LCB0aG9zZSBzZWN1cml0eSBmZWF0dXJlcyBjYW4gYmUN
CiAgIHR1cm5lZCBvZmYgZm9yIHRob3NlIHdobyBkbyBub3Qgd2FudCB0aGVtLg0KDQoNCg0KDQoN
CiAgICAgU3VtbWFyeTogMiBlcnJvcnMgKCoqKSwgMCBmbGF3cyAofn4pLCA0IHdhcm5pbmdzICg9
PSksIDEgY29tbWVudCAoLS0pLg0KDQogICAgIFJ1biBpZG5pdHMgd2l0aCB0aGUgLS12ZXJib3Nl
IG9wdGlvbiBmb3IgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhYm91dA0KICAgICB0aGUgaXRl
bXMgYWJvdmUuDQo9PT09PSBFTkQgPT09PT0NCg0KVGhhbmtzLA0KS2VudCAvLyBzaGVwaGVyZA0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5l
dG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0
aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv
RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt
PUEyeDFDeXZGR1Y3elB6dW56Tkx6X19DZTJOc3d5WU93MGlRVkktY053VG8mcz1ldEx4T0lyZ0dh
QUQzMC1VbURHa3JkZmlWdlk3QXNEMkdROHN6Q2tVQ2hrJmU9DQoNCg0K


From nobody Wed Jan 17 09:13: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 8183112FB4B for ; Wed, 17 Jan 2018 09:13:49 -0800 (PST)
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 oiuv1m063DTv for ; Wed, 17 Jan 2018 09:13:47 -0800 (PST)
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 0FB6812FAFB for ; Wed, 17 Jan 2018 09:13:47 -0800 (PST)
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 w0HHCtb5029889; Wed, 17 Jan 2018 09:13:37 -0800
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=zFpviyDgiz1PHNUJbnQZh5dL64zFEacv2yD5YxR4JzI=; b=zwZBXXlIgvlQxeCpTcFZIEfGSSzgZFHR6Ibr24nrVnAjqSGKbkLWFbhsbZ5jl/hZrj8v 6/sQ2fhhValQ8ZS3amq7gzGZLsgDmZMZFhwL528zjL6oT0azLDr1e/75MKawqfUpnIbf PP/lTLvPAV4TNRPX6OcBGBwy2l1lL4dkyDg6O1zH8sFLkE4u+KxuXvCPHWDaOdM83m4+ g42HwbfZ5EDdEuHNDoUs75sShKrl2t3wcnilY8Do11eqfV80KNrJRDGduxaRUU6p5aMG V4D1gV9wT5DvyCFo6rA+0yi+yFDqTeCltvTNvBmfPL3Q+7xQt0Yu1YTSTba7yM87dNIF 5g== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0181.outbound.protection.outlook.com [216.32.180.181]) by mx0a-00273201.pphosted.com with ESMTP id 2fjapbr03x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 09:13:37 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5SPR01MB87.namprd05.prod.outlook.com (10.164.253.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 17:13:35 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 17:13:35 +0000
From: Kent Watsen 
To: Alexander Clemm , Alex Campbell , Benoit Claise , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
Thread-Index: AQHTi/jgm64n1kE5c0S5iq2VpQaBSqN2at0AgABauYCAAElbAIAASOoAgACpZAA=
Date: Wed, 17 Jan 2018 17:13:34 +0000
Message-ID: 
References: <151579789446.21777.985631371557420470@ietfa.amsl.com>   <1516139180331.69061@Aviatnet.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB117@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB117@sjceml521-mbx.china.huawei.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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5SPR01MB87; 6:0mkGkSfyNKiVjqJOix7LFEckxHcduyY258LUfVDNAYa2QjbLzpR1s3BsRffMfSow4T/Aw6JRKgKviooYorgaLAy942jv91s4b9CO94oywetXmwjqUXMDezhJoMTse5dRVUQfhVAIuVioA78ExQMPLZdLA8rjiQTk4EGr/ejvS7GIpPHZMtdESoYNZx7Y1EjP10hoxlanGzVfQMmvDWZ+P/8FlBhomJQte0SlTwo4ZLjTm2R4WQ9Zi11J4mVaB/Eq2YTU2KD2H5in6rhV0Dkz2EAafBmuUmwoN+Ots7U6P6qGEzOelG6XTdvEX/wU5AzZOFiNIrqDv4p5P0y/FO0+A7sJiGieqHC+k4+zVN6aroVdc8WiBXN089hWevLXr7FZ; 5:SK0bHIuxUcr0kOpzN5GPbSJP5wATH0/wd7ttHytHOZ3mR9G0pKaoo+TpHS4Un9DdKJCwarJ8YmVqdIDSxo8/qFS/baY4Eg8otsRfroSrKNr8UOV46F06db/vclrNGGRI9l2MPAvnLRXMSHUUhQ6sTmS5dCenwQvu4XvL8vFQy4g=; 24:MqnQsw0tJWjHb36qAPBxgr66v9KwjYwoLr4INdDSl+uzbU4tAMBcZAlv3pPROGRKQW0usDRM69agTNM7G5TAfo30k1999JIb4OcMhOSiN0g=; 7:E2GLBA/NUCgpJz4FtCjDtzVLb5jXnqeZke2PTglXiFfNQ8SB9XinyHEFWkh5el41Qlu6Wow3fV+2Lk1uk+98o0ASJc3q0esh8S1fX/DLe6Bzu4o5SUFIP5rzQ3U9/nCGtOXvOGKR4j6wfTwzHi/Ix0WAfx5yPV/6r1EF5eV3UAcEaCPfr/geET6cdRkALnBaHAtxNyBXhiYhtkURVkDwL4SWejk7Z8LPqTeQ2IkOly50JIgKvU3rmbR6MuvhwUcS
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: caab339b-81e4-4150-fbb5-08d55dcda467
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5SPR01MB87; 
x-ms-traffictypediagnostic: DM5SPR01MB87:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705)(138986009662008)(95692535739014); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231042)(2400048)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041268)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5SPR01MB87; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5SPR01MB87; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(376002)(396003)(39380400002)(13464003)(189003)(51444003)(199004)(5660300001)(66066001)(2950100002)(6246003)(14454004)(2906002)(2900100001)(83506002)(36756003)(478600001)(110136005)(6512007)(25786009)(53936002)(26005)(99286004)(68736007)(3660700001)(86362001)(3280700002)(106356001)(8676002)(59450400001)(81156014)(102836004)(33656002)(6506007)(105586002)(76176011)(81166006)(305945005)(316002)(6486002)(77096006)(83716003)(58126008)(53546011)(97736004)(7736002)(6116002)(82746002)(2501003)(229853002)(8936002)(6436002)(230783001)(93886005)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5SPR01MB87; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: TLB7wDfgozcCu4hAqBcsOQHSON6CUiDE86MtDQ0hkm5NkS7W4Bmvggs9OmVhrLbJ9kEN+MahtBuG+xmvp2uU+w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3F94B5E03BA55C439463E5274B414F7A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: caab339b-81e4-4150-fbb5-08d55dcda467
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 17:13:34.9829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR01MB87
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_08:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801170240
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 17:13:49 -0000

DQoNCj4gSU1ITywgaWYgdGhpcyBtb2R1bGUgaXMgc3VwcG9zZWQgdG8gYmUgdXNlZnVsIGluIHBy
YWN0aWNlLCB3aXRob3V0DQo+IHJlcXVpcmluZyBpbW1lZGlhdGVseSBwcm9wcmlldGFyeSBhdWdt
ZW50YXRpb25zLCBVRFAgbmVlZHMgdG8gYmUNCj4gc3VwcG9ydGVkLiAgUkZDIDU0MjQgYWxzbyBz
dGF0ZXMgdGhhdCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEDQo+IHN1cHBvcnQgYSBVRFAgdHJhbnNw
b3J0IHBlciBSRkMgNTQyNi4gIA0KDQpBZ3JlZWQuDQoNCg0KPiBXaGV0aGVyIFRDUCBzdXBwb3J0
IHNob3VsZCBiZSBpbmNsdWRlZCBpcyBkZWJhdGFibGUgYmVjYXVzZSBub3QgYQ0KPiBzdGFuZGFy
ZCB0cmFuc3BvcnQuICBQZXJoYXBzIGl0IHNob3VsZCBub3QsIGhvd2V2ZXIgZ2l2ZW4gdGhhdCBp
dA0KPiBoYXMgYWxyZWFkeSBiZWVuIHNwZWNpZmllZCwgSSBkb24ndCB0aGluayBpdCBodXJ0cyB0
byBoYXZlIGl0IGFzDQo+IGEgZmVhdHVyZS9vcHRpb24gZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0
IHJlcXVpcmUgaXQuICANCg0KR2l2ZW4gdGhlIElFU0cgc3RhdGVtZW50IChjb3BpZWQgYmVsb3cp
IGFuZCB0aGUgSElTVE9SSUMgZG93bnJlZiwgSQ0KdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIGEg
aGFyZCBzZWxsLiAgQnV0LCBpZiBpdCB0dXJucyBvdXQgdGhhdA0KbW9zdCB2ZW5kb3JzIHN1cHBv
cnQgUkZDIDY1ODcsIHRoZW4gYSBjYXNlIGNvdWxkIGJlIG1hZGUgZm9yIGl0Lg0KDQpLZW50DQoN
Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXgNCj4gQ2FtcGJlbGwNCj4g
U2VudDogVHVlc2RheSwgSmFudWFyeSAxNiwgMjAxOCAxOjQ2IFBNDQo+IFRvOiBCZW5vaXQgQ2xh
aXNlIDxiY2xhaXNlQGNpc2NvLmNvbT47IEtlbnQgV2F0c2VuDQo+IDxrd2F0c2VuQGp1bmlwZXIu
bmV0PjsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBJLUQgQWN0aW9u
OiBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTkudHh0DQo+IA0KPiBCeSB0aGUgc2Ft
ZSByZWFzb25pbmcgc3VyZWx5IFVEUCBzaG91bGQgbm90IGJlIGF2YWlsYWJsZSBlaXRoZXIsIGJl
Y2F1c2UgaXQNCj4gYWxzbyBkb2Vzbid0IHByb3ZpZGUgc2VjdXJpdHkuDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UNCj4gPGJjbGFpc2VAY2lz
Y28uY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIDE3IEphbnVhcnkgMjAxOCA2OjIzIGEubS4NCj4g
VG86IEtlbnQgV2F0c2VuOyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2Rd
IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xOS50eHQNCj4gDQo+
IEhpLA0KPiA+DQo+ID4gICAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBI
aXN0b3JpYyBSRkM6IFJGQyA2NTg3DQo+ID4NCj4gPiBLZW50OiBobW1tLCB3aGF0J3MgZ29pbmcg
b24gaGVyZT8gIFRoaXMgWUFORyBtb2R1bGUgaXMgcHJvdmlkaW5nIGFuDQo+IGFiaWxpdHkgdG8g
Y29uZmlndXJlIHRoZSAidGNwIiB0cmFuc3BvcnQsIGV2ZW4gdGhvdWdoIHRoZSBJRVNHIG1hZGUg
dGhhdA0KPiBhYmlsaXR5IGhpc3RvcmljIGluIDIwMTIgKHNlZSBJRVNHIE5vdGUgYmVsb3cpLiAg
U2VhcmNoaW5nIG9ubGluZSwgaXQgbG9va3MgbGlrZQ0KPiBDaXNjbyBzdXBwb3J0cyB0aGlzLCBi
dXQgSnVuaXBlciBkb2VzIG5vdC4gIFdoYXQgYWJvdXQgb3RoZXIgdmVuZG9ycywgaXMgaXQNCj4g
d2lkZWx5IHN1cHBvcnRlZD8gIFdhcyB0aGlzIGRpc2N1c3NlZCBpbiB0aGUgV0c/ICBBbnN3ZXJp
bmcgbXkgb3duDQo+IHF1ZXN0aW9uLCBzZWFyY2hpbmcgbXkgbG9jYWwgbWFpbGJveCwgSSBkb24n
dCBzZWUgdGhpcyBldmVyIGJlaW5nIGRpc2N1c3NlZA0KPiBiZWZvcmUsIG90aGVyIHRoYW4gTWFy
dGluIHF1ZXN0aW9uaW5nIGlmIGl0IHdhcyBhIGdvb2QgaWRlYSBpbiBNYXIgMjAxNiAobm8NCj4g
cmVzcG9uc2UpLiAgUGxlYXNlIHN0YXJ0IGEgdGhyZWFkIG9uIHRoZSBsaXN0IHRvIGdldCBXRyBv
cGluaW9uIGlmIGl0J3Mgb2theSBmb3INCj4gdGhlIGRyYWZ0IHRvIHByb2NlZWQgYXMgaXMgb3Ig
bm90LiAgSGVyZSdzIHRoZSBJRVNHIE5vdGUgZnJvbSBSRkMgNjU4NzoNCj4gPg0KPiA+ICAgICBJ
RVNHIE5vdGUNCj4gPg0KPiA+ICAgICBUaGUgSUVTRyBkb2VzIG5vdCByZWNvbW1lbmQgaW1wbGVt
ZW50aW5nIG9yIGRlcGxveWluZyBzeXNsb2cgb3Zlcg0KPiA+ICAgICBwbGFpbiB0Y3AsIHdoaWNo
IGlzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCBiZWNhdXNlIGl0IGxhY2tzIHRoZQ0KPiA+
ICAgICBhYmlsaXR5IHRvIGVuYWJsZSBzdHJvbmcgc2VjdXJpdHkgW1JGQzMzNjVdLg0KPiA+DQo+
ID4gICAgIEltcGxlbWVudGF0aW9uIG9mIHRoZSBUTFMgdHJhbnNwb3J0IFtSRkM1NDI1XSBpcyBy
ZWNvbW1lbmRlZCBzbyB0aGF0DQo+ID4gICAgIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGZlYXR1cmVz
IGFyZSBhdmFpbGFibGUgdG8gb3BlcmF0b3JzIHdobyB3YW50IHRvDQo+ID4gICAgIGRlcGxveSBz
ZWN1cmUgc3lzbG9nLiAgU2ltaWxhcmx5LCB0aG9zZSBzZWN1cml0eSBmZWF0dXJlcyBjYW4gYmUN
Cj4gPiAgICAgdHVybmVkIG9mZiBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB3YW50IHRoZW0uDQo+ID4N
Cj4gPg0KPiA+DQo+IFdlbGwsIEkgYmVsaWV2ZSBpdCdzIGNsZWFyIHBsYWluIFRDUCBzaG91bGQg
bm90IGJlIGluIHRoZSBZQU5HIG1vZHVsZS4NCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiANCg0K
DQo=


From nobody Wed Jan 17 09:36:16 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 C4E5C1314BD for ; Wed, 17 Jan 2018 09:36:10 -0800 (PST)
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 XxxPBznXbSOa for ; Wed, 17 Jan 2018 09:36:09 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 4E6E212E04A for ; Wed, 17 Jan 2018 09:36:00 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id j3so11924516pfh.8 for ; Wed, 17 Jan 2018 09:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=aB+Y+xDHF0tPcOm53X2ktKglkPQ37Pa3EPkFkJ9BH+8=; b=N7R9Mq0er5Uo+DBTUGDAhLJ7KG4YNgyMNoDNJonqWHPS34RjhfT06qS+Tx4P7W48xE 7gmvV4NPBKedlpHY40WYR100WrsVnvfR4nrwv2qGJY4i2ZvNRy3k91Sy6//IAEJ0tNs0 vADQfIRiLzZ3nhZkCVTfk4NcIDsFXxQWvmOCgsrsbPDh+cczJBd2zb/qOkCiG7eQzfco ZuJJGGSp7PiQfTEKINe4NL6kVFfGGbYJ23vUnUCQ3/NSrRN8oVA6iZE9WKYpObD+etLP UD7dLSzfpyswpDuma9UQovFaubYvxflTyF3ivQ+TOaCGjZIaX/ReWHk5Saxy8sOUTwRK kJdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=aB+Y+xDHF0tPcOm53X2ktKglkPQ37Pa3EPkFkJ9BH+8=; b=pNvHMJJjNcXoBG7eBKufVRhdm/WNsoQNLQ/NBfK4z4lXNDcqeKTHNf1beq6Uv0PkBe dsG10QcWQCvoGZg7VGjd3buC0FeM8d7b6FpctHuCEUhvYvwJSEeOG/DhV3Sp3OsM9aM1 YnhFk2bAeBvK//a20zybyhnCdkIEwAaRLsI84YWqTFGrrzMpPFlsl9z3MROge+mhwcoD 88GtsA3rtV2UR2ncjTrs3hc91nojKOI17ckDkahJrwTgc/1o9Q5nR5IfJu/ZcwC87XFC j7G9ESGpMKdwAoRyUT46bxEnlGruYhN8cV/8MS9Rmnj/fqoJPZWeZGB55a9EPWWzhBJO vb9w==
X-Gm-Message-State: AKwxytdwpqa6Jft2JzRhC00VSPwWIHZdX26S8L5Nz02hdd6VGjPqWSX0 hsp/ZEc53Oyy6A65Z7cA7KQ=
X-Google-Smtp-Source: ACJfBosOZDqWDQhIpTga6zLSCap1gaq2hmGhyV+p7e4pTvy6fpO3Dv30GsHyswlP6txobHk3lhoKMA==
X-Received: by 10.98.198.2 with SMTP id m2mr13651557pfg.113.1516210558277; Wed, 17 Jan 2018 09:35:58 -0800 (PST)
Received: from [192.168.1.25] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id v186sm8801997pfb.5.2018.01.17.09.35.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 09:35:57 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 17 Jan 2018 09:35:57 -0800
From: Jeff Tantsura 
To: Martin Bjorklund , 
CC: 
Message-ID: <4544C128-E82E-4D9C-9EF1-BD799C8A6AEB@gmail.com>
Thread-Topic: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>
In-Reply-To: <20180116.164053.2123534827829006518.mbj@tail-f.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 17:36:11 -0000

+1 to 2

Cheers,
Jeff

On 1/16/18, 07:41, "netmod on behalf of Martin Bjorklund"  wrote:

    Vladimir Vassilev  wrote:
    > On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
    > 
    > > Vladimir Vassilev  wrote:
    
    [...]
    
    > >> There is also undocumented alignment space count function before
    > >>  that pyang uses to align the  fields of child data leafs
    > >> with common ancestor. If this is specified in the draft the tree
    > >> output can be deterministic and for me this is an advantage. This is
    > >> currently one of the few underspecified pieces of the tree format so I
    > >> had to check pyang implementation in oder to generate same alignment
    > >> space counts and binary identical tree output results.
    > > I think that we at least should write that there may be more than one
    > > space between  and :
    > >
    > >    There may be any number of additional space characters between
    > >     and .
    > For the sake of the argument (at least having this on the mailing list
    > as reference):
    > 
    >    should be aligned at a common offset for all sibling nodes
    >   from the start of  by adding trailing spaces. The recommended
    >   offset is 3 plus the length of the longest node name among all
    > sibling nodes
    >   including those siblings defined under choice and case nodes.
    > 
    > This is what pyang does now. It is not a perfect solution but it
    > allows identical output down to the bit.
    
    Does anyone else have an opinion on this?  I can see three
    alternatives:
    
      1) allow any number of addtional spaces
      2) allow any number of addtional spaces + define a suggested
         alignment algorithm
      3) mandate the alignment algorithm
    
    
    /martin
    
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod
    



From nobody Wed Jan 17 09:43: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 AEF2B1314C2 for ; Wed, 17 Jan 2018 09:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 7xH-FvOurVRG for ; Wed, 17 Jan 2018 09:43:07 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AD212E867 for ; Wed, 17 Jan 2018 09:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=exlbfAewNjR2bbpvG/Wsj/bD0HAX5rpPa1nAKmth7uY=; b=JXqGi1IB0u6P5EfDFBJd0/MTPbm9dE+T56yeKIoBT9mH8GnDNOyyi7KokUeLaotjcx7i1n8MpzacumZpynIG3fb+Qe2pNm+DpIDfQAna4gc1eYh/7oS0TXNVEg27wIsHrjymtXrltwJBCB2V3CKcWQgfaqcau2qAYe3S/xrOEH0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 17:42:59 +0000
Message-ID: <024201d38fba$766b2a20$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Alexander Clemm" , "Martin Bjorklund" , "Robert Wilton" 
Cc: 
References:  <20180116.115606.561861432247288407.mbj@tail-f.com>  <20180116.164053.2123534827829006518.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB145@sjceml521-mbx.china.huawei.com> <021e01d38f7d$03e80e60$4001a8c0@gateway.2wire.net> <40145d13-a6aa-feb5-bfb2-b87b236e7700@cisco.com>
Date: Wed, 17 Jan 2018 17:29:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: LNXP265CA0008.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::20) To DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f3527430-c955-4165-fa04-08d55dd1c032
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:DB6PR0701MB3000; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:PRPPKHAawu4nBXdiocBK8cvian9oUlzPltWzELemL6fE+Mt/BXeZxlQxrNH4j7JVsZjdsqObSwvXE66QN/o5rmFF8W/+//r1Mm6c2LB9qMGdxXRBvrQrg7MAqKKeBtjT/U02zDYdAwiylY/yYqN46QdBprSzK1mNGwojH5rE/cluAxLGtLHtc66M/3Ly79MIablmD6+cL2TIrPTUa25HG4aDryHgQZjwEOScYPY48vtLNEeqshRMRxYnXAgZlhDV; 25:7yi3AaKeCUXgIhjgbPsavvM+Tnmtxr76SkGXsrdPCl99zvEeZqoxigGJdLgQnqoN8ZHPDn4WMEW+YrHOi3ZSKJUYdXLth0x+E94ZQN7DTHCU+/ECyr5W9+c9hdFjwirMoqmipmt/AWnkPJdbjwpXPC69s94SHNkLVP2HvKXNcohjYqoWoKTfI+z8ngukr3JXZCYwxnQfcwEpRWEGnAzNYs/dQN9W38wV0/siny1YOoqUKPW8vkqlgSp+fFsmCjAywl+T3ag9dGcrXHNSO1Tga2oKiERgYlNohpjryqxLVoU/iF5mhrB7BTWQAFCRDlGVZslpJwWQD7Jwec3Hw8Eb+A==; 31:fG4FB3Ta84G+RwMGRxZ8xJpTxBSCSPs3FHClNGdvKAxloNycay+K0CsJiKGi/ONENviwqNe9zdn+2PlJ5N1wU7JjyDh1ucTbBgAkQGFUPgOyRR1/7dhjXTfV1yFYj65GGcPkwsxrNVmVdJ8N7L1fY3MF8Yw1GYoaFtNxrsYf0PIgm48/+SGj6tuajPQYJ5i4MQTJVSRtKW5Tir9QHZm7y3mCxsnCi+eZ14Xb/29GTHU=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB3000:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(50582790962513)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231023)(944501161)(6055026)(61426038)(61427038)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0701MB3000; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 4:3wJKL3q/iGlpXwo+V99zTxKTZEzIRI863kjGnA14y8cUbhHveUpaTZ69J0vQKiqML2DYr+lY4O1bezEZ13kcVUzHs7lDmjpciIKu7Wjtz7s9KMJTIsclZ2929cf4CjpkLUf9O8WyFSAy7MYyAifE3zFPmKYXy1LIzZl5U9wGZUFiIjPmn5sJHtoCosNYM3rZKdhaabvWUtpNQ6P1FAx0kJ2HYKs7S0pZiy94mwgxdXpeMenZ5LMF7DMaJ4OOAWbaKYIInoiFEZ1UMYamuHiN6Zk/0n8QmlQW62fEepd/RMbGagjOjI5G+pMRvDHtCc1MvJk3IaccqupE5WLyii9sjfOANtEZklIIY1/vkfMA4Rw=
X-Forefront-PRVS: 0555EC8317
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(366004)(376002)(39380400002)(24454002)(51444003)(189003)(199004)(13464003)(26005)(6246003)(316002)(81816011)(97736004)(966005)(8936002)(81156014)(50226002)(16526018)(81166006)(478600001)(93886005)(4720700003)(6666003)(386003)(23676004)(1456003)(1556002)(66066001)(52116002)(44716002)(6496006)(8676002)(33896004)(81686011)(68736007)(86362001)(47776003)(53546011)(5660300001)(230783001)(76176011)(16799955002)(2486003)(61296003)(53936002)(84392002)(50466002)(62236002)(229853002)(345774005)(4326008)(230700001)(6116002)(6486002)(3846002)(14496001)(305945005)(44736005)(9686003)(110136005)(25786009)(106356001)(6306002)(105586002)(7736002)(2906002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjMwMDA7MjM6Y3I1VVhxOFlZd3VRdHhMMm9pcTUrWWJu?= =?utf-8?B?RnFkQ1duakVNeVJyWHphZmRZN2RERHpEYkxKMWsxK1Y2NXhQL01INXdubTMr?= =?utf-8?B?MjJxTWFwM3ZyOWhGWVlacGlFdkFQUDZacGRYUEE3ZWpJMUZLdEg3OEM5NnAr?= =?utf-8?B?VVp1ZDZHdUdtM1FKeUxodkk1dG1qTGpiOExEZHZSOXYrdmJRa1NQeGdiYXpY?= =?utf-8?B?eWlmSGJKSk85cUIweGNJU0dScG1kQTVTOTVhUG0xcEFEeWM4V1YzTnVMUXc5?= =?utf-8?B?eHlFbnBoZStobUtsSkJMRG1taWlVbWkyckVpQ1Rmb0ZjeG1rT2RwQ2ZTMzhj?= =?utf-8?B?Y21LVnl0MTNlQzlkcGd5MVg3cS9CVmlkRUwzQ1lwR3ljcFAzYUs5WlNodk4w?= =?utf-8?B?eEowaHVwTW4xWXUxR0luNmZ0bHFTRW4raExKcEs0bzlhY3h5SEVMdGxVSDZW?= =?utf-8?B?Zm5uN25TaVVBMFZ2bDJudENaTGdvUnNMd242UEpqQWsySEt1UTNkRGRrb1lr?= =?utf-8?B?K0lyaS9kaDYyUnJyR01iWkwrNFlNaG1vUFVGYmdIY3pJeWRpNjZNNkJlYkpw?= =?utf-8?B?ZVd5WGZKZ00rVlJQcUFjWnE5NWtnQWc5STJSOG15SVBiNHFhNXlXNFEwRjZq?= =?utf-8?B?Y09vNitDZ1hwNmVqWVRWZ1pBSkY3SHIyd2VyRWlkNjdyUGhaRlpaeEFmaG02?= =?utf-8?B?N1MzVkVFelBZQ3duMlhaQWRVOWRIVmhQVEFFc3JoUFltay9VcHpocG9nZnJi?= =?utf-8?B?d3JRc3h5VFdRemhHWDEzd0JiYWVjTEd2ZkQwa3QwUlJZNUhYekdQRHQ3TGl4?= =?utf-8?B?b0ZjazlmSzVzMmhKdFhPazBGSGlWWk9tODA2TUNwSHF2UjROemRWYkRjdWRY?= =?utf-8?B?YUlZclZyRWxUR0I1RzM1UjA2QjRuQitoZzVCQ3JhWE5iZmx2K3EyeTZwNXFN?= =?utf-8?B?a2EraHgvTG1uU0FKRHVEZ3VwYkFmeWlLUGRJK294b1gvb3I2RWZrSHRCMmFz?= =?utf-8?B?NkVxQ1hSdU54R09hNHgzVnA2RVhQTHJLK3EyQjdpb0lHYUM1SUJrdzhYYmtP?= =?utf-8?B?V1R1SUo1NzZFdUwyUVZWTGovUlVwL1hWV0lWbGs3QkN2bUhYajFIV2lNd0Jv?= =?utf-8?B?THFIczBxNEU3WGZsKzhUVC94V3VDY2ZYYVlQYk1JTC95aEJ2MWhkMEJQTlJL?= =?utf-8?B?Q1MrTmJGNmpYenNkc3VtUCtqcm5EdVZyUnVpQ0pPd0taQmRqRUhMS1loaXpy?= =?utf-8?B?Z3BZMEV0c0pEZDFjeUgyNFpNV3ppdkNUY1k0dWNiSDhwVlJodlc4cC94VjVG?= =?utf-8?B?dFpnVFdPL1IzRmU0SjFTMHZZcGkxb2h2NkFNMTFmQWkvd0c4OC90Z2UvSEEx?= =?utf-8?B?UHliU3VWZkVjemhrMlQ3bm94NTdqWE0vMTQwMmFxaG4rYWlCa1g5NHAvVnkr?= =?utf-8?B?dmlZUlB3dGwwblJvWS9KTkQ5RUpBbUJaQ21sdlgzSGdrZkFkRGl6cE1tam1E?= =?utf-8?B?T2tmYmxPcUYrOSt6M0Y2b1lEZGdhUmY2MXZTMmRObWEzU2kxS084SmhMdGsv?= =?utf-8?B?TmhIQ2h5NnlXY1dRRkZ2WmtLVGJlTUUyWUZSOGVHWmxZMUliODdKYzBwK01P?= =?utf-8?B?eDZMM3h5ZldkRkY3cU5VVnRkSTM4cWVEY3JodzhDMmtHQ3o4QW1zdWljblRT?= =?utf-8?B?YVdBTFNqTW5kMnl6aSt5RnJyQys4U0JycHNLSWQvS3RJbUN5RTkyRzFCY1pr?= =?utf-8?B?cHAvQWwvZHZNOTRMRlpQYURhR0ZYcU9DUi9CYm52SDdyTUpFZmtXU0wxVG82?= =?utf-8?B?b3BlSHFELzV3SXBKZGFCeFE2cVBENlNZQ3VkMlhBRG1xY3RUKzRlVndVeHk0?= =?utf-8?B?ZXFhdll4OCtML3VaYXZtU01JbjNtdVd5RFNKWis0V2t0cmE0ZFFmMXNqaTBT?= =?utf-8?B?YmRiclJ6MXJIZHFQMDk0cnFEbFFXTVBNeXc5aU11MHdjS296WitYQk8wVGU4?= =?utf-8?B?cWZpWnZ4c1hxSDIxcEllM2dJaVZ6TWN3TDRGNzVZbjMrUlVWWnhRMzEzU09K?= =?utf-8?B?ZlVvVm5LODVNMUhPUHRqc05ZUHl3VHc4RDVobWZlMFF4MnVuZzRycmV5NS83?= =?utf-8?Q?rbbxK6oy749ZFqFL/ytC461slHiMtaGakLQpoV1AVplthY?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:Ne5Sq+SMOcC9CqI+0L4d8Gtm8WK76GHeUPA5TcqbzsJkH+L9o/0gQLUVA2VTdnAWSlkC2JIf33sl96KpFaxJ2sscMgHKdAbEl5tODvVUpHr/YEypaJU0jVdnUXM5lBE3Z2KYO4AXAdjEgNSh6FlS+VVqBhdKzLb8QHIEbXNM568/PxjOLtvgWRTqkpXtPw1l1bpnjXiocUpXV10eXHU/7J6SILnEMmNAiq+Q05agZHUg+gVxlLboY3/V/0NDQwsd7F3Z8A6W1gpo0Fn2KtE1MIjJdH2glutD2O+84Zk6LN9FOVdo7xVMPIOMokzr9UKN5QrBxC/7jVYTf2XYl6j3C7UdlaqiEY+SQKlO9Dq8mFU=; 5:RRbCV7wMfK9oyJBe+251Zd1dd1QTR/HKTbZThJOIKlKwHQlWzdUUcBaUPkiJVSomMydFaaaFjvd4fgcJukhAd+CzX4BTcZRjRlaSoQ1sja9ovTvjKgWm7ysTwQGxFpDq2hDXS/hWq/2Iypa1nJND2hYp1/JjhMPVMLBVjFL27nY=; 24:ruzuNYFt8V2gYBkPK7SzXVkuycSisL/oDyYFVq1yjDe/SgELc+2zb8QSrsJr1+jx/CiivsjJoaOZ6qkCW4Vs0oEvTLuhi/8Z8oPrYifuyks=; 7:5wgrKg0cxwFErfWgCgQJ5PtGkWqy80LROHTp7RTanf7HzJr26+ARXCjpnoju1UFiNvIxM+rjPne8jlIPyzUnnPvVE1tsIGgA/pojWKAZxq2ukrW+Xbi+srIbW8VWVlVBFG17tyhmI9xyV3mU+5Ui9kKj9mGBlTGIPInjZr4JrQe6xIWfcOtYFBaO76om9c9wzz3yDnh6CLOW/YQGcZaiK23AMpN7oDpvwht8r49fgKbXDCHq/7ddTCzwqd5ko/qr
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2018 17:42:59.3313 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f3527430-c955-4165-fa04-08d55dd1c032
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000
Archived-At: 
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 17:43:10 -0000

----- Original Message -----
From: "Robert Wilton" 
Sent: Wednesday, January 17, 2018 10:44 AM

> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
> > ----- Original Message -----
> > From: "Alexander Clemm" 
> > Sent: Wednesday, January 17, 2018 2:20 AM
> >
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is
needed
> > here.  The purpose is to make this human-readable and provide
readers a
> > good sense of the overall structure.
> >
> > 
> >
> > That's what I thought until Benoit said, and Robert agreed, that
> >
> > 'In the end, the tree view should be browsed with tooling.'
> The text based YANG tree diagram (i.e. covered by this draft) doesn't
> need to be browsable by tooling. The purpose of these diagrams should
> be to go in text documents to help explain and illustrate (to human
> readers) the structure of a YANG model.
>
> By "In the end, the tree view should be browsed with tooling.", what I
> mean is that I think that tools like YANG catalog will be the long
term
> way of interacting with and browsing YANG modules. For example, the
> link below for the RIP module.
>
> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
>
> This provides an interactive GUI "tree view" of a YANG model, which
> should be structurally equivalent as the text tree diagram, but
> otherwise the information may be represented in a more visual way.
This
> will become even more powerful when all of the standard YANG modules
are
> available together in a single browsable tree.
>
> Hopefully, that clarifies my previous comment.

Yes, thank you for the clarification,

Tom Petch





>
> Thanks,
> Rob
>
> >
> > i.e. the tree view should be machine readable after which something
is
> > produced for human consumption; not a view I share.
> >
> > Tom Petch
> >
> >
> >     The authoritative specification is still the .yang itself.
Providing
> > some guidance for how to represent the tree is good but let's not
> > over-engineer this; I believe retaining some flexibility is good.
> >> --- Alex
> >>
> >>> -----Original Message-----
> >> ...
> >>>> Does anyone else have an opinion on this?  I can see three
> >>>> alternatives:
> >>>>
> >>>>     1) allow any number of addtional spaces
> >>>>     2) allow any number of addtional spaces + define a suggested
> >>>>        alignment algorithm
> >>>>     3) mandate the alignment algorithm
> >>> Definition of symbols should be precise/consistent, so that
readers
> > can
> >>> consistently interpret tree diagrams.
> >>>
> >>> I think that flexibility in layout should be OK, but the draft
> > should provide
> >>> guideline to ensure the output is readable, and likely to be
broadly
> > consistent
> >>> (since consistency aids readability).
> >>>
> >>> If the IETF data modeling group is trying to specify text output
> > precisely
> >>> enough that it can be screen scraped then we may want to consider
> > whether
> >>> we are focusing on the right solution ;-)
> >>>
> >>> In summary, (2) is my preference, followed by (1), followed by
(3).
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>>
> >>>> /martin
> > .
> >
>


From nobody Wed Jan 17 10:39: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 63B52126DFB; Wed, 17 Jan 2018 10:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 xYmVRaS35DAS; Wed, 17 Jan 2018 10:39:48 -0800 (PST)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 10E6F126BFD; Wed, 17 Jan 2018 10:39:48 -0800 (PST)
Received: by mail-ot0-x234.google.com with SMTP id x4so2066155otg.7; Wed, 17 Jan 2018 10:39:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=kTkTn7bD2x3FA2jqZyxLErmaXlGKLUK1SbGOPk8DTes=; b=L0OmgAvDBwD9toIwD/mRjbKFBUc36jDfDNi+r+P5pv5r8nRYbl7tcRVItIHgYkXb5Y FtqoftmtL3IlaYM2iXP7Kp2PZNoTbkN63DW3o+jpseky5P46q/DggafZUMRFinBcShDo GrxLBU4TbRRA9/wblf8M6gBPxNnNgdysh2XaPt5kaL1ydzvI4qKJLE/5hbzoWDWSxDlV NxyFla2kNMHDEVrqlFvWeNhllofC2zsqVLne+33UWrFTWN2LSubsJGP/FZwkSwAx8MTQ dmpo1oRGxaGsbpVn+jdYZmlPc5vrzRTTWtZmwRyU1Kazw1hAlXGY9uk+GUZWDvAnX5J2 CQZA==
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:cc:to; bh=kTkTn7bD2x3FA2jqZyxLErmaXlGKLUK1SbGOPk8DTes=; b=G+5APatLwL9XaLG6bbIFtrfhi//shXkSNabLI7YQmPfGzDDugwLbw70ThZzrWBkUvu uiAL1ULVLSTV3Uu/3YXdRmjzc/3OPGztOgpe7FGRBV3dXDLWtKU8dmvGUKHbMchXZMpk tNd2kOK0mqv203Gtpqtia7W16PichygrG9OcMjD+1/TMiLrAygk5k38bihuIWhQMBkcr nlz2P/Xn9qOgQsJa56YjvdDuARc+z8mhdmw9B5/VxEdg6Rchsx2zWnynp5yxdaxJlyAp rkSE8Ohwoay8gsHXbyiKiTpVxhTk2H3TNAnkYTzkjw2G0e7njN9RpTUDP8Kz4gP549xk 03Iw==
X-Gm-Message-State: AKwxytew+YPW5xXue3/K72FGOhN7kPpDeyFMXKxW2ZX/npR383ST2MQH VcG/qaqHG6NIvwSSfUmUAav+vvfN
X-Google-Smtp-Source: ACJfBosNY4bNuoGsepeTDaGren0hPwDlaKW6os/42RQhX2h+ra29YOoJ4muIYBMaPa5HhyhfrNg3/A==
X-Received: by 10.157.41.197 with SMTP id g5mr1838716otd.53.1516214387008; Wed, 17 Jan 2018 10:39:47 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d998:dcd9:6c19:6a28]) by smtp.gmail.com with ESMTPSA id r12sm2371149ota.54.2018.01.17.10.39.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 10:39:46 -0800 (PST)
From: Mahesh Jethanandani 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: 
Date: Wed, 17 Jan 2018 10:39:44 -0800
Cc: NETMOD Working Group 
To: netconf 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: [netmod] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 18:39:49 -0000

The authors of draft-ietf-netconf-nmda-netconf and =
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, =
and believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. =
Please send your comments on this thread. Comments like =E2=80=9CI have =
reviewed the documents and believe they are ready for publication=E2=80=9D=
, or =E2=80=9CI have concerns about the document because =E2=80=A6=E2=80=9D=
 are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of =
the drafts.

Thanks.

Mahesh & Kent


From nobody Wed Jan 17 10:57: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 09EF01270AE for ; Wed, 17 Jan 2018 10:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Fv0BYA67vftP for ; Wed, 17 Jan 2018 10:57:39 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 3987712E87D for ; Wed, 17 Jan 2018 10:57:32 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id D9B531AB03F for ; Wed, 17 Jan 2018 11:57:31 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id zWxU1w00A2SSUrH01WxXPC; Wed, 17 Jan 2018 11:57:31 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=rDngYFZ6c6FTbGK86kYA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OEfH7elDNGxmz6VJ+q8go5pb69nlkQNBX8IXBR2Oq4s=; b=W6TgLnU1AvbreMi4pcmk5VHPJ9 xJt1pmnSlG+Y+BJTm8sx8vpEJPMmYTFP2GcBf38glnEV4wbGAXgTbIGTFfWQi77lW8jcmsqwtmTiG 4VeJDp1XMah9/DfDGHSandha4;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51548 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebsts-00448O-2D; Wed, 17 Jan 2018 11:57:28 -0700
To: Ladislav Lhotka , Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com>  <1516172373.21945.16.camel@nic.cz> <2d3e40ab-7dd6-20ea-ee41-c06c498d767c@labn.net> <1516205174.1388.48.camel@nic.cz>
From: Lou Berger 
Message-ID: 
Date: Wed, 17 Jan 2018 13:57:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516205174.1388.48.camel@nic.cz>
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-Exim-ID: 1ebsts-00448O-2D
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]:51548
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 18:57:41 -0000

On 1/17/2018 11:06 AM, Ladislav Lhotka wrote:
>>>> I thought that the problem with the current solution and NMDA, was that
>>>> there is no way to find out what the LNE schema is if the LNE isn't
>>>> booted, and hence isn't providing .  But I'm not sure what
>>>> issues that actually causes.  E.g. does it cause issues with
>>>> pre-configuration of the LNE?
>>> The issue that this causes is that the schema for the pre-configured LNE
>>> isn't
>>> known and validity of  is unclear.
>> Please elaborate on what you see here as a problem.  Those working on
>> LNE's (including myself) don't see an issue here.
> Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
> configuration for a LNE entry? If so, then I assume there is no corresponding
> LNE entry in . If this is correct, then I don't see from where you
> get the embedded YL instance. That is,  may contain
>
>    "ietf-logical-network-element:logical-network-element": [
>      { "name": "foo",
>        "root": { ... pre-provisioned config ... }
>      },
>      ...
>    ]
>
> But if the "foo" LNE isn't booted, then there is no "foo" entry in
> , i.e. also no corresponding instance of the "root" mount point.
>
> Is this reasoning flawed?
Yes.  At least the YL would be instantiated under operational because 
that's where it (server metadata) *always* goes.

Lou

>
> Lada
>


From nobody Wed Jan 17 11:10: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 C835A1275FD for ; Wed, 17 Jan 2018 11:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level: 
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 2_hCP8yoKzCr for ; Wed, 17 Jan 2018 11:09:59 -0800 (PST)
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 4343A1270AE for ; Wed, 17 Jan 2018 11:09:59 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DF18B83560A9 for ; Wed, 17 Jan 2018 19:09:54 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 19:09:56 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Wed, 17 Jan 2018 11:09:54 -0800
From: Alexander Clemm 
To: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" 
Thread-Topic: yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bYiGDflCZ3h0a24DFWm/LfU6N4bRCw
Date: Wed, 17 Jan 2018 19:09:52 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com>
In-Reply-To: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.24]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:10:02 -0000

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

SGkgRWluYXIsDQoNCkkgc3VnZ2VzdCB3ZSBhZGQgY2xhcmlmaWNhdGlvbiB0aGF0IGRlZmF1bHQg
dmFsdWVzIG11c3QgYmUgcmVwb3J0ZWQuICBGb3Igb24tY2hhbmdlLCBjbGVhcmx5IGFsbCBjaGFu
Z2VzIG5lZWQgdG8gYmUgcmVwb3J0ZWQsIHdoZXRoZXIgdGhlIGNoYW5nZSBpcyB0byBhIGRlZmF1
bHQgdmFsdWUgb3Igbm90LCBldmVyeXRoaW5nIGVsc2Ugd291bGQgYmUgY29uZnVzaW5nLiAgQWxz
byBmb3IgcGVyaW9kaWMsIGl0IHdvdWxkIGJlIGNvbmZ1c2luZyB0byBsZWF2ZSBvdXQgcmVhZGlu
Z3Mgd2hlbiBhIHZhbHVlIGlzIGF0IGRlZmF1bHQgIHZlcnN1cyBub3QgKHRoZSBvYmplY3QgbWln
aHQgYWxzbyBoYXZlIGJlZW4gZGVsZXRlZCwgZXRjKS4gIFNvLCBJIGRvbuKAmXQgdGhpbmsgd2Ug
bmVlZCB0byBhZGQgYSBmbGFnIG9yIHN1Y2ggdGhhdCB3b3VsZCBhbGxvdyB0byBleGNsdWRlIGRl
ZmF1bHRzIHdoaWNoIGFwcGVhciB0byBiZSBvZiBsaW1pdGVkIGJlbmVmaXQgdG8gYXBwbGljYXRp
b25zIHdoaWxlIGludHJvZHVjaW5nIGEgbG90IG1vcmUgY29tcGxleGl0eSB0byBkZWFsIHdpdGgg
Y29ybmVyIGNhc2VzIHN1Y2ggYXMgdGhlIG9uZXMgZGVzY3JpYmVkLg0KDQotLS0gQWxleA0KDQpG
cm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5
IDE3LCAyMDE4IDU6MjcgQU0NClRvOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFtuZXRtb2Rd
IHlhbmctcHVzaCBpc3N1ZTogZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMiBhbmQgZGVm
YXVsdCB2YWx1ZXMgYW5kIFJGQyA2MjQzDQoNCkFsbCwNCg0KSW4gZGlzY3Vzc2lvbnMgd2l0aCBz
b21lIGN1c3RvbWVycyBhbmQgb24gaW1wbGVtZW50YXRpb24sIHRoZSBpc3N1ZSBvZiBkZWZhdWx0
cyBoYXMgY29tZSB1cC4gRm9yIGdldC9nZXQtY29uZmlnIHdlIGhhdmUgdGhlIOKAnHdpdGggZGVm
YXVsdHMgY2FwYWJpbGl0eeKAnSBkZWZpbmVkIGluIFJGQyA2MjQzIHRoYXQgYWxsb3dzIHVzIHRv
IGNvbnRyb2wgdGhlIGJlaGF2aW91ciB3aXRoIHJlc3BlY3QgdG8gZGVmYXVsdHMuIFRvIHJlbWlu
ZCBmb2xrIHdpdGggYW4gZXhhbXBsZSwgd2UgY291bGQgaGF2ZToNCg0KICAgIDxycGMgbWVzc2Fn
ZS1pZD0iMTAxIg0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29u
ZjpiYXNlOjEuMCI+DQogICAgICA8Z2V0Pg0KICAgICAgICA8ZmlsdGVyIHR5cGU9InN1YnRyZWUi
Pg0KICAgICAgICAgIDxpbnRlcmZhY2VzIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvaW50
ZXJmYWNlcyIvPg0KICAgICAgICA8L2ZpbHRlcj4NCiAgICAgICAgPHdpdGgtZGVmYXVsdHMNCiAg
ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1uZXRjb25mLXdp
dGgtZGVmYXVsdHMiPg0KICAgICAgICAgIHJlcG9ydC1hbGwNCiAgICAgICAgPC93aXRoLWRlZmF1
bHRzPg0KICAgICAgPC9nZXQ+DQogICAgPC9ycGM+DQoNClRoZSBhZGRpdGlvbiBvZiB0aGUg4oCc
d2l0aC1kZWZhdWx0c+KAnSB0YWcgYW5kIHZhbHVlIGRldGVybWluZXMgdGhlIGJlaGF2aW9yIG9m
IHRoZSBnZXQgaW4gdGhpcyBleGFtcGxlICh0YWtlbiBmcm9tIEEuMy4xIGluIFJGQyA2MjQzPGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQzI3BhZ2UtMjI+KS4NCg0KSXQgc3RyaWtl
cyBtZSB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHNpbWlsYXIgbWVjaGFuaXNtIGZvciB0ZWxlbWV0
cnksIGFsbG93aW5nIGEgdXNlciB0byBzcGVjaWZ5LCBmb3IgZXhhbXBsZSwgdGhhdCBmb3IgYSBw
ZXJpb2RpYyBzdWJzY3JpcHRpb24gb24gYSBzdWJ0cmVlLCB0aGV5IGFsc28gd2lzaCBkZWZhdWx0
IHZhbHVlcyB0byBiZSByZXBvcnRlZC4gSSB0aGluayBhdCBtaW5pbXVtIHdlIG5lZWQgY2xhcmlm
aWNhdGlvbiBvbiB0aGlzLCBhcyBzZWN0aW9uIDMuNyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFu
Zy1wdXNoLTEyIGN1cnJlbnRseSBzYXlzOg0KDQpUaGUgY29udGVudCBvZiB0aGUgdXBkYXRlIHJl
Y29yZCBpcyBlcXVpdmFsZW50IHRvIHRoZSBjb250ZW50cyB0aGF0IHdvdWxkIGJlIG9idGFpbmVk
IGhhZCB0aGUgc2FtZSBkYXRhIGJlZW4gZXhwbGljaXRseSByZXRyaWV2ZWQgdXNpbmcgZS5nLiwg
YSBORVRDT05GICJnZXQiIG9wZXJhdGlvbiwgd2l0aCB0aGUgc2FtZSBmaWx0ZXJzIGFwcGxpZWQu
DQoNClRoaXMgdGV4dCBjYW4gY3VycmVudGx5IG9ubHkgcmVmZXIgdG8gYSDigJxnZXTigJ0gYXMg
ZGVmaW5lZCBpbiBSRkMgNjI0MSBhcyB0aGVyZSBpcyBubyByZWZlcmVuY2UgdG8gUkZDIDYyNDMg
YXMgeWV0LiBJIHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0aGlzIGlzc3VlIG5vdyB0byBkZWZp
bmUgZXhwZWN0YXRpb25zLCBldmVuIGlmIGl0IGlzIHRvIGV4cGxpY2l0bHkgbm90IGNvbnNpZGVy
IGFuIFJGQyA2MjQzLWxpa2UgbWVjaGFuaXNtIG9yIHRvIHNheSB0aGF0IHdlIG9ubHkgY29uc2lk
ZXIgZXhwbGljaXRseSBzZXQgdmFsdWVzIGluIHRlbGVtZXRyeSwgb3LigKYNCg0KQ2hlZXJzLA0K
DQpFaW5hcg0KDQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6sjceml521mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1
IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt
YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRWluYXIsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHN1Z2dlc3Qgd2UgYWRkIGNsYXJpZmljYXRpb24gdGhh
dCBkZWZhdWx0IHZhbHVlcyBtdXN0IGJlIHJlcG9ydGVkLiZuYnNwOyBGb3Igb24tY2hhbmdlLCBj
bGVhcmx5IGFsbCBjaGFuZ2VzIG5lZWQgdG8gYmUgcmVwb3J0ZWQsIHdoZXRoZXIgdGhlIGNoYW5n
ZSBpcyB0byBhIGRlZmF1bHQNCiB2YWx1ZSBvciBub3QsIGV2ZXJ5dGhpbmcgZWxzZSB3b3VsZCBi
ZSBjb25mdXNpbmcuJm5ic3A7IEFsc28gZm9yIHBlcmlvZGljLCBpdCB3b3VsZCBiZSBjb25mdXNp
bmcgdG8gbGVhdmUgb3V0IHJlYWRpbmdzIHdoZW4gYSB2YWx1ZSBpcyBhdCBkZWZhdWx0Jm5ic3A7
IHZlcnN1cyBub3QgKHRoZSBvYmplY3QgbWlnaHQgYWxzbyBoYXZlIGJlZW4gZGVsZXRlZCwgZXRj
KS4mbmJzcDsgU28sIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIHRvIGFkZCBhIGZsYWcgb3Igc3Vj
aCB0aGF0IHdvdWxkDQogYWxsb3cgdG8gZXhjbHVkZSBkZWZhdWx0cyB3aGljaCBhcHBlYXIgdG8g
YmUgb2YgbGltaXRlZCBiZW5lZml0IHRvIGFwcGxpY2F0aW9ucyB3aGlsZSBpbnRyb2R1Y2luZyBh
IGxvdCBtb3JlIGNvbXBsZXhpdHkgdG8gZGVhbCB3aXRoIGNvcm5lciBjYXNlcyBzdWNoIGFzIHRo
ZSBvbmVzIGRlc2NyaWJlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw
aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RWluYXIgTmlsc2VuLU55Z2FhcmQg
KGVpbmFybm4pPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAxNywgMjAxOCA1
OjI3IEFNPGJyPg0KPGI+VG86PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gW25ldG1vZF0geWFuZy1wdXNoIGlzc3VlOiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNo
LTEyIGFuZCBkZWZhdWx0IHZhbHVlcyBhbmQgUkZDIDYyNDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZGlzY3Vzc2lvbnMgd2l0aCBzb21lIGN1c3RvbWVycyBh
bmQgb24gaW1wbGVtZW50YXRpb24sIHRoZSBpc3N1ZSBvZiBkZWZhdWx0cyBoYXMgY29tZSB1cC4g
Rm9yIGdldC9nZXQtY29uZmlnIHdlIGhhdmUgdGhlIOKAnHdpdGggZGVmYXVsdHMgY2FwYWJpbGl0
eeKAnSBkZWZpbmVkIGluIFJGQyA2MjQzIHRoYXQgYWxsb3dzIHVzIHRvIGNvbnRyb2wgdGhlIGJl
aGF2aW91ciB3aXRoIHJlc3BlY3QgdG8gZGVmYXVsdHMuDQogVG8gcmVtaW5kIGZvbGsgd2l0aCBh
biBleGFtcGxlLCB3ZSBjb3VsZCBoYXZlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv
dXJpZXIiPiZuYnNwOyAmbmJzcDsgJmx0O3JwYyBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90Ozwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7eG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJh
c2U6MS4wJnF1b3Q7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbHQ7Z2V0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ZpbHRlciB0eXBlPSZxdW90
O3N1YnRyZWUmcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMgeG1sbnM9JnF1
b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL25zL2ludGVyZmFjZXMiPmh0dHA6Ly9leGFt
cGxlLmNvbS9ucy9pbnRlcmZhY2VzPC9hPiZxdW90Oy8mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2ZpbHRlciZn
dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZsdDt3aXRoLWRlZmF1bHRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv
dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxucz0mcXVvdDt1cm46
aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMmcXVvdDsm
Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgcmVwb3J0LWFsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
b3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy93aXRoLWRlZmF1bHRzJmd0
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbHQ7L2dldCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7
ICZuYnNwOyAmbHQ7L3JwYyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFkZGl0aW9uIG9mIHRoZSDigJw8
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+d2l0aC1kZWZhdWx0czwvc3Bhbj7igJ0g
dGFnIGFuZCB2YWx1ZSBkZXRlcm1pbmVzIHRoZSBiZWhhdmlvciBvZiB0aGUgZ2V0IGluIHRoaXMg
ZXhhbXBsZSAodGFrZW4gZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM2MjQzI3BhZ2UtMjIiPkEuMy4xIGluIFJGQyA2MjQzPC9hPikuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHN0cmlrZXMgbWUg
dGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBzaW1pbGFyIG1lY2hhbmlzbSBmb3IgdGVsZW1ldHJ5LCBh
bGxvd2luZyBhIHVzZXIgdG8gc3BlY2lmeSwgZm9yIGV4YW1wbGUsIHRoYXQgZm9yIGEgcGVyaW9k
aWMgc3Vic2NyaXB0aW9uIG9uIGEgc3VidHJlZSwgdGhleSBhbHNvIHdpc2ggZGVmYXVsdCB2YWx1
ZXMgdG8gYmUgcmVwb3J0ZWQuIEkgdGhpbmsgYXQgbWluaW11bSB3ZSBuZWVkIGNsYXJpZmljYXRp
b24NCiBvbiB0aGlzLCBhcyBzZWN0aW9uIDMuNyBvZiZuYnNwO2RyYWZ0LWlldGYtbmV0Y29uZi15
YW5nLXB1c2gtMTIgY3VycmVudGx5IHNheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+VGhlIGNvbnRlbnQgb2YgdGhlIHVw
ZGF0ZSByZWNvcmQgaXMgZXF1aXZhbGVudCB0byB0aGUgY29udGVudHMgdGhhdCB3b3VsZCBiZSBv
YnRhaW5lZCBoYWQgdGhlIHNhbWUgZGF0YSBiZWVuIGV4cGxpY2l0bHkgcmV0cmlldmVkIHVzaW5n
IGUuZy4sIGEgTkVUQ09ORiAmcXVvdDtnZXQmcXVvdDsgb3BlcmF0aW9uLCB3aXRoIHRoZSBzYW1l
IGZpbHRlcnMgYXBwbGllZC48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB0ZXh0IGNhbiBjdXJyZW50bHkgb25seSBy
ZWZlciB0byBhIOKAnGdldOKAnSBhcyBkZWZpbmVkIGluIFJGQyA2MjQxIGFzIHRoZXJlIGlzIG5v
IHJlZmVyZW5jZSB0byBSRkMgNjI0MyBhcyB5ZXQuIEkgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNz
IHRoaXMgaXNzdWUgbm93IHRvIGRlZmluZSBleHBlY3RhdGlvbnMsIGV2ZW4gaWYgaXQgaXMgdG8g
ZXhwbGljaXRseSBub3QgY29uc2lkZXIgYW4gUkZDIDYyNDMtbGlrZQ0KIG1lY2hhbmlzbSBvciB0
byBzYXkgdGhhdCB3ZSBvbmx5IGNvbnNpZGVyIGV4cGxpY2l0bHkgc2V0IHZhbHVlcyBpbiB0ZWxl
bWV0cnksIG9y4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVpbmFyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6sjceml521mbxchi_--


From nobody Wed Jan 17 11:10: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 9F93C12E858 for ; Wed, 17 Jan 2018 11:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 SDy6u6U1rqrO for ; Wed, 17 Jan 2018 11:10:07 -0800 (PST)
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 718491270AE for ; Wed, 17 Jan 2018 11:10:07 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 18D56176010 for ; Wed, 17 Jan 2018 12:10:07 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id zXA41w0042SSUrH01XA7pM; Wed, 17 Jan 2018 12:10:07 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=IQTN1rbPY9PPOIutjD8A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fuBE2O7mtJe7IBMTVCdb5FnhzPCIZ8N/9zzJjrN3uaA=; b=PEjaQo8bfO3RjjDMTVKYAcmFgY Sc0gNKv4rBLqIUbzc7AKPxuKlr4VD4PnN7UT8vCiZCfvKp5murnINlUGWIAaF02HHqjRPSAHeCZHv tFj8tbQskoY3/NDSmlbrpkg3R;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52548 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebt63-0047pj-SP; Wed, 17 Jan 2018 12:10:03 -0700
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net> <20180117.092002.464472752076487902.mbj@tail-f.com>  <20180117.154205.449528767667713089.mbj@tail-f.com> <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516206380.1388.62.camel@nic.cz>
From: Lou Berger 
Message-ID: <75f62f7e-6561-6d16-c638-ab36daa888bc@labn.net>
Date: Wed, 17 Jan 2018 14:10:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516206380.1388.62.camel@nic.cz>
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-Exim-ID: 1ebt63-0047pj-SP
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]:52548
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:10:17 -0000

On 1/17/2018 11:26 AM, Ladislav Lhotka wrote:
>>>> But when we discussed this the last time having inline schema
>>>> available at the top level (in the SM module), the general consensus
>>>> was that having YL under inline was the preferred approach.
>>> What is new now is that we have an indirection; each instance has its
>>> own pointer to the schema at the top level.  In the previous
>>> discussion, having the schema at the top level implied that all
>>> instances shared the same schema, and*that*  was rejected.
>>>
>> Indirection was possible at the previous time and is part of the current
>> scheme Mount definition. Yes, you need to use different mount points to
>> reference different schema, but take a look at the ni document that's
>> exactly what we are doing there. So I don't believe this is the point that
> What Martin and I are talking about is a mount point that is a list node of the
> "use-schema" type. There is no way how different entries of this list could have
> different schemas.
>
> The same applies to a container mount point that is inside a list. Then you can
> also have multiple*instances*  of the mount point, and with "use-schema" there
> is no way how these instances could have different schemas.
umm, if a server knows enough to use the right metadata indirection (per 
current proposal), it would have also know enough to use the right mount 
point and use-schema (in the old proposal).  Again, the latter is what 
we're doing to solve this *exact* problem for the non-inline case in the 
NI draft.

The only thing new in the proposal is how to encode the indirection, it 
doesn't change the fundamental points/discussion from when we decided on 
the current solution.

Lou
> Lada
>


From nobody Wed Jan 17 11:15: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 36E1412DA47 for ; Wed, 17 Jan 2018 11:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 65g0iln0LorO for ; Wed, 17 Jan 2018 11:15:04 -0800 (PST)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 D28B21200C1 for ; Wed, 17 Jan 2018 11:14:57 -0800 (PST)
Received: from cmgw2 (cmgw3 [10.0.90.83]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 87808175C03 for ; Wed, 17 Jan 2018 12:14:57 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id zXEu1w00a2SSUrH01XEx2E; Wed, 17 Jan 2018 12:14:57 -0700
X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=PFMWJjRlkQHzcpHTrEsA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vi05o1oOxN+0bEJBcTM6ainIHACAxWAEr3u35tPNkX8=; b=CWtS2YXHRcjd24po+hV+Ue7bsf +kzYSyhDCD1ZtyNswUj+w+MhOYokU298wDFeSDNVp2fxNPbE6cSqfzGWjk7wbwQwK7HcCGlGr+Iav Gfelzkvs9Qbgl8fhMiYz5MmA8;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52884 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebtAk-0049Jf-9E; Wed, 17 Jan 2018 12:14:54 -0700
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1516208266.1388.80.camel@nic.cz>
From: Lou Berger 
Message-ID: <2381f792-52da-83fd-62d6-e0b8fef68d34@labn.net>
Date: Wed, 17 Jan 2018 14:14:52 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516208266.1388.80.camel@nic.cz>
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-Exim-ID: 1ebtAk-0049Jf-9E
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]:52884
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:15:06 -0000

On 1/17/2018 11:57 AM, Ladislav Lhotka wrote:
>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>>> I don't agree. The metadata annotation solves real issues.
>> One issue with the annotation is that since the schema might be
>> different in different datastores, it means that the client needs to
>> read the annotation in all datastores, and then fetch the schemas.  So
>> it is a bit more difficult to work with for a client.
> But it doesn't mean that the schemas*must*  be different, and it is easy to
> figure out when they are the same. Also, modules sets in YLbis can further help
> avoid redundant parsing of the same modules.
>
> Lada
>

So I think this amplifies that the difference is one of optimization.   
Given the maturity of this work and the state of the dependent work, 
some of which is already with IESG for publication - I don't see how or 
why we should be discussing anything more than fixing flaws in this 
document.

Lou


From nobody Wed Jan 17 11:30: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 CC2BB12E876; Wed, 17 Jan 2018 11:30:24 -0800 (PST)
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 49LVomA4c2EO; Wed, 17 Jan 2018 11:30:22 -0800 (PST)
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 E228812DA47; Wed, 17 Jan 2018 11:30:22 -0800 (PST)
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 w0HIxiIj017382; Wed, 17 Jan 2018 11:02:01 -0800
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=/XTyOlZAFtjhUeokQxLwCQCbuZwl3w3Zm/AVr+lzmJQ=; b=pICYjghfCE8cjZ8I4qMvkDa1Tp1pn09snzNWoXykR8RRLTp7rhiaih3U63Y9ck6Sl4hs JTKCBtY5FfY8Oe7BpvBHpCTUvOCaOMOd18dET5Dhwobtc0OjOVBp/ValVtvBdkjJIXK3 Ga+at1r3s9Bb5Jx99oRWMdvsZahJu6/8ChaXuKJAlYWvhUqk37iVrapd5QH0bP0U7mOc GQFrs+2EfaiQjYh/4s7lfV+kRn9fu48I1o6TyNrvtN03Ay9D10u4fpfzAhOM0Yx29rhi eTFzhNS0CGZV/lvrUsyqYhyoXe07qIYGGgc6udbqwPfoRgyBeFw/lvsts469M0c99eIy 6A== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0184.outbound.protection.outlook.com [216.32.181.184]) by mx0a-00273201.pphosted.com with ESMTP id 2fjc8bg0ap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 11:02:01 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3033.namprd05.prod.outlook.com (10.168.177.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 19:02:00 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 19:02:00 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , netconf 
CC: NETMOD Working Group 
Thread-Topic: [Netconf] LC of NDMA NETCONF/RESTCONF drafts
Thread-Index: AQHTj8KSPXMvAaGHcUyNeBKvGHzSJKN4F/cA
Date: Wed, 17 Jan 2018 19:02:00 +0000
Message-ID: <8DF69A95-4CE3-4329-A3E3-CD9D4F8C0178@juniper.net>
References: 
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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3033; 6:nLhUP14w/gfYEJwoD5EBVbbONIjIW4MkcrAogGGVNJB+f05NF0XjVcQyfNJc7fD0nMm56PORFExAN3YIu7cR7P0hU+lQs953krYuBakNTZ/mIgmP2TLmYr2Q4Ki4gPwJ+tMNXVFBnRz7upWNH4jX2VNfoEG+t3cCLIJ3xCvX1F/S6bpaSXAx9ssiJM9P+XH/8wbDoBNSt0JGBnLsCJWdk4tOALP+9eZwjh3u8CvHF9C+LaImmsJCi1YwttYTsfz3SqpUJVWQDxXTypADXKD6ZJPygIF/k8aoYOODtCRcoGFFyZw7xmqemyW7v2ftVUaU/25Qwt82nV2y+/QIYcTDF/CNTLPLq5L6+AP9DxzgK+uH4AmJe6+Z0/iYC4NwDmYO; 5:5QcilAGuqcAA2yWcCRLFSYOzJc/N/kktulmzb8BJjtL201AwQWwY/KTpCfaej5Xgpymi6chxIP/xp75EEGfxcZqleUQJLY71YltDan+lOeBOtLf3YpFAxowsN1Q9bdDOPXhVNFwqH1U9j0iziS9v9EQiCPOFfjLfGqsDZZJdOt4=; 24:C9ml6FvZN2+zOPOJKMHXRdk8MbfwVM45q1H/4e0qo0Di1lPtL55omsdA2xDIndyR/hKzVDS8UugorrrVWIMaY7THxEmQBKqM2nOkuTM4iA0=; 7:0ee+vmYXao0W939G3g2vWpZ+CNYiTuDOIdcatAfoqUoVAxmT4lt/es/O5r4FmxSEH7EPBy0aZ8sXVjgyJwI1UxQk6n6RjYJnQdQDMWn5LWlX+LS6rGT0/lMUkNqkG++bdOHZP0UUmjOicjo76sausj0W6ZoHQlt/gBBzfHTe4yo/bzSWqd3H8hrjMMLKJJ4umHq1O+vd19bj6V7e4C9uBA719oHCWswUIozMpbP3myfUnL5iCNXhObeHR9PdmOFl
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8432409e-6d67-4fed-c2b4-08d55ddcc9e9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3033; 
x-ms-traffictypediagnostic: DM5PR05MB3033:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231042)(2400048)(944501161)(6055026)(6041268)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3033; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR05MB3033; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(346002)(396003)(376002)(199004)(189003)(58126008)(6506007)(102836004)(97736004)(8676002)(86362001)(575784001)(106356001)(6436002)(81156014)(81166006)(4326008)(6486002)(68736007)(82746002)(305945005)(7736002)(77096007)(26005)(3280700002)(8936002)(66066001)(3660700001)(76176011)(6246003)(6116002)(36756003)(2900100001)(5660300001)(105586002)(83716003)(229853002)(3846002)(478600001)(316002)(2906002)(110136005)(39060400002)(33656002)(966005)(6512007)(25786009)(83506002)(53936002)(14454004)(6306002)(99286004)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3033; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 0fGJZv1sn3XamzAeWFdfz5Pa4VdMpfl9Ymd0Rp/pghDTR6yzS9ZKouvr7VJO0/Sc/8ntiPbPoVv1MjtOkXE1Tg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <798E7743DB272E4AAE344061D55732E1@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8432409e-6d67-4fed-c2b4-08d55ddcc9e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 19:02:00.4052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3033
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_09:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=985 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801170262
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:30:25 -0000

SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGltcGFjdGluZyBlaXRoZXIgb2YgdGhlc2UgdHdvIGRy
YWZ0cy4NCg0KS2VudCAvLyBhcyBjby1hdXRob3INCg0KDQo9PT09PSBvcmlnaW5hbCBtZXNzYWdl
ID09PT09DQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLW5ldGNvbmYg
YW5kIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mIGhhdmUgcG9zdGVkIHVwZGF0ZXMg
dG8gdGhlaXIgZHJhZnRzLCBhbmQgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudHMgYXJlIHJlYWR5
IGZvciBMQy4NCg0KVGhpcyBzdGFydHMgYSAyIHdlZWsgTEMgb24gdGhlIHR3byBkcmFmdHMgdGhh
dCB3aWxsIGVuZCBvbiBKYW51YXJ5IDMxLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRo
aXMgdGhyZWFkLiBDb21tZW50cyBsaWtlIOKAnEkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnRz
IGFuZCBiZWxpZXZlIHRoZXkgYXJlIHJlYWR5IGZvciBwdWJsaWNhdGlvbuKAnSwgb3Ig4oCcSSBo
YXZlIGNvbmNlcm5zIGFib3V0IHRoZSBkb2N1bWVudCBiZWNhdXNlIOKApuKAnSBhcmUgd2VsY29t
ZSBhbmQgdXNlZnVsIGZvciB0aGUgYXV0aG9ycy4NCg0KQXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUg
d2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgZm9yIGVpdGhlciBvZiB0aGUgZHJhZnRz
Lg0KDQpUaGFua3MuDQoNCk1haGVzaCAmIEtlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGll
dGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1Ed0lHYVEmYz1IQWtZ
dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF
UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPVlEMElYdFVrTU1JM3FJSzYzdk5wc0RtdW1I
U2NfN24xVDZlc2l6Nk56aGMmcz01ZElieDQtN0NNLTVObWJJeWhHUzE2SGU0MWZ5Vl9Db0N1VExC
VjBtREx3JmU9DQoNCg0K


From nobody Wed Jan 17 11:32: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 8F1F112AF77 for ; Wed, 17 Jan 2018 11:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Xhkkctv8GdFr for ; Wed, 17 Jan 2018 11:32:02 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 75702124B17 for ; Wed, 17 Jan 2018 11:32:02 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id C27091AB6A9 for ; Wed, 17 Jan 2018 12:04:04 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id zX401w01D2SSUrH01X43Ky; Wed, 17 Jan 2018 12:04:04 -0700
X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=TC8IOceEIMk7EyGsMfwA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=P/Wf/4WasKatK2V81p1NEhwKlfsDZZiYzH5TQHxXF7U=; b=Jf/URp5WIQm6v6jSVLZp6+JKnZ uTL7OBd1IWYEWeWFrWW1Pmxpxnwc7MJ3110r0z7F31OHJI05IGeFsKdkzsNIR4xS9IM6BZ0JZuAfL ItYzL2oGL8nrClfNIiKEhYTse;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52058 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebt0C-0045wy-OM; Wed, 17 Jan 2018 12:04:00 -0700
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References:  <20180117.154205.449528767667713089.mbj@tail-f.com> <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net>
Date: Wed, 17 Jan 2018 14:03:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180117.171817.479473055872371790.mbj@tail-f.com>
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-Exim-ID: 1ebt0C-0045wy-OM
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]:52058
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:32:03 -0000

On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
...
>>> My main concern is actually the YL version.  I strongly think SM need
>>> to use YL-bis rather that the old YL, so that it can support NMDA.
>>>
>> Right now to SM is independent of Yang Library version and can run
>> with either.
> No this is not correct.  SM uses a grouping from the old YANG
> library (for the "use-schema" case),
I thought YLbis was an updat e to UL (i.e., no name change) as such SM 
can include either.

>   and talks about mounting
> "modules-state" ("inline" case).
In informative descriptions only.  Certainly these can be changed to 
allow for YL-bis if need be.

>> I certainly would expect use of Yang Library bis and nmda
>> to have advantages.
>>
>>> The implementation effort for supporting the new YL in clients and
>>> servers is minimal, esp. when compared to the efforts involved in
>>> supporting SM.
>>>
>>> Adding an indirection is (for me) less important, but it has the
>>> benefit of solving the two issues (a) and (b) above, and I haven't
>>> seen any technical problem with it.
>>>
>> (A) has implementation implications and those participating in the
>> discussion at the time expressed as not being worth the cost.
>> I don't believe b was seen as a significant issue either.
>>
>>> Do you have any technical concerns with using an annotation as an
>>> indirection?
>>>
>> The technicsl issue I have with the approaches the same one that was
>> raised when debated previously, ie the implementation overhead of
>> requiring inline schemas to be available at the top level.
> Ok.  I'm ok with keeping the inline case as it is.  However, I think
> we need to use the new YL-bis, so that we can support the NMDA.
Given that NMDA support is not yet fully defined, we're still in the 
transition period where support for both NMDA and non-NMDA 
implementations need to be considered.  Rob presented some options 
earlier in the thread that I think captures this.

Lou


>
>
> /martin
>
>
>
>
>


From nobody Wed Jan 17 11:44: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 98C6412E87D for ; Wed, 17 Jan 2018 11:44:28 -0800 (PST)
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_RP_MATCHES_RCVD=-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 lo9MlEIwBEJQ for ; Wed, 17 Jan 2018 11:44:26 -0800 (PST)
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 3F93112E877 for ; Wed, 17 Jan 2018 11:44:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4723; q=dns/txt; s=iport; t=1516218266; x=1517427866; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=zlZTETnBMUvcxk6kdbTClMo921gtXpw1OKCTzTTIyVM=; b=UKYRnHbZhx7xAlmdiQlg9VKVUHpjL7fiINysF8nvZLcTKilGG0cAAI2b 6wYpcXpFi2yI/GUUoBxOvrvEWeCdSioikvmJxJ+8K28wVWXDdJ9jpqfKk 9bZC7ktbc5iKkvVcCvR/YE8dqMgFxX3JrcCODvBN8zY7BDddDl+OsD4qc Q=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQDlpl9a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj0UniQeOO4ICBwMYC4RJTwKFJhUBAQEBAQEBAQF?= =?us-ascii?q?rKIUkAQEEAQEhBEcbCw4KKgICIQYwBgEMBgIBAYoXAxUQphWBbTqHPA2CBAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEQD4oRKQyCeYJrRAEBAgEBF4E+gy+CZQWjLz2EWII?= =?us-ascii?q?xgQWIQoUDghlnhTaDb4dujUNCiSqBPDUjgVAyGggbFRkkgioJhE9AN4wcAQEB?=
X-IronPort-AV: E=Sophos; i="5.46,374,1511827200"; d="asc'?scan'208"; a="1507097"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 19:44:24 +0000
Received: from [10.61.81.178] (ams3-vpn-dhcp4531.cisco.com [10.61.81.178]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0HJiNqO003681; Wed, 17 Jan 2018 19:44:24 GMT
To: Mahesh Jethanandani , NETMOD Working Group 
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
From: Eliot Lear 
Message-ID: <61aba7cb-d677-9673-9d4c-21ebf0cc226a@cisco.com>
Date: Wed, 17 Jan 2018 20:44:23 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SS4W0XvqXCXMXfV2j4DIQSghTW6s0tWe0"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 19:44:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--SS4W0XvqXCXMXfV2j4DIQSghTW6s0tWe0
Content-Type: multipart/mixed; boundary="in7P2qWmKQqFX5etSwRE6ssSvdG0TLfnE";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani ,
 NETMOD Working Group 
Message-ID: <61aba7cb-d677-9673-9d4c-21ebf0cc226a@cisco.com>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com>
 <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>
In-Reply-To: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com>

--in7P2qWmKQqFX5etSwRE6ssSvdG0TLfnE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Thank you Mahesh for taking everyone's feedback, showing a lot of
patience, and having to do this under what can only be described as
trying circumstances.=C2=A0 May I now ask the chairs what their next step=

is?=C2=A0 This draft was intended to be in response to LC comments.

Eliot


On 17.01.18 04:17, Mahesh Jethanandani wrote:
> This version of the drafts addresses comments received during the last =
run of the LC. We, the authors, believe that this document is ready for L=
C.
>
>> On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>>
>>        Title           : Network Access Control List (ACL) YANG Data M=
odel
>>        Authors         : Mahesh Jethanandani
>>                          Lisa Huang
>>                          Sonal Agarwal
>>                          Dana Blair
>> 	Filename        : draft-ietf-netmod-acl-model-15.txt
>> 	Pages           : 51
>> 	Date            : 2018-01-16
>>
>> Abstract:
>>   This document describes a data model of Access Control List (ACL)
>>   basic building blocks.
>>
>>   Editorial Note (To be removed by RFC Editor)
>>
>>   This draft contains many placeholder values that need to be replaced=

>>   with finalized values at the time of publication.  This note
>>   summarizes all of the substitutions that are needed.  Please note
>>   that no other RFC Editor instructions are specified anywhere else in=

>>   this document.
>>
>>   Artwork in this document contains shorthand references to drafts in
>>   progress.  Please apply the following replacements
>>
>>   o  "XXXX" --> the assigned RFC value for this draft both in this
>>      draft and in the YANG models under the revision statement.
>>
>>   o  Revision date in model needs to get updated with the date the
>>      draft gets approved.  The date also needs to get reflected on the=

>>      line with .
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-15
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> 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/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



--in7P2qWmKQqFX5etSwRE6ssSvdG0TLfnE--

--SS4W0XvqXCXMXfV2j4DIQSghTW6s0tWe0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpfp5cACgkQh7ZrRtnS
ejPj/Af8CM+EaVLGp+ODbhBvr6w9Z2ftoaxunisjv8p7Kf+Ejv4JrkFs2cYnzgUz
txhnytC8YWArcpLD4WAzqCK7RLfDZ4JgRR+w26co9zZWh3SmFHP9Avvt5R7ej7wy
4BVkF0PDWK3TAm5nnPGmQfW7d+ROD3+m+eK/sOISKkbJprBwlhT6hS4Hs3CfzGCX
ncs1RnP84HqhW9cIrzh2W6Ebcn7vOFCnvaNNchZPfNmJT2mKFtP+MokHxu6Bm8ix
NkI5D/GaorUN0yYxk/ffaaeWZ+x9H7vmtWcSMkA9OQ25QRFFffOPdy/Nus/Wix1K
xXjosCzYtYLKKVdPNm02DmTnvtfeZw==
=3uQc
-----END PGP SIGNATURE-----

--SS4W0XvqXCXMXfV2j4DIQSghTW6s0tWe0--


From nobody Wed Jan 17 12:06: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 23EFB12D872 for ; Wed, 17 Jan 2018 12:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 msiqy7Wk4awV for ; Wed, 17 Jan 2018 12:05:59 -0800 (PST)
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 2142612D7E3 for ; Wed, 17 Jan 2018 12:05:59 -0800 (PST)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 2212D64A9F; Wed, 17 Jan 2018 21:05:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516219557; bh=gMXRyKN2PDeS2jPI45xEsv0wbboyyUDMa2mbMVRK8jM=; h=From:To:Date; b=bX0EZp/BHgr8hZfWYUIXA+KmjdxwNlzAi/sIL5q+63J7tkc9IMPesWVMpCe0b6zgt 0mwj1xyAsMShpLqt0wLWAdcw5RZZ3zBQCCHH0a836KpGx1Tm8CNFK78eEuLp83RhOy GSl1oaNyPeYsPPuyPr9pF5fRLXbMr1bqfU3LPslg=
Message-ID: <1516219556.11294.6.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 21:05:56 +0100
In-Reply-To: <2381f792-52da-83fd-62d6-e0b8fef68d34@labn.net>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1516208266.1388.80.camel@nic.cz> <2381f792-52da-83fd-62d6-e0b8fef68d34@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 20:06:01 -0000

On Wed, 2018-01-17 at 14:14 -0500, Lou Berger wrote:
> 
> On 1/17/2018 11:57 AM, Ladislav Lhotka wrote:
> > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > 
> > > > I don't agree. The metadata annotation solves real issues.
> > > 
> > > One issue with the annotation is that since the schema might be
> > > different in different datastores, it means that the client needs to
> > > read the annotation in all datastores, and then fetch the schemas.  So
> > > it is a bit more difficult to work with for a client.
> > 
> > But it doesn't mean that the schemas*must*  be different, and it is easy to
> > figure out when they are the same. Also, modules sets in YLbis can further
> > help
> > avoid redundant parsing of the same modules.
> > 
> > Lada
> > 
> 
> So I think this amplifies that the difference is one of optimization.   
> Given the maturity of this work and the state of the dependent work, 
> some of which is already with IESG for publication - I don't see how or 
> why we should be discussing anything more than fixing flaws in this 
> document.

I beg to differ.

Lada

> 
> Lou
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 17 12:33: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 245AD12420B for ; Wed, 17 Jan 2018 12:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level: 
X-Spam-Status: No, score=-14.529 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ifq48_w8Y9g7 for ; Wed, 17 Jan 2018 12:33:07 -0800 (PST)
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 88699127275 for ; Wed, 17 Jan 2018 12:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28744; q=dns/txt; s=iport; t=1516221187; x=1517430787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5p7QDiU0h3RHV/7nqvSkVWPYmn71Uzc7JMVH+nTZM3A=; b=FDPNQyX1tDPuv/utZ3sMH8CchUDjE9v1hWpkC9DSSINlpYjcRDs+k8TD a08euIpgk7+vS+2ymHKuLGVyiM3PraUiRex1jFFr8bhFW1DfjFsYsU61z 2yHg3jBCjfrjZw+xMv/+Bign9mg18/uZ9sJ/lSJc2CxehibP8jylsioOx 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAQC1sV9a/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRzBmdCcHhAyKJI5egVsnly6CFgojhRgCGoRKPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBBCNWEAIBCBEEAQEOEwcDAgICMBQJCAIEDgWJT2QQph+CJ4lNA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYQ8ghWDaQyCeYFJgVsLAQECAYFHJjeCYTG?= =?us-ascii?q?CNAWjbAKIDI1FghlnkROKa4JYhiSDGwIRGQGBOwEfOYFQbxVnAYF/CTaCISmBT?= =?us-ascii?q?niKBYE0gRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200";  d="scan'208,217";a="126577786"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 20:33:06 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w0HKX6QH003326 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2018 20:33:06 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Jan 2018 15:33:05 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 17 Jan 2018 15:33:05 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Alexander Clemm 
CC: "netmod@ietf.org" 
Thread-Topic: yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bZRYJFO6bk50OEy2/RxrkWrKN4wiUAgAAXRIA=
Date: Wed, 17 Jan 2018 20:33:05 +0000
Message-ID: <376990F4-90E5-4504-BF55-C892420B70E7@cisco.com>
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.5.20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.99.225]
Content-Type: multipart/alternative; boundary="_000_376990F490E54504BF55C892420B70E7ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 20:33:10 -0000

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

DQoNCk9uIDE3IEphbiAyMDE4LCBhdCAxOTowOSwgQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIu
Y2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3cm90
ZToNCg0KSGkgRWluYXIsDQoNCkkgc3VnZ2VzdCB3ZSBhZGQgY2xhcmlmaWNhdGlvbiB0aGF0IGRl
ZmF1bHQgdmFsdWVzIG11c3QgYmUgcmVwb3J0ZWQuDQoNCmVpbmFybm4+IEnigJltIGFmcmFpZCBJ
IGRvIG5vdCBhZ3JlZSB3aXRoIHRoYXQsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byBjb25m
aWd1cmF0aW9uIGxlYXZlcy4gUGxhdGZvcm1zIGNhbiBoYXZlIHZhc3QgbnVtYmVycyBvZiBjb25m
aWd1cmF0aW9uIGRlZmF1bHRzIHRoYXQgdGhleSBydW4gd2l0aCB3aGVuIHRoZSBlbmQgdXNlciBt
YWtlcyBhIHJlbGF0aXZlbHkgc2ltcGxlIGNvbmZpZ3VyYXRpb24gY2hhbmdlLiBUYWtlIHRoZSBl
eGFtcGxlIG9mIGNyZWF0aW5nICBhIGxvb3BiYWNrIGludGVyZmFjZSBvbiBJT1MtWEUuIElmIHdl
IGxvb2sgYXQgdGhlIGRlZmF1bHRzIGZvciB0aGF0LCB3ZSB3b3VsZCBoYXZlIG92ZXIgNjAgZGVm
YXVsdCBsZWF2ZXMgdGhhdCB3b3VsZCBiZSByZXBvcnRlZCBpZiBhIHN1YnNjcmlwdGlvbiB3YXMg
ZXN0YWJsaXNoZWQgb24gdGhhdCBpbnRlcmZhY2XigKZldmVuIHRob3VnaCB0aGUgZXhwbGljaXQg
ZW5kLXVzZXIgY29uZmlnIG1heSBvbmx5IGJlIGEgY291cGxlIG9mIGxlYXZlcywgc2F5IGRlc2Ny
aXB0aW9uIGFuZCBhbiBJUHY0IGFkZHJlc3MNCg0KRm9yIG9uLWNoYW5nZSwgY2xlYXJseSBhbGwg
Y2hhbmdlcyBuZWVkIHRvIGJlIHJlcG9ydGVkLCB3aGV0aGVyIHRoZSBjaGFuZ2UgaXMgdG8gYSBk
ZWZhdWx0IHZhbHVlIG9yIG5vdCwgZXZlcnl0aGluZyBlbHNlIHdvdWxkIGJlIGNvbmZ1c2luZy4N
Cg0KZWluYXJubj4gSSBhZ3JlZSB0aGF0IGEgY2hhbmdlIHRvIG9yIGF3YXkgZnJvbSB0aGUgZGVm
YXVsdCB2YWx1ZSBuZWVkcyB0byBiZSByZXBvcnRlZC4gQW5kIEkgY2FuIGFsc28gYWdyZWUgdGhh
dCBpZiBhIGRlZmF1bHQgdmFsdWUgaXMgZXhwbGljaXRseSBzZXQgYnkgYW4gZW5kIHVzZXIsIHRo
ZW4gdGhhdCBkZWZhdWx0IHZhbHVlIHNob3VsZCBiZSByZXBvcnRlZCBvbiBhbiBvbmdvaW5nIGJh
c2lzLg0KDQplaW5hcm5uPiBBcyB5b3UgY2FuIHNlZSwgbXkgcHJpbWFyeSBjb25jZXJucyBhcmUg
YWJvdXQgY29uZmlndXJhdGlvbiBkYXRhLiBBcyB5ZXQsIEkgaGF2ZW7igJl0IHRob3VnaHQgc28g
bXVjaCBhYm91dCB0aGUgaW1wbGljYXRpb25zIG9uIGNvbmZpZyBmYWxzZSBkYXRhLg0KDQpBbHNv
IGZvciBwZXJpb2RpYywgaXQgd291bGQgYmUgY29uZnVzaW5nIHRvIGxlYXZlIG91dCByZWFkaW5n
cyB3aGVuIGEgdmFsdWUgaXMgYXQgZGVmYXVsdCAgdmVyc3VzIG5vdCAodGhlIG9iamVjdCBtaWdo
dCBhbHNvIGhhdmUgYmVlbiBkZWxldGVkLCBldGMpLg0KDQplaW5hcm5uPiBGb3IgY29uZmlnLCBJ
IGRvbuKAmXQgYWdyZWUuDQoNClNvLCBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBhZGQgYSBm
bGFnIG9yIHN1Y2ggdGhhdCB3b3VsZCBhbGxvdyB0byBleGNsdWRlIGRlZmF1bHRzIHdoaWNoIGFw
cGVhciB0byBiZSBvZiBsaW1pdGVkIGJlbmVmaXQgdG8gYXBwbGljYXRpb25zIHdoaWxlIGludHJv
ZHVjaW5nIGEgbG90IG1vcmUgY29tcGxleGl0eSB0byBkZWFsIHdpdGggY29ybmVyIGNhc2VzIHN1
Y2ggYXMgdGhlIG9uZXMgZGVzY3JpYmVkLg0KDQplaW5hcm5uPiBBbmQgSSBzdGlsbCBkbyBub3Qg
YWdyZWUsIGVzcGVjaWFsbHkgd2hlbiBjb25maWd1cmF0aW9uIG1heSBoYXZlIGEgbGFyZ2UgbnVt
YmVyIG9mIGRlZmF1bHQgc2V0dGluZ3MgdGhhdCBhcmUgcmVsYXRpdmVseSB1bmludGVyZXN0aW5n
IGluIHRlcm1zIG9mIHJlcG9ydGluZyB3aGVuIG9uZSBwdXRzIGluIHBsYWNlIHRlbGVtZXRyeS4g
QWZ0ZXIgYWxsLCB0aGUgY29uc3VtZXIga25vd3Mgd2hhdCB0aGUgZGVmYXVsdHMgYXJlIGZyb20g
dGhlIG1vZGVsLiBXaHkgc2VuZCBhbGwgdGhhdCBkYXRhIHRoYXQsIHR5cGljYWxseSwgYSBwbGF0
Zm9ybSB3aWxsIG5lZWQgdG8gd29yayBoYXJkZXIgdG8gZXh0cmFjdC4NCg0KZWluYXJubj4gSSB0
aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZSwgb3IgSSB3b3VsZG7igJl0IGhhdmUgcmFp
c2VkIGl0LCBidXQgSSBhbSBzdHJvbmdseSBvcHBvc2VkIHRvIG1ha2luZyB0aGUgYmVoYXZpb3Ig
b2YgdGVsZW1ldHJ5IHRoZSBlcXVpdmFsZW50IG9mIFJGQyA2MjQzIOKAnHJlcG9ydC1hbGzigJ0g
YmVoYXZpb3IuDQoNCkNoZWVycywNCg0KRWluYXINCg0KDQotLS0gQWxleA0KDQpGcm9tOiBuZXRt
b2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVpbmFyIE5p
bHNlbi1OeWdhYXJkIChlaW5hcm5uKQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE3LCAyMDE4
IDU6MjcgQU0NClRvOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1
YmplY3Q6IFtuZXRtb2RdIHlhbmctcHVzaCBpc3N1ZTogZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmct
cHVzaC0xMiBhbmQgZGVmYXVsdCB2YWx1ZXMgYW5kIFJGQyA2MjQzDQoNCkFsbCwNCg0KSW4gZGlz
Y3Vzc2lvbnMgd2l0aCBzb21lIGN1c3RvbWVycyBhbmQgb24gaW1wbGVtZW50YXRpb24sIHRoZSBp
c3N1ZSBvZiBkZWZhdWx0cyBoYXMgY29tZSB1cC4gRm9yIGdldC9nZXQtY29uZmlnIHdlIGhhdmUg
dGhlIOKAnHdpdGggZGVmYXVsdHMgY2FwYWJpbGl0eeKAnSBkZWZpbmVkIGluIFJGQyA2MjQzIHRo
YXQgYWxsb3dzIHVzIHRvIGNvbnRyb2wgdGhlIGJlaGF2aW91ciB3aXRoIHJlc3BlY3QgdG8gZGVm
YXVsdHMuIFRvIHJlbWluZCBmb2xrIHdpdGggYW4gZXhhbXBsZSwgd2UgY291bGQgaGF2ZToNCg0K
ICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFt
czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICA8Z2V0Pg0KICAgICAgICA8ZmlsdGVy
IHR5cGU9InN1YnRyZWUiPg0KICAgICAgICAgIDxpbnRlcmZhY2VzIHhtbG5zPSJodHRwOi8vZXhh
bXBsZS5jb20vbnMvaW50ZXJmYWNlcyIvPg0KICAgICAgICA8L2ZpbHRlcj4NCiAgICAgICAgPHdp
dGgtZGVmYXVsdHMNCiAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6
aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMiPg0KICAgICAgICAgIHJlcG9ydC1hbGwNCiAgICAg
ICAgPC93aXRoLWRlZmF1bHRzPg0KICAgICAgPC9nZXQ+DQogICAgPC9ycGM+DQoNClRoZSBhZGRp
dGlvbiBvZiB0aGUg4oCcd2l0aC1kZWZhdWx0c+KAnSB0YWcgYW5kIHZhbHVlIGRldGVybWluZXMg
dGhlIGJlaGF2aW9yIG9mIHRoZSBnZXQgaW4gdGhpcyBleGFtcGxlICh0YWtlbiBmcm9tIEEuMy4x
IGluIFJGQyA2MjQzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQzI3BhZ2UtMjI+
KS4NCg0KSXQgc3RyaWtlcyBtZSB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHNpbWlsYXIgbWVjaGFu
aXNtIGZvciB0ZWxlbWV0cnksIGFsbG93aW5nIGEgdXNlciB0byBzcGVjaWZ5LCBmb3IgZXhhbXBs
ZSwgdGhhdCBmb3IgYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24gb24gYSBzdWJ0cmVlLCB0aGV5IGFs
c28gd2lzaCBkZWZhdWx0IHZhbHVlcyB0byBiZSByZXBvcnRlZC4gSSB0aGluayBhdCBtaW5pbXVt
IHdlIG5lZWQgY2xhcmlmaWNhdGlvbiBvbiB0aGlzLCBhcyBzZWN0aW9uIDMuNyBvZiBkcmFmdC1p
ZXRmLW5ldGNvbmYteWFuZy1wdXNoLTEyIGN1cnJlbnRseSBzYXlzOg0KDQpUaGUgY29udGVudCBv
ZiB0aGUgdXBkYXRlIHJlY29yZCBpcyBlcXVpdmFsZW50IHRvIHRoZSBjb250ZW50cyB0aGF0IHdv
dWxkIGJlIG9idGFpbmVkIGhhZCB0aGUgc2FtZSBkYXRhIGJlZW4gZXhwbGljaXRseSByZXRyaWV2
ZWQgdXNpbmcgZS5nLiwgYSBORVRDT05GICJnZXQiIG9wZXJhdGlvbiwgd2l0aCB0aGUgc2FtZSBm
aWx0ZXJzIGFwcGxpZWQuDQoNClRoaXMgdGV4dCBjYW4gY3VycmVudGx5IG9ubHkgcmVmZXIgdG8g
YSDigJxnZXTigJ0gYXMgZGVmaW5lZCBpbiBSRkMgNjI0MSBhcyB0aGVyZSBpcyBubyByZWZlcmVu
Y2UgdG8gUkZDIDYyNDMgYXMgeWV0LiBJIHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0aGlzIGlz
c3VlIG5vdyB0byBkZWZpbmUgZXhwZWN0YXRpb25zLCBldmVuIGlmIGl0IGlzIHRvIGV4cGxpY2l0
bHkgbm90IGNvbnNpZGVyIGFuIFJGQyA2MjQzLWxpa2UgbWVjaGFuaXNtIG9yIHRvIHNheSB0aGF0
IHdlIG9ubHkgY29uc2lkZXIgZXhwbGljaXRseSBzZXQgdmFsdWVzIGluIHRlbGVtZXRyeSwgb3Li
gKYNCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQo=

--_000_376990F490E54504BF55C892420B70E7ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz
PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u
IDE3IEphbiAyMDE4LCBhdCAxOTowOSwgQWxleGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWls
dG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20iIGNsYXNzPSIiPmFsZXhhbmRlci5jbGVtbUBo
dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh
bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIg
c3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IaSBF
aW5hciw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy
Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw
YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkkg
c3VnZ2VzdCB3ZSBhZGQgY2xhcmlmaWNhdGlvbiB0aGF0IGRlZmF1bHQgdmFsdWVzIG11c3QgYmUg
cmVwb3J0ZWQuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmVpbmFybm4mZ3Q7IEnigJltIGFmcmFpZCBJ
IGRvIG5vdCBhZ3JlZSB3aXRoIHRoYXQsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byBjb25m
aWd1cmF0aW9uIGxlYXZlcy4gUGxhdGZvcm1zIGNhbiBoYXZlIHZhc3QgbnVtYmVycyBvZiBjb25m
aWd1cmF0aW9uIGRlZmF1bHRzIHRoYXQgdGhleSBydW4gd2l0aCB3aGVuIHRoZSBlbmQgdXNlciBt
YWtlcyBhIHJlbGF0aXZlbHkgc2ltcGxlIGNvbmZpZ3VyYXRpb24gY2hhbmdlLiBUYWtlIHRoZSBl
eGFtcGxlDQogb2YgY3JlYXRpbmcgJm5ic3A7YSBsb29wYmFjayBpbnRlcmZhY2Ugb24gSU9TLVhF
LiBJZiB3ZSBsb29rIGF0IHRoZSBkZWZhdWx0cyBmb3IgdGhhdCwgd2Ugd291bGQgaGF2ZSBvdmVy
IDYwIGRlZmF1bHQgbGVhdmVzIHRoYXQgd291bGQgYmUgcmVwb3J0ZWQgaWYgYSBzdWJzY3JpcHRp
b24gd2FzIGVzdGFibGlzaGVkIG9uIHRoYXQgaW50ZXJmYWNl4oCmZXZlbiB0aG91Z2ggdGhlIGV4
cGxpY2l0IGVuZC11c2VyIGNvbmZpZyBtYXkgb25seSBiZSBhIGNvdXBsZQ0KIG9mIGxlYXZlcywg
c2F5IGRlc2NyaXB0aW9uIGFuZCBhbiBJUHY0IGFkZHJlc3M8L2Rpdj4NCjxiciBjbGFzcz0iIj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx
MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs
IDEyNSk7IiBjbGFzcz0iIj5Gb3Igb24tY2hhbmdlLCBjbGVhcmx5IGFsbCBjaGFuZ2VzIG5lZWQg
dG8gYmUgcmVwb3J0ZWQsIHdoZXRoZXIgdGhlIGNoYW5nZSBpcyB0byBhIGRlZmF1bHQgdmFsdWUg
b3Igbm90LCBldmVyeXRoaW5nIGVsc2Ugd291bGQgYmUgY29uZnVzaW5nLjwvc3Bhbj48L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPGRpdj5laW5hcm5uJmd0OyZuYnNwO0kgYWdyZWUgdGhhdCBhIGNoYW5nZSB0byBvciBhd2F5
IGZyb20gdGhlIGRlZmF1bHQgdmFsdWUgbmVlZHMgdG8gYmUgcmVwb3J0ZWQuIEFuZCBJIGNhbiBh
bHNvIGFncmVlIHRoYXQgaWYgYSBkZWZhdWx0IHZhbHVlIGlzIGV4cGxpY2l0bHkgc2V0IGJ5IGFu
IGVuZCB1c2VyLCB0aGVuIHRoYXQgZGVmYXVsdCB2YWx1ZQ0KPGkgY2xhc3M9IiI+c2hvdWxkPC9p
PiBiZSByZXBvcnRlZCBvbiBhbiBvbmdvaW5nIGJhc2lzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjxkaXY+ZWluYXJubiZndDsgQXMgeW91IGNhbiBzZWUsIG15IHByaW1hcnkg
Y29uY2VybnMgYXJlIGFib3V0IGNvbmZpZ3VyYXRpb24gZGF0YS4gQXMgeWV0LCBJIGhhdmVu4oCZ
dCB0aG91Z2h0IHNvIG11Y2ggYWJvdXQgdGhlIGltcGxpY2F0aW9ucyBvbiBjb25maWcgZmFsc2Ug
ZGF0YS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBh
Z2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0K
PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv
bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5BbHNvIGZvciBwZXJp
b2RpYywgaXQgd291bGQgYmUgY29uZnVzaW5nIHRvIGxlYXZlIG91dCByZWFkaW5ncyB3aGVuIGEg
dmFsdWUgaXMgYXQgZGVmYXVsdCZuYnNwOyB2ZXJzdXMgbm90ICh0aGUgb2JqZWN0IG1pZ2h0IGFs
c28gaGF2ZSBiZWVuIGRlbGV0ZWQsIGV0YykuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmVpbmFybm4m
Z3Q7IEZvciBjb25maWcsIEkgZG9u4oCZdCBhZ3JlZS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
IiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250
LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlNv
LCBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBhZGQgYSBmbGFnIG9yIHN1Y2ggdGhhdCB3b3Vs
ZCBhbGxvdyB0byBleGNsdWRlIGRlZmF1bHRzIHdoaWNoIGFwcGVhciB0byBiZSBvZiBsaW1pdGVk
IGJlbmVmaXQgdG8gYXBwbGljYXRpb25zIHdoaWxlIGludHJvZHVjaW5nIGENCiBsb3QgbW9yZSBj
b21wbGV4aXR5IHRvIGRlYWwgd2l0aCBjb3JuZXIgY2FzZXMgc3VjaCBhcyB0aGUgb25lcyBkZXNj
cmliZWQuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdj5laW5hcm5uJmd0OyBBbmQgSSBzdGlsbCBkbyBub3QgYWdyZWUs
IGVzcGVjaWFsbHkgd2hlbiBjb25maWd1cmF0aW9uIG1heSBoYXZlIGEgbGFyZ2UgbnVtYmVyIG9m
IGRlZmF1bHQgc2V0dGluZ3MgdGhhdCBhcmUgcmVsYXRpdmVseSB1bmludGVyZXN0aW5nIGluIHRl
cm1zIG9mIHJlcG9ydGluZyB3aGVuIG9uZSBwdXRzIGluIHBsYWNlIHRlbGVtZXRyeS4gQWZ0ZXIg
YWxsLCB0aGUgY29uc3VtZXIga25vd3Mgd2hhdCB0aGUgZGVmYXVsdHMgYXJlIGZyb20NCiB0aGUg
bW9kZWwuIFdoeSBzZW5kIGFsbCB0aGF0IGRhdGEgdGhhdCwgdHlwaWNhbGx5LCBhIHBsYXRmb3Jt
IHdpbGwgbmVlZCB0byB3b3JrIGhhcmRlciB0byBleHRyYWN0LjwvZGl2Pg0KPGRpdj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXY+ZWluYXJubiZndDsgSSB0aGluayB0aGlzIGlzIGFuIGltcG9y
dGFudCBpc3N1ZSwgb3IgSSB3b3VsZG7igJl0IGhhdmUgcmFpc2VkIGl0LCBidXQgSSBhbSBzdHJv
bmdseSBvcHBvc2VkIHRvIG1ha2luZyB0aGUgYmVoYXZpb3Igb2YgdGVsZW1ldHJ5IHRoZSBlcXVp
dmFsZW50IG9mIFJGQyA2MjQzIOKAnHJlcG9ydC1hbGzigJ0gYmVoYXZpb3IuPC9kaXY+DQo8ZGl2
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFn
ZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln
aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u
dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPi0tLSBBbGV4PG86cCBj
bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx
cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg
MTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxl
ZnQtd2lkdGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgcGFkZGluZzogMGluIDBp
biAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVy
LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgYm9yZGVyLXRv
cC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNz
PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy
cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xh
c3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj5uZXRtb2QgWzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgY2xh
c3M9IiI+bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24NCiBCZWhhbGYg
T2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkVp
bmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNl
bnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5X
ZWRuZXNkYXksIEphbnVhcnkgMTcsIDIwMTggNToyNyBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNz
PSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYu
b3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbmV0bW9kXSB5YW5nLXB1c2gg
aXNzdWU6IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgYW5kIGRlZmF1bHQgdmFsdWVz
IGFuZCBSRkMgNjI0MzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNs
YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KQWxsLDxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KSW4gZGlzY3Vzc2lvbnMgd2l0aCBzb21l
IGN1c3RvbWVycyBhbmQgb24gaW1wbGVtZW50YXRpb24sIHRoZSBpc3N1ZSBvZiBkZWZhdWx0cyBo
YXMgY29tZSB1cC4gRm9yIGdldC9nZXQtY29uZmlnIHdlIGhhdmUgdGhlIOKAnHdpdGggZGVmYXVs
dHMgY2FwYWJpbGl0eeKAnSBkZWZpbmVkIGluIFJGQyA2MjQzIHRoYXQgYWxsb3dzIHVzIHRvIGNv
bnRyb2wgdGhlIGJlaGF2aW91ciB3aXRoIHJlc3BlY3QgdG8gZGVmYXVsdHMuIFRvIHJlbWluZCBm
b2xrIHdpdGgNCiBhbiBleGFtcGxlLCB3ZSBjb3VsZCBoYXZlOjxvOnAgY2xhc3M9IiI+PC9vOnA+
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw
aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v
OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt
aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZs
dDtycGMgbWVzc2FnZS1pZD0mcXVvdDsxMDEmcXVvdDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286
cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O3htbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90
OyZndDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJmx0O2dldCZndDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtmaWx0
ZXIgdHlwZT0mcXVvdDtzdWJ0cmVlJnF1b3Q7Jmd0Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw
PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZsdDtpbnRlcmZhY2VzIHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9u
cy9pbnRlcmZhY2VzIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl
cmxpbmU7IiBjbGFzcz0iIj5odHRwOi8vZXhhbXBsZS5jb20vbnMvaW50ZXJmYWNlczwvYT4mcXVv
dDsvJmd0Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj4m
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9maWx0ZXImZ3Q7PC9zcGFuPjxvOnAgY2xh
c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogQ291cmllcjsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbHQ7d2l0aC1kZWZhdWx0czwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw
MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp
ZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM9JnF1
b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRz
JnF1b3Q7Jmd0Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlm
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0i
Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlcG9ydC1hbGw8L3NwYW4+PG86
cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls
eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZsdDsvd2l0aC1kZWZhdWx0cyZndDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286
cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9nZXQmZ3Q7
PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg
Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiIGNsYXNzPSIiPiZuYnNwOyAm
bmJzcDsgJmx0Oy9ycGMmZ3Q7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhlIGFkZGl0aW9uIG9mIHRoZSDigJw8
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj53aXRoLWRlZmF1bHRz
PC9zcGFuPuKAnSB0YWcgYW5kIHZhbHVlIGRldGVybWluZXMgdGhlIGJlaGF2aW9yIG9mIHRoZSBn
ZXQgaW4gdGhpcyBleGFtcGxlICh0YWtlbiBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzYyNDMjcGFnZS0yMiIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl
eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+QS4zLjENCiBpbiBSRkMgNjI0Mzwv
YT4pLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u
dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N
CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg
Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0i
Ij4NCkl0IHN0cmlrZXMgbWUgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBzaW1pbGFyIG1lY2hhbmlz
bSBmb3IgdGVsZW1ldHJ5LCBhbGxvd2luZyBhIHVzZXIgdG8gc3BlY2lmeSwgZm9yIGV4YW1wbGUs
IHRoYXQgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIG9uIGEgc3VidHJlZSwgdGhleSBhbHNv
IHdpc2ggZGVmYXVsdCB2YWx1ZXMgdG8gYmUgcmVwb3J0ZWQuIEkgdGhpbmsgYXQgbWluaW11bSB3
ZSBuZWVkIGNsYXJpZmljYXRpb24gb24gdGhpcywgYXMNCiBzZWN0aW9uIDMuNyBvZiZuYnNwO2Ry
YWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgY3VycmVudGx5IHNheXM6PG86cCBjbGFzcz0i
Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m
bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0
OiAzMHB0OyBtYXJnaW4tcmlnaHQ6IDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2Vy
aWY7IiBjbGFzcz0iIj4NCjxpIGNsYXNzPSIiPlRoZSBjb250ZW50IG9mIHRoZSB1cGRhdGUgcmVj
b3JkIGlzIGVxdWl2YWxlbnQgdG8gdGhlIGNvbnRlbnRzIHRoYXQgd291bGQgYmUgb2J0YWluZWQg
aGFkIHRoZSBzYW1lIGRhdGEgYmVlbiBleHBsaWNpdGx5IHJldHJpZXZlZCB1c2luZyBlLmcuLCBh
IE5FVENPTkYgJnF1b3Q7Z2V0JnF1b3Q7IG9wZXJhdGlvbiwgd2l0aCB0aGUgc2FtZSBmaWx0ZXJz
IGFwcGxpZWQuPC9pPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250
LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl
cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsi
IGNsYXNzPSIiPg0KVGhpcyB0ZXh0IGNhbiBjdXJyZW50bHkgb25seSByZWZlciB0byBhIOKAnGdl
dOKAnSBhcyBkZWZpbmVkIGluIFJGQyA2MjQxIGFzIHRoZXJlIGlzIG5vIHJlZmVyZW5jZSB0byBS
RkMgNjI0MyBhcyB5ZXQuIEkgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNzIHRoaXMgaXNzdWUgbm93
IHRvIGRlZmluZSBleHBlY3RhdGlvbnMsIGV2ZW4gaWYgaXQgaXMgdG8gZXhwbGljaXRseSBub3Qg
Y29uc2lkZXIgYW4gUkZDIDYyNDMtbGlrZSBtZWNoYW5pc20gb3IgdG8gc2F5DQogdGhhdCB3ZSBv
bmx5IGNvbnNpZGVyIGV4cGxpY2l0bHkgc2V0IHZhbHVlcyBpbiB0ZWxlbWV0cnksIG9y4oCmPG86
cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls
eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj
bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7
IiBjbGFzcz0iIj4NCkNoZWVycyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250
LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl
cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss
IHNlcmlmOyIgY2xhc3M9IiI+DQpFaW5hcjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_376990F490E54504BF55C892420B70E7ciscocom_--


From nobody Wed Jan 17 12:44: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 C27FD12E893 for ; Wed, 17 Jan 2018 12:44:29 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 DJAcy0oKpRqS for ; Wed, 17 Jan 2018 12:44:27 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A335127136 for ; Wed, 17 Jan 2018 12:44:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 85259F89; Wed, 17 Jan 2018 21:44:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4OfTuPpJefjT; Wed, 17 Jan 2018 21:44:24 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 21:44:25 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AC6620147; Wed, 17 Jan 2018 21:44:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wDARCzTRuweS; Wed, 17 Jan 2018 21:44:24 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B47920144; Wed, 17 Jan 2018 21:44:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D9DB94214522; Wed, 17 Jan 2018 21:44:22 +0100 (CET)
Date: Wed, 17 Jan 2018 21:44:22 +0100
From: Juergen Schoenwaelder 
To: Alexander Clemm 
Cc: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" 
Message-ID: <20180117204422.bed7262buo3eshgv@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Alexander Clemm , "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" 
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 20:44:30 -0000

For what its worth, the NMDA documents for NETCONF and RESTCONF posted
today state that with-defaults only applies to non-operational
datastores and that values are always reported for operational
datastores, regardless whether they match any defaults.

/js

On Wed, Jan 17, 2018 at 07:09:52PM +0000, Alexander Clemm wrote:
> Hi Einar,
> 
> I suggest we add clarification that default values must be reported.  For on-change, clearly all changes need to be reported, whether the change is to a default value or not, everything else would be confusing.  Also for periodic, it would be confusing to leave out readings when a value is at default  versus not (the object might also have been deleted, etc).  So, I don’t think we need to add a flag or such that would allow to exclude defaults which appear to be of limited benefit to applications while introducing a lot more complexity to deal with corner cases such as the ones described.
> 
> --- Alex
> 
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Einar Nilsen-Nygaard (einarnn)
> Sent: Wednesday, January 17, 2018 5:27 AM
> To: netmod@ietf.org
> Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
> 
> All,
> 
> In discussions with some customers and on implementation, the issue of defaults has come up. For get/get-config we have the “with defaults capability” defined in RFC 6243 that allows us to control the behaviour with respect to defaults. To remind folk with an example, we could have:
> 
>               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>       
>         
>           
>         
>                   xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
>           report-all
>         
>       
>     
> 
> The addition of the “with-defaults” tag and value determines the behavior of the get in this example (taken from A.3.1 in RFC 6243).
> 
> It strikes me that we need to have a similar mechanism for telemetry, allowing a user to specify, for example, that for a periodic subscription on a subtree, they also wish default values to be reported. I think at minimum we need clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 currently says:
> 
> The content of the update record is equivalent to the contents that would be obtained had the same data been explicitly retrieved using e.g., a NETCONF "get" operation, with the same filters applied.
> 
> This text can currently only refer to a “get” as defined in RFC 6241 as there is no reference to RFC 6243 as yet. I think we need to address this issue now to define expectations, even if it is to explicitly not consider an RFC 6243-like mechanism or to say that we only consider explicitly set values in telemetry, or…
> 
> Cheers,
> 
> Einar
> 

> _______________________________________________
> 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 Wed Jan 17 13:17: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 D3E9012D82E for ; Wed, 17 Jan 2018 13:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 VKC5XPqMrD_d for ; Wed, 17 Jan 2018 13:17:27 -0800 (PST)
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 C4937129C6F for ; Wed, 17 Jan 2018 13:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5686; q=dns/txt; s=iport; t=1516223846; x=1517433446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zOrKx10mCiMsdy4Gy/nfU9fcTxTZhMxXwYtGJyGKrUU=; b=fzGtBNBBwt2eP02IZ8L6FYEXsrB/gzovpMHuh1pxx8ydTDPd7UAMeDOI 0A5tQNFDYIhXvyVqQpMGAUJcm82iYaEoenoA03xszFRxAUanj87Qc2aTj mncn+8V/G60mBmESxkwcchVa2GyAwYiWYZV4UOSaU5tDiwsawpS2qlXWK o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjBABKvF9a/4sNJK1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDETBmdCcHhAyZAoFbJ5lEChgLhElPAhqESkMUAQEBAQEBAQE?= =?us-ascii?q?BayiFIwEBAQMBAQEhEToLBQkCAgEIDgIBBAEBAQICCRoDAgICGQwLFAEICAIED?= =?us-ascii?q?gWKKwgQpiuCJ4lLAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoMtghWDQCkMgnm?= =?us-ascii?q?BSYFbCwEBAgGBRyYBFwomglAxgjQFo2wCiAyNRYIZZ5ETimuCWIYkgxsCERkBg?= =?us-ascii?q?TsBNiKBUG8VPSoBgX8JNoIhKYFOeIoFgTSBFwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200"; d="scan'208";a="126593715"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 21:17:25 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0HLHPEJ014405 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2018 21:17:25 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Jan 2018 16:17:24 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 17 Jan 2018 16:17:24 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Juergen Schoenwaelder 
CC: Alexander Clemm , "netmod@ietf.org" 
Thread-Topic: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bZRYJFO6bk50OEy2/RxrkWrKN4wiUAgAAaZwCAAAlAgA==
Date: Wed, 17 Jan 2018 21:17:24 +0000
Message-ID: <32996BEE-9920-45DC-BE26-625034315FC8@cisco.com>
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com> <20180117204422.bed7262buo3eshgv@elstar.local>
In-Reply-To: <20180117204422.bed7262buo3eshgv@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.5.20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.99.225]
Content-Type: text/plain; charset="utf-8"
Content-ID: <26F1C3253994BF48AEB4405C493B04EF@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 21:17:29 -0000

SnVlcmdlbiwNCg0KVGhhbmtzIGZvciB0aGF0ISBUaGF0IGlzIGEgdXNlZnVsIG5vdGUsIGFuZCBp
dCBjYW4gcmVkdWNlIHRoZSBwcm9ibGVtIHNwYWNlIGhlcmUsIGFuZCBJ4oCZbSBmaW5lIHdpdGgg
dGhhdC4gQXMgeW91IG1heSBoYXZlIHNlZW4gZnJvbSBteSByZXNwb25zZSwgdGhvdWdoLCBteSBt
YWluIGNvbmNlcm5zIGlzIGFib3V0IGNvbmZpZ3VyYXRpb24uDQoNClJlbWluZCBtZSDigJQgdW5k
ZXIgTk1EQSB3aWxsIGNvbmZpZ3VyYXRpb24gbGVhdmVzIGJlIHJlcG9ydGVkIGJhY2sgdmlhIOKA
nG9wZXJhdGlvbmFsIGRhdGFzdG9yZXPigJ0/IE1lYW5pbmcgdGhhdCBkZWZhdWx0IGNvbmZpZ3Vy
YXRpb24gZGF0YSBpcyBleHBlY3RlZCB0byBhbHdheXMgYmUgcmV0dXJuZWQgd2hlbiBhY2Nlc3Nl
ZCB2aWEgYW4g4oCcb3BlcmF0aW9uYWwgZGF0YXN0b3Jl4oCdLiBBcG9sb2dpZXMgaWYgdGhpcyBp
cyBhIGR1bWIgcXVlc3Rpb24sIGJ1dCBJ4oCZdmUgbm90IGJlZW4gYWJsZSB0byB0cmFjayBOTURB
IGNsb3NlIGVub3VnaCB0byBhbnN3ZXIgdGhpcyBxdWVzdGlvbiBpbW1lZGlhdGVseS4NCg0KQ2hl
ZXJzLA0KDQpFaW5hcg0KDQo+IE9uIDE3IEphbiAyMDE4LCBhdCAyMDo0NCwgSnVlcmdlbiBTY2hv
ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0K
PiANCj4gRm9yIHdoYXQgaXRzIHdvcnRoLCB0aGUgTk1EQSBkb2N1bWVudHMgZm9yIE5FVENPTkYg
YW5kIFJFU1RDT05GIHBvc3RlZA0KPiB0b2RheSBzdGF0ZSB0aGF0IHdpdGgtZGVmYXVsdHMgb25s
eSBhcHBsaWVzIHRvIG5vbi1vcGVyYXRpb25hbA0KPiBkYXRhc3RvcmVzIGFuZCB0aGF0IHZhbHVl
cyBhcmUgYWx3YXlzIHJlcG9ydGVkIGZvciBvcGVyYXRpb25hbA0KPiBkYXRhc3RvcmVzLCByZWdh
cmRsZXNzIHdoZXRoZXIgdGhleSBtYXRjaCBhbnkgZGVmYXVsdHMuDQo+IA0KPiAvanMNCj4gDQo+
IE9uIFdlZCwgSmFuIDE3LCAyMDE4IGF0IDA3OjA5OjUyUE0gKzAwMDAsIEFsZXhhbmRlciBDbGVt
bSB3cm90ZToNCj4+IEhpIEVpbmFyLA0KPj4gDQo+PiBJIHN1Z2dlc3Qgd2UgYWRkIGNsYXJpZmlj
YXRpb24gdGhhdCBkZWZhdWx0IHZhbHVlcyBtdXN0IGJlIHJlcG9ydGVkLiAgRm9yIG9uLWNoYW5n
ZSwgY2xlYXJseSBhbGwgY2hhbmdlcyBuZWVkIHRvIGJlIHJlcG9ydGVkLCB3aGV0aGVyIHRoZSBj
aGFuZ2UgaXMgdG8gYSBkZWZhdWx0IHZhbHVlIG9yIG5vdCwgZXZlcnl0aGluZyBlbHNlIHdvdWxk
IGJlIGNvbmZ1c2luZy4gIEFsc28gZm9yIHBlcmlvZGljLCBpdCB3b3VsZCBiZSBjb25mdXNpbmcg
dG8gbGVhdmUgb3V0IHJlYWRpbmdzIHdoZW4gYSB2YWx1ZSBpcyBhdCBkZWZhdWx0ICB2ZXJzdXMg
bm90ICh0aGUgb2JqZWN0IG1pZ2h0IGFsc28gaGF2ZSBiZWVuIGRlbGV0ZWQsIGV0YykuICBTbywg
SSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gYWRkIGEgZmxhZyBvciBzdWNoIHRoYXQgd291bGQg
YWxsb3cgdG8gZXhjbHVkZSBkZWZhdWx0cyB3aGljaCBhcHBlYXIgdG8gYmUgb2YgbGltaXRlZCBi
ZW5lZml0IHRvIGFwcGxpY2F0aW9ucyB3aGlsZSBpbnRyb2R1Y2luZyBhIGxvdCBtb3JlIGNvbXBs
ZXhpdHkgdG8gZGVhbCB3aXRoIGNvcm5lciBjYXNlcyBzdWNoIGFzIHRoZSBvbmVzIGRlc2NyaWJl
ZC4NCj4+IA0KPj4gLS0tIEFsZXgNCj4+IA0KPj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWlu
YXJubikNCj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNywgMjAxOCA1OjI3IEFNDQo+PiBU
bzogbmV0bW9kQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbbmV0bW9kXSB5YW5nLXB1c2ggaXNzdWU6
IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgYW5kIGRlZmF1bHQgdmFsdWVzIGFuZCBS
RkMgNjI0Mw0KPj4gDQo+PiBBbGwsDQo+PiANCj4+IEluIGRpc2N1c3Npb25zIHdpdGggc29tZSBj
dXN0b21lcnMgYW5kIG9uIGltcGxlbWVudGF0aW9uLCB0aGUgaXNzdWUgb2YgZGVmYXVsdHMgaGFz
IGNvbWUgdXAuIEZvciBnZXQvZ2V0LWNvbmZpZyB3ZSBoYXZlIHRoZSDigJx3aXRoIGRlZmF1bHRz
IGNhcGFiaWxpdHnigJ0gZGVmaW5lZCBpbiBSRkMgNjI0MyB0aGF0IGFsbG93cyB1cyB0byBjb250
cm9sIHRoZSBiZWhhdmlvdXIgd2l0aCByZXNwZWN0IHRvIGRlZmF1bHRzLiBUbyByZW1pbmQgZm9s
ayB3aXRoIGFuIGV4YW1wbGUsIHdlIGNvdWxkIGhhdmU6DQo+PiANCj4+ICAgIDxycGMgbWVzc2Fn
ZS1pZD0iMTAxIg0KPj4gICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj
b25mOmJhc2U6MS4wIj4NCj4+ICAgICAgPGdldD4NCj4+ICAgICAgICA8ZmlsdGVyIHR5cGU9InN1
YnRyZWUiPg0KPj4gICAgICAgICAgPGludGVyZmFjZXMgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv
bS9ucy9pbnRlcmZhY2VzIi8+DQo+PiAgICAgICAgPC9maWx0ZXI+DQo+PiAgICAgICAgPHdpdGgt
ZGVmYXVsdHMNCj4+ICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp
ZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cyI+DQo+PiAgICAgICAgICByZXBvcnQtYWxsDQo+PiAg
ICAgICAgPC93aXRoLWRlZmF1bHRzPg0KPj4gICAgICA8L2dldD4NCj4+ICAgIDwvcnBjPg0KPj4g
DQo+PiBUaGUgYWRkaXRpb24gb2YgdGhlIOKAnHdpdGgtZGVmYXVsdHPigJ0gdGFnIGFuZCB2YWx1
ZSBkZXRlcm1pbmVzIHRoZSBiZWhhdmlvciBvZiB0aGUgZ2V0IGluIHRoaXMgZXhhbXBsZSAodGFr
ZW4gZnJvbSBBLjMuMSBpbiBSRkMgNjI0MzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj
NjI0MyNwYWdlLTIyPikuDQo+PiANCj4+IEl0IHN0cmlrZXMgbWUgdGhhdCB3ZSBuZWVkIHRvIGhh
dmUgYSBzaW1pbGFyIG1lY2hhbmlzbSBmb3IgdGVsZW1ldHJ5LCBhbGxvd2luZyBhIHVzZXIgdG8g
c3BlY2lmeSwgZm9yIGV4YW1wbGUsIHRoYXQgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIG9u
IGEgc3VidHJlZSwgdGhleSBhbHNvIHdpc2ggZGVmYXVsdCB2YWx1ZXMgdG8gYmUgcmVwb3J0ZWQu
IEkgdGhpbmsgYXQgbWluaW11bSB3ZSBuZWVkIGNsYXJpZmljYXRpb24gb24gdGhpcywgYXMgc2Vj
dGlvbiAzLjcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMiBjdXJyZW50bHkgc2F5
czoNCj4+IA0KPj4gVGhlIGNvbnRlbnQgb2YgdGhlIHVwZGF0ZSByZWNvcmQgaXMgZXF1aXZhbGVu
dCB0byB0aGUgY29udGVudHMgdGhhdCB3b3VsZCBiZSBvYnRhaW5lZCBoYWQgdGhlIHNhbWUgZGF0
YSBiZWVuIGV4cGxpY2l0bHkgcmV0cmlldmVkIHVzaW5nIGUuZy4sIGEgTkVUQ09ORiAiZ2V0IiBv
cGVyYXRpb24sIHdpdGggdGhlIHNhbWUgZmlsdGVycyBhcHBsaWVkLg0KPj4gDQo+PiBUaGlzIHRl
eHQgY2FuIGN1cnJlbnRseSBvbmx5IHJlZmVyIHRvIGEg4oCcZ2V04oCdIGFzIGRlZmluZWQgaW4g
UkZDIDYyNDEgYXMgdGhlcmUgaXMgbm8gcmVmZXJlbmNlIHRvIFJGQyA2MjQzIGFzIHlldC4gSSB0
aGluayB3ZSBuZWVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSBub3cgdG8gZGVmaW5lIGV4cGVjdGF0
aW9ucywgZXZlbiBpZiBpdCBpcyB0byBleHBsaWNpdGx5IG5vdCBjb25zaWRlciBhbiBSRkMgNjI0
My1saWtlIG1lY2hhbmlzbSBvciB0byBzYXkgdGhhdCB3ZSBvbmx5IGNvbnNpZGVyIGV4cGxpY2l0
bHkgc2V0IHZhbHVlcyBpbiB0ZWxlbWV0cnksIG9y4oCmDQo+PiANCj4+IENoZWVycywNCj4+IA0K
Pj4gRWluYXINCj4+IA0KPiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcN
Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAN
Cj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp
dHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz
IFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMx
MDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo=


From nobody Wed Jan 17 13:45: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 BDD6612D77B for ; Wed, 17 Jan 2018 13:45:25 -0800 (PST)
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 vMO_5-oZuLNE for ; Wed, 17 Jan 2018 13:45:23 -0800 (PST)
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 5E8AD12D778 for ; Wed, 17 Jan 2018 13:45:23 -0800 (PST)
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 w0HLj3ea016375; Wed, 17 Jan 2018 13:45:20 -0800
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=DFnbQr16edHoWjdoFO689zR+JTKFTz2ROwxM6UX50Ks=; b=FXl7bfMJ0ik5fjbRRiJLQqouM73Rzip4WRSykNjhlrraxSZ3+mmXUGEAiTFlYPQAaRgN FFfsBXHc1pitKj3uvOXbCwvuDbrQQKmK4fq6A+4XdmW/I/lyXwAdKJaal9YZl9YFWVlD UMrfouCvcdSKmUX3i6v00IpjtvAoB4rJMGcTJV1yhKobrD/GNiVRLzdPj0O3gd3tiPIy wURyD+/yAPs1DfJtaUHML+rIMu+dLPJ7zoRDD9kb1hE3QhWBwTDkYoCmzPG5+RRt08qC GFsKRXn3RW+iv9W+Z+pT39gwBik0W4dWito5faV4qRhm9uxRo9IDM2AyYC9VuR8MLSw/ iA== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0178.outbound.protection.outlook.com [216.32.181.178]) by mx0a-00273201.pphosted.com with ESMTP id 2fjefe80w0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 13:45:19 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3067.namprd05.prod.outlook.com (10.173.218.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.428.9; Wed, 17 Jan 2018 21:45:18 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 21:45:18 +0000
From: Kent Watsen 
To: Eliot Lear , Mahesh Jethanandani , NETMOD Working Group 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
Thread-Index: AQHTj0EIB+dmOB/YRU2JZXs+lEM9h6N3ZM4AgAET1YD//833AA==
Date: Wed, 17 Jan 2018 21:45:18 +0000
Message-ID: <955981BF-70F6-4520-B7EA-0A90EA6EE1A6@juniper.net>
References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> <61aba7cb-d677-9673-9d4c-21ebf0cc226a@cisco.com>
In-Reply-To: <61aba7cb-d677-9673-9d4c-21ebf0cc226a@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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3067; 7:ppulmGpC55dJ8yuIe1R2j09t35FQpgtA7huvM+6ShvGdn3gV86SEaYi1JlqQLGrgtGmkXYnT+A/vrtoxy9znbspc5ry1q0vGGuqln5QQ8V5jnPEZRLKv/FBtWUCzuR/7EArfp0T0q500Yfv/vVDZ2F4j0EY7aGVwWjUgcziUZbVgSKjWv0/W/gmC4nDupVC3qncMragn15k8Za7zBCu4JRruWxqevrlRzCvE6kkRZZ8/kkhWwMfBxTkK60Cy+G4S
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 531c1218-fe7e-45db-c894-08d55df39a2e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3067; 
x-ms-traffictypediagnostic: DM5PR05MB3067:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(2400048)(944501161)(6055026)(6041268)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3067; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3067; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(39380400002)(396003)(346002)(199004)(377424004)(189003)(51444003)(478600001)(58126008)(305945005)(6506007)(7736002)(59450400001)(2950100002)(316002)(3660700001)(3280700002)(105586002)(102836004)(39060400002)(36756003)(6246003)(106356001)(53546011)(82746002)(76176011)(229853002)(33656002)(8676002)(6306002)(14454004)(230783001)(81156014)(966005)(53936002)(81166006)(6436002)(5660300001)(6116002)(83506002)(6486002)(66066001)(3846002)(26005)(86362001)(25786009)(83716003)(110136005)(68736007)(6512007)(2906002)(8936002)(99286004)(2900100001)(97736004)(77096007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3067; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: M1OPVaXkwEQ40p0u8uA4+7xY2HKq/NLrx1Adt1X+pwXNf2Pj0EYtQOM4JGdzwT3tdrpZGj0KTA9rbDUWW9LybA==
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: 531c1218-fe7e-45db-c894-08d55df39a2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 21:45:18.7205 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3067
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_11:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801170295
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 21:45:26 -0000

DQpZZXMsIGdvb2Qgam9iIE1haGVzaCBhbmQgdGVhbSENCg0KTXkgcHJldmlvdXMgTGFzdCBDYWxs
IGNsb3NpbmcgbWVzc2FnZSBbMV0gc2FpZCB0aGF0IHdlJ2QgZXZhbHVhdGUgaWYgdGhhdCBMYXN0
IENhbGwgd2FzIHN1Y2Nlc3NmdWwgb3Igbm90IGJhc2VkIG9uIHRoZSByZXN1bHQgb2YgdGhlIGVu
c3VpbmcgZGlzY3Vzc2lvbiByZWdhcmRpbmcgdGhlIG1vZGVsJ3Mgc3RydWN0dXJlLiAgQXMgdGhl
IGRpZmYgWzJdIGZvciB0aGlzIHVwZGF0ZSBzaG93cywgdGhlIGRyYWZ0IGhhcyBjaGFuZ2VkIHNp
Z25pZmljYW50bHkgc2luY2UgdGhlbiwgc3VjaCB0aGF0IEkgdGhpbmsgdGhhdCBhbm90aGVyIExh
c3QgQ2FsbCBpcyBuZWVkZWQuICBJIHdpbGwgc3RhcnQgaXQgbm93Lg0KDQpbMV0gaHR0cHM6Ly9t
YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvbFg0TEJRVGZOcDNncndEWDEtS052
c3VFSTlFDQpbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt
bmV0bW9kLWFjbC1tb2RlbC0xNQ0KDQpLZW50IC8vIHNoZXBoZXJkDQoNCg0KDQo9PT09PSBvcmln
aW5hbCBtZXNzYWdlID09PT09DQoNClRoYW5rIHlvdSBNYWhlc2ggZm9yIHRha2luZyBldmVyeW9u
ZSdzIGZlZWRiYWNrLCBzaG93aW5nIGEgbG90IG9mDQpwYXRpZW5jZSwgYW5kIGhhdmluZyB0byBk
byB0aGlzIHVuZGVyIHdoYXQgY2FuIG9ubHkgYmUgZGVzY3JpYmVkIGFzDQp0cnlpbmcgY2lyY3Vt
c3RhbmNlcy4gIE1heSBJIG5vdyBhc2sgdGhlIGNoYWlycyB3aGF0IHRoZWlyIG5leHQgc3RlcA0K
aXM/ICBUaGlzIGRyYWZ0IHdhcyBpbnRlbmRlZCB0byBiZSBpbiByZXNwb25zZSB0byBMQyBjb21t
ZW50cy4NCg0KRWxpb3QNCg0KDQpPbiAxNy4wMS4xOCAwNDoxNywgTWFoZXNoIEpldGhhbmFuZGFu
aSB3cm90ZToNCj4gVGhpcyB2ZXJzaW9uIG9mIHRoZSBkcmFmdHMgYWRkcmVzc2VzIGNvbW1lbnRz
IHJlY2VpdmVkIGR1cmluZyB0aGUgbGFzdCBydW4gb2YgdGhlIExDLiBXZSwgdGhlIGF1dGhvcnMs
IGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBMQy4NCj4NCj4+IE9uIEph
biAxNiwgMjAxOCwgYXQgNzoxMSBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0K
Pj4NCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t
bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29y
ayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAg
ICAgICBUaXRsZSAgICAgICAgICAgOiBOZXR3b3JrIEFjY2VzcyBDb250cm9sIExpc3QgKEFDTCkg
WUFORyBEYXRhIE1vZGVsDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWFoZXNoIEpldGhh
bmFuZGFuaQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIExpc2EgSHVhbmcNCj4+ICAgICAg
ICAgICAgICAgICAgICAgICAgICBTb25hbCBBZ2Fyd2FsDQo+PiAgICAgICAgICAgICAgICAgICAg
ICAgICAgRGFuYSBCbGFpcg0KPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9k
LWFjbC1tb2RlbC0xNS50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiA1MQ0KPj4gCURhdGUgICAg
ICAgICAgICA6IDIwMTgtMDEtMTYNCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVu
dCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIEFjY2VzcyBDb250cm9sIExpc3QgKEFDTCkNCj4+
ICAgYmFzaWMgYnVpbGRpbmcgYmxvY2tzLg0KPj4NCj4+ICAgRWRpdG9yaWFsIE5vdGUgKFRvIGJl
IHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCj4+DQo+PiAgIFRoaXMgZHJhZnQgY29udGFpbnMgbWFu
eSBwbGFjZWhvbGRlciB2YWx1ZXMgdGhhdCBuZWVkIHRvIGJlIHJlcGxhY2VkDQo+PiAgIHdpdGgg
ZmluYWxpemVkIHZhbHVlcyBhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbi4gIFRoaXMgbm90ZQ0K
Pj4gICBzdW1tYXJpemVzIGFsbCBvZiB0aGUgc3Vic3RpdHV0aW9ucyB0aGF0IGFyZSBuZWVkZWQu
ICBQbGVhc2Ugbm90ZQ0KPj4gICB0aGF0IG5vIG90aGVyIFJGQyBFZGl0b3IgaW5zdHJ1Y3Rpb25z
IGFyZSBzcGVjaWZpZWQgYW55d2hlcmUgZWxzZSBpbg0KPj4gICB0aGlzIGRvY3VtZW50Lg0KPj4N
Cj4+ICAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHNob3J0aGFuZCByZWZlcmVu
Y2VzIHRvIGRyYWZ0cyBpbg0KPj4gICBwcm9ncmVzcy4gIFBsZWFzZSBhcHBseSB0aGUgZm9sbG93
aW5nIHJlcGxhY2VtZW50cw0KPj4NCj4+ICAgbyAgIlhYWFgiIC0tPiB0aGUgYXNzaWduZWQgUkZD
IHZhbHVlIGZvciB0aGlzIGRyYWZ0IGJvdGggaW4gdGhpcw0KPj4gICAgICBkcmFmdCBhbmQgaW4g
dGhlIFlBTkcgbW9kZWxzIHVuZGVyIHRoZSByZXZpc2lvbiBzdGF0ZW1lbnQuDQo+Pg0KPj4gICBv
ICBSZXZpc2lvbiBkYXRlIGluIG1vZGVsIG5lZWRzIHRvIGdldCB1cGRhdGVkIHdpdGggdGhlIGRh
dGUgdGhlDQo+PiAgICAgIGRyYWZ0IGdldHMgYXBwcm92ZWQuICBUaGUgZGF0ZSBhbHNvIG5lZWRz
IHRvIGdldCByZWZsZWN0ZWQgb24gdGhlDQo+PiAgICAgIGxpbmUgd2l0aCA8Q09ERSBCRUdJTlM+
Lg0KPj4NCj4+DQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk
cmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
bmV0bW9kLWFjbC1tb2RlbC8NCj4+DQo+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u
cyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1uZXRtb2QtYWNsLW1vZGVsLTE1DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNQ0KPj4NCj4+IEEgZGlmZiBmcm9t
IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTUNCj4+DQo+
Pg0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy
b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g
YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PiBJbnRlcm5l
dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6
Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kDQo+IE1haGVzaCBKZXRoYW5hbmRhbmkNCj4gbWpldGhhbmFuZGFuaUBnbWFpbC5j
b20NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0KDQoNCg0K


From nobody Wed Jan 17 14:26: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 5B2E312E3AE for ; Wed, 17 Jan 2018 14:26:31 -0800 (PST)
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 wRit3A0K3PNc for ; Wed, 17 Jan 2018 14:26:29 -0800 (PST)
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 C40BB12D834 for ; Wed, 17 Jan 2018 14:26:29 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0HLnCTr014994; Wed, 17 Jan 2018 13:55:08 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=FPmTOlFOfbNtcarKJC4/D4xdNrbgU/XQa0JSOFt/k9A=; b=fMy5oL2yG6TrFrqAytZW5GCDepGpB4SufaLdZvhJ1O1bK/+05A8GjqGTbk1NbvVeXrr8 Mss4i/IK3A2aW90mPjlY/r952kmNzGx1FIGVthsFZIDJz13eVm7FQ4cYxvnRUYNlb3OH D3M1Vf0vtABesyTfI2KJtDnttjasyUnbITTQXKCAGB/4xZgx8olQ0kBU5e8n3ghbEYjd Q/dPnZvmPdNOM/GVHRjcbGlL/5EvqnssjBsf44OHNp59ptbtBNIyv97JaGVZfA00h7Fi IDpFZzTyzJL+tJt0vC23rSgnUPbdA5m3nipniSnq2YFsCJQc6UE1aVgMzs64JaShWB1l jg== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0016.outbound.protection.outlook.com [216.32.181.16]) by mx0a-00273201.pphosted.com with ESMTP id 2fjeeeg1wa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 13:55:08 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3483.namprd05.prod.outlook.com (10.174.240.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 21:55:04 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 21:55:04 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIA==
Date: Wed, 17 Jan 2018 21:55:04 +0000
Message-ID: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
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; DM5PR05MB3483; 6:Ln7SJwhEg75WPCzd5Hob9X0IT5EviNshXB/hDnaSVRV26MJXzL3RIDpDbf7OqRcUHPKtTBJDqI/iSLV/ZtcICfIC82pWDGgBhDUgZn1NYGKX2mIL1Dz3fr/cMwYy/ZQcG+wqcvxqyHmPPuhHvb68V3cq4GOAH7BmiEr4hG8mTx3zJ+8vHk+PnYY8RDeuOaeQ9rgz80MWKuYcxdXNqqkToqKdqfqIzdVd737rrRKKWlCfUtjIUOIM/5n9vKEtyo1QJP2XYHpeJGxrSer0MfbZ+S5ZwkGaH3FQ2Hta0V9/bOKPR8NniAbAcUFDwxTjNjqFsLKy7KKEiaBeGnNwO4d+/phXuQ1aD5gC6G/epE6ievXGJOjoY095sHVv9tSpdSfo; 5:QU2ko7WO+3KdXjkOpmRsDbqBHPJB3bouUo579igQfl4dq5x+f0UsBGQwFLjnUxipCyvQgBAUuR+Oj0J9gVtkoP9a5oMPU0DwtlIpOi83uEgK320p3rnO46QmsPSoqr2Bvkp6nuFS6GvEXPctyV6Vcl1pI6cW/OGgofkv+NzB8Ws=; 24:NzCiJMsM0jr8ggMcLR/JOL6dgaQZGJuDvXXoL14joBqfMIeNldWdbvJadXx4/VGp3ZG+8Qp2EzpWQYuKtunP8dhYTlMi+0f40GCiRzb648w=; 7:Yhr8YwL6RyBSVkGutyXUtaPCYS31wHjc/xMOb2BdzV5WssIM8yPMZQCctZ5ZKXw+TQZo8bmHOb0yVwDfrVdw3DNgMTegj6Up5E9AVmvMc79vcaj/usrqqJEZzvg8K4ZHcuFt/sRCuikKPVNd4NWOH84fu28m2gpcapupvElVKvPUjAqSsuYCF97BUcNM69HP1Wl+cc0EdkGHn8FoPEu3UtSECvxczw/4gQyc0Jptzp1twgDk1PpGwgsnhrGCAd/u
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7c77ec28-221b-4be6-8fb4-08d55df4f789
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3483; 
x-ms-traffictypediagnostic: DM5PR05MB3483:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231042)(2400048)(944501161)(3002001)(10201501046)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3483; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR05MB3483; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39380400002)(376002)(39860400002)(189003)(199004)(305945005)(5660300001)(2501003)(3846002)(39060400002)(99286004)(6116002)(2351001)(6916009)(77096007)(25786009)(8936002)(68736007)(7736002)(81166006)(8676002)(33656002)(66066001)(230783001)(97736004)(81156014)(4326008)(106356001)(1730700003)(105586002)(36756003)(59450400001)(3660700001)(6512007)(82746002)(6436002)(14454004)(86362001)(5640700003)(83506002)(2900100001)(3280700002)(26005)(102836004)(83716003)(478600001)(58126008)(316002)(6486002)(54906003)(2906002)(6506007)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3483; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 7yD9qxh/JnU4C896hAf0CKdEA5Q2rVPNoz0a8U+JSIWBUtBUjlerXvI1zTtuFdYb1nVk2v1IlK+FVv6cy7wchQ==
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: 7c77ec28-221b-4be6-8fb4-08d55df4f789
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 21:55:04.8402 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3483
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_11:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=884 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801170296
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:26:31 -0000

QWxsLA0KDQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u
DQpkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTUuDQoNClRoaXMgd29ya2luZyBncm91cCBs
YXN0IGNhbGwgZW5kcyBvbiBKYW51YXJ5IDMxc3QuDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz
IHRvIHRoZSBORVRNT0QgbWFpbGluZyBsaXN0Lg0KDQpQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwg
IkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudA0KYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9y
IHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50
LCBldmVuIGZyb20gYXV0aG9ycy4NCg0KQWxzbywgY291bGQgdGhlIGF1dGhvcnMsIGV4cGxpY2l0
bHkgQ0MtZWQgb24gdGhpcyBlbWFpbCwNCnBsZWFzZSBjb25maXJtIGF0IHRoaXMgdGltZSB0aGF0
IHRoZXkgYXJlIHVuYXdhcmUgb2YNCmFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQpU
aGFuayB5b3UsDQpORVRNT0QgQ2hhaXJzDQoNCg==


From nobody Wed Jan 17 14:30: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 263CC12EA93 for ; Wed, 17 Jan 2018 14:30:11 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 tGMu5DSLLhL4 for ; Wed, 17 Jan 2018 14:30:08 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A53F12EAAE for ; Wed, 17 Jan 2018 14:29:57 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 29FD56BA; Wed, 17 Jan 2018 23:29:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id M8R2-V2dfaAc; Wed, 17 Jan 2018 23:29:55 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 23:29:55 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCDE020147; Wed, 17 Jan 2018 23:29:55 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L8sGivvEGxEC; Wed, 17 Jan 2018 23:29:55 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3122820144; Wed, 17 Jan 2018 23:29:55 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 493FF4214695; Wed, 17 Jan 2018 23:29:53 +0100 (CET)
Date: Wed, 17 Jan 2018 23:29:53 +0100
From: Juergen Schoenwaelder 
To: "Einar Nilsen-Nygaard (einarnn)" 
Cc: Alexander Clemm , "netmod@ietf.org" 
Message-ID: <20180117222953.s3wikqjjhleflgy4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Einar Nilsen-Nygaard (einarnn)" , Alexander Clemm , "netmod@ietf.org" 
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com> <20180117204422.bed7262buo3eshgv@elstar.local> <32996BEE-9920-45DC-BE26-625034315FC8@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <32996BEE-9920-45DC-BE26-625034315FC8@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:30:11 -0000

On Wed, Jan 17, 2018 at 09:17:24PM +0000, Einar Nilsen-Nygaard (einarnn) wrote:
> Juergen,
> 
> Thanks for that! That is a useful note, and it can reduce the problem space here, and I’m fine with that. As you may have seen from my response, though, my main concerns is about configuration.
> 
> Remind me — under NMDA will configuration leaves be reported back via “operational datastores”? Meaning that default configuration data is expected to always be returned when accessed via an “operational datastore”. Apologies if this is a dumb question, but I’ve not been able to track NMDA close enough to answer this question immediately.
>

With NMDA, you have the (short) configuration of the interface lo in
 and once this has been applied, you have the (possibly long)
applied configuration and state of the interface lo in .

/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 Jan 17 14:38: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 10B6812D875; Wed, 17 Jan 2018 14:38:10 -0800 (PST)
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_RP_MATCHES_RCVD=-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 M_yjNne9UF15; Wed, 17 Jan 2018 14:38:08 -0800 (PST)
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 E3F50120713; Wed, 17 Jan 2018 14:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1390; q=dns/txt; s=iport; t=1516228688; x=1517438288; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=O7rLBEnvcGIamgBHG0XIq6CQ9eQaECZDj1uWzAKX3tQ=; b=cihmPAcGsPvaPeQ4mFKbvC+1in4zO1ROP/mXIC9BhvSZjhJ7SHA0wSnU 6DO9M5fAy6467fgr091y3PCGYIJ1ETHe08GfUEQDBVzPqa00kw15rMxJ2 UL3x+bsg69RsHdAq93BxRhfgPbROHAcZoeIfnqO+fbO/X4gdNPDIg2vS2 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQCFz19a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj0UnmUQKGAuESU8ChScUAQEBAQEBAQEBayiFJAE?= =?us-ascii?q?BBAEBIQ8BBTYLEAkCDgoCAiYCAicwBgEMBgIBAYovEIkZnXCCJ4lNAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBD4cZghIMgnmDLwEBAoFvgxeCZQWjbJVTghmGHYN?= =?us-ascii?q?vh26PI4gMgTw2IoFQMhoIGxU9giqEV0E3jFABAQE?=
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200";  d="scan'208";a="1507610"
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; 17 Jan 2018 22:38:05 +0000
Received: from [10.61.199.10] ([10.61.199.10]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0HMc5P5000593; Wed, 17 Jan 2018 22:38:05 GMT
To: Mahesh Jethanandani , netconf 
Cc: NETMOD Working Group 
References:  <8DF69A95-4CE3-4329-A3E3-CD9D4F8C0178@juniper.net>
From: Robert Wilton 
Message-ID: 
Date: Wed, 17 Jan 2018 22:38:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <8DF69A95-4CE3-4329-A3E3-CD9D4F8C0178@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:38:10 -0000

I'm not aware of any IPR impacting either of these two drafts.

Rob


On 17/01/2018 19:02, Kent Watsen wrote:
> I'm not aware of any IPR impacting either of these two drafts.
>
> Kent // as co-author
>
>
> ===== original message =====
>
> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.
>
> This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.
>
> Authors please indicate whether you are aware of any IPR for either of the drafts.
>
> Thanks.
>
> Mahesh & Kent
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc&s=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw&e=
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Jan 17 14:43: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 3445312D875 for ; Wed, 17 Jan 2018 14:43:22 -0800 (PST)
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_RP_MATCHES_RCVD=-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 KSicrKPu9QiJ for ; Wed, 17 Jan 2018 14:43:20 -0800 (PST)
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 6C9D612EAA7 for ; Wed, 17 Jan 2018 14:43:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14756; q=dns/txt; s=iport; t=1516228999; x=1517438599; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=JXpJ0iHVpul5TUmbRSzekHWEsSFLb+snKbXxzz4rHKE=; b=diT2Z9cOx+qP8RBuVOnRY+kV0yQmEjHy2w9LFYdPgZcFG+3fCNgjGr/g wmJdMjInWrXBMadeClMgMr1cycEADZMzFTe3uDGEkhvZbNyLe0EG5TPLw 43wZerJeQhPxF5AzzgnAzJi1TLUXG+nGd6vjFhfPRVBidvVUloa3qhg8z w=;
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200"; d="scan'208,217";a="1509293"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 22:43:17 +0000
Received: from [10.61.199.10] ([10.61.199.10]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0HMhHkV002268; Wed, 17 Jan 2018 22:43:17 GMT
To: Alexander Clemm , "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" 
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
From: Robert Wilton 
Message-ID: <4edb6032-c632-5a33-7c0a-93ed5551f187@cisco.com>
Date: Wed, 17 Jan 2018 22:43:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------65A5B14ECA33FC56A3EC1495"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:43:22 -0000

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

HI Alex,

Note, that when it comes to the NMDA  datastore there are 
no default values.  Only the values that are "in use".

Thanks,
Rob


On 17/01/2018 19:09, Alexander Clemm wrote:
>
> Hi Einar,
>
> I suggest we add clarification that default values must be reported.  
> For on-change, clearly all changes need to be reported, whether the 
> change is to a default value or not, everything else would be 
> confusing.  Also for periodic, it would be confusing to leave out 
> readings when a value is at default  versus not (the object might also 
> have been deleted, etc).  So, I don’t think we need to add a flag or 
> such that would allow to exclude defaults which appear to be of 
> limited benefit to applications while introducing a lot more 
> complexity to deal with corner cases such as the ones described.
>
> --- Alex
>
> *From:*netmod [mailto:netmod-bounces@ietf.org] *On Behalf Of *Einar 
> Nilsen-Nygaard (einarnn)
> *Sent:* Wednesday, January 17, 2018 5:27 AM
> *To:* netmod@ietf.org
> *Subject:* [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 
> and default values and RFC 6243
>
> All,
>
> In discussions with some customers and on implementation, the issue of 
> defaults has come up. For get/get-config we have the “with defaults 
> capability” defined in RFC 6243 that allows us to control the 
> behaviour with respect to defaults. To remind folk with an example, we 
> could have:
>
> 
>  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
>     
>
>       
>
>     
>
>     
>  xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
>
>       report-all
>
>     
>
>   
>
> 
>
> The addition of the “with-defaults” tag and value determines the 
> behavior of the get in this example (taken from A.3.1 in RFC 6243 
> ).
>
> It strikes me that we need to have a similar mechanism for telemetry, 
> allowing a user to specify, for example, that for a periodic 
> subscription on a subtree, they also wish default values to be 
> reported. I think at minimum we need clarification on this, as section 
> 3.7 of draft-ietf-netconf-yang-push-12 currently says:
>
>     /The content of the update record is equivalent to the contents
>     that would be obtained had the same data been explicitly retrieved
>     using e.g., a NETCONF "get" operation, with the same filters applied./
>
> This text can currently only refer to a “get” as defined in RFC 6241 
> as there is no reference to RFC 6243 as yet. I think we need to 
> address this issue now to define expectations, even if it is to 
> explicitly not consider an RFC 6243-like mechanism or to say that we 
> only consider explicitly set values in telemetry, or…
>
> Cheers,
>
> Einar
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------65A5B14ECA33FC56A3EC1495
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
HI Alex,

    

    
Note, that when it comes to the NMDA <operational>
      datastore there are no default values.  Only the values that are
      "in use".

    

    Thanks,

    Rob

    

    

    
On 17/01/2018 19:09, Alexander Clemm
      wrote:

    

    

      
      
      
      

        
Hi
            Einar,

        
 

        
I
            suggest we add clarification that default values must be
            reported.  For on-change, clearly all changes need to be
            reported, whether the change is to a default value or not,
            everything else would be confusing.  Also for periodic, it
            would be confusing to leave out readings when a value is at
            default  versus not (the object might also have been
            deleted, etc).  So, I don’t think we need to add a flag or
            such that would allow to exclude defaults which appear to be
            of limited benefit to applications while introducing a lot
            more complexity to deal with corner cases such as the ones
            described. 
            

        
 

        
---
            Alex

        
 

        

          

            

              
From:
                  netmod [mailto:netmod-bounces@ietf.org]
                  On Behalf Of Einar Nilsen-Nygaard (einarnn)

                  Sent: Wednesday, January 17, 2018 5:27 AM

                  To: netmod@ietf.org

                  Subject: [netmod] yang-push issue:
                  draft-ietf-netconf-yang-push-12 and default values and
                  RFC 6243

            

          

          
 

          
All, 

          

            
 

          

          

            
In discussions with some customers and
              on implementation, the issue of defaults has come up. For
              get/get-config we have the “with defaults capability”
              defined in RFC 6243 that allows us to control the
              behaviour with respect to defaults. To remind folk with an
              example, we could have:

          

          

            
 

          

          

            

              
   
                  <rpc message-id="101"

            

            

              
   
                     
                   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

            

            

              
   
                    <get>

            

            

              
   
                      <filter type="subtree">

            

            

              
   
                        <interfaces xmlns="http://example.com/ns/interfaces"/>

            

            

              
   
                      </filter>

            

            

              
   
                      <with-defaults

            

            

              
   
                     
                   xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">

            

            

              
   
                        report-all

            

            

              
   
                      </with-defaults>

            

            

              
   
                    </get>

            

            

              
   
                  </rpc>

            

          

          

            
 

          

          

            
The addition of the “with-defaults” tag
              and value determines the behavior of the get in this
              example (taken from A.3.1 in RFC 6243).

          

          

            
 

          

          

            
It strikes me that we need to have a
              similar mechanism for telemetry, allowing a user to
              specify, for example, that for a periodic subscription on
              a subtree, they also wish default values to be reported. I
              think at minimum we need clarification on this, as section
              3.7 of draft-ietf-netconf-yang-push-12 currently says:

          

          

            
 

          

          

            

              

                
The content of the update record
                    is equivalent to the contents that would be obtained
                    had the same data been explicitly retrieved using
                    e.g., a NETCONF "get" operation, with the same
                    filters applied.

              

            

          

          
 

          

            
This text can currently only refer to a
              “get” as defined in RFC 6241 as there is no reference to
              RFC 6243 as yet. I think we need to address this issue now
              to define expectations, even if it is to explicitly not
              consider an RFC 6243-like mechanism or to say that we only
              consider explicitly set values in telemetry, or…

          

          

            
 

          

          

            

              
Cheers,

            

            

              
 

            

            

              
Einar

            

          

          

            
 

          

        

      

      

      

      

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


    

    

  


--------------65A5B14ECA33FC56A3EC1495--


From nobody Wed Jan 17 14:49: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 01B9612EAB6 for ; Wed, 17 Jan 2018 14:49:28 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 OHTUfdlubN0R for ; Wed, 17 Jan 2018 14:49:26 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228DE12EAA7 for ; Wed, 17 Jan 2018 14:49:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E04376BA; Wed, 17 Jan 2018 23:49:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id QiPiLrmD_tWT; Wed, 17 Jan 2018 23:49:23 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jan 2018 23:49:24 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C971F20149; Wed, 17 Jan 2018 23:49:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eGJAmGaOloPH; Wed, 17 Jan 2018 23:49:24 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F03920147; Wed, 17 Jan 2018 23:49:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6DBED42146FE; Wed, 17 Jan 2018 23:49:16 +0100 (CET)
Date: Wed, 17 Jan 2018 23:49:16 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Message-ID: <20180117224916.4xtwnxgsw3snzwvf@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:49:28 -0000

Paging through the document, I found the following:

- The main module uses YANG 1.1, others modules use YANG 1.0. I think
  it makes sense to generally use YANG 1.1. (The packet header module
  may not need YANG 1.1 but then the main module is YANG 1.1 anyway.)

- Since YANG 1.1 is used, the references to RFC6020 should be replaced
  with references to RFC 7950.

- The security consideration needs to be updated to follow the newer
  template (which also covers RESTCONF).

- There is an open issue in the document (section 8) - are we going
  to resolve that during WG last call or is this a leftover?

- There are references to RFCs in the YANG modules (in reference
  statement) that must also be listed in the text and added to the
  references section. This is why you usually find text of the form

    This YANG module imports types from [RFC...] and references
    [RFC...], [RFC...], and [RFC...].

/js

On Wed, Jan 17, 2018 at 09:55:04PM +0000, Kent Watsen wrote:
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
> 
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
> 
> Thank you,
> NETMOD Chairs
> 
> _______________________________________________
> 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 Wed Jan 17 14:54: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 3EBD912EAC1 for ; Wed, 17 Jan 2018 14:54:02 -0800 (PST)
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 G80XbMJ63R0C for ; Wed, 17 Jan 2018 14:54:00 -0800 (PST)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 4599312EAA8 for ; Wed, 17 Jan 2018 14:53:55 -0800 (PST)
Received: by mail-ot0-x234.google.com with SMTP id 53so18365715otj.2 for ; Wed, 17 Jan 2018 14:53:55 -0800 (PST)
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=n08pv6LDMHelXCZ++ffY50PZ0asNQq1LRYAauRc6L0s=; b=rS7DOq16AQThoj2HMU0aOT/RLfkFX1RYximfrDKqDzoXi1DJK/G0IWUu8cL4N4iqka D5XQvUowNSIf0RLWpzdjEspFXkRBuhU4dsTwp464O/M/e66mE0S1gcFHcuwRIne10DLv ogR004oVk6drHiYqEmwh8vYqHUXYlTynnhA8tqzczrhxKM/YgpXkAII4thFUU8twFpbh lpfk31ANIRDEQwctVfwUVMBzKIxnXJ3uL+pQkspv6BLxrGHTwT5bs11Ssk+o+zBVFWMU zi7X2rMTnCUvk1rs2BrZ0yB3Iv8QJgIClR6OJ1Eqapy4M47Xk9TA/EQ15h94EDCHqXSh sDsw==
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=n08pv6LDMHelXCZ++ffY50PZ0asNQq1LRYAauRc6L0s=; b=WlRmkS752/7nTiHbct/UNGcb7iZxc+E9g26udXfb8vnL7SivXfhXCn+23Dh2bzwn3Q bArPUaVidD7xJ/9vyy4nJ7cUOSs6PJPKXl7gbR2LknGQJ/WE4UXTe2oj9ubgfWOHXKcs 34xOflRSV1Mb9PYLxX7D09JdvdNy3x3kBHutQJgdKiQ2G1SdUlDtrUGkRqcQaEWTfZP4 YgQCyjg85XPnTrga1kXwAmqcDjjwBipw3lskiyLcPY+i72X/F0JkrMyTQGpHeaFapUMq bqlH39fwSBvGIpj74/Vu+ch0aAvE++lvI+p9bRAdc/TRivNAUDD8N2aTrdw7tlT/9fhI 8DAQ==
X-Gm-Message-State: AKwxytfE6rr1auIwX5ehTGehEU6P6XQrHA9AU9UhL7+wOVJz16Jgofi2 mX+uRVnSnEh3KvMbS2KNc54=
X-Google-Smtp-Source: ACJfBouN8hDFI4mIwjNF2Ni/jyWPaWWk/Oy2zTxsQLezu2B3ZS0+48oRqwaYnBlsSe1jnpaNCrWV3Q==
X-Received: by 10.157.61.131 with SMTP id l3mr2045119otc.23.1516229634425; Wed, 17 Jan 2018 14:53:54 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d998:dcd9:6c19:6a28]) by smtp.gmail.com with ESMTPSA id l79sm2320783oig.41.2018.01.17.14.53.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 14:53:53 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: <20180117224916.4xtwnxgsw3snzwvf@elstar.local>
Date: Wed, 17 Jan 2018 14:53:51 -0800
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:54:04 -0000

> On Jan 17, 2018, at 2:49 PM, Juergen Schoenwaelder =
 wrote:
>=20
> Paging through the document, I found the following:
>=20
> - The main module uses YANG 1.1, others modules use YANG 1.0. I think
>  it makes sense to generally use YANG 1.1. (The packet header module
>  may not need YANG 1.1 but then the main module is YANG 1.1 anyway.)

Will update.

>=20
> - Since YANG 1.1 is used, the references to RFC6020 should be replaced
>  with references to RFC 7950.

Will update.

>=20
> - The security consideration needs to be updated to follow the newer
>  template (which also covers RESTCONF).

Will add.

>=20
> - There is an open issue in the document (section 8) - are we going
>  to resolve that during WG last call or is this a leftover?

This will be resolved in the next version of the module. It is =
documented under Issues tab in GitHub. Should we remove it from the =
draft?

>=20
> - There are references to RFCs in the YANG modules (in reference
>  statement) that must also be listed in the text and added to the
>  references section. This is why you usually find text of the form
>=20
>    This YANG module imports types from [RFC...] and references
>    [RFC...], [RFC...], and [RFC=E2=80=A6].

Will add.

>=20
> /js
>=20
> On Wed, Jan 17, 2018 at 09:55:04PM +0000, Kent Watsen wrote:
>> All,
>>=20
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-15.
>>=20
>> This working group last call ends on January 31st.
>> Please send your comments to the NETMOD mailing list.
>>=20
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>=20
>> Also, could the authors, explicitly CC-ed on this email,
>> please confirm at this time that they are unaware of
>> any IPR related to this draft.
>>=20
>> Thank you,
>> NETMOD Chairs
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=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

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Wed Jan 17 14:56: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 0C92112EABC for ; Wed, 17 Jan 2018 14:56:18 -0800 (PST)
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 1FwHdDmUg_hY for ; Wed, 17 Jan 2018 14:56:16 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 97A3D12EAAB for ; Wed, 17 Jan 2018 14:56:16 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id 53so18370486otj.2 for ; Wed, 17 Jan 2018 14:56:16 -0800 (PST)
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=dSVPyz0ukB9GnceEMJscR1lwX/LqCw+TCenLwnTvBvU=; b=oPPuhI42To/qG8Bbs5ocbPjbpNMKjteq7GgNel2icbXCE4KvAgXTtZEfvrCKilGcyB vHkOlIywXMYod00ULGPESvya8xfgIGRaWiYVlNuecifP+ih2nc/5H14VBtcWpggVaBkV sbAiwZG8DFbKhFa24qHZm2GC9U3Jlm5e8ecsi4g1HdGppdA3WWMQSymdbX8/xvjT32OT mum/yyYcme0kCof52saWXeZsF9gWuP1eue9avkR1xqHW4+NLZuvorbViF2Z1FWkhAw+G 5M5tyaqPsUeiLHls3AxPnUrVWZf0pvSITWqipCjZpE+VdJlUj+7HspvEYRCN8nEldvFV kcFw==
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=dSVPyz0ukB9GnceEMJscR1lwX/LqCw+TCenLwnTvBvU=; b=ijwHsiToV3YV9SsIIic5TSfmsRROZ1DTAoCybpafStPG5JQFKm4S568IiCzT0qrCLR NR+r1ZIMGxCjn8lmusFZ36ZKl7FPqrv4CnucEm41vfmSvuDUfxNtMKxbFXq5U8rMDMIX FTNzCTaAcDvbURRYZVplU2VElCjVMBUDQVblDXvvsrT6DHNQwzwoIaILrDJv+w31JJa9 PPlZVBYdmk/4mw+VsBGgypr1jmk5IyQ3JdPeV8tBuOm/W5KpBWwvZuUWOq2o5R9gFRXb l0zC14H7B5O4rZwBZK49XeO9GG0LKgYrHKYUYXQwfz1C3JVsRGJr54CYKMpRkgz4gQki RF2g==
X-Gm-Message-State: AKwxytcVb4KARBPWB2LsvBLumgM34IU5xwB5c5sg7elfCgdNBtTGCuQL 11d1Akr69BrTTl9XykBMFIJqLvn1
X-Google-Smtp-Source: ACJfBotb++I7ksP6Fr1cYQkZGkoHKK3Zq4QP4Xq7EVDFn3YPtNLAEs5txN+NGs+kXis2Fe70favotA==
X-Received: by 10.157.20.154 with SMTP id d26mr2044212ote.29.1516229776020; Wed, 17 Jan 2018 14:56:16 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d998:dcd9:6c19:6a28]) by smtp.gmail.com with ESMTPSA id 125sm2430831oig.7.2018.01.17.14.56.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 14:56:15 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
Date: Wed, 17 Jan 2018 14:56:13 -0800
Cc: "netmod@ietf.org" , Lisa Huang , Sonal Agarwal , Dana Blair 
Content-Transfer-Encoding: 7bit
Message-Id: <78A6F57A-CEAD-4FE8-B484-8BDC0EB05EAB@gmail.com>
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 22:56:18 -0000

I am not aware of any IPR related to the draft.

> On Jan 17, 2018, at 1:55 PM, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
> 
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
> 
> Thank you,
> NETMOD Chairs
> 

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Wed Jan 17 15:03: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 5A17612EACC for ; Wed, 17 Jan 2018 15:03:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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, 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 Nd8TWQecmmiz for ; Wed, 17 Jan 2018 15:03:02 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 27E6012EACE for ; Wed, 17 Jan 2018 15:03:00 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id d6so12329926pgv.2 for ; Wed, 17 Jan 2018 15:03:00 -0800 (PST)
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=b4IrbmiMFJ/BN6GWep+khg7uCheiWNh/S+Bs7CNi008=; b=jGcgoxBKlbCZowa3GyZdlWeMyfbJr3m52L+XcleA8fWXngIn1IQrVCCbLgloJhb0rG cQ8VSk9/T8au2u/z5/KzXcQQnR3rTeSZY+UilfCrySX6zVVvHhTAzWq17OyIBBSA/WqF 1+t7SomXr5fTsqEwDEKFycfI3k884grNL6FDEo0CivBr8/mnmBi2I/1noQj6sJpS4IlS UuxP6uD+yQPz7Nn+oIg4Qvjuu42lTFfCoS6XdPE4g/8uF01K+TqyJVUXKZEV/9BH3Fiw pN8xHkvIvyH0sEIiLRuu3NJliyenZ5l1/sgi38SS6cop9ZKHyP/TlcbcCTPV0R1NMeu2 8Qiw==
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=b4IrbmiMFJ/BN6GWep+khg7uCheiWNh/S+Bs7CNi008=; b=L+A6KkSL3RP/4mdDXYPMmKoJNwXxt7j1tgYzJbY/uKRiIwlbJ5edUokuRZy+vAtEo/ q1gBgPuezSgXjvfovf9mdw+zsQglBu94oxGUPgBeWJ9E1/PFT4VuVp0HPQb0JwC/1xcA nV6rHvt++KDn1BTBw1PBXMgYBy4ZL+dh501D5U4q/4dPsNlr3x6iot6pZGpPuc/MC7RN 9AeEiHUM6CDc1Ve2Qee89GMVJGAIe5vfi2ppZ2VbFSkH1tB/9At7p5YMyRvOkH+JxYKl X+G/sTlqTCdEzhsJmv+4fX97XU8ntFRauM4dtR/+ypFqr1LLSPT+GZk8ab7NA31caTWM xpQQ==
X-Gm-Message-State: AKwxytffsA/j/B27pj+Xu1Lex0/EKJxtpylYbIQ2o+nSQiZhiZ+V/oZx K3zu23V+Y5DyfozMcRmquHE=
X-Google-Smtp-Source: ACJfBosNS8VxrVDjGAysNJz9tc8xxbMcJJKq2WZDUeymRKk2Ih+Mf3N/YUS1GAm/FOcmfA1WuGFNDQ==
X-Received: by 10.98.252.82 with SMTP id e79mr21101013pfh.159.1516230179746; Wed, 17 Jan 2018 15:02:59 -0800 (PST)
Received: from ?IPv6:2001:420:30d:1268:f0f9:f5e6:cf19:82f2? ([2001:420:30d:1268:f0f9:f5e6:cf19:82f2]) by smtp.gmail.com with ESMTPSA id b6sm8087609pgc.2.2018.01.17.15.02.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 15:02:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Sonal Agarwal 
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
Date: Wed, 17 Jan 2018 15:02:58 -0800
Cc: "netmod@ietf.org" , Mahesh Jethanandani , Lisa Huang , Dana Blair 
Content-Transfer-Encoding: 7bit
Message-Id: <85C388DD-BCBD-4B8A-8CC1-9E794878C677@gmail.com>
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
To: Kent Watsen 
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 23:03:03 -0000

I am not aware of any IPR impacting this draft.

> On Jan 17, 2018, at 1:55 PM, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
> 
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
> 
> Thank you,
> NETMOD Chairs
> 


From nobody Wed Jan 17 15:33: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 6ABAF12EA59 for ; Wed, 17 Jan 2018 15:33:12 -0800 (PST)
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 hl2Ba6b9cPoi for ; Wed, 17 Jan 2018 15:33:10 -0800 (PST)
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 C2ADA12D893 for ; Wed, 17 Jan 2018 15:33:10 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0HNTVv8026215; Wed, 17 Jan 2018 15:33:09 -0800
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=+K8RGctL/mJU9I8US+ED4YploCnYmqZmpBJCv813CYg=; b=2IRxg2aPdNZkH9TBHJOQAXhsWVylwnY/bW9P88R5/6P41BE1VEbTduUEi0W5kv3YqeHh 6v7vKbaUv33JCTX02u7n1I2RSTE3tFbK0o6j1nySAC/2Q4c0NlIr/vkh1QRim1Wwf9Qe KQB8cR7pj29XyP/xN+JI1wqGIBammabSFaYKZw+/arnfky03WAwTswbb2ApT/6LzPFbu RczHNNS320uvo4hNnkdISJiWYVyRliGjzTbH4wkDxiAPqsuap91a6GhKYuezj4sJK3lH tfrJp02HAGv+wwUtIDCpeHFVdjNIRbXBiB9ROcsMIbSXaW3L1uzSWdnfjVei64xZzia+ /Q== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0114.outbound.protection.outlook.com [207.46.163.114]) by mx0a-00273201.pphosted.com with ESMTP id 2fjg3kr0pa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 15:33:09 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2812.namprd05.prod.outlook.com (10.168.175.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Wed, 17 Jan 2018 23:33:07 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Wed, 17 Jan 2018 23:33:07 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKN4qxIAgAABR4D//7cngA==
Date: Wed, 17 Jan 2018 23:33:07 +0000
Message-ID: 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> 
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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2812; 7:8T8T9elASXUUFY+O8Yq20N9tpeX96+fg0E6OZz5T9SR71XW5Z8V/4GuesR+C8DoVr97MhNiUToX6SH8q0SlmX+NZUf0E1+zW7SzbcGnxDFDZ8dnR7ZSjjmlr9nBpOAqlgaKkMbv0uuvTxGZEz9F0+8Ur0GHUlIccwYVd9STwGnj3lS+wjuNldyUFOTyrw4SFMzU2yqjlmTZG2JqSsGlonpc9+C8ZixQ0DyTWWhmwT+5qnO5EiUPqyt8ZdnxNlhXh
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d2c1cad6-f043-439b-ddc6-08d55e02a9e6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2812; 
x-ms-traffictypediagnostic: DM5PR05MB2812:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231045)(2400053)(944501161)(6055026)(6041268)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB2812; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR05MB2812; 
x-forefront-prvs: 0555EC8317
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(396003)(366004)(39380400002)(189003)(199004)(105586002)(102836004)(68736007)(4326008)(25786009)(81156014)(6246003)(39060400002)(8676002)(81166006)(2950100002)(59450400001)(83506002)(77096007)(82746002)(316002)(26005)(6506007)(99286004)(76176011)(33656002)(86362001)(83716003)(58126008)(110136005)(3280700002)(6116002)(66066001)(3846002)(14454004)(478600001)(53936002)(2906002)(36756003)(305945005)(97736004)(230783001)(106356001)(7736002)(2900100001)(5660300001)(8936002)(3660700001)(6512007)(229853002)(6486002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2812; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: k+RvcC8N7/2KkaYTfrH73fZBgoirKu1mRLc7HXRS2ADH/Vlta6SmxoDJFDIANcmbX+aPrvzeMpEQarIn6kjB1Q==
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: d2c1cad6-f043-439b-ddc6-08d55e02a9e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 23:33:07.5593 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2812
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-17_12:, , 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-1711220000 definitions=main-1801170318
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 23:33:12 -0000

DQpIIE1haGVzaCwNCg0KPj4gLSBUaGVyZSBpcyBhbiBvcGVuIGlzc3VlIGluIHRoZSBkb2N1bWVu
dCAoc2VjdGlvbiA4KSAtIGFyZSB3ZSBnb2luZw0KPj4gIHRvIHJlc29sdmUgdGhhdCBkdXJpbmcg
V0cgbGFzdCBjYWxsIG9yIGlzIHRoaXMgYSBsZWZ0b3Zlcj8NCj4NCj4gVGhpcyB3aWxsIGJlIHJl
c29sdmVkIGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIG1vZHVsZS4gSXQgaXMNCj4gZG9jdW1l
bnRlZCB1bmRlciBJc3N1ZXMgdGFiIGluIEdpdEh1Yi4gU2hvdWxkIHdlIHJlbW92ZSBpdCBmcm9t
DQo+IHRoZSBkcmFmdD8NCg0KTW9zdCBvZiBKdWVyZ2VuJ3MgY29tbWVudHMgYXJlIGVkaXRvcmlh
bCBpbiBuYXR1cmUgYW5kIGNhbiB0cnVseSBiZSBoYW5kbGVkIGFzIHBhcnQgb2YgdGhlIExDIHBy
b2Nlc3MsIGJ1dCB0aGlzIG9wZW4gaXNzdWUgaGFzIG1lIHdvcnJpZWQsIGFzIGl0IG1heSByZXN1
bHQgaW4gYSBzaWduaWZpY2FudCB0ZWNobmljYWwgY2hhbmdlLiAgDQoNCldoYXQgd2lsbCBpdCB0
YWtlIHRvIGNsb3NlIHRoaXMgb3BlbiBpc3N1ZT8gIElzIGl0IGp1c3QgYSBtYXR0ZXIgb2YgdGhl
IGdldHRpbmcgdGhlIFdHIHRvIGFncmVlIHRoYXQgaXQncyBub3QgYW4gaXNzdWUsIG9yIGRvIHdl
IGFscmVhZHkga25vdyB0aGF0IGl0IGlzIGEgcmVhbCBpc3N1ZSBhbmQgb25seSB0aGUgc29sdXRp
b24gaXMgcGVuZGluZz8NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQo=


From nobody Wed Jan 17 15:47:16 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 8134F12EA97 for ; Wed, 17 Jan 2018 15:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 kBCLEG_HmMdh for ; Wed, 17 Jan 2018 15:47:12 -0800 (PST)
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 D346412D86E for ; Wed, 17 Jan 2018 15:47:11 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CAE0FB564587B for ; Wed, 17 Jan 2018 23:47:07 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 23:47:09 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Wed, 17 Jan 2018 15:47:02 -0800
From: Alexander Clemm 
To: Robert Wilton , "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" 
Thread-Topic: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bYiGDflCZ3h0a24DFWm/LfU6N4bRCwgADDAID//4tN0A==
Date: Wed, 17 Jan 2018 23:47:01 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB93F@sjceml521-mbx.china.huawei.com>
References: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EADB6A6@sjceml521-mbx.china.huawei.com> <4edb6032-c632-5a33-7c0a-93ed5551f187@cisco.com>
In-Reply-To: <4edb6032-c632-5a33-7c0a-93ed5551f187@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.24]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB93Fsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jan 2018 23:47:14 -0000

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

VGhhbmtzLCBSb2IgYW5kIEp1ZXJnZW4sIGZvciBwb2ludGluZyB0aGlzIG91dCENCg0KSSBndWVz
cyB3ZSBzaG91bGQgYWRkIHRoaXMgdG8gdGhlIHRleHQgYXMgd2VsbC4NCg0KLS0tIEFsZXgNCg0K
RnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KU2VudDogV2Vk
bmVzZGF5LCBKYW51YXJ5IDE3LCAyMDE4IDI6NDMgUE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFs
ZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPjsgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4p
IDxlaW5hcm5uQGNpc2NvLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRt
b2RdIHlhbmctcHVzaCBpc3N1ZTogZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMiBhbmQg
ZGVmYXVsdCB2YWx1ZXMgYW5kIFJGQyA2MjQzDQoNCg0KSEkgQWxleCwNCg0KTm90ZSwgdGhhdCB3
aGVuIGl0IGNvbWVzIHRvIHRoZSBOTURBIDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlIHRoZXJlIGFy
ZSBubyBkZWZhdWx0IHZhbHVlcy4gIE9ubHkgdGhlIHZhbHVlcyB0aGF0IGFyZSAiaW4gdXNlIi4N
ClRoYW5rcywNClJvYg0KDQpPbiAxNy8wMS8yMDE4IDE5OjA5LCBBbGV4YW5kZXIgQ2xlbW0gd3Jv
dGU6DQpIaSBFaW5hciwNCg0KSSBzdWdnZXN0IHdlIGFkZCBjbGFyaWZpY2F0aW9uIHRoYXQgZGVm
YXVsdCB2YWx1ZXMgbXVzdCBiZSByZXBvcnRlZC4gIEZvciBvbi1jaGFuZ2UsIGNsZWFybHkgYWxs
IGNoYW5nZXMgbmVlZCB0byBiZSByZXBvcnRlZCwgd2hldGhlciB0aGUgY2hhbmdlIGlzIHRvIGEg
ZGVmYXVsdCB2YWx1ZSBvciBub3QsIGV2ZXJ5dGhpbmcgZWxzZSB3b3VsZCBiZSBjb25mdXNpbmcu
ICBBbHNvIGZvciBwZXJpb2RpYywgaXQgd291bGQgYmUgY29uZnVzaW5nIHRvIGxlYXZlIG91dCBy
ZWFkaW5ncyB3aGVuIGEgdmFsdWUgaXMgYXQgZGVmYXVsdCAgdmVyc3VzIG5vdCAodGhlIG9iamVj
dCBtaWdodCBhbHNvIGhhdmUgYmVlbiBkZWxldGVkLCBldGMpLiAgU28sIEkgZG9u4oCZdCB0aGlu
ayB3ZSBuZWVkIHRvIGFkZCBhIGZsYWcgb3Igc3VjaCB0aGF0IHdvdWxkIGFsbG93IHRvIGV4Y2x1
ZGUgZGVmYXVsdHMgd2hpY2ggYXBwZWFyIHRvIGJlIG9mIGxpbWl0ZWQgYmVuZWZpdCB0byBhcHBs
aWNhdGlvbnMgd2hpbGUgaW50cm9kdWNpbmcgYSBsb3QgbW9yZSBjb21wbGV4aXR5IHRvIGRlYWwg
d2l0aCBjb3JuZXIgY2FzZXMgc3VjaCBhcyB0aGUgb25lcyBkZXNjcmliZWQuDQoNCi0tLSBBbGV4
DQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pDQpTZW50OiBXZWRuZXNkYXksIEph
bnVhcnkgMTcsIDIwMTggNToyNyBBTQ0KVG86IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k
QGlldGYub3JnPg0KU3ViamVjdDogW25ldG1vZF0geWFuZy1wdXNoIGlzc3VlOiBkcmFmdC1pZXRm
LW5ldGNvbmYteWFuZy1wdXNoLTEyIGFuZCBkZWZhdWx0IHZhbHVlcyBhbmQgUkZDIDYyNDMNCg0K
QWxsLA0KDQpJbiBkaXNjdXNzaW9ucyB3aXRoIHNvbWUgY3VzdG9tZXJzIGFuZCBvbiBpbXBsZW1l
bnRhdGlvbiwgdGhlIGlzc3VlIG9mIGRlZmF1bHRzIGhhcyBjb21lIHVwLiBGb3IgZ2V0L2dldC1j
b25maWcgd2UgaGF2ZSB0aGUg4oCcd2l0aCBkZWZhdWx0cyBjYXBhYmlsaXR54oCdIGRlZmluZWQg
aW4gUkZDIDYyNDMgdGhhdCBhbGxvd3MgdXMgdG8gY29udHJvbCB0aGUgYmVoYXZpb3VyIHdpdGgg
cmVzcGVjdCB0byBkZWZhdWx0cy4gVG8gcmVtaW5kIGZvbGsgd2l0aCBhbiBleGFtcGxlLCB3ZSBj
b3VsZCBoYXZlOg0KDQogICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICB4bWxucz0i
dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgICAgIDxnZXQ+DQog
ICAgICAgIDxmaWx0ZXIgdHlwZT0ic3VidHJlZSI+DQogICAgICAgICAgPGludGVyZmFjZXMgeG1s
bnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pbnRlcmZhY2VzIi8+DQogICAgICAgIDwvZmlsdGVy
Pg0KICAgICAgICA8d2l0aC1kZWZhdWx0cw0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFt
czp4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cyI+DQogICAgICAgICAgcmVw
b3J0LWFsbA0KICAgICAgICA8L3dpdGgtZGVmYXVsdHM+DQogICAgICA8L2dldD4NCiAgICA8L3Jw
Yz4NCg0KVGhlIGFkZGl0aW9uIG9mIHRoZSDigJx3aXRoLWRlZmF1bHRz4oCdIHRhZyBhbmQgdmFs
dWUgZGV0ZXJtaW5lcyB0aGUgYmVoYXZpb3Igb2YgdGhlIGdldCBpbiB0aGlzIGV4YW1wbGUgKHRh
a2VuIGZyb20gQS4zLjEgaW4gUkZDIDYyNDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzYyNDMjcGFnZS0yMj4pLg0KDQpJdCBzdHJpa2VzIG1lIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEg
c2ltaWxhciBtZWNoYW5pc20gZm9yIHRlbGVtZXRyeSwgYWxsb3dpbmcgYSB1c2VyIHRvIHNwZWNp
ZnksIGZvciBleGFtcGxlLCB0aGF0IGZvciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiBvbiBhIHN1
YnRyZWUsIHRoZXkgYWxzbyB3aXNoIGRlZmF1bHQgdmFsdWVzIHRvIGJlIHJlcG9ydGVkLiBJIHRo
aW5rIGF0IG1pbmltdW0gd2UgbmVlZCBjbGFyaWZpY2F0aW9uIG9uIHRoaXMsIGFzIHNlY3Rpb24g
My43IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgY3VycmVudGx5IHNheXM6DQoN
ClRoZSBjb250ZW50IG9mIHRoZSB1cGRhdGUgcmVjb3JkIGlzIGVxdWl2YWxlbnQgdG8gdGhlIGNv
bnRlbnRzIHRoYXQgd291bGQgYmUgb2J0YWluZWQgaGFkIHRoZSBzYW1lIGRhdGEgYmVlbiBleHBs
aWNpdGx5IHJldHJpZXZlZCB1c2luZyBlLmcuLCBhIE5FVENPTkYgImdldCIgb3BlcmF0aW9uLCB3
aXRoIHRoZSBzYW1lIGZpbHRlcnMgYXBwbGllZC4NCg0KVGhpcyB0ZXh0IGNhbiBjdXJyZW50bHkg
b25seSByZWZlciB0byBhIOKAnGdldOKAnSBhcyBkZWZpbmVkIGluIFJGQyA2MjQxIGFzIHRoZXJl
IGlzIG5vIHJlZmVyZW5jZSB0byBSRkMgNjI0MyBhcyB5ZXQuIEkgdGhpbmsgd2UgbmVlZCB0byBh
ZGRyZXNzIHRoaXMgaXNzdWUgbm93IHRvIGRlZmluZSBleHBlY3RhdGlvbnMsIGV2ZW4gaWYgaXQg
aXMgdG8gZXhwbGljaXRseSBub3QgY29uc2lkZXIgYW4gUkZDIDYyNDMtbGlrZSBtZWNoYW5pc20g
b3IgdG8gc2F5IHRoYXQgd2Ugb25seSBjb25zaWRlciBleHBsaWNpdGx5IHNldCB2YWx1ZXMgaW4g
dGVsZW1ldHJ5LCBvcuKApg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0bW9kIG1haWxpbmcg
bGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB93Fsjceml521mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1
IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw
YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N
c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s
bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t
YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u
dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30N
CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIFJvYiBhbmQg
SnVlcmdlbiwgZm9yIHBvaW50aW5nIHRoaXMgb3V0ISZuYnNwOw0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGd1ZXNzIHdlIHNob3VsZCBhZGQgdGhpcyB0byB0
aGUgdGV4dCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+LS0tIEFsZXgmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl
IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv
d3RleHQiPiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE3LCAyMDE4IDI6NDMgUE08YnI+DQo8Yj5U
bzo8L2I+IEFsZXhhbmRlciBDbGVtbSAmbHQ7YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20mZ3Q7
OyBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgJmx0O2VpbmFybm5AY2lzY28uY29tJmd0
OzsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSB5YW5n
LXB1c2ggaXNzdWU6IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTIgYW5kIGRlZmF1bHQg
dmFsdWVzIGFuZCBSRkMgNjI0MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhJIEFsZXgs
PG86cD48L286cD48L3A+DQo8cD5Ob3RlLCB0aGF0IHdoZW4gaXQgY29tZXMgdG8gdGhlIE5NREEg
Jmx0O29wZXJhdGlvbmFsJmd0OyBkYXRhc3RvcmUgdGhlcmUgYXJlIG5vIGRlZmF1bHQgdmFsdWVz
LiZuYnNwOyBPbmx5IHRoZSB2YWx1ZXMgdGhhdCBhcmUgJnF1b3Q7aW4gdXNlJnF1b3Q7LjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij5UaGFua3MsPGJyPg0KUm9iPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMDEvMjAxOCAxOTowOSwgQWxleGFuZGVyIENsZW1t
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBFaW5hciw8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc3VnZ2VzdCB3ZSBhZGQgY2xhcmlmaWNhdGlvbiB0
aGF0IGRlZmF1bHQgdmFsdWVzIG11c3QgYmUgcmVwb3J0ZWQuJm5ic3A7IEZvciBvbi1jaGFuZ2Us
IGNsZWFybHkgYWxsIGNoYW5nZXMgbmVlZCB0byBiZSByZXBvcnRlZCwgd2hldGhlciB0aGUgY2hh
bmdlIGlzIHRvIGEgZGVmYXVsdA0KIHZhbHVlIG9yIG5vdCwgZXZlcnl0aGluZyBlbHNlIHdvdWxk
IGJlIGNvbmZ1c2luZy4mbmJzcDsgQWxzbyBmb3IgcGVyaW9kaWMsIGl0IHdvdWxkIGJlIGNvbmZ1
c2luZyB0byBsZWF2ZSBvdXQgcmVhZGluZ3Mgd2hlbiBhIHZhbHVlIGlzIGF0IGRlZmF1bHQmbmJz
cDsgdmVyc3VzIG5vdCAodGhlIG9iamVjdCBtaWdodCBhbHNvIGhhdmUgYmVlbiBkZWxldGVkLCBl
dGMpLiZuYnNwOyBTbywgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gYWRkIGEgZmxhZyBvciBz
dWNoIHRoYXQgd291bGQNCiBhbGxvdyB0byBleGNsdWRlIGRlZmF1bHRzIHdoaWNoIGFwcGVhciB0
byBiZSBvZiBsaW1pdGVkIGJlbmVmaXQgdG8gYXBwbGljYXRpb25zIHdoaWxlIGludHJvZHVjaW5n
IGEgbG90IG1vcmUgY29tcGxleGl0eSB0byBkZWFsIHdpdGggY29ybmVyIGNhc2VzIHN1Y2ggYXMg
dGhlIG9uZXMgZGVzY3JpYmVkLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4tLS0gQWxleDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi
bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCBbPGEgaHJlZj0ibWFpbHRv
Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubik8
YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE3LCAyMDE4IDU6MjcgQU08YnI+
DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW25ldG1vZF0geWFuZy1wdXNoIGlzc3VlOiBk
cmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTEyIGFuZCBkZWZhdWx0IHZhbHVlcyBhbmQgUkZD
IDYyNDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGws
IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZGlzY3Vz
c2lvbnMgd2l0aCBzb21lIGN1c3RvbWVycyBhbmQgb24gaW1wbGVtZW50YXRpb24sIHRoZSBpc3N1
ZSBvZiBkZWZhdWx0cyBoYXMgY29tZSB1cC4gRm9yIGdldC9nZXQtY29uZmlnIHdlIGhhdmUgdGhl
IOKAnHdpdGggZGVmYXVsdHMgY2FwYWJpbGl0eeKAnSBkZWZpbmVkIGluIFJGQyA2MjQzIHRoYXQg
YWxsb3dzIHVzIHRvIGNvbnRyb2wgdGhlIGJlaGF2aW91ciB3aXRoIHJlc3BlY3QgdG8gZGVmYXVs
dHMuDQogVG8gcmVtaW5kIGZvbGsgd2l0aCBhbiBleGFtcGxlLCB3ZSBjb3VsZCBoYXZlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJmx0O3JwYyBt
ZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy
aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM9JnF1b3Q7dXJuOmll
dGY6cGFyYW1zOjxhIGhyZWY9InhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj54bWw6bnM6bmV0Y29u
ZjpiYXNlOjEuMDwvYT4mcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJp
ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtnZXQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZmlsdGVyIHR5
cGU9JnF1b3Q7c3VidHJlZSZxdW90OyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291
cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aW50ZXJmYWNlcyB4
bWxucz0mcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvaW50ZXJmYWNlcyI+aHR0
cDovL2V4YW1wbGUuY29tL25zL2ludGVyZmFjZXM8L2E+JnF1b3Q7LyZndDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsv
ZmlsdGVyJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJmx0O3dpdGgtZGVmYXVsdHM8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zPSZx
dW90O3VybjppZXRmOnBhcmFtczo8YSBocmVmPSJ4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtd2l0
aC1kZWZhdWx0cyI+eG1sOm5zOnlhbmc6aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHM8L2E+JnF1
b3Q7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlcG9ydC1hbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvd2l0aC1kZWZhdWx0
cyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJmx0Oy9nZXQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZu
YnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhZGRpdGlvbiBvZiB0aGUg
4oCcPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPndpdGgtZGVmYXVsdHM8L3NwYW4+
4oCdIHRhZyBhbmQgdmFsdWUgZGV0ZXJtaW5lcyB0aGUgYmVoYXZpb3Igb2YgdGhlIGdldCBpbiB0
aGlzIGV4YW1wbGUgKHRha2VuIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNjI0MyNwYWdlLTIyIj5BLjMuMSBpbiBSRkMgNjI0MzwvYT4pLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzdHJpa2Vz
IG1lIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgc2ltaWxhciBtZWNoYW5pc20gZm9yIHRlbGVtZXRy
eSwgYWxsb3dpbmcgYSB1c2VyIHRvIHNwZWNpZnksIGZvciBleGFtcGxlLCB0aGF0IGZvciBhIHBl
cmlvZGljIHN1YnNjcmlwdGlvbiBvbiBhIHN1YnRyZWUsIHRoZXkgYWxzbyB3aXNoIGRlZmF1bHQg
dmFsdWVzIHRvIGJlIHJlcG9ydGVkLiBJIHRoaW5rIGF0IG1pbmltdW0gd2UgbmVlZCBjbGFyaWZp
Y2F0aW9uDQogb24gdGhpcywgYXMgc2VjdGlvbiAzLjcgb2YmbmJzcDtkcmFmdC1pZXRmLW5ldGNv
bmYteWFuZy1wdXNoLTEyIGN1cnJlbnRseSBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48aT5UaGUgY29udGVudCBvZiB0aGUgdXBkYXRlIHJlY29yZCBpcyBl
cXVpdmFsZW50IHRvIHRoZSBjb250ZW50cyB0aGF0IHdvdWxkIGJlIG9idGFpbmVkIGhhZCB0aGUg
c2FtZSBkYXRhIGJlZW4gZXhwbGljaXRseSByZXRyaWV2ZWQgdXNpbmcgZS5nLiwgYSBORVRDT05G
ICZxdW90O2dldCZxdW90OyBvcGVyYXRpb24sIHdpdGggdGhlIHNhbWUgZmlsdGVycyBhcHBsaWVk
LjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGlzIHRleHQgY2FuIGN1cnJlbnRseSBvbmx5IHJlZmVyIHRvIGEg4oCcZ2V0
4oCdIGFzIGRlZmluZWQgaW4gUkZDIDYyNDEgYXMgdGhlcmUgaXMgbm8gcmVmZXJlbmNlIHRvIFJG
QyA2MjQzIGFzIHlldC4gSSB0aGluayB3ZSBuZWVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSBub3cg
dG8gZGVmaW5lIGV4cGVjdGF0aW9ucywgZXZlbiBpZiBpdCBpcyB0byBleHBsaWNpdGx5IG5vdCBj
b25zaWRlciBhbiBSRkMgNjI0My1saWtlDQogbWVjaGFuaXNtIG9yIHRvIHNheSB0aGF0IHdlIG9u
bHkgY29uc2lkZXIgZXhwbGljaXRseSBzZXQgdmFsdWVzIGluIHRlbGVtZXRyeSwgb3LigKY8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+RWluYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJl
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286
cD48L3ByZT4NCjxwcmU+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2Q8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EADB93Fsjceml521mbxchi_--


From nobody Wed Jan 17 16:25: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 F407812D881 for ; Wed, 17 Jan 2018 16:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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] 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 ih4oyD2_79uW for ; Wed, 17 Jan 2018 16:25:43 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 4A489124BAC for ; Wed, 17 Jan 2018 16:25:43 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id i1so9392097qtj.8 for ; Wed, 17 Jan 2018 16:25:43 -0800 (PST)
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=OI2x1N/Y6jdOImL8fZOVV7G3sdTFSY9niAk2pZXbPEs=; b=KrMxzqfSVKlnR2NCWYD3MWtlGInFw1pHuG6NxpPVNA288lYiN1ZB8B4dbbd813qzJh oQsSUl3+EmKhvZGuBjY9LqmBunrNLXnN9PG+0QheLRhWBCoXymf+yaUMR4i+MlnuQT0D jTBfKfYYPe9c9zisrhtsswHKYfZtB/3+JGLSBKaf3KlLGF6SwEk/2a3vlIRLd39zLg2m E+U+Jh2aFIc2XYR+omQb9cOAxafjE2ne1Ulm2AQf2eHPBkwTF2QLnbx1nNZrVcKa8QXC odtMyFkrArJp0npYUyPWvSNeRbI56rPARhHztQ0INZPBaQsrp53P02L7bfuZ8sfB9TVP zlWg==
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=OI2x1N/Y6jdOImL8fZOVV7G3sdTFSY9niAk2pZXbPEs=; b=aV3Il0tzIj50qj/Dki+0Wo8G77sILw6zsT2Q3OubMOen/KS20YLbh5hd0hc9sZmEZZ F4/Rkc8dBGcPTkuTwoVZUUlroz6yIRFFYTqpfoD2E3nrrYE9iYNTTwJEzDrzukMd6PDz n1PKPFjzW/+oCD+InC/6VwKfbIKcd1QoYW303EKayHYM+ZE+dg8d/SNLGWdn/xxnkMtx Mo+G/KNNMqCZ7cE9mv2y1Qbhx3MM9fBwdsf9XK02NUbUCku3VHXNRR+n+t/Nusgg4z1R QKUsa1s+Xa0dxhlgd3al6cKssn8iYBnvjCxssvG63U1olt+up+OH/ak3sBcvx0gYJ9K7 cOtA==
X-Gm-Message-State: AKwxytccoeTAsUbkSr9ZPuBa3AtIJtGtT2OyVRQbhv8xnnYti7J94Gm0 HeWd3M6VsLdv84r7D99RRGN37nLFlOiaUGl2+3U=
X-Google-Smtp-Source: ACJfBovufBKG5OU0JaIqlTk1Dw98uB95Dn08G1ikeuq+GhKX1eZBiXtemWgc/nn5h4u7H8ZbYz2PQrB/OoBqfQWTSsU=
X-Received: by 10.55.197.20 with SMTP id p20mr58907955qki.337.1516235142370; Wed, 17 Jan 2018 16:25:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.109.139 with HTTP; Wed, 17 Jan 2018 16:25:41 -0800 (PST)
In-Reply-To: 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>  
From: Sonal Agarwal 
Date: Wed, 17 Jan 2018 16:25:41 -0800
Message-ID: 
To: Kent Watsen 
Cc: Mahesh Jethanandani ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1149aa3e0e99a10563020184"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 00:25:45 -0000

--001a1149aa3e0e99a10563020184
Content-Type: text/plain; charset="UTF-8"

Hi Kent,

The last remaining open issue is about adding containers for addresses
(source, destination) and ports (source, destination). A user has the
choice to use the container or leaf for address (source/dest) and port
(source/dest).  With this, the user can use the Yang model to configure
scale ACL's.

I did some preliminary work on this in August/September last year, but ran
out of time to explore this fully as I had to upload my other changes by
particular dates.

The non implementation of this does not detract from the usability of the
ACL model.

Closing the issue to completion will require me to revisit and implement
the yang solution for container support in the model.

Thanks,
Sonal.


On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen  wrote:

>
> H Mahesh,
>
> >> - There is an open issue in the document (section 8) - are we going
> >>  to resolve that during WG last call or is this a leftover?
> >
> > This will be resolved in the next version of the module. It is
> > documented under Issues tab in GitHub. Should we remove it from
> > the draft?
>
> Most of Juergen's comments are editorial in nature and can truly be
> handled as part of the LC process, but this open issue has me worried, as
> it may result in a significant technical change.
>
> What will it take to close this open issue?  Is it just a matter of the
> getting the WG to agree that it's not an issue, or do we already know that
> it is a real issue and only the solution is pending?
>
> Thanks,
> Kent
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi Kent,

The last remaining open issue =
is about adding containers for addresses (source, destination) and ports (s=
ource, destination). A user has the choice to use the container or leaf for=
 address (source/dest) and port (source/dest).=C2=A0 With this, the user ca=
n use the Yang model to configure scale ACL's.

I did some preliminary work on this in August/September last year, but ran=
 out of time to explore this fully as I had to upload my other changes by p=
articular dates.

The non implementation of this do=
es not detract from the usability of the ACL model.

Closing the issue to completion will require me to revisit and implement =
the yang solution for container support in the model.

<=
div>Thanks,
Sonal.


On Wed, Jan 17, 2018 at 3:33 PM, Kent=
 Watsen <kwatsen@juniper.net> wrote:


H Mahesh,



>> - There is an open issue in the document (section 8) - are we goin=
g

>>=C2=A0 to resolve that during WG last call or is this a leftover?
>

> This will be resolved in the next version of the module. It is

> documented under Issues tab in GitHub. Should we remove it from

> the draft?



Most of Juergen's comments are editorial in nature and can truly=
 be handled as part of the LC process, but this open issue has me worried, =
as it may result in a significant technical change.



What will it take to close this open issue?=C2=A0 Is it just a matter of th=
e getting the WG to agree that it's not an issue, or do we already know=
 that it is a real issue and only the solution is pending?



Thanks,

Kent










_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a1149aa3e0e99a10563020184--


From nobody Wed Jan 17 16:45:36 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 35EF712EAAB for ; Wed, 17 Jan 2018 16:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xpb9JK5JL678 for ; Wed, 17 Jan 2018 16:45:33 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE6712741D for ; Wed, 17 Jan 2018 16:45:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9819; q=dns/txt; s=iport; t=1516236333; x=1517445933; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RGHY2oapaeRSCyWq3DzX8DK81FcSNOY5y2Gi2CmQ1L4=; b=f1bJDC2FTIA0yQlIwRX9OWrcu0S9DDQ/0NSwOLuIGd0j7/sAcHcW/W+f k03q4zUch5IaQthCBBror2c2wliSFekdBsv7MO2w/WUqX5rTK/4YmXk4o CHJf5mmS0wWbx1Q9xnJ1LwaKgFQRFrjgo57GJwNAerWCdrHwGxZvwhN0u M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAwCt7F9a/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKd2Z0JweEDJkCggKJB4hWhVGCFgoYAQqESU8CGoRLQBcBAQE?= =?us-ascii?q?BAQEBAQFrKIUjAQEBBAEBIUsLEAIBCA4DAwECKAMCAgIfBgsUCQgCBAENBRuJN?= =?us-ascii?q?EwDFRCna4Inhz0NggQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZRhm6Ca0QBAQK?= =?us-ascii?q?CD4J3gmUFmXmJNj0CkE6FA5QTjgWIfQIRGQGBOwEgATeBUG8VPYIqghs5HIFmA?= =?us-ascii?q?XiLOYEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200";  d="scan'208,217";a="347613570"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 00:45:32 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0I0jVJO010871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Jan 2018 00:45:32 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; Wed, 17 Jan 2018 19:45:31 -0500
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; Wed, 17 Jan 2018 19:45:30 -0500
From: "Acee Lindem (acee)" 
To: Sonal Agarwal , Kent Watsen 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKN4/uMAgAABSICAAAr5gIAADrCA//+xqIA=
Date: Thu, 18 Jan 2018 00:45:30 +0000
Message-ID: 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   
In-Reply-To: 
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.198]
Content-Type: multipart/alternative; boundary="_000_D6855780ECED6aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 00:45:35 -0000

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

SGkgU29uYWwsDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv
Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFNvbmFsIEFnYXJ3YWwgPHNh
Z2Fyd2FsMTJAZ21haWwuY29tPG1haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbT4+DQpEYXRlOiBX
ZWRuZXNkYXksIEphbnVhcnkgMTcsIDIwMTggYXQgNzoyNSBQTQ0KVG86IEtlbnQgV2F0c2VuIDxr
d2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4NCkNjOiAibmV0
bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2Fs
bDogZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE1DQoNCkhpIEtlbnQsDQoNClRoZSBsYXN0
IHJlbWFpbmluZyBvcGVuIGlzc3VlIGlzIGFib3V0IGFkZGluZyBjb250YWluZXJzIGZvciBhZGRy
ZXNzZXMgKHNvdXJjZSwgZGVzdGluYXRpb24pIGFuZCBwb3J0cyAoc291cmNlLCBkZXN0aW5hdGlv
bikuIEEgdXNlciBoYXMgdGhlIGNob2ljZSB0byB1c2UgdGhlIGNvbnRhaW5lciBvciBsZWFmIGZv
ciBhZGRyZXNzIChzb3VyY2UvZGVzdCkgYW5kIHBvcnQgKHNvdXJjZS9kZXN0KS4gIFdpdGggdGhp
cywgdGhlIHVzZXIgY2FuIHVzZSB0aGUgWWFuZyBtb2RlbCB0byBjb25maWd1cmUgc2NhbGUgQUNM
J3MuDQoNCklzIHRoaXMgaXMgdGhlIG1vdGl2YXRpb24gZm9yIGRvaW5nIGl0IHR3byB3YXlzPyBJ
4oCZZCB0aGluayB0aGF0IGFnZ3JlZ2F0aW9uIG9mIGNvbW1vbiBtYXRjaCBjcml0ZXJpYSBmb3Ig
c2NhbGUgY291bGQgYmUgYmV0dGVyIGRvbmUgcHJvZ3JhbW1hdGljYWxseSB0aGFuIHRocm91Z2gg
cHJ1ZGVudCBjb25maWd1cmF0aW9uLg0KDQpUaGFua3MsDQpBY2VlDQoNCkkgZGlkIHNvbWUgcHJl
bGltaW5hcnkgd29yayBvbiB0aGlzIGluIEF1Z3VzdC9TZXB0ZW1iZXIgbGFzdCB5ZWFyLCBidXQg
cmFuIG91dCBvZiB0aW1lIHRvIGV4cGxvcmUgdGhpcyBmdWxseSBhcyBJIGhhZCB0byB1cGxvYWQg
bXkgb3RoZXIgY2hhbmdlcyBieSBwYXJ0aWN1bGFyIGRhdGVzLg0KDQpUaGUgbm9uIGltcGxlbWVu
dGF0aW9uIG9mIHRoaXMgZG9lcyBub3QgZGV0cmFjdCBmcm9tIHRoZSB1c2FiaWxpdHkgb2YgdGhl
IEFDTCBtb2RlbC4NCg0KQ2xvc2luZyB0aGUgaXNzdWUgdG8gY29tcGxldGlvbiB3aWxsIHJlcXVp
cmUgbWUgdG8gcmV2aXNpdCBhbmQgaW1wbGVtZW50IHRoZSB5YW5nIHNvbHV0aW9uIGZvciBjb250
YWluZXIgc3VwcG9ydCBpbiB0aGUgbW9kZWwuDQoNClRoYW5rcywNClNvbmFsLg0KDQoNCk9uIFdl
ZCwgSmFuIDE3LCAyMDE4IGF0IDM6MzMgUE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIu
bmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQoNCkggTWFoZXNoLA0KDQo+
PiAtIFRoZXJlIGlzIGFuIG9wZW4gaXNzdWUgaW4gdGhlIGRvY3VtZW50IChzZWN0aW9uIDgpIC0g
YXJlIHdlIGdvaW5nDQo+PiAgdG8gcmVzb2x2ZSB0aGF0IGR1cmluZyBXRyBsYXN0IGNhbGwgb3Ig
aXMgdGhpcyBhIGxlZnRvdmVyPw0KPg0KPiBUaGlzIHdpbGwgYmUgcmVzb2x2ZWQgaW4gdGhlIG5l
eHQgdmVyc2lvbiBvZiB0aGUgbW9kdWxlLiBJdCBpcw0KPiBkb2N1bWVudGVkIHVuZGVyIElzc3Vl
cyB0YWIgaW4gR2l0SHViLiBTaG91bGQgd2UgcmVtb3ZlIGl0IGZyb20NCj4gdGhlIGRyYWZ0Pw0K
DQpNb3N0IG9mIEp1ZXJnZW4ncyBjb21tZW50cyBhcmUgZWRpdG9yaWFsIGluIG5hdHVyZSBhbmQg
Y2FuIHRydWx5IGJlIGhhbmRsZWQgYXMgcGFydCBvZiB0aGUgTEMgcHJvY2VzcywgYnV0IHRoaXMg
b3BlbiBpc3N1ZSBoYXMgbWUgd29ycmllZCwgYXMgaXQgbWF5IHJlc3VsdCBpbiBhIHNpZ25pZmlj
YW50IHRlY2huaWNhbCBjaGFuZ2UuDQoNCldoYXQgd2lsbCBpdCB0YWtlIHRvIGNsb3NlIHRoaXMg
b3BlbiBpc3N1ZT8gIElzIGl0IGp1c3QgYSBtYXR0ZXIgb2YgdGhlIGdldHRpbmcgdGhlIFdHIHRv
IGFncmVlIHRoYXQgaXQncyBub3QgYW4gaXNzdWUsIG9yIGRvIHdlIGFscmVhZHkga25vdyB0aGF0
IGl0IGlzIGEgcmVhbCBpc3N1ZSBhbmQgb25seSB0aGUgc29sdXRpb24gaXMgcGVuZGluZz8NCg0K
VGhhbmtzLA0KS2VudA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0
bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KDQo=

--_000_D6855780ECED6aceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <79C522B23AB84E4FBF74DD3904458BBA@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBTb25hbCw8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i
Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt
YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE
RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog
MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC
T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl
PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVmPSJtYWls
dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZn
dDsgb24gYmVoYWxmIG9mIFNvbmFsIEFnYXJ3YWwgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWdhcndh
bDEyQGdtYWlsLmNvbSI+c2FnYXJ3YWwxMkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBKYW51YXJ5IDE3
LCAyMDE4IGF0IDc6MjUgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86
IDwvc3Bhbj5LZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5u
ZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RA
aWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsOiBk
cmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTU8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg
c3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFS
R0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SGkgS2VudCwNCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBsYXN0IHJlbWFpbmluZyBvcGVuIGlzc3VlIGlzIGFi
b3V0IGFkZGluZyBjb250YWluZXJzIGZvciBhZGRyZXNzZXMgKHNvdXJjZSwgZGVzdGluYXRpb24p
IGFuZCBwb3J0cyAoc291cmNlLCBkZXN0aW5hdGlvbikuIEEgdXNlciBoYXMgdGhlIGNob2ljZSB0
byB1c2UgdGhlIGNvbnRhaW5lciBvciBsZWFmIGZvciBhZGRyZXNzIChzb3VyY2UvZGVzdCkgYW5k
IHBvcnQgKHNvdXJjZS9kZXN0KS4mbmJzcDsgV2l0aCB0aGlzLCB0aGUgdXNlciBjYW4NCiB1c2Ug
dGhlIFlhbmcgbW9kZWwgdG8gY29uZmlndXJlIHNjYWxlIEFDTCdzLjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+SXMgdGhpcyBpcyB0aGUgbW90aXZhdGlvbiBmb3IgZG9pbmcgaXQgdHdvIHdheXM/IEni
gJlkIHRoaW5rIHRoYXQgYWdncmVnYXRpb24gb2YgY29tbW9uIG1hdGNoIGNyaXRlcmlhIGZvciBz
Y2FsZSBjb3VsZCBiZSBiZXR0ZXIgZG9uZSBwcm9ncmFtbWF0aWNhbGx5IHRoYW4gdGhyb3VnaCBw
cnVkZW50IGNvbmZpZ3VyYXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5UaGFua3MsJm5ic3A7PC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxzcGFuIGlkPSJP
TEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC
VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBB
RERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9
Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRpZCBzb21lIHByZWxpbWluYXJ5IHdv
cmsgb24gdGhpcyBpbiBBdWd1c3QvU2VwdGVtYmVyIGxhc3QgeWVhciwgYnV0IHJhbiBvdXQgb2Yg
dGltZSB0byBleHBsb3JlIHRoaXMgZnVsbHkgYXMgSSBoYWQgdG8gdXBsb2FkIG15IG90aGVyIGNo
YW5nZXMgYnkgcGFydGljdWxhciBkYXRlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PlRoZSBub24gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBkb2VzIG5vdCBkZXRyYWN0IGZyb20gdGhl
IHVzYWJpbGl0eSBvZiB0aGUgQUNMIG1vZGVsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+Q2xvc2luZyB0aGUgaXNzdWUgdG8gY29tcGxldGlvbiB3aWxsIHJlcXVpcmUgbWUgdG8gcmV2
aXNpdCBhbmQgaW1wbGVtZW50IHRoZSB5YW5nIHNvbHV0aW9uIGZvciBjb250YWluZXIgc3VwcG9y
dCBpbiB0aGUgbW9kZWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9k
aXY+DQo8ZGl2PlNvbmFsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQs
IEphbiAxNywgMjAxOCBhdCAzOjMzIFBNLCBLZW50IFdhdHNlbiA8c3BhbiBkaXI9Imx0ciI+DQom
bHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5r
d2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3Rl
IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0
OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KSCBNYWhlc2gsPGJyPg0K
PHNwYW4gY2xhc3M9IiI+PGJyPg0KJmd0OyZndDsgLSBUaGVyZSBpcyBhbiBvcGVuIGlzc3VlIGlu
IHRoZSBkb2N1bWVudCAoc2VjdGlvbiA4KSAtIGFyZSB3ZSBnb2luZzxicj4NCiZndDsmZ3Q7Jm5i
c3A7IHRvIHJlc29sdmUgdGhhdCBkdXJpbmcgV0cgbGFzdCBjYWxsIG9yIGlzIHRoaXMgYSBsZWZ0
b3Zlcj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHdpbGwgYmUgcmVzb2x2ZWQgaW4gdGhlIG5l
eHQgdmVyc2lvbiBvZiB0aGUgbW9kdWxlLiBJdCBpczxicj4NCiZndDsgZG9jdW1lbnRlZCB1bmRl
ciBJc3N1ZXMgdGFiIGluIEdpdEh1Yi4gU2hvdWxkIHdlIHJlbW92ZSBpdCBmcm9tPGJyPg0KJmd0
OyB0aGUgZHJhZnQ/PGJyPg0KPGJyPg0KPC9zcGFuPk1vc3Qgb2YgSnVlcmdlbidzIGNvbW1lbnRz
IGFyZSBlZGl0b3JpYWwgaW4gbmF0dXJlIGFuZCBjYW4gdHJ1bHkgYmUgaGFuZGxlZCBhcyBwYXJ0
IG9mIHRoZSBMQyBwcm9jZXNzLCBidXQgdGhpcyBvcGVuIGlzc3VlIGhhcyBtZSB3b3JyaWVkLCBh
cyBpdCBtYXkgcmVzdWx0IGluIGEgc2lnbmlmaWNhbnQgdGVjaG5pY2FsIGNoYW5nZS48YnI+DQo8
YnI+DQpXaGF0IHdpbGwgaXQgdGFrZSB0byBjbG9zZSB0aGlzIG9wZW4gaXNzdWU/Jm5ic3A7IElz
IGl0IGp1c3QgYSBtYXR0ZXIgb2YgdGhlIGdldHRpbmcgdGhlIFdHIHRvIGFncmVlIHRoYXQgaXQn
cyBub3QgYW4gaXNzdWUsIG9yIGRvIHdlIGFscmVhZHkga25vdyB0aGF0IGl0IGlzIGEgcmVhbCBp
c3N1ZSBhbmQgb25seSB0aGUgc29sdXRpb24gaXMgcGVuZGluZz88YnI+DQo8YnI+DQpUaGFua3Ms
PGJyPg0KS2VudDxicj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5f
X19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHJlbD0ibm9yZWZl
cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5s
aXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D6855780ECED6aceeciscocom_--


From nobody Wed Jan 17 16: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 B22C012D87E for ; Wed, 17 Jan 2018 16:54:41 -0800 (PST)
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 4aB9JUKZeYSl for ; Wed, 17 Jan 2018 16:54:35 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 C620212EADD for ; Wed, 17 Jan 2018 16:54:35 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id 23so12875877pfp.3 for ; Wed, 17 Jan 2018 16:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XjmzVf+AY3wtsnROoOokVOMC2BvpebKfm9QJehhsMBg=; b=W0K+hlpm2FZdmdRZzmxfGzwI8km9tQmsCw9T/5cV3Ys3pKBkJfem4rduHZPxRGwJNQ ROJECbQaPmhLhT9jxiSzFJz5Y+I/tiHE+GmvnblEu49R9pwiGxAy9hlUzTneTUjBGK6C 6zB5FGnkr5WPOD6nRj0WgmHfqchsE2vWHhd9TenGTTqO+TelP/VgQuMB6/KvzockkT4P WguhBQP7VUeQ+rHX/lMlpM8Wu9ErAecRp3t9EzzbCcY+OUjbltDdNNiqDmbZqS8dCWgp 4vyVggVN9aykBlqHlaXjPyQZt5RCyvN+BqT4tZJdCQ30lhywdLolooTB0hX4zC8XtBdk Qaiw==
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=XjmzVf+AY3wtsnROoOokVOMC2BvpebKfm9QJehhsMBg=; b=QtNuTQhb8EHRB1WejHUQLQoH3OtFdk2M+JxvdqQFiCthZTjLxrDBjPKu726yBdOMGn kc75sIvbVIrKuvtMbARG+YU96dhppa6BVGrrM3PnnDs8zOVV9Lti67KEiYJs4JQpyCzk 7hrMge2o/t8tm89W2YHH0nOVgPaCHQot+W1gDeMvRLjkBKSJAz6RgNxP1PQ/g7nT/T1A 7lbur26X+HJwmpfNkRLDwxnn1npog/5CkCihj9jgf5vi3Y0EaWF5s5J+c0haNd4zCNMJ uM8YuCmnbccRcQpRWWsAGCkneN9ENYaiQY+yMsBIeB6Tc+oNSfKJDq6xYTNueMLTOzv0 NtfQ==
X-Gm-Message-State: AKwxytdegyOCk4p3u04K3I8rDifhqcNEmwpcI5r/MRzY9zcDpqD8DKlX Vfnca0sEAnDwTnFLEHGCu8Y=
X-Google-Smtp-Source: ACJfBouS/SQfLSACftsVU6n9uT8I6liwxOMff5zYo9yBiIebHDhf9ziGoVN049wMMkH8zmQjGJ2Fkw==
X-Received: by 10.98.153.197 with SMTP id t66mr5746253pfk.142.1516236875202; Wed, 17 Jan 2018 16:54:35 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d998:dcd9:6c19:6a28]) by smtp.gmail.com with ESMTPSA id 125sm9346982pff.23.2018.01.17.16.54.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 16:54:34 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF12D5E5-126D-4120-816B-FE0F3247DBC4"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 17 Jan 2018 16:54:32 -0800
In-Reply-To: 
Cc: "netmod@ietf.org" , Sonal Agarwal 
To: Juergen Schoenwaelder , Kent Watsen 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 00:54:41 -0000

--Apple-Mail=_CF12D5E5-126D-4120-816B-FE0F3247DBC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The important thing to note is that the current model does not prevent =
ACEs from being configured for each ACL, like most configurations that =
exist today. As Acee mentions in his e-mail, scaling can be done =
programmatically also.

Object groups (or containers) are another way to organize rules that =
constitute an ACE. And object groups can contain other object groups. =
Instead of having an ACL with a list of rules, one could have an ACL =
that refers to an object group that contains the rules. And multiple ACL =
can refer to the same object group.

If there is a strong desire for the feature, the authors believe that =
this can be addressed in the next version of the *RFC*, probably as a =
bis document (sorry, if I was not clear what I meant by =E2=80=9Cnext =
version=E2=80=9D).

Looking at RFC 7950, I see that we can update the model in a backward =
compatible way, by adding a =E2=80=98case=E2=80=99 statement. How about =
adding a =E2=80=98choice=E2=80=99 statement? Would that be backward =
compatible? If not, we can make an editorial change to add the =
=E2=80=98choice=E2=80=99 statement in the model today, and later in the =
bis document add the =E2=80=98case=E2=80=99 statement for object groups.

Cheers.

> On Jan 17, 2018, at 4:25 PM, Sonal Agarwal  =
wrote:
>=20
> Hi Kent,
>=20
> The last remaining open issue is about adding containers for addresses =
(source, destination) and ports (source, destination). A user has the =
choice to use the container or leaf for address (source/dest) and port =
(source/dest).  With this, the user can use the Yang model to configure =
scale ACL's.
>=20
> I did some preliminary work on this in August/September last year, but =
ran out of time to explore this fully as I had to upload my other =
changes by particular dates.
>=20
> The non implementation of this does not detract from the usability of =
the ACL model.
>=20
> Closing the issue to completion will require me to revisit and =
implement the yang solution for container support in the model.
>=20
> Thanks,
> Sonal.
>=20
>=20
> On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen > wrote:
>=20
> H Mahesh,
>=20
> >> - There is an open issue in the document (section 8) - are we going
> >>  to resolve that during WG last call or is this a leftover?
> >
> > This will be resolved in the next version of the module. It is
> > documented under Issues tab in GitHub. Should we remove it from
> > the draft?
>=20
> Most of Juergen's comments are editorial in nature and can truly be =
handled as part of the LC process, but this open issue has me worried, =
as it may result in a significant technical change.
>=20
> What will it take to close this open issue?  Is it just a matter of =
the getting the WG to agree that it's not an issue, or do we already =
know that it is a real issue and only the solution is pending?
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_CF12D5E5-126D-4120-816B-FE0F3247DBC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
important thing to note is that the current model does not prevent ACEs =
from being configured for each ACL, like most configurations that exist =
today. As Acee mentions in his e-mail, scaling can be done =
programmatically also.

Object groups (or containers) are another way to organize =
rules that constitute an ACE. And object groups can contain other object =
groups. Instead of having an ACL with a list of rules, one could have an =
ACL that refers to an object group that contains the rules. And multiple =
ACL can refer to the same object group.

If there is a strong desire for the =
feature, the authors believe that this can be addressed in the next =
version of the *RFC*, probably as a bis document (sorry, if I was not =
clear what I meant by =E2=80=9Cnext version=E2=80=9D).

Looking at RFC 7950, I =
see that we can update the model in a backward compatible way, by adding =
a =E2=80=98case=E2=80=99 statement. How about adding a =E2=80=98choice=E2=80=
=99 statement? Would that be backward compatible? If not, we can make an =
editorial change to add the =E2=80=98choice=E2=80=99 statement in the =
model today, and later in the bis document add the =E2=80=98case=E2=80=99 =
statement for object groups.

Cheers.

On Jan =
17, 2018, at 4:25 PM, Sonal Agarwal <sagarwal12@gmail.com> wrote:

Hi Kent,

The last remaining open issue is about adding containers for =
addresses (source, destination) and ports (source, destination). A user =
has the choice to use the container or leaf for address (source/dest) =
and port (source/dest).  With this, the user can use the Yang model =
to configure scale ACL's.

I did some preliminary work on this in August/September last =
year, but ran out of time to explore this fully as I had to upload my =
other changes by particular dates.

The non implementation of this does not =
detract from the usability of the ACL model.

Closing the issue to completion will =
require me to revisit and implement the yang solution for container =
support in the model.

Thanks,
Sonal.


On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen <kwatsen@juniper.net> =
wrote:


H Mahesh,



>> - There is an open issue in the document (section 8) - are we =
going

>>  to resolve that during WG last call or is this a =
leftover?

>

> This will be resolved in the next version of the module. It is

> documented under Issues tab in GitHub. Should we remove it from

> the draft?



Most of Juergen's comments are editorial in nature and can truly =
be handled as part of the LC process, but this open issue has me =
worried, as it may result in a significant technical change.



What will it take to close this open issue?  Is it just a matter of =
the getting the WG to agree that it's not an issue, or do we already =
know that it is a real issue and only the solution is pending?



Thanks,

Kent










_______________________________________________

netmod mailing list

netmod@ietf.org

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








Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_CF12D5E5-126D-4120-816B-FE0F3247DBC4--


From nobody Wed Jan 17 23:29: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 19C5112AF6E for ; Wed, 17 Jan 2018 23:29:25 -0800 (PST)
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_RP_MATCHES_RCVD=-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 RZ2BLdGyaxSf for ; Wed, 17 Jan 2018 23:29:24 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33B2126C22 for ; Wed, 17 Jan 2018 23:29:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1516260563; x=1517470163; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4O+uJbGiQ4uK/VCNy8BSDEThhI1J6JouMJwZi7AWXBo=; b=QrhNTB87TO4Bqx1wEc9hznR8SraE3be/G183UyKjcLKHoScDVuYW/VqC 0Gb6obXL5gvxbJ+PiqbFBICTXjyGUKaAX89Rmx7jJKAs5zVJ6hQf+AvY8 O9fOs4rIMYjE+++Q4/WRi19bNtH8p/zt58E0ajvxJnFqpn8m7pG9S7T5j 4=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBzTGBa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUbhASLGI9smUYHA4U7AoUpFAEBAQEBAQEBAWsohSQBBSNWEAs?= =?us-ascii?q?OCioCAlcGAQwIAQEXihinWoIniVIBAQEBAQEBAQEBAQEBAQEBAQERD4o5gwWIO?= =?us-ascii?q?YJlBaNshFiCMY5KjCWHbpcvgTw2IoFQMhoIGxWCaIJTHIFmAkCMWgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.46,376,1511827200"; d="asc'?scan'208"; a="1461692"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 07:29:21 +0000
Received: from [10.61.81.178] (ams3-vpn-dhcp4531.cisco.com [10.61.81.178]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0I7TL4x025082; Thu, 18 Jan 2018 07:29:21 GMT
To: Sonal Agarwal , Kent Watsen 
Cc: "netmod@ietf.org" 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   
From: Eliot Lear 
Message-ID: 
Date: Thu, 18 Jan 2018 08:29:20 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l4NDmcdDvIcSeqPccT4j8inSkbmGx8kIf"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 07:29:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--l4NDmcdDvIcSeqPccT4j8inSkbmGx8kIf
Content-Type: multipart/mixed; boundary="b4po6jH9WfT3xttjnH4Cv0VOCGEILG2bU";
 protected-headers="v1"
From: Eliot Lear 
To: Sonal Agarwal , Kent Watsen 
Cc: "netmod@ietf.org" 
Message-ID: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
 <20180117224916.4xtwnxgsw3snzwvf@elstar.local>
 
 
 
In-Reply-To: 

--b4po6jH9WfT3xttjnH4Cv0VOCGEILG2bU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 18.01.18 01:25, Sonal Agarwal wrote:
> Hi Kent,
>
> The last remaining open issue is about adding containers for addresses
> (source, destination) and ports (source, destination). A user has the
> choice to use the container or leaf for address (source/dest) and port
> (source/dest).  With this, the user can use the Yang model to configure=

> scale ACL's.
>
> I did some preliminary work on this in August/September last year, but =
ran
> out of time to explore this fully as I had to upload my other changes b=
y
> particular dates.
>
> The non implementation of this does not detract from the usability of t=
he
> ACL model.
>
> Closing the issue to completion will require me to revisit and implemen=
t
> the yang solution for container support in the model.

+1 and I would go further.=C2=A0 Adding this makes the model even more
complex for the simpler cases.=C2=A0 If someone is looking to save memory=

through such a feature (assuming that it even does), it can be done
below this abstraction layer.

Eliot



--b4po6jH9WfT3xttjnH4Cv0VOCGEILG2bU--

--l4NDmcdDvIcSeqPccT4j8inSkbmGx8kIf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpgTNAACgkQh7ZrRtnS
ejMC6Qf/fxKYl9j0uo+QjYXIsMvLqTyDRbEK+JSRxls0xwDggi5uDC+4/RcR+tSq
48+HaPKBwnBqEgtD+0idy0hr2r41xQN5zIMOt9YsnY2PPHDPusnjrzmIjonqm3uK
u1q2TZcGvucdepkC7zWT46RAR/D9G0UtdQND7YWR/gWLvBN8g1owokT4AJFqvkpV
azlANZgw+54yMUiPodiSqysc2PW/jFog2WDvttWtvmNCIi2phHdddCV2ScXULGNO
PpeNHV25RBlQfdwWn+EkpmERgl2nU8BDS+W/472BvIGP9xvsJBT4u6RZK7F7yPbw
7nya88zWIcvr1F+zjQsUVUrT9DdF+w==
=6nvK
-----END PGP SIGNATURE-----

--l4NDmcdDvIcSeqPccT4j8inSkbmGx8kIf--


From nobody Wed Jan 17 23:56:57 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 B911112EB13 for ; Wed, 17 Jan 2018 23:56:54 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Gw45OTMlYJol for ; Wed, 17 Jan 2018 23:56:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3009D12EABE for ; Wed, 17 Jan 2018 23:56:51 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id EC1CD1AE0118; Thu, 18 Jan 2018 08:56:48 +0100 (CET)
Date: Thu, 18 Jan 2018 08:56:48 +0100 (CET)
Message-Id: <20180118.085648.2091191419931632376.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 07:56:55 -0000

Lou Berger  wrote:
> =

> =

> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> ...
> >>> My main concern is actually the YL version.  I strongly think SM =
need
> >>> to use YL-bis rather that the old YL, so that it can support NMDA=
.=

> >>>
> >> Right now to SM is independent of Yang Library version and can run=

> >> with either.
> > No this is not correct.  SM uses a grouping from the old YANG
> > library (for the "use-schema" case),
> I thought YLbis was an updat e to UL (i.e., no name change) as such S=
M
> can include either.

The old "modules-state" structure is deprecated, and a new structure
that allows multiple datastores is defined.  Note that YLbis can be
used by both NMDA-capabale and non-NMDA-capabale servers.

> >   and talks about mounting
> > "modules-state" ("inline" case).
> In informative descriptions only.=A0 Certainly these can be changed t=
o
> allow for YL-bis if need be.
> =

> >> I certainly would expect use of Yang Library bis and nmda
> >> to have advantages.
> >>
> >>> The implementation effort for supporting the new YL in clients an=
d
> >>> servers is minimal, esp. when compared to the efforts involved in=

> >>> supporting SM.
> >>>
> >>> Adding an indirection is (for me) less important, but it has the
> >>> benefit of solving the two issues (a) and (b) above, and I haven'=
t
> >>> seen any technical problem with it.
> >>>
> >> (A) has implementation implications and those participating in the=

> >> discussion at the time expressed as not being worth the cost.
> >> I don't believe b was seen as a significant issue either.
> >>
> >>> Do you have any technical concerns with using an annotation as an=

> >>> indirection?
> >>>
> >> The technicsl issue I have with the approaches the same one that w=
as
> >> raised when debated previously, ie the implementation overhead of
> >> requiring inline schemas to be available at the top level.
> > Ok.  I'm ok with keeping the inline case as it is.  However, I thin=
k
> > we need to use the new YL-bis, so that we can support the NMDA.
> Given that NMDA support is not yet fully defined, we're still in the
> transition period where support for both NMDA and non-NMDA
> implementations need to be considered.=A0 Rob presented some options
> earlier in the thread that I think captures this.

Again, note that YLbis supports both NMDA and non-NMDA servers.

Also note that YLbis is just a different read-only monitoring
structure.  Given an implementation that supports the old YL, it is
trivial to add support for YLbis (especially compared to the more than
non-trivial amount of work required to support schema mount...).


/martin


From nobody Wed Jan 17 23:58:07 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 4A44212EB15; Wed, 17 Jan 2018 23:58:00 -0800 (PST)
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 qqsQqi4y3_dm; Wed, 17 Jan 2018 23:57:58 -0800 (PST)
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 03FEE12EB13; Wed, 17 Jan 2018 23:57:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4672E2A22060; Thu, 18 Jan 2018 08:57:56 +0100 (CET)
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 hlO2MUfcqVb2; Thu, 18 Jan 2018 08:57:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1A82A2A2205E; Thu, 18 Jan 2018 08:57:56 +0100 (CET)
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 5-iO5Ie3Wbwt; Thu, 18 Jan 2018 08:57:56 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id D75912A2205D; Thu, 18 Jan 2018 08:57:55 +0100 (CET)
To: Mahesh Jethanandani , netconf 
Cc: NETMOD Working Group , Martin Bjorklund 
References: 
From: Vladimir Vassilev 
Message-ID: <5f355029-6265-aa29-c836-e6abcdd5382d@transpacket.com>
Date: Thu, 18 Jan 2018 08:57:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 07:58:00 -0000

Hello,

There is a YANG error in ietf-netconf-nmda@2018-01-17.yang:

Error: XPath expression 'derived-from-or-self(../datastore,=20
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-nmda.yang:148.63: error(348): invalid XPath expression synta=
x

Error: XPath expression 'derived-from-or-self(../datastore,=20
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-nmda.yang:178.63: error(348): invalid XPath expression synta=
x

The correct datastore identity is ds:operational. The same error was=20
reported for the previous version of the draft.

> -------- Forwarded Message --------
> Subject:=C2=A0=C2=A0=C2=A0=C2=A0 [netmod] validation of draft-ietf-netc=
onf-nmda-netconf-01
> Date:=C2=A0=C2=A0=C2=A0=C2=A0 Mon, 13 Nov 2017 19:48:49 +0100
> From:=C2=A0=C2=A0=C2=A0=C2=A0 Vladimir Vassilev 
> To: netmod@ietf.org 
>
> Hello,
>
> There is a validation error reported for
> ietf-netconf-datastores@2017-08-24.yang:
>
> Error: XPath expression 'derived-from-or-self(../datastore,
> "or:operational")' with invalid identity param 'or:operational'
> ietf-netconf-datastores@2017-08-24.yang:140.63: error(348): invalid
> XPath expression syntax

Vladimir

On 01/17/2018 07:39 PM, Mahesh Jethanandani wrote:
> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-n=
mda-restconf have posted updates to their drafts, and believe that the do=
cuments are ready for LC.
>
> This starts a 2 week LC on the two drafts that will end on January 31. =
Please send your comments on this thread. Comments like =E2=80=9CI have r=
eviewed the documents and believe they are ready for publication=E2=80=9D=
, or =E2=80=9CI have concerns about the document because =E2=80=A6=E2=80=9D=
 are welcome and useful for the authors.
>
> Authors please indicate whether you are aware of any IPR for either of =
the drafts.
>
> Thanks.
>
> Mahesh & Kent
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Thu Jan 18 00:12: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 6441E124D68 for ; Thu, 18 Jan 2018 00:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 N3IMC0rpuS5j for ; Thu, 18 Jan 2018 00:12:36 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 8A552124319 for ; Thu, 18 Jan 2018 00:12:35 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 1036764B30; Thu, 18 Jan 2018 09:12:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516263153; bh=lfxYBNleCPDB2Cbfn7qLCiXJ4s4eyxF80jdyVNge14U=; h=From:To:Date; b=X5zBDxDGQ5gkJEl/N+XhAWiJO/ZDSUAGqlIYjDhMM5ZhjgCA267z70uZVidR75zf1 HNgzp+r81r+FIRQJl9faeT1r84x78r3PeDUJQVzJ0FsWgu3DoeiMJqJF6+cWNbVskd KlmKd1sINTjYmQODT/NLY5y5H+6tDkf02798M63w=
Message-ID: <1516263152.12353.4.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund , lberger@labn.net
Cc: netmod@ietf.org
Date: Thu, 18 Jan 2018 09:12:32 +0100
In-Reply-To: <20180118.085648.2091191419931632376.mbj@tail-f.com>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 08:12:39 -0000

On Thu, 2018-01-18 at 08:56 +0100, Martin Bjorklund wrote:
> Lou Berger  wrote:
> > 
> > 
> > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > ...
> > > > > My main concern is actually the YL version.  I strongly think SM need
> > > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > > 
> > > > 
> > > > Right now to SM is independent of Yang Library version and can run
> > > > with either.
> > > 
> > > No this is not correct.  SM uses a grouping from the old YANG
> > > library (for the "use-schema" case),
> > 
> > I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> > can include either.
> 
> The old "modules-state" structure is deprecated, and a new structure
> that allows multiple datastores is defined.  Note that YLbis can be
> used by both NMDA-capabale and non-NMDA-capabale servers.

This is another reason to switch to the @schema-ref annotation, because
otherwise YLbis is unnecessarily complex and inefficient to be used under each
inline mount point instance, with the module-sets and datastore lists.

Lada

> 
> > >   and talks about mounting
> > > "modules-state" ("inline" case).
> > 
> > In informative descriptions only.  Certainly these can be changed to
> > allow for YL-bis if need be.
> > 
> > > > I certainly would expect use of Yang Library bis and nmda
> > > > to have advantages.
> > > > 
> > > > > The implementation effort for supporting the new YL in clients and
> > > > > servers is minimal, esp. when compared to the efforts involved in
> > > > > supporting SM.
> > > > > 
> > > > > Adding an indirection is (for me) less important, but it has the
> > > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > > seen any technical problem with it.
> > > > > 
> > > > 
> > > > (A) has implementation implications and those participating in the
> > > > discussion at the time expressed as not being worth the cost.
> > > > I don't believe b was seen as a significant issue either.
> > > > 
> > > > > Do you have any technical concerns with using an annotation as an
> > > > > indirection?
> > > > > 
> > > > 
> > > > The technicsl issue I have with the approaches the same one that was
> > > > raised when debated previously, ie the implementation overhead of
> > > > requiring inline schemas to be available at the top level.
> > > 
> > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > we need to use the new YL-bis, so that we can support the NMDA.
> > 
> > Given that NMDA support is not yet fully defined, we're still in the
> > transition period where support for both NMDA and non-NMDA
> > implementations need to be considered.  Rob presented some options
> > earlier in the thread that I think captures this.
> 
> Again, note that YLbis supports both NMDA and non-NMDA servers.
> 
> Also note that YLbis is just a different read-only monitoring
> structure.  Given an implementation that supports the old YL, it is
> trivial to add support for YLbis (especially compared to the more than
> non-trivial amount of work required to support schema mount...).
> 
> 
> /martin
> 
> _______________________________________________
> 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 Thu Jan 18 01:10:46 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 4194612EB23; Thu, 18 Jan 2018 01:10:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Susan Hares 
To: 
Cc: draft-ietf-netmod-rfc7223bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151626664023.10730.14013106005058631988@ietfa.amsl.com>
Date: Thu, 18 Jan 2018 01:10:40 -0800
Archived-At: 
Subject: [netmod] Rtgdir telechat review of draft-ietf-netmod-rfc7223bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 09:10:40 -0000

Reviewer: Susan Hares
Review result: Ready

Status: Ready to Go.

General comments:  Excellent document, well written and extremely readable. 
Appendices add to the document. Suggestion: Progress this document quickly
since it handles revised datastores work.

Technical side-comment:  I know I am in a minority position, but I personally
dislike the lack of versioning and the "deprecated" function.



From nobody Thu Jan 18 04:58: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 D7AB012D94C for ; Thu, 18 Jan 2018 04:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 eBYPHBNvlydr for ; Thu, 18 Jan 2018 04:58:14 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 2FD111201FA for ; Thu, 18 Jan 2018 04:58:14 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id E48981E0690 for ; Thu, 18 Jan 2018 05:58:13 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id zoyA1w0062SSUrH01oyDUF; Thu, 18 Jan 2018 05:58:13 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=B3I4fpRw_GwwlhMKXCEA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Vc5GtEy9cs7bkbp0PUNWoM5MRsukcLS8VE+PqTu3fT4=; b=f9UdIJnbnnswT9S8Q0P5u/h/Bp wIi09y6tW33l2woU8ealx9hNFPir7JYzaiaeyAhe+RcnQx1Uzrfn9s/+ZVXq8cYWuWD0VDOvxmELG 4MnRWThudr/XQXR2pnFRkwTpB;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:55326 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ec9lh-000cPw-TV; Thu, 18 Jan 2018 05:58:10 -0700
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Thu, 18 Jan 2018 07:58:07 -0500
Message-ID: <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20180118.085648.2091191419931632376.mbj@tail-f.com>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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-Exim-ID: 1ec9lh-000cPw-TV
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:55326
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 12:58:16 -0000

Martin,

I do agree with that at some point we will need to revisit scheme mount in 
the context of YL-bis, as there are different possible solutions for 
handling different datastores mounting  different schema. I think Rob laid 
out the options pretty well here, ie doing it now or publishing as is and 
immediately working on the document that covers both.

As I mentioned before I think this is as much a process issue as anything 
else - and have a planned call to discuss possible directions with chairs. 
I hope we can have some propose next steps on this to the working group in 
short order.

Lou


On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>>
>>
>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>> ...
>> >>> My main concern is actually the YL version.  I strongly think SM need
>> >>> to use YL-bis rather that the old YL, so that it can support NMDA.
>> >>>
>> >> Right now to SM is independent of Yang Library version and can run
>> >> with either.
>> > No this is not correct.  SM uses a grouping from the old YANG
>> > library (for the "use-schema" case),
>> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
>> can include either.
>
> The old "modules-state" structure is deprecated, and a new structure
> that allows multiple datastores is defined.  Note that YLbis can be
> used by both NMDA-capabale and non-NMDA-capabale servers.
>
>> >   and talks about mounting
>> > "modules-state" ("inline" case).
>> In informative descriptions only.  Certainly these can be changed to
>> allow for YL-bis if need be.
>>
>> >> I certainly would expect use of Yang Library bis and nmda
>> >> to have advantages.
>> >>
>> >>> The implementation effort for supporting the new YL in clients and
>> >>> servers is minimal, esp. when compared to the efforts involved in
>> >>> supporting SM.
>> >>>
>> >>> Adding an indirection is (for me) less important, but it has the
>> >>> benefit of solving the two issues (a) and (b) above, and I haven't
>> >>> seen any technical problem with it.
>> >>>
>> >> (A) has implementation implications and those participating in the
>> >> discussion at the time expressed as not being worth the cost.
>> >> I don't believe b was seen as a significant issue either.
>> >>
>> >>> Do you have any technical concerns with using an annotation as an
>> >>> indirection?
>> >>>
>> >> The technicsl issue I have with the approaches the same one that was
>> >> raised when debated previously, ie the implementation overhead of
>> >> requiring inline schemas to be available at the top level.
>> > Ok.  I'm ok with keeping the inline case as it is.  However, I think
>> > we need to use the new YL-bis, so that we can support the NMDA.
>> Given that NMDA support is not yet fully defined, we're still in the
>> transition period where support for both NMDA and non-NMDA
>> implementations need to be considered.  Rob presented some options
>> earlier in the thread that I think captures this.
>
> Again, note that YLbis supports both NMDA and non-NMDA servers.
>
> Also note that YLbis is just a different read-only monitoring
> structure.  Given an implementation that supports the old YL, it is
> trivial to add support for YLbis (especially compared to the more than
> non-trivial amount of work required to support schema mount...).
>
>
> /martin
>



From nobody Thu Jan 18 05:39: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 8B1B4126D74 for ; Thu, 18 Jan 2018 05:39:29 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 uYPSy_dT72K3 for ; Thu, 18 Jan 2018 05:39:27 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0892312700F for ; Thu, 18 Jan 2018 05:39:23 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 845C5F79; Thu, 18 Jan 2018 14:39:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id DtVZGAtNVvf8; Thu, 18 Jan 2018 14:39:20 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Jan 2018 14:39:21 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C39020152; Thu, 18 Jan 2018 14:39:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vWSN2ot8Axdm; Thu, 18 Jan 2018 14:39:20 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5541320149; Thu, 18 Jan 2018 14:39:20 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 3973342152CF; Thu, 18 Jan 2018 14:39:20 +0100 (CET)
Date: Thu, 18 Jan 2018 14:39:20 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20180118133920.aerpan7jdbtre3f3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com> <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 13:39:31 -0000

Ignoring process issues (not sure there are any), does it make sense
to publish a YANG module on the standards-track that is replaced by
something different 3-6 months later?

Note that the NMDA contributors, after getting the overall design
done, move sequentially through the details of the documents; we first
focused on the NMDA document, which is in the RFC editor queue now. We
then focussed on the protocol extensions, which are now in WG last
call. Currently we are focusing on getting the new yang library
finalized. If no major isses pop up, the NMDA work may be complete by
the London IETF. Hence the 3 months lower bound mentioned above.

/js

On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> Martin,
> 
> I do agree with that at some point we will need to revisit scheme mount in
> the context of YL-bis, as there are different possible solutions for
> handling different datastores mounting  different schema. I think Rob laid
> out the options pretty well here, ie doing it now or publishing as is and
> immediately working on the document that covers both.
> 
> As I mentioned before I think this is as much a process issue as anything
> else - and have a planned call to discuss possible directions with chairs. I
> hope we can have some propose next steps on this to the working group in
> short order.
> 
> Lou
> 
> 
> On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
> 
> > Lou Berger  wrote:
> > > 
> > > 
> > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > ...
> > > >>> My main concern is actually the YL version.  I strongly think SM need
> > > >>> to use YL-bis rather that the old YL, so that it can support NMDA.
> > > >>>
> > > >> Right now to SM is independent of Yang Library version and can run
> > > >> with either.
> > > > No this is not correct.  SM uses a grouping from the old YANG
> > > > library (for the "use-schema" case),
> > > I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> > > can include either.
> > 
> > The old "modules-state" structure is deprecated, and a new structure
> > that allows multiple datastores is defined.  Note that YLbis can be
> > used by both NMDA-capabale and non-NMDA-capabale servers.
> > 
> > > >   and talks about mounting
> > > > "modules-state" ("inline" case).
> > > In informative descriptions only. Certainly these can be changed to
> > > allow for YL-bis if need be.
> > > 
> > > >> I certainly would expect use of Yang Library bis and nmda
> > > >> to have advantages.
> > > >>
> > > >>> The implementation effort for supporting the new YL in clients and
> > > >>> servers is minimal, esp. when compared to the efforts involved in
> > > >>> supporting SM.
> > > >>>
> > > >>> Adding an indirection is (for me) less important, but it has the
> > > >>> benefit of solving the two issues (a) and (b) above, and I haven't
> > > >>> seen any technical problem with it.
> > > >>>
> > > >> (A) has implementation implications and those participating in the
> > > >> discussion at the time expressed as not being worth the cost.
> > > >> I don't believe b was seen as a significant issue either.
> > > >>
> > > >>> Do you have any technical concerns with using an annotation as an
> > > >>> indirection?
> > > >>>
> > > >> The technicsl issue I have with the approaches the same one that was
> > > >> raised when debated previously, ie the implementation overhead of
> > > >> requiring inline schemas to be available at the top level.
> > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > we need to use the new YL-bis, so that we can support the NMDA.
> > > Given that NMDA support is not yet fully defined, we're still in the
> > > transition period where support for both NMDA and non-NMDA
> > > implementations need to be considered. Rob presented some options
> > > earlier in the thread that I think captures this.
> > 
> > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > 
> > Also note that YLbis is just a different read-only monitoring
> > structure.  Given an implementation that supports the old YL, it is
> > trivial to add support for YLbis (especially compared to the more than
> > non-trivial amount of work required to support schema mount...).
> > 
> > 
> > /martin
> > 
> 
> 
> _______________________________________________
> 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 Thu Jan 18 07:58: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 E0B971204DA for ; Thu, 18 Jan 2018 07:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Chtd8NDZWF for ; Thu, 18 Jan 2018 07:58:06 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00103.outbound.protection.outlook.com [40.107.0.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F22312426E for ; Thu, 18 Jan 2018 07:58:06 -0800 (PST)
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; bh=utMohTB6UUDaaLhMg1uO59F9grZrl/Ftvt2woFYp+3M=; b=SuHpieCsh4tB4ZM0iwuFahIlhMcxqlUO+Uo4DeW84qEPyJeA27+jxGx9Ncauw+wCBHNkq9wF36E5YNn6c/fUimcrUzuRgDiNPk7wziJ6+ZS8LiaecnQPtGJdk0JKwfZzbMzy+1Rs0H7FmuxFlikBDR3CJQ5QseTJmXqQh0r0Di8=
Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB3121.eurprd07.prod.outlook.com (10.171.188.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Thu, 18 Jan 2018 15:58:04 +0000
Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::6577:7cc5:dea1:4182]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::6577:7cc5:dea1:4182%13]) with mapi id 15.20.0428.014; Thu, 18 Jan 2018 15:58:03 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt
Thread-Index: AQHTivL1k2GgPkr4Hk2kAwOkqwql+KN50hBA
Date: Thu, 18 Jan 2018 15:58:03 +0000
Message-ID: 
References: <151568539269.29588.1124423893874376613@ietfa.amsl.com>
In-Reply-To: <151568539269.29588.1124423893874376613@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.212.30]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB3121; 7:tK3c0lrbTJAiT8RYxDABhHsABI8O0utuXTuTIMeXtRItWRIwLUk7XkYI1mP/CEa5km0eRKq/ImIftFqnXU6TMCk8p4ZCFdTNG3fgOIpq/b6Erj9t7sliuc/fNUavj9HXn50ZRI+fiyMauVxejPvmJzyJrLhVL4oxFX4906kMrzHUyutaErUYX6Y6goXZeqZXNBN1uItXYpTf8Sjs5HY0FiGPpeQ+C6dIsjzlGG7+qQ1wZqq8hZIoXjwv55shPjuZ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fb7b1411-cd1e-49b0-c1d1-08d55e8c4210
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB3121; 
x-ms-traffictypediagnostic: AM4PR07MB3121:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040492)(2401047)(8121501046)(5005006)(3231046)(11241501184)(806099)(2400063)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041279)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB3121; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3121; 
x-forefront-prvs: 05568D1FF7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39380400002)(39860400002)(396003)(189003)(199004)(377424004)(13464003)(7696005)(5660300001)(66066001)(99286004)(25786009)(5250100002)(68736007)(6506007)(105586002)(316002)(53936002)(81156014)(6246003)(53546011)(81166006)(8936002)(106356001)(1730700003)(76176011)(6306002)(9686003)(102836004)(86362001)(3846002)(97736004)(2351001)(6116002)(8676002)(2900100001)(230783001)(6916009)(229853002)(2950100002)(5640700003)(55016002)(74316002)(6436002)(2906002)(14454004)(26005)(33656002)(2501003)(305945005)(7736002)(966005)(3660700001)(478600001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3121; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: HIRpfzv7XJ0AmMF+f6UeVhv4+N+CtkIHTq47XDwkWYX+ij59GI1FcwQ1Gx+R4UXfOO6er6a1qFlGCEldxTYBdWi3mE+6fD4y1At8IsNf8FY1yJSw65gz5r5sHdMqEkOt
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb7b1411-cd1e-49b0-c1d1-08d55e8c4210
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 15:58:03.9151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3121
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 15:58:09 -0000

Hi,

We do have a question about the operational-state value 'not-present'.  The=
 revised data store draft document mentions that for resources that are not=
 available (e.g. HW components) there will not be an entry for the state (s=
ee section 5.3.2) so for equipment there will never be a state entry where =
the operational state is 'not-present'.  For interfaces it appears to us th=
at if an interface is related to a HW component that is not there the opera=
tional state is either down of lower-layer-down depending on the position i=
n the interface stack.

Is there a need to keep the value 'not-present'  for operational-state?

Regards, Bart

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-drafts@=
ietf.org
Sent: Thursday, January 11, 2018 4:43 PM
To: i-d-announce@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : A YANG Data Model for Interface Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc7223bis-03.txt
	Pages           : 48
	Date            : 2018-01-11

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface-type-specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes definitions for configuration and system
   state (status information and counters for the collection of
   statistics).

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

   This document obsoletes RFC 7223.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7223bis-03


Please note that it may take a couple of minutes from the time of submissio=
n 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/

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


From nobody Thu Jan 18 08:25:47 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 8265F126D45 for ; Thu, 18 Jan 2018 08:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 ftQz0DahrTXc for ; Thu, 18 Jan 2018 08:25:44 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 9EF32126CBF for ; Thu, 18 Jan 2018 08:25:44 -0800 (PST)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0IGPh0q080539 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 18 Jan 2018 16:25:43 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local
To: Juergen Schoenwaelder , Lou Berger 
Cc: netmod@ietf.org
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com> <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local>
From: joel jaeggli 
Message-ID: <1e37fe97-d434-2ada-22e4-d109ad872a5d@bogus.com>
Date: Thu, 18 Jan 2018 08:25:35 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180118133920.aerpan7jdbtre3f3@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ip5SNBQ4yVm5yhysP70ASrW6mUNnftJbi"
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 16:25:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ip5SNBQ4yVm5yhysP70ASrW6mUNnftJbi
Content-Type: multipart/mixed; boundary="Ebn99VYIqr8RIZNa1gW9xyflTM7pdQpi4";
 protected-headers="v1"
From: joel jaeggli 
To: Juergen Schoenwaelder ,
 Lou Berger 
Cc: netmod@ietf.org
Message-ID: <1e37fe97-d434-2ada-22e4-d109ad872a5d@bogus.com>
Subject: Re: [netmod] schema mount and YANG library
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
 <20180117.171817.479473055872371790.mbj@tail-f.com>
 <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net>
 <20180118.085648.2091191419931632376.mbj@tail-f.com>
 <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
 <20180118133920.aerpan7jdbtre3f3@elstar.local>
In-Reply-To: <20180118133920.aerpan7jdbtre3f3@elstar.local>

--Ebn99VYIqr8RIZNa1gW9xyflTM7pdQpi4
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 1/18/18 05:39, Juergen Schoenwaelder wrote:
> Ignoring process issues (not sure there are any), does it make sense
> to publish a YANG module on the standards-track that is replaced by
> something different 3-6 months later?

Perhaps I apply a different discount rate on the future particularly
when timelines are involved. e.g. 3 months turns into a year and half
pretty quickly.

I think it's more a question of can we live with publishing the module
now as is? Or can  we not live with publishing it now?

> Note that the NMDA contributors, after getting the overall design
> done, move sequentially through the details of the documents; we first
> focused on the NMDA document, which is in the RFC editor queue now. We
> then focussed on the protocol extensions, which are now in WG last
> call. Currently we are focusing on getting the new yang library
> finalized. If no major isses pop up, the NMDA work may be complete by
> the London IETF. Hence the 3 months lower bound mentioned above.
>=20
> /js
>=20
> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
>> Martin,
>>
>> I do agree with that at some point we will need to revisit scheme moun=
t in
>> the context of YL-bis, as there are different possible solutions for
>> handling different datastores mounting  different schema. I think Rob =
laid
>> out the options pretty well here, ie doing it now or publishing as is =
and
>> immediately working on the document that covers both.
>>
>> As I mentioned before I think this is as much a process issue as anyth=
ing
>> else - and have a planned call to discuss possible directions with cha=
irs. I
>> hope we can have some propose next steps on this to the working group =
in
>> short order.
>>
>> Lou
>>
>>
>> On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote=
:
>>
>>> Lou Berger  wrote:
>>>>
>>>>
>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>>>> ...
>>>>>>> My main concern is actually the YL version.  I strongly think SM =
need
>>>>>>> to use YL-bis rather that the old YL, so that it can support NMDA=
=2E
>>>>>>>
>>>>>> Right now to SM is independent of Yang Library version and can run=

>>>>>> with either.
>>>>> No this is not correct.  SM uses a grouping from the old YANG
>>>>> library (for the "use-schema" case),
>>>> I thought YLbis was an updat e to UL (i.e., no name change) as such =
SM
>>>> can include either.
>>>
>>> The old "modules-state" structure is deprecated, and a new structure
>>> that allows multiple datastores is defined.  Note that YLbis can be
>>> used by both NMDA-capabale and non-NMDA-capabale servers.
>>>
>>>>>   and talks about mounting
>>>>> "modules-state" ("inline" case).
>>>> In informative descriptions only.=C2=A0 Certainly these can be chang=
ed to
>>>> allow for YL-bis if need be.
>>>>
>>>>>> I certainly would expect use of Yang Library bis and nmda
>>>>>> to have advantages.
>>>>>>
>>>>>>> The implementation effort for supporting the new YL in clients an=
d
>>>>>>> servers is minimal, esp. when compared to the efforts involved in=

>>>>>>> supporting SM.
>>>>>>>
>>>>>>> Adding an indirection is (for me) less important, but it has the
>>>>>>> benefit of solving the two issues (a) and (b) above, and I haven'=
t
>>>>>>> seen any technical problem with it.
>>>>>>>
>>>>>> (A) has implementation implications and those participating in the=

>>>>>> discussion at the time expressed as not being worth the cost.
>>>>>> I don't believe b was seen as a significant issue either.
>>>>>>
>>>>>>> Do you have any technical concerns with using an annotation as an=

>>>>>>> indirection?
>>>>>>>
>>>>>> The technicsl issue I have with the approaches the same one that w=
as
>>>>>> raised when debated previously, ie the implementation overhead of
>>>>>> requiring inline schemas to be available at the top level.
>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I thin=
k
>>>>> we need to use the new YL-bis, so that we can support the NMDA.
>>>> Given that NMDA support is not yet fully defined, we're still in the=

>>>> transition period where support for both NMDA and non-NMDA
>>>> implementations need to be considered.=C2=A0 Rob presented some opti=
ons
>>>> earlier in the thread that I think captures this.
>>>
>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
>>>
>>> Also note that YLbis is just a different read-only monitoring
>>> structure.  Given an implementation that supports the old YL, it is
>>> trivial to add support for YLbis (especially compared to the more tha=
n
>>> non-trivial amount of work required to support schema mount...).
>>>
>>>
>>> /martin
>>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20



--Ebn99VYIqr8RIZNa1gW9xyflTM7pdQpi4--

--Ip5SNBQ4yVm5yhysP70ASrW6mUNnftJbi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWmDKgAAKCRDwADWrtn9W
sgZuAJ9TVSmlnJmAkl8HsRwVwTMEgqyk5wCbBKOv2Y+iWAXJfBZ/uVtWvEiPcMo=
=b+7q
-----END PGP SIGNATURE-----

--Ip5SNBQ4yVm5yhysP70ASrW6mUNnftJbi--


From nobody Thu Jan 18 09:32: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 40F27129516 for ; Thu, 18 Jan 2018 09:32:02 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 BtWp9zq7RgbV for ; Thu, 18 Jan 2018 09:32:00 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CB2128961 for ; Thu, 18 Jan 2018 09:31:58 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 48D106B7; Thu, 18 Jan 2018 18:31:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id WnxK28o9dTQh; Thu, 18 Jan 2018 18:31:55 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Jan 2018 18:31:57 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04E8920147; Thu, 18 Jan 2018 18:31:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aedCrTi23fkv; Thu, 18 Jan 2018 18:31:56 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 702A920144; Thu, 18 Jan 2018 18:31:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D9ABE421FF23; Thu, 18 Jan 2018 18:31:53 +0100 (CET)
Date: Thu, 18 Jan 2018 18:31:53 +0100
From: Juergen Schoenwaelder 
To: joel jaeggli 
Cc: Lou Berger , netmod@ietf.org
Message-ID: <20180118173153.cd5okqs3rqj6s46r@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: joel jaeggli , Lou Berger , netmod@ietf.org
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com> <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local> <1e37fe97-d434-2ada-22e4-d109ad872a5d@bogus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1e37fe97-d434-2ada-22e4-d109ad872a5d@bogus.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 17:32:02 -0000

On Thu, Jan 18, 2018 at 08:25:35AM -0800, joel jaeggli wrote:
> 
> Perhaps I apply a different discount rate on the future particularly
> when timelines are involved. e.g. 3 months turns into a year and half
> pretty quickly.

I provided a reasoning why 3 months may be feasible, I doubled it
since its the IETF. You may apply the factor 6. But note that the last
piece of NMDA (the YANG library) is work reasonably well understood
with people dedicated to finish the last piece (obviously my very
biased view).

> I think it's more a question of can we live with publishing the module
> now as is? Or can  we not live with publishing it now?

The question is what we expect implementors to do and how we think
about achieving interoperability by publishing two significantly
different versions instead of one.

/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 Jan 18 10:30: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 9B7D8129C53 for ; Thu, 18 Jan 2018 10:30:54 -0800 (PST)
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 jukkBFVVYxEV for ; Thu, 18 Jan 2018 10:30:53 -0800 (PST)
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 E0F1712895E for ; Thu, 18 Jan 2018 10:30:52 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0IIO1BC008535; Thu, 18 Jan 2018 10:30:51 -0800
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=YmquMheHEzJd1q5z+ZPdCC5k9b3CDCl+keqrmA/VncU=; b=Ei8HbK0ZyRxEhVLVqn6g+CThsYRCn0jj5q0xZi6AtfgxaFQYTWP7aoiWPf9o/LK5M0MQ wzcvNxHqC50wL7BgijrGO/7NfOI4gFGs8axPFfsg6Zc5R0o7sh/2TvVWuib8cYPyQiLq KwUX1e06VGZiT3+5TcVmJEdvxB06LhHN+BB9yzMMVxNIbn/gS/rxhaIRxiEJQsOEhmwR /8m0ZAWWr8Io/yVYhG/VlLZhFr64yE/8japs+OrD7ixa+V4rQ/7yxZRdFsT4sRMbQQc3 NRIV0WsS3LuX1wsfB6bPzt5w16jLS8gBgYTddHpus/vxHqrsgxnnPOQa8w0Pei8Us+gv tw== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0016.outbound.protection.outlook.com [216.32.180.16]) by mx0b-00273201.pphosted.com with ESMTP id 2fk0tpr0vk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jan 2018 10:30:51 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5SPR00MB107.namprd05.prod.outlook.com (10.174.178.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Thu, 18 Jan 2018 18:30:49 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0428.014; Thu, 18 Jan 2018 18:30:49 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "EXT - joelja@bogus.com" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount and YANG library
Thread-Index: AQHTcDnC+LdQVLmjCEySNKfGe/5DBKNEeVYAgAUkMwCAAKKRgIAAVj0AgAAAtoCAAAXQgIAADrKAgAADggCAAAqGAIAq80GAgACl5oCAAEeFAIAACjwAgAAFgQCAABAegIAAAXeAgAAFyICAAAmmgIAADb+AgAAFsYCAAAR+AIAABzCAgAAVSQCAAPgTAIAAY9GAgAAG7oCAABEjgIAACb2AgAAuSwCAANftAIAAVDCAgAALhACAAC5zgIAAEoeA//+8pAA=
Date: Thu, 18 Jan 2018 18:30:49 +0000
Message-ID: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com> <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local> <1e37fe97-d434-2ada-22e4-d109ad872a5d@bogus.com> <20180118173153.cd5okqs3rqj6s46r@elstar.local>
In-Reply-To: <20180118173153.cd5okqs3rqj6s46r@elstar.local>
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; DM5SPR00MB107; 7:eC85vxxjaTURjIIYqIBfqJa320NJuIGIIrK2rw48MFL6XR3qnmKm+gPmLPPB92cM/gUpPC+Q/etJCshgeZ0WURynilfiEeOI0TBFgRRam0g5G+HDXx/CH3gTGmqlYIeTNjkNuulncpAwRgcbzwxtWsCaHPDIqJJAHWJe0bjIObqmNF/sR1H1hYoCptursByMiGkDO6fjbX1hKzWjoWugnnrLOOLVxfbi/CnkcB0pkj1ioGU03uCXWV392Cz9Hltf
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2fec48d2-92fc-4974-a3d6-08d55ea19952
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5SPR00MB107; 
x-ms-traffictypediagnostic: DM5SPR00MB107:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(944501161)(3002001)(6055026)(6041268)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5SPR00MB107; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5SPR00MB107; 
x-forefront-prvs: 05568D1FF7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(366004)(39860400002)(346002)(376002)(189003)(199004)(99286004)(33656002)(97736004)(3280700002)(2900100001)(3660700001)(8676002)(8936002)(68736007)(105586002)(106356001)(6246003)(81156014)(14454004)(478600001)(81166006)(36756003)(77096007)(2950100002)(110136005)(102836004)(76176011)(5660300001)(6506007)(82746002)(7736002)(93886005)(3846002)(6116002)(2906002)(58126008)(66066001)(53936002)(6512007)(26005)(316002)(305945005)(25786009)(6486002)(83506002)(86362001)(83716003)(229853002)(4326008)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5SPR00MB107; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lv83nqW8d8f0/SGVFXZUCVWR8vhTqvanLEScK/cxiVBiXMdFiJi9iYUWvuikbbgjq6wF2JLD26nDajeYYGu5xw==
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: 2fec48d2-92fc-4974-a3d6-08d55ea19952
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 18:30:49.7087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB107
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_08:, , 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-1711220000 definitions=main-1801180244
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 18:30:55 -0000

DQo+T24gVGh1LCBKYW4gMTgsIDIwMTggYXQgMDg6MjU6MzVBTSAtMDgwMCwgam9lbCBqYWVnZ2xp
IHdyb3RlOg0KPj4gDQo+PiBQZXJoYXBzIEkgYXBwbHkgYSBkaWZmZXJlbnQgZGlzY291bnQgcmF0
ZSBvbiB0aGUgZnV0dXJlIHBhcnRpY3VsYXJseQ0KPj4gd2hlbiB0aW1lbGluZXMgYXJlIGludm9s
dmVkLiBlLmcuIDMgbW9udGhzIHR1cm5zIGludG8gYSB5ZWFyIGFuZCBoYWxmDQo+PiBwcmV0dHkg
cXVpY2tseS4NCj4NCj4gSSBwcm92aWRlZCBhIHJlYXNvbmluZyB3aHkgMyBtb250aHMgbWF5IGJl
IGZlYXNpYmxlLCBJIGRvdWJsZWQgaXQNCj4gc2luY2UgaXRzIHRoZSBJRVRGLiBZb3UgbWF5IGFw
cGx5IHRoZSBmYWN0b3IgNi4gQnV0IG5vdGUgdGhhdCB0aGUgbGFzdA0KPiBwaWVjZSBvZiBOTURB
ICh0aGUgWUFORyBsaWJyYXJ5KSBpcyB3b3JrIHJlYXNvbmFibHkgd2VsbCB1bmRlcnN0b29kDQo+
IHdpdGggcGVvcGxlIGRlZGljYXRlZCB0byBmaW5pc2ggdGhlIGxhc3QgcGllY2UgKG9idmlvdXNs
eSBteSB2ZXJ5DQo+IGJpYXNlZCB2aWV3KS4NCg0KSSBiZWxpZXZlIHRoZSBpc3N1ZSBpc24ndCBz
byBtdWNoIHRoZSB0aW1pbmcgb24gdGhlIFlBTkcgTGlicmFyeSBiaXMsDQpzbyBtdWNoIGFzIHRo
ZSB0aW1pbmcgb24gaGF2aW5nIGFuIHVwZGF0ZWQgc2NoZW1hLW1vdW50IGRyYWZ0IHRoYXQgDQpp
cyBOTURBLWNvbXBhdGlibGUuDQoNCg0KPj4gSSB0aGluayBpdCdzIG1vcmUgYSBxdWVzdGlvbiBv
ZiBjYW4gd2UgbGl2ZSB3aXRoIHB1Ymxpc2hpbmcgdGhlIG1vZHVsZQ0KPj4gbm93IGFzIGlzPyBP
ciBjYW4gIHdlIG5vdCBsaXZlIHdpdGggcHVibGlzaGluZyBpdCBub3c/DQo+DQo+IFRoZSBxdWVz
dGlvbiBpcyB3aGF0IHdlIGV4cGVjdCBpbXBsZW1lbnRvcnMgdG8gZG8gYW5kIGhvdyB3ZSB0aGlu
aw0KPiBhYm91dCBhY2hpZXZpbmcgaW50ZXJvcGVyYWJpbGl0eSBieSBwdWJsaXNoaW5nIHR3byBz
aWduaWZpY2FudGx5DQo+IGRpZmZlcmVudCB2ZXJzaW9ucyBpbnN0ZWFkIG9mIG9uZS4NCg0KQWdy
ZWVkLCB3ZSB3aWxsIG5lZWQgdG8gcHJvdmlkZSBndWlkYW5jZSB3aXRoIHRoaXMgYXBwcm9hY2gu
DQoNCg0KS2VudCAvLyBub2JvZHkNCg0KDQo=


From nobody Thu Jan 18 10:47:54 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 9A86D12D7EB for ; Thu, 18 Jan 2018 10:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZiE0UUn_RMuC for ; Thu, 18 Jan 2018 10:47:52 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612AB12D77D for ; Thu, 18 Jan 2018 10:47:52 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 7D72CB813D5; Thu, 18 Jan 2018 10:47:45 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: muly_i@rad.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180118184745.7D72CB813D5@rfc-editor.org>
Date: Thu, 18 Jan 2018 10:47:45 -0800 (PST)
Archived-At: 
Subject: [netmod] [Editorial Errata Reported] RFC7950 (5237)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 18:47:53 -0000

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5237

--------------------------------------
Type: Editorial
Reported by: Muly Ilan 

Section: 6.4.1.1

Original Text
-------------
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "when" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Corrected Text
--------------
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "delay" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Notes
-----
The example action "reset" has an input parameter named "delay" and not a parameter named "when".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Jan 18 11:10:52 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 685C112D7F0 for ; Thu, 18 Jan 2018 11:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 s0GtF7qVXCGc for ; Thu, 18 Jan 2018 11:10:41 -0800 (PST)
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 A5E48129C56 for ; Thu, 18 Jan 2018 11:10:39 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:b461:31ff:fe16:2699]) by mail.nic.cz (Postfix) with ESMTPSA id 8AB3C64E9E for ; Thu, 18 Jan 2018 20:10:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516302637; bh=c999QN6MdDTCv324addjBv8l6ndl6El6ovmAis/SqPY=; h=From:To:Date; b=bB2a37POgerZxiuHRgXuKkMovtflnaNB1S5fkrMyiElwxmR5zzWHwd/4RuxQ5hF6Y PwCDR+YUNIIdlLCGJ2tn0wub/LrW18Tu/A2dadFavYNQDOunEqxO9w8Pw0MFCg22Fe iBh970lMz6haPKKMqtcA07WIRPudUt3bIY8pJN0U=
Message-ID: <1516302637.22408.23.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Thu, 18 Jan 2018 20:10:37 +0100
In-Reply-To: <20180118133920.aerpan7jdbtre3f3@elstar.local>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <5d8b65cf-e75e-e11e-a41a-722697ec3af8@labn.net> <20180118.085648.2091191419931632376.mbj@tail-f.com> <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 19:10:43 -0000

On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> Ignoring process issues (not sure there are any), does it make sense
> to publish a YANG module on the standards-track that is replaced by
> something different 3-6 months later?

IMO such a document churn would be a serious mistake. In the documents that are
currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
few tricky and interrelated things, so it's important to come up with a coherent
view into which all the components nicely fit. And I believe we are now quite
close.

Publishing an interim solution that is a priori known to be technically inferior
would just confuse people. The fact that it can be hacked to support two or
three particular data models (albeit important) doesn't warrant to do so.

> 
> Note that the NMDA contributors, after getting the overall design
> done, move sequentially through the details of the documents; we first
> focused on the NMDA document, which is in the RFC editor queue now. We
> then focussed on the protocol extensions, which are now in WG last
> call. Currently we are focusing on getting the new yang library
> finalized. If no major isses pop up, the NMDA work may be complete by
> the London IETF. Hence the 3 months lower bound mentioned above.

I agree, and will try to help.

Thanks, Lada

> 
> /js
> 
> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> > Martin,
> > 
> > I do agree with that at some point we will need to revisit scheme mount in
> > the context of YL-bis, as there are different possible solutions for
> > handling different datastores mounting  different schema. I think Rob laid
> > out the options pretty well here, ie doing it now or publishing as is and
> > immediately working on the document that covers both.
> > 
> > As I mentioned before I think this is as much a process issue as anything
> > else - and have a planned call to discuss possible directions with chairs. I
> > hope we can have some propose next steps on this to the working group in
> > short order.
> > 
> > Lou
> > 
> > 
> > On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
> > 
> > > Lou Berger  wrote:
> > > > 
> > > > 
> > > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > > ...
> > > > > > > My main concern is actually the YL version.  I strongly think SM
> > > > > > > need
> > > > > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > > > > 
> > > > > > 
> > > > > > Right now to SM is independent of Yang Library version and can run
> > > > > > with either.
> > > > > 
> > > > > No this is not correct.  SM uses a grouping from the old YANG
> > > > > library (for the "use-schema" case),
> > > > 
> > > > I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> > > > can include either.
> > > 
> > > The old "modules-state" structure is deprecated, and a new structure
> > > that allows multiple datastores is defined.  Note that YLbis can be
> > > used by both NMDA-capabale and non-NMDA-capabale servers.
> > > 
> > > > >   and talks about mounting
> > > > > "modules-state" ("inline" case).
> > > > 
> > > > In informative descriptions only.  Certainly these can be changed to
> > > > allow for YL-bis if need be.
> > > > 
> > > > > > I certainly would expect use of Yang Library bis and nmda
> > > > > > to have advantages.
> > > > > > 
> > > > > > > The implementation effort for supporting the new YL in clients and
> > > > > > > servers is minimal, esp. when compared to the efforts involved in
> > > > > > > supporting SM.
> > > > > > > 
> > > > > > > Adding an indirection is (for me) less important, but it has the
> > > > > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > > > > seen any technical problem with it.
> > > > > > > 
> > > > > > 
> > > > > > (A) has implementation implications and those participating in the
> > > > > > discussion at the time expressed as not being worth the cost.
> > > > > > I don't believe b was seen as a significant issue either.
> > > > > > 
> > > > > > > Do you have any technical concerns with using an annotation as an
> > > > > > > indirection?
> > > > > > > 
> > > > > > 
> > > > > > The technicsl issue I have with the approaches the same one that was
> > > > > > raised when debated previously, ie the implementation overhead of
> > > > > > requiring inline schemas to be available at the top level.
> > > > > 
> > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > > we need to use the new YL-bis, so that we can support the NMDA.
> > > > 
> > > > Given that NMDA support is not yet fully defined, we're still in the
> > > > transition period where support for both NMDA and non-NMDA
> > > > implementations need to be considered.  Rob presented some options
> > > > earlier in the thread that I think captures this.
> > > 
> > > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > > 
> > > Also note that YLbis is just a different read-only monitoring
> > > structure.  Given an implementation that supports the old YL, it is
> > > trivial to add support for YLbis (especially compared to the more than
> > > non-trivial amount of work required to support schema mount...).
> > > 
> > > 
> > > /martin
> > > 
> > 
> > 
> > _______________________________________________
> > 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 Thu Jan 18 11:15: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 A970812D574 for ; Thu, 18 Jan 2018 11:15:45 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 DM1JIgfth-lT for ; Thu, 18 Jan 2018 11:15:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAE8129C56 for ; Thu, 18 Jan 2018 11:15:44 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id EDF301AE0398; Thu, 18 Jan 2018 20:15:42 +0100 (CET)
Date: Thu, 18 Jan 2018 20:15:35 +0100 (CET)
Message-Id: <20180118.201535.2290905942673102021.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1516302637.22408.23.camel@nic.cz>
References: <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local> <1516302637.22408.23.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 19:15:46 -0000

Ladislav Lhotka  wrote:
> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> > Ignoring process issues (not sure there are any), does it make sense
> > to publish a YANG module on the standards-track that is replaced by
> > something different 3-6 months later?
> 
> IMO such a document churn would be a serious mistake. In the documents that are
> currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
> few tricky and interrelated things, so it's important to come up with a coherent
> view into which all the components nicely fit. And I believe we are now quite
> close.
> 
> Publishing an interim solution that is a priori known to be technically inferior
> would just confuse people. The fact that it can be hacked to support two or
> three particular data models (albeit important) doesn't warrant to do so.

I strongly agree with this!


/martin

> > 
> > Note that the NMDA contributors, after getting the overall design
> > done, move sequentially through the details of the documents; we first
> > focused on the NMDA document, which is in the RFC editor queue now. We
> > then focussed on the protocol extensions, which are now in WG last
> > call. Currently we are focusing on getting the new yang library
> > finalized. If no major isses pop up, the NMDA work may be complete by
> > the London IETF. Hence the 3 months lower bound mentioned above.
> 
> I agree, and will try to help.
> 
> Thanks, Lada
> 
> > 
> > /js
> > 
> > On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> > > Martin,
> > > 
> > > I do agree with that at some point we will need to revisit scheme mount in
> > > the context of YL-bis, as there are different possible solutions for
> > > handling different datastores mounting  different schema. I think Rob laid
> > > out the options pretty well here, ie doing it now or publishing as is and
> > > immediately working on the document that covers both.
> > > 
> > > As I mentioned before I think this is as much a process issue as anything
> > > else - and have a planned call to discuss possible directions with chairs. I
> > > hope we can have some propose next steps on this to the working group in
> > > short order.
> > > 
> > > Lou
> > > 
> > > 
> > > On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
> > > 
> > > > Lou Berger  wrote:
> > > > > 
> > > > > 
> > > > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > > > ...
> > > > > > > > My main concern is actually the YL version.  I strongly think SM
> > > > > > > > need
> > > > > > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > > > > > 
> > > > > > > 
> > > > > > > Right now to SM is independent of Yang Library version and can run
> > > > > > > with either.
> > > > > > 
> > > > > > No this is not correct.  SM uses a grouping from the old YANG
> > > > > > library (for the "use-schema" case),
> > > > > 
> > > > > I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> > > > > can include either.
> > > > 
> > > > The old "modules-state" structure is deprecated, and a new structure
> > > > that allows multiple datastores is defined.  Note that YLbis can be
> > > > used by both NMDA-capabale and non-NMDA-capabale servers.
> > > > 
> > > > > >   and talks about mounting
> > > > > > "modules-state" ("inline" case).
> > > > > 
> > > > > In informative descriptions only.  Certainly these can be changed to
> > > > > allow for YL-bis if need be.
> > > > > 
> > > > > > > I certainly would expect use of Yang Library bis and nmda
> > > > > > > to have advantages.
> > > > > > > 
> > > > > > > > The implementation effort for supporting the new YL in clients and
> > > > > > > > servers is minimal, esp. when compared to the efforts involved in
> > > > > > > > supporting SM.
> > > > > > > > 
> > > > > > > > Adding an indirection is (for me) less important, but it has the
> > > > > > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > > > > > seen any technical problem with it.
> > > > > > > > 
> > > > > > > 
> > > > > > > (A) has implementation implications and those participating in the
> > > > > > > discussion at the time expressed as not being worth the cost.
> > > > > > > I don't believe b was seen as a significant issue either.
> > > > > > > 
> > > > > > > > Do you have any technical concerns with using an annotation as an
> > > > > > > > indirection?
> > > > > > > > 
> > > > > > > 
> > > > > > > The technicsl issue I have with the approaches the same one that was
> > > > > > > raised when debated previously, ie the implementation overhead of
> > > > > > > requiring inline schemas to be available at the top level.
> > > > > > 
> > > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > > > we need to use the new YL-bis, so that we can support the NMDA.
> > > > > 
> > > > > Given that NMDA support is not yet fully defined, we're still in the
> > > > > transition period where support for both NMDA and non-NMDA
> > > > > implementations need to be considered.  Rob presented some options
> > > > > earlier in the thread that I think captures this.
> > > > 
> > > > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > > > 
> > > > Also note that YLbis is just a different read-only monitoring
> > > > structure.  Given an implementation that supports the old YL, it is
> > > > trivial to add support for YLbis (especially compared to the more than
> > > > non-trivial amount of work required to support schema mount...).
> > > > 
> > > > 
> > > > /martin
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 


From nobody Thu Jan 18 11:16: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 289D612D7ED for ; Thu, 18 Jan 2018 11:16:22 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 czg3br6DzLNm for ; Thu, 18 Jan 2018 11:16:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3329712D7F1 for ; Thu, 18 Jan 2018 11:16:15 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 61D8E1AE0398; Thu, 18 Jan 2018 20:16:14 +0100 (CET)
Date: Thu, 18 Jan 2018 20:16:07 +0100 (CET)
Message-Id: <20180118.201607.1054737737975973419.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
Cc: bclaise@cisco.com, warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net, muly_i@rad.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20180118184745.7D72CB813D5@rfc-editor.org>
References: <20180118184745.7D72CB813D5@rfc-editor.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5237)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 19:16:22 -0000

Hi,

This errata should be applied.  It is an obvious typo.


/martin



RFC Errata System  wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5237
> 
> --------------------------------------
> Type: Editorial
> Reported by: Muly Ilan 
> 
> Section: 6.4.1.1
> 
> Original Text
> -------------
> The accessible tree for an action invocation of "reset" on
> /a/b[id="1"] with the "when" parameter set to "10" would be:
> 
> 
> 
> 1
> 
> 10
> 
> 
> 
> 2
> 
> 
> // possibly other top-level nodes here
> 
> Corrected Text
> --------------
> The accessible tree for an action invocation of "reset" on
> /a/b[id="1"] with the "delay" parameter set to "10" would be:
> 
> 
> 
> 1
> 
> 10
> 
> 
> 
> 2
> 
> 
> // possibly other top-level nodes here
> 
> Notes
> -----
> The example action "reset" has an input parameter named "delay" and not a parameter named "when".
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title               : The YANG 1.1 Data Modeling Language
> Publication Date    : August 2016
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 


From nobody Thu Jan 18 11:35: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 5570812D80E; Thu, 18 Jan 2018 11:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 o9TzE7CvzcaG; Thu, 18 Jan 2018 11:35:21 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E488B12D7EA; Thu, 18 Jan 2018 11:35:21 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id F2626B81891; Thu, 18 Jan 2018 11:35:14 -0800 (PST)
To: muly_i@rad.com, mbj@tail-f.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: bclaise@cisco.com, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180118193514.F2626B81891@rfc-editor.org>
Date: Thu, 18 Jan 2018 11:35:14 -0800 (PST)
Archived-At: 
Subject: [netmod] [Errata Verified] RFC7950 (5237)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 19:35:23 -0000

The following errata report has been verified for RFC7950,
"The YANG 1.1 Data Modeling Language". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5237

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Muly Ilan 
Date Reported: 2018-01-18
Verified by: Benoit Claise (IESG)

Section: 6.4.1.1

Original Text
-------------
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "when" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Corrected Text
--------------
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "delay" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Notes
-----
The example action "reset" has an input parameter named "delay" and not a parameter named "when".

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Jan 18 11: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 3CBF1129C6C for ; Thu, 18 Jan 2018 11:36:01 -0800 (PST)
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_RP_MATCHES_RCVD=-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 RpUCJKrRokKF for ; Thu, 18 Jan 2018 11:35:59 -0800 (PST)
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 30994127011 for ; Thu, 18 Jan 2018 11:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2240; q=dns/txt; s=iport; t=1516304159; x=1517513759; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jO5ZKkqkC0NOtdwBbHOdOv4xLT+RNarGmcI4EwiN/Q8=; b=JNZU655RdPZOskyXqHurASoP+VND8+7tiuxsz/7t6RHfYdnYTvzkGixy lTggZNrmD3SvowTngJXvVmin6yKyYLLxQ3iFTa8+LioNdTvba0qKEmeKC JtbeiFpj01zaQ3nbfz/odaIBcrmEh2GG2gkmlrinSoE3B3RDMvPLfFYTj 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQD59WBa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeDXYsYj2yXRYICCiOFGAKFIRQBAQEBAQEBAQFrKIUkAQU?= =?us-ascii?q?jFUEQCw4KAgImAgJXBgEMBgIBAYovEKl1gieJTAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHoEPhxmBaCmDBYFJgWYEgViDLoJlBYpYGYkxj02VVoIZhh6Db4dvjy2EW4M?= =?us-ascii?q?ygTw2IoFQMhoIGxUZgk4JgleBeEA3jHoBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,378,1511827200";  d="scan'208";a="1484425"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 19:35:57 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0IJZuGQ032742; Thu, 18 Jan 2018 19:35:57 GMT
To: Martin Bjorklund , rfc-editor@rfc-editor.org
Cc: warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net, muly_i@rad.com, netmod@ietf.org
References: <20180118184745.7D72CB813D5@rfc-editor.org> <20180118.201607.1054737737975973419.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: <998f133c-1e89-f60a-681c-e2b7d87a8d5c@cisco.com>
Date: Thu, 18 Jan 2018 20:35:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180118.201607.1054737737975973419.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5237)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 19:36:01 -0000

Thanks.
It's now verified.

Regards, Benoit.
> Hi,
>
> This errata should be applied.  It is an obvious typo.
>
>
> /martin
>
>
>
> RFC Errata System  wrote:
>> The following errata report has been submitted for RFC7950,
>> "The YANG 1.1 Data Modeling Language".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5237
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Muly Ilan 
>>
>> Section: 6.4.1.1
>>
>> Original Text
>> -------------
>> The accessible tree for an action invocation of "reset" on
>> /a/b[id="1"] with the "when" parameter set to "10" would be:
>>
>> 
>> 
>> 1
>> 
>> 10
>> 
>> 
>> 
>> 2
>> 
>> 
>> // possibly other top-level nodes here
>>
>> Corrected Text
>> --------------
>> The accessible tree for an action invocation of "reset" on
>> /a/b[id="1"] with the "delay" parameter set to "10" would be:
>>
>> 
>> 
>> 1
>> 
>> 10
>> 
>> 
>> 
>> 2
>> 
>> 
>> // possibly other top-level nodes here
>>
>> Notes
>> -----
>> The example action "reset" has an input parameter named "delay" and not a parameter named "when".
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>> --------------------------------------
>> Title               : The YANG 1.1 Data Modeling Language
>> Publication Date    : August 2016
>> Author(s)           : M. Bjorklund, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Network Modeling
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>>
> .
>


From nobody Thu Jan 18 13:25: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 61349126FDC for ; Thu, 18 Jan 2018 13:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 r2W6PqDZSmWs for ; Thu, 18 Jan 2018 13:25:17 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 01CA31270AC for ; Thu, 18 Jan 2018 13:25:16 -0800 (PST)
Received: from MBP.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0ILPFOo082652 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 18 Jan 2018 21:25:15 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be MBP.local
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
References: <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local> <1516302637.22408.23.camel@nic.cz> <20180118.201535.2290905942673102021.mbj@tail-f.com>
From: joel jaeggli 
Message-ID: 
Date: Thu, 18 Jan 2018 13:25:10 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180118.201535.2290905942673102021.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 21:25:19 -0000

On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
>> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
>>> Ignoring process issues (not sure there are any), does it make sense
>>> to publish a YANG module on the standards-track that is replaced by
>>> something different 3-6 months later?
>> IMO such a document churn would be a serious mistake. In the documents=
 that are
>> currently on the table (at least NMDA, YLbis, SM) we are dealing with =
quite a
>> few tricky and interrelated things, so it's important to come up with =
a coherent
>> view into which all the components nicely fit. And I believe we are no=
w quite
>> close.
>>
>> Publishing an interim solution that is a priori known to be technicall=
y inferior
>> would just confuse people. The fact that it can be hacked to support t=
wo or
>> three particular data models (albeit important) doesn't warrant to do =
so.
> I strongly agree with this!
Do we believe that documents using normative referencing to this draft
e.g. in routing would require changes in order to accommodate an updated
draft?

If yes then we're doing ourselves a clear dis-service by essentially
clearing the boards of the existing draft.=C2=A0 If that is the case we
should consider publishing this one possibly with an appropriate
applicability statement; the work on the new one can proceed so that at
least they have a stable reference. This assumes not fundamental flaws
that make the current one unusable.


> /martin
>
>>> Note that the NMDA contributors, after getting the overall design
>>> done, move sequentially through the details of the documents; we firs=
t
>>> focused on the NMDA document, which is in the RFC editor queue now. W=
e
>>> then focussed on the protocol extensions, which are now in WG last
>>> call. Currently we are focusing on getting the new yang library
>>> finalized. If no major isses pop up, the NMDA work may be complete by=

>>> the London IETF. Hence the 3 months lower bound mentioned above.
>> I agree, and will try to help.
>>
>> Thanks, Lada
>>
>>> /js
>>>
>>> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
>>>> Martin,
>>>>
>>>> I do agree with that at some point we will need to revisit scheme mo=
unt in
>>>> the context of YL-bis, as there are different possible solutions for=

>>>> handling different datastores mounting  different schema. I think Ro=
b laid
>>>> out the options pretty well here, ie doing it now or publishing as i=
s and
>>>> immediately working on the document that covers both.
>>>>
>>>> As I mentioned before I think this is as much a process issue as any=
thing
>>>> else - and have a planned call to discuss possible directions with c=
hairs. I
>>>> hope we can have some propose next steps on this to the working grou=
p in
>>>> short order.
>>>>
>>>> Lou
>>>>
>>>>
>>>> On January 18, 2018 2:57:23 AM Martin Bjorklund  wro=
te:
>>>>
>>>>> Lou Berger  wrote:
>>>>>>
>>>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>>>>>> ...
>>>>>>>>> My main concern is actually the YL version.  I strongly think S=
M
>>>>>>>>> need
>>>>>>>>> to use YL-bis rather that the old YL, so that it can support NM=
DA.
>>>>>>>>>
>>>>>>>> Right now to SM is independent of Yang Library version and can r=
un
>>>>>>>> with either.
>>>>>>> No this is not correct.  SM uses a grouping from the old YANG
>>>>>>> library (for the "use-schema" case),
>>>>>> I thought YLbis was an updat e to UL (i.e., no name change) as suc=
h SM
>>>>>> can include either.
>>>>> The old "modules-state" structure is deprecated, and a new structur=
e
>>>>> that allows multiple datastores is defined.  Note that YLbis can be=

>>>>> used by both NMDA-capabale and non-NMDA-capabale servers.
>>>>>
>>>>>>>   and talks about mounting
>>>>>>> "modules-state" ("inline" case).
>>>>>> In informative descriptions only.  Certainly these can be changed =
to
>>>>>> allow for YL-bis if need be.
>>>>>>
>>>>>>>> I certainly would expect use of Yang Library bis and nmda
>>>>>>>> to have advantages.
>>>>>>>>
>>>>>>>>> The implementation effort for supporting the new YL in clients =
and
>>>>>>>>> servers is minimal, esp. when compared to the efforts involved =
in
>>>>>>>>> supporting SM.
>>>>>>>>>
>>>>>>>>> Adding an indirection is (for me) less important, but it has th=
e
>>>>>>>>> benefit of solving the two issues (a) and (b) above, and I have=
n't
>>>>>>>>> seen any technical problem with it.
>>>>>>>>>
>>>>>>>> (A) has implementation implications and those participating in t=
he
>>>>>>>> discussion at the time expressed as not being worth the cost.
>>>>>>>> I don't believe b was seen as a significant issue either.
>>>>>>>>
>>>>>>>>> Do you have any technical concerns with using an annotation as =
an
>>>>>>>>> indirection?
>>>>>>>>>
>>>>>>>> The technicsl issue I have with the approaches the same one that=
 was
>>>>>>>> raised when debated previously, ie the implementation overhead o=
f
>>>>>>>> requiring inline schemas to be available at the top level.
>>>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I th=
ink
>>>>>>> we need to use the new YL-bis, so that we can support the NMDA.
>>>>>> Given that NMDA support is not yet fully defined, we're still in t=
he
>>>>>> transition period where support for both NMDA and non-NMDA
>>>>>> implementations need to be considered.  Rob presented some options=

>>>>>> earlier in the thread that I think captures this.
>>>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
>>>>>
>>>>> Also note that YLbis is just a different read-only monitoring
>>>>> structure.  Given an implementation that supports the old YL, it is=

>>>>> trivial to add support for YLbis (especially compared to the more t=
han
>>>>> non-trivial amount of work required to support schema mount...).
>>>>>
>>>>>
>>>>> /martin
>>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> --=20
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> 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 Thu Jan 18 14:06:36 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 877B2126C83; Thu, 18 Jan 2018 14:06:31 -0800 (PST)
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.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151631319151.27035.12767137293938494304@ietfa.amsl.com>
Date: Thu, 18 Jan 2018 14:06:31 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-16.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 22:06:31 -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           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-16.txt
	Pages           : 70
	Date            : 2018-01-18

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-16
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-16


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 Thu Jan 18 14:11: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 A771C126BF0 for ; Thu, 18 Jan 2018 14:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 JmOkJrpvx20j for ; Thu, 18 Jan 2018 14:11:21 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 BDA321241F5 for ; Thu, 18 Jan 2018 14:11:20 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id g72so23145129lfg.5 for ; Thu, 18 Jan 2018 14:11:20 -0800 (PST)
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=7tb7hjqU2C1CCP0xm7m1zcGK3VYlL5RlEKPdaq/Hqz8=; b=Qg+fmkdVrJp93z9y3ak+DQrmFstXOWsvdaVLpaIh3nrOwjq7bwi5oY48mAvyQld+rb Baqt2V97rsBNaG7ELF7cyp+S2b9TbL2wTgGwdf+QegMroBUX0eZRD+mTzFoWm+n4/SyV Kr69iPRLvbQQ6IpZDPEb0ZUP7rV5dSGkUvtJKb7fq/iSY8FeslXVrMrZ2Yr3D3agMQhP rxqZUq62ZJ8BUVVRX/oES9dSGhAs8ubFKj4VP26lQvyIpfpgw/MMtWChwucJSJxkc1Tf CsuDtav6t/EQOFuqwSG2C7K14u3VdCpKx+18ZuBsL+X/ZAc9lVk82YpLIaMYFsAJrYM3 HkGw==
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=7tb7hjqU2C1CCP0xm7m1zcGK3VYlL5RlEKPdaq/Hqz8=; b=MMkyodTmubQwR/83U0f2Ot3holM/Jk5GijoOTH3Q2TIqEboJgCaOXFJXEisycdgOLs 7FVGD3djzd1NRQauMH2FTInbqjdZlPwSPUFgEmglDpHqvR/kxE7BXUW13GJrjllsVYF7 JYc8v4PVF7+iq+b15tPya8pGwGcW5xIiwlN6E5BDheidYFeUQnQAc6yR3Nuul9loups+ wjU90jlx9jmnOb2dEHjpHBvN9c5sbEeFflZb8LOjcNaj5Tmp6MMDbqBwepb0UJOAA7Qm PkMkeTOEv1LbDOpi03U1zEEAxqT7CeuA38E/Ct0qTTpDYSW5MhUNUBr5ozUBne55l9i/ r/XA==
X-Gm-Message-State: AKwxytenu5SqujxiILnrlVsY/a5Ih7ngX4q/FlVj+rQBgUMCaIttlPLQ Wy8KqetwH0aVQY8K29b6aOEwO5v0QoAmGlXl1v8vNw==
X-Google-Smtp-Source: ACJfBotm+CLu6wKIho3FFfIvKCPJWBVrMYr8m9ilwa6VvCSkPMGF6EYFr09K3HkTqe0bh4pY/y5SmUqRvbKDjdKNN5E=
X-Received: by 10.25.156.140 with SMTP id f134mr25874632lfe.120.1516313478876;  Thu, 18 Jan 2018 14:11:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.196.65 with HTTP; Thu, 18 Jan 2018 14:11:17 -0800 (PST)
In-Reply-To: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net>
References: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net>
From: Andy Bierman 
Date: Thu, 18 Jan 2018 14:11:17 -0800
Message-ID: 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11403b3c46e6c00563143ed7"
Archived-At: 
Subject: Re: [netmod] rfc6087bis shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Jan 2018 22:11:23 -0000

--001a11403b3c46e6c00563143ed7
Content-Type: text/plain; charset="UTF-8"

Hi,

I posted draft-16 which has all changes below except the unused reference
for RFC 5378.
The idnits tool is wrong. It ignores usage in an appendix.

Andy


On Mon, Jan 15, 2018 at 2:15 PM, Kent Watsen  wrote:

> Hi Andy,
>
>
> 1) before I forget, could you please confirm one more time (the last time
> being in 2016, sheesh!) that you are unaware of any IPR that needs to be
> filed for this draft, according to BCPs 78 and 79?
>
>
>
> 2) Idnits found three warnings, only the first might require thought for
> how best to fix it:
>
>   == Unused Reference: 'RFC5378' is defined on line 2502, but no explicit
>      reference was found in the text
>
>   == Outdated reference: A later version (-10) exists of
>      draft-ietf-netmod-revised-datastores-07
>
>   == Outdated reference: A later version (-04) exists of
>      draft-ietf-netmod-yang-tree-diagrams-02
>
>
>
> 3) in the Introduction, would this be better?
>  OLD
>    The standardization of network configuration interfaces for use with
>    ***the Network Configuration Protocol [RFC6241] and RESTCONF
> [RFC8040]***
>    requires a modular set of data models, which can be reused and
>    extended over time.
>  NEW
>    The standardization of network configuration interfaces for use with
>    network configuration management protocols, such as NETCONF [RFC6241]
>    and RESTCONF [RFC8040], requires a modular set of data models, which
>    can be reused and extended over time.
>
>
> 4) In the next paragraph, should "server" be qualified?
>    A *NETCONF or RESTCONF* server that supports
>    a particular YANG module will support client NETCONF and/or RESTCONF
>    operation requests, as indicated by the specific content defined in
>    the YANG module.
>
>
> 5) The next paragraph is no longer accurate and, given its value is
> unless, maybe it should be removed altogether?
>  OLD
>    This document is similar to the Structure of Management Information
>    version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
>    and structure.  However, since that document was written a decade
>    after SMIv2 modules had been in use, it was published as a 'Best
>    Current Practice' (BCP).  This document is not a BCP, but rather an
>    informational reference, intended to promote consistency in documents
>    containing YANG modules.
>
>
> 6) In the next paragraph, something seems off with the "may require"
> language.  Should it be just "requires" or perhaps "entails"?   Also, is it
> really to "maximize interoperability of NETCONF and RESTCONF
> implementations", or more just to make YANG modules more useful?
>  OLD
>    Many YANG constructs are defined as optional to use, such as the
>    description statement.  However, in order to ***maximize
>    interoperability of NETCONF and RESTCONF implementations utilizing
>    YANG data models***, it is desirable to define a set of usage guidelines
>    that ***may require*** a higher level of compliance than the minimum
> level
>    defined in the YANG specification.
>
>
> 7) In the Terminology Section, please add a normative reference to RFC
> 8174, Section 2.  The expected result follows:
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>       "MAY", and "OPTIONAL" in this document are to be interpreted as
>       described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>       appear in all capitals, as shown here.
>
>
> 8) Should the reference to RFC 6991 be informative instead?
>
>
> 9) The reference to the tree-diagrams draft being informative caught my
> eye. Looking into it revealed more:
> 9a) I think that Section 2.5.1 should be deleted, as the draft itself does
> not define any tree diagrams outside of sections 3.4, which already has a
> reference to that draft (as it should).
> 9b) should the guidelines make the Section 3.3 recommendation anymore?  -
> I thought that one of the main benefits of having the tree-diagrams draft
> was so that other drafts could easily inline-reference it, so as to avoid
> needing to say anything in their Terminology sections.
> 9c) I think Section 3.4 should 1) say that drafts should prefix each
> tree-diagram with a *normative* reference to the tree-diagrams draft and 2)
> update the example illustrating how it might be done.
> 9d) Finally, back to the tree-diagrams draft being informative, yes, I
> guess it is informative after all.  c'est la vie  ;)
>
>
> 10) Should Section 8 (Changes to RFC 6087) be moved to the Introduction?
> Note that the shepherd checklist says "If publication of this document
> changes the status of any existing RFCs, are those RFCs listed on the title
> page header, and are the changes listed in the abstract and discussed
> (explained, not just mentioned) in the introduction?"
>
>
> 11) I think that Section 6 (Security Considerations) should be largely
> moved into Section 3.7.  For this document, Section 6 should probably just
> say something like "This document only defines guidelines for YANG module
> designers and therefore does not itself have any Security considerations
> that need to be listed here."  What do you think?
>
>
> Thanks,
> Kent  // shepherd
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I posted draft-16 which has all cha=
nges below except the unused reference for RFC 5378.
The idnits t=
ool is wrong. It ignores usage in an appendix.

And=
y


O=
n Mon, Jan 15, 2018 at 2:15 PM, Kent Watsen <kwatsen@juniper.net&g=
t; wrote:
Hi Andy,





1) before I forget, could you please confirm one more time (the last time b=
eing in 2016, sheesh!) that you are unaware of any IPR that needs to be fil=
ed for this draft, according to BCPs 78 and 79?







2) Idnits found three warnings, only the first might require thought for ho=
w best to fix it:



=C2=A0 =3D=3D Unused Reference: 'RFC5378' is defined on line 2502, =
but no explicit

=C2=A0 =C2=A0 =C2=A0reference was found in the text



=C2=A0 =3D=3D Outdated reference: A later version (-10) exists of

=C2=A0 =C2=A0 =C2=A0draft-ietf-netmod-revised-datastores-07



=C2=A0 =3D=3D Outdated reference: A later version (-04) exists of

=C2=A0 =C2=A0 =C2=A0draft-ietf-netmod-yang-tree-diagrams-02







3) in the Introduction, would this be better?

=C2=A0OLD

=C2=A0 =C2=A0The standardization of network configuration interfaces for us=
e with

=C2=A0 =C2=A0***the Network Configuration Protocol [RFC6241] and RESTCONF [=
RFC8040]***

=C2=A0 =C2=A0requires a modular set of data models, which can be reused and=


=C2=A0 =C2=A0extended over time.

=C2=A0NEW

=C2=A0 =C2=A0The standardization of network configuration interfaces for us=
e with

=C2=A0 =C2=A0network configuration management protocols, such as NETCONF [R=
FC6241]

=C2=A0 =C2=A0and RESTCONF [RFC8040], requires a modular set of data models,=
 which

=C2=A0 =C2=A0can be reused and extended over time.





4) In the next paragraph, should "server" be qualified?

=C2=A0 =C2=A0A *NETCONF or RESTCONF* server that supports

=C2=A0 =C2=A0a particular YANG module will support client NETCONF and/or RE=
STCONF

=C2=A0 =C2=A0operation requests, as indicated by the specific content defin=
ed in

=C2=A0 =C2=A0the YANG module.





5) The next paragraph is no longer accurate and, given its value is unless,=
 maybe it should be removed altogether?

=C2=A0OLD

=C2=A0 =C2=A0This document is similar to the Structure of Management Inform=
ation

=C2=A0 =C2=A0version 2 (SMIv2) usage guidelines specification [RFC4181] in =
intent

=C2=A0 =C2=A0and structure.=C2=A0 However, since that document was written =
a decade

=C2=A0 =C2=A0after SMIv2 modules had been in use, it was published as a =
9;Best

=C2=A0 =C2=A0Current Practice' (BCP).=C2=A0 This document is not a BCP,=
 but rather an

=C2=A0 =C2=A0informational reference, intended to promote consistency in do=
cuments

=C2=A0 =C2=A0containing YANG modules.





6) In the next paragraph, something seems off with the "may require&qu=
ot; language.=C2=A0 Should it be just "requires" or perhaps "=
;entails"?=C2=A0 =C2=A0Also, is it really to "maximize interopera=
bility of NETCONF and RESTCONF implementations", or more just to make =
YANG modules more useful?

=C2=A0OLD

=C2=A0 =C2=A0Many YANG constructs are defined as optional to use, such as t=
he

=C2=A0 =C2=A0description statement.=C2=A0 However, in order to ***maximize<=
br>
=C2=A0 =C2=A0interoperability of NETCONF and RESTCONF implementations utili=
zing

=C2=A0 =C2=A0YANG data models***, it is desirable to define a set of usage =
guidelines

=C2=A0 =C2=A0that ***may require*** a higher level of compliance than the m=
inimum level

=C2=A0 =C2=A0defined in the YANG specification.





7) In the Terminology Section, please add a normative reference to RFC 8174=
, Section 2.=C2=A0 The expected result follows:

=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL

=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT",=
 "RECOMMENDED", "NOT RECOMMENDED",

=C2=A0 =C2=A0 =C2=A0 "MAY", and "OPTIONAL" in this docu=
ment are to be interpreted as

=C2=A0 =C2=A0 =C2=A0 described in BCP 14 [RFC2119] [RFC8174] when, and only=
 when, they

=C2=A0 =C2=A0 =C2=A0 appear in all capitals, as shown here.





8) Should the reference to RFC 6991 be informative instead?





9) The reference to the tree-diagrams draft being informative caught my eye=
. Looking into it revealed more:

9a) I think that Section 2.5.1 should be deleted, as the draft itself does =
not define any tree diagrams outside of sections 3.4, which already has a r=
eference to that draft (as it should).

9b) should the guidelines make the Section 3.3 recommendation anymore?=C2=
=A0 - I thought that one of the main benefits of having the tree-diagrams d=
raft was so that other drafts could easily inline-reference it, so as to av=
oid needing to say anything in their Terminology sections.

9c) I think Section 3.4 should 1) say that drafts should prefix each tree-d=
iagram with a *normative* reference to the tree-diagrams draft and 2) updat=
e the example illustrating how it might be done.

9d) Finally, back to the tree-diagrams draft being informative, yes, I gues=
s it is informative after all.=C2=A0 c'est la vie=C2=A0 ;)





10) Should Section 8 (Changes to RFC 6087) be moved to the Introduction?=C2=
=A0 Note that the shepherd checklist says "If publication of this docu=
ment changes the status of any existing RFCs, are those RFCs listed on the =
title page header, and are the changes listed in the abstract and discussed=
 (explained, not just mentioned) in the introduction?"





11) I think that Section 6 (Security Considerations) should be largely move=
d into Section 3.7.=C2=A0 For this document, Section 6 should probably just=
 say something like "This document only defines guidelines for YANG mo=
dule designers and therefore does not itself have any Security consideratio=
ns that need to be listed here."=C2=A0 What do you think?





Thanks,

Kent=C2=A0 // shepherd







_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a11403b3c46e6c00563143ed7--


From nobody Thu Jan 18 17:03: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 B26B812D77E; Thu, 18 Jan 2018 17:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 u_GV7ltqfbYp; Thu, 18 Jan 2018 17:03:13 -0800 (PST)
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 A6F3412D775; Thu, 18 Jan 2018 17:03:13 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D8BF09522D733; Fri, 19 Jan 2018 01:03:09 +0000 (GMT)
Received: from DGGEMA401-HUB.china.huawei.com (10.3.20.42) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 19 Jan 2018 01:03:11 +0000
Received: from DGGEMA503-MBX.china.huawei.com ([169.254.1.5]) by DGGEMA401-HUB.china.huawei.com ([10.3.20.42]) with mapi id 14.03.0361.001; Fri, 19 Jan 2018 09:02:56 +0800
From: "Hejia (Jia)" 
To: "Acee Lindem (acee)" , "rtg-ads@ietf.org" 
CC: "rtg-dir@ietf.org" , "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
Thread-Index: AdOQwL3kLsyOwxG8RviHeGXe7RKfjA==
Date: Fri, 19 Jan 2018 01:02:55 +0000
Message-ID: <735916399E11684EAF4EB4FB376B719553034BDD@DGGEMA503-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.57.113.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Rtgdir telechat review of draft-ietf-netmod-rfc8022bis-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 01:03:16 -0000

QWNlZSwNCg0KVGhhbmtzIGZvciBjb25zaWRlcmluZyBteSBjb21tZW50LiBJJ20gT0sgd2l0aCB0
aGUgbmV3IHZlcnNpb24uDQoNCg0KQi5SLg0KSmlhDQoNCg0KDQotLS0tLemCruS7tuWOn+S7ti0t
LS0tDQrlj5Hku7bkuro6IEFjZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29t
XSANCuWPkemAgeaXtumXtDogMjAxOOW5tDHmnIgxOOaXpSAwOjAzDQrmlLbku7bkuro6IEhlamlh
IChKaWEpIDxoZWppYUBodWF3ZWkuY29tPjsgcnRnLWFkc0BpZXRmLm9yZw0K5oqE6YCBOiBydGct
ZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLmFsbEBpZXRmLm9yZzsg
bmV0bW9kQGlldGYub3JnDQrkuLvpopg6IFJlOiBSdGdkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRy
YWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDgudHh0DQoNCkhpIEppYSwgDQoNClRoYW5rcyBm
b3IgeW91ciByZXZpZXcuIFRoZSBBcHBlbmRpeCBEIG5pdCBoYXMgYmVlbiBmaXhlZCBpbiB0aGUg
LTA5IHZlcnNpb24gICh0aGUgb25seSBjaGFuZ2UpLg0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDEv
MTcvMTgsIDE6NTAgQU0sICJIZWppYSAoSmlhKSIgPGhlamlhQGh1YXdlaS5jb20+IHdyb3RlOg0K
DQo+SGVsbG8sDQo+DQo+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0
b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQo+VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg
c2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCANCj5kcmFmdHMg
YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQg
DQo+c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmll
dyBpcyB0byBwcm92aWRlIA0KPmFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9y
ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyANCj5EaXJlY3RvcmF0ZSwgcGxlYXNlIHNl
ZSANCj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGly
DQo+DQo+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBv
ZiB0aGUgUm91dGluZyBBRHMsIA0KPml0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNv
bnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgDQo+SUVURiBMYXN0IENhbGwgY29tbWVu
dHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gDQo+dGhyb3Vn
aCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4NCj5Eb2N1bWVudCBkcmFm
dC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA4LnR4dA0KPlJldmlld2VyOiBKaWEgSGUNCj5SZXZp
ZXcgRGF0ZTogMTcgSmFudWFyeSAyMDE4DQo+SUVURiBMQyBFbmQgRGF0ZTogMTUgSmFudWFyeSAy
MDE4DQo+VGVsZWNoYXQgZGF0ZTogMjUgSmFudWFyeSAyMDE4DQo+SW50ZW5kZWQgU3RhdHVzOiBT
dGFuZGFyZHMgVHJhY2sNCj4NCj5TdW1tYXJ5DQo+VGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBO
TURBLWNvbXBsaWFudCB2ZXJzaW9uIG9mIFlBTkcgZGF0YSBtb2RlbCBmb3IgDQo+cm91dGluZyBt
YW5hZ2VtZW50LiBJdCBpcyB2ZXJ5IHdlbGwgd3JpdHRlbiBhbmQgcmVhZHkgZm9yIHB1YmxpY2F0
aW9uLg0KPkJ1dCBJIGhhcHBlbmVkIHRvIHNlZSBhIHNtYWxsIG5pdCBpbiBBcHBlbmRpeCBEIGp1
c3QgYmVmb3JlIEkgZmluaXNoZWQgDQo+bXkgcmV2aWV3LCBzZWUgYmVsb3cuDQo+DQo+Q29tbWVu
dHMNCj5Ob25lLg0KPg0KPk1ham9yIElzc3VlczoNCj5ObyBtYWpvciBpc3N1ZXMgZm91bmQuDQo+
DQo+TWlub3IgSXNzdWVzOg0KPk5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCj4NCj5OaXRzOg0KPklu
IEFwcGVuZGl4IEQsIHRoZSBuYW1lc3BhY2Ugb2YgImlldGYtaXB2Ni11bmljYXN0LXJvdXRpbmci
IGlzIHdyaXR0ZW4gDQo+YXMgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWlwdjYt
dW5pY2FzdC1yb3V0aW5nLTMiLiAiLTMiIGlzIA0KPm5vdCBtZWFuaW5nZnVsIGFuZCBuZWVkcyB0
byBiZSBkZWxldGVkLg0KPg0KPg0KPg0KPlJlZ2FyZHMsDQo+SmlhDQoNCg==


From nobody Thu Jan 18 22:50: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 E9F92124BE8 for ; Thu, 18 Jan 2018 22:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 IktWLT8eOQUg for ; Thu, 18 Jan 2018 22:50:14 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9EE7E1201F2 for ; Thu, 18 Jan 2018 22:50:12 -0800 (PST)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id BCF8264EC9; Fri, 19 Jan 2018 07:50:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516344610; bh=SDt94TSMI/MJsspmiNHRpDKlgx10gQ3lgupAmLlyavI=; h=From:To:Date; b=BP/49uiN+n1UjdvYNinSne0RE/3c+NCGjjW7rq7/fn4u3Z7+7IsQtoDs6dXkBIrQ9 ucHzI2FacU4F2eTJ1P70B8r/5l8s8MqmbKwKzzxVyIo4swiCF+ng3MM+yyOEFBx2mH IBcxsx6FppMcwU8TvFFTTVo5lvFRfwgz/DuzMp2g=
Message-ID: <1516344610.29743.4.camel@nic.cz>
From: Ladislav Lhotka 
To: joel jaeggli , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Fri, 19 Jan 2018 07:50:10 +0100
In-Reply-To: 
References: <16109590f18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180118133920.aerpan7jdbtre3f3@elstar.local> <1516302637.22408.23.camel@nic.cz> <20180118.201535.2290905942673102021.mbj@tail-f.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 06:50:21 -0000

On Thu, 2018-01-18 at 13:25 -0800, joel jaeggli wrote:
> 
> On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> > > > Ignoring process issues (not sure there are any), does it make sense
> > > > to publish a YANG module on the standards-track that is replaced by
> > > > something different 3-6 months later?
> > > 
> > > IMO such a document churn would be a serious mistake. In the documents
> > > that are
> > > currently on the table (at least NMDA, YLbis, SM) we are dealing with
> > > quite a
> > > few tricky and interrelated things, so it's important to come up with a
> > > coherent
> > > view into which all the components nicely fit. And I believe we are now
> > > quite
> > > close.
> > > 
> > > Publishing an interim solution that is a priori known to be technically
> > > inferior
> > > would just confuse people. The fact that it can be hacked to support two
> > > or
> > > three particular data models (albeit important) doesn't warrant to do so.
> > 
> > I strongly agree with this!
> 
> Do we believe that documents using normative referencing to this draft
> e.g. in routing would require changes in order to accommodate an updated
> draft?

As I wrote, the LNE and NI documents will have to update the examples in their
(non-normative) appendices. Drafts that just define specific YANG modules
shouldn't be affected even if they use schema mount.

It is IMO not a big deal.

Lada

> 
> If yes then we're doing ourselves a clear dis-service by essentially
> clearing the boards of the existing draft.  If that is the case we
> should consider publishing this one possibly with an appropriate
> applicability statement; the work on the new one can proceed so that at
> least they have a stable reference. This assumes not fundamental flaws
> that make the current one unusable.
> 
> 
> > /martin
> > 
> > > > Note that the NMDA contributors, after getting the overall design
> > > > done, move sequentially through the details of the documents; we first
> > > > focused on the NMDA document, which is in the RFC editor queue now. We
> > > > then focussed on the protocol extensions, which are now in WG last
> > > > call. Currently we are focusing on getting the new yang library
> > > > finalized. If no major isses pop up, the NMDA work may be complete by
> > > > the London IETF. Hence the 3 months lower bound mentioned above.
> > > 
> > > I agree, and will try to help.
> > > 
> > > Thanks, Lada
> > > 
> > > > /js
> > > > 
> > > > On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> > > > > Martin,
> > > > > 
> > > > > I do agree with that at some point we will need to revisit scheme
> > > > > mount in
> > > > > the context of YL-bis, as there are different possible solutions for
> > > > > handling different datastores mounting  different schema. I think Rob
> > > > > laid
> > > > > out the options pretty well here, ie doing it now or publishing as is
> > > > > and
> > > > > immediately working on the document that covers both.
> > > > > 
> > > > > As I mentioned before I think this is as much a process issue as
> > > > > anything
> > > > > else - and have a planned call to discuss possible directions with
> > > > > chairs. I
> > > > > hope we can have some propose next steps on this to the working group
> > > > > in
> > > > > short order.
> > > > > 
> > > > > Lou
> > > > > 
> > > > > 
> > > > > On January 18, 2018 2:57:23 AM Martin Bjorklund 
> > > > > wrote:
> > > > > 
> > > > > > Lou Berger  wrote:
> > > > > > > 
> > > > > > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > > > > > ...
> > > > > > > > > > My main concern is actually the YL version.  I strongly
> > > > > > > > > > think SM
> > > > > > > > > > need
> > > > > > > > > > to use YL-bis rather that the old YL, so that it can support
> > > > > > > > > > NMDA.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Right now to SM is independent of Yang Library version and can
> > > > > > > > > run
> > > > > > > > > with either.
> > > > > > > > 
> > > > > > > > No this is not correct.  SM uses a grouping from the old YANG
> > > > > > > > library (for the "use-schema" case),
> > > > > > > 
> > > > > > > I thought YLbis was an updat e to UL (i.e., no name change) as
> > > > > > > such SM
> > > > > > > can include either.
> > > > > > 
> > > > > > The old "modules-state" structure is deprecated, and a new structure
> > > > > > that allows multiple datastores is defined.  Note that YLbis can be
> > > > > > used by both NMDA-capabale and non-NMDA-capabale servers.
> > > > > > 
> > > > > > > >   and talks about mounting
> > > > > > > > "modules-state" ("inline" case).
> > > > > > > 
> > > > > > > In informative descriptions only.  Certainly these can be changed
> > > > > > > to
> > > > > > > allow for YL-bis if need be.
> > > > > > > 
> > > > > > > > > I certainly would expect use of Yang Library bis and nmda
> > > > > > > > > to have advantages.
> > > > > > > > > 
> > > > > > > > > > The implementation effort for supporting the new YL in
> > > > > > > > > > clients and
> > > > > > > > > > servers is minimal, esp. when compared to the efforts
> > > > > > > > > > involved in
> > > > > > > > > > supporting SM.
> > > > > > > > > > 
> > > > > > > > > > Adding an indirection is (for me) less important, but it has
> > > > > > > > > > the
> > > > > > > > > > benefit of solving the two issues (a) and (b) above, and I
> > > > > > > > > > haven't
> > > > > > > > > > seen any technical problem with it.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > (A) has implementation implications and those participating in
> > > > > > > > > the
> > > > > > > > > discussion at the time expressed as not being worth the cost.
> > > > > > > > > I don't believe b was seen as a significant issue either.
> > > > > > > > > 
> > > > > > > > > > Do you have any technical concerns with using an annotation
> > > > > > > > > > as an
> > > > > > > > > > indirection?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The technicsl issue I have with the approaches the same one
> > > > > > > > > that was
> > > > > > > > > raised when debated previously, ie the implementation overhead
> > > > > > > > > of
> > > > > > > > > requiring inline schemas to be available at the top level.
> > > > > > > > 
> > > > > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I
> > > > > > > > think
> > > > > > > > we need to use the new YL-bis, so that we can support the NMDA.
> > > > > > > 
> > > > > > > Given that NMDA support is not yet fully defined, we're still in
> > > > > > > the
> > > > > > > transition period where support for both NMDA and non-NMDA
> > > > > > > implementations need to be considered.  Rob presented some options
> > > > > > > earlier in the thread that I think captures this.
> > > > > > 
> > > > > > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > > > > > 
> > > > > > Also note that YLbis is just a different read-only monitoring
> > > > > > structure.  Given an implementation that supports the old YL, it is
> > > > > > trivial to add support for YLbis (especially compared to the more
> > > > > > than
> > > > > > non-trivial amount of work required to support schema mount...).
> > > > > > 
> > > > > > 
> > > > > > /martin
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > 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 Fri Jan 19 00:58:48 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 51890120454 for ; Fri, 19 Jan 2018 00:58:46 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 B0CrmMHymKLg for ; Fri, 19 Jan 2018 00:58:43 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE08D1201F2 for ; Fri, 19 Jan 2018 00:58:43 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 886EB1AE0290; Fri, 19 Jan 2018 09:58:41 +0100 (CET)
Date: Fri, 19 Jan 2018 09:58:41 +0100 (CET)
Message-Id: <20180119.095841.1647865928078984723.mbj@tail-f.com>
To: joelja@bogus.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <1516302637.22408.23.camel@nic.cz> <20180118.201535.2290905942673102021.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 08:58:46 -0000

Hi,

joel jaeggli  wrote:
> 
> 
> On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> >> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> >>> Ignoring process issues (not sure there are any), does it make sense
> >>> to publish a YANG module on the standards-track that is replaced by
> >>> something different 3-6 months later?
> >> IMO such a document churn would be a serious mistake. In the documents that are
> >> currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
> >> few tricky and interrelated things, so it's important to come up with a coherent
> >> view into which all the components nicely fit. And I believe we are now quite
> >> close.
> >>
> >> Publishing an interim solution that is a priori known to be technically inferior
> >> would just confuse people. The fact that it can be hacked to support two or
> >> three particular data models (albeit important) doesn't warrant to do so.
> > I strongly agree with this!
> Do we believe that documents using normative referencing to this draft
> e.g. in routing would require changes in order to accommodate an updated
> draft?
> 
> If yes then we're doing ourselves a clear dis-service by essentially
> clearing the boards of the existing draft.

As Lada wrote earlier, two of the three drafts need updated *examples*
in their appendicies.  They do not need any changes to their normative
sections.

> If that is the case we
> should consider publishing this one possibly with an appropriate
> applicability statement; the work on the new one can proceed so that at
> least they have a stable reference. This assumes not fundamental flaws
> that make the current one unusable.

Since some time back, we require all drafts to be NMDA compliant.  Why
should SM be different?  Note that this solution does not *require*
NMDA.

One reason for SM being late is that it has been difficult to find a
technical solution for which even the authors could agree.  The
current draft is a compromise.  By using YLbis we can solve some of
these issues, and since this is a central building block I think it
would be very unwise to publish it just to avoid updating two
examples.


/martin



> 
> 
> > /martin
> >
> >>> Note that the NMDA contributors, after getting the overall design
> >>> done, move sequentially through the details of the documents; we first
> >>> focused on the NMDA document, which is in the RFC editor queue now. We
> >>> then focussed on the protocol extensions, which are now in WG last
> >>> call. Currently we are focusing on getting the new yang library
> >>> finalized. If no major isses pop up, the NMDA work may be complete by
> >>> the London IETF. Hence the 3 months lower bound mentioned above.
> >> I agree, and will try to help.
> >>
> >> Thanks, Lada
> >>
> >>> /js
> >>>
> >>> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> >>>> Martin,
> >>>>
> >>>> I do agree with that at some point we will need to revisit scheme mount in
> >>>> the context of YL-bis, as there are different possible solutions for
> >>>> handling different datastores mounting  different schema. I think Rob laid
> >>>> out the options pretty well here, ie doing it now or publishing as is and
> >>>> immediately working on the document that covers both.
> >>>>
> >>>> As I mentioned before I think this is as much a process issue as anything
> >>>> else - and have a planned call to discuss possible directions with chairs. I
> >>>> hope we can have some propose next steps on this to the working group in
> >>>> short order.
> >>>>
> >>>> Lou
> >>>>
> >>>>
> >>>> On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
> >>>>
> >>>>> Lou Berger  wrote:
> >>>>>>
> >>>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> >>>>>> ...
> >>>>>>>>> My main concern is actually the YL version.  I strongly think SM
> >>>>>>>>> need
> >>>>>>>>> to use YL-bis rather that the old YL, so that it can support NMDA.
> >>>>>>>>>
> >>>>>>>> Right now to SM is independent of Yang Library version and can run
> >>>>>>>> with either.
> >>>>>>> No this is not correct.  SM uses a grouping from the old YANG
> >>>>>>> library (for the "use-schema" case),
> >>>>>> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> >>>>>> can include either.
> >>>>> The old "modules-state" structure is deprecated, and a new structure
> >>>>> that allows multiple datastores is defined.  Note that YLbis can be
> >>>>> used by both NMDA-capabale and non-NMDA-capabale servers.
> >>>>>
> >>>>>>>   and talks about mounting
> >>>>>>> "modules-state" ("inline" case).
> >>>>>> In informative descriptions only.  Certainly these can be changed to
> >>>>>> allow for YL-bis if need be.
> >>>>>>
> >>>>>>>> I certainly would expect use of Yang Library bis and nmda
> >>>>>>>> to have advantages.
> >>>>>>>>
> >>>>>>>>> The implementation effort for supporting the new YL in clients and
> >>>>>>>>> servers is minimal, esp. when compared to the efforts involved in
> >>>>>>>>> supporting SM.
> >>>>>>>>>
> >>>>>>>>> Adding an indirection is (for me) less important, but it has the
> >>>>>>>>> benefit of solving the two issues (a) and (b) above, and I haven't
> >>>>>>>>> seen any technical problem with it.
> >>>>>>>>>
> >>>>>>>> (A) has implementation implications and those participating in the
> >>>>>>>> discussion at the time expressed as not being worth the cost.
> >>>>>>>> I don't believe b was seen as a significant issue either.
> >>>>>>>>
> >>>>>>>>> Do you have any technical concerns with using an annotation as an
> >>>>>>>>> indirection?
> >>>>>>>>>
> >>>>>>>> The technicsl issue I have with the approaches the same one that was
> >>>>>>>> raised when debated previously, ie the implementation overhead of
> >>>>>>>> requiring inline schemas to be available at the top level.
> >>>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
> >>>>>>> we need to use the new YL-bis, so that we can support the NMDA.
> >>>>>> Given that NMDA support is not yet fully defined, we're still in the
> >>>>>> transition period where support for both NMDA and non-NMDA
> >>>>>> implementations need to be considered.  Rob presented some options
> >>>>>> earlier in the thread that I think captures this.
> >>>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
> >>>>>
> >>>>> Also note that YLbis is just a different read-only monitoring
> >>>>> structure.  Given an implementation that supports the old YL, it is
> >>>>> trivial to add support for YLbis (especially compared to the more than
> >>>>> non-trivial amount of work required to support schema mount...).
> >>>>>
> >>>>>
> >>>>> /martin
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >> -- 
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> 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 Fri Jan 19 07:33: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 70A3A127241 for ; Fri, 19 Jan 2018 07:33:01 -0800 (PST)
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_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 Uos-4-HcAmZt for ; Fri, 19 Jan 2018 07:32:58 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 B3E0B12700F for ; Fri, 19 Jan 2018 07:32:58 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 9981B1AC5C1 for ; Fri, 19 Jan 2018 08:13:31 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 0FDT1x00c2SSUrH01FDWzr; Fri, 19 Jan 2018 08:13:31 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=u07AKapRAAAA:8 a=xcTfSnc4AAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=GLTv1vwZtjG8OB2iqh4A:9 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
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:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vqHqj3XLuT0fakpDKtSskF+i14l95RE1S1hciAIC2Ds=; b=hJx6Y5ZeDIwg1NILYKXbRjLFrN /olaMoU2LeWBseiGHLhWPJAytZsgRevuUHwW6+BTUnF4sx0AY8ClmGkk84PKc02i2RK6iUjsg+Prr ikWSaQhEr7xcfcYAVXLRkewf3;
Received: from [172.56.3.195] (port=52893 helo=[IPV6:2607:fb90:1803:a580:0:19:a1a9:7c01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ecYMB-004DPw-7q; Fri, 19 Jan 2018 08:13:27 -0700
From: Lou Berger 
To: Martin Bjorklund , 
CC: 
Date: Fri, 19 Jan 2018 10:13:24 -0500
Message-ID: <1610efad0f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20180119.095841.1647865928078984723.mbj@tail-f.com>
References: <1516302637.22408.23.camel@nic.cz> <20180118.201535.2290905942673102021.mbj@tail-f.com>  <20180119.095841.1647865928078984723.mbj@tail-f.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
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: 172.56.3.195
X-Exim-ID: 1ecYMB-004DPw-7q
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:1803:a580:0:19:a1a9:7c01]) [172.56.3.195]:52893
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 15:33:01 -0000

Martin,

Managing transitions is always a challenge. Also coming up with a consensus 
solutions often involves compromise which will sometimes challenge 
enthusiasm for support of the solution. Unfortunately, schema mount hits 
both of these challenges.

>From the compromise standpoint, we've had parties basically negotiate over 
a period of 2 years on a solution that both accepted is workable. I know 
that the users of the draft explicitly decided that the documented solution 
was good enough for their needs and it was preferable to move forward then 
continue debating for their preferred changes.

>From the transition standpoint we have a document that completed last call 
months ago with only minor issues being raised. It is true that the current 
document doesn't support different schemas in different data stores, in all 
but one case, and this limitation should certainly be documented. But from 
the process standpoint, it's rather hard to say that we should not move 
forward with a post last call document in deference to an alternative that 
has yet to be documented, debated, or whose impact can be fully analyzed.

Lou

On January 19, 2018 3:59:22 AM Martin Bjorklund  wrote:
...
> Hi,
>
> joel jaeggli  wrote:
>>
>>
>> On 1/18/18 11:15 AM, Martin Bjorklund wrote:
>> > Ladislav Lhotka  wrote:
>> >> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
>> >>> Ignoring process issues (not sure there are any), does it make sense
>> >>> to publish a YANG module on the standards-track that is replaced by
>> >>> something different 3-6 months later?
>> >> IMO such a document churn would be a serious mistake. In the documents 
>> that are
>> >> currently on the table (at least NMDA, YLbis, SM) we are dealing with 
>> quite a
>> >> few tricky and interrelated things, so it's important to come up with a 
>> coherent
>> >> view into which all the components nicely fit. And I believe we are now 
>> quite
>> >> close.
>> >>
>> >> Publishing an interim solution that is a priori known to be technically 
>> inferior
>> >> would just confuse people. The fact that it can be hacked to support two or
>> >> three particular data models (albeit important) doesn't warrant to do so.
>> > I strongly agree with this!
>> Do we believe that documents using normative referencing to this draft
>> e.g. in routing would require changes in order to accommodate an updated
>> draft?
>>
>> If yes then we're doing ourselves a clear dis-service by essentially
>> clearing the boards of the existing draft.
>
> As Lada wrote earlier, two of the three drafts need updated *examples*
> in their appendicies.  They do not need any changes to their normative
> sections.
>
>> If that is the case we
>> should consider publishing this one possibly with an appropriate
>> applicability statement; the work on the new one can proceed so that at
>> least they have a stable reference. This assumes not fundamental flaws
>> that make the current one unusable.
>
> Since some time back, we require all drafts to be NMDA compliant.  Why
> should SM be different?  Note that this solution does not *require*
> NMDA.
>
> One reason for SM being late is that it has been difficult to find a
> technical solution for which even the authors could agree.  The
> current draft is a compromise.  By using YLbis we can solve some of
> these issues, and since this is a central building block I think it
> would be very unwise to publish it just to avoid updating two
> examples.
>
>
> /martin
>
>
>
>>
>>
>> > /martin
>> >
>> >>> Note that the NMDA contributors, after getting the overall design
>> >>> done, move sequentially through the details of the documents; we first
>> >>> focused on the NMDA document, which is in the RFC editor queue now. We
>> >>> then focussed on the protocol extensions, which are now in WG last
>> >>> call. Currently we are focusing on getting the new yang library
>> >>> finalized. If no major isses pop up, the NMDA work may be complete by
>> >>> the London IETF. Hence the 3 months lower bound mentioned above.
>> >> I agree, and will try to help.
>> >>
>> >> Thanks, Lada
>> >>
>> >>> /js
>> >>>
>> >>> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
>> >>>> Martin,
>> >>>>
>> >>>> I do agree with that at some point we will need to revisit scheme mount in
>> >>>> the context of YL-bis, as there are different possible solutions for
>> >>>> handling different datastores mounting  different schema. I think Rob laid
>> >>>> out the options pretty well here, ie doing it now or publishing as is and
>> >>>> immediately working on the document that covers both.
>> >>>>
>> >>>> As I mentioned before I think this is as much a process issue as anything
>> >>>> else - and have a planned call to discuss possible directions with 
>> chairs. I
>> >>>> hope we can have some propose next steps on this to the working group in
>> >>>> short order.
>> >>>>
>> >>>> Lou
>> >>>>
>> >>>>
>> >>>> On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
>> >>>>
>> >>>>> Lou Berger  wrote:
>> >>>>>>
>> >>>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>> >>>>>> ...
>> >>>>>>>>> My main concern is actually the YL version.  I strongly think SM
>> >>>>>>>>> need
>> >>>>>>>>> to use YL-bis rather that the old YL, so that it can support NMDA.
>> >>>>>>>>>
>> >>>>>>>> Right now to SM is independent of Yang Library version and can run
>> >>>>>>>> with either.
>> >>>>>>> No this is not correct.  SM uses a grouping from the old YANG
>> >>>>>>> library (for the "use-schema" case),
>> >>>>>> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
>> >>>>>> can include either.
>> >>>>> The old "modules-state" structure is deprecated, and a new structure
>> >>>>> that allows multiple datastores is defined.  Note that YLbis can be
>> >>>>> used by both NMDA-capabale and non-NMDA-capabale servers.
>> >>>>>
>> >>>>>>>   and talks about mounting
>> >>>>>>> "modules-state" ("inline" case).
>> >>>>>> In informative descriptions only.  Certainly these can be changed to
>> >>>>>> allow for YL-bis if need be.
>> >>>>>>
>> >>>>>>>> I certainly would expect use of Yang Library bis and nmda
>> >>>>>>>> to have advantages.
>> >>>>>>>>
>> >>>>>>>>> The implementation effort for supporting the new YL in clients and
>> >>>>>>>>> servers is minimal, esp. when compared to the efforts involved in
>> >>>>>>>>> supporting SM.
>> >>>>>>>>>
>> >>>>>>>>> Adding an indirection is (for me) less important, but it has the
>> >>>>>>>>> benefit of solving the two issues (a) and (b) above, and I haven't
>> >>>>>>>>> seen any technical problem with it.
>> >>>>>>>>>
>> >>>>>>>> (A) has implementation implications and those participating in the
>> >>>>>>>> discussion at the time expressed as not being worth the cost.
>> >>>>>>>> I don't believe b was seen as a significant issue either.
>> >>>>>>>>
>> >>>>>>>>> Do you have any technical concerns with using an annotation as an
>> >>>>>>>>> indirection?
>> >>>>>>>>>
>> >>>>>>>> The technicsl issue I have with the approaches the same one that was
>> >>>>>>>> raised when debated previously, ie the implementation overhead of
>> >>>>>>>> requiring inline schemas to be available at the top level.
>> >>>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>> >>>>>>> we need to use the new YL-bis, so that we can support the NMDA.
>> >>>>>> Given that NMDA support is not yet fully defined, we're still in the
>> >>>>>> transition period where support for both NMDA and non-NMDA
>> >>>>>> implementations need to be considered.  Rob presented some options
>> >>>>>> earlier in the thread that I think captures this.
>> >>>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
>> >>>>>
>> >>>>> Also note that YLbis is just a different read-only monitoring
>> >>>>> structure.  Given an implementation that supports the old YL, it is
>> >>>>> trivial to add support for YLbis (especially compared to the more than
>> >>>>> non-trivial amount of work required to support schema mount...).
>> >>>>>
>> >>>>>
>> >>>>> /martin
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> netmod mailing list
>> >>>> netmod@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>>
>> >> --
>> >> Ladislav Lhotka
>> >> Head, CZ.NIC Labs
>> >> PGP Key ID: 0xB8F92B08A9F76C67
>> >>
>> >> _______________________________________________
>> >> 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
>



From nobody Fri Jan 19 08:48: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 8E80312DA48 for ; Fri, 19 Jan 2018 08:47:59 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 HUO7v494gYY8 for ; Fri, 19 Jan 2018 08:47:57 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C804F12DA6C for ; Fri, 19 Jan 2018 08:47:39 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 37C5E1AE0399; Fri, 19 Jan 2018 17:47:38 +0100 (CET)
Date: Fri, 19 Jan 2018 17:47:37 +0100 (CET)
Message-Id: <20180119.174737.2013145074039238939.mbj@tail-f.com>
To: lberger@labn.net
Cc: joelja@bogus.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1610efad0f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References:  <20180119.095841.1647865928078984723.mbj@tail-f.com> <1610efad0f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 16:47:59 -0000

Lou Berger  wrote:
> Martin,
> 
> Managing transitions is always a challenge. Also coming up with a
> consensus solutions often involves compromise which will sometimes
> challenge enthusiasm for support of the solution. Unfortunately,
> schema mount hits both of these challenges.
> 
> From the compromise standpoint, we've had parties basically negotiate
> over a period of 2 years on a solution that both accepted is
> workable. I know that the users of the draft explicitly decided that

Note that nothing changes for other documents if we use YLbis (except
for updating some examples, as Lada noted).  Also note that there are
other users than other WGs (vendor implementations).

Yes, it may add a few more weeks to the publication process, but I
definitely think it is worth it.  As you wrote, we've been working
on this for a couple of years, so waiting a few more weeks should be
ok.

I note that you didn't reply to my question about why this document is
different compared to all other documents that we require to be
NMDA-compliant.


/martin


> the documented solution was good enough for their needs and it was
> preferable to move forward then continue debating for their preferred
> changes.
> 
> From the transition standpoint we have a document that completed last
> call months ago with only minor issues being raised. It is true that
> the current document doesn't support different schemas in different
> data stores, in all but one case, and this limitation should certainly
> be documented. But from the process standpoint, it's rather hard to
> say that we should not move forward with a post last call document in
> deference to an alternative that has yet to be documented, debated, or
> whose impact can be fully analyzed.
> 
> Lou
> 
> On January 19, 2018 3:59:22 AM Martin Bjorklund 
> wrote:
> ...
> > Hi,
> >
> > joel jaeggli  wrote:
> >>
> >>
> >> On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> >> > Ladislav Lhotka  wrote:
> >> >> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> >> >>> Ignoring process issues (not sure there are any), does it make sense
> >> >>> to publish a YANG module on the standards-track that is replaced by
> >> >>> something different 3-6 months later?
> >> >> IMO such a document churn would be a serious mistake. In the documents
> >> >> that are
> >> >> currently on the table (at least NMDA, YLbis, SM) we are dealing with
> >> >> quite a
> >> >> few tricky and interrelated things, so it's important to come up with
> >> >> a coherent
> >> >> view into which all the components nicely fit. And I believe we are
> >> >> now quite
> >> >> close.
> >> >>
> >> >> Publishing an interim solution that is a priori known to be
> >> >> technically inferior
> >> >> would just confuse people. The fact that it can be hacked to support
> >> >> two or
> >> >> three particular data models (albeit important) doesn't warrant to do
> >> >> so.
> >> > I strongly agree with this!
> >> Do we believe that documents using normative referencing to this draft
> >> e.g. in routing would require changes in order to accommodate an
> >> updated
> >> draft?
> >>
> >> If yes then we're doing ourselves a clear dis-service by essentially
> >> clearing the boards of the existing draft.
> >
> > As Lada wrote earlier, two of the three drafts need updated *examples*
> > in their appendicies.  They do not need any changes to their normative
> > sections.
> >
> >> If that is the case we
> >> should consider publishing this one possibly with an appropriate
> >> applicability statement; the work on the new one can proceed so that
> >> at
> >> least they have a stable reference. This assumes not fundamental flaws
> >> that make the current one unusable.
> >
> > Since some time back, we require all drafts to be NMDA compliant.  Why
> > should SM be different?  Note that this solution does not *require*
> > NMDA.
> >
> > One reason for SM being late is that it has been difficult to find a
> > technical solution for which even the authors could agree.  The
> > current draft is a compromise.  By using YLbis we can solve some of
> > these issues, and since this is a central building block I think it
> > would be very unwise to publish it just to avoid updating two
> > examples.
> >
> >
> > /martin
> >
> >
> >
> >>
> >>
> >> > /martin
> >> >
> >> >>> Note that the NMDA contributors, after getting the overall design
> >> >>> done, move sequentially through the details of the documents; we first
> >> >>> focused on the NMDA document, which is in the RFC editor queue now. We
> >> >>> then focussed on the protocol extensions, which are now in WG last
> >> >>> call. Currently we are focusing on getting the new yang library
> >> >>> finalized. If no major isses pop up, the NMDA work may be complete by
> >> >>> the London IETF. Hence the 3 months lower bound mentioned above.
> >> >> I agree, and will try to help.
> >> >>
> >> >> Thanks, Lada
> >> >>
> >> >>> /js
> >> >>>
> >> >>> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> >> >>>> Martin,
> >> >>>>
> >> >>>> I do agree with that at some point we will need to revisit scheme
> >> >>>> mount in
> >> >>>> the context of YL-bis, as there are different possible solutions for
> >> >>>> handling different datastores mounting different schema. I think Rob
> >> >>>> laid
> >> >>>> out the options pretty well here, ie doing it now or publishing as is
> >> >>>> and
> >> >>>> immediately working on the document that covers both.
> >> >>>>
> >> >>>> As I mentioned before I think this is as much a process issue as
> >> >>>> anything
> >> >>>> else - and have a planned call to discuss possible directions with
> >> >>>> chairs. I
> >> >>>> hope we can have some propose next steps on this to the working group
> >> >>>> in
> >> >>>> short order.
> >> >>>>
> >> >>>> Lou
> >> >>>>
> >> >>>>
> >> >>>> On January 18, 2018 2:57:23 AM Martin Bjorklund 
> >> >>>> wrote:
> >> >>>>
> >> >>>>> Lou Berger  wrote:
> >> >>>>>>
> >> >>>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> >> >>>>>> ...
> >> >>>>>>>>> My main concern is actually the YL version.  I strongly think SM
> >> >>>>>>>>> need
> >> >>>>>>>>> to use YL-bis rather that the old YL, so that it can support NMDA.
> >> >>>>>>>>>
> >> >>>>>>>> Right now to SM is independent of Yang Library version and can run
> >> >>>>>>>> with either.
> >> >>>>>>> No this is not correct.  SM uses a grouping from the old YANG
> >> >>>>>>> library (for the "use-schema" case),
> >> >>>>>> I thought YLbis was an updat e to UL (i.e., no name change) as such
> >> >>>>>> SM
> >> >>>>>> can include either.
> >> >>>>> The old "modules-state" structure is deprecated, and a new structure
> >> >>>>> that allows multiple datastores is defined.  Note that YLbis can be
> >> >>>>> used by both NMDA-capabale and non-NMDA-capabale servers.
> >> >>>>>
> >> >>>>>>>   and talks about mounting
> >> >>>>>>> "modules-state" ("inline" case).
> >> >>>>>> In informative descriptions only.  Certainly these can be changed to
> >> >>>>>> allow for YL-bis if need be.
> >> >>>>>>
> >> >>>>>>>> I certainly would expect use of Yang Library bis and nmda
> >> >>>>>>>> to have advantages.
> >> >>>>>>>>
> >> >>>>>>>>> The implementation effort for supporting the new YL in clients and
> >> >>>>>>>>> servers is minimal, esp. when compared to the efforts involved in
> >> >>>>>>>>> supporting SM.
> >> >>>>>>>>>
> >> >>>>>>>>> Adding an indirection is (for me) less important, but it has the
> >> >>>>>>>>> benefit of solving the two issues (a) and (b) above, and I haven't
> >> >>>>>>>>> seen any technical problem with it.
> >> >>>>>>>>>
> >> >>>>>>>> (A) has implementation implications and those participating in the
> >> >>>>>>>> discussion at the time expressed as not being worth the cost.
> >> >>>>>>>> I don't believe b was seen as a significant issue either.
> >> >>>>>>>>
> >> >>>>>>>>> Do you have any technical concerns with using an annotation as an
> >> >>>>>>>>> indirection?
> >> >>>>>>>>>
> >> >>>>>>>> The technicsl issue I have with the approaches the same one that
> >> >>>>>>>> was
> >> >>>>>>>> raised when debated previously, ie the implementation overhead of
> >> >>>>>>>> requiring inline schemas to be available at the top level.
> >> >>>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
> >> >>>>>>> we need to use the new YL-bis, so that we can support the NMDA.
> >> >>>>>> Given that NMDA support is not yet fully defined, we're still in the
> >> >>>>>> transition period where support for both NMDA and non-NMDA
> >> >>>>>> implementations need to be considered.  Rob presented some options
> >> >>>>>> earlier in the thread that I think captures this.
> >> >>>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
> >> >>>>>
> >> >>>>> Also note that YLbis is just a different read-only monitoring
> >> >>>>> structure.  Given an implementation that supports the old YL, it is
> >> >>>>> trivial to add support for YLbis (especially compared to the more than
> >> >>>>> non-trivial amount of work required to support schema mount...).
> >> >>>>>
> >> >>>>>
> >> >>>>> /martin
> >> >>>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> netmod mailing list
> >> >>>> netmod@ietf.org
> >> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >> >>>
> >> >> --
> >> >> Ladislav Lhotka
> >> >> Head, CZ.NIC Labs
> >> >> PGP Key ID: 0xB8F92B08A9F76C67
> >> >>
> >> >> _______________________________________________
> >> >> 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
> >
> 
> 


From nobody Fri Jan 19 09:04:36 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 D7ECA12E03A for ; Fri, 19 Jan 2018 09:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 72-opl_55rSh for ; Fri, 19 Jan 2018 09:04:31 -0800 (PST)
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 D781612DB71 for ; Fri, 19 Jan 2018 09:04:29 -0800 (PST)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id A311365307 for ; Fri, 19 Jan 2018 18:04:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516381467; bh=8eN567hJqZ+eC2V553HvvTB2YekhOl9GMln7R4b8+5w=; h=From:To:Date; b=n1VNWsnA3xKzekTyIrRBPh4R7pZOnK2MucaKjSOoIX4Aq3pPiVeOXVzp40SAYKJ+Z NI3vYoIVx3AqQoTq3BcwKqSIIToUw48zvvavkiF0hO/iZipygTqLX5vpYxNl1iQrdI D/c4QNBNSSMhCPhnWWSJD9oYj1leaE+VoTo3QCVY=
Message-ID: <1516381466.14685.21.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 19 Jan 2018 18:04:26 +0100
In-Reply-To: <1610efad0f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <1516302637.22408.23.camel@nic.cz> <20180118.201535.2290905942673102021.mbj@tail-f.com>  <20180119.095841.1647865928078984723.mbj@tail-f.com> <1610efad0f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 17:04:35 -0000

Hi Lou,

On Fri, 2018-01-19 at 10:13 -0500, Lou Berger wrote:
> Martin,
> 
> Managing transitions is always a challenge. Also coming up with a consensus 
> solutions often involves compromise which will sometimes challenge 
> enthusiasm for support of the solution. Unfortunately, schema mount hits 
> both of these challenges.

Transition problems is what we would create by publishing the current revision
of SM now and another in a couple of months. It would most likely mean keeping
some annoying baggage like obsolete nodes that only confuse readers. We can and
should avoid this.

> 
> > From the compromise standpoint, we've had parties basically negotiate over 
> 
> a period of 2 years on a solution that both accepted is workable. I know 
> that the users of the draft explicitly decided that the documented solution 
> was good enough for their needs and it was preferable to move forward then 
> continue debating for their preferred changes.
> 
> > From the transition standpoint we have a document that completed last call 
> 
> months ago with only minor issues being raised. It is true that the current 
> document doesn't support different schemas in different data stores, in all 
> but one case, and this limitation should certainly be documented. But from

For me, it is not so much about limitations but rather about architecture, i.e.
good design of metadata that describe the overall data model. If it is messy
with gaps covered by hand-waving statements, nobody will understand it.

Lada

> the process standpoint, it's rather hard to say that we should not move 
> forward with a post last call document in deference to an alternative that 
> has yet to be documented, debated, or whose impact can be fully analyzed.
> 
> Lou
> 
> On January 19, 2018 3:59:22 AM Martin Bjorklund  wrote:
> ...
> > Hi,
> > 
> > joel jaeggli  wrote:
> > > 
> > > 
> > > On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> > > > Ladislav Lhotka  wrote:
> > > > > On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> > > > > > Ignoring process issues (not sure there are any), does it make sense
> > > > > > to publish a YANG module on the standards-track that is replaced by
> > > > > > something different 3-6 months later?
> > > > > 
> > > > > IMO such a document churn would be a serious mistake. In the
> > > > > documents 
> > > 
> > > that are
> > > > > currently on the table (at least NMDA, YLbis, SM) we are dealing with 
> > > 
> > > quite a
> > > > > few tricky and interrelated things, so it's important to come up with
> > > > > a 
> > > 
> > > coherent
> > > > > view into which all the components nicely fit. And I believe we are
> > > > > now 
> > > 
> > > quite
> > > > > close.
> > > > > 
> > > > > Publishing an interim solution that is a priori known to be
> > > > > technically 
> > > 
> > > inferior
> > > > > would just confuse people. The fact that it can be hacked to support
> > > > > two or
> > > > > three particular data models (albeit important) doesn't warrant to do
> > > > > so.
> > > > 
> > > > I strongly agree with this!
> > > 
> > > Do we believe that documents using normative referencing to this draft
> > > e.g. in routing would require changes in order to accommodate an updated
> > > draft?
> > > 
> > > If yes then we're doing ourselves a clear dis-service by essentially
> > > clearing the boards of the existing draft.
> > 
> > As Lada wrote earlier, two of the three drafts need updated *examples*
> > in their appendicies.  They do not need any changes to their normative
> > sections.
> > 
> > > If that is the case we
> > > should consider publishing this one possibly with an appropriate
> > > applicability statement; the work on the new one can proceed so that at
> > > least they have a stable reference. This assumes not fundamental flaws
> > > that make the current one unusable.
> > 
> > Since some time back, we require all drafts to be NMDA compliant.  Why
> > should SM be different?  Note that this solution does not *require*
> > NMDA.
> > 
> > One reason for SM being late is that it has been difficult to find a
> > technical solution for which even the authors could agree.  The
> > current draft is a compromise.  By using YLbis we can solve some of
> > these issues, and since this is a central building block I think it
> > would be very unwise to publish it just to avoid updating two
> > examples.
> > 
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > 
> > > > /martin
> > > > 
> > > > > > Note that the NMDA contributors, after getting the overall design
> > > > > > done, move sequentially through the details of the documents; we
> > > > > > first
> > > > > > focused on the NMDA document, which is in the RFC editor queue now.
> > > > > > We
> > > > > > then focussed on the protocol extensions, which are now in WG last
> > > > > > call. Currently we are focusing on getting the new yang library
> > > > > > finalized. If no major isses pop up, the NMDA work may be complete
> > > > > > by
> > > > > > the London IETF. Hence the 3 months lower bound mentioned above.
> > > > > 
> > > > > I agree, and will try to help.
> > > > > 
> > > > > Thanks, Lada
> > > > > 
> > > > > > /js
> > > > > > 
> > > > > > On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> > > > > > > Martin,
> > > > > > > 
> > > > > > > I do agree with that at some point we will need to revisit scheme
> > > > > > > mount in
> > > > > > > the context of YL-bis, as there are different possible solutions
> > > > > > > for
> > > > > > > handling different datastores mounting  different schema. I think
> > > > > > > Rob laid
> > > > > > > out the options pretty well here, ie doing it now or publishing as
> > > > > > > is and
> > > > > > > immediately working on the document that covers both.
> > > > > > > 
> > > > > > > As I mentioned before I think this is as much a process issue as
> > > > > > > anything
> > > > > > > else - and have a planned call to discuss possible directions
> > > > > > > with 
> > > 
> > > chairs. I
> > > > > > > hope we can have some propose next steps on this to the working
> > > > > > > group in
> > > > > > > short order.
> > > > > > > 
> > > > > > > Lou
> > > > > > > 
> > > > > > > 
> > > > > > > On January 18, 2018 2:57:23 AM Martin Bjorklund 
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > Lou Berger  wrote:
> > > > > > > > > 
> > > > > > > > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > > > > > > > ...
> > > > > > > > > > > > My main concern is actually the YL version.  I strongly
> > > > > > > > > > > > think SM
> > > > > > > > > > > > need
> > > > > > > > > > > > to use YL-bis rather that the old YL, so that it can
> > > > > > > > > > > > support NMDA.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Right now to SM is independent of Yang Library version and
> > > > > > > > > > > can run
> > > > > > > > > > > with either.
> > > > > > > > > > 
> > > > > > > > > > No this is not correct.  SM uses a grouping from the old
> > > > > > > > > > YANG
> > > > > > > > > > library (for the "use-schema" case),
> > > > > > > > > 
> > > > > > > > > I thought YLbis was an updat e to UL (i.e., no name change) as
> > > > > > > > > such SM
> > > > > > > > > can include either.
> > > > > > > > 
> > > > > > > > The old "modules-state" structure is deprecated, and a new
> > > > > > > > structure
> > > > > > > > that allows multiple datastores is defined.  Note that YLbis can
> > > > > > > > be
> > > > > > > > used by both NMDA-capabale and non-NMDA-capabale servers.
> > > > > > > > 
> > > > > > > > > >   and talks about mounting
> > > > > > > > > > "modules-state" ("inline" case).
> > > > > > > > > 
> > > > > > > > > In informative descriptions only.  Certainly these can be
> > > > > > > > > changed to
> > > > > > > > > allow for YL-bis if need be.
> > > > > > > > > 
> > > > > > > > > > > I certainly would expect use of Yang Library bis and nmda
> > > > > > > > > > > to have advantages.
> > > > > > > > > > > 
> > > > > > > > > > > > The implementation effort for supporting the new YL in
> > > > > > > > > > > > clients and
> > > > > > > > > > > > servers is minimal, esp. when compared to the efforts
> > > > > > > > > > > > involved in
> > > > > > > > > > > > supporting SM.
> > > > > > > > > > > > 
> > > > > > > > > > > > Adding an indirection is (for me) less important, but it
> > > > > > > > > > > > has the
> > > > > > > > > > > > benefit of solving the two issues (a) and (b) above, and
> > > > > > > > > > > > I haven't
> > > > > > > > > > > > seen any technical problem with it.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > (A) has implementation implications and those
> > > > > > > > > > > participating in the
> > > > > > > > > > > discussion at the time expressed as not being worth the
> > > > > > > > > > > cost.
> > > > > > > > > > > I don't believe b was seen as a significant issue either.
> > > > > > > > > > > 
> > > > > > > > > > > > Do you have any technical concerns with using an
> > > > > > > > > > > > annotation as an
> > > > > > > > > > > > indirection?
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > The technicsl issue I have with the approaches the same
> > > > > > > > > > > one that was
> > > > > > > > > > > raised when debated previously, ie the implementation
> > > > > > > > > > > overhead of
> > > > > > > > > > > requiring inline schemas to be available at the top level.
> > > > > > > > > > 
> > > > > > > > > > Ok.  I'm ok with keeping the inline case as it is.  However,
> > > > > > > > > > I think
> > > > > > > > > > we need to use the new YL-bis, so that we can support the
> > > > > > > > > > NMDA.
> > > > > > > > > 
> > > > > > > > > Given that NMDA support is not yet fully defined, we're still
> > > > > > > > > in the
> > > > > > > > > transition period where support for both NMDA and non-NMDA
> > > > > > > > > implementations need to be considered.  Rob presented some
> > > > > > > > > options
> > > > > > > > > earlier in the thread that I think captures this.
> > > > > > > > 
> > > > > > > > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > > > > > > > 
> > > > > > > > Also note that YLbis is just a different read-only monitoring
> > > > > > > > structure.  Given an implementation that supports the old YL, it
> > > > > > > > is
> > > > > > > > trivial to add support for YLbis (especially compared to the
> > > > > > > > more than
> > > > > > > > non-trivial amount of work required to support schema mount...).
> > > > > > > > 
> > > > > > > > 
> > > > > > > > /martin
> > > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > 
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > 
> 
> 
> _______________________________________________
> 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 Fri Jan 19 10:05: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 27AF51275AB for ; Fri, 19 Jan 2018 10:05:21 -0800 (PST)
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_RP_MATCHES_RCVD=-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 j9BIxlwgUYBs for ; Fri, 19 Jan 2018 10:05:19 -0800 (PST)
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 48080127599 for ; Fri, 19 Jan 2018 10:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2223; q=dns/txt; s=iport; t=1516385119; x=1517594719; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=AAncMPNqxzTMVbdyT8M+awunrK5x7rGzNMdcrcbbrzw=; b=JzGd4tNC59+WRsGX5dqkmC+I2DJQzPseAH6omQuCCuzIbNvXySQMGL2p 2Eur3wYKeXgJgkEei1hDvZoZwUTJBM5u29VVwBkp25AjJq7cJBLvUQFWA BK7HwVb64iIw8O4AQSb7J9EzR6DbvCgnaIP0tZU1VFbcMj4JV2tdPZ0Aa 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQAaMmJa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUcJ4NdixiPRyeZSQqFOwKFJRQBAQEBAQEBAQFrKIUjAQEBAwE?= =?us-ascii?q?jDwEFUQsOCgICJgICVwYBDAYCAQEXihAIr1mCJ4oyAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYEPgzmDbIFoKQyCeYMvBIFZgy2CZQWjdZVYghmKDiaHS48xiA2BPDY?= =?us-ascii?q?igU8yGggbFYJnhFdBN4xsAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,382,1511827200";  d="scan'208";a="1501131"
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; 19 Jan 2018 18:05:15 +0000
Received: from [10.61.73.253] (ams3-vpn-dhcp2557.cisco.com [10.61.73.253]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0JI5EIU026193; Fri, 19 Jan 2018 18:05:14 GMT
To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org, Lou Berger 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
Date: Fri, 19 Jan 2018 18:05:15 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180117.174039.2105430212248651483.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 18:05:21 -0000

On 17/01/2018 16:40, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:



>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>> I don't agree. The metadata annotation solves real issues.
> One issue with the annotation is that since the schema might be
> different in different datastores, it means that the client needs to
> read the annotation in all datastores, and then fetch the schemas.  So
> it is a bit more difficult to work with for a client.
I'm still not convinced that I really understand all the arguments here:

Using YLbis over YL seems to have obvious benefits to me, in that I 
perceive that it gives a cleaner data model.  But I also understand 
Lou's concerns - although its not clear to me whether Lou's primary 
concern is timing, or the fact that implementations are forced to use YLbis.

I also agree with Juergen that from an YLbis authors perspective YLbis 
is quite close.  I believe that the YANG model itself has been agreed 
(at the interim meeting in Nov/Dec), and hence really what is left is 
just tidying/enhancing the descriptive text in the document.

I don't really understand the benefits of the metadata annotations. It 
feels like this is going to be more hassle because a client will have to 
query each datastore separately rather than getting the information in a 
single operation.

A regular (without SM) NMDA NC/YANG server supports multiple datastores, 
but that information is only exposed via one so them (i.e. 
).  So, in a server supporting inline SM, it seems quite 
natural to me for the mounted schema information to also only be 
available via the mounted .  This seems to mirror the 
standard NC/YANG+YL behavior, and also seems to naturally recurse if 
required.

Hence, for me, I see the choice as:
1) do we publish the existing model now (perhaps also mark the draft as 
experimental) followed by an updated draft with the NMDA compatible module?
2) do we publish both models in a single draft (e.g. with the existing 
model in an appendix)?
3) do we only publish a single version of the draft with an NMDA 
compliant solution.

Thanks,
Rob



From nobody Fri Jan 19 10:42:54 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 9010C129C51 for ; Fri, 19 Jan 2018 10:42:52 -0800 (PST)
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 elM-xxlVPSWo for ; Fri, 19 Jan 2018 10:42:49 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 EBB42128959 for ; Fri, 19 Jan 2018 10:42:38 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id x4so2213483otg.7 for ; Fri, 19 Jan 2018 10:42:38 -0800 (PST)
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=n3bvsD3cyjcXjFX5Cs9ir1UqQ3OLB6bar/ieBx3dIAs=; b=hEgSXCeJM6uNc2JhabL9lUEvrQTKd3t+vompTbWMuqDWUt8yw8ZvN8ca4C8dnpPFIH lURDuYIwkC8mSEBEK/VvWKokD+qQTQ6wl+xQrVE8WqLzpR0vDNgMs6OXaAPm2C6HTmJ/ H8CFcfWGsbrrlhTJ4bmuZ1GWZfxUSDu4IY1BXZODsoXTNTgaeY4elhDMMrxIsQc1ncgb W+w1R6I7cEeAAZ+zVj0tfQiU8IZw99th5bsVckdh5P75unX4JZUSN/XqPJy9kca6/5vL ji3VbVrtUWwVUGlNP7XnWNlPXKa21aNJp7zU083AifDR0QLUSZYoi1mhhRzMJLCZCKod w9DA==
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=n3bvsD3cyjcXjFX5Cs9ir1UqQ3OLB6bar/ieBx3dIAs=; b=W2NCI9SxpPNfjRxFaIJfeuu9XGMbjr4hmMKHFcsN64+A+wWqHMXB55/1JhHIG7O9op zBO96fbpGxCjVzHBZXNGp0q8wz4UZZal+KOUhalTh+PRhNvevkggK/EQXA8E4Y5yOOqO pW/0uTC1+wcbHdWfRA0DfxGGEjO6XkG67LZXEliJD0I60DK+Y1yVM+L70m8KZd6XQtbW wLUdTXVc7ILL6SaGifCwvCIrbEdH7jl+CyjsC5WAhu7X80PugVAO/7fpZB/8sFgVxqsT 3E2qsTZ2UMEchPFhLlSzaweP/cjZBbMQVHXL3GL/dUB9dMWavV1KFmfmc2Eal3dJ38TU 8YpA==
X-Gm-Message-State: AKwxytdZ6ufQI05DNFlfNQGByowe48gh0r6AB6lqMKiMPxek3Pzf6MTt B9IQEBCUJIE/ZxymYBuvOS0=
X-Google-Smtp-Source: ACJfBovc/xoYRXgierP81bxEKQYh03N4AuU8hmMfvfEjCriR1VRTI6uzcT9rNWI/iz57IQm1jT9ojw==
X-Received: by 10.157.27.171 with SMTP id z40mr5821327otd.357.1516387358333; Fri, 19 Jan 2018 10:42:38 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:e935:89d3:e703:5695]) by smtp.gmail.com with ESMTPSA id 74sm3913078otv.28.2018.01.19.10.42.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 10:42:37 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Fri, 19 Jan 2018 10:42:35 -0800
Cc: Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com>
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>  
To: Kent Watsen 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 18:42:52 -0000

Kent,

I have not heard a strong requirement to have the open issue fixed in =
this version of the RFC. We would therefore like to defer it to a bis =
document.

I will wait for the LC to complete, and update the draft to address all =
the comments received during the LC.

Thanks.

> On Jan 17, 2018, at 3:33 PM, Kent Watsen  wrote:
>=20
>=20
> H Mahesh,
>=20
>>> - There is an open issue in the document (section 8) - are we going
>>> to resolve that during WG last call or is this a leftover?
>>=20
>> This will be resolved in the next version of the module. It is
>> documented under Issues tab in GitHub. Should we remove it from
>> the draft?
>=20
> Most of Juergen's comments are editorial in nature and can truly be =
handled as part of the LC process, but this open issue has me worried, =
as it may result in a significant technical change. =20
>=20
> What will it take to close this open issue?  Is it just a matter of =
the getting the WG to agree that it's not an issue, or do we already =
know that it is a real issue and only the solution is pending?
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>=20

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Fri Jan 19 11:04: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 00D58127137 for ; Fri, 19 Jan 2018 11:04:13 -0800 (PST)
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 cCtpJvauAayA for ; Fri, 19 Jan 2018 11:04:11 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 BF290128D2E for ; Fri, 19 Jan 2018 11:04:08 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 5C8561E3FDD for ; Fri, 19 Jan 2018 12:01:05 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 0K121x00m2SSUrH01K15Yj; Fri, 19 Jan 2018 12:01:05 -0700
X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=AUd_NHdVAAAA:8 a=VfLx_E0lEhFqYHDakOcA:9 a=QEXdDO2ut3YA:10
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:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5jY2V52fsF5Jub5axKPZEACPUqIYlFswkBRBI0eSaXc=; b=m3BySAO9OxC2RhtVaY5FTBrW22 4Hu+pi1dXudBactbcuUUyDH/g0zETuvGKPyRYwu1OgL5BfXPYmWdrGyjnRFpb530yeRgoV3sNGEEm H/L/s5p1fUcptR8NpUiwH7EI9;
Received: from [172.56.3.195] (port=55228 helo=[IPV6:2607:fb90:1803:a580:0:19:a1a9:7c01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ecbuP-0012Jy-Uo; Fri, 19 Jan 2018 12:01:02 -0700
From: Lou Berger 
To: Robert Wilton , Martin Bjorklund , , 
Date: Fri, 19 Jan 2018 14:00:59 -0500
Message-ID: <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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: 172.56.3.195
X-Exim-ID: 1ecbuP-0012Jy-Uo
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:1803:a580:0:19:a1a9:7c01]) [172.56.3.195]:55228
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Jan 2018 19:04:13 -0000

Rob,


On January 19, 2018 1:05:46 PM Robert Wilton  wrote:

>
>
> On 17/01/2018 16:40, Martin Bjorklund wrote:
>> Ladislav Lhotka  wrote:
>
> 
>
>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>>> I don't agree. The metadata annotation solves real issues.
>> One issue with the annotation is that since the schema might be
>> different in different datastores, it means that the client needs to
>> read the annotation in all datastores, and then fetch the schemas.  So
>> it is a bit more difficult to work with for a client.
> I'm still not convinced that I really understand all the arguments here:
>
> Using YLbis over YL seems to have obvious benefits to me, in that I
> perceive that it gives a cleaner data model. 

It is worth noting that the current scheme amount document can be used 
either with young library or Young Library BIS.

> But I also understand
> Lou's concerns - although its not clear to me whether Lou's primary
> concern is timing, or the fact that implementations are forced to use YLbis.
>

My concern is the delay required to reach consensus  on an unspecified 
solution that has not been discussed and may contain unknown implications. 
Keep in mind that where we are today has required compromises. Just because 
we have one party that understands what they think they're going to write 
doesn't mean that there will be changes as details are worked out, and as 
consensus is obtained.


> I also agree with Juergen that from an YLbis authors perspective YLbis
> is quite close.  I believe that the YANG model itself has been agreed
> (at the interim meeting in Nov/Dec), and hence really what is left is
> just tidying/enhancing the descriptive text in the document.
>
> I don't really understand the benefits of the metadata annotations. It
> feels like this is going to be more hassle because a client will have to
> query each datastore separately rather than getting the information in a
> single operation.
>
> A regular (without SM) NMDA NC/YANG server supports multiple datastores,
> but that information is only exposed via one so them (i.e.
> ).  So, in a server supporting inline SM, it seems quite
> natural to me for the mounted schema information to also only be
> available via the mounted . 

It also enables and implementation of the current SM document to support 
nmda data stores under a inline Mount point.

> This seems to mirror the
> standard NC/YANG+YL behavior, and also seems to naturally recurse if
> required.
>
> Hence, for me, I see the choice as:
> 1) do we publish the existing model now (perhaps also mark the draft as
> experimental) followed by an updated draft with the NMDA compatible module?
> 2) do we publish both models in a single draft (e.g. with the existing
> model in an appendix)?
> 3) do we only publish a single version of the draft with an NMDA
> compliant solution.
>

There are certainly a few variants possible, but the fundamental choice is 
to go ahead with basically what passed last call or not.

Lou

> Thanks,
> Rob
>
>
>



From nobody Sat Jan 20 07:21: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 6F2AF12AF6E for ; Sat, 20 Jan 2018 07:21:30 -0800 (PST)
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 K_Oe8LdfVCTQ for ; Sat, 20 Jan 2018 07:21:28 -0800 (PST)
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 89046126C89 for ; Sat, 20 Jan 2018 07:21:28 -0800 (PST)
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 w0KFJdxo014324; Sat, 20 Jan 2018 07:21:25 -0800
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=hqi753bczkAGgbVk90lRMnpv+xF+ebprk08nKy4Sl7I=; b=NTQigCPKgU0ZwPQKE6nnpHG8jYUgd3lhNWo55v1BmV0hq+pCqEsvzYvO4S+bN8WRUyCz 1E8UlTSbwfGhgypJ4rysjZ3JUQ6GbWFmq5gG0GJ/8IKuLtHuH4HMrLj3HNLeP9BWYhGf NEP2s7HqOMSktBHrET0+v30QRW8F8M1Un5VV7PS7AOk1oGSsjXB94m9JGF0TuEgyR7Yw uNh+ssQEMPJ5D3/+Rzd/fFsHq4me1ZUeFc/o4SasGTag3PCgdmefr9ufOq3sg2PU+qXW vB9pHuAhbHzfQdDycXQdNOTWDW3P+0rjg2Q0Ud9NrfHxaB/g2DVBT06a7JusCscnx2Sl lA== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0084.outbound.protection.outlook.com [207.46.163.84]) by mx0a-00273201.pphosted.com with ESMTP id 2fm7qp81qf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 20 Jan 2018 07:21:25 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3354.namprd05.prod.outlook.com (10.174.191.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Sat, 20 Jan 2018 15:21:23 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 15:21:23 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
CC: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKN4qxIAgAABR4D//7cngIADJ0+AgAEGT4A=
Date: Sat, 20 Jan 2018 15:21:23 +0000
Message-ID: 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com>
In-Reply-To: <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3354; 7:lNC73T45Pu6yz/GRwlMQnRWoBWF/XFA3KpvMhnA+RTKGIi04HB9WSkod7Q8p5IRDLkBTULbNFm5L1D79gfeKO2yVkU9AnCsE7QZJ0D4rQj7JLudNTvlk6B0TQdDFfhlVPwIdGHwc0Ksr5SCfpGAxPtE2RrfetkIaGdqGqZ8umOJbePG80Bk7geY32tFmGsdTbK/uRyP7rUUk91cA0C/0OW7mRqFNGh9XCJqmjMy4ojhMi2AkjmYCeqaJ6JZxLR+T
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7be95521-2030-4198-4705-08d560197751
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3354; 
x-ms-traffictypediagnostic: DM5PR05MB3354:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(2400081)(944501161)(10201501046)(6055026)(6041288)(20161123558120)(201703131423095)(201703011903075)(20161123555045)(201703061421075)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3354; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3354; 
x-forefront-prvs: 0558D3C5AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(376002)(366004)(346002)(396003)(39830400003)(189003)(199004)(81166006)(76176011)(5660300001)(8676002)(105586002)(106356001)(305945005)(6916009)(53546011)(39060400002)(3660700001)(59450400001)(7736002)(102836004)(4326008)(6506007)(3280700002)(25786009)(6246003)(2906002)(2950100002)(82746002)(36756003)(68736007)(81156014)(8936002)(6512007)(230783001)(6116002)(53936002)(3846002)(229853002)(2900100001)(66066001)(6436002)(58126008)(561944003)(54906003)(6486002)(86362001)(83506002)(14454004)(1411001)(93886005)(97736004)(83716003)(77096007)(33656002)(99286004)(508600001)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3354; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bW9NjTNGda7wbLL3pM1hpOtTZ+mUvCW1dt8k5KmZL6GCiTdgcR+tilSF22d3rBR1s20hjBx3LkMTe7iOtzqmuw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A463F4441200541BD53F621100D190A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7be95521-2030-4198-4705-08d560197751
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 15:21:23.4745 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3354
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-20_06:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801200224
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 15:21:31 -0000

SGkgTWFoZXNoLA0KDQpJJ20gb2theSBub3QgYWRkaW5nIHRoZSBhYmlsaXR5IHRvIHJlZmVyZW5j
ZSBhbiBleHRlcm5hbCBydWxlYmFzZSBub3csIG9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91J2Qg
YWxzbyBsaWtlIHRvIGRlZmVyIHByaW1pbmcgdGhlIFlBTkcgbW9kZWwgbm93IHNvIHRoYXQgaXQg
Y2FuIGJlIGFkZGVkIGxhdGVyIGluIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgbWFubmVyPw0KDQpJ
ZiB5b3UgcGxhbiB0byBwcmltZSB0aGUgWUFORyBtb2RlbCBzbyB0aGF0IHRoZSBhYmlsaXR5IHRv
IHJlZmVyZW5jZSBhbiBleHRlcm5hbCBydWxlYmFzZSBjYW4gYWRkZWQgbGF0ZXIgaW4gYSBiYWNr
d2FyZHMgY29tcGF0aWJsZSBtYW5uZXIsIGNhbiB5b3UgcGxlYXNlIHNlbmQgYSBjb25jcmV0ZSBw
cm9wb3NhbCB0byB0aGUgbGlzdCBzbyB0aGF0IHdlIGNhbiBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUg
aW1wYWN0PyAgDQoNCk15IGV4cGVjdGF0aW9uIGlzIHRoYXQgaXQgbWVyZWx5IGFkZHMgYSAnY2hv
aWNlJyBzdGF0ZW1lbnQgYXJvdW5kIHRoZSBleGlzdGluZyBydWxlYmFzZSBjb250YWluZXIsIHRo
ZXJlYnkgZW5hYmxpbmcgc29tZXRoaW5nIG90aGVyIHRoYW4gYSBydWxlYmFzZSBjb250YWluZXIg
dG8gZXhpc3Qgc29tZSBkYXkgaW4gdGhlIGZ1dHVyZS4gIA0KDQpJZiB0aGUgYWRkaXRpb24gaXMg
aW5kZWVkIGp1c3QgdGhpcywgdGhlbiBJIGRvbid0IGJlbGlldmUgdGhhdCBpdCBtYXRlcmlhbGx5
IGNoYW5nZXMgdGhlIEFDTCBtb2RlbCBhbmQgdGhlcmVmb3JlIGNhbiBiZSBhZGRlZCBhcyBhIExD
IGNvbW1lbnQuICBPZiBjb3Vyc2UsIHRoZSBXRyB3aWxsIHdhbnQgdG8gcmV2aWV3IHRoZSBhZGRp
dGlvbiBmb3IgY29ycmVjdG5lc3MsIGJ1dCBvdGhlcndpc2Ugc2hvdWxkIGJlIGFscmlnaHQuDQoN
ClRoYW5rcywNCktlbnQgLy8gY28tY2hhaXIgYW5kIHNoZXBoZXJkDQoNCg0KPT09PT0gb3JpZ2lu
YWwgbWVzc2FnZSA9PT09PQ0KDQpLZW50LA0KDQpJIGhhdmUgbm90IGhlYXJkIGEgc3Ryb25nIHJl
cXVpcmVtZW50IHRvIGhhdmUgdGhlIG9wZW4gaXNzdWUgZml4ZWQgaW4gdGhpcyB2ZXJzaW9uIG9m
IHRoZSBSRkMuIFdlIHdvdWxkIHRoZXJlZm9yZSBsaWtlIHRvIGRlZmVyIGl0IHRvIGEgYmlzIGRv
Y3VtZW50Lg0KDQpJIHdpbGwgd2FpdCBmb3IgdGhlIExDIHRvIGNvbXBsZXRlLCBhbmQgdXBkYXRl
IHRoZSBkcmFmdCB0byBhZGRyZXNzIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRo
ZSBMQy4NCg0KVGhhbmtzLg0KDQo+IE9uIEphbiAxNywgMjAxOCwgYXQgMzozMyBQTSwgS2VudCBX
YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gDQo+IEggTWFoZXNoLA0K
PiANCj4+PiAtIFRoZXJlIGlzIGFuIG9wZW4gaXNzdWUgaW4gdGhlIGRvY3VtZW50IChzZWN0aW9u
IDgpIC0gYXJlIHdlIGdvaW5nDQo+Pj4gdG8gcmVzb2x2ZSB0aGF0IGR1cmluZyBXRyBsYXN0IGNh
bGwgb3IgaXMgdGhpcyBhIGxlZnRvdmVyPw0KPj4gDQo+PiBUaGlzIHdpbGwgYmUgcmVzb2x2ZWQg
aW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgbW9kdWxlLiBJdCBpcw0KPj4gZG9jdW1lbnRlZCB1
bmRlciBJc3N1ZXMgdGFiIGluIEdpdEh1Yi4gU2hvdWxkIHdlIHJlbW92ZSBpdCBmcm9tDQo+PiB0
aGUgZHJhZnQ/DQo+IA0KPiBNb3N0IG9mIEp1ZXJnZW4ncyBjb21tZW50cyBhcmUgZWRpdG9yaWFs
IGluIG5hdHVyZSBhbmQgY2FuIHRydWx5IGJlIGhhbmRsZWQgYXMgcGFydCBvZiB0aGUgTEMgcHJv
Y2VzcywgYnV0IHRoaXMgb3BlbiBpc3N1ZSBoYXMgbWUgd29ycmllZCwgYXMgaXQgbWF5IHJlc3Vs
dCBpbiBhIHNpZ25pZmljYW50IHRlY2huaWNhbCBjaGFuZ2UuICANCj4gDQo+IFdoYXQgd2lsbCBp
dCB0YWtlIHRvIGNsb3NlIHRoaXMgb3BlbiBpc3N1ZT8gIElzIGl0IGp1c3QgYSBtYXR0ZXIgb2Yg
dGhlIGdldHRpbmcgdGhlIFdHIHRvIGFncmVlIHRoYXQgaXQncyBub3QgYW4gaXNzdWUsIG9yIGRv
IHdlIGFscmVhZHkga25vdyB0aGF0IGl0IGlzIGEgcmVhbCBpc3N1ZSBhbmQgb25seSB0aGUgc29s
dXRpb24gaXMgcGVuZGluZz8NCj4gDQo+IFRoYW5rcywNCj4gS2VudA0KPiANCj4gDQo+IA0KPiAN
Cg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCg0KDQoNCg==


From nobody Sat Jan 20 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 1D028126D73 for ; Sat, 20 Jan 2018 07:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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] 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 AQfrD-cbcRId for ; Sat, 20 Jan 2018 07:38:57 -0800 (PST)
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 4FD3B126CE8 for ; Sat, 20 Jan 2018 07:38:57 -0800 (PST)
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 w0KFcv6Z028256; Sat, 20 Jan 2018 07:38:57 -0800
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=9CGm4zgNW1VFgMYocb5hazBys2QmlvTB85FBlbGjbMk=; b=mjGZJP/hn1XONR/Rsu8LLe3EDMI5xei0y18oetSMLGIiEq1WE8UQQTLYhEVRawW3b51F 58aEOHo+rTuTXBhSJjd1WhpLyVXSjYp3GpVg6O1Er7OWI0/wQ20FFIoWrwStrj2rDzHr 6FvTuHez2DlZwOevrwWu821zDF/cveBg298qm0bZkJ6V+r+eG00lGCEwwMSCJ4Igq/c/ yyIXfOmfFwjiRO7eYGmXfg4mLtxDC6owQbx6XvYiD08FjLqzeUY2jndJWozvq/7ILbdS K0pGviNQ/kQOOSl8x0K3bFRukGe+fl8UDKWLQpRzCOJ2RQK7omttZ6a/qZOnQkyebkuN /Q== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0021.outbound.protection.outlook.com [216.32.180.21]) by mx0a-00273201.pphosted.com with ESMTP id 2fm7qp82e5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 20 Jan 2018 07:38:56 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2969.namprd05.prod.outlook.com (10.168.176.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Sat, 20 Jan 2018 15:38:55 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 15:38:55 +0000
From: Kent Watsen 
To: Andy Bierman 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis shepherd writeup issues
Thread-Index: AQHTjk5PObzC4gOr+kyp3emJqB/ObaN6NemAgAJjOQA=
Date: Sat, 20 Jan 2018 15:38:55 +0000
Message-ID: 
References: <12F22078-737E-435B-BB3D-08DE1020280D@juniper.net> 
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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2969; 7:b37olVra0IoHkq6QbcsRGkij3C4BHy/eA+5wcbop1GdBupf1X0KoVzo0+sJjRyPUEQjwsPXx7Ybmax54qXVYQ4t46jU8tOsHYCvQD8ySyLced8iYCy7z3fO9RUJlVmaZSeQux6f9c27gNyugqkljF53FPVMDjqPjGjt++ISOpKAQIqrK0ti/NePosVMOO2UZnI/gbHpW3wXGh4G1+d5sHACyHYVW1z/KUqwNDAL//v+6194iLjM3okqIdPETbuvp
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8450f299-2ca8-4d2e-f0b9-08d5601bea2d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2969; 
x-ms-traffictypediagnostic: DM5PR05MB2969:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(192374486261705)(138986009662008)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB2969; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB2969; 
x-forefront-prvs: 0558D3C5AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(346002)(39380400002)(189003)(76104003)(51444003)(199004)(2950100002)(6916009)(82746002)(83506002)(53546011)(3660700001)(6506007)(6486002)(33656002)(2906002)(59450400001)(2900100001)(5660300001)(106356001)(105586002)(229853002)(102836004)(76176011)(6436002)(3280700002)(26005)(81166006)(81156014)(8676002)(66066001)(83716003)(8936002)(77096007)(316002)(86362001)(7736002)(606006)(68736007)(14454004)(58126008)(53936002)(4326008)(6116002)(99286004)(36756003)(25786009)(478600001)(97736004)(6306002)(54896002)(236005)(6512007)(3846002)(6246003)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2969; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Ikj7rjZOs7FWP0W0N1Q166c6riikK+lRH6037yDdOpwzE14OIzv17yXLLqSI8vHIaXPM4GtaWWX4cUgjXwgXWQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F32F96B4611A496C82D95F65B3DC1808junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8450f299-2ca8-4d2e-f0b9-08d5601bea2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 15:38:55.1274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2969
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-20_06:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801200229
Archived-At: 
Subject: Re: [netmod] rfc6087bis shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 15:39:00 -0000

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

VGhhbmsgeW91LCBBbmR5LiAgQWxsIGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkLg0KSSdsbCBz
dWJtaXQgdGhlIHNoZXBoZXJkIHdyaXRldXAgc2hvcnRseS4NCg0KS2VudCAvLyBzaGVwaGVyZA0K
DQoNCk9uIDEvMTgvMTgsIDU6MTEgUE0sICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5j
b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSSBwb3N0ZWQg
ZHJhZnQtMTYgd2hpY2ggaGFzIGFsbCBjaGFuZ2VzIGJlbG93IGV4Y2VwdCB0aGUgdW51c2VkIHJl
ZmVyZW5jZSBmb3IgUkZDIDUzNzguDQpUaGUgaWRuaXRzIHRvb2wgaXMgd3JvbmcuIEl0IGlnbm9y
ZXMgdXNhZ2UgaW4gYW4gYXBwZW5kaXguDQoNCkFuZHkNCg0KDQpPbiBNb24sIEphbiAxNSwgMjAx
OCBhdCAyOjE1IFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dh
dHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KSGkgQW5keSwNCg0KDQoxKSBiZWZvcmUgSSBmb3Jn
ZXQsIGNvdWxkIHlvdSBwbGVhc2UgY29uZmlybSBvbmUgbW9yZSB0aW1lICh0aGUgbGFzdCB0aW1l
IGJlaW5nIGluIDIwMTYsIHNoZWVzaCEpIHRoYXQgeW91IGFyZSB1bmF3YXJlIG9mIGFueSBJUFIg
dGhhdCBuZWVkcyB0byBiZSBmaWxlZCBmb3IgdGhpcyBkcmFmdCwgYWNjb3JkaW5nIHRvIEJDUHMg
NzggYW5kIDc5Pw0KDQoNCg0KMikgSWRuaXRzIGZvdW5kIHRocmVlIHdhcm5pbmdzLCBvbmx5IHRo
ZSBmaXJzdCBtaWdodCByZXF1aXJlIHRob3VnaHQgZm9yIGhvdyBiZXN0IHRvIGZpeCBpdDoNCg0K
ICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNTM3OCcgaXMgZGVmaW5lZCBvbiBsaW5lIDI1MDIs
IGJ1dCBubyBleHBsaWNpdA0KICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQoN
CiAgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNpb24gKC0xMCkgZXhpc3RzIG9m
DQogICAgIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wNw0KDQogID09IE91
dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMDQpIGV4aXN0cyBvZg0KICAgICBk
cmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDINCg0KDQoNCjMpIGluIHRoZSBJ
bnRyb2R1Y3Rpb24sIHdvdWxkIHRoaXMgYmUgYmV0dGVyPw0KIE9MRA0KICAgVGhlIHN0YW5kYXJk
aXphdGlvbiBvZiBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gaW50ZXJmYWNlcyBmb3IgdXNlIHdpdGgN
CiAgICoqKnRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgW1JGQzYyNDFdIGFuZCBS
RVNUQ09ORiBbUkZDODA0MF0qKioNCiAgIHJlcXVpcmVzIGEgbW9kdWxhciBzZXQgb2YgZGF0YSBt
b2RlbHMsIHdoaWNoIGNhbiBiZSByZXVzZWQgYW5kDQogICBleHRlbmRlZCBvdmVyIHRpbWUuDQog
TkVXDQogICBUaGUgc3RhbmRhcmRpemF0aW9uIG9mIG5ldHdvcmsgY29uZmlndXJhdGlvbiBpbnRl
cmZhY2VzIGZvciB1c2Ugd2l0aA0KICAgbmV0d29yayBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQg
cHJvdG9jb2xzLCBzdWNoIGFzIE5FVENPTkYgW1JGQzYyNDFdDQogICBhbmQgUkVTVENPTkYgW1JG
QzgwNDBdLCByZXF1aXJlcyBhIG1vZHVsYXIgc2V0IG9mIGRhdGEgbW9kZWxzLCB3aGljaA0KICAg
Y2FuIGJlIHJldXNlZCBhbmQgZXh0ZW5kZWQgb3ZlciB0aW1lLg0KDQoNCjQpIEluIHRoZSBuZXh0
IHBhcmFncmFwaCwgc2hvdWxkICJzZXJ2ZXIiIGJlIHF1YWxpZmllZD8NCiAgIEEgKk5FVENPTkYg
b3IgUkVTVENPTkYqIHNlcnZlciB0aGF0IHN1cHBvcnRzDQogICBhIHBhcnRpY3VsYXIgWUFORyBt
b2R1bGUgd2lsbCBzdXBwb3J0IGNsaWVudCBORVRDT05GIGFuZC9vciBSRVNUQ09ORg0KICAgb3Bl
cmF0aW9uIHJlcXVlc3RzLCBhcyBpbmRpY2F0ZWQgYnkgdGhlIHNwZWNpZmljIGNvbnRlbnQgZGVm
aW5lZCBpbg0KICAgdGhlIFlBTkcgbW9kdWxlLg0KDQoNCjUpIFRoZSBuZXh0IHBhcmFncmFwaCBp
cyBubyBsb25nZXIgYWNjdXJhdGUgYW5kLCBnaXZlbiBpdHMgdmFsdWUgaXMgdW5sZXNzLCBtYXli
ZSBpdCBzaG91bGQgYmUgcmVtb3ZlZCBhbHRvZ2V0aGVyPw0KIE9MRA0KICAgVGhpcyBkb2N1bWVu
dCBpcyBzaW1pbGFyIHRvIHRoZSBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbg0K
ICAgdmVyc2lvbiAyIChTTUl2MikgdXNhZ2UgZ3VpZGVsaW5lcyBzcGVjaWZpY2F0aW9uIFtSRkM0
MTgxXSBpbiBpbnRlbnQNCiAgIGFuZCBzdHJ1Y3R1cmUuICBIb3dldmVyLCBzaW5jZSB0aGF0IGRv
Y3VtZW50IHdhcyB3cml0dGVuIGEgZGVjYWRlDQogICBhZnRlciBTTUl2MiBtb2R1bGVzIGhhZCBi
ZWVuIGluIHVzZSwgaXQgd2FzIHB1Ymxpc2hlZCBhcyBhICdCZXN0DQogICBDdXJyZW50IFByYWN0
aWNlJyAoQkNQKS4gIFRoaXMgZG9jdW1lbnQgaXMgbm90IGEgQkNQLCBidXQgcmF0aGVyIGFuDQog
ICBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSwgaW50ZW5kZWQgdG8gcHJvbW90ZSBjb25zaXN0ZW5j
eSBpbiBkb2N1bWVudHMNCiAgIGNvbnRhaW5pbmcgWUFORyBtb2R1bGVzLg0KDQoNCjYpIEluIHRo
ZSBuZXh0IHBhcmFncmFwaCwgc29tZXRoaW5nIHNlZW1zIG9mZiB3aXRoIHRoZSAibWF5IHJlcXVp
cmUiIGxhbmd1YWdlLiAgU2hvdWxkIGl0IGJlIGp1c3QgInJlcXVpcmVzIiBvciBwZXJoYXBzICJl
bnRhaWxzIj8gICBBbHNvLCBpcyBpdCByZWFsbHkgdG8gIm1heGltaXplIGludGVyb3BlcmFiaWxp
dHkgb2YgTkVUQ09ORiBhbmQgUkVTVENPTkYgaW1wbGVtZW50YXRpb25zIiwgb3IgbW9yZSBqdXN0
IHRvIG1ha2UgWUFORyBtb2R1bGVzIG1vcmUgdXNlZnVsPw0KIE9MRA0KICAgTWFueSBZQU5HIGNv
bnN0cnVjdHMgYXJlIGRlZmluZWQgYXMgb3B0aW9uYWwgdG8gdXNlLCBzdWNoIGFzIHRoZQ0KICAg
ZGVzY3JpcHRpb24gc3RhdGVtZW50LiAgSG93ZXZlciwgaW4gb3JkZXIgdG8gKioqbWF4aW1pemUN
CiAgIGludGVyb3BlcmFiaWxpdHkgb2YgTkVUQ09ORiBhbmQgUkVTVENPTkYgaW1wbGVtZW50YXRp
b25zIHV0aWxpemluZw0KICAgWUFORyBkYXRhIG1vZGVscyoqKiwgaXQgaXMgZGVzaXJhYmxlIHRv
IGRlZmluZSBhIHNldCBvZiB1c2FnZSBndWlkZWxpbmVzDQogICB0aGF0ICoqKm1heSByZXF1aXJl
KioqIGEgaGlnaGVyIGxldmVsIG9mIGNvbXBsaWFuY2UgdGhhbiB0aGUgbWluaW11bSBsZXZlbA0K
ICAgZGVmaW5lZCBpbiB0aGUgWUFORyBzcGVjaWZpY2F0aW9uLg0KDQoNCjcpIEluIHRoZSBUZXJt
aW5vbG9neSBTZWN0aW9uLCBwbGVhc2UgYWRkIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMg
ODE3NCwgU2VjdGlvbiAyLiAgVGhlIGV4cGVjdGVkIHJlc3VsdCBmb2xsb3dzOg0KICAgICAgVGhl
IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM
TA0KICAgICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5P
VCBSRUNPTU1FTkRFRCIsDQogICAgICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1
bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMNCiAgICAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQg
W1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5DQogICAgICBhcHBl
YXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLg0KDQoNCjgpIFNob3VsZCB0aGUgcmVm
ZXJlbmNlIHRvIFJGQyA2OTkxIGJlIGluZm9ybWF0aXZlIGluc3RlYWQ/DQoNCg0KOSkgVGhlIHJl
ZmVyZW5jZSB0byB0aGUgdHJlZS1kaWFncmFtcyBkcmFmdCBiZWluZyBpbmZvcm1hdGl2ZSBjYXVn
aHQgbXkgZXllLiBMb29raW5nIGludG8gaXQgcmV2ZWFsZWQgbW9yZToNCjlhKSBJIHRoaW5rIHRo
YXQgU2VjdGlvbiAyLjUuMSBzaG91bGQgYmUgZGVsZXRlZCwgYXMgdGhlIGRyYWZ0IGl0c2VsZiBk
b2VzIG5vdCBkZWZpbmUgYW55IHRyZWUgZGlhZ3JhbXMgb3V0c2lkZSBvZiBzZWN0aW9ucyAzLjQs
IHdoaWNoIGFscmVhZHkgaGFzIGEgcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQgKGFzIGl0IHNob3Vs
ZCkuDQo5Yikgc2hvdWxkIHRoZSBndWlkZWxpbmVzIG1ha2UgdGhlIFNlY3Rpb24gMy4zIHJlY29t
bWVuZGF0aW9uIGFueW1vcmU/ICAtIEkgdGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgbWFpbiBiZW5l
Zml0cyBvZiBoYXZpbmcgdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQgd2FzIHNvIHRoYXQgb3RoZXIg
ZHJhZnRzIGNvdWxkIGVhc2lseSBpbmxpbmUtcmVmZXJlbmNlIGl0LCBzbyBhcyB0byBhdm9pZCBu
ZWVkaW5nIHRvIHNheSBhbnl0aGluZyBpbiB0aGVpciBUZXJtaW5vbG9neSBzZWN0aW9ucy4NCjlj
KSBJIHRoaW5rIFNlY3Rpb24gMy40IHNob3VsZCAxKSBzYXkgdGhhdCBkcmFmdHMgc2hvdWxkIHBy
ZWZpeCBlYWNoIHRyZWUtZGlhZ3JhbSB3aXRoIGEgKm5vcm1hdGl2ZSogcmVmZXJlbmNlIHRvIHRo
ZSB0cmVlLWRpYWdyYW1zIGRyYWZ0IGFuZCAyKSB1cGRhdGUgdGhlIGV4YW1wbGUgaWxsdXN0cmF0
aW5nIGhvdyBpdCBtaWdodCBiZSBkb25lLg0KOWQpIEZpbmFsbHksIGJhY2sgdG8gdGhlIHRyZWUt
ZGlhZ3JhbXMgZHJhZnQgYmVpbmcgaW5mb3JtYXRpdmUsIHllcywgSSBndWVzcyBpdCBpcyBpbmZv
cm1hdGl2ZSBhZnRlciBhbGwuICBjJ2VzdCBsYSB2aWUgIDspDQoNCg0KMTApIFNob3VsZCBTZWN0
aW9uIDggKENoYW5nZXMgdG8gUkZDIDYwODcpIGJlIG1vdmVkIHRvIHRoZSBJbnRyb2R1Y3Rpb24/
ICBOb3RlIHRoYXQgdGhlIHNoZXBoZXJkIGNoZWNrbGlzdCBzYXlzICJJZiBwdWJsaWNhdGlvbiBv
ZiB0aGlzIGRvY3VtZW50IGNoYW5nZXMgdGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcgUkZDcywg
YXJlIHRob3NlIFJGQ3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgYW5kIGFyZSB0
aGUgY2hhbmdlcyBsaXN0ZWQgaW4gdGhlIGFic3RyYWN0IGFuZCBkaXNjdXNzZWQgKGV4cGxhaW5l
ZCwgbm90IGp1c3QgbWVudGlvbmVkKSBpbiB0aGUgaW50cm9kdWN0aW9uPyINCg0KDQoxMSkgSSB0
aGluayB0aGF0IFNlY3Rpb24gNiAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpIHNob3VsZCBiZSBs
YXJnZWx5IG1vdmVkIGludG8gU2VjdGlvbiAzLjcuICBGb3IgdGhpcyBkb2N1bWVudCwgU2VjdGlv
biA2IHNob3VsZCBwcm9iYWJseSBqdXN0IHNheSBzb21ldGhpbmcgbGlrZSAiVGhpcyBkb2N1bWVu
dCBvbmx5IGRlZmluZXMgZ3VpZGVsaW5lcyBmb3IgWUFORyBtb2R1bGUgZGVzaWduZXJzIGFuZCB0
aGVyZWZvcmUgZG9lcyBub3QgaXRzZWxmIGhhdmUgYW55IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25z
IHRoYXQgbmVlZCB0byBiZSBsaXN0ZWQgaGVyZS4iICBXaGF0IGRvIHlvdSB0aGluaz8NCg0KDQpU
aGFua3MsDQpLZW50ICAvLyBzaGVwaGVyZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2Q8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed01G
YVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4
bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXNLc3dkTHJ2c2FSOHp5aWY5
ZHpwVVQ5d2EwRGwxa2Vfck5JYmE5a1Z5Zkkmcz13NU0tTkN5dEVXbkNXbV9Hb05TbTFkTDBVUHdm
LXdwYkt6ZjRaWm1DV2pJJmU9Pg0KDQo=

--_000_F32F96B4611A496C82D95F65B3DC1808junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <1574FB8DFFB39A4299DC4590D10C8284@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
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rIHlv
dSwgQW5keS4mbmJzcDsgQWxsIGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5JJ2xsIHN1Ym1pdCB0aGUgc2hlcGhlcmQgd3JpdGV1cCBzaG9ydGx5LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudCAvLyBzaGVw
aGVyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAxLzE4LzE4LCA1OjExIFBNLCAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0Ozxh
IGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgcG9zdGVkIGRyYWZ0LTE2IHdoaWNoIGhhcyBhbGwgY2hhbmdlcyBiZWxvdyBl
eGNlcHQgdGhlIHVudXNlZCByZWZlcmVuY2UgZm9yIFJGQyA1Mzc4LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlkbml0cyB0b29sIGlzIHdy
b25nLiBJdCBpZ25vcmVzIHVzYWdlIGluIGFuIGFwcGVuZGl4LjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEphbiAxNSwgMjAxOCBhdCAyOjE1IFBNLCBL
ZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRhcmdl
dD0iX2JsYW5rIj5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQW5keSw8YnI+DQo8YnI+
DQo8YnI+DQoxKSBiZWZvcmUgSSBmb3JnZXQsIGNvdWxkIHlvdSBwbGVhc2UgY29uZmlybSBvbmUg
bW9yZSB0aW1lICh0aGUgbGFzdCB0aW1lIGJlaW5nIGluIDIwMTYsIHNoZWVzaCEpIHRoYXQgeW91
IGFyZSB1bmF3YXJlIG9mIGFueSBJUFIgdGhhdCBuZWVkcyB0byBiZSBmaWxlZCBmb3IgdGhpcyBk
cmFmdCwgYWNjb3JkaW5nIHRvIEJDUHMgNzggYW5kIDc5Pzxicj4NCjxicj4NCjxicj4NCjxicj4N
CjIpIElkbml0cyBmb3VuZCB0aHJlZSB3YXJuaW5ncywgb25seSB0aGUgZmlyc3QgbWlnaHQgcmVx
dWlyZSB0aG91Z2h0IGZvciBob3cgYmVzdCB0byBmaXggaXQ6PGJyPg0KPGJyPg0KJm5ic3A7ID09
IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM1Mzc4JyBpcyBkZWZpbmVkIG9uIGxpbmUgMjUwMiwgYnV0
IG5vIGV4cGxpY2l0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWZlcmVuY2Ugd2FzIGZvdW5k
IGluIHRoZSB0ZXh0PGJyPg0KPGJyPg0KJm5ic3A7ID09IE91dGRhdGVkIHJlZmVyZW5jZTogQSBs
YXRlciB2ZXJzaW9uICgtMTApIGV4aXN0cyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJh
ZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTA3PGJyPg0KPGJyPg0KJm5ic3A7ID09
IE91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMDQpIGV4aXN0cyBvZjxicj4N
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1z
LTAyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KMykgaW4gdGhlIEludHJvZHVjdGlvbiwgd291bGQg
dGhpcyBiZSBiZXR0ZXI/PGJyPg0KJm5ic3A7T0xEPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBzdGFu
ZGFyZGl6YXRpb24gb2YgbmV0d29yayBjb25maWd1cmF0aW9uIGludGVyZmFjZXMgZm9yIHVzZSB3
aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyoqKnRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9j
b2wgW1JGQzYyNDFdIGFuZCBSRVNUQ09ORiBbUkZDODA0MF0qKio8YnI+DQombmJzcDsgJm5ic3A7
cmVxdWlyZXMgYSBtb2R1bGFyIHNldCBvZiBkYXRhIG1vZGVscywgd2hpY2ggY2FuIGJlIHJldXNl
ZCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ZXh0ZW5kZWQgb3ZlciB0aW1lLjxicj4NCiZuYnNwO05F
Vzxicj4NCiZuYnNwOyAmbmJzcDtUaGUgc3RhbmRhcmRpemF0aW9uIG9mIG5ldHdvcmsgY29uZmln
dXJhdGlvbiBpbnRlcmZhY2VzIGZvciB1c2Ugd2l0aDxicj4NCiZuYnNwOyAmbmJzcDtuZXR3b3Jr
IGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBwcm90b2NvbHMsIHN1Y2ggYXMgTkVUQ09ORiBbUkZD
NjI0MV08YnI+DQombmJzcDsgJm5ic3A7YW5kIFJFU1RDT05GIFtSRkM4MDQwXSwgcmVxdWlyZXMg
YSBtb2R1bGFyIHNldCBvZiBkYXRhIG1vZGVscywgd2hpY2g8YnI+DQombmJzcDsgJm5ic3A7Y2Fu
IGJlIHJldXNlZCBhbmQgZXh0ZW5kZWQgb3ZlciB0aW1lLjxicj4NCjxicj4NCjxicj4NCjQpIElu
IHRoZSBuZXh0IHBhcmFncmFwaCwgc2hvdWxkICZxdW90O3NlcnZlciZxdW90OyBiZSBxdWFsaWZp
ZWQ/PGJyPg0KJm5ic3A7ICZuYnNwO0EgKk5FVENPTkYgb3IgUkVTVENPTkYqIHNlcnZlciB0aGF0
IHN1cHBvcnRzPGJyPg0KJm5ic3A7ICZuYnNwO2EgcGFydGljdWxhciBZQU5HIG1vZHVsZSB3aWxs
IHN1cHBvcnQgY2xpZW50IE5FVENPTkYgYW5kL29yIFJFU1RDT05GPGJyPg0KJm5ic3A7ICZuYnNw
O29wZXJhdGlvbiByZXF1ZXN0cywgYXMgaW5kaWNhdGVkIGJ5IHRoZSBzcGVjaWZpYyBjb250ZW50
IGRlZmluZWQgaW48YnI+DQombmJzcDsgJm5ic3A7dGhlIFlBTkcgbW9kdWxlLjxicj4NCjxicj4N
Cjxicj4NCjUpIFRoZSBuZXh0IHBhcmFncmFwaCBpcyBubyBsb25nZXIgYWNjdXJhdGUgYW5kLCBn
aXZlbiBpdHMgdmFsdWUgaXMgdW5sZXNzLCBtYXliZSBpdCBzaG91bGQgYmUgcmVtb3ZlZCBhbHRv
Z2V0aGVyPzxicj4NCiZuYnNwO09MRDxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGlz
IHNpbWlsYXIgdG8gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IEluZm9ybWF0aW9uPGJyPg0K
Jm5ic3A7ICZuYnNwO3ZlcnNpb24gMiAoU01JdjIpIHVzYWdlIGd1aWRlbGluZXMgc3BlY2lmaWNh
dGlvbiBbUkZDNDE4MV0gaW4gaW50ZW50PGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBzdHJ1Y3R1cmUu
Jm5ic3A7IEhvd2V2ZXIsIHNpbmNlIHRoYXQgZG9jdW1lbnQgd2FzIHdyaXR0ZW4gYSBkZWNhZGU8
YnI+DQombmJzcDsgJm5ic3A7YWZ0ZXIgU01JdjIgbW9kdWxlcyBoYWQgYmVlbiBpbiB1c2UsIGl0
IHdhcyBwdWJsaXNoZWQgYXMgYSAnQmVzdDxicj4NCiZuYnNwOyAmbmJzcDtDdXJyZW50IFByYWN0
aWNlJyAoQkNQKS4mbmJzcDsgVGhpcyBkb2N1bWVudCBpcyBub3QgYSBCQ1AsIGJ1dCByYXRoZXIg
YW48YnI+DQombmJzcDsgJm5ic3A7aW5mb3JtYXRpb25hbCByZWZlcmVuY2UsIGludGVuZGVkIHRv
IHByb21vdGUgY29uc2lzdGVuY3kgaW4gZG9jdW1lbnRzPGJyPg0KJm5ic3A7ICZuYnNwO2NvbnRh
aW5pbmcgWUFORyBtb2R1bGVzLjxicj4NCjxicj4NCjxicj4NCjYpIEluIHRoZSBuZXh0IHBhcmFn
cmFwaCwgc29tZXRoaW5nIHNlZW1zIG9mZiB3aXRoIHRoZSAmcXVvdDttYXkgcmVxdWlyZSZxdW90
OyBsYW5ndWFnZS4mbmJzcDsgU2hvdWxkIGl0IGJlIGp1c3QgJnF1b3Q7cmVxdWlyZXMmcXVvdDsg
b3IgcGVyaGFwcyAmcXVvdDtlbnRhaWxzJnF1b3Q7PyZuYnNwOyAmbmJzcDtBbHNvLCBpcyBpdCBy
ZWFsbHkgdG8gJnF1b3Q7bWF4aW1pemUgaW50ZXJvcGVyYWJpbGl0eSBvZiBORVRDT05GIGFuZCBS
RVNUQ09ORiBpbXBsZW1lbnRhdGlvbnMmcXVvdDssIG9yIG1vcmUganVzdCB0byBtYWtlIFlBTkcg
bW9kdWxlcw0KIG1vcmUgdXNlZnVsPzxicj4NCiZuYnNwO09MRDxicj4NCiZuYnNwOyAmbmJzcDtN
YW55IFlBTkcgY29uc3RydWN0cyBhcmUgZGVmaW5lZCBhcyBvcHRpb25hbCB0byB1c2UsIHN1Y2gg
YXMgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9uIHN0YXRlbWVudC4mbmJzcDsgSG93
ZXZlciwgaW4gb3JkZXIgdG8gKioqbWF4aW1pemU8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJvcGVy
YWJpbGl0eSBvZiBORVRDT05GIGFuZCBSRVNUQ09ORiBpbXBsZW1lbnRhdGlvbnMgdXRpbGl6aW5n
PGJyPg0KJm5ic3A7ICZuYnNwO1lBTkcgZGF0YSBtb2RlbHMqKiosIGl0IGlzIGRlc2lyYWJsZSB0
byBkZWZpbmUgYSBzZXQgb2YgdXNhZ2UgZ3VpZGVsaW5lczxicj4NCiZuYnNwOyAmbmJzcDt0aGF0
ICoqKm1heSByZXF1aXJlKioqIGEgaGlnaGVyIGxldmVsIG9mIGNvbXBsaWFuY2UgdGhhbiB0aGUg
bWluaW11bSBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDtkZWZpbmVkIGluIHRoZSBZQU5HIHNwZWNp
ZmljYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KNykgSW4gdGhlIFRlcm1pbm9sb2d5IFNlY3Rpb24s
IHBsZWFzZSBhZGQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyA4MTc0LCBTZWN0aW9uIDIu
Jm5ic3A7IFRoZSBleHBlY3RlZCByZXN1bHQgZm9sbG93czo8YnI+DQombmJzcDsgJm5ic3A7ICZu
YnNwOyBUaGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7
LCAmcXVvdDtSRVFVSVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgTk9UJnF1b3Q7LCAmcXVvdDtTSE9VTEQmcXVvdDssICZx
dW90O1NIT1VMRCBOT1QmcXVvdDssICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LCAmcXVvdDtOT1Qg
UkVDT01NRU5ERUQmcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7TUFZJnF1
b3Q7LCBhbmQgJnF1b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUg
aW50ZXJwcmV0ZWQgYXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmliZWQgaW4gQkNQ
IDE0IFtSRkMyMTE5XSBbUkZDODE3NF0gd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleTxicj4NCiZu
YnNwOyAmbmJzcDsgJm5ic3A7IGFwcGVhciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUu
PGJyPg0KPGJyPg0KPGJyPg0KOCkgU2hvdWxkIHRoZSByZWZlcmVuY2UgdG8gUkZDIDY5OTEgYmUg
aW5mb3JtYXRpdmUgaW5zdGVhZD88YnI+DQo8YnI+DQo8YnI+DQo5KSBUaGUgcmVmZXJlbmNlIHRv
IHRoZSB0cmVlLWRpYWdyYW1zIGRyYWZ0IGJlaW5nIGluZm9ybWF0aXZlIGNhdWdodCBteSBleWUu
IExvb2tpbmcgaW50byBpdCByZXZlYWxlZCBtb3JlOjxicj4NCjlhKSBJIHRoaW5rIHRoYXQgU2Vj
dGlvbiAyLjUuMSBzaG91bGQgYmUgZGVsZXRlZCwgYXMgdGhlIGRyYWZ0IGl0c2VsZiBkb2VzIG5v
dCBkZWZpbmUgYW55IHRyZWUgZGlhZ3JhbXMgb3V0c2lkZSBvZiBzZWN0aW9ucyAzLjQsIHdoaWNo
IGFscmVhZHkgaGFzIGEgcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQgKGFzIGl0IHNob3VsZCkuPGJy
Pg0KOWIpIHNob3VsZCB0aGUgZ3VpZGVsaW5lcyBtYWtlIHRoZSBTZWN0aW9uIDMuMyByZWNvbW1l
bmRhdGlvbiBhbnltb3JlPyZuYnNwOyAtIEkgdGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgbWFpbiBi
ZW5lZml0cyBvZiBoYXZpbmcgdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQgd2FzIHNvIHRoYXQgb3Ro
ZXIgZHJhZnRzIGNvdWxkIGVhc2lseSBpbmxpbmUtcmVmZXJlbmNlIGl0LCBzbyBhcyB0byBhdm9p
ZCBuZWVkaW5nIHRvIHNheSBhbnl0aGluZyBpbiB0aGVpciBUZXJtaW5vbG9neQ0KIHNlY3Rpb25z
Ljxicj4NCjljKSBJIHRoaW5rIFNlY3Rpb24gMy40IHNob3VsZCAxKSBzYXkgdGhhdCBkcmFmdHMg
c2hvdWxkIHByZWZpeCBlYWNoIHRyZWUtZGlhZ3JhbSB3aXRoIGEgKm5vcm1hdGl2ZSogcmVmZXJl
bmNlIHRvIHRoZSB0cmVlLWRpYWdyYW1zIGRyYWZ0IGFuZCAyKSB1cGRhdGUgdGhlIGV4YW1wbGUg
aWxsdXN0cmF0aW5nIGhvdyBpdCBtaWdodCBiZSBkb25lLjxicj4NCjlkKSBGaW5hbGx5LCBiYWNr
IHRvIHRoZSB0cmVlLWRpYWdyYW1zIGRyYWZ0IGJlaW5nIGluZm9ybWF0aXZlLCB5ZXMsIEkgZ3Vl
c3MgaXQgaXMgaW5mb3JtYXRpdmUgYWZ0ZXIgYWxsLiZuYnNwOyBjJ2VzdCBsYSB2aWUmbmJzcDsg
Oyk8YnI+DQo8YnI+DQo8YnI+DQoxMCkgU2hvdWxkIFNlY3Rpb24gOCAoQ2hhbmdlcyB0byBSRkMg
NjA4NykgYmUgbW92ZWQgdG8gdGhlIEludHJvZHVjdGlvbj8mbmJzcDsgTm90ZSB0aGF0IHRoZSBz
aGVwaGVyZCBjaGVja2xpc3Qgc2F5cyAmcXVvdDtJZiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3Vt
ZW50IGNoYW5nZXMgdGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcgUkZDcywgYXJlIHRob3NlIFJG
Q3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgYW5kIGFyZSB0aGUgY2hhbmdlcyBs
aXN0ZWQNCiBpbiB0aGUgYWJzdHJhY3QgYW5kIGRpc2N1c3NlZCAoZXhwbGFpbmVkLCBub3QganVz
dCBtZW50aW9uZWQpIGluIHRoZSBpbnRyb2R1Y3Rpb24/JnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0K
MTEpIEkgdGhpbmsgdGhhdCBTZWN0aW9uIDYgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSBzaG91
bGQgYmUgbGFyZ2VseSBtb3ZlZCBpbnRvIFNlY3Rpb24gMy43LiZuYnNwOyBGb3IgdGhpcyBkb2N1
bWVudCwgU2VjdGlvbiA2IHNob3VsZCBwcm9iYWJseSBqdXN0IHNheSBzb21ldGhpbmcgbGlrZSAm
cXVvdDtUaGlzIGRvY3VtZW50IG9ubHkgZGVmaW5lcyBndWlkZWxpbmVzIGZvciBZQU5HIG1vZHVs
ZSBkZXNpZ25lcnMgYW5kIHRoZXJlZm9yZSBkb2VzIG5vdCBpdHNlbGYNCiBoYXZlIGFueSBTZWN1
cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IG5lZWQgdG8gYmUgbGlzdGVkIGhlcmUuJnF1b3Q7Jm5i
c3A7IFdoYXQgZG8geW91IHRoaW5rPzxicj4NCjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpLZW50
Jm5ic3A7IC8vIHNoZXBoZXJkPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3
TUZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFt
cDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209c0tz
d2RMcnZzYVI4enlpZjlkenBVVDl3YTBEbDFrZV9yTkliYTlrVnlmSSZhbXA7cz13NU0tTkN5dEVX
bkNXbV9Hb05TbTFkTDBVUHdmLXdwYkt6ZjRaWm1DV2pJJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_F32F96B4611A496C82D95F65B3DC1808junipernet_--


From nobody Sat Jan 20 08:07: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 BF7C412D77A for ; Sat, 20 Jan 2018 08:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 f8GTzZN5WB-K for ; Sat, 20 Jan 2018 08:07:03 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 0E003120726 for ; Sat, 20 Jan 2018 08:07:03 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C179D1E0850 for ; Sat, 20 Jan 2018 09:07:01 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 0g6x1x01b2SSUrH01g705V; Sat, 20 Jan 2018 09:07:01 -0700
X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=YkuV9oxj9kgA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
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=ILUDtc3kgOIawejQANrnwUAivNOr50triTvPyJb3NiM=; b=t4AVS0IsceySYxa4j3sEvlGUvJ BDhVPHgpFdzcppAjLkXHlNFh3X9Nd/4/G4MDxJDsywR7LmYXXDSm4gpvc8YSuZ6h51CBw/8XslUmM xZpTWDFbE5Wk159sFRpJP35Q0;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49838 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ecvfV-003vM6-QU; Sat, 20 Jan 2018 09:06:57 -0700
To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net
Cc: NetMod WG 
From: Lou Berger 
Message-ID: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
Date: Sat, 20 Jan 2018 11:06:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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-Exim-ID: 1ecvfV-003vM6-QU
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]:49838
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 16:07:05 -0000

Authors, Contributors, WG,

As part of the preparation for WG adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



From nobody Sat Jan 20 08:09:11 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 3FF8012D77B; Sat, 20 Jan 2018 08:09:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151646454925.3102.11520910606181503399.idtracker@ietfa.amsl.com>
Date: Sat, 20 Jan 2018 08:09:09 -0800
Archived-At: 
Subject: [netmod] The NETMOD WG has placed draft-bierman-netmod-yang-data-ext in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 16:09:09 -0000

The NETMOD WG has placed draft-bierman-netmod-yang-data-ext in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-data-ext/

Comment:
IPR Poll started:
https://mailarchive.ietf.org/arch/msg/netmod/l8fHy-88SrlUSpyUNkGe-ixKSmI
Pending responses:
  Andy Bierman
  Martin Bjorklund
   Kent Watsen


From nobody Sat Jan 20 09:06:45 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 BA6D412D77B; Sat, 20 Jan 2018 09:06:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kent Watsen 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, iesg-secretary@ietf.org, kwatsen@juniper.net, netmod@ietf.org
Message-ID: <151646800475.3094.11408667855755512962.idtracker@ietfa.amsl.com>
Date: Sat, 20 Jan 2018 09:06:44 -0800
Archived-At: 
Subject: [netmod] Publication has been requested for draft-ietf-netmod-rfc6087bis-16
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 17:06:45 -0000

Kent Watsen has requested publication of draft-ietf-netmod-rfc6087bis-16 as Best Current Practice on behalf of the NETMOD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/


From nobody Sat Jan 20 10:13: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 7F690120726 for ; Sat, 20 Jan 2018 10:13:01 -0800 (PST)
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 mPeQ6VWN-t01 for ; Sat, 20 Jan 2018 10:12:59 -0800 (PST)
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 5F49312711B for ; Sat, 20 Jan 2018 10:12:57 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0KI9NRw027082; Sat, 20 Jan 2018 10:12:55 -0800
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=kagpfapbrZBT4bbqt4v86dyrfCDPc6rDHdzFBJ/8hTM=; b=ygsKO1gJArihxT+FYvoH+l2u8E2IscKedO+1qjezt4didIQtkFAhK+WUC3Y71OhUJ1+h 6Y/BcWG6xHOcsdgFLST8lJDN7XV4K+yr78V/7WX//YwbTfUwEM6RDWqM6rpdWzrp8o+b BHRasOR4IFKBe9EDEubVf3qzD2PwumWt9F+Koe935B2DPcnIwgVYbnl/vMxLg+lAdppP O6h5kaWSNqF6UdxnWl1wRFlFXM02qNj0Lxsirur8piJrXlBZNzRny7CbKI6p26S6NeEE ZboASl4b6Mxr9fjJXQkLHQLsLeDJQ3LVOBw+KjBrl1qTtLpGb3nqMb4T+A5zxRD54NU3 dA== 
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 2fma46r1cc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 20 Jan 2018 10:12:55 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3067.namprd05.prod.outlook.com (10.173.218.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Sat, 20 Jan 2018 18:12:53 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 18:12:53 +0000
From: Kent Watsen 
To: Lou Berger , "andy@yumaworks.com" ,  "mbj@tail-f.com" 
CC: NetMod WG 
Thread-Topic: Regarding IPR on draft-bierman-netmod-yang-data-ext-01
Thread-Index: AQHTkgi7OfgR37Ts7UevP+sM26PTz6N8vLCA
Date: Sat, 20 Jan 2018 18:12:53 +0000
Message-ID: <23B7F491-7898-436A-A97A-175DB396F0EF@juniper.net>
References: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
In-Reply-To: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
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; DM5PR05MB3067; 7:A6sOUd8Ag+eLfIru9fuBJ4NiRF4vGCXaTneAlxqUqTNnH7rvSVrogEqZ2dZoTWoqX/ZQYmmogvoIfumbBjBHSKOuuhuk1u4RjyhGAkNoFfmI+MYrnWWsHdZUIxS7qKSpmdruub31jFJpXu6znlhJ6cJeOWCA4roNcKL3ZPomC3s9cutu9LfcQRIfuqockBmLlOJVrrqhKKdFXqMBKw2mJG0wZmOdoylWF6VS/qIIdBShCPR+7DIcNfi2gd0N7kKu
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f8d1cea0-aa63-4b05-68d7-08d560316c8f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3067; 
x-ms-traffictypediagnostic: DM5PR05MB3067:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231046)(2400081)(944501161)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3067; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3067; 
x-forefront-prvs: 0558D3C5AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(39860400002)(366004)(189003)(199004)(2501003)(76176011)(5660300001)(25786009)(3280700002)(229853002)(6506007)(2950100002)(82746002)(33656002)(81156014)(81166006)(230783001)(83716003)(105586002)(316002)(3660700001)(66066001)(36756003)(58126008)(97736004)(8676002)(110136005)(6246003)(6486002)(575784001)(53936002)(8936002)(14454004)(305945005)(86362001)(2900100001)(6346003)(478600001)(6436002)(6116002)(3846002)(966005)(2906002)(26005)(102836004)(83506002)(99286004)(77096007)(106356001)(7736002)(6512007)(4326008)(2201001)(68736007)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3067; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: io3XSMXru9wE12pgN4JAYHO9yOAJCvI1CW5SA+0/iByWBNra0xAcBcbD9x/u7bMvnQn74yAob5QYkJC19KuUTg==
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: f8d1cea0-aa63-4b05-68d7-08d560316c8f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 18:12:53.3326 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3067
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-20_08:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801200264
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 18:13:01 -0000

Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K
DQpLZW50IC8vIGNvLWF1dGhvcg0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0K
QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24g
Zm9yIFdHIGFkb3B0aW9uOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz
IHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoi
Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCIN
Cm9yDQoiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0K
DQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ
RVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0
YWlscyk/DQoNCklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZ
ZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ
UiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYg
eW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3Ug
dGhpbmsNCmFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1
dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGlu
ZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdh
cmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv
IHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20g
ZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBU
TyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KVE8gTElORVMuDQoNCklmIHlv
dSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUg
bm90IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9m
IHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJh
Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KYXdhcmUgb2YgSVBSIG9mIG90
aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQpwYXJ0aWNp
cGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIN
CnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJG
Q3MgbGlzdGVkIGFib3ZlDQphbmQNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwLTNBX190cmFjLnRvb2xzLmlldGYub3JnX2dyb3VwX2llc2dfdHJhY193aWtp
X0ludGVsbGVjdHVhbFByb3BlcnR5JmQ9RHdJQ2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJY
ZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJ
U2xhSmRjWm8mbT1UVkhPVTdNOENVU3E1VDVacmNfNmIyUUhZTjg2REJOalhnazA4RFJ3Y2FJJnM9
dTNZNDVVXzRhbzBYWFA5Q2lPZ1pEOEVqRGxYY09vWDlGdTFyN2MzNVF2QSZlPS4NCg0KVGhhbmsg
eW91LA0KTmV0TW9kIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGlu
IHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg0KDQoNCg0K


From nobody Sat Jan 20 11:30:57 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 DDFBA124235 for ; Sat, 20 Jan 2018 11:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_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=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 l6zD76B0aSFb for ; Sat, 20 Jan 2018 11:30:53 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 653AC120726 for ; Sat, 20 Jan 2018 11:30:53 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id q194so5953976lfe.13 for ; Sat, 20 Jan 2018 11:30:53 -0800 (PST)
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=tBMHu1Hi1oMkQCr5QApopuhER5zIVQ+IYJzXUlsYCJ0=; b=jZAQtBcOKHC9ZiKzwb7PSwTzPBMAdu/TJAITXwgwaKQwxXcZO3D6/Gk9NXo8xJ1NyW y4I3FFhzfkTATI40mPAtp4IwE/tYu4TFyNdOuEzxJ3xXNSm4KDusaC3/ecB20zYGFL4t R5Oqpk1dj7MYi7f+0a0zlibyns3z2g/C9ULMjjyiwlwzIu6Ax8aUux44Osp0GFDkg/22 W+OPFp5SIuCnMDexPJlX6qIFR9eyotRyPl/JUpGh96TD3D0+u8mm1KuaoWOUKmYxVrqy 6RvMM65LwokHdMAU8LI2fJTm3LKqmIyVt0mcoJVBpZpuaWTV4fRvWmtuLViJeWXopLiL Qiag==
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=tBMHu1Hi1oMkQCr5QApopuhER5zIVQ+IYJzXUlsYCJ0=; b=Xj/Vu7Fan757dd35wF8vuYkjCbfnQi74ZwswQIOsIjP9MaoqlrG/2O7k0bnxIvOvlm iC/CJWBMUmRPHWcI4DGFkzmWIZ2jtaerI5kDD0dMhMWO/T4Hwq3HNnHtP/NvjvLTRbGA U5NGDcg0ZX2N76WoGs4dNdruppKrHty3Nl8WX7uDA3wSROUcx7b9z833F3pRSOm/8V+g CzOLceXPZ5V8yzv0/CsDY5iCSL6aEwzjYNKuwFqtdL/7QfvSHP8XZNqq3J7E/V2/E7/6 5WL5w/YDBhTZYsU3xxHfsg28XGMGJAiaJS9A3jl+LSuuTfvG8qdTrdvUaAh0plmKeAB8 POYQ==
X-Gm-Message-State: AKwxytdbpAr8dU373spYSsKyzlNBDVW+TgVPLBu8bbIyPG68jro5Jk85 f31LyoC+giQQF/CkHk8BRGACvZNG/qSylqnAAyEEi3GF
X-Google-Smtp-Source: AH8x227t7kVet1nBhd1H8iAvhFCaEIbqb6vjMBCisZKbpu4va6qJCEkKcbk1Yx0cqGC38Z2VzJIX8Z5EOq9IXjixiME=
X-Received: by 10.46.125.7 with SMTP id y7mr1327191ljc.117.1516476651490; Sat, 20 Jan 2018 11:30:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Sat, 20 Jan 2018 11:30:50 -0800 (PST)
In-Reply-To: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
References: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
From: Andy Bierman 
Date: Sat, 20 Jan 2018 11:30:50 -0800
Message-ID: 
To: Lou Berger 
Cc: Martin Bjorklund , Kent Watsen , NetMod WG 
Content-Type: multipart/alternative; boundary="f4f5e80937e01f63e705633a3cfc"
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 19:30:56 -0000

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

"No, I'm not aware of any IPR that applies to this draft"


Andy


On Sat, Jan 20, 2018 at 8:06 AM, Lou Berger  wrote:

> Authors, Contributors, WG,
>
> As part of the preparation for WG adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
>

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


"No, I'm not awa=
re of any IPR that applies to this draft"


Andy
<=
div>

On Sat, Jan 20, 2018 at 8:06 AM,=
 Lou Berger <lberger@labn.net> wrote:
Authors, Contributors, WG,



As part of the preparation for WG adoption:



Are you aware of any IPR that applies to drafts identified above?



Please state either:



"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo=
t;

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author and listed

contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<=
br>
TO LINES.



If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under

the IETF IPR rules which encourages you to notify the IETF if you are

aware of IPR of others on an IETF contribution, or to refrain from

participating in any contribution or discussion related to your

undisclosed IPR. For more information, please see the RFCs listed above

and

http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.



Thank you,

NetMod WG Chairs



PS Please include all listed in the headers of this message in your

response.









--f4f5e80937e01f63e705633a3cfc--


From nobody Sat Jan 20 14:16:47 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 5A51C1242F5 for ; Sat, 20 Jan 2018 14:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 103p63ioh1HU for ; Sat, 20 Jan 2018 14:16:44 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 4033B12421A for ; Sat, 20 Jan 2018 14:16:44 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id f4so12328291qtj.6 for ; Sat, 20 Jan 2018 14:16:44 -0800 (PST)
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=ybi1RAohSOAVOUhB6mCXR+v6Nd9Wx4SeXXUWc7cNprE=; b=ZnTLg75md0NcO5u7A3CyV4HQriLJCjYRiZaHAQNA0In7cL39RCXPOlLcinMux+P2jr 6YItKpg+i48W6ovdwp5vrcX4m4J8E4CCLmvUgFBQ8Y1i4GN8dOh3sGmAFW04kojeeepn vlV6B2Hj5zXr/bl8XkBDmqK5+Boyr416x0zY9jK+pe8bCnnwDQrEoT2uXDs/oI1syWXD iC5nDxuwIQjQyGqBQL24XnO5WmDzha1JPXoMKMpF4dpENRlboQ2PMjv+HqfTF2PHOQkU 1c3yLtrloqt/nnLiyGE8sKtuRMaRW7+DQuJJDWLoyJz2STF8gWuxXi4NUax+9kI+aX6W d9Ew==
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=ybi1RAohSOAVOUhB6mCXR+v6Nd9Wx4SeXXUWc7cNprE=; b=ffWuw+dRUTCEZTPHvAWYCm3JJP81PROMKytKWgqqagBD9U9Zb+0Fdln1elIRGn55Wv BA/1mLoIvHKJvpDWMXl6IntTJsyeYQCYpisjETmFNR0LL1sRDyCLEYKYSQBLvYaX2Avs jdx8m4Zf1lpen0geNNCDoh7dmz/29plLi6d7BqQclG6Y56JwwhzQ9xZyMmenu74rbsBe Fgi1dpiKHlKV1DwokErvzftDp4DdB8YK8bOxVEF2e5d9zJTpqrFBvLzUskfRSkL3+4q+ rmbZBmlPlifO4R4KlJfa2jOV+gOtcpkd6nNUExPlJ3voF4WiPeD1QTEj8IR0u1ozqOZ/ a1HA==
X-Gm-Message-State: AKwxytcmGjqtimHU+7Ps46aPlITcWgh7ek/0pWoCQaevC0KjADrFStv9 OL9vz0YH7Lyri67ORVgOdGw=
X-Google-Smtp-Source: AH8x2249KmquJH9k+29mE7a1reDYYFkoobDl++umqAhulMOHt6nRMMFBWqeq2Xeiok3x0dhTDGLINg==
X-Received: by 10.237.48.225 with SMTP id 88mr4493166qtf.340.1516486603437; Sat, 20 Jan 2018 14:16:43 -0800 (PST)
Received: from ?IPv6:2601:19b:880:14c8:d9c8:8954:e35f:50fd? ([2601:19b:880:14c8:d9c8:8954:e35f:50fd]) by smtp.gmail.com with ESMTPSA id h55sm8964673qta.75.2018.01.20.14.16.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jan 2018 14:16:42 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dean Bogdanovic 
In-Reply-To: <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Date: Sat, 20 Jan 2018 17:16:40 -0500
Cc: Robert Wilton , Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 22:16:46 -0000

As Lou mentioned, schema mount can be used with or without YANG library. =
As author who uses the schema mount in a draft and in product, don=E2=80=99=
t want to hold back the publication. We, IETF, are too slow. Getting =
data model RFCs published takes too much time and we are not getting =
experience from implementation and operational usage. Things have to =
move much faster or the industry will move away from this organization. =
At the end, if we need to we can revise to support future publications.=20=


Dean

> On Jan 19, 2018, at 2:00 PM, Lou Berger  wrote:
>=20
> Rob,
>=20
>=20
> On January 19, 2018 1:05:46 PM Robert Wilton  =
wrote:
>=20
>>=20
>>=20
>> On 17/01/2018 16:40, Martin Bjorklund wrote:
>>> Ladislav Lhotka  wrote:
>>=20
>> 
>>=20
>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I =
think
>>>> I don't agree. The metadata annotation solves real issues.
>>> One issue with the annotation is that since the schema might be
>>> different in different datastores, it means that the client needs to
>>> read the annotation in all datastores, and then fetch the schemas.  =
So
>>> it is a bit more difficult to work with for a client.
>> I'm still not convinced that I really understand all the arguments =
here:
>>=20
>> Using YLbis over YL seems to have obvious benefits to me, in that I
>> perceive that it gives a cleaner data model.=20
>=20
> It is worth noting that the current scheme amount document can be used =
either with young library or Young Library BIS.
>=20
>> But I also understand
>> Lou's concerns - although its not clear to me whether Lou's primary
>> concern is timing, or the fact that implementations are forced to use =
YLbis.
>>=20
>=20
> My concern is the delay required to reach consensus  on an unspecified =
solution that has not been discussed and may contain unknown =
implications. Keep in mind that where we are today has required =
compromises. Just because we have one party that understands what they =
think they're going to write doesn't mean that there will be changes as =
details are worked out, and as consensus is obtained.
>=20
>=20
>> I also agree with Juergen that from an YLbis authors perspective =
YLbis
>> is quite close.  I believe that the YANG model itself has been agreed
>> (at the interim meeting in Nov/Dec), and hence really what is left is
>> just tidying/enhancing the descriptive text in the document.
>>=20
>> I don't really understand the benefits of the metadata annotations. =
It
>> feels like this is going to be more hassle because a client will have =
to
>> query each datastore separately rather than getting the information =
in a
>> single operation.
>>=20
>> A regular (without SM) NMDA NC/YANG server supports multiple =
datastores,
>> but that information is only exposed via one so them (i.e.
>> ).  So, in a server supporting inline SM, it seems quite
>> natural to me for the mounted schema information to also only be
>> available via the mounted .=20
>=20
> It also enables and implementation of the current SM document to =
support nmda data stores under a inline Mount point.
>=20
>> This seems to mirror the
>> standard NC/YANG+YL behavior, and also seems to naturally recurse if
>> required.
>>=20
>> Hence, for me, I see the choice as:
>> 1) do we publish the existing model now (perhaps also mark the draft =
as
>> experimental) followed by an updated draft with the NMDA compatible =
module?
>> 2) do we publish both models in a single draft (e.g. with the =
existing
>> model in an appendix)?
>> 3) do we only publish a single version of the draft with an NMDA
>> compliant solution.
>>=20
>=20
> There are certainly a few variants possible, but the fundamental =
choice is to go ahead with basically what passed last call or not.
>=20
> Lou
>=20
>> Thanks,
>> Rob
>>=20
>>=20
>>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Sat Jan 20 15:44: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 D3D49126BF0 for ; Sat, 20 Jan 2018 15:44:27 -0800 (PST)
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 Cmu7th-2eyT4 for ; Sat, 20 Jan 2018 15:44:26 -0800 (PST)
Received: from mx0b-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 48427127419 for ; Sat, 20 Jan 2018 15:44:25 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0KNi1Ea015867; Sat, 20 Jan 2018 15:44:22 -0800
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=wzWKD7jVubsy5rP2Cy9HMMZGyT7VC/jpTnX/6I6tJa4=; b=CSCdqONfovuo8wP1MVGH4Du95iY1SmQYOasSYeGExlFMnoHaB1/aZ4vOxDskpevn+2+I xw0sTRAGYjnjtpVSoKwPCwDcy1dNd3w/Yu4KBvA6QD08DzAKOxgPdrWLSEovkqBHgF1d pAk34IBLP+nBxX4AOnJh4qau54IpjN8WoGzERLpzRGOadZxGwc8viuvw8dSvO+vuI7MC iODEKoM7yat6fQ57SoXP3alv1FJ2htFgL3IjsOTYjUmmFDTN3DpZRPPeBDaG85SxPn0b FwYHQ33JparJ/1qAmxYhLEHge0axttYgzA4JQUZUf1WuLcd51zhJAJ6BdPDM+0oL16HT hg== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0086.outbound.protection.outlook.com [207.46.163.86]) by mx0a-00273201.pphosted.com with ESMTP id 2fmexyr1t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 20 Jan 2018 15:44:22 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2828.namprd05.prod.outlook.com (10.168.175.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Sat, 20 Jan 2018 23:44:20 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 23:44:20 +0000
From: Kent Watsen 
To: Dean Bogdanovic , Lou Berger 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount and YANG library
Thread-Index: AQHTcDnC+LdQVLmjCEySNKfGe/5DBKNEeVYAgAUkMwCAAKKRgIAAVj0AgAAAtoCAAAXQgIAADrKAgAADggCAAAqGAIAq80GAgACl5oCAAEeFAIAACjwAgAAFgQCAABAegIAAAXeAgAAFyICAAAmmgIAADb+AgAAFsYCAAAR+AIAABzCAgAAVSQCAAPgTAIAAY9GAgAAG7oCAABEjgIAACb2AgAAEjICAAAG0gIADPE2AgAAPkoCAAckBAP//xK0A
Date: Sat, 20 Jan 2018 23:44:20 +0000
Message-ID: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2828; 7:D+pOO8lckqKArST/arXR7b5iOmAnjN/K98xjUWfFfYD60AleNRcdywRDPpPx4sG7dokSpn92jdrqU4GJ/Ycl9Q4iiChSw3kaIg5hlIS0tGwgMSxCnEpUAqsipu565bkBLrz1Ifh/6fhGIFl5UWbyFxmef6UTJV1lgBuH40My5S5TSLNSjgFvs0JHYq/efU1OBjBENg+47gzWax9/PasA/XBOUxK33huSXfw6DA99uAxKEne0dBeIm00+4OgviYRB
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f0400c71-44ee-47d4-3d0a-08d5605fba5b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2828; 
x-ms-traffictypediagnostic: DM5PR05MB2828:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(2400081)(944501161)(3002001)(6055026)(6041288)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB2828; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB2828; 
x-forefront-prvs: 0558D3C5AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(39860400002)(376002)(366004)(199004)(189003)(82746002)(39060400002)(6436002)(6116002)(3846002)(6246003)(33656002)(53936002)(6486002)(229853002)(66066001)(76176011)(4326008)(478600001)(99286004)(6512007)(93886005)(102836004)(36756003)(25786009)(6506007)(14454004)(59450400001)(86362001)(81156014)(8676002)(81166006)(5660300001)(68736007)(2900100001)(316002)(8936002)(7736002)(58126008)(305945005)(110136005)(3280700002)(3660700001)(83716003)(2950100002)(97736004)(105586002)(106356001)(2906002)(77096007)(26005)(83506002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2828; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 26M2H+KGUX3aAAOJftSB+lSVAFZjom68QVnbZilcnQ9+/+vzevLfTj/p1nOxtBQmWLU0VO0/m9yNYssLdhfdDA==
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: f0400c71-44ee-47d4-3d0a-08d5605fba5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 23:44:20.6869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2828
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-20_08:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801200340
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Jan 2018 23:44:28 -0000

SGkgRGVhbiwNCg0KIkFzIExvdSBtZW50aW9uZWQsIHNjaGVtYSBtb3VudCBjYW4gYmUgdXNlZCB3
aXRoIG9yIHdpdGhvdXQgWUFORyBsaWJyYXJ5LiBBcyBhdXRob3Igd2hvIHVzZXMgdGhlIHNjaGVt
YSBtb3VudCBpbiBhIGRyYWZ0IGFuZCBpbiBwcm9kdWN0LCBkb27igJl0IHdhbnQgdG8gaG9sZCBi
YWNrIHRoZSBwdWJsaWNhdGlvbi4gV2UsIElFVEYsIGFyZSB0b28gc2xvdy4gR2V0dGluZyBkYXRh
IG1vZGVsIFJGQ3MgcHVibGlzaGVkIHRha2VzIHRvbyBtdWNoIHRpbWUgYW5kIHdlIGFyZSBub3Qg
Z2V0dGluZyBleHBlcmllbmNlIGZyb20gaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsIHVz
YWdlLiBUaGluZ3MgaGF2ZSB0byBtb3ZlIG11Y2ggZmFzdGVyIG9yIHRoZSBpbmR1c3RyeSB3aWxs
IG1vdmUgYXdheSBmcm9tIHRoaXMgb3JnYW5pemF0aW9uLiBBdCB0aGUgZW5kLCBpZiB3ZSBuZWVk
IHRvIHdlIGNhbiByZXZpc2UgdG8gc3VwcG9ydCBmdXR1cmUgcHVibGljYXRpb25zLiINCg0KDQpK
dXN0IGEgY2xhcmlmaWNhdGlvbiBvbiB5b3VyIGxhc3Qgc2VudGVuY2UsIG15IHVuZGVyc3RhbmRp
bmcgaXMgdGhhdCBhIHJldmlzaW9uIGlzIG5lY2Vzc2FyeSBpbiBvcmRlciBmb3Igc2NoZW1hLW1v
dW50IHRvIHdvcmsgb24gTk1EQS1iYXNlZCBzZXJ2ZXJzLiAgU2hvdWxkIHdlIHB1Ymxpc2ggdGhl
IGN1cnJlbnQgZHJhZnQgYXMgaXMgbm93LCB3ZSdyZSBlZmZlY3RpdmVseSBjb21taXR0ZWQgdG8g
cHVibGlzaGluZyBhbiBOTURBLXVwZGF0ZSBpbiB0aGUgbmVhci10ZXJtIGFueXdheXMuDQoNCktl
bnQNCg0KDQoNCg0K


From nobody Sat Jan 20 16:54: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 ACA5D126CD8 for ; Sat, 20 Jan 2018 16:54:16 -0800 (PST)
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 Rh1VhpcjsmEZ for ; Sat, 20 Jan 2018 16:54:13 -0800 (PST)
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 D42801205D3 for ; Sat, 20 Jan 2018 16:54:13 -0800 (PST)
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 w0L0sBdD005358; Sat, 20 Jan 2018 16:54:11 -0800
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=B4Z8b9tIxowUqF5aWkgTKMs4qH9kLszsusLJ38ZzoJk=; b=NR2sFpwQ6x/hFxBkExvYXa9ugv85EmV6Rt2Z4/ayxhxiYBSRtRUpNSXG/k+46eBYZux7 XArjZ0hObprlEuN23aPq6V2P6qd6kwjKiDcx+41ySe4gleguDMQPKAEhL95+BolxYHYb Nqwf3z67O8gLlVlpv1R/wgfF4K+wj4nUZAsRkBMRHxhzVg8URZ00JkzI68RuHtOajb9h s/1qdCIG2A4bAk80666ff0lYPCq+ARJ+Zg97DHqq8V4BCZ9mHCv4znvc66y+dOtE69mZ +y6Wk1pRwaBAmPKiv6Sogs8l6vD4TGZb7pEwZ9T5JUCqz+0vpOixmx1algoFmHxEo+YT mg== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) by mx0a-00273201.pphosted.com with ESMTP id 2fmg8e812b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 20 Jan 2018 16:54:11 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3276.namprd05.prod.outlook.com (10.173.220.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Sun, 21 Jan 2018 00:54:10 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.004; Sun, 21 Jan 2018 00:54:10 +0000
From: Kent Watsen 
To: Dean Bogdanovic , Lou Berger 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount and YANG library
Thread-Index: AQHTcDnC+LdQVLmjCEySNKfGe/5DBKNEeVYAgAUkMwCAAKKRgIAAVj0AgAAAtoCAAAXQgIAADrKAgAADggCAAAqGAIAq80GAgACl5oCAAEeFAIAACjwAgAAFgQCAABAegIAAAXeAgAAFyICAAAmmgIAADb+AgAAFsYCAAAR+AIAABzCAgAAVSQCAAPgTAIAAY9GAgAAG7oCAABEjgIAACb2AgAAEjICAAAG0gIADPE2AgAAPkoCAAckBAP//xK0AgAATgoA=
Date: Sun, 21 Jan 2018 00:54:10 +0000
Message-ID: <5288D137-92DB-49A8-B789-520C0152EBEE@juniper.net>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  
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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3276; 7:B07f3G/6wVvu5yX8+BJwaVaEvYOdTQNF+myukN9Cb+aDI1kHyvRiKQxE/yewvtJLLBksBbXX/YE4ASeHF2fesQen7V5lYmRhFNuwsN0uqPkHNXdtIJF5osV6A34KuXeEm910lGB/qHgb0lRtqU58eArI7bsqNhghafyX9XSPqIPq5bXNGb4qIiGQhsqrtv9dbk5+ACpfW4pK/FBAHOfYtoSR2Wd/hDlo9TbuwWuJvd8I4mat8tNuY3znjkobn1ci
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8399a715-8039-4dda-848c-08d560697b6e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3276; 
x-ms-traffictypediagnostic: DM5PR05MB3276:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231023)(2400081)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3276; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3276; 
x-forefront-prvs: 0559FB9674
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(39860400002)(346002)(396003)(189003)(199004)(6246003)(66066001)(59450400001)(76176011)(316002)(575784001)(3660700001)(86362001)(83506002)(5660300001)(97736004)(478600001)(966005)(229853002)(7736002)(305945005)(82746002)(105586002)(83716003)(102836004)(2900100001)(93886005)(3280700002)(25786009)(6506007)(81156014)(81166006)(6512007)(36756003)(6306002)(53936002)(2950100002)(99286004)(33656002)(106356001)(6436002)(8936002)(39060400002)(8676002)(14454004)(6116002)(3846002)(26005)(68736007)(77096007)(4326008)(110136005)(2906002)(58126008)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3276; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jsBmVUWwCtH5DxamzlKXT69tH6294xnArdl2EX6UVZIiqAv0lmraXjt5PQuFTgCizmmNLHOVm5D6ADfkbpFOnQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <72446AC47DD8334DB588009DA7DDB0DE@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8399a715-8039-4dda-848c-08d560697b6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2018 00:54:10.0841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3276
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-20_08:, , 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-1711220000 definitions=main-1801210010
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jan 2018 00:54:17 -0000

RGVhbiB3cml0ZXM6ICI8c25pcC8+IEF0IHRoZSBlbmQsIGlmIHdlIG5lZWQgdG8gd2UgY2FuIHJl
dmlzZSB0byBzdXBwb3J0IGZ1dHVyZSBwdWJsaWNhdGlvbnMuIg0KDQpJIHdyaXRlOiAiSnVzdCBh
IGNsYXJpZmljYXRpb24gb24geW91ciBsYXN0IHNlbnRlbmNlLCBteSB1bmRlcnN0YW5kaW5nIGlz
IHRoYXQgYSByZXZpc2lvbiBpcyBuZWNlc3NhcnkgaW4gb3JkZXIgZm9yIHNjaGVtYS1tb3VudCB0
byB3b3JrIG9uIE5NREEtYmFzZWQgc2VydmVycy4gIFNob3VsZCB3ZSBwdWJsaXNoIHRoZSBjdXJy
ZW50IGRyYWZ0IGFzIGlzIG5vdywgd2UncmUgZWZmZWN0aXZlbHkgY29tbWl0dGVkIHRvIHB1Ymxp
c2hpbmcgYW4gTk1EQS11cGRhdGUgaW4gdGhlIG5lYXItdGVybSBhbnl3YXlzLiINCg0KTG91J3Mg
Y29ycmVjdGluZyBtZSBvZmYtbGlzdC4gIEhlIHNheXMgdGhhdCBjdXJyZW50IHNvbHV0aW9uIGNh
biBiZSB1c2VkIG9uIE5NREEgc2VydmVycywgYWxiZWl0IHdpdGggdGhlIHdpdGggZGlzY2xhaW1l
ciB0aGF0IGFsbCBub24taW5saW5lIHNjaGVtYSBtdXN0IGJlIHRoZSBzYW1lIGZvciBhbGwgZGF0
YXN0b3Jlcy4gIE9rYXksIHRoaXMgbGV0cyBzb21lIHN0ZWFtIG9mZiwgbWF5YmUgd2UgZG9uJ3Qg
aGF2ZSB0byB1cGRhdGUgaXQgcmlnaHQgYXdheSwgRGVhbidzIHN0YXRlbWVudCBpcyBhY2N1cmF0
ZS4gIEJ1dCBJIGltYWdpbmUgdGhhdCB3ZSdsbCBnZXQgYXJvdW5kIHRvIGl0IHNvb25lciBvciBs
YXRlciwgc28gaXQgZG9lc24ndCBjaGFuZ2UgdGhlcmUgYmVpbmcgYW4gdXBkYXRlIGF0IHNvbWUg
cG9pbnQuICANCg0KSSB0aGluayB3aGF0IEknbSBtaXNzaW5nIGlzIGhvdyBiaWcgdXAgYW4gdXBz
ZXQgd291bGQgaXQgYmU/ICBDYW4gdGhlIGF1dGhvcnMgcGxlYXNlIHNrZXRjaCBvdXQgd2hhdCB0
aGUgTk1EQS1vcmllbnRlZCB1cGRhdGUgd291bGQgbG9vayBsaWtlPyAgV291bGQgaXQsIGZvciBp
bnN0YW5jZSwgbWFuaWZlc3QgYXMgYSByZXZpc2lvbiB0byB0aGUgZXhpc3RpbmcgbW9kdWxlIG9y
IGEgbmV3IG1vZHVsZSBhbmQsIGlmIGl0IHdlcmUgYSBuZXcgbW9kdWxlLCB3b3VsZCBpdCBiZSBw
b3NzaWJsZSBmb3IgYSBzZXJ2ZXIgdG8gaW1wbGVtZW50IGJvdGggdGhlIG9sZCBhbmQgbmV3IG1v
ZHVsZXMgc2ltdWx0YW5lb3VzbHkgd2l0aG91dCBjYXVzaW5nIHByb2JsZW1zPw0KDQpLZW50DQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2Qg
bWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f
bmV0bW9kJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNX
em9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1iZXpD
UHhUQXpPdUNqdzNSV2tlN045Tk9uUnI0NG15OXFWQnRZZTRhMG1BJnM9ZnJXVlJQVmx5QWNQQVFs
LUFSTnZDWWlZdy1ldVB6NmwtMjNsVTlIU1FDVSZlPQ0KDQoNCg==


From nobody Sat Jan 20 21:33: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 C4D2E124BFA for ; Sat, 20 Jan 2018 21:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_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=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 uaKuqlHZPlQn for ; Sat, 20 Jan 2018 21:32:59 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 A2C33120047 for ; Sat, 20 Jan 2018 21:32:59 -0800 (PST)
Received: by mail-oi0-x232.google.com with SMTP id f19so285126oig.4 for ; Sat, 20 Jan 2018 21:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sbfwzTZuiXdU2Z8v82aY1y32NGI6Gyyjht4LI0RK6Xw=; b=oxEkN+2Gabw4G8ePK8P5/jruiBYDA2wfYNpL9CqRDl5EodjOMwTA0unh3o1PtXoT35 fK8iRzK5XcWeKgQHNpQPfhTAkFgb4tSN2y4Dlo3l5DWGfxZec0tTG7+WrJQSCU6NvrWi LoWuBVUirJvWhf25ezaItZ69YJLJhpRYxxvd3ZVcdYBoPEouMdssJdr4TrUB5cNg869+ cIthgIKWtJROoiguPOj7RIvYtC7s23npXHF/X60Df0nqq718hzwj/HJFa+jiCh89OQMk G7FqRxQnGgg1aT19nbbqsV7c6YpP3SpQtDH0BsF4NiECJ52OaRxNg9X8EUyGDxDOpBSe dYfQ==
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=sbfwzTZuiXdU2Z8v82aY1y32NGI6Gyyjht4LI0RK6Xw=; b=qjr60fR4lhgtLEq+OVsxFjRGDwElGnLmGz70JSFPLKkSIaHq2hCarNYX6h+HLNh8Hh fVhm4vSRMcoN/eCNZZ79m3IYYVkzgugq2PzzoBGMry5fK/08tToanAbzYLeJ9x1xSc+Y S2/QRy0Thel+L1dbPe/yA1aySuX/5QHQckUK0dzVpytXHn8jdnRHpFqFwHipy0NVYVcQ yjqz5EIcSxiPv9CuQv8TL2OOYTOcVy+MYclQpTydK9DVuUwpGynr4SLzkUByHohWT9Uf 64S/krB+dtNPlNV9gpgcPvnF58P8f49iCwh7roGcN7l2B9zKpWLOnzwDRdjiwwzDzRXZ 7nBA==
X-Gm-Message-State: AKwxytfstCpqjVKAIFuH+PvwDm82joRvHS4cAfIQQleyrD9PEXDDXjKC YbVjeiqoXN7hxAI0O3/2ChE=
X-Google-Smtp-Source: AH8x224t5quxVzl/iw5T7noApDLjTNj3Qz7EsMc3f51ule1BFvvM23bj6SiPk/DCdaTL99+HWae/wQ==
X-Received: by 10.202.63.6 with SMTP id m6mr1558088oia.143.1516512778631; Sat, 20 Jan 2018 21:32:58 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:4188:630a:ffb1:83c8]) by smtp.gmail.com with ESMTPSA id u75sm5663494oia.55.2018.01.20.21.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jan 2018 21:32:57 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD0AF01D-8D44-4831-87A2-625F88A54EB3"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sat, 20 Jan 2018 21:32:55 -0800
In-Reply-To: 
Cc: Juergen Schoenwaelder , "netmod@ietf.org" 
To: Kent Watsen 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jan 2018 05:33:02 -0000

--Apple-Mail=_FD0AF01D-8D44-4831-87A2-625F88A54EB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jan 20, 2018, at 7:21 AM, Kent Watsen  wrote:
>=20
> Hi Mahesh,
>=20
> I'm okay not adding the ability to reference an external rulebase now, =
or are you saying that you'd also like to defer priming the YANG model =
now so that it can be added later in a backwards compatible manner?
>=20
> If you plan to prime the YANG model so that the ability to reference =
an external rulebase can added later in a backwards compatible manner, =
can you please send a concrete proposal to the list so that we can =
better understand the impact? =20
>=20
> My expectation is that it merely adds a 'choice' statement around the =
existing rulebase container, thereby enabling something other than a =
rulebase container to exist some day in the future. =20

That is correct. The proposal is to add a =E2=80=98choice=E2=80=99 =
statement in parts of the model that will allow an external rulebase to =
be added in the future as another case statement.

Here is the concrete proposal of what those changes will look like:

https://github.com/netmod-wg/acl-model/pull/23 =


Thanks
=20
>=20
> If the addition is indeed just this, then I don't believe that it =
materially changes the ACL model and therefore can be added as a LC =
comment.  Of course, the WG will want to review the addition for =
correctness, but otherwise should be alright.
>=20
> Thanks,
> Kent // co-chair and shepherd
>=20
>=20
> =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D
>=20
> Kent,
>=20
> I have not heard a strong requirement to have the open issue fixed in =
this version of the RFC. We would therefore like to defer it to a bis =
document.
>=20
> I will wait for the LC to complete, and update the draft to address =
all the comments received during the LC.
>=20
> Thanks.
>=20
>> On Jan 17, 2018, at 3:33 PM, Kent Watsen  wrote:
>>=20
>>=20
>> H Mahesh,
>>=20
>>>> - There is an open issue in the document (section 8) - are we going
>>>> to resolve that during WG last call or is this a leftover?
>>>=20
>>> This will be resolved in the next version of the module. It is
>>> documented under Issues tab in GitHub. Should we remove it from
>>> the draft?
>>=20
>> Most of Juergen's comments are editorial in nature and can truly be =
handled as part of the LC process, but this open issue has me worried, =
as it may result in a significant technical change. =20
>>=20
>> What will it take to close this open issue?  Is it just a matter of =
the getting the WG to agree that it's not an issue, or do we already =
know that it is a real issue and only the solution is pending?
>>=20
>> Thanks,
>> Kent
>>=20
>>=20
>>=20
>>=20
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com
>=20
>=20
>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_FD0AF01D-8D44-4831-87A2-625F88A54EB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Jan 20, 2018, at 7:21 AM, Kent Watsen <kwatsen@juniper.net>=
 wrote:

Hi Mahesh,

I'm okay not adding =
the ability to reference an external rulebase now, or are you saying =
that you'd also like to defer priming the YANG model now so that it can =
be added later in a backwards compatible manner?

If you plan to prime the YANG model so that the ability to =
reference an external rulebase can added later in a backwards compatible =
manner, can you please send a concrete proposal to the list so that we =
can better understand the impact?  

My =
expectation is that it merely adds a 'choice' statement around the =
existing rulebase container, thereby enabling something other than a =
rulebase container to exist some day in the future.  

That is =
correct. The proposal is to add a =E2=80=98choice=E2=80=99 statement in =
parts of the model that will allow an external rulebase to be added in =
the future as another case statement.

Here is the concrete proposal of what those =
changes will look like:

Thanks
 

If=
 the addition is indeed just this, then I don't believe that it =
materially changes the ACL model and therefore can be added as a LC =
comment.  Of course, the WG will want to review the addition for =
correctness, but otherwise should be alright.

Thanks,
Kent // co-chair and shepherd


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

Kent,

I have not heard a strong requirement to have =
the open issue fixed in this version of the RFC. We would therefore like =
to defer it to a bis document.

I will wait =
for the LC to complete, and update the draft to address all the comments =
received during the LC.

Thanks.

On Jan =
17, 2018, at 3:33 PM, Kent Watsen <kwatsen@juniper.net>=
 wrote:


H Mahesh,

- There is an open issue in the document =
(section 8) - are we going
to resolve that during WG last =
call or is this a leftover?

This=
 will be resolved in the next version of the module. It is
documented under Issues tab in GitHub. Should we remove it =
from
the draft?

Most of Juergen's comments are editorial in nature and can =
truly be handled as part of the LC process, but this open issue has me =
worried, as it may result in a significant technical change.  

What will it take to close this open issue? =
 Is it just a matter of the getting the WG to agree that it's not =
an issue, or do we already know that it is a real issue and only the =
solution is pending?

Thanks,
Kent





Mahesh =
Jethanandani
mjethanandani@gmail.com






Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_FD0AF01D-8D44-4831-87A2-625F88A54EB3--


From nobody Sun Jan 21 07:57: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 0BD4F12773A for ; Sun, 21 Jan 2018 07:57:49 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 4o1t99k0dnlQ for ; Sun, 21 Jan 2018 07:57:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0731205F0 for ; Sun, 21 Jan 2018 07:57:47 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 104A91AE034E; Sun, 21 Jan 2018 16:57:45 +0100 (CET)
Date: Sun, 21 Jan 2018 16:57:44 +0100 (CET)
Message-Id: <20180121.165744.2097248269985653820.mbj@tail-f.com>
To: lberger@labn.net
Cc: andy@yumaworks.com, kwatsen@juniper.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
References: <6585a71e-b00d-f55a-5336-45a46fb607fa@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Jan 2018 15:57:49 -0000

Lou Berger  wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG adoption:
> 
> Are you aware of any IPR that applies to drafts identified above?

No, I'm not aware of any IPR that applies to this draft.


/martin


From nobody Mon Jan 22 03:13: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 21334126B6E for ; Mon, 22 Jan 2018 03:13:23 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 2m41CsLGBsld for ; Mon, 22 Jan 2018 03:13:20 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F56124239 for ; Mon, 22 Jan 2018 03:13:20 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C1B94EFE; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id pSnLR3MkYgIi; Mon, 22 Jan 2018 12:13:15 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A81D920147; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xQzCUDhdoz70; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B88020144; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 212A04223C13; Mon, 22 Jan 2018 12:13:18 +0100 (CET)
Date: Mon, 22 Jan 2018 12:13:18 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: netmod@ietf.org
Message-ID: <20180122111318.d7riglic333nj7ki@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , netmod@ietf.org
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 11:13:23 -0000

On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
> 
> Hence, for me, I see the choice as:
> 1) do we publish the existing model now (perhaps also mark the draft as
> experimental) followed by an updated draft with the NMDA compatible module?
> 2) do we publish both models in a single draft (e.g. with the existing model
> in an appendix)?
> 3) do we only publish a single version of the draft with an NMDA compliant
> solution.
>

I think the situation is as follows (likely obvious but it may help to
make sure we are all on the same page):

- the NI and LNE models have a normative reference to
  I-D.ietf-netmod-schema-mount (and this makes sense since there are
  MUST sentences in the I-D)

- I-D.ietf-netmod-schema-mount (last updated in October) has normative
  references to RFC 7895 (old YANG library)

- RFC 7895 does not work with NMDA, NMDA work on a YANG library update
  replacing RFC 7895

So the YANG library update is gating the schema mount update which is
gating the publication of the NI and LNE models.

A proper solution would be to prioritize work on the YANG library
update and the schema mount update. I assume that the next revision of
the YANG library update (say end of January) is ready for WG last call
and perhaps the schema mount authors can take an effort to get that
document there as well, say beginning of February.

/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 Mon Jan 22 05:36: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 4E8D712711E for ; Mon, 22 Jan 2018 05:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Zn7gfz7eC7iL for ; Mon, 22 Jan 2018 05:36:16 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA39126C2F for ; Mon, 22 Jan 2018 05:35:58 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 635A11820412; Mon, 22 Jan 2018 14:35:44 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 4C8E7182040D; Mon, 22 Jan 2018 14:35:38 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Martin Bjorklund , netmod@ietf.org, Lou Berger 
In-Reply-To: <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com>
Mail-Followup-To: Robert Wilton , Martin Bjorklund , netmod@ietf.org, Lou Berger 
Date: Mon, 22 Jan 2018 14:35:49 +0100
Message-ID: <87efmim2x6.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 13:36:19 -0000

Robert Wilton  writes:

> On 17/01/2018 16:40, Martin Bjorklund wrote:
>> Ladislav Lhotka  wrote:
>
> 
>
>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>>> I don't agree. The metadata annotation solves real issues.
>> One issue with the annotation is that since the schema might be
>> different in different datastores, it means that the client needs to
>> read the annotation in all datastores, and then fetch the schemas.  So
>> it is a bit more difficult to work with for a client.
> I'm still not convinced that I really understand all the arguments here:
>
> Using YLbis over YL seems to have obvious benefits to me, in that I=20
> perceive that it gives a cleaner data model.=C2=A0 But I also understand=
=20
> Lou's concerns - although its not clear to me whether Lou's primary=20
> concern is timing, or the fact that implementations are forced to use
> YLbis.

Note that it is only the migration to YLbis that implies changes in the
appendices of LNE and NI. The metadata annotation for inline mount
points doesn't require any change in any existing draft I am aware of.

>
> I also agree with Juergen that from an YLbis authors perspective YLbis=20
> is quite close.=C2=A0 I believe that the YANG model itself has been agree=
d=20
> (at the interim meeting in Nov/Dec), and hence really what is left is=20
> just tidying/enhancing the descriptive text in the document.
>
> I don't really understand the benefits of the metadata annotations. It

My take is this:

Section 3.2 currently requires that "every instance of the [inline]
mount point that exists in the parent tree MUST contain a copy of YANG
library data". This was indeed the original idea that however doesn't
work with NMDA.

Lou's suggestion was that for inline mount point instances in
configuration datastores, the (embedded) YANG library will be available
under the corresponding mount point instance in . The
problem with this is that the corresponding instance needn't always
exist because

- NMDA mentions situations (e.g pre-provisioning) where an instance in
   has no corresponding instance in 

- Only "base" NMDA config datastores are required to keep a copy of
  their data in . Other datastores IMO needn't follow this
  rule, or the relationship with  needn't be so
  straightforward.=20=20

Lou argued that this is not a problem for LNE and NI, but I think it is
not sufficient provided that schema mount is intended as a general
mechanism.

The metadat annotation solves this. Moreover, it allows for keeping all
schema-related metadata in one place that we can possibly think of as a
metadata datastore.

A use-schema-type mount point will then have a leafref to the mounted
schema directly in the metadata (i.e. fixed at implementation time)
whereas every instance of an inline-type mount point supplies the
same leafref at run time via the annotation. This is IMO a much cleaner
architecture.=20=20

> feels like this is going to be more hassle because a client will have to=
=20
> query each datastore separately rather than getting the information in a=
=20
> single operation.

But then the client would get schemas for all datastores, even those it
is not interested in.

Assume we have an inline mount point "root" (a container), and let's say
the schema for all NMDA config datastores is the same but 
has a different schema. The *all* config datastores will contain just this
instance:

    

and  can have

    

Thanks to module sets in YLbis this can be expressed very efficiently
and I don't see how this could be a hassle for a client.

>
> A regular (without SM) NMDA NC/YANG server supports multiple datastores,=
=20
> but that information is only exposed via one so them (i.e.=20
> ).=C2=A0 So, in a server supporting inline SM, it seems quit=
e=20
> natural to me for the mounted schema information to also only be=20
> available via the mounted .=C2=A0 This seems to mirror the=20
> standard NC/YANG+YL behavior, and also seems to naturally recurse if=20
> required.

Not really. The difference is that the regular YL is unconditionally
present in a fixed location in . In contrast, to get the
embedded YL for an inline mount point instance in a config datastore, it
is necessary to determine a corresponding mount point instance in
, which is IMO not always possible. The metadata annotation
will point to the appropriate schema right away from the config datastore.=
=20

>
> Hence, for me, I see the choice as:
> 1) do we publish the existing model now (perhaps also mark the draft as=20
> experimental) followed by an updated draft with the NMDA compatible
> module?
> 2) do we publish both models in a single draft (e.g. with the existing=20
> model in an appendix)?
> 3) do we only publish a single version of the draft with an NMDA=20
> compliant solution.

I support #3.

Lada

>
> Thanks,
> Rob
>
>

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Jan 22 05:39: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 C7A07126C2F for ; Mon, 22 Jan 2018 05:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 V6cAMPR9J9rb for ; Mon, 22 Jan 2018 05:39:25 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5BB127286 for ; Mon, 22 Jan 2018 05:39:17 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id F28BA1820414; Mon, 22 Jan 2018 14:39:03 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 44EDC182040D; Mon, 22 Jan 2018 14:38:59 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , Dean Bogdanovic , Lou Berger 
Cc: "netmod\@ietf.org" 
In-Reply-To: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <1610fcba1f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  
Mail-Followup-To: Kent Watsen , Dean Bogdanovic , Lou Berger , "netmod\@ietf.org" 
Date: Mon, 22 Jan 2018 14:39:11 +0100
Message-ID: <87bmhmm2rk.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 13:39:27 -0000

Kent Watsen  writes:

> Hi Dean,
>
> "As Lou mentioned, schema mount can be used with or without YANG library.=
 As author who uses the schema mount in a draft and in product, don=E2=80=
=99t want to hold back the publication. We, IETF, are too slow. Getting dat=
a model RFCs published takes too much time and we are not getting experienc=
e from implementation and operational usage. Things have to move much faste=
r or the industry will move away from this organization. At the end, if we =
need to we can revise to support future publications."
>
>
> Just a clarification on your last sentence, my understanding is that a
> revision is necessary in order for schema-mount to work on NMDA-based
> servers.  Should we publish the current draft as is now, we're
> effectively committed to publishing an NMDA-update in the near-term
> anyways.

Yes, and also keeping some deprecated nodes from the old version, which
would make the new model hard to read. This is IMO too high a price.

Lada

>
> Kent
>
>
>
>
> _______________________________________________
> 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 Jan 22 05:45: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 EEF35126BF6 for ; Mon, 22 Jan 2018 05:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TxA8ZkWfDg0E for ; Mon, 22 Jan 2018 05:45:40 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1751252BA for ; Mon, 22 Jan 2018 05:45:39 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 9ABE81820413; Mon, 22 Jan 2018 14:45:26 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id ED6DD182040D; Mon, 22 Jan 2018 14:45:24 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Robert Wilton 
Cc: netmod@ietf.org
In-Reply-To: <20180122111318.d7riglic333nj7ki@elstar.local>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder , Robert Wilton , netmod@ietf.org
Date: Mon, 22 Jan 2018 14:45:36 +0100
Message-ID: <878tcqm2gv.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 13:45:42 -0000

Juergen Schoenwaelder  writes:

> On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
>> 
>> Hence, for me, I see the choice as:
>> 1) do we publish the existing model now (perhaps also mark the draft as
>> experimental) followed by an updated draft with the NMDA compatible module?
>> 2) do we publish both models in a single draft (e.g. with the existing model
>> in an appendix)?
>> 3) do we only publish a single version of the draft with an NMDA compliant
>> solution.
>>
>
> I think the situation is as follows (likely obvious but it may help to
> make sure we are all on the same page):
>
> - the NI and LNE models have a normative reference to
>   I-D.ietf-netmod-schema-mount (and this makes sense since there are
>   MUST sentences in the I-D)
>
> - I-D.ietf-netmod-schema-mount (last updated in October) has normative
>   references to RFC 7895 (old YANG library)
>
> - RFC 7895 does not work with NMDA, NMDA work on a YANG library update
>   replacing RFC 7895
>
> So the YANG library update is gating the schema mount update which is
> gating the publication of the NI and LNE models.
>
> A proper solution would be to prioritize work on the YANG library
> update and the schema mount update. I assume that the next revision of
> the YANG library update (say end of January) is ready for WG last call
> and perhaps the schema mount authors can take an effort to get that
> document there as well, say beginning of February.

I completely agree.

Lada

>
> /js
>
> -- 
> 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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Jan 22 07:50: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 CA013126DD9 for ; Mon, 22 Jan 2018 07:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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] 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 Nd0TXSkvWwrr for ; Mon, 22 Jan 2018 07:50:31 -0800 (PST)
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 C442A124207 for ; Mon, 22 Jan 2018 07:50:31 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0MFmXs1014210; Mon, 22 Jan 2018 07:50:29 -0800
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=oRqxkaiKp+a63y5V+Rb/YKOl9GyT7HA08JyvfvTGF9w=; b=Nr8lFbYrNwgczXy6ngBTjg8aqKD73pya3lxcSN28KvzJyYPHf501O+1upzfTlUBbjQyr ykY3wN4epUskxLy91ynOU6HRjQbsgeOyTstmwjDnO1584cIq02HJP8TxEoAn1/q+kpvf iQfQbGfe/64EKuW5cWCPrS2vbKtHp4Lzz6FbXgp89aVKkg9tGeHItlmpClCtD3xjIbbm MQnCIM6LmGBSqjl2cyFFrLmYwNf/qCpWj+//moqg4WULXQOx+sNsgC7WHJx4c0eZ3pWj JF+Yk+EqeIBSyFDoXdTak+WICfr17fH9O1pm54U3pqdgZNfYX3CExIEGuofaY0NH4ifQ Yw== 
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0016.outbound.protection.outlook.com [207.46.163.16]) by mx0a-00273201.pphosted.com with ESMTP id 2fnjpsg1fj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 07:50:28 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2842.namprd05.prod.outlook.com (10.168.175.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Mon, 22 Jan 2018 15:50:26 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.008; Mon, 22 Jan 2018 15:50:27 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
CC: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKN4qxIAgAABR4D//7cngIADJ0+AgAEGT4CAAUG5gIAB6wuA
Date: Mon, 22 Jan 2018 15:50:27 +0000
Message-ID: <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net>
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local>   <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com>  <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com>
In-Reply-To: <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.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.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2842; 7:hdlHw4EAx8xG7rehFZ5KNGZpQHRIyHNbROhIo8XmiUsYaNDO1MizCJrpboVTz6J96e/O/k+J7frjNVzWQRSv//WKuTSejVTajZZF38pruVz9MP9M7S/nkahMLNm1Pex6laee8WwRhOfN9I44E+mkCV6SIgmADAcWLWB0puRKCCRepe1Twm6tPyYDZvWrE9/0CKGLkhOTCOSMuZk6rnmibNzRH0XQBtpTcZAMXTnhTvzegQpFTnwMV1wRtxsVijSP
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8227fe44-6478-4094-55af-08d561afdb6a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2842; 
x-ms-traffictypediagnostic: DM5PR05MB2842:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(166708455590820)(138986009662008)(85827821059158)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231046)(2400081)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB2842; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR05MB2842; 
x-forefront-prvs: 0560A2214D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(39860400002)(376002)(396003)(189003)(199004)(3660700001)(3280700002)(54906003)(5660300001)(83506002)(33656002)(229853002)(36756003)(316002)(58126008)(25786009)(93886005)(105586002)(6246003)(82746002)(106356001)(1411001)(14454004)(66066001)(478600001)(966005)(97736004)(2906002)(39060400002)(99286004)(86362001)(81156014)(8676002)(230783001)(102836004)(7736002)(8936002)(6346003)(6306002)(3846002)(54896002)(6116002)(26005)(77096007)(83716003)(236005)(81166006)(4326008)(6916009)(6506007)(68736007)(53546011)(6486002)(6436002)(59450400001)(53936002)(6512007)(76176011)(2900100001)(561944003)(2950100002)(9326002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2842; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Oa1TNUV2fHsQEV27VCW/vBnI3Gse0G+EcOvgIX5xdUP5XXtYBEOxUs3U9jEnDDkq9r4NGs8VhclL9t3PkuJJbQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_543B7D01A4914BFBB74B786002F31022junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8227fe44-6478-4094-55af-08d561afdb6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 15:50:27.0830 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2842
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_06:, , 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-1711220000 definitions=main-1801220223
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 15:50:39 -0000

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

SGkgTWFoZXNoLA0KDQpUaGFua3MsIGl0IGRvZXNuJ3QgZ2V0IG11Y2ggbW9yZSBjb25jcmV0ZSB0
aGVuIGEgcHVsbCByZXF1ZXN0ICA7KQ0KDQpPa2F5LCBzbyBmcm9tIGEgY2hhaXIvc2hlcGhlcmQg
cGVyc3BlY3RpdmUsIGNhbiBmb2xrcyBwbGVhc2UgY29uc2lkZXIgdGhpcyB1cGRhdGUgdG8gLTE1
IGFzIHRoZSBMQyBzb2x1dGlvbiB0byByZW1vdmluZyB0aGUgb3BlbiBpc3N1ZSBKdWVyZ2VuIGZv
dW5kIGluIHRoZSBkcmFmdD8NCg0KQXMgYSBjb250cmlidXRvciwgSSBkb24ndCB0aGluayB0aGUg
bmFtZSBvZiB0aGUgZ3JvdXBpbmdzIG9yIHRoZWlyIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgc2hv
dWxkIGFsbHVkZSB0byBzb21ldGhpbmcgdGhhdCBkb2Vzbid0IGV4aXN0IHlldC4gIFJhdGhlciB0
aGFuIGUuZy4gInNvdXJjZS1vci1ncm91cCIsIGNvdWxkIGl0IGJlIGluc3RlYWQgc29tZXRoaW5n
IGxpa2UgInNvdXJjZS10eXBlIj8gICAgQWxzbywgdGhlIHVwZGF0ZSBzZWVtcyB0byBiZSBmb3Ig
Ym90aCB3aGVuIHNwZWNpZnlpbmcgbmV0d29ya3MgYXMgd2VsbCBhcyB3aGVuIHNwZWNpZnlpbmcg
cG9ydC1yYW5nZXMsIGJ1dCB0aGUgb3JpZ2luYWwgaXNzdWUgKHNlZSBiZWxvdykgb25seSBtZW50
aW9uZWQgYWRkcmVzc2VzIC0gaXMgdGhlIHB1bGwtcmVxdWVzdCBhY3R1YWxseSB3aGF0J3MgbmVl
ZGVkIGFuZCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGlzc3VlIGluIFNlY3Rpb24gOCBpcyBpbmNv
bXBsZXRlPw0KDQogICAgOC4gIE9wZW4gSXNzdWVzDQoNCiAgICAgICBvICBUaGUgY3VycmVudCBt
b2RlbCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBjb25jZXB0IG9mICJjb250YWluZXJzIg0KICAgICAg
ICAgICAgdXNlZCB0byBjb250YWluIG11bHRpcGxlIGFkZHJlc3NlcyBwZXIgcnVsZSBlbnRyeS4N
Cg0KVGhhbmtzLA0KS2VudA0KDQoNCk9uIDEvMjEvMTgsIDEyOjMyIEFNLCAiTWFoZXNoIEpldGhh
bmFuZGFuaSIgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdt
YWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KDQpPbiBKYW4gMjAsIDIwMTgsIGF0IDc6MjEgQU0sIEtl
bnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0
Pj4gd3JvdGU6DQoNCkhpIE1haGVzaCwNCg0KSSdtIG9rYXkgbm90IGFkZGluZyB0aGUgYWJpbGl0
eSB0byByZWZlcmVuY2UgYW4gZXh0ZXJuYWwgcnVsZWJhc2Ugbm93LCBvciBhcmUgeW91IHNheWlu
ZyB0aGF0IHlvdSdkIGFsc28gbGlrZSB0byBkZWZlciBwcmltaW5nIHRoZSBZQU5HIG1vZGVsIG5v
dyBzbyB0aGF0IGl0IGNhbiBiZSBhZGRlZCBsYXRlciBpbiBhIGJhY2t3YXJkcyBjb21wYXRpYmxl
IG1hbm5lcj8NCg0KSWYgeW91IHBsYW4gdG8gcHJpbWUgdGhlIFlBTkcgbW9kZWwgc28gdGhhdCB0
aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgYW4gZXh0ZXJuYWwgcnVsZWJhc2UgY2FuIGFkZGVkIGxh
dGVyIGluIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgbWFubmVyLCBjYW4geW91IHBsZWFzZSBzZW5k
IGEgY29uY3JldGUgcHJvcG9zYWwgdG8gdGhlIGxpc3Qgc28gdGhhdCB3ZSBjYW4gYmV0dGVyIHVu
ZGVyc3RhbmQgdGhlIGltcGFjdD8NCg0KTXkgZXhwZWN0YXRpb24gaXMgdGhhdCBpdCBtZXJlbHkg
YWRkcyBhICdjaG9pY2UnIHN0YXRlbWVudCBhcm91bmQgdGhlIGV4aXN0aW5nIHJ1bGViYXNlIGNv
bnRhaW5lciwgdGhlcmVieSBlbmFibGluZyBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIHJ1bGViYXNl
IGNvbnRhaW5lciB0byBleGlzdCBzb21lIGRheSBpbiB0aGUgZnV0dXJlLg0KDQpUaGF0IGlzIGNv
cnJlY3QuIFRoZSBwcm9wb3NhbCBpcyB0byBhZGQgYSDigJhjaG9pY2XigJkgc3RhdGVtZW50IGlu
IHBhcnRzIG9mIHRoZSBtb2RlbCB0aGF0IHdpbGwgYWxsb3cgYW4gZXh0ZXJuYWwgcnVsZWJhc2Ug
dG8gYmUgYWRkZWQgaW4gdGhlIGZ1dHVyZSBhcyBhbm90aGVyIGNhc2Ugc3RhdGVtZW50Lg0KDQpI
ZXJlIGlzIHRoZSBjb25jcmV0ZSBwcm9wb3NhbCBvZiB3aGF0IHRob3NlIGNoYW5nZXMgd2lsbCBs
b29rIGxpa2U6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwv
MjM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19n
aXRodWIuY29tX25ldG1vZC0yRHdnX2FjbC0yRG1vZGVsX3B1bGxfMjMmZD1Ed01GYVEmYz1IQWtZ
dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF
UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPVRUY1ZObUQtcFA1SmczUDBpTExtTk4tb1Ro
dG1MaURELWktY2ZtbWwtZDQmcz05YW1kMTVmRW9UNDA2YmxtZHVhTHVxR283bDFNaTBqdDg2bmlk
Yk9KMmZVJmU9Pg0KDQpUaGFua3MNCg0KDQoNCklmIHRoZSBhZGRpdGlvbiBpcyBpbmRlZWQganVz
dCB0aGlzLCB0aGVuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGl0IG1hdGVyaWFsbHkgY2hhbmdlcyB0
aGUgQUNMIG1vZGVsIGFuZCB0aGVyZWZvcmUgY2FuIGJlIGFkZGVkIGFzIGEgTEMgY29tbWVudC4g
IE9mIGNvdXJzZSwgdGhlIFdHIHdpbGwgd2FudCB0byByZXZpZXcgdGhlIGFkZGl0aW9uIGZvciBj
b3JyZWN0bmVzcywgYnV0IG90aGVyd2lzZSBzaG91bGQgYmUgYWxyaWdodC4NCg0KVGhhbmtzLA0K
S2VudCAvLyBjby1jaGFpciBhbmQgc2hlcGhlcmQNCg0KDQo9PT09PSBvcmlnaW5hbCBtZXNzYWdl
ID09PT09DQoNCktlbnQsDQoNCkkgaGF2ZSBub3QgaGVhcmQgYSBzdHJvbmcgcmVxdWlyZW1lbnQg
dG8gaGF2ZSB0aGUgb3BlbiBpc3N1ZSBmaXhlZCBpbiB0aGlzIHZlcnNpb24gb2YgdGhlIFJGQy4g
V2Ugd291bGQgdGhlcmVmb3JlIGxpa2UgdG8gZGVmZXIgaXQgdG8gYSBiaXMgZG9jdW1lbnQuDQoN
Ckkgd2lsbCB3YWl0IGZvciB0aGUgTEMgdG8gY29tcGxldGUsIGFuZCB1cGRhdGUgdGhlIGRyYWZ0
IHRvIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIExDLg0KDQpU
aGFua3MuDQoNCg0KT24gSmFuIDE3LCAyMDE4LCBhdCAzOjMzIFBNLCBLZW50IFdhdHNlbiA8a3dh
dHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQoN
CkggTWFoZXNoLA0KDQoNCi0gVGhlcmUgaXMgYW4gb3BlbiBpc3N1ZSBpbiB0aGUgZG9jdW1lbnQg
KHNlY3Rpb24gOCkgLSBhcmUgd2UgZ29pbmcNCnRvIHJlc29sdmUgdGhhdCBkdXJpbmcgV0cgbGFz
dCBjYWxsIG9yIGlzIHRoaXMgYSBsZWZ0b3Zlcj8NCg0KVGhpcyB3aWxsIGJlIHJlc29sdmVkIGlu
IHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIG1vZHVsZS4gSXQgaXMNCmRvY3VtZW50ZWQgdW5kZXIg
SXNzdWVzIHRhYiBpbiBHaXRIdWIuIFNob3VsZCB3ZSByZW1vdmUgaXQgZnJvbQ0KdGhlIGRyYWZ0
Pw0KDQpNb3N0IG9mIEp1ZXJnZW4ncyBjb21tZW50cyBhcmUgZWRpdG9yaWFsIGluIG5hdHVyZSBh
bmQgY2FuIHRydWx5IGJlIGhhbmRsZWQgYXMgcGFydCBvZiB0aGUgTEMgcHJvY2VzcywgYnV0IHRo
aXMgb3BlbiBpc3N1ZSBoYXMgbWUgd29ycmllZCwgYXMgaXQgbWF5IHJlc3VsdCBpbiBhIHNpZ25p
ZmljYW50IHRlY2huaWNhbCBjaGFuZ2UuDQoNCldoYXQgd2lsbCBpdCB0YWtlIHRvIGNsb3NlIHRo
aXMgb3BlbiBpc3N1ZT8gIElzIGl0IGp1c3QgYSBtYXR0ZXIgb2YgdGhlIGdldHRpbmcgdGhlIFdH
IHRvIGFncmVlIHRoYXQgaXQncyBub3QgYW4gaXNzdWUsIG9yIGRvIHdlIGFscmVhZHkga25vdyB0
aGF0IGl0IGlzIGEgcmVhbCBpc3N1ZSBhbmQgb25seSB0aGUgc29sdXRpb24gaXMgcGVuZGluZz8N
Cg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5k
YW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQpNYWhl
c2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFu
ZGFuaUBnbWFpbC5jb20+DQoNCg0K

--_000_543B7D01A4914BFBB74B786002F31022junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <6453C456E7681C4EBC49BA5168E742DE@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
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIE1haGVz
aCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5r
cywgaXQgZG9lc24ndCBnZXQgbXVjaCBtb3JlIGNvbmNyZXRlIHRoZW4gYSBwdWxsIHJlcXVlc3Qm
bmJzcDsgOyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
Pk9rYXksIHNvIGZyb20gYSBjaGFpci9zaGVwaGVyZCBwZXJzcGVjdGl2ZSwgY2FuIGZvbGtzIHBs
ZWFzZSBjb25zaWRlciB0aGlzIHVwZGF0ZSB0byAtMTUgYXMgdGhlIExDIHNvbHV0aW9uIHRvIHJl
bW92aW5nIHRoZSBvcGVuIGlzc3VlIEp1ZXJnZW4gZm91bmQgaW4gdGhlIGRyYWZ0PzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+QXMgYSBjb250cmlidXRv
ciwgSSBkb24ndCB0aGluayB0aGUgbmFtZSBvZiB0aGUgZ3JvdXBpbmdzIG9yIHRoZWlyIGRlc2Ny
aXB0aW9uIHN0YXRlbWVudHMgc2hvdWxkIGFsbHVkZSB0byBzb21ldGhpbmcgdGhhdCBkb2Vzbid0
IGV4aXN0IHlldC4mbmJzcDsgUmF0aGVyIHRoYW4gZS5nLiAmcXVvdDtzb3VyY2Utb3ItZ3JvdXAm
cXVvdDssIGNvdWxkIGl0IGJlIGluc3RlYWQgc29tZXRoaW5nDQogbGlrZSAmcXVvdDtzb3VyY2Ut
dHlwZSZxdW90Oz8mbmJzcDsgJm5ic3A7Jm5ic3A7QWxzbywgdGhlIHVwZGF0ZSBzZWVtcyB0byBi
ZSBmb3IgYm90aCB3aGVuIHNwZWNpZnlpbmcgbmV0d29ya3MgYXMgd2VsbCBhcyB3aGVuIHNwZWNp
ZnlpbmcgcG9ydC1yYW5nZXMsIGJ1dCB0aGUgb3JpZ2luYWwgaXNzdWUgKHNlZSBiZWxvdykgb25s
eSBtZW50aW9uZWQgYWRkcmVzc2VzIC0gaXMgdGhlIHB1bGwtcmVxdWVzdCBhY3R1YWxseSB3aGF0
J3MgbmVlZGVkIGFuZCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlDQogaXNzdWUgaW4gU2VjdGlvbiA4
IGlzIGluY29tcGxldGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgOC4mbmJzcDsgT3BlbiBJc3N1ZXM8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7IFRoZSBjdXJyZW50IG1vZGVsIGRvZXMgbm90IHN1
cHBvcnQgdGhlIGNvbmNlcHQgb2YgJnF1b3Q7Y29udGFpbmVycyZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlZCB0byBjb250YWluIG11bHRpcGxlIGFkZHJlc3NlcyBwZXIg
cnVsZSBlbnRyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzIxLzE4LCAxMjozMiBB
TSwgJnF1b3Q7TWFoZXNoIEpldGhhbmFuZGFuaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1q
ZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBKYW4gMjAsIDIwMTgsIGF0IDc6MjEgQU0sIEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWls
dG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWFoZXNo
LDxicj4NCjxicj4NCkknbSBva2F5IG5vdCBhZGRpbmcgdGhlIGFiaWxpdHkgdG8gcmVmZXJlbmNl
IGFuIGV4dGVybmFsIHJ1bGViYXNlIG5vdywgb3IgYXJlIHlvdSBzYXlpbmcgdGhhdCB5b3UnZCBh
bHNvIGxpa2UgdG8gZGVmZXIgcHJpbWluZyB0aGUgWUFORyBtb2RlbCBub3cgc28gdGhhdCBpdCBj
YW4gYmUgYWRkZWQgbGF0ZXIgaW4gYSBiYWNrd2FyZHMgY29tcGF0aWJsZSBtYW5uZXI/PGJyPg0K
PGJyPg0KSWYgeW91IHBsYW4gdG8gcHJpbWUgdGhlIFlBTkcgbW9kZWwgc28gdGhhdCB0aGUgYWJp
bGl0eSB0byByZWZlcmVuY2UgYW4gZXh0ZXJuYWwgcnVsZWJhc2UgY2FuIGFkZGVkIGxhdGVyIGlu
IGEgYmFja3dhcmRzIGNvbXBhdGlibGUgbWFubmVyLCBjYW4geW91IHBsZWFzZSBzZW5kIGEgY29u
Y3JldGUgcHJvcG9zYWwgdG8gdGhlIGxpc3Qgc28gdGhhdCB3ZSBjYW4gYmV0dGVyIHVuZGVyc3Rh
bmQgdGhlIGltcGFjdD8gJm5ic3A7PGJyPg0KPGJyPg0KTXkgZXhwZWN0YXRpb24gaXMgdGhhdCBp
dCBtZXJlbHkgYWRkcyBhICdjaG9pY2UnIHN0YXRlbWVudCBhcm91bmQgdGhlIGV4aXN0aW5nIHJ1
bGViYXNlIGNvbnRhaW5lciwgdGhlcmVieSBlbmFibGluZyBzb21ldGhpbmcgb3RoZXIgdGhhbiBh
IHJ1bGViYXNlIGNvbnRhaW5lciB0byBleGlzdCBzb21lIGRheSBpbiB0aGUgZnV0dXJlLiAmbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgY29ycmVjdC4gVGhlIHByb3Bvc2FsIGlzIHRvIGFkZCBh
IOKAmGNob2ljZeKAmSBzdGF0ZW1lbnQgaW4gcGFydHMgb2YgdGhlIG1vZGVsIHRoYXQgd2lsbCBh
bGxvdyBhbiBleHRlcm5hbCBydWxlYmFzZSB0byBiZSBhZGRlZCBpbiB0aGUgZnV0dXJlIGFzIGFu
b3RoZXIgY2FzZSBzdGF0ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgdGhlIGNvbmNyZXRlIHByb3Bvc2FsIG9mIHdoYXQg
dGhvc2UgY2hhbmdlcyB3aWxsIGxvb2sgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX25ldG1vZC0yRHdnX2Fj
bC0yRG1vZGVsX3B1bGxfMjMmYW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgw
VWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz
QllhR1R2aklTbGFKZGNabyZhbXA7bT1UVGNWTm1ELXBQNUpnM1AwaUxMbU5OLW9UaHRtTGlERC1p
LWNmbW1sLWQ0JmFtcDtzPTlhbWQxNWZFb1Q0MDZibG1kdWFMdXFHbzdsMU1pMGp0ODZuaWRiT0oy
ZlUmYW1wO2U9Ij5odHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIz
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCklmIHRoZSBhZGRpdGlvbiBpcyBpbmRlZWQganVzdCB0
aGlzLCB0aGVuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGl0IG1hdGVyaWFsbHkgY2hhbmdlcyB0aGUg
QUNMIG1vZGVsIGFuZCB0aGVyZWZvcmUgY2FuIGJlIGFkZGVkIGFzIGEgTEMgY29tbWVudC4gJm5i
c3A7T2YgY291cnNlLCB0aGUgV0cgd2lsbCB3YW50IHRvIHJldmlldyB0aGUgYWRkaXRpb24gZm9y
IGNvcnJlY3RuZXNzLCBidXQgb3RoZXJ3aXNlIHNob3VsZCBiZSBhbHJpZ2h0Ljxicj4NCjxicj4N
ClRoYW5rcyw8YnI+DQpLZW50IC8vIGNvLWNoYWlyIGFuZCBzaGVwaGVyZDxicj4NCjxicj4NCjxi
cj4NCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT08YnI+DQo8YnI+DQpLZW50LDxicj4NCjxi
cj4NCkkgaGF2ZSBub3QgaGVhcmQgYSBzdHJvbmcgcmVxdWlyZW1lbnQgdG8gaGF2ZSB0aGUgb3Bl
biBpc3N1ZSBmaXhlZCBpbiB0aGlzIHZlcnNpb24gb2YgdGhlIFJGQy4gV2Ugd291bGQgdGhlcmVm
b3JlIGxpa2UgdG8gZGVmZXIgaXQgdG8gYSBiaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSSB3aWxs
IHdhaXQgZm9yIHRoZSBMQyB0byBjb21wbGV0ZSwgYW5kIHVwZGF0ZSB0aGUgZHJhZnQgdG8gYWRk
cmVzcyBhbGwgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmluZyB0aGUgTEMuPGJyPg0KPGJyPg0K
VGhhbmtzLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiBKYW4gMTcsIDIwMTgsIGF0IDM6MzMgUE0sIEtlbnQgV2F0c2VuICZsdDs8YSBo
cmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4m
Z3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCkggTWFoZXNoLDxicj4NCjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlcmUgaXMgYW4gb3Bl
biBpc3N1ZSBpbiB0aGUgZG9jdW1lbnQgKHNlY3Rpb24gOCkgLSBhcmUgd2UgZ29pbmc8YnI+DQp0
byByZXNvbHZlIHRoYXQgZHVyaW5nIFdHIGxhc3QgY2FsbCBvciBpcyB0aGlzIGEgbGVmdG92ZXI/
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQpUaGlzIHdpbGwgYmUgcmVzb2x2ZWQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgbW9kdWxl
LiBJdCBpczxicj4NCmRvY3VtZW50ZWQgdW5kZXIgSXNzdWVzIHRhYiBpbiBHaXRIdWIuIFNob3Vs
ZCB3ZSByZW1vdmUgaXQgZnJvbTxicj4NCnRoZSBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGJyPg0KTW9zdCBvZiBKdWVyZ2VuJ3MgY29tbWVudHMgYXJlIGVkaXRvcmlhbCBpbiBuYXR1
cmUgYW5kIGNhbiB0cnVseSBiZSBoYW5kbGVkIGFzIHBhcnQgb2YgdGhlIExDIHByb2Nlc3MsIGJ1
dCB0aGlzIG9wZW4gaXNzdWUgaGFzIG1lIHdvcnJpZWQsIGFzIGl0IG1heSByZXN1bHQgaW4gYSBz
aWduaWZpY2FudCB0ZWNobmljYWwgY2hhbmdlLiAmbmJzcDs8YnI+DQo8YnI+DQpXaGF0IHdpbGwg
aXQgdGFrZSB0byBjbG9zZSB0aGlzIG9wZW4gaXNzdWU/ICZuYnNwO0lzIGl0IGp1c3QgYSBtYXR0
ZXIgb2YgdGhlIGdldHRpbmcgdGhlIFdHIHRvIGFncmVlIHRoYXQgaXQncyBub3QgYW4gaXNzdWUs
IG9yIGRvIHdlIGFscmVhZHkga25vdyB0aGF0IGl0IGlzIGEgcmVhbCBpc3N1ZSBhbmQgb25seSB0
aGUgc29sdXRpb24gaXMgcGVuZGluZz88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2VudDxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpNYWhlc2gg
SmV0aGFuYW5kYW5pPGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29t
Ij5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBn
bWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_543B7D01A4914BFBB74B786002F31022junipernet_--


From nobody Mon Jan 22 08:18: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 673F4127078 for ; Mon, 22 Jan 2018 08:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 twd0MzYrTwd2 for ; Mon, 22 Jan 2018 08:18:29 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDF8127076 for ; Mon, 22 Jan 2018 08:18:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4290; q=dns/txt; s=iport; t=1516637909; x=1517847509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cxuZGb40U/U26qNaBOgzA01PCEW3ENIJYxvObk8HVTc=; b=GhUl9bxMcLJvPp5IG2RYEMvuQ0EWTNt7REPKJA6wpXWFxgkCLpEDaWwT Cj8DuPdOBsYjVR714bbM4ERnj/xC1O6ewvI1lA0frmtjgX1V4p49iiRTx FZM4fd9z6bekWXgB+n7r5Vvxu7yeMqdLQUOZ3FDng/kVNIgchaWMi32sH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQCWDmZa/5NdJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQmZ0JweDVookjmWCApc+ghcKGAuESU8CGoRWPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAwEBASEROgsOAgIBCBAIAgImAgICGQwLFRACBAENBRuKEAgQt?= =?us-ascii?q?RiCJ4ouAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQqDOoIVgz8pgwWDLwEBAoF?= =?us-ascii?q?vFwomglAxgjQFmgCJegKVWQ2CDpIEinWMJQIRGQGBOwEfOYFQbxU9KgGBf4RXe?= =?us-ascii?q?IlTgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,397,1511827200"; d="scan'208";a="346134275"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 16:18:16 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0MGIGPc000577 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2018 16:18:16 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 22 Jan 2018 11:18:15 -0500
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; Mon, 22 Jan 2018 11:18:15 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , Juergen Schoenwaelder , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount and YANG library
Thread-Index: AQHTjpmkXZcjBoxLfUed9b6huAMBJw==
Date: Mon, 22 Jan 2018 16:18:15 +0000
Message-ID: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz>
In-Reply-To: <878tcqm2gv.fsf@nic.cz>
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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0525EFB00DAE084688BC4C7370E3814B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:18:31 -0000

SGkgTGFkYSwgDQoNCk15IHByaW1hcnkgY29uY2VybiBpcyB0aGF0IHRoZSBZQU5HIFNjaGVtYSBN
b3VudCBkZWxheSB3aWxsIG5vdCBvbmx5IGhvbGQgdGhlIE5JL0xORSBidXQgYWxsIHRoZSBtb2Rl
bHMgdGhhdCBhcmUgZGVwZW5kZW50IG9uIHRoZW0gKGUuZy4sIEwyVlBOIGFuZCBMM1ZQTikuIFRo
aXMgaXMgZm9yIGEgZG9jdW1lbnQgdGhhdCBoYXMgYWxyZWFkeSBmaW5pc2hlZCBXRyBMYXN0IENh
bGwuIEFkZGl0aW9uYWxseSwgeW91ciBlc3RpbWF0ZSBmb3IgdGhlIHNpemUgb2YgdGhlIGNoYW5n
ZSBhbmQgdGltZSB0byByZWFjaCBzdGFuZGFyZGl6YXRpb24gaXMgYmFzZWQgb24gdGhlcmUgYmVp
bmcgaW1tZWRpYXRlIGNvbnNlbnN1cyBvbiB0aGUgY2hhbmdlcy4gVGhpcyBpcyBwcm9iYWJseSBv
dmVybHkgb3B0aW1pc3RpYyBnaXZlbiB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiB0aGUgcHJvcG9z
ZWQgWUFORyBMaWJyYXJ5IEJJUyBjaGFuZ2VzLiBJ4oCZZCB2b3RlIHRvIHB1Ymxpc2ggdGhlIGV4
aXN0aW5nIGRyYWZ0LiANCg0KSW4gYW55IGNhc2UsIGJlaW5nIGFibGUgdG8gc2VlIHRoZSBwcm9w
b3NlZCBjaGFuZ2VzIEFTQVAgaXMgY3JpdGljYWwuIA0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDEv
MjIvMTgsIDg6NDUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSIgPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToN
Cg0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPiB3cml0ZXM6DQogICAgDQogICAgPiBPbiBGcmksIEphbiAxOSwgMjAxOCBhdCAw
NjowNToxNVBNICswMDAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KICAgID4+IA0KICAgID4+IEhl
bmNlLCBmb3IgbWUsIEkgc2VlIHRoZSBjaG9pY2UgYXM6DQogICAgPj4gMSkgZG8gd2UgcHVibGlz
aCB0aGUgZXhpc3RpbmcgbW9kZWwgbm93IChwZXJoYXBzIGFsc28gbWFyayB0aGUgZHJhZnQgYXMN
CiAgICA+PiBleHBlcmltZW50YWwpIGZvbGxvd2VkIGJ5IGFuIHVwZGF0ZWQgZHJhZnQgd2l0aCB0
aGUgTk1EQSBjb21wYXRpYmxlIG1vZHVsZT8NCiAgICA+PiAyKSBkbyB3ZSBwdWJsaXNoIGJvdGgg
bW9kZWxzIGluIGEgc2luZ2xlIGRyYWZ0IChlLmcuIHdpdGggdGhlIGV4aXN0aW5nIG1vZGVsDQog
ICAgPj4gaW4gYW4gYXBwZW5kaXgpPw0KICAgID4+IDMpIGRvIHdlIG9ubHkgcHVibGlzaCBhIHNp
bmdsZSB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aXRoIGFuIE5NREEgY29tcGxpYW50DQogICAgPj4g
c29sdXRpb24uDQogICAgPj4NCiAgICA+DQogICAgPiBJIHRoaW5rIHRoZSBzaXR1YXRpb24gaXMg
YXMgZm9sbG93cyAobGlrZWx5IG9idmlvdXMgYnV0IGl0IG1heSBoZWxwIHRvDQogICAgPiBtYWtl
IHN1cmUgd2UgYXJlIGFsbCBvbiB0aGUgc2FtZSBwYWdlKToNCiAgICA+DQogICAgPiAtIHRoZSBO
SSBhbmQgTE5FIG1vZGVscyBoYXZlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0bw0KICAgID4gICBJ
LUQuaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50IChhbmQgdGhpcyBtYWtlcyBzZW5zZSBzaW5jZSB0
aGVyZSBhcmUNCiAgICA+ICAgTVVTVCBzZW50ZW5jZXMgaW4gdGhlIEktRCkNCiAgICA+DQogICAg
PiAtIEktRC5pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQgKGxhc3QgdXBkYXRlZCBpbiBPY3RvYmVy
KSBoYXMgbm9ybWF0aXZlDQogICAgPiAgIHJlZmVyZW5jZXMgdG8gUkZDIDc4OTUgKG9sZCBZQU5H
IGxpYnJhcnkpDQogICAgPg0KICAgID4gLSBSRkMgNzg5NSBkb2VzIG5vdCB3b3JrIHdpdGggTk1E
QSwgTk1EQSB3b3JrIG9uIGEgWUFORyBsaWJyYXJ5IHVwZGF0ZQ0KICAgID4gICByZXBsYWNpbmcg
UkZDIDc4OTUNCiAgICA+DQogICAgPiBTbyB0aGUgWUFORyBsaWJyYXJ5IHVwZGF0ZSBpcyBnYXRp
bmcgdGhlIHNjaGVtYSBtb3VudCB1cGRhdGUgd2hpY2ggaXMNCiAgICA+IGdhdGluZyB0aGUgcHVi
bGljYXRpb24gb2YgdGhlIE5JIGFuZCBMTkUgbW9kZWxzLg0KICAgID4NCiAgICA+IEEgcHJvcGVy
IHNvbHV0aW9uIHdvdWxkIGJlIHRvIHByaW9yaXRpemUgd29yayBvbiB0aGUgWUFORyBsaWJyYXJ5
DQogICAgPiB1cGRhdGUgYW5kIHRoZSBzY2hlbWEgbW91bnQgdXBkYXRlLiBJIGFzc3VtZSB0aGF0
IHRoZSBuZXh0IHJldmlzaW9uIG9mDQogICAgPiB0aGUgWUFORyBsaWJyYXJ5IHVwZGF0ZSAoc2F5
IGVuZCBvZiBKYW51YXJ5KSBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsDQogICAgPiBhbmQgcGVy
aGFwcyB0aGUgc2NoZW1hIG1vdW50IGF1dGhvcnMgY2FuIHRha2UgYW4gZWZmb3J0IHRvIGdldCB0
aGF0DQogICAgPiBkb2N1bWVudCB0aGVyZSBhcyB3ZWxsLCBzYXkgYmVnaW5uaW5nIG9mIEZlYnJ1
YXJ5Lg0KICAgIA0KICAgIEkgY29tcGxldGVseSBhZ3JlZS4NCiAgICANCiAgICBMYWRhDQogICAg
DQogICAgPg0KICAgID4gL2pzDQogICAgPg0KICAgID4gLS0gDQogICAgPiBKdWVyZ2VuIFNjaG9l
bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KICAgID4g
UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl
bWVuIHwgR2VybWFueQ0KICAgID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0
cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KICAgID4NCiAgICA+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQogICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgDQogICAgLS0gDQogICAgTGFkaXNsYXYgTGhv
dGthDQogICAgSGVhZCwgQ1ouTklDIExhYnMNCiAgICBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlG
NzZDNjcNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAg
ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo=


From nobody Mon Jan 22 08:21: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 193401272E1 for ; Mon, 22 Jan 2018 08:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 qeUOYrh7UZ4m for ; Mon, 22 Jan 2018 08:21:28 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 4AA40124207 for ; Mon, 22 Jan 2018 08:21:26 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id y26so7442642pfi.10 for ; Mon, 22 Jan 2018 08:21:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=dPDKs0z9ZSHOQzxnG+vhlc9V/7DI6YDhW7GjmmkRh14=; b=agzn6E6Fg80SDmLgzm4IPDOudqlKkAvWXIIuPJgP5TSisJg9EMwfaxD1PO61vV5r48 ISudzJSoBg3WLLwsswhS0gsK3ff2uvXrc5zZRCoIFabeGxrhYWWtYLNgZkNX8YpAfa0f mG+4GaQlVMa6OXIj+auO6Oq9UQocYeE4KdyU34Pp8EnWBH/tgZ5ro7NbAwn1ndzLkRvv zo8sNmJeUoMb1tOXGrN/Gl8pywKofVnffijl08vxidyzIVIOSZJC+9FtuJca/Qw4Vqu9 rwaQq+WmCA/XkA7HQihXrGMmDjbYh/9ywWj/YLs0IQZZu+rApbkQuHbQaImd2X4C3tT8 U0EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=dPDKs0z9ZSHOQzxnG+vhlc9V/7DI6YDhW7GjmmkRh14=; b=SHUhFyTVxwX1RNQmgNB5IxoPZc8EKnPIh6v9PCbtv2qKgwAHfIvgljEVQMLovmddDO lF592ggN+JDLn0X1cB5SUcJvZYpWGzNBZjDqMg7Ww1N6e/+iecJ2RaXG0GJKF4JT6EOR B/UPY+3gkuPV0fXaxp3JFLSwIsOcGSmWLdpYvh83hNjaceryvGqk/Ui/07K29jdWgonV LDhRq3AUw6x1mXSRUmoObd9Y5Z74QQg3CcX7VeBVqKmHLpB8W076a6A/cCuiq/Lc0mSf WOrY6xm2awDX46u/zTh7fogKAVPQg/mBDBVqzHpqJDYaqtKx9I3gi+NNsYj7uYX3s61c 0Q3g==
X-Gm-Message-State: AKwxytfrjAANCnt9XwCQAjTqQm2tQ7Q/jf/Vc3JlcVFAYzgTBJ3vAgFU niZk+Mquz7ZwwOwatLQQvRw=
X-Google-Smtp-Source: AH8x226g+A50DUnYfZRe0o5iez9sk+xHkSIfHCQ9kWirRMcdTaRYrXL0SzrS0lhkPim8qECZ69u48A==
X-Received: by 10.98.23.23 with SMTP id 23mr8883732pfx.179.1516638085717; Mon, 22 Jan 2018 08:21:25 -0800 (PST)
Received: from [192.168.1.25] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id r84sm1520560pfk.92.2018.01.22.08.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 08:21:25 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Mon, 22 Jan 2018 08:21:23 -0800
From: Jeff Tantsura 
To: "Acee Lindem (acee)" , Ladislav Lhotka , Juergen Schoenwaelder , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
CC: "netmod@ietf.org" 
Message-ID: 
Thread-Topic: [netmod] schema mount and YANG library
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:21:33 -0000

+1, with Acee

Cheers,
Jeff

On 1/22/18, 08:18, "netmod on behalf of Acee Lindem (acee)"  wrote:

    Hi Lada,=20
   =20
    My primary concern is that the YANG Schema Mount delay will not only ho=
ld the NI/LNE but all the models that are dependent on them (e.g., L2VPN and=
 L3VPN). This is for a document that has already finished WG Last Call. Addi=
tionally, your estimate for the size of the change and time to reach standar=
dization is based on there being immediate consensus on the changes. This is=
 probably overly optimistic given there was discussion on the proposed YANG =
Library BIS changes. I=E2=80=99d vote to publish the existing draft.=20
   =20
    In any case, being able to see the proposed changes ASAP is critical.=20
   =20
    Thanks,
    Acee
   =20
    On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka"  wrote:
   =20
        Juergen Schoenwaelder  writes=
:
       =20
        > On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
        >>=20
        >> Hence, for me, I see the choice as:
        >> 1) do we publish the existing model now (perhaps also mark the d=
raft as
        >> experimental) followed by an updated draft with the NMDA compati=
ble module?
        >> 2) do we publish both models in a single draft (e.g. with the ex=
isting model
        >> in an appendix)?
        >> 3) do we only publish a single version of the draft with an NMDA=
 compliant
        >> solution.
        >>
        >
        > I think the situation is as follows (likely obvious but it may he=
lp to
        > make sure we are all on the same page):
        >
        > - the NI and LNE models have a normative reference to
        >   I-D.ietf-netmod-schema-mount (and this makes sense since there =
are
        >   MUST sentences in the I-D)
        >
        > - I-D.ietf-netmod-schema-mount (last updated in October) has norm=
ative
        >   references to RFC 7895 (old YANG library)
        >
        > - RFC 7895 does not work with NMDA, NMDA work on a YANG library u=
pdate
        >   replacing RFC 7895
        >
        > So the YANG library update is gating the schema mount update whic=
h is
        > gating the publication of the NI and LNE models.
        >
        > A proper solution would be to prioritize work on the YANG library
        > update and the schema mount update. I assume that the next revisi=
on of
        > the YANG library update (say end of January) is ready for WG last=
 call
        > and perhaps the schema mount authors can take an effort to get th=
at
        > document there as well, say beginning of February.
       =20
        I completely agree.
       =20
        Lada
       =20
        >
        > /js
        >
        > --=20
        > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
        > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Ge=
rmany
        > Fax:   +49 421 200 3103         
        >
        > _______________________________________________
        > netmod mailing list
        > netmod@ietf.org
        > https://www.ietf.org/mailman/listinfo/netmod
       =20
        --=20
        Ladislav Lhotka
        Head, CZ.NIC Labs
        PGP Key ID: 0xB8F92B08A9F76C67
       =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



From nobody Mon Jan 22 08:37: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 077E2126E64 for ; Mon, 22 Jan 2018 08:37:50 -0800 (PST)
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_RP_MATCHES_RCVD=-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 vFmR8hdATKwt for ; Mon, 22 Jan 2018 08:37:47 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046A8124207 for ; Mon, 22 Jan 2018 08:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16728; q=dns/txt; s=iport; t=1516639067; x=1517848667; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=BojCRg2NIi5yY5S0ddOo3YQNLMrhLnXGMKfPOUKPFWc=; b=O1wL8NXwJ+HKNogd7UpUCV1sB7qdCTagYoDDPhmSghHK4kPN8DLyWuMg qhjr78aSlQS3s/5aaMBHpHW4xUMH+6Ua0IDFwtzVkznoiaRg5v/l8Ccms 47ChGPTDjeYiT7A7sfrovQo0O6BRklls0sUyAOfRRx/emJtSHh7XNMb1e E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQB4EmZa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj3N8lleCAgoYC4FegmtPAoUzFAEBAQEBAQEBAWs?= =?us-ascii?q?ohSMBAQEEAQEhDwEFNgsMBAsRBAEBAQICIwMCAicfCQgGAQwGAgEBFooZELUYg?= =?us-ascii?q?ieKLwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+DOoNsgWgpDIFrWDaDLwEBAgG?= =?us-ascii?q?BNhgBAQiDLYJlBYpph0iRSYgTjUiCG4Yfg3Emh06KdYJcgWaIEIE8NiKBUDIaC?= =?us-ascii?q?BsVPYIqhFhAN4gugjwBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,397,1511827200";  d="scan'208";a="1537199"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 16:37:44 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0MGbi0L006086; Mon, 22 Jan 2018 16:37:44 GMT
To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Martin Bjorklund 
Cc: "netmod@ietf.org" 
References: <20180109.163933.49682684192910889.mbj@tail-f.com>  <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> 
From: Benoit Claise 
Message-ID: 
Date: Mon, 22 Jan 2018 17:37:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
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] AD review of draft-ietf-netmod-entity-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:37:50 -0000

Dear all,

Since almost everyone who spoke up in the WG preferred option 2, let's 
go with that one.
Martin, can you please post a new draft version.

This document is on the IESG telechat this Thursday.

Regards, Benoit
> Hi Martin,
>
> We agree with option 2.
>
> Regards, Bart
>
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, January 11, 2018 2:47 PM
> To: Bogaert, Bart (Nokia - BE/Antwerp) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
>
> Hi,
>
> To summarize this, I think we have three options for the three nodes 'model-name', 'mfg-name', and 'serial-num':
>
>    1.  Do nothing (keep the nodes as config true).
>
>    2.  Make these three nodes config false (fairly simple change).
>        (vendors can augment w/ their own config true nodes).
>
>    3.  Add three new nodes for the configured values.
>
>
> After thinking about this some more, and discussing with Benoit, I think the best path forward is to do 2, i.e., mark the nodes 'model-name', 'mfg-name', and 'serial-num' as "config false".  As such they would not be configurable, and thus contain the detected values.
> If no value is detected, the node is not present.
>
> Note that 1 or 3 can be done in a future update to this module (or by a vendor).
>
>
> /martin
>
>
> Martin Bjorklund  wrote:
>> Hi,
>>
>> "Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
>>> Hi,
>>>
>>> --- snip ---
>>>
>>>> state.”, so the above sentence only applies for the second case below.
>>> Ok.
>>>
>>>> 2. The second case is that something is detected but it can’t be read.
>>>> We do not see a reason to use the value configured for the leafs
>>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in
>>>> the configuration data.  These leafs are defined as optional so
>>>> why would we report something entered by an operator in the
>>>> operational datastore that intends to report on what is detected?
>>>> Is it not better to not report them at all?  In an NMDA context it
>>>> would be possible to have a different value (or no value at all)
>>>> for certain leafs while there is something in the running/intended datastore.
>>> The normal NMDA procedure for a configuration leaf is to repeat it
>>> in operational state.  This is then the "applied configuration".
>>> I don't think we should have a special rule for these leafs.
>>>
>>> This also means that a client that just wants to read all the serial
>>> numbers can do so from one place, the operational state, regardless
>>> of how they came into existance.
>>>
>>> [Bogaert, Bart ]
>>>
>>> We do understand that a target of NMDA is to read out the actually
>>> applied data in one request.  But the result should not be
>>> confusion. A key word is “applied”.
>>>
>>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains
>>> (I put a part of the section between ***):
>>> The datastore schema for  MUST be a superset of the
>>> combined datastore schema used in all configuration datastores
>>> except that configuration data nodes supported in a configuration
>>> datastore ***MAY be omitted from  if a server is not
>>> able to accurately report them ***.
>> Note that this text talks about the *schema*.  It is intended for
>> servers to migrate to NMDA without having to instrument all config
>> nodes in  immediately.  If you apply this to
>> ietf-hardware, it could be a server that implements the node
>> "serial-num" in config, but not in  (which would be
>> weird).
>>
>>> For example, it is expected that the value of multiple leafs need to
>>> be a consistent set, e.g. the mfg-name, the model-name, and the
>>> serial-num.
>>> Suppose we have a use case in which a hardware component is
>>> planned/configured (e.g. a board supporting DSL interfaces) but a
>>> different one is plugged (e.g. a board supporting ethernet
>>> interfaces).
>>> Suppose it is possible to read some fields on the detected component
>>> but due to an issue not to read other fields.
>>> If in that case the operational datastore will be completed with the
>>> data taken from the running datastore, then the presented view might
>>> be inconsistent.
>> This is true for other similar nodes as well - "asset-id" and "uri".
>>
>>> The question is also: what data is applied? Our assumption: if there
>>> is a mismatch between detected versus configured hardware, then the
>>> interface/service related data that is configured consistently with
>>> the planned hardware is not applied on the mismatching hardware.
>>> I.e. the detected hardware is not brought in service so not
>>> ‘applied’, the operational datastore only (accurately) reports on
>>> what is detected.
>> If there is a mismatch and the server doesn't apply the configured
>> values, then obviously the configured 'mfg-name' etc are not copied to
>> .
>>
>>> We do not see this as a special rule for this data but rather would
>>> apply a general rule:
>>> -	if there is a ‘missing resource’, then the data is not reported in the
>>>   	operational datastore.
>>> -	If the server is not able to report accurately, then the data is
>>>   	omitted from the operational
>> I think that if you want complete separation between the values of
>> 'mfg-name', 'model-name', and 'serial-num' in configuration and
>> operational state, then these should be modelled as separate leafs.
>> We should have a config false leaf 'serial-num' that only contains the
>> detected value (if found), and a config true leaf 'config-serial-num'
>> or something, that contains the configured serial number.
>>
>> But if this is the case, I wonder if it wouldn't be better to leave
>> such additional config objects to vendors, and simply make these three
>> nodes config false in ietf-hardware.
>>
>>
>> /martin
>>
>>> Regards, Bart
>>>
>>> /martin
>>>
>>>
>>>> Best regards, Bart
>>>>
>>>> -----Original Message-----
>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
>>>> Wilton
>>>> Sent: Thursday, December 21, 2017 4:14 PM
>>>> To: Martin Bjorklund ; netmod@ietf.org
>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
>>>>
>>>> Hi Martin,
>>>>
>>>>
>>>> On 21/12/2017 11:37, Martin Bjorklund wrote:
>>>>> Hi,
>>>>>
>>>>> I need WG input on this issue.  The question is how to handle
>>>>> 'serial-num', 'mfg-name', and 'model-name'.  I think they should
>>>>> all be treated the same.  Based on previous WG discussion (see
>>>>> e.g. the mail thread "draft-ietf-netmod-entity issue #13"), I
>>>>> think they should all be configurable, but the configured value
>>>>> is only used in operational state if the system cannot read it from the hardware.
>>>> I think that this approach is probably OK:
>>>>    - The client can always see the real value if it is available.
>>>>    - If it is not available then they can assign a value via
>>>> configuration.
>>>>
>>>> I was also considering an alternative approach of having a
>>>> separate set of config false leaves for the "burnt in values".
>>>> And then having the configurable leaves always override the
>>>> default operational values. E.g. similar to how an interface MAC
>>>> address would expect to be handled.
>>>>
>>>> But one set of leaves is probably sufficient.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>> So I suggest the following changes:
>>>>>
>>>>> OLD:
>>>>>
>>>>>         leaf serial-num {
>>>>>           type string;
>>>>>           config false;
>>>>>           description
>>>>>             "The vendor-specific serial number string for the
>>>>>              component.  The preferred value is the serial number
>>>>>              string actually printed on the component itself (if
>>>>>              present).";
>>>>>           reference "RFC 6933: entPhysicalSerialNum";
>>>>>         }
>>>>>
>>>>> NEW:
>>>>>
>>>>>         leaf serial-num {
>>>>>           type string;
>>>>>           description
>>>>>             "The vendor-specific serial number string for the
>>>>>              component.  The preferred value is the serial number
>>>>>              string actually printed on the component itself (if
>>>>>              present).
>>>>>
>>>>>              This leaf can be configured.  There are two use cases for
>>>>>              this; as a 'post-it' note if the server cannot determine
>>>>>              this value from the component, or when pre-provisioning a
>>>>>              component.
>>>>>
>>>>>              If the server can determine the serial number from the
>>>>>              component, then that value is always used in operational
>>>>>              state, even if another value has been configured.";
>>>>>           reference "RFC 6933: entPhysicalSerialNum";
>>>>>         }
>>>>>
>>>>> And corresponding text for 'mfg-name' and 'model-name'.
>>>>>
>>>>> And also:
>>>>>
>>>>> OLD:
>>>>>
>>>>>            When the server detects a new hardware component, it
>>>>>            initializes a list entry in the operational state.
>>>>>
>>>>>            If the server does not support configuration of hardware
>>>>>            components, list entries in the operational state are
>>>>>            initialized with values for all nodes as detected by the
>>>>>            implementation.
>>>>>
>>>>>            Otherwise, the following procedure is followed:
>>>>>
>>>>>              1. If there is an entry in the /hardware/component list in
>>>>>                 the intended configuration with values for the nodes
>>>>>                 'class', 'parent', 'parent-rel-pos' that are equal to
>>>>>                 the detected values, then:
>>>>>
>>>>>              1a. If the configured entry has a value for 'mfg-name'
>>>>>                  that is equal to the detected value, or if the
>>>>>                  'mfg-name' value cannot be detected, then the list
>>>>>                  entry in the operational state is initialized with the
>>>>>                  configured values for all configured nodes, including
>>>>>                  the 'name'.
>>>>>
>>>>>                  Otherwise, the list entry in the operational state is
>>>>>                  initialized with values for all nodes as detected by
>>>>>                  the implementation.  The implementation may raise an
>>>>>                  alarm that informs about the 'mfg-name' mismatch
>>>>>                  condition.  How this is done is outside the scope of
>>>>>                  this document.
>>>>>
>>>>>              1b. Otherwise (i.e., there is no matching configuration
>>>>>                  entry), the list entry in the operational state is
>>>>>                  initialized with values for all nodes as detected by
>>>>>                  the implementation.
>>>>>
>>>>>            If the /hardware/component list in the intended
>>>>>            configuration is modified, then the system MUST behave as if
>>>>>            it re-initializes itself, and follow the procedure in
>>>>> (1).";
>>>>>
>>>>> NEW:
>>>>>
>>>>>            When the server detects a new hardware component, it
>>>>>            initializes a list entry in the operational state.
>>>>>
>>>>>            If the server does not support configuration of hardware
>>>>>            components, list entries in the operational state are
>>>>>            initialized with values for all nodes as detected by the
>>>>>            implementation.
>>>>>
>>>>>            Otherwise, the following procedure is followed:
>>>>>
>>>>>              1. If there is an entry in the /hardware/component list in
>>>>>                 the intended configuration with values for the nodes
>>>>>                 'class', 'parent', 'parent-rel-pos' that are equal to
>>>>>                 the detected values, then the list entry in operational
>>>>>                 state is initialized with the configured values,
>>>>>                 including the 'name'.  The leafs 'serial-num',
>>>>>                 'mfg-name', and 'model-name' are treated specially; see
>>>>>                 their descriptions for details.
>>>>>
>>>>>              2. Otherwise (i.e., there is no matching configuration
>>>>>                 entry), the list entry in the operational state is
>>>>>                 initialized with values for all nodes as detected by
>>>>>                 the implementation.
>>>>>
>>>>>            If the /hardware/component list in the intended
>>>>>            configuration is modified, then the system MUST behave as if
>>>>>            it re-initializes itself, and follow the procedure in
>>>>> (1).";
>>>>>
>>>>>
>>>>>
>>>>> /martin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Benoit Claise  wrote:
>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
>>>>>>> Benoit Claise  wrote:
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Only kept the relevant excerpts.
>>>>>>>>>> - Some objects are read-write in RFC6933:
>>>>>>>>>>           entPhysicalSerialNum
>>>>>>>>>>           entPhysicalAlias
>>>>>>>>>>           entPhysicalAssetID
>>>>>>>>>>           entPhysicalUris
>>>>>>>>>>
>>>>>>>>>> For example, entPhysicalSerialNum being read-write always
>>>>>>>>>> bothered me.
>>>>>>>>>> serial-num is now "config false", which is a good news IMO.
>>>>>>>>> Actually, this was not the intention.  In
>>>>>>>>> draft-ietf-netmod-entity-03 this is configurable.  I missed
>>>>>>>>> this in the conversion to NMDA.
>>>>>>>> Ah. So no good news in this case...
>>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only
>>>>>>>>>> in RFC6933, while it's "config true" in
>>>>>>>>>> draft-ietf-netmod-entity
>>>>>>>>> Yes, this was added per request from the WG.  See e.g. the
>>>>>>>>> thread "draft-ietf-netmod-entity issue #13".
>>>>>>>> Sure. It was mainly an observation.
>>>>>>>>> However, I think that what we have now is probably not correct.
>>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
>>>>>>>>> should be config true, and the description of list 'component'
>>>>>>>>> updated to reflect that all these tree leafs are handled the same way.
>>>>>>>>>
>>>>>>>>> I would like to know what the WG thinks about this.
>>>>>>>> Talking as a contributor this time.
>>>>>>>> It seems that inventory management is kind of broken when
>>>>>>>> someone can change 'serial-num', 'mfg-name', and 'model-name.
>>>>>>> They can't really change them.  The configured values are only
>>>>>>> used (i.e. visible in the operational state) if the device
>>>>>>> cannot detect them automatically.  I.e., they work as "post-it" notes only.
>>>>>> If I look at, for example, the mfg-name, description, this is
>>>>>> not what it says.
>>>>>>
>>>>>>      leaf mfg-name {
>>>>>>              type string;
>>>>>>              description
>>>>>>                "The name of the manufacturer of this physical component.
>>>>>>                 The preferred value is the manufacturer name string
>>>>>>                 actually printed on the component itself (if present).
>>>>>>
>>>>>>                 Note that comparisons between instances of the model-name,
>>>>>>                 firmware-rev, software-rev, and the serial-num nodes are
>>>>>>                 only meaningful amongst component with the same value of
>>>>>>                 mfg-name.
>>>>>>
>>>>>>                 If the manufacturer name string associated with the
>>>>>>                 physical component is unknown to the server, then this
>>>>>>                 node is not instantiated.";
>>>>>>              reference "RFC 6933 :
>>>>>>              entPhysicalMfgName";
>>>>>>
>>>>>> Regards, Benoit
>>>>>>
>>>>>>> /martin
>>>>>>> .
>>>>>>>
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jan 22 08:44:58 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 E093512751F; Mon, 22 Jan 2018 08:44:51 -0800 (PST)
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.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151663949186.8203.7263205071438283746@ietfa.amsl.com>
Date: Mon, 22 Jan 2018 08:44:51 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-entity-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:44: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           : A YANG Data Model for Hardware Management
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Jie Dong
                          Dan Romascanu
	Filename        : draft-ietf-netmod-entity-08.txt
	Pages           : 56
	Date            : 2018-01-22

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-08
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-08


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 Jan 22 08:45: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 43471127871 for ; Mon, 22 Jan 2018 08:45:10 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 C-38ypSyha8t for ; Mon, 22 Jan 2018 08:45:03 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995A4127775 for ; Mon, 22 Jan 2018 08:45:00 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 695AE65B; Mon, 22 Jan 2018 17:44:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ObuQsUolnrgs; Mon, 22 Jan 2018 17:44:56 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Jan 2018 17:44:59 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 506D72014B; Mon, 22 Jan 2018 17:44:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dOIw3t5gAg8g; Mon, 22 Jan 2018 17:44:58 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A180D20149; Mon, 22 Jan 2018 17:44:58 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 85CBA422472E; Mon, 22 Jan 2018 17:44:57 +0100 (CET)
Date: Mon, 22 Jan 2018 17:44:57 +0100
From: Juergen Schoenwaelder 
To: "Acee Lindem (acee)" 
Cc: Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
Message-ID: <20180122164457.megfkkubdowexa7e@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:45:10 -0000

Acee,

the documents that have already finished WG Last Call have a normative
reference on schema mount, which has not yet finished WG Last Call as
far as I recall. I think the RFC editor does not publish a document
with a missing normative reference. I continue to believe that the
time difference between doing the right thing and doing something
faster using definition we are in the process to deprecate is really
small. But of course, I may be entirely wrong.

/js

On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote:
> Hi Lada, 
> 
> My primary concern is that the YANG Schema Mount delay will not only hold the NI/LNE but all the models that are dependent on them (e.g., L2VPN and L3VPN). This is for a document that has already finished WG Last Call. Additionally, your estimate for the size of the change and time to reach standardization is based on there being immediate consensus on the changes. This is probably overly optimistic given there was discussion on the proposed YANG Library BIS changes. I’d vote to publish the existing draft. 
> 
> In any case, being able to see the proposed changes ASAP is critical. 
> 
> Thanks,
> Acee
> 
> On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka"  wrote:
> 
>     Juergen Schoenwaelder  writes:
>     
>     > On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
>     >> 
>     >> Hence, for me, I see the choice as:
>     >> 1) do we publish the existing model now (perhaps also mark the draft as
>     >> experimental) followed by an updated draft with the NMDA compatible module?
>     >> 2) do we publish both models in a single draft (e.g. with the existing model
>     >> in an appendix)?
>     >> 3) do we only publish a single version of the draft with an NMDA compliant
>     >> solution.
>     >>
>     >
>     > I think the situation is as follows (likely obvious but it may help to
>     > make sure we are all on the same page):
>     >
>     > - the NI and LNE models have a normative reference to
>     >   I-D.ietf-netmod-schema-mount (and this makes sense since there are
>     >   MUST sentences in the I-D)
>     >
>     > - I-D.ietf-netmod-schema-mount (last updated in October) has normative
>     >   references to RFC 7895 (old YANG library)
>     >
>     > - RFC 7895 does not work with NMDA, NMDA work on a YANG library update
>     >   replacing RFC 7895
>     >
>     > So the YANG library update is gating the schema mount update which is
>     > gating the publication of the NI and LNE models.
>     >
>     > A proper solution would be to prioritize work on the YANG library
>     > update and the schema mount update. I assume that the next revision of
>     > the YANG library update (say end of January) is ready for WG last call
>     > and perhaps the schema mount authors can take an effort to get that
>     > document there as well, say beginning of February.
>     
>     I completely agree.
>     
>     Lada
>     
>     >
>     > /js
>     >
>     > -- 
>     > 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
>     
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>     
>     _______________________________________________
>     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 Mon Jan 22 08:58: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 5687A1273B1 for ; Mon, 22 Jan 2018 08:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 j_i9IolQzHj4 for ; Mon, 22 Jan 2018 08:58:18 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D137412778E for ; Mon, 22 Jan 2018 08:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6536; q=dns/txt; s=iport; t=1516640297; x=1517849897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jO4OT40nEQ/YO+En47HXWaql7hg6cY7Ers4+BMmay1E=; b=OZ1uY+zUgMtgjacMDQt6FdDFa9BjUboa5u4KCN2tzZ/X45zsU0IvsMpc YNCiQjMKLCgjLq+u4sS+YJ+1gJzSDBtanrF8O9V5SJUVuLH9eT3OKdEIY vcfYVG3ylDGssbu1I/E07ewlny328JRY+uk5fNe7MRBCqk5g3v2+6b/4m o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAgDKF2Za/5JdJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQmZ0JweDVookjjA1ggKXPoIXChgNhEdPAhqEVj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFJAEBBAEBIRE6Cw4CAgEIDgIIAgImAgICGQwLFRACBA4FG4oYELR+g?= =?us-ascii?q?ieKLwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYEKgzqCFYM/KQyCeYJRXgEBAoI?= =?us-ascii?q?GCiaCUDGCNAWjegKIEY1IghuSBIp1glyJSQIRGQGBOwEfOYFQbxU9KgGBf4RXe?= =?us-ascii?q?IlTgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,397,1511827200"; d="scan'208";a="335902364"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 16:58:16 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0MGwGQ0017617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2018 16:58:16 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 22 Jan 2018 11:58:15 -0500
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; Mon, 22 Jan 2018 11:58:15 -0500
From: "Acee Lindem (acee)" 
To: Juergen Schoenwaelder 
CC: Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount and YANG library
Thread-Index: AQHTjpmkXZcjBoxLfUed9b6huAMBJ6OAd0qA//+v6QA=
Date: Mon, 22 Jan 2018 16:58:15 +0000
Message-ID: 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz>  <20180122164457.megfkkubdowexa7e@elstar.local>
In-Reply-To: <20180122164457.megfkkubdowexa7e@elstar.local>
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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9788AC829869F84E885B937A4901A20F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 16:58:24 -0000

SXQgd2FzIFdHIExhc3QgQ2FsbOKAmWVkOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy
Y2gvbXNnL25ldG1vZC9jc1V2czY0MDhFbjB5WS12YXB5VTNJRmNKcVENCg0KQW5kIGl0IHdhcyBj
bG9zZWQ6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kL2diWEU0
TGUxSV8zWTVvYU5ucGpZb1paWjRsdw0KDQpIb3dldmVyLCBpdCBtYXkgbm90IGhhdmUgZXZlciBj
b21wbGV0ZWQuDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDEvMjIvMTgsIDExOjQ1IEFNLCAiSnVl
cmdlbiBTY2hvZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl
PiB3cm90ZToNCg0KICAgIEFjZWUsDQogICAgDQogICAgdGhlIGRvY3VtZW50cyB0aGF0IGhhdmUg
YWxyZWFkeSBmaW5pc2hlZCBXRyBMYXN0IENhbGwgaGF2ZSBhIG5vcm1hdGl2ZQ0KICAgIHJlZmVy
ZW5jZSBvbiBzY2hlbWEgbW91bnQsIHdoaWNoIGhhcyBub3QgeWV0IGZpbmlzaGVkIFdHIExhc3Qg
Q2FsbCBhcw0KICAgIGZhciBhcyBJIHJlY2FsbC4gSSB0aGluayB0aGUgUkZDIGVkaXRvciBkb2Vz
IG5vdCBwdWJsaXNoIGEgZG9jdW1lbnQNCiAgICB3aXRoIGEgbWlzc2luZyBub3JtYXRpdmUgcmVm
ZXJlbmNlLiBJIGNvbnRpbnVlIHRvIGJlbGlldmUgdGhhdCB0aGUNCiAgICB0aW1lIGRpZmZlcmVu
Y2UgYmV0d2VlbiBkb2luZyB0aGUgcmlnaHQgdGhpbmcgYW5kIGRvaW5nIHNvbWV0aGluZw0KICAg
IGZhc3RlciB1c2luZyBkZWZpbml0aW9uIHdlIGFyZSBpbiB0aGUgcHJvY2VzcyB0byBkZXByZWNh
dGUgaXMgcmVhbGx5DQogICAgc21hbGwuIEJ1dCBvZiBjb3Vyc2UsIEkgbWF5IGJlIGVudGlyZWx5
IHdyb25nLg0KICAgIA0KICAgIC9qcw0KICAgIA0KICAgIE9uIE1vbiwgSmFuIDIyLCAyMDE4IGF0
IDA0OjE4OjE1UE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCiAgICA+IEhpIExh
ZGEsIA0KICAgID4gDQogICAgPiBNeSBwcmltYXJ5IGNvbmNlcm4gaXMgdGhhdCB0aGUgWUFORyBT
Y2hlbWEgTW91bnQgZGVsYXkgd2lsbCBub3Qgb25seSBob2xkIHRoZSBOSS9MTkUgYnV0IGFsbCB0
aGUgbW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGVtIChlLmcuLCBMMlZQTiBhbmQgTDNW
UE4pLiBUaGlzIGlzIGZvciBhIGRvY3VtZW50IHRoYXQgaGFzIGFscmVhZHkgZmluaXNoZWQgV0cg
TGFzdCBDYWxsLiBBZGRpdGlvbmFsbHksIHlvdXIgZXN0aW1hdGUgZm9yIHRoZSBzaXplIG9mIHRo
ZSBjaGFuZ2UgYW5kIHRpbWUgdG8gcmVhY2ggc3RhbmRhcmRpemF0aW9uIGlzIGJhc2VkIG9uIHRo
ZXJlIGJlaW5nIGltbWVkaWF0ZSBjb25zZW5zdXMgb24gdGhlIGNoYW5nZXMuIFRoaXMgaXMgcHJv
YmFibHkgb3Zlcmx5IG9wdGltaXN0aWMgZ2l2ZW4gdGhlcmUgd2FzIGRpc2N1c3Npb24gb24gdGhl
IHByb3Bvc2VkIFlBTkcgTGlicmFyeSBCSVMgY2hhbmdlcy4gSeKAmWQgdm90ZSB0byBwdWJsaXNo
IHRoZSBleGlzdGluZyBkcmFmdC4gDQogICAgPiANCiAgICA+IEluIGFueSBjYXNlLCBiZWluZyBh
YmxlIHRvIHNlZSB0aGUgcHJvcG9zZWQgY2hhbmdlcyBBU0FQIGlzIGNyaXRpY2FsLiANCiAgICA+
IA0KICAgID4gVGhhbmtzLA0KICAgID4gQWNlZQ0KICAgID4gDQogICAgPiBPbiAxLzIyLzE4LCA4
OjQ1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiIDxuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQogICAgPiAN
CiAgICA+ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZT4gd3JpdGVzOg0KICAgID4gICAgIA0KICAgID4gICAgID4gT24gRnJpLCBK
YW4gMTksIDIwMTggYXQgMDY6MDU6MTVQTSArMDAwMCwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCiAg
ICA+ICAgICA+PiANCiAgICA+ICAgICA+PiBIZW5jZSwgZm9yIG1lLCBJIHNlZSB0aGUgY2hvaWNl
IGFzOg0KICAgID4gICAgID4+IDEpIGRvIHdlIHB1Ymxpc2ggdGhlIGV4aXN0aW5nIG1vZGVsIG5v
dyAocGVyaGFwcyBhbHNvIG1hcmsgdGhlIGRyYWZ0IGFzDQogICAgPiAgICAgPj4gZXhwZXJpbWVu
dGFsKSBmb2xsb3dlZCBieSBhbiB1cGRhdGVkIGRyYWZ0IHdpdGggdGhlIE5NREEgY29tcGF0aWJs
ZSBtb2R1bGU/DQogICAgPiAgICAgPj4gMikgZG8gd2UgcHVibGlzaCBib3RoIG1vZGVscyBpbiBh
IHNpbmdsZSBkcmFmdCAoZS5nLiB3aXRoIHRoZSBleGlzdGluZyBtb2RlbA0KICAgID4gICAgID4+
IGluIGFuIGFwcGVuZGl4KT8NCiAgICA+ICAgICA+PiAzKSBkbyB3ZSBvbmx5IHB1Ymxpc2ggYSBz
aW5nbGUgdmVyc2lvbiBvZiB0aGUgZHJhZnQgd2l0aCBhbiBOTURBIGNvbXBsaWFudA0KICAgID4g
ICAgID4+IHNvbHV0aW9uLg0KICAgID4gICAgID4+DQogICAgPiAgICAgPg0KICAgID4gICAgID4g
SSB0aGluayB0aGUgc2l0dWF0aW9uIGlzIGFzIGZvbGxvd3MgKGxpa2VseSBvYnZpb3VzIGJ1dCBp
dCBtYXkgaGVscCB0bw0KICAgID4gICAgID4gbWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNh
bWUgcGFnZSk6DQogICAgPiAgICAgPg0KICAgID4gICAgID4gLSB0aGUgTkkgYW5kIExORSBtb2Rl
bHMgaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8NCiAgICA+ICAgICA+ICAgSS1ELmlldGYt
bmV0bW9kLXNjaGVtYS1tb3VudCAoYW5kIHRoaXMgbWFrZXMgc2Vuc2Ugc2luY2UgdGhlcmUgYXJl
DQogICAgPiAgICAgPiAgIE1VU1Qgc2VudGVuY2VzIGluIHRoZSBJLUQpDQogICAgPiAgICAgPg0K
ICAgID4gICAgID4gLSBJLUQuaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50IChsYXN0IHVwZGF0ZWQg
aW4gT2N0b2JlcikgaGFzIG5vcm1hdGl2ZQ0KICAgID4gICAgID4gICByZWZlcmVuY2VzIHRvIFJG
QyA3ODk1IChvbGQgWUFORyBsaWJyYXJ5KQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+IC0gUkZD
IDc4OTUgZG9lcyBub3Qgd29yayB3aXRoIE5NREEsIE5NREEgd29yayBvbiBhIFlBTkcgbGlicmFy
eSB1cGRhdGUNCiAgICA+ICAgICA+ICAgcmVwbGFjaW5nIFJGQyA3ODk1DQogICAgPiAgICAgPg0K
ICAgID4gICAgID4gU28gdGhlIFlBTkcgbGlicmFyeSB1cGRhdGUgaXMgZ2F0aW5nIHRoZSBzY2hl
bWEgbW91bnQgdXBkYXRlIHdoaWNoIGlzDQogICAgPiAgICAgPiBnYXRpbmcgdGhlIHB1YmxpY2F0
aW9uIG9mIHRoZSBOSSBhbmQgTE5FIG1vZGVscy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBB
IHByb3BlciBzb2x1dGlvbiB3b3VsZCBiZSB0byBwcmlvcml0aXplIHdvcmsgb24gdGhlIFlBTkcg
bGlicmFyeQ0KICAgID4gICAgID4gdXBkYXRlIGFuZCB0aGUgc2NoZW1hIG1vdW50IHVwZGF0ZS4g
SSBhc3N1bWUgdGhhdCB0aGUgbmV4dCByZXZpc2lvbiBvZg0KICAgID4gICAgID4gdGhlIFlBTkcg
bGlicmFyeSB1cGRhdGUgKHNheSBlbmQgb2YgSmFudWFyeSkgaXMgcmVhZHkgZm9yIFdHIGxhc3Qg
Y2FsbA0KICAgID4gICAgID4gYW5kIHBlcmhhcHMgdGhlIHNjaGVtYSBtb3VudCBhdXRob3JzIGNh
biB0YWtlIGFuIGVmZm9ydCB0byBnZXQgdGhhdA0KICAgID4gICAgID4gZG9jdW1lbnQgdGhlcmUg
YXMgd2VsbCwgc2F5IGJlZ2lubmluZyBvZiBGZWJydWFyeS4NCiAgICA+ICAgICANCiAgICA+ICAg
ICBJIGNvbXBsZXRlbHkgYWdyZWUuDQogICAgPiAgICAgDQogICAgPiAgICAgTGFkYQ0KICAgID4g
ICAgIA0KICAgID4gICAgID4NCiAgICA+ICAgICA+IC9qcw0KICAgID4gICAgID4NCiAgICA+ICAg
ICA+IC0tIA0KICAgID4gICAgID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv
YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICA+ICAgICA+IFBob25lOiArNDkgNDIxIDIw
MCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCiAg
ICA+ICAgICA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3Lmph
Y29icy11bml2ZXJzaXR5LmRlLz4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgID4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KICAgID4gICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiAgICAgPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgID4gICAgIA0K
ICAgID4gICAgIC0tIA0KICAgID4gICAgIExhZGlzbGF2IExob3RrYQ0KICAgID4gICAgIEhlYWQs
IENaLk5JQyBMYWJzDQogICAgPiAgICAgUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQog
ICAgPiAgICAgDQogICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCiAgICA+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiAgICAgbmV0
bW9kQGlldGYub3JnDQogICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCiAgICA+ICAgICANCiAgICA+IA0KICAgIA0KICAgIC0tIA0KICAgIEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI
DQogICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3
NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAg
PGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCiAgICANCg0K


From nobody Mon Jan 22 09:44: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 2293A127863 for ; Mon, 22 Jan 2018 09:44:52 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 CfIfVH4mV5E3 for ; Mon, 22 Jan 2018 09:44:50 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35021205F0 for ; Mon, 22 Jan 2018 09:44:49 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AFFC7EFE; Mon, 22 Jan 2018 18:44:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id pqxePrvxLxXh; Mon, 22 Jan 2018 18:44:45 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Jan 2018 18:44:48 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67C5620149; Mon, 22 Jan 2018 18:44:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0aEMTr5-QRGa; Mon, 22 Jan 2018 18:44:47 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E0C120147; Mon, 22 Jan 2018 18:44:47 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6B5BB4224989; Mon, 22 Jan 2018 18:44:45 +0100 (CET)
Date: Mon, 22 Jan 2018 18:44:45 +0100
From: Juergen Schoenwaelder 
To: "Acee Lindem (acee)" 
Cc: Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
Message-ID: <20180122174445.bsfdh3dqzw54m2lw@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz>  <20180122164457.megfkkubdowexa7e@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 17:44:52 -0000

Thanks. The longer WG last call thread started with Rob's message in
which he also asked about alignment with the YANG library update
(posted November 2nd). So the document is in a limbo state since
November 6th.

/js

On Mon, Jan 22, 2018 at 04:58:15PM +0000, Acee Lindem (acee) wrote:
> It was WG Last Call’ed: https://mailarchive.ietf.org/arch/msg/netmod/csUvs6408En0yY-vapyU3IFcJqQ
> 
> And it was closed: https://mailarchive.ietf.org/arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw
> 
> However, it may not have ever completed.
> 
> Thanks,
> Acee 
> 
> On 1/22/18, 11:45 AM, "Juergen Schoenwaelder"  wrote:
> 
>     Acee,
>     
>     the documents that have already finished WG Last Call have a normative
>     reference on schema mount, which has not yet finished WG Last Call as
>     far as I recall. I think the RFC editor does not publish a document
>     with a missing normative reference. I continue to believe that the
>     time difference between doing the right thing and doing something
>     faster using definition we are in the process to deprecate is really
>     small. But of course, I may be entirely wrong.
>     
>     /js
>     
>     On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote:
>     > Hi Lada, 
>     > 
>     > My primary concern is that the YANG Schema Mount delay will not only hold the NI/LNE but all the models that are dependent on them (e.g., L2VPN and L3VPN). This is for a document that has already finished WG Last Call. Additionally, your estimate for the size of the change and time to reach standardization is based on there being immediate consensus on the changes. This is probably overly optimistic given there was discussion on the proposed YANG Library BIS changes. I’d vote to publish the existing draft. 
>     > 
>     > In any case, being able to see the proposed changes ASAP is critical. 
>     > 
>     > Thanks,
>     > Acee
>     > 
>     > On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka"  wrote:
>     > 
>     >     Juergen Schoenwaelder  writes:
>     >     
>     >     > On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
>     >     >> 
>     >     >> Hence, for me, I see the choice as:
>     >     >> 1) do we publish the existing model now (perhaps also mark the draft as
>     >     >> experimental) followed by an updated draft with the NMDA compatible module?
>     >     >> 2) do we publish both models in a single draft (e.g. with the existing model
>     >     >> in an appendix)?
>     >     >> 3) do we only publish a single version of the draft with an NMDA compliant
>     >     >> solution.
>     >     >>
>     >     >
>     >     > I think the situation is as follows (likely obvious but it may help to
>     >     > make sure we are all on the same page):
>     >     >
>     >     > - the NI and LNE models have a normative reference to
>     >     >   I-D.ietf-netmod-schema-mount (and this makes sense since there are
>     >     >   MUST sentences in the I-D)
>     >     >
>     >     > - I-D.ietf-netmod-schema-mount (last updated in October) has normative
>     >     >   references to RFC 7895 (old YANG library)
>     >     >
>     >     > - RFC 7895 does not work with NMDA, NMDA work on a YANG library update
>     >     >   replacing RFC 7895
>     >     >
>     >     > So the YANG library update is gating the schema mount update which is
>     >     > gating the publication of the NI and LNE models.
>     >     >
>     >     > A proper solution would be to prioritize work on the YANG library
>     >     > update and the schema mount update. I assume that the next revision of
>     >     > the YANG library update (say end of January) is ready for WG last call
>     >     > and perhaps the schema mount authors can take an effort to get that
>     >     > document there as well, say beginning of February.
>     >     
>     >     I completely agree.
>     >     
>     >     Lada
>     >     
>     >     >
>     >     > /js
>     >     >
>     >     > -- 
>     >     > 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
>     >     
>     >     -- 
>     >     Ladislav Lhotka
>     >     Head, CZ.NIC Labs
>     >     PGP Key ID: 0xB8F92B08A9F76C67
>     >     
>     >     _______________________________________________
>     >     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         
>     
> 

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


From nobody Mon Jan 22 11:14: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 84E4812700F for ; Mon, 22 Jan 2018 11:14:16 -0800 (PST)
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_RP_MATCHES_RCVD=-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 SDyau4tlXkZU for ; Mon, 22 Jan 2018 11:14:14 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3501E126D45 for ; Mon, 22 Jan 2018 11:14:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17000; q=dns/txt; s=iport; t=1516648453; x=1517858053; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nlYu1EO+trTofw7IW/RQNIyViQ5SAIdUcVWiP+kxQI8=; b=UGkjV9XJekyFMOlxv2YxDee6XPCQFmJCIKo6hoY4nlHdq7BoFiIO1nPV fzclmb75JD/T/yIjR+qg0gNG6OUgdoOEzU/9takZkV7WbawJRUzJuorTk oWrBtyqa/nP37db/0i5AXCS7Jh2SqObsK7Hz1YDCowdLB57i5fiEjcJPF g=;
X-Files: ietf-pf.diffs, acl.diffs, signature.asc : 656, 2284, 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAQDSNmZa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj0EykWqFaYICBwMYAQqBOQGDD08ChUgUAQEBAQE?= =?us-ascii?q?BAQEBayiFJAEBBAEBIUsbCw4KKgICAiUwBgEMBgIBAYovELUAgicmihABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEOCgWESYV9gwWDLwEBAoE8ARIBNhWCa4JlBaN6hF2?= =?us-ascii?q?CMY5NghuGH4Nxh3SXR4E8NiJgcDIaCBsVPYIqhFhAN4gtgjwBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,397,1511827200";  d="asc'?scan'208,217";a="1539115"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 19:14:11 +0000
Received: from [10.61.198.231] ([10.61.198.231]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0MJEArd028397; Mon, 22 Jan 2018 19:14:10 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
From: Eliot Lear 
Message-ID: <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
Date: Mon, 22 Jan 2018 20:14:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8qmQ6caAFGo826vM0g4PnTRIo4dLisDNp"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 19:14:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8qmQ6caAFGo826vM0g4PnTRIo4dLisDNp
Content-Type: multipart/mixed; boundary="8onMu72VncMK8umhOueItNmKArUNjNHB1";
 protected-headers="v1"
From: Eliot Lear 
To: Kent Watsen , "netmod@ietf.org" 
Message-ID: <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>

--8onMu72VncMK8umhOueItNmKArUNjNHB1
Content-Type: multipart/mixed;
 boundary="------------43FE15720BC12DD345F541D7"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------43FE15720BC12DD345F541D7
Content-Type: multipart/alternative;
 boundary="------------0BD7D138C463E8A66E9BDCBE"


--------------0BD7D138C463E8A66E9BDCBE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Kent and Mahesh and Sonal,

Thanks very much for working on this draft.=C2=A0 I have noted one proble=
m
that I think needs correcting.=C2=A0 I come prepared with a diff.

The current model has {source,dest}-port-or-range hanging off ipv4 or
ipv6.=C2=A0 This is a transport parameter and is not appropriate for
protocols that do not use ports (ie, ICMP, ESP, etc).=C2=A0 A better loca=
le
would be to hang these components underneath l4 underneath their
respective tcp and udp branches.

Because this is so basic a function, I propose that this *not* be
included in match-on-tcp or match-on-udp.=C2=A0 Instead, the contents of =
both
tcp and udp be moved to new containers "tcp-all" and "udp-all",
respectively, and the ports hang as peers to that.=C2=A0 Thus, if a very
simple device can understand TCP and UDP ports but cannot understand
more detailed information, that is supported.

=C2=A0And so from a tree perspective, it would look like this:


       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16


A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is
attached.

Eliot



On 17.01.18 22:55, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-15.
>
> This working group last call ends on January 31st.
> Please send your comments to the NETMOD mailing list.
>
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Also, could the authors, explicitly CC-ed on this email,
> please confirm at this time that they are unaware of
> any IPR related to this draft.
>
> Thank you,
> NETMOD Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


--------------0BD7D138C463E8A66E9BDCBE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Kent and Mahesh and Sonal,

    
Thanks very much for working on this draft.=C2=A0 I have noted one=

      problem that I think needs correcting.=C2=A0 I come prepared with a=

      diff.

    
The current model has {source,dest}-port-or-range hanging off
      ipv4 or ipv6.=C2=A0 This is a transport parameter and is not
      appropriate for protocols that do not use ports (ie, ICMP, ESP,
      etc).=C2=A0 A better locale would be to hang these components
      underneath l4 underneath their respective tcp and udp branches.
=

    
Because this is so basic a function, I propose that this not
      be included in match-on-tcp or match-on-udp.=C2=A0 Instead, the
      contents of both tcp and udp be moved to new containers "tcp-all"
      and "udp-all", respectively, and the ports hang as peers to that.=C2=
=A0
      Thus, if a very simple device can understand TCP and UDP ports but
      cannot understand more detailed information, that is supported.
=

    =C2=A0And so from a tree perspective, it would look like this:
    


    

    
       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16

    


    

    A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is
    attached.

    

    Eliot

    

    

    

    
On 17.01.18 22:55, Kent Watsen wrote:<=
br>
    

    

      
All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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



    

    

  


--------------0BD7D138C463E8A66E9BDCBE--

--------------43FE15720BC12DD345F541D7
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="ietf-pf.diffs"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf-pf.diffs"

KioqIGlldGYtcGFja2V0LWZpZWxkc0AyMDE4LTAxLTE2Lnlhbmcub3JpZwlNb24gSmFuIDIy
IDEyOjU4OjA4IDIwMTgKLS0tIGlldGYtcGFja2V0LWZpZWxkc0AyMDE4LTAxLTE2LnlhbmcJ
TW9uIEphbiAyMiAxMzoxMDo1NyAyMDE4CioqKioqKioqKioqKioqKgoqKiogMTkwLDIwNSAq
KioqCiAgICAgICAgICAgcGF5bG9hZC4gSW4gSVB2NiwgdGhpcyBmaWVsZCBpcyBrbm93biBh
cyAnbmV4dC1oZWFkZXIuIjsKICAgICAgICByZWZlcmVuY2UgIlJGQyA3MTksIFJGQyAyNDYw
LiI7CiAgICAgIH0KLSAgICAgY29udGFpbmVyIHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJh
dG9yIHsKLSAgICAgICB1c2VzIHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I7Ci0gICAgICAgZGVz
Y3JpcHRpb24KLSAgICAgICAgICJTb3VyY2UgcG9ydCBkZWZpbml0aW9uLiI7Ci0gICAgIH0K
LSAgICAgY29udGFpbmVyIGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3Igewot
ICAgICAgIHVzZXMgcG9ydC1yYW5nZS1vci1vcGVyYXRvcjsKLSAgICAgICBkZXNjcmlwdGlv
bgotICAgICAgICAgIkRlc3RpbmF0aW9uIHBvcnQgZGVmaW5pdGlvbi4iOwotICAgICB9CiAg
ICB9CiAgCiAgICBncm91cGluZyBhY2wtaXB2NC1oZWFkZXItZmllbGRzIHsKLS0tIDE5MCwx
OTUgLS0tLQo=
--------------43FE15720BC12DD345F541D7
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="acl.diffs"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="acl.diffs"

KioqIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdEAyMDE4LTAxLTE2Lnlhbmcub3JpZwlNb24g
SmFuIDIyIDEwOjE2OjE3IDIwMTgKLS0tIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdEAyMDE4
LTAxLTE2LnlhbmcJTW9uIEphbiAyMiAxMzowOTowNiAyMDE4CioqKioqKioqKioqKioqKgoq
KiogNDQwLDQ1NyAqKioqCiAgCiAgICAgICAgICAgICAgY2hvaWNlIGw0IHsKICAgICAgICAg
ICAgICAgIGNvbnRhaW5lciB0Y3AgewohICAgICAgICAgICAgICAgICBpZi1mZWF0dXJlIG1h
dGNoLW9uLXRjcDsKICAgICAgICAgICAgICAgICAgdXNlcyBwYWNrZXQtZmllbGRzOmFjbC10
Y3AtaGVhZGVyLWZpZWxkczsKISAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAg
ICAgICAgICAgICAgICAgICAgIlJ1bGUgc2V0IHRoYXQgbWF0Y2hlcyBUQ1AgaGVhZGVycy4i
OwohICAgICAgICAgICAgICAgfQohIAogICAgICAgICAgICAgICAgY29udGFpbmVyIHVkcCB7
CiEgICAgICAgICAgICAgICAgIGlmLWZlYXR1cmUgbWF0Y2gtb24tdWRwOwohICAgICAgICAg
ICAgICAgICB1c2VzIHBhY2tldC1maWVsZHM6YWNsLXVkcC1oZWFkZXItZmllbGRzOwohICAg
ICAgICAgICAgICAgICBkZXNjcmlwdGlvbgohICAgICAgICAgICAgICAgICAgICJSdWxlIHNl
dCB0aGF0IG1hdGNoZXMgVURQIGhlYWRlcnMuIjsKISAgICAgICAgICAgICAgIH0KICAKICAg
ICAgICAgICAgICAgIGNvbnRhaW5lciBpY21wIHsKICAgICAgICAgICAgICAgICAgaWYtZmVh
dHVyZSBtYXRjaC1vbi1pY21wOwotLS0gNDQwLDQ4MiAtLS0tCiAgCiAgICAgICAgICAgICAg
Y2hvaWNlIGw0IHsKICAgICAgICAgICAgICAgIGNvbnRhaW5lciB0Y3AgewohIAkJY29udGFp
bmVyIHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yIHsKISAJCSAgIHVzZXMgcGFja2V0
LWZpZWxkczpwb3J0LXJhbmdlLW9yLW9wZXJhdG9yOwohIAkJICAgICAgZGVzY3JpcHRpb24K
ISAJCSAgICAgICAgIlNvdXJjZSBwb3J0IGRlZmluaXRpb24uIjsKISAgICAgICAgICAgICAg
ICAgfQkJCQohIAkJY29udGFpbmVyIGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0
b3IgewohIAkJICAgdXNlcyBwYWNrZXQtZmllbGRzOnBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I7
CiEgCQkgICBkZXNjcmlwdGlvbgohICAJCSAgICAgIkRlc3RpbmF0aW9uIHBvcnQgZGVmaW5p
dGlvbi4iOwohIAkJfQohIAkJY29udGFpbmVyIHRjcC1hbGwgewohICAgICAgICAgICAgICAg
ICAgICBpZi1mZWF0dXJlIG1hdGNoLW9uLXRjcDsKICAgICAgICAgICAgICAgICAgdXNlcyBw
YWNrZXQtZmllbGRzOmFjbC10Y3AtaGVhZGVyLWZpZWxkczsKISAgICAgICAgICAgICAgICAg
ICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAgICAgICJSdWxlIHNldCB0aGF0IG1h
dGNoZXMgVENQIGhlYWRlcnMuIjsKISAgICAgICAgICAgICAgICAgfQohIAkgICAgICAJZGVz
Y3JpcHRpb24gIlRDUCBtYXRjaGFibGUgY2hhcmFjdGVyaXN0aWNzIjsKISAJICAgICAgfQog
ICAgICAgICAgICAgICAgY29udGFpbmVyIHVkcCB7CiEgCQljb250YWluZXIgc291cmNlLXBv
cnQtcmFuZ2Utb3Itb3BlcmF0b3IgewohIAkJICAgdXNlcyBwYWNrZXQtZmllbGRzOnBvcnQt
cmFuZ2Utb3Itb3BlcmF0b3I7CiEgCQkgICAgICBkZXNjcmlwdGlvbgohIAkJICAgICAgICAi
U291cmNlIHBvcnQgZGVmaW5pdGlvbi4iOwohICAgICAgICAgICAgICAgICB9CQkJCiEgCQlj
b250YWluZXIgZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvciB7CiEgCQkgICB1
c2VzIHBhY2tldC1maWVsZHM6cG9ydC1yYW5nZS1vci1vcGVyYXRvcjsKISAJCSAgIGRlc2Ny
aXB0aW9uCiEgIAkJICAgICAiRGVzdGluYXRpb24gcG9ydCBkZWZpbml0aW9uLiI7CiEgCQl9
CiEgCQljb250YWluZXIgdWRwLWFsbCB7CiEgICAgICAgICAgICAgICAgICAgIGlmLWZlYXR1
cmUgbWF0Y2gtb24tdWRwOwohICAgICAgICAgICAgICAgICAgICB1c2VzIHBhY2tldC1maWVs
ZHM6YWNsLXVkcC1oZWFkZXItZmllbGRzOwohICAgICAgICAgICAgICAgICAgICBkZXNjcmlw
dGlvbgohICAgICAgICAgICAgICAgICAgICAgICJSdWxlIHNldCB0aGF0IG1hdGNoZXMgVURQ
IGhlYWRlcnMuIjsKISAgICAgICAgICAgICAgICAgfQohIAkgICAgICAJZGVzY3JpcHRpb24g
IlVEUCBtYXRjaGFibGUgY2hhcmFjdGVyaXN0aWNzIjsKISAJICAgICAgfQogIAogICAgICAg
ICAgICAgICAgY29udGFpbmVyIGljbXAgewogICAgICAgICAgICAgICAgICBpZi1mZWF0dXJl
IG1hdGNoLW9uLWljbXA7Cg==
--------------43FE15720BC12DD345F541D7--

--8onMu72VncMK8umhOueItNmKArUNjNHB1--

--8qmQ6caAFGo826vM0g4PnTRIo4dLisDNp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpmOAIACgkQh7ZrRtnS
ejM8hQf/QsVUUE3skYPq4rCEEWYYeoh4DYNgTiz9/oUvilYbWbqu+dfl77/kzFuT
OZ9208cC8kPxO0aEx+N93cipKTtfGmXSic7lry8gZ8RwlKU5797iFW+u1nmI4YLc
79VGlyVgTMfOGSmQxmRacluxIcXMVQ6nmBOV723qqpt5Zdpat+70Mz/41M7vuOdD
APOwiVK0wyW4LrXls0KTfCJTY9XRk53SD5FP9dP66+uKDqB+x/kevyu5ntuOOcHC
GO55pMKtJUrLriU5quRGtxjIcbWcBxp1L05/W9Dx0tt5DO2w0KabD0cjEtMxXwuQ
C++ARK7tnK9PG6a2i3PpOX8iE/wA6A==
=VcBc
-----END PGP SIGNATURE-----

--8qmQ6caAFGo826vM0g4PnTRIo4dLisDNp--


From nobody Mon Jan 22 12:06:10 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 7E5DE127136 for ; Mon, 22 Jan 2018 12:06:05 -0800 (PST)
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 ldMqn0Gvq92u for ; Mon, 22 Jan 2018 12:06:03 -0800 (PST)
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 5201D12AF84 for ; Mon, 22 Jan 2018 12:05:59 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0MK4dks031601 for ; Mon, 22 Jan 2018 12:05:56 -0800
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=8GB88RWGS6GQjDX5fhj/Y2ksjY6W/b1CPPrZEU5LGPo=; b=avcbSe80eqalJ0OSFJbaUiRrR7GNUWJFElZcBwxvNFOqPOXFE8eQiHD19E4Vv9mhoQCt xIZKf1GH1tHOb9jkayeMNk2tIa/MYu+IrPyzL+XUbdvyKhK8YpK2y13YngwW5KPvQDjN U+7qYdkmDQ2qXXvj6gOUv4tXT6SsGfHS8Bm0y/uFKNZ6iBsTLQfUUBeaezfNmiFvEade mRodBpgFKJT9YUEzKTVyoscclP13wQybV/zi4HHKnpS5z0BYlpCb6MmReDlk7iQZtELt s+iOQBpc/HfTAj3VovV7Ty+8YjGx4K0oM8FV5l6Xu5gOUXolWSLUqoz3ZZVIvOxBeDj6 WA== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0019.outbound.protection.outlook.com [216.32.181.19]) by mx0b-00273201.pphosted.com with ESMTP id 2fnpfp80vq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 22 Jan 2018 12:05:56 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3113.namprd05.prod.outlook.com (10.173.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Mon, 22 Jan 2018 20:05:53 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.008; Mon, 22 Jan 2018 20:05:54 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: moving forward with schema mount
Thread-Index: AQHTk7xos3ciVL7Jy0SyClhY/I/+rA==
Date: Mon, 22 Jan 2018 20:05:54 +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; DM5PR05MB3113; 7:5ubEXFhqsyHIL+GFT66k/dVz+Z5FKp6n8bSrGEA14WYfiJIw9F2L60DUxsecq1wCRRvBTaqxZwyAIlgDhhdPWvN5N5ETu1zFRFNYBhDVAnIfS3vqbzERa3QK+qN7p6LB9QCq2oiQ4M+I0sgn3RYROOEtgjIiLHuBbrj61wJqlAgK4XLiABGgXHkVUh7aiNyTHJnVpiPXcuraSPNjVtkVyc989H4VjZ8TjghxT8uUk2gYCSeNy0kDg8TGWXmZ6j+O
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 5efc5664-a919-4365-1789-08d561d38b0e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3113; 
x-ms-traffictypediagnostic: DM5PR05MB3113:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(2400081)(944501161)(6055026)(6041288)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3113; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3113; 
x-forefront-prvs: 0560A2214D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(346002)(396003)(366004)(39860400002)(189003)(199004)(6436002)(97736004)(86362001)(53936002)(33656002)(478600001)(6306002)(5640700003)(2906002)(6916009)(6512007)(3846002)(6116002)(966005)(5660300001)(14454004)(6486002)(83716003)(2501003)(36756003)(2900100001)(66066001)(81166006)(1730700003)(105586002)(8676002)(81156014)(102836004)(59450400001)(316002)(8936002)(68736007)(83506002)(6506007)(106356001)(305945005)(99286004)(7736002)(58126008)(82746002)(3280700002)(3660700001)(2351001)(26005)(77096007)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3113; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: J43LusMe8Osq+Bw0DC20BwDrCca48+Ga5JNMfWSeLER6pAV24XTqTsSi2nRApPZzItL5Pz9igIJb/gOnKumIJA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <10FC747D57D3F74E89D472C82E18D833@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5efc5664-a919-4365-1789-08d561d38b0e
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 20:05:54.0493 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3113
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_08:, , 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-1711220000 definitions=main-1801220274
Archived-At: 
Subject: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 20:06:05 -0000

DQpUaGFuayB5b3UgYWxsIGZvciB0aGUgaW1wb3J0YW50IGRpc2N1c3Npb24gc2luY2UgdGhlIGNv
bXBsZXRpb24gb2YgV0dMQyBvbiBOb3YgNnRoLg0KDQpQZXIgbm9ybWFsIHByb2Nlc3MsIGRyYWZ0
cyB0eXBpY2FsbHkgcHJvZ3Jlc3Mgb25jZSBMQyBjb21tZW50cyBhcmUgYWRkcmVzcyB1bmxlc3Mg
c2lnbmlmaWNhbnQgZmF1bHRzIGFyZSBmb3VuZC4gIFBvc3QgTEMgY29tbWVudHMgaGF2ZSBiZWVu
IG1hZGUsIHdoaWNoIG5lZWRlZCBjb25zaWRlcmF0aW9uLCBub3RhYmx5IHRoZSByZWxhdGlvbnNo
aXAgd2l0aCBOTURBIGFuZCByZmM3ODk1YmlzIGFuZCBhbiBhbHRlcm5hdGUgcmVwcmVzZW50YXRp
b24gb2YgaW5saW5lIHNjaGVtYS4gIFRoZXNlIGhhdmUgYmVlbiBjb25zaWRlcmVkIHJlc3BlY3Rp
bmcgdGhlaXIgaW1wYWN0IG9uIHRoZSBsYXN0IGNhbGwgY29uc2Vuc3VzIGFuZCBpdCBpcyB0aGUg
cG9zaXRpb24gb2YgdGhlIGNoYWlycyB0aGF0IGl0IGlzIGJlc3QgdG8gYWR2YW5jZSB0aGUgZXhp
c3Rpbmcgc2NoZW1hLW1vdW50IGRvY3VtZW50IGF0IHRoaXMgdGltZS4NCg0KR2l2ZW4gdGhhdCB0
aGVyZSBhcmUgc2lnbmlmaWNhbnQgY29uY2VybnMgZm9yIGhvdyB0aGUgc29sdXRpb24gcHJvcG9z
ZWQgaW4gdGhpcyBkcmFmdCBvcGVyYXRlcyB3aXRoIE5NREEsIHdlIGRvIHRoaW5rIGl0IHJlYXNv
bmFibGUgdG8gYWRkIGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHRvIHRoZSBkcmFmdCB0aGF0
IGNvdmVycyBpdHMgb3BlcmF0aW9uIGluIE5NREEgaW1wbGVtZW50YXRpb25zLiBXZSBkbyBub3Qg
YmVsaWV2ZSB0aGF0IHN1Y2ggYSBzdGF0ZW1lbnQgc3Vic3RhbnRpdmVseSBhbHRlcnMgdGhlIGRy
YWZ0IG5vciB3b3VsZCBpdCBpbXBhY3QgZHJhZnRzIHRoYXQgbm9ybWF0aXZlbHkgcmVmZXJlbmNl
IHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpJbiBhZGRpdGlvbiB0byByZXNvbHZpbmcgdGhlIHJlbWFp
bmluZyBvcGVuIHRocmVhZCBbMV0sIHdlIGFsc28gYWdyZWUgd2l0aCB0aGUgcmVjZW50bHkgbWFk
ZSBjb21tZW50IHRoYXQgdGhlIHNjaGVtYSBtb3VudCBkcmFmdCBzaG91bGQgYWxsb3cgdGhlIHVz
ZSBvZiByZmM3ODk1YmlzIChpLmUuLCBub3QgcmVmZXJlbmNlIC9tb2R1bGVzLXN0YXRlKSwgdGhl
cmVieSBlbmFibGluZyB0aGUgZHJhZnQncyB1c2UgKHRob3VnaCBub3QgaWRlYWwpIG9uIHNlcnZl
cnMgc3VwcG9ydGluZyByZmM3ODk1YmlzLg0KDQpUaGUgY2hhaXJzIHdpbGwgcHJvcG9zZSBzcGVj
aWZpYyB0ZXh0IGZvciB0aGUgdXBkYXRlcyBtZW50aW9uZWQgaW4gdGhpcyBtZXNzYWdlIHRvIGJl
IHJldmlld2VkIGJ5IHRoZSBXRyBmb3IgY29ycmVjdG5lc3MgYmVmb3JlIGZpbmFsIHN1Ym1pc3Np
b24gYW5kIGFkdmFuY2VtZW50LiANCg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj
aGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMjAwNDkuaHRtbA0KDQpUaGFua3MsDQpLZW50LCBM
b3UsIGFuZCBKb2VsDQoNCg0KDQo=


From nobody Mon Jan 22 13:49: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 4DCA112D7E2 for ; Mon, 22 Jan 2018 13:49:06 -0800 (PST)
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 egX9ZqIk7BHT for ; Mon, 22 Jan 2018 13:49:03 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 A28BA127137 for ; Mon, 22 Jan 2018 13:49:03 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id 136so8120049pgd.8 for ; Mon, 22 Jan 2018 13:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QkPv8s2VzDhzREeXtbXbQad4/fsgICd3ChTpIRWp70M=; b=NKiHA0KY0QgNERjIFJM2oAS1RFlSOg1F3zFcviXN2HD2VWbdDe3o+Ot/LXr3ov4RsV 3A1DR9gybKaGS9reLipQKlz6qcQnodl6Vs2uDwf8xkLGdSs6m9jrFh9KIewEfSmxbntX pfTTfKTlT+3+Je6F3h7w3HBhk6c9Ee9Va6jEdMWSnryuRMyDzK9G6dd5NrMg+2Pw6kuJ lnDpx0s6ITJ3gXi1GO97hhmy02Mk23ASgJkLKywfDTVf2FUp82xbccqo8ZcfHCwx8GZ8 xwZ9xxJmvU/9lvWijJ4R83Vy0sJmp4vb13EDqmznMIsd63qmjNTNeZb82zO7NmBfqh0b yfiA==
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=QkPv8s2VzDhzREeXtbXbQad4/fsgICd3ChTpIRWp70M=; b=Iw6uE1yWpZ5H6AGvoGJ5MCi2v05VKYTIkzj7mrtPpGFC4xynfm/jpCgyZPBTnGOWrt /hyioosjgHDPy2jSUlIsyzAI2EOJvxN7rIpIzrTcI3ypoBFaa4bRsdE7Jh3nJcq2HbWN rINYVkCaPBk2502GJcRMrZDCqIbWKHkOL66Ca6YO1e9vRFJqcl2XQHWsxnhBjmJgWa70 IPKqLYuKXc4SjPIjH44ufkXLpn2ly8YpQGAad8t7Yqi3T1H9g3GnwMwz3cM28m80gKc3 JnxowSNrQ54jxGTw09KZE3DUIur9XPH5tRAqD/vuQzfGrQHufQSRRoHGc5JZr04dmC8G TPbw==
X-Gm-Message-State: AKwxytcpVCagZiWdbxoe10efKbDyoLsrjz6c5b1zhrjGR6gTZ93JqX0K bLfsLIbv7hK8u3BSU/4FHNfCX2Ul
X-Google-Smtp-Source: AH8x226+1iOO2VvLyESaFnI+ncOMUQ1Yt/Ug1iji1nIwHSWLYlQH6Por4OJzDdVecsCPEdLsyPvzzA==
X-Received: by 2002:a17:902:7244:: with SMTP id c4-v6mr4329889pll.414.1516657742914;  Mon, 22 Jan 2018 13:49:02 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:b1fb:ae:6399:a3f3]) by smtp.gmail.com with ESMTPSA id q67sm2835056pfi.164.2018.01.22.13.49.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 13:49:02 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: <0480E3FD-BFAC-41F5-8408-3DAB117A8625@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1BCB1FD8-6B19-4CE1-810F-7903B0CA4283"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 22 Jan 2018 13:48:59 -0800
In-Reply-To: <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
Cc: Kent Watsen , "netmod@ietf.org" 
To: Eliot Lear 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 21:49:06 -0000

--Apple-Mail=_1BCB1FD8-6B19-4CE1-810F-7903B0CA4283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Eliot,

I am not sure about what is a basic function, and what is not. Tomorrow, =
somebody can argue that TCP SYN flag is a basic function and should be =
broken out from under the TCP header.

I would rather that port definition remain under TCP/UDP with the =
feature statement =E2=80=98match-on-tcp=E2=80=99 and =E2=80=98match-on-udp=
=E2=80=99. The proposed change then looks like what is here =
, and all the changes in the PR are captured here =
.

Thanks

> On Jan 22, 2018, at 11:14 AM, Eliot Lear  wrote:
>=20
> Hi Kent and Mahesh and Sonal,
>=20
> Thanks very much for working on this draft.  I have noted one problem =
that I think needs correcting.  I come prepared with a diff.
>=20
> The current model has {source,dest}-port-or-range hanging off ipv4 or =
ipv6.  This is a transport parameter and is not appropriate for =
protocols that do not use ports (ie, ICMP, ESP, etc).  A better locale =
would be to hang these components underneath l4 underneath their =
respective tcp and udp branches.
>=20
> Because this is so basic a function, I propose that this not be =
included in match-on-tcp or match-on-udp.  Instead, the contents of both =
tcp and udp be moved to new containers "tcp-all" and "udp-all", =
respectively, and the ports hang as peers to that.  Thus, if a very =
simple device can understand TCP and UDP ports but cannot understand =
more detailed information, that is supported.
>=20
>  And so from a tree perspective, it would look like this:
>=20
>        |        |  +--rw (l4)?
>        |        |  |  +--:(tcp)
>        |        |  |  |  +--rw tcp
>        |        |  |  |     +--rw source-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
>        |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          =
inet:port-number
>        |        |  |  |     +--rw destination-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
>        |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          =
inet:port-number
>        |        |  |  |     +--rw tcp-all {match-on-tcp}?
>        |        |  |  |        +--rw sequence-number?          uint32
>        |        |  |  |        +--rw acknowledgement-number?   uint32
>        |        |  |  |        +--rw data-offset?              uint8
>        |        |  |  |        +--rw reserved?                 uint8
>        |        |  |  |        +--rw flags?                    bits
>        |        |  |  |        +--rw window-size?              uint16
>        |        |  |  |        +--rw urgent-pointer?           uint16
>        |        |  |  |        +--rw options?                  uint32
>        |        |  |  +--:(udp)
>        |        |  |  |  +--rw udp
>        |        |  |  |     +--rw source-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
>        |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          =
inet:port-number
>        |        |  |  |     +--rw destination-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
>        |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          =
inet:port-number
>        |        |  |  |     +--rw udp-all {match-on-udp}?
>        |        |  |  |        +--rw length?   uint16
>=20
> A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is =
attached.
>=20
> Eliot
>=20
>=20
>=20
> On 17.01.18 22:55, Kent Watsen wrote:
>> All,
>>=20
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-15.
>>=20
>> This working group last call ends on January 31st.
>> Please send your comments to the NETMOD mailing list.
>>=20
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>=20
>> Also, could the authors, explicitly CC-ed on this email,
>> please confirm at this time that they are unaware of
>> any IPR related to this draft.
>>=20
>> Thank you,
>> NETMOD Chairs
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>>=20
>=20
> *** ietf-packet-fields@2018-01-16.yang.orig	Mon Jan 22 12:58:08 2018
> --- ietf-packet-fields@2018-01-16.yang	Mon Jan 22 13:10:57 2018
> ***************
> *** 190,205 ****
>           payload. In IPv6, this field is known as 'next-header.";
>        reference "RFC 719, RFC 2460.";
>      }
> -     container source-port-range-or-operator {
> -       uses port-range-or-operator;
> -       description
> -         "Source port definition.";
> -     }
> -     container destination-port-range-or-operator {
> -       uses port-range-or-operator;
> -       description
> -         "Destination port definition.";
> -     }
>    }
>=20
>    grouping acl-ipv4-header-fields {
> --- 190,195 ----
> *** ietf-access-control-list@2018-01-16.yang.orig	Mon Jan 22 =
10:16:17 2018
> --- ietf-access-control-list@2018-01-16.yang	Mon Jan 22 13:09:06 2018
> ***************
> *** 440,457 ****
>=20
>              choice l4 {
>                container tcp {
> !                 if-feature match-on-tcp;
>                  uses packet-fields:acl-tcp-header-fields;
> !                   description
>                      "Rule set that matches TCP headers.";
> !               }
> !=20
>                container udp {
> !                 if-feature match-on-udp;
> !                 uses packet-fields:acl-udp-header-fields;
> !                 description
> !                   "Rule set that matches UDP headers.";
> !               }
>=20
>                container icmp {
>                  if-feature match-on-icmp;
> --- 440,482 ----
>=20
>              choice l4 {
>                container tcp {
> ! 		container source-port-range-or-operator {
> ! 		   uses packet-fields:port-range-or-operator;
> ! 		      description
> ! 		        "Source port definition.";
> !                 }		=09
> ! 		container destination-port-range-or-operator {
> ! 		   uses packet-fields:port-range-or-operator;
> ! 		   description
> !  		     "Destination port definition.";
> ! 		}
> ! 		container tcp-all {
> !                    if-feature match-on-tcp;
>                  uses packet-fields:acl-tcp-header-fields;
> !                    description
>                      "Rule set that matches TCP headers.";
> !                 }
> ! 	      	description "TCP matchable characteristics";
> ! 	      }
>                container udp {
> ! 		container source-port-range-or-operator {
> ! 		   uses packet-fields:port-range-or-operator;
> ! 		      description
> ! 		        "Source port definition.";
> !                 }		=09
> ! 		container destination-port-range-or-operator {
> ! 		   uses packet-fields:port-range-or-operator;
> ! 		   description
> !  		     "Destination port definition.";
> ! 		}
> ! 		container udp-all {
> !                    if-feature match-on-udp;
> !                    uses packet-fields:acl-udp-header-fields;
> !                    description
> !                      "Rule set that matches UDP headers.";
> !                 }
> ! 	      	description "UDP matchable characteristics";
> ! 	      }
>=20
>                container icmp {
>                  if-feature match-on-icmp;
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_1BCB1FD8-6B19-4CE1-810F-7903B0CA4283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Eliot,

I =
am not sure about what is a basic function, and what is not. Tomorrow, =
somebody can argue that TCP SYN flag is a basic function and should be =
broken out from under the TCP header.

I would rather that port definition =
remain under TCP/UDP with the feature statement =E2=80=98match-on-tcp=E2=80=
=99 and =E2=80=98match-on-udp=E2=80=99. The proposed change then looks =
like what is here, and all the changes =
in the PR are captured here.

Thanks

On Jan 22, 2018, at 11:14 AM, Eliot Lear =
<lear@cisco.com> =
wrote:


 =20
    
 =20
  
Hi =
Kent and Mahesh and Sonal,
Thanks very much for working =
on this draft.  I have noted one
      problem that I think needs correcting.  I come prepared with =
a
      diff.
The current model has =
{source,dest}-port-or-range hanging off
      ipv4 or ipv6.  This is a transport parameter and is not
      appropriate for protocols that do not use ports (ie, ICMP, ESP,
      etc).  A better locale would be to hang these components
      underneath l4 underneath their respective tcp and udp =
branches.
Because this is so basic a function, I =
propose that this not
      be included in match-on-tcp or match-on-udp.  Instead, the
      contents of both tcp and udp be moved to new containers "tcp-all"
      and "udp-all", respectively, and the ports hang as peers to =
that. 
      Thus, if a very simple device can understand TCP and UDP ports but
      cannot understand more detailed information, that is =
supported.

     And so from a tree perspective, it would look like this:
    


    

    
       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
       |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          =
inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
       |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          =
inet:port-number
       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
       |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          =
inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    =
inet:port-number
       |        |  |  |     |     |  +--rw upper-port    =
inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          =
inet:port-number
       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16


    

    A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is
    attached.

    

    Eliot

    

    

    

    
On 17.01.18 22:55, Kent Watsen =
wrote:

    

    

      
All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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



    

    

  


*** ietf-packet-fields@2018-01-16.yang.orig	Mon Jan =
22 12:58:08 2018
--- ietf-packet-fields@2018-01-16.yang	Mon Jan =
22 13:10:57 2018
***************
*** 190,205 =
****
 =
          payload. In =
IPv6, this field is known as 'next-header.";
 =
       reference "RFC 719, RFC =
2460.";
      }
- =
    container source-port-range-or-operator {
-       uses =
port-range-or-operator;
- =
      description
- =
        "Source port =
definition.";
-     }
- =
    container destination-port-range-or-operator =
{
-       uses =
port-range-or-operator;
- =
      description
- =
        "Destination port =
definition.";
-     }
 =
   }

 =
   grouping acl-ipv4-header-fields {
--- =
190,195 ----
*** ietf-access-control-list@2018-01-16.yang.orig	Mon Jan =
22 10:16:17 2018
--- ietf-access-control-list@2018-01-16.yang	Mon Jan =
22 13:09:06 2018
***************
*** 440,457 =
****

 =
            &n=
bsp;choice l4 {
 =
            &n=
bsp;  container tcp {
! =
            &n=
bsp;   if-feature match-on-tcp;
 =
            &n=
bsp;    uses packet-fields:acl-tcp-header-fields;
! =
            &n=
bsp;     description
 =
            &n=
bsp;        "Rule set that =
matches TCP headers.";
! =
            &n=
bsp; }
! 
 =
            &n=
bsp;  container udp {
! =
            &n=
bsp;   if-feature match-on-udp;
! =
            &n=
bsp;   uses packet-fields:acl-udp-header-fields;
! =
            &n=
bsp;   description
! =
            &n=
bsp;     "Rule set that matches UDP =
headers.";
! =
            &n=
bsp; }

 =
            &n=
bsp;  container icmp {
 =
            &n=
bsp;    if-feature match-on-icmp;
--- =
440,482 ----

 =
            &n=
bsp;choice l4 {
 =
            &n=
bsp;  container tcp {
! 		container =
source-port-range-or-operator {
! 		 =
  uses packet-fields:port-range-or-operator;
! =
	=
	=
      description
! 		 =
       "Source port definition.";
! =
            &n=
bsp;   }			
! 		container =
destination-port-range-or-operator {
! 		 =
  uses packet-fields:port-range-or-operator;
! =
	=
	=
   description
!  		 =
    "Destination port definition.";
! =
	=
	=
}
! 		container tcp-all {
!=
 =
            &n=
bsp;      if-feature match-on-tcp;
 =
            &n=
bsp;    uses packet-fields:acl-tcp-header-fields;
! =
            &n=
bsp;      description
 =
            &n=
bsp;        "Rule set that =
matches TCP headers.";
! =
            &n=
bsp;   }
! 	 =
     	description "TCP matchable =
characteristics";
! 	 =
     }
 =
            &n=
bsp;  container udp {
! 		container =
source-port-range-or-operator {
! 		 =
  uses packet-fields:port-range-or-operator;
! =
	=
	=
      description
! 		 =
       "Source port definition.";
! =
            &n=
bsp;   }			
! 		container =
destination-port-range-or-operator {
! 		 =
  uses packet-fields:port-range-or-operator;
! =
	=
	=
   description
!  		 =
    "Destination port definition.";
! =
	=
	=
}
! 		container udp-all {
!=
 =
            &n=
bsp;      if-feature match-on-udp;
! =
            &n=
bsp;      uses =
packet-fields:acl-udp-header-fields;
! =
            &n=
bsp;      description
! =
            &n=
bsp;        "Rule set that =
matches UDP headers.";
! =
            &n=
bsp;   }
! 	 =
     	description "UDP matchable =
characteristics";
! 	 =
     }

 =
            &n=
bsp;  container icmp {
 =
            &n=
bsp;    if-feature match-on-icmp;
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_1BCB1FD8-6B19-4CE1-810F-7903B0CA4283--


From nobody Mon Jan 22 13:55:26 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 CC1C412D7EE for ; Mon, 22 Jan 2018 13:55:24 -0800 (PST)
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_RP_MATCHES_RCVD=-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 4OseMBUIiln8 for ; Mon, 22 Jan 2018 13:55:21 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E9D12D7E9 for ; Mon, 22 Jan 2018 13:55:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39042; q=dns/txt; s=iport; t=1516658120; x=1517867720; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=z0jgHX2W98b3e4YbXIdh3Zcboi2BNceuAK5ecnq6bG4=; b=QVAIaqm4YFZG96IoeuRJp0gzKQH4NYKQK+qlJfmcq1PF9IqlDKf7gZMu /A6drszOQUmCWU0p4mKxJOdelbxKPGUjnJuU3sGyn+bx1RTyXK9jWU384 CPEFqPOLn/CfYjAJjZI5MAN0Q/ShWOL+Xdpk/mHdmuoiLlXuxf1QdzTQB s=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQBfXGZa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj0IyiQ+ORIICBwMYAQyBNwGDD08CGoUuFAEBAQE?= =?us-ascii?q?BAQEBAWsohSQBAQQBASFLCxAJAg4KIAcDAgICHwYfEQYNBgIBAYoXAxUQlyCdc?= =?us-ascii?q?IInJoceDYJoAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhEmFfYMFgmtEAQECgTw?= =?us-ascii?q?BEgE2FQqCYYJlBaM9PYRdgjGBBYhEhQSCG4Yfg3GHdI1RQ4kzgTw2ImBwMhoIG?= =?us-ascii?q?xU9giqEWEA3BYgogjwBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,398,1511827200";  d="asc'?scan'208,217";a="1540674"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 21:55:18 +0000
Received: from [10.61.198.231] ([10.61.198.231]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0MLtHoq030030; Mon, 22 Jan 2018 21:55:17 GMT
To: Mahesh Jethanandani 
Cc: Kent Watsen , "netmod@ietf.org" 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com> <0480E3FD-BFAC-41F5-8408-3DAB117A8625@gmail.com>
From: Eliot Lear 
Message-ID: <171620d8-1f64-cf62-4dc2-5790f133da33@cisco.com>
Date: Mon, 22 Jan 2018 22:55:16 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <0480E3FD-BFAC-41F5-8408-3DAB117A8625@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aIRAjPNwBhBvBsmIkrWkdSvS9Dw0F92jI"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 21:55:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aIRAjPNwBhBvBsmIkrWkdSvS9Dw0F92jI
Content-Type: multipart/mixed; boundary="PP2RNTFNSw590uu6GGt5t1NvsrePiRCMN";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani 
Cc: Kent Watsen , "netmod@ietf.org" 
Message-ID: <171620d8-1f64-cf62-4dc2-5790f133da33@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
 <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
 <0480E3FD-BFAC-41F5-8408-3DAB117A8625@gmail.com>
In-Reply-To: <0480E3FD-BFAC-41F5-8408-3DAB117A8625@gmail.com>

--PP2RNTFNSw590uu6GGt5t1NvsrePiRCMN
Content-Type: multipart/alternative;
 boundary="------------FF521B1411ED0A8E30BCA443"
Content-Language: en-US

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

SSdtIG9rIHdpdGggdGhpcyBhcyB3ZWxsLCBNYWhlc2guCgpUaGFua3MsCgpFbGlvdAoKCk9u
IDIyLjAxLjE4IDIyOjQ4LCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOgo+IEVsaW90LAo+
Cj4gSSBhbSBub3Qgc3VyZSBhYm91dCB3aGF0IGlzIGEgYmFzaWMgZnVuY3Rpb24sIGFuZCB3
aGF0IGlzIG5vdC4KPiBUb21vcnJvdywgc29tZWJvZHkgY2FuIGFyZ3VlIHRoYXQgVENQIFNZ
TiBmbGFnIGlzIGEgYmFzaWMgZnVuY3Rpb24gYW5kCj4gc2hvdWxkIGJlIGJyb2tlbiBvdXQg
ZnJvbSB1bmRlciB0aGUgVENQIGhlYWRlci4KPgo+IEkgd291bGQgcmF0aGVyIHRoYXQgcG9y
dCBkZWZpbml0aW9uIHJlbWFpbiB1bmRlciBUQ1AvVURQIHdpdGggdGhlCj4gZmVhdHVyZSBz
dGF0ZW1lbnQg4oCYbWF0Y2gtb24tdGNw4oCZIGFuZCDigJhtYXRjaC1vbi11ZHDigJkuIFRo
ZSBwcm9wb3NlZAo+IGNoYW5nZSB0aGVuIGxvb2tzIGxpa2Ugd2hhdCBpc8KgaGVyZQo+IDxo
dHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIzL2NvbW1pdHMv
ZGM0ZWQ1NTZiZDcxY2I5ZTY0OGIwYmFiZGViZTA1YTNhNWI3YmY2OD4sCj4gYW5kIGFsbCB0
aGUgY2hhbmdlcyBpbiB0aGUgUFIgYXJlIGNhcHR1cmVkwqBoZXJlCj4gPGh0dHBzOi8vZ2l0
aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjM+Lgo+Cj4gVGhhbmtzCj4KPj4g
T24gSmFuIDIyLCAyMDE4LCBhdCAxMToxNCBBTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5j
b20KPj4gPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pgo+PiBIaSBLZW50IGFu
ZCBNYWhlc2ggYW5kIFNvbmFsLAo+Pgo+PiBUaGFua3MgdmVyeSBtdWNoIGZvciB3b3JraW5n
IG9uIHRoaXMgZHJhZnQuwqAgSSBoYXZlIG5vdGVkIG9uZSBwcm9ibGVtCj4+IHRoYXQgSSB0
aGluayBuZWVkcyBjb3JyZWN0aW5nLsKgIEkgY29tZSBwcmVwYXJlZCB3aXRoIGEgZGlmZi4K
Pj4KPj4gVGhlIGN1cnJlbnQgbW9kZWwgaGFzIHtzb3VyY2UsZGVzdH0tcG9ydC1vci1yYW5n
ZSBoYW5naW5nIG9mZiBpcHY0IG9yCj4+IGlwdjYuwqAgVGhpcyBpcyBhIHRyYW5zcG9ydCBw
YXJhbWV0ZXIgYW5kIGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IKPj4gcHJvdG9jb2xzIHRoYXQg
ZG8gbm90IHVzZSBwb3J0cyAoaWUsIElDTVAsIEVTUCwgZXRjKS7CoCBBIGJldHRlcgo+PiBs
b2NhbGUgd291bGQgYmUgdG8gaGFuZyB0aGVzZSBjb21wb25lbnRzIHVuZGVybmVhdGggbDQg
dW5kZXJuZWF0aAo+PiB0aGVpciByZXNwZWN0aXZlIHRjcCBhbmQgdWRwIGJyYW5jaGVzLgo+
Pgo+PiBCZWNhdXNlIHRoaXMgaXMgc28gYmFzaWMgYSBmdW5jdGlvbiwgSSBwcm9wb3NlIHRo
YXQgdGhpcyAqbm90KiBiZQo+PiBpbmNsdWRlZCBpbiBtYXRjaC1vbi10Y3Agb3IgbWF0Y2gt
b24tdWRwLsKgIEluc3RlYWQsIHRoZSBjb250ZW50cyBvZgo+PiBib3RoIHRjcCBhbmQgdWRw
IGJlIG1vdmVkIHRvIG5ldyBjb250YWluZXJzICJ0Y3AtYWxsIiBhbmQgInVkcC1hbGwiLAo+
PiByZXNwZWN0aXZlbHksIGFuZCB0aGUgcG9ydHMgaGFuZyBhcyBwZWVycyB0byB0aGF0LsKg
IFRodXMsIGlmIGEgdmVyeQo+PiBzaW1wbGUgZGV2aWNlIGNhbiB1bmRlcnN0YW5kIFRDUCBh
bmQgVURQIHBvcnRzIGJ1dCBjYW5ub3QgdW5kZXJzdGFuZAo+PiBtb3JlIGRldGFpbGVkIGlu
Zm9ybWF0aW9uLCB0aGF0IGlzIHN1cHBvcnRlZC4KPj4KPj4gwqBBbmQgc28gZnJvbSBhIHRy
ZWUgcGVyc3BlY3RpdmUsIGl0IHdvdWxkIGxvb2sgbGlrZSB0aGlzOgo+Pgo+Pgo+PiAgICAg
ICAgfCAgICAgICAgfCAgKy0tcncgKGw0KT8KPj4gICAgICAgIHwgICAgICAgIHwgIHwgICst
LToodGNwKQo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgKy0tcncgdGNwCj4+ICAgICAg
ICB8ICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVy
YXRvcgo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgKy0tcncgKHBvcnQtcmFu
Z2Utb3Itb3BlcmF0b3IpPwo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAg
Ky0tOihyYW5nZSkKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwgICAgIHwgICst
LXJ3IGxvd2VyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcgo+PiAgICAgICAgfCAgICAgICAg
fCAgfCAgfCAgICAgfCAgICAgfCAgKy0tcncgdXBwZXItcG9ydCAgICBpbmV0OnBvcnQtbnVt
YmVyCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICArLS06KG9wZXJhdG9y
KQo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgICAgKy0tcncgb3BlcmF0
b3I/ICAgICBvcGVyYXRvcgo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAg
ICAgKy0tcncgcG9ydCAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCj4+ICAgICAgICB8ICAg
ICAgICB8ICB8ICB8ICAgICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJh
dG9yCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICArLS1ydyAocG9ydC1yYW5n
ZS1vci1vcGVyYXRvcik/Cj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICAr
LS06KHJhbmdlKQo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgfCAgKy0t
cncgbG93ZXItcG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyCj4+ICAgICAgICB8ICAgICAgICB8
ICB8ICB8ICAgICB8ICAgICB8ICArLS1ydyB1cHBlci1wb3J0ICAgIGluZXQ6cG9ydC1udW1i
ZXIKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLToob3BlcmF0b3Ip
Cj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICAgICArLS1ydyBvcGVyYXRv
cj8gICAgIG9wZXJhdG9yCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICAg
ICArLS1ydyBwb3J0ICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXIKPj4gICAgICAgIHwgICAg
ICAgIHwgIHwgIHwgICAgICstLXJ3IHRjcC1hbGwge21hdGNoLW9uLXRjcH0/Cj4+ICAgICAg
ICB8ICAgICAgICB8ICB8ICB8ICAgICAgICArLS1ydyBzZXF1ZW5jZS1udW1iZXI/ICAgICAg
ICAgIHVpbnQzMgo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgICAgKy0tcncgYWNr
bm93bGVkZ2VtZW50LW51bWJlcj8gICB1aW50MzIKPj4gICAgICAgIHwgICAgICAgIHwgIHwg
IHwgICAgICAgICstLXJ3IGRhdGEtb2Zmc2V0PyAgICAgICAgICAgICAgdWludDgKPj4gICAg
ICAgIHwgICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IHJlc2VydmVkPyAgICAgICAgICAg
ICAgICAgdWludDgKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IGZs
YWdzPyAgICAgICAgICAgICAgICAgICAgYml0cwo+PiAgICAgICAgfCAgICAgICAgfCAgfCAg
fCAgICAgICAgKy0tcncgd2luZG93LXNpemU/ICAgICAgICAgICAgICB1aW50MTYKPj4gICAg
ICAgIHwgICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IHVyZ2VudC1wb2ludGVyPyAgICAg
ICAgICAgdWludDE2Cj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICAgICArLS1ydyBv
cHRpb25zPyAgICAgICAgICAgICAgICAgIHVpbnQzMgo+PiAgICAgICAgfCAgICAgICAgfCAg
fCAgKy0tOih1ZHApCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICArLS1ydyB1ZHAKPj4g
ICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHNvdXJjZS1wb3J0LXJhbmdlLW9y
LW9wZXJhdG9yCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICArLS1ydyAocG9y
dC1yYW5nZS1vci1vcGVyYXRvcik/Cj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8
ICAgICArLS06KHJhbmdlKQo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAg
fCAgKy0tcncgbG93ZXItcG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyCj4+ICAgICAgICB8ICAg
ICAgICB8ICB8ICB8ICAgICB8ICAgICB8ICArLS1ydyB1cHBlci1wb3J0ICAgIGluZXQ6cG9y
dC1udW1iZXIKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLToob3Bl
cmF0b3IpCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICAgICArLS1ydyBv
cGVyYXRvcj8gICAgIG9wZXJhdG9yCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8
ICAgICAgICArLS1ydyBwb3J0ICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXIKPj4gICAgICAg
IHwgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3It
b3BlcmF0b3IKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwgICstLXJ3IChwb3J0
LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwg
ICAgICstLToocmFuZ2UpCj4+ICAgICAgICB8ICAgICAgICB8ICB8ICB8ICAgICB8ICAgICB8
ICArLS1ydyBsb3dlci1wb3J0ICAgIGluZXQ6cG9ydC1udW1iZXIKPj4gICAgICAgIHwgICAg
ICAgIHwgIHwgIHwgICAgIHwgICAgIHwgICstLXJ3IHVwcGVyLXBvcnQgICAgaW5ldDpwb3J0
LW51bWJlcgo+PiAgICAgICAgfCAgICAgICAgfCAgfCAgfCAgICAgfCAgICAgKy0tOihvcGVy
YXRvcikKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICAgICstLXJ3IG9w
ZXJhdG9yPyAgICAgb3BlcmF0b3IKPj4gICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgIHwg
ICAgICAgICstLXJ3IHBvcnQgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgo+PiAgICAgICAg
fCAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgdWRwLWFsbCB7bWF0Y2gtb24tdWRwfT8KPj4g
ICAgICAgIHwgICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IGxlbmd0aD8gICB1aW50MTYK
Pj4KPj4KPj4gQSBkaWZmIGlldGYtcGFja2V0LWZpZWxkcy55YW5nIGFuZCBpZXRmLWFjY2Vz
cy1jb250cm9sLWxpc3RzLnlhbmcgaXMKPj4gYXR0YWNoZWQuCj4+Cj4+IEVsaW90Cj4+Cj4+
Cj4+Cj4+IE9uIDE3LjAxLjE4IDIyOjU1LCBLZW50IFdhdHNlbiB3cm90ZToKPj4+IEFsbCwK
Pj4+Cj4+PiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs
IG9uCj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTUuCj4+Pgo+Pj4gVGhpcyB3
b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEphbnVhcnkgMzFzdC4KPj4+IFBsZWFz
ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIE5FVE1PRCBtYWlsaW5nIGxpc3QuCj4+Pgo+
Pj4gUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1l
bnQKPj4+IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3
ZWxjb21lIQo+Pj4gVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1
dGhvcnMuCj4+Pgo+Pj4gQWxzbywgY291bGQgdGhlIGF1dGhvcnMsIGV4cGxpY2l0bHkgQ0Mt
ZWQgb24gdGhpcyBlbWFpbCwKPj4+IHBsZWFzZSBjb25maXJtIGF0IHRoaXMgdGltZSB0aGF0
IHRoZXkgYXJlIHVuYXdhcmUgb2YKPj4+IGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0
Lgo+Pj4KPj4+IFRoYW5rIHlvdSwKPj4+IE5FVE1PRCBDaGFpcnMKPj4+Cj4+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gbmV0bW9kIG1h
aWxpbmcgbGlzdAo+Pj4gbmV0bW9kQGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4KPj4KPj4gKioqIGlldGYtcGFja2V0LWZp
ZWxkc0AyMDE4LTAxLTE2Lnlhbmcub3JpZwo+PiA8bWFpbHRvOmlldGYtcGFja2V0LWZpZWxk
c0AyMDE4LTAxLTE2Lnlhbmcub3JpZz5Nb24gSmFuIDIyIDEyOjU4OjA4IDIwMTgKPj4gLS0t
IGlldGYtcGFja2V0LWZpZWxkc0AyMDE4LTAxLTE2LnlhbmcKPj4gPG1haWx0bzppZXRmLXBh
Y2tldC1maWVsZHNAMjAxOC0wMS0xNi55YW5nPk1vbiBKYW4gMjIgMTM6MTA6NTcgMjAxOAo+
PiAqKioqKioqKioqKioqKioKPj4gKioqIDE5MCwyMDUgKioqKgo+PiDCoMKgwqDCoMKgwqDC
oMKgwqDCoHBheWxvYWQuIEluIElQdjYsIHRoaXMgZmllbGQgaXMga25vd24gYXMgJ25leHQt
aGVhZGVyLiI7Cj4+IMKgwqDCoMKgwqDCoMKgcmVmZXJlbmNlICJSRkMgNzE5LCBSRkMgMjQ2
MC4iOwo+PiDCoMKgwqDCoMKgfQo+PiAtIMKgwqDCoMKgY29udGFpbmVyIHNvdXJjZS1wb3J0
LXJhbmdlLW9yLW9wZXJhdG9yIHsKPj4gLSDCoMKgwqDCoMKgwqB1c2VzIHBvcnQtcmFuZ2Ut
b3Itb3BlcmF0b3I7Cj4+IC0gwqDCoMKgwqDCoMKgZGVzY3JpcHRpb24KPj4gLSDCoMKgwqDC
oMKgwqDCoMKgIlNvdXJjZSBwb3J0IGRlZmluaXRpb24uIjsKPj4gLSDCoMKgwqDCoH0KPj4g
LSDCoMKgwqDCoGNvbnRhaW5lciBkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9y
IHsKPj4gLSDCoMKgwqDCoMKgwqB1c2VzIHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I7Cj4+IC0g
wqDCoMKgwqDCoMKgZGVzY3JpcHRpb24KPj4gLSDCoMKgwqDCoMKgwqDCoMKgIkRlc3RpbmF0
aW9uIHBvcnQgZGVmaW5pdGlvbi4iOwo+PiAtIMKgwqDCoMKgfQo+PiDCoMKgwqB9Cj4+Cj4+
IMKgwqDCoGdyb3VwaW5nIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgewo+PiAtLS0gMTkwLDE5
NSAtLS0tCj4+ICoqKiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RAMjAxOC0wMS0xNi55YW5n
Lm9yaWcKPj4gPG1haWx0bzppZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RAMjAxOC0wMS0xNi55
YW5nLm9yaWc+TW9uIEphbiAyMgo+PiAxMDoxNjoxNyAyMDE4Cj4+IC0tLSBpZXRmLWFjY2Vz
cy1jb250cm9sLWxpc3RAMjAxOC0wMS0xNi55YW5nCj4+IDxtYWlsdG86aWV0Zi1hY2Nlc3Mt
Y29udHJvbC1saXN0QDIwMTgtMDEtMTYueWFuZz5Nb24gSmFuIDIyIDEzOjA5OjA2IDIwMTgK
Pj4gKioqKioqKioqKioqKioqCj4+ICoqKiA0NDAsNDU3ICoqKioKPj4KPj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqBjaG9pY2UgbDQgewo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqBjb250YWluZXIgdGNwIHsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoGlmLWZlYXR1cmUgbWF0Y2gtb24tdGNwOwo+PiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgdXNlcyBwYWNrZXQtZmllbGRzOmFjbC10Y3AtaGVhZGVyLWZpZWxk
czsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBkZXNjcmlwdGlv
bgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAiUnVsZSBz
ZXQgdGhhdCBtYXRjaGVzIFRDUCBoZWFkZXJzLiI7Cj4+ICEgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoH0KPj4gIQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBjb250
YWluZXIgdWRwIHsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGlmLWZl
YXR1cmUgbWF0Y2gtb24tdWRwOwo+PiAhIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgdXNlcyBwYWNrZXQtZmllbGRzOmFjbC11ZHAtaGVhZGVyLWZpZWxkczsKPj4gISDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGRlc2NyaXB0aW9uCj4+ICEgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIlJ1bGUgc2V0IHRoYXQgbWF0Y2hlcyBVRFAg
aGVhZGVycy4iOwo+PiAhIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB9Cj4+Cj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNvbnRhaW5lciBpY21wIHsKPj4gwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGlmLWZlYXR1cmUgbWF0Y2gtb24taWNtcDsK
Pj4gLS0tIDQ0MCw0ODIgLS0tLQo+Pgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNo
b2ljZSBsNCB7Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNvbnRhaW5lciB0
Y3Agewo+PiAhIGNvbnRhaW5lciBzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvciB7Cj4+
ICEgwqDCoHVzZXMgcGFja2V0LWZpZWxkczpwb3J0LXJhbmdlLW9yLW9wZXJhdG9yOwo+PiAh
IMKgwqDCoMKgwqBkZXNjcmlwdGlvbgo+PiAhIMKgwqDCoMKgwqDCoMKgIlNvdXJjZSBwb3J0
IGRlZmluaXRpb24uIjsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoH0K
Pj4gISBjb250YWluZXIgZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvciB7Cj4+
ICEgwqDCoHVzZXMgcGFja2V0LWZpZWxkczpwb3J0LXJhbmdlLW9yLW9wZXJhdG9yOwo+PiAh
IMKgwqBkZXNjcmlwdGlvbgo+PiAhIMKgwqDCoMKgwqAiRGVzdGluYXRpb24gcG9ydCBkZWZp
bml0aW9uLiI7Cj4+ICEgfQo+PiAhIGNvbnRhaW5lciB0Y3AtYWxsIHsKPj4gISDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGlmLWZlYXR1cmUgbWF0Y2gtb24tdGNw
Owo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgdXNlcyBwYWNrZXQtZmll
bGRzOmFjbC10Y3AtaGVhZGVyLWZpZWxkczsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoGRlc2NyaXB0aW9uCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCJSdWxlIHNldCB0aGF0IG1hdGNoZXMgVENQIGhlYWRlcnMu
IjsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoH0KPj4gISDCoMKgwqDC
oMKgZGVzY3JpcHRpb24gIlRDUCBtYXRjaGFibGUgY2hhcmFjdGVyaXN0aWNzIjsKPj4gISDC
oMKgwqDCoMKgfQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBjb250YWluZXIg
dWRwIHsKPj4gISBjb250YWluZXIgc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3Igewo+
PiAhIMKgwqB1c2VzIHBhY2tldC1maWVsZHM6cG9ydC1yYW5nZS1vci1vcGVyYXRvcjsKPj4g
ISDCoMKgwqDCoMKgZGVzY3JpcHRpb24KPj4gISDCoMKgwqDCoMKgwqDCoCJTb3VyY2UgcG9y
dCBkZWZpbml0aW9uLiI7Cj4+ICEgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB9
Cj4+ICEgY29udGFpbmVyIGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3Igewo+
PiAhIMKgwqB1c2VzIHBhY2tldC1maWVsZHM6cG9ydC1yYW5nZS1vci1vcGVyYXRvcjsKPj4g
ISDCoMKgZGVzY3JpcHRpb24KPj4gISDCoMKgwqDCoMKgIkRlc3RpbmF0aW9uIHBvcnQgZGVm
aW5pdGlvbi4iOwo+PiAhIH0KPj4gISBjb250YWluZXIgdWRwLWFsbCB7Cj4+ICEgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBpZi1mZWF0dXJlIG1hdGNoLW9uLXVk
cDsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHVzZXMgcGFj
a2V0LWZpZWxkczphY2wtdWRwLWhlYWRlci1maWVsZHM7Cj4+ICEgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBkZXNjcmlwdGlvbgo+PiAhIMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCJSdWxlIHNldCB0aGF0IG1hdGNoZXMgVURQ
IGhlYWRlcnMuIjsKPj4gISDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoH0KPj4g
ISDCoMKgwqDCoMKgZGVzY3JpcHRpb24gIlVEUCBtYXRjaGFibGUgY2hhcmFjdGVyaXN0aWNz
IjsKPj4gISDCoMKgwqDCoMKgfQo+Pgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqBjb250YWluZXIgaWNtcCB7Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqBpZi1mZWF0dXJlIG1hdGNoLW9uLWljbXA7Cj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4gbmV0
bW9kQGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Cj4gTWFoZXNoIEpldGhhbmFuZGFu
aQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp
bC5jb20+Cj4KCg==
--------------FF521B1411ED0A8E30BCA443
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I'm ok with this as well, Mahesh.

    
Thanks,

    
Eliot

    

    

    
On 22.01.18 22:48, Mahesh Jethanandani=

      wrote:

    

    

      
      Eliot,
      


      

      
I am not sure about what is a basic function, and
        what is not. Tomorrow, somebody can argue that TCP SYN flag is a
        basic function and should be broken out from under the TCP
        header.

      


      

      
I would rather that port definition remain under
        TCP/UDP with the feature statement =E2=80=98match-on-tcp=E2=80=99=
 and
        =E2=80=98match-on-udp=E2=80=99. The proposed change then looks li=
ke what is=C2=A0here, and all the chang=
es
        in the PR are captured=C2=A0here.

      


      

      

        
Thanks

        


          

            
On Jan 22, 2018, at 11:14 AM, Eliot Lear <=
lear@cisco.com> wrote:
            

            

              

                
Hi Kent and Mahesh and Sonal,

                
Thanks very much for working on this draft.=
=C2=A0
                  I have noted one problem that I think needs
                  correcting.=C2=A0 I come prepared with a diff.

                
The current model has
                  {source,dest}-port-or-range hanging off ipv4 or ipv6.=C2=
=A0
                  This is a transport parameter and is not appropriate
                  for protocols that do not use ports (ie, ICMP, ESP,
                  etc).=C2=A0 A better locale would be to hang these
                  components underneath l4 underneath their respective
                  tcp and udp branches.

                
Because this is so basic a function, I
                  propose that this not be included in
                  match-on-tcp or match-on-udp.=C2=A0 Instead, the conten=
ts
                  of both tcp and udp be moved to new containers
                  "tcp-all" and "udp-all", respectively, and the ports
                  hang as peers to that.=C2=A0 Thus, if a very simple dev=
ice
                  can understand TCP and UDP ports but cannot understand
                  more detailed information, that is supported.

                =C2=A0And so from a tree perspective, it would look like
                this:
                


                

                
       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16

                


                

                A diff ietf-packet-fields.yang and
                ietf-access-control-lists.yang is attached.

                

                Eliot

                

                

                

                
On 17.01.18 22:55, Kent
                  Watsen wrote:

                

                

                  
All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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



                

                

              

              *** ietf-packet-fields@20=
18-01-16.yang.orig	Mon
              Jan 22 12:58:08 2018

              --- ietf-packet-fields@20=
18-01-16.yang	Mon
              Jan 22 13:10:57 2018

              ***************

              *** 190,205 ****

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
payload. In IPv6, this field is known as
              'next-header.";

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reference "RFC 71=
9, RFC 2460.";

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              - =C2=A0=C2=A0=C2=A0=C2=A0container source-port-range-or-op=
erator {

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses port-range-or-op=
erator;

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Source p=
ort definition.";

              - =C2=A0=C2=A0=C2=A0=C2=A0}

              - =C2=A0=C2=A0=C2=A0=C2=A0container destination-port-range-=
or-operator {

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses port-range-or-op=
erator;

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Destinat=
ion port definition.";

              - =C2=A0=C2=A0=C2=A0=C2=A0}

              =C2=A0=C2=A0=C2=A0}

              

              =C2=A0=C2=A0=C2=A0grouping acl-ipv4-header-fields {

              --- 190,195 ----

              *** ietf-access-control-l=
ist@2018-01-16.yang.orig	Mon
              Jan 22 10:16:17 2018

              --- ietf-access-control-l=
ist@2018-01-16.yang	Mon
              Jan 22 13:09:06 2018

              ***************

              *** 440,457 ****

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0choice l4 {

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container tcp {

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match-on-tcp;

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses packet-fields:acl-tcp-head=
er-fields;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Rule s=
et that matches TCP headers.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              ! 

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container udp {

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match-on-udp;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses
              packet-fields:acl-udp-header-fields;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Rule set that matches=
 UDP headers.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container icmp {

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match-on-icmp;

              --- 440,482 ----

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0choice l4 {

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container tcp {

              ! =
		=
container
              source-port-range-or-operator {

              ! =
		=

              =C2=A0=C2=A0uses packet-fields:port-range-or-operator;

              ! =
		=

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              ! =
		=

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Source port defi=
nition.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}			

              ! =
		=
container
              destination-port-range-or-operator {

              ! =
		=

              =C2=A0=C2=A0uses packet-fields:port-range-or-operator;

              ! =
		=

              =C2=A0=C2=A0description

              ! =C2=A0		<=
/span>
              =C2=A0=C2=A0=C2=A0=C2=A0"Destination port definition.";

              ! =
		=
}

              ! =
		=
container
              tcp-all {

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match=
-on-tcp;

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses packet-fields:acl-tcp-head=
er-fields;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Rule s=
et that matches TCP headers.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              ! =
	
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0	description
              "TCP matchable characteristics";

              ! =
	
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container udp {

              ! =
		=
container
              source-port-range-or-operator {

              ! =
		=

              =C2=A0=C2=A0uses packet-fields:port-range-or-operator;

              ! =
		=

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              ! =
		=

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Source port defi=
nition.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}			

              ! =
		=
container
              destination-port-range-or-operator {

              ! =
		=

              =C2=A0=C2=A0uses packet-fields:port-range-or-operator;

              ! =
		=

              =C2=A0=C2=A0description

              ! =C2=A0		<=
/span>
              =C2=A0=C2=A0=C2=A0=C2=A0"Destination port definition.";

              ! =
		=
}

              ! =
		=
container
              udp-all {

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match=
-on-udp;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uses
              packet-fields:acl-udp-header-fields;

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Rul=
e set that matches UDP
              headers.";

              ! =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              ! =
	
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0	description
              "UDP matchable characteristics";

              ! =
	
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0container icmp {

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if-feature match-on-icmp;

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

              https://www.ietf.org/mailman/listinfo/net=
mod

            

          

        

        

        

          
Mahesh Jethanandani

          
mjethanandani@gmail.com=


        

        

      

    

    

  


--------------FF521B1411ED0A8E30BCA443--

--PP2RNTFNSw590uu6GGt5t1NvsrePiRCMN--

--aIRAjPNwBhBvBsmIkrWkdSvS9Dw0F92jI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpmXcQACgkQh7ZrRtnS
ejOmWQf/fibpan5hk8+OE7HwjKfH80Xo7ck7ZGFEY/DQWRJ/zU35J3Wq9B6C2CzH
yiAQlhb1f9AvvCKC221ypbXIM+4scVAK0zomN5UUmzInKAqlTaL7gb0FQyx7PQau
E4IWfDDvCXsrlNFwDdxNY2Ur9vi/uxweambRNVQpttHJ+GuJFa7w4b/nyrJgm6mF
QBAcRhEd9BuJqf+2wjMXlQVxcx4n/t8TUvnVv1wD7jyBfd/ByRcm2o7ExUZnY3NB
h8tHf4zgyFb5wDZlSsV/bIvHRUuvnB05MpVBkItGVBdUejgXIHA+d7OblGJ0XOg7
0kIW756m8mjx1RPckkdHjIvRcn5Chw==
=lR0m
-----END PGP SIGNATURE-----

--aIRAjPNwBhBvBsmIkrWkdSvS9Dw0F92jI--


From nobody Mon Jan 22 14:02: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 C34EC12D7E9 for ; Mon, 22 Jan 2018 14:02:10 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 9y98l3GBnIzs for ; Mon, 22 Jan 2018 14:02:08 -0800 (PST)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7510124D6C for ; Mon, 22 Jan 2018 14:02:06 -0800 (PST)
From: Alex Campbell 
To: Eliot Lear , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKOA0LyA//+d5sg=
Date: Mon, 22 Jan 2018 22:02:05 +0000
Message-ID: <1516658524969.70610@Aviatnet.com>
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>, <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
In-Reply-To: <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.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_151665852496970610Aviatnetcom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 22:02:11 -0000

--_000_151665852496970610Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,


Good point - adding on to that, I'd like to point out that there are more p=
rotocols that use ports besides TCP and UDP, such as SCTP and DCCP.
If the port number was not protocol-specific then devices would also have t=
o match SCTP ports, DCCP ports, and other protocol ports, even for protocol=
s which haven't been invented yet. This is not possible to implement.

> Thus, if a very simple device can understand TCP and UDP ports but cannot=
 understand more detailed information, that is supported.


I don't think YANG features can possibly envision or handle all the potenti=
al variations between devices, unless we give each criterion its own separa=
te feature.

To my knowledge, the device I am currently working on doesn't support port =
range matching, or operators other than 'equals', and I see there is curren=
tly no YANG feature for that.

Do you think it would be better to let vendors use deviations to indicate w=
hich features aren't supported?



________________________________
From: netmod  on behalf of Eliot Lear 
Sent: Tuesday, 23 January 2018 8:14 a.m.
To: Kent Watsen; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15


Hi Kent and Mahesh and Sonal,

Thanks very much for working on this draft.  I have noted one problem that =
I think needs correcting.  I come prepared with a diff.

The current model has {source,dest}-port-or-range hanging off ipv4 or ipv6.=
  This is a transport parameter and is not appropriate for protocols that d=
o not use ports (ie, ICMP, ESP, etc).  A better locale would be to hang the=
se components underneath l4 underneath their respective tcp and udp branche=
s.

Because this is so basic a function, I propose that this not be included in=
 match-on-tcp or match-on-udp.  Instead, the contents of both tcp and udp b=
e moved to new containers "tcp-all" and "udp-all", respectively, and the po=
rts hang as peers to that.  Thus, if a very simple device can understand TC=
P and UDP ports but cannot understand more detailed information, that is su=
pported.

 And so from a tree perspective, it would look like this:


       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16


A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is attach=
ed.

Eliot



On 17.01.18 22:55, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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




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













Hi,








Good point - adding on to that, I'd like to point out that there are more p=
rotocols that use ports besides TCP and UDP, such as SCTP and DCCP.

If the port number was not protocol-specific then devices would also have t=
o match SCTP ports, DCCP ports, and other protocol ports, even for protocol=
s which haven't been invented yet. This is not possible to implement.



> Thus, if a very simple device can understand TCP and UDP ports but can=
not understand more detailed information, that is supported.







I don't think YANG features can possibly envision or handle all the pote=
ntial variations between devices, unless we give each criterion its own sep=
arate feature.


To my knowledge, the device I am currently working on doesn't support po=
rt range matching, or operators other than 'equals', and I see there is cur=
rently no YANG feature for that.


Do you think it would be better to let vendors use deviations to indicat=
e which features aren't supported?


















From: netmod <netmod-b=
ounces@ietf.org> on behalf of Eliot Lear <lear@cisco.com>

Sent: Tuesday, 23 January 2018 8:14 a.m.

To: Kent Watsen; netmod@ietf.org

Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

 






Hi Kent and Mahesh and Sonal,


Thanks very much for working on this draft.  I have noted one probl=
em that I think needs correcting.  I come prepared with a diff.


The current model has {source,dest}-port-or-range hanging off ipv4 or ip=
v6.  This is a transport parameter and is not appropriate for protocol=
s that do not use ports (ie, ICMP, ESP, etc).  A better locale would b=
e to hang these components underneath l4 underneath
 their respective tcp and udp branches.


Because this is so basic a function, I propose that this not be i=
ncluded in match-on-tcp or match-on-udp.  Instead, the contents of bot=
h tcp and udp be moved to new containers "tcp-all" and "udp-=
all", respectively, and the ports hang as peers to that. 
 Thus, if a very simple device can understand TCP and UDP ports but cannot =
understand more detailed information, that is supported.

 And so from a tree perspective, it would look like this:






       |        |  +--rw (l4)?=0A=
       |        |  |  +--:(tcp)=0A=
       |        |  |  |  +--rw tcp=0A=
       |        |  |  |     +--rw source-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw destination-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw tcp-all {match-on-tcp}?=0A=
       |        |  |  |        +--rw sequence-number?          uint32=
=0A=
       |        |  |  |        +--rw acknowledgement-number?   uint32=
=0A=
       |        |  |  |        +--rw data-offset?              uint8=0A=
       |        |  |  |        +--rw reserved?                 uint8=0A=
       |        |  |  |        +--rw flags?                    bits=0A=
       |        |  |  |        +--rw window-size?              uint16=
=0A=
       |        |  |  |        +--rw urgent-pointer?           uint16=
=0A=
       |        |  |  |        +--rw options?                  uint32=
=0A=
       |        |  |  +--:(udp)=0A=
       |        |  |  |  +--rw udp=0A=
       |        |  |  |     +--rw source-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw destination-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw udp-all {match-on-udp}?=0A=
       |        |  |  |        +--rw length?   uint16






A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is attach=
ed.



Eliot








On 17.01.18 22:55, Kent Watsen wrote:






All,=0A=
=0A=
This starts a two-week working group last call on=0A=
draft-ietf-netmod-acl-model-15.=0A=
=0A=
This working group last call ends on January 31st.=0A=
Please send your comments to the NETMOD mailing list.=0A=
=0A=
Positive comments, e.g., "I've reviewed this document=0A=
and believe it is ready for publication", are welcome!=0A=
This is useful and important, even from authors.=0A=
=0A=
Also, could the authors, explicitly CC-ed on this email,=0A=
please confirm at this time that they are unaware of=0A=
any IPR related to this draft.=0A=
=0A=
Thank you,=0A=
NETMOD Chairs=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmo=
d@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=
=0A=













--_000_151665852496970610Aviatnetcom_--


From nobody Mon Jan 22 14:06: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 55FFA127369; Mon, 22 Jan 2018 14:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 x5Kxa2kROm1D; Mon, 22 Jan 2018 14:05:57 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6758112D7F2; Mon, 22 Jan 2018 14:05:57 -0800 (PST)
Received: from MBP.local ([104.153.224.166]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0MM5kJJ011392 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Jan 2018 22:05:54 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [104.153.224.166] claimed to be MBP.local
From: joel jaeggli 
To: NETMOD Working Group 
Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <2cde8b64-0455-a513-4719-feb61c87a952@bogus.com>  <1fcc0c28-4c99-c0c7-91ae-f2e3f0b009af@bogus.com>
Message-ID: <7833f013-22e0-6d47-18ee-9569f48fe932@bogus.com>
Date: Mon, 22 Jan 2018 14:05:33 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1fcc0c28-4c99-c0c7-91ae-f2e3f0b009af@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: [netmod] Closure - : WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 22:05:59 -0000

Greetings,

This WGLC is concluded.

We have consensus to advance the document.

The authors should submit an update reflecting the result of the
dicussion on the text representation of tree diagrams not being usable
by machine parsers.

The exchange between Robert Wilton and Martin Bjorkland I think sums
this up succinctly.

(Robert)

OK, so the "Providing some guidance for how to represent the tree is
good" is along the lines of what I was thinking for the "algorithm"
would be for 2.

E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace
separated fields (e.g.  and ).=C2=A0 Additional whitespace ma=
y
be used to column align fields (e.g. within a list or container) to
improve readability".

(Martin)
This is fine with me.  It is something in between (1) and (2) which
people preferred.  I will add this text.

Thanks all, looking forward to IETF last call.

joel
=C2=A0


On 1/16/18 9:24 AM, joel jaeggli wrote:
> The current dicussion on the draft is not yet concluded. The WGLC will
> conclude when discussion of the editorial changes is complete.
>
> Thanks
> joel
>
> On 1/10/18 8:16 AM, joel jaeggli wrote:
>> Just a reminder given the date that this was posted. This last call is=

>> expected to complete Monday 1/15/18.
>>
>> Thanks
>>
>> joel
>>
>>
>> On 1/1/18 2:01 PM, joel jaeggli wrote:
>>> Greetings,
>>>
>>> We hope  the new year is a time to make great progess on outstanding
>>> documents before preparation for the  London IETF begins in earnest.
>>>
>>> This starts a two-week working group last call on:
>>>
>>>  YANG Tree Diagrams
>>> draft-ietf-netmod-yang-tree-diagrams
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams=
/
>>>
>>> Please send email to the list indicating your support or concerns.
>>>
>>> We are particularly interested in statements of the form:
>>>
>>>   * I have reviewed this draft and found no issues.
>>>   * I have reviewed this draft and found the following issues: ...
>>>
>>>
>>> Thank you,
>>> NETMOD WG Chairs
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 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 Jan 22 14:06: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 BCBC712D7EB for ; Mon, 22 Jan 2018 14:06:51 -0800 (PST)
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_RP_MATCHES_RCVD=-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 u8i8u9KeIrmM for ; Mon, 22 Jan 2018 14:06:49 -0800 (PST)
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 5EC04124D6C for ; Mon, 22 Jan 2018 14:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17252; q=dns/txt; s=iport; t=1516658808; x=1517868408; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ZTOyWgW5BecfAmGAQrAiIIByQJTRHH1zjVJLS9tZnrc=; b=PRVSK1mlX+TQnR1RfrDwbjs+NyqkXGgsl5azfUAT2wjIeEhY6KIKxqAW HWz06a5/Mk2YtOeK22xb8JtkXlJ99BGVg2pGhJjhWhjhwOHmFhdABpMf/ 7oAmzNXgt0GGjZFf2IOlhxP1AJX4J6sXx+JUYG1a6rRyodUXK5MEA3wEA o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQAxX2Za/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKAYFddCeDXYsYj3SRaoVpggIHAxgBCoE5AYMPTwKFRxUBAQE?= =?us-ascii?q?BAQEBAQFrKIUjAQEBAwEBASFLEAsLEQQBAQEqAgInKAgGAQwGAgEBiicIELR6g?= =?us-ascii?q?icmihMBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWESYVUKYMFgy8BAQKBPAESASc?= =?us-ascii?q?kgmuCZQWKWpkghF2CMY5NghuGH4Nxh3SXR4E8NSMlO3AyGggbFT2CKoRYQDeIJ?= =?us-ascii?q?4I8AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,398,1511827200";  d="asc'?scan'208,217";a="1592472"
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; 22 Jan 2018 22:06:46 +0000
Received: from [10.61.198.231] ([10.61.198.231]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0MM6j99000770; Mon, 22 Jan 2018 22:06:45 GMT
To: Alex Campbell , Kent Watsen , "netmod@ietf.org" 
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com> <1516658524969.70610@Aviatnet.com>
From: Eliot Lear 
Message-ID: <9e65fc46-be29-f854-ae83-6bd0130a6c8e@cisco.com>
Date: Mon, 22 Jan 2018 23:06:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516658524969.70610@Aviatnet.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JBmHCGea4gesvPWUpMS3B9JKaLP4gwfma"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 22:06:52 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JBmHCGea4gesvPWUpMS3B9JKaLP4gwfma
Content-Type: multipart/mixed; boundary="6WVkTBHE70SMNJbQNnhOxPULdWJBO91HC";
 protected-headers="v1"
From: Eliot Lear 
To: Alex Campbell ,
 Kent Watsen , "netmod@ietf.org" 
Message-ID: <9e65fc46-be29-f854-ae83-6bd0130a6c8e@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>
 <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com>
 <1516658524969.70610@Aviatnet.com>
In-Reply-To: <1516658524969.70610@Aviatnet.com>

--6WVkTBHE70SMNJbQNnhOxPULdWJBO91HC
Content-Type: multipart/alternative;
 boundary="------------45EDA4D71BE46B2E37DD7480"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------45EDA4D71BE46B2E37DD7480
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 22.01.18 23:02, Alex Campbell wrote:
>
>
> Hi,
>
>
> Good point - adding on to that, I'd like to point out that there are
> more protocols that use ports besides TCP and UDP, such as SCTP and DCC=
P.
> If the port number was not protocol-specific then devices would also
> have to match SCTP ports, DCCP ports, and other protocol ports, even
> for protocols which haven't been invented yet. This is not possible to
> implement.
>
> > Thus, if a very simple device can understand TCP and UDP ports but
> cannot understand more detailed information, that is supported.
>
>
> I don't think YANG features can possibly envision or handle all the
> potential variations between devices, unless we give each criterion
> its own separate feature.
>
> To my knowledge, the device I am currently working on doesn't support
> port range matching, or operators other than 'equals', and I see there
> is currently no YANG feature for that.
>
> Do you think it would be better to let vendors use deviations to
> indicate which features aren't supported?
>

Yes, and so I agreed to Mahesh's simpler change.

Eliot
>
>
>
> -----------------------------------------------------------------------=
-
> *From:* netmod  on behalf of Eliot Lear
> 
> *Sent:* Tuesday, 23 January 2018 8:14 a.m.
> *To:* Kent Watsen; netmod@ietf.org
> *Subject:* Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15
> =C2=A0
>
> Hi Kent and Mahesh and Sonal,
>
> Thanks very much for working on this draft.=C2=A0 I have noted one prob=
lem
> that I think needs correcting.=C2=A0 I come prepared with a diff.
>
> The current model has {source,dest}-port-or-range hanging off ipv4 or
> ipv6.=C2=A0 This is a transport parameter and is not appropriate for
> protocols that do not use ports (ie, ICMP, ESP, etc).=C2=A0 A better lo=
cale
> would be to hang these components underneath l4 underneath their
> respective tcp and udp branches.
>
> Because this is so basic a function, I propose that this *not* be
> included in match-on-tcp or match-on-udp.=C2=A0 Instead, the contents o=
f
> both tcp and udp be moved to new containers "tcp-all" and "udp-all",
> respectively, and the ports hang as peers to that.=C2=A0 Thus, if a ver=
y
> simple device can understand TCP and UDP ports but cannot understand
> more detailed information, that is supported.
>
> =C2=A0And so from a tree perspective, it would look like this:
>
>
>        |        |  +--rw (l4)?
>        |        |  |  +--:(tcp)
>        |        |  |  |  +--rw tcp
>        |        |  |  |     +--rw source-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er
>        |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          inet:port-numb=
er
>        |        |  |  |     +--rw destination-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er
>        |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          inet:port-numb=
er
>        |        |  |  |     +--rw tcp-all {match-on-tcp}?
>        |        |  |  |        +--rw sequence-number?          uint32
>        |        |  |  |        +--rw acknowledgement-number?   uint32
>        |        |  |  |        +--rw data-offset?              uint8
>        |        |  |  |        +--rw reserved?                 uint8
>        |        |  |  |        +--rw flags?                    bits
>        |        |  |  |        +--rw window-size?              uint16
>        |        |  |  |        +--rw urgent-pointer?           uint16
>        |        |  |  |        +--rw options?                  uint32
>        |        |  |  +--:(udp)
>        |        |  |  |  +--rw udp
>        |        |  |  |     +--rw source-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er
>        |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          inet:port-numb=
er
>        |        |  |  |     +--rw destination-port-range-or-operator
>        |        |  |  |     |  +--rw (port-range-or-operator)?
>        |        |  |  |     |     +--:(range)
>        |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er
>        |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er
>        |        |  |  |     |     +--:(operator)
>        |        |  |  |     |        +--rw operator?     operator
>        |        |  |  |     |        +--rw port          inet:port-numb=
er
>        |        |  |  |     +--rw udp-all {match-on-udp}?
>        |        |  |  |        +--rw length?   uint16
>
>
> A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is
> attached.
>
> Eliot
>
>
>
> On 17.01.18 22:55, Kent Watsen wrote:
>> All,
>>
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-15.
>>
>> This working group last call ends on January 31st.
>> Please send your comments to the NETMOD mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Also, could the authors, explicitly CC-ed on this email,
>> please confirm at this time that they are unaware of
>> any IPR related to this draft.
>>
>> Thank you,
>> NETMOD Chairs
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>


--------------45EDA4D71BE46B2E37DD7480
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 22.01.18 23:02, Alex Campbell wrote=
:

    

    

      
      
      


      

      
Hi,

      

      


      

      Good point - adding on to that, I'd like to point out that there
      are more protocols that use ports besides TCP and UDP, such as
      SCTP and DCCP.

      If the port number was not protocol-specific then devices would
      also have to match SCTP ports, DCCP ports, and other protocol
      ports, even for protocols which haven't been invented yet. This is
      not possible to implement.

      

      > Thus, if a very simple device can understand TCP and UDP
      ports but cannot understand more detailed information, that is
      supported.

      


      

      
I don't think YANG features can possibly envision or handle all
        the potential variations between devices, unless we give each
        criterion its own separate feature.

      
To my knowledge, the device I am currently working on doesn't
        support port range matching, or operators other than 'equals',
        and I see there is currently no YANG feature for that.

      
Do you think it would be better to let vendors use deviations
        to indicate which features aren't supported?

      

    

    

    Yes, and so I agreed to Mahesh's simpler change.

    

    Eliot

    

      

      

      


      

      


      

      

        

        
From:
            netmod <netmod-bounces@ietf.org> on behalf of Eli=
ot
            Lear <lear@cisco.com>

            Sent: Tuesday, 23 January 2018 8:14 a.m.

            To: Kent Watsen; netmod@ietf.org

            Subject: Re: [netmod] WG Last Call:
            draft-ietf-netmod-acl-model-15
          
=C2=A0

        

        

          
Hi Kent and Mahesh and Sonal,

          
Thanks very much for working on this draft.=C2=A0 I have not=
ed
            one problem that I think needs correcting.=C2=A0 I come prepa=
red
            with a diff.

          
The current model has {source,dest}-port-or-range hanging
            off ipv4 or ipv6.=C2=A0 This is a transport parameter and is =
not
            appropriate for protocols that do not use ports (ie, ICMP,
            ESP, etc).=C2=A0 A better locale would be to hang these
            components underneath l4 underneath their respective tcp and
            udp branches.

          
Because this is so basic a function, I propose that this =
not
            be included in match-on-tcp or match-on-udp.=C2=A0 Instead, t=
he
            contents of both tcp and udp be moved to new containers
            "tcp-all" and "udp-all", respectively, and the ports hang as
            peers to that.=C2=A0 Thus, if a very simple device can unders=
tand
            TCP and UDP ports but cannot understand more detailed
            information, that is supported.

          =C2=A0And so from a tree perspective, it would look like this:
          


          

          
       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number=

       |        |  |  |     |     |  +--rw upper-port    inet:port-number=

       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number=

       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16

          


          

          A diff ietf-packet-fields.yang and
          ietf-access-control-lists.yang is attached.

          

          Eliot

          

          

          

          
On 17.01.18 22:55, Kent Watsen
            wrote:

          

          

            
All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

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



          

          

        

      

    

    

  


--------------45EDA4D71BE46B2E37DD7480--

--6WVkTBHE70SMNJbQNnhOxPULdWJBO91HC--

--JBmHCGea4gesvPWUpMS3B9JKaLP4gwfma
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpmYHUACgkQh7ZrRtnS
ejN7swf/Wg4/WMqAgBa+upQr9HW2cPJ5rhiKGMEXrp73/V7kZLmw/Y9h0UeGXxXQ
D4z9hah9lZ9amXB7D7jU2qGVRkfuSOIqSdXrUg3FgK+PI4MI6Tec01ntKVrlmEgb
+UM+dvTmHOdwwuacj11QnHHfOzzQrKVDVLDXYBvm3HYoFxT90DyuNUKCogGNmVKP
YJxbkICZ/RXcDu7OQ5IqqHuDmavQoehcWpWYsuFB88W1m0p1K2fxH9Ho51FrLZW0
FkS2hzIDviFuLBHu4Atoa1Kz5XQhdZo9FS2bZbrZd7ZenVNFNDQtffT39KM39AcC
Ff3SZQGPjzVATCpqQV3Vfk1zkauE+w==
=l5i1
-----END PGP SIGNATURE-----

--JBmHCGea4gesvPWUpMS3B9JKaLP4gwfma--


From nobody Mon Jan 22 15:46: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 D1D3812D82D for ; Mon, 22 Jan 2018 15:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_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=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 bML6J1vFty8p for ; Mon, 22 Jan 2018 15:46:25 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 7DCEE12D850 for ; Mon, 22 Jan 2018 15:46:24 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id t139so12776262lff.0 for ; Mon, 22 Jan 2018 15:46:24 -0800 (PST)
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=s/YlACvsIzVPHws/arp50KNM/EXSo6EWtL/Cc+SIePQ=; b=1L2WtQ/yk4HZVDuteAjd4USSdIQW1lRIeq8fL2Lz3BHK1sy/anc/K/d/ESLfa5yRIo mu6z4DVCUU9J4K3Uw2cZssl2NF+GkqbqXiHs5M+b3BZ9YnQ5sfzU2mTxfuhGsGPQp+Gk xo4qlJNLV7EtvbU0Hkgyuclg25r7wVeQdggyIFmggKl6sBEEuFA/4cShuV0gQ/GwMHaV nfCVv3o2kbnXFbvZyHadZOJ4JSYu9KnIApwY7IlYs3k8u3wN2dhHBeCUDaKVed82Ba/V ct9iAxTciFOtWsS6rZnG7PHTtqz2x5YQB+jxw4UJrBF1HM/Nk3pGeDWAXz9iMdjcp6J7 zLYA==
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=s/YlACvsIzVPHws/arp50KNM/EXSo6EWtL/Cc+SIePQ=; b=UKPN3uMHM2SabYgscd62FOQjmk+ZoyiEf0NQLdSFYTM2mvShqYwt2Gi9jY3MUpKyaI 2CbzagbWHxyXYHmOobeZp/4bOdilqdz3RDQ2sGSnxD12CwzeeBt7ZYldYPZlSVS4edNS U2ShYkzN45CkUU0d5lU7l3FSkyTBE1pHee2LvG8vzJbXfxiSAoOTKCcWHP2bxvUpXUhA 9+IkHzddwhJN4iE6u1+JL6n4rIFsdZKO1O8M4fEJ0qo0QCB232XHxoHadx6hDPNhy6c5 l5IrGZi6dytUr9OhglNIpIrULBQIvmaauAozYX0QjteIMrubEryRGp4tbqRoRBeG5chV nq6A==
X-Gm-Message-State: AKwxytdKr32USYKiHJIZF5iCkMepdJiTs+6VnS8RGkawYgXoHAzsfpk8 WBzpC1ci9tBjoUGkocIbZfNWHulknfA2Xgm4dsJ7ag==
X-Google-Smtp-Source: AH8x227Qj7xKGtBP5osEvdY7pqjc800qieIc+kCHDyWTwkIE77aP7ixDf17YHlh8kng3cI9ZnSUkHHS1bKSxCMY/Wg0=
X-Received: by 10.25.26.200 with SMTP id a191mr213541lfa.35.1516664782638; Mon, 22 Jan 2018 15:46:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Mon, 22 Jan 2018 15:46:21 -0800 (PST)
In-Reply-To: <20180122174445.bsfdh3dqzw54m2lw@elstar.local>
References: <16104ca0948.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180117.171817.479473055872371790.mbj@tail-f.com> <1516206873.1388.68.camel@nic.cz> <20180117.174039.2105430212248651483.mbj@tail-f.com> <1827bdbb-a1ef-4302-bbb1-c0a3078de85a@cisco.com> <20180122111318.d7riglic333nj7ki@elstar.local> <878tcqm2gv.fsf@nic.cz>  <20180122164457.megfkkubdowexa7e@elstar.local>  <20180122174445.bsfdh3dqzw54m2lw@elstar.local>
From: Andy Bierman 
Date: Mon, 22 Jan 2018 15:46:21 -0800
Message-ID: 
To: Juergen Schoenwaelder ,  "Acee Lindem (acee)" , Ladislav Lhotka ,  "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11401eda9ce8760563660979"
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 23:46:28 -0000

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

Hi,


On Mon, Jan 22, 2018 at 9:44 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Thanks. The longer WG last call thread started with Rob's message in
> which he also asked about alignment with the YANG library update
> (posted November 2nd). So the document is in a limbo state since
> November 6th.
>
>

Can somebody please answer some simple questions:

Q1) why can't SM use augment to add objects to YLbis?

Q2)  why should readers/developers of YLbis need to know
about SM if their implementations do not support SM at all?

Q3) Is there a msg in the email archive that explains the reasons that
YLbis needs to be delayed? Where is the concrete proposal to add
specific objects to YLbis?


/js
>
>

Andy



> On Mon, Jan 22, 2018 at 04:58:15PM +0000, Acee Lindem (acee) wrote:
> > It was WG Last Call=E2=80=99ed: https://mailarchive.ietf.org/arch/msg/n=
etmod/
> csUvs6408En0yY-vapyU3IFcJqQ
> >
> > And it was closed: https://mailarchive.ietf.org/
> arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw
> >
> > However, it may not have ever completed.
> >
> > Thanks,
> > Acee
> >
> > On 1/22/18, 11:45 AM, "Juergen Schoenwaelder"  university.de> wrote:
> >
> >     Acee,
> >
> >     the documents that have already finished WG Last Call have a
> normative
> >     reference on schema mount, which has not yet finished WG Last Call =
as
> >     far as I recall. I think the RFC editor does not publish a document
> >     with a missing normative reference. I continue to believe that the
> >     time difference between doing the right thing and doing something
> >     faster using definition we are in the process to deprecate is reall=
y
> >     small. But of course, I may be entirely wrong.
> >
> >     /js
> >
> >     On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote:
> >     > Hi Lada,
> >     >
> >     > My primary concern is that the YANG Schema Mount delay will not
> only hold the NI/LNE but all the models that are dependent on them (e.g.,
> L2VPN and L3VPN). This is for a document that has already finished WG Las=
t
> Call. Additionally, your estimate for the size of the change and time to
> reach standardization is based on there being immediate consensus on the
> changes. This is probably overly optimistic given there was discussion on
> the proposed YANG Library BIS changes. I=E2=80=99d vote to publish the ex=
isting
> draft.
> >     >
> >     > In any case, being able to see the proposed changes ASAP is
> critical.
> >     >
> >     > Thanks,
> >     > Acee
> >     >
> >     > On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" <
> netmod-bounces@ietf.org on behalf of lhotka@nic.cz> wrote:
> >     >
> >     >     Juergen Schoenwaelder 
> writes:
> >     >
> >     >     > On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton
> wrote:
> >     >     >>
> >     >     >> Hence, for me, I see the choice as:
> >     >     >> 1) do we publish the existing model now (perhaps also mark
> the draft as
> >     >     >> experimental) followed by an updated draft with the NMDA
> compatible module?
> >     >     >> 2) do we publish both models in a single draft (e.g. with
> the existing model
> >     >     >> in an appendix)?
> >     >     >> 3) do we only publish a single version of the draft with a=
n
> NMDA compliant
> >     >     >> solution.
> >     >     >>
> >     >     >
> >     >     > I think the situation is as follows (likely obvious but it
> may help to
> >     >     > make sure we are all on the same page):
> >     >     >
> >     >     > - the NI and LNE models have a normative reference to
> >     >     >   I-D.ietf-netmod-schema-mount (and this makes sense since
> there are
> >     >     >   MUST sentences in the I-D)
> >     >     >
> >     >     > - I-D.ietf-netmod-schema-mount (last updated in October) ha=
s
> normative
> >     >     >   references to RFC 7895 (old YANG library)
> >     >     >
> >     >     > - RFC 7895 does not work with NMDA, NMDA work on a YANG
> library update
> >     >     >   replacing RFC 7895
> >     >     >
> >     >     > So the YANG library update is gating the schema mount updat=
e
> which is
> >     >     > gating the publication of the NI and LNE models.
> >     >     >
> >     >     > A proper solution would be to prioritize work on the YANG
> library
> >     >     > update and the schema mount update. I assume that the next
> revision of
> >     >     > the YANG library update (say end of January) is ready for W=
G
> last call
> >     >     > and perhaps the schema mount authors can take an effort to
> get that
> >     >     > document there as well, say beginning of February.
> >     >
> >     >     I completely agree.
> >     >
> >     >     Lada
> >     >
> >     >     >
> >     >     > /js
> >     >     >
> >     >     > --
> >     >     > Juergen Schoenwaelder           Jacobs University Bremen
> gGmbH
> >     >     > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Breme=
n
> | Germany
> >     >     > Fax:   +49 421 200 3103          university.de/>
> >     >     >
> >     >     > _______________________________________________
> >     >     > netmod mailing list
> >     >     > netmod@ietf.org
> >     >     > https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >     >     --
> >     >     Ladislav Lhotka
> >     >     Head, CZ.NIC Labs
> >     >     PGP Key ID: 0xB8F92B08A9F76C67
> >     >
> >     >     _______________________________________________
> >     >     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         
> >
> >
>
> --
> 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
>

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


Hi,


On Mon, Jan 22, 2018 at 9:44 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=

Thanks. The longer WG last call thread start=
ed with Rob's message in

which he also asked about alignment with the YANG library update

(posted November 2nd). So the document is in a limbo state since

November 6th.




Can somebody please ans=
wer some simple questions:

Q1) why can't SM us=
e augment to add objects to YLbis?

Q2) =C2=A0why s=
hould readers/developers of YLbis need to know
about SM if their =
implementations do not support SM at all?

Q3) Is t=
here a msg in the email archive that explains the reasons that
YL=
bis needs to be delayed? Where is the concrete proposal to add
sp=
ecific objects to YLbis?



/js




Andy

=C2=A0

On Mon, Jan 22, 2018 at 04:58:15PM +0000, Acee Lindem (acee) wrote:

> It was WG Last Call=E2=80=99ed: https://mailarchive.ietf.org/arch/msg/netmod/csUvs6408En=
0yY-vapyU3IFcJqQ

>

> And it was closed: http=
s://mailarchive.ietf.org/arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ=
4lw

>

> However, it may not have ever completed.

>

> Thanks,

> Acee

>

> On 1/22/18, 11:45 AM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-u=
niversity.de> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Acee,

>

>=C2=A0 =C2=A0 =C2=A0the documents that have already finished WG Last Ca=
ll have a normative

>=C2=A0 =C2=A0 =C2=A0reference on schema mount, which has not yet finish=
ed WG Last Call as

>=C2=A0 =C2=A0 =C2=A0far as I recall. I think the RFC editor does not pu=
blish a document

>=C2=A0 =C2=A0 =C2=A0with a missing normative reference. I continue to b=
elieve that the

>=C2=A0 =C2=A0 =C2=A0time difference between doing the right thing and d=
oing something

>=C2=A0 =C2=A0 =C2=A0faster using definition we are in the process to de=
precate is really

>=C2=A0 =C2=A0 =C2=A0small. But of course, I may be entirely wrong.

>

>=C2=A0 =C2=A0 =C2=A0/js

>

>=C2=A0 =C2=A0 =C2=A0On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lind=
em (acee) wrote:

>=C2=A0 =C2=A0 =C2=A0> Hi Lada,

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> My primary concern is that the YANG Schema Mou=
nt delay will not only hold the NI/LNE but all the models that are dependen=
t on them (e.g., L2VPN and L3VPN). This is for a document that has already =
finished WG Last Call. Additionally, your estimate for the size of the chan=
ge and time to reach standardization is based on there being immediate cons=
ensus on the changes. This is probably overly optimistic given there was di=
scussion on the proposed YANG Library BIS changes. I=E2=80=99d vote to publ=
ish the existing draft.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> In any case, being able to see the proposed ch=
anges ASAP is critical.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Thanks,

>=C2=A0 =C2=A0 =C2=A0> Acee

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> On 1/22/18, 8:45 AM, "netmod on behalf of=
 Ladislav Lhotka" <netmo=
d-bounces@ietf.org on behalf of lhotka=
@nic.cz> wrote:

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Juergen Schoenwaelder <<=
a href=3D"mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jaco=
bs-university.de> writes:

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Fri, Jan 19, 2018 a=
t 06:05:15PM +0000, Robert Wilton wrote:

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Hence, for me, I s=
ee the choice as:

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 1) do we publish t=
he existing model now (perhaps also mark the draft as

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> experimental) foll=
owed by an updated draft with the NMDA compatible module?

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 2) do we publish b=
oth models in a single draft (e.g. with the existing model

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> in an appendix)?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 3) do we only publ=
ish a single version of the draft with an NMDA compliant

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> solution.

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> I think the situation =
is as follows (likely obvious but it may help to

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> make sure we are all o=
n the same page):

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> - the NI and LNE model=
s have a normative reference to

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0I-D.ietf-n=
etmod-schema-mount (and this makes sense since there are

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0MUST sente=
nces in the I-D)

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> - I-D.ietf-netmod-sche=
ma-mount (last updated in October) has normative

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0references=
 to RFC 7895 (old YANG library)

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> - RFC 7895 does not wo=
rk with NMDA, NMDA work on a YANG library update

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0replacing =
RFC 7895

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> So the YANG library up=
date is gating the schema mount update which is

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> gating the publication=
 of the NI and LNE models.

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> A proper solution woul=
d be to prioritize work on the YANG library

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> update and the schema =
mount update. I assume that the next revision of

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> the YANG library updat=
e (say end of January) is ready for WG last call

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> and perhaps the schema=
 mount authors can take an effort to get that

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> document there as well=
, say beginning of February.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I completely agree.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Lada

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> /js

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> --

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

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Phone: +49 421 200 358=
7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Fax:=C2=A0 =C2=A0+49 4=
21 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs=
-university.de/>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> ______________________=
_________________________

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> netmod mailing list
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> netmod@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> htt=
ps://www.ietf.org/mailman/listinfo/netmod

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Ladislav Lhotka

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Head, CZ.NIC Labs

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0PGP Key ID: 0xB8F92B08A9F76=
C67

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0___________________________=
____________________

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0netmod mailing list

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0netmod@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://=
www.ietf.org/mailman/listinfo/netmod

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>

>

>=C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Jacobs University Bremen gGmbH

>=C2=A0 =C2=A0 =C2=A0Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Campus Ring 1 | 28759 Bremen | Germany

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


>

>



--

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/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a11401eda9ce8760563660979--


From nobody Mon Jan 22 23:35: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 3A28912711D for ; Mon, 22 Jan 2018 23:35:02 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UGSWIq5uiDoj for ; Mon, 22 Jan 2018 23:34:59 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E904124BFA for ; Mon, 22 Jan 2018 23:34:59 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id C495E1AE02BE; Tue, 23 Jan 2018 08:34:56 +0100 (CET)
Date: Tue, 23 Jan 2018 08:34:56 +0100 (CET)
Message-Id: <20180123.083456.145541722754241477.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, acee@cisco.com, lhotka@nic.cz, rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20180122174445.bsfdh3dqzw54m2lw@elstar.local> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 07:35:02 -0000

QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBIaSwNCj4gDQo+IA0K
PiBPbiBNb24sIEphbiAyMiwgMjAxOCBhdCA5OjQ0IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
PA0KPiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiANCj4g
PiBUaGFua3MuIFRoZSBsb25nZXIgV0cgbGFzdCBjYWxsIHRocmVhZCBzdGFydGVkIHdpdGggUm9i
J3MgbWVzc2FnZSBpbg0KPiA+IHdoaWNoIGhlIGFsc28gYXNrZWQgYWJvdXQgYWxpZ25tZW50IHdp
dGggdGhlIFlBTkcgbGlicmFyeSB1cGRhdGUNCj4gPiAocG9zdGVkIE5vdmVtYmVyIDJuZCkuIFNv
IHRoZSBkb2N1bWVudCBpcyBpbiBhIGxpbWJvIHN0YXRlIHNpbmNlDQo+ID4gTm92ZW1iZXIgNnRo
Lg0KPiA+DQo+ID4NCj4gDQo+IENhbiBzb21lYm9keSBwbGVhc2UgYW5zd2VyIHNvbWUgc2ltcGxl
IHF1ZXN0aW9uczoNCj4gDQo+IFExKSB3aHkgY2FuJ3QgU00gdXNlIGF1Z21lbnQgdG8gYWRkIG9i
amVjdHMgdG8gWUxiaXM/DQoNClRoZSBpZGVhIGlzIHRoYXQgU00gYXVnbWVudHMgWUxiaXM7IHRo
aXMgaXMgd2hhdCB3ZSBhcmd1ZSBzaG91bGQgYmUNCmRvbmUgbm93Lg0KDQo+IFEyKSAgd2h5IHNo
b3VsZCByZWFkZXJzL2RldmVsb3BlcnMgb2YgWUxiaXMgbmVlZCB0byBrbm93DQo+IGFib3V0IFNN
IGlmIHRoZWlyIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3VwcG9ydCBTTSBhdCBhbGw/DQoNClRo
ZXkgZG9uJ3QuICBUaGUgaWRlYSBpcyB0byBwdXQgYWxsIFNNLXJlbGF0ZWQgc3R1ZmYgaW4gU00u
ICBObw0KY2hhbmdlcyB0byBZTGJpcy4NCg0KPiBRMykgSXMgdGhlcmUgYSBtc2cgaW4gdGhlIGVt
YWlsIGFyY2hpdmUgdGhhdCBleHBsYWlucyB0aGUgcmVhc29ucyB0aGF0DQo+IFlMYmlzIG5lZWRz
IHRvIGJlIGRlbGF5ZWQ/IFdoZXJlIGlzIHRoZSBjb25jcmV0ZSBwcm9wb3NhbCB0byBhZGQNCj4g
c3BlY2lmaWMgb2JqZWN0cyB0byBZTGJpcz8NCg0KWUxiaXMgZG9lcyBub3QgbmVlZCB0byBiZSBk
ZWxheWVkLiAgV2UgaG9wZSBpdCBjYW4gYWR2YW5jZSBxdWlja2x5Lg0KDQoNCi9tYXJ0aW4NCg0K
DQoNCj4gDQo+IA0KPiAvanMNCj4gPg0KPiA+DQo+IA0KPiBBbmR5DQo+IA0KPiANCj4gDQo+ID4g
T24gTW9uLCBKYW4gMjIsIDIwMTggYXQgMDQ6NTg6MTVQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFj
ZWUpIHdyb3RlOg0KPiA+ID4gSXQgd2FzIFdHIExhc3QgQ2FsbOKAmWVkOiBodHRwczovL21haWxh
cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC8NCj4gPiBjc1V2czY0MDhFbjB5WS12YXB5
VTNJRmNKcVENCj4gPiA+DQo+ID4gPiBBbmQgaXQgd2FzIGNsb3NlZDogaHR0cHM6Ly9tYWlsYXJj
aGl2ZS5pZXRmLm9yZy8NCj4gPiBhcmNoL21zZy9uZXRtb2QvZ2JYRTRMZTFJXzNZNW9hTm5wallv
WlpaNGx3DQo+ID4gPg0KPiA+ID4gSG93ZXZlciwgaXQgbWF5IG5vdCBoYXZlIGV2ZXIgY29tcGxl
dGVkLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IEFjZWUNCj4gPiA+DQo+ID4gPiBPbiAx
LzIyLzE4LCAxMTo0NSBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtDQo+ID4gdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gICAgIEFj
ZWUsDQo+ID4gPg0KPiA+ID4gICAgIHRoZSBkb2N1bWVudHMgdGhhdCBoYXZlIGFscmVhZHkgZmlu
aXNoZWQgV0cgTGFzdCBDYWxsIGhhdmUgYQ0KPiA+IG5vcm1hdGl2ZQ0KPiA+ID4gICAgIHJlZmVy
ZW5jZSBvbiBzY2hlbWEgbW91bnQsIHdoaWNoIGhhcyBub3QgeWV0IGZpbmlzaGVkIFdHIExhc3Qg
Q2FsbCBhcw0KPiA+ID4gICAgIGZhciBhcyBJIHJlY2FsbC4gSSB0aGluayB0aGUgUkZDIGVkaXRv
ciBkb2VzIG5vdCBwdWJsaXNoIGEgZG9jdW1lbnQNCj4gPiA+ICAgICB3aXRoIGEgbWlzc2luZyBu
b3JtYXRpdmUgcmVmZXJlbmNlLiBJIGNvbnRpbnVlIHRvIGJlbGlldmUgdGhhdCB0aGUNCj4gPiA+
ICAgICB0aW1lIGRpZmZlcmVuY2UgYmV0d2VlbiBkb2luZyB0aGUgcmlnaHQgdGhpbmcgYW5kIGRv
aW5nIHNvbWV0aGluZw0KPiA+ID4gICAgIGZhc3RlciB1c2luZyBkZWZpbml0aW9uIHdlIGFyZSBp
biB0aGUgcHJvY2VzcyB0byBkZXByZWNhdGUgaXMgcmVhbGx5DQo+ID4gPiAgICAgc21hbGwuIEJ1
dCBvZiBjb3Vyc2UsIEkgbWF5IGJlIGVudGlyZWx5IHdyb25nLg0KPiA+ID4NCj4gPiA+ICAgICAv
anMNCj4gPiA+DQo+ID4gPiAgICAgT24gTW9uLCBKYW4gMjIsIDIwMTggYXQgMDQ6MTg6MTVQTSAr
MDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPiA+ID4gICAgID4gSGkgTGFkYSwNCj4g
PiA+ICAgICA+DQo+ID4gPiAgICAgPiBNeSBwcmltYXJ5IGNvbmNlcm4gaXMgdGhhdCB0aGUgWUFO
RyBTY2hlbWEgTW91bnQgZGVsYXkgd2lsbCBub3QNCj4gPiBvbmx5IGhvbGQgdGhlIE5JL0xORSBi
dXQgYWxsIHRoZSBtb2RlbHMgdGhhdCBhcmUgZGVwZW5kZW50IG9uIHRoZW0gKGUuZy4sDQo+ID4g
TDJWUE4gYW5kIEwzVlBOKS4gVGhpcyBpcyBmb3IgYSBkb2N1bWVudCB0aGF0IGhhcyBhbHJlYWR5
IGZpbmlzaGVkIFdHIExhc3QNCj4gPiBDYWxsLiBBZGRpdGlvbmFsbHksIHlvdXIgZXN0aW1hdGUg
Zm9yIHRoZSBzaXplIG9mIHRoZSBjaGFuZ2UgYW5kIHRpbWUgdG8NCj4gPiByZWFjaCBzdGFuZGFy
ZGl6YXRpb24gaXMgYmFzZWQgb24gdGhlcmUgYmVpbmcgaW1tZWRpYXRlIGNvbnNlbnN1cyBvbiB0
aGUNCj4gPiBjaGFuZ2VzLiBUaGlzIGlzIHByb2JhYmx5IG92ZXJseSBvcHRpbWlzdGljIGdpdmVu
IHRoZXJlIHdhcyBkaXNjdXNzaW9uIG9uDQo+ID4gdGhlIHByb3Bvc2VkIFlBTkcgTGlicmFyeSBC
SVMgY2hhbmdlcy4gSeKAmWQgdm90ZSB0byBwdWJsaXNoIHRoZSBleGlzdGluZw0KPiA+IGRyYWZ0
Lg0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+IEluIGFueSBjYXNlLCBiZWluZyBhYmxlIHRvIHNl
ZSB0aGUgcHJvcG9zZWQgY2hhbmdlcyBBU0FQIGlzDQo+ID4gY3JpdGljYWwuDQo+ID4gPiAgICAg
Pg0KPiA+ID4gICAgID4gVGhhbmtzLA0KPiA+ID4gICAgID4gQWNlZQ0KPiA+ID4gICAgID4NCj4g
PiA+ICAgICA+IE9uIDEvMjIvMTgsIDg6NDUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlz
bGF2IExob3RrYSIgPA0KPiA+IG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBs
aG90a2FAbmljLmN6PiB3cm90ZToNCj4gPiA+ICAgICA+DQo+ID4gPiAgICAgPiAgICAgSnVlcmdl
biBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+
ID4gd3JpdGVzOg0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+ICAgICA+IE9uIEZyaSwgSmFuIDE5
LCAyMDE4IGF0IDA2OjA1OjE1UE0gKzAwMDAsIFJvYmVydCBXaWx0b24NCj4gPiB3cm90ZToNCj4g
PiA+ICAgICA+ICAgICA+Pg0KPiA+ID4gICAgID4gICAgID4+IEhlbmNlLCBmb3IgbWUsIEkgc2Vl
IHRoZSBjaG9pY2UgYXM6DQo+ID4gPiAgICAgPiAgICAgPj4gMSkgZG8gd2UgcHVibGlzaCB0aGUg
ZXhpc3RpbmcgbW9kZWwgbm93IChwZXJoYXBzIGFsc28gbWFyaw0KPiA+IHRoZSBkcmFmdCBhcw0K
PiA+ID4gICAgID4gICAgID4+IGV4cGVyaW1lbnRhbCkgZm9sbG93ZWQgYnkgYW4gdXBkYXRlZCBk
cmFmdCB3aXRoIHRoZSBOTURBDQo+ID4gY29tcGF0aWJsZSBtb2R1bGU/DQo+ID4gPiAgICAgPiAg
ICAgPj4gMikgZG8gd2UgcHVibGlzaCBib3RoIG1vZGVscyBpbiBhIHNpbmdsZSBkcmFmdCAoZS5n
LiB3aXRoDQo+ID4gdGhlIGV4aXN0aW5nIG1vZGVsDQo+ID4gPiAgICAgPiAgICAgPj4gaW4gYW4g
YXBwZW5kaXgpPw0KPiA+ID4gICAgID4gICAgID4+IDMpIGRvIHdlIG9ubHkgcHVibGlzaCBhIHNp
bmdsZSB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aXRoIGFuDQo+ID4gTk1EQSBjb21wbGlhbnQNCj4g
PiA+ICAgICA+ICAgICA+PiBzb2x1dGlvbi4NCj4gPiA+ICAgICA+ICAgICA+Pg0KPiA+ID4gICAg
ID4gICAgID4NCj4gPiA+ICAgICA+ICAgICA+IEkgdGhpbmsgdGhlIHNpdHVhdGlvbiBpcyBhcyBm
b2xsb3dzIChsaWtlbHkgb2J2aW91cyBidXQgaXQNCj4gPiBtYXkgaGVscCB0bw0KPiA+ID4gICAg
ID4gICAgID4gbWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGFnZSk6DQo+ID4gPiAg
ICAgPiAgICAgPg0KPiA+ID4gICAgID4gICAgID4gLSB0aGUgTkkgYW5kIExORSBtb2RlbHMgaGF2
ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8NCj4gPiA+ICAgICA+ICAgICA+ICAgSS1ELmlldGYt
bmV0bW9kLXNjaGVtYS1tb3VudCAoYW5kIHRoaXMgbWFrZXMgc2Vuc2Ugc2luY2UNCj4gPiB0aGVy
ZSBhcmUNCj4gPiA+ICAgICA+ICAgICA+ICAgTVVTVCBzZW50ZW5jZXMgaW4gdGhlIEktRCkNCj4g
PiA+ICAgICA+ICAgICA+DQo+ID4gPiAgICAgPiAgICAgPiAtIEktRC5pZXRmLW5ldG1vZC1zY2hl
bWEtbW91bnQgKGxhc3QgdXBkYXRlZCBpbiBPY3RvYmVyKSBoYXMNCj4gPiBub3JtYXRpdmUNCj4g
PiA+ICAgICA+ICAgICA+ICAgcmVmZXJlbmNlcyB0byBSRkMgNzg5NSAob2xkIFlBTkcgbGlicmFy
eSkNCj4gPiA+ICAgICA+ICAgICA+DQo+ID4gPiAgICAgPiAgICAgPiAtIFJGQyA3ODk1IGRvZXMg
bm90IHdvcmsgd2l0aCBOTURBLCBOTURBIHdvcmsgb24gYSBZQU5HDQo+ID4gbGlicmFyeSB1cGRh
dGUNCj4gPiA+ICAgICA+ICAgICA+ICAgcmVwbGFjaW5nIFJGQyA3ODk1DQo+ID4gPiAgICAgPiAg
ICAgPg0KPiA+ID4gICAgID4gICAgID4gU28gdGhlIFlBTkcgbGlicmFyeSB1cGRhdGUgaXMgZ2F0
aW5nIHRoZSBzY2hlbWEgbW91bnQgdXBkYXRlDQo+ID4gd2hpY2ggaXMNCj4gPiA+ICAgICA+ICAg
ICA+IGdhdGluZyB0aGUgcHVibGljYXRpb24gb2YgdGhlIE5JIGFuZCBMTkUgbW9kZWxzLg0KPiA+
ID4gICAgID4gICAgID4NCj4gPiA+ICAgICA+ICAgICA+IEEgcHJvcGVyIHNvbHV0aW9uIHdvdWxk
IGJlIHRvIHByaW9yaXRpemUgd29yayBvbiB0aGUgWUFORw0KPiA+IGxpYnJhcnkNCj4gPiA+ICAg
ICA+ICAgICA+IHVwZGF0ZSBhbmQgdGhlIHNjaGVtYSBtb3VudCB1cGRhdGUuIEkgYXNzdW1lIHRo
YXQgdGhlIG5leHQNCj4gPiByZXZpc2lvbiBvZg0KPiA+ID4gICAgID4gICAgID4gdGhlIFlBTkcg
bGlicmFyeSB1cGRhdGUgKHNheSBlbmQgb2YgSmFudWFyeSkgaXMgcmVhZHkgZm9yIFdHDQo+ID4g
bGFzdCBjYWxsDQo+ID4gPiAgICAgPiAgICAgPiBhbmQgcGVyaGFwcyB0aGUgc2NoZW1hIG1vdW50
IGF1dGhvcnMgY2FuIHRha2UgYW4gZWZmb3J0IHRvDQo+ID4gZ2V0IHRoYXQNCj4gPiA+ICAgICA+
ICAgICA+IGRvY3VtZW50IHRoZXJlIGFzIHdlbGwsIHNheSBiZWdpbm5pbmcgb2YgRmVicnVhcnku
DQo+ID4gPiAgICAgPg0KPiA+ID4gICAgID4gICAgIEkgY29tcGxldGVseSBhZ3JlZS4NCj4gPiA+
ICAgICA+DQo+ID4gPiAgICAgPiAgICAgTGFkYQ0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+ICAg
ICA+DQo+ID4gPiAgICAgPiAgICAgPiAvanMNCj4gPiA+ICAgICA+ICAgICA+DQo+ID4gPiAgICAg
PiAgICAgPiAtLQ0KPiA+ID4gICAgID4gICAgID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAg
ICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4NCj4gPiBnR21iSA0KPiA+ID4gICAgID4gICAg
ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg
QnJlbWVuDQo+ID4gfCBHZXJtYW55DQo+ID4gPiAgICAgPiAgICAgPiBGYXg6ICAgKzQ5IDQyMSAy
MDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtDQo+ID4gdW5pdmVyc2l0eS5kZS8+
DQo+ID4gPiAgICAgPiAgICAgPg0KPiA+ID4gICAgID4gICAgID4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ICAgICA+ICAgICA+IG5ldG1vZCBt
YWlsaW5nIGxpc3QNCj4gPiA+ICAgICA+ICAgICA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gICAg
ID4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4g
PiA+ICAgICA+DQo+ID4gPiAgICAgPiAgICAgLS0NCj4gPiA+ICAgICA+ICAgICBMYWRpc2xhdiBM
aG90a2ENCj4gPiA+ICAgICA+ICAgICBIZWFkLCBDWi5OSUMgTGFicw0KPiA+ID4gICAgID4gICAg
IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+
ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+
ID4gICAgID4gICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ICAgICA+ICAgICBuZXRtb2RA
aWV0Zi5vcmcNCj4gPiA+ICAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+DQo+ID4gPg0KPiA+ID4gICAg
IC0tDQo+ID4gPiAgICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p
dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiA+ICAgICBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg
ICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfA0KPiA+IEdlcm1hbnkNCj4gPiA+
ICAgICBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMt
dW5pdmVyc2l0eS5kZS8+DQo+ID4gPg0KPiA+ID4NCj4gPg0KPiA+IC0tDQo+ID4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g
PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0
cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0
DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4gPg0K


From nobody Mon Jan 22 23:47:04 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 1AF4F12D962; Mon, 22 Jan 2018 23:46:57 -0800 (PST)
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.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151669361705.29662.10176504098163066598@ietfa.amsl.com>
Date: Mon, 22 Jan 2018 23:46:57 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 07:46:57 -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 Tree Diagrams
        Authors         : Martin Bjorklund
                          Lou Berger
	Filename        : draft-ietf-netmod-yang-tree-diagrams-05.txt
	Pages           : 13
	Date            : 2018-01-22

Abstract:
   This document captures the current syntax used in YANG module Tree
   Diagrams.  The purpose of the document is to provide a single
   location for this definition.  This syntax may be updated from time
   to time based on the evolution of the YANG language.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-05


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 Tue Jan 23 00:24: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 3BD931243FE for ; Tue, 23 Jan 2018 00:24:29 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aoZ6hmn1hX7Y for ; Tue, 23 Jan 2018 00:24:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD0120726 for ; Tue, 23 Jan 2018 00:24:27 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B3771AE02BE; Tue, 23 Jan 2018 09:24:26 +0100 (CET)
Date: Tue, 23 Jan 2018 09:24:25 +0100 (CET)
Message-Id: <20180123.092425.1788188537428313683.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 08:24:29 -0000

Hi,

So do you believe that this decision reflects rough consensus in the
WG?

I hope that the document writeup will show that the WG is divided on
this issue.

For the record, if this means that using Schema Mount *with* NMDA gets
delayed, I strongly object to this decision.

Assuming this document now moves forward as-is, can we assume that we
can start to work on the bis document immediately?  What is needed?

  1.  a new individual draft
  2.  some time until this becomes WG draft
  3.  some time before WGLC

Do we have to go through all these steps?

This new draft would immediately obsolete the current SM document,
right?  And it would mark the current SM YANG nodes as deprecated.

Maybe we can send both the original document and the bis document to
the IESG at the same time ;-)


/martin


Kent Watsen  wrote:
> 
> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
> 
> Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationship with NMDA and rfc7895bis and an alternate representation of inline schema.  These have been considered respecting their impact on the last call consensus and it is the position of the chairs that it is best to advance the existing schema-mount document at this time.
> 
> Given that there are significant concerns for how the solution proposed in this draft operates with NMDA, we do think it reasonable to add an applicability statement to the draft that covers its operation in NMDA implementations. We do not believe that such a statement substantively alters the draft nor would it impact drafts that normatively reference the current draft.
> 
> In addition to resolving the remaining open thread [1], we also agree with the recently made comment that the schema mount draft should allow the use of rfc7895bis (i.e., not reference /modules-state), thereby enabling the draft's use (though not ideal) on servers supporting rfc7895bis.
> 
> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement. 
> 
> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
> 
> Thanks,
> Kent, Lou, and Joel
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Jan 23 03:11: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 D22371200FC; Tue, 23 Jan 2018 03:11:48 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MYg3LxIA5HUw; Tue, 23 Jan 2018 03:11:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02E3D1200C1; Tue, 23 Jan 2018 03:11:46 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id BBADC1AE043F; Tue, 23 Jan 2018 12:03:52 +0100 (CET)
Date: Tue, 23 Jan 2018 12:03:51 +0100 (CET)
Message-Id: <20180123.120351.835152015425541015.mbj@tail-f.com>
To: joelja@bogus.com
Cc: netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
From: Martin Bjorklund 
In-Reply-To: <7833f013-22e0-6d47-18ee-9569f48fe932@bogus.com>
References:  <1fcc0c28-4c99-c0c7-91ae-f2e3f0b009af@bogus.com> <7833f013-22e0-6d47-18ee-9569f48fe932@bogus.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Closure - : WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 11:11:49 -0000

Hi,

I just posted draft-ietf-netmod-yang-tree-diagrams-05.txt.  It
addressed the issue below, and the other WGLC issues:

  o  the main tree now uses 2 spaces for indentation instead of 4

  o  added example for expanded/unexpanded grouping

  o  fixed errors in the row syntax

  o  aligned all examples to use proper amount of whitespace
     indentation

This document should now be ready to progress.



/martin


joel jaeggli  wrote:
> Greetings,
> =

> This WGLC is concluded.
> =

> We have consensus to advance the document.
> =

> The authors should submit an update reflecting the result of the
> dicussion on the text representation of tree diagrams not being usabl=
e
> by machine parsers.
> =

> The exchange between Robert Wilton and Martin Bjorkland I think sums
> this up succinctly.
> =

> (Robert)
> =

> OK, so the "Providing some guidance for how to represent the tree is
> good" is along the lines of what I was thinking for the "algorithm"
> would be for 2.
> =

> E.g. something along the lines of:
> "Arbitrary whitespace is allowed between any of the whitespace
> separated fields (e.g.  and ).=A0 Additional whitespace m=
ay
> be used to column align fields (e.g. within a list or container) to
> improve readability".
> =

> (Martin)
> This is fine with me.  It is something in between (1) and (2) which
> people preferred.  I will add this text.
> =

> Thanks all, looking forward to IETF last call.
> =

> joel
> =A0
> =

> =

> On 1/16/18 9:24 AM, joel jaeggli wrote:
> > The current dicussion on the draft is not yet concluded. The WGLC w=
ill
> > conclude when discussion of the editorial changes is complete.
> >
> > Thanks
> > joel
> >
> > On 1/10/18 8:16 AM, joel jaeggli wrote:
> >> Just a reminder given the date that this was posted. This last cal=
l is
> >> expected to complete Monday 1/15/18.
> >>
> >> Thanks
> >>
> >> joel
> >>
> >>
> >> On 1/1/18 2:01 PM, joel jaeggli wrote:
> >>> Greetings,
> >>>
> >>> We hope  the new year is a time to make great progess on outstand=
ing
> >>> documents before preparation for the  London IETF begins in earne=
st.
> >>>
> >>> This starts a two-week working group last call on:
> >>>
> >>>  YANG Tree Diagrams
> >>> draft-ietf-netmod-yang-tree-diagrams
> >>>
> >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diag=
rams/
> >>>
> >>> Please send email to the list indicating your support or concerns=
.=

> >>>
> >>> We are particularly interested in statements of the form:
> >>>
> >>>   * I have reviewed this draft and found no issues.
> >>>   * I have reviewed this draft and found the following issues: ..=
.=

> >>>
> >>>
> >>> Thank you,
> >>> NETMOD WG Chairs
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> 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


From nobody Tue Jan 23 06:09:48 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 5908C126B72 for ; Tue, 23 Jan 2018 06:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 2ITJa_0xiP4w for ; Tue, 23 Jan 2018 06:09:44 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 9D5FE126579 for ; Tue, 23 Jan 2018 06:09:44 -0800 (PST)
Received: from MBP.local ([50.224.58.242]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0NE9gjQ017107 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 23 Jan 2018 14:09:43 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [50.224.58.242] claimed to be MBP.local
To: Martin Bjorklund , kwatsen@juniper.net
Cc: netmod@ietf.org
References:  <20180123.092425.1788188537428313683.mbj@tail-f.com>
From: joel jaeggli 
Message-ID: <49d02eec-a9b7-ca7d-5bbe-4f0a1f8e07c3@bogus.com>
Date: Tue, 23 Jan 2018 09:09:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180123.092425.1788188537428313683.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 14:09:46 -0000

On 1/23/18 3:24 AM, Martin Bjorklund wrote:
> Hi,
>
> So do you believe that this decision reflects rough consensus in the
> WG?
>
> I hope that the document writeup will show that the WG is divided on
> this issue.
>
> For the record, if this means that using Schema Mount *with* NMDA gets
> delayed, I strongly object to this decision.
I don't think it does. assuming we had a draft that addresses that
problem. we could poll for working group adoption now.=C2=A0 and proceed =
with
that one accordingly. what happens there is orthogonal to sending this
one on it's way.
> Assuming this document now moves forward as-is, can we assume that we
> can start to work on the bis document immediately?  What is needed?
>
>   1.  a new individual draft
>   2.  some time until this becomes WG draft
call for adoption can occur once we have a draft.
>   3.  some time before WGLC
>
> Do we have to go through all these steps?
there's roughly three weeks of more or less required process time=C2=A0
between submission to a working group and the close of WGLC, everything
else is compressible to various degrees if we can satisfy our standards
for consensus, and we don't spend to much time orbiting the same point.
> This new draft would immediately obsolete the current SM document,
> right?  And it would mark the current SM YANG nodes as deprecated.
>
> Maybe we can send both the original document and the bis document to
> the IESG at the same time ;-)
If you hurry. the first one has taken a bit over 2 years to this point,
I certainly think we can reel that in.
>
> /martin
>
>
> Kent Watsen  wrote:
>> Thank you all for the important discussion since the completion of WGL=
C on Nov 6th.
>>
>> Per normal process, drafts typically progress once LC comments are add=
ress unless significant faults are found.  Post LC comments have been mad=
e, which needed consideration, notably the relationship with NMDA and rfc=
7895bis and an alternate representation of inline schema.  These have bee=
n considered respecting their impact on the last call consensus and it is=
 the position of the chairs that it is best to advance the existing schem=
a-mount document at this time.
>>
>> Given that there are significant concerns for how the solution propose=
d in this draft operates with NMDA, we do think it reasonable to add an a=
pplicability statement to the draft that covers its operation in NMDA imp=
lementations. We do not believe that such a statement substantively alter=
s the draft nor would it impact drafts that normatively reference the cur=
rent draft.
>>
>> In addition to resolving the remaining open thread [1], we also agree =
with the recently made comment that the schema mount draft should allow t=
he use of rfc7895bis (i.e., not reference /modules-state), thereby enabli=
ng the draft's use (though not ideal) on servers supporting rfc7895bis.
>>
>> The chairs will propose specific text for the updates mentioned in thi=
s message to be reviewed by the WG for correctness before final submissio=
n and advancement.=20
>>
>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html=

>>
>> Thanks,
>> Kent, Lou, and Joel
>>
>>
>>
>> _______________________________________________
>> 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 Tue Jan 23 08:52: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 0BDF212706D for ; Tue, 23 Jan 2018 08:52:54 -0800 (PST)
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 LrYNPN6947RI for ; Tue, 23 Jan 2018 08:52:52 -0800 (PST)
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 4CD021270B4 for ; Tue, 23 Jan 2018 08:52:52 -0800 (PST)
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 w0NGmj2M031943; Tue, 23 Jan 2018 08:52:51 -0800
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=Q47/1AZ02CPD6OzTsd/rg2IA38TXVynHXQciUfCwIVs=; b=jDyy5g6JCAhEnQjfGilazuhcrBfcavmEv0zBCr1eVSFav8wG6Wob4mUJ1dOMenTiYPAB D5xC9V/QsMYsg2vj1nTdSVZFCcIo7jk3iNi4GgmX+EL+oB7u6pOc+BJO1IFMiZ1oP3pD zN91SMm0HcXiEtnUTMfud2yZfDiahcrHdQDNUkhZKPZQ0s/nIokCL6G64PS1USrdUszL GsGLgRCuruxnaG7OSD0C3E7WzGkD65LCng3wv/VLgE+An/Thd73wtKx5eVMEUe351ZRb Hkvr2KJhMDgRoD3DGbxOtNDWlxTb6e9gYH0meTSGmNWfwv/THxGMl+/V/RThEpH0iOHi dA== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2fp6rwga1b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 08:52:51 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3468.namprd05.prod.outlook.com (10.174.240.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Tue, 23 Jan 2018 16:52:50 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.013; Tue, 23 Jan 2018 16:52:50 +0000
From: Kent Watsen 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] moving forward with schema mount
Thread-Index: AQHTk7xos3ciVL7Jy0SyClhY/I/+rKOBH66AgAA6OoA=
Date: Tue, 23 Jan 2018 16:52:50 +0000
Message-ID: <2411D1AA-7D86-4DCD-BB8B-E7AE416EEFAB@juniper.net>
References:  <20180123.092425.1788188537428313683.mbj@tail-f.com>
In-Reply-To: <20180123.092425.1788188537428313683.mbj@tail-f.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.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3468; 7:QMjWAHruIKwqW5bpxHd65BhbN51oSpxYtA+QNg67sOhADxZflUrNMXwEIsjealeW+2oijTWvDEpsWuy1VTMK+R6SCJY1VOOYnPLQPJr2yNPNNYmOaustKScCqZ/ZNA5Pt4H+v1ikamg+iwU8j9KLtFc0uRIhS41GJEST9ldwMg2COToLS0jP9naTXbXjg+njQ861xuck70TldtI1nUX6CxNr4dhXz3N5Je+C7vdHnDYql40Ut1VygmhK5sRnjhkj
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f774736a-16df-4cae-8c9c-08d56281bcd4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3468; 
x-ms-traffictypediagnostic: DM5PR05MB3468:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3468; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3468; 
x-forefront-prvs: 05610E64EE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(39380400002)(189003)(199004)(102836004)(33656002)(83506002)(14454004)(4326008)(305945005)(25786009)(6506007)(7736002)(478600001)(99286004)(36756003)(5660300001)(82746002)(2950100002)(6916009)(6116002)(3846002)(3280700002)(76176011)(2906002)(66066001)(77096007)(58126008)(6512007)(316002)(6436002)(229853002)(26005)(53936002)(6486002)(3660700001)(97736004)(6246003)(68736007)(105586002)(106356001)(8936002)(86362001)(2900100001)(81156014)(81166006)(8676002)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3468; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: F5CfEJRqXb2lHVYK0OuWtzFAZtlBDbpSlPKyRt9wPqx8aI7HYgHKiLZFIuTGz3LFSTv4HEvJmFcjRxXhcjsm8w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <7D415EC1F2E35441ABCDA682AF48BC7C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f774736a-16df-4cae-8c9c-08d56281bcd4
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 16:52:50.0361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3468
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_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-1711220000 definitions=main-1801230231
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 16:52:54 -0000

DQo+IFNvIGRvIHlvdSBiZWxpZXZlIHRoYXQgdGhpcyBkZWNpc2lvbiByZWZsZWN0cyByb3VnaCBj
b25zZW5zdXMNCj4gaW4gdGhlIFdHPw0KDQpOb3QgY3VycmVudGx5LCBhcyB0aGVyZSBhcmUgdHdv
IHZvY2FsIGdyb3VwcyB3aXRoIG9wcG9zaW5nIA0Kdmlld3BvaW50cy4gIEhvd2V2ZXIsIHRoZXJl
IHdhcyBzdHJvbmcgZm9yIGFkdmFuY2luZyBpdCANCmJlZm9yZS4gIFRoZSBjaGFpcnMgaGFkIHRv
IG1ha2UgYSBkZWNpc2lvbiBhbmQsIGFzIHlvdSBjYW4NCmltYWdpbmUsIGl0IHdhc24ndCBlYXN5
LiAgVWx0aW1hdGVseSwgdG8gdXNlIGEgY29sbG9xdWlhbGlzbSwNCmEgYmlyZCBpbiBoYW5kIGlz
IGJldHRlciB0aGFuIHR3byBpbiB0aGUgYnVzaC4NCg0KDQo+IEkgaG9wZSB0aGF0IHRoZSBkb2N1
bWVudCB3cml0ZXVwIHdpbGwgc2hvdyB0aGF0IHRoZSBXRyBpcw0KPiBkaXZpZGVkIG9uIHRoaXMg
aXNzdWUuDQoNCkl0IHdpbGwgYW5kLCB1bmRvdWJ0ZWRseSwgdGhlIElFVEYgTGFzdCBDYWxsIHdp
bGwgYmUgYW4gDQppbnRlcmVzdGluZyBvbmUuDQoNCg0KPiBUaGlzIG5ldyBkcmFmdCB3b3VsZCBp
bW1lZGlhdGVseSBvYnNvbGV0ZSB0aGUgY3VycmVudCBTTSBkb2N1bWVudCwNCj4gcmlnaHQ/ICBB
bmQgaXQgd291bGQgbWFyayB0aGUgY3VycmVudCBTTSBZQU5HIG5vZGVzIGFzIGRlcHJlY2F0ZWQu
DQoNCkEgV0cgZGVjaXNpb24sIGJ1dCBzZWVtcyByZWFzb25hYmxlLiAgQXJlIHRoZXJlIGFueSBz
bWFsbCB0aGluZ3MNCnRoYXQgY2FuIGJlIGRvbmUgdG8gdGhlIGN1cnJlbnQgbW9kZWwgdG8gZmFj
aWxpdGF0ZSB0aGlzPw0KDQoNCj4gTWF5YmUgd2UgY2FuIHNlbmQgYm90aCB0aGUgb3JpZ2luYWwg
ZG9jdW1lbnQgYW5kIHRoZSBiaXMgZG9jdW1lbnQNCj4gdG8gdGhlIElFU0cgYXQgdGhlIHNhbWUg
dGltZSA7LSkNCg0KVGhpcyB3b3VsZCBiZSBmYWJ1bG91cy4NCg0KDQpLZW50DQoNCg0KDQo=


From nobody Tue Jan 23 12:26: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 33D1612D778 for ; Tue, 23 Jan 2018 12:26:17 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 7LCsj0GQsfF8 for ; Tue, 23 Jan 2018 12:26:15 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCDA12AF84 for ; Tue, 23 Jan 2018 12:26:14 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0FC816B7; Tue, 23 Jan 2018 21:26:13 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4137O7dskg4A; Tue, 23 Jan 2018 21:26:09 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Jan 2018 21:26:12 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C330E20147; Tue, 23 Jan 2018 21:26:12 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8ByBSJe2bBVR; Tue, 23 Jan 2018 21:26:12 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E65B200F0; Tue, 23 Jan 2018 21:26:12 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 03DA04226894; Tue, 23 Jan 2018 21:26:10 +0100 (CET)
Date: Tue, 23 Jan 2018 21:26:10 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Message-ID: <20180123202610.vhclqrsfshevtbj3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 20:26:17 -0000

On Mon, Jan 22, 2018 at 08:05:54PM +0000, Kent Watsen wrote:
> 
> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
> 
> Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationship with NMDA and rfc7895bis and an alternate representation of inline schema.  These have been considered respecting their impact on the last call consensus and it is the position of the chairs that it is best to advance the existing schema-mount document at this time.
>

If we take the formal road, then you may want to read again Robert
Wilton's email posted on November 2nd (Thu, 2 Nov 2017 17:06:34 +0000)
again. He does talk about YANG library alignment - so YANG library
alignment is not just post LC comments. (I personally prefer to have
technical discussion than formal discussions but if it is necessary to
g there...)

/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 Jan 23 12:32: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 3394212AF84 for ; Tue, 23 Jan 2018 12:32:55 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 6pOnme0-ZXhT for ; Tue, 23 Jan 2018 12:32:54 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CDD12AF83 for ; Tue, 23 Jan 2018 12:32:53 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 99B056B7; Tue, 23 Jan 2018 21:32:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id A0xazdh_Aerd; Tue, 23 Jan 2018 21:32:48 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Jan 2018 21:32:52 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 580B220147; Tue, 23 Jan 2018 21:32:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kgke_1bBcYZ8; Tue, 23 Jan 2018 21:32:52 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2DFA200F0; Tue, 23 Jan 2018 21:32:51 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id CF73F422690C; Tue, 23 Jan 2018 21:32:51 +0100 (CET)
Date: Tue, 23 Jan 2018 21:32:51 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20180123203251.pucunzlddzvigabr@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" 
References:  <20180123.092425.1788188537428313683.mbj@tail-f.com> <2411D1AA-7D86-4DCD-BB8B-E7AE416EEFAB@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2411D1AA-7D86-4DCD-BB8B-E7AE416EEFAB@juniper.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 20:32:55 -0000

On Tue, Jan 23, 2018 at 04:52:50PM +0000, Kent Watsen wrote:
> 
> Not currently, as there are two vocal groups with opposing 
> viewpoints.  However, there was strong for advancing it 
> before.  The chairs had to make a decision and, as you can
> imagine, it wasn't easy.  Ultimately, to use a colloquialism,
> a bird in hand is better than two in the bush.
>

I am not convinced that publishing two competing schema mount
solutions at more or less the same time makes the Internet work
better.

/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 Jan 23 14:55:37 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 CF82212D87A; Tue, 23 Jan 2018 14:55:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francis Dupont 
To: 
Cc: draft-ietf-netmod-rfc8022bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151674813480.15558.2493616807577632397@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 14:55:34 -0800
Archived-At: 
Subject: [netmod] Genart telechat review of draft-ietf-netmod-rfc8022bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 22:55:35 -0000

Reviewer: Francis Dupont
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-netmod-rfc8022bis-??
Reviewer: Francis Dupont
Review Date: 2018-01-23
IETF LC End Date: 2018-01-15
IESG Telechat date: 2018-01-25

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: I'll send another message tomorrow with a few comments.



From nobody Tue Jan 23 15:23:36 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 B1A8E12D93E; Tue, 23 Jan 2018 15:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8_fT9EWCF_Dz; Tue, 23 Jan 2018 15:23:24 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABAE12D876; Tue, 23 Jan 2018 15:23:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1302; q=dns/txt; s=iport; t=1516749803; x=1517959403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+mvV1mEtXkgQW3mciwyN42m9rI0lB0aLgObZJqt27pY=; b=DzVharluFjXSYwRepPtkDIVonJPoEDq4UvjjeTUkMhmnX3NwSeBuvtd7 EOh2gJbUWYvYL6rVe8tOMpWXO5G98/UDv4cu8yAzOZgpZtPF6dUfXnG96 I3vjhKzogwKjSO72j3dBARAAEYcOyb7OVE6TcYsQYZlXFi/c79MdI1OPs M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQBKw2da/4sNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWiiSOZYFbJ5c+ghcKI4UYAhqEXFQYAQEBAQEBAQE?= =?us-ascii?q?CayiFJAYjEUUQAgEIEAQGAiYCAgIwFRACBAENBYo1ELM9gieKVQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQ+DPIIVgz8pDIJ5gy8CAoFvBzECgl0xgjQBBIp4mQY?= =?us-ascii?q?CiBKNSYIbhh+LaY1UiU8CERkBgTsBHzmBUHAVZwGBf4RXeI0DgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,403,1511827200"; d="scan'208";a="349967046"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 23:23:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0NNNM25032346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jan 2018 23:23:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 18:23:21 -0500
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; Tue, 23 Jan 2018 18:23:21 -0500
From: "Acee Lindem (acee)" 
To: Francis Dupont , "gen-art@ietf.org" 
CC: "draft-ietf-netmod-rfc8022bis.all@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Genart telechat review of draft-ietf-netmod-rfc8022bis-06
Thread-Index: AQHTlJ1J77V9ue5JsU649qEg8oLSOKOCGRQA
Date: Tue, 23 Jan 2018 23:23:21 +0000
Message-ID: <12EDF8E9-63F3-46E7-9615-EFA32AFB154C@cisco.com>
References: <151674813480.15558.2493616807577632397@ietfa.amsl.com>
In-Reply-To: <151674813480.15558.2493616807577632397@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <349AB151C555154E94C3890E074D945F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Genart telechat review of draft-ietf-netmod-rfc8022bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jan 2018 23:23:26 -0000

VGhhbmtzIEZyYW5jaXMhDQpBY2VlDQoNCu+7v09uIDEvMjMvMTgsIDU6NTUgUE0sICJGcmFuY2lz
IER1cG9udCIgPEZyYW5jaXMuRHVwb250QGZkdXBvbnQuZnI+IHdyb3RlOg0KDQogICAgUmV2aWV3
ZXI6IEZyYW5jaXMgRHVwb250DQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkNCiAgICANCiAgICBJ
IGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2Vu
ZXJhbCBBcmVhDQogICAgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9j
dW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0KICAgIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFp
ci4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXINCiAgICBkb2N1bWVudCBzaGVw
aGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCiAg
ICANCiAgICBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQogICAg
DQogICAgPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uDQog
ICAgDQogICAgRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtPz8NCiAgICBS
ZXZpZXdlcjogRnJhbmNpcyBEdXBvbnQNCiAgICBSZXZpZXcgRGF0ZTogMjAxOC0wMS0yMw0KICAg
IElFVEYgTEMgRW5kIERhdGU6IDIwMTgtMDEtMTUNCiAgICBJRVNHIFRlbGVjaGF0IGRhdGU6IDIw
MTgtMDEtMjUNCiAgICANCiAgICBTdW1tYXJ5OiBSZWFkeQ0KICAgIA0KICAgIE1ham9yIGlzc3Vl
czogTm9uZQ0KICAgIA0KICAgIE1pbm9yIGlzc3VlczogTm9uZQ0KICAgIA0KICAgIE5pdHMvZWRp
dG9yaWFsIGNvbW1lbnRzOiBJJ2xsIHNlbmQgYW5vdGhlciBtZXNzYWdlIHRvbW9ycm93IHdpdGgg
YSBmZXcgY29tbWVudHMuDQogICAgDQogICAgDQogICAgDQoNCg==


From nobody Tue Jan 23 18:56: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 897E412D890; Tue, 23 Jan 2018 18:56:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-netmod-rfc8022bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151676258855.24213.12138954771524998033.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 18:56:28 -0800
Archived-At: 
Subject: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 02:56:28 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-netmod-rfc8022bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There are a few instances of 2119 keywords in lower case. Please consider using
the boilerplate from RFC 8174.



From nobody Tue Jan 23 19:21: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 ABC7A12D93E; Tue, 23 Jan 2018 19:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 c9g3eUZPT4gG; Tue, 23 Jan 2018 19:21:10 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43EF1275C5; Tue, 23 Jan 2018 19:21:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1578; q=dns/txt; s=iport; t=1516764069; x=1517973669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AWfPH5alHuHJBlRUkQtyfa3kXW2ElJXcb/TIBkUYkHQ=; b=m6p7hpomo9ICzTSwJDbF1sRI7n2TZp0DjuIKrkIu2KmEBtl5ORhauLQW S94bsBj7cv/R1lajH6o4TD8qoYaW8t3ZhvfFT4EOfgUI+CDTnbm8LX9l4 zgvnMxG6+FPDL0d5hCvrO1Vc2EiuBCmYjBZaQEP8LqzRREjPYyJtzBFak k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAQDT+mda/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWiiSOZplAFYICCiOFGAIahFxUGAEBAQEBAQEBAms?= =?us-ascii?q?ohSQGIxFFEAIBCBoCJgICAjAVEAIEAQ0FijUQswuCJ4pWAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWBD4M8ghWDaIMFgy8CAQEBAYE6ARIBH4MXMYI0BYpdmSYCiBK?= =?us-ascii?q?NSw2CDoYfi2mKd4JgiVACERkBgTsBHzlgVxEIcBVnAYF/gwmBTngBi1WBJYEXA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.46,405,1511827200"; d="scan'208";a="345202428"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 03:21:08 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w0O3L8pq022419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jan 2018 03:21:08 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 22:21:08 -0500
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; Tue, 23 Jan 2018 22:21:07 -0500
From: "Acee Lindem (acee)" 
To: Ben Campbell , The IESG 
CC: "draft-ietf-netmod-rfc8022bis@ietf.org" , Joel Jaeggli , "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
Thread-Index: AQHTlL7vMGTBCAt5aU6Rf6WvVSKU2aOCW0GA
Date: Wed, 24 Jan 2018 03:21:07 +0000
Message-ID: 
References: <151676258855.24213.12138954771524998033.idtracker@ietfa.amsl.com>
In-Reply-To: <151676258855.24213.12138954771524998033.idtracker@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <94CC9467707FDA44B266D9E1C4C2D364@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 03:21:12 -0000

SGkgQmVuLCANCg0K77u/T24gMS8yMy8xOCwgOTo1NiBQTSwgIkJlbiBDYW1wYmVsbCIgPGJlbkBu
b3N0cnVtLmNvbT4gd3JvdGU6DQoNCiAgICBCZW4gQ2FtcGJlbGwgaGFzIGVudGVyZWQgdGhlIGZv
bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAy
MmJpcy0wOTogTm8gT2JqZWN0aW9uDQogICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug
a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwg
YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g
Y3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICANCiAg
ICANCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l
bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg
SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUg
ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k
IGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u
ZXRtb2QtcmZjODAyMmJpcy8NCiAgICANCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog
ICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgVGhlcmUgYXJlIGEgZmV3
IGluc3RhbmNlcyBvZiAyMTE5IGtleXdvcmRzIGluIGxvd2VyIGNhc2UuIFBsZWFzZSBjb25zaWRl
ciB1c2luZw0KICAgIHRoZSBib2lsZXJwbGF0ZSBmcm9tIFJGQyA4MTc0Lg0KDQpUaGlzIHNvdW5k
cyBmYW1pbGlhciA7XikuIEknbGwgdXBkYXRlIHRoZSBzZWN0aW9uIGFuZCBhZGQgUkZDIDgxNzQg
YXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KICAgIA0KICAg
IA0KICAgIA0KDQo=


From nobody Tue Jan 23 19:54: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 ED23312D880; Tue, 23 Jan 2018 19:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 jDN7LP_1SnZ8; Tue, 23 Jan 2018 19:54:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3268F12D775; Tue, 23 Jan 2018 19:54:26 -0800 (PST)
Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0O3sL0r005951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jan 2018 21:54:21 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105]
From: Ben Campbell 
Message-Id: <85A95636-19B0-493F-A20F-9D3A1CDF276E@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C52C9419-D283-45CE-B001-237EF5E34253"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 23 Jan 2018 21:54:20 -0600
In-Reply-To: 
Cc: The IESG , "draft-ietf-netmod-rfc8022bis@ietf.org" , Joel Jaeggli , "netmod-chairs@ietf.org" , "netmod@ietf.org" 
To: "Acee Lindem (acee)" 
References: <151676258855.24213.12138954771524998033.idtracker@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 03:54:28 -0000

--Apple-Mail=_C52C9419-D283-45CE-B001-237EF5E34253
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jan 23, 2018, at 9:21 PM, Acee Lindem (acee)  =
wrote:
>=20
> Hi Ben,
>=20
> =EF=BB=BFOn 1/23/18, 9:56 PM, "Ben Campbell"  wrote:
>=20

[=E2=80=A6]

>=20
>=20
>    =
----------------------------------------------------------------------
>    COMMENT:
>    =
----------------------------------------------------------------------
>=20
>    There are a few instances of 2119 keywords in lower case. Please =
consider using
>    the boilerplate from RFC 8174.
>=20
> This sounds familiar ;^).

Yep. I=E2=80=99m a broken record this week :-)

> I'll update the section and add RFC 8174 as a normative reference.

Thanks!

Ben.


--Apple-Mail=_C52C9419-D283-45CE-B001-237EF5E34253
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

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpoA2wACgkQgFZKbJXz
1A0h8w/9HW5q96Tp4INxcjZppJE3pfYJP2jWhadnyBRq/jvPTbIkkLhsTO81wiI/
ne+KybZro/CNcE+Xk7PmjKJIWDJqHUiMqjukJJnmfZ73hWrUPvR3wq4PEy0ltmy0
LaKFDhJqOX5xHn+j9MQ3SxYDZf4Z36gbGqDorgVq5l1ZhGcrNlroBFDCali02kbR
ZBK/gvgM9hOYKzU3j/XbLwBYf/ztAOWcZRsRlFOXeooPyWZkxQ/c7lA9GDd08Ldf
tKOFJhjBdA6XduPl6pVn1vRMd5+KWH7j2R5ooIPFe6c5wC8NeI84GxLoGcj0jhhz
VgpgT9QIXQKMFM7sV+ipbYCvzRfzmG44TXphJkNDJOdldnX8IFMwzRmodRYrcLZS
SGWzZzYqdrVyCJ509+hivFFQG3mr4lJFSWsqhIZ8D/4ZjP1/DYXzSz0Ue0YrUOIe
T26p3oTxVjyEY58T6wiWhPxZ4uszzNKxGwkQhvEEkf+lX6m7AzUhe87mKWqgBGkf
BtBky9fDMhf6iUb9gPlrocCDMVdgeXFSPgamBnTPbt49iiF6mHZxrv6Dx4t0PUB5
eqdN36Er47Y2iMNHhrzf/lq+ZNs2684kqTQ7eC4Eq93dhMJ+5EbpToNNtmagObZg
xJ9svMTY1a7h6LleX0bt8FPQfypM/Lw9pz38YYAbu8uCNz8Q7ww=
=hgme
-----END PGP SIGNATURE-----

--Apple-Mail=_C52C9419-D283-45CE-B001-237EF5E34253--


From nobody Tue Jan 23 21:20:32 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 5CE3512D960; Tue, 23 Jan 2018 21:20:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Jaeggli 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, iesg-secretary@ietf.org, joelja@gmail.com, Joel Jaeggli , netmod@ietf.org
Message-ID: <151677123037.24092.2570810268048407225.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 21:20:30 -0800
Archived-At: 
Subject: [netmod] Publication has been requested for draft-ietf-netmod-yang-tree-diagrams-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 05:20:31 -0000

Joel Jaeggli has requested publication of draft-ietf-netmod-yang-tree-diagrams-05 as Best Current Practice on behalf of the NETMOD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/


From nobody Wed Jan 24 04:00:42 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 338011200FC for ; Wed, 24 Jan 2018 04:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 r_1eoc60J0MH for ; Wed, 24 Jan 2018 04:00:36 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92C1200C5 for ; Wed, 24 Jan 2018 04:00:36 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 91B081820412; Wed, 24 Jan 2018 13:00:10 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id F062F18203F6; Wed, 24 Jan 2018 13:00:05 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Kent Watsen 
Cc: "netmod\@ietf.org" 
In-Reply-To: <20180123202610.vhclqrsfshevtbj3@elstar.local>
References:  <20180123202610.vhclqrsfshevtbj3@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder , Kent Watsen , "netmod\@ietf.org" 
Date: Wed, 24 Jan 2018 13:00:29 +0100
Message-ID: <87k1w7zcte.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 12:00:40 -0000

Juergen Schoenwaelder  writes:

> On Mon, Jan 22, 2018 at 08:05:54PM +0000, Kent Watsen wrote:
>> 
>> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>> 
>> Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationship with NMDA and rfc7895bis and an alternate representation of inline schema.  These have been considered respecting their impact on the last call consensus and it is the position of the chairs that it is best to advance the existing schema-mount document at this time.
>>
>
> If we take the formal road, then you may want to read again Robert
> Wilton's email posted on November 2nd (Thu, 2 Nov 2017 17:06:34 +0000)
> again. He does talk about YANG library alignment - so YANG library
> alignment is not just post LC comments. (I personally prefer to have
> technical discussion than formal discussions but if it is necessary to
> g there...)

As a matter of fact, I proposed pretty much the same thing already back in
March 2017:

https://www.ietf.org/mail-archive/web/netmod/current/msg18045.html

Lada

>
> /js
>
> -- 
> 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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 24 04:37: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 55734120726 for ; Wed, 24 Jan 2018 04:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level: 
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 KIYSyB6a-qjJ for ; Wed, 24 Jan 2018 04:37:36 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BDD54120227 for ; Wed, 24 Jan 2018 04:37:36 -0800 (PST)
Received: from dap.chopps.org (24-247-65-170.dhcp.trcy.mi.charter.com [24.247.65.170]) (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 20A9262A03; Wed, 24 Jan 2018 12:37:36 +0000 (UTC)
References: 
User-agent: mu4e 1.0-alpha2; emacs 25.3.1
From: Christian Hopps 
To: Kent Watsen 
Cc: "netmod\@ietf.org" 
In-reply-to: 
Date: Wed, 24 Jan 2018 07:37:35 -0500
Message-ID: <87vafrl9f4.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 12:37:38 -0000

Great news.

Thanks,
Chris.

Kent Watsen  writes:

> Thank you all for the important discussion since the completion 
> of WGLC on Nov 6th.
>
> Per normal process, drafts typically progress once LC comments 
> are address unless significant faults are found.  Post LC 
> comments have been made, which needed consideration, notably the 
> relationship with NMDA and rfc7895bis and an alternate 
> representation of inline schema.  These have been considered 
> respecting their impact on the last call consensus and it is the 
> position of the chairs that it is best to advance the existing 
> schema-mount document at this time.
>
> Given that there are significant concerns for how the solution 
> proposed in this draft operates with NMDA, we do think it 
> reasonable to add an applicability statement to the draft that 
> covers its operation in NMDA implementations. We do not believe 
> that such a statement substantively alters the draft nor would 
> it impact drafts that normatively reference the current draft.
>
> In addition to resolving the remaining open thread [1], we also 
> agree with the recently made comment that the schema mount draft 
> should allow the use of rfc7895bis (i.e., not reference 
> /modules-state), thereby enabling the draft's use (though not 
> ideal) on servers supporting rfc7895bis.
>
> The chairs will propose specific text for the updates mentioned 
> in this message to be reviewed by the WG for correctness before 
> final submission and advancement.
>
> [1] 
> https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>
> Thanks,
> Kent, Lou, and Joel
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Jan 24 05:07:54 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 BFD3112421A for ; Wed, 24 Jan 2018 05:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ShTeL33avLgr for ; Wed, 24 Jan 2018 05:07:50 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 380F512420B for ; Wed, 24 Jan 2018 05:07:50 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 87FA71820412; Wed, 24 Jan 2018 14:07:24 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1749418203F6; Wed, 24 Jan 2018 14:07:19 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , "netmod\@ietf.org" 
In-Reply-To: 
References: 
Mail-Followup-To: Kent Watsen , "netmod\@ietf.org" 
Date: Wed, 24 Jan 2018 14:07:43 +0100
Message-ID: <878tcnz9pc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 13:07:53 -0000

Hi,

Kent Watsen  writes:

> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>
> Per normal process, drafts typically progress once LC comments are
> address unless significant faults are found.  Post LC comments have
> been made, which needed consideration, notably the relationship with
> NMDA and rfc7895bis and an alternate representation of inline schema.
> These have been considered respecting their impact on the last call
> consensus and it is the position of the chairs that it is best to
> advance the existing schema-mount document at this time.

I guess I have no chance but strongly object to this. Is it normal to
proceed this way without reaching WG consensus and against the will of
*both* document authors?

>
> Given that there are significant concerns for how the solution
> proposed in this draft operates with NMDA, we do think it reasonable
> to add an applicability statement to the draft that covers its
> operation in NMDA implementations. We do not believe that such a
> statement substantively alters the draft nor would it impact drafts
> that normatively reference the current draft.
>
> In addition to resolving the remaining open thread [1],

Hmm, who resolved this thread? Lou proposed some text and nobody
expressed any agreement with it. In fact, I believe it is nothing more
than hand-waving.

I must say that the work on this draft was very frustrating for me. Even
more than on RFC 8022, and this tells you something.

Lada

> we also agree
> with the recently made comment that the schema mount draft should
> allow the use of rfc7895bis (i.e., not reference /modules-state),
> thereby enabling the draft's use (though not ideal) on servers
> supporting rfc7895bis.
>
> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement. 
>
> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>
> Thanks,
> Kent, Lou, and Joel
>
>
>
> _______________________________________________
> 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 Wed Jan 24 06:36: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 B3FE1124B18 for ; Wed, 24 Jan 2018 06:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 0YQVCChQZePo for ; Wed, 24 Jan 2018 06:35:57 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 92CDE12422F for ; Wed, 24 Jan 2018 06:35:57 -0800 (PST)
Received: from MBP.local ([64.191.222.125]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w0OEZsqF028620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 24 Jan 2018 14:35:55 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [64.191.222.125] claimed to be MBP.local
To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz>
From: joel jaeggli 
Message-ID: <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
Date: Wed, 24 Jan 2018 09:35:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <878tcnz9pc.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 14:36:00 -0000

On 1/24/18 8:07 AM, Ladislav Lhotka wrote:
> Hi,
>
> Kent Watsen  writes:
>
>> Thank you all for the important discussion since the completion of WGL=
C on Nov 6th.
>>
>> Per normal process, drafts typically progress once LC comments are
>> address unless significant faults are found.  Post LC comments have
>> been made, which needed consideration, notably the relationship with
>> NMDA and rfc7895bis and an alternate representation of inline schema.
>> These have been considered respecting their impact on the last call
>> consensus and it is the position of the chairs that it is best to
>> advance the existing schema-mount document at this time.
> I guess I have no chance but strongly object to this. Is it normal to
> proceed this way without reaching WG consensus and against the will of
> *both* document authors?
Once the document is adopted by the working group it's the working
group's document.

The consensus call was made back here:

https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

To my mind the discussion that we picked up in the new year highlights
the limitations of the existing draft without it being fatally flawed.
To wit (and this is my opinion), this one is stable and should proceed,
clearing the path for drafts with normative dependencies; we should
proceed with an update in a timely fashion.

IETF Last call serves a useful function in that is exposes the problem
discussed here beyond the working group, particularly to those who
depend on schema mount today. I think we understand in making this
judgement call where the working group participants stand today.

>> Given that there are significant concerns for how the solution
>> proposed in this draft operates with NMDA, we do think it reasonable
>> to add an applicability statement to the draft that covers its
>> operation in NMDA implementations. We do not believe that such a
>> statement substantively alters the draft nor would it impact drafts
>> that normatively reference the current draft.
>>
>> In addition to resolving the remaining open thread [1],
> Hmm, who resolved this thread? Lou proposed some text and nobody
> expressed any agreement with it. In fact, I believe it is nothing more
> than hand-waving.
>
> I must say that the work on this draft was very frustrating for me. Eve=
n
> more than on RFC 8022, and this tells you something.
>
> Lada
>
>> we also agree
>> with the recently made comment that the schema mount draft should
>> allow the use of rfc7895bis (i.e., not reference /modules-state),
>> thereby enabling the draft's use (though not ideal) on servers
>> supporting rfc7895bis.
>>
>> The chairs will propose specific text for the updates mentioned in thi=
s message to be reviewed by the WG for correctness before final submissio=
n and advancement.=20
>>
>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html=

>>
>> Thanks,
>> Kent, Lou, and Joel
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod



From nobody Wed Jan 24 06:55: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 BF201126579 for ; Wed, 24 Jan 2018 06:55:33 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 cESsV3b-TcQz for ; Wed, 24 Jan 2018 06:55:31 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B231B1250B8 for ; Wed, 24 Jan 2018 06:55:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 82355F89; Wed, 24 Jan 2018 15:55:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id T-KmSIiXPxZW; Wed, 24 Jan 2018 15:55:30 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Jan 2018 15:55:30 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68C5520149; Wed, 24 Jan 2018 15:55:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BAjtXXUtll99; Wed, 24 Jan 2018 15:55:30 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0480620147; Wed, 24 Jan 2018 15:55:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 4F805422811D; Wed, 24 Jan 2018 15:55:28 +0100 (CET)
Date: Wed, 24 Jan 2018 15:55:28 +0100
From: Juergen Schoenwaelder 
To: joel jaeggli 
Cc: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
Message-ID: <20180124145528.e6igaz7et7xm4u27@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: joel jaeggli , Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz> <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 14:55:34 -0000

On Wed, Jan 24, 2018 at 09:35:49AM -0500, joel jaeggli wrote:
> 
> Once the document is adopted by the working group it's the working
> group's document.
> 
> The consensus call was made back here:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

So then go ahead and resolve _all_ comments that were made during
WG last call.
 
> To my mind the discussion that we picked up in the new year highlights
> the limitations of the existing draft without it being fatally flawed.
> To wit (and this is my opinion), this one is stable and should proceed,
> clearing the path for drafts with normative dependencies; we should
> proceed with an update in a timely fashion.

I believe the YANG library alignment issue was raised earlier than
'new year' and actually during WG last call. Since the YANG library
interim (NETCONF WG) in December we have a clearer view on YANG
library. Anyway, I expect that all WG last call comments will be dealt
with - otherwise there is a process error.

/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 Jan 24 07:18: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 03126126BF6 for ; Wed, 24 Jan 2018 07:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.03
X-Spam-Level: 
X-Spam-Status: No, score=-7.03 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] 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 6quqXTTuH8bL for ; Wed, 24 Jan 2018 07:18:16 -0800 (PST)
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 D1CC1120727 for ; Wed, 24 Jan 2018 07:18:15 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 41CDB65318; Wed, 24 Jan 2018 16:18:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516807093; bh=QrI+JnGCYcglZjCUx9hQKarmK0rq5Z1YiQIXWpWdq3o=; h=From:To:Date; b=HQc+aN2EoES2LLv/7UqF+IXw2918esON45xVwBmqQWkWz0vqnu4P37vU2hwv7Bl8+ pooiG5sYo/Q9KJW3X0d4FvVD3KZ/MzZKLVuqWevwq+5tzGsAaKKt2ELimqGgkscJZ/ MvTd1xQrNjnghGw/iN4zlPfV2YQebYSHg+aveFes=
Message-ID: <1516807093.8341.74.camel@nic.cz>
From: Ladislav Lhotka 
To: joel jaeggli , Kent Watsen ,  "netmod@ietf.org" 
Date: Wed, 24 Jan 2018 16:18:13 +0100
In-Reply-To: <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
References:  <878tcnz9pc.fsf@nic.cz> <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 15:18:19 -0000

On Wed, 2018-01-24 at 09:35 -0500, joel jaeggli wrote:
> 
> On 1/24/18 8:07 AM, Ladislav Lhotka wrote:
> > Hi,
> > 
> > Kent Watsen  writes:
> > 
> > > Thank you all for the important discussion since the completion of WGLC on
> > > Nov 6th.
> > > 
> > > Per normal process, drafts typically progress once LC comments are
> > > address unless significant faults are found.  Post LC comments have
> > > been made, which needed consideration, notably the relationship with
> > > NMDA and rfc7895bis and an alternate representation of inline schema.
> > > These have been considered respecting their impact on the last call
> > > consensus and it is the position of the chairs that it is best to
> > > advance the existing schema-mount document at this time.
> > 
> > I guess I have no chance but strongly object to this. Is it normal to
> > proceed this way without reaching WG consensus and against the will of
> > *both* document authors?
> 
> Once the document is adopted by the working group it's the working
> group's document.
> 
> The consensus call was made back here:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

Ongoing threads are mentioned here, and they have to be resolved.

> 
> To my mind the discussion that we picked up in the new year highlights
> the limitations of the existing draft without it being fatally flawed.

What would be fatally flawed are two different versions of schema mount.

> To wit (and this is my opinion), this one is stable and should proceed,
> clearing the path for drafts with normative dependencies; we should
> proceed with an update in a timely fashion.
> 
> IETF Last call serves a useful function in that is exposes the problem
> discussed here beyond the working group, particularly to those who
> depend on schema mount today. I think we understand in making this
> judgement call where the working group participants stand today.

An author objecting against his own document in the IETF LC - this sounds pretty
crazy. If possible, I'd prefer to find consensus within the WG.

Lada

> 
> > > Given that there are significant concerns for how the solution
> > > proposed in this draft operates with NMDA, we do think it reasonable
> > > to add an applicability statement to the draft that covers its
> > > operation in NMDA implementations. We do not believe that such a
> > > statement substantively alters the draft nor would it impact drafts
> > > that normatively reference the current draft.
> > > 
> > > In addition to resolving the remaining open thread [1],
> > 
> > Hmm, who resolved this thread? Lou proposed some text and nobody
> > expressed any agreement with it. In fact, I believe it is nothing more
> > than hand-waving.
> > 
> > I must say that the work on this draft was very frustrating for me. Even
> > more than on RFC 8022, and this tells you something.
> > 
> > Lada
> > 
> > > we also agree
> > > with the recently made comment that the schema mount draft should
> > > allow the use of rfc7895bis (i.e., not reference /modules-state),
> > > thereby enabling the draft's use (though not ideal) on servers
> > > supporting rfc7895bis.
> > > 
> > > The chairs will propose specific text for the updates mentioned in this
> > > message to be reviewed by the WG for correctness before final submission
> > > and advancement. 
> > > 
> > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
> > > 
> > > Thanks,
> > > Kent, Lou, and Joel
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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 Wed Jan 24 07:40: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 59E9912DA44 for ; Wed, 24 Jan 2018 07:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 A7OF4uDJYtxn for ; Wed, 24 Jan 2018 07:40:46 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16081126C3D for ; Wed, 24 Jan 2018 07:40:46 -0800 (PST)
Received: from [::1] (port=41698 helo=fs2.dc.labn.net) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1eeNAJ-00019Q-L6; Wed, 24 Jan 2018 18:40:43 +0300
To: joel jaeggli , Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz> <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
From: Lou Berger 
Reply-To: lberger@labn.net
Message-ID: <5ebf6026-fb59-8bd2-8f72-3b5be9667de7@labn.net>
Date: Wed, 24 Jan 2018 10:40:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 15:40:48 -0000

One additional point below.

n 01/24/2018 09:35 AM, joel jaeggli wrote:
> 
> 
> On 1/24/18 8:07 AM, Ladislav Lhotka wrote:
>> Hi,
>>
>> Kent Watsen  writes:
>>
>>> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>>>
>>> Per normal process, drafts typically progress once LC comments are
>>> address unless significant faults are found.  Post LC comments have
>>> been made, which needed consideration, notably the relationship with
>>> NMDA and rfc7895bis and an alternate representation of inline schema.
>>> These have been considered respecting their impact on the last call
>>> consensus and it is the position of the chairs that it is best to
>>> advance the existing schema-mount document at this time.
>> I guess I have no chance but strongly object to this. Is it normal to
>> proceed this way without reaching WG consensus and against the will of
>> *both* document authors?
> Once the document is adopted by the working group it's the working
> group's document.
> 

A document moving away from the original authors intent or even
agreement has happened before in the IETF.  I'm aware of several cases
of it *right now*, one in this group the others in different areas.  In
the case of this group, the original (lead) author choose to remove
themselves from the work and others in the WG took over the pen.  In the
other WGs, the original authors dropped the work and new authors took it
over.  In the case of the work that I initiated that this happened with,
I'm not sure if I'm listed or not as it's been so long since I looked at
the draft, but I know I'm no longer on the front page and the WG chair
appointed editor is a non-original author who I recommended.  So your
current position is not unique, nor counter to our process.

As a reminder, it is the responsibility of the document editors to
document WG consensus -- they have a lot of latitude in how they do
this, but in the end, WG consensus is what should be captured once an a
topic is discussed. It is also the WG chairs responsibility to ensure
that a document reflects WG consensus, this includes ensuring that the
document editors/authors follow consensus and appointing editors when
the authors need assistance in this.  An editor can be appointed if you
and Martin think this is necessary, but I think the preference of the
chairs is that we don't at this late date.

Lou


> The consensus call was made back here:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html
> 
> To my mind the discussion that we picked up in the new year highlights
> the limitations of the existing draft without it being fatally flawed.
> To wit (and this is my opinion), this one is stable and should proceed,
> clearing the path for drafts with normative dependencies; we should
> proceed with an update in a timely fashion.
> 
> IETF Last call serves a useful function in that is exposes the problem
> discussed here beyond the working group, particularly to those who
> depend on schema mount today. I think we understand in making this
> judgement call where the working group participants stand today.
> 
>>> Given that there are significant concerns for how the solution
>>> proposed in this draft operates with NMDA, we do think it reasonable
>>> to add an applicability statement to the draft that covers its
>>> operation in NMDA implementations. We do not believe that such a
>>> statement substantively alters the draft nor would it impact drafts
>>> that normatively reference the current draft.
>>>
>>> In addition to resolving the remaining open thread [1],
>> Hmm, who resolved this thread? Lou proposed some text and nobody
>> expressed any agreement with it. In fact, I believe it is nothing more
>> than hand-waving.
>>
>> I must say that the work on this draft was very frustrating for me. Even
>> more than on RFC 8022, and this tells you something.
>>
>> Lada
>>
>>> we also agree
>>> with the recently made comment that the schema mount draft should
>>> allow the use of rfc7895bis (i.e., not reference /modules-state),
>>> thereby enabling the draft's use (though not ideal) on servers
>>> supporting rfc7895bis.
>>>
>>> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement. 
>>>
>>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>>>
>>> Thanks,
>>> Kent, Lou, and Joel
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Wed Jan 24 07:42:38 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 200F0126CD6 for ; Wed, 24 Jan 2018 07:42:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 DT-0I0kFoZPG for ; Wed, 24 Jan 2018 07:42:32 -0800 (PST)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 A6138126C3D for ; Wed, 24 Jan 2018 07:42:30 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id DDFE54186E for ; Wed, 24 Jan 2018 08:20:12 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 2FL81x01P2SSUrH01FLB6G; Wed, 24 Jan 2018 08:20:12 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=Scm6ppW0Vsq7PnY0iGgA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lKtFt5O3z5UtzHhGjKdliqymD6yA7cCsCmutmHFtP68=; b=uXLaKM3Jwh40b+7rPb3EIHih+S TDpTCZuIZg2H73nO2JLAdTdx1IaG8LkQDVWr6TBP1TL43akCtymFvlVygX8GIX+ByVbYP82R2ByNx ILAlSaco1mOCUHeOrIDJ+WxE5;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60938 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eeMqO-000ybh-Nu; Wed, 24 Jan 2018 08:20:08 -0700
To: Kent Watsen , "netmod@ietf.org" 
References:  <20180123202610.vhclqrsfshevtbj3@elstar.local>
From: Lou Berger 
Message-ID: <87b0d5ed-52d9-7bb2-e83b-89241baa35bc@labn.net>
Date: Wed, 24 Jan 2018 10:20:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180123202610.vhclqrsfshevtbj3@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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-Exim-ID: 1eeMqO-000ybh-Nu
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:60938
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 15:42:36 -0000

On 01/23/2018 03:26 PM, Juergen Schoenwaelder wrote:
> On Mon, Jan 22, 2018 at 08:05:54PM +0000, Kent Watsen wrote:
>>
>> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>>
>> Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationship with NMDA and rfc7895bis and an alternate representation of inline schema.  These have been considered respecting their impact on the last call consensus and it is the position of the chairs that it is best to advance the existing schema-mount document at this time.
>>
> 
> If we take the formal road, then you may want to read again Robert
> Wilton's email posted on November 2nd (Thu, 2 Nov 2017 17:06:34 +0000)
> again. He does talk about YANG library alignment - so YANG library
> alignment is not just post LC comments. (I personally prefer to have
> technical discussion than formal discussions but if it is necessary to
> g there...)

Focusing a moment on the future and the technical, it would be most
helpful to have a document that describes SM with NMDA and YL-bis.  This
would at least be a starting point for WG discussion.  It might even
help show if the current plan is flawed.

I, personally, suspect that a proposal that changes basic approach, or
revisits past arguments, will end up in another round of very long
discussions based on what each party thinks is optimal. Therefore, I
hope that the initial proposed solution would take a minimalistic change
approach in order to garner widest support.  This consensus foundation
could then provide a foundation for further optimization to the degree
supported by WG consensus.

Lou


> 
> /js
> 


From nobody Wed Jan 24 07:43:37 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 C8BF6126C3D; Wed, 24 Jan 2018 07:43:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan 
To: "The IESG" 
Cc: draft-ietf-netmod-rfc8022bis@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@bogus.com, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151680861581.25648.8503007790939454483.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 07:43:35 -0800
Archived-At: 
Subject: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 15:43:36 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc8022bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Lots of places in the document where NMDA is misspelled as NDMA. Please fix.

* Section 9.1.

The ranges for AdvDefaultLifetime and MaxRtrAdvInterval have been changed by
RFC-to-be-8319 to update the values specified in RFC4861.  Please change these
ranges to the new values.

OLD:

leaf max-rtr-adv-interval {
           type uint16 {
             range "4..1800";
           }

NEW:

leaf max-rtr-adv-interval {
           type uint16 {
             range "4..65535";
           }

OLD:

         leaf default-lifetime {
           type uint16 {
             range "0..9000";
           }

NEW:
         leaf default-lifetime {
           type uint16 {
             range "0..65535";
           }



From nobody Wed Jan 24 07:46:10 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 2D32B126C26; Wed, 24 Jan 2018 07:46:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, bclaise@cisco.com, Joel Jaeggli , draft-ietf-netmod-yang-tree-diagrams@ietf.org
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151680876317.25728.5445241397306700358.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 07:46:03 -0800
Archived-At: 
Subject: [netmod] Last Call:  (YANG Tree Diagrams) to Best Current Practice
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 15:46:03 -0000

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Tree Diagrams'
   as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document captures the current syntax used in YANG module Tree
   Diagrams.  The purpose of the document is to provide a single
   location for this definition.  This syntax may be updated from time
   to time based on the evolution of the YANG language.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Wed Jan 24 09:01: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 1C1BF12708C for ; Wed, 24 Jan 2018 09:01:16 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 HsfklPiGK0rf for ; Wed, 24 Jan 2018 09:01:12 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1236F127076 for ; Wed, 24 Jan 2018 09:01:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KL4MSnRjByvvXDyOyRw4WhqSI+LGI++O7k8saINIDdg=; b=HX4AizW3m8gEyFp/BoCCxA3i1RdCdqLZt5YaewvSRyPKeQFuqw1w2GTZqQbrQnygIw3Gu+rFrBVvWnI5VJMAQI4vF7ZEuTcOhP60pws4aUl+6sL6d1X38tiax/ZWa/lGzFT4Yzvi8690Nw+OY9q9VTX9UQtoFfM0H6Ps9ZS4Yr4=
Received: from pc6 (86.169.153.236) by AM5PR0701MB2994.eurprd07.prod.outlook.com (2603:10a6:203:48::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Wed, 24 Jan 2018 17:01:09 +0000
Message-ID: <045f01d39534$c02ba480$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , 
References: <151579789446.21777.985631371557420470@ietfa.amsl.com> 
Date: Wed, 24 Jan 2018 16:46:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6P190CA0005.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::18) To AM5PR0701MB2994.eurprd07.prod.outlook.com (2603:10a6:203:48::16)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 69540d51-2d7d-4c19-ad0d-08d5634c10ed
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:AM5PR0701MB2994; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 3:ztHpWYYQyvthqK8vhMyrgiWm1bKGKshuYO75A5lSjJAgLBWtdIUwy6jBhn2mUGXHd9n5baDfpw1rM0UpzW3nnsHFRiUbIxr5G44M0Q248YP2zshlyG4NtDIZ0w/y0ZHckf6n6S5eTedDUpYHyWIbmEb8bzFpzzDmefPTSMnsWz0BsK6TOdSbRzE2c2L3kjOMMOE4jwYGkPlh9Q8F2UB8OJabS0yXFIeEu5TcK9JU/FJmB2ZH/ft33agb3fh/2bRq; 25:NjWRjaC4pW/MvASWJKXmDzOOAmjZ4CAU5WT1WxxA2lBaR1K4KvAUKjfQMTFb8UzwlzZLxgTBFCOqxHs7KZADTt3iOccAiifxj9rWRms8CwZ01ZDDN+iostWKVyCix0yMOkji8SipxFfl+aNyJbgK653H4nDfHnsftun8Y9GzXzuaxsqksDGo1Yl8gosqDZvsai/1i99af+vYGKcNInSZjK6yUouwz5Igb3xB3mmal1++19IqLazzuYHEDrSXfxEHtkYFTnDT6pUw5KxcvqYQNLzIH156dd6fXH26kV+DbDdqDvho89E9pJoX/AKddlgRBfYDGvRZVsIKjU/tILFG2g==; 31:fspUisgdt13VKq/NUVzoS1R59INv3kaj3doh79bU7ajsLrjKZ9XApxrPji2UVWgqpEoJTrFYGx8vSGYR1nr5p+WZUm1+bMb+FBE9TBQs5/gdhxVHVKIiMa+GBoIkkqqb53GJFVvbmIviO5B7oVDR9u7wEPmkrlTfIN2fjx2RfjDLthLGq0keXvMDzsK8AZ3bnVjHIVzZ8BiQ0v6FLjVy4Aqhbm/M4kZn5ATygYlD/Pg=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2994:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(209352067349851)(192374486261705)(138986009662008); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231046)(2400081)(944501161)(93006095)(93001095)(3002001)(20161123222025)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:AM5PR0701MB2994; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2994; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 4:WUIUqZEZ07DlP1yDPGjmXFqpqIGU7wVxVAva237DNhwxmqXx0LVKI9vwBvI1islNlV5Nygs+ELFbuzVtaXTJEa9sSFgICp5CjAg9N5TC/FsmzvYAriSRQG4gWBztKr2i74gb/SQBGQ5XGPLrNNHRWzFeA/PqOJe8z40pCNmKUga4OKojYKGr5q3PI55RttErWQ4/n/cPKQhIxH3eFV6x2w7fgNYQFsQ+V2YublIDflDUkcLYdQYZzBC86xFrjQD7tJmvOYu2b2PynM7OqxhoyMSaRUJuQB8LwWdRglb8LFLSxaDH1Z4GKajGe8j4zHIOOLPLRd6jTNZZ8k3fhTFx13HdfTa+eo4PVELmupIcexzZFUXqQGjm0cScVx90W2+W
X-Forefront-PRVS: 056297E276
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39380400002)(39860400002)(346002)(366004)(189003)(199004)(13464003)(44736005)(6306002)(76176011)(110136005)(386003)(8666007)(305945005)(14496001)(81156014)(81166006)(8936002)(230783001)(44716002)(4720700003)(25786009)(9686003)(47776003)(50226002)(52116002)(62236002)(50466002)(59450400001)(106356001)(81686011)(81816011)(316002)(7736002)(6496006)(33896004)(6666003)(66066001)(8676002)(966005)(53936002)(6246003)(1556002)(478600001)(1941001)(1456003)(230700001)(23756003)(5660300001)(105586002)(3846002)(2906002)(16526018)(26005)(84392002)(86362001)(6116002)(68736007)(229853002)(97736004)(61296003)(6486002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2994; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2994; 23:6yE4lbeb7He1BX5mgr4UorwBIKZvMDsCfmcrT?= =?iso-8859-1?Q?qaiR+iRIlq4Wo//hJcN+NX8n3NkVyb23d4tLLqSYxbmNrFUMjIb5BmFSmD?= =?iso-8859-1?Q?XqMr6DQe24uYnYmO/RRVAAnnYYDtwC3qFyF6yCdILF6N1nFHhW+GSYULo6?= =?iso-8859-1?Q?c4CUWC4ZtZqP+TFMKgwC9lKVJpgl51ppJWxxoxNoaA0vw7Pr+CIlqOewQr?= =?iso-8859-1?Q?TNm3LYESkanO8nfCHmHWfqXy6x+nmRwmUhUuhWfbRqP+j8pXcPAsRlMojM?= =?iso-8859-1?Q?ibSN7VGTGq0itlzVBZ8w+tNoNjMKeZ4pgqptZGh7cmIPe7YD3OinDFphJp?= =?iso-8859-1?Q?iarE8LqkRHmwmCudFIBGA22DVnBI6H6tGzsy0K6yNKIUvyR0pk0DkblL5w?= =?iso-8859-1?Q?jf3qADOdL2lq2oKgd31qq5GhgD4Rs4F57ZUhS+oWAkIRAjUO616MUdbizy?= =?iso-8859-1?Q?sFSnuyT7GVNNS5RwXJbbuXlkySZ1Ozej+BbV9leV1Ld7PPyvgvd63n/67p?= =?iso-8859-1?Q?DgCIjz4gvBPz2uDUgI7kmJW0Zs/KHfLLMWgAu16AQqc3Y0vXOJ3u9kBJJM?= =?iso-8859-1?Q?Va3i9N7LTjh4UP8RjGXrFyvTSSp++qdWzExshRDCFQbT0TwjbZ84bTgpE3?= =?iso-8859-1?Q?qla+BbnmvskHWI0vUHT6XYNpt7HxrvfIHt4GIagoT5BA1t8ujnuNPzbZTM?= =?iso-8859-1?Q?sl63kfV4/AECqWUP/qAIJg5suiBpEygg8cw0PN9ixOb23OsxQB+Y1WsbVs?= =?iso-8859-1?Q?XT0E9yut7twmhV/Co4Qt4l8jbBQroUhM4vqA8MH85hlyj6EPpUt3mNMh+j?= =?iso-8859-1?Q?HkMBwLcxEFdfxARzk3uPl9UpZ27wrvYdRIKeFiF+ZlefNVCADnn5TJyRS+?= =?iso-8859-1?Q?smz0Y20WBhs4usQ/VUfoJwJPSa1Vg5hPzd3lirO00DkJXjeiNrFiDbUPU0?= =?iso-8859-1?Q?JJgX2QoRabtoQF8l91RSvGNRW6sSF2B9QIoMMG9ipoFM4ZwjxgduGKRSJT?= =?iso-8859-1?Q?3hub6hqKNdK+H4TykgQnYGGkTvBhJ3QlNcsMcRv4bt+zbPmr1o2fFVEo3L?= =?iso-8859-1?Q?4nLgcMAXOjB9yiWVfKD7Y6J3ysbz7FARp6rA/BEHvd8XYdewMuQ4izHbH0?= =?iso-8859-1?Q?W44DKU36UIy5/GiPyhMSCKxAkUGbJryFiScXevsOawlYis8wlXscc2VF6U?= =?iso-8859-1?Q?dCy5hRz1+XfnDkDlxxjzUlUO/+HtfpMnm6k+VvSEkMDvL4AkWDLtnEkwDa?= =?iso-8859-1?Q?48oxNjUiQOrs6h6eLeuLRYYFolhrG2H3cLQAIp5XlL7RR2tLOqDpKrFmkj?= =?iso-8859-1?Q?e8NMVkxP8kIBTbhdd7SUNwut/vPHTBGNRTHbFTlkBEGFbITIZnhTRnxk+L?= =?iso-8859-1?Q?dUt08x7w5qJNsKiwqLSya0ZGSdWDor5sKVprMy6NPtSnefo9c4/kni0lV2?= =?iso-8859-1?Q?cPG5PYxMgQGDT0DBEr7UBlnuSL1Nm/lUdWbUIeNjalxOb8CiSlPdmsLtFQ?= =?iso-8859-1?Q?O006a3ThV8Tb9+DXZNeH22Wi6X3y+r0ZsmDsfVCK779zBroLfSwOxyxV9p?= =?iso-8859-1?Q?GeKiEVQ=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 6:Jyxq1oskPoaeibrK2UvAmf04g1xfkmcka1EGxGbeB4nFo2RXpPxS1Fka454x4eoR6X5oCXYEwEm5591KhYXUUUojfkHP6UMsMi7k+5hodGbQb3XzWYHaGoBxnMTRNCrRA93YGqQqlJGy+HxxCGax3EpN7AA3CwYJRxrwkzHud8K8ODmaTWT2zGtIyrbWXbQetxYuq4WqDRz9Rww4QaNceOuqPomfr86GUvIRj4hfvbJVb/1lB0+w0MreLWaL08ptpLFe7fPfmjpRPwOA8WlzOpzj7DDFaAxSYFsKxjhGqazrEjTXAjc/kJ+I5JWeUq19HUeXh5awx3FPb+8rL2sBvugAF382oLAMlS3pJZXUr9I=; 5:/5OSOYqR0rY3q+eWdtRsSohM9p3Np0vhPXoFkQmZWeL+IW5I6Ehd4J2b2do95FeJSTbuX05OiyfykKF+FN2vX2poTUQWV1qfnTXrOdZY4aIgxTQSbTJPqNh8u5hfLzFR378WMTD4+y/GfR97ra0dPeinLXgycG+TxpnAh7MX+Fg=; 24:f9Fzg/VsTMDJDpcGP+2uoUgj9tV81FEpc9twYwr8wXD4rDDvUoTL/0DAqUR9X7NeAMY8SZrp5QLRE0WteuLiOAmplB5mX9DFLMMEpyogc5o=; 7:b8KUuGsBo5fV/Jp4/mGjkoy0Fif5OvyeOsL/G8hyy69IHg6f7e+GNOjm4AHirNB5Tqh0kDupq9gfTKdfLXXcN7i+u7jlVralbUTL0YHlBOWFk3A7NvWLYQW89tBJJTsY9MOqoWdwTMU2uWsKllIZKSV30FPi9JJrCbSSw/O8/dXdtyt8620BMh5l36kY7jI1mgG9OH77UGBZ9BEY6RM5c/rWrvaOBCA7aPQRAN7TJBq8lt/ECkm50YnXdbb55WiK
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2018 17:01:09.2188 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 69540d51-2d7d-4c19-ad0d-08d5634c10ed
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2994
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 17:01:16 -0000

Kent

My request for a reference for Posix hs been fixed in -19.

Tom Petch

----- Original Message -----
From: "Kent Watsen" 
To: 
Sent: Tuesday, January 16, 2018 4:59 PM

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: https://www.ietf.org/tools/idnits.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> ===== START =====
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   https://trustee.ietf.org/license-info):
>   --------------------------------------------------------------------
--------
>
>      No issues found here.
>
>   Checking nits according to
https://www.ietf.org/id-info/1id-guidelines.txt:
>   --------------------------------------------------------------------
--------
>
>      No issues found here.
>
>   Checking nits according to https://www.ietf.org/id-info/checklist :
>   --------------------------------------------------------------------
--------
>
>   ** There is 1 instance of too long lines in the document, the
longest one
>      being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   --------------------------------------------------------------------
--------
>
>   == Line 352 has weird spacing: '...gorithm    ide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>      it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>      a matching beginning. Boilerplate error?
>
>      (The document does seem to have the reference to RFC 2119 which
the
>      ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should ignore it.
>
>
>   -- The document date (January 12, 2018) is 4 days in the past.  Is
this
>      intentional?
>
> Kent: this is fine, it is intentional.
>
>
>   Checking references for intended status: Proposed Standard
>   --------------------------------------------------------------------
--------
>
>      (See RFCs 3967 and 4897 for information about using normative
references
>      to lower-maturity documents in RFCs)
>
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1386,
>      but no explicit reference was found in the text
>
> Kent: looking at the XML, I see that the entire paragraph uses '[' and
']' as opposed to .  Please fix this.
>
>
>   == Unused Reference: 'RFC7895' is defined on line 1456, but no
explicit
>      reference was found in the text
>
> Kent: looking at the XML, I see two instances of an unwanted "/>"
string.  For instance: />  Please fix this.
>
>
>   ** Downref: Normative reference to an Historic RFC: RFC 6587
>
> Kent: hmmm, what's going on here?  This YANG module is providing an
ability to configure the "tcp" transport, even though the IESG made that
ability historic in 2012 (see IESG Note below).  Searching online, it
looks like Cisco supports this, but Juniper does not.  What about other
vendors, is it widely supported?  Was this discussed in the WG?
Answering my own question, searching my local mailbox, I don't see this
ever being discussed before, other than Martin questioning if it was a
good idea in Mar 2016 (no response).  Please start a thread on the list
to get WG opinion if it's okay for the draft to proceed as is or not.
Here's the IESG Note from RFC 6587:
>
>    IESG Note
>
>    The IESG does not recommend implementing or deploying syslog over
>    plain tcp, which is described in this document, because it lacks
the
>    ability to enable strong security [RFC3365].
>
>    Implementation of the TLS transport [RFC5425] is recommended so
that
>    appropriate security features are available to operators who want
to
>    deploy secure syslog.  Similarly, those security features can be
>    turned off for those who do not want them.
>
>
>
>
>
>      Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment
(--).
>
>      Run idnits with the --verbose option for more detailed
information about
>      the items above.
> ===== END =====
>
> Thanks,
> Kent // shepherd
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Jan 24 09:29:52 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 62EBE1270AB; Wed, 24 Jan 2018 09:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=R0pbr66I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IEQ7Znn4
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 25t7kwVst7-G; Wed, 24 Jan 2018 09:29:43 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489871270B4; Wed, 24 Jan 2018 09:29:43 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A66E122412; Wed, 24 Jan 2018 12:29:42 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 24 Jan 2018 12:29:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=jHaHwTtzIbsacY+UHAbbMEA71WbCm VN52+QaQVN10Tc=; b=R0pbr66I4KNEEwFlRaJYwFGO+jHt/yuJGy3VxanMWpIx+ i49Co03evT4UY1NsGersoy8ZFP64WoZcHR5ZRf7HWBaUXse2hszxvZbw+VrYPqPi WJDkeJjVnnkUW1RuNwuPE47H+be8BBLR1MnQaWywaSilgPBZPpr02zaOp5bCV5GO 14GRg8rtAEA4XRm/VnHw/Gi3XXUa4DUiGW8wL6rniaGU6L6P6yYaF1GwJA1qMc4P wC+ir8+jAGzv6JIQqnZv0pwfXxQX0KmyDiqQTiwSMy5Mt+C3wUrhgpZebw0xiTbL Bh2J0Ig+LUUA8olBxl9ZHGeC952CC9IP5xNQNZepA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jHaHwT tzIbsacY+UHAbbMEA71WbCmVN52+QaQVN10Tc=; b=IEQ7Znn4eGX1VKO6yjMmXU DsPX6jQRH404rAmkm/S/R3Pa6vP/IlQafe3T9TwAW2WroLhPcm9oAQxAiebTRzKm tCQKF1vgpoNujEcOyaxbvi1D92g06QOLgtpzy7jazQjLa45taEQqr7Qv3I+lH0bT kn3Tr1D2pkKX2eYios2ykETe8eSRmMbKmwbP7ucGR25yi8UTn3xCCZFEGaU722rw oh4BaMgG2SOJUbcPpQLILs8VARuuzpnDNgYiY16O/PuKf+gXQHP9ECxRDuKMvYxp Tj6BAbquKAxvzrINFYBju1IOYbDQ4BVgXyulkSFB3AY9lToG8GIouflJxAxnkEvA ==
X-ME-Sender: 
Received: from [10.19.234.245] (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C03B247A9; Wed, 24 Jan 2018 12:29:41 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <151674813480.15558.2493616807577632397@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 12:29:39 -0500
Cc: gen-art , draft-ietf-netmod-rfc8022bis.all@ietf.org, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <689D947C-D77F-44B0-92CA-A12BD53CCB0E@cooperw.in>
References: <151674813480.15558.2493616807577632397@ietfa.amsl.com>
To: Francis Dupont 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] [Gen-art] Genart telechat review of draft-ietf-netmod-rfc8022bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 17:29:45 -0000

Francis, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Jan 23, 2018, at 5:55 PM, Francis Dupont =
 wrote:
>=20
> Reviewer: Francis Dupont
> Review result: Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-netmod-rfc8022bis-??
> Reviewer: Francis Dupont
> Review Date: 2018-01-23
> IETF LC End Date: 2018-01-15
> IESG Telechat date: 2018-01-25
>=20
> Summary: Ready
>=20
> Major issues: None
>=20
> Minor issues: None
>=20
> Nits/editorial comments: I'll send another message tomorrow with a few =
comments.
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Thu Jan 25 03:15: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 8756F12DA15 for ; Thu, 25 Jan 2018 03:15:38 -0800 (PST)
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_RP_MATCHES_RCVD=-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 LzJ1lmYgODqO for ; Thu, 25 Jan 2018 03:15:36 -0800 (PST)
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 F19F912DA0A for ; Thu, 25 Jan 2018 03:15:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2709; q=dns/txt; s=iport; t=1516878936; x=1518088536; h=from:subject:to:message-id:date:mime-version; bh=FDtgu5vUfROs4U7+Y3xWbB3Lo+F68tB0ERqJ+Ti+P00=; b=g3oyteXh0H1zpGzzlk0H/jVQCcSOu3IopJtr4ukzh83Eulv1Yw1Zu7Aj SHEIUs7dXLq+E3T5CGKvVMh6zucsvy4jCFMPgePZZep4NNH6eSnmPRjE0 HQHUdBmB38Uv02RBcqLe2siaQjOT72jxNZk73rI3D6xuOZbX26Sg1LKpr k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQCqomla/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj0+SFoVpggIKI4pPFAEBAQEBAQEBAmsohU1vBgE?= =?us-ascii?q?9Al8NCAEBijEQly+NWJAZgicmijoBAQEHAQEBASSEUYNsgWgpDIJJAYNeAgEBA?= =?us-ascii?q?QGBNSuDJIJlBY0QlnmCBYYQjU2CG2eFOINxh3qNWoFriBOBPDYigVAzGggbFYJ?= =?us-ascii?q?nCYRPQDcBjAEsgh0BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,411,1511827200"; d="scan'208,217";a="1598124"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 11:15:34 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0PBFX00029855 for ; Thu, 25 Jan 2018 11:15:33 GMT
From: Benoit Claise 
To: NETMOD Working Group 
Message-ID: 
Date: Thu, 25 Jan 2018 10:18:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------10DA8535DBFE03CA1762F8FC"
Content-Language: en-US
Archived-At: 
Subject: [netmod] Validators updated in the toolchain
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 11:15:38 -0000

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

Dear all,

yanglint upgraded to 0.14.65 from 0.13.79
yangdump-pro upgraded to 17.10-4 from 17.10-3
pyang upgraded to the latest github version (still version 1.7.3), but 
compliant to draft-ietf-netmod-yang-tree-diagrams-05 

confd: not yet upgraded

Some bugs have been fixed with the new versions.

So please checked your YANG modules:
     http://www.claise.be/IETFYANGPageCompilation.html
     OR
     from the tracker
         => Additional URLS
         => Yang catalog entry for 
         => compilation-result
         For example: 
https://yangcatalog.org/results/ietf-lisp-etr@2017-07-01_ietf.html
Note: those results come from the same toolchain

Next step is to upgrade the toolchain on yangvalidator.org

Regards, Benoit




--------------10DA8535DBFE03CA1762F8FC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    yanglint upgraded to 0.14.65 from 0.13.79

    yangdump-pro upgraded to 17.10-4 from 17.10-3

    pyang upgraded to the latest github version (still version 1.7.3),
    but compliant to draft-ietf-netmod-yang-tree-diagrams-05

    confd: not yet upgraded

    

    Some bugs have been fixed with the new versions.

    

    So please checked your YANG modules:

        http://www.claise.be/IETFYANGPageCompilation.html  

        OR  

        from the tracker 

            => Additional URLS 

            => Yang catalog entry for <YANG module>

            => compilation-result

            For example:
    https://yangcatalog.org/results/ietf-lisp-etr@2017-07-01_ietf.html

    Note: those results come from the same toolchain

    

    Next step is to upgrade the toolchain on yangvalidator.org

    

    Regards, Benoit

    

    

    

  


--------------10DA8535DBFE03CA1762F8FC--


From nobody Thu Jan 25 03:20: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 D1D2A12DA1A for ; Thu, 25 Jan 2018 03:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.508
X-Spam-Level: 
X-Spam-Status: No, score=-14.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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_RP_MATCHES_RCVD=-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 tgVmvLEdY30n for ; Thu, 25 Jan 2018 03:20:15 -0800 (PST)
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 7C94E12DA16 for ; Thu, 25 Jan 2018 03:20:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44432; q=dns/txt; s=iport; t=1516879214; x=1518088814; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=yORDjG0ZEZWMjIpsYKmuU5X1pkSpNGzFXeCIDD/GrPw=; b=OHd+MnrR9vrDeE+Z0hMw6yQNmdJ4DlMuQ79UPHmvLdbnqDcC/9Y+hEcs ZDX+7JaWxEHmP0huApV88UI01EZgsbtUfAg1/K36GS2OdyL1SjpuYGSzY 0to8fLTVbFJIbUb15k6OMY27oPR9kQXcGMRFnzHbzxuJ2slFe4+ZLqjsD w=;
X-Files: bkkgoabpbicgbeom.png : 14007
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQCqomla/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEYEXdCeDXYsYj0+DLZRSggIHAQIlhRYChTQVAQEBAQEBAQE?= =?us-ascii?q?CayiFJAYFHksbHQsBAQEiAgICFQEOIw4GDQUBAgEBAoovELUggicmijoBAQEBA?= =?us-ascii?q?QEBAwEBAQEBAQEBAQEBDgoFhFGDbIFoKQyGKAEBAgEBgTUOFIMtgmUFimmHUJA?= =?us-ascii?q?sgSSHEAGBBI1NjCuHeo1agWuEXoM1gTw1I4FQMxoIGxWCZ4RYQDcBjAEsgh0BA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.46,411,1511827200";  d="png'150?scan'150,208,217,150";a="1598191"
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; 25 Jan 2018 11:20:12 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0PBKCKg023857 for ; Thu, 25 Jan 2018 11:20:12 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: 
Message-ID: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com>
Date: Thu, 25 Jan 2018 12:20:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6F096081234516D0BFD2715F"
Content-Language: en-US
Archived-At: 
Subject: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 11:20:20 -0000

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

Dear all,

Thank you for this important document.
I've been spending quite some time trying to relay feedback seen on 
multiple fronts.
This is part 1 of the review, till section 4.21


-

    This document defines a set of usage guidelines for Standards Track
    documents containing [RFC7950 ] data models.

This is not inline with:
    This section contains the module(s) defined by the specification.
    These modules SHOULD be written using the YANG 1.1 [RFC7950 ] syntax.
    YANG 1.0 [RFC6020 ] syntax MAY be used if no YANG 1.1 constructs or
    semantics are needed in the module.

So it should be changed to
    This document defines a set of usage guidelines for Standards Track
    documents containing YANG 1.1 [RFC7950 ] and YANG 1.0 [RFC6020] data models.

Similarly in section 4
OLD:
    
    Modules in IETF Standards Track specifications MUST comply with all
    syntactic and semantic requirements of YANG [RFC7950 ].

NEW:
    Modules in IETF Standards Track specifications MUST comply with all
    syntactic and semantic requirements of YANG 1.1 [RFC7950 ]. See the exception
    for YANG 1.0 in section 3.6

Note that I tried to add some new text around the following sentence but that paragraph became clumsy.
    Alternatively,
    if YANG 1.0 is used, then Modules in IETF Standards Track specifications
    MUST comply with all syntactic and semantic requirements of YANG 1.0 [RFC6020].

Finally, in section 3.6, I would add a sentence to this paragraph
    This section contains the module(s) defined by the specification.
    These modules SHOULD be written using the YANG 1.1 [RFC7950 ] syntax.
    YANG 1.0 [RFC6020 ] syntax MAY be used if no YANG 1.1 constructs or
    semantics are needed in the module.

The sentence such as:
    if any the imported YANG modules is based on YANG 1.1, the main YANG
    module MUST also be written in YANG 1.1.

  - section 3, editorial:
    There are three usage scenarios for YANG that can appear in an
    Internet-Draft or RFC:

    o  normative module or submodule

    o  example module or submodule

    o  example YANG fragment not part of any module or submodule

    The guidelines in this document refer mainly to a normative_complete_
    module or submodule, but may be applicable to example modules and
    YANG fragments as well.

Either add "complete" to "o  normative module or submodule)" and be consistent throughout the document,
or remove it from the last sentence.


- section 3.2

    The "" tag SHOULD be followed by a string identifying
    the file name specified inSection 5.2 of [RFC7950] .  The name string
    form that includes the revision-date SHOULD be used.  The following
    example is for the '2010-01-18' revision of the 'ietf-foo' module:

     file "ietf-foo@2016-03-20.yang"

I would add that both revision versions (on the  and in the module) MUST match.
I ran into all sort of tooling issues because of such discrepancies.

- section 3.2.1
Add "see section 4.9 regarding the namespace guidelines for example modules"

- The following in paragraph in section 3.3 seems misplaced.

        If YANG tree diagrams are used, then a normative reference to the
        YANG tree diagrams specification MUST be provided for each diagram.
        (Refer to the example in the next section.)

It should be in section 3.4.
Btw, no need to have the specifications for each diagram!
Also, we want to add some guidelines on how to reference the tree 
diagram convention
For ex: no need to copy over the conventions
Basically, we just need: 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3

PROPOSAL (replacing the previous paragraph)

        If YANG tree diagrams are used, then a normative reference to the
        YANG tree diagrams specification MUST be provided. As an example guideline
        (from https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
        here is a subsection in the terminology section

        Tree Diagrams

        Tree diagrams used in this document follow the notation defined in
        [I-D.ietf-netmod-yang-tree-diagrams
    ].

- section 3.5
You should add a good example to illustrate the second paragraph (Based 
on some previous feedback, YANG module designer wants to work from examples)
I would suggest to add 
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09#section-2.3


- section 3.6, editorial
OLD:

   Note that all YANG statements within a YANG module are considered
    normative, if the module itself is considered normative, and not an
    example module.
NEW:

   Note that all YANG statements within a YANG module are considered
    normative, if the module itself is considered normative, and not an
    example module or a example YANG fragment.

- section 3.6

    Example YANG modules MUST NOT contain any normative text, including
    any reserved words from [RFC2119 ].

I guess it applies also to the "example YANG fragments"

- section 3.10
Mention yanglint.
yanglint validates xpath, while pyang doesn't.

- section 3.11
You might consider the addition of xym https://github.com/xym-tool/xym

- section 3.12
mention that the examples MUST be validated.
Pointing to the tool would be a welcome addition.

- section 4.6.x
You should really mention a common mistake about the missing derived-from-or-self(), flagged in many YANG doctor reviews::
  
You should explain the applicability: identity augmentation.

- section 4.7 "Lifecycle Management"
     The status statement MUST be present if its value is 'deprecated' or
    'obsolete'.

I've been confused for a little, thinking this section was about the IETF document lifecyle management and the obsolete document tag.
Proposal: "Objects Lifecycle Management" or "YANG Objects Lifecycle Management"
     The YANG objects status statement MUST be present if its value is 'deprecated' or
    'obsolete'.
  

- section 4.8
    The contact statement MUST be present.  If the module is contained in
    a document intended for Standards Track status, then the working
    group web and mailing information MUST be present, and the main
    document author or editor contact information SHOULD be present.  If
    additional authors or editors exist, their contact information MAY be
    present.


I would add: No need to include the WG chair contacts.

- section 4.10

        The separation of configuration data and operational state SHOULD be
        considered carefully.  It is sometimes useful to define separate top-
        level containers for configuration and non-configuration data.  For
        some existing top-level data nodes, configuration data was not in
        scope, so only one container representing operational state was
        created.

What about NMDA?
This section is not inline with 4.23.3
Btw, in case a YANG supports NMDA , RFC6087bis should include the guideline is that it must be clearly mentioned.
The example of the abstract in https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03 could be mentioned.
    The YANG model in this document conforms to the Network Management
    Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.


In the same section about "top-level data definitions", any guidelines in connection with https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ and schema mount?
Too early?

In section 4.23, add the [I-D.ietf-netmod-revised-datastores 
] reference next to NMDA
In section 4.23.3
OLD:
(b) For published models, the model should be republished with an
    NMDA-compatible structure, deprecating non-NMDA constructs.  For
    example, the "ietf-interfaces" model in [RFC7223 ] will be
    restructured as an NMDA-compatible model.

NEW:
(b) For published models, the model should be republished with an
    NMDA-compatible structure, deprecating non-NMDA constructs.  For
    example, the "ietf-interfaces" model in [RFC7223 ] has been
    restructured as an NMDA-compatible model in [RFC7223bis].

I believe [I-D.ietf-netmod-revised-datastores] should a normative reference

- section 4.14.2

Something wrong with:
    -top-level siblings are not ordered -top-level siblings not are not
    static, and depends on the modules that are loaded

- section 4.17
Discussing with YANG doctors that a feature-per-leaf is most likely the wrong approach, Jürgen came up with this.

OLD

    The YANG "feature" statement is used to define a label for a set of
    optional functionality within a module.  The "if-feature" statement
    is used in the YANG statements associated with a feature.

    The set of YANG features available in a module should be considered
    carefully.  The description-stmt within a feature-stmt MUST specify
    any interactions with other features.

    If there is a large set of objects...

NEW

    The YANG "feature" statement is used to define a label for a set of
    optional functionality within a module.  The "if-feature" statement
    is used in the YANG statements associated with a feature.  The
    description-stmt within a feature-stmt MUST specify any
    interactions with other features.

    The set of YANG features defined in a module should be considered
    carefully. Very fine granular features increase interoperability
    complexity and should be avoided. A likely misuse of the feature
    mechanism is the tagging of individual leafs (e.g., counters) with
    separate features.

    If there is a large set of objects...

back to section 4.5
    If a data definition is optional, depending on server support for a
    NETCONF or RESTCONF protocol capability, then a YANG 'feature'
    statement SHOULD be defined to indicate that the NETCONF or RESTCONF
    capability is supported within the data model.

NEW:
     If a data definition is optional which depends on server support then
     a YANG 'feature' statement SHOULD be defined.  The defined 'feature'
     SHOULD then be used in the conditional 'if-feature' statement
     referencing the optional data definition.

This is currently under discussion with the YANG doctors.

Regards, Benoit




--------------6F096081234516D0BFD2715F
Content-Type: multipart/related;
 boundary="------------FC398B92878038616A71D06D"


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


  

    
  
  
    Dear all,

    

      

      Thank you for this important document.

      I've been spending quite some time trying to relay feedback seen
      on multiple fronts.

      This is part 1 of the review, till section 4.21

      

      

      - 

      
   This document defines a set of usage guidelines for Standards Track
   documents containing [RFC7950] data models. 

This is not inline with:
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax.
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or
   semantics are needed in the module.

So it should be changed to 
   This document defines a set of usage guidelines for Standards Track
   documents containing YANG 1.1 [RFC7950] and YANG 1.0 [RFC6020] data models. 

Similarly in section 4
OLD:
   
   Modules in IETF Standards Track specifications MUST comply with all
   syntactic and semantic requirements of YANG [RFC7950].

NEW: 
   Modules in IETF Standards Track specifications MUST comply with all
   syntactic and semantic requirements of YANG 1.1 [RFC7950]. See the exception
   for YANG 1.0 in section 3.6

Note that I tried to add some new text around the following sentence but that paragraph became clumsy.
   Alternatively, 
   if YANG 1.0 is used, then Modules in IETF Standards Track specifications 
   MUST comply with all syntactic and semantic requirements of YANG 1.0 [RFC6020].

Finally, in section 3.6, I would add a sentence to this paragraph
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax.
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or
   semantics are needed in the module.

The sentence such as: 
   if any the imported YANG modules is based on YANG 1.1, the main YANG 
   module MUST also be written in YANG 1.1.

 - section 3, editorial:
   There are three usage scenarios for YANG that can appear in an
   Internet-Draft or RFC:

   o  normative module or submodule

   o  example module or submodule

   o  example YANG fragment not part of any module or submodule

   The guidelines in this document refer mainly to a normative complete
   module or submodule, but may be applicable to example modules and
   YANG fragments as well.

Either add "complete" to "o  normative module or submodule)" and be consistent throughout the document,
or remove it from the last sentence.


- section 3.2

   The "<CODE BEGINS>" tag SHOULD be followed by a string identifying
   the file name specified in Section 5.2 of [RFC7950].  The name string
   form that includes the revision-date SHOULD be used.  The following
   example is for the '2010-01-18' revision of the 'ietf-foo' module:

   <CODE BEGINS> file "ietf-foo@2016-03-20.yang"

I would add that both revision versions (on the <CODE BEGINS> and in the module) MUST match.
I ran into all sort of tooling issues because of such discrepancies.

- section 3.2.1
Add "see section 4.9 regarding the namespace guidelines for example modules"

- The following in paragraph in section 3.3 seems misplaced.  


      

        
   If YANG tree diagrams are used, then a normative reference to the
   YANG tree diagrams specification MUST be provided for each diagram.
   (Refer to the example in the next section.)

      

      It should be in section 3.4.

      Btw, no need to have the specifications for each diagram!

      Also, we want to add some guidelines on how to reference the tree
      diagram convention

      For ex: no need to copy over the conventions

      Basically, we just need:
      https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3

      

      PROPOSAL (replacing the previous paragraph) 

      

        
   If YANG tree diagrams are used, then a normative reference to the
   YANG tree diagrams specification MUST be provided. As an example guideline 
   (from https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
   here is a subsection in the terminology section

   Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [I-D.ietf-netmod-yang-tree-diagrams].

      

      - section 3.5

      You should add a good example to illustrate the second paragraph
      (Based on some previous feedback, YANG module designer wants to
      work from examples)

      I would suggest to add
      https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09#section-2.3

      

      

      - section 3.6, editorial

      OLD:

      
  Note that all YANG statements within a YANG module are considered
   normative, if the module itself is considered normative, and not an
   example module. 
NEW:

  Note that all YANG statements within a YANG module are considered
   normative, if the module itself is considered normative, and not an
   example module or a example YANG fragment. 



      - section 3.6

      
   Example YANG modules MUST NOT contain any normative text, including
   any reserved words from [RFC2119].

I guess it applies also to the "example YANG fragments"

- section 3.10
Mention yanglint.
yanglint validates xpath, while pyang doesn't.

- section 3.11
You might consider the addition of xym https://github.com/xym-tool/xym

- section 3.12
mention that the examples MUST be validated.
Pointing to the tool would be a welcome addition.

- section 4.6.x
You should really mention a common mistake about the missing derived-from-or-self(), flagged in many YANG doctor reviews::
 
You should explain the applicability: identity augmentation.

- section 4.7 "Lifecycle Management"
    The status statement MUST be present if its value is 'deprecated' or
   'obsolete'. 

I've been confused for a little, thinking this section was about the IETF document lifecyle management and the obsolete document tag.
Proposal: "Objects Lifecycle Management" or "YANG Objects Lifecycle Management"
    The YANG objects status statement MUST be present if its value is 'deprecated' or
   'obsolete'. 
 

- section 4.8
   The contact statement MUST be present.  If the module is contained in
   a document intended for Standards Track status, then the working
   group web and mailing information MUST be present, and the main
   document author or editor contact information SHOULD be present.  If
   additional authors or editors exist, their contact information MAY be
   present.


I would add: No need to include the WG chair contacts.

- section 4.10


      

        
   The separation of configuration data and operational state SHOULD be
   considered carefully.  It is sometimes useful to define separate top-
   level containers for configuration and non-configuration data.  For
   some existing top-level data nodes, configuration data was not in
   scope, so only one container representing operational state was
   created. 


      

      
What about NMDA?
This section is not inline with 4.23.3
Btw, in case a YANG supports NMDA , RFC6087bis should include the guideline is that it must be clearly mentioned.
The example of the abstract in https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03 could be mentioned.
   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.


In the same section about "top-level data definitions", any guidelines in connection with https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ and schema mount?
Too early?

In section 4.23, add the [I-D.ietf-netmod-revised-datastores] reference next to NMDA
In section 4.23.3
OLD:
(b) For published models, the model should be republished with an
   NMDA-compatible structure, deprecating non-NMDA constructs.  For
   example, the "ietf-interfaces" model in [RFC7223] will be
   restructured as an NMDA-compatible model.

NEW:
(b) For published models, the model should be republished with an
   NMDA-compatible structure, deprecating non-NMDA constructs.  For
   example, the "ietf-interfaces" model in [RFC7223] has been 
   restructured as an NMDA-compatible model in [RFC7223bis].

I believe [I-D.ietf-netmod-revised-datastores] should a normative reference

- section 4.14.2 

Something wrong with: 
   -top-level siblings are not ordered -top-level siblings not are not
   static, and depends on the modules that are loaded

- section 4.17
Discussing with YANG doctors that a feature-per-leaf is most likely the wrong approach, Jürgen came up with this.

OLD

   The YANG "feature" statement is used to define a label for a set of
   optional functionality within a module.  The "if-feature" statement
   is used in the YANG statements associated with a feature.

   The set of YANG features available in a module should be considered
   carefully.  The description-stmt within a feature-stmt MUST specify
   any interactions with other features.

   If there is a large set of objects...

NEW

   The YANG "feature" statement is used to define a label for a set of
   optional functionality within a module.  The "if-feature" statement
   is used in the YANG statements associated with a feature.  The
   description-stmt within a feature-stmt MUST specify any
   interactions with other features.

   The set of YANG features defined in a module should be considered
   carefully. Very fine granular features increase interoperability
   complexity and should be avoided. A likely misuse of the feature
   mechanism is the tagging of individual leafs (e.g., counters) with
   separate features.

   If there is a large set of objects...

back to section 4.5
   If a data definition is optional, depending on server support for a
   NETCONF or RESTCONF protocol capability, then a YANG 'feature'
   statement SHOULD be defined to indicate that the NETCONF or RESTCONF
   capability is supported within the data model.

NEW: 
    If a data definition is optional which depends on server support then
    a YANG 'feature' statement SHOULD be defined.  The defined 'feature'
    SHOULD then be used in the conditional 'if-feature' statement
    referencing the optional data definition.

This is currently under discussion with the YANG doctors.

Regards, Benoit


      

      

    

  


--------------FC398B92878038616A71D06D
Content-Type: image/png;
 name="bkkgoabpbicgbeom.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="bkkgoabpbicgbeom.png"

iVBORw0KGgoAAAANSUhEUgAABJwAAADaCAIAAABsAs/pAAAgAElEQVR4nO2dPW7rutaGNYg0
Fwi+xoCA1KdxlVoNb5eUdwAXcMn6tHsARloWtztTCOARaCyZgr5CprQokZTo2KZ+ngcvsB2J
IpcoJ+S7uSQVTdM0TfMDAACwQhoAAIDdU7T/5B6UAQAAbiHvIAoAALAEMHUAALBi8g6iAAAA
S+Cppu5yOhRFdX5OYwAAsAPyDqK1LotCmbxBAADA7nn2St3ldMDVAQDAvcg7iDZNU+sSVwcA
AHl5evrlucLUAQDAvcg7iDZN0xiFqQMAgLxg6gAAYMXkHUSbBlMHAAD5wdQBAMCKyTuINg2m
DgAA8vP8p19eTgcelgIAAPch7yDaNE37tBR8HQAAZISVOgAAWDF5B9GmYaUOAADyg6kDAIAV
k3cQbRpMHQAA5AdTBwAAKybvINo0mDoAAMgP76kDAIAVk3cQbXhPHQAALICnmrrL6VAcTpfn
NAYAADsg7yBa67IodZ03CAAA2D3Pf/olAADA3cg7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDA
isk7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsht6s5V
URRre3Pd5XQoFv9uhlX2LABAKnkHUQ9GFUWxtjfX1bosFv9uhlX2LADAc8ht6n5+fs7VDdbj
cjpkdVWXU7VsU3eulu46AQDuQd5B1I9RN1iPWpdZXVWt1bJNnVFLd50AAPlYq6nLDaYOAGAR
5B1E/dxk6nKDqQMAWDFPNXWX06G4UlWd6ThX1flc2e3S33VbnVxHW8vYtPjrF9VM5Uy2KYtV
1UZyPa4Lqa+nOk+ZujaUa1XueYko+y6Y125CziemDgD2Qd5BtNal/QOtVGc6jFLGKLvdiPLd
VifX0dYyNi3++kU1UzmTbcqiUm0k1+O6kPp6lJkydW0o16rc8xJR9l0wr92EnE9MHQBAmOeZ
usvp0PuUy+ngOJr+s7RivS1xfhiWjNfvFDxXU7eZ2Zbsv5fToTr/uPme8p46YdEG/s09xz6I
y/ksTsuWDrWbGn+wfwAANknGEbTWZe9Tal06jqb/LK1Yb0ucH4Yl4/U7BY2aus3MtmT/rXWp
TOPme8p76oRFG/g39xz7IGpjxGnZ0qF2U+MP9g8AAHQ8zdSFl7Zk+mVnZUZJmcPjh6YlVL9Y
5hqYLj+2XVv/NaKp5j305zL67Ikm0G5y/PaksXQAsA/yDaDhpS2ZftlZmVFS5vD4oWkJ1S+W
ucaLZpFobP3XiKaa99Cfy+izJ5pAu8nx25PG0gEAhNmBqUuzN482dc5amygSNnW32TNW6gBg
H+QbQPOZujR782hT56y1iSJhU3ebPWOlDgAgzFPTL4XNEMmSflM3cCUjz+ZLv/TWPz9j0Ylm
aK6kRXMyK4OETJ2TVDq5Upcaf38emDoA2AMZR1D3eZUiWdJv6gauZOTZfOmX3vrnZyw60QzN
lbRoTmZlkJCpc5JKJ1fqUuPvzwNTBwAQ4qkPSpGphP3CVfdjl5c42De6Uy2Ujuipf3xIzOuI
aM5VW/b6xJOzW011mnhVnTwX97zkc1Kqqq082m5C/M6pYOoAYA/kHURlKmG/cNX92OUlDvY5
SYfhe9i89Y8PiXkdEY1RbdnrE0+MW43SE6+qk+finpd8TopSbeXRdhPid04FUwcAEGIBrzSA
R4CpA4B9kHcQheeBqQMACIOp2yrtaxLW9wZAAIAk8g6i8ETa1ySY3GEAACwRTB0AAKyYvIMo
AADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMo
AADAEsDUAQDAisk7iAIAACwBTN0NXCbePL4u7LvNhycU2j4Br1IAgKeSdxDdCvXEm8fXhX23
+fCEQtsn4FUKALACMHW3cTlVWzF1LaGXlae+xJyXngPAc8k7iG6IWqutmLqW0MvKU19izkvP
AWANYOpuA1OXWA8AwGPIO4huCExdYj0AAEti0abOJgAWRVFVnVkQWwf+4Vx5isvNU6mEbepg
VRVFUVTn63FdKqGo/jxl6togr1W5+Yie+Oe2O50KGWpXJEVe2x9kSGLqAGCd5B1EU7EJgEVR
KNWZBbF14B+M8hSXm6dSCdvUQaWKoiiUuR7XpRKK6s2UqWuDvFbl5iN64p/b7nQqZKhdkRR5
bX+QIYmpA4A9sVxTdzkdeuNxOR06Q3M5n4Vd672JsBOyuOMynAO8nKv2SPvv5XSozm2VTvW2
fmHRBj4qFIQ//lC7ofjT2z1X/al3tYvzxtQBwBrJO4gmUeuyNx61LjtDUxsj7FrvTYSdkMUd
l+Ec4MWo9kj7b61LZdoqnept/cKiDXxUKAh//KF2Q/Gnt2tUf+pd7eK8MXUAsB8Wa+rCS2Gu
nfEvgXmXucZHeLDWx5qTq/0ZhjPDu0jjNPjsiSbQbnL84XafYOqsIwUAeBp5B9EUwkthrp3x
L4F5l7nGR3iw1seak6v9GYYzw7tI4zT47Ikm0G5y/OF2n2DqrCMFAFg4qzN1zlrb2Jv0O67u
In2l6bGmLhR/2NSl2qSMpu6meAEAfkPeQTSFkKlz1trG3qTfcXUX6StNjzV1ofjDpi7VJmU0
dTeUBwDIwWJNnZPvKJIxz4Ob5YRncYuL+9VSHrAfMleODZIZjrET8Jo6f/yhdlPjj5k69xY+
TB0AbIG8g2gSMt9RJGOawc1ywrO4xcX9aikP2A+ZK8cGyQzH2Al4TZ0//lC7qfHHTJ17C59b
KaYOAPbEck3dj5t66MtePFTVodvl5ilKy+LmO8Y8h62jOrcfD6fL9ckj50F252niVXVd4ers
fPbHH203If5Yu6KHDqez96xk6fA9e1PXDFMHAM8k7yCaikw99GUvlkqV3S43T1FaFjffMeY5
bB3KtB9LXV+fPGIG2Z164lV1XWFlnM/++KPtJsQfa1f0UKmN96xk6fA9e3EwdQCwBhZt6mB9
YOoA4LnkHURh+2DqAGANYOrgvvhyOwEAHkbeQRR2gC+3EwBgYWDqAABgxeQdRAEAAJYApg4A
AFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4A
AFZM3kEUAABgCWzI1NnXZd/nPWniXea/fj7/ZeJN5esi1M839j+vQACAX5F3EH0s9nXZ93lP
mniX+a+fz19PvKl8XYT6+cb+5xUIAJCBDZm6lvu8/PpyOtzXZ1xO1VZMXUuon1P7n5eVA8Dv
yDuIPoP7vPy61uV9fUat1VZMXUuon1P7n5eVA0AOMHUPrEWAqUusBwBgHnkH0WdwH5Nwd6uB
qUusBwDgkezB1IlMSrnPpguGN08mX7apg1XVlru20x3Qt1udp0xd2+q1KrdVT5xz251OhQy1
K5Iir+0P+gFTBwDLIO8g+gw8JkFkUsp9Nl0wvHky+bJNHVSqLXdtpzugb1eZKVPXtnqtym3V
E+fcdqdTIUPtiqTIa/uDfsDUAcCa2b6pczacq96cXM7ni2ezv5ZIe61zsv/axM3L6dBVIe+p
G3rG3i1dTgfh2vr2/XGG2g2db3q756rvk3E6KqYOAJZB3kH0GYxMgrPBqN6c1MbUns3+WiLt
tc7J/msTN2tddlXIe+qGnrF3S7UuhWvr2/fHGWo3dL7p7RrV98k4HRVTBwBrZvOmTixbeczM
eKu/llh7rpe62p/hytyMCqVxGnz2xBloN3K+qe0+wdRZRwoAcDN5B9FnMDQJYtnKY2bGW/21
xNpzvdTV/gxX5mZUKI3T4LMnzkC7kfNNbfcJps46UgCAJ7MDUxcyH0XEsyzH1IXiDJu6VJuU
0dTdFC8AgCTvIPoMxqYuZD6KiGdZjqkLxRk2dak2KaOpu6E8AMA92LypG6dWjsudq7uv1Lk2
SGY4BgmZOn+coXZD55varmzZ99YBTB0ALIO8g+gz8KRfeteq3ETDu6/UuTZIZjgGCZk6f5yh
dkPnm9qubNn31gFMHQCsmc2YuvA9Y4Nd1kPI549U1aEYPBdkVvaizXWszu3Hw+lyffLI2a2o
Ok28qq4rXJ2dz/44o+0Gzje1XZHJeTidvWclS0f6PwqmDgB+R95B9JGE7xkb7LIeQj5/RKmy
GDwXZFyNB5vrqEz7sdT19ckjxq1I6YlX1XWFlXE+++OMths439R2RSZnqY33rGTpSP9HwdQB
QA42Y+pgnWDqAOB35B1EAYZg6gAgB5g6yIsvtxMAYDZ5B1GAEb7cTgCAB4OpAwCAFZN3EAUA
AFgCmDoAAFgxeQdRAACAJYCpAwCAFZN3EAUAAFgCV1P33XyjG/RP3SCEdqLsf3CQV+EB7g+6
QfkjQAg9S7nbRyFh6p6u7LNMhNDTlP0PDvIKU3df5Y8AIfQs5W4fhYSpe7oeNX38W/3rP3X2
KSxCSCr7HxzkFabuvsofAdqSjHrRdf4wUEC520chYerGMseiKI7mUfX/Uzf//E//qyiKd/PP
36ooinuYsfrf/6f+m1a+KP5P/8k95Y3pb9W9vfWvv3MHczeZv4qiKJIuFv2cqPb3a/ybFdoe
ui43/p6av9qj6uYfTN1StTtTZ96KolDmUfX/aZo/tX5p2zCqKArfpLx+L4ui1Kf83ZEej+n/
Tr6Z7JE/Uu119F/BiX74UOV7fZfroj7Syi/qe+XT8r8/07+/vbIHiwLC1HlljkfzqMq7ad+/
/lO3s8Y7zKT/p/9lJ5GzVf/7fcmmLtWm3kf/fX90o0uz01vt5/DatX+797rc9Hvq1p//rxny
aXemrvnTmLfHmrrGvLVzwVq/BGeu9bv61eT7pMu7ruHMjCfVZqxf/rWyaD/U+uUuzqrWL8nf
1N9+rx6sPN+fD5XUaPT31/0+5O9R5BemzqunmLq//m6XAsp//+/3U+QbKlm4qTN/5XA+CWZD
LHB1zFnM+e97v4yzAC2+n29WmqnzXpebfk8xdWsQpu6+ujbQzgVr/VKEVmyWNvmeGY95W/hC
0N3lN3Wxfjjp8i5rUDct9y3te5XQb4/TDaYu+PuLqVuHdmzqvvRrURSF0s6P5edX05o6fbxO
1I+6P6rbaEs239/152tRFOroK+/RP3XzT13/+//aOaL56/eZeM4yXZv6pa65ZFfj0TXR5pi1
iXZTpu6ae6bsISJOm8YmbMzcducsUv35T+lYJTHV/u+7p562/L/+U9sDy3//LxqPJ35n43yH
doP+/Kd0aqaf4/0c6p+/VWFXz67xDCxZoqkbXpe6ufH3FFO3Bm3V1F1T5+xc7vpjO0Mzb8p8
2P+LktPvj/4/qLq5XP1eFkWh3nzlPbLH2JYKOZs0b0VXi5x899tl7txJl0VRvOi6/dDH5E0L
7LLabNrY9XO4/nA8ftkwCrfycJyyQ6/ttsmv6q29Ntc4pyfco3om2p2uRynhLkL9c+3YgakL
9YNVd/V//Q3ua473W8p1vOYWKnuI6Hz7vRJfrbntzsn5jPTb7OsbjccTv7NxuCuo0O+v5/vw
y4uMHqYdm7rv5utTWWPWfH8331/6+Fl/fzftbXWv3edX/dUW0MpubMtYQ/hdf776ynv1CJPg
JoaZv9pVhb9VOyO3BboZauMmm9X//j/3t9+ZlNtD5FT1f+a/dtXiv+9dWlqoXXch8W9lJ9/h
dtvaRrbkv+/CANhW3Kl/W7P579+xeALxtz/muNuNfr7te/i36uscZyAnmrq7CVO3Bm3V1DXN
SStnal3rNzFT7Wet3TTSma3J6Vz9XvrKexUOSM71nXufnAUZoxyT0N3e0zR/GvNhRIXjFSRp
A8TeQP2heFoX6/z9cXyp9/x9cX4oMYE2Svi68r3ut9h1rWC7gXpC7YbjF31y0uWs/vf2c/x7
UOuXGTZ1xtd3sNwX6bfE6ygXoOTZ1eZDuHHbeqjdyPcq7fuTeH2D8QTib3/8/RURDtbyZjbw
d3Kr2rWp+9bqqJtvrdplt6/P0i6yyfTL+vP1at7EMt0VW74v43726d6TyPGk3PzVzm7t5PI6
yf6f/suZy87Iu5MT5cFn0Qu92fC2K5ePBpP1287L6s9/VO9hhmcXiScUf/PPU9Iv6ee0fo70
zwJN3cADY+qWqu2auj9GvZl2Bat8r+UkWaZf9vf4fIz+kNny8j6gqXuCgjt6T2mDkItX7t+r
j+BRzumNzUY3eRWz2ED9wXjiCpq6UZzDJFdrsu12G/9UsmKonqn+8Uj6jan+ifbzhKm7Q4bh
uP5Av91wHaX5H3z2fPtD12uq31LPa+71DX9//PE3f+5j6vzfh3vViu6tfZu6L338rL8+tf7S
x89aHzszFjJ1pbOy1yufqRst04Un2XczdU4qmgggbDZuuWvrcWYjFH/zT8aVOvo5uX8WaepG
9Wf/K4e82rCpq/Wbrk9af9T6TdeOzfGbuvDtb481dZFZeKKpu24cZO7NsmF7MHVOwC9z+j/U
zw9eqfP1yaNNnZNq6PkvkLGpu8W7Ps7UheJv/mDq9qh9m7rv+vNTfx71V3tfXJ826Td131oF
XnVwT1MXeuS9d7v30YWhSbZT+M9/yunbrkJmoz/QPkki1u4w9W6evGmB8mEV7j2BSWbDH/+g
ieGuB4p+jocdNnXurYbGOQpTh8LasKlr6net35U+DZ/07jd1nsy7cZnbTZ17pJv+F75RL9XU
NfV7qd5cexqoPxhPVPNN3cAld/d6pZq6UD1T/ROvR6ynxfo/2M8RS+O9p868+deyvNu9X7JQ
v6Vfx5Cpc28ynDJ1U/02+/uTeH3nmEwZ/6AJd5eT3jlPmLp1aOemrtFHey9cf7+cuWZZHo19
CErRPU/l61OmTbcLd7LMsLxH05Ps+abOMz21OXji5VrtYyTsQ/ws73ri2fpd4XfjfHYesFH+
9d5WHm13cLvUlJkMP8DDyTC0TmB4L5aTi+iLxxf/6Kzv8VTSWaKf4/0c7h8RZ/nvv7ub/UL3
5sXvLbyfMHVr0JZNnbhbp5+J2awxZUQ63nVW7D7KoZ0HyjLD8h7FApLpYUoHb38K3BMlkkGH
v7+DdEHfozvG9Ufi8SvwoItQnKKv++2i9+1LwNpqJxbrZvTDpMFw82tlp83q/8C3xGMJ/Ots
4ysV2u6xkdF+S7qOXWFlnM/OeZVvqq08fr0C36u070/S9Y3F44t//Kvn+O2TLudljQb1i0PR
Q7V3U5dB95s+5nnDGEIoJkzdGrRpU5dB+SNA2fWr2+r29ybAbJJPQLpR+U8C+YWpe7ryTzoR
Qg+Ukwua/Q8O8gpTd1/ljwAtQDe9Yg49Wb43FiQq/0kgvzB1T1fuGSdC6HnK/gcHeYWpu6/y
R4AQepZyt49CwtQ9XdlnmQihpyn7HxzkFabuvsofAULoWcrdPgoJU/d0ZZ9lIoSepux/cJBX
mLr7Kn8ECKFnKXf7KCRMHUIIoZ0JS4fQ8pW7fYTWJUwdQgihnQlTh9Dylbt9hNYlTB1CCKGd
CVOH0PKVu32E1iVMHUIIoZ0JU7dctW9MFu9ZFntDL7POJ6Pc90SvX/aN1cNXmYW2B6+LefO+
ti52fW1V9g3d2TsDoVUJU4cQQmhnwtQtWOatnevX+mXolOr3sihuf8P13ZXnldkf6vGNGuV/
P7V/u/+6nHTpM7qR6zus/+ldi9CqhalDCCG0M2HqFizz1s71a/1SDF9m/aH6ZZwFKLAY9WAt
z9QFrkutXzz9E7u+mDqEfiFMHUIIoZ0JU7dg1e9lO9c3b6NMy5MuHVNxzeVTb9cUSFHepguK
HL82tU9dcwWvmZPdIcZWMmsx8KTLQiIszYfy1NOWf9G1PbB8r6PxeOJ3Ng53eRXqH6O6fNFr
PANLlmjqhtdleCnnXl9MHUK/EKYOIYTQzoSp247kgo+0BLX5sHbiQ3VpfuatLWxU67i6FMEP
JeyHUdbk1O+ud3PvHPOs1H0oYbRsKyLUzj6ZDxOLJxB/++N4pS4cZ6h/jOrrrPXL70xdSIPI
p4WpQ+h2YeoQQgjtTJi67UgaksFnYXF6U9cWsObBmiixTOcxbyGNTZ2t3+qkVe8Va/02fi6I
P55Q/M2f1PTLUP88y9QllB94YH4jEUoTpg4hhNDOhKnbjvymxUntE0/sCJu6W+6Oe5ypC8Xf
/FmbqWOlDqFnCVOHEEJoZ8LUbUchU9fbLftkjvZzYGUs2X4MW7nKSeNs6nflpF8mmDp//IMm
hrtm94+0T85bBEZ7m1nb/fLeUxcVpg6h24WpQwghtDNh6jaiLkdRGeez8yCT8k2VRVG8GZtj
KV6S1hZ7M83wtrSphbvwg1KcTE7ruIb3vDk5n754fPGPznr89MjZ/SPiLN9Nd7Nf6N68+L2F
4dZT1z8xdQjdLkwdQgihnQlTh9CjFXhPXVSYOoRuF6YOIYTQzoSpQ+jBuvU2RbHsmf8kEFqT
MHUIIYR2JkwdQstX7vYRWpcwdQghhHYmTB1Cy1fu9hFalzB1CCGEdiZMHULLV+72EVqXfmHq
fgAAAFbIbYMfAADAlsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEtikqbucDkVxOF1yxwEA
AI8m7yD6LGpdFkWp69xxAADAMtmkqfv5+bmcqqeausvpMN9FnqvqfI96AAAg7yD6RGqtnmrq
al3Od5FGKXOPegAA4DYwdRmImDoAAEgi7yD6RJ5t6pKImDoAAHgCWzJ156q4Up2lqeu3D3Iy
xQFVJXZdTofxjnbj4XSxe+0Bw5+7mg+nc1fRsLAnIl89wzi7fW3hqrJ7cIkAsFPyDqIPxij7
518Zaer67YOcTHGAUmJXrcvxjnZjqWu71x4w/LmrudSmq2hY2BORr55hnN2+trBSdg8uEQAg
gc2YOpm36NxTd5Z27Vz19kfsuJwOju3qysgdP52Vaveez9JIOc1cmypkY8J3xVbqfPUcpD/1
Bj06CgBgJ+QdRB+JzFt07qkz0q4Z1dsfsaPWpWO7ujJyR9NZqXavMbbUqJlrU4VsTPiu2Eqd
r55S+lNv0KOjAAAgwlZM3TDdsnM5YpluuKglV83ExkjeZmSnz4xVrusTDm++qRuW7UO4nA7y
VFirA4BdkncQfSDDdMvO5YhluuGillw1ExsjeZuRnT4z5lg34eRSTN2wbB9CrUt5KqzVAQDM
Zgembs4aVr/Od0dTF3RnmDoAgHuRdxB9IBFTN2cNq1/nu6OpC7ozTB0AQF62YupcW+NmJvpv
ODsP7qIT6ZeDhEtZb9JKXeEkfsr0y27HuSqGC3pRcygiwNQBAGzY1Lm2xs1M9N9wZgZ30Yn0
y0HCpaw3aaWucBI/Zfplt8OoYrigFzWHIgJMHQDArWzG1A2yKU/itjr34STC7PlyMoe77I7h
E05C2/tb7qrD6RR4RMtl9ACVcD2DSK9bu+LV2fkMALAz8g6ij8XJptTitjr34STC7AkGxmq8
Y/iEk9D2/pY7VWodeERLPXqASrieQaTXrV1xZZzPAAAwgw2ZuoXBs0sAAJ5A3kF0V/DsEgCA
xYKpexSYOgCAJ5B3EN0VmDoAgMWCqXsInjfLAQDAA8g7iO4Hz5vlAABgMWDqAABgxeQdRAEA
AJYApg4AAFZM3kEUAABgCVxN3XfzjRBCCK1O4QHuD0IIIbRCYeoQQgjtTJg6hBBC2xKmDiGE
0M6EqUMIIbQt7dzU1Z+vRVEo/W2ORVG86q/8IaHHSKvXz/rmw/Wx/PzKfQoIoXsJU9erfi+L
olAfjXkriqLUp/whocfIqBdd33z4hyrf69yngBAKa+emrtHH1svVn69FcTTf383XZ1kUhTQA
+lgUxYw5/Zd+nW8LtTrq/Kd/k1on3POoE0nqz+mYr1cwfH2j5/WlX48md88jhO4kTJ3Qh2q9
XP1eFoUyf5rmpMuiKKQB+FBFUcyY09f6Zb4tNOrN5D/9m9Q64Z5HnUhSf07HfL2C4esbPa9a
vyiTu+cRQkFh6lovV3++9hN9fSxfj9ZOfOnX1/L4i0Uev1Zs6prv7/qz65/v+vP1Yb7uXnIt
Wfj6Rs6rt4UIodULUyf0oVovV7+X/UT/Q5UvytqJWr+U5dsvFnn8WrGpa/409XvXP039Xj7M
191LriULX9/IefW2ECG0QO3d1H19lq2X08d+Bq+P6vNTdQs7x0/dT/q7xRxnEclu92xUx+Ng
5We4IiSP0sdua2chQvWE4omUb76/dHfE8aiEjx23G5E0P833tzl2rWs1qEcf+2CO2hxDXXF7
fyZc5enrGzqvUSWxzkm5XtH+Sb0uCKF5wtQJnXTZerkP1c/gP5R616pb2HnTup/0d4s5ziKS
3e7ZqN7syGDrH64IyaM+VL/VWohQPaF4IuWbP7V+sUe8KSV87LjdiKT5af405q1rXbxyva3n
Q/XBvBnzFuqK2/sz4SpPX9/QeY0qiXVOyvWK9k/qdUFov9q7qfNKH5X+aif65viqv776Sb/W
dlqvVZuuKeR4gLa8WAB093pX6pz7vsyxUHqinlA8gfJf+tVbZ7DdkAbmp/58VbqNoY/NHIWv
e207s93Sr5vdrz/j0bpriZHr6z+vYISxFudfr2D/JF8XhNA8Yeqm9KHUR91O9M1bqU91P+n/
MHZab1QxzMdzPEBbXiwAunu9K3XOfV/mrVAfE/WE4gmUr/WLt85guyENzE/9XqqPNoY+NvMm
fN1L25ntln7d7H79GY/WXUuMXF//eQUjjLU4/3oF+yf5uiC0X2HqPNJHpdv5fTur/vKt1BXF
PBMiTZTjEMamTizL2BZ0vJ5QPP7yX3Z5ana7IfnNjz66rsP2m91u+0eYurv1ZzxaN3Mydn3j
pi7BRiZcr1D/pF8XhNA8Yeqm9KHURzu/b2fVtW+lrijmmRBpohyHMDZ1YllmsMgTqicUj7/8
yS5PzW43JL/5+VCu67D9Zrfb/hGm7m79GY/WzZyMXd+4qUuwkQnXK9Q/6dcFof0KU+dRO8n+
+iyLdm2kNydiVu15csbvTV0oxc5fTzieVIvde08AABZySURBVFOXmtrnT1NMNXX37M94tOOV
Ot/1jadfJq7UJVyvcP+QconQY4Spm1I7yT7psmjXRnpzImbVnidn/N7UhVLs/PWE40k1damp
ff40xVRTd8/+jEc7XqnzXd94+mXiSl3C9Qr3DymXCM0Vps6jsDnpJ9n2CSvywDRT59zP1lYV
tA0hkxCKJ9Cu+zzJr89yqt2QHPPz9VlevYr72oDOQ84xLb/tz6jG99R5r2/wvHyVTPRPyvUK
rmQmXxeE0Dxh6qYUNif9JNs+YUUemGbqnPvZbLpdwDaETEIonkC77vMkT7qcajckx/ycdHn1
Ku5rAzoPOce0/LY/oxrfU+e9vsHz8lUy0T8p1yu4kpl8XRDarzB1Q2n3+Rbdj22eXv+ci6N6
LZy3IIzS5LpcO6Wdz21DfSaea4RkVa0HCNfjjyfarhapDEcTbTek0YNeRD1OxuDRiC3iZYBt
2Edz1/6MylkWk3XK62si55Xy9Mu06xXrn7TrghCaLUxdVB/u8y26H9s8ve4pIy9KvRTOWxAk
b6YRuXbqw/ncNtRn4rlGyPm7915H6/HHE23XiHFQGAZfuyGNHvTiPFhyuN1uES8DbMNW5q79
GZWzLCbrlNfXRM4r5emXadcr1j9p1wWhXQtTh/agX7+QgPfUIbQlYerQ7vTrFxLwnjqEli1M
HdqH3NTQVHF7G0KbEqYO7VBuamiquL0NoYULU4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0J
U4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0JU4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0J
UxeR6d+kfTS5g1m17Du4X/VX/mBuiPO2+Jf//WnPS7z3PH9ICD1FmLq5Mm/+91CjVNl3cJf6
lD+YG+K8Lf7lf3/a8xLvPc8fEkI3ClMX1NdnedRPb1er5Ea/9Os6puPmOD/OG/rh4XGmxL+S
748+tl6u/nxdrPNE6AHC1M3TSZdv5untGpXcaK1f1jEdN2/z47yhHx4eZ0r8K/n+fKjWy9Xv
5WKdJ0KzhKkLKs/7pnOamUdrX6ZuFd8ffWy9XP35Wvzm5ewIrUyYunnK877pnGbm0dqXqVvF
9+dDtV6ufi+L37ycHaHswtT59KVfC4nS3S6t7EYxZW/Lv+ove+DrZ62PRVGo47EoiuKor5l4
dsJt0/mcnDexcbgrpHBaYB+nOs5wF7rPFHQKf32WXQLh12dZFOXnlzl2+YTX8+36x3tenWaa
omg/ePs/Vs/1EojOj8Qfj3O2qVvN96f5+ixbL6ePxcANtpcep4e2KUzdpGr94v4d++h2mf7v
WD9lb8uX+mQPfNH1hyqKQr2poiiKN3PNxLMTbpvOV8icN7FxuCukcFpgH6d6m+EuPlTfqix8
0jYmZU66LIryvTZvhV3VuZ5v1z/e8+o00xRF+8Hb/7F6rpdAdH4k/nics03dar4/zUmXrZf7
UMXADbaXHqeH1iJMXVCelRatxETZHB1f0d2e1Hx/N1qb7+9GH9s5sS35pV+Ppi2sdd3Xed14
/TF9hWpsNsSWL/066X+0EnN3c+xMiIjt67N8fVW2HnPsY64/X3tTFzwvf5yxkDz9EOt/r+QC
lGw9FH88zl+v1C30++MXpg5tWZi6efKstBglJsrmzfEV3e1JzZ+m+TDmT9N8qHZObEvW+uWa
4VZ/mLqvU6a93bJCNTYbYkutXyb9j1Fi7m7eOhMiYjvp8qVUth7z1sdcv5e9qQuelz/OWEie
foj1v1dyAUq2Hoo/HuevV+oW+v3xC1OH1iVMXVDjSbk+urP/L33sp7z153E447flrRkQk3Jn
UeW6sfn+vpepEytsxXAFxnemxYD2EPd868/XctLUBc8rEGdQvn6I9r9Xg9i6z3lM3VK/Pwjt
T5i6eRpPyj+UO/uv9Vs/5a3f1XDGb8tbMyAm5c6iyv1NnVhhK4YrML4zHY6D7SHu+dbvZTlp
6oLnFYgzKF8/RPvfq0Fs3ec8pm6p3x+EtiBMXVCPm5Q7qW79TL35/r6bqROSZmzumXrPVxTz
m6LYeU3H6QpT97zvD0L7E6Zunh43KXdS3fqZevOnuZupE5JmbO6Zes9XFPOboth5TcfpClP3
vO8PQlsQpi4ob/qczEb7+lRO+lzCpLyv2T6pwtPEcFdQI7PhxDlt6nypktftjnkohKmzLba3
fllTFz4vb5zRkDz9EOt/r8Kmzhf/VJx3SL/M+P3Rx1nLtqLrihk3LiK0TmHq5smbPiez0U5a
OelzCZPyvmb7pApPE8NdQY3MhhPntKnzpUpetzvmoRCmzrbY3vplTV34vLxxRkPy9EOs/70K
mzpf/FNx3iH9MuP350PNWrYVXVfMuHERoaUIU+dT+EEXTqbi0bQbZa5jt92WFC8Ba6s9Gln/
61G9Ohl0fWbd5O1Mw3a7KbtWno0JVXVTeZnmpz6FCen64fXT9DeDBc4rGGdM/n7w9v9UDUo7
n4Pxh+JMjn+R359EU2eO3FCHNixM3aTCD7pwMhXF/WZucSNKipeAtdUqI+t/UeqlkJPvPrNu
8namYbvdlN0oz8aEqrqpvEzzU+/ChHT98KJNfzNY4LyCccbk7wdv/0/VoD6cz8H4Q3Emx7/I
70+iqTNv3FCHViVMHZqrGStjaCvSarSAidCGhKlDN2nGyhjaiowaLWAitGhh6tBcYer2I/vg
zfyRIPQQYerQTcLU7Uf2wZv5I0FopjB1aIb6fD9uskIIrV+YOpSqPt+Pm6wQQksUpg4hhNDO
hKlDCCG0LWHqEEII7UyYOoQQQtvSL0zdDwAAwAq5bfADAADYEpg6AABYMXkHUQAAgCWAqQMA
gBWTdxAFAABYApsydZfToSiqc+4wAADgaeQdRB9NrcuiUCZ3GAAAsHA2Zep+fn4upwOuDgBg
P+QdRJ9ArUtcHQAAxNmaqfs5V5g6AID9kHcQfQZGYeoAACAOpg4AAFZM3kH0GWDqAABgCkwd
AACsmLyD6DPA1AEAwBSbM3U/l9OBh6UAAOyFvIPoU6h1ycNSAAAgxuZMHSt1AAB7Iu8g+gxY
qQMAgCkwdQAAsGLyDqLPAFMHAABTYOoAAGDF5B1EnwGmDgAAptiaqeM9dQAAuyLvIPoEeE8d
AABMsilTdzkdisPpkjsMAAB4GnkH0UdT67IodZ07DAAAWDibMnUAALA38g6iAAAASwBTBwAA
KybvIAoAALAEMHUAALBi8g6iAAAASwBTBwAAKybvIAoAALAEMHUAALBi8g6iAAAASwBTBwAA
KybvIAoAALAEMHUAALBi8g6iAAAAS2BTpu5crfvF42uPHwDg+eQdRB+NUet+8fja4wcAWAuY
ugWx9vgBAJ5P3kH00azdFK09fgCAtbAVU3c5HQqHw+kid7Q/dj+cqqIoDqdzd5Qt/vPz83Ou
RrVEGZc/V0VRVFVVFEVRna/7q/N1h6/dxPhtVO2GWVECAGySvIPoA6l16Y4Lpa7ljvbH7get
iqIotemOssWbpmmMGtUSZVzeqKIolFJFURTKXPcrc93hazcxfhtVu2FWlAAA0LEVU/fz8xNa
6bqcDmJzV6Y1Xuduc9FtFx6p3xxp1Fv+XLVey/7bRRFqNzV+uw9TBwC7Ju8g+mj8K121LsXm
rkxrvEy3uei2C4/Ub4406i1vVOu17L9dFKF2U+O3+zB1AADJ7MDUSd91OVXWAA392vVgsex2
Je7qQuVtLLZtaep87SbHDwAAP/s0ddJ31VpZAzT0a9eDxbLblbirC5W3sdi2panztZscPwAA
3MwuTF3nqGQBZ4XtR5i6tHWvUPmIqfO2mxw/AAD87NXUdY5KFnBW2Bph6tLWvULlI6bO225y
/AAAcDMbM3UHsQ7nLIidq+rsLnOdKydvUaZlJjmnQPnYSp233dT4f37IvgQA2LypK8U6nLMg
ZpQy7jKXUU7eokzLTHJOgfKxlTpvu6nxNw3ZlwAAN7IpUyceNzIyOpfTYZj2eH1eyugA96El
05ZpXN7mZFZn+2iUS1uoOkfaTYu/PQcsHQDsnLyD6MOpvQ8+6XYN0h6vz0sZHeA+tGTaMo3L
25xMZeyjUeq2kDKRdtPib88BSwcAcAPbMnURRstcqXmW9+LGdn130w2X8wAA9kfeQTQno2Wu
1DzLe3Fju7676YbLeQAAMI+9mLrx3WjrMnW+u+nsgzUBAHZM3kE0I+O70dZl6nx309kHawIA
QCJbN3VOamRvgfpnVj7XFiW3G4gfAABa8g6iGXBSI3sL1D+z8rm2KLndQPwAAPAbtm7qAABg
0+QdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABg
xeQdRAEAAJbAJk3d5XTgUZEAALsg7yD6LGpd8qhIAAAIsklT9+N/V/dj2zvMd5G+l87dUg8A
AOQdRJ+I713dj22vnO8ifS+du6UeAAC4DUxdBiKmDgAAksg7iD6RZ5u6JCKmDgAAnsCWTF3/
Zu/qLE1dv32QkykOqCqxS7zxu9/RbjycLnavPWD4c1fz4XTuKhoW9kTkq2cYZ7evLVxVdg8u
EQB2St5B9MH0b/ZWRpq6fvsgJ1McoJTYJd743e9oN5a6tnvtAcOfu5pLbbqKhoU9EfnqGcbZ
7WsLK2X34BIBABLYjKmTeYvOPXVnadfOVW9/xI7L6eDYrq6M3PHTWal27/ksjZTTzLWpQjYm
fFdspc5Xz0H6U2/Qo6MAAHZC3kH0kci8ReeeOiPtmlG9/RE7al06tqsrI3c0nZVq9xpjS42a
uTZVyMaE74qt1PnqKaU/9QY9OgoAACJsxdQN0y07lyOW6YaLWnLVTGyM5G1GdvrMWOW6PuHw
5pu6Ydk+hMvpIE+FtToA2CV5B9EHMky37FyOWKYbLmrJVTOxMZK3GdnpM2OOdRNOLsXUDcv2
IdS6lKfCWh0AwGx2YOrmrGH163x3NHVBd4apAwC4F3kH0QcSMXVz1rD6db47mrqgO8PUAQDk
ZSumzrU1bmai/4az8+AuOpF+OUi4lPUmrdQVTuKnTL/sdpyrYrigFzWHIgJMHQDAhk2da2vc
zET/DWdmcBedSL8cJFzKepNW6gon8VOmX3Y7jCqGC3pRcygiwNQBANzKZkzdIJvyJG6rcx9O
IsyeLydzuMvuGD7hJLS9v+WuOpxOgUe0XEYPUAnXM4j0urUrXp2dzwAAOyPvIPpYnGxKLW6r
cx9OIsyeYGCsxjuGTzgJbe9vuVOl1oFHtNSjB6iE6xlEet3aFVfG+QwAADPYkKlbGDy7BADg
CeQdRHcFzy4BAFgsmLpHgakDAHgCeQfRXYGpAwBYLJi6h+B5sxwAADyAvIPofvC8WQ4AABYD
pg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYA
pg4AAFZM3kEUAABgCWzI1LXv4K7O7aMneerkhvnd6yI2+rIJ+w764cmFtsfr4fcI1kPeQfSx
tO/gVqZ99CRPndwwv3tdxEZfNmHfQT88udD2eD38HsHW2ZCp+zlX7Rz0cjoURXX+sfNTOS+d
O1G9nA7zp7PnqjrfGHNu7Izf8qgTSerP2XWFr2/0vC6nw8IvWPtKjOuJde/HmNODIcea4GTH
v0cAiybvIPpgjGrnoLUui0KZxs5P5bx07kS11uX86axRytwUcX7sjN/yqBNJ6s/ZdYWvb/S8
al0u/IK1r8S4nlj3fow5PRhyrAlOdvx7BLBBtmbqqnM71e9msOfqcKjsD5fTQfx0x4bXPPW9
nPoeuZwOi5/Gu5YsfH0j53VPi/koztXh0J+oPJmpw+5h6ka/RwDLJe8g+mCMauegtS77+a9R
ZansD7UuxU93bHjNU99a9z1S63Lx03jXkoWvb+S87mkxH4VRZdmfqDyZqcPuYepGv0cAW2NL
pq6bqp+rfgZ/rqqTnRBfTof+B7lI5Uxdvelq15y0yi6a2PqHK0LyqP4N5P3WUD2heCLlnSOq
qhI+1hdNpNscv3D2VSTXjK7BVOfrbk9X3N6f0wwMWez6hs4rwdWlXa9o/yRel3NVnXv/ak+m
beEs2h/03B1Mnff3SJ4zTg+WRd5B9MF0U3Wj+hm8UUrbCXGty/4HuUjlTF296WrXnDRlF01s
/cMVIXlU/wbyfmuonlA8kfLOEUop4WN90US6zfELxleRXDO6BqPMdbenK27vz2kGhix2fUPn
leDq0q5XtH8Sr4tRyvT+1Z5M24IR7Q967g6mzvt7JM8ZpwdbYEumzks7N65Ol+u8tp/qX87n
S1do5CrGk2C5cOHu9a7UOUVkA6F6QvEEyjuLT6JMsN0QA/NjjcS5EpP3/gf7yf4rfMfd+jMe
rbuWGLm+/vMKRhhrcf71CvZP6nVpv1T2KHEy8ts2TiS9g6mLgKmDJZJ3EM1BOzdWur7Oa/up
fm1M3RUauYrxJFguXLh7vSt1ThHZQKieUDyB8s7ikygTbDfEwPxYI2GUmLz3P9hP9l/hO+7W
n/Fo3bXEyPX1n1cwwliL869XsH9Sr0v7pbJHiZOR37ZxIukdTF0ETB1sh12YunZK3E5rL76V
umK8VOQ1IdJEOQ5hPEMXyzKDFkL1hOLxlw/l44XbDeE3P8Nz6peKXI8iI7pXf8ajddfYYtc3
buoSbGTC9Qr1T/J1cStaiKkDWCJ5B9EcGKVMOyVup7W1b6XOs1TkNSHSRDkOYTxDF8sygxZC
9YTi8ZcP5eOF2w3hNz/Dc+qXilyPIiO6V3/Go3XX2GLXN27qEmxkwvUK9U/ydXErWoipA9gO
+zB1zrNTujy22Nz4DqYuNIn21xOOJ9XUpU7e/WmKqabunv0Zj3a8Uue7vvH0y8SVuoTrFe6f
xOvSXYDL6XA4nTF1ACHyDqI5aKfA8tkpXR5bbG58B1MXmkT76wnHk2rqUifv/jTFVFN3z/6M
RzteqfNd33j6ZeJKXcL1CvdP4nXpLkCty1IbTB3AfdmJqevpzYmTXPjLlTrnNjQ7qw/YhpBJ
CMUTaNddsuq9ToJdsYdWTj2egEShOablt/05Ee7wnjrv9Q2el6+SqQYTrldwJTP1uogTc5/v
07csbrATh6WYunM1Zy23g+xLWCR5B9EchM2Jk1z4y5U65zY0O6sP2IaQSQjFE2jXXbLqvU6C
XbGHKqceT0Ci0BzT8tv+nAh3eE+dcXd7Td2ggZQnpaRdr+BKZup1ESfmPt+nb1ncYCcOSzF1
Rs1Zy+0g+xI2xLZN3dl9voXzbHj5nIuqOhTdSs/gySeDzdXZ+dzSH+QaIVlVN8cP1OOPJ9qu
TOnzP8Fjcgo+Ol03RXGw3W6p+peYXexbze7Zn1GcZTEnanF9z5HzSvF0adcr1j9J12X4FoPh
DY7uaTpflMEZh7bLqmabOvuyA4BFkXcQfTrGfb6F82x4+ZwLpcqiW+kZPPlksFkZ53NLf5Br
hGRV3Rw/UI8/nmi7MqVPTMx97YYYna6bojjYbrco07jvDpDR3aE/ozjLYk7U4vqayHmleLq0
6xXrn6TrMnyLwfAGR/c0nS/K4IxD22VVs02dfdkBwAbYtqmDLfLrFxIkrAuCwLcCC5CfvIMo
wB349QsJEtYFQeBbgQVYK5g6WB+/u0GM28tuI+HhMgDPJO8gCnAXfneDGLeX3UbCw2UAls//
A+21LnPe8xT6AAAAAElFTkSuQmCC
--------------FC398B92878038616A71D06D--

--------------6F096081234516D0BFD2715F--


From nobody Thu Jan 25 03:59: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 82CAE12DA24 for ; Thu, 25 Jan 2018 03:59:44 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 HHTS1scNTuEp for ; Thu, 25 Jan 2018 03:59:43 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA77F12DA23 for ; Thu, 25 Jan 2018 03:59:42 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 944046BA; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id E97C9fIb-U7F; Thu, 25 Jan 2018 12:59:40 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BD3F20149; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NoOK7_EjoUDK; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F68920147; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 21CF242295C3; Thu, 25 Jan 2018 12:59:41 +0100 (CET)
Date: Thu, 25 Jan 2018 12:59:41 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Cc: NETMOD Working Group 
Message-ID: <20180125115941.tmfquapklprdw2d3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Benoit Claise , NETMOD Working Group 
References:  <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 11:59:44 -0000

On Thu, Jan 25, 2018 at 12:20:11PM +0100, Benoit Claise wrote:
 
> PROPOSAL (replacing the previous paragraph)
> 
>        If YANG tree diagrams are used, then a normative reference to the
>        YANG tree diagrams specification MUST be provided. As an example guideline
>        (from https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
>        here is a subsection in the terminology section

The current practice is that the tree diagrams reference is an
informative reference and not a normative reference.

/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 Jan 25 04:20: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 9447C1242F7 for ; Thu, 25 Jan 2018 04:20:34 -0800 (PST)
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_RP_MATCHES_RCVD=-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 q2_6_eo6LlBU for ; Thu, 25 Jan 2018 04:20:33 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A2E12025C for ; Thu, 25 Jan 2018 04:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=669; q=dns/txt; s=iport; t=1516882832; x=1518092432; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=OIoqFNZYn1vdodspCCzXZL5DVf0QYifxorM+h/yas/k=; b=VEV6GxjO3o1nV9SCrdSB2DfAx/WjX1aAxXxX5obxYILXN9GqZ+t1emOm v1Hsc8I7dbVXJuq7u7sHcJVAxEAGhmdic4zh92dEE+JYATO92bGRtzmhk Fe9uj94mDtHvaFnW3I0d2o4qWJnFbwrNL8JFBB5iAZz7CMOPVr6SZzLE4 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQCqomla/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj08nmVoKI4UYAoU1FAEBAQEBAQEBAmsohSQBBSM?= =?us-ascii?q?PAQVRCxgCAiYCAlcGDQgBAYoxELUggieKYAEBAQEBAQEBAgEBAQEBAQEcBYEPg?= =?us-ascii?q?0KDbIFoKQyCeYMvAQECAYUFgmUFpAmIFY1NggKKKYd6jVqBa4gTgTw2IoFQMxo?= =?us-ascii?q?IGxWCaIRXQDcBjkoBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,411,1511827200";  d="scan'208";a="1594226"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 12:20:30 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0PCKU7N020406 for ; Thu, 25 Jan 2018 12:20:30 GMT
To: NETMOD Working Group 
References:  <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <20180125115941.tmfquapklprdw2d3@elstar.local>
From: Benoit Claise 
Message-ID: <73ced326-63fa-2305-f425-d7bd919c58df@cisco.com>
Date: Thu, 25 Jan 2018 13:20:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180125115941.tmfquapklprdw2d3@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 12:20:35 -0000

On 1/25/2018 12:59 PM, Juergen Schoenwaelder wrote:
> On Thu, Jan 25, 2018 at 12:20:11PM +0100, Benoit Claise wrote:
>   
>> PROPOSAL (replacing the previous paragraph)
>>
>>         If YANG tree diagrams are used, then a normative reference to the
>>         YANG tree diagrams specification MUST be provided. As an example guideline
>>         (from https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
>>         here is a subsection in the terminology section
> The current practice is that the tree diagrams reference is an
> informative reference and not a normative reference.
Good catch Jürgen.

Regards, Benoit
>
> /js
>


From nobody Thu Jan 25 04:45: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 C9E9C1242F7 for ; Thu, 25 Jan 2018 04:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 oJcsN9fcBagH for ; Thu, 25 Jan 2018 04:45:18 -0800 (PST)
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 0E02E1201F2 for ; Thu, 25 Jan 2018 04:45:18 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0PCj9cA020935; Thu, 25 Jan 2018 04:45:15 -0800
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 : mime-version; s=PPS1017; bh=+VDMrCsME+ib3tGbIA7rMJZVBKPlM0Zbi3fyIibZXXY=; b=EpW9nXk/e4nWFaurNNA81yS/+JqgIppEpV2P0T+a563J5JIZkxXFNymJ2LOwratonowN oD1XgEWpvrdqnwCgLcOmT3JFwwG8YHHoSZeAbEutHUg9m9zAXKLZAJyFpwWKlX/FyYw9 ortzDHWjEdavn7FMboLF14v/T2lZZk/OqzgPXEAeNOIGgTQ0JnA4Fzrvt2J04NS4Xw4Q EBnCKar/bRxFkWXt5sziYODgHZbKl8GOAoP341f215EP8SP6VeADsx+aFwkH6CE283hf vp0VXyaWRlZuclYWPx6GjkklcpBHXHMfWjeKsxkXkSDC1j+MAlxUJPCItRkEJnvtbe85 3w== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0047.outbound.protection.outlook.com [207.46.163.47]) by mx0a-00273201.pphosted.com with ESMTP id 2fqfh1000p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 04:45:14 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3371.namprd05.prod.outlook.com (10.174.191.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Thu, 25 Jan 2018 12:45:13 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.006; Thu, 25 Jan 2018 12:45:13 +0000
From: Kent Watsen 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
Thread-Index: AQHTlc5/jPHFjNSqUUC1y3CP53NHm6OENUCA
Date: Thu, 25 Jan 2018 12:45:12 +0000
Message-ID: <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net>
References:  <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com>
In-Reply-To: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3371; 7:Yk0m5HV0SV0OUKgYz3kKofpx4j6C3YExksy6bc32pwAAPWW9OWsOnoJrLBfUytvFSRud5bGsPrlK1qcxIGXZkLH86ek2aT8YEkgLEF4RN0R7mJR1JXzok1bZAkX3wS8+lD0unkmnRMl6+o6Eo0y03bSme9mKGQX9TfB+J8MyDBG/uOiKOHwDI0nZCvZcuteR0cGrAoU+BL4eQKvPUeJgRWDqlLP8XlLOBFf5aHo6MGn1q2aKg9ViERxzk2E0zFDj
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8df33f19-d79b-4cbd-f479-08d563f17a28
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:DM5PR05MB3371; 
x-ms-traffictypediagnostic: DM5PR05MB3371:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(120809045254105)(166708455590820)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(2400081)(944501161)(10201501046)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3371; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3371; 
x-forefront-prvs: 0563F2E8B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(39380400002)(376002)(15374003)(377424004)(189003)(199004)(2906002)(83716003)(99286004)(186003)(478600001)(230783001)(83506002)(966005)(25786009)(316002)(105586002)(6246003)(33656002)(7736002)(66066001)(106356001)(58126008)(110136005)(86362001)(82746002)(36756003)(236005)(6512007)(54556002)(76176011)(54896002)(6306002)(2950100002)(53936002)(3846002)(6486002)(6116002)(6436002)(8676002)(5660300001)(26005)(77096007)(3660700001)(733005)(59450400001)(81156014)(81166006)(3280700002)(102836004)(345774005)(6506007)(99936001)(53546011)(606006)(68736007)(14454004)(2900100001)(8936002)(97736004)(561944003)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3371; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 7cPE3n8cjEH03zrw/6+wV/DCbtYkX8wc5RerBm4qc624FvY6EKmQOFoL5xIuf307xlx2xW/H+T7lKcgOyi5M5w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_004_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8df33f19-d79b-4cbd-f479-08d563f17a28
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 12:45:13.0253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3371
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250173
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 12:45:22 -0000

--_004_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_
Content-Type: multipart/alternative;
	boundary="_000_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_"

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

SSBzZWUgYSBsb3Qgb2Ygc3VnZ2VzdGlvbnMgdG8gcmVmZXJlbmNlIG90aGVyIGRyYWZ0cyBhcyBl
eGFtcGxlcy4gIEkgd291bGQgZGlzY291cmFnZSBkb2luZyB0aGF0LiAgSSByZWNvbW1lbmQgdGhp
cyBkcmFmdCBjbGVhcmx5IHN0YXRpbmcgdGhlIGRlc2lyZSwgaW5jbHVkaW5nIGl0cyBvd24gZXhh
bXBsZXMgaWYgbmVlZGVkLg0KDQpSZWdhcmRpbmcgcmVmZXJlbmNpbmcgdGhlIHRyZWUtZGlhZ3Jh
bXMgZHJhZnQsIEkgZG9uJ3QgYWdyZWUgdGhhdCBoYXZpbmcgYSAiVHJlZSBEaWFncmFtcyIgc2Vj
dGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uIGlzIGJldHRlciB0aGFuIGFuIGlubGluZSByZWZlcmVu
Y2Ugd2hlcmUgdXNlZDoNCjEpIHRoZSB0ZXJtICJ0cmVlIGRpYWdyYW0iIGlzIG5vdCBhbnl3aGVy
ZSBkZWZpbmVkDQoyKSBzZWN0aW9ucyBoYXZpbmcgdHJlZSBkaWFncmFtcyBoYXZlIHRvIHJlZmVy
ZW5jZSB0aGUgc2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uLCBhbmQgd2h5IHJlZmVyZW5jZSB0
aGUgSW50cm8gc2VjdGlvbiB3aGVuIGl0J3MganVzdCBhcyBlYXN5IHRvIHJlZmVyZW5jZSB0aGUg
ZHJhZnQ/DQozKSBpdCBtYWtlcyB0aGUgSW50cm9kdWN0aW9uIGFuZCBUYWJsZSBvZiBDb250ZW50
cyB1bm5lY2Vzc2FyaWx5IGJ1c3kNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQpPbiAxLzI1LzE4
LCA2OjIwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlIiA8bmV0bW9kLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2YgYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6DQoN
CkRlYXIgYWxsLA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgaW1wb3J0YW50IGRvY3VtZW50Lg0KSSd2
ZSBiZWVuIHNwZW5kaW5nIHF1aXRlIHNvbWUgdGltZSB0cnlpbmcgdG8gcmVsYXkgZmVlZGJhY2sg
c2VlbiBvbiBtdWx0aXBsZSBmcm9udHMuDQpUaGlzIGlzIHBhcnQgMSBvZiB0aGUgcmV2aWV3LCB0
aWxsIHNlY3Rpb24gNC4yMQ0KDQoNCi0NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2V0
IG9mIHVzYWdlIGd1aWRlbGluZXMgZm9yIFN0YW5kYXJkcyBUcmFjaw0KDQogICBkb2N1bWVudHMg
Y29udGFpbmluZyBbUkZDNzk1MDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNzk1MCZkPUR3TURhUSZjPUhB
a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK
OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpOa2J1YklY
aXdQRGpfVWtfcVl4cXlMQV9tYyZzPXQ4ZnNoU3BlMERoaDV1VEU4c1JOZ1NYb0xUa1ktNC1ubGVQ
YVljMU15MEEmZT0+XSBkYXRhIG1vZGVscy4NCg0KDQoNClRoaXMgaXMgbm90IGlubGluZSB3aXRo
Og0KDQogICBUaGlzIHNlY3Rpb24gY29udGFpbnMgdGhlIG1vZHVsZShzKSBkZWZpbmVkIGJ5IHRo
ZSBzcGVjaWZpY2F0aW9uLg0KDQogICBUaGVzZSBtb2R1bGVzIFNIT1VMRCBiZSB3cml0dGVuIHVz
aW5nIHRoZSBZQU5HIDEuMSBbUkZDNzk1MDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNzk1MCZkPUR3TURh
USZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpO
a2J1YklYaXdQRGpfVWtfcVl4cXlMQV9tYyZzPXQ4ZnNoU3BlMERoaDV1VEU4c1JOZ1NYb0xUa1kt
NC1ubGVQYVljMU15MEEmZT0+XSBzeW50YXguDQoNCiAgIFlBTkcgMS4wIFtSRkM2MDIwPGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0
Zi5vcmdfaHRtbF9yZmM2MDIwJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh
SmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJnM9TDhM
Wm9oVVdaUUhnQ2M2OXRTSDc4dzNtbWVCRjdacEVhWUdmRFBZZjUtOCZlPT5dIHN5bnRheCBNQVkg
YmUgdXNlZCBpZiBubyBZQU5HIDEuMSBjb25zdHJ1Y3RzIG9yDQoNCiAgIHNlbWFudGljcyBhcmUg
bmVlZGVkIGluIHRoZSBtb2R1bGUuDQoNCg0KDQpTbyBpdCBzaG91bGQgYmUgY2hhbmdlZCB0bw0K
DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzZXQgb2YgdXNhZ2UgZ3VpZGVsaW5lcyBmb3Ig
U3RhbmRhcmRzIFRyYWNrDQoNCiAgIGRvY3VtZW50cyBjb250YWluaW5nIFlBTkcgMS4xIFtSRkM3
OTUwPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
dG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3OTUwJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxB
X21jJnM9dDhmc2hTcGUwRGhoNXVURThzUk5nU1hvTFRrWS00LW5sZVBhWWMxTXkwQSZlPT5dIGFu
ZCBZQU5HIDEuMCBbUkZDNjAyMF0gZGF0YSBtb2RlbHMuDQoNCg0KDQpTaW1pbGFybHkgaW4gc2Vj
dGlvbiA0DQoNCk9MRDoNCg0KDQoNCiAgIE1vZHVsZXMgaW4gSUVURiBTdGFuZGFyZHMgVHJhY2sg
c3BlY2lmaWNhdGlvbnMgTVVTVCBjb21wbHkgd2l0aCBhbGwNCg0KICAgc3ludGFjdGljIGFuZCBz
ZW1hbnRpYyByZXF1aXJlbWVudHMgb2YgWUFORyBbUkZDNzk1MDxodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZj
Nzk1MCZkPUR3TURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pv
Q0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJR
UUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtfcVl4cXlMQV9tYyZzPXQ4ZnNoU3BlMERoaDV1VEU4
c1JOZ1NYb0xUa1ktNC1ubGVQYVljMU15MEEmZT0+XS4NCg0KDQoNCk5FVzoNCg0KICAgTW9kdWxl
cyBpbiBJRVRGIFN0YW5kYXJkcyBUcmFjayBzcGVjaWZpY2F0aW9ucyBNVVNUIGNvbXBseSB3aXRo
IGFsbA0KDQogICBzeW50YWN0aWMgYW5kIHNlbWFudGljIHJlcXVpcmVtZW50cyBvZiBZQU5HIDEu
MSBbUkZDNzk1MDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNzk1MCZkPUR3TURhUSZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtf
cVl4cXlMQV9tYyZzPXQ4ZnNoU3BlMERoaDV1VEU4c1JOZ1NYb0xUa1ktNC1ubGVQYVljMU15MEEm
ZT0+XS4gU2VlIHRoZSBleGNlcHRpb24NCg0KICAgZm9yIFlBTkcgMS4wIGluIHNlY3Rpb24gMy42
DQoNCg0KDQpOb3RlIHRoYXQgSSB0cmllZCB0byBhZGQgc29tZSBuZXcgdGV4dCBhcm91bmQgdGhl
IGZvbGxvd2luZyBzZW50ZW5jZSBidXQgdGhhdCBwYXJhZ3JhcGggYmVjYW1lIGNsdW1zeS4NCg0K
ICAgQWx0ZXJuYXRpdmVseSwNCg0KICAgaWYgWUFORyAxLjAgaXMgdXNlZCwgdGhlbiBNb2R1bGVz
IGluIElFVEYgU3RhbmRhcmRzIFRyYWNrIHNwZWNpZmljYXRpb25zDQoNCiAgIE1VU1QgY29tcGx5
IHdpdGggYWxsIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMgcmVxdWlyZW1lbnRzIG9mIFlBTkcgMS4w
IFtSRkM2MDIwXS4NCg0KDQoNCkZpbmFsbHksIGluIHNlY3Rpb24gMy42LCBJIHdvdWxkIGFkZCBh
IHNlbnRlbmNlIHRvIHRoaXMgcGFyYWdyYXBoDQoNCiAgIFRoaXMgc2VjdGlvbiBjb250YWlucyB0
aGUgbW9kdWxlKHMpIGRlZmluZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uDQoNCiAgIFRoZXNlIG1v
ZHVsZXMgU0hPVUxEIGJlIHdyaXR0ZW4gdXNpbmcgdGhlIFlBTkcgMS4xIFtSRkM3OTUwPGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0
Zi5vcmdfaHRtbF9yZmM3OTUwJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh
SmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJnM9dDhm
c2hTcGUwRGhoNXVURThzUk5nU1hvTFRrWS00LW5sZVBhWWMxTXkwQSZlPT5dIHN5bnRheC4NCg0K
ICAgWUFORyAxLjAgW1JGQzYwMjA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzYwMjAmZD1Ed01EYVEmYz1I
QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpH
SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJ
WGl3UERqX1VrX3FZeHF5TEFfbWMmcz1MOExab2hVV1pRSGdDYzY5dFNINzh3M21tZUJGN1pwRWFZ
R2ZEUFlmNS04JmU9Pl0gc3ludGF4IE1BWSBiZSB1c2VkIGlmIG5vIFlBTkcgMS4xIGNvbnN0cnVj
dHMgb3INCg0KICAgc2VtYW50aWNzIGFyZSBuZWVkZWQgaW4gdGhlIG1vZHVsZS4NCg0KDQoNClRo
ZSBzZW50ZW5jZSBzdWNoIGFzOg0KDQogICBpZiBhbnkgdGhlIGltcG9ydGVkIFlBTkcgbW9kdWxl
cyBpcyBiYXNlZCBvbiBZQU5HIDEuMSwgdGhlIG1haW4gWUFORw0KDQogICBtb2R1bGUgTVVTVCBh
bHNvIGJlIHdyaXR0ZW4gaW4gWUFORyAxLjEuDQoNCg0KDQogLSBzZWN0aW9uIDMsIGVkaXRvcmlh
bDoNCg0KICAgVGhlcmUgYXJlIHRocmVlIHVzYWdlIHNjZW5hcmlvcyBmb3IgWUFORyB0aGF0IGNh
biBhcHBlYXIgaW4gYW4NCg0KICAgSW50ZXJuZXQtRHJhZnQgb3IgUkZDOg0KDQoNCg0KICAgbyAg
bm9ybWF0aXZlIG1vZHVsZSBvciBzdWJtb2R1bGUNCg0KDQoNCiAgIG8gIGV4YW1wbGUgbW9kdWxl
IG9yIHN1Ym1vZHVsZQ0KDQoNCg0KICAgbyAgZXhhbXBsZSBZQU5HIGZyYWdtZW50IG5vdCBwYXJ0
IG9mIGFueSBtb2R1bGUgb3Igc3VibW9kdWxlDQoNCg0KDQogICBUaGUgZ3VpZGVsaW5lcyBpbiB0
aGlzIGRvY3VtZW50IHJlZmVyIG1haW5seSB0byBhIG5vcm1hdGl2ZSBjb21wbGV0ZQ0KDQogICBt
b2R1bGUgb3Igc3VibW9kdWxlLCBidXQgbWF5IGJlIGFwcGxpY2FibGUgdG8gZXhhbXBsZSBtb2R1
bGVzIGFuZA0KDQogICBZQU5HIGZyYWdtZW50cyBhcyB3ZWxsLg0KDQoNCg0KRWl0aGVyIGFkZCAi
Y29tcGxldGUiIHRvICJvICBub3JtYXRpdmUgbW9kdWxlIG9yIHN1Ym1vZHVsZSkiIGFuZCBiZSBj
b25zaXN0ZW50IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50LA0KDQpvciByZW1vdmUgaXQgZnJvbSB0
aGUgbGFzdCBzZW50ZW5jZS4NCg0KDQoNCg0KDQotIHNlY3Rpb24gMy4yDQoNCg0KDQogICBUaGUg
IjxDT0RFIEJFR0lOUz4iIHRhZyBTSE9VTEQgYmUgZm9sbG93ZWQgYnkgYSBzdHJpbmcgaWRlbnRp
ZnlpbmcNCg0KICAgdGhlIGZpbGUgbmFtZSBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjIgb2YgW1JG
Qzc5NTBdPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3OTUwLTIzc2VjdGlvbi0yRDUuMiZkPUR3TURhUSZj
PUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2
WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpOa2J1
YklYaXdQRGpfVWtfcVl4cXlMQV9tYyZzPW9RWTZsaGhqUnVPRVl5X05mLTdIRzZfLWVNZ3dYN3ha
ZzRWS05Iam5UTWMmZT0+LiAgVGhlIG5hbWUgc3RyaW5nDQoNCiAgIGZvcm0gdGhhdCBpbmNsdWRl
cyB0aGUgcmV2aXNpb24tZGF0ZSBTSE9VTEQgYmUgdXNlZC4gIFRoZSBmb2xsb3dpbmcNCg0KICAg
ZXhhbXBsZSBpcyBmb3IgdGhlICcyMDEwLTAxLTE4JyByZXZpc2lvbiBvZiB0aGUgJ2lldGYtZm9v
JyBtb2R1bGU6DQoNCg0KDQogICA8Q09ERSBCRUdJTlM+IGZpbGUgImlldGYtZm9vQDIwMTYtMDMt
MjAueWFuZyI8bWFpbHRvOmlldGYtZm9vQDIwMTYtMDMtMjAueWFuZz4NCg0KDQoNCkkgd291bGQg
YWRkIHRoYXQgYm90aCByZXZpc2lvbiB2ZXJzaW9ucyAob24gdGhlIDxDT0RFIEJFR0lOUz4gYW5k
IGluIHRoZSBtb2R1bGUpIE1VU1QgbWF0Y2guDQoNCkkgcmFuIGludG8gYWxsIHNvcnQgb2YgdG9v
bGluZyBpc3N1ZXMgYmVjYXVzZSBvZiBzdWNoIGRpc2NyZXBhbmNpZXMuDQoNCg0KDQotIHNlY3Rp
b24gMy4yLjENCg0KQWRkICJzZWUgc2VjdGlvbiA0LjkgcmVnYXJkaW5nIHRoZSBuYW1lc3BhY2Ug
Z3VpZGVsaW5lcyBmb3IgZXhhbXBsZSBtb2R1bGVzIg0KDQoNCg0KLSBUaGUgZm9sbG93aW5nIGlu
IHBhcmFncmFwaCBpbiBzZWN0aW9uIDMuMyBzZWVtcyBtaXNwbGFjZWQuDQoNCiAgIElmIFlBTkcg
dHJlZSBkaWFncmFtcyBhcmUgdXNlZCwgdGhlbiBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gdGhl
DQoNCiAgIFlBTkcgdHJlZSBkaWFncmFtcyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgcHJvdmlkZWQg
Zm9yIGVhY2ggZGlhZ3JhbS4NCg0KICAgKFJlZmVyIHRvIHRoZSBleGFtcGxlIGluIHRoZSBuZXh0
IHNlY3Rpb24uKQ0KSXQgc2hvdWxkIGJlIGluIHNlY3Rpb24gMy40Lg0KQnR3LCBubyBuZWVkIHRv
IGhhdmUgdGhlIHNwZWNpZmljYXRpb25zIGZvciBlYWNoIGRpYWdyYW0hDQpBbHNvLCB3ZSB3YW50
IHRvIGFkZCBzb21lIGd1aWRlbGluZXMgb24gaG93IHRvIHJlZmVyZW5jZSB0aGUgdHJlZSBkaWFn
cmFtIGNvbnZlbnRpb24NCkZvciBleDogbm8gbmVlZCB0byBjb3B5IG92ZXIgdGhlIGNvbnZlbnRp
b25zDQpCYXNpY2FsbHksIHdlIGp1c3QgbmVlZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMjc2VjdGlvbi0xLjM8aHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o
dG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJmYzcyMjNiaXMtMkQwMy0yM3NlY3Rpb24tMkQx
LjMmZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJ
JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUx0TzJSUVFJ
ZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmcz1RbG5yYm5HWkVvLXpRWXpHOUFX
azg2YV9tMjJJY3BCbkdRa2V3RVdIYXhRJmU9Pg0KDQpQUk9QT1NBTCAocmVwbGFjaW5nIHRoZSBw
cmV2aW91cyBwYXJhZ3JhcGgpDQoNCiAgIElmIFlBTkcgdHJlZSBkaWFncmFtcyBhcmUgdXNlZCwg
dGhlbiBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gdGhlDQoNCiAgIFlBTkcgdHJlZSBkaWFncmFt
cyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgcHJvdmlkZWQuIEFzIGFuIGV4YW1wbGUgZ3VpZGVsaW5l
DQoNCiAgIChmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1v
ZC1yZmM3MjIzYmlzLTAzI3NlY3Rpb24tMS4zPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYt
MkRuZXRtb2QtMkRyZmM3MjIzYmlzLTJEMDMtMjNzZWN0aW9uLTJEMS4zJmQ9RHdNRGFRJmM9SEFr
WXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5
RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhp
d1BEal9Va19xWXhxeUxBX21jJnM9UWxucmJuR1pFby16UVl6RzlBV2s4NmFfbTIySWNwQm5HUWtl
d0VXSGF4USZlPT4pLA0KDQogICBoZXJlIGlzIGEgc3Vic2VjdGlvbiBpbiB0aGUgdGVybWlub2xv
Z3kgc2VjdGlvbg0KDQoNCg0KICAgVHJlZSBEaWFncmFtcw0KDQoNCg0KICAgVHJlZSBkaWFncmFt
cyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgZm9sbG93IHRoZSBub3RhdGlvbiBkZWZpbmVkIGluDQoN
CiAgIFtJLUQuaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zPGh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9k
cmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZmM3MjIzYmlzLTJEMDMtMjNyZWYtMkRJLTJERC5pZXRm
LTJEbmV0bW9kLTJEeWFuZy0yRHRyZWUtMkRkaWFncmFtcyZkPUR3TURhUSZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtf
cVl4cXlMQV9tYyZzPUpJZGFiUDc3Unota0FyRkY2REczTUc1WDI0X0FQdVB6b0dpZkhORWRwbVkm
ZT0+XS4NCi0gc2VjdGlvbiAzLjUNCllvdSBzaG91bGQgYWRkIGEgZ29vZCBleGFtcGxlIHRvIGls
bHVzdHJhdGUgdGhlIHNlY29uZCBwYXJhZ3JhcGggKEJhc2VkIG9uIHNvbWUgcHJldmlvdXMgZmVl
ZGJhY2ssIFlBTkcgbW9kdWxlIGRlc2lnbmVyIHdhbnRzIHRvIHdvcmsgZnJvbSBleGFtcGxlcykN
Ckkgd291bGQgc3VnZ2VzdCB0byBhZGQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDkjc2VjdGlvbi0yLjM8aHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2Ry
YWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJmYzgwMjJiaXMtMkQwOS0yM3NlY3Rpb24tMkQyLjMmZD1E
d01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXpr
UDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUx0TzJSUVFJZWdXbE40
TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmcz14dWlBUTRad3pHb0F3bnlGbUpjOUh6SWRO
N3hzcVR6WFE0NkZCTFRxZThNJmU9Pg0KDQoNCi0gc2VjdGlvbiAzLjYsIGVkaXRvcmlhbA0KT0xE
Og0KDQogIE5vdGUgdGhhdCBhbGwgWUFORyBzdGF0ZW1lbnRzIHdpdGhpbiBhIFlBTkcgbW9kdWxl
IGFyZSBjb25zaWRlcmVkDQoNCiAgIG5vcm1hdGl2ZSwgaWYgdGhlIG1vZHVsZSBpdHNlbGYgaXMg
Y29uc2lkZXJlZCBub3JtYXRpdmUsIGFuZCBub3QgYW4NCg0KICAgZXhhbXBsZSBtb2R1bGUuDQoN
Ck5FVzoNCg0KDQoNCiAgTm90ZSB0aGF0IGFsbCBZQU5HIHN0YXRlbWVudHMgd2l0aGluIGEgWUFO
RyBtb2R1bGUgYXJlIGNvbnNpZGVyZWQNCg0KICAgbm9ybWF0aXZlLCBpZiB0aGUgbW9kdWxlIGl0
c2VsZiBpcyBjb25zaWRlcmVkIG5vcm1hdGl2ZSwgYW5kIG5vdCBhbg0KDQogICBleGFtcGxlIG1v
ZHVsZSBvciBhIGV4YW1wbGUgWUFORyBmcmFnbWVudC4NCg0KDQotIHNlY3Rpb24gMy42DQoNCiAg
IEV4YW1wbGUgWUFORyBtb2R1bGVzIE1VU1QgTk9UIGNvbnRhaW4gYW55IG5vcm1hdGl2ZSB0ZXh0
LCBpbmNsdWRpbmcNCg0KICAgYW55IHJlc2VydmVkIHdvcmRzIGZyb20gW1JGQzIxMTk8aHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm
Lm9yZ19odG1sX3JmYzIxMTkmZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst
bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmcz1uX3U2
b2FWZFRXcy15NW5lNWZpMnBkZ0stVWlnVVVuZ1A3ZDh1aHNvcnhNJmU9Pl0uDQoNCg0KDQpJIGd1
ZXNzIGl0IGFwcGxpZXMgYWxzbyB0byB0aGUgImV4YW1wbGUgWUFORyBmcmFnbWVudHMiDQoNCg0K
DQotIHNlY3Rpb24gMy4xMA0KDQpNZW50aW9uIHlhbmdsaW50Lg0KDQp5YW5nbGludCB2YWxpZGF0
ZXMgeHBhdGgsIHdoaWxlIHB5YW5nIGRvZXNuJ3QuDQoNCg0KDQotIHNlY3Rpb24gMy4xMQ0KDQpZ
b3UgbWlnaHQgY29uc2lkZXIgdGhlIGFkZGl0aW9uIG9mIHh5bSBodHRwczovL2dpdGh1Yi5jb20v
eHltLXRvb2wveHltPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0zQV9fZ2l0aHViLmNvbV94eW0tMkR0b29sX3h5bSZkPUR3TURhUSZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtf
cVl4cXlMQV9tYyZzPWVVTEFmR29fQ0JWamJGWEd4NDlIUjczVVNyS1hqQ3JMLVhhQVdLZFhsS2Mm
ZT0+DQoNCg0KDQotIHNlY3Rpb24gMy4xMg0KDQptZW50aW9uIHRoYXQgdGhlIGV4YW1wbGVzIE1V
U1QgYmUgdmFsaWRhdGVkLg0KDQpQb2ludGluZyB0byB0aGUgdG9vbCB3b3VsZCBiZSBhIHdlbGNv
bWUgYWRkaXRpb24uDQoNCg0KDQotIHNlY3Rpb24gNC42LngNCg0KWW91IHNob3VsZCByZWFsbHkg
bWVudGlvbiBhIGNvbW1vbiBtaXN0YWtlIGFib3V0IHRoZSBtaXNzaW5nIGRlcml2ZWQtZnJvbS1v
ci1zZWxmKCksIGZsYWdnZWQgaW4gbWFueSBZQU5HIGRvY3RvciByZXZpZXdzOjoNCg0KW2NpZDpp
bWFnZTAwMS5wbmdAMDFEMzk1QjAuNkYxQ0ZEQjBdDQoNCllvdSBzaG91bGQgZXhwbGFpbiB0aGUg
YXBwbGljYWJpbGl0eTogaWRlbnRpdHkgYXVnbWVudGF0aW9uLg0KDQoNCg0KLSBzZWN0aW9uIDQu
NyAiTGlmZWN5Y2xlIE1hbmFnZW1lbnQiDQoNCiAgICBUaGUgc3RhdHVzIHN0YXRlbWVudCBNVVNU
IGJlIHByZXNlbnQgaWYgaXRzIHZhbHVlIGlzICdkZXByZWNhdGVkJyBvcg0KDQogICAnb2Jzb2xl
dGUnLg0KDQoNCg0KSSd2ZSBiZWVuIGNvbmZ1c2VkIGZvciBhIGxpdHRsZSwgdGhpbmtpbmcgdGhp
cyBzZWN0aW9uIHdhcyBhYm91dCB0aGUgSUVURiBkb2N1bWVudCBsaWZlY3lsZSBtYW5hZ2VtZW50
IGFuZCB0aGUgb2Jzb2xldGUgZG9jdW1lbnQgdGFnLg0KDQpQcm9wb3NhbDogIk9iamVjdHMgTGlm
ZWN5Y2xlIE1hbmFnZW1lbnQiIG9yICJZQU5HIE9iamVjdHMgTGlmZWN5Y2xlIE1hbmFnZW1lbnQi
DQoNCiAgICBUaGUgWUFORyBvYmplY3RzIHN0YXR1cyBzdGF0ZW1lbnQgTVVTVCBiZSBwcmVzZW50
IGlmIGl0cyB2YWx1ZSBpcyAnZGVwcmVjYXRlZCcgb3INCg0KICAgJ29ic29sZXRlJy4NCg0KDQoN
Cg0KDQotIHNlY3Rpb24gNC44DQoNCiAgIFRoZSBjb250YWN0IHN0YXRlbWVudCBNVVNUIGJlIHBy
ZXNlbnQuICBJZiB0aGUgbW9kdWxlIGlzIGNvbnRhaW5lZCBpbg0KDQogICBhIGRvY3VtZW50IGlu
dGVuZGVkIGZvciBTdGFuZGFyZHMgVHJhY2sgc3RhdHVzLCB0aGVuIHRoZSB3b3JraW5nDQoNCiAg
IGdyb3VwIHdlYiBhbmQgbWFpbGluZyBpbmZvcm1hdGlvbiBNVVNUIGJlIHByZXNlbnQsIGFuZCB0
aGUgbWFpbg0KDQogICBkb2N1bWVudCBhdXRob3Igb3IgZWRpdG9yIGNvbnRhY3QgaW5mb3JtYXRp
b24gU0hPVUxEIGJlIHByZXNlbnQuICBJZg0KDQogICBhZGRpdGlvbmFsIGF1dGhvcnMgb3IgZWRp
dG9ycyBleGlzdCwgdGhlaXIgY29udGFjdCBpbmZvcm1hdGlvbiBNQVkgYmUNCg0KICAgcHJlc2Vu
dC4NCg0KDQoNCg0KDQpJIHdvdWxkIGFkZDogTm8gbmVlZCB0byBpbmNsdWRlIHRoZSBXRyBjaGFp
ciBjb250YWN0cy4NCg0KDQoNCi0gc2VjdGlvbiA0LjEwDQoNCiAgIFRoZSBzZXBhcmF0aW9uIG9m
IGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgb3BlcmF0aW9uYWwgc3RhdGUgU0hPVUxEIGJlDQoNCiAg
IGNvbnNpZGVyZWQgY2FyZWZ1bGx5LiAgSXQgaXMgc29tZXRpbWVzIHVzZWZ1bCB0byBkZWZpbmUg
c2VwYXJhdGUgdG9wLQ0KDQogICBsZXZlbCBjb250YWluZXJzIGZvciBjb25maWd1cmF0aW9uIGFu
ZCBub24tY29uZmlndXJhdGlvbiBkYXRhLiAgRm9yDQoNCiAgIHNvbWUgZXhpc3RpbmcgdG9wLWxl
dmVsIGRhdGEgbm9kZXMsIGNvbmZpZ3VyYXRpb24gZGF0YSB3YXMgbm90IGluDQoNCiAgIHNjb3Bl
LCBzbyBvbmx5IG9uZSBjb250YWluZXIgcmVwcmVzZW50aW5nIG9wZXJhdGlvbmFsIHN0YXRlIHdh
cw0KDQogICBjcmVhdGVkLg0KDQpXaGF0IGFib3V0IE5NREE/DQoNClRoaXMgc2VjdGlvbiBpcyBu
b3QgaW5saW5lIHdpdGggNC4yMy4zDQoNCkJ0dywgaW4gY2FzZSBhIFlBTkcgc3VwcG9ydHMgTk1E
QSAsIFJGQzYwODdiaXMgc2hvdWxkIGluY2x1ZGUgdGhlIGd1aWRlbGluZSBpcyB0aGF0IGl0IG11
c3QgYmUgY2xlYXJseSBtZW50aW9uZWQuDQoNClRoZSBleGFtcGxlIG9mIHRoZSBhYnN0cmFjdCBp
biBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jp
cy0wMzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmZjNzIyM2Jpcy0y
RDAzJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9D
SSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1MdE8yUlFR
SWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJnM9UnBTRWVydkhkY0RRbFMwQWst
NVRWYmYzSV9vUjViWHZoR1I2OGRqdlBTbyZlPT4gY291bGQgYmUgbWVudGlvbmVkLg0KDQogICBU
aGUgWUFORyBtb2RlbCBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm1zIHRvIHRoZSBOZXR3b3JrIE1h
bmFnZW1lbnQNCg0KICAgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSBkZWZpbmVkIGluIEktRC5pZXRm
LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMuDQoNCg0KDQoNCg0KSW4gdGhlIHNhbWUgc2VjdGlv
biBhYm91dCAidG9wLWxldmVsIGRhdGEgZGVmaW5pdGlvbnMiLCBhbnkgZ3VpZGVsaW5lcyBpbiBj
b25uZWN0aW9uIHdpdGggaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0
Zi1ydGd3Zy1sbmUtbW9kZWwvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHJ0
Z3dnLTJEbG5lLTJEbW9kZWxfJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh
SmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJnM9dXVD
NjJlTTJzT0JWUXh4VlR5azJVY3hBbk9pVHF5ZFRheWk3ajc2NGU4dyZlPT4gYW5kIHNjaGVtYSBt
b3VudD8NCg0KVG9vIGVhcmx5Pw0KDQoNCg0KSW4gc2VjdGlvbiA0LjIzLCBhZGQgdGhlIFtJLUQu
aWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGll
dGYtMkRuZXRtb2QtMkRyZmM2MDg3YmlzLTJEMTYtMjNyZWYtMkRJLTJERC5pZXRmLTJEbmV0bW9k
LTJEcmV2aXNlZC0yRGRhdGFzdG9yZXMmZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZtPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMm
cz1zelliUlhwWG4wOUU0Sm1oR0xMLTgtVGUtbjd0Y0E1RFNsaHpTcTZxU1VjJmU9Pl0gcmVmZXJl
bmNlIG5leHQgdG8gTk1EQQ0KDQpJbiBzZWN0aW9uIDQuMjMuMw0KDQpPTEQ6DQoNCihiKSBGb3Ig
cHVibGlzaGVkIG1vZGVscywgdGhlIG1vZGVsIHNob3VsZCBiZSByZXB1Ymxpc2hlZCB3aXRoIGFu
DQoNCiAgIE5NREEtY29tcGF0aWJsZSBzdHJ1Y3R1cmUsIGRlcHJlY2F0aW5nIG5vbi1OTURBIGNv
bnN0cnVjdHMuICBGb3INCg0KICAgZXhhbXBsZSwgdGhlICJpZXRmLWludGVyZmFjZXMiIG1vZGVs
IGluIFtSRkM3MjIzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3MjIzJmQ9RHdNRGFRJmM9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9V
a19xWXhxeUxBX21jJnM9SHJBZl9Wd3hwMlpUMUZCWTJHY2JQRlBMTHJvYjREdGFwMk4wSXBHN1dF
SSZlPT5dIHdpbGwgYmUNCg0KICAgcmVzdHJ1Y3R1cmVkIGFzIGFuIE5NREEtY29tcGF0aWJsZSBt
b2RlbC4NCg0KDQoNCk5FVzoNCg0KKGIpIEZvciBwdWJsaXNoZWQgbW9kZWxzLCB0aGUgbW9kZWwg
c2hvdWxkIGJlIHJlcHVibGlzaGVkIHdpdGggYW4NCg0KICAgTk1EQS1jb21wYXRpYmxlIHN0cnVj
dHVyZSwgZGVwcmVjYXRpbmcgbm9uLU5NREEgY29uc3RydWN0cy4gIEZvcg0KDQogICBleGFtcGxl
LCB0aGUgImlldGYtaW50ZXJmYWNlcyIgbW9kZWwgaW4gW1JGQzcyMjM8aHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1s
X3JmYzcyMjMmZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY
Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUx0
TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmcz1IckFmX1Z3eHAyWlQx
RkJZMkdjYlBGUExMcm9iNER0YXAyTjBJcEc3V0VJJmU9Pl0gaGFzIGJlZW4NCg0KICAgcmVzdHJ1
Y3R1cmVkIGFzIGFuIE5NREEtY29tcGF0aWJsZSBtb2RlbCBpbiBbUkZDNzIyM2Jpc10uDQoNCg0K
DQpJIGJlbGlldmUgW0ktRC5pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXNdIHNob3VsZCBh
IG5vcm1hdGl2ZSByZWZlcmVuY2UNCg0KDQoNCi0gc2VjdGlvbiA0LjE0LjINCg0KDQoNClNvbWV0
aGluZyB3cm9uZyB3aXRoOg0KDQogICAtdG9wLWxldmVsIHNpYmxpbmdzIGFyZSBub3Qgb3JkZXJl
ZCAtdG9wLWxldmVsIHNpYmxpbmdzIG5vdCBhcmUgbm90DQoNCiAgIHN0YXRpYywgYW5kIGRlcGVu
ZHMgb24gdGhlIG1vZHVsZXMgdGhhdCBhcmUgbG9hZGVkDQoNCg0KDQotIHNlY3Rpb24gNC4xNw0K
DQpEaXNjdXNzaW5nIHdpdGggWUFORyBkb2N0b3JzIHRoYXQgYSBmZWF0dXJlLXBlci1sZWFmIGlz
IG1vc3QgbGlrZWx5IHRoZSB3cm9uZyBhcHByb2FjaCwgSsO8cmdlbiBjYW1lIHVwIHdpdGggdGhp
cy4NCg0KDQoNCk9MRA0KDQoNCg0KICAgVGhlIFlBTkcgImZlYXR1cmUiIHN0YXRlbWVudCBpcyB1
c2VkIHRvIGRlZmluZSBhIGxhYmVsIGZvciBhIHNldCBvZg0KDQogICBvcHRpb25hbCBmdW5jdGlv
bmFsaXR5IHdpdGhpbiBhIG1vZHVsZS4gIFRoZSAiaWYtZmVhdHVyZSIgc3RhdGVtZW50DQoNCiAg
IGlzIHVzZWQgaW4gdGhlIFlBTkcgc3RhdGVtZW50cyBhc3NvY2lhdGVkIHdpdGggYSBmZWF0dXJl
Lg0KDQoNCg0KICAgVGhlIHNldCBvZiBZQU5HIGZlYXR1cmVzIGF2YWlsYWJsZSBpbiBhIG1vZHVs
ZSBzaG91bGQgYmUgY29uc2lkZXJlZA0KDQogICBjYXJlZnVsbHkuICBUaGUgZGVzY3JpcHRpb24t
c3RtdCB3aXRoaW4gYSBmZWF0dXJlLXN0bXQgTVVTVCBzcGVjaWZ5DQoNCiAgIGFueSBpbnRlcmFj
dGlvbnMgd2l0aCBvdGhlciBmZWF0dXJlcy4NCg0KDQoNCiAgIElmIHRoZXJlIGlzIGEgbGFyZ2Ug
c2V0IG9mIG9iamVjdHMuLi4NCg0KDQoNCk5FVw0KDQoNCg0KICAgVGhlIFlBTkcgImZlYXR1cmUi
IHN0YXRlbWVudCBpcyB1c2VkIHRvIGRlZmluZSBhIGxhYmVsIGZvciBhIHNldCBvZg0KDQogICBv
cHRpb25hbCBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhIG1vZHVsZS4gIFRoZSAiaWYtZmVhdHVyZSIg
c3RhdGVtZW50DQoNCiAgIGlzIHVzZWQgaW4gdGhlIFlBTkcgc3RhdGVtZW50cyBhc3NvY2lhdGVk
IHdpdGggYSBmZWF0dXJlLiAgVGhlDQoNCiAgIGRlc2NyaXB0aW9uLXN0bXQgd2l0aGluIGEgZmVh
dHVyZS1zdG10IE1VU1Qgc3BlY2lmeSBhbnkNCg0KICAgaW50ZXJhY3Rpb25zIHdpdGggb3RoZXIg
ZmVhdHVyZXMuDQoNCg0KDQogICBUaGUgc2V0IG9mIFlBTkcgZmVhdHVyZXMgZGVmaW5lZCBpbiBh
IG1vZHVsZSBzaG91bGQgYmUgY29uc2lkZXJlZA0KDQogICBjYXJlZnVsbHkuIFZlcnkgZmluZSBn
cmFudWxhciBmZWF0dXJlcyBpbmNyZWFzZSBpbnRlcm9wZXJhYmlsaXR5DQoNCiAgIGNvbXBsZXhp
dHkgYW5kIHNob3VsZCBiZSBhdm9pZGVkLiBBIGxpa2VseSBtaXN1c2Ugb2YgdGhlIGZlYXR1cmUN
Cg0KICAgbWVjaGFuaXNtIGlzIHRoZSB0YWdnaW5nIG9mIGluZGl2aWR1YWwgbGVhZnMgKGUuZy4s
IGNvdW50ZXJzKSB3aXRoDQoNCiAgIHNlcGFyYXRlIGZlYXR1cmVzLg0KDQoNCg0KICAgSWYgdGhl
cmUgaXMgYSBsYXJnZSBzZXQgb2Ygb2JqZWN0cy4uLg0KDQoNCg0KYmFjayB0byBzZWN0aW9uIDQu
NQ0KDQogICBJZiBhIGRhdGEgZGVmaW5pdGlvbiBpcyBvcHRpb25hbCwgZGVwZW5kaW5nIG9uIHNl
cnZlciBzdXBwb3J0IGZvciBhDQoNCiAgIE5FVENPTkYgb3IgUkVTVENPTkYgcHJvdG9jb2wgY2Fw
YWJpbGl0eSwgdGhlbiBhIFlBTkcgJ2ZlYXR1cmUnDQoNCiAgIHN0YXRlbWVudCBTSE9VTEQgYmUg
ZGVmaW5lZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBORVRDT05GIG9yIFJFU1RDT05GDQoNCiAgIGNh
cGFiaWxpdHkgaXMgc3VwcG9ydGVkIHdpdGhpbiB0aGUgZGF0YSBtb2RlbC4NCg0KDQoNCk5FVzoN
Cg0KICAgIElmIGEgZGF0YSBkZWZpbml0aW9uIGlzIG9wdGlvbmFsIHdoaWNoIGRlcGVuZHMgb24g
c2VydmVyIHN1cHBvcnQgdGhlbg0KDQogICAgYSBZQU5HICdmZWF0dXJlJyBzdGF0ZW1lbnQgU0hP
VUxEIGJlIGRlZmluZWQuICBUaGUgZGVmaW5lZCAnZmVhdHVyZScNCg0KICAgIFNIT1VMRCB0aGVu
IGJlIHVzZWQgaW4gdGhlIGNvbmRpdGlvbmFsICdpZi1mZWF0dXJlJyBzdGF0ZW1lbnQNCg0KICAg
IHJlZmVyZW5jaW5nIHRoZSBvcHRpb25hbCBkYXRhIGRlZmluaXRpb24uDQoNCg0KDQpUaGlzIGlz
IGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uIHdpdGggdGhlIFlBTkcgZG9jdG9ycy4NCg0KDQoN
ClJlZ2FyZHMsIEJlbm9pdA0KDQo=

--_000_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj
aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+
DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh
cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9
IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN
aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls
ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo
I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh
cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0
eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1
IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl
LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQt
dmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJh
bnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGln
bjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y
OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s
b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmkiPkkgc2VlIGEgbG90IG9mIHN1Z2dlc3Rpb25zIHRvIHJlZmVy
ZW5jZSBvdGhlciBkcmFmdHMgYXMgZXhhbXBsZXMuJm5ic3A7IEkgd291bGQgZGlzY291cmFnZSBk
b2luZyB0aGF0LiZuYnNwOyBJIHJlY29tbWVuZCB0aGlzIGRyYWZ0IGNsZWFybHkgc3RhdGluZyB0
aGUgZGVzaXJlLCBpbmNsdWRpbmcgaXRzIG93biBleGFtcGxlcyBpZiBuZWVkZWQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5SZWdhcmRpbmcgcmVmZXJl
bmNpbmcgdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQsIEkgZG9uJ3QgYWdyZWUgdGhhdCBoYXZpbmcg
YSAmcXVvdDtUcmVlIERpYWdyYW1zJnF1b3Q7IHNlY3Rpb24gaW4gdGhlIEludHJvZHVjdGlvbiBp
cyBiZXR0ZXIgdGhhbiBhbiBpbmxpbmUgcmVmZXJlbmNlIHdoZXJlIHVzZWQ6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OkNhbGlicmkiPjEpIHRoZSB0ZXJtICZxdW90O3RyZWUgZGlhZ3JhbSZxdW90OyBpcyBub3QgYW55
d2hlcmUgZGVmaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4yKSBzZWN0aW9ucyBoYXZpbmcgdHJl
ZSBkaWFncmFtcyBoYXZlIHRvIHJlZmVyZW5jZSB0aGUgc2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0
aW9uLCBhbmQgd2h5IHJlZmVyZW5jZSB0aGUgSW50cm8gc2VjdGlvbiB3aGVuIGl0J3MganVzdCBh
cyBlYXN5IHRvIHJlZmVyZW5jZSB0aGUgZHJhZnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjMpIGl0
IG1ha2VzIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIFRhYmxlIG9mIENvbnRlbnRzIHVubmVjZXNzYXJp
bHkgYnVzeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+
S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMjUv
MTgsIDY6MjAgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91
bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBj
aXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGFuayB5b3UgZm9y
IHRoaXMgaW1wb3J0YW50IGRvY3VtZW50Ljxicj4NCkkndmUgYmVlbiBzcGVuZGluZyBxdWl0ZSBz
b21lIHRpbWUgdHJ5aW5nIHRvIHJlbGF5IGZlZWRiYWNrIHNlZW4gb24gbXVsdGlwbGUgZnJvbnRz
Ljxicj4NClRoaXMgaXMgcGFydCAxIG9mIHRoZSByZXZpZXcsIHRpbGwgc2VjdGlvbiA0LjIxPGJy
Pg0KPGJyPg0KPGJyPg0KLSA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2V0IG9mIHVzYWdlIGd1aWRlbGluZXMgZm9yIFN0YW5k
YXJkcyBUcmFjazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkb2N1bWVudHMg
Y29udGFpbmluZyBbPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzc5NTAmYW1wO2Q9RHdNRGFR
JmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1MdE8yUlFR
SWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJmFtcDtzPXQ4ZnNoU3BlMERoaDV1
VEU4c1JOZ1NYb0xUa1ktNC1ubGVQYVljMU15MEEmYW1wO2U9IiB0aXRsZT0iJnF1b3Q7VGhlIFlB
TkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UmcXVvdDsiPlJGQzc5NTA8L2E+XSBkYXRhIG1v
ZGVscy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+VGhpcyBpcyBub3QgaW5saW5lIHdpdGg6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7IFRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgbW9kdWxlKHMpIGRlZmluZWQgYnkgdGhl
IHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZXNl
IG1vZHVsZXMgU0hPVUxEIGJlIHdyaXR0ZW4gdXNpbmcgdGhlIFlBTkcgMS4xIFs8YSBocmVmPSJo
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xz
LmlldGYub3JnX2h0bWxfcmZjNzk1MCZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERq
X1VrX3FZeHF5TEFfbWMmYW1wO3M9dDhmc2hTcGUwRGhoNXVURThzUk5nU1hvTFRrWS00LW5sZVBh
WWMxTXkwQSZhbXA7ZT0iIHRpdGxlPSImcXVvdDtUaGUgWUFORyAxLjEgRGF0YSBNb2RlbGluZyBM
YW5ndWFnZSZxdW90OyI+UkZDNzk1MDwvYT5dIHN5bnRheC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgWUFORyAxLjAgWzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM2MDIw
JmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY
Y1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8m
YW1wO209THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtfcVl4cXlMQV9tYyZhbXA7cz1M
OExab2hVV1pRSGdDYzY5dFNINzh3M21tZUJGN1pwRWFZR2ZEUFlmNS04JmFtcDtlPSIgdGl0bGU9
IiZxdW90O1lBTkcgLSBBIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UgZm9yIHRoZSBOZXR3b3JrIENv
bmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpJnF1b3Q7Ij5SRkM2MDIwPC9hPl0gc3ludGF4
IE1BWSBiZSB1c2VkIGlmIG5vIFlBTkcgMS4xIGNvbnN0cnVjdHMgb3I8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgc2VtYW50aWNzIGFyZSBuZWVkZWQgaW4gdGhlIG1vZHVsZS48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TbyBp
dCBzaG91bGQgYmUgY2hhbmdlZCB0byA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzZXQgb2YgdXNhZ2UgZ3VpZGVsaW5lcyBm
b3IgU3RhbmRhcmRzIFRyYWNrPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRv
Y3VtZW50cyBjb250YWluaW5nIFlBTkcgMS4xIFs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZj
Nzk1MCZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2
b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmYW1w
O3M9dDhmc2hTcGUwRGhoNXVURThzUk5nU1hvTFRrWS00LW5sZVBhWWMxTXkwQSZhbXA7ZT0iIHRp
dGxlPSImcXVvdDtUaGUgWUFORyAxLjEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSZxdW90OyI+UkZD
Nzk1MDwvYT5dIGFuZCBZQU5HIDEuMCBbUkZDNjAyMF0gZGF0YSBtb2RlbHMuIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNpbWlsYXJseSBpbiBz
ZWN0aW9uIDQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PTEQ6PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw
O01vZHVsZXMgaW4gSUVURiBTdGFuZGFyZHMgVHJhY2sgc3BlY2lmaWNhdGlvbnMgTVVTVCBjb21w
bHkgd2l0aCBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3ludGFjdGlj
IGFuZCBzZW1hbnRpYyByZXF1aXJlbWVudHMgb2YgWUFORyBbPGEgaHJlZj0iaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o
dG1sX3JmYzc5NTAmYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN
Sy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZhbXA7bT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxB
X21jJmFtcDtzPXQ4ZnNoU3BlMERoaDV1VEU4c1JOZ1NYb0xUa1ktNC1ubGVQYVljMU15MEEmYW1w
O2U9IiB0aXRsZT0iJnF1b3Q7VGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UmcXVv
dDsiPlJGQzc5NTA8L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5ORVc6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwO01vZHVsZXMgaW4gSUVURiBTdGFuZGFyZHMgVHJhY2sgc3BlY2lmaWNhdGlvbnMgTVVTVCBj
b21wbHkgd2l0aCBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3ludGFj
dGljIGFuZCBzZW1hbnRpYyByZXF1aXJlbWVudHMgb2YgWUFORyAxLjEgWzxhIGhyZWY9Imh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0
Zi5vcmdfaHRtbF9yZmM3OTUwJmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mYW1wO209THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtf
cVl4cXlMQV9tYyZhbXA7cz10OGZzaFNwZTBEaGg1dVRFOHNSTmdTWG9MVGtZLTQtbmxlUGFZYzFN
eTBBJmFtcDtlPSIgdGl0bGU9IiZxdW90O1RoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1
YWdlJnF1b3Q7Ij5SRkM3OTUwPC9hPl0uIFNlZSB0aGUgZXhjZXB0aW9uPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZvciBZQU5HIDEuMCBpbiBzZWN0aW9uIDMuNjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5vdGUgdGhhdCBJ
IHRyaWVkIHRvIGFkZCBzb21lIG5ldyB0ZXh0IGFyb3VuZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNl
IGJ1dCB0aGF0IHBhcmFncmFwaCBiZWNhbWUgY2x1bXN5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyBBbHRlcm5hdGl2ZWx5LCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDtpZiBZQU5HIDEuMCBpcyB1c2VkLCB0aGVuIE1vZHVsZXMgaW4gSUVURiBT
dGFuZGFyZHMgVHJhY2sgc3BlY2lmaWNhdGlvbnMgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7TVVTVCBjb21wbHkgd2l0aCBhbGwgc3ludGFjdGljIGFuZCBzZW1hbnRp
YyByZXF1aXJlbWVudHMgb2YgWUFORyAxLjAgW1JGQzYwMjBdLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkZpbmFsbHksIGluIHNlY3Rpb24gMy42
LCBJIHdvdWxkIGFkZCBhIHNlbnRlbmNlIHRvIHRoaXMgcGFyYWdyYXBoPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgbW9kdWxlKHMp
IGRlZmluZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IFRoZXNlIG1vZHVsZXMgU0hPVUxEIGJlIHdyaXR0ZW4gdXNpbmcgdGhlIFlBTkcg
MS4xIFs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNzk1MCZhbXA7ZD1Ed01EYVEmYW1wO2M9
SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40
TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmYW1wO3M9dDhmc2hTcGUwRGhoNXVURThzUk5n
U1hvTFRrWS00LW5sZVBhWWMxTXkwQSZhbXA7ZT0iIHRpdGxlPSImcXVvdDtUaGUgWUFORyAxLjEg
RGF0YSBNb2RlbGluZyBMYW5ndWFnZSZxdW90OyI+UkZDNzk1MDwvYT5dIHN5bnRheC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgWUFORyAxLjAgWzxhIGhyZWY9Imh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v
cmdfaHRtbF9yZmM2MDIwJmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mYW1wO209THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtfcVl4
cXlMQV9tYyZhbXA7cz1MOExab2hVV1pRSGdDYzY5dFNINzh3M21tZUJGN1pwRWFZR2ZEUFlmNS04
JmFtcDtlPSIgdGl0bGU9IiZxdW90O1lBTkcgLSBBIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UgZm9y
IHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpJnF1b3Q7Ij5SRkM2
MDIwPC9hPl0gc3ludGF4IE1BWSBiZSB1c2VkIGlmIG5vIFlBTkcgMS4xIGNvbnN0cnVjdHMgb3I8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2VtYW50aWNzIGFyZSBuZWVkZWQg
aW4gdGhlIG1vZHVsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5UaGUgc2VudGVuY2Ugc3VjaCBhczogPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7aWYgYW55IHRoZSBpbXBvcnRlZCBZQU5HIG1vZHVsZXMgaXMgYmFz
ZWQgb24gWUFORyAxLjEsIHRoZSBtYWluIFlBTkcgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7bW9kdWxlIE1VU1QgYWxzbyBiZSB3cml0dGVuIGluIFlBTkcgMS4xLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
Oy0gc2VjdGlvbiAzLCBlZGl0b3JpYWw6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IFRoZXJlIGFyZSB0aHJlZSB1c2FnZSBzY2VuYXJpb3MgZm9yIFlBTkcgdGhhdCBjYW4gYXBw
ZWFyIGluIGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEludGVybmV0LURy
YWZ0IG9yIFJGQzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBub3JtYXRpdmUgbW9kdWxlIG9yIHN1Ym1vZHVs
ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBvJm5ic3A7IGV4YW1wbGUgbW9kdWxlIG9yIHN1Ym1vZHVsZTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBv
Jm5ic3A7IGV4YW1wbGUgWUFORyBmcmFnbWVudCBub3QgcGFydCBvZiBhbnkgbW9kdWxlIG9yIHN1
Ym1vZHVsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyBUaGUgZ3VpZGVsaW5lcyBpbiB0aGlzIGRvY3VtZW50IHJlZmVyIG1h
aW5seSB0byBhIG5vcm1hdGl2ZSA8dT5jb21wbGV0ZTwvdT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgbW9kdWxlIG9yIHN1Ym1vZHVsZSwgYnV0IG1heSBiZSBhcHBsaWNhYmxl
IHRvIGV4YW1wbGUgbW9kdWxlcyBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgWUFORyBmcmFnbWVudHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5FaXRoZXIgYWRkICZxdW90O2NvbXBsZXRlJnF1b3Q7IHRv
ICZxdW90O28mbmJzcDsgbm9ybWF0aXZlIG1vZHVsZSBvciBzdWJtb2R1bGUpJnF1b3Q7IGFuZCBi
ZSBjb25zaXN0ZW50IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50LDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPm9yIHJlbW92ZSBpdCBmcm9tIHRoZSBsYXN0IHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPi0gc2VjdGlvbiAzLjI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlICZxdW90OyZsdDtDT0RFIEJFR0lO
UyZndDsmcXVvdDsgdGFnIFNIT1VMRCBiZSBmb2xsb3dlZCBieSBhIHN0cmluZyBpZGVudGlmeWlu
ZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgZmlsZSBuYW1lIHNwZWNp
ZmllZCBpbiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNzk1MC0yM3NlY3Rpb24tMkQ1LjIm
YW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj
V3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZh
bXA7bT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJmFtcDtzPW9R
WTZsaGhqUnVPRVl5X05mLTdIRzZfLWVNZ3dYN3haZzRWS05Iam5UTWMmYW1wO2U9Ij5TZWN0aW9u
Jm5ic3A7NS4yIG9mIFtSRkM3OTUwXTwvYT4uJm5ic3A7IFRoZSBuYW1lIHN0cmluZzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBmb3JtIHRoYXQgaW5jbHVkZXMgdGhlIHJldmlz
aW9uLWRhdGUgU0hPVUxEIGJlIHVzZWQuJm5ic3A7IFRoZSBmb2xsb3dpbmc8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZXhhbXBsZSBpcyBmb3IgdGhlICcyMDEwLTAxLTE4JyBy
ZXZpc2lvbiBvZiB0aGUgJ2lldGYtZm9vJyBtb2R1bGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZsdDtDT0RFIEJFR0lO
UyZndDsgZmlsZSA8YSBocmVmPSJtYWlsdG86aWV0Zi1mb29AMjAxNi0wMy0yMC55YW5nIj4mcXVv
dDtpZXRmLWZvb0AyMDE2LTAzLTIwLnlhbmcmcXVvdDs8L2E+PG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB3b3VsZCBhZGQgdGhhdCBib3RoIHJl
dmlzaW9uIHZlcnNpb25zIChvbiB0aGUgJmx0O0NPREUgQkVHSU5TJmd0OyBhbmQgaW4gdGhlIG1v
ZHVsZSkgTVVTVCBtYXRjaC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIHJhbiBpbnRvIGFsbCBz
b3J0IG9mIHRvb2xpbmcgaXNzdWVzIGJlY2F1c2Ugb2Ygc3VjaCBkaXNjcmVwYW5jaWVzLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0gc2VjdGlv
biAzLjIuMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFkZCAmcXVvdDtzZWUgc2VjdGlvbiA0Ljkg
cmVnYXJkaW5nIHRoZSBuYW1lc3BhY2UgZ3VpZGVsaW5lcyBmb3IgZXhhbXBsZSBtb2R1bGVzJnF1
b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
LSBUaGUgZm9sbG93aW5nIGluIHBhcmFncmFwaCBpbiBzZWN0aW9uIDMuMyBzZWVtcyBtaXNwbGFj
ZWQuJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYg
WUFORyB0cmVlIGRpYWdyYW1zIGFyZSB1c2VkLCB0aGVuIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0
byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgWUFORyB0cmVlIGRpYWdy
YW1zIHNwZWNpZmljYXRpb24gTVVTVCBiZSBwcm92aWRlZCBmb3IgZWFjaCBkaWFncmFtLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAoUmVmZXIgdG8gdGhlIGV4YW1wbGUgaW4g
dGhlIG5leHQgc2VjdGlvbi4pPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkl0IHNob3VsZCBiZSBpbiBzZWN0aW9uIDMuNC48YnI+DQpCdHcsIG5v
IG5lZWQgdG8gaGF2ZSB0aGUgc3BlY2lmaWNhdGlvbnMgZm9yIGVhY2ggZGlhZ3JhbSE8YnI+DQpB
bHNvLCB3ZSB3YW50IHRvIGFkZCBzb21lIGd1aWRlbGluZXMgb24gaG93IHRvIHJlZmVyZW5jZSB0
aGUgdHJlZSBkaWFncmFtIGNvbnZlbnRpb248YnI+DQpGb3IgZXg6IG5vIG5lZWQgdG8gY29weSBv
dmVyIHRoZSBjb252ZW50aW9uczxicj4NCkJhc2ljYWxseSwgd2UganVzdCBuZWVkOiA8YSBocmVm
PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv
b2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmZjNzIyM2Jpcy0yRDAz
LTIzc2VjdGlvbi0yRDEuMyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBV
akJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZ
eHF5TEFfbWMmYW1wO3M9UWxucmJuR1pFby16UVl6RzlBV2s4NmFfbTIySWNwQm5HUWtld0VXSGF4
USZhbXA7ZT0iPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9k
LXJmYzcyMjNiaXMtMDMjc2VjdGlvbi0xLjM8L2E+PGJyPg0KPGJyPg0KUFJPUE9TQUwgKHJlcGxh
Y2luZyB0aGUgcHJldmlvdXMgcGFyYWdyYXBoKSA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDtJZiBZQU5HIHRyZWUgZGlhZ3JhbXMgYXJlIHVzZWQsIHRoZW4gYSBub3Jt
YXRpdmUgcmVmZXJlbmNlIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBZQU5HIHRyZWUgZGlhZ3JhbXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIHByb3ZpZGVkLiBBcyBh
biBleGFtcGxlIGd1aWRlbGluZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsoZnJvbSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0bW9k
LTJEcmZjNzIyM2Jpcy0yRDAzLTIzc2VjdGlvbi0yRDEuMyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFr
WXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2
WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6
TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmYW1wO3M9UWxucmJuR1pFby16UVl6RzlBV2s4NmFf
bTIySWNwQm5HUWtld0VXSGF4USZhbXA7ZT0iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzI3NlY3Rpb24tMS4zPC9hPiksPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGhlcmUgaXMgYSBzdWJzZWN0aW9uIGluIHRoZSB0
ZXJtaW5vbG9neSBzZWN0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRyZWUgRGlhZ3JhbXM8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7VHJlZSBk
aWFncmFtcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgZm9sbG93IHRoZSBub3RhdGlvbiBkZWZpbmVk
IGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu
b3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmZjNzIyM2Jpcy0yRDAzLTIzcmVmLTJE
SS0yREQuaWV0Zi0yRG5ldG1vZC0yRHlhbmctMkR0cmVlLTJEZGlhZ3JhbXMmYW1wO2Q9RHdNRGFR
JmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1MdE8yUlFR
SWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJmFtcDtzPUpJZGFiUDc3Unota0Fy
RkY2REczTUc1WDI0X0FQdVB6b0dpZkhORWRwbVkmYW1wO2U9Ij5JLUQuaWV0Zi1uZXRtb2QteWFu
Zy10cmVlLWRpYWdyYW1zPC9hPl0uPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPi0gc2VjdGlvbiAzLjU8YnI+DQpZb3Ugc2hvdWxkIGFkZCBhIGdv
b2QgZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIChCYXNlZCBvbiBz
b21lIHByZXZpb3VzIGZlZWRiYWNrLCBZQU5HIG1vZHVsZSBkZXNpZ25lciB3YW50cyB0byB3b3Jr
IGZyb20gZXhhbXBsZXMpPGJyPg0KSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCA8YSBocmVmPSJodHRw
czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll
dGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmZjODAyMmJpcy0yRDA5LTIzc2Vj
dGlvbi0yRDIuMyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFf
bWMmYW1wO3M9eHVpQVE0Wnd6R29Bd255Rm1KYzlIeklkTjd4c3FUelhRNDZGQkxUcWU4TSZhbXA7
ZT0iPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgw
MjJiaXMtMDkjc2VjdGlvbi0yLjM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KLSBzZWN0aW9uIDMuNiwg
ZWRpdG9yaWFsPGJyPg0KT0xEOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsgTm90ZSB0aGF0
IGFsbCBZQU5HIHN0YXRlbWVudHMgd2l0aGluIGEgWUFORyBtb2R1bGUgYXJlIGNvbnNpZGVyZWQ8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbm9ybWF0aXZlLCBpZiB0aGUgbW9k
dWxlIGl0c2VsZiBpcyBjb25zaWRlcmVkIG5vcm1hdGl2ZSwgYW5kIG5vdCBhbjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBleGFtcGxlIG1vZHVsZS4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+TkVXOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyBOb3RlIHRoYXQgYWxsIFlBTkcgc3RhdGVtZW50cyB3aXRoaW4gYSBZ
QU5HIG1vZHVsZSBhcmUgY29uc2lkZXJlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyBub3JtYXRpdmUsIGlmIHRoZSBtb2R1bGUgaXRzZWxmIGlzIGNvbnNpZGVyZWQgbm9ybWF0
aXZlLCBhbmQgbm90IGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGV4YW1w
bGUgbW9kdWxlIG9yIGEgZXhhbXBsZSBZQU5HIGZyYWdtZW50LiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBzZWN0
aW9uIDMuNjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgRXhhbXBsZSBZQU5HIG1v
ZHVsZXMgTVVTVCBOT1QgY29udGFpbiBhbnkgbm9ybWF0aXZlIHRleHQsIGluY2x1ZGluZzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbnkgcmVzZXJ2ZWQgd29yZHMgZnJvbSBb
PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzIxMTkmYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpH
SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1MdE8yUlFRSWVnV2xONE1Jek5r
YnViSVhpd1BEal9Va19xWXhxeUxBX21jJmFtcDtzPW5fdTZvYVZkVFdzLXk1bmU1ZmkycGRnSy1V
aWdVVW5nUDdkOHVoc29yeE0mYW1wO2U9IiB0aXRsZT0iJnF1b3Q7S2V5IHdvcmRzIGZvciB1c2Ug
aW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMmcXVvdDsiPlJGQzIxMTk8L2E+
XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J
IGd1ZXNzIGl0IGFwcGxpZXMgYWxzbyB0byB0aGUgJnF1b3Q7ZXhhbXBsZSBZQU5HIGZyYWdtZW50
cyZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPi0gc2VjdGlvbiAzLjEwPG86cD48L286cD48L3ByZT4NCjxwcmU+TWVudGlvbiB5YW5nbGlu
dC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT55YW5nbGludCB2YWxpZGF0ZXMgeHBhdGgsIHdoaWxl
IHB5YW5nIGRvZXNuJ3QuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+LSBzZWN0aW9uIDMuMTE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Zb3UgbWln
aHQgY29uc2lkZXIgdGhlIGFkZGl0aW9uIG9mIHh5bSA8YSBocmVmPSJodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21feHltLTJEdG9v
bF94eW0mYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZhbXA7bT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21jJmFt
cDtzPWVVTEFmR29fQ0JWamJGWEd4NDlIUjczVVNyS1hqQ3JMLVhhQVdLZFhsS2MmYW1wO2U9Ij5o
dHRwczovL2dpdGh1Yi5jb20veHltLXRvb2wveHltPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0gc2VjdGlvbiAzLjEyPG86cD48L286cD48
L3ByZT4NCjxwcmU+bWVudGlvbiB0aGF0IHRoZSBleGFtcGxlcyBNVVNUIGJlIHZhbGlkYXRlZC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Qb2ludGluZyB0byB0aGUgdG9vbCB3b3VsZCBiZSBhIHdl
bGNvbWUgYWRkaXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+LSBzZWN0aW9uIDQuNi54PG86cD48L286cD48L3ByZT4NCjxwcmU+WW91IHNo
b3VsZCByZWFsbHkgbWVudGlvbiBhIGNvbW1vbiBtaXN0YWtlIGFib3V0IHRoZSBtaXNzaW5nIGRl
cml2ZWQtZnJvbS1vci1zZWxmKCksIGZsYWdnZWQgaW4gbWFueSBZQU5HIGRvY3RvciByZXZpZXdz
Ojo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjExODAiIGhl
aWdodD0iMjE4IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFEMzk1
QjAuNkYxQ0ZEQjAiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Zb3Ugc2hvdWxkIGV4cGxhaW4g
dGhlIGFwcGxpY2FiaWxpdHk6IGlkZW50aXR5IGF1Z21lbnRhdGlvbi48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tIHNlY3Rpb24gNC43ICZxdW90
O0xpZmVjeWNsZSBNYW5hZ2VtZW50JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFRoZSBzdGF0dXMgc3RhdGVtZW50IE1VU1QgYmUgcHJlc2VudCBpZiBpdHMg
dmFsdWUgaXMgJ2RlcHJlY2F0ZWQnIG9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7ICdvYnNvbGV0ZScuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPkkndmUgYmVlbiBjb25mdXNlZCBmb3IgYSBsaXR0bGUsIHRoaW5raW5nIHRo
aXMgc2VjdGlvbiB3YXMgYWJvdXQgdGhlIElFVEYgZG9jdW1lbnQgbGlmZWN5bGUgbWFuYWdlbWVu
dCBhbmQgdGhlIG9ic29sZXRlIGRvY3VtZW50IHRhZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Q
cm9wb3NhbDogJnF1b3Q7T2JqZWN0cyBMaWZlY3ljbGUgTWFuYWdlbWVudCZxdW90OyBvciAmcXVv
dDtZQU5HIE9iamVjdHMgTGlmZWN5Y2xlIE1hbmFnZW1lbnQmcXVvdDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFlBTkcgb2JqZWN0cyBzdGF0dXMgc3RhdGVt
ZW50IE1VU1QgYmUgcHJlc2VudCBpZiBpdHMgdmFsdWUgaXMgJ2RlcHJlY2F0ZWQnIG9yPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICdvYnNvbGV0ZScuIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPi0gc2VjdGlvbiA0Ljg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsgVGhlIGNvbnRhY3Qgc3RhdGVtZW50IE1VU1QgYmUgcHJlc2VudC4mbmJzcDsgSWYgdGhl
IG1vZHVsZSBpcyBjb250YWluZWQgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgYSBkb2N1bWVudCBpbnRlbmRlZCBmb3IgU3RhbmRhcmRzIFRyYWNrIHN0YXR1cywgdGhlbiB0
aGUgd29ya2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBncm91cCB3ZWIg
YW5kIG1haWxpbmcgaW5mb3JtYXRpb24gTVVTVCBiZSBwcmVzZW50LCBhbmQgdGhlIG1haW48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZG9jdW1lbnQgYXV0aG9yIG9yIGVkaXRv
ciBjb250YWN0IGluZm9ybWF0aW9uIFNIT1VMRCBiZSBwcmVzZW50LiZuYnNwOyBJZjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhZGRpdGlvbmFsIGF1dGhvcnMgb3IgZWRpdG9y
cyBleGlzdCwgdGhlaXIgY29udGFjdCBpbmZvcm1hdGlvbiBNQVkgYmU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgcHJlc2VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J
IHdvdWxkIGFkZDogTm8gbmVlZCB0byBpbmNsdWRlIHRoZSBXRyBjaGFpciBjb250YWN0cy48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tIHNlY3Rp
b24gNC4xMDxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBzZXBhcmF0
aW9uIG9mIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgb3BlcmF0aW9uYWwgc3RhdGUgU0hPVUxEIGJl
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyZWQgY2FyZWZ1bGx5
LiZuYnNwOyBJdCBpcyBzb21ldGltZXMgdXNlZnVsIHRvIGRlZmluZSBzZXBhcmF0ZSB0b3AtPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxldmVsIGNvbnRhaW5lcnMgZm9yIGNv
bmZpZ3VyYXRpb24gYW5kIG5vbi1jb25maWd1cmF0aW9uIGRhdGEuJm5ic3A7IEZvcjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzb21lIGV4aXN0aW5nIHRvcC1sZXZlbCBkYXRh
IG5vZGVzLCBjb25maWd1cmF0aW9uIGRhdGEgd2FzIG5vdCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyBzY29wZSwgc28gb25seSBvbmUgY29udGFpbmVyIHJlcHJlc2VudGlu
ZyBvcGVyYXRpb25hbCBzdGF0ZSB3YXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgY3JlYXRlZC4gPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+V2hhdCBh
Ym91dCBOTURBPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgc2VjdGlvbiBpcyBub3QgaW5s
aW5lIHdpdGggNC4yMy4zPG86cD48L286cD48L3ByZT4NCjxwcmU+QnR3LCBpbiBjYXNlIGEgWUFO
RyBzdXBwb3J0cyBOTURBICwgUkZDNjA4N2JpcyBzaG91bGQgaW5jbHVkZSB0aGUgZ3VpZGVsaW5l
IGlzIHRoYXQgaXQgbXVzdCBiZSBjbGVhcmx5IG1lbnRpb25lZC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5UaGUgZXhhbXBsZSBvZiB0aGUgYWJzdHJhY3QgaW4gPGEgaHJlZj0iaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o
dG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJmYzcyMjNiaXMtMkQwMyZhbXA7ZD1Ed01EYVEm
YW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05
emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJ
ZWdXbE40TUl6TmtidWJJWGl3UERqX1VrX3FZeHF5TEFfbWMmYW1wO3M9UnBTRWVydkhkY0RRbFMw
QWstNVRWYmYzSV9vUjViWHZoR1I2OGRqdlBTbyZhbXA7ZT0iPmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzPC9hPiBjb3VsZCBiZSBtZW50
aW9uZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBZQU5HIG1vZGVs
IGluIHRoaXMgZG9jdW1lbnQgY29uZm9ybXMgdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIGRl
ZmluZWQgaW4gSS1ELmlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5JbiB0aGUgc2FtZSBzZWN0aW9uIGFib3V0ICZxdW90O3RvcC1sZXZlbCBk
YXRhIGRlZmluaXRpb25zJnF1b3Q7LCBhbnkgZ3VpZGVsaW5lcyBpbiBjb25uZWN0aW9uIHdpdGgg
PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEcnRnd2ctMkRsbmUt
MkRtb2RlbF8mYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u
ZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklT
bGFKZGNabyZhbXA7bT1MdE8yUlFRSWVnV2xONE1Jek5rYnViSVhpd1BEal9Va19xWXhxeUxBX21j
JmFtcDtzPXV1QzYyZU0yc09CVlF4eFZUeWsyVWN4QW5PaVRxeWRUYXlpN2o3NjRlOHcmYW1wO2U9
Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLWxuZS1t
b2RlbC88L2E+IGFuZCBzY2hlbWEgbW91bnQ/PG86cD48L286cD48L3ByZT4NCjxwcmU+VG9vIGVh
cmx5PzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PkluIHNlY3Rpb24gNC4yMywgYWRkIHRoZSBbPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0
LTJEaWV0Zi0yRG5ldG1vZC0yRHJmYzYwODdiaXMtMkQxNi0yM3JlZi0yREktMkRELmlldGYtMkRu
ZXRtb2QtMkRyZXZpc2VkLTJEZGF0YXN0b3JlcyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUx0TzJSUVFJZWdXbE40TUl6TmtidWJJ
WGl3UERqX1VrX3FZeHF5TEFfbWMmYW1wO3M9c3pZYlJYcFhuMDlFNEptaEdMTC04LVRlLW43dGNB
NURTbGh6U3E2cVNVYyZhbXA7ZT0iPkktRC5pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXM8
L2E+XSByZWZlcmVuY2UgbmV4dCB0byBOTURBPG86cD48L286cD48L3ByZT4NCjxwcmU+SW4gc2Vj
dGlvbiA0LjIzLjM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PTEQ6PG86cD48L286cD48L3ByZT4N
CjxwcmU+KGIpIEZvciBwdWJsaXNoZWQgbW9kZWxzLCB0aGUgbW9kZWwgc2hvdWxkIGJlIHJlcHVi
bGlzaGVkIHdpdGggYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgTk1EQS1j
b21wYXRpYmxlIHN0cnVjdHVyZSwgZGVwcmVjYXRpbmcgbm9uLU5NREEgY29uc3RydWN0cy4mbmJz
cDsgRm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIHRoZSAm
cXVvdDtpZXRmLWludGVyZmFjZXMmcXVvdDsgbW9kZWwgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf
aHRtbF9yZmM3MjIzJmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhl
TUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mYW1wO209THRPMlJRUUllZ1dsTjRNSXpOa2J1YklYaXdQRGpfVWtfcVl4cXlM
QV9tYyZhbXA7cz1IckFmX1Z3eHAyWlQxRkJZMkdjYlBGUExMcm9iNER0YXAyTjBJcEc3V0VJJmFt
cDtlPSIgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1vZGVsIGZvciBJbnRlcmZhY2UgTWFuYWdl
bWVudCZxdW90OyI+UkZDNzIyMzwvYT5dIHdpbGwgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgcmVzdHJ1Y3R1cmVkIGFzIGFuIE5NREEtY29tcGF0aWJsZSBtb2RlbC48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5ORVc6PG86
cD48L286cD48L3ByZT4NCjxwcmU+KGIpIEZvciBwdWJsaXNoZWQgbW9kZWxzLCB0aGUgbW9kZWwg
c2hvdWxkIGJlIHJlcHVibGlzaGVkIHdpdGggYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsgTk1EQS1jb21wYXRpYmxlIHN0cnVjdHVyZSwgZGVwcmVjYXRpbmcgbm9uLU5NREEg
Y29uc3RydWN0cy4mbmJzcDsgRm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IGV4YW1wbGUsIHRoZSAmcXVvdDtpZXRmLWludGVyZmFjZXMmcXVvdDsgbW9kZWwgaW4gWzxhIGhy
ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
dG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3MjIzJmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209THRPMlJRUUllZ1dsTjRNSXpOa2J1YklY
aXdQRGpfVWtfcVl4cXlMQV9tYyZhbXA7cz1IckFmX1Z3eHAyWlQxRkJZMkdjYlBGUExMcm9iNER0
YXAyTjBJcEc3V0VJJmFtcDtlPSIgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1vZGVsIGZvciBJ
bnRlcmZhY2UgTWFuYWdlbWVudCZxdW90OyI+UkZDNzIyMzwvYT5dIGhhcyBiZWVuIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO3Jlc3RydWN0dXJlZCBhcyBhbiBOTURB
LWNvbXBhdGlibGUgbW9kZWwgaW4gW1JGQzcyMjNiaXNdLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgYmVsaWV2ZSBbSS1ELmlldGYtbmV0bW9k
LXJldmlzZWQtZGF0YXN0b3Jlc10gc2hvdWxkIGEgbm9ybWF0aXZlIHJlZmVyZW5jZTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0gc2VjdGlvbiA0
LjE0LjIgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+U29tZXRoaW5nIHdyb25nIHdpdGg6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyZuYnNwOy10b3AtbGV2ZWwgc2libGluZ3MgYXJlIG5vdCBvcmRlcmVkIC10b3AtbGV2ZWwg
c2libGluZ3Mgbm90IGFyZSBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
c3RhdGljLCBhbmQgZGVwZW5kcyBvbiB0aGUgbW9kdWxlcyB0aGF0IGFyZSBsb2FkZWQ8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tIHNlY3Rpb24g
NC4xNzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRpc2N1c3Npbmcgd2l0aCBZQU5HIGRvY3RvcnMg
dGhhdCBhIGZlYXR1cmUtcGVyLWxlYWYgaXMgbW9zdCBsaWtlbHkgdGhlIHdyb25nIGFwcHJvYWNo
LCBKw7xyZ2VuIGNhbWUgdXAgd2l0aCB0aGlzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9MRDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgWUFORyAmcXVvdDtmZWF0
dXJlJnF1b3Q7IHN0YXRlbWVudCBpcyB1c2VkIHRvIGRlZmluZSBhIGxhYmVsIGZvciBhIHNldCBv
ZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvcHRpb25hbCBmdW5jdGlvbmFs
aXR5IHdpdGhpbiBhIG1vZHVsZS4mbmJzcDsgVGhlICZxdW90O2lmLWZlYXR1cmUmcXVvdDsgc3Rh
dGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlzIHVzZWQgaW4gdGhl
IFlBTkcgc3RhdGVtZW50cyBhc3NvY2lhdGVkIHdpdGggYSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUg
c2V0IG9mIFlBTkcgZmVhdHVyZXMgYXZhaWxhYmxlIGluIGEgbW9kdWxlIHNob3VsZCBiZSBjb25z
aWRlcmVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNhcmVmdWxseS4mbmJz
cDsgVGhlIGRlc2NyaXB0aW9uLXN0bXQgd2l0aGluIGEgZmVhdHVyZS1zdG10IE1VU1Qgc3BlY2lm
eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbnkgaW50ZXJhY3Rpb25zIHdp
dGggb3RoZXIgZmVhdHVyZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIHRoZXJlIGlzIGEgbGFyZ2Ugc2V0IG9mIG9i
amVjdHMuLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5ORVc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsgVGhlIFlBTkcgJnF1b3Q7ZmVhdHVyZSZxdW90OyBzdGF0ZW1lbnQg
aXMgdXNlZCB0byBkZWZpbmUgYSBsYWJlbCBmb3IgYSBzZXQgb2Y8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsgb3B0aW9uYWwgZnVuY3Rpb25hbGl0eSB3aXRoaW4gYSBtb2R1bGUu
Jm5ic3A7IFRoZSAmcXVvdDtpZi1mZWF0dXJlJnF1b3Q7IHN0YXRlbWVudDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpcyB1c2VkIGluIHRoZSBZQU5HIHN0YXRlbWVudHMgYXNz
b2NpYXRlZCB3aXRoIGEgZmVhdHVyZS4mbmJzcDsgVGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uLXN0bXQgd2l0aGluIGEgZmVhdHVyZS1zdG10IE1VU1Qg
c3BlY2lmeSBhbnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW50ZXJhY3Rp
b25zIHdpdGggb3RoZXIgZmVhdHVyZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBzZXQgb2YgWUFORyBmZWF0dXJl
cyBkZWZpbmVkIGluIGEgbW9kdWxlIHNob3VsZCBiZSBjb25zaWRlcmVkPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNhcmVmdWxseS4gVmVyeSBmaW5lIGdyYW51bGFyIGZlYXR1
cmVzIGluY3JlYXNlIGludGVyb3BlcmFiaWxpdHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsgY29tcGxleGl0eSBhbmQgc2hvdWxkIGJlIGF2b2lkZWQuIEEgbGlrZWx5IG1pc3Vz
ZSBvZiB0aGUgZmVhdHVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtZWNo
YW5pc20gaXMgdGhlIHRhZ2dpbmcgb2YgaW5kaXZpZHVhbCBsZWFmcyAoZS5nLiwgY291bnRlcnMp
IHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2VwYXJhdGUgZmVhdHVy
ZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7IElmIHRoZXJlIGlzIGEgbGFyZ2Ugc2V0IG9mIG9iamVjdHMuLi48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5iYWNrIHRvIHNl
Y3Rpb24gNC41PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIGEgZGF0YSBk
ZWZpbml0aW9uIGlzIG9wdGlvbmFsLCBkZXBlbmRpbmcgb24gc2VydmVyIHN1cHBvcnQgZm9yIGE8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgTkVUQ09ORiBvciBSRVNUQ09ORiBw
cm90b2NvbCBjYXBhYmlsaXR5LCB0aGVuIGEgWUFORyAnZmVhdHVyZSc8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgc3RhdGVtZW50IFNIT1VMRCBiZSBkZWZpbmVkIHRvIGluZGlj
YXRlIHRoYXQgdGhlIE5FVENPTkYgb3IgUkVTVENPTkY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgY2FwYWJpbGl0eSBpcyBzdXBwb3J0ZWQgd2l0aGluIHRoZSBkYXRhIG1vZGVs
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5F
VzogPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgYSBk
YXRhIGRlZmluaXRpb24gaXMgb3B0aW9uYWwgd2hpY2ggZGVwZW5kcyBvbiBzZXJ2ZXIgc3VwcG9y
dCB0aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgWUFORyAn
ZmVhdHVyZScgc3RhdGVtZW50IFNIT1VMRCBiZSBkZWZpbmVkLiZuYnNwOyBUaGUgZGVmaW5lZCAn
ZmVhdHVyZSc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgU0hPVUxE
IHRoZW4gYmUgdXNlZCBpbiB0aGUgY29uZGl0aW9uYWwgJ2lmLWZlYXR1cmUnIHN0YXRlbWVudDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyByZWZlcmVuY2luZyB0aGUg
b3B0aW9uYWwgZGF0YSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMgY3VycmVudGx5IHVuZGVyIGRpc2N1c3Npb24g
d2l0aCB0aGUgWUFORyBkb2N0b3JzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_--

--_004_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=14008;
	creation-date="Thu, 25 Jan 2018 12:45:12 GMT";
	modification-date="Thu, 25 Jan 2018 12:45:12 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAABJwAAADaCAIAAABsAs/pAAAgAElEQVR4nO2dPW7rutaGNYg0Fwi+
xoCA1KdxlVoNb5eUdwAXcMn6tHsARloWtztTCOARaCyZgr5CprQokZTo2KZ+ngcvsB2JIpcoJ+S7
uSQVTdM0TfMDAACwQhoAAIDdU7T/5B6UAQAAbiHvIAoAALAEMHUAALBi8g6iAAAAS+Cppu5yOhRF
dX5OYwAAsAPyDqK1LotCmbxBAADA7nn2St3ldMDVAQDAvcg7iDZNU+sSVwcAAHl5evrlucLUAQDA
vcg7iDZN0xiFqQMAgLxg6gAAYMXkHUSbBlMHAAD5wdQBAMCKyTuINg2mDgAA8vP8p19eTgcelgIA
APch7yDaNE37tBR8HQAAZISVOgAAWDF5B9GmYaUOAADyg6kDAIAVk3cQbRpMHQAA5AdTBwAAKybv
INo0mDoAAMgP76kDAIAVk3cQbXhPHQAALICnmrrL6VAcTpfnNAYAADsg7yBa67IodZ03CAAA2D3P
f/olAADA3cg7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsDU
AQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsht6s5VURRre3Pd5XQoFv9uhlX2LABAKnkHUQ9GFUWx
tjfX1bosFv9uhlX2LADAc8ht6n5+fs7VDdbjcjpkdVWXU7VsU3eulu46AQDuQd5B1I9RN1iPWpdZ
XVWt1bJNnVFLd50AAPlYq6nLDaYOAGAR5B1E/dxk6nKDqQMAWDFPNXWX06G4UlWd6ThX1flc2e3S
33VbnVxHW8vYtPjrF9VM5Uy2KYtV1UZyPa4Lqa+nOk+ZujaUa1XueYko+y6Y125CziemDgD2Qd5B
tNal/QOtVGc6jFLGKLvdiPLdVifX0dYyNi3++kU1UzmTbcqiUm0k1+O6kPp6lJkydW0o16rc8xJR
9l0wr92EnE9MHQBAmOeZusvp0PuUy+ngOJr+s7RivS1xfhiWjNfvFDxXU7eZ2Zbsv5fToTr/uPme
8p46YdEG/s09xz6Iy/ksTsuWDrWbGn+wfwAANknGEbTWZe9Tal06jqb/LK1Yb0ucH4Yl4/U7BY2a
us3MtmT/rXWpTOPme8p76oRFG/g39xz7IGpjxGnZ0qF2U+MP9g8AAHQ8zdSFl7Zk+mVnZUZJmcPj
h6YlVL9Y5hqYLj+2XVv/NaKp5j305zL67Ikm0G5y/PaksXQAsA/yDaDhpS2ZftlZmVFS5vD4oWkJ
1S+WucaLZpFobP3XiKaa99Cfy+izJ5pAu8nx25PG0gEAhNmBqUuzN482dc5amygSNnW32TNW6gBg
H+QbQPOZujR782hT56y1iSJhU3ebPWOlDgAgzFPTL4XNEMmSflM3cCUjz+ZLv/TWPz9j0YlmaK6k
RXMyK4OETJ2TVDq5Upcaf38emDoA2AMZR1D3eZUiWdJv6gauZOTZfOmX3vrnZyw60QzNlbRoTmZl
kJCpc5JKJ1fqUuPvzwNTBwAQ4qkPSpGphP3CVfdjl5c42De6Uy2Ujuipf3xIzOuIaM5VW/b6xJOz
W011mnhVnTwX97zkc1Kqqq082m5C/M6pYOoAYA/kHURlKmG/cNX92OUlDvY5SYfhe9i89Y8PiXkd
EY1RbdnrE0+MW43SE6+qk+finpd8TopSbeXRdhPid04FUwcAEGIBrzSAR4CpA4B9kHcQheeBqQMA
CIOp2yrtaxLW9wZAAIAk8g6i8ETa1ySY3GEAACwRTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwB
TB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTN0N
XCbePL4u7LvNhycU2j4Br1IAgKeSdxDdCvXEm8fXhX23+fCEQtsn4FUKALACMHW3cTlVWzF1LaGX
lae+xJyXngPAc8k7iG6IWqutmLqW0MvKU19izkvPAWANYOpuA1OXWA8AwGPIO4huCExdYj0AAEti
0abOJgAWRVFVnVkQWwf+4Vx5isvNU6mEbepgVRVFUVTn63FdKqGo/jxl6togr1W5+Yie+Oe2O50K
GWpXJEVe2x9kSGLqAGCd5B1EU7EJgEVRKNWZBbF14B+M8hSXm6dSCdvUQaWKoiiUuR7XpRKK6s2U
qWuDvFbl5iN64p/b7nQqZKhdkRR5bX+QIYmpA4A9sVxTdzkdeuNxOR06Q3M5n4Vd672JsBOyuOMy
nAO8nKv2SPvv5XSozm2VTvW2fmHRBj4qFIQ//lC7ofjT2z1X/al3tYvzxtQBwBrJO4gmUeuyNx61
LjtDUxsj7FrvTYSdkMUdl+Ec4MWo9kj7b61LZdoqnept/cKiDXxUKAh//KF2Q/Gnt2tUf+pd7eK8
MXUAsB8Wa+rCS2GunfEvgXmXucZHeLDWx5qTq/0ZhjPDu0jjNPjsiSbQbnL84XafYOqsIwUAeBp5
B9EUwkthrp3xL4F5l7nGR3iw1seak6v9GYYzw7tI4zT47Ikm0G5y/OF2n2DqrCMFAFg4qzN1zlrb
2Jv0O67uIn2l6bGmLhR/2NSl2qSMpu6meAEAfkPeQTSFkKlz1trG3qTfcXUX6StNjzV1ofjDpi7V
JmU0dTeUBwDIwWJNnZPvKJIxz4Ob5YRncYuL+9VSHrAfMleODZIZjrET8Jo6f/yhdlPjj5k69xY+
TB0AbIG8g2gSMt9RJGOawc1ywrO4xcX9aikP2A+ZK8cGyQzH2Al4TZ0//lC7qfHHTJ17C59bKaYO
APbEck3dj5t66MtePFTVodvl5ilKy+LmO8Y8h62jOrcfD6fL9ckj50F252niVXVd4ersfPbHH203
If5Yu6KHDqez96xk6fA9e1PXDFMHAM8k7yCaikw99GUvlkqV3S43T1FaFjffMeY5bB3KtB9LXV+f
PGIG2Z164lV1XWFlnM/++KPtJsQfa1f0UKmN96xk6fA9e3EwdQCwBhZt6mB9YOoA4LnkHURh+2Dq
AGANYOrgvvhyOwEAHkbeQRR2gC+3EwBgYWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABg
xeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWzI1NnXZd/n
PWniXea/fj7/ZeJN5esi1M839j+vQACAX5F3EH0s9nXZ93lPmniX+a+fz19PvKl8XYT6+cb+5xUI
AJCBDZm6lvu8/PpyOtzXZ1xO1VZMXUuon1P7n5eVA8DvyDuIPoP7vPy61uV9fUat1VZMXUuon1P7
n5eVA0AOMHUPrEWAqUusBwBgHnkH0WdwH5Nwd6uBqUusBwDgkezB1IlMSrnPpguGN08mX7apg1XV
lru20x3Qt1udp0xd2+q1KrdVT5xz251OhQy1K5Iir+0P+gFTBwDLIO8g+gw8JkFkUsp9Nl0wvHky
+bJNHVSqLXdtpzugb1eZKVPXtnqtym3VE+fcdqdTIUPtiqTIa/uDfsDUAcCa2b6pczacq96cXM7n
i2ezv5ZIe61zsv/axM3L6dBVIe+pG3rG3i1dTgfh2vr2/XGG2g2db3q756rvk3E6KqYOAJZB3kH0
GYxMgrPBqN6c1MbUns3+WiLttc7J/msTN2tddlXIe+qGnrF3S7UuhWvr2/fHGWo3dL7p7RrV98k4
HRVTBwBrZvOmTixbeczMeKu/llh7rpe62p/hytyMCqVxGnz2xBloN3K+qe0+wdRZRwoAcDN5B9Fn
MDQJYtnKY2bGW/21xNpzvdTV/gxX5mZUKI3T4LMnzkC7kfNNbfcJps46UgCAJ7MDUxcyH0XEsyzH
1IXiDJu6VJuU0dTdFC8AgCTvIPoMxqYuZD6KiGdZjqkLxRk2dak2KaOpu6E8AMA92LypG6dWjsud
q7uv1Lk2SGY4BgmZOn+coXZD55varmzZ99YBTB0ALIO8g+gz8KRfeteq3ETDu6/UuTZIZjgGCZk6
f5yhdkPnm9qubNn31gFMHQCsmc2YuvA9Y4Nd1kPI549U1aEYPBdkVvaizXWszu3Hw+lyffLI2a2o
Ok28qq4rXJ2dz/44o+0Gzje1XZHJeTidvWclS0f6PwqmDgB+R95B9JGE7xkb7LIeQj5/RKmyGDwX
ZFyNB5vrqEz7sdT19ckjxq1I6YlX1XWFlXE+++OMths439R2RSZnqY33rGTpSP9HwdQBQA42Y+pg
nWDqAOB35B1EAYZg6gAgB5g6yIsvtxMAYDZ5B1GAEb7cTgCAB4OpAwCAFZN3EAUAAFgCmDoAAFgx
eQdRAACAJYCpAwCAFZN3EAUAAFgCV1P33XyjG/RP3SCEdqLsf3CQV+EB7g+6QfkjQAg9S7nbRyFh
6p6u7LNMhNDTlP0PDvIKU3df5Y8AIfQs5W4fhYSpe7oeNX38W/3rP3X2KSxCSCr7HxzkFabuvsof
AdqSjHrRdf4wUEC520chYerGMseiKI7mUfX/Uzf//E//qyiKd/PP36ooinuYsfrf/6f+m1a+KP5P
/8k95Y3pb9W9vfWvv3MHczeZv4qiKJIuFv2cqPb3a/ybFdoeui43/p6av9qj6uYfTN1StTtTZ96K
olDmUfX/aZo/tX5p2zCqKArfpLx+L4ui1Kf83ZEej+n/Tr6Z7JE/Uu119F/BiX74UOV7fZfroj7S
yi/qe+XT8r8/07+/vbIHiwLC1HlljkfzqMq7ad+//lO3s8Y7zKT/p/9lJ5GzVf/7fcmmLtWm3kf/
fX90o0uz01vt5/DatX+797rc9Hvq1p//rxnyaXemrvnTmLfHmrrGvLVzwVq/BGeu9bv61eT7pMu7
ruHMjCfVZqxf/rWyaD/U+uUuzqrWL8nf1N9+rx6sPN+fD5XUaPT31/0+5O9R5BemzqunmLq//m6X
Asp//+/3U+QbKlm4qTN/5XA+CWZDLHB1zFnM+e97v4yzAC2+n29WmqnzXpebfk8xdWsQpu6+ujbQ
zgVr/VKEVmyWNvmeGY95W/hC0N3lN3Wxfjjp8i5rUDct9y3te5XQb4/TDaYu+PuLqVuHdmzqvvRr
URSF0s6P5edX05o6fbxO1I+6P6rbaEs239/152tRFOroK+/RP3XzT13/+//aOaL56/eZeM4yXZv6
pa65ZFfj0TXR5pi1iXZTpu6ae6bsISJOm8YmbMzcducsUv35T+lYJTHV/u+7p562/L/+U9sDy3//
LxqPJ35n43yHdoP+/Kd0aqaf4/0c6p+/VWFXz67xDCxZoqkbXpe6ufH3FFO3Bm3V1F1T5+xc7vpj
O0Mzb8p82P+LktPvj/4/qLq5XP1eFkWh3nzlPbLH2JYKOZs0b0VXi5x899tl7txJl0VRvOi6/dDH
5E0L7LLabNrY9XO4/nA8ftkwCrfycJyyQ6/ttsmv6q29Ntc4pyfco3om2p2uRynhLkL9c+3YgakL
9YNVd/V//Q3ua473W8p1vOYWKnuI6Hz7vRJfrbntzsn5jPTb7OsbjccTv7NxuCuo0O+v5/vwy4uM
HqYdm7rv5utTWWPWfH8331/6+Fl/fzftbXWv3edX/dUW0MpubMtYQ/hdf776ynv1CJPgJoaZv9pV
hb9VOyO3BboZauMmm9X//j/3t9+ZlNtD5FT1f+a/dtXiv+9dWlqoXXch8W9lJ9/hdtvaRrbkv+/C
ANhW3Kl/W7P579+xeALxtz/muNuNfr7te/i36uscZyAnmrq7CVO3Bm3V1DXNSStnal3rNzFT7Wet
3TTSma3J6Vz9XvrKexUOSM71nXufnAUZoxyT0N3e0zR/GvNhRIXjFSRpA8TeQP2heFoX6/z9cXyp
9/x9cX4oMYE2Svi68r3ut9h1rWC7gXpC7YbjF31y0uWs/vf2c/x7UOuXGTZ1xtd3sNwX6bfE6ygX
oOTZ1eZDuHHbeqjdyPcq7fuTeH2D8QTib3/8/RURDtbyZjbwd3Kr2rWp+9bqqJtvrdplt6/P0i6y
yfTL+vP1at7EMt0VW74v43726d6TyPGk3PzVzm7t5PI6yf6f/suZy87Iu5MT5cFn0Qu92fC2K5eP
BpP1287L6s9/VO9hhmcXiScUf/PPU9Iv6ee0fo70zwJN3cADY+qWqu2auj9GvZl2Bat8r+UkWaZf
9vf4fIz+kNny8j6gqXuCgjt6T2mDkItX7t+rj+BRzumNzUY3eRWz2ED9wXjiCpq6UZzDJFdrsu12
G/9UsmKonqn+8Uj6jan+ifbzhKm7Q4bhuP5Av91wHaX5H3z2fPtD12uq31LPa+71DX9//PE3f+5j
6vzfh3vViu6tfZu6L338rL8+tf7Sx89aHzszFjJ1pbOy1yufqRst04Un2XczdU4qmgggbDZuuWvr
cWYjFH/zT8aVOvo5uX8WaepG9Wf/K4e82rCpq/Wbrk9af9T6TdeOzfGbuvDtb481dZFZeKKpu24c
ZO7NsmF7MHVOwC9z+j/Uzw9eqfP1yaNNnZNq6PkvkLGpu8W7Ps7UheJv/mDq9qh9m7rv+vNTfx71
V3tfXJ826Td131oFXnVwT1MXeuS9d7v30YWhSbZT+M9/yunbrkJmoz/QPkki1u4w9W6evGmB8mEV
7j2BSWbDH/+gieGuB4p+jocdNnXurYbGOQpTh8LasKlr6net35U+DZ/07jd1nsy7cZnbTZ17pJv+
F75RL9XUNfV7qd5cexqoPxhPVPNN3cAld/d6pZq6UD1T/ROvR6ynxfo/2M8RS+O9p868+deyvNu9
X7JQv6Vfx5Cpc28ynDJ1U/02+/uTeH3nmEwZ/6AJd5eT3jlPmLp1aOemrtFHey9cf7+cuWZZHo19
CErRPU/l61OmTbcLd7LMsLxH05Ps+abOMz21OXji5VrtYyTsQ/ws73ri2fpd4XfjfHYesFH+9d5W
Hm13cLvUlJkMP8DDyTC0TmB4L5aTi+iLxxf/6Kzv8VTSWaKf4/0c7h8RZ/nvv7ub/UL35sXvLbyf
MHVr0JZNnbhbp5+J2awxZUQ63nVW7D7KoZ0HyjLD8h7FApLpYUoHb38K3BMlkkGHv7+DdEHfozvG
9Ufi8SvwoItQnKKv++2i9+1LwNpqJxbrZvTDpMFw82tlp83q/8C3xGMJ/Ots4ysV2u6xkdF+S7qO
XWFlnM/OeZVvqq08fr0C36u070/S9Y3F44t//Kvn+O2TLudljQb1i0PRQ7V3U5dB95s+5nnDGEIo
JkzdGrRpU5dB+SNA2fWr2+r29ybAbJJPQLpR+U8C+YWpe7ryTzoRQg+Ukwua/Q8O8gpTd1/ljwAt
QDe9Yg49Wb43FiQq/0kgvzB1T1fuGSdC6HnK/gcHeYWpu6/yR4AQepZyt49CwtQ9XdlnmQihpyn7
HxzkFabuvsofAULoWcrdPgoJU/d0ZZ9lIoSepux/cJBXmLr7Kn8ECKFnKXf7KCRMHUIIoZ0JS4fQ
8pW7fYTWJUwdQgihnQlTh9Dylbt9hNYlTB1CCKGdCVOH0PKVu32E1iVMHUIIoZ0JU7dctW9MFu9Z
FntDL7POJ6Pc90SvX/aN1cNXmYW2B6+LefO+ti52fW1V9g3d2TsDoVUJU4cQQmhnwtQtWOatnevX
+mXolOr3sihuf8P13ZXnldkf6vGNGuV/P7V/u/+6nHTpM7qR6zus/+ldi9CqhalDCCG0M2HqFizz
1s71a/1SDF9m/aH6ZZwFKLAY9WAtz9QFrkutXzz9E7u+mDqEfiFMHUIIoZ0JU7dg1e9lO9c3b6NM
y5MuHVNxzeVTb9cUSFHepguKHL82tU9dcwWvmZPdIcZWMmsx8KTLQiIszYfy1NOWf9G1PbB8r6Px
eOJ3Ng53eRXqH6O6fNFrPANLlmjqhtdleCnnXl9MHUK/EKYOIYTQzoSp247kgo+0BLX5sHbiQ3Vp
fuatLWxU67i6FMEPJeyHUdbk1O+ud3PvHPOs1H0oYbRsKyLUzj6ZDxOLJxB/++N4pS4cZ6h/jOrr
rPXL70xdSIPIp4WpQ+h2YeoQQgjtTJi67UgaksFnYXF6U9cWsObBmiixTOcxbyGNTZ2t3+qkVe8V
a/02fi6IP55Q/M2f1PTLUP88y9QllB94YH4jEUoTpg4hhNDOhKnbjvymxUntE0/sCJu6W+6Oe5yp
C8Xf/FmbqWOlDqFnCVOHEEJoZ8LUbUchU9fbLftkjvZzYGUs2X4MW7nKSeNs6nflpF8mmDp//IMm
hrtm94+0T85bBEZ7m1nb/fLeUxcVpg6h24WpQwghtDNh6jaiLkdRGeez8yCT8k2VRVG8GZtjKV6S
1hZ7M83wtrSphbvwg1KcTE7ruIb3vDk5n754fPGPznr89MjZ/SPiLN9Nd7Nf6N68+L2F4dZT1z8x
dQjdLkwdQgihnQlTh9CjFXhPXVSYOoRuF6YOIYTQzoSpQ+jBuvU2RbHsmf8kEFqTMHUIIYR2Jkwd
QstX7vYRWpcwdQghhHYmTB1Cy1fu9hFalzB1CCGEdiZMHULLV+72EVqXfmHqfgAAAFbIbYMfAADA
lsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEtikqbucDkVxOF1yxwEAAI8m7yD6LGpdFkWp69xx
AADAMtmkqfv5+bmcqqeausvpMN9FnqvqfI96AAAg7yD6RGqtnmrqal3Od5FGKXOPegAA4DYwdRmI
mDoAAEgi7yD6RJ5t6pKImDoAAHgCWzJ156q4Up2lqeu3D3IyxQFVJXZdTofxjnbj4XSxe+0Bw5+7
mg+nc1fRsLAnIl89wzi7fW3hqrJ7cIkAsFPyDqIPxij7518Zaer67YOcTHGAUmJXrcvxjnZjqWu7
1x4w/LmrudSmq2hY2BORr55hnN2+trBSdg8uEQAggc2YOpm36NxTd5Z27Vz19kfsuJwOju3qysgd
P52Vaveez9JIOc1cmypkY8J3xVbqfPUcpD/1Bj06CgBgJ+QdRB+JzFt07qkz0q4Z1dsfsaPWpWO7
ujJyR9NZqXavMbbUqJlrU4VsTPiu2Eqdr55S+lNv0KOjAAAgwlZM3TDdsnM5YpluuKglV83Exkje
ZmSnz4xVrusTDm++qRuW7UO4nA7yVFirA4BdkncQfSDDdMvO5YhluuGillw1ExsjeZuRnT4z5lg3
4eRSTN2wbB9CrUt5KqzVAQDMZgembs4aVr/Od0dTF3RnmDoAgHuRdxB9IBFTN2cNq1/nu6OpC7oz
TB0AQF62YupcW+NmJvpvODsP7qIT6ZeDhEtZb9JKXeEkfsr0y27HuSqGC3pRcygiwNQBAGzY1Lm2
xs1M9N9wZgZ30Yn0y0HCpaw3aaWucBI/Zfplt8OoYrigFzWHIgJMHQDArWzG1A2yKU/itjr34STC
7PlyMoe77I7hE05C2/tb7qrD6RR4RMtl9ACVcD2DSK9bu+LV2fkMALAz8g6ij8XJptTitjr34STC
7AkGxmq8Y/iEk9D2/pY7VWodeERLPXqASrieQaTXrV1xZZzPAAAwgw2ZuoXBs0sAAJ5A3kF0V/Ds
EgCAxYKpexSYOgCAJ5B3EN0VmDoAgMWCqXsInjfLAQDAA8g7iO4Hz5vlAABgMWDqAABgxeQdRAEA
AJYApg4AAFZM3kEUAABgCVxN3XfzjRBCCK1O4QHuD0IIIbRCYeoQQgjtTJg6hBBC2xKmDiGE0M6E
qUMIIbQt7dzU1Z+vRVEo/W2ORVG86q/8IaHHSKvXz/rmw/Wx/PzKfQoIoXsJU9erfi+LolAfjXkr
iqLUp/whocfIqBdd33z4hyrf69yngBAKa+emrtHH1svVn69FcTTf383XZ1kUhTQA+lgUxYw5/Zd+
nW8LtTrq/Kd/k1on3POoE0nqz+mYr1cwfH2j5/WlX48md88jhO4kTJ3Qh2q9XP1eFoUyf5rmpMui
KKQB+FBFUcyY09f6Zb4tNOrN5D/9m9Q64Z5HnUhSf07HfL2C4esbPa9avyiTu+cRQkFh6lovV3++
9hN9fSxfj9ZOfOnX1/L4i0Uev1Zs6prv7/qz65/v+vP1Yb7uXnItWfj6Rs6rt4UIodULUyf0oVov
V7+X/UT/Q5UvytqJWr+U5dsvFnn8WrGpa/409XvXP039Xj7M191LriULX9/IefW2ECG0QO3d1H19
lq2X08d+Bq+P6vNTdQs7x0/dT/q7xRxnEclu92xUx+Ng5We4IiSP0sdua2chQvWE4omUb76/dHfE
8aiEjx23G5E0P833tzl2rWs1qEcf+2CO2hxDXXF7fyZc5enrGzqvUSWxzkm5XtH+Sb0uCKF5wtQJ
nXTZerkP1c/gP5R616pb2HnTup/0d4s5ziKS3e7ZqN7syGDrH64IyaM+VL/VWohQPaF4IuWbP7V+
sUe8KSV87LjdiKT5af405q1rXbxyva3nQ/XBvBnzFuqK2/sz4SpPX9/QeY0qiXVOyvWK9k/qdUFo
v9q7qfNKH5X+aif65viqv776Sb/WdlqvVZuuKeR4gLa8WAB093pX6pz7vsyxUHqinlA8gfJf+tVb
Z7DdkAbmp/58VbqNoY/NHIWve207s93Sr5vdrz/j0bpriZHr6z+vYISxFudfr2D/JF8XhNA8Yeqm
9KHUR91O9M1bqU91P+n/MHZab1QxzMdzPEBbXiwAunu9K3XOfV/mrVAfE/WE4gmUr/WLt85guyEN
zE/9XqqPNoY+NvMmfN1L25ntln7d7H79GY/WXUuMXF//eQUjjLU4/3oF+yf5uiC0X2HqPNJHpdv5
fTur/vKt1BXFPBMiTZTjEMamTizL2BZ0vJ5QPP7yX3Z5ana7IfnNjz66rsP2m91u+0eYurv1Zzxa
N3Mydn3jpi7BRiZcr1D/pF8XhNA8Yeqm9KHURzu/b2fVtW+lrijmmRBpohyHMDZ1YllmsMgTqicU
j7/8yS5PzW43JL/5+VCu67D9Zrfb/hGm7m79GY/WzZyMXd+4qUuwkQnXK9Q/6dcFof0KU+dRO8n+
+iyLdm2kNydiVu15csbvTV0oxc5fTzieVIvde08AABZySURBVFOXmtrnT1NMNXX37M94tOOVOt/1
jadfJq7UJVyvcP+QconQY4Spm1I7yT7psmjXRnpzImbVnidn/N7UhVLs/PWE40k1dampff40xVRT
d8/+jEc7XqnzXd94+mXiSl3C9Qr3DymXCM0Vps6jsDnpJ9n2CSvywDRT59zP1lYVtA0hkxCKJ9Cu
+zzJr89yqt2QHPPz9VlevYr72oDOQ84xLb/tz6jG99R5r2/wvHyVTPRPyvUKrmQmXxeE0Dxh6qYU
Nif9JNs+YUUemGbqnPvZbLpdwDaETEIonkC77vMkT7qcajckx/ycdHn1Ku5rAzoPOce0/LY/oxrf
U+e9vsHz8lUy0T8p1yu4kpl8XRDarzB1Q2n3+Rbdj22eXv+ci6N6LZy3IIzS5LpcO6Wdz21DfSae
a4RkVa0HCNfjjyfarhapDEcTbTek0YNeRD1OxuDRiC3iZYBt2Edz1/6MylkWk3XK62si55Xy9Mu0
6xXrn7TrghCaLUxdVB/u8y26H9s8ve4pIy9KvRTOWxAkb6YRuXbqw/ncNtRn4rlGyPm7915H6/HH
E23XiHFQGAZfuyGNHvTiPFhyuN1uES8DbMNW5q79GZWzLCbrlNfXRM4r5emXadcr1j9p1wWhXQtT
h/agX7+QgPfUIbQlYerQ7vTrFxLwnjqEli1MHdqH3NTQVHF7G0KbEqYO7VBuamiquL0NoYULU4cQ
QmhnwtQhhBDaljB1CCGEdiZMHUIIoW0JU4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0JU4cQQmhn
wtQhhBDaljB1CCGEdiZMHUIIoW0JUxeR6d+kfTS5g1m17Du4X/VX/mBuiPO2+Jf//WnPS7z3PH9I
CD1FmLq5Mm/+91CjVNl3cJf6lD+YG+K8Lf7lf3/a8xLvPc8fEkI3ClMX1NdnedRPb1er5Ea/9Os6
puPmOD/OG/rh4XGmxL+S748+tl6u/nxdrPNE6AHC1M3TSZdv5untGpXcaK1f1jEdN2/z47yhHx4e
Z0r8K/n+fKjWy9Xv5WKdJ0KzhKkLKs/7pnOamUdrX6ZuFd8ffWy9XP35Wvzm5ewIrUyYunnK877p
nGbm0dqXqVvF9+dDtV6ufi+L37ycHaHswtT59KVfC4nS3S6t7EYxZW/Lv+ove+DrZ62PRVGo47Eo
iuKor5l4dsJt0/mcnDexcbgrpHBaYB+nOs5wF7rPFHQKf32WXQLh12dZFOXnlzl2+YTX8+36x3te
nWaaomg/ePs/Vs/1EojOj8Qfj3O2qVvN96f5+ixbL6ePxcANtpcep4e2KUzdpGr94v4d++h2mf7v
WD9lb8uX+mQPfNH1hyqKQr2poiiKN3PNxLMTbpvOV8icN7FxuCukcFpgH6d6m+EuPlTfqix80jYm
ZU66LIryvTZvhV3VuZ5v1z/e8+o00xRF+8Hb/7F6rpdAdH4k/nics03dar4/zUmXrZf7UMXADbaX
HqeH1iJMXVCelRatxETZHB1f0d2e1Hx/N1qb7+9GH9s5sS35pV+Ppi2sdd3Xed14/TF9hWpsNsSW
L/066X+0EnN3c+xMiIjt67N8fVW2HnPsY64/X3tTFzwvf5yxkDz9EOt/r+QClGw9FH88zl+v1C30
++MXpg5tWZi6efKstBglJsrmzfEV3e1JzZ+m+TDmT9N8qHZObEvW+uWa4VZ/mLqvU6a93bJCNTYb
YkutXyb9j1Fi7m7eOhMiYjvp8qVUth7z1sdcv5e9qQuelz/OWEiefoj1v1dyAUq2Hoo/HuevV+oW
+v3xC1OH1iVMXVDjSbk+urP/L33sp7z153E447flrRkQk3JnUeW6sfn+vpepEytsxXAFxnemxYD2
EPd868/XctLUBc8rEGdQvn6I9r9Xg9i6z3lM3VK/PwjtT5i6eRpPyj+UO/uv9Vs/5a3f1XDGb8tb
MyAm5c6iyv1NnVhhK4YrML4zHY6D7SHu+dbvZTlp6oLnFYgzKF8/RPvfq0Fs3ec8pm6p3x+EtiBM
XVCPm5Q7qW79TL35/r6bqROSZmzumXrPVxTzm6LYeU3H6QpT97zvD0L7E6Zunh43KXdS3fqZevOn
uZupE5JmbO6Zes9XFPOboth5TcfpClP3vO8PQlsQpi4ob/qczEb7+lRO+lzCpLyv2T6pwtPEcFdQ
I7PhxDlt6nypktftjnkohKmzLba3fllTFz4vb5zRkDz9EOt/r8Kmzhf/VJx3SL/M+P3Rx1nLtqLr
ihk3LiK0TmHq5smbPiez0U5aOelzCZPyvmb7pApPE8NdQY3MhhPntKnzpUpetzvmoRCmzrbY3vpl
TV34vLxxRkPy9EOs/70Kmzpf/FNx3iH9MuP350PNWrYVXVfMuHERoaUIU+dT+EEXTqbi0bQbZa5j
t92WFC8Ba6s9Gln/61G9Ohl0fWbd5O1Mw3a7KbtWno0JVXVTeZnmpz6FCen64fXT9DeDBc4rGGdM
/n7w9v9UDUo7n4Pxh+JMjn+R359EU2eO3FCHNixM3aTCD7pwMhXF/WZucSNKipeAtdUqI+t/Ueql
kJPvPrNu8namYbvdlN0oz8aEqrqpvEzzU+/ChHT98KJNfzNY4LyCccbk7wdv/0/VoD6cz8H4Q3Em
x7/I70+iqTNv3FCHViVMHZqrGStjaCvSarSAidCGhKlDN2nGyhjaiowaLWAitGhh6tBcYer2I/vg
zfyRIPQQYerQTcLU7Uf2wZv5I0FopjB1aIb6fD9uskIIrV+YOpSqPt+Pm6wQQksUpg4hhNDOhKlD
CCG0LWHqEEII7UyYOoQQQtvSL0zdDwAAwAq5bfADAADYEpg6AABYMXkHUQAAgCWAqQMAgBWTdxAF
AABYApsydZfToSiqc+4wAADgaeQdRB9NrcuiUCZ3GAAAsHA2Zep+fn4upwOuDgBgP+QdRJ9ArUtc
HQAAxNmaqfs5V5g6AID9kHcQfQZGYeoAACAOpg4AAFZM3kH0GWDqAABgCkwdAACsmLyD6DPA1AEA
wBSbM3U/l9OBh6UAAOyFvIPoU6h1ycNSAAAgxuZMHSt1AAB7Iu8g+gxYqQMAgCkwdQAAsGLyDqLP
AFMHAABTYOoAAGDF5B1EnwGmDgAAptiaqeM9dQAAuyLvIPoEeE8dAABMsilTdzkdisPpkjsMAAB4
GnkH0UdT67IodZ07DAAAWDibMnUAALA38g6iAAAASwBTBwAAKybvIAoAALAEMHUAALBi8g6iAAAA
SwBTBwAAKybvIAoAALAEMHUAALBi8g6iAAAASwBTBwAAKybvIAoAALAEMHUAALBi8g6iAAAAS2BT
pu5crfvF42uPHwDg+eQdRB+NUet+8fja4wcAWAuYugWx9vgBAJ5P3kH00azdFK09fgCAtbAVU3c5
HQqHw+kid7Q/dj+cqqIoDqdzd5Qt/vPz83OuRrVEGZc/V0VRVFVVFEVRna/7q/N1h6/dxPhtVO2G
WVECAGySvIPoA6l16Y4Lpa7ljvbH7getiqIotemOssWbpmmMGtUSZVzeqKIolFJFURTKXPcrc93h
azcxfhtVu2FWlAAA0LEVU/fz8xNa6bqcDmJzV6Y1Xuduc9FtFx6p3xxp1Fv+XLVey/7bRRFqNzV+
uw9TBwC7Ju8g+mj8K121LsXmrkxrvEy3uei2C4/Ub4406i1vVOu17L9dFKF2U+O3+zB1AADJ7MDU
Sd91OVXWAA392vVgsex2Je7qQuVtLLZtaep87SbHDwAAP/s0ddJ31VpZAzT0a9eDxbLblbirC5W3
sdi2panztZscPwAA3MwuTF3nqGQBZ4XtR5i6tHWvUPmIqfO2mxw/AAD87NXUdY5KFnBW2Bph6tLW
vULlI6bO225y/AAAcDMbM3UHsQ7nLIidq+rsLnOdKydvUaZlJjmnQPnYSp233dT4f37IvgQA2Lyp
K8U6nLMgZpQy7jKXUU7eokzLTHJOgfKxlTpvu6nxNw3ZlwAAN7IpUyceNzIyOpfTYZj2eH1eyugA
96El05ZpXN7mZFZn+2iUS1uoOkfaTYu/PQcsHQDsnLyD6MOpvQ8+6XYN0h6vz0sZHeA+tGTaMo3L
25xMZeyjUeq2kDKRdtPib88BSwcAcAPbMnURRstcqXmW9+LGdn130w2X8wAA9kfeQTQno2Wu1DzL
e3Fju7676YbLeQAAMI+9mLrx3WjrMnW+u+nsgzUBAHZM3kE0I+O70dZl6nx309kHawIAQCJbN3VO
amRvgfpnVj7XFiW3G4gfAABa8g6iGXBSI3sL1D+z8rm2KLndQPwAAPAbtm7qAABg0+QdRAEAAJYA
pg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJbAJk3d
5XTgUZEAALsg7yD6LGpd8qhIAAAIsklT9+N/V/dj2zvMd5G+l87dUg8AAOQdRJ+I713dj22vnO8i
fS+du6UeAAC4DUxdBiKmDgAAksg7iD6RZ5u6JCKmDgAAnsCWTF3/Zu/qLE1dv32QkykOqCqxS7zx
u9/RbjycLnavPWD4c1fz4XTuKhoW9kTkq2cYZ7evLVxVdg8uEQB2St5B9MH0b/ZWRpq6fvsgJ1Mc
oJTYJd743e9oN5a6tnvtAcOfu5pLbbqKhoU9EfnqGcbZ7WsLK2X34BIBABLYjKmTeYvOPXVnadfO
VW9/xI7L6eDYrq6M3PHTWal27/ksjZTTzLWpQjYmfFdspc5Xz0H6U2/Qo6MAAHZC3kH0kci8Reee
OiPtmlG9/RE7al06tqsrI3c0nZVq9xpjS42auTZVyMaE74qt1PnqKaU/9QY9OgoAACJsxdQN0y07
lyOW6YaLWnLVTGyM5G1GdvrMWOW6PuHw5pu6Ydk+hMvpIE+FtToA2CV5B9EHMky37FyOWKYbLmrJ
VTOxMZK3GdnpM2OOdRNOLsXUDcv2IdS6lKfCWh0AwGx2YOrmrGH163x3NHVBd4apAwC4F3kH0QcS
MXVz1rD6db47mrqgO8PUAQDkZSumzrU1bmai/4az8+AuOpF+OUi4lPUmrdQVTuKnTL/sdpyrYrig
FzWHIgJMHQDAhk2da2vczET/DWdmcBedSL8cJFzKepNW6gon8VOmX3Y7jCqGC3pRcygiwNQBANzK
ZkzdIJvyJG6rcx9OIsyeLydzuMvuGD7hJLS9v+WuOpxOgUe0XEYPUAnXM4j0urUrXp2dzwAAOyPv
IPpYnGxKLW6rcx9OIsyeYGCsxjuGTzgJbe9vuVOl1oFHtNSjB6iE6xlEet3aFVfG+QwAADPYkKlb
GDy7BADgCeQdRHcFzy4BAFgsmLpHgakDAHgCeQfRXYGpAwBYLJi6h+B5sxwAADyAvIPofvC8WQ4A
ABYDpg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYA
pg4AAFZM3kEUAABgCWzI1LXv4K7O7aMneerkhvnd6yI2+rIJ+w764cmFtsfr4fcI1kPeQfSxtO/g
VqZ99CRPndwwv3tdxEZfNmHfQT88udD2eD38HsHW2ZCp+zlX7Rz0cjoURXX+sfNTOS+dO1G9nA7z
p7PnqjrfGHNu7Izf8qgTSerP2XWFr2/0vC6nw8IvWPtKjOuJde/HmNODIcea4GTHv0cAiybvIPpg
jGrnoLUui0KZxs5P5bx07kS11uX86axRytwUcX7sjN/yqBNJ6s/ZdYWvb/S8al0u/IK1r8S4nlj3
fow5PRhyrAlOdvx7BLBBtmbqqnM71e9msOfqcKjsD5fTQfx0x4bXPPW9nPoeuZwOi5/Gu5YsfH0j
53VPi/koztXh0J+oPJmpw+5h6ka/RwDLJe8g+mCMauegtS77+a9RZansD7UuxU93bHjNU99a9z1S
63Lx03jXkoWvb+S87mkxH4VRZdmfqDyZqcPuYepGv0cAW2NLpq6bqp+rfgZ/rqqTnRBfTof+B7lI
5Uxdvelq15y0yi6a2PqHK0LyqP4N5P3WUD2heCLlnSOqqhI+1hdNpNscv3D2VSTXjK7BVOfrbk9X
3N6f0wwMWez6hs4rwdWlXa9o/yRel3NVnXv/ak+mbeEs2h/03B1Mnff3SJ4zTg+WRd5B9MF0U3Wj
+hm8UUrbCXGty/4HuUjlTF296WrXnDRlF01s/cMVIXlU/wbyfmuonlA8kfLOEUop4WN90US6zfEL
xleRXDO6BqPMdbenK27vz2kGhix2fUPnleDq0q5XtH8Sr4tRyvT+1Z5M24IR7Q967g6mzvt7JM8Z
pwdbYEumzks7N65Ol+u8tp/qX87nS1do5CrGk2C5cOHu9a7UOUVkA6F6QvEEyjuLT6JMsN0QA/Nj
jcS5EpP3/gf7yf4rfMfd+jMerbuWGLm+/vMKRhhrcf71CvZP6nVpv1T2KHEy8ts2TiS9g6mLgKmD
JZJ3EM1BOzdWur7Oa/upfm1M3RUauYrxJFguXLh7vSt1ThHZQKieUDyB8s7ikygTbDfEwPxYI2GU
mLz3P9hP9l/hO+7Wn/Fo3bXEyPX1n1cwwliL869XsH9Sr0v7pbJHiZOR37ZxIukdTF0ETB1sh12Y
unZK3E5rL76VumK8VOQ1IdJEOQ5hPEMXyzKDFkL1hOLxlw/l44XbDeE3P8Nz6peKXI8iI7pXf8aj
ddfYYtc3buoSbGTC9Qr1T/J1cStaiKkDWCJ5B9EcGKVMOyVup7W1b6XOs1TkNSHSRDkOYTxDF8sy
gxZC9YTi8ZcP5eOF2w3hNz/Dc+qXilyPIiO6V3/Go3XX2GLXN27qEmxkwvUK9U/ydXErWoipA9gO
+zB1zrNTujy22Nz4DqYuNIn21xOOJ9XUpU7e/WmKqabunv0Zj3a8Uue7vvH0y8SVuoTrFe6fxOvS
XYDL6XA4nTF1ACHyDqI5aKfA8tkpXR5bbG58B1MXmkT76wnHk2rqUifv/jTFVFN3z/6MRzteqfNd
33j6ZeJKXcL1CvdP4nXpLkCty1IbTB3AfdmJqevpzYmTXPjLlTrnNjQ7qw/YhpBJCMUTaNddsuq9
ToJdsYdWTj2egEShOablt/05Ee7wnjrv9Q2el6+SqQYTrldwJTP1uogTc5/v07csbrATh6WYunM1
Zy23g+xLWCR5B9EchM2Jk1z4y5U65zY0O6sP2IaQSQjFE2jXXbLqvU6CXbGHKqceT0Ci0BzT8tv+
nAh3eE+dcXd7Td2ggZQnpaRdr+BKZup1ESfmPt+nb1ncYCcOSzF1Rs1Zy+0g+xI2xLZN3dl9voXz
bHj5nIuqOhTdSs/gySeDzdXZ+dzSH+QaIVlVN8cP1OOPJ9quTOnzP8Fjcgo+Ol03RXGw3W6p+peY
Xexbze7Zn1GcZTEnanF9z5HzSvF0adcr1j9J12X4FoPhDY7uaTpflMEZh7bLqmabOvuyA4BFkXcQ
fTrGfb6F82x4+ZwLpcqiW+kZPPlksFkZ53NLf5BrhGRV3Rw/UI8/nmi7MqVPTMx97YYYna6bojjY
brco07jvDpDR3aE/ozjLYk7U4vqayHmleLq06xXrn6TrMnyLwfAGR/c0nS/K4IxD22VVs02dfdkB
wAbYtqmDLfLrFxIkrAuCwLcCC5CfvIMowB349QsJEtYFQeBbgQVYK5g6WB+/u0GM28tuI+HhMgDP
JO8gCnAXfneDGLeX3UbCw2UAls//A+21LnPe8xT6AAAAAElFTkSuQmCCAA==

--_004_6BAC6B1190A94CA1AE53FFAC084FB76Ejunipernet_--


From nobody Thu Jan 25 05:26:52 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 61238124B17 for ; Thu, 25 Jan 2018 05:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 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] 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 rbfNLED2bW8G for ; Thu, 25 Jan 2018 05:26:48 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 C46DC1200FC for ; Thu, 25 Jan 2018 05:26:48 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 58E841E08E2 for ; Thu, 25 Jan 2018 06:26:48 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 2dSl1x00T2SSUrH01dSoTf; Thu, 25 Jan 2018 06:26:48 -0700
X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=67PtzbbiM-k2xX6K1nAA:9 a=QEXdDO2ut3YA:10
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:To:Sender:Reply-To:Cc: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=53CDTUbAlRzq7in3gG3kgae1SV5SEfOeAiPPaRiaizc=; b=DE/AVvVKxVMPRrVBVeodAPZcqN 3QDGm4q4mFPEOmV3LHa5KzLh0KBYg44/b5LMkoX/j1NJvb2qutCarXnSKaxAiC9aHP7E5HEy9bx2o Q4qpbQxPNv7LS+A8wKms/xm4R;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:58958 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eehYD-001YG7-5j; Thu, 25 Jan 2018 06:26:45 -0700
To: NetMod WG , NetMod WG Chairs 
From: Lou Berger 
Message-ID: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Date: Thu, 25 Jan 2018 08:26:42 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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-Exim-ID: 1eehYD-001YG7-5j
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]:58958
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 13:26:50 -0000

Hi,

This is the start of a *two* week poll on making
draft-bierman-netmod-yang-data-ext a working group document. Please send 
email to the list indicating "yes/support" or "no/do not support".  If 
indicating no, please state your reservations with the document.  If 
yes, please also feel free to provide comments you'd like to see 
addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Lou (and Co-chairs)


From nobody Thu Jan 25 06:03:07 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 8CE8B120726; Thu, 25 Jan 2018 06:03:06 -0800 (PST)
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_RP_MATCHES_RCVD=-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 2ItSpJbXZtKr; Thu, 25 Jan 2018 06:03:05 -0800 (PST)
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 7E30C120227; Thu, 25 Jan 2018 06:03:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=708; q=dns/txt; s=iport; t=1516888984; x=1518098584; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=P/oMWad5EbwvVzwWsbipjndTrt/CjKz5KETaP/KyIAQ=; b=LVZof/ZIiWXvRHdUs0i06CkRX442cN1Fb3a0yOrn2UC13tvqpn1bmrcq b13nyf0JdUWPxDWhlxwxPddz3Msg7q+tZyusb7jugO7BdLCanygkBIIuZ 1hGBnWehxjMhGHqWYMoDsRwBYpz+lS0E7r77YKr+IHRiD/V2V4JHhrmI2 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQB34mla/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj3WXWIICChgLhElPAoJuFAEBAQEBAQEBAmsohSQ?= =?us-ascii?q?BAQQBASEPAQU2GwsOCgICJgICJzAGAQwGAgEBijEQtD2CJ4pVAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARoFgQ+DQoNsghGDBYMvAQECgTwBEgGDNoJlBZoOiXyVYoIbhh+?= =?us-ascii?q?DcYd6j0eIE4E8NiJgcDMaCBsVPYIqhFdBN4wWgjwBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,412,1511827200";  d="scan'208";a="1649458"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 14:03:02 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0PE316G027366; Thu, 25 Jan 2018 14:03:02 GMT
To: Lou Berger , NetMod WG , NetMod WG Chairs 
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
From: Robert Wilton 
Message-ID: <333423d2-b1a5-c556-fcd3-84e465490871@cisco.com>
Date: Thu, 25 Jan 2018 14:03:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 14:03:06 -0000

Support.

Thanks,
Rob


On 25/01/2018 13:26, Lou Berger wrote:
> Hi,
>
> This is the start of a *two* week poll on making
> draft-bierman-netmod-yang-data-ext a working group document. Please 
> send email to the list indicating "yes/support" or "no/do not 
> support".  If indicating no, please state your reservations with the 
> document.  If yes, please also feel free to provide comments you'd 
> like to see addressed once the document is a WG document.
>
> This poll ends on February 8.
>
> Thank you!
>
> Lou (and Co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Jan 25 06:56:10 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 88D5012DA28; Thu, 25 Jan 2018 06:56:09 -0800 (PST)
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 2GzzKM75RQRv; Thu, 25 Jan 2018 06:56:07 -0800 (PST)
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 32A3B1241F8; Thu, 25 Jan 2018 06:56:07 -0800 (PST)
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 w0PEtE4r031499; Thu, 25 Jan 2018 06:56:04 -0800
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=tPyY4sOeMcIQ/fuWPsPystRr6ksxQtOi/PYh8DewR+k=; b=Wj7pJfpM+wKqatYcbhrU01bzs/stMBojOQndESn2zj07EIrxf6q7Tiy//OfZh0IrUKQC p+jsjPUPfQqb+IMVnleYkywUdylMQbQhKGJadsTMM34jcF2EJY7MV8WPZpefqbA4KIHM XY0U1iUuwvLyH/+0XV9qYMksEZ8hlfEmOElSJ9JDDwf5ZvoRhYVJoe6KNl9b0qy2b5hX rLRK6dMoHerZiJvj+ndgXZM8cD9GqaTQHMzYTF/LMUICojMScHZIK2j3X/0jwYjKK3HJ oAngZpOID4cREetgaWfngX8BfsK/7huGCRI1JUQO5KEQsP5JcfRgoU6mMGS9lEqKhxWa iA== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0179.outbound.protection.outlook.com [216.32.181.179]) by mx0b-00273201.pphosted.com with ESMTP id 2fqh23r19v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 06:56:03 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3273.namprd05.prod.outlook.com (10.173.220.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Thu, 25 Jan 2018 14:55:51 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.006; Thu, 25 Jan 2018 14:55:51 +0000
From: Kent Watsen 
To: Robert Wilton , Lou Berger , "NetMod WG" , NetMod WG Chairs 
Thread-Topic: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
Thread-Index: AQHTleAqmJIeAORwS0KCxIIo07busaOEnquA//+68AA=
Date: Thu, 25 Jan 2018 14:55:51 +0000
Message-ID: 
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net> <333423d2-b1a5-c556-fcd3-84e465490871@cisco.com>
In-Reply-To: <333423d2-b1a5-c556-fcd3-84e465490871@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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3273; 6:rsm3dxC10EwmD4vf1ywEVXxkeEyenjpAeNXXSe1sJZIfYjRFpS7NgkMomKqLDlML4ePD+kE9pq74K8OCGy8hSHxP1fA8iTsjNy2rFF/cGrPk70X/yMF8PmN5wU5LMYBWiU6LIdwldWrrVdBSpe0gxTBBhkWwnhjz9lvh4un7BD76BKt+W7EVaWz45HVnw2EdLrMjX0BT27TYRnvPr4peSY4f8awRuSH2c5//F/z9mN42q2kE55HfzVy6n0N1QDKESaowOW1lIqnCbr4+LDqTdGIJvwwFKDIjRO0NUcfszn+kkNLOdm/jdU6vV85EUfNuqg+BDOGjvN9Q6MjtWQf4RfC55lQn9FTq1MkmhIASFYm2Ajbw913QUDPtoL3Deqyy; 5:QPgkZ8XxX1ucDjZTl+B3q2vQHU5Gbo9oF3qFzrFPVKtyQ2y9c0b17Nsd4MzZZIybVZfb7Ckz8FmOi/5bxwABYM+Po4WZ32BALV5oDFnrJddDJR5wt309VITmFraIMr/OAuupjjdtLsFrSnbv2lGFVoM2+ByICtqoQTvpd+EeypM=; 24:7LWlTA8WOJLUFBvIZj+p26fpqWGUmB7ffm9uAkYwvU0TS/cD8KOlOCU6IetS8h19nY1dm/ijwmfmJrApRUGNWKwubIGHPybZvsNmGGUzljM=; 7:oVBip4PBEYlWDa1FYw+f2XxcEuq5azFMoHeglrAbDKf/P8SskzSmk1yD1bQE5L7YbbbYiYL8C5VgD5FPdkBOjoUuWiRGKx5T4QOv7w5WNyNiUaIVAbkRxDbeJFVlpwCeaBo89jlTY/gSObq/OnHePf61BHMHekDwjrU2GA370S+0/IU92Jt2PNR+s9w3qfxIxXInSljCu2yFYRyfmoryMh5R5AVlUTFxnqfl4HlO4AWyUsYCboR8QfgYhOA1C/ZH
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 62c127b0-6463-4862-967d-08d56403b9f8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3273; 
x-ms-traffictypediagnostic: DM5PR05MB3273:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231055)(2400081)(944501161)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3273; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3273; 
x-forefront-prvs: 0563F2E8B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(189003)(199004)(316002)(86362001)(6246003)(2906002)(66066001)(68736007)(105586002)(8936002)(110136005)(2900100001)(3846002)(478600001)(966005)(58126008)(82746002)(83716003)(53546011)(8676002)(97736004)(6306002)(53936002)(102836004)(305945005)(6506007)(7736002)(99286004)(81156014)(81166006)(6116002)(186003)(6512007)(575784001)(77096007)(26005)(5660300001)(229853002)(3660700001)(106356001)(3280700002)(6436002)(6486002)(76176011)(25786009)(230783001)(33656002)(36756003)(83506002)(2950100002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3273; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3AzADAQpC5rXg5VUA0if0/RDXwbJXj2mVWAEAAVHdBQbEZ3dQf8R9N0iQPkrj+bpnroRk9wZyjHF/je9JbVt6Q==
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: 62c127b0-6463-4862-967d-08d56403b9f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 14:55:51.0080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3273
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_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-1711220000 definitions=main-1801250203
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 14:56:09 -0000

c3VwcG9ydCwgYXMgYSBjb250cmlidXRvcg0KDQp0aGlzIGRyYWZ0IGlzIG5lZWRlZCB0byByZXNv
bHZlIGEgemVyb3RvdWNoIGxhc3QgY2FsbCBpc3N1ZQ0KDQpLLg0KDQoNCg0KT24gMjUvMDEvMjAx
OCAxMzoyNiwgTG91IEJlcmdlciB3cm90ZToNCj4gSGksDQo+DQo+IFRoaXMgaXMgdGhlIHN0YXJ0
IG9mIGEgKnR3byogd2VlayBwb2xsIG9uIG1ha2luZw0KPiBkcmFmdC1iaWVybWFuLW5ldG1vZC15
YW5nLWRhdGEtZXh0IGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gUGxlYXNlIA0KPiBzZW5kIGVt
YWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9zdXBwb3J0IiBvciAibm8vZG8gbm90IA0K
PiBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0
aW9ucyB3aXRoIHRoZSANCj4gZG9jdW1lbnQuICBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJl
ZSB0byBwcm92aWRlIGNvbW1lbnRzIHlvdSdkIA0KPiBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25j
ZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCj4NCj4gVGhpcyBwb2xsIGVuZHMgb24g
RmVicnVhcnkgOC4NCj4NCj4gVGhhbmsgeW91IQ0KPg0KPiBMb3UgKGFuZCBDby1jaGFpcnMpDQo+
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f
bGlzdGluZm9fbmV0bW9kJmQ9RHdJRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k
YjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mbT1fZENmN2ZYU3VqNUc4RVlfSEMyWkpuUlBPU2hNd01yd3VpTmp4aW5jT2ZNJnM9RFJSWmhk
UUFJOVNJZ3c4VUwxU0J5VDhGR1FqZkpEcHZ1TmY0aktfMVVnUSZlPQ0KPiAuDQo+DQoNCg0KDQo=


From nobody Thu Jan 25 07:34: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 8CA2C126B6D for ; Thu, 25 Jan 2018 07:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.508
X-Spam-Level: 
X-Spam-Status: No, score=-14.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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_RP_MATCHES_RCVD=-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 EM77D5VUuUzV for ; Thu, 25 Jan 2018 07:34:13 -0800 (PST)
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 1C15E124BAC for ; Thu, 25 Jan 2018 07:34:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70878; q=dns/txt; s=iport; t=1516894452; x=1518104052; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=eoJOSEGAKU9vSJG3OviAvWIAtKI+31IjcoCJODjv6fU=; b=H7ogpHTFqS6aJWE2hLjFG/HJwDGNSMdEz8RnznAlFWbjNwwnOZetobOT cVZ0vHHs00K4I7BZq9SpwiqCyR04WR5D9QqMTCkqFv4S0bag2uEj59JdH O5fi0XuPBa/JLg2VFsPi7InWOEwwacxvHj5Al5XB5tm/Gt0ydUkGBf9Ac c=;
X-Files: image001.png : 14008
X-IronPort-AV: E=Sophos;i="5.46,412,1511827200";  d="png'150?scan'150,208,217,150";a="1651194"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 15:34:10 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0PFYAcQ007619; Thu, 25 Jan 2018 15:34:10 GMT
To: Kent Watsen , NETMOD Working Group 
References:  <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net>
From: Benoit Claise 
Message-ID: <5c2ae0a9-b4b9-3d13-395e-1c779f99f941@cisco.com>
Date: Thu, 25 Jan 2018 16:34:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net>
Content-Type: multipart/alternative; boundary="------------19CCC62E2214EEA8159EBDD6"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 15:34:16 -0000

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

Kent,
>
> I see a lot of suggestions to reference other drafts as examples.  I 
> would discourage doing that.  I recommend this draft clearly stating 
> the desire, including its own examples if needed.
>
I recall a remark by Rajiv (in cc) during a NETMOD meeting, along the 
lines of:
I want to create a YANG module but I don't have the time/willingness to 
read every single RFCs before doing so. I want a kind of template, along 
with examples on how to populate it.

We have to understand that a document such as RFC6087bis is not for the 
people who know YANG by heart.
So more examples to illustrate the point is obviously better.
Copying examples inside RFC6087bis we could simply references seems a 
waste of time.
>
> Regarding referencing the tree-diagrams draft, I don't agree that 
> having a "Tree Diagrams" section in the Introduction is better than an 
> inline reference where used:
>
> 1) the term "tree diagram" is not anywhere defined
>
> 2) sections having tree diagrams have to reference the section in the 
> Introduction, and why reference the Intro section when it's just as 
> easy to reference the draft?
>
> 3) it makes the Introduction and Table of Contents unnecessarily busy
>
Again, people want easy guidelines/template.

Regards, Benoit
>
> Kent // contributor
>
> On 1/25/18, 6:20 AM, "netmod on behalf of Benoit Claise" 
>  on behalf of 
> bclaise@cisco.com > wrote:
>
> Dear all,
>
>
> Thank you for this important document.
> I've been spending quite some time trying to relay feedback seen on 
> multiple fronts.
> This is part 1 of the review, till section 4.21
>
>
> -
>
>     This document defines a set of usage guidelines for Standards Track
>     documents containing [RFC7950 
> ] data models.
> This is not inline with:
>     This section contains the module(s) defined by the specification.
>     These modules SHOULD be written using the YANG 1.1 [RFC7950 
> ] syntax.
>     YANG 1.0 [RFC6020 
> ] syntax MAY be used if no YANG 1.1 constructs or
>     semantics are needed in the module.
> So it should be changed to
>     This document defines a set of usage guidelines for Standards Track
>     documents containing YANG 1.1 [RFC7950 
> ] and YANG 1.0 [RFC6020] data models.
> Similarly in section 4
> OLD:
>     
>     Modules in IETF Standards Track specifications MUST comply with all
>     syntactic and semantic requirements of YANG [RFC7950 
> ].
> NEW:
>     Modules in IETF Standards Track specifications MUST comply with all
>     syntactic and semantic requirements of YANG 1.1 [RFC7950 
> ]. See the exception
>     for YANG 1.0 in section 3.6
> Note that I tried to add some new text around the following sentence but that paragraph became clumsy.
>     Alternatively,
>     if YANG 1.0 is used, then Modules in IETF Standards Track specifications
>     MUST comply with all syntactic and semantic requirements of YANG 1.0 [RFC6020].
> Finally, in section 3.6, I would add a sentence to this paragraph
>     This section contains the module(s) defined by the specification.
>     These modules SHOULD be written using the YANG 1.1 [RFC7950 
> ] syntax.
>     YANG 1.0 [RFC6020 
> ] syntax MAY be used if no YANG 1.1 constructs or
>     semantics are needed in the module.
> The sentence such as:
>     if any the imported YANG modules is based on YANG 1.1, the main YANG
>     module MUST also be written in YANG 1.1.
>   - section 3, editorial:
>     There are three usage scenarios for YANG that can appear in an
>     Internet-Draft or RFC:
>     o  normative module or submodule
>     o  example module or submodule
>     o  example YANG fragment not part of any module or submodule
>     The guidelines in this document refer mainly to a normative_complete_
>     module or submodule, but may be applicable to example modules and
>     YANG fragments as well.
> Either add "complete" to "o  normative module or submodule)" and be consistent throughout the document,
> or remove it from the last sentence.
> - section 3.2
>     The "" tag SHOULD be followed by a string identifying
>     the file name specified inSection 5.2 of [RFC7950] 
> .  The name string
>     form that includes the revision-date SHOULD be used.  The following
>     example is for the '2010-01-18' revision of the 'ietf-foo' module:
>      file"ietf-foo@2016-03-20.yang" 
> I would add that both revision versions (on the  and in the module) MUST match.
> I ran into all sort of tooling issues because of such discrepancies.
> - section 3.2.1
> Add "see section 4.9 regarding the namespace guidelines for example modules"
> - The following in paragraph in section 3.3 seems misplaced.
>
>         If YANG tree diagrams are used, then a normative reference to the
>
>         YANG tree diagrams specification MUST be provided for each diagram.
>
>         (Refer to the example in the next section.)
>
> It should be in section 3.4.
> Btw, no need to have the specifications for each diagram!
> Also, we want to add some guidelines on how to reference the tree 
> diagram convention
> For ex: no need to copy over the conventions
> Basically, we just need: 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3 
> 
>
> PROPOSAL (replacing the previous paragraph)
>
>         If YANG tree diagrams are used, then a normative reference to the
>
>         YANG tree diagrams specification MUST be provided. As an example guideline
>
>         (fromhttps://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3
>     ),
>
>         here is a subsection in the terminology section
>
>         Tree Diagrams
>
>         Tree diagrams used in this document follow the notation defined in
>
>         [I-D.ietf-netmod-yang-tree-diagrams
>     ].
>
> - section 3.5
> You should add a good example to illustrate the second paragraph 
> (Based on some previous feedback, YANG module designer wants to work 
> from examples)
> I would suggest to add 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09#section-2.3 
> 
>
>
> - section 3.6, editorial
> OLD:
>
>    Note that all YANG statements within a YANG module are considered
>     normative, if the module itself is considered normative, and not an
>     example module.
> NEW:
>    Note that all YANG statements within a YANG module are considered
>     normative, if the module itself is considered normative, and not an
>     example module or a example YANG fragment.
>
> - section 3.6
>
>     Example YANG modules MUST NOT contain any normative text, including
>     any reserved words from [RFC2119 
> ].
> I guess it applies also to the "example YANG fragments"
> - section 3.10
> Mention yanglint.
> yanglint validates xpath, while pyang doesn't.
> - section 3.11
> You might consider the addition of xymhttps://github.com/xym-tool/xym 
> 
> - section 3.12
> mention that the examples MUST be validated.
> Pointing to the tool would be a welcome addition.
> - section 4.6.x
> You should really mention a common mistake about the missing derived-from-or-self(), flagged in many YANG doctor reviews::
>   
> You should explain the applicability: identity augmentation.
> - section 4.7 "Lifecycle Management"
>      The status statement MUST be present if its value is 'deprecated' or
>     'obsolete'.
> I've been confused for a little, thinking this section was about the IETF document lifecyle management and the obsolete document tag.
> Proposal: "Objects Lifecycle Management" or "YANG Objects Lifecycle Management"
>      The YANG objects status statement MUST be present if its value is 'deprecated' or
>     'obsolete'.
>   
> - section 4.8
>     The contact statement MUST be present.  If the module is contained in
>     a document intended for Standards Track status, then the working
>     group web and mailing information MUST be present, and the main
>     document author or editor contact information SHOULD be present.  If
>     additional authors or editors exist, their contact information MAY be
>     present.
> I would add: No need to include the WG chair contacts.
> - section 4.10
>
>         The separation of configuration data and operational state SHOULD be
>
>         considered carefully.  It is sometimes useful to define separate top-
>
>         level containers for configuration and non-configuration data.  For
>
>         some existing top-level data nodes, configuration data was not in
>
>         scope, so only one container representing operational state was
>
>         created.
>
> What about NMDA?
> This section is not inline with 4.23.3
> Btw, in case a YANG supports NMDA , RFC6087bis should include the guideline is that it must be clearly mentioned.
> The example of the abstract inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03 
>   could be mentioned.
>     The YANG model in this document conforms to the Network Management
>     Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.
> In the same section about "top-level data definitions", any guidelines in connection withhttps://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ 
>   and schema mount?
> Too early?
> In section 4.23, add the [I-D.ietf-netmod-revised-datastores 
> ] reference next to NMDA
> In section 4.23.3
> OLD:
> (b) For published models, the model should be republished with an
>     NMDA-compatible structure, deprecating non-NMDA constructs.  For
>     example, the "ietf-interfaces" model in [RFC7223 
> ] will be
>     restructured as an NMDA-compatible model.
> NEW:
> (b) For published models, the model should be republished with an
>     NMDA-compatible structure, deprecating non-NMDA constructs.  For
>     example, the "ietf-interfaces" model in [RFC7223 
> ] has been
>     restructured as an NMDA-compatible model in [RFC7223bis].
> I believe [I-D.ietf-netmod-revised-datastores] should a normative reference
> - section 4.14.2
> Something wrong with:
>     -top-level siblings are not ordered -top-level siblings not are not
>     static, and depends on the modules that are loaded
> - section 4.17
> Discussing with YANG doctors that a feature-per-leaf is most likely the wrong approach, Jürgen came up with this.
> OLD
>     The YANG "feature" statement is used to define a label for a set of
>     optional functionality within a module.  The "if-feature" statement
>     is used in the YANG statements associated with a feature.
>     The set of YANG features available in a module should be considered
>     carefully.  The description-stmt within a feature-stmt MUST specify
>     any interactions with other features.
>     If there is a large set of objects...
> NEW
>     The YANG "feature" statement is used to define a label for a set of
>     optional functionality within a module.  The "if-feature" statement
>     is used in the YANG statements associated with a feature.  The
>     description-stmt within a feature-stmt MUST specify any
>     interactions with other features.
>     The set of YANG features defined in a module should be considered
>     carefully. Very fine granular features increase interoperability
>     complexity and should be avoided. A likely misuse of the feature
>     mechanism is the tagging of individual leafs (e.g., counters) with
>     separate features.
>     If there is a large set of objects...
> back to section 4.5
>     If a data definition is optional, depending on server support for a
>     NETCONF or RESTCONF protocol capability, then a YANG 'feature'
>     statement SHOULD be defined to indicate that the NETCONF or RESTCONF
>     capability is supported within the data model.
> NEW:
>      If a data definition is optional which depends on server support then
>      a YANG 'feature' statement SHOULD be defined.  The defined 'feature'
>      SHOULD then be used in the conditional 'if-feature' statement
>      referencing the optional data definition.
> This is currently under discussion with the YANG doctors.
> Regards, Benoit
>


--------------19CCC62E2214EEA8159EBDD6
Content-Type: multipart/related;
 boundary="------------7B22ABE36005120A360B8894"


--------------7B22ABE36005120A360B8894
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Kent,

    

    

      
      
      
      
      
      
      

        
I see a
            lot of suggestions to reference other drafts as examples.  I
            would discourage doing that.  I recommend this draft clearly
            stating the desire, including its own examples if needed.

      

    

    I recall a remark by Rajiv (in cc) during a NETMOD meeting, along
    the lines of:

    I want to create a YANG module but I don't have the time/willingness
    to read every single RFCs before doing so. I want a kind of
    template, along with examples on how to populate it.

    

    We have to understand that a document such as RFC6087bis is not for
    the people who know YANG by heart.

    So more examples to illustrate the point is obviously better.

    Copying examples inside RFC6087bis we could simply references seems
    a waste of time. 

    

      

        

        
 

        
Regarding
            referencing the tree-diagrams draft, I don't agree that
            having a "Tree Diagrams" section in the Introduction is
            better than an inline reference where used:

        
1) the
            term "tree diagram" is not anywhere defined

        
2)
            sections having tree diagrams have to reference the section
            in the Introduction, and why reference the Intro section
            when it's just as easy to reference the draft?

        
3) it
            makes the Introduction and Table of Contents unnecessarily
            busy

      

    

    Again, people want easy guidelines/template.

    

    Regards, Benoit

    

      

        

        
 

        
Kent //
            contributor

        
 

        

          

            
On 1/25/18, 6:20 AM, "netmod on behalf
              of Benoit Claise" <netmod-bounces@ietf.org on
              behalf of
              bclaise@cisco.com>
              wrote:

          

        

        

          
 

        

        
Dear all,

        

          


            Thank you for this important document.

            I've been spending quite some time trying to relay feedback
            seen on multiple fronts.

            This is part 1 of the review, till section 4.21

            

            

            - 

          
   This document defines a set of usage guidelines for Standards Track

          
   documents containing [RFC7950] data models. 

          
 

          
This is not inline with:

          
   This section contains the module(s) defined by the specification.

          
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax.

          
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or

          
   semantics are needed in the module.

          
 

          
So it should be changed to 

          
   This document defines a set of usage guidelines for Standards Track

          
   documents containing YANG 1.1 [RFC7950] and YANG 1.0 [RFC6020] data models. 

          
 

          
Similarly in section 4

          
OLD:

          
   

          
   Modules in IETF Standards Track specifications MUST comply with all

          
   syntactic and semantic requirements of YANG [RFC7950].

          
 

          
NEW: 

          
   Modules in IETF Standards Track specifications MUST comply with all

          
   syntactic and semantic requirements of YANG 1.1 [RFC7950]. See the exception

          
   for YANG 1.0 in section 3.6

          
 

          
Note that I tried to add some new text around the following sentence but that paragraph became clumsy.

          
   Alternatively, 

          
   if YANG 1.0 is used, then Modules in IETF Standards Track specifications 

          
   MUST comply with all syntactic and semantic requirements of YANG 1.0 [RFC6020].

          
 

          
Finally, in section 3.6, I would add a sentence to this paragraph

          
   This section contains the module(s) defined by the specification.

          
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax.

          
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or

          
   semantics are needed in the module.

          
 

          
The sentence such as: 

          
   if any the imported YANG modules is based on YANG 1.1, the main YANG 

          
   module MUST also be written in YANG 1.1.

          
 

          
 - section 3, editorial:

          
   There are three usage scenarios for YANG that can appear in an

          
   Internet-Draft or RFC:

          
 

          
   o  normative module or submodule

          
 

          
   o  example module or submodule

          
 

          
   o  example YANG fragment not part of any module or submodule

          
 

          
   The guidelines in this document refer mainly to a normative complete

          
   module or submodule, but may be applicable to example modules and

          
   YANG fragments as well.

          
 

          
Either add "complete" to "o  normative module or submodule)" and be consistent throughout the document,

          
or remove it from the last sentence.

          
 

          
 

          
- section 3.2

          
 

          
   The "<CODE BEGINS>" tag SHOULD be followed by a string identifying

          
   the file name specified in Section 5.2 of [RFC7950].  The name string

          
   form that includes the revision-date SHOULD be used.  The following

          
   example is for the '2010-01-18' revision of the 'ietf-foo' module:

          
 

          
   <CODE BEGINS> file "ietf-foo@2016-03-20.yang"

          
 

          
I would add that both revision versions (on the <CODE BEGINS> and in the module) MUST match.

          
I ran into all sort of tooling issues because of such discrepancies.

          
 

          
- section 3.2.1

          
Add "see section 4.9 regarding the namespace guidelines for example modules"

          
 

          
- The following in paragraph in section 3.3 seems misplaced.  

          

            
   If YANG tree diagrams are used, then a normative reference to the

            
   YANG tree diagrams specification MUST be provided for each diagram.

            
   (Refer to the example in the next section.)

          

          
It should be in section 3.4.

            Btw, no need to have the specifications for each diagram!

            Also, we want to add some guidelines on how to reference the
            tree diagram convention

            For ex: no need to copy over the conventions

            Basically, we just need: 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3

            

            PROPOSAL (replacing the previous paragraph) 

          

            
   If YANG tree diagrams are used, then a normative reference to the

            
   YANG tree diagrams specification MUST be provided. As an example guideline 

            
   (from https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),

            
   here is a subsection in the terminology section

            
 

            
   Tree Diagrams

            
 

            
   Tree diagrams used in this document follow the notation defined in

            
   [I-D.ietf-netmod-yang-tree-diagrams].

          

          
- section 3.5

            You should add a good example to illustrate the second
            paragraph (Based on some previous feedback, YANG module
            designer wants to work from examples)

            I would suggest to add 
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09#section-2.3

            

            

            - section 3.6, editorial

            OLD:

          
  Note that all YANG statements within a YANG module are considered

          
   normative, if the module itself is considered normative, and not an

          
   example module. 

          
NEW:

          
 

          
  Note that all YANG statements within a YANG module are considered

          
   normative, if the module itself is considered normative, and not an

          
   example module or a example YANG fragment. 

          
 

          
- section 3.6

          
   Example YANG modules MUST NOT contain any normative text, including

          
   any reserved words from [RFC2119].

          
 

          
I guess it applies also to the "example YANG fragments"

          
 

          
- section 3.10

          
Mention yanglint.

          
yanglint validates xpath, while pyang doesn't.

          
 

          
- section 3.11

          
You might consider the addition of xym https://github.com/xym-tool/xym

          
 

          
- section 3.12

          
mention that the examples MUST be validated.

          
Pointing to the tool would be a welcome addition.

          
 

          
- section 4.6.x

          
You should really mention a common mistake about the missing derived-from-or-self(), flagged in many YANG doctor reviews::

          
 

          
You should explain the applicability: identity augmentation.

          
 

          
- section 4.7 "Lifecycle Management"

          
    The status statement MUST be present if its value is 'deprecated' or

          
   'obsolete'. 

          
 

          
I've been confused for a little, thinking this section was about the IETF document lifecyle management and the obsolete document tag.

          
Proposal: "Objects Lifecycle Management" or "YANG Objects Lifecycle Management"

          
    The YANG objects status statement MUST be present if its value is 'deprecated' or

          
   'obsolete'. 

          
 

          
 

          
- section 4.8

          
   The contact statement MUST be present.  If the module is contained in

          
   a document intended for Standards Track status, then the working

          
   group web and mailing information MUST be present, and the main

          
   document author or editor contact information SHOULD be present.  If

          
   additional authors or editors exist, their contact information MAY be

          
   present.

          
 

          
 

          
I would add: No need to include the WG chair contacts.

          
 

          
- section 4.10

          

            
   The separation of configuration data and operational state SHOULD be

            
   considered carefully.  It is sometimes useful to define separate top-

            
   level containers for configuration and non-configuration data.  For

            
   some existing top-level data nodes, configuration data was not in

            
   scope, so only one container representing operational state was

            
   created. 

          

          
What about NMDA?

          
This section is not inline with 4.23.3

          
Btw, in case a YANG supports NMDA , RFC6087bis should include the guideline is that it must be clearly mentioned.

          
The example of the abstract in https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03 could be mentioned.

          
   The YANG model in this document conforms to the Network Management

          
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

          
 

          
 

          
In the same section about "top-level data definitions", any guidelines in connection with https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ and schema mount?

          
Too early?

          
 

          
In section 4.23, add the [I-D.ietf-netmod-revised-datastores] reference next to NMDA

          
In section 4.23.3

          
OLD:

          
(b) For published models, the model should be republished with an

          
   NMDA-compatible structure, deprecating non-NMDA constructs.  For

          
   example, the "ietf-interfaces" model in [RFC7223] will be

          
   restructured as an NMDA-compatible model.

          
 

          
NEW:

          
(b) For published models, the model should be republished with an

          
   NMDA-compatible structure, deprecating non-NMDA constructs.  For

          
   example, the "ietf-interfaces" model in [RFC7223] has been 

          
   restructured as an NMDA-compatible model in [RFC7223bis].

          
 

          
I believe [I-D.ietf-netmod-revised-datastores] should a normative reference

          
 

          
- section 4.14.2 

          
 

          
Something wrong with: 

          
   -top-level siblings are not ordered -top-level siblings not are not

          
   static, and depends on the modules that are loaded

          
 

          
- section 4.17

          
Discussing with YANG doctors that a feature-per-leaf is most likely the wrong approach, Jürgen came up with this.

          
 

          
OLD

          
 

          
   The YANG "feature" statement is used to define a label for a set of

          
   optional functionality within a module.  The "if-feature" statement

          
   is used in the YANG statements associated with a feature.

          
 

          
   The set of YANG features available in a module should be considered

          
   carefully.  The description-stmt within a feature-stmt MUST specify

          
   any interactions with other features.

          
 

          
   If there is a large set of objects...

          
 

          
NEW

          
 

          
   The YANG "feature" statement is used to define a label for a set of

          
   optional functionality within a module.  The "if-feature" statement

          
   is used in the YANG statements associated with a feature.  The

          
   description-stmt within a feature-stmt MUST specify any

          
   interactions with other features.

          
 

          
   The set of YANG features defined in a module should be considered

          
   carefully. Very fine granular features increase interoperability

          
   complexity and should be avoided. A likely misuse of the feature

          
   mechanism is the tagging of individual leafs (e.g., counters) with

          
   separate features.

          
 

          
   If there is a large set of objects...

          
 

          
back to section 4.5

          
   If a data definition is optional, depending on server support for a

          
   NETCONF or RESTCONF protocol capability, then a YANG 'feature'

          
   statement SHOULD be defined to indicate that the NETCONF or RESTCONF

          
   capability is supported within the data model.

          
 

          
NEW: 

          
    If a data definition is optional which depends on server support then

          
    a YANG 'feature' statement SHOULD be defined.  The defined 'feature'

          
    SHOULD then be used in the conditional 'if-feature' statement

          
    referencing the optional data definition.

          
 

          
This is currently under discussion with the YANG doctors.

          
 

          
Regards, Benoit

          
 

        

      

    

    

  


--------------7B22ABE36005120A360B8894
Content-Type: image/png;
 name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="image001.png"

iVBORw0KGgoAAAANSUhEUgAABJwAAADaCAIAAABsAs/pAAAgAElEQVR4nO2dPW7rutaGNYg0
Fwi+xoCA1KdxlVoNb5eUdwAXcMn6tHsARloWtztTCOARaCyZgr5CprQokZTo2KZ+ngcvsB2J
IpcoJ+S7uSQVTdM0TfMDAACwQhoAAIDdU7T/5B6UAQAAbiHvIAoAALAEMHUAALBi8g6iAAAA
S+Cppu5yOhRFdX5OYwAAsAPyDqK1LotCmbxBAADA7nn2St3ldMDVAQDAvcg7iDZNU+sSVwcA
AHl5evrlucLUAQDAvcg7iDZN0xiFqQMAgLxg6gAAYMXkHUSbBlMHAAD5wdQBAMCKyTuINg2m
DgAA8vP8p19eTgcelgIAAPch7yDaNE37tBR8HQAAZISVOgAAWDF5B9GmYaUOAADyg6kDAIAV
k3cQbRpMHQAA5AdTBwAAKybvINo0mDoAAMgP76kDAIAVk3cQbXhPHQAALICnmrrL6VAcTpfn
NAYAADsg7yBa67IodZ03CAAA2D3Pf/olAADA3cg7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDA
isk7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsht6s5V
URRre3Pd5XQoFv9uhlX2LABAKnkHUQ9GFUWxtjfX1bosFv9uhlX2LADAc8ht6n5+fs7VDdbj
cjpkdVWXU7VsU3eulu46AQDuQd5B1I9RN1iPWpdZXVWt1bJNnVFLd50AAPlYq6nLDaYOAGAR
5B1E/dxk6nKDqQMAWDFPNXWX06G4UlWd6ThX1flc2e3S33VbnVxHW8vYtPjrF9VM5Uy2KYtV
1UZyPa4Lqa+nOk+ZujaUa1XueYko+y6Y125CziemDgD2Qd5BtNal/QOtVGc6jFLGKLvdiPLd
VifX0dYyNi3++kU1UzmTbcqiUm0k1+O6kPp6lJkydW0o16rc8xJR9l0wr92EnE9MHQBAmOeZ
usvp0PuUy+ngOJr+s7RivS1xfhiWjNfvFDxXU7eZ2Zbsv5fToTr/uPme8p46YdEG/s09xz6I
y/ksTsuWDrWbGn+wfwAANknGEbTWZe9Tal06jqb/LK1Yb0ucH4Yl4/U7BY2aus3MtmT/rXWp
TOPme8p76oRFG/g39xz7IGpjxGnZ0qF2U+MP9g8AAHQ8zdSFl7Zk+mVnZUZJmcPjh6YlVL9Y
5hqYLj+2XVv/NaKp5j305zL67Ikm0G5y/PaksXQAsA/yDaDhpS2ZftlZmVFS5vD4oWkJ1S+W
ucaLZpFobP3XiKaa99Cfy+izJ5pAu8nx25PG0gEAhNmBqUuzN482dc5amygSNnW32TNW6gBg
H+QbQPOZujR782hT56y1iSJhU3ebPWOlDgAgzFPTL4XNEMmSflM3cCUjz+ZLv/TWPz9j0Ylm
aK6kRXMyK4OETJ2TVDq5Upcaf38emDoA2AMZR1D3eZUiWdJv6gauZOTZfOmX3vrnZyw60QzN
lbRoTmZlkJCpc5JKJ1fqUuPvzwNTBwAQ4qkPSpGphP3CVfdjl5c42De6Uy2Ujuipf3xIzOuI
aM5VW/b6xJOzW011mnhVnTwX97zkc1Kqqq082m5C/M6pYOoAYA/kHURlKmG/cNX92OUlDvY5
SYfhe9i89Y8PiXkdEY1RbdnrE0+MW43SE6+qk+finpd8TopSbeXRdhPid04FUwcAEGIBrzSA
R4CpA4B9kHcQheeBqQMACIOp2yrtaxLW9wZAAIAk8g6i8ETa1ySY3GEAACwRTB0AAKyYvIMo
AADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEsDUAQDAisk7iAIAACwBTB0AAKyYvIMo
AADAEsDUAQDAisk7iAIAACwBTN0NXCbePL4u7LvNhycU2j4Br1IAgKeSdxDdCvXEm8fXhX23
+fCEQtsn4FUKALACMHW3cTlVWzF1LaGXlae+xJyXngPAc8k7iG6IWqutmLqW0MvKU19izkvP
AWANYOpuA1OXWA8AwGPIO4huCExdYj0AAEti0abOJgAWRVFVnVkQWwf+4Vx5isvNU6mEbepg
VRVFUVTn63FdKqGo/jxl6togr1W5+Yie+Oe2O50KGWpXJEVe2x9kSGLqAGCd5B1EU7EJgEVR
KNWZBbF14B+M8hSXm6dSCdvUQaWKoiiUuR7XpRKK6s2UqWuDvFbl5iN64p/b7nQqZKhdkRR5
bX+QIYmpA4A9sVxTdzkdeuNxOR06Q3M5n4Vd672JsBOyuOMynAO8nKv2SPvv5XSozm2VTvW2
fmHRBj4qFIQ//lC7ofjT2z1X/al3tYvzxtQBwBrJO4gmUeuyNx61LjtDUxsj7FrvTYSdkMUd
l+Ec4MWo9kj7b61LZdoqnept/cKiDXxUKAh//KF2Q/Gnt2tUf+pd7eK8MXUAsB8Wa+rCS2Gu
nfEvgXmXucZHeLDWx5qTq/0ZhjPDu0jjNPjsiSbQbnL84XafYOqsIwUAeBp5B9EUwkthrp3x
L4F5l7nGR3iw1seak6v9GYYzw7tI4zT47Ikm0G5y/OF2n2DqrCMFAFg4qzN1zlrb2Jv0O67u
In2l6bGmLhR/2NSl2qSMpu6meAEAfkPeQTSFkKlz1trG3qTfcXUX6StNjzV1ofjDpi7VJmU0
dTeUBwDIwWJNnZPvKJIxz4Ob5YRncYuL+9VSHrAfMleODZIZjrET8Jo6f/yhdlPjj5k69xY+
TB0AbIG8g2gSMt9RJGOawc1ywrO4xcX9aikP2A+ZK8cGyQzH2Al4TZ0//lC7qfHHTJ17C59b
KaYOAPbEck3dj5t66MtePFTVodvl5ilKy+LmO8Y8h62jOrcfD6fL9ckj50F252niVXVd4ers
fPbHH203If5Yu6KHDqez96xk6fA9e1PXDFMHAM8k7yCaikw99GUvlkqV3S43T1FaFjffMeY5
bB3KtB9LXV+fPGIG2Z164lV1XWFlnM/++KPtJsQfa1f0UKmN96xk6fA9e3EwdQCwBhZt6mB9
YOoA4LnkHURh+2DqAGANYOrgvvhyOwEAHkbeQRR2gC+3EwBgYWDqAABgxeQdRAEAAJYApg4A
AFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4A
AFZM3kEUAABgCWzI1NnXZd/nPWniXea/fj7/ZeJN5esi1M839j+vQACAX5F3EH0s9nXZ93lP
mniX+a+fz19PvKl8XYT6+cb+5xUIAJCBDZm6lvu8/PpyOtzXZ1xO1VZMXUuon1P7n5eVA8Dv
yDuIPoP7vPy61uV9fUat1VZMXUuon1P7n5eVA0AOMHUPrEWAqUusBwBgHnkH0WdwH5Nwd6uB
qUusBwDgkezB1IlMSrnPpguGN08mX7apg1XVlru20x3Qt1udp0xd2+q1KrdVT5xz251OhQy1
K5Iir+0P+gFTBwDLIO8g+gw8JkFkUsp9Nl0wvHky+bJNHVSqLXdtpzugb1eZKVPXtnqtym3V
E+fcdqdTIUPtiqTIa/uDfsDUAcCa2b6pczacq96cXM7ni2ezv5ZIe61zsv/axM3L6dBVIe+p
G3rG3i1dTgfh2vr2/XGG2g2db3q756rvk3E6KqYOAJZB3kH0GYxMgrPBqN6c1MbUns3+WiLt
tc7J/msTN2tddlXIe+qGnrF3S7UuhWvr2/fHGWo3dL7p7RrV98k4HRVTBwBrZvOmTixbeczM
eKu/llh7rpe62p/hytyMCqVxGnz2xBloN3K+qe0+wdRZRwoAcDN5B9FnMDQJYtnKY2bGW/21
xNpzvdTV/gxX5mZUKI3T4LMnzkC7kfNNbfcJps46UgCAJ7MDUxcyH0XEsyzH1IXiDJu6VJuU
0dTdFC8AgCTvIPoMxqYuZD6KiGdZjqkLxRk2dak2KaOpu6E8AMA92LypG6dWjsudq7uv1Lk2
SGY4BgmZOn+coXZD55varmzZ99YBTB0ALIO8g+gz8KRfeteq3ETDu6/UuTZIZjgGCZk6f5yh
dkPnm9qubNn31gFMHQCsmc2YuvA9Y4Nd1kPI549U1aEYPBdkVvaizXWszu3Hw+lyffLI2a2o
Ok28qq4rXJ2dz/44o+0Gzje1XZHJeTidvWclS0f6PwqmDgB+R95B9JGE7xkb7LIeQj5/RKmy
GDwXZFyNB5vrqEz7sdT19ckjxq1I6YlX1XWFlXE+++OMths439R2RSZnqY33rGTpSP9HwdQB
QA42Y+pgnWDqAOB35B1EAYZg6gAgB5g6yIsvtxMAYDZ5B1GAEb7cTgCAB4OpAwCAFZN3EAUA
AFgCmDoAAFgxeQdRAACAJYCpAwCAFZN3EAUAAFgCV1P33XyjG/RP3SCEdqLsf3CQV+EB7g+6
QfkjQAg9S7nbRyFh6p6u7LNMhNDTlP0PDvIKU3df5Y8AIfQs5W4fhYSpe7oeNX38W/3rP3X2
KSxCSCr7HxzkFabuvsofAdqSjHrRdf4wUEC520chYerGMseiKI7mUfX/Uzf//E//qyiKd/PP
36ooinuYsfrf/6f+m1a+KP5P/8k95Y3pb9W9vfWvv3MHczeZv4qiKJIuFv2cqPb3a/ybFdoe
ui43/p6av9qj6uYfTN1StTtTZ96KolDmUfX/aZo/tX5p2zCqKArfpLx+L4ui1Kf83ZEej+n/
Tr6Z7JE/Uu119F/BiX74UOV7fZfroj7Syi/qe+XT8r8/07+/vbIHiwLC1HlljkfzqMq7ad+/
/lO3s8Y7zKT/p/9lJ5GzVf/7fcmmLtWm3kf/fX90o0uz01vt5/DatX+797rc9Hvq1p//rxny
aXemrvnTmLfHmrrGvLVzwVq/BGeu9bv61eT7pMu7ruHMjCfVZqxf/rWyaD/U+uUuzqrWL8nf
1N9+rx6sPN+fD5XUaPT31/0+5O9R5BemzqunmLq//m6XAsp//+/3U+QbKlm4qTN/5XA+CWZD
LHB1zFnM+e97v4yzAC2+n29WmqnzXpebfk8xdWsQpu6+ujbQzgVr/VKEVmyWNvmeGY95W/hC
0N3lN3Wxfjjp8i5rUDct9y3te5XQb4/TDaYu+PuLqVuHdmzqvvRrURSF0s6P5edX05o6fbxO
1I+6P6rbaEs239/152tRFOroK+/RP3XzT13/+//aOaL56/eZeM4yXZv6pa65ZFfj0TXR5pi1
iXZTpu6ae6bsISJOm8YmbMzcducsUv35T+lYJTHV/u+7p562/L/+U9sDy3//LxqPJ35n43yH
doP+/Kd0aqaf4/0c6p+/VWFXz67xDCxZoqkbXpe6ufH3FFO3Bm3V1F1T5+xc7vpjO0Mzb8p8
2P+LktPvj/4/qLq5XP1eFkWh3nzlPbLH2JYKOZs0b0VXi5x899tl7txJl0VRvOi6/dDH5E0L
7LLabNrY9XO4/nA8ftkwCrfycJyyQ6/ttsmv6q29Ntc4pyfco3om2p2uRynhLkL9c+3YgakL
9YNVd/V//Q3ua473W8p1vOYWKnuI6Hz7vRJfrbntzsn5jPTb7OsbjccTv7NxuCuo0O+v5/vw
y4uMHqYdm7rv5utTWWPWfH8331/6+Fl/fzftbXWv3edX/dUW0MpubMtYQ/hdf776ynv1CJPg
JoaZv9pVhb9VOyO3BboZauMmm9X//j/3t9+ZlNtD5FT1f+a/dtXiv+9dWlqoXXch8W9lJ9/h
dtvaRrbkv+/CANhW3Kl/W7P579+xeALxtz/muNuNfr7te/i36uscZyAnmrq7CVO3Bm3V1DXN
SStnal3rNzFT7Wet3TTSma3J6Vz9XvrKexUOSM71nXufnAUZoxyT0N3e0zR/GvNhRIXjFSRp
A8TeQP2heFoX6/z9cXyp9/x9cX4oMYE2Svi68r3ut9h1rWC7gXpC7YbjF31y0uWs/vf2c/x7
UOuXGTZ1xtd3sNwX6bfE6ygXoOTZ1eZDuHHbeqjdyPcq7fuTeH2D8QTib3/8/RURDtbyZjbw
d3Kr2rWp+9bqqJtvrdplt6/P0i6yyfTL+vP1at7EMt0VW74v43726d6TyPGk3PzVzm7t5PI6
yf6f/suZy87Iu5MT5cFn0Qu92fC2K5ePBpP1287L6s9/VO9hhmcXiScUf/PPU9Iv6ee0fo70
zwJN3cADY+qWqu2auj9GvZl2Bat8r+UkWaZf9vf4fIz+kNny8j6gqXuCgjt6T2mDkItX7t+r
j+BRzumNzUY3eRWz2ED9wXjiCpq6UZzDJFdrsu12G/9UsmKonqn+8Uj6jan+ifbzhKm7Q4bh
uP5Av91wHaX5H3z2fPtD12uq31LPa+71DX9//PE3f+5j6vzfh3vViu6tfZu6L338rL8+tf7S
x89aHzszFjJ1pbOy1yufqRst04Un2XczdU4qmgggbDZuuWvrcWYjFH/zT8aVOvo5uX8WaepG
9Wf/K4e82rCpq/Wbrk9af9T6TdeOzfGbuvDtb481dZFZeKKpu24cZO7NsmF7MHVOwC9z+j/U
zw9eqfP1yaNNnZNq6PkvkLGpu8W7Ps7UheJv/mDq9qh9m7rv+vNTfx71V3tfXJ826Td131oF
XnVwT1MXeuS9d7v30YWhSbZT+M9/yunbrkJmoz/QPkki1u4w9W6evGmB8mEV7j2BSWbDH/+g
ieGuB4p+jocdNnXurYbGOQpTh8LasKlr6net35U+DZ/07jd1nsy7cZnbTZ17pJv+F75RL9XU
NfV7qd5cexqoPxhPVPNN3cAld/d6pZq6UD1T/ROvR6ynxfo/2M8RS+O9p868+deyvNu9X7JQ
v6Vfx5Cpc28ynDJ1U/02+/uTeH3nmEwZ/6AJd5eT3jlPmLp1aOemrtFHey9cf7+cuWZZHo19
CErRPU/l61OmTbcLd7LMsLxH05Ps+abOMz21OXji5VrtYyTsQ/ws73ri2fpd4XfjfHYesFH+
9d5WHm13cLvUlJkMP8DDyTC0TmB4L5aTi+iLxxf/6Kzv8VTSWaKf4/0c7h8RZ/nvv7ub/UL3
5sXvLbyfMHVr0JZNnbhbp5+J2awxZUQ63nVW7D7KoZ0HyjLD8h7FApLpYUoHb38K3BMlkkGH
v7+DdEHfozvG9Ufi8SvwoItQnKKv++2i9+1LwNpqJxbrZvTDpMFw82tlp83q/8C3xGMJ/Ots
4ysV2u6xkdF+S7qOXWFlnM/OeZVvqq08fr0C36u070/S9Y3F44t//Kvn+O2TLudljQb1i0PR
Q7V3U5dB95s+5nnDGEIoJkzdGrRpU5dB+SNA2fWr2+r29ybAbJJPQLpR+U8C+YWpe7ryTzoR
Qg+Ukwua/Q8O8gpTd1/ljwAtQDe9Yg49Wb43FiQq/0kgvzB1T1fuGSdC6HnK/gcHeYWpu6/y
R4AQepZyt49CwtQ9XdlnmQihpyn7HxzkFabuvsofAULoWcrdPgoJU/d0ZZ9lIoSepux/cJBX
mLr7Kn8ECKFnKXf7KCRMHUIIoZ0JS4fQ8pW7fYTWJUwdQgihnQlTh9Dylbt9hNYlTB1CCKGd
CVOH0PKVu32E1iVMHUIIoZ0JU7dctW9MFu9ZFntDL7POJ6Pc90SvX/aN1cNXmYW2B6+LefO+
ti52fW1V9g3d2TsDoVUJU4cQQmhnwtQtWOatnevX+mXolOr3sihuf8P13ZXnldkf6vGNGuV/
P7V/u/+6nHTpM7qR6zus/+ldi9CqhalDCCG0M2HqFizz1s71a/1SDF9m/aH6ZZwFKLAY9WAt
z9QFrkutXzz9E7u+mDqEfiFMHUIIoZ0JU7dg1e9lO9c3b6NMy5MuHVNxzeVTb9cUSFHepguK
HL82tU9dcwWvmZPdIcZWMmsx8KTLQiIszYfy1NOWf9G1PbB8r6PxeOJ3Ng53eRXqH6O6fNFr
PANLlmjqhtdleCnnXl9MHUK/EKYOIYTQzoSp247kgo+0BLX5sHbiQ3VpfuatLWxU67i6FMEP
JeyHUdbk1O+ud3PvHPOs1H0oYbRsKyLUzj6ZDxOLJxB/++N4pS4cZ6h/jOrrrPXL70xdSIPI
p4WpQ+h2YeoQQgjtTJi67UgaksFnYXF6U9cWsObBmiixTOcxbyGNTZ2t3+qkVe8Va/02fi6I
P55Q/M2f1PTLUP88y9QllB94YH4jEUoTpg4hhNDOhKnbjvymxUntE0/sCJu6W+6Oe5ypC8Xf
/FmbqWOlDqFnCVOHEEJoZ8LUbUchU9fbLftkjvZzYGUs2X4MW7nKSeNs6nflpF8mmDp//IMm
hrtm94+0T85bBEZ7m1nb/fLeUxcVpg6h24WpQwghtDNh6jaiLkdRGeez8yCT8k2VRVG8GZtj
KV6S1hZ7M83wtrSphbvwg1KcTE7ruIb3vDk5n754fPGPznr89MjZ/SPiLN9Nd7Nf6N68+L2F
4dZT1z8xdQjdLkwdQgihnQlTh9CjFXhPXVSYOoRuF6YOIYTQzoSpQ+jBuvU2RbHsmf8kEFqT
MHUIIYR2JkwdQstX7vYRWpcwdQghhHYmTB1Cy1fu9hFalzB1CCGEdiZMHULLV+72EVqXfmHq
fgAAAFbIbYMfAADAlsDUAQDAisk7iAIAACwBTB0AAKyYvIMoAADAEtikqbucDkVxOF1yxwEA
AI8m7yD6LGpdFkWp69xxAADAMtmkqfv5+bmcqqeausvpMN9FnqvqfI96AAAg7yD6RGqtnmrq
al3Od5FGKXOPegAA4DYwdRmImDoAAEgi7yD6RJ5t6pKImDoAAHgCWzJ156q4Up2lqeu3D3Iy
xQFVJXZdTofxjnbj4XSxe+0Bw5+7mg+nc1fRsLAnIl89wzi7fW3hqrJ7cIkAsFPyDqIPxij7
518Zaer67YOcTHGAUmJXrcvxjnZjqWu71x4w/LmrudSmq2hY2BORr55hnN2+trBSdg8uEQAg
gc2YOpm36NxTd5Z27Vz19kfsuJwOju3qysgdP52Vaveez9JIOc1cmypkY8J3xVbqfPUcpD/1
Bj06CgBgJ+QdRB+JzFt07qkz0q4Z1dsfsaPWpWO7ujJyR9NZqXavMbbUqJlrU4VsTPiu2Eqd
r55S+lNv0KOjAAAgwlZM3TDdsnM5YpluuKglV83ExkjeZmSnz4xVrusTDm++qRuW7UO4nA7y
VFirA4BdkncQfSDDdMvO5YhluuGillw1ExsjeZuRnT4z5lg34eRSTN2wbB9CrUt5KqzVAQDM
Zgembs4aVr/Od0dTF3RnmDoAgHuRdxB9IBFTN2cNq1/nu6OpC7ozTB0AQF62YupcW+NmJvpv
ODsP7qIT6ZeDhEtZb9JKXeEkfsr0y27HuSqGC3pRcygiwNQBAGzY1Lm2xs1M9N9wZgZ30Yn0
y0HCpaw3aaWucBI/Zfplt8OoYrigFzWHIgJMHQDArWzG1A2yKU/itjr34STC7PlyMoe77I7h
E05C2/tb7qrD6RR4RMtl9ACVcD2DSK9bu+LV2fkMALAz8g6ij8XJptTitjr34STC7AkGxmq8
Y/iEk9D2/pY7VWodeERLPXqASrieQaTXrV1xZZzPAAAwgw2ZuoXBs0sAAJ5A3kF0V/DsEgCA
xYKpexSYOgCAJ5B3EN0VmDoAgMWCqXsInjfLAQDAA8g7iO4Hz5vlAABgMWDqAABgxeQdRAEA
AJYApg4AAFZM3kEUAABgCVxN3XfzjRBCCK1O4QHuD0IIIbRCYeoQQgjtTJg6hBBC2xKmDiGE
0M6EqUMIIbQt7dzU1Z+vRVEo/W2ORVG86q/8IaHHSKvXz/rmw/Wx/PzKfQoIoXsJU9erfi+L
olAfjXkriqLUp/whocfIqBdd33z4hyrf69yngBAKa+emrtHH1svVn69FcTTf383XZ1kUhTQA
+lgUxYw5/Zd+nW8LtTrq/Kd/k1on3POoE0nqz+mYr1cwfH2j5/WlX48md88jhO4kTJ3Qh2q9
XP1eFoUyf5rmpMuiKKQB+FBFUcyY09f6Zb4tNOrN5D/9m9Q64Z5HnUhSf07HfL2C4esbPa9a
vyiTu+cRQkFh6lovV3++9hN9fSxfj9ZOfOnX1/L4i0Uev1Zs6prv7/qz65/v+vP1Yb7uXnIt
Wfj6Rs6rt4UIodULUyf0oVovV7+X/UT/Q5UvytqJWr+U5dsvFnn8WrGpa/409XvXP039Xj7M
191LriULX9/IefW2ECG0QO3d1H19lq2X08d+Bq+P6vNTdQs7x0/dT/q7xRxnEclu92xUx+Ng
5We4IiSP0sdua2chQvWE4omUb76/dHfE8aiEjx23G5E0P833tzl2rWs1qEcf+2CO2hxDXXF7
fyZc5enrGzqvUSWxzkm5XtH+Sb0uCKF5wtQJnXTZerkP1c/gP5R616pb2HnTup/0d4s5ziKS
3e7ZqN7syGDrH64IyaM+VL/VWohQPaF4IuWbP7V+sUe8KSV87LjdiKT5af405q1rXbxyva3n
Q/XBvBnzFuqK2/sz4SpPX9/QeY0qiXVOyvWK9k/qdUFov9q7qfNKH5X+aif65viqv776Sb/W
dlqvVZuuKeR4gLa8WAB093pX6pz7vsyxUHqinlA8gfJf+tVbZ7DdkAbmp/58VbqNoY/NHIWv
e207s93Sr5vdrz/j0bpriZHr6z+vYISxFudfr2D/JF8XhNA8Yeqm9KHUR91O9M1bqU91P+n/
MHZab1QxzMdzPEBbXiwAunu9K3XOfV/mrVAfE/WE4gmUr/WLt85guyENzE/9XqqPNoY+NvMm
fN1L25ntln7d7H79GY/WXUuMXF//eQUjjLU4/3oF+yf5uiC0X2HqPNJHpdv5fTur/vKt1BXF
PBMiTZTjEMamTizL2BZ0vJ5QPP7yX3Z5ana7IfnNjz66rsP2m91u+0eYurv1ZzxaN3Mydn3j
pi7BRiZcr1D/pF8XhNA8Yeqm9KHURzu/b2fVtW+lrijmmRBpohyHMDZ1YllmsMgTqicUj7/8
yS5PzW43JL/5+VCu67D9Zrfb/hGm7m79GY/WzZyMXd+4qUuwkQnXK9Q/6dcFof0KU+dRO8n+
+iyLdm2kNydiVu15csbvTV0oxc5fTzieVIvde08AABZySURBVFOXmtrnT1NMNXX37M94tOOV
Ot/1jadfJq7UJVyvcP+QconQY4Spm1I7yT7psmjXRnpzImbVnidn/N7UhVLs/PWE40k1damp
ff40xVRTd8/+jEc7XqnzXd94+mXiSl3C9Qr3DymXCM0Vps6jsDnpJ9n2CSvywDRT59zP1lYV
tA0hkxCKJ9Cu+zzJr89yqt2QHPPz9VlevYr72oDOQ84xLb/tz6jG99R5r2/wvHyVTPRPyvUK
rmQmXxeE0Dxh6qYUNif9JNs+YUUemGbqnPvZbLpdwDaETEIonkC77vMkT7qcajckx/ycdHn1
Ku5rAzoPOce0/LY/oxrfU+e9vsHz8lUy0T8p1yu4kpl8XRDarzB1Q2n3+Rbdj22eXv+ci6N6
LZy3IIzS5LpcO6Wdz21DfSaea4RkVa0HCNfjjyfarhapDEcTbTek0YNeRD1OxuDRiC3iZYBt
2Edz1/6MylkWk3XK62si55Xy9Mu06xXrn7TrghCaLUxdVB/u8y26H9s8ve4pIy9KvRTOWxAk
b6YRuXbqw/ncNtRn4rlGyPm7915H6/HHE23XiHFQGAZfuyGNHvTiPFhyuN1uES8DbMNW5q79
GZWzLCbrlNfXRM4r5emXadcr1j9p1wWhXQtTh/agX7+QgPfUIbQlYerQ7vTrFxLwnjqEli1M
HdqH3NTQVHF7G0KbEqYO7VBuamiquL0NoYULU4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0J
U4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0JU4cQQmhnwtQhhBDaljB1CCGEdiZMHUIIoW0J
UxeR6d+kfTS5g1m17Du4X/VX/mBuiPO2+Jf//WnPS7z3PH9ICD1FmLq5Mm/+91CjVNl3cJf6
lD+YG+K8Lf7lf3/a8xLvPc8fEkI3ClMX1NdnedRPb1er5Ea/9Os6puPmOD/OG/rh4XGmxL+S
748+tl6u/nxdrPNE6AHC1M3TSZdv5untGpXcaK1f1jEdN2/z47yhHx4eZ0r8K/n+fKjWy9Xv
5WKdJ0KzhKkLKs/7pnOamUdrX6ZuFd8ffWy9XP35Wvzm5ewIrUyYunnK877pnGbm0dqXqVvF
9+dDtV6ufi+L37ycHaHswtT59KVfC4nS3S6t7EYxZW/Lv+ove+DrZ62PRVGo47EoiuKor5l4
dsJt0/mcnDexcbgrpHBaYB+nOs5wF7rPFHQKf32WXQLh12dZFOXnlzl2+YTX8+36x3tenWaa
omg/ePs/Vs/1EojOj8Qfj3O2qVvN96f5+ixbL6ePxcANtpcep4e2KUzdpGr94v4d++h2mf7v
WD9lb8uX+mQPfNH1hyqKQr2poiiKN3PNxLMTbpvOV8icN7FxuCukcFpgH6d6m+EuPlTfqix8
0jYmZU66LIryvTZvhV3VuZ5v1z/e8+o00xRF+8Hb/7F6rpdAdH4k/nics03dar4/zUmXrZf7
UMXADbaXHqeH1iJMXVCelRatxETZHB1f0d2e1Hx/N1qb7+9GH9s5sS35pV+Ppi2sdd3Xed14
/TF9hWpsNsSWL/066X+0EnN3c+xMiIjt67N8fVW2HnPsY64/X3tTFzwvf5yxkDz9EOt/r+QC
lGw9FH88zl+v1C30++MXpg5tWZi6efKstBglJsrmzfEV3e1JzZ+m+TDmT9N8qHZObEvW+uWa
4VZ/mLqvU6a93bJCNTYbYkutXyb9j1Fi7m7eOhMiYjvp8qVUth7z1sdcv5e9qQuelz/OWEie
foj1v1dyAUq2Hoo/HuevV+oW+v3xC1OH1iVMXVDjSbk+urP/L33sp7z153E447flrRkQk3Jn
UeW6sfn+vpepEytsxXAFxnemxYD2EPd868/XctLUBc8rEGdQvn6I9r9Xg9i6z3lM3VK/Pwjt
T5i6eRpPyj+UO/uv9Vs/5a3f1XDGb8tbMyAm5c6iyv1NnVhhK4YrML4zHY6D7SHu+dbvZTlp
6oLnFYgzKF8/RPvfq0Fs3ec8pm6p3x+EtiBMXVCPm5Q7qW79TL35/r6bqROSZmzumXrPVxTz
m6LYeU3H6QpT97zvD0L7E6Zunh43KXdS3fqZevOnuZupE5JmbO6Zes9XFPOboth5TcfpClP3
vO8PQlsQpi4ob/qczEb7+lRO+lzCpLyv2T6pwtPEcFdQI7PhxDlt6nypktftjnkohKmzLba3
fllTFz4vb5zRkDz9EOt/r8Kmzhf/VJx3SL/M+P3Rx1nLtqLrihk3LiK0TmHq5smbPiez0U5a
OelzCZPyvmb7pApPE8NdQY3MhhPntKnzpUpetzvmoRCmzrbY3vplTV34vLxxRkPy9EOs/70K
mzpf/FNx3iH9MuP350PNWrYVXVfMuHERoaUIU+dT+EEXTqbi0bQbZa5jt92WFC8Ba6s9Gln/
61G9Ohl0fWbd5O1Mw3a7KbtWno0JVXVTeZnmpz6FCen64fXT9DeDBc4rGGdM/n7w9v9UDUo7
n4Pxh+JMjn+R359EU2eO3FCHNixM3aTCD7pwMhXF/WZucSNKipeAtdUqI+t/UeqlkJPvPrNu
8namYbvdlN0oz8aEqrqpvEzzU+/ChHT98KJNfzNY4LyCccbk7wdv/0/VoD6cz8H4Q3Emx7/I
70+iqTNv3FCHViVMHZqrGStjaCvSarSAidCGhKlDN2nGyhjaiowaLWAitGhh6tBcYer2I/vg
zfyRIPQQYerQTcLU7Uf2wZv5I0FopjB1aIb6fD9uskIIrV+YOpSqPt+Pm6wQQksUpg4hhNDO
hKlDCCG0LWHqEEII7UyYOoQQQtvSL0zdDwAAwAq5bfADAADYEpg6AABYMXkHUQAAgCWAqQMA
gBWTdxAFAABYApsydZfToSiqc+4wAADgaeQdRB9NrcuiUCZ3GAAAsHA2Zep+fn4upwOuDgBg
P+QdRJ9ArUtcHQAAxNmaqfs5V5g6AID9kHcQfQZGYeoAACAOpg4AAFZM3kH0GWDqAABgCkwd
AACsmLyD6DPA1AEAwBSbM3U/l9OBh6UAAOyFvIPoU6h1ycNSAAAgxuZMHSt1AAB7Iu8g+gxY
qQMAgCkwdQAAsGLyDqLPAFMHAABTYOoAAGDF5B1EnwGmDgAAptiaqeM9dQAAuyLvIPoEeE8d
AABMsilTdzkdisPpkjsMAAB4GnkH0UdT67IodZ07DAAAWDibMnUAALA38g6iAAAASwBTBwAA
KybvIAoAALAEMHUAALBi8g6iAAAASwBTBwAAKybvIAoAALAEMHUAALBi8g6iAAAASwBTBwAA
KybvIAoAALAEMHUAALBi8g6iAAAAS2BTpu5crfvF42uPHwDg+eQdRB+NUet+8fja4wcAWAuY
ugWx9vgBAJ5P3kH00azdFK09fgCAtbAVU3c5HQqHw+kid7Q/dj+cqqIoDqdzd5Qt/vPz83Ou
RrVEGZc/V0VRVFVVFEVRna/7q/N1h6/dxPhtVO2GWVECAGySvIPoA6l16Y4Lpa7ljvbH7get
iqIotemOssWbpmmMGtUSZVzeqKIolFJFURTKXPcrc93hazcxfhtVu2FWlAAA0LEVU/fz8xNa
6bqcDmJzV6Y1Xuduc9FtFx6p3xxp1Fv+XLVey/7bRRFqNzV+uw9TBwC7Ju8g+mj8K121LsXm
rkxrvEy3uei2C4/Ub4406i1vVOu17L9dFKF2U+O3+zB1AADJ7MDUSd91OVXWAA392vVgsex2
Je7qQuVtLLZtaep87SbHDwAAP/s0ddJ31VpZAzT0a9eDxbLblbirC5W3sdi2panztZscPwAA
3MwuTF3nqGQBZ4XtR5i6tHWvUPmIqfO2mxw/AAD87NXUdY5KFnBW2Bph6tLWvULlI6bO225y
/AAAcDMbM3UHsQ7nLIidq+rsLnOdKydvUaZlJjmnQPnYSp233dT4f37IvgQA2LypK8U6nLMg
ZpQy7jKXUU7eokzLTHJOgfKxlTpvu6nxNw3ZlwAAN7IpUyceNzIyOpfTYZj2eH1eyugA96El
05ZpXN7mZFZn+2iUS1uoOkfaTYu/PQcsHQDsnLyD6MOpvQ8+6XYN0h6vz0sZHeA+tGTaMo3L
25xMZeyjUeq2kDKRdtPib88BSwcAcAPbMnURRstcqXmW9+LGdn130w2X8wAA9kfeQTQno2Wu
1DzLe3Fju7676YbLeQAAMI+9mLrx3WjrMnW+u+nsgzUBAHZM3kE0I+O70dZl6nx309kHawIA
QCJbN3VOamRvgfpnVj7XFiW3G4gfAABa8g6iGXBSI3sL1D+z8rm2KLndQPwAAPAbtm7qAABg
0+QdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABg
xeQdRAEAAJbAJk3d5XTgUZEAALsg7yD6LGpd8qhIAAAIsklT9+N/V/dj2zvMd5G+l87dUg8A
AOQdRJ+I713dj22vnO8ifS+du6UeAAC4DUxdBiKmDgAAksg7iD6RZ5u6JCKmDgAAnsCWTF3/
Zu/qLE1dv32QkykOqCqxS7zxu9/RbjycLnavPWD4c1fz4XTuKhoW9kTkq2cYZ7evLVxVdg8u
EQB2St5B9MH0b/ZWRpq6fvsgJ1McoJTYJd743e9oN5a6tnvtAcOfu5pLbbqKhoU9EfnqGcbZ
7WsLK2X34BIBABLYjKmTeYvOPXVnadfOVW9/xI7L6eDYrq6M3PHTWal27/ksjZTTzLWpQjYm
fFdspc5Xz0H6U2/Qo6MAAHZC3kH0kci8ReeeOiPtmlG9/RE7al06tqsrI3c0nZVq9xpjS42a
uTZVyMaE74qt1PnqKaU/9QY9OgoAACJsxdQN0y07lyOW6YaLWnLVTGyM5G1GdvrMWOW6PuHw
5pu6Ydk+hMvpIE+FtToA2CV5B9EHMky37FyOWKYbLmrJVTOxMZK3GdnpM2OOdRNOLsXUDcv2
IdS6lKfCWh0AwGx2YOrmrGH163x3NHVBd4apAwC4F3kH0QcSMXVz1rD6db47mrqgO8PUAQDk
ZSumzrU1bmai/4az8+AuOpF+OUi4lPUmrdQVTuKnTL/sdpyrYrigFzWHIgJMHQDAhk2da2vc
zET/DWdmcBedSL8cJFzKepNW6gon8VOmX3Y7jCqGC3pRcygiwNQBANzKZkzdIJvyJG6rcx9O
IsyeLydzuMvuGD7hJLS9v+WuOpxOgUe0XEYPUAnXM4j0urUrXp2dzwAAOyPvIPpYnGxKLW6r
cx9OIsyeYGCsxjuGTzgJbe9vuVOl1oFHtNSjB6iE6xlEet3aFVfG+QwAADPYkKlbGDy7BADg
CeQdRHcFzy4BAFgsmLpHgakDAHgCeQfRXYGpAwBYLJi6h+B5sxwAADyAvIPofvC8WQ4AABYD
pg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYApg4AAFZM3kEUAABgCWDqAABgxeQdRAEAAJYA
pg4AAFZM3kEUAABgCWzI1LXv4K7O7aMneerkhvnd6yI2+rIJ+w764cmFtsfr4fcI1kPeQfSx
tO/gVqZ99CRPndwwv3tdxEZfNmHfQT88udD2eD38HsHW2ZCp+zlX7Rz0cjoURXX+sfNTOS+d
O1G9nA7zp7PnqjrfGHNu7Izf8qgTSerP2XWFr2/0vC6nw8IvWPtKjOuJde/HmNODIcea4GTH
v0cAiybvIPpgjGrnoLUui0KZxs5P5bx07kS11uX86axRytwUcX7sjN/yqBNJ6s/ZdYWvb/S8
al0u/IK1r8S4nlj3fow5PRhyrAlOdvx7BLBBtmbqqnM71e9msOfqcKjsD5fTQfx0x4bXPPW9
nPoeuZwOi5/Gu5YsfH0j53VPi/koztXh0J+oPJmpw+5h6ka/RwDLJe8g+mCMauegtS77+a9R
ZansD7UuxU93bHjNU99a9z1S63Lx03jXkoWvb+S87mkxH4VRZdmfqDyZqcPuYepGv0cAW2NL
pq6bqp+rfgZ/rqqTnRBfTof+B7lI5Uxdvelq15y0yi6a2PqHK0LyqP4N5P3WUD2heCLlnSOq
qhI+1hdNpNscv3D2VSTXjK7BVOfrbk9X3N6f0wwMWez6hs4rwdWlXa9o/yRel3NVnXv/ak+m
beEs2h/03B1Mnff3SJ4zTg+WRd5B9MF0U3Wj+hm8UUrbCXGty/4HuUjlTF296WrXnDRlF01s
/cMVIXlU/wbyfmuonlA8kfLOEUop4WN90US6zfELxleRXDO6BqPMdbenK27vz2kGhix2fUPn
leDq0q5XtH8Sr4tRyvT+1Z5M24IR7Q967g6mzvt7JM8ZpwdbYEumzks7N65Ol+u8tp/qX87n
S1do5CrGk2C5cOHu9a7UOUVkA6F6QvEEyjuLT6JMsN0QA/NjjcS5EpP3/gf7yf4rfMfd+jMe
rbuWGLm+/vMKRhhrcf71CvZP6nVpv1T2KHEy8ts2TiS9g6mLgKmDJZJ3EM1BOzdWur7Oa/up
fm1M3RUauYrxJFguXLh7vSt1ThHZQKieUDyB8s7ikygTbDfEwPxYI2GUmLz3P9hP9l/hO+7W
n/Fo3bXEyPX1n1cwwliL869XsH9Sr0v7pbJHiZOR37ZxIukdTF0ETB1sh12YunZK3E5rL76V
umK8VOQ1IdJEOQ5hPEMXyzKDFkL1hOLxlw/l44XbDeE3P8Nz6peKXI8iI7pXf8ajddfYYtc3
buoSbGTC9Qr1T/J1cStaiKkDWCJ5B9EcGKVMOyVup7W1b6XOs1TkNSHSRDkOYTxDF8sygxZC
9YTi8ZcP5eOF2w3hNz/Dc+qXilyPIiO6V3/Go3XX2GLXN27qEmxkwvUK9U/ydXErWoipA9gO
+zB1zrNTujy22Nz4DqYuNIn21xOOJ9XUpU7e/WmKqabunv0Zj3a8Uue7vvH0y8SVuoTrFe6f
xOvSXYDL6XA4nTF1ACHyDqI5aKfA8tkpXR5bbG58B1MXmkT76wnHk2rqUifv/jTFVFN3z/6M
RzteqfNd33j6ZeJKXcL1CvdP4nXpLkCty1IbTB3AfdmJqevpzYmTXPjLlTrnNjQ7qw/YhpBJ
CMUTaNddsuq9ToJdsYdWTj2egEShOablt/05Ee7wnjrv9Q2el6+SqQYTrldwJTP1uogTc5/v
07csbrATh6WYunM1Zy23g+xLWCR5B9EchM2Jk1z4y5U65zY0O6sP2IaQSQjFE2jXXbLqvU6C
XbGHKqceT0Ci0BzT8tv+nAh3eE+dcXd7Td2ggZQnpaRdr+BKZup1ESfmPt+nb1ncYCcOSzF1
Rs1Zy+0g+xI2xLZN3dl9voXzbHj5nIuqOhTdSs/gySeDzdXZ+dzSH+QaIVlVN8cP1OOPJ9qu
TOnzP8Fjcgo+Ol03RXGw3W6p+peYXexbze7Zn1GcZTEnanF9z5HzSvF0adcr1j9J12X4FoPh
DY7uaTpflMEZh7bLqmabOvuyA4BFkXcQfTrGfb6F82x4+ZwLpcqiW+kZPPlksFkZ53NLf5Br
hGRV3Rw/UI8/nmi7MqVPTMx97YYYna6bojjYbrco07jvDpDR3aE/ozjLYk7U4vqayHmleLq0
6xXrn6TrMnyLwfAGR/c0nS/K4IxD22VVs02dfdkBwAbYtqmDLfLrFxIkrAuCwLcCC5CfvIMo
wB349QsJEtYFQeBbgQVYK5g6WB+/u0GM28tuI+HhMgDPJO8gCnAXfneDGLeX3UbCw2UAls//
A+21LnPe8xT6AAAAAElFTkSuQmCCAA==
--------------7B22ABE36005120A360B8894--

--------------19CCC62E2214EEA8159EBDD6--


From nobody Thu Jan 25 08:48:15 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 A712512D94E; Thu, 25 Jan 2018 08:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 vPLM0OO7SukH; Thu, 25 Jan 2018 08:48:11 -0800 (PST)
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 502CA12D95C; Thu, 25 Jan 2018 08:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2818; q=dns/txt; s=iport; t=1516898891; x=1518108491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=89oVeugcejmJ4VltxWbTnxmys2DcI9Dj2F501QGCd8c=; b=Dzh+q3kPO7pdrtHsSp3B6JwYEcqogPQhDa/lXw9gsAp2knxpuoBmZs4+ Wb9xy9s1cQPYyxgRSUyzI8xvVgCnYaHXecx1FlXKZW2eWvlvSIMJaWIO2 n1YOUhtppT248YJ9RCR4Rs2E04M4YveZTdMHOmm0p99X8H5nGRHNiojyS g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAgDJCWpa/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWmQ2ZWoICCiOFGAIagX5YFAEBAQEBAQEBAmsohSQ?= =?us-ascii?q?GIxFFEAIBCBoCJgICAjAVEAIEAQ0FijUQtGOCJ4pSAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWBD4NCghWDPymDBYMvAgEBAQGBOgESAR+DFzGCNAWKYJkqAogTjU2?= =?us-ascii?q?CG4Yfi2uKfIJgiVECERkBgTsBNiJgVxEIcBVnAYF/gwmBTngBi32BJYEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,412,1511827200"; d="scan'208";a="347803152"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 16:48:06 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w0PGm6QT024897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2018 16:48:06 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 25 Jan 2018 11:48:05 -0500
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; Thu, 25 Jan 2018 11:48:05 -0500
From: "Acee Lindem (acee)" 
To: Suresh Krishnan , The IESG 
CC: "draft-ietf-netmod-rfc8022bis@ietf.org" , Joel Jaeggli , "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
Thread-Index: AQHTlSoaR8T/HlwVzUmTGPRq8EWYVKOEzjUA
Date: Thu, 25 Jan 2018 16:48:05 +0000
Message-ID: 
References: <151680861581.25648.8503007790939454483.idtracker@ietfa.amsl.com>
In-Reply-To: <151680861581.25648.8503007790939454483.idtracker@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 16:48:14 -0000

SGkgU3VyZXNoLCANCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IC0gc2VlIGlubGluZS4gDQoNCu+7
v09uIDEvMjQvMTgsIDEwOjQzIEFNLCAiU3VyZXNoIEtyaXNobmFuIiA8c3VyZXNoQGthbG9vbS5j
b20+IHdyb3RlOg0KDQogICAgU3VyZXNoIEtyaXNobmFuIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp
bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMt
MDk6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg
dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAgIGVtYWlsIGFkZHJl
c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0
aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgDQogICAgDQog
ICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp
c2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg
RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgDQogICAgDQogICAgVGhlIGRvY3Vt
ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJl
Og0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9k
LXJmYzgwMjJiaXMvDQogICAgDQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENP
TU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgICogTG90cyBvZiBwbGFjZXMgaW4g
dGhlIGRvY3VtZW50IHdoZXJlIE5NREEgaXMgbWlzc3BlbGxlZCBhcyBORE1BLiBQbGVhc2UgZml4
Lg0KDQpJJ20gaGFyZHdpcmVkIHRvIHR5cGUgIk4tRCIgLSB5b3UgY2FuIHRha2UgdGhlIGJveSBv
dXQgb2YgTm9ydGggRGFrb3RhIGJ1dCB5b3UgY2FuJ3QgdGhlIE5vcnRoIERha290YSBvdXQgb2Yg
dGhlIGJveS4uLiBJJ3ZlIGZpeGVkIGFsbCB0aGVzZS4gDQoNCg0KICAgIA0KICAgICogU2VjdGlv
biA5LjEuDQogICAgDQogICAgVGhlIHJhbmdlcyBmb3IgQWR2RGVmYXVsdExpZmV0aW1lIGFuZCBN
YXhSdHJBZHZJbnRlcnZhbCBoYXZlIGJlZW4gY2hhbmdlZCBieQ0KICAgIFJGQy10by1iZS04MzE5
IHRvIHVwZGF0ZSB0aGUgdmFsdWVzIHNwZWNpZmllZCBpbiBSRkM0ODYxLiAgUGxlYXNlIGNoYW5n
ZSB0aGVzZQ0KICAgIHJhbmdlcyB0byB0aGUgbmV3IHZhbHVlcy4NCiAgICANCiAgICBPTEQ6DQog
ICAgDQogICAgbGVhZiBtYXgtcnRyLWFkdi1pbnRlcnZhbCB7DQogICAgICAgICAgICAgICB0eXBl
IHVpbnQxNiB7DQogICAgICAgICAgICAgICAgIHJhbmdlICI0Li4xODAwIjsNCiAgICAgICAgICAg
ICAgIH0NCiAgICANCiAgICBORVc6DQogICAgDQogICAgbGVhZiBtYXgtcnRyLWFkdi1pbnRlcnZh
bCB7DQogICAgICAgICAgICAgICB0eXBlIHVpbnQxNiB7DQogICAgICAgICAgICAgICAgIHJhbmdl
ICI0Li42NTUzNSI7DQogICAgICAgICAgICAgICB9DQogICAgDQogICAgT0xEOg0KICAgIA0KICAg
ICAgICAgICAgIGxlYWYgZGVmYXVsdC1saWZldGltZSB7DQogICAgICAgICAgICAgICB0eXBlIHVp
bnQxNiB7DQogICAgICAgICAgICAgICAgIHJhbmdlICIwLi45MDAwIjsNCiAgICAgICAgICAgICAg
IH0NCiAgICANCiAgICBORVc6DQogICAgICAgICAgICAgbGVhZiBkZWZhdWx0LWxpZmV0aW1lIHsN
CiAgICAgICAgICAgICAgIHR5cGUgdWludDE2IHsNCiAgICAgICAgICAgICAgICAgcmFuZ2UgIjAu
LjY1NTM1IjsNCiAgICAgICAgICAgICAgIH0NCiAgICANCiAgICBHb29kIHBvaW50LCB0aGVzZSBj
aGFuZ2VzIHdpbGwgYmUgaW4gdGggLTEwIHZlcnNpb24uIA0KDQpUaGFua3MsDQpBY2VlDQogICAg
DQoNCg==


From nobody Thu Jan 25 09:07:20 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 773DC1270AC; Thu, 25 Jan 2018 09:07:08 -0800 (PST)
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.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151690002840.8370.1512108360179744508@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 09:07:08 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 17:07:08 -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           : A YANG Data Model for Routing Management (NMDA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-10.txt
	Pages           : 77
	Date            : 2018-01-25

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-10
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-10


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 Thu Jan 25 09:09: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 3976912DA4C; Thu, 25 Jan 2018 09:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 A7rye-r34fbq; Thu, 25 Jan 2018 09:09:44 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541971270AC; Thu, 25 Jan 2018 09:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1516900184; x=1518109784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jLjCgBbaERNu2WtSFtugiOqbuuJrgHCpFcT+aaPIT90=; b=HgCA4JBlYZY671MeQ6/f5VR9AEv3OYyDduUpvaz+tGJg8gZuY6H3Z0a6 x60qgmZPaebyeDCWxyrJcIUg+VZ4QRGpStmqwilHIyUq8VOnvTq7Fyqfx +vBEzPJSubpYaceTFvCtb4muUgS/uYmHADuY66MiLpeFX9OUXeM1M/XUq Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQCiDmpa/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWiiSOaYFbl2qCFwoYC4RJTwIagX5UGAEBAQEBAQE?= =?us-ascii?q?BAmsohSQCBAEBIRE6CxACAQgSCAImAgICJQsVAg4CBA4FijUQtGiCJ4pTAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYEPg0KCFYM/KQyCeYMvAQECAQEXhG0xgjQFpAo?= =?us-ascii?q?CiBONTYIbZ4U4i2uNXIlRAhEZAYE7AR85gVBwFRkkKgGBfwmETniNI4EXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,412,1511827200"; d="scan'208";a="61746104"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 17:09:43 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0PH9hY4006619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2018 17:09:43 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; Thu, 25 Jan 2018 12:09:42 -0500
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; Thu, 25 Jan 2018 12:09:42 -0500
From: "Acee Lindem (acee)" 
To: The IESG 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-10.txt
Thread-Index: AQHTlf8DDZxA/FQBzUG+buex6m/W0KOE0pWA
Date: Thu, 25 Jan 2018 17:09:42 +0000
Message-ID: 
References: <151690002840.8370.1512108360179744508@ietfa.amsl.com>
In-Reply-To: <151690002840.8370.1512108360179744508@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6334F4DF97BA684AA8DE3EBD4C1A5384@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 17:09:46 -0000

VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBCZW4gQ2FtcGJlbGwncyBhbmQgU3VyZXNoIEtyaXNobmFu
J3MgSUVTRyBUZWxlY2hhdCBjb21tZW50cy4gDQpUaGFua3MsDQpBY2VlIA0KDQrvu79PbiAxLzI1
LzE4LCAxMjowNyBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu
b3JnIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh
dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQog
ICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBNb2RlbGluZyBXRyBv
ZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBE
YXRhIE1vZGVsIGZvciBSb3V0aW5nIE1hbmFnZW1lbnQgKE5NREEgVmVyc2lvbikNCiAgICAgICAg
ICAgIEF1dGhvcnMgICAgICAgICA6IExhZGlzbGF2IExob3RrYQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQWNlZSBMaW5kZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlp
bmd6aGVuIFF1DQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgw
MjJiaXMtMTAudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDc3DQogICAgCURhdGUgICAgICAg
ICAgICA6IDIwMTgtMDEtMjUNCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3Vt
ZW50IGNvbnRhaW5zIGEgc3BlY2lmaWNhdGlvbiBvZiB0aHJlZSBZQU5HIG1vZHVsZXMgYW5kIG9u
ZQ0KICAgICAgIHN1Ym1vZHVsZS4gIFRvZ2V0aGVyIHRoZXkgZm9ybSB0aGUgY29yZSByb3V0aW5n
IGRhdGEgbW9kZWwgdGhhdA0KICAgICAgIHNlcnZlcyBhcyBhIGZyYW1ld29yayBmb3IgY29uZmln
dXJpbmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZw0KICAgICAgIHN1YnN5c3RlbS4gIEl0IGlzIGV4
cGVjdGVkIHRoYXQgdGhlc2UgbW9kdWxlcyB3aWxsIGJlIGF1Z21lbnRlZCBieQ0KICAgICAgIGFk
ZGl0aW9uYWwgWUFORyBtb2R1bGVzIGRlZmluaW5nIGRhdGEgbW9kZWxzIGZvciBjb250cm9sLXBs
YW5lDQogICAgICAgcHJvdG9jb2xzLCByb3V0ZSBmaWx0ZXJzLCBhbmQgb3RoZXIgZnVuY3Rpb25z
LiAgVGhlIGNvcmUgcm91dGluZyBkYXRhDQogICAgICAgbW9kZWwgcHJvdmlkZXMgY29tbW9uIGJ1
aWxkaW5nIGJsb2NrcyBmb3Igc3VjaCBleHRlbnNpb25zIC0tIHJvdXRlcywNCiAgICAgICBSb3V0
aW5nIEluZm9ybWF0aW9uIEJhc2VzIChSSUJzKSwgYW5kIGNvbnRyb2wtcGxhbmUgcHJvdG9jb2xz
Lg0KICAgIA0KICAgICAgIFRoZSBZQU5HIG1vZHVsZXMgaW4gdGhpcyBkb2N1bWVudCBjb25mb3Jt
IHRvIHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQNCiAgICAgICBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJl
IChOTURBKS4gIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA4MDIyLg0KICAgIA0KICAgIA0K
ICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K
ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJm
YzgwMjJiaXMvDQogICAgDQogICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh
aWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l
dG1vZC1yZmM4MDIyYmlzLTEwDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
aHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTEwDQogICAgDQogICAgQSBkaWZmIGZy
b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTEwDQog
ICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXpl
ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAg
DQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ
IGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgDQogICAg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRt
b2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K


From nobody Thu Jan 25 12:36:38 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 C2E2F12EAAA; Thu, 25 Jan 2018 12:35:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Phillip Hallam-Baker 
To: 
Cc: draft-ietf-netmod-yang-tree-diagrams.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151691255573.8494.16260998328717962330@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 12:35:55 -0800
Archived-At: 
Subject: [netmod] Secdir telechat review of draft-ietf-netmod-yang-tree-diagrams-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 20:35:56 -0000

Reviewer: Phillip Hallam-Baker
Review result: Has Nits

I have reviewed the document and it is generally free of security
considerations as claimed. There are some areas of concern however, the
significance of which may become more apparent as such tools find future use.

As described in the document, the tree diagram format is intended to serve as
an output generated by a tool to aid human interpretation. Thus, a potential
ambiguity can arise if the tool used to generate the format is buggy or if the
document contains schema and presentation data compiled from different versions
of the source.

Specifications using this representation need to make clear which
representation is canonical. Otherwise we end up in a situation in which a
document that has an ambiguity being unfixable by means of issuing an errata
because there is no agreement as to whether the change is breaking or not.

Another issue that is of concern is that even though the format is not intended
to be an input format, there can be no guarantee it will not be used as such.
Indeed it could be argued that a spec that makes use of this format should
encourage this approach so as to detect possible ambiguities.


From nobody Thu Jan 25 14:53: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 4722512EADB; Thu, 25 Jan 2018 14:53:30 -0800 (PST)
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 qqp-2vgqLThc; Thu, 25 Jan 2018 14:53:28 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 3137A12EAD9; Thu, 25 Jan 2018 14:53:28 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id d9so8521779oth.6; Thu, 25 Jan 2018 14:53:28 -0800 (PST)
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=os36mgffw4SgN1L53woHDmV6nZiPLH6l/l3x+IYz9YU=; b=ptPTQ7TSt13C6KRJMaVzkXBJLWqLyJEumUjOeWKkMaQLBo36W2IG3EtvIieGxJXXlr smPvNc0AjOLYfp4Ker05h+CM7OtyEY6DEKSRiz+jqpBm0LUj6L3mRqp1cI9r/Zeklhu1 tVdca8XphBGd6eBjV0ch6u7YmQRStNsVeVHSW2x2Oycb8qyhsrmEtso0OWqxtUBgfjM7 u07oXaXtOAoT8ikPqGQAHuVs2+9oi/HMq4Kwfi3mtAEioTTZPIScj7Ut8kynegoKy+Vx uvW1B2+NVfTG0lv5ZF2VUYX7bTRlfb9MED1+UMivA9Fpg6upn/cgTwQuUFq35ernW6P2 lS+w==
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=os36mgffw4SgN1L53woHDmV6nZiPLH6l/l3x+IYz9YU=; b=F/W1ZUIMgfUWzA7VUJHwLbZYnoOGmb/vfapQfSDz+a1rIxJGLKBcK1ZNM8V315AFQ3 oAYPEQ8HPwKo4AiK3XtU+czcOLW/cAENvNeIWfERtNJg5FHubNMd5XI/JZNsfAvL+/6H 1Wt1TWF7TOCfAacAGBvS14EWhaDeqEVPpcG74XL50wxcU3Bu/uUUYTz9PzIE6GsiMHSn 3W0VKpTvnKP5X4I6USaoX/SmQewr0NueLnsSQiXv74EuD9rBBMz/WhBXnTn3au51+WFf 8FZeVm4s4tC9XbJ66OyXVAa65ruOzH0lUzEVfowMLiQPiAmGMXHeW1NKhqyf5pnJy4aM FVWg==
X-Gm-Message-State: AKwxytdwtWfnlqEgrlyn0MeFGB04IkYaBExS5R4eKmSeVKYbZpF5oZFr Mr5wvdVbuc/8UYl1H041e2s=
X-Google-Smtp-Source: AH8x226QaxmjqyNNMnPlu+XbMDHKjiLjiyzHgJwwT4leuzQv1kbhLVquRK/hYSXwB3Ps8s+U8JyaDg==
X-Received: by 10.157.86.193 with SMTP id b1mr14506633otj.187.1516920807558; Thu, 25 Jan 2018 14:53:27 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:20bf:4b41:284a:f75]) by smtp.gmail.com with ESMTPSA id r186sm3441537oia.27.2018.01.25.14.53.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 14:53:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Date: Thu, 25 Jan 2018 14:53:23 -0800
Cc: NetMod WG , NetMod WG Chairs 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C84ED22-3BC0-4775-89EB-AE75E0360FFE@gmail.com>
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 22:53:30 -0000

Support.

> On Jan 25, 2018, at 5:26 AM, Lou Berger  wrote:
>=20
> Hi,
>=20
> This is the start of a *two* week poll on making
> draft-bierman-netmod-yang-data-ext a working group document. Please =
send email to the list indicating "yes/support" or "no/do not support".  =
If indicating no, please state your reservations with the document.  If =
yes, please also feel free to provide comments you'd like to see =
addressed once the document is a WG document.
>=20
> This poll ends on February 8.
>=20
> Thank you!
>=20
> Lou (and Co-chairs)
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Fri Jan 26 01:14:47 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 5238412DB6E; Fri, 26 Jan 2018 01:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 hpOs23ZpqCyX; Fri, 26 Jan 2018 01:14:43 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982712D95F; Fri, 26 Jan 2018 01:14:42 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 21D06602F5; Fri, 26 Jan 2018 10:14:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1516958080; bh=1nWFXsE/Dpu+VkPFmfxDm6/x1wdxmwYLQMxttC9901o=; h=To:Date:Subject:From; b=yiZV8z+Ogzm09Hl0YuUYXEHI6sZOfnPffrTTSXCUSKrIx4EDfLAi6Xd5AhLu4FfKK BtGRKa7UyJ3P1UTQaSXpIEWDT7AXACRuRzuuwKB5I80FpO+at///MsMRlLQndR4qfU 4HIejgfnb/d5BHxMTp+p44iRqUkzcK4n5pmPioIw=
Content-Type: text/plain; charset="utf-8"
To: "netmod" , netconf@ietf.org
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Fri, 26 Jan 2018 10:14:40 +0100
Message-ID: <4f1c-5a6af180-b-5fc7eb00@241510494>
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] YANG library bis model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 09:14:46 -0000

Hello,

we have tried implementing the YANG module ietf-yang-library@2018-01-17=
.yang from draft-ietf-netconf-rfc7895 and have encountered a problem. I=
 am not completely certain that the issue is with the model and not our=
 XPath evaluator, but based on the definitions I have found I believe t=
he model is wrong.

   module: ietf-yang-library
     +--ro yang-library
        +--ro module-set* [name]
           +--ro module* [name]
              +--ro name         yang:yang-identifier
              +--ro deviation* [module]
                 +--ro module    -> ../../name

In the tree diagram (I have removed irrelevant parts) it can be seen th=
at there is a "deviation" leafref that should point from one "module" l=
ist instance to another identifying the deviation module. So, the suppo=
sed evaluation should take the following steps: we start with leaf "mod=
ule" we take ".." path so we get the "deviation" list. Then we take ano=
ther ".." and we end up with all the "module" list instances. Finally, =
we try to find "name" leaf in all these instances of the "module" list.=


However, our evaluator and some I have found online (all behaving accor=
ding to XPath definition, I think) proceed differently. At the point of=
 going one step up (parent node) into what es expected to be all the "m=
odule" list instances, the context node actually becomes only the *spec=
ific module list instance* we have started from, so when looking for th=
e "name" leaf only the name of this list instance is taken into conside=
ration. Needless to say, the evaluation never finds a matching "name" l=
eaf because "module/name" and "module/deviation/module" should never ma=
tch in one "module" list instance and so the validation always fails.

Kind regards,
Michal Vasko


From nobody Fri Jan 26 01:55: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 2C27312E04A for ; Fri, 26 Jan 2018 01:55:37 -0800 (PST)
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_RP_MATCHES_RCVD=-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 fE5N4T0iRYfE for ; Fri, 26 Jan 2018 01:55:34 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E0012E04D for ; Fri, 26 Jan 2018 01:55:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21958; q=dns/txt; s=iport; t=1516960533; x=1518170133; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=Mv2k0BDHGpfCs+203AsQK7kNNoxNeQVyQ8wOVq3f0FE=; b=eJupTqnbACcMFBM3Z4TiZqxZvZu9AkBAwsMj8t+/QOiZXJv/2T2zw8uM IcBBScZknsPL/rNsALavv971GpCV9JMkSCyYnZuoR5jwhvilBBibD9VBo tNwBkkL/lXXTvFgnWcM/YcyCo8gKAcLOw+EvP/mYZzcNoKPtfvC/RcPmr 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdBAB2+mpa/xbLJq1DGhoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGEKHQng12LGKFphVQVggIKJoUVAhqCVxYBAQEBAQEBAQJrKEIBAQM?= =?us-ascii?q?JAoRSBiNmCUQCAgJVBg0IAQEWihsQM5QpnXGCJyaKMwEBAQEBAQQBAQEBAQEBH?= =?us-ascii?q?AWEUoNsgWgphE6BZgIBAQEBgTUigy2CZQWaEooBiBeNT4IbhiCDcYd8in+CYYF?= =?us-ascii?q?siBOBPCYKKIFQMxoIGxWCZ4JhgXhANwGHQoIJhDkBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,415,1511827200"; d="scan'208,217";a="1609772"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 09:55:31 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0Q9tVcf014479 for ; Fri, 26 Jan 2018 09:55:31 GMT
References: <2a8653ac-eee8-3ced-4644-23c04cf87a51@cisco.com>
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: <2a8653ac-eee8-3ced-4644-23c04cf87a51@cisco.com>
Message-ID: <7cd9c63c-8bbe-e7c3-3cb0-dc5c1ebc7304@cisco.com>
Date: Fri, 26 Jan 2018 10:55:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <2a8653ac-eee8-3ced-4644-23c04cf87a51@cisco.com>
Content-Type: multipart/alternative; boundary="------------9238D757FC0528D05C5DB009"
Content-Language: en-US
Archived-At: 
Subject: [netmod] YANG modules publication: what to focus on next? Jan 26th
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 09:55:37 -0000

This is a multi-part message in MIME format.
--------------9238D757FC0528D05C5DB009
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication=20
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me=20
share it with everybody.
Here is an update after yesterday telechat:=20
draft-ietf-netmod-rfc8022bis-10=20
 and=20
draft-ietf-netmod-entity-08=20
 are approved=


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue=20
)
 =C2=A0 Note that draft-ietf-netmod-revised-datastores, a normative refer=
ence=20
for many YANG modules,
 =C2=A0 was just approved. Good news!

We now have many YANG modules in RFC editor queue:
***draft-ietf-lime-yang-connectionless-oam-18=20
**
****draft-ietf-lime-yang-connectionless-oam-methods-13=20
**
****draft-ietf-i2rs-yang-l3-topology-16=20
**
****draft-ietf-i2rs-yang-network-topo-20=20
**
****draft-wu-l3sm-rfc8049bis-11=20
****
**draft-ietf-netconf-rfc6536bis-09=20

*draft-ietf-netmod-rfc7223bis-03=20

draft-ietf-netmod-rfc7277bis-03=20

draft-ietf-rtgwg-yang-vrrp-09=20

draft-ietf-rtgwg-yang-rip-08=20

draft-ietf-netmod-revised-datastores-10=20

draft-ietf-netmod-rfc8022bis-10=20

draft-ietf-netmod-entity-08=20


Here are the YANG module dependencies=20
=20
for these RFC editor modules, as requirement before publishing.

Some more YANG modules are on the IESG table:
 =C2=A0=C2=A0=C2=A0 draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG tele=
chat)
draft-ietf-rtgwg-ni-model-06=20
 is on the=20
Feb 8th IESG telechat
draft-ietf-rtgwg-lne-model-05=20
 is on the =

Jan 25th IESG telechat
draft-ietf-netmod-yang-tree-diagrams-05=20
i=
s=20
on the Jan 25th IESG telechat

Assuming those are in the RFC editor queue, this is the new set of YANG=20
module dependencies=20
.
It takes a little bit of re-arrangering the elements, but all the=20
information is there.

The next bottlenecks for publishing those YANG modules are:
 =C2=A0=C2=A0=C2=A0 draft-ietf-netmod-schema-mount
 =C2=A0=C2=A0=C2=A0 ietf-bfd-yang (currently in WG LC)
 =C2=A0=C2=A0=C2=A0 draft-ietf-ospf-yang
 =C2=A0=C2=A0=C2=A0 draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NI, LNE, and schema mount, RFC7895bis, schema mount:_
 =C2=A0=C2=A0=C2=A0 draft-ietf-rtgwg-lne-model
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: on the next IESG telechat
 =C2=A0=C2=A0=C2=A0 draft-ietf-rtgwg-ni-model
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: on the next IESG telechat
 =C2=A0=C2=A0=C2=A0 draft-ietf-netmod-schema-mount:
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: Under discussion in NETMOD=

 =C2=A0=C2=A0=C2=A0 draft-ietf-netconf-rfc7895bis
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: Under discussion in NETMOD=


_NETMOD:_
draft-ietf-netmod-syslog-model-17=20
=20
almost done
draft-ietf-netmod-acl-model-15=20


_NETCONF:_
 =C2=A0=C2=A0=C2=A0 Time to progress this set of documents (TLS, SSH, cli=
ent, server,=20
keystore)=20


_LIME:_
draft-ietf-lime-yang-connection-oriented-oam-model-00
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: AD review done


Regards, Benoit

--------------9238D757FC0528D05C5DB009
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KDQogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl
IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICA8L2hlYWQ+DQogIDxi
b2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgIERlYXIgYWxsLDxi
cj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otZm9yd2FyZC1jb250YWluZXIiPg0KICAgICAgPGRp
diBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgPGRpdiBjbGFzcz0i
bW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJtb3otZm9y
d2FyZC1jb250YWluZXIiPg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQt
Y29udGFpbmVyIj4gPGJyPg0KICAgICAgICAgICAgICBBdCB0aGUgbGFzdCBJRVRGIG1lZXRp
bmcsIEFsaWEsIERlYm9yYWggYW5kIEkgbG9va2VkIGF0DQogICAgICAgICAgICAgIHRoZSBw
dWJsaWNhdGlvbiBzdGF0dXMgb2YgbW9zdCBZQU5HIG1vZHVsZXMuPGJyPg0KICAgICAgICAg
ICAgICBTaW5jZSB0aGF0IHRpbWUsIEkndmUgYmVlbiBrZWVwaW5nIGEgc3VtbWFyeSBvZiB0
aGUNCiAgICAgICAgICAgICAgc2l0dWF0aW9uLiBMZXQgbWUgc2hhcmUgaXQgd2l0aCBldmVy
eWJvZHkuPGJyPg0KICAgICAgICAgICAgICBIZXJlIGlzIGFuIHVwZGF0ZSBhZnRlciB5ZXN0
ZXJkYXkgdGVsZWNoYXQ6IDxhDQogICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy8iPmRy
YWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMTA8L2E+DQogICAgICAgICAgICAgIGFuZCA8
YQ0KICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS8iPmRyYWZ0LWlldGYtbmV0bW9kLWVudGl0
eS0wODwvYT4NCiAgICAgICAgICAgICAgYXJlIGFwcHJvdmVkPGJyPg0KICAgICAgICAgICAg
ICA8YnI+DQogICAgICAgICAgICAgIEJlZm9yZSBwdWJsaXNoaW5nIFlBTkcgbW9kdWxlcywg
d2UgaGF2ZSB0d28gc2VyaWVzIG9mDQogICAgICAgICAgICAgIGJvdHRsZW5lY2tzOiA8YnI+
DQogICAgICAgICAgICAgIC0gdGhlIFlBTkcgbW9kdWxlIGltcG9ydCAoc2hvd24gYnkgdG9v
bGluZyBiZWxvdyk8YnI+DQogICAgICAgICAgICAgIC0gdGhlIG5vcm1hdGl2ZSByZWZlcmVu
Y2VzIChNSVNTUkVGIGluIHRoZSA8YQ0KICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2Vu
ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9y
Lm9yZy9jdXJyZW50X3F1ZXVlLnBocCI+UkZDDQogICAgICAgICAgICAgICAgZWRpdG9yIHF1
ZXVlPC9hPik8YnI+DQogICAgICAgICAgICAgIMKgIE5vdGUgdGhhdCBkcmFmdC1pZXRmLW5l
dG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMsIGENCiAgICAgICAgICAgICAgbm9ybWF0aXZlIHJl
ZmVyZW5jZSBmb3IgbWFueSBZQU5HIG1vZHVsZXMsPGJyPg0KICAgICAgICAgICAgICDCoCB3
YXMganVzdCBhcHByb3ZlZC4gR29vZCBuZXdzITxicj4NCiAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICBXZSBub3cgaGF2ZSBtYW55IFlBTkcgbW9kdWxlcyBpbiBSRkMgZWRp
dG9yIHF1ZXVlOjxicj4NCiAgICAgICAgICAgICAgPGI+wqDCoMKgIDwvYj48Yj48YQ0KaHJl
Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1saW1lLXlh
bmctY29ubmVjdGlvbmxlc3Mtb2FtIg0KICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0tMTg8
L2E+PC9iPjxiPjxicj4NCiAgICAgICAgICAgICAgPC9iPjxiPsKgwqDCoCA8L2I+PGI+PGEN
CmhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlt
ZS15YW5nLWNvbm5lY3Rpb25sZXNzLW9hbS1tZXRob2RzIg0KICAgICAgICAgICAgICAgICAg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9u
bGVzcy1vYW0tbWV0aG9kcy0xMzwvYT48L2I+PGI+PGJyPg0KICAgICAgICAgICAgICA8L2I+
PGI+wqDCoMKgIDwvYj48Yj48YQ0KICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xv
Z3kiDQogICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRyYWZ0LWll
dGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTE2PC9hPjwvYj48Yj48YnI+DQogICAgICAgICAg
ICAgIDwvYj48Yj7CoMKgwqAgPC9iPjxiPjxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8iDQogICAg
ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRyYWZ0LWlldGYtaTJycy15
YW5nLW5ldHdvcmstdG9wby0yMDwvYT48L2I+PGI+PGJyPg0KICAgICAgICAgICAgICA8L2I+
PGI+wqDCoMKgIDwvYj48Yj48YQ0KICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzIg0KICAg
ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC13dS1sM3NtLXJm
YzgwNDliaXMtMTE8L2E+PC9iPjxiPg0KICAgICAgICAgICAgICA8L2I+PGI+PGJyPg0KICAg
ICAgICAgICAgICAgIMKgwqDCoCA8L2I+PGI+PGENCiAgICAgICAgICAgICAgICAgIGhyZWY9
Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1y
ZmM2NTM2YmlzIg0KICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5k
cmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcy0wOTwvYT48YnI+DQogICAgICAgICAgICAg
ICAgwqDCoMKgIDwvYj48YQ0KICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMvIg0KICAg
ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1uZXRtb2Qt
cmZjNzIyM2Jpcy0wMzwvYT48YnI+DQogICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAg
ICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LWlldGYtbmV0bW9kLXJmYzcyNzdiaXMvIg0KICAgICAgICAgICAgICAgIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMzwvYT48YnI+DQog
ICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy12cnJwLyIN
CiAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRyYWZ0LWlldGYtcnRn
d2cteWFuZy12cnJwLTA5PC9hPjxicj4NCiAgICAgICAgICAgICAgwqDCoMKgIDxhDQogICAg
ICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1ydGd3Zy15YW5nLXJpcC8iDQogICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLXJ0Z3dnLXlhbmctcmlwLTA4PC9hPjxicj4NCiAgICAg
ICAgICAgICAgwqDCoMKgIDxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMvIg0KICAgICAgICAg
ICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNl
ZC1kYXRhc3RvcmVzLTEwPC9hPjxicj4NCiAgICAgICAgICAgICAgwqDCoMKgIDxhDQogICAg
ICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy8iPmRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJi
aXMtMTA8L2E+PGJyPg0KICAgICAgICAgICAgICDCoMKgwqAgPGENCiAgICAgICAgICAgICAg
ICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5l
dG1vZC1lbnRpdHkvIj5kcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDg8L2E+PGJyPg0KICAg
ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSINCmhyZWY9Imh0dHBzOi8vd3d3LnlhbmdjYXRhbG9nLm9yZy95YW5nLXNlYXJjaC9pbXBh
Y3RfYW5hbHlzaXMucGhwP21vZHVsZXNbXT1pZXRmLWlwJmFtcDttb2R1bGVzW109aWV0Zi1j
b25uZWN0aW9ubGVzcy1vYW0mYW1wO21vZHVsZXNbXT1pZXRmLWxpbWUtdGltZS10eXBlcyZh
bXA7bW9kdWxlc1tdPWlldGYtY29ubmVjdGlvbmxlc3Mtb2FtLW1ldGhvZHMmYW1wO21vZHVs
ZXNbXT1pZXRmLWwzLXVuaWNhc3QtdG9wb2xvZ3kmYW1wO21vZHVsZXNbXT1pZXRmLWwzLXVu
aWNhc3QtdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xv
Z3kmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVs
ZXNbXT1pZXRmLW5ldHdvcmsmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstc3RhdGUmYW1w
O21vZHVsZXNbXT1pZXRmLWwzdnBuLXN2YyZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29uZi1h
Y20mYW1wO21vZHVsZXNbXT1pZXRmLWludGVyZmFjZXMmYW1wO21vZHVsZXNbXT1pZXRmLXZy
cnAmYW1wO21vZHVsZXNbXT1pZXRmLXJpcCZhbXA7bW9kdWxlc1tdPWlldGYtZGF0YXN0b3Jl
cyZhbXA7bW9kdWxlc1tdPWlldGYtb3JpZ2luJmFtcDttb2R1bGVzW109aWV0Zi1pcHY0LXVu
aWNhc3Qtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtaXB2Ni11bmljYXN0LXJvdXRpbmcm
YW1wO21vZHVsZXNbXT1pZXRmLWlwdjYtcm91dGVyLWFkdmVydGlzZW1lbnRzJmFtcDttb2R1
bGVzW109aWV0Zi1yb3V0aW5nJmFtcDttb2R1bGVzW109aWFuYS1oYXJkd2FyZSZhbXA7bW9k
dWxlc1tdPWlldGYtaGFyZHdhcmUmYW1wO21vZHVsZXNbXT1pZXRmLWhhcmR3YXJlLXN0YXRl
JmFtcDtyZWN1cnNlPTEmYW1wO3JmY3M9MSZhbXA7c2hvd19zdWJtPTEmYW1wO3Nob3dfZGly
PWRlcGVuZGVuY2llcyI+SGVyZQ0KICAgICAgICAgICAgICAgIGFyZSB0aGUgWUFORyBtb2R1
bGUgZGVwZW5kZW5jaWVzPC9hPiBmb3IgdGhlc2UgUkZDDQogICAgICAgICAgICAgIGVkaXRv
ciBtb2R1bGVzLCBhcyByZXF1aXJlbWVudCBiZWZvcmUgcHVibGlzaGluZy48YnI+DQogICAg
ICAgICAgICAgIDxkaXYgY2xhc3M9Im1vei1mb3J3YXJkLWNvbnRhaW5lciI+DQogICAgICAg
ICAgICAgICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAg
ICAgICAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+IDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgU29tZSBtb3JlIFlBTkcgbW9kdWxlcyBhcmUgb24gdGhlIElFU0cgdGFi
bGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1waW0teWFu
ZyBoYXMgYSBESVNDVVNTIChKYW4gMTF0aCBJRVNHDQogICAgICAgICAgICAgICAgICAgIHRl
bGVjaGF0KTxicj4NCiAgICAgICAgICAgICAgICAgICAgwqDCoMKgIDxhDQogICAgICAgICAg
ICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbC8iPmRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwtMDY8
L2E+DQogICAgICAgICAgICAgICAgICAgIGlzIG9uIHRoZSBGZWIgOHRoIElFU0cgdGVsZWNo
YXQ8YnI+DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAg
ICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtcnRnd2ctbG5lLW1vZGVsLyI+ZHJhZnQtaWV0Zi1ydGd3Zy1sbmUtbW9kZWwtMDU8L2E+
DQogICAgICAgICAgICAgICAgICAgIGlzIG9uIHRoZSBKYW4gMjV0aCBJRVNHIHRlbGVjaGF0
IMKgwqAgPGJyPg0KICAgICAgICAgICAgICAgICAgICDCoMKgwqAgPGENCmhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJl
ZS1kaWFncmFtcy8iPmRyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcy0wNcKg
DQogICAgICAgICAgICAgICAgICAgIDwvYT5pcyBvbiB0aGUgSmFuIDI1dGggSUVTRyB0ZWxl
Y2hhdCDCoMKgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICBBc3N1bWluZyB0aG9zZSBhcmUgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUsIHRo
aXMgaXMNCiAgICAgICAgICAgICAgICAgICAgdGhlIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSINCmhyZWY9Imh0dHBzOi8vd3d3LnlhbmdjYXRhbG9nLm9yZy95YW5nLXNlYXJjaC9pbXBh
Y3RfYW5hbHlzaXMucGhwP21vZHVsZXNbXT1pZXRmLWlwJmFtcDttb2R1bGVzW109aWV0Zi1j
b25uZWN0aW9ubGVzcy1vYW0mYW1wO21vZHVsZXNbXT1pZXRmLWxpbWUtdGltZS10eXBlcyZh
bXA7bW9kdWxlc1tdPWlldGYtY29ubmVjdGlvbmxlc3Mtb2FtLW1ldGhvZHMmYW1wO21vZHVs
ZXNbXT1pZXRmLWwzLXVuaWNhc3QtdG9wb2xvZ3kmYW1wO21vZHVsZXNbXT1pZXRmLWwzLXVu
aWNhc3QtdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xv
Z3kmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVs
ZXNbXT1pZXRmLW5ldHdvcmsmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstc3RhdGUmYW1w
O21vZHVsZXNbXT1pZXRmLWwzdnBuLXN2YyZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29uZi1h
Y20mYW1wO21vZHVsZXNbXT1pZXRmLWludGVyZmFjZXMmYW1wO21vZHVsZXNbXT1pZXRmLXZy
cnAmYW1wO21vZHVsZXNbXT1pZXRmLXJpcCZhbXA7bW9kdWxlc1tdPWlldGYtZGF0YXN0b3Jl
cyZhbXA7bW9kdWxlc1tdPWlldGYtb3JpZ2luJmFtcDttb2R1bGVzW109aWV0Zi1pcHY0LXVu
aWNhc3Qtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtaXB2Ni11bmljYXN0LXJvdXRpbmcm
YW1wO21vZHVsZXNbXT1pZXRmLWlwdjYtcm91dGVyLWFkdmVydGlzZW1lbnRzJmFtcDttb2R1
bGVzW109aWV0Zi1yb3V0aW5nJmFtcDttb2R1bGVzW109aWFuYS1oYXJkd2FyZSZhbXA7bW9k
dWxlc1tdPWlldGYtaGFyZHdhcmUmYW1wO21vZHVsZXNbXT1pZXRmLWhhcmR3YXJlLXN0YXRl
JmFtcDttb2R1bGVzW109aWV0Zi1waW0tYmFzZSZhbXA7bW9kdWxlc1tdPWlldGYtcGltLWJp
ZGlyJmFtcDttb2R1bGVzW109aWV0Zi1waW0tZG0mYW1wO21vZHVsZXNbXT1pZXRmLXBpbS1y
cCZhbXA7bW9kdWxlc1tdPWlldGYtcGltLXNtJmFtcDttb2R1bGVzW109aWV0Zi1uZXR3b3Jr
LWluc3RhbmNlJmFtcDttb2R1bGVzW109aWV0Zi1sb2dpY2FsLW5ldHdvcmstZWxlbWVudCZh
bXA7cmVjdXJzZT0xJmFtcDtyZmNzPTEmYW1wO3Nob3dfc3VibT0xJmFtcDtzaG93X2Rpcj1k
ZXBlbmRlbmNpZXMiPm5ldw0KICAgICAgICAgICAgICAgICAgICAgIHNldCBvZiBZQU5HIG1v
ZHVsZSBkZXBlbmRlbmNpZXM8L2E+Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgSXQgdGFr
ZXMgYSBsaXR0bGUgYml0IG9mIHJlLWFycmFuZ2VyaW5nIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICBlbGVtZW50cywgYnV0IGFsbCB0aGUgaW5mb3JtYXRpb24gaXMgdGhlcmUuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgIDxmb250IGNv
bG9yPSIjZmYwMDAwIj5UaGUgbmV4dCBib3R0bGVuZWNrcyBmb3INCiAgICAgICAgICAgICAg
ICAgICAgICBwdWJsaXNoaW5nIHRob3NlIFlBTkcgbW9kdWxlcyBhcmU6PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQ8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgwqDCoMKgIGlldGYtYmZkLXlhbmcgKGN1cnJl
bnRseSBpbiBXRyBMQyk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgwqDCoMKgIGRyYWZ0
LWlldGYtb3NwZi15YW5nPGJyPg0KICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCBkcmFm
dC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZzxicj4NCiAgICAgICAgICAgICAgICAgICAgICBQ
bGVhc2UgcHJvZ3Jlc3MgdGhvc2UgZG9jdW1lbnRzIGFzYXA8L2ZvbnQ+PGJyPg0KICAgICAg
ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgIFNvbWUgbW9yZSB1cGRh
dGVzIGJlbG93Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICA8dT4gTkksIExORSwgYW5kIHNjaGVtYSBtb3VudCwgUkZDNzg5NWJpcywgc2No
ZW1hDQogICAgICAgICAgICAgICAgICAgICAgbW91bnQ6PC91Pjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtcnRnd2ctbG5lLW1vZGVsPGJyPg0KICAgICAg
ICAgICAgICAgICAgICDCoMKgwqAgwqDCoMKgIFN0YXR1czogb24gdGhlIG5leHQgSUVTRyB0
ZWxlY2hhdDxicj4NCiAgICAgICAgICAgICAgICAgICAgwqDCoMKgIGRyYWZ0LWlldGYtcnRn
d2ctbmktbW9kZWw8YnI+DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCDCoMKgwqAgU3Rh
dHVzOiBvbiB0aGUgbmV4dCBJRVNHIHRlbGVjaGF0PGJyPg0KICAgICAgICAgICAgICAgICAg
ICDCoMKgwqAgZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50Ojxicj4NCiAgICAgICAg
ICAgICAgICAgICAgwqDCoMKgIMKgwqDCoCBTdGF0dXM6IFVuZGVyIGRpc2N1c3Npb24gaW4g
TkVUTU9EPGJyPg0KICAgICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1uZXRj
b25mLXJmYzc4OTViaXM8YnI+DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCDCoMKgwqAg
U3RhdHVzOiBVbmRlciBkaXNjdXNzaW9uIGluIE5FVE1PRDxicj4NCiAgICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg
ICA8dT5ORVRNT0Q6PC91Pjxicj4NCiAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAg
ICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwvIj5kcmFmdC1pZXRmLW5ldG1vZC1z
eXNsb2ctbW9kZWwtMTc8L2E+DQogICAgICAgICAgICAgICAgICBhbG1vc3QgZG9uZTxicj4N
CiAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAgICAgICBocmVm
PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1h
Y2wtbW9kZWwvIj5kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTU8L2E+PGJyPg0KICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPHU+TkVUQ09ORjo8L3U+
PGJyPg0KICAgICAgICAgICAgICAgICAgwqDCoMKgIFRpbWUgdG8gcHJvZ3Jlc3MgPGEgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cueWFuZ2NhdGFsb2cub3Jn
L3lhbmctc2VhcmNoL2ltcGFjdF9hbmFseXNpcy5waHA/bW9kdWxlc1tdPWlldGYtdGxzLWNs
aWVudCZhbXA7bW9kdWxlc1tdPWlldGYtdGxzLXNlcnZlciZhbXA7bW9kdWxlc1tdPWlldGYt
c3NoLWNsaWVudCZhbXA7bW9kdWxlc1tdPWlldGYtc3NoLXNlcnZlciZhbXA7bW9kdWxlc1td
PWlldGYtcmVzdGNvbmYtY2xpZW50JmFtcDttb2R1bGVzW109aWV0Zi1yZXN0Y29uZi1zZXJ2
ZXImYW1wO21vZHVsZXNbXT1pZXRmLWtleXN0b3JlJmFtcDttb2R1bGVzW109aWV0Zi1uZXRj
b25mLWNsaWVudCZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29uZi1zZXJ2ZXImYW1wO29yZ3Nb
XT1pZXRmJmFtcDtyZWN1cnNlPSZhbXA7cmZjcz0xIj50aGlzDQogICAgICAgICAgICAgICAg
ICAgIHNldCBvZiBkb2N1bWVudHMgKFRMUywgU1NILCBjbGllbnQsIHNlcnZlciwNCiAgICAg
ICAgICAgICAgICAgICAga2V5c3RvcmUpPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgIDx1PkxJTUU6PC91Pjxicj4NCiAgICAgICAgICAgICAg
ICAgIMKgwqDCoA0KICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1saW1lLXlhbmctY29u
bmVjdGlvbi1vcmllbnRlZC1vYW0tbW9kZWwtMDA8YnI+DQogICAgICAgICAgICAgICAgICDC
oMKgwqAgwqDCoMKgIFN0YXR1czogQUQgcmV2aWV3IGRvbmU8YnI+DQogICAgICAgICAgICAg
ICAgICA8YnI+DQogICAgICAgICAgICAgICAgICDCoMKgwqAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgUmVnYXJkcywgQmVub2l0PGJyPg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvZGl2Pg0KICA8L2JvZHk+
DQo8L2h0bWw+DQo=
--------------9238D757FC0528D05C5DB009--


From nobody Fri Jan 26 01:55: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 CC48812E04A; Fri, 26 Jan 2018 01:55:38 -0800 (PST)
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_RP_MATCHES_RCVD=-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 rK-XZzgcGiFi; Fri, 26 Jan 2018 01:55:36 -0800 (PST)
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 3B2E012D892; Fri, 26 Jan 2018 01:55:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2147; q=dns/txt; s=iport; t=1516960536; x=1518170136; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=VPl0w2MwOd04gBwMZmxqdWZN0JpNnpZRxauaupJwBxY=; b=loyBrxFULDNKUgaqf4BPorpLR1NzBH873EQQXkIl+beYDRkAy3zSdbXe X71fQPWiA5yRKSsUUEOF9S/eH7bZHGCKsm7HMV5/Z27/HBX4aEdkV2T5t +snGjnZ+SqbAjpPdrZ4bz5SeFFTvNo43AzdoEci6Cv3EFDf57GcR5rpIa c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQBT+mpa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj1Inl1mCAgoYC4RJTwKCcxQBAQEBAQEBAQJrKIU?= =?us-ascii?q?jAQEBAwEBASEECwEFNhALCxgCAiYCAicwBgEMBgIBAYopCBCyS4FtOopZAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARoFgQ+DQ4NsghEMgnmDLwEBAoFXgy+CZQWSPIdWigG?= =?us-ascii?q?VZowsh3yPTIgTgTw2IoFQMxoIGxU9giqEWEE3izwsgh0BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,415,1511827200";  d="scan'208";a="1615223"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 09:55:34 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0Q9tYln005892; Fri, 26 Jan 2018 09:55:34 GMT
To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , netmod , netconf@ietf.org
References: <4f1c-5a6af180-b-5fc7eb00@241510494>
From: Robert Wilton 
Message-ID: <14c97065-5e5b-2670-6b7b-ee1eb01a8fa1@cisco.com>
Date: Fri, 26 Jan 2018 09:55:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <4f1c-5a6af180-b-5fc7eb00@241510494>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] YANG library bis model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 09:55:39 -0000

Hi Michal,

Thanks for raising this.

On 26/01/2018 09:14, Michal Vaško wrote:
> Hello,
>
> we have tried implementing the YANG module ietf-yang-library@2018-01-17.yang from draft-ietf-netconf-rfc7895 and have encountered a problem. I am not completely certain that the issue is with the model and not our XPath evaluator, but based on the definitions I have found I believe the model is wrong.
>
>     module: ietf-yang-library
>       +--ro yang-library
>          +--ro module-set* [name]
>             +--ro module* [name]
>                +--ro name         yang:yang-identifier
>                +--ro deviation* [module]
>                   +--ro module    -> ../../name
>
> In the tree diagram (I have removed irrelevant parts) it can be seen that there is a "deviation" leafref that should point from one "module" list instance to another identifying the deviation module. So, the supposed evaluation should take the following steps: we start with leaf "module" we take ".." path so we get the "deviation" list. Then we take another ".." and we end up with all the "module" list instances. Finally, we try to find "name" leaf in all these instances of the "module" list.
>
> However, our evaluator and some I have found online (all behaving according to XPath definition, I think) proceed differently. At the point of going one step up (parent node) into what es expected to be all the "module" list instances, the context node actually becomes only the *specific module list instance* we have started from, so when looking for the "name" leaf only the name of this list instance is taken into consideration. Needless to say, the evaluation never finds a matching "name" leaf because "module/name" and "module/deviation/module" should never match in one "module" list instance and so the validation always fails.
It looks like the leafref should be "../../../module/name".

Does that fix the issue for you?

Thanks,
Rob


> Kind regards,
> Michal Vasko
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> .
>


From nobody Fri Jan 26 02:05:48 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 7BBDB12D9FE; Fri, 26 Jan 2018 02:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 rpjtVDOWdCgq; Fri, 26 Jan 2018 02:05:39 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A2012D849; Fri, 26 Jan 2018 02:05:18 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 34461602F5; Fri, 26 Jan 2018 11:05:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1516961116; bh=Wz6fYuvGKhw5o1uS7fwMPLF+//+A3XQIUTD2rk5u+V4=; h=In-Reply-To:From:Date:Cc:To:Subject; b=D3i/FKRbT8Rt2gzP4pfWjNTR+XBkwNy8yjJwLF9wizNX/sbmB5HiLGspEFAgdYiIv 5KzObnMvrUY/pxWDqvLLL/bimoLFm732qhiCac9NbLD2EW+hKRYM+JO1oq7o8obryk lqhgaHwokxQhNULBFfN439OgJ6SwC2NFronktjLA=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <14c97065-5e5b-2670-6b7b-ee1eb01a8fa1@cisco.com>
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
Date: Fri, 26 Jan 2018 11:05:16 +0100
Cc: "netmod" , netconf@ietf.org
To: "Robert Wilton" 
MIME-Version: 1.0
Message-ID: <1ed4-5a6afd80-13-59123580@152590790>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod]  =?utf-8?b?Pz09P3V0Zi04P3E/IFtOZXRjb25mXSBZQU5HIGxpYnJh?= =?utf-8?q?ry_bis_model?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 10:05:47 -0000

Hi Rob,

I have forgotten to mention that I have fixed it by modifying the leafr=
ef path the exact same way you proposed, it works fine that way.

Regards,
Michal

On Friday, January 26, 2018 10:55 CET, Robert Wilton  wrote: 
 
> Hi Michal,
> 
> Thanks for raising this.
> 
> On 26/01/2018 09:14, Michal Va=C5=A1ko wrote:
> > Hello,
> >
> > we have tried implementing the YANG module ietf-yang-library@2018-0=
1-17.yang from draft-ietf-netconf-rfc7895 and have encountered a proble=
m. I am not completely certain that the issue is with the model and not=
 our XPath evaluator, but based on the definitions I have found I belie=
ve the model is wrong.
> >
> >     module: ietf-yang-library
> >       +--ro yang-library
> >          +--ro module-set* [name]
> >             +--ro module* [name]
> >                +--ro name         yang:yang-identifier
> >                +--ro deviation* [module]
> >                   +--ro module    -> ../../name
> >
> > In the tree diagram (I have removed irrelevant parts) it can be see=
n that there is a "deviation" leafref that should point from one "modul=
e" list instance to another identifying the deviation module. So, the s=
upposed evaluation should take the following steps: we start with leaf =
"module" we take ".." path so we get the "deviation" list. Then we take=
 another ".." and we end up with all the "module" list instances. Final=
ly, we try to find "name" leaf in all these instances of the "module" l=
ist.
> >
> > However, our evaluator and some I have found online (all behaving a=
ccording to XPath definition, I think) proceed differently. At the poin=
t of going one step up (parent node) into what es expected to be all th=
e "module" list instances, the context node actually becomes only the *=
specific module list instance* we have started from, so when looking fo=
r the "name" leaf only the name of this list instance is taken into con=
sideration. Needless to say, the evaluation never finds a matching "nam=
e" leaf because "module/name" and "module/deviation/module" should neve=
r match in one "module" list instance and so the validation always fail=
s.
> It looks like the leafref should be "../../../module/name".
> 
> Does that fix the issue for you?
> 
> Thanks,
> Rob
> 
> 
> > Kind regards,
> > Michal Vasko
> >
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> > .
> >
> 
 
 


From nobody Fri Jan 26 02:29: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 3AED612E870; Fri, 26 Jan 2018 02:29:10 -0800 (PST)
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_RP_MATCHES_RCVD=-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 f3PGY-HNZ667; Fri, 26 Jan 2018 02:29:08 -0800 (PST)
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 BC46C12E869; Fri, 26 Jan 2018 02:29:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2671; q=dns/txt; s=iport; t=1516962548; x=1518172148; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=P092M8Q4XUyAeo+8lTW0PrRNWNY88hkhhGfHQdub4lo=; b=eDD2RDaX4RhGasF7+N75zBm0vTOWdlqinDGeT6Qanap7QulwGTypjriV p4HUU3/j/nopHQam+smne7cRwarFELGKluZrUErqpl2BdJZHCMpge/Hrp V8nZ2ntZ28DvzukETiVmeJ24hNZtflefJWVSMkEb5QhcZ2v/lbNVpNrkm w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQB4Amta/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj3mXWYICChgLhElPAoJzFAEBAQEBAQEBAmsohSQ?= =?us-ascii?q?BAQQBASEECwEFNgsQCxgCAiYCAicwBg0GAgEBijEQshiBbTqKWAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEaBYEPg0ODbIIRgwWDLwEBAoFXgy+CZQWSPJFXlWaMLId8j0y?= =?us-ascii?q?IE4E8NiKBUDMaCBsVPYIqhFhBN4s8LIIdAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,415,1511827200";  d="scan'208";a="1663341"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 10:29:05 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0QAT50v026060; Fri, 26 Jan 2018 10:29:05 GMT
To: =?UTF-8?Q?Michal_Va=c5=a1ko?= 
Cc: netmod , netconf@ietf.org
References: <1ed4-5a6afd80-13-59123580@152590790>
From: Robert Wilton 
Message-ID: 
Date: Fri, 26 Jan 2018 10:29:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1ed4-5a6afd80-13-59123580@152590790>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] YANG library bis model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 10:29:10 -0000

Hi Michal,

I've fixed this in the latest draft.

Thanks again for pointing this out.
Rob


On 26/01/2018 10:05, Michal Vaško wrote:
> Hi Rob,
>
> I have forgotten to mention that I have fixed it by modifying the leafref path the exact same way you proposed, it works fine that way.
>
> Regards,
> Michal
>
> On Friday, January 26, 2018 10:55 CET, Robert Wilton  wrote:
>   
>> Hi Michal,
>>
>> Thanks for raising this.
>>
>> On 26/01/2018 09:14, Michal Vaško wrote:
>>> Hello,
>>>
>>> we have tried implementing the YANG module ietf-yang-library@2018-01-17.yang from draft-ietf-netconf-rfc7895 and have encountered a problem. I am not completely certain that the issue is with the model and not our XPath evaluator, but based on the definitions I have found I believe the model is wrong.
>>>
>>>      module: ietf-yang-library
>>>        +--ro yang-library
>>>           +--ro module-set* [name]
>>>              +--ro module* [name]
>>>                 +--ro name         yang:yang-identifier
>>>                 +--ro deviation* [module]
>>>                    +--ro module    -> ../../name
>>>
>>> In the tree diagram (I have removed irrelevant parts) it can be seen that there is a "deviation" leafref that should point from one "module" list instance to another identifying the deviation module. So, the supposed evaluation should take the following steps: we start with leaf "module" we take ".." path so we get the "deviation" list. Then we take another ".." and we end up with all the "module" list instances. Finally, we try to find "name" leaf in all these instances of the "module" list.
>>>
>>> However, our evaluator and some I have found online (all behaving according to XPath definition, I think) proceed differently. At the point of going one step up (parent node) into what es expected to be all the "module" list instances, the context node actually becomes only the *specific module list instance* we have started from, so when looking for the "name" leaf only the name of this list instance is taken into consideration. Needless to say, the evaluation never finds a matching "name" leaf because "module/name" and "module/deviation/module" should never match in one "module" list instance and so the validation always fails.
>> It looks like the leafref should be "../../../module/name".
>>
>> Does that fix the issue for you?
>>
>> Thanks,
>> Rob
>>
>>
>>> Kind regards,
>>> Michal Vasko
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>> .
>>>
>   
>   
>
> .
>


From nobody Fri Jan 26 04: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 A334712DA1D; Fri, 26 Jan 2018 04:01:08 -0800 (PST)
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_RP_MATCHES_RCVD=-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 Ds32VTjaSd1A; Fri, 26 Jan 2018 04:01:06 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDA912D946; Fri, 26 Jan 2018 04:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9186; q=dns/txt; s=iport; t=1516968066; x=1518177666; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mawhOgM+SU/94s7CC/0S84Cs8HIAuGcTUvNaP0EbnE4=; b=ZWK0L+PKEUqDv2kbTC2Hh9Ge5Wj1Rspxc3vJ8j9aO6rvl6jHG6fG8Y4L RPiZpFnI4+juI55ufIyI6FS2se3TrixNO+UNftRMC0/hP/8nj3GIdl9Rr Q1nLX85XPdPS67bM+EEBPx3dHR1YbaayXI9Xg9WeX7IfOeEzLA+y+A6Rv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQDiF2ta/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgV50J4NdixiPeJFwh2sKGAEKhElPAoJ1FAEBAQEBAQEBAms?= =?us-ascii?q?ohSQBAQQBASFLCxAJEAoqAgInMAYBDAYCAQGKMRCTYZ1xgicmijEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYRSg2yBaCmGNAEBAgGBWIMtgmUFpBOIF41PghuGIIN?= =?us-ascii?q?xh3yKf4JhgWyIE4E8NiIlgSszGggbFT2CKoRYQTcBAY4DAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,416,1511827200"; d="scan'208,217";a="1611657"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 12:01:03 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0QC131c022777; Fri, 26 Jan 2018 12:01:03 GMT
To: Mahesh Jethanandani , netconf 
Cc: NETMOD Working Group 
References: 
From: Robert Wilton 
Message-ID: 
Date: Fri, 26 Jan 2018 12:01:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4BF34C2E5CC90A2DD2A11A13"
Content-Language: en-US
Archived-At: 
Subject: [netmod] WG LC comment on draft-ietf-netconf-nmda-netconf-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 12:01:08 -0000

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

Hi,

One minor point that came up after the WG LC drafts had been posted is 
that draft-ietf-netconf-nmda-netconf-02 explicitly references the path 
"/yang-library/checksum", which means that the draft has a hard 
dependency on this leaf always existing at this path in YANG library.

e.g. section 2 of draft-ietf-netconf-nmda-netconf-02 contains:

    The parameter "checksum" has the same value as the leaf
    "/yang-library/checksum" from "ietf-yang-library".  This parameter
    MUST be present.

I think that it would be more flexible if the draft only referred to a 
"YANG library checksum", and then have Yang Library bis formally define 
the "YANG library checksum" term.  This is to avoid the need to formally 
update NMDA NETCONF draft, if the checksum path ever needs to be updated 
in a future revision of YANG library.


To give an example of where we hit a similar issue, was in RFC 7950, 
section 5.6.4, that has to be updated by 
draft-ietf-netconf-nmda-netconf-02 because it explicitly references the 
"/modules-state/module" list.   Generally, I think that it would be good 
to try and avoid these tight dependencies where possible, and try to 
have them more loosely coupled.

E.g., text from 7950:


        5.6.4 .
        Announcing Conformance Information in NETCONF



    This document defines the following mechanism for announcing
    conformance information.  Other mechanisms may be defined by future
    specifications.

    A NETCONF server MUST announce the modules it implements (see
    Section 5.6.5 ) by implementing the YANG module "ietf-yang-library"
    defined in [RFC7895 ] and listing all implemented modules in the
    "/modules-state/module" list.


Requiring this text in draft-ietf-netconf-nmda-netconf-02:

    This document updates [RFC7950], Section 5.6.4, to allow servers to
    advertise the capability :yang-library:1.1 instead of :yang-
    library:1.0, and to implement the subtree "/yang-library"
    [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".

Thanks,
Rob



On 17/01/2018 18:39, Mahesh Jethanandani wrote:
> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.
>
> This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.
>
> Authors please indicate whether you are aware of any IPR for either of the drafts.
>
> Thanks.
>
> Mahesh & Kent
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------4BF34C2E5CC90A2DD2A11A13
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    
One minor point that came up after the WG LC drafts had been
      posted is that draft-ietf-netconf-nmda-netconf-02 explicitly
      references the path "/yang-library/checksum", which means that the
      draft has a hard dependency on this leaf always existing at this
      path in YANG library.

    

    
e.g. section 2 of draft-ietf-netconf-nmda-netconf-02 contains:

    

    
   The parameter "checksum" has the same value as the leaf
   "/yang-library/checksum" from "ietf-yang-library".  This parameter
   MUST be present.

    
I think that it would be more flexible if the draft only referred
      to a "YANG library checksum", and then have Yang Library bis
      formally define the "YANG library checksum" term.  This is to
      avoid the need to formally update NMDA NETCONF draft, if the
      checksum path ever needs to be updated in a future revision of
      YANG library.

    


    

    
To give an example of where we hit a similar issue, was in RFC
      7950, section 5.6.4, that has to be updated by
      draft-ietf-netconf-nmda-netconf-02 because it explicitly
      references the "/modules-state/module" list.   Generally, I think
      that it would be good to try and avoid these tight dependencies
      where possible, and try to have them more loosely coupled.

    

    
E.g., text from 7950:

    

    
5.6.4.  Announcing Conformance Information in NETCONF


   This document defines the following mechanism for announcing
   conformance information.  Other mechanisms may be defined by future
   specifications.

   A NETCONF server MUST announce the modules it implements (see
   Section 5.6.5) by implementing the YANG module "ietf-yang-library"
   defined in [RFC7895] and listing all implemented modules in the
   "/modules-state/module" list.


    

    Requiring this text in draft-ietf-netconf-nmda-netconf-02:

    

    
   This document updates [RFC7950], Section 5.6.4, to allow servers to
   advertise the capability :yang-library:1.1 instead of :yang-
   library:1.0, and to implement the subtree "/yang-library"
   [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".

    
Thanks,

      Rob

    

    


    

    

    
On 17/01/2018 18:39, Mahesh
      Jethanandani wrote:

    

    

      
The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the drafts.

Thanks.

Mahesh & Kent

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


    

    

  


--------------4BF34C2E5CC90A2DD2A11A13--


From nobody Fri Jan 26 04:19: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 ED48E12EA81; Fri, 26 Jan 2018 04:19:52 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 OuZXq3VV4Fou; Fri, 26 Jan 2018 04:19:51 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F62E12DA1D; Fri, 26 Jan 2018 04:19:51 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D82116BA; Fri, 26 Jan 2018 13:19:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 6_AlSG6oQMwz; Fri, 26 Jan 2018 13:19:30 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Jan 2018 13:19:31 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 936A920149; Fri, 26 Jan 2018 13:19:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ob6cTeEaRmsE; Fri, 26 Jan 2018 13:19:31 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB9A320147; Fri, 26 Jan 2018 13:19:30 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 880E8422B42D; Fri, 26 Jan 2018 13:19:28 +0100 (CET)
Date: Fri, 26 Jan 2018 13:19:28 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Mahesh Jethanandani , netconf , NETMOD Working Group 
Message-ID: <20180126121928.okojvgryszxhubj7@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Mahesh Jethanandani , netconf , NETMOD Working Group 
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] WG LC comment on draft-ietf-netconf-nmda-netconf-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 12:19:53 -0000

I support this proposal.

/js

On Fri, Jan 26, 2018 at 12:01:03PM +0000, Robert Wilton wrote:
> Hi,
> 
> One minor point that came up after the WG LC drafts had been posted is that
> draft-ietf-netconf-nmda-netconf-02 explicitly references the path
> "/yang-library/checksum", which means that the draft has a hard dependency
> on this leaf always existing at this path in YANG library.
> 
> e.g. section 2 of draft-ietf-netconf-nmda-netconf-02 contains:
> 
>    The parameter "checksum" has the same value as the leaf
>    "/yang-library/checksum" from "ietf-yang-library".  This parameter
>    MUST be present.
> 
> I think that it would be more flexible if the draft only referred to a "YANG
> library checksum", and then have Yang Library bis formally define the "YANG
> library checksum" term.  This is to avoid the need to formally update NMDA
> NETCONF draft, if the checksum path ever needs to be updated in a future
> revision of YANG library.
> 
> 
> To give an example of where we hit a similar issue, was in RFC 7950, section
> 5.6.4, that has to be updated by draft-ietf-netconf-nmda-netconf-02 because
> it explicitly references the "/modules-state/module" list.   Generally, I
> think that it would be good to try and avoid these tight dependencies where
> possible, and try to have them more loosely coupled.
> 
> E.g., text from 7950:
> 
> 
>        5.6.4 .
>        Announcing Conformance Information in NETCONF
> 
> 
> 
>    This document defines the following mechanism for announcing
>    conformance information.  Other mechanisms may be defined by future
>    specifications.
> 
>    A NETCONF server MUST announce the modules it implements (see
>    Section 5.6.5 ) by implementing the YANG module "ietf-yang-library"
>    defined in [RFC7895 ] and listing all implemented modules in the
>    "/modules-state/module" list.
> 
> 
> Requiring this text in draft-ietf-netconf-nmda-netconf-02:
> 
>    This document updates [RFC7950], Section 5.6.4, to allow servers to
>    advertise the capability :yang-library:1.1 instead of :yang-
>    library:1.0, and to implement the subtree "/yang-library"
>    [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".
> 
> Thanks,
> Rob
> 
> 
> 
> On 17/01/2018 18:39, Mahesh Jethanandani wrote:
> > The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.
> > 
> > This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.
> > 
> > Authors please indicate whether you are aware of any IPR for either of the drafts.
> > 
> > Thanks.
> > 
> > Mahesh & Kent
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 

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


-- 
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 Jan 26 05:05:19 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 9DA1712E86A; Fri, 26 Jan 2018 05:05:13 -0800 (PST)
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.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151697191362.24413.7930767613752319065@ietfa.amsl.com>
Date: Fri, 26 Jan 2018 05:05:13 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-11.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 13:05:13 -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           : A YANG Data Model for Routing Management (NMDA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-11.txt
	Pages           : 77
	Date            : 2018-01-26

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-11


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 Fri Jan 26 05:08:52 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 311FC12E858 for ; Fri, 26 Jan 2018 05:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.51
X-Spam-Level: 
X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 gX7qyOhxFFwK for ; Fri, 26 Jan 2018 05:08:48 -0800 (PST)
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 296E512DA08 for ; Fri, 26 Jan 2018 05:08:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3326; q=dns/txt; s=iport; t=1516972128; x=1518181728; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MGbPP0eFGMzK5b5Lt02aZc6URumQRA+YZ9Yd8eLN4ec=; b=MhJy/AslrP5NkqQWm226fXDHRN4pKxkSFhN6gL9p13A4hirO0B+poQwR h7t6QlSPVWYe191ks49PKXiY7y254fiExDm8sFFlf+nt6JBnzAC9R8BbD SDjOaLVBLVtZ0qnt7eda8kuqsnIoGoY9AOQxxw2LER87sd9h/kvJFvbdw c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAgB5J2ta/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQYDweDVpkOgUYEEZdrghcKGAuESU8CGgyBd1YWAQEBAQE?= =?us-ascii?q?BAQECayiFGwkCBAEBIRE6CxACAQgQAggCJgICAiULFQIOAhIFhXOEQhCxPIIni?= =?us-ascii?q?lYBAQEBAQEBAQIBAQEBAQEBAQEBAR2BD4NDghWDPykMgnmDLwEBAgEBF4FWgxc?= =?us-ascii?q?UHYI0BaQTAogVjU+CG2eFOYttjWCJUgIRGQGBOwEmByuBUHAVGSQqAVkIgR4Jh?= =?us-ascii?q?E94jG6BFwEBBQ?=
X-IronPort-AV: E=Sophos;i="5.46,416,1511827200"; d="scan'208";a="130163851"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 13:08:47 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0QD8k1D025890 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 26 Jan 2018 13:08:47 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; Fri, 26 Jan 2018 08:08:46 -0500
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, 26 Jan 2018 08:08:46 -0500
From: "Acee Lindem (acee)" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-11.txt
Thread-Index: AQHTlqZq2TJXgAIarUCJ6BeMKRALu6OGIEiA
Date: Fri, 26 Jan 2018 13:08:46 +0000
Message-ID: 
References: <151697191362.24413.7930767613752319065@ietfa.amsl.com>
In-Reply-To: <151697191362.24413.7930767613752319065@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-11.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 13:08:50 -0000

SnVzdCBhIHNtYWxsIGZpeCB0byB0aGUgUklQIFlBTkcgZXhhbXBsZSBiYXNlZCBvbiBjb21tZW50
cyBmcm9tIEZyYW5jaXMgRHVwb250LiANClRoYW5rcywNCkFjZWUgDQoNCu+7v09uIDEvMjYvMTgs
IDg6MDYgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIg
PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh
YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRo
aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgTW9kZWxpbmcgV0cgb2YgdGhl
IElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBIFlBTkcgRGF0YSBN
b2RlbCBmb3IgUm91dGluZyBNYW5hZ2VtZW50IChOTURBIFZlcnNpb24pDQogICAgICAgICAgICBB
dXRob3JzICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEFjZWUgTGluZGVtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZaW5nemhl
biBRdQ0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlz
LTExLnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiA3Nw0KICAgIAlEYXRlICAgICAgICAgICAg
OiAyMDE4LTAxLTI2DQogICAgDQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBj
b250YWlucyBhIHNwZWNpZmljYXRpb24gb2YgdGhyZWUgWUFORyBtb2R1bGVzIGFuZCBvbmUNCiAg
ICAgICBzdWJtb2R1bGUuICBUb2dldGhlciB0aGV5IGZvcm0gdGhlIGNvcmUgcm91dGluZyBkYXRh
IG1vZGVsIHRoYXQNCiAgICAgICBzZXJ2ZXMgYXMgYSBmcmFtZXdvcmsgZm9yIGNvbmZpZ3VyaW5n
IGFuZCBtYW5hZ2luZyBhIHJvdXRpbmcNCiAgICAgICBzdWJzeXN0ZW0uICBJdCBpcyBleHBlY3Rl
ZCB0aGF0IHRoZXNlIG1vZHVsZXMgd2lsbCBiZSBhdWdtZW50ZWQgYnkNCiAgICAgICBhZGRpdGlv
bmFsIFlBTkcgbW9kdWxlcyBkZWZpbmluZyBkYXRhIG1vZGVscyBmb3IgY29udHJvbC1wbGFuZQ0K
ICAgICAgIHByb3RvY29scywgcm91dGUgZmlsdGVycywgYW5kIG90aGVyIGZ1bmN0aW9ucy4gIFRo
ZSBjb3JlIHJvdXRpbmcgZGF0YQ0KICAgICAgIG1vZGVsIHByb3ZpZGVzIGNvbW1vbiBidWlsZGlu
ZyBibG9ja3MgZm9yIHN1Y2ggZXh0ZW5zaW9ucyAtLSByb3V0ZXMsDQogICAgICAgUm91dGluZyBJ
bmZvcm1hdGlvbiBCYXNlcyAoUklCcyksIGFuZCBjb250cm9sLXBsYW5lIHByb3RvY29scy4NCiAg
ICANCiAgICAgICBUaGUgWUFORyBtb2R1bGVzIGluIHRoaXMgZG9jdW1lbnQgY29uZm9ybSB0byB0
aGUgTmV0d29yayBNYW5hZ2VtZW50DQogICAgICAgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSAoTk1E
QSkuICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODAyMi4NCiAgICANCiAgICANCiAgICBU
aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIy
YmlzLw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs
ZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qt
cmZjODAyMmJpcy0xMQ0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv
ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0xMQ0KICAgIA0KICAgIEEgZGlmZiBmcm9tIHRo
ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRm
Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0xMQ0KICAgIA0K
ICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl
cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAg
IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
CiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1h
aWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgDQoNCg==


From nobody Fri Jan 26 06:19: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 5901212DA09 for ; Fri, 26 Jan 2018 06:18:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level: 
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 MWp_m1iHrtJs for ; Fri, 26 Jan 2018 06:18:57 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB512D873 for ; Fri, 26 Jan 2018 06:18:57 -0800 (PST)
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 CC48B62A00; Fri, 26 Jan 2018 14:18:56 +0000 (UTC)
References:  <878tcnz9pc.fsf@nic.cz>
User-agent: mu4e 0.9.18; emacs 25.3.1
From: Christian Hopps 
To: Ladislav Lhotka 
Cc: Kent Watsen , "netmod\@ietf.org" 
In-reply-to: <878tcnz9pc.fsf@nic.cz>
Date: Fri, 26 Jan 2018 09:18:55 -0500
Message-ID: <87wp04og8g.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 14:18:59 -0000

Maybe a meeting at this point is useful? It would consolidate things and
get away from the endless email threads.

If this isn't already known to everyone. There are many people for whom
the length of time to market from IETF simple doesn't work in particular
with models. That's one big reason that openconfig exists. Sitting on
working solutions waiting for them to be perfect is just getting us
ignored by industry.

In particular when I, Lou, et al. realized we needed a way to "mount
schema" for a clean VRF and VM solution, we thought this was a simple
thing and we could do it rather quickly -- the concept is just not that
complex. The idea was picked up by Martin and Lada who produced drafts,
and there were in fact some devil in the details and those got worked
out over longer than anyone wanted, but it is what it is.

Now it seems we are supposed to wait a bunch longer on yet other works
in progress for as near as I can tell (could be wrong here as I just
don't have time to read the very long email threads that netmod
generates) capturing meta-data in a cleaner way than another. This does
*not* seem like a reason to stall this work any further.

Thanks,
Chris.

Ladislav Lhotka  writes:

> Hi,
>
> Kent Watsen  writes:
>
>> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>>
>> Per normal process, drafts typically progress once LC comments are
>> address unless significant faults are found.  Post LC comments have
>> been made, which needed consideration, notably the relationship with
>> NMDA and rfc7895bis and an alternate representation of inline schema.
>> These have been considered respecting their impact on the last call
>> consensus and it is the position of the chairs that it is best to
>> advance the existing schema-mount document at this time.
>
> I guess I have no chance but strongly object to this. Is it normal to
> proceed this way without reaching WG consensus and against the will of
> *both* document authors?
>
>>
>> Given that there are significant concerns for how the solution
>> proposed in this draft operates with NMDA, we do think it reasonable
>> to add an applicability statement to the draft that covers its
>> operation in NMDA implementations. We do not believe that such a
>> statement substantively alters the draft nor would it impact drafts
>> that normatively reference the current draft.
>>
>> In addition to resolving the remaining open thread [1],
>
> Hmm, who resolved this thread? Lou proposed some text and nobody
> expressed any agreement with it. In fact, I believe it is nothing more
> than hand-waving.
>
> I must say that the work on this draft was very frustrating for me. Even
> more than on RFC 8022, and this tells you something.
>
> Lada
>
>> we also agree
>> with the recently made comment that the schema mount draft should
>> allow the use of rfc7895bis (i.e., not reference /modules-state),
>> thereby enabling the draft's use (though not ideal) on servers
>> supporting rfc7895bis.
>>
>> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement.
>>
>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>>
>> Thanks,
>> Kent, Lou, and Joel
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jan 26 06:33: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 82C0C12E86A for ; Fri, 26 Jan 2018 06:33:55 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 pFUoAIftLtKp for ; Fri, 26 Jan 2018 06:33:53 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12212751F for ; Fri, 26 Jan 2018 06:33:53 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 816C31AE0118; Fri, 26 Jan 2018 15:33:52 +0100 (CET)
Date: Fri, 26 Jan 2018 15:33:52 +0100 (CET)
Message-Id: <20180126.153352.606955299235802591.mbj@tail-f.com>
To: chopps@chopps.org
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87wp04og8g.fsf@chopps.org>
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 14:33:55 -0000

Hi,

Christian Hopps  wrote:
> 
> Maybe a meeting at this point is useful? It would consolidate things and
> get away from the endless email threads.
> 
> If this isn't already known to everyone. There are many people for whom
> the length of time to market from IETF simple doesn't work in particular
> with models. That's one big reason that openconfig exists. Sitting on
> working solutions waiting for them to be perfect is just getting us
> ignored by industry.
> 
> In particular when I, Lou, et al. realized we needed a way to "mount
> schema" for a clean VRF and VM solution, we thought this was a simple
> thing and we could do it rather quickly -- the concept is just not that
> complex. The idea was picked up by Martin and Lada who produced drafts,
> and there were in fact some devil in the details and those got worked
> out over longer than anyone wanted, but it is what it is.
> 
> Now it seems we are supposed to wait a bunch longer on yet other works
> in progress for as near as I can tell (could be wrong here as I just
> don't have time to read the very long email threads that netmod
> generates) capturing meta-data in a cleaner way than another.

During the time since we started working on schema mount, we (the WG)
have also defined the NMDA.  All we (the SM authors and others) are
asking for is that schema mount is defined to be compatible with the
NMDA.  This is something we (the IETF) currently require of all other
drafts.

The missing piece of this puzzle is the new YANG library.  During the
interim in December a solution was picked.  This solution is
documented in the latest draft, and a new version of this draft will
be published next week, which we hope can go to WGLC.


/martin


This does
> *not* seem like a reason to stall this work any further.
> 
> Thanks,
> Chris.
> 
> Ladislav Lhotka  writes:
> 
> > Hi,
> >
> > Kent Watsen  writes:
> >
> >> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
> >>
> >> Per normal process, drafts typically progress once LC comments are
> >> address unless significant faults are found.  Post LC comments have
> >> been made, which needed consideration, notably the relationship with
> >> NMDA and rfc7895bis and an alternate representation of inline schema.
> >> These have been considered respecting their impact on the last call
> >> consensus and it is the position of the chairs that it is best to
> >> advance the existing schema-mount document at this time.
> >
> > I guess I have no chance but strongly object to this. Is it normal to
> > proceed this way without reaching WG consensus and against the will of
> > *both* document authors?
> >
> >>
> >> Given that there are significant concerns for how the solution
> >> proposed in this draft operates with NMDA, we do think it reasonable
> >> to add an applicability statement to the draft that covers its
> >> operation in NMDA implementations. We do not believe that such a
> >> statement substantively alters the draft nor would it impact drafts
> >> that normatively reference the current draft.
> >>
> >> In addition to resolving the remaining open thread [1],
> >
> > Hmm, who resolved this thread? Lou proposed some text and nobody
> > expressed any agreement with it. In fact, I believe it is nothing more
> > than hand-waving.
> >
> > I must say that the work on this draft was very frustrating for me. Even
> > more than on RFC 8022, and this tells you something.
> >
> > Lada
> >
> >> we also agree
> >> with the recently made comment that the schema mount draft should
> >> allow the use of rfc7895bis (i.e., not reference /modules-state),
> >> thereby enabling the draft's use (though not ideal) on servers
> >> supporting rfc7895bis.
> >>
> >> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement.
> >>
> >> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
> >>
> >> Thanks,
> >> Kent, Lou, and Joel
> >>
> >>
> >>
> >> _______________________________________________
> >> 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 Fri Jan 26 06:40:07 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 668CD12751F for ; Fri, 26 Jan 2018 06:40:05 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 TYZbnfltmtp0 for ; Fri, 26 Jan 2018 06:40:02 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 498E4124B17 for ; Fri, 26 Jan 2018 06:40:02 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id 68so1912264ite.4 for ; Fri, 26 Jan 2018 06:40:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K3h0BHbasPzbyE3RWesJsjTzsxkPgz4k8PU+lvl7/yo=; b=oFE1plQlwXZ+ayGpxtwPbyJoM++Anv4UaGbrPob+VFIAuqwqmQho5FfeaaKavKEiBb 4mc2Th6vz9NhkkwrS/3raFL+54a+oTIOi/GzsvXqTVt+UEWD7M3MXrsYIeTvTEfmp4Dx 6u6KPX8FtnpAXH2hQ0hbCO5HG4ZSpZLhifbk0=
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=K3h0BHbasPzbyE3RWesJsjTzsxkPgz4k8PU+lvl7/yo=; b=AJA5RwDhILxAUrc72cudmOd96PJeItT6KCC88D6w0SjGX4MqxtIt8NoZm2r4bB1wS+ raV2yNmD5LYxmnAhCVvYBNUHRoSaRPL9MFkIQFhDYugQcT8+ZQVZ1CfmjYFcATJ+S6rs HxzxTw9Z+0w2oJPvRVaMo2DJkKioOSaFRLUZ+HQJllfFdpV6aquNzO/Xd0V4WmK4w9xO eqcDH6O2j/aGlV2EkkTMaRrWYlQN1l6pUiFFn4rnDBXD7Ey8cd6L3yqqwOreJYfmbBoK rYLZ1/rTIdXbvZupAad+xYg8iPAFQFd4z/gLqL7kufIQNGLNq+IuRMArNRtkmuU/sgh6 f50w==
X-Gm-Message-State: AKwxyteaj4bNrTg8mGg1x+Lw/IRWs5xYbT3dEX5vhcuWsD3XXDX//aXa xaFS69LuhFN19JpueVCD9FlTnrn5xlz3ovul04zO354D
X-Google-Smtp-Source: AH8x226/qJURBCampadnzYEy693aXduZQTqFQjHhbX1IkiF2rRQUXqGyxQwhAj7+BMSEV9jOdEi4aUpe0WDVY3XZPhw=
X-Received: by 10.36.86.15 with SMTP id o15mr17869627itb.60.1516977601548; Fri, 26 Jan 2018 06:40:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.12.142 with HTTP; Fri, 26 Jan 2018 06:40:00 -0800 (PST)
In-Reply-To: <87wp04og8g.fsf@chopps.org>
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org>
From: David Bannister 
Date: Fri, 26 Jan 2018 09:40:00 -0500
Message-ID: 
To: Christian Hopps 
Cc: Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1144d5fe12c87f0563aedf2c"
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 14:40:05 -0000

--001a1144d5fe12c87f0563aedf2c
Content-Type: text/plain; charset="UTF-8"

Chris +1 on the taking too long in pursuit of the perfect model.  No
service provider or enterprise wants to put their network evolution on hold
waiting for the IETF.  Instead they will seek what they need from other
SDOs as you point out.  The IETF needs to modernize their process and
perhaps adopt some of the methods used by OpenConfig.  Read that as getting
away from a long drawn out consensus process that turns into a multi-year
effort.

On Fri, Jan 26, 2018 at 9:18 AM, Christian Hopps  wrote:

>
> Maybe a meeting at this point is useful? It would consolidate things and
> get away from the endless email threads.
>
> If this isn't already known to everyone. There are many people for whom
> the length of time to market from IETF simple doesn't work in particular
> with models. That's one big reason that openconfig exists. Sitting on
> working solutions waiting for them to be perfect is just getting us
> ignored by industry.
>
> In particular when I, Lou, et al. realized we needed a way to "mount
> schema" for a clean VRF and VM solution, we thought this was a simple
> thing and we could do it rather quickly -- the concept is just not that
> complex. The idea was picked up by Martin and Lada who produced drafts,
> and there were in fact some devil in the details and those got worked
> out over longer than anyone wanted, but it is what it is.
>
> Now it seems we are supposed to wait a bunch longer on yet other works
> in progress for as near as I can tell (could be wrong here as I just
> don't have time to read the very long email threads that netmod
> generates) capturing meta-data in a cleaner way than another. This does
> *not* seem like a reason to stall this work any further.
>
> Thanks,
> Chris.
>
> Ladislav Lhotka  writes:
>
> > Hi,
> >
> > Kent Watsen  writes:
> >
> >> Thank you all for the important discussion since the completion of WGLC
> on Nov 6th.
> >>
> >> Per normal process, drafts typically progress once LC comments are
> >> address unless significant faults are found.  Post LC comments have
> >> been made, which needed consideration, notably the relationship with
> >> NMDA and rfc7895bis and an alternate representation of inline schema.
> >> These have been considered respecting their impact on the last call
> >> consensus and it is the position of the chairs that it is best to
> >> advance the existing schema-mount document at this time.
> >
> > I guess I have no chance but strongly object to this. Is it normal to
> > proceed this way without reaching WG consensus and against the will of
> > *both* document authors?
> >
> >>
> >> Given that there are significant concerns for how the solution
> >> proposed in this draft operates with NMDA, we do think it reasonable
> >> to add an applicability statement to the draft that covers its
> >> operation in NMDA implementations. We do not believe that such a
> >> statement substantively alters the draft nor would it impact drafts
> >> that normatively reference the current draft.
> >>
> >> In addition to resolving the remaining open thread [1],
> >
> > Hmm, who resolved this thread? Lou proposed some text and nobody
> > expressed any agreement with it. In fact, I believe it is nothing more
> > than hand-waving.
> >
> > I must say that the work on this draft was very frustrating for me. Even
> > more than on RFC 8022, and this tells you something.
> >
> > Lada
> >
> >> we also agree
> >> with the recently made comment that the schema mount draft should
> >> allow the use of rfc7895bis (i.e., not reference /modules-state),
> >> thereby enabling the draft's use (though not ideal) on servers
> >> supporting rfc7895bis.
> >>
> >> The chairs will propose specific text for the updates mentioned in this
> message to be reviewed by the WG for correctness before final submission
> and advancement.
> >>
> >> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
> >>
> >> Thanks,
> >> Kent, Lou, and Joel
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>

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


Chris +1 on the taking too long in pursuit of the perfect =
model.=C2=A0 No service provider or enterprise wants to put their network e=
volution on hold waiting for the IETF.=C2=A0 Instead they will seek what th=
ey need from other SDOs as you point out.=C2=A0 The IETF needs to modernize=
 their process and perhaps adopt some of the methods used by OpenConfig.=C2=
=A0 Read that as getting away from a long drawn out consensus process that =
turns into a multi-year effort.

On Fri, Jan 26, 2018 at 9:18 AM, Christian Hopps <=
chopps@chopps.org> wrote:
<=
br>
Maybe a meeting at this point is useful? It would consolidate things and
get away from the endless email threads.



If this isn't already known to everyone. There are many people for whom=


the length of time to market from IETF simple doesn't work in particula=
r

with models. That's one big reason that openconfig exists. Sitting on
working solutions waiting for them to be perfect is just getting us

ignored by industry.



In particular when I, Lou, et al. realized we needed a way to "mount
schema" for a clean VRF and VM solution, we thought this was a simple<=
br>
thing and we could do it rather quickly -- the concept is just not that

complex. The idea was picked up by Martin and Lada who produced drafts,

and there were in fact some devil in the details and those got worked

out over longer than anyone wanted, but it is what it is.



Now it seems we are supposed to wait a bunch longer on yet other works

in progress for as near as I can tell (could be wrong here as I just

don't have time to read the very long email threads that netmod

generates) capturing meta-data in a cleaner way than another. This does

*not* seem like a reason to stall this work any further.



Thanks,

Chris.



Ladislav Lhotka <lhotka@nic.cz> =
writes:



> Hi,

>

> Kent Watsen <kwatsen@juniper=
.net> writes:

>

>> Thank you all for the important discussion since the completion of=
 WGLC on Nov 6th.

>>

>> Per normal process, drafts typically progress once LC comments are=


>> address unless significant faults are found.=C2=A0 Post LC comment=
s have

>> been made, which needed consideration, notably the relationship wi=
th

>> NMDA and rfc7895bis and an alternate representation of inline sche=
ma.

>> These have been considered respecting their impact on the last cal=
l

>> consensus and it is the position of the chairs that it is best to<=
br>
>> advance the existing schema-mount document at this time.

>

> I guess I have no chance but strongly object to this. Is it normal to<=
br>
> proceed this way without reaching WG consensus and against the will of=


> *both* document authors?

>

>>

>> Given that there are significant concerns for how the solution

>> proposed in this draft operates with NMDA, we do think it reasonab=
le

>> to add an applicability statement to the draft that covers its

>> operation in NMDA implementations. We do not believe that such a
>> statement substantively alters the draft nor would it impact draft=
s

>> that normatively reference the current draft.

>>

>> In addition to resolving the remaining open thread [1],

>

> Hmm, who resolved this thread? Lou proposed some text and nobody

> expressed any agreement with it. In fact, I believe it is nothing more=


> than hand-waving.

>

> I must say that the work on this draft was very frustrating for me. Ev=
en

> more than on RFC 8022, and this tells you something.

>

> Lada

>

>> we also agree

>> with the recently made comment that the schema mount draft should<=
br>
>> allow the use of rfc7895bis (i.e., not reference /modules-state),<=
br>
>> thereby enabling the draft's use (though not ideal) on servers=


>> supporting rfc7895bis.

>>

>> The chairs will propose specific text for the updates mentioned in=
 this message to be reviewed by the WG for correctness before final submiss=
ion and advancement.

>>

>> [1] https://www.ietf.org/=
mail-archive/web/netmod/current/msg20049.html

>>

>> Thanks,

>> Kent, Lou, and Joel

>>

>>

>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netm=
od



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a1144d5fe12c87f0563aedf2c--


From nobody Fri Jan 26 06:42: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 803CC12D87C for ; Fri, 26 Jan 2018 06:42:01 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 6lNIHVEGFQFJ for ; Fri, 26 Jan 2018 06:42:00 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0498512751F for ; Fri, 26 Jan 2018 06:42:00 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BF630FAC; Fri, 26 Jan 2018 15:41:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZdQl9B5D_lxR; Fri, 26 Jan 2018 15:41:39 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Jan 2018 15:41:40 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C3E72014B; Fri, 26 Jan 2018 15:41:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PHMfTWOYXeav; Fri, 26 Jan 2018 15:41:40 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41E0C20147; Fri, 26 Jan 2018 15:41:39 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 36062422BA5E; Fri, 26 Jan 2018 15:41:38 +0100 (CET)
Date: Fri, 26 Jan 2018 15:41:38 +0100
From: Juergen Schoenwaelder 
To: Christian Hopps 
Cc: Ladislav Lhotka , "netmod@ietf.org" 
Message-ID: <20180126144138.tvx3375i5gshwu45@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , Ladislav Lhotka , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87wp04og8g.fsf@chopps.org>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 14:42:01 -0000

On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
> 
> Now it seems we are supposed to wait a bunch longer on yet other works
> in progress for as near as I can tell (could be wrong here as I just
> don't have time to read the very long email threads that netmod
> generates) capturing meta-data in a cleaner way than another. This does
> *not* seem like a reason to stall this work any further.
>

What is your interpretation of 'a bunch longer'? Or said differently,
how much time do you think it will take to get the current schema
mount approved (which has pending WG last call issues) and how much
time would you find acceptable for a solution that also complies with
NMDA and YANG library bis? I believe people are willing to give the
later high priority.

/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 Jan 26 07:04: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 6C9CE12DA70 for ; Fri, 26 Jan 2018 07:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level: 
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 7_tMSvjO8lu0 for ; Fri, 26 Jan 2018 07:04:25 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9199212D87D for ; Fri, 26 Jan 2018 07:04:25 -0800 (PST)
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 B41D662A00; Fri, 26 Jan 2018 15:04:24 +0000 (UTC)
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126.153352.606955299235802591.mbj@tail-f.com>
User-agent: mu4e 0.9.18; emacs 25.3.1
From: Christian Hopps 
To: Martin Bjorklund 
Cc: lhotka@nic.cz, netmod@ietf.org
In-reply-to: <20180126.153352.606955299235802591.mbj@tail-f.com>
Date: Fri, 26 Jan 2018 10:04:23 -0500
Message-ID: <87tvv8oe4o.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 15:04:27 -0000

Unfortunately, I don't have time to go into a multi-email back and forth
justifying point by point. The model is going on 2 years old now, I
think it works just fine for what operators need, and see no issue with
NMDA -- it should just work that was the point behind the NMDA design.

Thanks,
Chris.

Martin Bjorklund  writes:

> Hi,
>
> Christian Hopps  wrote:
>>
>> Maybe a meeting at this point is useful? It would consolidate things and
>> get away from the endless email threads.
>>
>> If this isn't already known to everyone. There are many people for whom
>> the length of time to market from IETF simple doesn't work in particular
>> with models. That's one big reason that openconfig exists. Sitting on
>> working solutions waiting for them to be perfect is just getting us
>> ignored by industry.
>>
>> In particular when I, Lou, et al. realized we needed a way to "mount
>> schema" for a clean VRF and VM solution, we thought this was a simple
>> thing and we could do it rather quickly -- the concept is just not that
>> complex. The idea was picked up by Martin and Lada who produced drafts,
>> and there were in fact some devil in the details and those got worked
>> out over longer than anyone wanted, but it is what it is.
>>
>> Now it seems we are supposed to wait a bunch longer on yet other works
>> in progress for as near as I can tell (could be wrong here as I just
>> don't have time to read the very long email threads that netmod
>> generates) capturing meta-data in a cleaner way than another.
>
> During the time since we started working on schema mount, we (the WG)
> have also defined the NMDA.  All we (the SM authors and others) are
> asking for is that schema mount is defined to be compatible with the
> NMDA.  This is something we (the IETF) currently require of all other
> drafts.
>
> The missing piece of this puzzle is the new YANG library.  During the
> interim in December a solution was picked.  This solution is
> documented in the latest draft, and a new version of this draft will
> be published next week, which we hope can go to WGLC.
>
>
> /martin
>
>
> This does
>> *not* seem like a reason to stall this work any further.
>>
>> Thanks,
>> Chris.
>>
>> Ladislav Lhotka  writes:
>>
>> > Hi,
>> >
>> > Kent Watsen  writes:
>> >
>> >> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>> >>
>> >> Per normal process, drafts typically progress once LC comments are
>> >> address unless significant faults are found.  Post LC comments have
>> >> been made, which needed consideration, notably the relationship with
>> >> NMDA and rfc7895bis and an alternate representation of inline schema.
>> >> These have been considered respecting their impact on the last call
>> >> consensus and it is the position of the chairs that it is best to
>> >> advance the existing schema-mount document at this time.
>> >
>> > I guess I have no chance but strongly object to this. Is it normal to
>> > proceed this way without reaching WG consensus and against the will of
>> > *both* document authors?
>> >
>> >>
>> >> Given that there are significant concerns for how the solution
>> >> proposed in this draft operates with NMDA, we do think it reasonable
>> >> to add an applicability statement to the draft that covers its
>> >> operation in NMDA implementations. We do not believe that such a
>> >> statement substantively alters the draft nor would it impact drafts
>> >> that normatively reference the current draft.
>> >>
>> >> In addition to resolving the remaining open thread [1],
>> >
>> > Hmm, who resolved this thread? Lou proposed some text and nobody
>> > expressed any agreement with it. In fact, I believe it is nothing more
>> > than hand-waving.
>> >
>> > I must say that the work on this draft was very frustrating for me. Even
>> > more than on RFC 8022, and this tells you something.
>> >
>> > Lada
>> >
>> >> we also agree
>> >> with the recently made comment that the schema mount draft should
>> >> allow the use of rfc7895bis (i.e., not reference /modules-state),
>> >> thereby enabling the draft's use (though not ideal) on servers
>> >> supporting rfc7895bis.
>> >>
>> >> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement.
>> >>
>> >> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>> >>
>> >> Thanks,
>> >> Kent, Lou, and Joel
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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 Fri Jan 26 07:06:10 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 7DA9512D87D for ; Fri, 26 Jan 2018 07:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level: 
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 ReghnhGKiT6a for ; Fri, 26 Jan 2018 07:06:08 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0612D964 for ; Fri, 26 Jan 2018 07:06:08 -0800 (PST)
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 5424262A00; Fri, 26 Jan 2018 15:06:07 +0000 (UTC)
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local>
User-agent: mu4e 0.9.18; emacs 25.3.1
From: Christian Hopps 
To: Juergen Schoenwaelder 
Cc: Ladislav Lhotka , "netmod\@ietf.org" 
In-reply-to: <20180126144138.tvx3375i5gshwu45@elstar.local>
Date: Fri, 26 Jan 2018 10:06:06 -0500
Message-ID: <87shasoe1t.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 15:06:10 -0000

In the context of holding up this work, I don't care one iota about YANG
library bis, and it works just fine with NMDA AFAICT.

We need models to get work done.

Thanks,
Chris.

Juergen Schoenwaelder  writes:

> On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
>>
>> Now it seems we are supposed to wait a bunch longer on yet other works
>> in progress for as near as I can tell (could be wrong here as I just
>> don't have time to read the very long email threads that netmod
>> generates) capturing meta-data in a cleaner way than another. This does
>> *not* seem like a reason to stall this work any further.
>>
>
> What is your interpretation of 'a bunch longer'? Or said differently,
> how much time do you think it will take to get the current schema
> mount approved (which has pending WG last call issues) and how much
> time would you find acceptable for a solution that also complies with
> NMDA and YANG library bis? I believe people are willing to give the
> later high priority.
>
> /js


From nobody Fri Jan 26 07:23: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 50B74124239 for ; Fri, 26 Jan 2018 07:23:07 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 EvvcpSh3bAcY for ; Fri, 26 Jan 2018 07:23:05 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD60B1241FC for ; Fri, 26 Jan 2018 07:23:04 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A4E0F6B7; Fri, 26 Jan 2018 16:23:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TZLOuoN2HLum; Fri, 26 Jan 2018 16:22:44 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Jan 2018 16:22:45 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7603320149; Fri, 26 Jan 2018 16:22:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bIWrqditbnzn; Fri, 26 Jan 2018 16:22:45 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14F1F20147; Fri, 26 Jan 2018 16:22:45 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B0821422BE43; Fri, 26 Jan 2018 16:22:44 +0100 (CET)
Date: Fri, 26 Jan 2018 16:22:44 +0100
From: Juergen Schoenwaelder 
To: Christian Hopps 
Cc: Ladislav Lhotka , "netmod@ietf.org" 
Message-ID: <20180126152244.5lg4tmn34ktiycw3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , Ladislav Lhotka , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local> <87shasoe1t.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87shasoe1t.fsf@chopps.org>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 15:23:07 -0000

OK, I accept that you do not care. Please also accept that others do
care. And these people believe YANG library bis is needed.

Since you do not want to read emails and involve yourself in
discussions of technical details, I assume this is where our
conversation stops.

I tought you wanted to start a constructive conversation towards a
resolution of the problem but it seems I misunderstood.

/js

On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
> 
> In the context of holding up this work, I don't care one iota about YANG
> library bis, and it works just fine with NMDA AFAICT.
> 
> We need models to get work done.
> 
> Thanks,
> Chris.
> 
> Juergen Schoenwaelder  writes:
> 
> > On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
> >>
> >> Now it seems we are supposed to wait a bunch longer on yet other works
> >> in progress for as near as I can tell (could be wrong here as I just
> >> don't have time to read the very long email threads that netmod
> >> generates) capturing meta-data in a cleaner way than another. This does
> >> *not* seem like a reason to stall this work any further.
> >>
> >
> > What is your interpretation of 'a bunch longer'? Or said differently,
> > how much time do you think it will take to get the current schema
> > mount approved (which has pending WG last call issues) and how much
> > time would you find acceptable for a solution that also complies with
> > NMDA and YANG library bis? I believe people are willing to give the
> > later high priority.
> >
> > /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 Jan 26 07:30:42 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 18262124234 for ; Fri, 26 Jan 2018 07:30:41 -0800 (PST)
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 lhPQCMtBVLBP for ; Fri, 26 Jan 2018 07:30:38 -0800 (PST)
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 5ABF01200FC for ; Fri, 26 Jan 2018 07:30:38 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id l20so2129735qtj.11 for ; Fri, 26 Jan 2018 07:30:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MGEBb2q/URzhNAaqMrdTPfVT4ADeRRknj7Khf8PiRnI=; b=QDmNI/r3Y91V8kDrQc+tyzijTcAU9ItIYooHCjuYmE3SZkPMch28ofpuqmcZdV+o3R LVuVLnxFZeNhkpV5MCtM77nMbzgG4Ci43oReH2dnQ1Z95LM6KWGqxuNR1WQMoSa5/glN vMUQn+bfroTuJ7Iw1ah64evWCYloKlxeQVfVXppgLr0HmYls8PFDen0WxHJ9znNvTp42 39dJSXQf+tMnzZnYdjexyMKF36JjizL3S+iFbrN8at3x92MwhR+lh5VIpDWCmLkm8S7f FS4JepLOqr6XZIVPvLGMk0olumUfBa4xdV3ZF6iqxlvmTR+/lFdR0c4LgO+JHgW96juc r9Vw==
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=MGEBb2q/URzhNAaqMrdTPfVT4ADeRRknj7Khf8PiRnI=; b=VMvErXoyqZzgTSUKkIjqQJCrPGaWiO1ucZHFw35k1bz3TFzxqV7vEjija96ZXzSXmr jVjUeuyCLB+zcQ9zZjRE/KR/7cxdJyswRO8AU8/yYp3GyubrJCd6gMCM+60DnLvL+PRh ObP4Ek7XtQ2yWYglyh4lCE63aD1iDYAM21GOf8wPgQDJbLScA4TD/kA5cPAafLR039vC 0j93H7E2eJbof+wzkFLjs1EegXZyRKw3vdDCuwV6R5rPA6sHn2UaTlGCFioqmjkd8oRf 3xmsJS9Nd6Dg0Kj5tDaN4Pd392TZ5gzltSSvitjXBpmNOIX+SUJjxEgFyfh95xQMczt6 kfjw==
X-Gm-Message-State: AKwxytdAnE4bhIBUB4XzlgsKL7JatgJtMEG/CWgroGWPKai4lqvoPII4 TsfLB3tnoZa5p47yXa0frJtfs2Lm
X-Google-Smtp-Source: AH8x224EwFzeq/X76HlcBVeH2b1vC7+wBANOmenJNESh06c6sabd7ErCRqwthFXNuVhY6CnwOxY6Nw==
X-Received: by 10.55.204.18 with SMTP id r18mr20897548qki.212.1516980637521; Fri, 26 Jan 2018 07:30:37 -0800 (PST)
Received: from [10.0.1.12] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id y24sm2308868qty.40.2018.01.26.07.30.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 07:30:36 -0800 (PST)
From: Dean Bogdanovic 
Message-Id: <69A97D4B-4DD5-4270-9E58-76AF208C3A80@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8314B8F-A022-4455-970A-68D7C56B43FA"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 26 Jan 2018 10:30:35 -0500
In-Reply-To: <20180126152244.5lg4tmn34ktiycw3@elstar.local>
Cc: Christian Hopps , "netmod@ietf.org" 
To: Juergen Schoenwaelder 
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local> <87shasoe1t.fsf@chopps.org> <20180126152244.5lg4tmn34ktiycw3@elstar.local>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 15:30:41 -0000

--Apple-Mail=_B8314B8F-A022-4455-970A-68D7C56B43FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I will ask a different question

How many people have implemented the draft? And are they talking from =
experience implementing the model? I have implemented LNE and NI and to =
be honest, when customers ask about IETF compatibility, i reference a =
draft and tell them it will take long time until IETF finalizes the RFC. =
When it does, we will update the implementation if needed. Within WG are =
hearing very little about implementation and operational experience and =
feedback during the process.=20
If any company had to wait two or more years to release software, they =
would find themselves out of customers.

Dean

> On Jan 26, 2018, at 10:22 AM, Juergen Schoenwaelder =
 wrote:
>=20
> OK, I accept that you do not care. Please also accept that others do
> care. And these people believe YANG library bis is needed.
>=20
> Since you do not want to read emails and involve yourself in
> discussions of technical details, I assume this is where our
> conversation stops.
>=20
> I tought you wanted to start a constructive conversation towards a
> resolution of the problem but it seems I misunderstood.
>=20
> /js
>=20
> On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
>>=20
>> In the context of holding up this work, I don't care one iota about =
YANG
>> library bis, and it works just fine with NMDA AFAICT.
>>=20
>> We need models to get work done.
>>=20
>> Thanks,
>> Chris.
>>=20
>> Juergen Schoenwaelder  writes:
>>=20
>>> On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
>>>>=20
>>>> Now it seems we are supposed to wait a bunch longer on yet other =
works
>>>> in progress for as near as I can tell (could be wrong here as I =
just
>>>> don't have time to read the very long email threads that netmod
>>>> generates) capturing meta-data in a cleaner way than another. This =
does
>>>> *not* seem like a reason to stall this work any further.
>>>>=20
>>>=20
>>> What is your interpretation of 'a bunch longer'? Or said =
differently,
>>> how much time do you think it will take to get the current schema
>>> mount approved (which has pending WG last call issues) and how much
>>> time would you find acceptable for a solution that also complies =
with
>>> NMDA and YANG library bis? I believe people are willing to give the
>>> later high priority.
>>>=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


--Apple-Mail=_B8314B8F-A022-4455-970A-68D7C56B43FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I =
will ask a different question

How many people have implemented the draft? And are they =
talking from experience implementing the model? I have implemented LNE =
and NI and to be honest, when customers ask about IETF compatibility, i =
reference a draft and tell them it will take long time until IETF =
finalizes the RFC. When it does, we will update the implementation if needed. Within WG are hearing very little about =
implementation and operational experience and feedback during the =
process. 
If any company had to wait two or =
more years to release software, they would find themselves out of =
customers.

Dean

On Jan 26, 2018, at 10:22 AM, =
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

OK, =
I accept that you do not care. Please also accept that others do
care. And these people believe YANG library bis is needed.

Since you do not want to read emails and =
involve yourself in
discussions of technical details, I =
assume this is where our
conversation stops.

I tought you wanted to start a constructive =
conversation towards a
resolution of the problem but it =
seems I misunderstood.

/js

On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps =
wrote:

In the context of holding up this work, I don't care one iota =
about YANG
library bis, and it works just fine with NMDA =
AFAICT.

We need models to get work done.

Thanks,
Chris.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

On Fri, =
Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:

Now it =
seems we are supposed to wait a bunch longer on yet other works
in progress for as near as I can tell (could be wrong here as =
I just
don't have time to read the very long email threads =
that netmod
generates) capturing meta-data in a cleaner =
way than another. This does
*not* seem like a reason to =
stall this work any further.

What is your interpretation of 'a bunch longer'? Or said =
differently,
how much time do you think it will take to =
get the current schema
mount approved (which has pending =
WG last call issues) and how much
time would you find =
acceptable for a solution that also complies with
NMDA and =
YANG library bis? I believe people are willing to give the
later high priority.

/js

-- 
Juergen Schoenwaelder =
          Jacobs =
University Bremen gGmbH
Phone: +49 421 200 3587 =
        Campus Ring 1 | 28759 =
Bremen | Germany
Fax:   +49 421 200 3103 =
        <https://www.jacobs-university.de/>

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

=

--Apple-Mail=_B8314B8F-A022-4455-970A-68D7C56B43FA--


From nobody Fri Jan 26 08:40:45 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 827CC129511 for ; Fri, 26 Jan 2018 08:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level: 
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 5TiFHvln0Ojr for ; Fri, 26 Jan 2018 08:40:42 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE8126CF9 for ; Fri, 26 Jan 2018 08:40:41 -0800 (PST)
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 04B3662A00; Fri, 26 Jan 2018 16:40:40 +0000 (UTC)
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local> <87shasoe1t.fsf@chopps.org> <20180126152244.5lg4tmn34ktiycw3@elstar.local>
User-agent: mu4e 0.9.18; emacs 25.3.1
From: Christian Hopps 
To: Juergen Schoenwaelder 
Cc: Ladislav Lhotka , "netmod\@ietf.org" 
In-reply-to: <20180126152244.5lg4tmn34ktiycw3@elstar.local>
Date: Fri, 26 Jan 2018 11:40:39 -0500
Message-ID: <87k1w4o9o8.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 16:40:43 -0000

Hi Juergen,

I want to be understood so I'll reply again. It's not that I don't want
to involve myself in technical discussions, it's that I (and others)
think that what's being discussed now no longer matters to getting work
done. The work is good enough *now*. When we get to this point it
doesn't make sense for me to participate anymore, the problem is solved,
I need to work on other problems that aren't solved yet.

We need models for VRFs and VMs, people are now arguing about having
totally different schema mounted at the same mount point based on the
datastore (?!?) and where exactly the meta-data should reside. It's
divorced from the "get shit done" reality.

Thanks,
Chris.

Juergen Schoenwaelder  writes:

> OK, I accept that you do not care. Please also accept that others do
> care. And these people believe YANG library bis is needed.
>
> Since you do not want to read emails and involve yourself in
> discussions of technical details, I assume this is where our
> conversation stops.
>
> I tought you wanted to start a constructive conversation towards a
> resolution of the problem but it seems I misunderstood.

> /js
>
> On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
>>
>> In the context of holding up this work, I don't care one iota about YANG
>> library bis, and it works just fine with NMDA AFAICT.
>>
>> We need models to get work done.
>>
>> Thanks,
>> Chris.
>>
>> Juergen Schoenwaelder  writes:
>>
>> > On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
>> >>
>> >> Now it seems we are supposed to wait a bunch longer on yet other works
>> >> in progress for as near as I can tell (could be wrong here as I just
>> >> don't have time to read the very long email threads that netmod
>> >> generates) capturing meta-data in a cleaner way than another. This does
>> >> *not* seem like a reason to stall this work any further.
>> >>
>> >
>> > What is your interpretation of 'a bunch longer'? Or said differently,
>> > how much time do you think it will take to get the current schema
>> > mount approved (which has pending WG last call issues) and how much
>> > time would you find acceptable for a solution that also complies with
>> > NMDA and YANG library bis? I believe people are willing to give the
>> > later high priority.
>> >
>> > /js


From nobody Fri Jan 26 09:07: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 4C12912DA49 for ; Fri, 26 Jan 2018 09:07:31 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 INlCrhDYq6Hr for ; Fri, 26 Jan 2018 09:07:29 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48FC126BF0 for ; Fri, 26 Jan 2018 09:07:28 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A4D89FAC; Fri, 26 Jan 2018 18:07:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id x0F-5iSthHaJ; Fri, 26 Jan 2018 18:07:07 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Jan 2018 18:07:09 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4667C2014B; Fri, 26 Jan 2018 18:07:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z_u-MqPzCk2A; Fri, 26 Jan 2018 18:07:08 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CB6B20147; Fri, 26 Jan 2018 18:07:08 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 21168422C0AE; Fri, 26 Jan 2018 18:07:06 +0100 (CET)
Date: Fri, 26 Jan 2018 18:07:06 +0100
From: Juergen Schoenwaelder 
To: Christian Hopps 
Cc: "netmod@ietf.org" 
Message-ID: <20180126170706.qff6pdck2bg3efe6@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , "netmod@ietf.org" 
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local> <87shasoe1t.fsf@chopps.org> <20180126152244.5lg4tmn34ktiycw3@elstar.local> <87k1w4o9o8.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87k1w4o9o8.fsf@chopps.org>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 17:07:31 -0000

Chris,

nobody (I think) is having an issue with the lne and ni models. And it
is great to hear that you have implemented them. However, please also
understand that schema mount is a rather fundamental extension of the
YANG technology and that people maintaining that technology and
writing generic tools need to have this extension work together with
other extensions we have been working on. For you, this may be
irrelevant or not important and it may be 'divorced from your "get
shit done" reality'. But then, please accept that there are other
communities with different priorities.

I believe we will be more effective if we find a way forward that can
work for everybody involved. Trying to convince other communities that
their priorities are plain wrong is neither constructive nor does it
lead to faster progress I think.

/js

On Fri, Jan 26, 2018 at 11:40:39AM -0500, Christian Hopps wrote:
> 
> Hi Juergen,
> 
> I want to be understood so I'll reply again. It's not that I don't want
> to involve myself in technical discussions, it's that I (and others)
> think that what's being discussed now no longer matters to getting work
> done. The work is good enough *now*. When we get to this point it
> doesn't make sense for me to participate anymore, the problem is solved,
> I need to work on other problems that aren't solved yet.
> 
> We need models for VRFs and VMs, people are now arguing about having
> totally different schema mounted at the same mount point based on the
> datastore (?!?) and where exactly the meta-data should reside. It's
> divorced from the "get shit done" reality.
> 
> Thanks,
> Chris.
> 
> Juergen Schoenwaelder  writes:
> 
> > OK, I accept that you do not care. Please also accept that others do
> > care. And these people believe YANG library bis is needed.
> >
> > Since you do not want to read emails and involve yourself in
> > discussions of technical details, I assume this is where our
> > conversation stops.
> >
> > I tought you wanted to start a constructive conversation towards a
> > resolution of the problem but it seems I misunderstood.
> 
> > /js
> >
> > On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
> >>
> >> In the context of holding up this work, I don't care one iota about YANG
> >> library bis, and it works just fine with NMDA AFAICT.
> >>
> >> We need models to get work done.
> >>
> >> Thanks,
> >> Chris.
> >>
> >> Juergen Schoenwaelder  writes:
> >>
> >> > On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
> >> >>
> >> >> Now it seems we are supposed to wait a bunch longer on yet other works
> >> >> in progress for as near as I can tell (could be wrong here as I just
> >> >> don't have time to read the very long email threads that netmod
> >> >> generates) capturing meta-data in a cleaner way than another. This does
> >> >> *not* seem like a reason to stall this work any further.
> >> >>
> >> >
> >> > What is your interpretation of 'a bunch longer'? Or said differently,
> >> > how much time do you think it will take to get the current schema
> >> > mount approved (which has pending WG last call issues) and how much
> >> > time would you find acceptable for a solution that also complies with
> >> > NMDA and YANG library bis? I believe people are willing to give the
> >> > later high priority.
> >> >
> >> > /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 Jan 26 10:11:36 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 080511200E5; Fri, 26 Jan 2018 10:11:34 -0800 (PST)
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 4-SyWHOHQDcy; Fri, 26 Jan 2018 10:11:32 -0800 (PST)
Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::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 16081126CC7; Fri, 26 Jan 2018 10:11:29 -0800 (PST)
Received: by mail-oi0-x243.google.com with SMTP id 5so879811oip.5; Fri, 26 Jan 2018 10:11:29 -0800 (PST)
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=Id7y8Uf2eetfZebA/0U70vXr3rksiSY5pdkayCLBIVY=; b=CRtGmWHMKDXvV2OTiHBp1T2Owg4Muk2WQUZllvuhiI3LC/NZiHTkvL9sKb6xlUFWPf PyEf8sxA/ML1uFv58A59fuaNkreok7VcJeDwEmYQ7wEnAnpjRTtjA1wcgsoYTUEGiIPS 35aaWUCR/mPRfCboQeIqt7gbNvmwT2DoU91WNoBCe6JnZOxKeLWJI0i4RWL19sFCbujS oMiTfjHXmCE7aQ7Qci2J6NS8bK2YTT7KaghnlX3LeiFr7iC8KxaTEO9utLkCqtpw7yvM gXqRk8Kz6Ld0JGRcPssTOhXJ1/H/LLO8YniOQrXMIHmrhqEIi80GaQSCpFevCrWrhPKE aBvA==
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=Id7y8Uf2eetfZebA/0U70vXr3rksiSY5pdkayCLBIVY=; b=VQMd1QmY2IvDuQgZx7KrC6yHA4UgrSffhguWOkKU+UeEJt/nkymaxFROt7BcalcyV8 JpRc/4jf6HZo/kBBhh3dWnkx0whncGLiPimnjlh/SH+0q1VebAVHK6w1/KEV5PqC2/1m K3OhuNVGF9z0cXYP/yZhlIit4tt+MdYuJ/Z3HK+5jhvzvGIRcW+DKAd38++cPSQnAh4L etGbJ5fP8+Lg051uqgPbm0awdHzidVxUJWAqA92+B+zgVqfl3p9y7wfQTPBiQnNZo7K5 34r7aKvprCPjG/WLapZ+/b70Zr5PhlNYwy7k1rc2KYos3QUYNFe7k4X7L7PeYpZd51C2 o5tg==
X-Gm-Message-State: AKwxytcd32EzAPMD5VBJXKkSinwsZw7Xn4+UoRHd5X3iEd+JpUEdxMIQ MJoLYdVEadfVSRpi+Lw+HcgGwCOCGjHo9WqJU08=
X-Google-Smtp-Source: AH8x227BSLq4Xeq+5P2Tav8YYotxKHlKnORgU3QNJB5zAyoDsxkePCbRUJIWUNtUAf0aw+p4YplUf2lNImA24Tf8i+0=
X-Received: by 10.202.183.139 with SMTP id h133mr13420458oif.103.1516990288193;  Fri, 26 Jan 2018 10:11:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.37.125 with HTTP; Fri, 26 Jan 2018 10:11:27 -0800 (PST)
In-Reply-To: <151691255573.8494.16260998328717962330@ietfa.amsl.com>
References: <151691255573.8494.16260998328717962330@ietfa.amsl.com>
From: Phillip Hallam-Baker 
Date: Fri, 26 Jan 2018 13:11:27 -0500
Message-ID: 
To: secdir@ietf.org
Cc: draft-ietf-netmod-yang-tree-diagrams.all@ietf.org,  IETF Discussion Mailing List , netmod@ietf.org
Content-Type: multipart/alternative; boundary="001a113cd22a41707b0563b1d377"
Archived-At: 
Subject: Re: [netmod] [secdir] Secdir telechat review of draft-ietf-netmod-yang-tree-diagrams-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 18:11:34 -0000

--001a113cd22a41707b0563b1d377
Content-Type: text/plain; charset="UTF-8"

Just saw this didn't get the boilerplate added when posted by the tracker.
Please assume it to be there.

On Thu, Jan 25, 2018 at 3:35 PM, Phillip Hallam-Baker 
wrote:

> Reviewer: Phillip Hallam-Baker
> Review result: Has Nits
>
> I have reviewed the document and it is generally free of security
> considerations as claimed. There are some areas of concern however, the
> significance of which may become more apparent as such tools find future
> use.
>
> As described in the document, the tree diagram format is intended to serve
> as
> an output generated by a tool to aid human interpretation. Thus, a
> potential
> ambiguity can arise if the tool used to generate the format is buggy or if
> the
> document contains schema and presentation data compiled from different
> versions
> of the source.
>
> Specifications using this representation need to make clear which
> representation is canonical. Otherwise we end up in a situation in which a
> document that has an ambiguity being unfixable by means of issuing an
> errata
> because there is no agreement as to whether the change is breaking or not.
>
> Another issue that is of concern is that even though the format is not
> intended
> to be an input format, there can be no guarantee it will not be used as
> such.
> Indeed it could be argued that a spec that makes use of this format should
> encourage this approach so as to detect possible ambiguities.
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>



-- 
Website: http://hallambaker.com/

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


Jus=
t saw this didn't get the boilerplate added when posted by the tracker.=
 Please assume it to be there.

On Thu, Jan 25, 2018 at 3:35 PM, Phillip Hallam-Ba=
ker <hallam@gmail.com> wrote:
Reviewer: Phillip Hallam-Baker

Review result: Has Nits



I have reviewed the document and it is generally free of security

considerations as claimed. There are some areas of concern however, the

significance of which may become more apparent as such tools find future us=
e.



As described in the document, the tree diagram format is intended to serve =
as

an output generated by a tool to aid human interpretation. Thus, a potentia=
l

ambiguity can arise if the tool used to generate the format is buggy or if =
the

document contains schema and presentation data compiled from different vers=
ions

of the source.



Specifications using this representation need to make clear which

representation is canonical. Otherwise we end up in a situation in which a<=
br>
document that has an ambiguity being unfixable by means of issuing an errat=
a

because there is no agreement as to whether the change is breaking or not.<=
br>


Another issue that is of concern is that even though the format is not inte=
nded

to be an input format, there can be no guarantee it will not be used as suc=
h.

Indeed it could be argued that a spec that makes use of this format should<=
br>
encourage this approach so as to detect possible ambiguities.



_______________________________________________

secdir mailing list

secdir@ietf.org

https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/=
wiki/SecDirReview





-- 
Website: http://hallambaker.com/
=




--001a113cd22a41707b0563b1d377--


From nobody Fri Jan 26 10:53: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 2753A127076 for ; Fri, 26 Jan 2018 10:53:23 -0800 (PST)
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, MIME_QP_LONG_LINE=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 ZnSEdSmhoogx for ; Fri, 26 Jan 2018 10:53:21 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 364DA126DEE for ; Fri, 26 Jan 2018 10:53:21 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id z17so806758pgc.4 for ; Fri, 26 Jan 2018 10:53:21 -0800 (PST)
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=XpamgWI8+pEz7YQgBLjxA5p8NKNvs6rqV3GHiuWe+qc=; b=YBeQehWRzfe0oWMxkY0P9w7xr51+/AJd/pj4z7St814CTz9DJSjdTGOFEsTdFdsfbU n45s3rldVjeWuC97GZqZCQUkGs68wpFb5Lp4lDk9fboQc/9tF4Shuk0o0IMPVlcH8v6n LtQTFdWyRD9cHMqUFKnTiT+TUT7WwG+nxbo8r/PxQnbDWaI36lbR7nk+zS/yYwcGBhNN wvlEgaUIRuBSP6Y4Kp2NYu3AYDAOYd1DoxyZvkI9fqrBSq26IBOU4RCf5+9JkMdMu3As j2UvQ5v/cQ6fxDDW4LB63IkvcEBJIPFhbsP2JWIlKk3+SZc/uMcUXGqIEuoci0SqJX8b sXrg==
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=XpamgWI8+pEz7YQgBLjxA5p8NKNvs6rqV3GHiuWe+qc=; b=EbeAyvIXkkEvhkOxql3+1QJja3WK3t3LZ+efbDN8L7Xmv96DiIMQNcUDQbefmZCMcC g7nEeUFqQpaERxBmPjwuFMcUbTU+5rSbEkCBI9BwoaZbgyfgll6/Gq6i1ARUc7n5T+yT sgjtyBgUavaPKrilZag8Cw6pHoJnDTUZM0fkCYiSTWh7VbL4oCzRoLh7JzVwixHCbm4D 1IWaD72tplpF4QnsTu09CxgqPsqOdMD83Gp46vZxpbxw5CbwICdxXvXKdoA6cnxSTNUg oWMzLfkPK42ZEtnuARwf1VTm2c+3uCXcSjcb/4WV5NL7pxC17VWvjCetNvLEGby/2n4U fHLg==
X-Gm-Message-State: AKwxytdjvniediRnC/f6uZZw0vk19arMgPB5VZeytK8BPoGhgGUHee1J RnNrNrUC32hvjXL8wcJCH3Y=
X-Google-Smtp-Source: AH8x226CPHGUC/THalvC/bqjPw7WRBHzbIqR6Zt2ZeMWPaZOOtqYU/V5ort6MlDS+3X5TiNAuZq19g==
X-Received: by 10.99.7.14 with SMTP id 14mr16339061pgh.68.1516992800852; Fri, 26 Jan 2018 10:53:20 -0800 (PST)
Received: from [192.168.1.2] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id t25sm9309543pge.41.2018.01.26.10.53.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 10:53:20 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-70A9CCC0-3BA9-46E7-8702-5CA3EFF966D4
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (15C202)
In-Reply-To: <69A97D4B-4DD5-4270-9E58-76AF208C3A80@gmail.com>
Date: Fri, 26 Jan 2018 10:53:19 -0800
Cc: Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <878tcnz9pc.fsf@nic.cz> <87wp04og8g.fsf@chopps.org> <20180126144138.tvx3375i5gshwu45@elstar.local> <87shasoe1t.fsf@chopps.org> <20180126152244.5lg4tmn34ktiycw3@elstar.local> <69A97D4B-4DD5-4270-9E58-76AF208C3A80@gmail.com>
To: Dean Bogdanovic 
Archived-At: 
Subject: Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 18:53:23 -0000

--Apple-Mail-70A9CCC0-3BA9-46E7-8702-5CA3EFF966D4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 Dean.
I=E2=80=99m having this discussion on daily bases...
I do care about sustainability and long term growth though=20

Regards,
Jeff

> On Jan 26, 2018, at 07:30, Dean Bogdanovic  wrote:
>=20
> I will ask a different question
>=20
> How many people have implemented the draft? And are they talking from expe=
rience implementing the model? I have implemented LNE and NI and to be hones=
t, when customers ask about IETF compatibility, i reference a draft and tell=
 them it will take long time until IETF finalizes the RFC. When it does, we w=
ill update the implementation if needed. Within WG are hearing very little a=
bout implementation and operational experience and feedback during the proce=
ss.=20
> If any company had to wait two or more years to release software, they wou=
ld find themselves out of customers.
>=20
> Dean
>=20
>> On Jan 26, 2018, at 10:22 AM, Juergen Schoenwaelder  wrote:
>>=20
>> OK, I accept that you do not care. Please also accept that others do
>> care. And these people believe YANG library bis is needed.
>>=20
>> Since you do not want to read emails and involve yourself in
>> discussions of technical details, I assume this is where our
>> conversation stops.
>>=20
>> I tought you wanted to start a constructive conversation towards a
>> resolution of the problem but it seems I misunderstood.
>>=20
>> /js
>>=20
>>> On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
>>>=20
>>> In the context of holding up this work, I don't care one iota about YANG=

>>> library bis, and it works just fine with NMDA AFAICT.
>>>=20
>>> We need models to get work done.
>>>=20
>>> Thanks,
>>> Chris.
>>>=20
>>> Juergen Schoenwaelder  writes:
>>>=20
>>>>> On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
>>>>>=20
>>>>> Now it seems we are supposed to wait a bunch longer on yet other works=

>>>>> in progress for as near as I can tell (could be wrong here as I just
>>>>> don't have time to read the very long email threads that netmod
>>>>> generates) capturing meta-data in a cleaner way than another. This doe=
s
>>>>> *not* seem like a reason to stall this work any further.
>>>>>=20
>>>>=20
>>>> What is your interpretation of 'a bunch longer'? Or said differently,
>>>> how much time do you think it will take to get the current schema
>>>> mount approved (which has pending WG last call issues) and how much
>>>> time would you find acceptable for a solution that also complies with
>>>> NMDA and YANG library bis? I believe people are willing to give the
>>>> later high priority.
>>>>=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
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--Apple-Mail-70A9CCC0-3BA9-46E7-8702-5CA3EFF966D4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 Dean.
I=E2=80=99m having this discus=
sion on daily bases...
I do care about sustainability and long ter=
m growth though 

Regards,
Jef=
f

On Jan 26, 2018, at 07:30, Dean Bogdanovic <ivandean@gmail.com> wrote:

I will ask a different question

How many people have implemented the=
 draft? And are they talking from experience implementing the model? I have i=
mplemented LNE and NI and to be honest, when customers ask about IETF compat=
ibility, i reference a draft and tell them it will take long time until IETF=
 finalizes the RFC. When it does, we will update the implementation if needed. Within WG are hearing very little about implementation a=
nd operational experience and feedback during the process. 
If any company had to wait two or more years to release software, t=
hey would find themselves out of customers.

Dean

On Jan 26, 2018, at 10:22 AM, Juerge=
n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

OK, I accept t=
hat you do not care. Please also accept that others do
care. A=
nd these people believe YANG library bis is needed.

Since you do not want to read emails and involve yourself in
discussions of technical details, I assume this is where our
conversation stops.

I tought you wanted to sta=
rt a constructive conversation towards a
resolution of the pro=
blem but it seems I misunderstood.

/js

On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hop=
ps wrote:

=
In the context of holding up this work, I don't care one iota about YANG
library bis, and it works just fine with NMDA AFAICT.

We need models to get work done.

Thanks,
Chris.

Juergen Schoenw=
aelder <j.schoenwaelder@jacobs-university.de> writes:

On Fri, Jan 26, 2018 at 09:18:5=
5AM -0500, Christian Hopps wrote:

Now it seems we are supposed to wait a bunch longer o=
n yet other works
in progress for as near as I can tell (could=
 be wrong here as I just
don't have time to read the very long=
 email threads that netmod
generates) capturing meta-data in a=
 cleaner way than another. This does
*not* seem like a reason t=
o stall this work any further.

What is your interpretation of 'a bunch longer'? Or said differe=
ntly,
how much time do you think it will take to get the curre=
nt schema
mount approved (which has pending WG last call issue=
s) and how much
time would you find acceptable for a solution t=
hat also complies with
NMDA and YANG library bis? I believe pe=
ople are willing to give the
later high priority.

/js

=
-- 
Juergen Schoenwaelder       =
    Jacobs University Bremen gGmbH
Phone: +=
49 421 200 3587         Campus Ring 1=
 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 &n=
bsp;       <https://www.jacobs-university.de/>

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

=

--Apple-Mail-70A9CCC0-3BA9-46E7-8702-5CA3EFF966D4--


From nobody Fri Jan 26 20:00: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 0E79612D869 for ; Fri, 26 Jan 2018 20:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 80KAWMYYGgOX for ; Fri, 26 Jan 2018 20:00:36 -0800 (PST)
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 D04151205D3 for ; Fri, 26 Jan 2018 20:00:35 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C72ECBD318327 for ; Sat, 27 Jan 2018 04:00:31 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 27 Jan 2018 04:00:33 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sat, 27 Jan 2018 12:00:25 +0800
From: Qin Wu 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-00.txt
Thread-Index: AQHTlyLTkpEv2GctDkKFlZNYmf1woKOHF23g
Date: Sat, 27 Jan 2018 04:00: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.136.79.67]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jan 2018 04:00:38 -0000

SGksIEZvbGtzOg0KV2UgaGF2ZSBqdXN0IHBvc3RlZCBhIG5ldyB2LSgwMCkgZHJhZnQgdG8gZGlz
Y3VzcyBEb2N1bWVudGF0aW9uIENvbnZlbnRpb25zIGZvciBFeHByZXNzaW5nIFlBTkcgaW4gWE1M
Lg0KWW91IGNvbW1lbnRzIGFyZSB3ZWxjb21lIQ0KDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0t
LS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQx5pyIMjfml6UgMTE6NTYN
CuaUtuS7tuS6ujogQmVub2l0IENsYWlzZTsgUWluIFd1OyBBZHJpYW4gRmFycmVsOyBCZW5vw650
IENsYWlzZQ0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5l
dG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv
ZiBJLUQsIGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDAudHh0DQpo
YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFFpbiBXdSBhbmQgcG9zdGVkIHRvIHRo
ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9j
LWNvbnZlbnRpb25zDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJRG9jdW1lbnRhdGlvbiBDb252ZW50
aW9ucyBmb3IgRXhwcmVzc2luZyBZQU5HIGluIFhNTA0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wMS0y
Ng0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAg
ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2Qt
eWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29u
dmVudGlvbnMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDANCkh0bWxpemVkOiAgICAg
ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1LW5ldG1vZC15
YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIE1hbnkgZG9jdW1l
bnRzIHRoYXQgZGVmaW5lIFlBTkcgbW9kdWxlcyBhbHNvIGluY2x1ZGUgZXhhbXBsZXMNCiAgIHBy
ZXNlbnRlZCBpbiBYTUwuDQoNCiAgIElFVEYgZG9jdW1lbnRhdGlvbiBoYXMgc3BlY2lmaWMgbGlt
aXRzIG9uIGxpbmUgbGVuZ3RoIGFuZCBzb21lIFhNTA0KICAgZXhhbXBsZXMgaGF2ZSB0byBpbmNs
dWRlIGxpbmUgd3JhcHMgdGhhdCB3b3VsZCBub3Qgbm9ybWFsbHkgYmUNCiAgIGFsbG93ZWQgYWNj
b3JkaW5nIHRvIHRoZSBYTUwgcmVwcmVzZW50YXRpb24gcnVsZXMgb2YgUkZDNzk1MCBhbmQNCiAg
IFJGQzc5NTIuDQoNCiAgIFRoaXMgZG9jdW1lbnQgbGF5cyBvdXQgZG9jdW1lbnRhdGlvbiBjb252
ZW50aW9ucyB0aGF0IGFsbG93IFlBTkcNCiAgIGV4YW1wbGVzIHRvIGJlIHByZXNlbnRlZCBpbiBJ
RVRGIGRvY3VtZW50YXRpb24gd2hlbiBsZWFmIG5vZGUNCiAgIGVuY29kaW5nIHdvdWxkIG90aGVy
d2lzZSBleGNlZWQgdGhlIG1heGltdW0gbGluZSBsZW5ndGguICBUaGVyZSBhcmUNCiAgIG5vIGlt
cGxpY2F0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGZvciBZQU5HIHBhcnNlcnM6IHRoaXMgZG9jdW1l
bnQgZG9lcw0KICAgbm90IGNoYW5nZSB0aGUgcnVsZXMgZm9yIHByZXNlbnRpbmcgWUFORyBtb2Rl
bHMgb3IgZm9yIGVuY29kaW5nIFlBTkcNCiAgIGluIGRhdGEgZmlsZXMgb3IgaW4gdGhlIHdpcmUu
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu
dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu
aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Mon Jan 29 04:18:26 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 3685413187C; Mon, 29 Jan 2018 04:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eZ7W9b6Bkvbc; Mon, 29 Jan 2018 04:18:15 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AD303131859; Mon, 29 Jan 2018 04:17:06 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 4DD341820415; Mon, 29 Jan 2018 13:16:48 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 2626718203F6; Mon, 29 Jan 2018 13:16:45 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , Robert Wilton , Lou Berger , NetMod WG , NetMod WG Chairs 
In-Reply-To: 
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net> <333423d2-b1a5-c556-fcd3-84e465490871@cisco.com> 
Mail-Followup-To: Kent Watsen , Robert Wilton , Lou Berger , NetMod WG , NetMod WG Chairs 
Date: Mon, 29 Jan 2018 13:17:00 +0100
Message-ID: <87a7wwn9kz.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jan 2018 12:18:24 -0000

I support the adoption.

Lada

Kent Watsen  writes:

> support, as a contributor
>
> this draft is needed to resolve a zerotouch last call issue
>
> K.
>
>
>
> On 25/01/2018 13:26, Lou Berger wrote:
>> Hi,
>>
>> This is the start of a *two* week poll on making
>> draft-bierman-netmod-yang-data-ext a working group document. Please 
>> send email to the list indicating "yes/support" or "no/do not 
>> support".  If indicating no, please state your reservations with the 
>> document.  If yes, please also feel free to provide comments you'd 
>> like to see addressed once the document is a WG document.
>>
>> This poll ends on February 8.
>>
>> Thank you!
>>
>> Lou (and Co-chairs)
>>
>> _______________________________________________
>> 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=_dCf7fXSuj5G8EY_HC2ZJnRPOShMwMrwuiNjxincOfM&s=DRRZhdQAI9SIgw8UL1SByT8FGQjfJDpvuNf4jK_1UgQ&e=
>> .
>>
>
>
>
> _______________________________________________
> 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 Mon Jan 29 07:50: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 DBA5012EC86 for ; Mon, 29 Jan 2018 07:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mtd07izu66Hs for ; Mon, 29 Jan 2018 07:50:08 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B33F12EC75 for ; Mon, 29 Jan 2018 07:49:57 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0TFng7E008387; Mon, 29 Jan 2018 15:49:42 GMT
Received: from 950129200 ([193.56.242.60]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0TFneQI008353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2018 15:49:41 GMT
Reply-To: 
From: "Adrian Farrel" 
To: 
Date: Mon, 29 Jan 2018 15:49:39 -0000
Message-ID: <071701d39918$c6cc9f00$5465dd00$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdOZGLxxp2paG1WDTQOcqbXGOjEobg==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23628.000
X-TM-AS-Result: No--16.030-10.0-31-10
X-imss-scan-details: No--16.030-10.0-31-10
X-TMASE-MatchedRID: AQrYL7loigPEQS2ecfkpF6DH6drx3JPVGWAN/II9wcRaW2Ktn+I8/nk1 Tuqc6F4GADZ3LWMKU8KH85V8v/EpVd0Hi7N6dLT+EroQVzSW9XRu/Xr6CKXiN7v408/GP5HqE1t fv0R8u8HBBOpssnjSO/P3uahlKArx/jsbtWBGy0y7vYqkCS0dLxbjReJSRusbRfmFzyKgHb7YFR cQqylt5m6mUHbiBraMPDF4aOlLYwcEdG16FO0c4o9hRjNfZeOXmX+W7bzPOQGpqdpbu0w7OrcIM 0irdNICCCbEEgOySDMgnvrgPYqDApTR9ziZdqjAH5YQyOg71ZZ9LQinZ4QefNQdB5NUNSsioeQz lhj3almNo+PRbWqfRDsAVzN+Ov/sJ8b5jtoZc/yVuCtSkmQR2axOpk15LyhNlfBiLoXke1xpFPo VKGo4wQ==
Archived-At: 
Subject: [netmod] Summary for the busy : draft-wu-netmod-yang-xml-doc-conventions-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jan 2018 15:50:11 -0000

Hi,

Just a summary for those of you who are busy...

May YANG module documents include examples in XML.

Sometimes there are line length problems caused by the 73 character =
limit.

Different documents have adopted different ways around this as special =
cases.

It would be useful to have a generic approach so that all documents have =
the same look and feel. It has also been suggested that this might ease =
auto-verification of examples, but that might be a challenge for other =
reasons.

We have not included JSON in this document. JSON is somewhat more =
compact, but the same issue could arise, so we do plan to look at this =
in the future.

Thoughts would be most welcome.

Adrian

> A new version of I-D, draft-wu-netmod-yang-xml-doc-conventions-00.txt
> has been successfully submitted by Qin Wu and posted to the IETF =
repository.
>=20
> Name:		draft-wu-netmod-yang-xml-doc-conventions
> Revision:	00
> Title:		Documentation Conventions for Expressing YANG in XML
> Document date:	2018-01-26
> Group:		Individual Submission
> Pages:		9
> URL:            =
https://www.ietf.org/internet-drafts/draft-wu-netmod-yang-xml-
> doc-conventions-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-wu-netmod-yang-xml-doc-
> conventions/
> Htmlized:       =
https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-
> conventions-00
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-wu-netmod-yang-xml-
> doc-conventions-00
>=20
>=20
> Abstract:
>    Many documents that define YANG modules also include examples
>    presented in XML.
>=20
>    IETF documentation has specific limits on line length and some XML
>    examples have to include line wraps that would not normally be
>    allowed according to the XML representation rules of RFC7950 and
>    RFC7952.
>=20
>    This document lays out documentation conventions that allow YANG
>    examples to be presented in IETF documentation when leaf node
>    encoding would otherwise exceed the maximum line length.  There are
>    no implications in this document for YANG parsers: this document =
does
>    not change the rules for presenting YANG models or for encoding =
YANG
>    in data files or in the wire.


From nobody Mon Jan 29 08:50:50 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 BBE0412F290; Mon, 29 Jan 2018 08:50:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , Joel Jaeggli , netmod@ietf.org, joelja@bogus.com, bclaise@cisco.com, rfc-editor@rfc-editor.org, draft-ietf-netmod-rfc8022bis@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151724464876.13067.8824749476533649916.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jan 2018 08:50:48 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'A YANG Data Model for Routing Management (NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jan 2018 16:50:49 -0000

The IESG has approved the following document:
- 'A YANG Data Model for Routing Management (NMDA Version)'
  (draft-ietf-netmod-rfc8022bis-11.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/





Technical Summary

   This document contains a specification of three YANG modules and one
   submodule.  Together the modules  form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  These modules are augmented by additional YANG modules 
   defining data models for control-plane protocols, route filters, and other 
   functions.  The core routing data model provides common building blocks 
   for such extensions -- routes, Routing Information Bases (RIBs), and 
   control-plane protocols. 
  
   This bis  update to RFC 8022 fully conforms to the Network Management 
   Datastore Architecture (NMDA). Consequently, this document obsoletes 
   RFC 8022.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

WGLC commenced Wed, 29 Nov 2017 completed on Fri, 15 Dec
2017.  A draft revision was performed during the last call to address
editorial issues.  The draft itself is a mechanical update to include 
support for the Network Management  Datastore Architecture 
normatively in the data model for routing manangement.

Personnel

   Joel Jaeggli is the document shepherd, 
   Benoit Claise is the Responsible AD. 


From nobody Mon Jan 29 11:19:07 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 8341C12FAEA; Mon, 29 Jan 2018 11:18:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, Lou Berger , bclaise@cisco.com, draft-ietf-netmod-entity@ietf.org, lberger@labn.net, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151725353553.19462.6316783620696720501.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jan 2018 11:18:55 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'A YANG Data Model for Hardware Management' to Proposed Standard (draft-ietf-netmod-entity-08.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jan 2018 19:18:55 -0000

The IESG has approved the following document:
- 'A YANG Data Model for Hardware Management'
  (draft-ietf-netmod-entity-08.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/





Technical Summary

   This document defines a YANG data model for the management of
   hardware on a single server.  It paralles previous work done on
   Entity MIBs.

Working Group Summary

  This document has been refactored to support NMDA.  The BBF is very
  interested in this work and is building on it.  Noting else notable
  occurred during WG processing.

Document Quality

There seems to be reasonable interest in this work, and the BBF is
planning on using it as a foundation for other work.

Personnel

   Lou Berger is the Document Shepherd
   Benoit Claise is the Responsible Area  Director


From nobody Mon Jan 29 15:09: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 6E04E130A97 for ; Mon, 29 Jan 2018 15:09:39 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 5_P1dlFbHP71 for ; Mon, 29 Jan 2018 15:09:37 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 A50CC12EC54 for ; Mon, 29 Jan 2018 15:09:37 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id l29so7810022qkj.8 for ; Mon, 29 Jan 2018 15:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=xpt035imEKRIoFJeCDAlTje7OHK5iMVT/aqCTblKyxM=; b=BeoILL06xhZchllkokHBLeYDe3xKmRChQvUwgWzr1kn/ds8K52FVcXzzvPyxipmi9O sraiRwjPxLGIdPRMnDftLiF4ygarmXgvwFYpZnpgtiXgkqbbGn4H+mHtya3HK7LF6Flt KyLx7iOK47ZT7GSrRM6cpCfAOXvfqECmihqyEgdN0j4zjb1WeNPtsNERk3lA0tFuWI67 WG81C1xJV9Dffyy4tedPF1jLIkKCQIiFPCoorrdBsQjZnwNG9He1K4TWdBovcWMzwEYc 70+HVB+dcQlN6+vgGBPPPWLoFzBsAubEg+NCrn/xZ9GDaEVDlVqm3QWa9WS9RGe/sQNJ +cBg==
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:cc; bh=xpt035imEKRIoFJeCDAlTje7OHK5iMVT/aqCTblKyxM=; b=qXzV8FBWCSTAXagUDDxpxlCb4TwFdlVDt9Zq94MziOnAS/rBRXwczIhVhDuGFUZQUr TUn3Emb8GUY2N8we/JcBuXqUs1+BPNqDklhNMoAl5hXnZN9+gV9vR/biPLP+OG3nY2e1 lduOfjG0SLNlmlbcf6BN+6fne7Rxb7dNWbrgmPPW5kSEUAjbQk0/693lFgvc8l76z1ej nlharLiU0YL8Psw2XkQKEPf8ENAUwwrZBm2QOvsy7mH+VYEQFwSKI2tvxREpzHsF5leT EnG5qb2IsoL4w086vwrV13LF+123jShFtkDItOWyns0f2ybH/GlwHPUNyIYDo9vrpezg UdeQ==
X-Gm-Message-State: AKwxytdobh8jbKjoQaux3zTLmFE6hmlI+b1xzBkqHG+PB+QJ8Kjdkx0Q EWf95fO0ZZustaM68J4KUPvf4wdyNAIOoblCOi1d+a0iX8A=
X-Google-Smtp-Source: AH8x224l5pALqjU92fUif1YfUYzIeA2sBJ8SpqZX4z0jra40rNXOYb9S05kUcRIU/tSifedEUB3hDBtUFhkS/dCsuo8=
X-Received: by 10.55.137.197 with SMTP id l188mr25359519qkd.84.1517267376763;  Mon, 29 Jan 2018 15:09:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.84.149 with HTTP; Mon, 29 Jan 2018 15:09:36 -0800 (PST)
From: Stig Venaas 
Date: Mon, 29 Jan 2018 15:09:36 -0800
Message-ID: 
To: "" 
Cc: rtg-dir@ietf.org, draft-ietf-netmod-yang-tree-diagrams.all@ietf.org,  netmod@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [netmod] RtgDir review: Review of draft-ietf-netmod-yang-tree-diagrams-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jan 2018 23:09:39 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-netmod-yang-tree-diagrams-05.txt
Reviewer: Stig Venaas
Review Date: 2018-01-29
IETF LC End Date: 2018-02-07
Intended Status: Best Current Practice

Summary:
This document is basically ready for publication, but has nits that
should be considered prior to publication.

Comments:
The draft is well written and ready for publication except for perhaps
two nits. My YANG skills are a bit limited though, so it is possible
that I may have missed issues.

Major Issues:
No major issues found.

Minor Issues:
No minor issues found.

Nits:
In the introduction it says:
   Today's common practice is to include the definition of the syntax
   used to represent a YANG module in every document that provides a
   tree diagram.  This practice has several disadvantages and the
   purpose of the document is to provide a single location for this
              ^^^^
   definition.  It is not the intent of this document to restrict future
   changes, but rather to ensure such changes are easily identified and
   suitably agreed upon.

It would be better to say "this document".

In section 2 it says:
   A module is identified by "module:" followed the module-name.

In the introduction [RFC7223] Section 3 is given as an example
tree diagram, but this does not start with "module:". Would
another example be better? It might also be good to have a
richer example that makes use of most of the defined symbols.

Otherwise the document looks great to me.

Stig


From nobody Tue Jan 30 00:40: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 0E8341316D5 for ; Tue, 30 Jan 2018 00:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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=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 iU20za0jWG1s for ; Tue, 30 Jan 2018 00:39:58 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 16D3F1316C6 for ; Tue, 30 Jan 2018 00:39:57 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:50da:e2ff:fe89:c1ef]) by mail.nic.cz (Postfix) with ESMTPSA id A43AF64311; Tue, 30 Jan 2018 09:39:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1517301594; bh=+9XrpkmQlgMEQbtTUk5zxeJMNiRklNh3bfaXeZgRiQU=; h=From:To:Date; b=EGG25UVwi4LiQB2kS1+cd1JEy5Y9CflZR9te2wcc0z3oSNc0CxowN9Hte8YYjW4Wl Jcpm8yh/HALr2wgVflbCfN2ZiBuqOwGIsGED/3teL1jwDLldKkBU9vxuN4r7syY9Mp nmJ+q4v2nWLzkuGvbTpvjzQxCR7MknV0Kb+C0wko=
Message-ID: <1517301594.16367.14.camel@nic.cz>
From: Ladislav Lhotka 
To: Benoit Claise 
Cc: NETMOD WG 
Date: Tue, 30 Jan 2018 09:39:54 +0100
References: <151724464876.13067.8824749476533649916.idtracker@ietfa.amsl.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4 
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: [netmod] [Fwd: Protocol Action: 'A YANG Data Model for Routing Management (NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 08:40:01 -0000

Hi Benoit,

Yang Validation reports one error for this document:

ietf-ipv6-router-advertisements@2018-01-25.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.14.59: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib}
{model} -i:
err : Unable to parse submodule, parse the main module instead.

I discussed it with Radek, and the problem is caused by the validation procedure
that tries to validate the submodule ietf-ipv6-router-advertisements separately,
which yanglint cannot do. The submodule is validated along with the main module
ietf-ipv6-unicast-routing to which it belongs.

Is it possible to fix this false positive?

Thanks, Lada

-------- Forwarded Message --------
From: The IESG 
To: IETF-Announce 
Cc: netmod-chairs@ietf.org, netmod@ietf.org, The IESG , draft-iet
f-netmod-rfc8022bis@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] Protocol Action: 'A YANG Data Model for Routing Management
(NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)
Date: Mon, 29 Jan 2018 08:50:48 -0800

The IESG has approved the following document:
- 'A YANG Data Model for Routing Management (NMDA Version)'
  (draft-ietf-netmod-rfc8022bis-11.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/





Technical Summary

   This document contains a specification of three YANG modules and one
   submodule.  Together the modules  form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  These modules are augmented by additional YANG modules 
   defining data models for control-plane protocols, route filters, and other 
   functions.  The core routing data model provides common building blocks 
   for such extensions -- routes, Routing Information Bases (RIBs), and 
   control-plane protocols. 
  
   This bis  update to RFC 8022 fully conforms to the Network Management 
   Datastore Architecture (NMDA). Consequently, this document obsoletes 
   RFC 8022.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

WGLC commenced Wed, 29 Nov 2017 completed on Fri, 15 Dec
2017.  A draft revision was performed during the last call to address
editorial issues.  The draft itself is a mechanical update to include 
support for the Network Management  Datastore Architecture 
normatively in the data model for routing manangement.

Personnel

   Joel Jaeggli is the document shepherd, 
   Benoit Claise is the Responsible AD. 

_______________________________________________
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 Jan 30 01:09: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 D035D13177E for ; Tue, 30 Jan 2018 01:09:41 -0800 (PST)
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_RP_MATCHES_RCVD=-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 QBXoMohtN9yi for ; Tue, 30 Jan 2018 01:09:38 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF13131A0C for ; Tue, 30 Jan 2018 01:05:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14364; q=dns/txt; s=iport; t=1517303127; x=1518512727; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=0IEUIxzjzTquhP46n4jRoJ/2JfGfMFild7BhI3crRKA=; b=PmBdnqfuAp+3BqWKUI+5M74C7WMN41XglhFbbP8QDelyG2CUlDn0YU07 8JtkydIFqawB6BjcDRtZ9srirEvVtHKs+FP8XbIYQkI19IOy3sWH9iH0Q M5Lf6c7a9FTRKXXm3mlTc/nm4t0UJQPsMJs3y4BhiiOcfGNpa+x5awBcV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQCwNHBa/xbLJq1BGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEKHUog2CLGI9SJ5FvhWmCAgoYAQmESk8CgxMUAQEBAQEBAQE?= =?us-ascii?q?CayiFIwEBAQQBASFLCxALEQECAQIWDgcCAiciBggGDQYCAQEXihoQM6Ujgicmi?= =?us-ascii?q?kIBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhFSDbIFoKQyCeYFdgVIBAQEBAQEXgRF?= =?us-ascii?q?lH4JYgmUFimyCKJcBiBiNUIIbihKHfIsEgmGBbYgUgTw2IhKBPjMaCBsVPYIqC?= =?us-ascii?q?YMBgW5ANwEBAQGMSiyCHQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,433,1511827200"; d="scan'208,217";a="1689233"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2018 09:05:23 +0000
Received: from [10.61.213.192] ([10.61.213.192]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0U95M4d005831; Tue, 30 Jan 2018 09:05:22 GMT
To: Ladislav Lhotka 
Cc: NETMOD WG , Henrik Levkowetz 
References: <151724464876.13067.8824749476533649916.idtracker@ietfa.amsl.com> <1517301594.16367.14.camel@nic.cz>
From: Benoit Claise 
Message-ID: <2dc432bb-4270-0659-05ad-06e48c2c8e31@cisco.com>
Date: Tue, 30 Jan 2018 10:05:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1517301594.16367.14.camel@nic.cz>
Content-Type: multipart/alternative; boundary="------------96A30BFD96785D75DD710C51"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Fwd: Protocol Action: 'A YANG Data Model for Routing Management (NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 09:09:42 -0000

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

Hi Lada,

The error you see comes from 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

	Yang Validation 	
	☯ 1 errors, 0 warnings. 



So this is flagged at the time of posting the draft.

I covered this false positive in my toolchain, as a daily cronjob
See http://www.claise.be/IETFYANGPageCompilation.html
See 
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv6-router-advertisements@2018-01-25.yang

And this populates the following entries.
Additional URLs 	

- Yang catalog entry for ietf-ipv4-unicast-routing@2018-01-25.yang 
 

- Yang catalog entry for ietf-ipv6-router-advertisements@2018-01-25.yang 
 

- Yang catalog entry for ietf-ipv6-unicast-routing@2018-01-25.yang 
 

- Yang catalog entry for ietf-routing@2018-01-25.yang 
 

- Yang impact analysis for draft-ietf-netmod-rfc8022bis 
 


See the "compilation-status" field.

The ideal solution is a flag in yanglint not to take into account the 
submodule (that would also simplify my live). I discussed this with 
Radek in the past.
Asking Henrik to take care of the different validator exceptions is very 
time consuming, believe me. So we can't impose that.

The alternative solution is a better integration between the toolchains. 
I'm looking for some extra funding for this (btw, everything is 
opensource). If anybody is able to help, contact me privately.

Regards, Benoit
> Hi Benoit,
>
> Yang Validation reports one error for this document:
>
> ietf-ipv6-router-advertisements@2018-01-25.yang:
> pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
> No validation errors
>
> yanglint 0.14.59: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib}
> {model} -i:
> err : Unable to parse submodule, parse the main module instead.
>
> I discussed it with Radek, and the problem is caused by the validation procedure
> that tries to validate the submodule ietf-ipv6-router-advertisements separately,
> which yanglint cannot do. The submodule is validated along with the main module
> ietf-ipv6-unicast-routing to which it belongs.
>
> Is it possible to fix this false positive?
>
> Thanks, Lada
>
> -------- Forwarded Message --------
> From: The IESG 
> To: IETF-Announce 
> Cc: netmod-chairs@ietf.org, netmod@ietf.org, The IESG , draft-iet
> f-netmod-rfc8022bis@ietf.org, rfc-editor@rfc-editor.org
> Subject: [netmod] Protocol Action: 'A YANG Data Model for Routing Management
> (NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)
> Date: Mon, 29 Jan 2018 08:50:48 -0800
>
> The IESG has approved the following document:
> - 'A YANG Data Model for Routing Management (NMDA Version)'
>    (draft-ietf-netmod-rfc8022bis-11.txt) as Proposed Standard
>
> This document is the product of the Network Modeling Working Group.
>
> The IESG contact persons are Warren Kumari and Benoit Claise.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/
>
>
>
>
>
> Technical Summary
>
>     This document contains a specification of three YANG modules and one
>     submodule.  Together the modules  form the core routing data model that
>     serves as a framework for configuring and managing a routing
>     subsystem.  These modules are augmented by additional YANG modules
>     defining data models for control-plane protocols, route filters, and other
>     functions.  The core routing data model provides common building blocks
>     for such extensions -- routes, Routing Information Bases (RIBs), and
>     control-plane protocols.
>    
>     This bis  update to RFC 8022 fully conforms to the Network Management
>     Datastore Architecture (NMDA). Consequently, this document obsoletes
>     RFC 8022.
>
> Working Group Summary
>
>     Was there anything in the WG process that is worth noting?
>     For example, was there controversy about particular points
>     or were there decisions where the consensus was
>     particularly rough?
>
> Document Quality
>
> WGLC commenced Wed, 29 Nov 2017 completed on Fri, 15 Dec
> 2017.  A draft revision was performed during the last call to address
> editorial issues.  The draft itself is a mechanical update to include
> support for the Network Management  Datastore Architecture
> normatively in the data model for routing manangement.
>
> Personnel
>
>     Joel Jaeggli is the document shepherd,
>     Benoit Claise is the Responsible AD.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



--------------96A30BFD96785D75DD710C51
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Lada,

      

      The error you see comes from
      https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

      

        
          

            

            		
            Yang Validation
            

            		
             ☯  1
                errors, 0 warnings. 
          

        
      

    

    

    So this is flagged at the time of posting the draft.

    

    I covered this false positive in my toolchain, as a daily cronjob

    See http://www.claise.be/IETFYANGPageCompilation.html

    See
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv6-router-advertisements@2018-01-25.yang

    

    And this populates the following entries.

    

      
        

          Additional URLs
           

          		
        

      
    

    

      
        

           - Yang
              catalog entry for
              ietf-ipv4-unicast-routing@2018-01-25.yang
        

        

           - Yang
              catalog entry for
              ietf-ipv6-router-advertisements@2018-01-25.yang
        

        

           - Yang
              catalog entry for
              ietf-ipv6-unicast-routing@2018-01-25.yang
        

        

           - Yang
              catalog entry for ietf-routing@2018-01-25.yang
        

        

           - Yang
              impact analysis for draft-ietf-netmod-rfc8022bis
        

      
    

    See the "compilation-status" field.

    

    The ideal solution is a flag in yanglint not to take into account
    the submodule (that would also simplify my live). I discussed this
    with Radek in the past.

    Asking Henrik to take care of the different validator exceptions is
    very time consuming, believe me. So we can't impose that.

    

    The alternative solution is a better integration between the
    toolchains. I'm looking for some extra funding for this (btw,
    everything is opensource). If anybody is able to help, contact me
    privately.

    

    Regards, Benoit

    

      
Hi Benoit,

Yang Validation reports one error for this document:

ietf-ipv6-router-advertisements@2018-01-25.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.14.59: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib}
{model} -i:
err : Unable to parse submodule, parse the main module instead.

I discussed it with Radek, and the problem is caused by the validation procedure
that tries to validate the submodule ietf-ipv6-router-advertisements separately,
which yanglint cannot do. The submodule is validated along with the main module
ietf-ipv6-unicast-routing to which it belongs.

Is it possible to fix this false positive?

Thanks, Lada

-------- Forwarded Message --------
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: netmod-chairs@ietf.org, netmod@ietf.org, The IESG <iesg@ietf.org>, draft-iet
f-netmod-rfc8022bis@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] Protocol Action: 'A YANG Data Model for Routing Management
(NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)
Date: Mon, 29 Jan 2018 08:50:48 -0800

The IESG has approved the following document:
- 'A YANG Data Model for Routing Management (NMDA Version)'
  (draft-ietf-netmod-rfc8022bis-11.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/





Technical Summary

   This document contains a specification of three YANG modules and one
   submodule.  Together the modules  form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  These modules are augmented by additional YANG modules 
   defining data models for control-plane protocols, route filters, and other 
   functions.  The core routing data model provides common building blocks 
   for such extensions -- routes, Routing Information Bases (RIBs), and 
   control-plane protocols. 
  
   This bis  update to RFC 8022 fully conforms to the Network Management 
   Datastore Architecture (NMDA). Consequently, this document obsoletes 
   RFC 8022.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

WGLC commenced Wed, 29 Nov 2017 completed on Fri, 15 Dec
2017.  A draft revision was performed during the last call to address
editorial issues.  The draft itself is a mechanical update to include 
support for the Network Management  Datastore Architecture 
normatively in the data model for routing manangement.

Personnel

   Joel Jaeggli is the document shepherd, 
   Benoit Claise is the Responsible AD. 

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


    

    

    

  


--------------96A30BFD96785D75DD710C51--


From nobody Tue Jan 30 01:35: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 0FB69131715 for ; Tue, 30 Jan 2018 01:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 7pzBHFlxXW7P for ; Tue, 30 Jan 2018 01:35:07 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D889B1316E6 for ; Tue, 30 Jan 2018 01:35:03 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 2A866602D3; Tue, 30 Jan 2018 10:35:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1517304901; bh=C6ydyMukBcMRJIcT4g7YGg+4HrU5wi5/W3DWgaLTBsQ=; h=To:Date:Subject:From; b=lKsof7IVOR7bX2NDN4+SSau31J70+MyhtYPV95Y+2XFgSZnPsFT3+B+H3rfMMC/5p RDoAk4C0i8xyx+W4WjivU5HxcBslQ5ce7vJBbKbx9hC/L8xlRUp1NlbEedkCHRTSTF fLBilm+F9erT9+rVy2RPSOTv/qvdE3BFighunHo4=
Content-Type: text/plain; charset="utf-8"
To: "netmod" 
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Tue, 30 Jan 2018 10:35:01 +0100
Message-ID: <4f1c-5a703c80-79-5fc7eb00@206654228>
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] YANG tree diagram uses
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 09:35:10 -0000

Hi,

we have encountered some problem while implementing a feature from draf=
t-ietf-netmod-yang-tree-diagrams-05, specifically not resolving groupin=
gs and printing uses names instead (Section 2.2).

We have 2 example models, A and B. A defines a container and a grouping=
. B defines an augment that adds uses into the container from A and res=
olves to the grouping from model A.

grouping A:g;
A:c {
  B:uses A:g;
}

Now, if printing model A with the augment not resolving uses we current=
ly print

+--rw c
   +---u B:A:g;

since the uses is foreign. We could not decide what the "correct" outpu=
t should be and it is likely left to various interpretations but we wer=
e wondering what some of you think. Should it perhaps be only "B:g" sin=
ce the grouping becomes local? But what if the grouping would be from a=
 third model, are 2 prefixes okay? Thanks for your opinions.

Regards,
Michal


From nobody Tue Jan 30 07:04: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 B114A12EB94 for ; Tue, 30 Jan 2018 07:04:12 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 oByY13qay5kz for ; Tue, 30 Jan 2018 07:04:10 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED16F12D9FF for ; Tue, 30 Jan 2018 07:00:57 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 225671AE018A; Tue, 30 Jan 2018 16:00:57 +0100 (CET)
Date: Tue, 30 Jan 2018 16:00:56 +0100 (CET)
Message-Id: <20180130.160056.1269600856222747465.mbj@tail-f.com>
To: mvasko@cesnet.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <4f1c-5a703c80-79-5fc7eb00@206654228>
References: <4f1c-5a703c80-79-5fc7eb00@206654228>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] YANG tree diagram uses
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 15:04:13 -0000

Michal Va=A8ko  wrote:
> Hi,
> =

> we have encountered some problem while implementing a feature from
> draft-ietf-netmod-yang-tree-diagrams-05, specifically not resolving
> groupings and printing uses names instead (Section 2.2).
> =

> We have 2 example models, A and B. A defines a container and a
> grouping. B defines an augment that adds uses into the container from=

> A and resolves to the grouping from model A.
> =

> grouping A:g;
> A:c {
>   B:uses A:g;
> }
> =

> Now, if printing model A with the augment not resolving uses we
> currently print
> =

> +--rw c
>    +---u B:A:g;

pyang prints this as well, but it is more "by accident".   It looks
quite odd.

It wouldn't be correct to write

    +---u B:g;

since 'g' isn't defined in B. =

   =

OTOH,

    +---u A:g;

is correct in the sense that "A:g" is the "name of the grouping", and
that is what the current document says should be printed.  Granted,
this doesn't show the whole picture, but maybe this is good enough.

It might be wise to not print a grouping like this in order to avoid
confusion.


/martin


> =

> since the uses is foreign. We could not decide what the "correct"
> output should be and it is likely left to various interpretations but=

> we were wondering what some of you think. Should it perhaps be only
> "B:g" since the grouping becomes local? But what if the grouping woul=
d
> be from a third model, are 2 prefixes okay? Thanks for your opinions.=

> =

> Regards,
> Michal
> =

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


From nobody Tue Jan 30 08:04:57 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 E81DA12EAFA for ; Tue, 30 Jan 2018 08:04:55 -0800 (PST)
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 4Jq02se9kS-l for ; Tue, 30 Jan 2018 08:04:53 -0800 (PST)
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 CD39B126FDC for ; Tue, 30 Jan 2018 08:04:53 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0UFsbti017688 for ; Tue, 30 Jan 2018 07:55:00 -0800
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=zMG7vvFjKd9/P/cADFVTTo4yfyj1Od8c0N9lQ5exyF4=; b=KyM7+72yOU0stY16yUE7IOEjdAe9kLboC5S5XNg/LENxOmFJ2f4dds/1vELx3aie0iEL yBgr8qLWAJx0/LXWQMLE4aQEQQJgY+crtArhkPCj7Oqe3KjXK04uqqGmIStg7dfgFgbX h6xyfZ8vdYkGp1djyFLkxOfNVOktBc2HIjq98jWo81Y1kAUc9PLZNIm9gRKLMYkCTbw9 8duKF1/h62/oe2F/OfB06WTlhr6Er98GU2BfeIfQs4nuqSMoSXjIoXTC1IeyHMJP86xV Q52wMhwt9/0H+zTmQ/UjRGZo6Ri80viSC7ejAsW5m0TANaxD7t8z58TKVGxLbWMBSMbd ow== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2ftm139dt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 30 Jan 2018 07:55:00 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3451.namprd05.prod.outlook.com (10.174.240.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Tue, 30 Jan 2018 15:54:59 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.008; Tue, 30 Jan 2018 15:54:59 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
Thread-Index: AQHTleAqmJIeAORwS0KCxIIo07busaOGzqYAgAM5PbCAAj3mAA==
Date: Tue, 30 Jan 2018 15:54:59 +0000
Message-ID: <2816EEDB-8F03-481B-9C69-CA87C23AE360@juniper.net>
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>  <08dacd196b6c47a285eade464d6b9ce7@XCH-RTP-013.cisco.com>
In-Reply-To: <08dacd196b6c47a285eade464d6b9ce7@XCH-RTP-013.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.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3451; 6:2yPtKtq5GlcwcEn/F1hfiyaTcYFqXfVZwuE61+/qQZ7x1rIIyEoH0yU/sLQaqWP4S66uLttbFIxEne2GvBj1rhyzaJnaroqREFFEdLFogEpvbOd2auaXA9e7MsPO/EwD2T/hiUyPX9ngtM995Q8yF9ITqiIKPlChe+VuB9wscbvkcWkxR9flr4BZg2T+HW5IxL9tp2S5MFTaD3xhahAGg1ZaINbVBWYRY7vtFOzXP4MGzaU1pP5XobBca0tets9WP7EqIzW99y9Uu5a5QvbkWy0qeluPDHQWe44S+blEoV5oc1FJUYUkc9EYwg3D32FC1FAGp1rIa9d4daAQFRuGvak0GvTLiytSN/FiDnq2L9x9DKHnE3jJAdaO0l2o9aux; 5:CIpY/HIx6+BnkIHSt6CyUh3rLm/ttc8dn0EwLZb+Eok3d9XzgZJSIAs+J0mQ5z3EUWJDQd75N9lBd2/rKc9Xumo/tU0/5uyCVWp0DxHuJnH0wvhXMetmkKnjEs75XcKoFeQAun3Cjz7ppNtyKsqdd/wTHFNItIuBzZc4M1865dg=; 24:BXrjVrbHmduQvsCE93J5XE2ROLOaCIvn7+CACxT7jEy6H3rIsXz3aQ+RhujrBTGXXqCyTOLgTW/JoaVoAbzn4Homkab2vjOaMNwo4+D3E0c=; 7:EJZrJfrugGttV5niawlUw6P+lrZiB1NqOjLm4QUE1NZbQefAzqtFjKygwuDv7PoqS9lbEIuSfb97gTEu6Cg6+x9RyAjrwg/Kjy5PCyx+cEeRC1c1QAWYL52Bra73V5O6EM0cy4UGM7DMSV3VO8WJwr26AjIUSUeKTJnIuFJQIB1h/ODEeTGPuiSmmto81RFKhOaC9T4ul37kKlnb0X2foaK3uexVOrp05EsaGVPbb189gx2Eym0jlwueuNlJVLmj
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f16e4fe6-f01e-4273-de52-08d567f9d0e4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3451; 
x-ms-traffictypediagnostic: DM5PR05MB3451:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231101)(944501161)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3451; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3451; 
x-forefront-prvs: 0568F32D91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(376002)(346002)(366004)(199004)(189003)(26005)(97736004)(81166006)(5640700003)(36756003)(102836004)(6116002)(2351001)(186003)(2950100002)(5660300001)(33656002)(2473003)(77096007)(106356001)(6916009)(83506002)(3846002)(25786009)(58126008)(59450400001)(2906002)(2501003)(68736007)(76176011)(6512007)(478600001)(6506007)(99286004)(81156014)(82746002)(3280700002)(14454004)(8936002)(229853002)(83716003)(7736002)(66066001)(2900100001)(305945005)(86362001)(6486002)(8676002)(316002)(6436002)(53936002)(105586002)(1730700003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3451; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: mz0MJguuk7ySyPOF0TIJDblPHIzJ5bb5JC2CpEbNJRUMv38caBCncG3kVnMytOoQyYswASa6F4CTF9TwPtL2rw==
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: f16e4fe6-f01e-4273-de52-08d567f9d0e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2018 15:54:59.1658 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3451
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-30_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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801300198
Archived-At: 
Subject: [netmod] FW: WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 16:04:56 -0000

W2ZvcndhcmRpbmcgeWFuZy1kYXRhLWV4dCBwb3N0ZWQgdG8gdGhlIG5ldGNvbmYgbGlzdF0NCg0K
Sy4NCg0KRXJpYyBWb2l0IHdyaXRlczoNCg0KSSB0aGluayB0aGlzIHdvcmsgaXMgZXhjZWxsZW50
LiAgSSB3b3VsZCBsaWtlIHRvIHNlZSBpdCBhZG9wdGVkLg0KDQoNCj4gUGxlYXNlIHRha2UgYSBt
b21lbnQgdG8gcG9zdCBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgdGhlIHlhbmctZGF0YS1l
eHQNCj4gZHJhZnQgaW4gdGhlIE5FVE1PRCB3b3JraW5nIGdyb3VwLg0KPiANCj4gUmVjYWxsIHRo
YXQgb25lIG9mIHRoZSB6ZXJvdG91Y2ggbGFzdCBjYWxsIGNvbW1lbnRzIHJlc3VsdGVkIGluIGEg
bmVlZCBmb3INCj4gYSBkcmFmdCBzdWNoIGFzIHRoaXMsIGluIG9yZGVyIHRvIG1vdmUgaXRzIG5v
cm1hdGl2ZSByZWZlcmVuY2UgZm9yIHRoZSANCj4gInlhbmctZGF0YSIgZXh0ZW5zaW9uIGF3YXkg
ZnJvbSBSRkMgODA0MC4NCj4gDQo+IFRoaXMgbW9kaWZpY2F0aW9uIGlzIG5lZWRlZCBzaW5jZSBz
b21lIGNsYWltIHRoYXQgcmM6eWFuZy1kYXRhIGNhbid0IGVuY29kZQ0KPiBhIHRvcC1sZXZlbCAn
Y2hvaWNlJyBzdGF0ZW1lbnQgZXZlbiB3aGVuIGl0IG9ubHkgaGFzIGRlc2NlbmRhbnRzIHRoYXQg
YXJlDQo+IGNvbnRhaW5lcnMuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBLZW50ICAvLyBjby1hdXRo
b3Igb24gYm90aCBkcmFmdHMNCj4gDQo+IA0KPiA9PT09PSBvcmlnaW5hbCBtZXNzYWdlID09PT09
DQo+DQo+IEhpLA0KPiANCj4gVGhpcyBpcyB0aGUgc3RhcnQgb2YgYSAqdHdvKiB3ZWVrIHBvbGwg
b24gbWFraW5nIGRyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctDQo+IGRhdGEtZXh0IGEgd29ya2lu
ZyBncm91cCBkb2N1bWVudC4gUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGlu
Zw0KPiAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5n
IG5vLCBwbGVhc2Ugc3RhdGUgeW91cg0KPiByZXNlcnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1lbnQu
ICBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlDQo+IGNvbW1lbnRzIHlv
dSdkIGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3Vt
ZW50Lg0KPiANCj4gVGhpcyBwb2xsIGVuZHMgb24gRmVicnVhcnkgOC4NCj4gDQo+IFRoYW5rIHlv
dSENCj4gDQo+IExvdSAoYW5kIENvLWNoYWlycykNCj4gDQoNCg==


From nobody Tue Jan 30 08:31: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 614BC12DA4A; Tue, 30 Jan 2018 08:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_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=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 UKzp9omAsyHZ; Tue, 30 Jan 2018 08:31:13 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 1404E12EC38; Tue, 30 Jan 2018 08:30:51 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id h92so16249582lfi.7; Tue, 30 Jan 2018 08:30:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=DOXPGlciv36anbySkR3ykVSCJuPOalDTpR6JtF4WMFs=; b=oaSQPq46KZoCrw9Nv8ZidekQnOOoUac2oG+M/UfcJrn78Oic2eEsNMPBBJIe3tOoIb dpFW+uY9V7PRtZqV6eQUAK1HgMCsdMk9dYT9sE9aPhjQaNOdGZyhGcO1qPd18cd6oikt a4tXF841D5P8ZclJYVCwgv8nqD1kbOj+se8a2iWX8eDKlMMzNwlEKJzqLtHVS5MO/J/w GvzIFau3B4KuYOIIpZrvBDyZZU17UD30dSIpb9NXP/ERj5jmT/3c5ej41jc2PO4LBKs1 SgtyZmx22fahAGti5EBOi3aSpWbqrzqieqRlb7ia5ePtL1/MmYefU38IP+YT77J1wJTz cHHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=DOXPGlciv36anbySkR3ykVSCJuPOalDTpR6JtF4WMFs=; b=S5ExQtXmWdCzFd3jEz891dnY8xNugxslIDB0Cr/kY9O1K08m+u2NWtNShVMWspnd80 FHJfm1wpOCg/AoO5r2/Ks9WCxLgt5M0YEIKqS3R174lU8qVKWsX5Q3ckJqISBGx4++r9 Gj40r84voq5mzQv2WZD7Z3hVJJA9feX7Mz+dZPZ929Mj/MQ4ht5eznqrGYsKWQXxAzEO dtjPchKiNWHaQetxQ252RIlWGyMZG2XlpvL3t0m8zM6v6rXHe1GFzFv640vsx6nOHwzF kgbR3gnVdJZgP/hk6CqsiO9hllLTdXWoWu9GyBJQ9LJA2f7yn7ot1BDuortmDfbjzbD3 232g==
X-Gm-Message-State: AKwxytf3/+xn6UrmQdX7dDtgeJ+bul2SYs/B9wMj3EdGth60spI3qL1H eStyzrUmn2Y9IquBBIqvuOTQ9wJZ
X-Google-Smtp-Source: AH8x225FGYNC7UccEItnEXQYvyUDybhWf6v9fQ3sEuEoKhWt2nsIpiEaIOQ7jU5xehj9OObLtB/qaw==
X-Received: by 10.46.89.208 with SMTP id g77mr11314572ljf.88.1517329849350; Tue, 30 Jan 2018 08:30:49 -0800 (PST)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id g19sm2843696lja.65.2018.01.30.08.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 08:30:48 -0800 (PST)
From: "Xufeng Liu" 
To: "'Lou Berger'" , "'NetMod WG'" , "'NetMod WG Chairs'" 
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
In-Reply-To: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Date: Tue, 30 Jan 2018 11:30:45 -0500
Message-ID: <023701d399e7$af835030$0e89f090$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHGdWLj+sac6BF8fEo6O+YSRXl+PKOm5HvA
Content-Language: en-us
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWU5YmMzMDEyLTA1ZGEtMTFlOC05YzQyLTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxlOWJjMzAxNC0wNWRhLTExZTgtOWM0Mi0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjEwNzAiIHQ9IjEzMTYxODAzNDQ1MDAyMDM5OSIgaD0iUFBUd212WGpyYjI3cXNlQko4ZmlUMm1YRW9BPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 16:31:16 -0000

Support.

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Thursday, January 25, 2018 8:27 AM
> To: NetMod WG ; NetMod WG Chairs  chairs@ietf.org>
> Subject: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
> 
> Hi,
> 
> This is the start of a *two* week poll on making
draft-bierman-netmod-yang-
> data-ext a working group document. Please send email to the list
indicating
> "yes/support" or "no/do not support".  If indicating no, please state your
> reservations with the document.  If yes, please also feel free to provide
> comments you'd like to see addressed once the document is a WG document.
> 
> This poll ends on February 8.
> 
> Thank you!
> 
> Lou (and Co-chairs)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 30 10:28: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 9686712EAD1; Tue, 30 Jan 2018 10:28:00 -0800 (PST)
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, FREEMAIL_FROM=0.001, 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=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 M2_xM1NiH--P; Tue, 30 Jan 2018 10:27:59 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 20F2012F4BF; Tue, 30 Jan 2018 10:27:42 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id 25so12483073ioj.9; Tue, 30 Jan 2018 10:27:42 -0800 (PST)
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=nfzVK37yYGl2ju8vL637eAwpXEOHgYiWACaPI14Fi0k=; b=O/Q7V4evSH7J3CWRJnsUZYeoGskSfUhw+3Q+nXH8H7YNlBoSfyI4YKxKt1HMW2eMqs Ck44i35ate4egH/aAlXC58ljIGnQhJDQ0JnlmdI2/A6NNR9Ethq9W4qBgQj80oaGm9OO 2aNxn3gOb0hFhF/1WS/NGB094Fbd+s07rWljvaLhmzhsmV3j/gmBxZcE+bXWoT2cxwMc skQH+FhlM71da8JqmZgS36aNTtMQdYBQr4eEdLn0biFfp6TDjvY76EB5+gW58YP7zi6N v3LoGMZIH053tYj1AN6nHetyg7J/qFBc+t3VnzKx+mlq4rbYciYS/zPJtlpNlMCbyEiB owKQ==
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=nfzVK37yYGl2ju8vL637eAwpXEOHgYiWACaPI14Fi0k=; b=QTx8A1eFJbGQt15EPalk5DjkVCrwz2cp+uG/EYAUcfmGF86bkbS3WgVG2UlRyaKnsL fot9459MeDSEljqmdCjdNQ0tOUyN+d+aYBUy1wQOQnzDjEKeDyAVJKYm7bjUvZMwuxOX glMvdqwSH6Omys68rn1dfcPKRqhsNBMMN9m/rU8UDGtz+HaQzHjgRXjqMtJGf8TtulwQ 5aeUS7LTJhxfZdsQX3wTcdL4ToMXr7WOeHN2ox0n1LNqPNILLOm5/my0dZul30bP6RNH VDhCLioNnMjO14KvnnT8xlg1cP+IHXm/xVHv0TqGrnB3cmjGHRfchFPXp0c2btbUnE0C 1ImA==
X-Gm-Message-State: AKwxytf5sy86LfXdgxn+n3nuqkXZc/jV6e0fdr/0hYclsIDUP78vyoW2 pVElQ5XyOUXfvwiuWkg5sxa1k+AA
X-Google-Smtp-Source: AH8x225yvSkDon6wjyQTJD/1pEmXo+unK7XG1QjzXf6c47LfHGSp9IWbPyjE4QthIh9NNguMRsjN9Q==
X-Received: by 10.107.28.201 with SMTP id c192mr30006197ioc.26.1517336861195;  Tue, 30 Jan 2018 10:27:41 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:8c7d:b427:24fb:d349]) by smtp.gmail.com with ESMTPSA id t84sm6119044iod.6.2018.01.30.10.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 10:27:40 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Tue, 30 Jan 2018 10:27:39 -0800
Cc: NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: netconf 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 18:28:00 -0000

Authors and WG,

We have not received any explicit support for this LC on this email =
thread. If you believe these drafts are important and should proceed, =
please state your support by responding to this email thread.

Thanks.

> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani =
 wrote:
>=20
> The authors of draft-ietf-netconf-nmda-netconf and =
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, =
and believe that the documents are ready for LC.
>=20
> This starts a 2 week LC on the two drafts that will end on January 31. =
Please send your comments on this thread. Comments like =E2=80=9CI have =
reviewed the documents and believe they are ready for publication=E2=80=9D=
, or =E2=80=9CI have concerns about the document because =E2=80=A6=E2=80=9D=
 are welcome and useful for the authors.
>=20
> Authors please indicate whether you are aware of any IPR for either of =
the drafts.
>=20
> Thanks.
>=20
> Mahesh & Kent
>=20

Mahesh & Kent


From nobody Tue Jan 30 10:55:47 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 CB5DA12F26D; Tue, 30 Jan 2018 10:55:39 -0800 (PST)
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 ZgYMAgtrC970; Tue, 30 Jan 2018 10:55:37 -0800 (PST)
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 7C7B112ECC5; Tue, 30 Jan 2018 10:55:37 -0800 (PST)
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 w0UImoP7019480; Tue, 30 Jan 2018 10:55:35 -0800
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=F/ZWr2oxSO82EM+bNnTC1RRVpyA10EBLTH/zO20yjyk=; b=XHqeGbkBmRqnEt6WQ76djMjCJ2VwUWOdlvRBcPK/2PFMa8BV8XMRVZT2ktU2jA9b16z0 q20YbPVmSJJOqc5uqbe9i9RXi3XB8qp99t8XtUhCysIEDk0ESkq+dfK1QV/QRBgR3iBw MaO1+WxLtFG/yK6BtfwjJEEcu6MK74LCFZ9cXFhKxngzh1yKad8FftWHIxBKhm5Srs9Y kTiPhT0Xd54W9pCPr2rXcwOjY45opDmtopT+SgAct9NBpVqHAfcnNOfV6RQUtWqEzTm/ q0bmhaQy1yNP4fPkqU603LCzuBoWPcpLmescTp8xckfM5txwf7BNiTOhmrcmEq6W3ez2 0w== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0177.outbound.protection.outlook.com [216.32.181.177]) by mx0b-00273201.pphosted.com with ESMTP id 2ftw4m87k3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jan 2018 10:55:34 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3673.namprd05.prod.outlook.com (10.174.190.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Tue, 30 Jan 2018 18:55:32 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.008; Tue, 30 Jan 2018 18:55:32 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , netconf 
CC: NETMOD Working Group 
Thread-Topic: [Netconf] LC of NDMA NETCONF/RESTCONF drafts
Thread-Index: AQHTj8KSPXMvAaGHcUyNeBKvGHzSJKOM0H+A//+z94A=
Date: Tue, 30 Jan 2018 18:55:32 +0000
Message-ID: <8148FDBD-2B46-4D3B-9A50-2323F3005976@juniper.net>
References:  
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; DM5PR05MB3673; 7:63OBSJzI8lR1xAczzPFfw9VLBzLnT3E8B+RsYV1Uc8HQtElK7qDrntoIC0VSd6clHHFLSAhNV4HG/ATGzXqAlRzZF1U8YW1p+p2vvMnwb802RLvg9w+cLqYp/WeiCsxSC0vXGTFX5q0C9twBT+D4cFIP0WB0Oo9IgKC/geFedt6JY1UYLagJual1OY/eZN5iyXC3P0QBGNj6GRGraJAGEAS8OnGR94YnLbUn/y6j9VMZI5Y13WZWnLPX25b++vUc
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ad22c652-a3ad-456f-ef50-08d568130a4c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3673; 
x-ms-traffictypediagnostic: DM5PR05MB3673:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3673; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3673; 
x-forefront-prvs: 0568F32D91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(39380400002)(346002)(376002)(366004)(199004)(189003)(110136005)(3660700001)(106356001)(36756003)(3280700002)(83716003)(53546011)(102836004)(6486002)(186003)(2900100001)(58126008)(86362001)(575784001)(59450400001)(316002)(26005)(83506002)(66066001)(76176011)(2950100002)(305945005)(6506007)(7736002)(77096007)(8676002)(478600001)(2906002)(14454004)(6116002)(33656002)(3846002)(82746002)(966005)(105586002)(53936002)(68736007)(8936002)(81166006)(81156014)(97736004)(99286004)(6436002)(229853002)(6512007)(25786009)(4326008)(6246003)(6306002)(5660300001)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3673; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bh34v2qcmEutBcOfn4OYyYPmdF8mEFH8L8Uy9TFRAhFNifFLhFZmEQUa0NSpdwE0AL/Y9wLpIDZepUYpt8/3Vw==
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: ad22c652-a3ad-456f-ef50-08d568130a4c
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2018 18:55:32.8504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3673
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-30_08:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801300230
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 18:55:40 -0000

DQpJIGhhdmUgcmVhZCBhbmQgc3VwcG9ydCBib3RoIGRyYWZ0cyBmb3IgYWR2YW5jZW1lbnQuDQoN
CktlbnQgLy8gY28tYXV0aG9yDQoNCg0KPT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0KDQpB
dXRob3JzIGFuZCBXRywNCg0KV2UgaGF2ZSBub3QgcmVjZWl2ZWQgYW55IGV4cGxpY2l0IHN1cHBv
cnQgZm9yIHRoaXMgTEMgb24gdGhpcyBlbWFpbCB0aHJlYWQuIElmIHlvdSBiZWxpZXZlIHRoZXNl
IGRyYWZ0cyBhcmUgaW1wb3J0YW50IGFuZCBzaG91bGQgcHJvY2VlZCwgcGxlYXNlIHN0YXRlIHlv
dXIgc3VwcG9ydCBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgdGhyZWFkLg0KDQpUaGFua3Mu
DQoNCj4gT24gSmFuIDE3LCAyMDE4LCBhdCAxMDozOSBBTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8
bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gVGhlIGF1dGhvcnMgb2YgZHJh
ZnQtaWV0Zi1uZXRjb25mLW5tZGEtbmV0Y29uZiBhbmQgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEt
cmVzdGNvbmYgaGF2ZSBwb3N0ZWQgdXBkYXRlcyB0byB0aGVpciBkcmFmdHMsIGFuZCBiZWxpZXZl
IHRoYXQgdGhlIGRvY3VtZW50cyBhcmUgcmVhZHkgZm9yIExDLg0KPiANCj4gVGhpcyBzdGFydHMg
YSAyIHdlZWsgTEMgb24gdGhlIHR3byBkcmFmdHMgdGhhdCB3aWxsIGVuZCBvbiBKYW51YXJ5IDMx
LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLiBDb21tZW50cyBsaWtl
IOKAnEkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnRzIGFuZCBiZWxpZXZlIHRoZXkgYXJlIHJl
YWR5IGZvciBwdWJsaWNhdGlvbuKAnSwgb3Ig4oCcSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBk
b2N1bWVudCBiZWNhdXNlIOKApuKAnSBhcmUgd2VsY29tZSBhbmQgdXNlZnVsIGZvciB0aGUgYXV0
aG9ycy4NCj4gDQo+IEF1dGhvcnMgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFyZSBhd2Fy
ZSBvZiBhbnkgSVBSIGZvciBlaXRoZXIgb2YgdGhlIGRyYWZ0cy4NCj4gDQo+IFRoYW5rcy4NCj4g
DQo+IE1haGVzaCAmIEtlbnQNCj4gDQoNCk1haGVzaCAmIEtlbnQNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpO
ZXRjb25mQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1Ed0lH
YVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4
bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWNoeFpHNVpyQm5IQ192TzBm
OWtZaEduTXdBVWVGMkFMcW5wcWp0MkZPd0kmcz1jTHhQdmF3M3dCSzhLZlV4MFpLTlB5cVBQaEMx
N1l4LW85U0pRX3E0QVdFJmU9DQoNCg0K


From nobody Tue Jan 30 11:33:15 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 61B581316DA; Tue, 30 Jan 2018 11:33:08 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 gh90KVOucauM; Tue, 30 Jan 2018 11:33:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6BB12FACA; Tue, 30 Jan 2018 11:33:04 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3FE85FA6; Tue, 30 Jan 2018 20:33:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id KS4i6JbY-cPV; Tue, 30 Jan 2018 20:32:59 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Jan 2018 20:33:03 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C3C52014E; Tue, 30 Jan 2018 20:33:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Osmm7nljASO1; Tue, 30 Jan 2018 20:33:02 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 933E120147; Tue, 30 Jan 2018 20:33:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C9E944230D5B; Tue, 30 Jan 2018 20:33:01 +0100 (CET)
Date: Tue, 30 Jan 2018 20:33:01 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: Mahesh Jethanandani , netconf , NETMOD Working Group 
Message-ID: <20180130193301.63e4xt5thsprsym6@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Mahesh Jethanandani , netconf , NETMOD Working Group 
References:   <8148FDBD-2B46-4D3B-9A50-2323F3005976@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <8148FDBD-2B46-4D3B-9A50-2323F3005976@juniper.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 19:33:08 -0000

Same here.

/js

On Tue, Jan 30, 2018 at 06:55:32PM +0000, Kent Watsen wrote:
> 
> I have read and support both drafts for advancement.
> 
> Kent // co-author
> 
> 
> ===== original message =====
> 
> Authors and WG,
> 
> We have not received any explicit support for this LC on this email thread. If you believe these drafts are important and should proceed, please state your support by responding to this email thread.
> 
> Thanks.
> 
> > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  wrote:
> > 
> > The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.
> > 
> > This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.
> > 
> > Authors please indicate whether you are aware of any IPR for either of the drafts.
> > 
> > Thanks.
> > 
> > Mahesh & Kent
> > 
> 
> Mahesh & Kent
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI&s=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE&e=
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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 Jan 30 12:35:42 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 1C4FA12FAFE for ; Tue, 30 Jan 2018 12:35:40 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 cJRjgCB4BjNz for ; Tue, 30 Jan 2018 12:35:38 -0800 (PST)
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 B464412F4CE for ; Tue, 30 Jan 2018 12:35:35 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id g72so17320182lfg.5 for ; Tue, 30 Jan 2018 12:35:35 -0800 (PST)
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=tz8ECHVf2GBDUFQCj9UwMaD30OAqzhilX1LrznKBaiY=; b=VnAkiI8X96dhaEceRZDsLUCoFV6v47ae6yzCnSPDM7JK1zTgvgDFJDsA8IaXE+Vkly oQf5PvEsGn0H153O4Zz4iKzFTwfzSm9epm9ec8R7ESr+9RZygzC+aweOnSjYfGMXI3eb yVISnlIB+iMKikd0FW+/+WuXmLcrhJdRJE6gy+L9tzd+kfCUYUPw6cOaB6b4Z6gWerS5 B5zQfaAiaW1lcyY3ESPq37oSeDMc9IYpU9FJYC+hy6S1ZSN1bYuWwB70jBhCBSXEIFMx mYe+piSpWX6uR6xnFn1TO5888M1SefhWRwaT75fCgbjsh4EiAnxKpsckE/SNFp1dinvH SEbQ==
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=tz8ECHVf2GBDUFQCj9UwMaD30OAqzhilX1LrznKBaiY=; b=iVxlL1tnOtEDMba66kY0JmREKgeQdDoWoEPPRNL8GpGmGHfO9QUpchg/nYhFlY2XyC 9n8MO/ukEEsWnwXYfgGfZNVLjkMnHvb6Fk2xbWIc7clrL2ip25ddeSn+mPwfBPY5pvK3 xUxxgj7KiDDDUK4Gxx+XmAEpWkeabPMcqgXQ0J9SSuGXxvYltQVgulpH+xsK8ZRd7fiW eyaNAmQT29PJNLMNKej6pHRL3gGV5dtvJg1BbXjrdp2eUKtlBwUTwXMbZCRqgOuTYXKz wZMgKsS7Fw1VXcjL6YN2FyGpyYLbDP+ruwBoXUjDGjjB6Zp8Ly3Cma0Xe3br21DJ9kcL 6ifw==
X-Gm-Message-State: AKwxytfM+LAdvP/pQNrwWhzCCO6MMg/HTAkktG5ekPwCDNNmO3wHyoz8 vVvdZlWNYSoFzJxaykqTIxgbUunzXuqpspLYGbfSSg==
X-Google-Smtp-Source: AH8x224M044Wp03Hn1VDUwy/AkfJV00DCaKpnsX00GGJZ1JbCSGw6gvPN7E2uCg/z++sLR8aiiukjFJtZdsnUke9ZUo=
X-Received: by 10.25.26.200 with SMTP id a191mr14797497lfa.35.1517344533873; Tue, 30 Jan 2018 12:35:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Tue, 30 Jan 2018 12:35:33 -0800 (PST)
In-Reply-To: 
References:  
From: Andy Bierman 
Date: Tue, 30 Jan 2018 12:35:33 -0800
Message-ID: 
To: Mahesh Jethanandani 
Cc: netconf , NETMOD Working Group 
Content-Type: multipart/alternative; boundary="001a11401edaf1a68f0564044dce"
Archived-At: 
Subject: Re: [netmod] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jan 2018 20:35:40 -0000

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

Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
    There are many places where a datastore-ref type is used.
    However, "conventional" is valid for base "datastore", even though
    it is ambiguous as a datastore selector.

2) origin filter is limited to 1 source
   This filtering seems rather limited.  A client must retrieve
 and check
    all the values in use, then make repeated requests for each source as a
different
     leaf

3) with-defaults broken
    The operational datastore does not support with-defaults.
     Instead, the client must use origin-filter=3Dor:default or with-origin
     and check all the origin attributes.  Since a client needs to use
     with-defaults for other datastores, this special handling of

     seems unhelpful.


Andy


On Tue, Jan 30, 2018 at 10:27 AM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Authors and WG,
>
> We have not received any explicit support for this LC on this email
> thread. If you believe these drafts are important and should proceed,
> please state your support by responding to this email thread.
>
> Thanks.
>
> > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
> >
> > The authors of draft-ietf-netconf-nmda-netconf and
> draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and
> believe that the documents are ready for LC.
> >
> > This starts a 2 week LC on the two drafts that will end on January 31.
> Please send your comments on this thread. Comments like =E2=80=9CI have r=
eviewed
> the documents and believe they are ready for publication=E2=80=9D, or =E2=
=80=9CI have
> concerns about the document because =E2=80=A6=E2=80=9D are welcome and us=
eful for the
> authors.
> >
> > Authors please indicate whether you are aware of any IPR for either of
> the drafts.
> >
> > Thanks.
> >
> > Mahesh & Kent
> >
>
> Mahesh & Kent
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I have some questions about these d=
rafts.

1) what if datastore set to "conventio=
nal"?
=C2=A0 =C2=A0 There are many places where a datastore-=
ref type is used.
=C2=A0 =C2=A0 However, "conventional"=
 is valid for base "datastore", even though
=C2=A0 =C2=
=A0 it is ambiguous as a datastore selector.

2) or=
igin filter is limited to 1 source
=C2=A0 =C2=A0This filtering se=
ems rather limited.=C2=A0 A client must retrieve <with-origin> and ch=
eck
=C2=A0 =C2=A0 all the values in use, then make repeated reque=
sts for each source as a different
=C2=A0 =C2=A0 <origin-filte=
r> leaf

3) with-defaults broken
=C2=
=A0 =C2=A0 The operational datastore does not support with-defaults.
<=
div>=C2=A0 =C2=A0 =C2=A0Instead, the client must use origin-filter=3Dor:def=
ault or with-origin
=C2=A0 =C2=A0 =C2=A0and check all the origin =
attributes.=C2=A0 Since a client needs to use
=C2=A0 =C2=A0 =C2=
=A0with-defaults for other datastores, this special handling of <operati=
onal>
=C2=A0 =C2=A0 =C2=A0seems unhelpful.


Andy


On Tue, Jan 30, 2018 at 10:27 AM, Mahesh=
 Jethanandani <mjethanandani@gmail.com> wrote:
Authors and WG,



We have not received any explicit support for this LC on this email thread.=
 If you believe these drafts are important and should proceed, please state=
 your support by responding to this email thread.



Thanks.



> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

>

> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-net=
conf-nmda-restconf have posted updates to their drafts, and believe th=
at the documents are ready for LC.

>

> This starts a 2 week LC on the two drafts that will end on January 31.=
 Please send your comments on this thread. Comments like =E2=80=9CI have re=
viewed the documents and believe they are ready for publication=E2=80=9D, o=
r =E2=80=9CI have concerns about the document because =E2=80=A6=E2=80=9D ar=
e welcome and useful for the authors.

>

> Authors please indicate whether you are aware of any IPR for either of=
 the drafts.

>

> Thanks.

>

> Mahesh & Kent

>



Mahesh & Kent



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a11401edaf1a68f0564044dce--


From nobody Tue Jan 30 23:58: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 6C3CD1319D6; Tue, 30 Jan 2018 23:58:02 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9mMrECo28bIL; Tue, 30 Jan 2018 23:58:00 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50AE41319E2; Tue, 30 Jan 2018 23:57:12 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 617CC1AE0144; Wed, 31 Jan 2018 08:57:11 +0100 (CET)
Date: Wed, 31 Jan 2018 08:57:10 +0100 (CET)
Message-Id: <20180131.085710.841622353246103633.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: kwatsen@juniper.net, netconf@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20180130193301.63e4xt5thsprsym6@elstar.local>
References:  <8148FDBD-2B46-4D3B-9A50-2323F3005976@juniper.net> <20180130193301.63e4xt5thsprsym6@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 07:58:02 -0000

SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku
ZGU+IHdyb3RlOg0KPiBTYW1lIGhlcmUuDQoNCkFuZCBzYW1lIGhlcmUuDQoNCg0KL21hcnRpbg0K
DQoNCj4gDQo+IC9qcw0KPiANCj4gT24gVHVlLCBKYW4gMzAsIDIwMTggYXQgMDY6NTU6MzJQTSAr
MDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4gDQo+ID4gSSBoYXZlIHJlYWQgYW5kIHN1cHBv
cnQgYm90aCBkcmFmdHMgZm9yIGFkdmFuY2VtZW50Lg0KPiA+IA0KPiA+IEtlbnQgLy8gY28tYXV0
aG9yDQo+ID4gDQo+ID4gDQo+ID4gPT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0KPiA+IA0K
PiA+IEF1dGhvcnMgYW5kIFdHLA0KPiA+IA0KPiA+IFdlIGhhdmUgbm90IHJlY2VpdmVkIGFueSBl
eHBsaWNpdCBzdXBwb3J0IGZvciB0aGlzIExDIG9uIHRoaXMgZW1haWwgdGhyZWFkLiBJZiB5b3Ug
YmVsaWV2ZSB0aGVzZSBkcmFmdHMgYXJlIGltcG9ydGFudCBhbmQgc2hvdWxkIHByb2NlZWQsIHBs
ZWFzZSBzdGF0ZSB5b3VyIHN1cHBvcnQgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHRocmVh
ZC4NCj4gPiANCj4gPiBUaGFua3MuDQo+ID4gDQo+ID4gPiBPbiBKYW4gMTcsIDIwMTgsIGF0IDEw
OjM5IEFNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3Jv
dGU6DQo+ID4gPiANCj4gPiA+IFRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRh
LW5ldGNvbmYgYW5kIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mIGhhdmUgcG9zdGVk
IHVwZGF0ZXMgdG8gdGhlaXIgZHJhZnRzLCBhbmQgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudHMg
YXJlIHJlYWR5IGZvciBMQy4NCj4gPiA+IA0KPiA+ID4gVGhpcyBzdGFydHMgYSAyIHdlZWsgTEMg
b24gdGhlIHR3byBkcmFmdHMgdGhhdCB3aWxsIGVuZCBvbiBKYW51YXJ5IDMxLiBQbGVhc2Ugc2Vu
ZCB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLiBDb21tZW50cyBsaWtlIOKAnEkgaGF2ZSBy
ZXZpZXdlZCB0aGUgZG9jdW1lbnRzIGFuZCBiZWxpZXZlIHRoZXkgYXJlIHJlYWR5IGZvciBwdWJs
aWNhdGlvbuKAnSwgb3Ig4oCcSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBkb2N1bWVudCBiZWNh
dXNlIOKApuKAnSBhcmUgd2VsY29tZSBhbmQgdXNlZnVsIGZvciB0aGUgYXV0aG9ycy4NCj4gPiA+
IA0KPiA+ID4gQXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9m
IGFueSBJUFIgZm9yIGVpdGhlciBvZiB0aGUgZHJhZnRzLg0KPiA+ID4gDQo+ID4gPiBUaGFua3Mu
DQo+ID4gPiANCj4gPiA+IE1haGVzaCAmIEtlbnQNCj4gPiA+IA0KPiA+IA0KPiA+IE1haGVzaCAm
IEtlbnQNCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0K
PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29uZiZkPUR3SUdhUSZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y2h4Wkc1WnJCbkhDX3ZPMGY5a1loR25Nd0FVZUYy
QUxxbnBxanQyRk93SSZzPWNMeFB2YXczd0JLOEtmVXgwWktOUHlxUFBoQzE3WXgtbzlTSlFfcTRB
V0UmZT0NCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRm
Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K
PiANCj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZl
cnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2Ft
cHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAw
IDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiANCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29u
ZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Wed Jan 31 00:13: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 1B95D131987; Wed, 31 Jan 2018 00:13:07 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 MddlAMi75R1T; Wed, 31 Jan 2018 00:13:04 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA041319B3; Wed, 31 Jan 2018 00:11:21 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 96015F89; Wed, 31 Jan 2018 09:11:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id lEFF4Zxh7uO4; Wed, 31 Jan 2018 09:11:19 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 31 Jan 2018 09:11:19 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7086E20147; Wed, 31 Jan 2018 09:11:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 53isN0feicE1; Wed, 31 Jan 2018 09:11:18 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA8B520149; Wed, 31 Jan 2018 09:11:18 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id BBE2E423149E; Wed, 31 Jan 2018 09:11:18 +0100 (CET)
Date: Wed, 31 Jan 2018 09:11:18 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Mahesh Jethanandani , netconf , NETMOD Working Group 
Message-ID: <20180131081118.uqxivaxbkbbzzmji@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Mahesh Jethanandani , netconf , NETMOD Working Group 
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf]  LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 08:13:07 -0000

On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
> 
> I have some questions about these drafts.
> 
> 1) what if datastore set to "conventional"?
>     There are many places where a datastore-ref type is used.
>     However, "conventional" is valid for base "datastore", even though
>     it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.
 
> 2) origin filter is limited to 1 source
>    This filtering seems rather limited.  A client must retrieve
>  and check
>     all the values in use, then make repeated requests for each source as a
> different
>      leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.

> 3) with-defaults broken
>     The operational datastore does not support with-defaults.
>      Instead, the client must use origin-filter=or:default or with-origin
>      and check all the origin attributes.  Since a client needs to use
>      with-defaults for other datastores, this special handling of
> 
>      seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.

/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 Jan 31 00:23: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 721EC1316EA; Wed, 31 Jan 2018 00:23:18 -0800 (PST)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MgCGBVx-nGz1; Wed, 31 Jan 2018 00:23:16 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE7912D94D; Wed, 31 Jan 2018 00:22:06 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A4961AE0144; Wed, 31 Jan 2018 09:22:05 +0100 (CET)
Date: Wed, 31 Jan 2018 09:22:04 +0100 (CET)
Message-Id: <20180131.092204.390494514011757011.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: mjethanandani@gmail.com, netconf@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] [Netconf]  LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 08:23:18 -0000

SGksDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gSGksDQo+
IA0KPiBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlc2UgZHJhZnRzLg0KPiANCj4gMSkg
d2hhdCBpZiBkYXRhc3RvcmUgc2V0IHRvICJjb252ZW50aW9uYWwiPw0KPiAgICAgVGhlcmUgYXJl
IG1hbnkgcGxhY2VzIHdoZXJlIGEgZGF0YXN0b3JlLXJlZiB0eXBlIGlzIHVzZWQuDQo+ICAgICBI
b3dldmVyLCAiY29udmVudGlvbmFsIiBpcyB2YWxpZCBmb3IgYmFzZSAiZGF0YXN0b3JlIiwgZXZl
biB0aG91Z2gNCj4gICAgIGl0IGlzIGFtYmlndW91cyBhcyBhIGRhdGFzdG9yZSBzZWxlY3Rvci4N
Cg0KRm9yIGVkaXQtZGF0YSwgdGhlIHRleHQgc2F5czoNCg0KICAgICAgICBsZWFmIGRhdGFzdG9y
ZSB7DQogICAgICAgICAgdHlwZSBkczpkYXRhc3RvcmUtcmVmOw0KICAgICAgICAgIGRlc2NyaXB0
aW9uDQogICAgICAgICAgICAiRGF0YXN0b3JlIHdoaWNoIGlzIHRoZSB0YXJnZXQgb2YgdGhlIGVk
aXQtZGF0YSBvcGVyYXRpb24uDQoNCiAgICAgICAgICAgICBJZiB0aGUgdGFyZ2V0IGRhdGFzdG9y
ZSBpcyBub3Qgd3JpdGFibGUsIHRoZW4gdGhlIHNlcnZlcg0KICAgICAgICAgICAgIE1VU1QgcmV0
dXJuIGFuIDxycGMtZXJyb3I+IGVsZW1lbnQgd2l0aCBhbiA8ZXJyb3ItdGFnPg0KICAgICAgICAg
ICAgIHZhbHVlIG9mICdpbnZhbGlkLXZhbHVlJyI7DQoNClNvIGZyb20gdGhpcyBpdCBmb2xsb3dz
IHRoYXQgaWYgdGhlIGNsaWVudCBzZW5kcyAiY29udmVudGlvbmFsIiwgdGhlDQpzZXJ2ZXIgd2ls
bCByZXBseSB3aXRoIGFuICdpbnZhbGlkLXZhbHVlJyBlcnJvci4NCg0KTWF5YmUgd2UgY2FuIGV2
ZW4gY2xhcmlmeToNCg0KICAgICAgICAgICAgIElmIHRoZSB0YXJnZXQgZGF0YXN0b3JlIGlzIG5v
dCB3cml0YWJsZSwgb3IgaXMgbm90DQogICAgICAgICAgICAgc3VwcG9ydGVkIG9uIHRoZSBzZXJ2
ZXIsIHRoZW4gdGhlIHNlcnZlcg0KICAgICAgICAgICAgIE1VU1QgcmV0dXJuIGFuIDxycGMtZXJy
b3I+IGVsZW1lbnQgd2l0aCBhbiA8ZXJyb3ItdGFnPg0KDQoNClRoZXJlIGlzIHNpbWlsYXIgdGV4
dCBmb3IgbG9jay91bmxvY2svdmFsaWRhdGUuDQoNCg0KDQpCdXQgZm9yIGdldC1kYXRhLCB0aGUg
dGV4dCBqdXN0IHNheXM6DQoNCiAgICAgICAgbGVhZiBkYXRhc3RvcmUgew0KICAgICAgICAgIHR5
cGUgZHM6ZGF0YXN0b3JlLXJlZjsNCiAgICAgICAgICAuLi4NCiAgICAgICAgICBkZXNjcmlwdGlv
bg0KICAgICAgICAgICAgIkRhdGFzdG9yZSBmcm9tIHdoaWNoIHRvIHJldHJpZXZlIGRhdGEuIjsN
Cg0KSSB0aGluayB3ZSBzaG91bGQgYWRkIHRleHQ6DQoNCiAgSWYgdGhlIGRhdGFzdG9yZSBpcyBu
b3Qgc3VwcG9ydGVkIG9uIHRoZSBzZXJ2ZXIsICwgdGhlbiB0aGUgc2VydmVyDQogIE1VU1QgcmV0
dXJuIGFuIDxycGMtZXJyb3I+IGVsZW1lbnQgd2l0aCBhbiA8ZXJyb3ItdGFnPiB2YWx1ZSBvZg0K
ICAnaW52YWxpZC12YWx1ZScuDQoNCg0KPiAyKSBvcmlnaW4gZmlsdGVyIGlzIGxpbWl0ZWQgdG8g
MSBzb3VyY2UNCj4gICAgVGhpcyBmaWx0ZXJpbmcgc2VlbXMgcmF0aGVyIGxpbWl0ZWQuICBBIGNs
aWVudCBtdXN0IHJldHJpZXZlDQo+IDx3aXRoLW9yaWdpbj4gYW5kIGNoZWNrDQo+ICAgICBhbGwg
dGhlIHZhbHVlcyBpbiB1c2UsIHRoZW4gbWFrZSByZXBlYXRlZCByZXF1ZXN0cyBmb3IgZWFjaCBz
b3VyY2UgYXMgYQ0KPiBkaWZmZXJlbnQNCj4gICAgIDxvcmlnaW4tZmlsdGVyPiBsZWFmDQoNClNp
bmNlICJBTkQiIG9mIG9yaWdpbnMgZG9lc24ndCByZWFsbHkgbWFrZSBhbnkgc2Vuc2UsIEkgdGhp
bmsgd2UgY2FuDQptYWtlIHRoaXMgYSBsZWFmLWxpc3QgYW5kIGV4cGxhaW4gdGhhdCB0aGVzZSB2
YWx1ZXMgYXJlIE9SOmVkLiAgRG8geW91DQp0aGluayB0aGlzIHdvdWxkIGJlIGEgZ29vZCBpZGVh
Pw0KDQo+IDMpIHdpdGgtZGVmYXVsdHMgYnJva2VuDQo+ICAgICBUaGUgb3BlcmF0aW9uYWwgZGF0
YXN0b3JlIGRvZXMgbm90IHN1cHBvcnQgd2l0aC1kZWZhdWx0cy4NCj4gICAgICBJbnN0ZWFkLCB0
aGUgY2xpZW50IG11c3QgdXNlIG9yaWdpbi1maWx0ZXI9b3I6ZGVmYXVsdCBvciB3aXRoLW9yaWdp
bg0KPiAgICAgIGFuZCBjaGVjayBhbGwgdGhlIG9yaWdpbiBhdHRyaWJ1dGVzLiAgU2luY2UgYSBj
bGllbnQgbmVlZHMgdG8gdXNlDQo+ICAgICAgd2l0aC1kZWZhdWx0cyBmb3Igb3RoZXIgZGF0YXN0
b3JlcywgdGhpcyBzcGVjaWFsIGhhbmRsaW5nIG9mDQo+IDxvcGVyYXRpb25hbD4NCj4gICAgICBz
ZWVtcyB1bmhlbHBmdWwuDQoNClRoZSAid2l0aC1kZWZhdWx0cyIgZmVhdHVyZSBpcyBtb3N0bHkg
dXNlZnVsIGluIGNvbmZpZ3VyYXRpb24NCmRhdGFzdG9yZXMsIHdoZXJlIHRoZSBjbGllbnQgbmVl
ZHMgdG8gdW5kZXJzdGFuZCBob3cgdGhlIHNlcnZlciB0cmVhdHMNCmRlZmF1bHRzLiAgV2hlbiB0
aGUgc2VydmVyIHN0YXJ0cyB0byBvcGVyYXRpb25hbGx5IHVzZSBjb25maWcgZGF0YSwgaXQNCndp
bGwgYWxzbyB0YWtlIGRlZmF1bHQgdmFsdWVzIGludG8gYWNjb3VudCBhbmQgdXNlIHRoZXNlIHZh
bHVlcywganVzdA0KYXMgaWYgdGhleSBoYWQgYmVlbiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQuICBk
ZWZhdWx0IHZhbHVlcyBhcmUgImluDQp1c2UiIGFuZCB0aHVzIHByZXNlbnQgaW4gdGhlIG9wZXJh
dGlvbmFsIHN0YXRlIGRhdGFzdG9yZSAod2hpY2ggYnkNCmRlZmluaXRpb24gY29udGFpbnMgYWxs
IHZhbHVlcyB0aGF0IGFyZSBpbiB1c2UpLiAgU2luY2UgdGhlc2UgdmFsdWVzDQphcmUgcHJlc2Vu
dCBpbiB0aGUgZGF0YXN0b3JlLCB0aGV5IGFyZSBhbHdheXMgcmV0dXJuZWQuICBJZiBmb3Igc29t
ZQ0KcmVhc29uIGEgZGVmYXVsdCB2YWx1ZSBpcyBOT1QgdXNlZCwgdGhlIGxlYWYgd2lsbCBub3Qg
YmUgcHJlc2VudCBpbg0KPG9wZXJhdGlvbmFsPiwgYW5kIGl0IHdpbGwgbm90IGJlIHJlcG9ydGVk
Lg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiBPbiBUdWUs
IEphbiAzMCwgMjAxOCBhdCAxMDoyNyBBTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8DQo+IG1qZXRo
YW5hbmRhbmlAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+ID4gQXV0aG9ycyBhbmQgV0csDQo+ID4N
Cj4gPiBXZSBoYXZlIG5vdCByZWNlaXZlZCBhbnkgZXhwbGljaXQgc3VwcG9ydCBmb3IgdGhpcyBM
QyBvbiB0aGlzIGVtYWlsDQo+ID4gdGhyZWFkLiBJZiB5b3UgYmVsaWV2ZSB0aGVzZSBkcmFmdHMg
YXJlIGltcG9ydGFudCBhbmQgc2hvdWxkIHByb2NlZWQsDQo+ID4gcGxlYXNlIHN0YXRlIHlvdXIg
c3VwcG9ydCBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgdGhyZWFkLg0KPiA+DQo+ID4gVGhh
bmtzLg0KPiA+DQo+ID4gPiBPbiBKYW4gMTcsIDIwMTgsIGF0IDEwOjM5IEFNLCBNYWhlc2ggSmV0
aGFuYW5kYW5pIDwNCj4gPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gPg0K
PiA+ID4gVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtbmV0Y29uZiBhbmQN
Cj4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZiBoYXZlIHBvc3RlZCB1cGRhdGVz
IHRvIHRoZWlyIGRyYWZ0cywgYW5kDQo+ID4gYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudHMgYXJl
IHJlYWR5IGZvciBMQy4NCj4gPiA+DQo+ID4gPiBUaGlzIHN0YXJ0cyBhIDIgd2VlayBMQyBvbiB0
aGUgdHdvIGRyYWZ0cyB0aGF0IHdpbGwgZW5kIG9uIEphbnVhcnkgMzEuDQo+ID4gUGxlYXNlIHNl
bmQgeW91ciBjb21tZW50cyBvbiB0aGlzIHRocmVhZC4gQ29tbWVudHMgbGlrZSDigJxJIGhhdmUg
cmV2aWV3ZWQNCj4gPiB0aGUgZG9jdW1lbnRzIGFuZCBiZWxpZXZlIHRoZXkgYXJlIHJlYWR5IGZv
ciBwdWJsaWNhdGlvbuKAnSwgb3Ig4oCcSSBoYXZlDQo+ID4gY29uY2VybnMgYWJvdXQgdGhlIGRv
Y3VtZW50IGJlY2F1c2Ug4oCm4oCdIGFyZSB3ZWxjb21lIGFuZCB1c2VmdWwgZm9yIHRoZQ0KPiA+
IGF1dGhvcnMuDQo+ID4gPg0KPiA+ID4gQXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5
b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgZm9yIGVpdGhlciBvZg0KPiA+IHRoZSBkcmFmdHMuDQo+
ID4gPg0KPiA+ID4gVGhhbmtzLg0KPiA+ID4NCj4gPiA+IE1haGVzaCAmIEtlbnQNCj4gPiA+DQo+
ID4NCj4gPiBNYWhlc2ggJiBLZW50DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPiA+DQo=


From nobody Wed Jan 31 01:22:36 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 6D1C112EC85 for ; Wed, 31 Jan 2018 01:22:35 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 Eu9jlkJ82R2u for ; Wed, 31 Jan 2018 01:22:33 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 9B03412D848 for ; Wed, 31 Jan 2018 01:22:32 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id t79so19626372lfe.3 for ; Wed, 31 Jan 2018 01:22:32 -0800 (PST)
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=FRR4OMjl2fxRMGBc9J27bUlUtgT9HSi2usy3RrS5TwM=; b=i2mB1MAzzjJRpK9w6wUPYFp8DEbTgNXS74iGJc1qq/yUBQ2t19TVMv5T4NM8WF7EYQ PccTisiXQ2/yzBmWhX7LWJJwkc761LYWA7ajO3yvLgCAimWDJULstVAXnZcw/LeqCIkZ j2QjeAYIpdIAGwJp2ZUfA6iR9XJ//nutEOTU317srqvA2ez1I/GsgLxgWRK+qamanHRr 3uHWBDt7pWrwYU2l0Zdqb8tpnAGia63fXLRiIv0Dzjm2kh8BL26YvjmCD+dCJq/OVYBN CKY5n2lWWAu2NtCaal7WfN9xsOV5ef7nEoGd4eYAwRICdhYvb1zxdgpQ6d0eSEq+9FKs 8fSg==
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=FRR4OMjl2fxRMGBc9J27bUlUtgT9HSi2usy3RrS5TwM=; b=kgO0xfB72mP5OG72wRBzFnT6XBEhUMNCc+N3HW6a1uRyIpfIHQqLDdENrPJGanm3E/ SKjme5QcIz1QUmqA2lF5Cey8eRDn0qScsCTgOtvt99w64U9DA2RvmVn+BZV11zb1FPON xU+xBgS7dpojYiaUDLsrEALS/Ewiz72mAD1/xyg38jM+lxPE4EL9OZIfz4DEnwEo3zaL E0mMX6bIzTNA+mqfQ1o9gmf6blmOH05CSFSYw/L7W6f+aQ5BVs/UUJs9xXpD3iPFPbXt fk7DYXxK5ZGrC7EnNb/jMuv5d30CJvI+yPh6S/TY8qEyqBmj4OKhTC6I37m9OMQD7gTC Nhqw==
X-Gm-Message-State: AKwxytfmhabXYL5532eIuIZoeE313xxDtOdIiaOjQcE20rMXVTbsO8PU EH6uCeBvC+NEJ/9QE7s+0DiBYPef6neNktU+cjVCXQ==
X-Google-Smtp-Source: AH8x227VidR3bEDiFjcnOPkx8hLQEM9bJIJqViC77o0EcWlVGMC/izgqV1Drb8hPhOC72I9XpgPn0sUdN4RCZoQBYrA=
X-Received: by 10.25.190.203 with SMTP id o194mr19604306lff.120.1517390550854;  Wed, 31 Jan 2018 01:22:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Wed, 31 Jan 2018 01:22:30 -0800 (PST)
In-Reply-To: <20180131081118.uqxivaxbkbbzzmji@elstar.local>
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local>
From: Andy Bierman 
Date: Wed, 31 Jan 2018 01:22:30 -0800
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Mahesh Jethanandani , netconf ,  NETMOD Working Group 
Content-Type: multipart/alternative; boundary="94eb2c1a185ec5043305640f04eb"
Archived-At: 
Subject: Re: [netmod] [Netconf]  LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 09:22:35 -0000

--94eb2c1a185ec5043305640f04eb
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> >     There are many places where a datastore-ref type is used.
> >     However, "conventional" is valid for base "datastore", even though
> >     it is ambiguous as a datastore selector.
>
> We can add explicit text that an identity that does not resolve to a
> datastore implemented by the server results in an invalid value error.
>
>

OK



> > 2) origin filter is limited to 1 source
> >    This filtering seems rather limited.  A client must retrieve
> >  and check
> >     all the values in use, then make repeated requests for each source
> as a
> > different
> >      leaf
>
> If the client does , then it has all origin information
> and it can filter locally. That said, we could make origin-filter a
> leaf-list which is logically ORed so that one can retrieve
> origin-filter=or:system or origin-filter=or:learned in one request.
>
>

OK


> > 3) with-defaults broken
> >     The operational datastore does not support with-defaults.
> >      Instead, the client must use origin-filter=or:default or with-origin
> >      and check all the origin attributes.  Since a client needs to use
> >      with-defaults for other datastores, this special handling of
> > 
> >      seems unhelpful.
>
> I think the with-defaults semantics for conventional configuration
> datastores are much more complicated than necessary for the
> operational state datastore. Note that that the operational state
> datastore reports in-use values not really defaults:
>
>   foo
>
> This reports that the value 'foo' is in use and that it originates
> from a default value. Note that this could also be
>
>   foo
>
> in case the intended configuration datastore configured the value
> 'foo' (despite this value matching the default). The with-defaults
> solution is pretty complex because it tries to handle how different
> systems deal with configuration defaults. The idea is to not carry
> this complexity over to in-use values in the operational state
> datastore.
>
>

Before NMDA, the client could decide if it wanted to retrieve default nodes
or not.
This client-choice has been removed from NMDA, which is a problem.




> /js
>
>
Andy


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

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




On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bier=
man wrote:

> Hi,

>

> I have some questions about these drafts.

>

> 1) what if datastore set to "conventional"?

>=C2=A0 =C2=A0 =C2=A0There are many places where a datastore-ref type is=
 used.

>=C2=A0 =C2=A0 =C2=A0However, "conventional" is valid for base=
 "datastore", even though

>=C2=A0 =C2=A0 =C2=A0it is ambiguous as a datastore selector.



We can add explicit text that an identity that does not resolve to a

datastore implemented by the server results in an invalid value error.




OK

=

=C2=A0

> 2) origin filter is limited to 1 source

>=C2=A0 =C2=A0 This filtering seems rather limited.=C2=A0 A client must =
retrieve

> <with-origin> and check

>=C2=A0 =C2=A0 =C2=A0all the values in use, then make repeated requests =
for each source as a

> different

>=C2=A0 =C2=A0 =C2=A0<origin-filter> leaf



If the client does <with-origin>, then it has all origin information<=
br>
and it can filter locally. That said, we could make origin-filter a

leaf-list which is logically ORed so that one can retrieve

origin-filter=3Dor:system or origin-filter=3Dor:learned in one request.




OK
=C2=A0

> 3) with-defaults broken

>=C2=A0 =C2=A0 =C2=A0The operational datastore does not support with-def=
aults.

>=C2=A0 =C2=A0 =C2=A0 Instead, the client must use origin-filter=3Dor:de=
fault or with-origin

>=C2=A0 =C2=A0 =C2=A0 and check all the origin attributes.=C2=A0 Since a=
 client needs to use

>=C2=A0 =C2=A0 =C2=A0 with-defaults for other datastores, this special h=
andling of

> <operational>

>=C2=A0 =C2=A0 =C2=A0 seems unhelpful.



I think the with-defaults semantics for conventional configuration

datastores are much more complicated than necessary for the

operational state datastore. Note that that the operational state

datastore reports in-use values not really defaults:



=C2=A0 <leaf or:origin=3D'default'>foo</leaf>



This reports that the value 'foo' is in use and that it originates<=
br>
from a default value. Note that this could also be



=C2=A0 <leaf or:origin=3D'intended'>foo</leaf>



in case the intended configuration datastore configured the value

'foo' (despite this value matching the default). The with-defaults<=
br>
solution is pretty complex because it tries to handle how different

systems deal with configuration defaults. The idea is to not carry

this complexity over to in-use values in the operational state

datastore.




Before NMDA, the client could decide =
if it wanted to retrieve default nodes or not.
This client-choice=
 has been removed from NMDA, which is a problem.

<=
br>
=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/>





--94eb2c1a185ec5043305640f04eb--


From nobody Wed Jan 31 01:28:52 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 CCAC412D848; Wed, 31 Jan 2018 01:28:46 -0800 (PST)
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_RP_MATCHES_RCVD=-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 FuGWG7aa0La1; Wed, 31 Jan 2018 01:28:45 -0800 (PST)
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 861481241F8; Wed, 31 Jan 2018 01:28:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2080; q=dns/txt; s=iport; t=1517390924; x=1518600524; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8AHDLqDoB9iYQvLGVqQxj64Ut2NPTYc9ecKMACG8ppw=; b=jQvx0ryv0MKmi85sw9TjhYjDjKqADHVOpTMG8hOnFKSXquRWys2GVon6 fyKQEdwTD7+FWGQqJtwlaxB/W2P6E/RbjEdVGK8eTAwcS1ajDt9j1EM8+ KfNUybkBzJxdFcb+7pGGGT2OplXE3nmO3Xs4gMViSldMFN15+ruW3i+ue E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQDYinFa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMVgRN1KINgixiPeokSjkmCAgoYC4RJTwKDIhQBAQEBAQEBAQJ?= =?us-ascii?q?rKIUkAQEEAQEhDwEFNhsJAg4KAgImAgIhBjAGAQwGAgEBihkDFRCJL51xgieHO?= =?us-ascii?q?Q2DHQEBAQEBAQEBAQEBAQEBAQEBAQEBGQWBD4NMg2yBaCmDBYJrRAEBAoE8ARI?= =?us-ascii?q?BH4MXgmUFo1s+i0mFGoUGgh2GIoNxJodWji6BJogUgTw2ImBwMxoIGxU9giqDe?= =?us-ascii?q?wEJckE3iiiCPAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,439,1511827200";  d="scan'208";a="1716828"
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; 31 Jan 2018 09:28:40 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0V9SdC7021914; Wed, 31 Jan 2018 09:28:40 GMT
To: Kent Watsen , Mahesh Jethanandani , netconf , NETMOD Working Group 
References:   <8148FDBD-2B46-4D3B-9A50-2323F3005976@juniper.net> <20180130193301.63e4xt5thsprsym6@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Wed, 31 Jan 2018 09:28:39 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180130193301.63e4xt5thsprsym6@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 09:28:47 -0000

As co-author, I have read and support both drafts for advancement.

In fact, I think that it is important that we get these drafts (and 
YL-bis) completed and standardized quickly, since the YANG models that 
IETF is standardizing rely on the NMDA.

Thanks,
Rob


On 30/01/2018 19:33, Juergen Schoenwaelder wrote:
> Same here.
>
> /js
>
> On Tue, Jan 30, 2018 at 06:55:32PM +0000, Kent Watsen wrote:
>> I have read and support both drafts for advancement.
>>
>> Kent // co-author
>>
>>
>> ===== original message =====
>>
>> Authors and WG,
>>
>> We have not received any explicit support for this LC on this email thread. If you believe these drafts are important and should proceed, please state your support by responding to this email thread.
>>
>> Thanks.
>>
>>> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  wrote:
>>>
>>> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.
>>>
>>> This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.
>>>
>>> Authors please indicate whether you are aware of any IPR for either of the drafts.
>>>
>>> Thanks.
>>>
>>> Mahesh & Kent
>>>
>> Mahesh & Kent
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI&s=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE&e=
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf


From nobody Wed Jan 31 03:32:37 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 D4462131A3E; Wed, 31 Jan 2018 03:32:30 -0800 (PST)
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_RP_MATCHES_RCVD=-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 57jh5x_pgABK; Wed, 31 Jan 2018 03:32:27 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0CA131A3F; Wed, 31 Jan 2018 03:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17286; q=dns/txt; s=iport; t=1517398284; x=1518607884; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=w4Ydop+F9EYjvECr2jDuFQktOhfqNbqL4mXxbAywVOg=; b=VzPAYkFSEw5bR58V58KuH5QDHw+tLqpYmmWAqday71oPzAjRK15xzmSm tN2EL8f3tjLxIjcCY86AFl1FpG0whKF2cExN+xlESXg2hdp4Qf+N2vC4G 8jbicEYQFpcUUKjEXr8Q2RX7cZJXDoyDGSEsS11i4TJP1Uppzd5KLM2lD U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQA6qHFa/xbLJq1SBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgxGBF3Uog2CLGI96kXKFaYICChgBCoM6gQ9PAoMiFAEBAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEDAQEBIUsLBQkCCQIQAgYnAwICGwwfAw4GAQwGAgEBFQKKE?= =?us-ascii?q?ggQiGOdcYInJoo9AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFhFaDbIFoKYMFgy8?= =?us-ascii?q?BAQKBRQMPAjcmglCCZQWaAooclWyMMIFlhhiPVIgVgTw2IoFQMxoIGxU9giqCH?= =?us-ascii?q?DkcggZBN4lpgksBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,439,1511827200"; d="scan'208,217";a="1714250"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 11:31:21 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0VBVLSe001928; Wed, 31 Jan 2018 11:31:21 GMT
To: Andy Bierman , netconf , NETMOD Working Group 
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local> 
From: Robert Wilton 
Message-ID: <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com>
Date: Wed, 31 Jan 2018 11:31:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------059635660E4F88B64D01C962"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 11:32:31 -0000

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

Hi Andy,


On 31/01/2018 09:22, Andy Bierman wrote:
>
>
> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>     > Hi,
>     >
>     > I have some questions about these drafts.
>     >
>     > 1) what if datastore set to "conventional"?
>     >     There are many places where a datastore-ref type is used.
>     >     However, "conventional" is valid for base "datastore", even
>     though
>     >     it is ambiguous as a datastore selector.
>
>     We can add explicit text that an identity that does not resolve to a
>     datastore implemented by the server results in an invalid value error.
>
>
>
> OK
>
>     > 2) origin filter is limited to 1 source
>     >    This filtering seems rather limited.  A client must retrieve
>     >  and check
>     >     all the values in use, then make repeated requests for each
>     source as a
>     > different
>     >      leaf
>
>     If the client does , then it has all origin information
>     and it can filter locally. That said, we could make origin-filter a
>     leaf-list which is logically ORed so that one can retrieve
>     origin-filter=or:system or origin-filter=or:learned in one request.
>
>
>
> OK
>
>     > 3) with-defaults broken
>     >     The operational datastore does not support with-defaults.
>     >      Instead, the client must use origin-filter=or:default or
>     with-origin
>     >      and check all the origin attributes.  Since a client needs
>     to use
>     >      with-defaults for other datastores, this special handling of
>     > 
>     >      seems unhelpful.
>
>     I think the with-defaults semantics for conventional configuration
>     datastores are much more complicated than necessary for the
>     operational state datastore. Note that that the operational state
>     datastore reports in-use values not really defaults:
>
>       foo
>
>     This reports that the value 'foo' is in use and that it originates
>     from a default value. Note that this could also be
>
>       foo
>
>     in case the intended configuration datastore configured the value
>     'foo' (despite this value matching the default). The with-defaults
>     solution is pretty complex because it tries to handle how different
>     systems deal with configuration defaults. The idea is to not carry
>     this complexity over to in-use values in the operational state
>     datastore.
>
>
>
> Before NMDA, the client could decide if it wanted to retrieve default 
> nodes or not.
> This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from 
operational (defined in section 5.3 of the NMDA architecture):
  - it should return explicit values for everything that is affecting 
the actual running state of the device (regardless of whether the 
operational value matches a schema default value).
  - it does not need to, and should not, return operational values for 
stuff that isn't actually in use, i.e. don't return needless and 
unwanted data.

In particular, if no value is returned from a particular data node in 
 then, barring mgmt protocol errors, a client can assume 
that any functionality associated with that data node is off (i.e. not 
in use).

Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then  
does not need to return any data for it.  It would be reasonable to 
return a flag to indicate that OSPF is not enabled/running.

(ii) If you have some funky widget on an interface that defaults to 
being off and isn't being used then  don't need to return 
any data for it.

(iii) But, if you have some funky widget on an interface that defaults 
to being on, then the server should return data for it.  If it is 
actually enabled, then it would indicate that it is on and return any 
associated values with its operational state, or if it is disabled then 
it should explicitly report that it is off.

(iv) I would regard that all applied configuration is "in use" by the 
system, even if it matches the default value, and hence it should be 
reported.


This behavior for  is obviously slightly different from the 
existing with-default handling that is supported for configuration 
datastores.  As I recall, there were a couple of reasons that we decided 
to have a different behavior for :
(a) to have consistent semantics for all servers, rather than different 
servers supporting different with-defaults behaviors (which makes life 
harder for clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with 
the existing with-defaults semantics it is not clear to me that servers 
will always return an explicit value to indicate that a particular 
widget is off if the schema defines that the default it that is 
enabled.  If the server doesn't support a given widget at all, it is 
quite plausible that it will just return no data for it. In theory 
features/deviations should handle this, but those don't work so well if 
different linecards have different capabilities. Hence being explicit 
about stuff that is in use seems more robust.

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


--------------059635660E4F88B64D01C962
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

    

    

    
On 31/01/2018 09:22, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Jan 31, 2018 at 12:11 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Tue,
              Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:

              > Hi,

              >

              > I have some questions about these drafts.

              >

              > 1) what if datastore set to "conventional"?

              >     There are many places where a datastore-ref type
              is used.

              >     However, "conventional" is valid for base
              "datastore", even though

              >     it is ambiguous as a datastore selector.

              

              We can add explicit text that an identity that does not
              resolve to a

              datastore implemented by the server results in an invalid
              value error.

              

            

            


            

            


            

            
OK

            


            

            
 

            

              > 2) origin filter is limited to 1 source

              >    This filtering seems rather limited.  A client
              must retrieve

              > <with-origin> and check

              >     all the values in use, then make repeated
              requests for each source as a

              > different

              >     <origin-filter> leaf

              

              If the client does <with-origin>, then it has all
              origin information

              and it can filter locally. That said, we could make
              origin-filter a

              leaf-list which is logically ORed so that one can retrieve

              origin-filter=or:system or origin-filter=or:learned in one
              request.

              

            

            


            

            


            

            
OK

            
 

            

              > 3) with-defaults broken

              >     The operational datastore does not support
              with-defaults.

              >      Instead, the client must use
              origin-filter=or:default or with-origin

              >      and check all the origin attributes.  Since a
              client needs to use

              >      with-defaults for other datastores, this special
              handling of

              > <operational>

              >      seems unhelpful.

              

              I think the with-defaults semantics for conventional
              configuration

              datastores are much more complicated than necessary for
              the

              operational state datastore. Note that that the
              operational state

              datastore reports in-use values not really defaults:

              

                <leaf or:origin='default'>foo</leaf>

              

              This reports that the value 'foo' is in use and that it
              originates

              from a default value. Note that this could also be

              

                <leaf or:origin='intended'>foo</leaf>

              

              in case the intended configuration datastore configured
              the value

              'foo' (despite this value matching the default). The
              with-defaults

              solution is pretty complex because it tries to handle how
              different

              systems deal with configuration defaults. The idea is to
              not carry

              this complexity over to in-use values in the operational
              state

              datastore.

              

                

            


            

            


            

            
Before NMDA, the client could decide if it wanted to
              retrieve default nodes or not.

            
This client-choice has been removed from NMDA, which is
              a problem.

          

        

      

    

    We tried to reach a sensible compromise on the data returned from
    operational (defined in section 5.3 of the NMDA architecture):

     - it should return explicit values for everything that is affecting
    the actual running state of the device (regardless of whether the
    operational value matches a schema default value).

     - it does not need to, and should not, return operational values
    for stuff that isn't actually in use, i.e. don't return needless and
    unwanted data.

    

    In particular, if no value is returned from a particular data node
    in <operational> then, barring mgmt protocol errors, a client
    can assume that any functionality associated with that data node is
    off (i.e. not in use).

    

    Some examples to illustrate the behavior:

    

    (i) If a protocol, e.g. OSPF,  is not enabled/running then
    <operational> does not need to return any data for it.  It
    would be reasonable to return a flag to indicate that OSPF is not
    enabled/running.

    

    (ii) If you have some funky widget on an interface that defaults to
    being off and isn't being used then <operational> don't need
    to return any data for it.

    

    (iii) But, if you have some funky widget on an interface that
    defaults to being on, then the server should return data for it.  If
    it is actually enabled, then it would indicate that it is on and
    return any associated values with its operational state, or if it is
    disabled then it should explicitly report that it is off. 

    

    (iv) I would regard that all applied configuration is "in use" by
    the system, even if it matches the default value, and hence it
    should be reported.

    

    

    This behavior for <operational> is obviously slightly
    different from the existing with-default handling that is supported
    for configuration datastores.  As I recall, there were a couple of
    reasons that we decided to have a different behavior for
    <operational>:

    (a) to have consistent semantics for all servers, rather than
    different servers supporting different with-defaults behaviors
    (which makes life harder for clients because they must cope with all
    variants).

    (b) to remove any potential ambiguity if data isn't returned.  I.e.
    with the existing with-defaults semantics it is not clear to me that
    servers will always return an explicit value to indicate that a
    particular widget is off if the schema defines that the default it
    that is enabled.  If the server doesn't support a given widget at
    all, it is quite plausible that it will just return no data for it. 
    In theory features/deviations should handle this, but those don't
    work so well if different linecards have different capabilities. 
    Hence being explicit about stuff that is in use seems more robust.

    

    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


    

    

  


--------------059635660E4F88B64D01C962--


From nobody Wed Jan 31 04:33: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 91A7B12E854; Wed, 31 Jan 2018 04:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HyzoIdi8GQan; Wed, 31 Jan 2018 04:33:32 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 56C2F12DA42; Wed, 31 Jan 2018 04:33:04 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id EEE191820413; Wed, 31 Jan 2018 13:32:32 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id AA7FC18203DE; Wed, 31 Jan 2018 13:32:30 +0100 (CET)
From: Ladislav Lhotka 
To: Mahesh Jethanandani , netconf 
Cc: NETMOD Working Group 
In-Reply-To: 
References:  
Mail-Followup-To: Mahesh Jethanandani , netconf , NETMOD Working Group 
Date: Wed, 31 Jan 2018 13:32:59 +0100
Message-ID: <87k1vyw6mc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 12:33:35 -0000

Hi,

I read the draft draft-ietf-netconf-nmda-restconf-02, I believe it is
important and ready to be published. We plan an implementation.

Thanks for this work,

Lada

Mahesh Jethanandani  writes:

> Authors and WG,
>
> We have not received any explicit support for this LC on this email threa=
d. If you believe these drafts are important and should proceed, please sta=
te your support by responding to this email thread.
>
> Thanks.
>
>> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  wrote:
>>=20
>> The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nm=
da-restconf have posted updates to their drafts, and believe that the docum=
ents are ready for LC.
>>=20
>> This starts a 2 week LC on the two drafts that will end on January 31. P=
lease send your comments on this thread. Comments like =E2=80=9CI have revi=
ewed the documents and believe they are ready for publication=E2=80=9D, or =
=E2=80=9CI have concerns about the document because =E2=80=A6=E2=80=9D are =
welcome and useful for the authors.
>>=20
>> Authors please indicate whether you are aware of any IPR for either of t=
he drafts.
>>=20
>> Thanks.
>>=20
>> Mahesh & Kent
>>=20
>
> Mahesh & Kent
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Jan 31 08:53:57 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 1723512EB8C; Wed, 31 Jan 2018 08:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 FK44hZP3XBRR; Wed, 31 Jan 2018 08:53:52 -0800 (PST)
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 CA13012EAFA; Wed, 31 Jan 2018 08:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31950; q=dns/txt; s=iport; t=1517417631; x=1518627231; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ifer7fFM75vV7pqlXV87qBH8L+10h1GdwMVOQsBGLuk=; b=jIXq+rODnwMuMbxRu4+8Y2H6yA2Yorfa8ot2SKCL1n5VPtckyvq6C6Zs Ia4ROwyo38zflfxlR7CYL7GTKYWbS01G2ldjYsLUCjSy5s4nv87h9ZPX5 eZr/KDc9mS5xFZi7pYDGZ8EazZSCrzDihYwNjCXFsjI0myYv1anE816Xp k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBi83Fa/5xdJa1SBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkpHMWZ1KAqDVphPggKXW4ICChgBCoRJTwIagjVXFQEBAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEDAQEBIQpBBAwJAgIBCBACAwMNEwcDAgICGQwLFAMOAgQBE?= =?us-ascii?q?ggRAok2XAgQpw6CJyaKPAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYRWghWBV4F?= =?us-ascii?q?ogy6DLwEBAoFFAw8CLQoVEYITPYJlBZoCihwClWGCJoo5gT+GGJc8AhEZAYE7A?= =?us-ascii?q?TUjgVBwFT2CKoJVHIIGeIlbgTSBFwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,440,1511827200";  d="scan'208,217";a="348389826"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 16:53:49 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w0VGrng0022371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Jan 2018 16:53:49 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 11:53:48 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 31 Jan 2018 11:53:49 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Andy Bierman , netconf , NETMOD Working Group 
Thread-Topic: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
Thread-Index: AQHTmoc5ksbA2PO8/Em42tqduaeEB6OOIWVQ
Date: Wed, 31 Jan 2018 16:53:48 +0000
Message-ID: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com>
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local>  <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com>
In-Reply-To: <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_29b8034ef2a94523944d53767e6789beXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 16:53:55 -0000

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

SSBoYXZlIHJlYWQgYW5kIHN1cHBvcnQgdGhlc2UgdHdvIGRyYWZ0cyBnb2luZyBmb3J3YXJkLg0K
DQoNCg0KSSBkbyBoYXZlIG9uZSBhZGRpdGlvbmFsIHRob3VnaHQgYmVsb3cgb24gZHJhZnQtaWV0
Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzIHNlY3Rpb24gNS4zIGRlZmF1bHQgaGFuZGxpbmcg
cHJvY2Vzcy4gIFNlZSBpbi1saW5lLi4uDQoNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiAtWCwgSmFu
dWFyeSAzMSwgMjAxOCA2OjMxIEFNDQoNCg0KSGkgQW5keSwNCg0KT24gMzEvMDEvMjAxOCAwOToy
MiwgQW5keSBCaWVybWFuIHdyb3RlOg0KDQoNCk9uIFdlZCwgSmFuIDMxLCAyMDE4IGF0IDEyOjEx
IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3Jv
dGU6DQpPbiBUdWUsIEphbiAzMCwgMjAxOCBhdCAxMjozNTozM1BNIC0wODAwLCBBbmR5IEJpZXJt
YW4gd3JvdGU6DQo+IEhpLA0KPg0KPiBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlc2Ug
ZHJhZnRzLg0KPg0KPiAxKSB3aGF0IGlmIGRhdGFzdG9yZSBzZXQgdG8gImNvbnZlbnRpb25hbCI/
DQo+ICAgICBUaGVyZSBhcmUgbWFueSBwbGFjZXMgd2hlcmUgYSBkYXRhc3RvcmUtcmVmIHR5cGUg
aXMgdXNlZC4NCj4gICAgIEhvd2V2ZXIsICJjb252ZW50aW9uYWwiIGlzIHZhbGlkIGZvciBiYXNl
ICJkYXRhc3RvcmUiLCBldmVuIHRob3VnaA0KPiAgICAgaXQgaXMgYW1iaWd1b3VzIGFzIGEgZGF0
YXN0b3JlIHNlbGVjdG9yLg0KDQpXZSBjYW4gYWRkIGV4cGxpY2l0IHRleHQgdGhhdCBhbiBpZGVu
dGl0eSB0aGF0IGRvZXMgbm90IHJlc29sdmUgdG8gYQ0KZGF0YXN0b3JlIGltcGxlbWVudGVkIGJ5
IHRoZSBzZXJ2ZXIgcmVzdWx0cyBpbiBhbiBpbnZhbGlkIHZhbHVlIGVycm9yLg0KDQoNCk9LDQoN
Cg0KPiAyKSBvcmlnaW4gZmlsdGVyIGlzIGxpbWl0ZWQgdG8gMSBzb3VyY2UNCj4gICAgVGhpcyBm
aWx0ZXJpbmcgc2VlbXMgcmF0aGVyIGxpbWl0ZWQuICBBIGNsaWVudCBtdXN0IHJldHJpZXZlDQo+
IDx3aXRoLW9yaWdpbj4gYW5kIGNoZWNrDQo+ICAgICBhbGwgdGhlIHZhbHVlcyBpbiB1c2UsIHRo
ZW4gbWFrZSByZXBlYXRlZCByZXF1ZXN0cyBmb3IgZWFjaCBzb3VyY2UgYXMgYQ0KPiBkaWZmZXJl
bnQNCj4gICAgIDxvcmlnaW4tZmlsdGVyPiBsZWFmDQoNCklmIHRoZSBjbGllbnQgZG9lcyA8d2l0
aC1vcmlnaW4+LCB0aGVuIGl0IGhhcyBhbGwgb3JpZ2luIGluZm9ybWF0aW9uDQphbmQgaXQgY2Fu
IGZpbHRlciBsb2NhbGx5LiBUaGF0IHNhaWQsIHdlIGNvdWxkIG1ha2Ugb3JpZ2luLWZpbHRlciBh
DQpsZWFmLWxpc3Qgd2hpY2ggaXMgbG9naWNhbGx5IE9SZWQgc28gdGhhdCBvbmUgY2FuIHJldHJp
ZXZlDQpvcmlnaW4tZmlsdGVyPW9yOnN5c3RlbSBvciBvcmlnaW4tZmlsdGVyPW9yOmxlYXJuZWQg
aW4gb25lIHJlcXVlc3QuDQoNCg0KT0sNCg0KPiAzKSB3aXRoLWRlZmF1bHRzIGJyb2tlbg0KPiAg
ICAgVGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBkb2VzIG5vdCBzdXBwb3J0IHdpdGgtZGVmYXVs
dHMuDQo+ICAgICAgSW5zdGVhZCwgdGhlIGNsaWVudCBtdXN0IHVzZSBvcmlnaW4tZmlsdGVyPW9y
OmRlZmF1bHQgb3Igd2l0aC1vcmlnaW4NCj4gICAgICBhbmQgY2hlY2sgYWxsIHRoZSBvcmlnaW4g
YXR0cmlidXRlcy4gIFNpbmNlIGEgY2xpZW50IG5lZWRzIHRvIHVzZQ0KPiAgICAgIHdpdGgtZGVm
YXVsdHMgZm9yIG90aGVyIGRhdGFzdG9yZXMsIHRoaXMgc3BlY2lhbCBoYW5kbGluZyBvZg0KPiA8
b3BlcmF0aW9uYWw+DQo+ICAgICAgc2VlbXMgdW5oZWxwZnVsLg0KDQpJIHRoaW5rIHRoZSB3aXRo
LWRlZmF1bHRzIHNlbWFudGljcyBmb3IgY29udmVudGlvbmFsIGNvbmZpZ3VyYXRpb24NCmRhdGFz
dG9yZXMgYXJlIG11Y2ggbW9yZSBjb21wbGljYXRlZCB0aGFuIG5lY2Vzc2FyeSBmb3IgdGhlDQpv
cGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuIE5vdGUgdGhhdCB0aGF0IHRoZSBvcGVyYXRpb25h
bCBzdGF0ZQ0KZGF0YXN0b3JlIHJlcG9ydHMgaW4tdXNlIHZhbHVlcyBub3QgcmVhbGx5IGRlZmF1
bHRzOg0KDQogIDxsZWFmIG9yOm9yaWdpbj0nZGVmYXVsdCc+Zm9vPC9sZWFmPg0KDQpUaGlzIHJl
cG9ydHMgdGhhdCB0aGUgdmFsdWUgJ2ZvbycgaXMgaW4gdXNlIGFuZCB0aGF0IGl0IG9yaWdpbmF0
ZXMNCmZyb20gYSBkZWZhdWx0IHZhbHVlLiBOb3RlIHRoYXQgdGhpcyBjb3VsZCBhbHNvIGJlDQoN
CiAgPGxlYWYgb3I6b3JpZ2luPSdpbnRlbmRlZCc+Zm9vPC9sZWFmPg0KDQppbiBjYXNlIHRoZSBp
bnRlbmRlZCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBjb25maWd1cmVkIHRoZSB2YWx1ZQ0KJ2Zv
bycgKGRlc3BpdGUgdGhpcyB2YWx1ZSBtYXRjaGluZyB0aGUgZGVmYXVsdCkuIFRoZSB3aXRoLWRl
ZmF1bHRzDQpzb2x1dGlvbiBpcyBwcmV0dHkgY29tcGxleCBiZWNhdXNlIGl0IHRyaWVzIHRvIGhh
bmRsZSBob3cgZGlmZmVyZW50DQpzeXN0ZW1zIGRlYWwgd2l0aCBjb25maWd1cmF0aW9uIGRlZmF1
bHRzLiBUaGUgaWRlYSBpcyB0byBub3QgY2FycnkNCnRoaXMgY29tcGxleGl0eSBvdmVyIHRvIGlu
LXVzZSB2YWx1ZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlDQpkYXRhc3RvcmUuDQoNCg0KQmVm
b3JlIE5NREEsIHRoZSBjbGllbnQgY291bGQgZGVjaWRlIGlmIGl0IHdhbnRlZCB0byByZXRyaWV2
ZSBkZWZhdWx0IG5vZGVzIG9yIG5vdC4NClRoaXMgY2xpZW50LWNob2ljZSBoYXMgYmVlbiByZW1v
dmVkIGZyb20gTk1EQSwgd2hpY2ggaXMgYSBwcm9ibGVtLg0KV2UgdHJpZWQgdG8gcmVhY2ggYSBz
ZW5zaWJsZSBjb21wcm9taXNlIG9uIHRoZSBkYXRhIHJldHVybmVkIGZyb20gb3BlcmF0aW9uYWwg
KGRlZmluZWQgaW4gc2VjdGlvbiA1LjMgb2YgdGhlIE5NREEgYXJjaGl0ZWN0dXJlKToNCiAtIGl0
IHNob3VsZCByZXR1cm4gZXhwbGljaXQgdmFsdWVzIGZvciBldmVyeXRoaW5nIHRoYXQgaXMgYWZm
ZWN0aW5nIHRoZSBhY3R1YWwgcnVubmluZyBzdGF0ZSBvZiB0aGUgZGV2aWNlIChyZWdhcmRsZXNz
IG9mIHdoZXRoZXIgdGhlIG9wZXJhdGlvbmFsIHZhbHVlIG1hdGNoZXMgYSBzY2hlbWEgZGVmYXVs
dCB2YWx1ZSkuDQogLSBpdCBkb2VzIG5vdCBuZWVkIHRvLCBhbmQgc2hvdWxkIG5vdCwgcmV0dXJu
IG9wZXJhdGlvbmFsIHZhbHVlcyBmb3Igc3R1ZmYgdGhhdCBpc24ndCBhY3R1YWxseSBpbiB1c2Us
IGkuZS4gZG9uJ3QgcmV0dXJuIG5lZWRsZXNzIGFuZCB1bndhbnRlZCBkYXRhLg0KDQpJbiBwYXJ0
aWN1bGFyLCBpZiBubyB2YWx1ZSBpcyByZXR1cm5lZCBmcm9tIGEgcGFydGljdWxhciBkYXRhIG5v
ZGUgaW4gPG9wZXJhdGlvbmFsPiB0aGVuLCBiYXJyaW5nIG1nbXQgcHJvdG9jb2wgZXJyb3JzLCBh
IGNsaWVudCBjYW4gYXNzdW1lIHRoYXQgYW55IGZ1bmN0aW9uYWxpdHkgYXNzb2NpYXRlZCB3aXRo
IHRoYXQgZGF0YSBub2RlIGlzIG9mZiAoaS5lLiBub3QgaW4gdXNlKS4NCg0KU29tZSBleGFtcGxl
cyB0byBpbGx1c3RyYXRlIHRoZSBiZWhhdmlvcjoNCg0KKGkpIElmIGEgcHJvdG9jb2wsIGUuZy4g
T1NQRiwgIGlzIG5vdCBlbmFibGVkL3J1bm5pbmcgdGhlbiA8b3BlcmF0aW9uYWw+IGRvZXMgbm90
IG5lZWQgdG8gcmV0dXJuIGFueSBkYXRhIGZvciBpdC4gIEl0IHdvdWxkIGJlIHJlYXNvbmFibGUg
dG8gcmV0dXJuIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IE9TUEYgaXMgbm90IGVuYWJsZWQvcnVu
bmluZy4NCg0KKGlpKSBJZiB5b3UgaGF2ZSBzb21lIGZ1bmt5IHdpZGdldCBvbiBhbiBpbnRlcmZh
Y2UgdGhhdCBkZWZhdWx0cyB0byBiZWluZyBvZmYgYW5kIGlzbid0IGJlaW5nIHVzZWQgdGhlbiA8
b3BlcmF0aW9uYWw+IGRvbid0IG5lZWQgdG8gcmV0dXJuIGFueSBkYXRhIGZvciBpdC4NCg0KKGlp
aSkgQnV0LCBpZiB5b3UgaGF2ZSBzb21lIGZ1bmt5IHdpZGdldCBvbiBhbiBpbnRlcmZhY2UgdGhh
dCBkZWZhdWx0cyB0byBiZWluZyBvbiwgdGhlbiB0aGUgc2VydmVyIHNob3VsZCByZXR1cm4gZGF0
YSBmb3IgaXQuICBJZiBpdCBpcyBhY3R1YWxseSBlbmFibGVkLCB0aGVuIGl0IHdvdWxkIGluZGlj
YXRlIHRoYXQgaXQgaXMgb24gYW5kIHJldHVybiBhbnkgYXNzb2NpYXRlZCB2YWx1ZXMgd2l0aCBp
dHMgb3BlcmF0aW9uYWwgc3RhdGUsIG9yIGlmIGl0IGlzIGRpc2FibGVkIHRoZW4gaXQgc2hvdWxk
IGV4cGxpY2l0bHkgcmVwb3J0IHRoYXQgaXQgaXMgb2ZmLg0KDQooaXYpIEkgd291bGQgcmVnYXJk
IHRoYXQgYWxsIGFwcGxpZWQgY29uZmlndXJhdGlvbiBpcyAiaW4gdXNlIiBieSB0aGUgc3lzdGVt
LCBldmVuIGlmIGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQgdmFsdWUsIGFuZCBoZW5jZSBpdCBzaG91
bGQgYmUgcmVwb3J0ZWQuDQoNCg0KVGhpcyBiZWhhdmlvciBmb3IgPG9wZXJhdGlvbmFsPiBpcyBv
YnZpb3VzbHkgc2xpZ2h0bHkgZGlmZmVyZW50IGZyb20gdGhlIGV4aXN0aW5nIHdpdGgtZGVmYXVs
dCBoYW5kbGluZyB0aGF0IGlzIHN1cHBvcnRlZCBmb3IgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVz
LiAgQXMgSSByZWNhbGwsIHRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcmVhc29ucyB0aGF0IHdlIGRl
Y2lkZWQgdG8gaGF2ZSBhIGRpZmZlcmVudCBiZWhhdmlvciBmb3IgPG9wZXJhdGlvbmFsPjoNCihh
KSB0byBoYXZlIGNvbnNpc3RlbnQgc2VtYW50aWNzIGZvciBhbGwgc2VydmVycywgcmF0aGVyIHRo
YW4gZGlmZmVyZW50IHNlcnZlcnMgc3VwcG9ydGluZyBkaWZmZXJlbnQgd2l0aC1kZWZhdWx0cyBi
ZWhhdmlvcnMgKHdoaWNoIG1ha2VzIGxpZmUgaGFyZGVyIGZvciBjbGllbnRzIGJlY2F1c2UgdGhl
eSBtdXN0IGNvcGUgd2l0aCBhbGwgdmFyaWFudHMpLg0KKGIpIHRvIHJlbW92ZSBhbnkgcG90ZW50
aWFsIGFtYmlndWl0eSBpZiBkYXRhIGlzbid0IHJldHVybmVkLiAgSS5lLiB3aXRoIHRoZSBleGlz
dGluZyB3aXRoLWRlZmF1bHRzIHNlbWFudGljcyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCBz
ZXJ2ZXJzIHdpbGwgYWx3YXlzIHJldHVybiBhbiBleHBsaWNpdCB2YWx1ZSB0byBpbmRpY2F0ZSB0
aGF0IGEgcGFydGljdWxhciB3aWRnZXQgaXMgb2ZmIGlmIHRoZSBzY2hlbWEgZGVmaW5lcyB0aGF0
IHRoZSBkZWZhdWx0IGl0IHRoYXQgaXMgZW5hYmxlZC4gIElmIHRoZSBzZXJ2ZXIgZG9lc24ndCBz
dXBwb3J0IGEgZ2l2ZW4gd2lkZ2V0IGF0IGFsbCwgaXQgaXMgcXVpdGUgcGxhdXNpYmxlIHRoYXQg
aXQgd2lsbCBqdXN0IHJldHVybiBubyBkYXRhIGZvciBpdC4gIEluIHRoZW9yeSBmZWF0dXJlcy9k
ZXZpYXRpb25zIHNob3VsZCBoYW5kbGUgdGhpcywgYnV0IHRob3NlIGRvbid0IHdvcmsgc28gd2Vs
bCBpZiBkaWZmZXJlbnQgbGluZWNhcmRzIGhhdmUgZGlmZmVyZW50IGNhcGFiaWxpdGllcy4gIEhl
bmNlIGJlaW5nIGV4cGxpY2l0IGFib3V0IHN0dWZmIHRoYXQgaXMgaW4gdXNlIHNlZW1zIG1vcmUg
cm9idXN0Lg0KDQo8ZXJpYz4gVGhlc2UgYXJlIGdvb2QgZXhhbXBsZXMuICBJdCB3b3VsZCBiZSBn
cmVhdCBpZiBzZWN0aW9uIDUuMyBjb3VsZCBiZSB0d2Vha2VkIHRvIG1ha2UgY2xlYXJlciB0aGUg
cmVsYXRpb25zaGlwIGJldHdlZW4gcnVubmluZyBkYXRhc3RvcmUgZGVmYXVsdHMgYW5kIG90aGVy
IG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBkZWZhdWx0cyBmb3IgdGhlIHNhbWUgdHJlZS4NCg0KRm9y
IGV4YW1wbGUsIGxldOKAmXMgc2F5IEkgY3JlYXRlIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24s
IGFuZCB0aGUgZGVmYXVsdCB0cmFuc3BvcnQgcHJvdG9jb2wgaXMgTkVUQ09ORi4gIE5FVENPTkYg
d2lsbCBiZSB1c2VkIGZvciB0aGF0IHN1YnNjcmlwdGlvbiBldmVuIHRob3VnaCB0aGUgbm9kZSBt
aWdodCBub3QgYmUgcG9wdWxhdGVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgb2JqZWN0IHdvdWxkIG5v
dCBhcHBlYXIgaW4gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCBidXQgTVVTVCogYXBwZWFyIGluIHRo
ZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgd2l0aCB0aGUgZGVmYXVsdCBvcmlnaW4gKGFzIGl0IGlz
IGluLXVzZSkuDQoNClRoaXMgdG8gbWUgaXMgdGhlIGRlc2lyZWQgYmVoYXZpb3IgYXMgaXQgZG9l
c27igJl0IGluY29ycmVjdGx5IGFkZCBpbmZvcm1hdGlvbiB0byB0aGUgcnVubmluZyBkYXRhc3Rv
cmUsIGJ1dCBzaG93cyB3aGF0IGlzIGluLXVzZSB3aXRoaW4gb3BlcmF0aW9uYWwuICAgSSBzdXNw
ZWN0IG90aGVyIHN1Y2ggcmVsYXRpb25zaGlwcyBmb3Igb3RoZXIgb3BlcmF0aW9uYWwgdHJlZSBk
ZWZhdWx0cyBjb3VsZCBiZSBhc3NlcnRlZCwgcGVyaGFwcyBiYXNlZCBvbiB0aGUgb3JpZ2luLg0K
DQooKiBNYXliZSDigJhNVVNUIGV2ZW50dWFsbHnigJksIGFzIG9idmlvdXNseSB0aGVyZSBpcyBh
IHRlbXBvcmFsIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0d28gZGF0YXN0b3Jlcy4pDQoNCkVy
aWMNCg0KVGhhbmtzLA0KUm9iDQoNCg0KDQoNCg0KDQovanMNCg0KQW5keQ0KDQotLQ0KSnVlcmdl
biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN
ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy
ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v
d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5l
dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=

--_000_29b8034ef2a94523944d53767e6789beXCHRTP013ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl
eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0
IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJs
YWNrO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQ
cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy
IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y
bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVt
YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn
Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiM1QjlCRDUiPkkgaGF2ZSByZWFkIGFuZCBzdXBwb3J0IHRoZXNlIHR3byBk
cmFmdHMgZ29pbmcgZm9yd2FyZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6IzVCOUJENSI+SSBkbyBoYXZlIG9uZSBhZGRpdGlvbmFsIHRob3VnaHQgYmVsb3cgb24g
ZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzIHNlY3Rpb24gNS4zIGRlZmF1bHQg
aGFuZGxpbmcgcHJvY2Vzcy4mbmJzcDsgU2VlIGluLWxpbmUuLi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVy
dCBXaWx0b24gLVgsIEphbnVhcnkgMzEsIDIwMTggNjozMSBBTTxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD5IaSBBbmR5LDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gMzEvMDEvMjAxOCAwOToyMiwgQW5keSBCaWVybWFuIHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAz
MSwgMjAxOCBhdCAxMjoxMSBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJt
YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFu
ayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij5PbiBUdWUsIEphbiAzMCwgMjAxOCBhdCAxMjozNTozM1BNIC0w
ODAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0
OyBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlc2UgZHJhZnRzLjxicj4NCiZndDs8YnI+
DQomZ3Q7IDEpIHdoYXQgaWYgZGF0YXN0b3JlIHNldCB0byAmcXVvdDtjb252ZW50aW9uYWwmcXVv
dDs/PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlcmUgYXJlIG1hbnkgcGxhY2VzIHdo
ZXJlIGEgZGF0YXN0b3JlLXJlZiB0eXBlIGlzIHVzZWQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7SG93ZXZlciwgJnF1b3Q7Y29udmVudGlvbmFsJnF1b3Q7IGlzIHZhbGlkIGZvciBiYXNl
ICZxdW90O2RhdGFzdG9yZSZxdW90OywgZXZlbiB0aG91Z2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDtpdCBpcyBhbWJpZ3VvdXMgYXMgYSBkYXRhc3RvcmUgc2VsZWN0b3IuPGJyPg0KPGJy
Pg0KV2UgY2FuIGFkZCBleHBsaWNpdCB0ZXh0IHRoYXQgYW4gaWRlbnRpdHkgdGhhdCBkb2VzIG5v
dCByZXNvbHZlIHRvIGE8YnI+DQpkYXRhc3RvcmUgaW1wbGVtZW50ZWQgYnkgdGhlIHNlcnZlciBy
ZXN1bHRzIGluIGFuIGludmFsaWQgdmFsdWUgZXJyb3IuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IDIpIG9yaWdpbiBmaWx0ZXIgaXMgbGltaXRlZCB0byAx
IHNvdXJjZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZmlsdGVyaW5nIHNlZW1zIHJhdGhl
ciBsaW1pdGVkLiZuYnNwOyBBIGNsaWVudCBtdXN0IHJldHJpZXZlPGJyPg0KJmd0OyAmbHQ7d2l0
aC1vcmlnaW4mZ3Q7IGFuZCBjaGVjazxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FsbCB0
aGUgdmFsdWVzIGluIHVzZSwgdGhlbiBtYWtlIHJlcGVhdGVkIHJlcXVlc3RzIGZvciBlYWNoIHNv
dXJjZSBhcyBhPGJyPg0KJmd0OyBkaWZmZXJlbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDsmbHQ7b3JpZ2luLWZpbHRlciZndDsgbGVhZjxicj4NCjxicj4NCklmIHRoZSBjbGllbnQgZG9l
cyAmbHQ7d2l0aC1vcmlnaW4mZ3Q7LCB0aGVuIGl0IGhhcyBhbGwgb3JpZ2luIGluZm9ybWF0aW9u
PGJyPg0KYW5kIGl0IGNhbiBmaWx0ZXIgbG9jYWxseS4gVGhhdCBzYWlkLCB3ZSBjb3VsZCBtYWtl
IG9yaWdpbi1maWx0ZXIgYTxicj4NCmxlYWYtbGlzdCB3aGljaCBpcyBsb2dpY2FsbHkgT1JlZCBz
byB0aGF0IG9uZSBjYW4gcmV0cmlldmU8YnI+DQpvcmlnaW4tZmlsdGVyPW9yOnN5c3RlbSBvciBv
cmlnaW4tZmlsdGVyPW9yOmxlYXJuZWQgaW4gb25lIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAzKSB3aXRoLWRlZmF1bHRzIGJyb2tlbjxicj4N
CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgZG9lcyBu
b3Qgc3VwcG9ydCB3aXRoLWRlZmF1bHRzLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBJ
bnN0ZWFkLCB0aGUgY2xpZW50IG11c3QgdXNlIG9yaWdpbi1maWx0ZXI9b3I6ZGVmYXVsdCBvciB3
aXRoLW9yaWdpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgY2hlY2sgYWxsIHRo
ZSBvcmlnaW4gYXR0cmlidXRlcy4mbmJzcDsgU2luY2UgYSBjbGllbnQgbmVlZHMgdG8gdXNlPGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGgtZGVmYXVsdHMgZm9yIG90aGVyIGRhdGFz
dG9yZXMsIHRoaXMgc3BlY2lhbCBoYW5kbGluZyBvZjxicj4NCiZndDsgJmx0O29wZXJhdGlvbmFs
Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZWVtcyB1bmhlbHBmdWwuPGJyPg0K
PGJyPg0KSSB0aGluayB0aGUgd2l0aC1kZWZhdWx0cyBzZW1hbnRpY3MgZm9yIGNvbnZlbnRpb25h
bCBjb25maWd1cmF0aW9uPGJyPg0KZGF0YXN0b3JlcyBhcmUgbXVjaCBtb3JlIGNvbXBsaWNhdGVk
IHRoYW4gbmVjZXNzYXJ5IGZvciB0aGU8YnI+DQpvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUu
IE5vdGUgdGhhdCB0aGF0IHRoZSBvcGVyYXRpb25hbCBzdGF0ZTxicj4NCmRhdGFzdG9yZSByZXBv
cnRzIGluLXVzZSB2YWx1ZXMgbm90IHJlYWxseSBkZWZhdWx0czo8YnI+DQo8YnI+DQombmJzcDsg
Jmx0O2xlYWYgb3I6b3JpZ2luPSdkZWZhdWx0JyZndDtmb28mbHQ7L2xlYWYmZ3Q7PGJyPg0KPGJy
Pg0KVGhpcyByZXBvcnRzIHRoYXQgdGhlIHZhbHVlICdmb28nIGlzIGluIHVzZSBhbmQgdGhhdCBp
dCBvcmlnaW5hdGVzPGJyPg0KZnJvbSBhIGRlZmF1bHQgdmFsdWUuIE5vdGUgdGhhdCB0aGlzIGNv
dWxkIGFsc28gYmU8YnI+DQo8YnI+DQombmJzcDsgJmx0O2xlYWYgb3I6b3JpZ2luPSdpbnRlbmRl
ZCcmZ3Q7Zm9vJmx0Oy9sZWFmJmd0Ozxicj4NCjxicj4NCmluIGNhc2UgdGhlIGludGVuZGVkIGNv
bmZpZ3VyYXRpb24gZGF0YXN0b3JlIGNvbmZpZ3VyZWQgdGhlIHZhbHVlPGJyPg0KJ2ZvbycgKGRl
c3BpdGUgdGhpcyB2YWx1ZSBtYXRjaGluZyB0aGUgZGVmYXVsdCkuIFRoZSB3aXRoLWRlZmF1bHRz
PGJyPg0Kc29sdXRpb24gaXMgcHJldHR5IGNvbXBsZXggYmVjYXVzZSBpdCB0cmllcyB0byBoYW5k
bGUgaG93IGRpZmZlcmVudDxicj4NCnN5c3RlbXMgZGVhbCB3aXRoIGNvbmZpZ3VyYXRpb24gZGVm
YXVsdHMuIFRoZSBpZGVhIGlzIHRvIG5vdCBjYXJyeTxicj4NCnRoaXMgY29tcGxleGl0eSBvdmVy
IHRvIGluLXVzZSB2YWx1ZXMgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlPGJyPg0KZGF0YXN0b3Jl
LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5CZWZvcmUgTk1EQSwgdGhlIGNsaWVudCBjb3VsZCBkZWNpZGUgaWYgaXQgd2FudGVk
IHRvIHJldHJpZXZlIGRlZmF1bHQgbm9kZXMgb3Igbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBjbGllbnQtY2hvaWNlIGhhcyBiZWVu
IHJlbW92ZWQgZnJvbSBOTURBLCB3aGljaCBpcyBhIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPldlIHRyaWVkIHRvIHJlYWNoIGEg
c2Vuc2libGUgY29tcHJvbWlzZSBvbiB0aGUgZGF0YSByZXR1cm5lZCBmcm9tIG9wZXJhdGlvbmFs
IChkZWZpbmVkIGluIHNlY3Rpb24gNS4zIG9mIHRoZSBOTURBIGFyY2hpdGVjdHVyZSk6PGJyPg0K
Jm5ic3A7LSBpdCBzaG91bGQgcmV0dXJuIGV4cGxpY2l0IHZhbHVlcyBmb3IgZXZlcnl0aGluZyB0
aGF0IGlzIGFmZmVjdGluZyB0aGUgYWN0dWFsIHJ1bm5pbmcgc3RhdGUgb2YgdGhlIGRldmljZSAo
cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBvcGVyYXRpb25hbCB2YWx1ZSBtYXRjaGVzIGEgc2No
ZW1hIGRlZmF1bHQgdmFsdWUpLjxicj4NCiZuYnNwOy0gaXQgZG9lcyBub3QgbmVlZCB0bywgYW5k
IHNob3VsZCBub3QsIHJldHVybiBvcGVyYXRpb25hbCB2YWx1ZXMgZm9yIHN0dWZmIHRoYXQgaXNu
J3QgYWN0dWFsbHkgaW4gdXNlLCBpLmUuIGRvbid0IHJldHVybiBuZWVkbGVzcyBhbmQgdW53YW50
ZWQgZGF0YS48YnI+DQo8YnI+DQpJbiBwYXJ0aWN1bGFyLCBpZiBubyB2YWx1ZSBpcyByZXR1cm5l
ZCBmcm9tIGEgcGFydGljdWxhciBkYXRhIG5vZGUgaW4gJmx0O29wZXJhdGlvbmFsJmd0OyB0aGVu
LCBiYXJyaW5nIG1nbXQgcHJvdG9jb2wgZXJyb3JzLCBhIGNsaWVudCBjYW4gYXNzdW1lIHRoYXQg
YW55IGZ1bmN0aW9uYWxpdHkgYXNzb2NpYXRlZCB3aXRoIHRoYXQgZGF0YSBub2RlIGlzIG9mZiAo
aS5lLiBub3QgaW4gdXNlKS48YnI+DQo8YnI+DQpTb21lIGV4YW1wbGVzIHRvIGlsbHVzdHJhdGUg
dGhlIGJlaGF2aW9yOjxicj4NCjxicj4NCihpKSBJZiBhIHByb3RvY29sLCBlLmcuIE9TUEYsJm5i
c3A7IGlzIG5vdCBlbmFibGVkL3J1bm5pbmcgdGhlbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGRvZXMg
bm90IG5lZWQgdG8gcmV0dXJuIGFueSBkYXRhIGZvciBpdC4mbmJzcDsgSXQgd291bGQgYmUgcmVh
c29uYWJsZSB0byByZXR1cm4gYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgT1NQRiBpcyBub3QgZW5h
YmxlZC9ydW5uaW5nLjxicj4NCjxicj4NCihpaSkgSWYgeW91IGhhdmUgc29tZSBmdW5reSB3aWRn
ZXQgb24gYW4gaW50ZXJmYWNlIHRoYXQgZGVmYXVsdHMgdG8gYmVpbmcgb2ZmIGFuZCBpc24ndCBi
ZWluZyB1c2VkIHRoZW4gJmx0O29wZXJhdGlvbmFsJmd0OyBkb24ndCBuZWVkIHRvIHJldHVybiBh
bnkgZGF0YSBmb3IgaXQuPGJyPg0KPGJyPg0KKGlpaSkgQnV0LCBpZiB5b3UgaGF2ZSBzb21lIGZ1
bmt5IHdpZGdldCBvbiBhbiBpbnRlcmZhY2UgdGhhdCBkZWZhdWx0cyB0byBiZWluZyBvbiwgdGhl
biB0aGUgc2VydmVyIHNob3VsZCByZXR1cm4gZGF0YSBmb3IgaXQuJm5ic3A7IElmIGl0IGlzIGFj
dHVhbGx5IGVuYWJsZWQsIHRoZW4gaXQgd291bGQgaW5kaWNhdGUgdGhhdCBpdCBpcyBvbiBhbmQg
cmV0dXJuIGFueSBhc3NvY2lhdGVkIHZhbHVlcyB3aXRoIGl0cyBvcGVyYXRpb25hbCBzdGF0ZSwg
b3IgaWYNCiBpdCBpcyBkaXNhYmxlZCB0aGVuIGl0IHNob3VsZCBleHBsaWNpdGx5IHJlcG9ydCB0
aGF0IGl0IGlzIG9mZi4gPGJyPg0KPGJyPg0KKGl2KSBJIHdvdWxkIHJlZ2FyZCB0aGF0IGFsbCBh
cHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgJnF1b3Q7aW4gdXNlJnF1b3Q7IGJ5IHRoZSBzeXN0ZW0s
IGV2ZW4gaWYgaXQgbWF0Y2hlcyB0aGUgZGVmYXVsdCB2YWx1ZSwgYW5kIGhlbmNlIGl0IHNob3Vs
ZCBiZSByZXBvcnRlZC48YnI+DQo8YnI+DQo8YnI+DQpUaGlzIGJlaGF2aW9yIGZvciAmbHQ7b3Bl
cmF0aW9uYWwmZ3Q7IGlzIG9idmlvdXNseSBzbGlnaHRseSBkaWZmZXJlbnQgZnJvbSB0aGUgZXhp
c3Rpbmcgd2l0aC1kZWZhdWx0IGhhbmRsaW5nIHRoYXQgaXMgc3VwcG9ydGVkIGZvciBjb25maWd1
cmF0aW9uIGRhdGFzdG9yZXMuJm5ic3A7IEFzIEkgcmVjYWxsLCB0aGVyZSB3ZXJlIGEgY291cGxl
IG9mIHJlYXNvbnMgdGhhdCB3ZSBkZWNpZGVkIHRvIGhhdmUgYSBkaWZmZXJlbnQgYmVoYXZpb3Ig
Zm9yICZsdDtvcGVyYXRpb25hbCZndDs6PGJyPg0KKGEpIHRvIGhhdmUgY29uc2lzdGVudCBzZW1h
bnRpY3MgZm9yIGFsbCBzZXJ2ZXJzLCByYXRoZXIgdGhhbiBkaWZmZXJlbnQgc2VydmVycyBzdXBw
b3J0aW5nIGRpZmZlcmVudCB3aXRoLWRlZmF1bHRzIGJlaGF2aW9ycyAod2hpY2ggbWFrZXMgbGlm
ZSBoYXJkZXIgZm9yIGNsaWVudHMgYmVjYXVzZSB0aGV5IG11c3QgY29wZSB3aXRoIGFsbCB2YXJp
YW50cykuPGJyPg0KKGIpIHRvIHJlbW92ZSBhbnkgcG90ZW50aWFsIGFtYmlndWl0eSBpZiBkYXRh
IGlzbid0IHJldHVybmVkLiZuYnNwOyBJLmUuIHdpdGggdGhlIGV4aXN0aW5nIHdpdGgtZGVmYXVs
dHMgc2VtYW50aWNzIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHNlcnZlcnMgd2lsbCBhbHdh
eXMgcmV0dXJuIGFuIGV4cGxpY2l0IHZhbHVlIHRvIGluZGljYXRlIHRoYXQgYSBwYXJ0aWN1bGFy
IHdpZGdldCBpcyBvZmYgaWYgdGhlIHNjaGVtYSBkZWZpbmVzIHRoYXQgdGhlDQogZGVmYXVsdCBp
dCB0aGF0IGlzIGVuYWJsZWQuJm5ic3A7IElmIHRoZSBzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0IGEg
Z2l2ZW4gd2lkZ2V0IGF0IGFsbCwgaXQgaXMgcXVpdGUgcGxhdXNpYmxlIHRoYXQgaXQgd2lsbCBq
dXN0IHJldHVybiBubyBkYXRhIGZvciBpdC4mbmJzcDsgSW4gdGhlb3J5IGZlYXR1cmVzL2Rldmlh
dGlvbnMgc2hvdWxkIGhhbmRsZSB0aGlzLCBidXQgdGhvc2UgZG9uJ3Qgd29yayBzbyB3ZWxsIGlm
IGRpZmZlcmVudCBsaW5lY2FyZHMgaGF2ZSBkaWZmZXJlbnQNCiBjYXBhYmlsaXRpZXMuJm5ic3A7
IEhlbmNlIGJlaW5nIGV4cGxpY2l0IGFib3V0IHN0dWZmIHRoYXQgaXMgaW4gdXNlIHNlZW1zIG1v
cmUgcm9idXN0LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVCOUJENSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiM1QjlCRDUiPiZsdDtlcmljJmd0OyBUaGVzZSBhcmUgZ29vZCBleGFt
cGxlcy4mbmJzcDsgSXQgd291bGQgYmUgZ3JlYXQgaWYgc2VjdGlvbiA1LjMgY291bGQgYmUgdHdl
YWtlZCB0byBtYWtlIGNsZWFyZXIgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHJ1bm5pbmcgZGF0
YXN0b3JlIGRlZmF1bHRzIGFuZCBvdGhlcg0KIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBkZWZhdWx0
cyBmb3IgdGhlIHNhbWUgdHJlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVCOUJENSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1
QjlCRDUiPkZvciBleGFtcGxlLCBsZXTigJlzIHNheSBJIGNyZWF0ZSBhIGNvbmZpZ3VyZWQgc3Vi
c2NyaXB0aW9uLCBhbmQgdGhlIGRlZmF1bHQgdHJhbnNwb3J0IHByb3RvY29sIGlzIE5FVENPTkYu
Jm5ic3A7IE5FVENPTkYgd2lsbCBiZSB1c2VkIGZvciB0aGF0IHN1YnNjcmlwdGlvbiBldmVuIHRo
b3VnaA0KIHRoZSBub2RlIG1pZ2h0IG5vdCBiZSBwb3B1bGF0ZWQuJm5ic3A7IEluIHRoaXMgY2Fz
ZSwgdGhlIG9iamVjdCB3b3VsZCBub3QgYXBwZWFyIGluIHRoZSBydW5uaW5nIGRhdGFzdG9yZSwg
YnV0IE1VU1QqIGFwcGVhciBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIHdpdGggdGhlIGRl
ZmF1bHQgb3JpZ2luIChhcyBpdCBpcyBpbi11c2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUI5QkQ1Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzVCOUJENSI+VGhpcyB0byBtZSBpcyB0aGUgZGVzaXJlZCBiZWhhdmlvciBhcyBp
dCBkb2VzbuKAmXQgaW5jb3JyZWN0bHkgYWRkIGluZm9ybWF0aW9uIHRvIHRoZSBydW5uaW5nIGRh
dGFzdG9yZSwgYnV0IHNob3dzIHdoYXQgaXMgaW4tdXNlIHdpdGhpbiBvcGVyYXRpb25hbC4mbmJz
cDsmbmJzcDsgSSBzdXNwZWN0DQogb3RoZXIgc3VjaCByZWxhdGlvbnNoaXBzIGZvciBvdGhlciBv
cGVyYXRpb25hbCB0cmVlIGRlZmF1bHRzIGNvdWxkIGJlIGFzc2VydGVkLCBwZXJoYXBzIGJhc2Vk
IG9uIHRoZSBvcmlnaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1QjlCRDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUI5QkQ1
Ij4oKiBNYXliZSDigJhNVVNUIGV2ZW50dWFsbHnigJksIGFzIG9idmlvdXNseSB0aGVyZSBpcyBh
IHRlbXBvcmFsIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0d28gZGF0YXN0b3Jlcy4pPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiM1QjlCRDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUI5QkQ1Ij5FcmljPC9zcGFuPjxicj4NCjxi
cj4NClRoYW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6
Izg4ODg4OCI+L2pzPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56
YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls
ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+SnVlcmdlbiBTY2hv
ZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKYWNvYnMg
VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+
UGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PC9zcGFuPjxicj4NCjxz
cGFuIGNsYXNzPSJob2VuemIiPkZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0MjEgMjAwIDMxMDMm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3
LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmphY29i
cy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0bW9kIG1haWxpbmcg
bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPm5ldG1vZEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_29b8034ef2a94523944d53767e6789beXCHRTP013ciscocom_--


From nobody Wed Jan 31 09:24:26 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 2FC7012EBC5; Wed, 31 Jan 2018 09:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 gUvxOYleO_Jf; Wed, 31 Jan 2018 09:24:16 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9929212EC24; Wed, 31 Jan 2018 09:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33705; q=dns/txt; s=iport; t=1517419454; x=1518629054; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=oZC6SsARx4ALbNS/E2eN5zloffouil5vIdMSqlFclpw=; b=SR1d6aVNBiBcJjzd/AxSWtwHUvbvSf3calJCTPbFuaQFFvppXVnKSRIT isBgrl5zFvN030cNZq1LGzK9DZO33zZQwm/OZ+fnBg7K81ktBM5yvI/rM W0jh+Y0KI6cy9X+x5xfubOzR/DPHN9qBl2oMfjUCv3I77H9v/oaqdg2I1 U=;
X-IronPort-AV: E=Sophos;i="5.46,440,1511827200"; d="scan'208,217";a="1722140"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 17:24:12 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0VHOCsL032654; Wed, 31 Jan 2018 17:24:12 GMT
To: "Eric Voit (evoit)" , Andy Bierman ,  netconf , NETMOD Working Group 
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local>  <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com> <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com>
From: Robert Wilton 
Message-ID: <0b096694-d5e2-4406-b5b2-0813814ddd73@cisco.com>
Date: Wed, 31 Jan 2018 17:24:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com>
Content-Type: multipart/alternative; boundary="------------96FD3EDFC584BFC458676B1C"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 17:24:20 -0000

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

Hi Eric,


On 31/01/2018 16:53, Eric Voit (evoit) wrote:
>
> I have read and support these two drafts going forward.
>
> I do have one additional thought below on 
> draft-ietf-netmod-revised-datastores section 5.3 default handling 
> process.  See in-line...
>
> *From:*Robert Wilton -X, January 31, 2018 6:31 AM
>
> Hi Andy,
>
> On 31/01/2018 09:22, Andy Bierman wrote:
>
>     On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder
>          > wrote:
>
>         On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>         > Hi,
>         >
>         > I have some questions about these drafts.
>         >
>         > 1) what if datastore set to "conventional"?
>         >     There are many places where a datastore-ref type is used.
>         >     However, "conventional" is valid for base "datastore",
>         even though
>         >     it is ambiguous as a datastore selector.
>
>         We can add explicit text that an identity that does not
>         resolve to a
>         datastore implemented by the server results in an invalid
>         value error.
>
>     OK
>
>         > 2) origin filter is limited to 1 source
>         >    This filtering seems rather limited.  A client must retrieve
>         >  and check
>         >     all the values in use, then make repeated requests for
>         each source as a
>         > different
>         >      leaf
>
>         If the client does , then it has all origin
>         information
>         and it can filter locally. That said, we could make
>         origin-filter a
>         leaf-list which is logically ORed so that one can retrieve
>         origin-filter=or:system or origin-filter=or:learned in one
>         request.
>
>     OK
>
>         > 3) with-defaults broken
>         >     The operational datastore does not support with-defaults.
>         >      Instead, the client must use origin-filter=or:default
>         or with-origin
>         >      and check all the origin attributes. Since a client
>         needs to use
>         >      with-defaults for other datastores, this special
>         handling of
>         > 
>         >      seems unhelpful.
>
>         I think the with-defaults semantics for conventional configuration
>         datastores are much more complicated than necessary for the
>         operational state datastore. Note that that the operational state
>         datastore reports in-use values not really defaults:
>
>           foo
>
>         This reports that the value 'foo' is in use and that it originates
>         from a default value. Note that this could also be
>
>           foo
>
>         in case the intended configuration datastore configured the value
>         'foo' (despite this value matching the default). The with-defaults
>         solution is pretty complex because it tries to handle how
>         different
>         systems deal with configuration defaults. The idea is to not carry
>         this complexity over to in-use values in the operational state
>         datastore.
>
>     Before NMDA, the client could decide if it wanted to retrieve
>     default nodes or not.
>
>     This client-choice has been removed from NMDA, which is a problem.
>
> We tried to reach a sensible compromise on the data returned from 
> operational (defined in section 5.3 of the NMDA architecture):
>  - it should return explicit values for everything that is affecting 
> the actual running state of the device (regardless of whether the 
> operational value matches a schema default value).
>  - it does not need to, and should not, return operational values for 
> stuff that isn't actually in use, i.e. don't return needless and 
> unwanted data.
>
> In particular, if no value is returned from a particular data node in 
>  then, barring mgmt protocol errors, a client can assume 
> that any functionality associated with that data node is off (i.e. not 
> in use).
>
> Some examples to illustrate the behavior:
>
> (i) If a protocol, e.g. OSPF,  is not enabled/running then 
>  does not need to return any data for it.  It would be 
> reasonable to return a flag to indicate that OSPF is not enabled/running.
>
> (ii) If you have some funky widget on an interface that defaults to 
> being off and isn't being used then  don't need to return 
> any data for it.
>
> (iii) But, if you have some funky widget on an interface that defaults 
> to being on, then the server should return data for it.  If it is 
> actually enabled, then it would indicate that it is on and return any 
> associated values with its operational state, or if it is disabled 
> then it should explicitly report that it is off.
>
> (iv) I would regard that all applied configuration is "in use" by the 
> system, even if it matches the default value, and hence it should be 
> reported.
>
>
> This behavior for  is obviously slightly different from 
> the existing with-default handling that is supported for configuration 
> datastores.  As I recall, there were a couple of reasons that we 
> decided to have a different behavior for :
> (a) to have consistent semantics for all servers, rather than 
> different servers supporting different with-defaults behaviors (which 
> makes life harder for clients because they must cope with all variants).
> (b) to remove any potential ambiguity if data isn't returned.  I.e. 
> with the existing with-defaults semantics it is not clear to me that 
> servers will always return an explicit value to indicate that a 
> particular widget is off if the schema defines that the default it 
> that is enabled. If the server doesn't support a given widget at all, 
> it is quite plausible that it will just return no data for it.  In 
> theory features/deviations should handle this, but those don't work so 
> well if different linecards have different capabilities.  Hence being 
> explicit about stuff that is in use seems more robust.
>
>  These are good examples.  It would be great if section 5.3 
> could be tweaked to make clearer the relationship between running 
> datastore defaults and other operational datastore defaults for the 
> same tree.
>
I think that the boat has probably sailed on changing 5.3 in the NMDA 
architecture, unless it is done as an erratum.  I'm not sure that this 
is required.  I actually think that FAQs are a good place for these 
sorts of examples, and extra explanatory text.

> For example, let’s say I create a configured subscription, and the 
> default transport protocol is NETCONF.  NETCONF will be used for that 
> subscription even though the node might not be populated.  In this 
> case, the object would not appear in the running datastore, but MUST* 
> appear in the operational datastore with the default origin (as it is 
> in-use).
>
Yes, that is the intended interpretation, although I think that we say 
SHOULD rather than MUST, and give the implementation a bit of leeway in 
choosing what is "in use".

Also, the NMDA definition of the "default" origin is wider than the YANG 
default statement, or "with-defaults" definition.  The NMDA definition 
of the "default" origin is:

          "Denotes configuration that does not have an configured or
           learned value, but has a default value in use.  Covers both
           values defined in a 'default' statement, and values defined
           via an explanation in a 'description' statement.";


The aim of this text is to allow more complex defaults, such as a 
hierarchical default behavior that cannot be expressed using a simple 
"default" statement.

Thanks,
Rob


> This to me is the desired behavior as it doesn’t incorrectly add 
> information to the running datastore, but shows what is in-use within 
> operational.   I suspect other such relationships for other 
> operational tree defaults could be asserted, perhaps based on the origin.
>
> (* Maybe ‘MUST eventually’, as obviously there is a temporal 
> relationship between the two datastores.)
>
> Eric
>
> 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
>


--------------96FD3EDFC584BFC458676B1C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Eric,

    

    

    
On 31/01/2018 16:53, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
I have read
            and support these two drafts going forward. 
            

        
 

        
I do have
            one additional thought below on
            draft-ietf-netmod-revised-datastores section 5.3 default
            handling process.  See in-line...

        
 

        
 

        

          

            

              
From:
                  Robert Wilton -X, January 31, 2018 6:31 AM

                  

                  

            

          

          
Hi Andy,

          
 

          

            
On 31/01/2018 09:22, Andy Bierman
              wrote:

          

          

            

              
 

              

                
 

                

                  
On Wed, Jan 31, 2018 at 12:11 AM,
                    Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
                    wrote:

                  

                    
On
                      Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy
                      Bierman wrote:

                      > Hi,

                      >

                      > I have some questions about these drafts.

                      >

                      > 1) what if datastore set to "conventional"?

                      >     There are many places where a
                      datastore-ref type is used.

                      >     However, "conventional" is valid for base
                      "datastore", even though

                      >     it is ambiguous as a datastore selector.

                      

                      We can add explicit text that an identity that
                      does not resolve to a

                      datastore implemented by the server results in an
                      invalid value error.

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
OK

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
>
                      2) origin filter is limited to 1 source

                      >    This filtering seems rather limited.  A
                      client must retrieve

                      > <with-origin> and check

                      >     all the values in use, then make repeated
                      requests for each source as a

                      > different

                      >     <origin-filter> leaf

                      

                      If the client does <with-origin>, then it
                      has all origin information

                      and it can filter locally. That said, we could
                      make origin-filter a

                      leaf-list which is logically ORed so that one can
                      retrieve

                      origin-filter=or:system or
                      origin-filter=or:learned in one request.

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
OK

                  

                  

                    
 

                  

                  

                    
>
                      3) with-defaults broken

                      >     The operational datastore does not
                      support with-defaults.

                      >      Instead, the client must use
                      origin-filter=or:default or with-origin

                      >      and check all the origin attributes. 
                      Since a client needs to use

                      >      with-defaults for other datastores, this
                      special handling of

                      > <operational>

                      >      seems unhelpful.

                      

                      I think the with-defaults semantics for
                      conventional configuration

                      datastores are much more complicated than
                      necessary for the

                      operational state datastore. Note that that the
                      operational state

                      datastore reports in-use values not really
                      defaults:

                      

                        <leaf or:origin='default'>foo</leaf>

                      

                      This reports that the value 'foo' is in use and
                      that it originates

                      from a default value. Note that this could also be

                      

                        <leaf
                      or:origin='intended'>foo</leaf>

                      

                      in case the intended configuration datastore
                      configured the value

                      'foo' (despite this value matching the default).
                      The with-defaults

                      solution is pretty complex because it tries to
                      handle how different

                      systems deal with configuration defaults. The idea
                      is to not carry

                      this complexity over to in-use values in the
                      operational state

                      datastore.

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
Before NMDA, the client could
                      decide if it wanted to retrieve default nodes or
                      not.

                  

                  

                    
This client-choice has been
                      removed from NMDA, which is a problem.

                  

                

              

            

          

          
We tried to
            reach a sensible compromise on the data returned from
            operational (defined in section 5.3 of the NMDA
            architecture):

             - it should return explicit values for everything that is
            affecting the actual running state of the device (regardless
            of whether the operational value matches a schema default
            value).

             - it does not need to, and should not, return operational
            values for stuff that isn't actually in use, i.e. don't
            return needless and unwanted data.

            

            In particular, if no value is returned from a particular
            data node in <operational> then, barring mgmt protocol
            errors, a client can assume that any functionality
            associated with that data node is off (i.e. not in use).

            

            Some examples to illustrate the behavior:

            

            (i) If a protocol, e.g. OSPF,  is not enabled/running then
            <operational> does not need to return any data for
            it.  It would be reasonable to return a flag to indicate
            that OSPF is not enabled/running.

            

            (ii) If you have some funky widget on an interface that
            defaults to being off and isn't being used then
            <operational> don't need to return any data for it.

            

            (iii) But, if you have some funky widget on an interface
            that defaults to being on, then the server should return
            data for it.  If it is actually enabled, then it would
            indicate that it is on and return any associated values with
            its operational state, or if it is disabled then it should
            explicitly report that it is off. 

            

            (iv) I would regard that all applied configuration is "in
            use" by the system, even if it matches the default value,
            and hence it should be reported.

            

            

            This behavior for <operational> is obviously slightly
            different from the existing with-default handling that is
            supported for configuration datastores.  As I recall, there
            were a couple of reasons that we decided to have a different
            behavior for <operational>:

            (a) to have consistent semantics for all servers, rather
            than different servers supporting different with-defaults
            behaviors (which makes life harder for clients because they
            must cope with all variants).

            (b) to remove any potential ambiguity if data isn't
            returned.  I.e. with the existing with-defaults semantics it
            is not clear to me that servers will always return an
            explicit value to indicate that a particular widget is off
            if the schema defines that the default it that is enabled. 
            If the server doesn't support a given widget at all, it is
            quite plausible that it will just return no data for it.  In
            theory features/deviations should handle this, but those
            don't work so well if different linecards have different
            capabilities.  Hence being explicit about stuff that is in
            use seems more robust.

          
 

          
<eric>
              These are good examples.  It would be great if section 5.3
              could be tweaked to make clearer the relationship between
              running datastore defaults and other operational datastore
              defaults for the same tree.

        

      

    

    I think that the boat has probably sailed on changing 5.3 in the
    NMDA architecture, unless it is done as an erratum.  I'm not sure
    that this is required.  I actually think that FAQs are a good place
    for these sorts of examples, and extra explanatory text.

    

    

      

        

          

          
 

          
For
              example, let’s say I create a configured subscription, and
              the default transport protocol is NETCONF.  NETCONF will
              be used for that subscription even though the node might
              not be populated.  In this case, the object would not
              appear in the running datastore, but MUST* appear in the
              operational datastore with the default origin (as it is
              in-use).

        

      

    

    Yes, that is the intended interpretation, although I think that we
    say SHOULD rather than MUST, and give the implementation a bit of
    leeway in choosing what is "in use".

    

    Also, the NMDA definition of the "default" origin is wider than the
    YANG default statement, or "with-defaults" definition.  The NMDA
    definition of the "default" origin is:

    

    
         "Denotes configuration that does not have an configured or
          learned value, but has a default value in use.  Covers both
          values defined in a 'default' statement, and values defined
          via an explanation in a 'description' statement.";

    

    The aim of this text is to allow more complex defaults, such as a
    hierarchical default behavior that cannot be expressed using a
    simple "default" statement.

    

    Thanks,

    Rob

    

    

    

      

        

          

          
 

          
This
              to me is the desired behavior as it doesn’t incorrectly
              add information to the running datastore, but shows what
              is in-use within operational.   I suspect other such
              relationships for other operational tree defaults could be
              asserted, perhaps based on the origin.

          
 

          
(*
              Maybe ‘MUST eventually’, as obviously there is a temporal
              relationship between the two datastores.)

          
 

          
Eric

            

            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

          

          
 

        

      

    

    

  


--------------96FD3EDFC584BFC458676B1C--


From nobody Wed Jan 31 10:16: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 6F83D12ECA8; Wed, 31 Jan 2018 10:16:30 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 xJPfG_OUsQrA; Wed, 31 Jan 2018 10:16:28 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493AF12EC38; Wed, 31 Jan 2018 10:16:22 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0E7E3FCB; Wed, 31 Jan 2018 19:16:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dhkF0EW1cbpF; Wed, 31 Jan 2018 19:16:20 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 31 Jan 2018 19:16:20 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B956A20151; Wed, 31 Jan 2018 19:16:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zROYOO3F70vA; Wed, 31 Jan 2018 19:16:19 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A39CB20150; Wed, 31 Jan 2018 19:16:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 745D14232A64; Wed, 31 Jan 2018 19:16:19 +0100 (CET)
Date: Wed, 31 Jan 2018 19:16:19 +0100
From: Juergen Schoenwaelder 
To: "Eric Voit (evoit)" 
Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Andy Bierman , netconf , NETMOD Working Group 
Message-ID: <20180131181619.ziqdv5peqdeeuhl4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Eric Voit (evoit)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Andy Bierman , netconf , NETMOD Working Group 
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local>  <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com> <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 18:16:30 -0000

On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:
> 
> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.  See in-line...
>

Well, this document is with the RFC editor now. I do not think it needs
clarification. It already has text in 5.3 such as:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

/js
 
> From: Robert Wilton -X, January 31, 2018 6:31 AM
> 
> 
> Hi Andy,
> 
> On 31/01/2018 09:22, Andy Bierman wrote:
> 
> 
> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder > wrote:
> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> >     There are many places where a datastore-ref type is used.
> >     However, "conventional" is valid for base "datastore", even though
> >     it is ambiguous as a datastore selector.
> 
> We can add explicit text that an identity that does not resolve to a
> datastore implemented by the server results in an invalid value error.
> 
> 
> OK
> 
> 
> > 2) origin filter is limited to 1 source
> >    This filtering seems rather limited.  A client must retrieve
> >  and check
> >     all the values in use, then make repeated requests for each source as a
> > different
> >      leaf
> 
> If the client does , then it has all origin information
> and it can filter locally. That said, we could make origin-filter a
> leaf-list which is logically ORed so that one can retrieve
> origin-filter=or:system or origin-filter=or:learned in one request.
> 
> 
> OK
> 
> > 3) with-defaults broken
> >     The operational datastore does not support with-defaults.
> >      Instead, the client must use origin-filter=or:default or with-origin
> >      and check all the origin attributes.  Since a client needs to use
> >      with-defaults for other datastores, this special handling of
> > 
> >      seems unhelpful.
> 
> I think the with-defaults semantics for conventional configuration
> datastores are much more complicated than necessary for the
> operational state datastore. Note that that the operational state
> datastore reports in-use values not really defaults:
> 
>   foo
> 
> This reports that the value 'foo' is in use and that it originates
> from a default value. Note that this could also be
> 
>   foo
> 
> in case the intended configuration datastore configured the value
> 'foo' (despite this value matching the default). The with-defaults
> solution is pretty complex because it tries to handle how different
> systems deal with configuration defaults. The idea is to not carry
> this complexity over to in-use values in the operational state
> datastore.
> 
> 
> Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
> This client-choice has been removed from NMDA, which is a problem.
> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
>  - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
>  - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data.
> 
> In particular, if no value is returned from a particular data node in  then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).
> 
> Some examples to illustrate the behavior:
> 
> (i) If a protocol, e.g. OSPF,  is not enabled/running then  does not need to return any data for it.  It would be reasonable to return a flag to indicate that OSPF is not enabled/running.
> 
> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then  don't need to return any data for it.
> 
> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it.  If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.
> 
> (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported.
> 
> 
> This behavior for  is obviously slightly different from the existing with-default handling that is supported for configuration datastores.  As I recall, there were a couple of reasons that we decided to have a different behavior for :
> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
> (b) to remove any potential ambiguity if data isn't returned.  I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.  If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it.  In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.  Hence being explicit about stuff that is in use seems more robust.
> 
>  These are good examples.  It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
> 
> For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF.  NETCONF will be used for that subscription even though the node might not be populated.  In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
> 
> This to me is the desired behavior as it doesn’t incorrectly add information to the running datastore, but shows what is in-use within operational.   I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin.
> 
> (* Maybe ‘MUST eventually’, as obviously there is a temporal relationship between the two datastores.)
> 
> Eric
> 
> 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
> 

> _______________________________________________
> 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 Wed Jan 31 12:55:48 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 2F9F6124217; Wed, 31 Jan 2018 12:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 LJFOtqC6-c4q; Wed, 31 Jan 2018 12:55:43 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAF812D962; Wed, 31 Jan 2018 12:55:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42342; q=dns/txt; s=iport; t=1517432143; x=1518641743; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LI7r14TBiKzQ1DCVWaH2iozIackS4C37FifCtJ3Jklk=; b=aChKDZ5yTdDvdALapC9bvxk/NgQEo02eq/YMvXq6rAl5Oc5OgVDR5D79 AwHtDl/0RdCOjwym/qqvdokK9UdrxSElo1eJP8AiW9OfcsnVkW6pygUdB jhyp98CBiJU3HophtNRXraFNkyGYyCsgRuYL9spPqOKXYGVGZ9pvQJnOk c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCXLHJa/4oNJK1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkpHMWZ1KAqDVphQggKXW4F/AwoYAQqESU8CGoI1VxUBAQE?= =?us-ascii?q?BAQEBAQJrKIUjAQEBAwEBASEKQQQMCQICAQgQAgMDDRMBBgMCAgIZDAsUAw4CB?= =?us-ascii?q?AESCBECiTZcCBCoCYInJopEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFhFaCFYF?= =?us-ascii?q?XgWiDLoMvAQECgUUDDwItChURglCCZQWaAoocApVhgiaKOYE/hhiXPAIRGQGBO?= =?us-ascii?q?wE1I4FQcBU9giqCVRyCBniJXYE0gRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,441,1511827200";  d="scan'208,217";a="348520134"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 20:55:42 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w0VKtfxH004262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Jan 2018 20:55:41 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 15:55:40 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 31 Jan 2018 15:55:40 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Andy Bierman , netconf , NETMOD Working Group 
Thread-Topic: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
Thread-Index: AQHTmoc5ksbA2PO8/Em42tqduaeEB6OOIWVQgABt+4D//94zkA==
Date: Wed, 31 Jan 2018 20:55:40 +0000
Message-ID: 
References:    <20180131081118.uqxivaxbkbbzzmji@elstar.local>  <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com> <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <0b096694-d5e2-4406-b5b2-0813814ddd73@cisco.com>
In-Reply-To: <0b096694-d5e2-4406-b5b2-0813814ddd73@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_c79e5ed9375d4a82af53bcb2526b91a4XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 20:55:47 -0000

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

RnJvbTogUm9iZXJ0IFdpbHRvbiwgSmFudWFyeSAzMSwgMjAxOCAxMjoyNCBQTQ0KDQpIaSBFcmlj
LA0KDQpPbiAzMS8wMS8yMDE4IDE2OjUzLCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCg0KSSBo
YXZlIHJlYWQgYW5kIHN1cHBvcnQgdGhlc2UgdHdvIGRyYWZ0cyBnb2luZyBmb3J3YXJkLg0KDQoN
Cg0KSSBkbyBoYXZlIG9uZSBhZGRpdGlvbmFsIHRob3VnaHQgYmVsb3cgb24gZHJhZnQtaWV0Zi1u
ZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzIHNlY3Rpb24gNS4zIGRlZmF1bHQgaGFuZGxpbmcgcHJv
Y2Vzcy4gIFNlZSBpbi1saW5lLi4uDQoNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiAtWCwgSmFudWFy
eSAzMSwgMjAxOCA2OjMxIEFNDQoNCg0KDQpIaSBBbmR5LA0KDQpPbiAzMS8wMS8yMDE4IDA5OjIy
LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQoNCg0KT24gV2VkLCBKYW4gMzEsIDIwMTggYXQgMTI6MTEg
QU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz
aXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90
ZToNCk9uIFR1ZSwgSmFuIDMwLCAyMDE4IGF0IDEyOjM1OjMzUE0gLTA4MDAsIEFuZHkgQmllcm1h
biB3cm90ZToNCj4gSGksDQo+DQo+IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGVzZSBk
cmFmdHMuDQo+DQo+IDEpIHdoYXQgaWYgZGF0YXN0b3JlIHNldCB0byAiY29udmVudGlvbmFsIj8N
Cj4gICAgIFRoZXJlIGFyZSBtYW55IHBsYWNlcyB3aGVyZSBhIGRhdGFzdG9yZS1yZWYgdHlwZSBp
cyB1c2VkLg0KPiAgICAgSG93ZXZlciwgImNvbnZlbnRpb25hbCIgaXMgdmFsaWQgZm9yIGJhc2Ug
ImRhdGFzdG9yZSIsIGV2ZW4gdGhvdWdoDQo+ICAgICBpdCBpcyBhbWJpZ3VvdXMgYXMgYSBkYXRh
c3RvcmUgc2VsZWN0b3IuDQoNCldlIGNhbiBhZGQgZXhwbGljaXQgdGV4dCB0aGF0IGFuIGlkZW50
aXR5IHRoYXQgZG9lcyBub3QgcmVzb2x2ZSB0byBhDQpkYXRhc3RvcmUgaW1wbGVtZW50ZWQgYnkg
dGhlIHNlcnZlciByZXN1bHRzIGluIGFuIGludmFsaWQgdmFsdWUgZXJyb3IuDQoNCg0KT0sNCg0K
DQo+IDIpIG9yaWdpbiBmaWx0ZXIgaXMgbGltaXRlZCB0byAxIHNvdXJjZQ0KPiAgICBUaGlzIGZp
bHRlcmluZyBzZWVtcyByYXRoZXIgbGltaXRlZC4gIEEgY2xpZW50IG11c3QgcmV0cmlldmUNCj4g
PHdpdGgtb3JpZ2luPiBhbmQgY2hlY2sNCj4gICAgIGFsbCB0aGUgdmFsdWVzIGluIHVzZSwgdGhl
biBtYWtlIHJlcGVhdGVkIHJlcXVlc3RzIGZvciBlYWNoIHNvdXJjZSBhcyBhDQo+IGRpZmZlcmVu
dA0KPiAgICAgPG9yaWdpbi1maWx0ZXI+IGxlYWYNCg0KSWYgdGhlIGNsaWVudCBkb2VzIDx3aXRo
LW9yaWdpbj4sIHRoZW4gaXQgaGFzIGFsbCBvcmlnaW4gaW5mb3JtYXRpb24NCmFuZCBpdCBjYW4g
ZmlsdGVyIGxvY2FsbHkuIFRoYXQgc2FpZCwgd2UgY291bGQgbWFrZSBvcmlnaW4tZmlsdGVyIGEN
CmxlYWYtbGlzdCB3aGljaCBpcyBsb2dpY2FsbHkgT1JlZCBzbyB0aGF0IG9uZSBjYW4gcmV0cmll
dmUNCm9yaWdpbi1maWx0ZXI9b3I6c3lzdGVtIG9yIG9yaWdpbi1maWx0ZXI9b3I6bGVhcm5lZCBp
biBvbmUgcmVxdWVzdC4NCg0KDQpPSw0KDQo+IDMpIHdpdGgtZGVmYXVsdHMgYnJva2VuDQo+ICAg
ICBUaGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRvZXMgbm90IHN1cHBvcnQgd2l0aC1kZWZhdWx0
cy4NCj4gICAgICBJbnN0ZWFkLCB0aGUgY2xpZW50IG11c3QgdXNlIG9yaWdpbi1maWx0ZXI9b3I6
ZGVmYXVsdCBvciB3aXRoLW9yaWdpbg0KPiAgICAgIGFuZCBjaGVjayBhbGwgdGhlIG9yaWdpbiBh
dHRyaWJ1dGVzLiAgU2luY2UgYSBjbGllbnQgbmVlZHMgdG8gdXNlDQo+ICAgICAgd2l0aC1kZWZh
dWx0cyBmb3Igb3RoZXIgZGF0YXN0b3JlcywgdGhpcyBzcGVjaWFsIGhhbmRsaW5nIG9mDQo+IDxv
cGVyYXRpb25hbD4NCj4gICAgICBzZWVtcyB1bmhlbHBmdWwuDQoNCkkgdGhpbmsgdGhlIHdpdGgt
ZGVmYXVsdHMgc2VtYW50aWNzIGZvciBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbg0KZGF0YXN0
b3JlcyBhcmUgbXVjaCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gbmVjZXNzYXJ5IGZvciB0aGUNCm9w
ZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZS4gTm90ZSB0aGF0IHRoYXQgdGhlIG9wZXJhdGlvbmFs
IHN0YXRlDQpkYXRhc3RvcmUgcmVwb3J0cyBpbi11c2UgdmFsdWVzIG5vdCByZWFsbHkgZGVmYXVs
dHM6DQoNCiAgPGxlYWYgb3I6b3JpZ2luPSdkZWZhdWx0Jz5mb288L2xlYWY+DQoNClRoaXMgcmVw
b3J0cyB0aGF0IHRoZSB2YWx1ZSAnZm9vJyBpcyBpbiB1c2UgYW5kIHRoYXQgaXQgb3JpZ2luYXRl
cw0KZnJvbSBhIGRlZmF1bHQgdmFsdWUuIE5vdGUgdGhhdCB0aGlzIGNvdWxkIGFsc28gYmUNCg0K
ICA8bGVhZiBvcjpvcmlnaW49J2ludGVuZGVkJz5mb288L2xlYWY+DQoNCmluIGNhc2UgdGhlIGlu
dGVuZGVkIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGNvbmZpZ3VyZWQgdGhlIHZhbHVlDQonZm9v
JyAoZGVzcGl0ZSB0aGlzIHZhbHVlIG1hdGNoaW5nIHRoZSBkZWZhdWx0KS4gVGhlIHdpdGgtZGVm
YXVsdHMNCnNvbHV0aW9uIGlzIHByZXR0eSBjb21wbGV4IGJlY2F1c2UgaXQgdHJpZXMgdG8gaGFu
ZGxlIGhvdyBkaWZmZXJlbnQNCnN5c3RlbXMgZGVhbCB3aXRoIGNvbmZpZ3VyYXRpb24gZGVmYXVs
dHMuIFRoZSBpZGVhIGlzIHRvIG5vdCBjYXJyeQ0KdGhpcyBjb21wbGV4aXR5IG92ZXIgdG8gaW4t
dXNlIHZhbHVlcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUNCmRhdGFzdG9yZS4NCg0KDQpCZWZv
cmUgTk1EQSwgdGhlIGNsaWVudCBjb3VsZCBkZWNpZGUgaWYgaXQgd2FudGVkIHRvIHJldHJpZXZl
IGRlZmF1bHQgbm9kZXMgb3Igbm90Lg0KVGhpcyBjbGllbnQtY2hvaWNlIGhhcyBiZWVuIHJlbW92
ZWQgZnJvbSBOTURBLCB3aGljaCBpcyBhIHByb2JsZW0uDQpXZSB0cmllZCB0byByZWFjaCBhIHNl
bnNpYmxlIGNvbXByb21pc2Ugb24gdGhlIGRhdGEgcmV0dXJuZWQgZnJvbSBvcGVyYXRpb25hbCAo
ZGVmaW5lZCBpbiBzZWN0aW9uIDUuMyBvZiB0aGUgTk1EQSBhcmNoaXRlY3R1cmUpOg0KIC0gaXQg
c2hvdWxkIHJldHVybiBleHBsaWNpdCB2YWx1ZXMgZm9yIGV2ZXJ5dGhpbmcgdGhhdCBpcyBhZmZl
Y3RpbmcgdGhlIGFjdHVhbCBydW5uaW5nIHN0YXRlIG9mIHRoZSBkZXZpY2UgKHJlZ2FyZGxlc3Mg
b2Ygd2hldGhlciB0aGUgb3BlcmF0aW9uYWwgdmFsdWUgbWF0Y2hlcyBhIHNjaGVtYSBkZWZhdWx0
IHZhbHVlKS4NCiAtIGl0IGRvZXMgbm90IG5lZWQgdG8sIGFuZCBzaG91bGQgbm90LCByZXR1cm4g
b3BlcmF0aW9uYWwgdmFsdWVzIGZvciBzdHVmZiB0aGF0IGlzbid0IGFjdHVhbGx5IGluIHVzZSwg
aS5lLiBkb24ndCByZXR1cm4gbmVlZGxlc3MgYW5kIHVud2FudGVkIGRhdGEuDQoNCkluIHBhcnRp
Y3VsYXIsIGlmIG5vIHZhbHVlIGlzIHJldHVybmVkIGZyb20gYSBwYXJ0aWN1bGFyIGRhdGEgbm9k
ZSBpbiA8b3BlcmF0aW9uYWw+IHRoZW4sIGJhcnJpbmcgbWdtdCBwcm90b2NvbCBlcnJvcnMsIGEg
Y2xpZW50IGNhbiBhc3N1bWUgdGhhdCBhbnkgZnVuY3Rpb25hbGl0eSBhc3NvY2lhdGVkIHdpdGgg
dGhhdCBkYXRhIG5vZGUgaXMgb2ZmIChpLmUuIG5vdCBpbiB1c2UpLg0KDQpTb21lIGV4YW1wbGVz
IHRvIGlsbHVzdHJhdGUgdGhlIGJlaGF2aW9yOg0KDQooaSkgSWYgYSBwcm90b2NvbCwgZS5nLiBP
U1BGLCAgaXMgbm90IGVuYWJsZWQvcnVubmluZyB0aGVuIDxvcGVyYXRpb25hbD4gZG9lcyBub3Qg
bmVlZCB0byByZXR1cm4gYW55IGRhdGEgZm9yIGl0LiAgSXQgd291bGQgYmUgcmVhc29uYWJsZSB0
byByZXR1cm4gYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgT1NQRiBpcyBub3QgZW5hYmxlZC9ydW5u
aW5nLg0KDQooaWkpIElmIHlvdSBoYXZlIHNvbWUgZnVua3kgd2lkZ2V0IG9uIGFuIGludGVyZmFj
ZSB0aGF0IGRlZmF1bHRzIHRvIGJlaW5nIG9mZiBhbmQgaXNuJ3QgYmVpbmcgdXNlZCB0aGVuIDxv
cGVyYXRpb25hbD4gZG9uJ3QgbmVlZCB0byByZXR1cm4gYW55IGRhdGEgZm9yIGl0Lg0KDQooaWlp
KSBCdXQsIGlmIHlvdSBoYXZlIHNvbWUgZnVua3kgd2lkZ2V0IG9uIGFuIGludGVyZmFjZSB0aGF0
IGRlZmF1bHRzIHRvIGJlaW5nIG9uLCB0aGVuIHRoZSBzZXJ2ZXIgc2hvdWxkIHJldHVybiBkYXRh
IGZvciBpdC4gIElmIGl0IGlzIGFjdHVhbGx5IGVuYWJsZWQsIHRoZW4gaXQgd291bGQgaW5kaWNh
dGUgdGhhdCBpdCBpcyBvbiBhbmQgcmV0dXJuIGFueSBhc3NvY2lhdGVkIHZhbHVlcyB3aXRoIGl0
cyBvcGVyYXRpb25hbCBzdGF0ZSwgb3IgaWYgaXQgaXMgZGlzYWJsZWQgdGhlbiBpdCBzaG91bGQg
ZXhwbGljaXRseSByZXBvcnQgdGhhdCBpdCBpcyBvZmYuDQoNCihpdikgSSB3b3VsZCByZWdhcmQg
dGhhdCBhbGwgYXBwbGllZCBjb25maWd1cmF0aW9uIGlzICJpbiB1c2UiIGJ5IHRoZSBzeXN0ZW0s
IGV2ZW4gaWYgaXQgbWF0Y2hlcyB0aGUgZGVmYXVsdCB2YWx1ZSwgYW5kIGhlbmNlIGl0IHNob3Vs
ZCBiZSByZXBvcnRlZC4NCg0KDQpUaGlzIGJlaGF2aW9yIGZvciA8b3BlcmF0aW9uYWw+IGlzIG9i
dmlvdXNseSBzbGlnaHRseSBkaWZmZXJlbnQgZnJvbSB0aGUgZXhpc3Rpbmcgd2l0aC1kZWZhdWx0
IGhhbmRsaW5nIHRoYXQgaXMgc3VwcG9ydGVkIGZvciBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMu
ICBBcyBJIHJlY2FsbCwgdGhlcmUgd2VyZSBhIGNvdXBsZSBvZiByZWFzb25zIHRoYXQgd2UgZGVj
aWRlZCB0byBoYXZlIGEgZGlmZmVyZW50IGJlaGF2aW9yIGZvciA8b3BlcmF0aW9uYWw+Og0KKGEp
IHRvIGhhdmUgY29uc2lzdGVudCBzZW1hbnRpY3MgZm9yIGFsbCBzZXJ2ZXJzLCByYXRoZXIgdGhh
biBkaWZmZXJlbnQgc2VydmVycyBzdXBwb3J0aW5nIGRpZmZlcmVudCB3aXRoLWRlZmF1bHRzIGJl
aGF2aW9ycyAod2hpY2ggbWFrZXMgbGlmZSBoYXJkZXIgZm9yIGNsaWVudHMgYmVjYXVzZSB0aGV5
IG11c3QgY29wZSB3aXRoIGFsbCB2YXJpYW50cykuDQooYikgdG8gcmVtb3ZlIGFueSBwb3RlbnRp
YWwgYW1iaWd1aXR5IGlmIGRhdGEgaXNuJ3QgcmV0dXJuZWQuICBJLmUuIHdpdGggdGhlIGV4aXN0
aW5nIHdpdGgtZGVmYXVsdHMgc2VtYW50aWNzIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHNl
cnZlcnMgd2lsbCBhbHdheXMgcmV0dXJuIGFuIGV4cGxpY2l0IHZhbHVlIHRvIGluZGljYXRlIHRo
YXQgYSBwYXJ0aWN1bGFyIHdpZGdldCBpcyBvZmYgaWYgdGhlIHNjaGVtYSBkZWZpbmVzIHRoYXQg
dGhlIGRlZmF1bHQgaXQgdGhhdCBpcyBlbmFibGVkLiAgSWYgdGhlIHNlcnZlciBkb2Vzbid0IHN1
cHBvcnQgYSBnaXZlbiB3aWRnZXQgYXQgYWxsLCBpdCBpcyBxdWl0ZSBwbGF1c2libGUgdGhhdCBp
dCB3aWxsIGp1c3QgcmV0dXJuIG5vIGRhdGEgZm9yIGl0LiAgSW4gdGhlb3J5IGZlYXR1cmVzL2Rl
dmlhdGlvbnMgc2hvdWxkIGhhbmRsZSB0aGlzLCBidXQgdGhvc2UgZG9uJ3Qgd29yayBzbyB3ZWxs
IGlmIGRpZmZlcmVudCBsaW5lY2FyZHMgaGF2ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzLiAgSGVu
Y2UgYmVpbmcgZXhwbGljaXQgYWJvdXQgc3R1ZmYgdGhhdCBpcyBpbiB1c2Ugc2VlbXMgbW9yZSBy
b2J1c3QuDQoNCjxlcmljPiBUaGVzZSBhcmUgZ29vZCBleGFtcGxlcy4gIEl0IHdvdWxkIGJlIGdy
ZWF0IGlmIHNlY3Rpb24gNS4zIGNvdWxkIGJlIHR3ZWFrZWQgdG8gbWFrZSBjbGVhcmVyIHRoZSBy
ZWxhdGlvbnNoaXAgYmV0d2VlbiBydW5uaW5nIGRhdGFzdG9yZSBkZWZhdWx0cyBhbmQgb3RoZXIg
b3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRlZmF1bHRzIGZvciB0aGUgc2FtZSB0cmVlLg0KSSB0aGlu
ayB0aGF0IHRoZSBib2F0IGhhcyBwcm9iYWJseSBzYWlsZWQgb24gY2hhbmdpbmcgNS4zIGluIHRo
ZSBOTURBIGFyY2hpdGVjdHVyZSwgdW5sZXNzIGl0IGlzIGRvbmUgYXMgYW4gZXJyYXR1bS4gIEkn
bSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgcmVxdWlyZWQuICBJIGFjdHVhbGx5IHRoaW5rIHRoYXQg
RkFRcyBhcmUgYSBnb29kIHBsYWNlIGZvciB0aGVzZSBzb3J0cyBvZiBleGFtcGxlcywgYW5kIGV4
dHJhIGV4cGxhbmF0b3J5IHRleHQuDQoNCjxlcmljPiBGQVFzIGFyZSBmaW5lIGNvbnNpZGVyaW5n
IHRoYXQgTk1EQSBBcmNoIGhhcyBnb25lIHRocm91Z2ggV0dMQy4NCg0KDQpGb3IgZXhhbXBsZSwg
bGV04oCZcyBzYXkgSSBjcmVhdGUgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgYW5kIHRoZSBk
ZWZhdWx0IHRyYW5zcG9ydCBwcm90b2NvbCBpcyBORVRDT05GLiAgTkVUQ09ORiB3aWxsIGJlIHVz
ZWQgZm9yIHRoYXQgc3Vic2NyaXB0aW9uIGV2ZW4gdGhvdWdoIHRoZSBub2RlIG1pZ2h0IG5vdCBi
ZSBwb3B1bGF0ZWQuICBJbiB0aGlzIGNhc2UsIHRoZSBvYmplY3Qgd291bGQgbm90IGFwcGVhciBp
biB0aGUgcnVubmluZyBkYXRhc3RvcmUsIGJ1dCBNVVNUKiBhcHBlYXIgaW4gdGhlIG9wZXJhdGlv
bmFsIGRhdGFzdG9yZSB3aXRoIHRoZSBkZWZhdWx0IG9yaWdpbiAoYXMgaXQgaXMgaW4tdXNlKS4N
ClllcywgdGhhdCBpcyB0aGUgaW50ZW5kZWQgaW50ZXJwcmV0YXRpb24sIGFsdGhvdWdoIEkgdGhp
bmsgdGhhdCB3ZSBzYXkgU0hPVUxEIHJhdGhlciB0aGFuIE1VU1QsIGFuZCBnaXZlIHRoZSBpbXBs
ZW1lbnRhdGlvbiBhIGJpdCBvZiBsZWV3YXkgaW4gY2hvb3Npbmcgd2hhdCBpcyAiaW4gdXNlIi4N
Cg0KPGVyaWM+ICBUaGUgcG9pbnQgSSB3YXMgdHJ5aW5nIHRvIGhpZ2hsaWdodCBpcyB0aGF0IHRo
ZXJlIGFyZSBkZWZpbmFibGUgY2F0ZWdvcmllcyBvZiBkZWZhdWx0cyBhbmQgdGhlaXIgaW5zdGFu
dGlhdGlvbiBhY3Jvc3MgdGhlIE5NREEgZGF0YXN0b3Jlcy4gRm9yIGV4YW1wbGUsIHRoZSBjYXNl
IGxpc3RlZCBhYm92ZSBoYXMgYSDigJhjb25maWcgdHJ1ZeKAmSB0cmVlIHdpdGggYSBkZWZhdWx0
IHZhbHVlIHdoaWNoIGlzIG5vdCBwb3B1bGF0ZWQgaW4g4oCYcnVubmluZ+KAmSwgYnV0IFNIT1VM
RCBiZSBwb3B1bGF0ZWQgaW4g4oCYb3BlcmF0aW9uYWzigJkuICAgQmVjYXVzZSBvZiB0aGUgU0hP
VUxELCBpdCB3aWxsIGJlIGhhcmQgdG8gYnVpbGQgcG9ydGFibGUgY3Jvc3MtdmVuZG9yIGFwcGxp
Y2F0aW9ucy4gIEJ1dCB0aGF0IGlzIHdoZXJlIHdlIGFyZSBhdCB0aGlzIHRpbWUuDQoNCkF0IHNv
bWUgZnV0dXJlIHRpbWUsIGltcGxlbWVudGVycyBmb2xsb3dlZCBieSBZQU5HIHVzZXJzLCB3aWxs
IHdhbnQgZ3VpZGFuY2UgKGFuZCBjb25zaXN0ZW5jeSkgYWNyb3NzIHRoaXMgdW5pdmVyc2Ugb2Yg
Y3Jvc3MtZGF0YXN0b3JlIG9iamVjdCBwb3B1bGF0aW9uIHBvc3NpYmlsaXRpZXMuIEFuZCBCVFcg
dGhpcyBndWlkYW5jZSB3aWxsIG5lZWQgdG8gY29uc2lkZXIgdGhlIGNvbXBsZXhpdGllcyBvZiB0
aGUgdGltZSBkaW1lbnNpb24gdG9vLg0KDQpFcmljDQoNCg0KQWxzbywgdGhlIE5NREEgZGVmaW5p
dGlvbiBvZiB0aGUgImRlZmF1bHQiIG9yaWdpbiBpcyB3aWRlciB0aGFuIHRoZSBZQU5HIGRlZmF1
bHQgc3RhdGVtZW50LCBvciAid2l0aC1kZWZhdWx0cyIgZGVmaW5pdGlvbi4gIFRoZSBOTURBIGRl
ZmluaXRpb24gb2YgdGhlICJkZWZhdWx0IiBvcmlnaW4gaXM6DQoNCg0KDQogICAgICAgICAiRGVu
b3RlcyBjb25maWd1cmF0aW9uIHRoYXQgZG9lcyBub3QgaGF2ZSBhbiBjb25maWd1cmVkIG9yDQoN
CiAgICAgICAgICBsZWFybmVkIHZhbHVlLCBidXQgaGFzIGEgZGVmYXVsdCB2YWx1ZSBpbiB1c2Uu
ICBDb3ZlcnMgYm90aA0KDQogICAgICAgICAgdmFsdWVzIGRlZmluZWQgaW4gYSAnZGVmYXVsdCcg
c3RhdGVtZW50LCBhbmQgdmFsdWVzIGRlZmluZWQNCg0KICAgICAgICAgIHZpYSBhbiBleHBsYW5h
dGlvbiBpbiBhICdkZXNjcmlwdGlvbicgc3RhdGVtZW50LiI7DQoNClRoZSBhaW0gb2YgdGhpcyB0
ZXh0IGlzIHRvIGFsbG93IG1vcmUgY29tcGxleCBkZWZhdWx0cywgc3VjaCBhcyBhIGhpZXJhcmNo
aWNhbCBkZWZhdWx0IGJlaGF2aW9yIHRoYXQgY2Fubm90IGJlIGV4cHJlc3NlZCB1c2luZyBhIHNp
bXBsZSAiZGVmYXVsdCIgc3RhdGVtZW50Lg0KDQpUaGFua3MsDQpSb2INCg0KDQoNCg0KVGhpcyB0
byBtZSBpcyB0aGUgZGVzaXJlZCBiZWhhdmlvciBhcyBpdCBkb2VzbuKAmXQgaW5jb3JyZWN0bHkg
YWRkIGluZm9ybWF0aW9uIHRvIHRoZSBydW5uaW5nIGRhdGFzdG9yZSwgYnV0IHNob3dzIHdoYXQg
aXMgaW4tdXNlIHdpdGhpbiBvcGVyYXRpb25hbC4gICBJIHN1c3BlY3Qgb3RoZXIgc3VjaCByZWxh
dGlvbnNoaXBzIGZvciBvdGhlciBvcGVyYXRpb25hbCB0cmVlIGRlZmF1bHRzIGNvdWxkIGJlIGFz
c2VydGVkLCBwZXJoYXBzIGJhc2VkIG9uIHRoZSBvcmlnaW4uDQoNCigqIE1heWJlIOKAmE1VU1Qg
ZXZlbnR1YWxseeKAmSwgYXMgb2J2aW91c2x5IHRoZXJlIGlzIGEgdGVtcG9yYWwgcmVsYXRpb25z
aGlwIGJldHdlZW4gdGhlIHR3byBkYXRhc3RvcmVzLikNCg0KRXJpYw0KDQpUaGFua3MsDQpSb2IN
Cg0KDQoNCg0KDQoNCg0KL2pzDQoNCkFuZHkNCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg
ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAy
MDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpG
YXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVy
c2l0eS5kZS8+DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRmLm9yZzxt
YWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KDQoNCg==

--_000_c79e5ed9375d4a82af53bcb2526b91a4XCHRTP013ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl
eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0
IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn
aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy
DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250
LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy
NQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24sIEphbnVhcnkg
MzEsIDIwMTggMTI6MjQgUE08YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVy
aWMsPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMxLzAxLzIwMTggMTY6NTMsIEVyaWMgVm9pdCAoZXZvaXQp
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij5JIGhhdmUgcmVhZCBhbmQgc3VwcG9ydCB0aGVz
ZSB0d28gZHJhZnRzIGdvaW5nIGZvcndhcmQuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzVCOUJENSI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiM1QjlCRDUiPkkgZG8gaGF2ZSBvbmUgYWRkaXRpb25hbCB0aG91Z2h0IGJl
bG93IG9uIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyBzZWN0aW9uIDUuMyBk
ZWZhdWx0IGhhbmRsaW5nIHByb2Nlc3MuJm5ic3A7IFNlZSBpbi1saW5lLi4uPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k
b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PiBSb2JlcnQgV2lsdG9uIC1YLCBKYW51YXJ5IDMxLCAyMDE4IDY6MzEgQU08YnI+DQo8YnI+DQo8
YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+SGkgQW5keSw8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMxLzAxLzIwMTggMDk6MjIsIEFuZHkg
Qmllcm1hbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gV2VkLCBKYW4gMzEsIDIwMTggYXQgMTI6MTEgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIg
dGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv
dHRvbToxMi4wcHQiPk9uIFR1ZSwgSmFuIDMwLCAyMDE4IGF0IDEyOjM1OjMzUE0gLTA4MDAsIEFu
ZHkgQmllcm1hbiB3cm90ZTo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2
ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGVzZSBkcmFmdHMuPGJyPg0KJmd0Ozxicj4NCiZndDsg
MSkgd2hhdCBpZiBkYXRhc3RvcmUgc2V0IHRvICZxdW90O2NvbnZlbnRpb25hbCZxdW90Oz88YnI+
DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgbWFueSBwbGFjZXMgd2hlcmUgYSBk
YXRhc3RvcmUtcmVmIHR5cGUgaXMgdXNlZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtI
b3dldmVyLCAmcXVvdDtjb252ZW50aW9uYWwmcXVvdDsgaXMgdmFsaWQgZm9yIGJhc2UgJnF1b3Q7
ZGF0YXN0b3JlJnF1b3Q7LCBldmVuIHRob3VnaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw
O2l0IGlzIGFtYmlndW91cyBhcyBhIGRhdGFzdG9yZSBzZWxlY3Rvci48YnI+DQo8YnI+DQpXZSBj
YW4gYWRkIGV4cGxpY2l0IHRleHQgdGhhdCBhbiBpZGVudGl0eSB0aGF0IGRvZXMgbm90IHJlc29s
dmUgdG8gYTxicj4NCmRhdGFzdG9yZSBpbXBsZW1lbnRlZCBieSB0aGUgc2VydmVyIHJlc3VsdHMg
aW4gYW4gaW52YWxpZCB2YWx1ZSBlcnJvci48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IDIp
IG9yaWdpbiBmaWx0ZXIgaXMgbGltaXRlZCB0byAxIHNvdXJjZTxicj4NCiZndDsmbmJzcDsgJm5i
c3A7IFRoaXMgZmlsdGVyaW5nIHNlZW1zIHJhdGhlciBsaW1pdGVkLiZuYnNwOyBBIGNsaWVudCBt
dXN0IHJldHJpZXZlPGJyPg0KJmd0OyAmbHQ7d2l0aC1vcmlnaW4mZ3Q7IGFuZCBjaGVjazxicj4N
CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FsbCB0aGUgdmFsdWVzIGluIHVzZSwgdGhlbiBtYWtl
IHJlcGVhdGVkIHJlcXVlc3RzIGZvciBlYWNoIHNvdXJjZSBhcyBhPGJyPg0KJmd0OyBkaWZmZXJl
bnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7b3JpZ2luLWZpbHRlciZndDsgbGVh
Zjxicj4NCjxicj4NCklmIHRoZSBjbGllbnQgZG9lcyAmbHQ7d2l0aC1vcmlnaW4mZ3Q7LCB0aGVu
IGl0IGhhcyBhbGwgb3JpZ2luIGluZm9ybWF0aW9uPGJyPg0KYW5kIGl0IGNhbiBmaWx0ZXIgbG9j
YWxseS4gVGhhdCBzYWlkLCB3ZSBjb3VsZCBtYWtlIG9yaWdpbi1maWx0ZXIgYTxicj4NCmxlYWYt
bGlzdCB3aGljaCBpcyBsb2dpY2FsbHkgT1JlZCBzbyB0aGF0IG9uZSBjYW4gcmV0cmlldmU8YnI+
DQpvcmlnaW4tZmlsdGVyPW9yOnN5c3RlbSBvciBvcmlnaW4tZmlsdGVyPW9yOmxlYXJuZWQgaW4g
b25lIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9LPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgMykgd2l0aC1kZWZhdWx0cyBi
cm9rZW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgb3BlcmF0aW9uYWwgZGF0YXN0
b3JlIGRvZXMgbm90IHN1cHBvcnQgd2l0aC1kZWZhdWx0cy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgSW5zdGVhZCwgdGhlIGNsaWVudCBtdXN0IHVzZSBvcmlnaW4tZmlsdGVyPW9yOmRl
ZmF1bHQgb3Igd2l0aC1vcmlnaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIGNo
ZWNrIGFsbCB0aGUgb3JpZ2luIGF0dHJpYnV0ZXMuJm5ic3A7IFNpbmNlIGEgY2xpZW50IG5lZWRz
IHRvIHVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoLWRlZmF1bHRzIGZvciBv
dGhlciBkYXRhc3RvcmVzLCB0aGlzIHNwZWNpYWwgaGFuZGxpbmcgb2Y8YnI+DQomZ3Q7ICZsdDtv
cGVyYXRpb25hbCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VlbXMgdW5oZWxw
ZnVsLjxicj4NCjxicj4NCkkgdGhpbmsgdGhlIHdpdGgtZGVmYXVsdHMgc2VtYW50aWNzIGZvciBj
b252ZW50aW9uYWwgY29uZmlndXJhdGlvbjxicj4NCmRhdGFzdG9yZXMgYXJlIG11Y2ggbW9yZSBj
b21wbGljYXRlZCB0aGFuIG5lY2Vzc2FyeSBmb3IgdGhlPGJyPg0Kb3BlcmF0aW9uYWwgc3RhdGUg
ZGF0YXN0b3JlLiBOb3RlIHRoYXQgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGU8YnI+DQpkYXRh
c3RvcmUgcmVwb3J0cyBpbi11c2UgdmFsdWVzIG5vdCByZWFsbHkgZGVmYXVsdHM6PGJyPg0KPGJy
Pg0KJm5ic3A7ICZsdDtsZWFmIG9yOm9yaWdpbj0nZGVmYXVsdCcmZ3Q7Zm9vJmx0Oy9sZWFmJmd0
Ozxicj4NCjxicj4NClRoaXMgcmVwb3J0cyB0aGF0IHRoZSB2YWx1ZSAnZm9vJyBpcyBpbiB1c2Ug
YW5kIHRoYXQgaXQgb3JpZ2luYXRlczxicj4NCmZyb20gYSBkZWZhdWx0IHZhbHVlLiBOb3RlIHRo
YXQgdGhpcyBjb3VsZCBhbHNvIGJlPGJyPg0KPGJyPg0KJm5ic3A7ICZsdDtsZWFmIG9yOm9yaWdp
bj0naW50ZW5kZWQnJmd0O2ZvbyZsdDsvbGVhZiZndDs8YnI+DQo8YnI+DQppbiBjYXNlIHRoZSBp
bnRlbmRlZCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBjb25maWd1cmVkIHRoZSB2YWx1ZTxicj4N
Cidmb28nIChkZXNwaXRlIHRoaXMgdmFsdWUgbWF0Y2hpbmcgdGhlIGRlZmF1bHQpLiBUaGUgd2l0
aC1kZWZhdWx0czxicj4NCnNvbHV0aW9uIGlzIHByZXR0eSBjb21wbGV4IGJlY2F1c2UgaXQgdHJp
ZXMgdG8gaGFuZGxlIGhvdyBkaWZmZXJlbnQ8YnI+DQpzeXN0ZW1zIGRlYWwgd2l0aCBjb25maWd1
cmF0aW9uIGRlZmF1bHRzLiBUaGUgaWRlYSBpcyB0byBub3QgY2Fycnk8YnI+DQp0aGlzIGNvbXBs
ZXhpdHkgb3ZlciB0byBpbi11c2UgdmFsdWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZTxicj4N
CmRhdGFzdG9yZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QmVmb3JlIE5NREEsIHRoZSBjbGllbnQgY291bGQgZGVjaWRlIGlm
IGl0IHdhbnRlZCB0byByZXRyaWV2ZSBkZWZhdWx0IG5vZGVzIG9yIG5vdC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgY2xpZW50LWNob2lj
ZSBoYXMgYmVlbiByZW1vdmVkIGZyb20gTk1EQSwgd2hpY2ggaXMgYSBwcm9ibGVtLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij5XZSB0cmllZCB0
byByZWFjaCBhIHNlbnNpYmxlIGNvbXByb21pc2Ugb24gdGhlIGRhdGEgcmV0dXJuZWQgZnJvbSBv
cGVyYXRpb25hbCAoZGVmaW5lZCBpbiBzZWN0aW9uIDUuMyBvZiB0aGUgTk1EQSBhcmNoaXRlY3R1
cmUpOjxicj4NCiZuYnNwOy0gaXQgc2hvdWxkIHJldHVybiBleHBsaWNpdCB2YWx1ZXMgZm9yIGV2
ZXJ5dGhpbmcgdGhhdCBpcyBhZmZlY3RpbmcgdGhlIGFjdHVhbCBydW5uaW5nIHN0YXRlIG9mIHRo
ZSBkZXZpY2UgKHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgb3BlcmF0aW9uYWwgdmFsdWUgbWF0
Y2hlcyBhIHNjaGVtYSBkZWZhdWx0IHZhbHVlKS48YnI+DQombmJzcDstIGl0IGRvZXMgbm90IG5l
ZWQgdG8sIGFuZCBzaG91bGQgbm90LCByZXR1cm4gb3BlcmF0aW9uYWwgdmFsdWVzIGZvciBzdHVm
ZiB0aGF0IGlzbid0IGFjdHVhbGx5IGluIHVzZSwgaS5lLiBkb24ndCByZXR1cm4gbmVlZGxlc3Mg
YW5kIHVud2FudGVkIGRhdGEuPGJyPg0KPGJyPg0KSW4gcGFydGljdWxhciwgaWYgbm8gdmFsdWUg
aXMgcmV0dXJuZWQgZnJvbSBhIHBhcnRpY3VsYXIgZGF0YSBub2RlIGluICZsdDtvcGVyYXRpb25h
bCZndDsgdGhlbiwgYmFycmluZyBtZ210IHByb3RvY29sIGVycm9ycywgYSBjbGllbnQgY2FuIGFz
c3VtZSB0aGF0IGFueSBmdW5jdGlvbmFsaXR5IGFzc29jaWF0ZWQgd2l0aCB0aGF0IGRhdGEgbm9k
ZSBpcyBvZmYgKGkuZS4gbm90IGluIHVzZSkuPGJyPg0KPGJyPg0KU29tZSBleGFtcGxlcyB0byBp
bGx1c3RyYXRlIHRoZSBiZWhhdmlvcjo8YnI+DQo8YnI+DQooaSkgSWYgYSBwcm90b2NvbCwgZS5n
LiBPU1BGLCZuYnNwOyBpcyBub3QgZW5hYmxlZC9ydW5uaW5nIHRoZW4gJmx0O29wZXJhdGlvbmFs
Jmd0OyBkb2VzIG5vdCBuZWVkIHRvIHJldHVybiBhbnkgZGF0YSBmb3IgaXQuJm5ic3A7IEl0IHdv
dWxkIGJlIHJlYXNvbmFibGUgdG8gcmV0dXJuIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IE9TUEYg
aXMgbm90IGVuYWJsZWQvcnVubmluZy48YnI+DQo8YnI+DQooaWkpIElmIHlvdSBoYXZlIHNvbWUg
ZnVua3kgd2lkZ2V0IG9uIGFuIGludGVyZmFjZSB0aGF0IGRlZmF1bHRzIHRvIGJlaW5nIG9mZiBh
bmQgaXNuJ3QgYmVpbmcgdXNlZCB0aGVuICZsdDtvcGVyYXRpb25hbCZndDsgZG9uJ3QgbmVlZCB0
byByZXR1cm4gYW55IGRhdGEgZm9yIGl0Ljxicj4NCjxicj4NCihpaWkpIEJ1dCwgaWYgeW91IGhh
dmUgc29tZSBmdW5reSB3aWRnZXQgb24gYW4gaW50ZXJmYWNlIHRoYXQgZGVmYXVsdHMgdG8gYmVp
bmcgb24sIHRoZW4gdGhlIHNlcnZlciBzaG91bGQgcmV0dXJuIGRhdGEgZm9yIGl0LiZuYnNwOyBJ
ZiBpdCBpcyBhY3R1YWxseSBlbmFibGVkLCB0aGVuIGl0IHdvdWxkIGluZGljYXRlIHRoYXQgaXQg
aXMgb24gYW5kIHJldHVybiBhbnkgYXNzb2NpYXRlZCB2YWx1ZXMgd2l0aCBpdHMgb3BlcmF0aW9u
YWwgc3RhdGUsIG9yIGlmDQogaXQgaXMgZGlzYWJsZWQgdGhlbiBpdCBzaG91bGQgZXhwbGljaXRs
eSByZXBvcnQgdGhhdCBpdCBpcyBvZmYuIDxicj4NCjxicj4NCihpdikgSSB3b3VsZCByZWdhcmQg
dGhhdCBhbGwgYXBwbGllZCBjb25maWd1cmF0aW9uIGlzICZxdW90O2luIHVzZSZxdW90OyBieSB0
aGUgc3lzdGVtLCBldmVuIGlmIGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQgdmFsdWUsIGFuZCBoZW5j
ZSBpdCBzaG91bGQgYmUgcmVwb3J0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KVGhpcyBiZWhhdmlvciBm
b3IgJmx0O29wZXJhdGlvbmFsJmd0OyBpcyBvYnZpb3VzbHkgc2xpZ2h0bHkgZGlmZmVyZW50IGZy
b20gdGhlIGV4aXN0aW5nIHdpdGgtZGVmYXVsdCBoYW5kbGluZyB0aGF0IGlzIHN1cHBvcnRlZCBm
b3IgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiZuYnNwOyBBcyBJIHJlY2FsbCwgdGhlcmUgd2Vy
ZSBhIGNvdXBsZSBvZiByZWFzb25zIHRoYXQgd2UgZGVjaWRlZCB0byBoYXZlIGEgZGlmZmVyZW50
IGJlaGF2aW9yIGZvciAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Ojxicj4NCihhKSB0byBoYXZlIGNvbnNp
c3RlbnQgc2VtYW50aWNzIGZvciBhbGwgc2VydmVycywgcmF0aGVyIHRoYW4gZGlmZmVyZW50IHNl
cnZlcnMgc3VwcG9ydGluZyBkaWZmZXJlbnQgd2l0aC1kZWZhdWx0cyBiZWhhdmlvcnMgKHdoaWNo
IG1ha2VzIGxpZmUgaGFyZGVyIGZvciBjbGllbnRzIGJlY2F1c2UgdGhleSBtdXN0IGNvcGUgd2l0
aCBhbGwgdmFyaWFudHMpLjxicj4NCihiKSB0byByZW1vdmUgYW55IHBvdGVudGlhbCBhbWJpZ3Vp
dHkgaWYgZGF0YSBpc24ndCByZXR1cm5lZC4mbmJzcDsgSS5lLiB3aXRoIHRoZSBleGlzdGluZyB3
aXRoLWRlZmF1bHRzIHNlbWFudGljcyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCBzZXJ2ZXJz
IHdpbGwgYWx3YXlzIHJldHVybiBhbiBleHBsaWNpdCB2YWx1ZSB0byBpbmRpY2F0ZSB0aGF0IGEg
cGFydGljdWxhciB3aWRnZXQgaXMgb2ZmIGlmIHRoZSBzY2hlbWEgZGVmaW5lcyB0aGF0IHRoZQ0K
IGRlZmF1bHQgaXQgdGhhdCBpcyBlbmFibGVkLiZuYnNwOyBJZiB0aGUgc2VydmVyIGRvZXNuJ3Qg
c3VwcG9ydCBhIGdpdmVuIHdpZGdldCBhdCBhbGwsIGl0IGlzIHF1aXRlIHBsYXVzaWJsZSB0aGF0
IGl0IHdpbGwganVzdCByZXR1cm4gbm8gZGF0YSBmb3IgaXQuJm5ic3A7IEluIHRoZW9yeSBmZWF0
dXJlcy9kZXZpYXRpb25zIHNob3VsZCBoYW5kbGUgdGhpcywgYnV0IHRob3NlIGRvbid0IHdvcmsg
c28gd2VsbCBpZiBkaWZmZXJlbnQgbGluZWNhcmRzIGhhdmUgZGlmZmVyZW50DQogY2FwYWJpbGl0
aWVzLiZuYnNwOyBIZW5jZSBiZWluZyBleHBsaWNpdCBhYm91dCBzdHVmZiB0aGF0IGlzIGluIHVz
ZSBzZWVtcyBtb3JlIHJvYnVzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUI5QkQ1Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVCOUJENSI+
Jmx0O2VyaWMmZ3Q7IFRoZXNlIGFyZSBnb29kIGV4YW1wbGVzLiZuYnNwOyBJdCB3b3VsZCBiZSBn
cmVhdCBpZiBzZWN0aW9uIDUuMyBjb3VsZCBiZSB0d2Vha2VkIHRvIG1ha2UgY2xlYXJlciB0aGUg
cmVsYXRpb25zaGlwIGJldHdlZW4gcnVubmluZyBkYXRhc3RvcmUgZGVmYXVsdHMgYW5kIG90aGVy
DQogb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRlZmF1bHRzIGZvciB0aGUgc2FtZSB0cmVlLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSB0aGluayB0aGF0IHRoZSBib2F0IGhhcyBwcm9iYWJseSBzYWlsZWQgb24gY2hhbmdp
bmcgNS4zIGluIHRoZSBOTURBIGFyY2hpdGVjdHVyZSwgdW5sZXNzIGl0IGlzIGRvbmUgYXMgYW4g
ZXJyYXR1bS4mbmJzcDsgSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyByZXF1aXJlZC4mbmJzcDsg
SSBhY3R1YWxseSB0aGluayB0aGF0IEZBUXMgYXJlIGEgZ29vZCBwbGFjZSBmb3IgdGhlc2Ugc29y
dHMgb2YgZXhhbXBsZXMsIGFuZCBleHRyYQ0KIGV4cGxhbmF0b3J5IHRleHQuPHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+Jmx0O2VyaWMmZ3Q7IEZBUXMgYXJlIGZpbmUgY29uc2lkZXJpbmcgdGhhdCBOTURBIEFyY2gg
aGFzIGdvbmUgdGhyb3VnaCBXR0xDLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp
biA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVC
OUJENSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1QjlCRDUiPkZvciBleGFtcGxlLCBsZXTigJlzIHNheSBJ
IGNyZWF0ZSBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLCBhbmQgdGhlIGRlZmF1bHQgdHJhbnNw
b3J0IHByb3RvY29sIGlzIE5FVENPTkYuJm5ic3A7IE5FVENPTkYgd2lsbCBiZSB1c2VkIGZvciB0
aGF0IHN1YnNjcmlwdGlvbiBldmVuIHRob3VnaA0KIHRoZSBub2RlIG1pZ2h0IG5vdCBiZSBwb3B1
bGF0ZWQuJm5ic3A7IEluIHRoaXMgY2FzZSwgdGhlIG9iamVjdCB3b3VsZCBub3QgYXBwZWFyIGlu
IHRoZSBydW5uaW5nIGRhdGFzdG9yZSwgYnV0IE1VU1QqIGFwcGVhciBpbiB0aGUgb3BlcmF0aW9u
YWwgZGF0YXN0b3JlIHdpdGggdGhlIGRlZmF1bHQgb3JpZ2luIChhcyBpdCBpcyBpbi11c2UpLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+WWVzLCB0aGF0IGlzIHRoZSBpbnRlbmRlZCBpbnRlcnByZXRhdGlvbiwgYWx0aG91
Z2ggSSB0aGluayB0aGF0IHdlIHNheSBTSE9VTEQgcmF0aGVyIHRoYW4gTVVTVCwgYW5kIGdpdmUg
dGhlIGltcGxlbWVudGF0aW9uIGEgYml0IG9mIGxlZXdheSBpbiBjaG9vc2luZyB3aGF0IGlzICZx
dW90O2luIHVzZSZxdW90Oy48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7ZXJpYyZndDsgJm5ic3A7VGhlIHBv
aW50IEkgd2FzIHRyeWluZyB0byBoaWdobGlnaHQgaXMgdGhhdCB0aGVyZSBhcmUgZGVmaW5hYmxl
IGNhdGVnb3JpZXMgb2YgZGVmYXVsdHMgYW5kIHRoZWlyIGluc3RhbnRpYXRpb24gYWNyb3NzIHRo
ZSBOTURBIGRhdGFzdG9yZXMuIEZvciBleGFtcGxlLA0KIHRoZSBjYXNlIGxpc3RlZCBhYm92ZSBo
YXMgYSDigJhjb25maWcgdHJ1ZeKAmSB0cmVlIHdpdGggYSBkZWZhdWx0IHZhbHVlIHdoaWNoIGlz
IG5vdCBwb3B1bGF0ZWQgaW4g4oCYcnVubmluZ+KAmSwgYnV0IFNIT1VMRCBiZSBwb3B1bGF0ZWQg
aW4g4oCYb3BlcmF0aW9uYWzigJkuICZuYnNwOyZuYnNwO0JlY2F1c2Ugb2YgdGhlIFNIT1VMRCwg
aXQgd2lsbCBiZSBoYXJkIHRvIGJ1aWxkIHBvcnRhYmxlIGNyb3NzLXZlbmRvciBhcHBsaWNhdGlv
bnMuJm5ic3A7IEJ1dCB0aGF0IGlzIHdoZXJlIHdlIGFyZQ0KIGF0IHRoaXMgdGltZS4mbmJzcDsg
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BdCBzb21lIGZ1dHVy
ZSB0aW1lLCBpbXBsZW1lbnRlcnMgZm9sbG93ZWQgYnkgWUFORyB1c2Vycywgd2lsbCB3YW50IGd1
aWRhbmNlIChhbmQgY29uc2lzdGVuY3kpIGFjcm9zcyB0aGlzIHVuaXZlcnNlIG9mIGNyb3NzLWRh
dGFzdG9yZSBvYmplY3QgcG9wdWxhdGlvbiBwb3NzaWJpbGl0aWVzLg0KIEFuZCBCVFcgdGhpcyBn
dWlkYW5jZSB3aWxsIG5lZWQgdG8gY29uc2lkZXIgdGhlIGNvbXBsZXhpdGllcyBvZiB0aGUgdGlt
ZSBkaW1lbnNpb24gdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCkFsc28sIHRoZSBOTURBIGRlZmluaXRpb24gb2YgdGhlICZxdW90O2RlZmF1bHQmcXVv
dDsgb3JpZ2luIGlzIHdpZGVyIHRoYW4gdGhlIFlBTkcgZGVmYXVsdCBzdGF0ZW1lbnQsIG9yICZx
dW90O3dpdGgtZGVmYXVsdHMmcXVvdDsgZGVmaW5pdGlvbi4mbmJzcDsgVGhlIE5NREEgZGVmaW5p
dGlvbiBvZiB0aGUgJnF1b3Q7ZGVmYXVsdCZxdW90OyBvcmlnaW4gaXM6PGJyPg0KPGJyPg0KPGJy
Pg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1k
aXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4
LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk
ZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RGVub3RlcyBjb25maWd1cmF0
aW9uIHRoYXQgZG9lcyBub3QgaGF2ZSBhbiBjb25maWd1cmVkIG9yPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG
NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFybmVkIHZhbHVlLCBidXQgaGFzIGEgZGVmYXVsdCB2YWx1
ZSBpbiB1c2UuJm5ic3A7IENvdmVycyBib3RoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr
OmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB2YWx1ZXMgZGVmaW5lZCBpbiBhICdkZWZhdWx0JyBzdGF0ZW1lbnQsIGFuZCB2YWx1
ZXMgZGVmaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv
dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVy
Om5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmlhIGFuIGV4
cGxhbmF0aW9uIGluIGEgJ2Rlc2NyaXB0aW9uJyBzdGF0ZW1lbnQuJnF1b3Q7OzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgYWlt
IG9mIHRoaXMgdGV4dCBpcyB0byBhbGxvdyBtb3JlIGNvbXBsZXggZGVmYXVsdHMsIHN1Y2ggYXMg
YSBoaWVyYXJjaGljYWwgZGVmYXVsdCBiZWhhdmlvciB0aGF0IGNhbm5vdCBiZSBleHByZXNzZWQg
dXNpbmcgYSBzaW1wbGUgJnF1b3Q7ZGVmYXVsdCZxdW90OyBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0K
VGhhbmtzLDxicj4NClJvYjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiM1QjlCRDUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUI5QkQ1Ij5UaGlzIHRvIG1l
IGlzIHRoZSBkZXNpcmVkIGJlaGF2aW9yIGFzIGl0IGRvZXNu4oCZdCBpbmNvcnJlY3RseSBhZGQg
aW5mb3JtYXRpb24gdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCBidXQgc2hvd3Mgd2hhdCBpcyBp
bi11c2Ugd2l0aGluIG9wZXJhdGlvbmFsLiZuYnNwOyZuYnNwOyBJIHN1c3BlY3QNCiBvdGhlciBz
dWNoIHJlbGF0aW9uc2hpcHMgZm9yIG90aGVyIG9wZXJhdGlvbmFsIHRyZWUgZGVmYXVsdHMgY291
bGQgYmUgYXNzZXJ0ZWQsIHBlcmhhcHMgYmFzZWQgb24gdGhlIG9yaWdpbi48L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVC
OUJENSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1QjlCRDUiPigqIE1heWJlIOKAmE1VU1QgZXZlbnR1YWxs
eeKAmSwgYXMgb2J2aW91c2x5IHRoZXJlIGlzIGEgdGVtcG9yYWwgcmVsYXRpb25zaGlwIGJldHdl
ZW4gdGhlIHR3byBkYXRhc3RvcmVzLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVCOUJENSI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiM1QjlCRDUiPkVyaWM8L3NwYW4+PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxi
cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw
YW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi9qczwvc3Bhbj48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS08L3NwYW4+
PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9l
bnpiIj5KdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDwvc3Bhbj48YnI+DQo8c3Bh
biBjbGFzcz0iaG9lbnpiIj5QaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1h
bnk8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RmF4OiZuYnNwOyAmbmJzcDsmIzQz
OzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEg
aHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8L3NwYW4+PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5uZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl
Zj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_c79e5ed9375d4a82af53bcb2526b91a4XCHRTP013ciscocom_--


From nobody Wed Jan 31 13:36: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 062CD12D838 for ; Wed, 31 Jan 2018 13:36:13 -0800 (PST)
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 o55D_qhZQB5c for ; Wed, 31 Jan 2018 13:36:11 -0800 (PST)
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 E440E126CD6 for ; Wed, 31 Jan 2018 13:36:10 -0800 (PST)
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 w0VLXlM1002743 for ; Wed, 31 Jan 2018 13:36:10 -0800
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=CFL9wqAcCmiJmVKcvs4EhjxqUV+ObE7jhnYLyycUQ+4=; b=mopFO1U/QjSKzFfAyOq0hjzAClImySxhq+k5zwO0Lo8/lKdPLnEPVkbiXn/2Fe/j4Rk3 w+l8XWsYE7oeA3UbXiQd+Aifzd99jl4grKzd83HipodUo/nCsmRQ4i1QrpZRINKNyLPi C5LrA0qQgEvv3S0kcNzhH22iXp/md6nCQgjwM2yxmFAqc/HDqPOPHzjbE1m9cu8bEhTk GgCfF707YJoyCNL/8xBjCMGOnwylCFPTODKMDPrliftfl/qt5Jp8fzp79aJpDKjwY7Hh S8gss62vVg+bspB3j1znk/s+jBK2bXJezWVs3gf6Rdb6n0jrsNHDa893w20FAbqpsTwr Yw== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0b-00273201.pphosted.com with ESMTP id 2funcur2vu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jan 2018 13:36:10 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3114.namprd05.prod.outlook.com (10.173.219.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 31 Jan 2018 21:36:07 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.012; Wed, 31 Jan 2018 21:36:07 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: schema-mount pre09 branch
Thread-Index: AQHTmtuBvJr0HeYRT0idzYLw7Rs9mA==
Date: Wed, 31 Jan 2018 21:36:07 +0000
Message-ID: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net>
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; DM5PR05MB3114; 7:yTdcyU0QNNX+e9I+isGKoxfk7uc52zRf33Uig6zyRqjTNMHlRIgl1asc30xvqMxCd4UtLXBHI2sBwJwAin82T6Ske5vI3WvfOtbmNTTrHNNpMa94T1DaLgtiT0lEbZfnOvAmM5Ho+8t0Na0I2QAfTCuvszQ7VSd95jPidaAPSq0ov6UR5By4vyYPnvs4Jywl5mJLWZD+ilfqAGA/8uYdZ1al3BR4fVJmFm+9NroOnprJ/0k/rrOV9ncrz9aQ9ko6
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3864ccea-d1ea-4c7a-fc0e-08d568f2a3a4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3114; 
x-ms-traffictypediagnostic: DM5PR05MB3114:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(275740015457677);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3114; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3114; 
x-forefront-prvs: 056929CBB8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(366004)(346002)(376002)(199004)(189003)(966005)(8676002)(81166006)(1730700003)(81156014)(53936002)(102836004)(33656002)(2501003)(106356001)(36756003)(26005)(6486002)(6306002)(83506002)(6512007)(99286004)(105586002)(82746002)(6116002)(3846002)(2351001)(316002)(2900100001)(66066001)(14454004)(58126008)(25786009)(305945005)(97736004)(186003)(5640700003)(83716003)(6916009)(7736002)(478600001)(6506007)(6436002)(3280700002)(3660700001)(77096007)(2906002)(59450400001)(68736007)(86362001)(5660300001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3114; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4lK5zDsxQJs0xn8c/WuMuVivK35Zr43iwjmSq6WH/IN6x9ZD9gYAV8ilNLRL8aN16DwE743SHltMMRRvXdCIUQ==
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: 3864ccea-d1ea-4c7a-fc0e-08d568f2a3a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2018 21:36:07.9353 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3114
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310269
Archived-At: 
Subject: [netmod] schema-mount pre09 branch
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 21:36:13 -0000

QWxsLA0KDQpUaGUgYXV0aG9ycyBjcmVhdGVkIGEgInByZTA5IiBicmFuY2ggb24gR2l0SHViIGEg
ZmV3IHdlZWtzIGJhY2suICBPbiB0aGlzIGJyYW5jaCwgdGhleSBjb21wbGV0ZWQgYSBmdWxsIHVw
ZGF0ZSBvZiB0aGUgZHJhZnQuICBXaGlsZSB3YWl0aW5nIGZvciBkZXRhaWxzIG9uIGhvdyB0byBw
cm9jZWVkIHdpdGggcmVnYXJkcyB0byBhIFNNLWJpcywgd2UgdGhvdWdodCBpdCB3b3VsZCBiZSBo
ZWxwZnVsIHRvIG1ha2UgdGhpcyB0ZXh0IGF2YWlsYWJsZSBub3cgc28gdGhhdCB0aGUgdGVjaG5p
Y2FsIHBhcnRzIGNhbiBiZSBkaXNjdXNzZWQuICBXaXRoIHRoaXMgaW4gbWluZCwgY2FuIGZvbGtz
IHBsZWFzZSBoYXZlIGEgcXVpY2sgbG9vayBhbmQgcG9zdCBhbnkgdGVjaG5pY2FsIGNvbW1lbnRz
IHRoZXkgaGF2ZT8gIA0KDQoNClRoZSAidHh0IiB2ZXJzaW9uIG9mIHRoZSBkcmFmdDogIGh0dHBz
Oi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9uZXRtb2Qtd2cvc2NoZW1hLW1vdW50L3ByZTA5
L2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC1wcmUtMDkudHh0DQoNCg0KcmZjZGlmZiBh
Z2FpbnN0IHRoZSBjdXJyZW50IC0wOCBkcmFmdDogIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMT1kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQtMDgmdXJsMj1odHRwczovL3Jh
dy5naXRodWJ1c2VyY29udGVudC5jb20vbmV0bW9kLXdnL3NjaGVtYS1tb3VudC9wcmUwOS9kcmFm
dC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQtcHJlLTA5LnR4dA0KDQoNClNpbmNlIHJmYzc4OTVi
aXMgb2Jzb2xldGVzIFJGQyA3ODk1LCB0aGUgc2VydmVyLW11c3QtaW1wbGVtZW50LXJmYzc4OTVi
aXMgcmVxdWlyZW1lbnQgaXMgbm8gc3VycHJpc2UsIHJpZ2h0Pw0KDQpUaGFua3MsDQpLZW50IC8v
IHNoZXBoZXJkDQoNCg0K